Delta: チェーンレプリケーションを使用した高可用性、強く一貫したストレージ (2022)

Kumar Mrinal、Binbin Luによる 過去数年間にわたり、Metaはさまざまなユースケースやワークロード特性に対応する数多くのストレージサービスを提供してきました。その過程で、ストレージ分野のシステムを削減・統合することを目指してきました。同時に、クリティカルなパッケージワークロード専用のソリューションを持つことは、すべての人をより幸せにします。これは、ディザスタリカバリとブートストラップ戦略のために不可欠です。この認識と、Metaのビルドおよび配布アーティファクトにストレージを提供するビジネスニーズが組み合わさって、新しいオブジェクトストレージサービスであるDeltaが誕生しました。 MetaインフラストラクチャスタックにおけるDeltaの位置付け（下記参照）を考えてみてください。これは最下層に位置し、残りのインフラストラクチャの可用性とリカバリ可能性に必要な基本的なプリミティブを提供します。ブートストラップシステムの場合、ソリューションをより信頼性の高いものにする場合にのみ、複雑さを導入すべきです。パフォーマンスと効率性については、最小限しか関心がありません。ブートストラップシステムに関するもう1つの考慮事項は、ブートストラップ自体です。エンジニアが少数のマシンにアクセスしてインフラストラクチャの残りを復元できるこのプロセスは、製品をユーザーが利用できる状態に戻すのに役立ちます。最後に、ブートストラップデータは、災害が発生した場合のリカバリのためにバックアップする必要があります。この記事では、Deltaの目標、Deltaのアーキテクチャを管理する主要な概念、Deltaの本番環境でのユースケース、リカバリプロバイダーとしての進化、および今後の作業項目について説明します。 Deltaとは何か？ Deltaは、シンプルで信頼性が高く、スケーラブルで、依存性の低いオブジェクトストレージシステムです。put、get、delete、listの4つの高レベル操作のみを備えています。Deltaは、シンプルさと信頼性を優先するために、レイテンシとストレージ効率を犠牲にします。水平スケーラブルであるため、Deltaは最小限の依存関係で、ソフトな依存関係に対して適切なフェイルオーバー戦略を備えています。 Deltaは以下のものではありません： 汎用ストレージシステム：Deltaのコア原則は、レジリエンスとデータ保護です。低依存性システムで使用するために特別に設計されています。 ファイルシステム：Deltaはシンプルなオブジェクトストレージシステムとして機能します。Posixなどのファイルシステムセマンティクスを公開する意図はありません。 ストレージ効率を最大化するように最適化されたシステム：レジリエンスを主要な原則とし、クリティカルシステムに焦点を当てているため、Deltaはストレージ効率、レイテンシ、またはスループットを最適化する意図はありません。 Deltaのアーキテクチャ Deltaは、フェイルストップストレージサーバーのクラスタを調整するアプローチであるチェーンレプリケーションを本番環境で稼働させています。これは、強い一貫性保証を犠牲にすることなく、高いスループットと可用性を示す大規模ストレージサービスをサポートすることを目的としています。Deltaがクライアントデータをレプリケートするためにチェーンレプリケーションをどのように活用するかを詳しく説明する前に、まずチェーンレプリケーションの基本を探ってみましょう。 チェーンレプリケーション 基本的に、チェーンレプリケーションはサーバーを線形にチェーン状に配置します。リンクドリストのように、各チェーンはオブジェクトのレプリカを冗長に格納するホストのセットを含みます。各チェーンには一連のサーバーが含まれます。最初のサーバーをヘッド、最後のサーバーをテールと呼びます。下の図は4つのサーバーを持つチェーンの例を示しています。各書き込みリクエストはヘッドサーバーにルーティングされます。更新はチェーンを通じてヘッドサーバーからテールサーバーにパイプライン処理されます。すべてのサーバーが更新を永続化した後、テールが書き込みリクエストに応答します。読み込みリクエストはテールサーバーのみにルーティングされます。クライアントがチェーンのテールから読み取れるものは、チェーンに属するすべてのサーバーにレプリケートされており、強い一貫性を保証します。 チェーンレプリケーション vs. クォーラムレプリケーション チェーンレプリケーションが何を意味するかの概要を説明したので、他の広く使用されているレプリケーション戦略と比較してチェーンレプリケーションがどのように機能するかを探ってみましょう。 ストレージ効率：チェーンレプリケーションは、明らかに最もストレージ効率の高いレプリケーション戦略を提供しません。チェーン内のすべてのホストにデータセット全体の冗長コピーを格納します。比較的に効率的なアプローチには、イレージャーコーディング技術を使用してデータフラグメントをインテリジェントにレプリケートすることが含まれます。 耐障害性：最適なバケットレイアウトでは、チェーンレプリケーションはクォーラムベースのレプリケーションメカニズムと同等またはそれ以上の耐障害性を提供できます。なぜなら？ `n`ノードのチェーンは、可用性を損なうことなく最大`n – 2`ノードまでの障害を許容できます。対照的に、クォーラムベースのレプリケーションシステムでは、書き込みを処理するために少なくとも`w`ホストが利用可能である必要があります。さらに、読み取りを処理するために`r`ホストが利用可能である必要があります。ここで`w`と`r`はそれぞれ書き込みクォーラムサイズと読み取りクォーラムサイズを表します。 パフォーマンス：レプリケーション戦略（プライマリバックアップなど）では、すべてのバックアップサーバーが読み取りを処理できます。これにより、読み取りスループットが増加します。チェーンレプリケーションのネイティブな考え方では、チェーンのテールのみが読み取りを処理できます。（この部分は最適化されており、後でこの記事の「割り当てられたクエリ」セクションで詳細を共有します。）クォーラムベースのレプリケーションメカニズムと同様に、チェーンレプリケーションではすべての書き込みはプライマリ（チェーンのヘッド）にルーティングされます。しかし、チェーンレプリケーションでは、チェーン内のすべてのホストが更新を認識した後でのみ書き込みに応答されます。したがって、チェーンレプリケーションは、クォーラムベースのレプリケーションメカニズムと比較して、平均書き込みレイテンシが高くなります。 クォーラムコンセンサス：クォーラムベースのシステムは、システム内のクォーラムを維持するために複雑なコンセンサスおよびリーダー選出メカニズムを必要とします。対照的に、チェーンレプリケーションベースのシステムにおけるクォーラムコンセンサスの範囲は、はるかに単純なチェーンホストマッピングに狭められます。たとえば、チェーンヘッドは、明示的なリーダー選出を必要とせずに、常に書き込み処理のリーダーとして機能します。 上記の違いを考慮すると、チェーンレプリケーションはマシン間でデータをレプリケートするための最もストレージ効率の高い方法を提供できないことは明らかです。さらに、チェーン内のすべてのリンクが更新を永続化した場合にのみ書き込みを成功と見なすため、クォーラムベースのシステムと比較して平均書き込みレイテンシが高くなります。しかし、同等の耐障害性と一貫性保証を提供しながら、非常にシンプルです。 Deltaバケットの解剖 チェーンレプリケーションの予備的な理解が得られたところで、Deltaがそれをどのように活用して複数のサーバー間でデータをレプリケートするかについて説明しましょう。上記の各Deltaバケットには複数のチェーンが含まれています。各チェーンは通常4つ以上のサーバーで構成されており、これは望ましいレプリケーションファクターに基づいて変化する可能性があります。各チェーン自体はレプリカセットとして機能し、データとトラフィックのスライスを提供します。これは、クライアントデータセットの論理的なシャードと考えることができます。特定のチェーン内のサーバーは、さまざまな障害ドメイン（電源、ネットワークなど）に分散されます。これにより、1つ以上の障害ドメインのサーバーが利用できなくなった場合でも、クライアントデータの耐久性と可用性が保証されます。 バケットレイアウトの権威であるバケットコンフィグを維持します。バケットにサーバーやチェーンを追加または削除すると、バケットコンフィグは適切に更新されます。クライアントがDeltaバケット内のオブジェクトにアクセスするとき、オブジェクト名のハッシュ値によって適切なチェーンが選択されます。書き込みは常に適切なチェーンのヘッドにルーティングされます。ローカルストレージにデータを書き込み、チェーン内の次のホストに書き込みを転送します。チェーンの最後のホストがローカルメディアにデータを永続的に格納した後でのみ、書き込みが確認されます。読み取りは常に適切なチェーンのテールにルーティングされます。これにより、完全にレプリケートされたデータのみが表示され、読み取り可能であることが保証され、それによって強い一貫性が保証されます。Deltaは、バケットに新しいサーバーを追加し、サービスの可用性やスループットに影響を与えることなく、新しいサーバーにチェーンをインテリジェントに再分散することで、水平スケーラビリティをサポートします。たとえば、1つの戦術は、最も多くのチェーンを持つサーバーが、負荷を再分散するために新しいサーバーにいくつかのチェーンを転送することです。新しいバケットレイアウトは、望ましい障害ドメインのdを引き続きフォローします。