"このコンテンツは古いものです。現在、このバージョンの Well-Architected Framework は、次の場所にあります。 https://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/reliability.html

REL 10: ワークロードを保護するために障害分離をどのように使用しますか?

障害部分を分離した境界は、ワークロード内の障害の影響を限られた数のコンポーネントに限定します。境界外のコンポーネントは、障害の影響を受けません。障害部分を切り離した境界を複数使用すると、ワークロードへの影響を制限できます。

リソース

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

ベストプラクティス:

改善計画

複数の場所にワークロードをデプロイする

  • 複数のアベイラビリティーゾーンと AWS リージョンを使用する: ワークロードデータとリソースを複数のアベイラビリティーゾーンに分散するか、必要に応じて複数の AWS リージョンにかけて分散します。これらのロケーションは、必要に応じて多様化できます。
  • ワークロードを複数のリージョンにデプロイする必要がある場合は、マルチリージョン戦略を選択します: 信頼性のほとんどのニーズは、マルチアベイラビリティーゾーン戦略を使用して単一の AWS リージョン内で満たすことができます。必要に応じて、ビジネスニーズを満たすためにマルチリージョン戦略を使用します。
    AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
  • ワークロードの AWS Outposts を評価する: ワークロードでオンプレミスのデータセンターへの低レイテンシーが必要な場合、またはローカルのデータ処理要件がある場合があります。その場合、AWS Outposts を使用してオンプレミスで AWS インフラストラクチャとサービスを実行します。
    What is AWS Outposts?
  • AWS ローカルゾーンがユーザーにサービスを提供するのに役立つかどうかを判断する: o 低レイテンシーの要件がある場合は、AWS ローカルゾーンがユーザーの近くにあるかどうかを確認してください。近くにある場合は、それらのユーザーに近いワークロードをデプロイするのに使用します。
    AWS Local Zones FAQ

    • 単一のロケーションに制約されるコンポーネントのリカバリを自動化する

  • 自己修復を実装する: 可能であれば自動スケーリングを利用して、インスタンスとコンテナをデプロイします。自動スケーリングを利用できない場合は、EC2 インスタンスの自動復旧機能を利用するか、Amazon EC2 または ECS のコンテナのライフサイクルイベントを利用して自己修復自動化を実装します。
  • 単一インスタンス IP アドレスや、プライベート IP アドレス、elastic IP アドレス、インスタンスメタデータを必要とするワークロードには、EC2 インスタンスの自動復旧機能を使用します。
    Recover your instance.
  • 自動スケーリングや EC2 の復旧機能を利用できない場合は、EC2 インスタンスのライフサイクルイベントや ECS イベントを利用して、自己修復を自動化します。
    EC2 Auto Scaling lifecycle hooks
    Amazon ECS events

    • バルクヘッドアーキテクチャを使用する

  • バルクヘッドアーキテクチャを使用する: 船の隔壁のように、このパターンは、障害がリクエスト/ユーザーの小さなサブセットに確実にとどまるようにすることで、障害のあるリクエストの数が制限され、ほとんどがエラーなしで続行されます。データの隔壁は通常パーティションまたはシャードと呼ばれ、サービスの隔壁はセルと呼ばれます。
    Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
    AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
  • ワークロードのセルベースのアーキテクチャを評価する: セルベースのアーキテクチャでは、各セルは独立した完全なサービスのインスタンスで、最大サイズは固定されています。負荷が増加すると、セルが追加されることでワークロードが増大します。着信トラフィックでパーティションキーを使用して、リクエストを処理するセルを決定します。障害は発生した単一のセルに限定され、他のセルがエラーなしで継続するため、障害のあるリクエストの数が制限されます。セル間の相互作用を最小限に抑え、各リクエストに複雑なマッピングサービスを含める必要がないように、適切なパーティションキーを特定することが重要です。複雑なマッピングをするサービスでは、単に問題がマッピングサービスに移行するだけであり、セルが相互作用するサービスでは、セルの独立性が低下します (これにより可用性の改善が想定されます)。