クラウドは、2つの主要なコンポーネントで構成されています：シングルエントリポイント（ETV）とクラウドマジック（OM）。 Amazon S3クラウドストレージを検討してください。ETBは非常に便利なREST APIを使用しており、Cloud Elvesはドルで稼働しています。 S3に小さなビデオファイルまたはデータベースを配置することを希望する企業は、計画負荷に対して月ごとに支払う金額を計算機で事前に計算します。
この記事は、エルフが自由の精神、電気を供給し、少しの「 コカイン 」も必要とする別のクラウドストレージに関するものです。
これは、 Ellipticsリポジトリと呼ばれます。
その作成の歴史は、 POHMELFSの一部として2007年に遡ります。 翌年、Ellipticsは別のプロジェクトに移され、分散データストレージへのさまざまなアプローチが試されました。それらの多くは、現実の実用性が少なすぎるため、複雑さのため適合しませんでした。 最終的に、その作者であるユージン・ポリヤコフは、現代の形で楕円学を創り出しました。
耐障害性
これは、Ellipticsが保存を目指す5つの要素の最初のものです。 車は絶えず故障し、ハードドライブは故障し、時々エルフは攻撃を受けて樹皮を投げます。 また、Black MagicとWitchcraftの力により、データセンターはいつでも世界から脱落する可能性があります。 これらの最も明らかなものは、ケーブルの破損と電気の損失です。
悲しい話
一度、雨の間、1匹の子猫が寒く感じたので、彼は自分自身を暖めることにしました。 近くに単一の部屋はありませんでしたが、GOSTに厳密に従って作られた変圧器ボックスは例外で、開口部は10センチメートル未満でした。変圧器が短絡し、1匹の子猫が小さくなり、データセンターは電気なしになりました。 これは週末、土曜日に発生したため、常勤の電気技師は職場にいないため、電力供給を回復できませんでした。 もちろん、ディーゼル発電機は利用可能で動作しましたが、燃料は数時間で十分でした。 セキュリティサービスは、データトラックの領土内に燃料トラックと呼ばれるものを入れることを拒否しました。 最終的に、すべてが安全に決定されましたが、誰もそのような状況から安全ではありません。
ドライブまたはサーバーが切断された場合の対処方法は誰もが長い間知っていました。 しかし、データセンター、Amazonリージョン、または別の大きなイベントが発生した場合、システムに何が起こるのか不思議ではありません。 Ellipticsはもともと、この種の問題を解決するために計画されました。
Ellipticsでは、すべてのドキュメントは512ビットキーを使用して保存されます。これは、ドキュメント名のsha512関数の結果として取得されます。 すべてのキーは、0〜2 512の値の範囲を持つリングである分散ハッシュテーブル （DHT）として表すことができます。 リングは1つのグループ内のすべてのマシン間でランダムに分割され、各キーは複数の異なるグループに同時に保存できます。 1つのグループが1つのデータセンターであるとおおよそ推測できます。 原則として、Yandexはすべてのドキュメントのコピーを3つ保存します。一部のマシンに障害が発生した場合、リングの一部のコピーは1つしか失われません。 データセンター全体に障害が発生した場合でも、情報は失われず、すべてのドキュメントが少なくとも2つ以上のコピーに残されるため、エルフは人々に喜びをもたらすことができます。
拡張性
Elf管理者は常に追加のマシンを接続できるようにしたいと考えていましたが、Ellipticsはそれを実行できます！ グループに新しいコンピューターを接続すると、それらの2,512個のキーからランダムな間隔がかかり、これらのキーに対する以降のすべての要求はこのコンピューターに送信されます。
それぞれが数百台のマシンで構成される3つのグループがある場合、新しいマシンを追加するとリバランスが必要になり、その結果、それらを復元するために大量のデータをネットワーク経由で転送する必要があります。 これに適さない人のために、 コカインクラウドプラットフォームで実行される負荷分散システム-Mastermindを開発しました。 Mastermindは、各サーバーの負荷に基づいて特定のファイルを保存するグループを決定するピアツーピアピアのセットです。 難しい数学の魔法もここにあります-空き容量、ディスク負荷、CPU負荷、スイッチ負荷、ドロップレートなどが考慮されます。 Mastermindノードのいずれかに障害が発生した場合、以前と同様にすべてが機能し続けます。 グループのサイズを小さく保つと、新しいマシンを追加するときに、新しいグループを発行してMastermindに知らせるだけで十分です。 この場合、どのグループを検索するかに関する情報がファイル識別子に追加されます。 このメカニズムにより、真に無限かつ非常にシンプルなストレージ拡張が可能になります。
データセキュリティ
バランス調整後、または紛失した場合でも間違ったマシン上にあることが判明した古いデータをシステムがどのように処理するかを見てみましょう。
この場合、Ellipticsは回復システムを提供します。 彼女の仕事のスキームは次のとおりです。彼女はすべてのマシンを通過し、データが自分のマシン上にない場合、それらを正しいマシンに移動します。 一部のドキュメントが3つのコピーにないことが判明した場合、この手順中にドキュメントに必要なマシンが乗算されます。 さらに、システムがMastermindで動作する場合、ファイルの場所のグループ番号はメタ情報から取得されます。 回復速度は多くの要因に依存し、キー回復の正確な速度を呼び出すことはできませんが、負荷テストが示すように、ボトルネックはデータ転送に使用されるマシン間のネットワークチャネルです。
スピード
Ellipticsはオーバーヘッドが低く、キャッシュを操作するときに1台のマシンで1秒あたり最大24万回の読み取りを実行できます。 ディスクを使用する場合、速度は自然に低下し、ディスクからデータを読み取る速度に依存します。
Ellipticsに基づいて、HistoryDBプロジェクトが実装されました。 その助けを借りて、さまざまな外部イベントからのログを保存します。 テスト中、3台のマシンのグループは、3000万人のユーザーからのログが書き込まれたときに、1秒あたり1万件の要求に冷静かつスムーズに対処しました。 同時に、それらの10％がすべてのデータの80％を生成しました。 合計3,000万人のユーザーが毎日約5億の更新を占めました。 ただし、このデータを単に保存するのは簡単です。 したがって、システムは、負荷がかかった状態で、特定の期間（日/月）にアクティブだったすべてのユーザーのリストを取得し、任意のユーザーのログを任意の日で見ることができ、ユーザーデータに他のセカンダリインデックスを追加できるようにテストされました。
また、Ellipticsに基づいて、YandexはYandex.Music、Photos、Maps、Market、Vertical Search、People Search、Backup Mailなどのサービスを構築しました。 移動の準備とYandex.Disk。
シンプルなアーキテクチャ
Ellipticsでは、クライアントはサーバーに直接接続します。これにより、次のことが可能になります。
- シンプルなアーキテクチャを備えています。
- トランザクションが正しく実行されることを確認します。
- グループ内のどのマシンが特定のキーを担当しているかを常に把握してください。
データストレージサービスのユーザーには、データの書き込み、削除、読み取り、処理を簡単に行える次のAPIがあります。
- C ++ 11の非同期ライブラリ
- Pythonバインディング
- FastCGIおよびTheVoidに基づくHTTPフロントエンド（boost :: asioを使用）
ただし、特効薬はなく、Ellipticsには独自の制限と問題があります。
- 最終的な一貫性。 Ellipticsは完全に配布されているため、さまざまな問題が発生した場合、サーバーは現在のバージョンよりも古いバージョンのファイルをレンダリングすることがあります。 場合によっては、これが適用できない場合があります。応答時間が低下するため、より信頼性の高いデータ要求方法を使用できます。
- クライアントが複数のサーバーに並行してデータを書き込むため、クライアントとサーバー間のネットワークがボトルネックになる可能性があります。
- APIは、高レベルのクエリには便利ではない場合があります。 現時点では、便利なSQLのようなデータクエリは提供していません。
- また、Ellipticsには高レベルのトランザクションサポートがないため、コマンドのグループがすべて実行されるか、まったく実行されないことを保証することはできません。
次の記事では、Ellipticsの使用例を示し、さらに技術的な詳細を説明します。キャッシュの内部構造、eblobバックエンドの操作、データストリーミング、セカンダリインデックスなどです。