REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する - 信頼性の柱
実装のガイダンスリソース

REL10-BP04 バルクヘッドアーキテクチャを使用して影響範囲を制限する

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

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

一般的なアンチパターン:

  • セルを際限なく増殖させる。

  • コードの更新やデプロイをすべてのセルに同時に適用する。

  • セル間で状態またはコンポーネントを共有する (ルーターレイヤーを除く)。

  • 複雑なビジネスロジックやルーティングロジックをルーターレイヤーに追加する。

  • セル間のインタラクションを最小に抑えない。

このベストプラクティスを活用するメリット: セルベースアーキテクチャでは、多数の一般的なタイプの障害がセル自体に封じ込めるため、障害分離が向上します。このような障害境界は、コードのデプロイの失敗や、破損したリクエスト、または特定の障害モードをトリガーするリクエスト (ポイズンピルリクエストとも呼ばれる) など、これ以外の方法では封じ込めが困難なタイプの障害への回復力を実現します。

実装のガイダンス

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

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

セルベースアーキテクチャを示す図

図 11: セルベースアーキテクチャ

実装手順

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

  1. パーティションキー: パーティションキーを選択する際は、特に配慮が必要です。

    • このキーは、サービスの粒度またはサービスのワークロードを最小限のクロスセルインタラクションで分割できる自然な方法に沿って分割を行う必要があります。例としては、 カスタマー ID や リソース ID があります.

    • パーティションキーは、あらゆるリクエストにおいて、直接またはその他のパラメータによって決定論的に容易に推測できる方法で使用できる必要があります。

  2. 永続的なセルマッピング: アップストリームサービスは、リソースのライフサイクル全体にわたり、単一のセルとのみインタラクションを行う必要があります。

    • ワークロードによっては、あるセルから別のセルにデータを移行するためにセル移行戦略が必要となる場合があります。セルの移行が必要になる可能性のあるシナリオには、ワークロード内の特定のユーザーまたはリソースが過剰に増大して、専用のセルが必要になる、といった場合があります。

    • セルは、セル間で状態またはコンポーネントを共有すべきではありません。

    • つまり、セル間のインタラクションは回避するか、最小限に抑える必要があります。これは、このようなインタラクションにより、セル間の依存関係が形成され、障害分離による改善が妨げられるためです。

  3. ルーターレイヤー: ルーターレイヤーはセル間の共有コンポーネントであるため、セルと同様の区分化戦略に従うことはできません。

    • ルーターレイヤーでは、パーティションマッピングアルゴリズムを計算効率の高い方法で使用して、リクエストを個別のセルに分散することをお勧めします。例えば、暗号化ハッシュ関数と合同算術を組み合わせてパーティションキーをセルにマップするなどの方法があります。

    • マルチセルへの影響を回避するには、ルーティングレイヤーを可能な限りシンプルかつ水平方向にスケーラブルなものとする必要があります。この場合、このレイヤー内での複雑なビジネスロジックは避ける必要があります。この方法には期待される動作をいつでも簡単に把握できるという利点があり、完全なテスト容易性が実現します。Colm MacCárthaigh が『Reliability, constant work, and a good cup of coffee (信頼性、動作の継続、一杯のコーヒー)』で説明しているとおり、シンプルな設計と一定の作業パターンは、信頼性の高いシステムを生み出し、アンチフラジャイルの低減につながります。

  4. セルのサイズ: セルにはサイズ制限が必要であり、最大サイズを超えて拡大すべきではありません。

    • 最大サイズを特定するには、限界点に達して安全なオペレーションの限界が明らかになるまで徹底的にテストを実施する必要があります。テストプラクティスの実装方法の詳細については、以下を参照してください。 REL07-BP04 ワークロードの負荷テストを実施する

    • 全体的なワークロードの増大は、セルの追加によるべきです。これにより、需要の拡大に合わせてワークロードをスケーリングできるようになります。

  5. マルチ AZ またはマルチリージョン戦略: さまざまな障害ドメインからの保護として、マルチレイヤーの回復力を活用する必要があります。

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

  6. コードのデプロイ: コードの変更をすべてのセルに同時にデプロイせずに、タイミングをずらしたコードのデプロイ戦略を優先する必要があります。

このベストプラクティスが確立されていない場合のリスクレベル: 高

リソース

関連するベストプラクティス:

関連するドキュメント:

関連動画:

関連する例: