REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する
このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。
セルベースのアーキテクチャ では、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの独立性が低下します (そのため、これにより想定される可用性の改善が低下)。
図 11: セルベースアーキテクチャ
AWS ブログ投稿で、Colm MacCarthaigh 氏は Amazon Route 53 が シャッフルシャーディング
図 12: それぞれ 2 つのセルを持つ 4 つの従来のシャードに分割されたサービス
シャッフルシャーディングでは、それぞれ 2 つのセルを持つ仮想シャードを作成し、顧客をそれらの仮想シャードの 1 つに割り当てます。問題が発生した場合でも、サービス全体の 4 分の 1 が失われる可能性がありますが、顧客またはリソースが割り当てられる方法から、シャッフルシャーディングでは影響を受ける範囲が 25% を大幅に下回ることになります。8 つのセル中の 2 つのセルには 28 のユニークな組み合わせがあります。つまり、シャッフルシャード (仮想シャード) が 28 通りあります。数百または数千の顧客がいて、各顧客を 1 つのシャッフルシャードに割り当てた場合、問題が発生したことで影響を受ける範囲はわずか 1/28 です。これは通常のシャーディングより 7 倍優れています。
図 13: それぞれ 2 つのセルを持つ 28 のシャッフルシャード (仮想シャード) に分割されたサービス (28 通りのうち 2 つのシャッフルシャードのみを表示)
シャードは、セルだけでなく、サーバー、キュー、またはその他のリソースにも使用できます。
このベストプラクティスを活用しない場合のリスクレベル: ミディアム
実装のガイダンス
バルクヘッドアーキテクチャを使用します。このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。
ワークロードのセルベースのアーキテクチャを評価します。セルベースのアーキテクチャでは、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの自律性が低下します (そのため、予想された可用性の向上も低下します)。
-
Colm MacCarthaigh は、 AWS ブログの記事で、Amazon Route 53 がシャッフルシャーディングの概念を用いて顧客のリクエストをシャードに分離する方法を説明しています。
-
リソース
関連するドキュメント:
関連動画:
関連する例:
