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

バルクヘッドアーキテクチャ (セルベースアーキテクチャとも呼ばれる) を実装して、ワークロード内の障害の影響を限られた数のコンポーネントに制限します。

 **期待される成果:** セルベースアーキテクチャでは、複数の分離されたワークロードのインスタンスを使用します。各インスタンスはセルと呼ばれます。各セルは独立しており、その他のセルとは状態を共有せず、ワークロードのリクエスト全体のサブセットを処理します。これにより、不適切なソフトウェア更新などの障害による個別のセルおよび処理中のリクエストへの予測される影響が軽減されます。例えばワークロードが 10 個のセルを使用して 100 個のリクエストを処理していると、障害が発生した場合、リクエスト全体の 90% は障害の影響を受けません。

 **一般的なアンチパターン:** 
+  セルを際限なく増殖させる。
+  コードの更新やデプロイをすべてのセルに同時に適用する。
+  セル間で状態またはコンポーネントを共有する (ルーターレイヤーを除く)。
+  複雑なビジネスロジックやルーティングロジックをルーターレイヤーに追加する。
+  セル間のインタラクションを最小に抑えない。

 **このベストプラクティスを活用するメリット:** セルベースアーキテクチャでは、多くの一般的な障害はセル自体に封じ込められるため、障害の分離を強化できます。このように障害を分離することで、コードのデプロイに失敗したり、リクエストが破損したり特定の障害モードを呼び出したり (ポイズンピルリクエスト) するなど、他の方法では封じ込めが難しい障害が起きても回復が可能になります。

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

 船ではバルクヘッドが使用されており、船体が破損しても、船体の一部のセクションのみに封じ込めることができます。複雑なシステムでは、このパターンを模して障害分離を実現する場合がよくあります。障害部分を分離した境界は、ワークロード内の障害の影響を限られた数のコンポーネントに限定します。境界の外部のコンポーネントは、障害の影響を受けません。障害を分離した複数の境界を使用して、ワークロードへの影響を制限することができます。AWS では、複数のアベイラビリティーゾーンとリージョンを使用して障害分離を実現できます。この障害分離の概念はワークロードのアーキテクチャにも拡張できます。

 ワークロード全体は、パーティションキーによってセルに分割されます。このキーは、サービスの粒度に従うか、サービスのワークロードをセル間のインタラクションを最小限にして分割できる自然な方法に従う必要があります。パーティションキーの例には、カスタマー ID、リソース ID、またはほとんどの API コールで簡単にアクセスできるその他のパラメータなどがあります。セルルーティングレイヤーは、パーティションキーに基づいて個々のセルにリクエストを分散し、クライアントに単一のエンドポイントを提示します。

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


 **実装手順** 

 セルベースアーキテクチャを設計する場合、以下のとおり、考慮すべき設計上の考慮事項がいくつかあります。

1.  **パーティションキー:** パーティションキーを選択するときは特に注意が必要です。
   +  このキーは、サービスの粒度またはサービスのワークロードを最小限のクロスセルインタラクションで分割できる自然な方法に沿って分割を行う必要があります。例えば、`customer ID` や `resource ID` などがあります。
   +  パーティションキーは、あらゆるリクエストにおいて、直接またはその他のパラメータによって決定論的に容易に推測できる方法で使用できる必要があります。

1.  **永続的なセルマッピング:** アップストリームのサービスは、リソースのライフサイクルを通じて 1 つのセルとしかやり取りできません。
   +  ワークロードによっては、あるセルから別のセルにデータを移行するためにセル移行戦略が必要となる場合があります。セルの移行が必要になる可能性のあるシナリオには、ワークロード内の特定のユーザーまたはリソースが過剰に増大して、専用のセルが必要になる、といった場合があります。
   +  セルは、セル間で状態またはコンポーネントを共有すべきではありません。
   +  つまり、セル間のインタラクションは回避するか、最小限に抑える必要があります。これは、このようなインタラクションにより、セル間の依存関係が形成され、障害分離による改善が妨げられるためです。

1.  **ルーターレイヤー:** ルーターレイヤーはセル間で共有されたコンポーネントであるため、セルと同じ区分化の戦略をとることはできません。
   +  ルーターレイヤーでは、パーティションマッピングアルゴリズムを計算効率の高い方法で使用して、リクエストを個別のセルに分散することをお勧めします。例えば、暗号化ハッシュ関数と合同算術を組み合わせてパーティションキーをセルにマップするなどの方法があります。
   +  マルチセルへの影響を回避するには、ルーティングレイヤーを可能な限りシンプルかつ水平方向にスケーラブルなものとする必要があります。この場合、このレイヤー内での複雑なビジネスロジックは避ける必要があります。この方法には期待される動作をいつでも簡単に把握できるという利点があり、完全なテスト容易性が実現します。Colm MacCárthaigh が「[信頼性、動作の継続、1 杯のおいしいコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/)」で述べているとおり、信頼性の高いシステムを生み反脆弱性を最小限に抑えるものは、シンプルな設計と継続的な取り組みです。

1.  **セルのサイズ:** セルにはサイズの上限を設定する必要があり、それを超えるサイズは許容すべきではありません。
   +  最大サイズを特定するには、限界点に達して安全なオペレーションの限界が明らかになるまで徹底的にテストを実施する必要があります。テストプラクティスの実装方法の詳細については、「[REL07-BP04 ワークロードの負荷テストを実施する](rel_adapt_to_changes_load_tested_adapt.md)」を参照してください。
   +  全体的なワークロードの増大は、セルの追加によるべきです。これにより、需要の拡大に合わせてワークロードをスケールできるようになります。

1.  **マルチ AZ またはマルチリージョン戦略:** さまざまな障害に対抗するには、耐障害性を多層的に活用する必要があります。
   +  回復力のためには、複数の防御層を構築するアプローチを使用する必要があります。1 つの層では、複数の AZ を使用して高可用性アーキテクチャを構築することによって、小規模で一般的な混乱に対して保護します。もう 1 つの防御層では、広範囲の自然災害やリージョンレベルの混乱など、まれな出来事に対して保護します。この 2 番目の層には、複数の AWS リージョンにまたがるアプリケーションの設計が必要です。ワークロードのためのマルチリージョン戦略の実装は、国の広い範囲に影響を与える自然災害や、リージョン全体に及ぶ技術的障害に対する保護に役立ちます。マルチリージョンアーキテクチャの実装はかなり複雑になることがあり、通常、ほとんどのワークロードには不要である点に注意してください。詳細については、「[REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)」を参照してください。

1.  **コードのデプロイ:** コードの変更は、すべてのセルに同時にデプロイするのではなく段階的にデプロイする方法が推奨されます。
   +  これにより、不適切なデプロイや人的エラーによる複数のセルでの障害発生可能性を最小限に抑えることができます。詳細については、「[安全なハンズオフデプロイメントの自動化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)」を参照してください。

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

 **関連するベストプラクティス:** 
+  [REL07-BP04 ワークロードの負荷テストを実施する](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md) 

 **関連ドキュメント:** 
+  [信頼性、動作の継続、1 杯のおいしいコーヒー](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS and Compartmentalization](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [シャッフルシャーディングを使ったワークロードの分離](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [安全なハンズオフデプロイメントの自動化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **関連動画:** 
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [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) 
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience ](https://www.youtube.com/watch?v=wUzSeSfu1XA)