2011年10月、モスクワは、負荷の高いHighLoad ++プロジェクトの開発者による年次会議を開催しました。
会議の主要なポイントを読者と共有することにしました。 すべての情報は公開されており、会議ページで利用できるため、すべての論文をまとめることはそれほど悪い考えではないと判断しました。 レポートには、各レポートに関する詳細な情報は含まれていません。重要な点のみが触れられています。
HighLoad ++ 2011で言われたことです。
「大人の方法で」クラウドベースのWebサービスを設計する/ Sergey Ryzhikov（1C-Bitrix）
1Cには、ロシア、アメリカ、ヨーロッパに3つのデータセンターがあります。 データセンター間の通信が失われると、数時間かかる場合があります。 非同期マスター複製は、データベースサーバー間で構成されます。
すべてのアーキテクチャは、Amazon Web Servicesから構築されています。
静的コンテンツの場合、Amazon S3が使用されます。 とりわけ、利点はEBSと比較してこのようなソリューションの低価格です。
Elastic Cloud Balancing、CloudWatch、およびAuto Scalingで使用されます。
DBのある車-EC2で。 それぞれ17.1Gb RAM。 ソフトウェアRAIDアレイはEBSディスクから構築されます。 RAID-10は、最速かつ最も信頼性の高いものとして選択されています。
InnoDBによって使用されます。
バックアップは、FSフリーズを使用してEC2のスナップショットを使用して行われます。
Amazon RBSは、次の理由で使用されていません。
- データベースに完全なルートがありません
- 透明ではない
- 長時間のダウンタイムのリスク
Odnoklassnikiバイナリデータウェアハウスアーキテクチャ/ Alexander Khristoforov、Oleg Anastasiev（Odnoklassniki）
one-dbを使用する可能性が最初に評価されました。 次の制限がありました。
- 悪いパフォーマンス
- 長いバックアップ（最大17時間）
現在のソリューションは、zookeeperクラスターとストレージクラスターを実装しています。
ストレージクラスターの各ノードには、N個のストアがあります。 それぞれに、データセグメント（256 Mb）とRAID1ログアレイが別々のディスクにあります。 IO処理は、NIO Socket Server（Mina）によって処理されます。
予約はxfs_ioを使用して発生します。
インデックスは、通常の配列に基づいたハッシュテーブルを使用します。 直接メモリに直接保存されます。
起動時に、データの整合性がチェックされます。 ログは同期され、必要に応じて消去されます。
複製係数-3。
ルーティングはパーティションに基づいています。 ハッシュIDが計算され、N個のストレージで割った余りが計算されます。 計算されたパーティション値はルーティングテーブルで検索され、データディスクが検索されます。
リージョンの概念が使用されます。 拡張のためにデータを移動する必要はありません。
Zookeeperは調整に使用されます。 その利点は、信頼性とパフォーマンスです。 Zookeeperは次のデータを保存します。
- 利用可能なサーバーとそのアドレス
- ドライブの場所とステータス
- ルーティングテーブル
- 分散ロック
MongoDB / Sergey Tulentsevを使用しない理由
レポートのキーポイント：
- マップ/低速でシングルスレッドの削減
- map / reduceの各操作は読み取りまたは書き込みロックを課します
- メモリマップファイルの問題-システムのメモリ管理が不十分
- すべてのシャードが等しい場合、あまり便利ではありません。 組み込みの自動共有が適切に構成されていない
RuNetで初めて：1日あたり1億文字の物語/ Andrey Sas（Badoo）
非同期送信を使用しました。 送信キューは、ファイルに基づいて実装されます-ネイティブツール、ロギング、読み取り/書き込みの容易さ。
sendmailの代わりに、SSMTPクライアントが使用されます。
メモリ内は、フォールトトレランス（文字を失うことへの恐怖）には使用されません。
ローカルDNSクエリキャッシュを実装し、DNSおよびSMTPワーカーの数を増やしました。
複雑なシステムの管理に関するレシピの大本またはよくある質問/アレクサンダー・ティトフ、イゴール・クロッキン（スカイプ）
Cobblerツールを使用することをお勧めします。 このツールは、さまざまなLinuxディストリビューションをサポートし、便利な相互作用メカニズムを備えています。
構成管理用-シェフ。
監視-Zabbix API。
統計、データベース、リポジトリのバックアップ。
大規模なデータ収集アプリケーションの設計/ Josh Berkus
Mozilla Soccoroプロジェクトを使用して、転倒に関する統計を収集することをお勧めします。 情報を保存するには、hbaseが最もスケーラブルなソリューションとして使用されます。 同時に、データ自体はhbase（30ノードで40 TB）に保存されます。 メタデータ（500 GB）の保存には、2つのPostgreSQLサーバーが責任を負います。 6台のサーバーが負荷分散を行っています。
構成管理のツールとして-puppet。
12 Redisのユースケース-Tarantool / Alexander Kalendarev、Konstantin Osipov（Mail.ru）
Tarantool-最もホットなデータを保存するためのNoSQL DBMS。 TarantoolはすべてのデータをRAMに保存し、すべての変更をディスクに記録するため、障害発生時のデータの信頼性が保証されます。 メモリにデータを保存すると、最大パフォーマンスでクエリを実行できます-従来の最新の機器で毎秒200〜30万クエリ。
スケーリングは、tarantoolプロキシとシャードに基づいて行われることが提案されています。
まもなくtarantoolは次の機能も取得します。
- トランザクションサポート
- マスター複製マスター
- クラスターマネージャー
- ロードバランサー
Javaのガベージコレクションの秘密/ Alexey Ragozin
メモリ内のリンクをカウントすることは最良のツールではありません。 巡回グラフからあなたを救うわけではありません。マルチスレッドではうまく機能しません。 また、CPU負荷の15〜30％です。
世代仮説によると、ほとんどのオブジェクトは若くして死にます。 それらが存在する限り、それらは少数の他のオブジェクトによって参照されます。 したがって、「若い」オブジェクトと「古い」オブジェクトのストレージを分離することにより、生産性を向上させることができます。
HotSpotのようなJVMには、多くのキーがあります。 キーを使用する可能性に関する情報は、Alexeyのブログに含まれています。
機密性の高いガベージコレクションアプリケーションを一時停止するには、Concurrent Mark Sweep GCを使用することをお勧めします。 特に含まれるもの：-XX：+ ExplicitGCInvokesConcurrent
CMSは多くの場合、アプリケーションの操作中にガベージを収集します。「新しい」世代のオブジェクトはstop-the-worldモード（かなり速い操作）で収集され、「古い」世代は並行して長時間収集されます。 したがって、アプリケーションは生成仮説の条件を満たす必要があります。
その結果、32 GBのヒープの場合、一時停止が150ミリ秒に達することはありません。
オプションとして、オフヒープメモリを使用します。 しかし、これはすでにはるかに難しい作業です。
Apache Cassandra-別のNoSQLストレージ/ Vladimir Klimontovich
Apache Cassandra = Amazon Dynamo + Google Bigtable。
トークンリングトポロジに基づくデータパーティション分割のテクノロジが使用されます。 レプリケーションもこのトポロジに基づいています。 この点で、CassandraはAmazon Dynamoに似ています。
キー/値データモデルはBigtableから取得されます。 複雑なクエリが利用可能、インデックス（役に立たないもの）。
LIFO要求キャッシュメカニズム。
最も簡単なスケーリング方法は2倍です。 次に、パーティションセグメントの範囲を単純に2で除算します。
ノードは、Thriftプロトコルに基づいて相互に通信します。
AJAX Layout / Oleg Illarionov（VK）
ページは、AJAXリクエストを個別に送信するいくつかのiframeに分割されます。
HTML5は、特にローカルストレージとして積極的に使用されています。
並行して、静的とコンテンツが接続されます。
ページがキャッシュされます。 独自のスタブを使用して、ブラウザーのHistory APIを操作します。 戻ると、ツリーがDOMから削除され、環境変数がコピーされます。
コンテンツをすばやく検索するために、クライアントで検索が行われます。
NginxとOpenstack Swiftの統合に基づいて静的コンテンツを保存および配信するためのクラウドストレージを構築する/ Stanislav Bogatyrev、Nikolay Dvas（Clodo）
クラウドで使用するには、Amazon S3やRackspace Cloud Filesなどのオブジェクトストレージが適切なソリューションのようです。 Clodoクラウドストレージは、Swiftテクノロジー（基盤となるRackspace Cloud Files）を使用して構築され、主にWebサイトのコンテンツの格納と配信を目的としています-構築の主な重点は、より一般的なS3やクラウドファイル コンテンツを多数のクライアントに配信する場合、Swiftリポジトリの動作は遅くなります。 したがって、nginxはフロントエンドとして変更され、2つの側面で変更されました。
マルチゾーンキャッシュの追加（キャッシュに使用される高価なディスクのディスク容量を40％節約できます）;
それぞれに独立したnginxを持つフロントエンドクラスターを使用するときに、オブジェクトごとのキャッシュクリーニングとpokonteinernyキャッシュクリーニングの両方を管理するメカニズムを追加しました。
PSこの記事が説明の性質（非常に簡潔な情報、スライドの要約、講演者のスピーチ）のために否定的な反応を引き起こさないことを願っています。 この記事ではすべてのレポートについて説明しているわけではありません。公式Webサイトでは、欠落しているすべてのスピーチに関する情報を見つけることができます。
PPS HighLoad ++を編成してくれたOleg BuninとOntikoの代表のおかげで、2012年の次の会議を楽しみにしています！