# REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する
<a name="rel_fault_isolation_use_bulkhead"></a>

 このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。 

 セルベースのアーキテクチャ *では*、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの独立性が低下します (そのため、これにより想定される可用性の改善が低下)。 

![\[セルベースアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)


 AWS ブログ投稿で、Colm MacCarthaigh 氏は Amazon Route 53 が [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) の概念を使用して、顧客リクエストをシャードに分離する方法を説明します。この場合、シャードは 2 つ以上のセルで構成されます。パーティションキーに基づいて、顧客 (またはリソース、または分離対象) からのトラフィックは、割り当てられたシャードにルーティングされます。シャードごとに 2 つのセルを持つ 8 つのセルがあり、顧客が 4 つのシャードに分割された場合、問題が発生した場合に影響を受ける顧客は全体の 25% です。 

![\[従来のシャードに分割されたサービスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)


 シャッフルシャーディングでは、それぞれ 2 つのセルを持つ仮想シャードを作成し、顧客をそれらの仮想シャードの 1 つに割り当てます。問題が発生した場合でも、サービス全体の 4 分の 1 が失われる可能性がありますが、顧客またはリソースが割り当てられる方法から、シャッフルシャーディングでは影響を受ける範囲が 25% を大幅に下回ることになります。8 つのセル中の 2 つのセルには 28 のユニークな組み合わせがあります。つまり、シャッフルシャード (仮想シャード) が 28 通りあります。数百または数千の顧客がいて、各顧客を 1 つのシャッフルシャードに割り当てた場合、問題が発生したことで影響を受ける範囲はわずか 1/28 です。これは通常のシャーディングより 7 倍優れています。 

![\[シャッフルシャードに分割されたサービスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)


 シャードは、セルだけでなく、サーバー、キュー、またはその他のリソースにも使用できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  バルクヘッドアーキテクチャを使用します。このパターンは、船の隔壁のように、障害がリクエストまたはユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数を制限し、ほとんどがエラーなしで続行できるようにします。多くの場合、データの隔壁はパーティションと呼ばれ、サービスの隔壁はセルと呼ばれます。 
  +  [Well-Architected ラボ: シャッフルシャーディングを使用した障害分離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/) 
  +  [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
  +  [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20) 
+  ワークロードのセルベースのアーキテクチャを評価します。セルベースのアーキテクチャでは、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングを必要とするサービスは、問題をマッピングサービスにシフトするだけですが、セル間の相互作用を必要とするサービスは、セルの自律性が低下します (そのため、予想された可用性の向上も低下します)。 
  +  Colm MacCarthaigh は、 AWS ブログの記事で、Amazon Route 53 がシャッフルシャーディングの概念を用いて顧客のリクエストをシャードに分離する方法を説明しています。 
    +  [シャッフルシャーディング: 大量およびマジカルな障害切り離し](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [シャッフルシャーディング: 大量およびマジカルな障害切り離し](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation) 
+  [The Amazon Builders' Library: シャッフルシャーディングを使ったワークロードの分離](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/) 

 **関連動画:** 
+  [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20) 
+  [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 

 **関連する例:** 
+  [Well-Architected ラボ: シャッフルシャーディングを使用した障害分離](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)