# 障害部分を切り離してワークロードを保護する
障害分離は、コンポーネントまたはシステムの障害の影響を定義された境界に制限します。適切な分離により、境界の外部のコンポーネントは障害の影響を受けません。複数の障害分離境界にわたってワークロードを実行すると、障害に対する回復力が高まる可能性があります。
**Topics**
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 単一のロケーションに制約されるコンポーネントのリカバリを自動化する](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 バルクヘッドアーキテクチャを使用して影響範囲を制限する](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 複数の場所にワークロードをデプロイする
ワークロードのデータとリソースを複数のアベイラビリティーゾーンに分散するか、必要に応じて複数の AWS リージョンにまたがって分散します。
AWS のサービス設計の基本的な原則は、基盤となる物理インフラストラクチャを含む単一障害点を回避することです。AWS は、[リージョン](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html)と呼ばれる複数の地理的ロケーションで、クラウドコンピューティングリソースとサービスをグローバルに提供します。各リージョンは物理的および論理的に独立しており、3 つ以上の[アベイラビリティーゾーン (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) で構成されています。アベイラビリティーゾーンは地理的には互いに近接していますが、物理的には分離され、隔離されています。アベイラビリティーゾーンとリージョン間でワークロードを分散すると、火災、洪水、気象関連の災害、地震、人為的ミスなどの脅威のリスクが軽減されます。
ワークロードに適した高可用性を提供するロケーション戦略を作成します。
**期待される成果:** 本番稼働ワークロードは、耐障害性と高可用性を実現するために、複数のアベイラビリティーゾーン (AZ) またはリージョンに分散されます。
**一般的なアンチパターン:**
+ 本番稼働ワークロードを 1 つのアベイラビリティーゾーンにのみ存在させる。
+ マルチ AZ アーキテクチャでビジネス要件を満たせるときに、マルチリージョンアーキテクチャを実装する。
+ デプロイまたはデータが非同期化され、設定ドリフトやデータのレプリケート不足が発生する。
+ 回復力要件とマルチロケーション要件がアプリケーションコンポーネント間で異なる場合に、コンポーネント間の依存関係を考慮しない。
**このベストプラクティスを活用するメリット:**
+ ワークロードは、電力や環境制御の障害、自然災害、アップストリームサービスの障害、AZ またはリージョン全体に影響を及ぼすネットワークの問題などのインシデントに対して、より耐性を持つようになります。
+ Amazon EC2 インスタンスの広範なインベントリにアクセスし、特定の EC2 インスタンスタイプを起動するときに InsufficientCapacityExceptions (ICE) が発生する可能性を減らすことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
リージョンの少なくとも 2 つのアベイラビリティーゾーン (AZ) にすべての本番稼働ワークロードをデプロイして運用します。
**複数のアベイラビリティーゾーンを使用する**
アベイラビリティーゾーンは、火災、洪水、竜巻などのリスクによる相関障害を回避するために、物理的に互いに分離されたリソースホスティングの場所です。各アベイラビリティーゾーンには、ユーティリティ電源接続、バックアップ電源、機械サービス、ネットワーク接続などの独立した物理インフラストラクチャがあります。この配置により、これらのコンポーネントのいずれかの障害は、影響を受けるアベイラビリティーゾーンのみに制限されます。例えば、AZ 全体のインシデントにより、影響を受けるアベイラビリティーゾーンで EC2 インスタンスが使用できなくなった場合でも、他のアベイラビリティーゾーンのインスタンスは引き続き利用できます。
物理的に分離されているにもかかわらず、同じ AWS リージョン 内のアベイラビリティーゾーンは、高スループット、低レイテンシー (1 桁ミリ秒) のネットワークを提供できるほど近い位置にあります。ユーザーエクスペリエンスに大きな影響を与えることなく、ほとんどのワークロードのアベイラビリティーゾーン間でデータを同期的にレプリケートできます。つまり、アクティブ/アクティブまたはアクティブ/スタンバイの設定でリージョンのアベイラビリティーゾーンを使用できます。
ワークロードに関連するすべてのコンピューティングは、複数のアベイラビリティーゾーンに分散する必要があります。これには、[Amazon EC2](https://aws.amazon.com/ec2/) インスタンス、[AWS Fargate](https://aws.amazon.com/fargate/) タスク、VPC にアタッチされた [AWS Lambda](https://aws.amazon.com/lambda/) 関数が含まれます。[EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)、[Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) などの AWS コンピューティングサービスは、アベイラビリティーゾーン間でコンピューティングを起動および管理する方法を提供します。必要に応じて別のアベイラビリティーゾーンでコンピューティングを自動的に置き換えるように設定して、アベイラビリティーを維持します。利用可能なアベイラビリティーゾーンにトラフィックを転送するには、コンピューティングの前に、Application Load Balancer や Network Load Balancer などのロードバランサーを配置します。AWS Load Balancer は、アベイラビリティーゾーンに障害が発生した場合に、トラフィックを利用可能なインスタンスに再ルーティングできます。
また、ワークロードのデータをレプリケートし、複数のアベイラビリティーゾーンで使用できるようにする必要があります。[Amazon S3](https://aws.amazon.com/s3/)、[Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/)、[Amazon Aurora](https://aws.amazon.com/aurora/)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) などの一部の AWS マネージドデータサービスは、デフォルトで複数のアベイラビリティーゾーンにデータをレプリケートし、アベイラビリティーゾーンの障害に対して堅牢です。[Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) などの他の AWS マネージドデータサービスでは、マルチ AZ レプリケーションを有効にする必要があります。これらのサービスを有効にすると、アベイラビリティーゾーンの障害が自動的に検出され、利用可能なアベイラビリティーゾーンにリクエストがリダイレクトされ、復旧後に必要に応じて顧客の介入なしにデータの再レプリケートが行われます。使用する各 AWS マネージドデータサービスのユーザーガイドをよく読み、マルチ AZ 機能、動作、操作を理解してください。
[Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) ボリュームや Amazon EC2 インスタンスストレージなどのセルフマネージドストレージを使用している場合は、マルチ AZ レプリケーションを自分で管理する必要があります。
![\[3 つのアベイラビリティーゾーンにまたがってデプロイされる多階層アーキテクチャを示す図。Amazon S3 と Amazon DynamoDB は常に自動的にマルチ AZ です。ELB も 3 つのゾーンすべてにデプロイされます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/multi-tier-architecture.png)
**複数の AWS リージョン を使用する**
非常に高い耐障害性を必要とするワークロード (重要なインフラストラクチャ、医療関連のアプリケーション、厳格な顧客要件または義務付けられたアベイラビリティー要件を持つサービスなど) がある場合は、単一の AWS リージョン で提供できるものを超える追加の可用性が必要になることがあります。この場合、少なくとも 2 つの AWS リージョン にわたってワークロードをデプロイして運用する必要があります (データレジデンシー要件で許可されている場合)。
AWS リージョン は、世界中のさまざまな地理的地域と複数の大陸にあります。AWS リージョン は、アベイラビリティーゾーンのみよりもさらに物理的に分離および隔離されています。AWS サービスは、いくつかの例外を除き、この設計を利用して、異なるリージョン間で完全に独立して動作します (*リージョンサービス*とも呼ばれます)。AWS リージョンal サービスの障害は、別のリージョンのサービスに影響を与えないように設計されています。
複数のリージョンでワークロードを操作する場合は、追加の要件を考慮する必要があります。異なるリージョンのリソースは互いに独立しているため、各リージョンでワークロードのコンポーネントを複製する必要があります。これには、コンピューティングおよびデータサービスに加えて、VPC などの基盤インフラストラクチャが含まれます。
**注:** マルチリージョン設計を検討するときは、ワークロードが 1 つのリージョンで実行できることを確認します。あるリージョンのコンポーネントが別のリージョンのサービスまたはコンポーネントに依存するリージョン間に依存関係を作成すると、障害のリスクが高まり、信頼性体制が大幅に弱まる可能性があります。
マルチリージョンのデプロイを容易にし、一貫性を維持するために、[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) は AWS インフラストラクチャ全体を複数のリージョンにレプリケートできます。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) は、設定ドリフトを検出し、リージョン内の AWS リソースが同期していないときに通知することもできます。多くの AWS サービスは、重要なワークロードアセットに対してマルチリージョンレプリケーションを提供します。例えば、[EC2 Image Builder](https://aws.amazon.com/image-builder/) は、使用する各リージョンへのビルドのたびに EC2 マシンイメージ (AMI) を発行できます。[Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) は、コンテナイメージを選択したリージョンにレプリケートできます。
選択した各リージョンにもデータをレプリケートする必要があります。多くの AWS マネージドデータサービスは、Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache、Amazon EFS などのクロスリージョンレプリケーション機能を備えています。[Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/)は、サポートされている任意のリージョンでの書き込みを受け入れ、他のすべての設定済みリージョン間でデータをレプリケートします。他のサービスでは、他のリージョンに読み取り専用レプリカが含まれているため、書き込みのプライマリリージョンを指定する必要があります。ワークロードが使用する AWS マネージドデータサービスごとに、そのユーザーガイドとデベロッパーガイドを参照して、マルチリージョンの機能と制限を理解してください。書き込みの転送先、トランザクションの機能と制限、レプリケーションの実行方法、リージョン間の同期をモニタリングする方法に特に注意してください。
AWS には、リクエストトラフィックをリージョンデプロイに非常に柔軟にルーティングする機能もあります。例えば、[Amazon Route 53](https://aws.amazon.com/route53/) を使用して DNS レコードを設定し、ユーザーに最も近い利用可能なリージョンにトラフィックを誘導できます。または、DNS レコードをアクティブ/スタンバイ構成で構成し、1 つのリージョンをプライマリとして指定し、プライマリリージョンに異常が発生した場合にのみリージョンレプリカにフォールバックすることもできます。[Route 53 ヘルスチェック](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html)を設定し、異常なエンドポイントを検出し、自動フェイルオーバーを実行し、さらに [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) を使用して、必要に応じて手動でトラフィックを再ルーティングするための高可用性ルーティング制御を実現できます。
高可用性のために複数のリージョンで運用しないことを選択した場合でも、ディザスタリカバリ (DR) 戦略の一環として複数のリージョンを検討してください。可能であれば、ワークロードのインフラストラクチャコンポーネントとデータを、セカンダリリージョンの*ウォームスタンバイ*または*パイロットライト*構成でレプリケートします。この設計では、VPC、Auto Scaling グループ、コンテナオーケストレーター、その他のコンポーネントなどのプライマリリージョンからベースラインインフラストラクチャをレプリケートしますが、スタンバイリージョンの可変サイズのコンポーネント (EC2 インスタンスやデータベースレプリカの数など) を最小操作可能なサイズに設定します。また、プライマリリージョンからスタンバイリージョンへの継続的なデータレプリケーションも用意します。インシデントが発生した場合は、スタンバイリージョンのリソースをスケールアウトまたは拡張し、プライマリリージョンに昇格させることができます。
### 実装手順
1. ビジネス関係者やデータレジデンシーのエキスパートと協力して、リソースとデータをホストするためにどの AWS リージョン を使用できるかを決定します。
1. ビジネスおよび技術の関係者と協力してワークロードを評価し、その耐障害性ニーズがマルチ AZ アプローチ (単一の AWS リージョン) で満たされるかどうか、またはマルチリージョンアプローチ (複数のリージョンが許可されている場合) が必要かどうかを判断します。複数のリージョンを使用すると可用性が高まりますが、複雑さとコストが増加する可能性があります。評価する際には、次の要素を考慮してください。
1. **ビジネス目的と顧客要件:** アベイラビリティーゾーンまたはリージョンでワークロードに影響を与えるインシデントが発生すると、どのくらいのダウンタイムが許容されますか? 「[REL13-BP01 ダウンタイムやデータ損失に関する復旧目標を定義する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)」で説明されているように、復旧ポイントの目的を評価します。
1. **ディザスタリカバリ (DR) の要件**: どのような潜在的な災害に対して保険をかけたいですか? 単一のアベイラビリティーゾーンからリージョン全体まで、さまざまな影響範囲でデータ損失や長期的に利用不可になる可能性を考慮してください。アベイラビリティーゾーン間でデータとリソースをレプリケートし、1 つのアベイラビリティーゾーンで持続的な障害が発生した場合は、別のアベイラビリティーゾーンでサービスを復旧できます。リージョン間でデータとリソースをレプリケートする場合、別のリージョンでサービスを復旧できます。
1. コンピューティングリソースを複数のアベイラビリティーゾーンにデプロイします。
1. VPC で、異なるアベイラビリティーゾーンに複数のサブネットを作成します。インシデント発生時でもワークロードを処理するために必要なリソースを収容できる大きさになるようにそれぞれを構成します。詳細については、「[REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)」を参照してください。
1. Amazon EC2 インスタンスを使用している場合は、[EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) を使用してインスタンスを管理します。Auto Scaling グループの作成時に前のステップで選択したサブネットを指定します。
1. [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) または [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)の AWS Fargate コンピューティングを使用している場合は、ECS Service の作成、ECS タスクの起動、または EKS の [Fargate プロファイル](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html)の作成の最初のステップで選択したサブネットを選択します。
1. VPC で実行する必要がある AWS Lambda 関数を使用している場合は、Lambda 関数の作成時に最初のステップで選択したサブネットを選択します。VPC 構成を持たない機能については、AWS Lambda が自動的に可用性を管理します。
1. ロードバランサーなどのトラフィックディレクターをコンピューティングリソースの前に配置します。クロスゾーン負荷分散が有効になっている場合、[AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) と [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) は、アベイラビリティーゾーンの障害が原因で EC2 インスタンスやコンテナなどのターゲットに到達できない場合にそれを検出し、正常なアベイラビリティーゾーンのターゲットにトラフィックを再ルーティングします。クロスゾーン負荷分散を無効にする場合は、Amazon Application Recovery Controller (ARC) を使用してゾーンシフト機能を提供します。サードパーティーのロードバランサーを使用している場合、または独自のロードバランサーを実装している場合は、異なるアベイラビリティーゾーンにまたがる複数のフロントエンドでロードバランサーを設定します。
1. ワークロードのデータを複数のアベイラビリティーゾーンにレプリケートします。
1. Amazon RDS、Amazon ElastiCache、Amazon FSx などの AWS マネージドデータサービスを使用する場合は、そのユーザーガイドを読んで、データのレプリケーションと耐障害性の機能を理解します。必要に応じてクロス AZ レプリケーションとフェイルオーバーを有効にします。
1. Amazon S3、Amazon EFS、Amazon FSx などの AWS マネージドストレージサービスを使用する場合は、高い耐久性が求められるデータに対してシングル AZ または 1 つのゾーン構成を使用しないでください。これらのサービスにはマルチ AZ 設定を使用します。各サービスのユーザーガイドを確認して、マルチ AZ レプリケーションがデフォルトで有効になっているか、有効にする必要があるかを判断します。
1. セルフマネージド型データベース、キュー、またはその他のストレージサービスを実行する場合は、アプリケーションの手順またはベストプラクティスに従って、マルチ AZ レプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。
1. AZ の障害を検出し、正常なアベイラビリティーゾーンにトラフィックを再ルーティングするように DNS サービスを設定します。Amazon Route 53 を Elastic ロードバランサーと組み合わせて使用すると、自動的にこれを実行できます。Route 53 は、ヘルスチェックを使用して正常な IP アドレスのみを持つクエリに応答するフェイルオーバーレコードで設定することもできます。フェイルオーバーに使用される DNS レコードでは、レコードキャッシュが復旧を妨げるのを防ぐために、短い有効期間 (TTL) 値 (60 秒以下など) を指定します (Route 53 エイリアスレコードは適切な TTL を提供します)。
**複数の AWS リージョン を使用する場合の追加ステップ**
1. 選択したリージョン全体で、ワークロードで使用されるすべてのオペレーティングシステム (OS) とアプリケーションコードをレプリケートします。必要に応じて、Amazon EC2 Image Builder などのソリューションを使用して Amazon EC2 マシンイメージ (AMI) をレプリケートします。Amazon ECR クロスリージョンレプリケーションなどのソリューションを使用して、レジストリに保存されているコンテナイメージをレプリケートします。アプリケーションリソースの保存に使用される Amazon S3 バケットのリージョンレプリケーションを有効にします。
1. コンピューティングリソースと設定メタデータ (AWS Systems Manager Parameter Store に保存されているパラメータなど) を複数のリージョンにデプロイします。前のステップで説明したのと同じ手順を使用しますが、ワークロードに使用するリージョンごとに設定をレプリケートします。AWS CloudFormation などの Infrastructure as code (IaC) ソリューションを使用して、リージョン間で設定を均一に再現します。ディザスタリカバリにパイロットライト設定でセカンダリリージョンを使用している場合は、コンピューティングリソースの数を最小値に減らしてコストを削減し、それに応じて復旧までの時間を長くすることができます。
1. プライマリリージョンからセカンダリリージョンにデータをレプリケートします。
1. Amazon DynamoDB グローバルテーブルは、サポートされている任意のリージョンから書き込むことができるデータのグローバルレプリカを提供します。Amazon RDS、Amazon Aurora、Amazon Elasticache などの他の AWS マネージドデータサービスでは、プライマリ (読み取り/書き込み) リージョンとレプリカ (読み取り専用) リージョンを指定します。リージョンレプリケーションの詳細については、各サービスのユーザーガイドとデベロッパーガイドを参照してください。
1. セルフマネージドデータベースを実行している場合は、アプリケーションの手順またはベストプラクティスに従って、マルチリージョンレプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。
1. ワークロードで AWS EventBridge を使用している場合は、選択したイベントをプライマリリージョンからセカンダリリージョンに転送する必要がある場合があります。そのためには、セカンダリリージョンのイベントバスをプライマリリージョンの一致イベントのターゲットとして指定します。
1. リージョン間で同じ暗号化キーを使用するかどうか、またどの程度使用するかを検討します。セキュリティと使いやすさのバランスをとる一般的なアプローチは、リージョンローカルデータと認証にリージョンスコープキーを使用し、グローバルスコープキーを使用して、異なるリージョン間でレプリケートされるデータの暗号化を行うことです。[AWS Key Management Service(KMS)](https://aws.amazon.com/kms/) は、リージョン間で共有されるキーを安全に分散および保護するための[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)をサポートしています。
1. AWS Global Accelerator を検討して、正常なエンドポイントを含むリージョンにトラフィックを誘導することによって、アプリケーションの可用性を向上させます。
## リソース
**関連するベストプラクティス:**
+ [REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 静的安定性を使用してバイモーダル動作を防止する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 ダウンタイムやデータ損失に関する復旧目標を定義する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**関連ドキュメント:**
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure)
+ [ホワイトペーパー: AWS 障害分離境界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Amazon EC2 Auto Scaling のレジリエンス](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling: 例: アベイラビリティーゾーン間でインスタンスを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [EC2 Image Builder の仕組み](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Amazon ECS がタスクをコンテナインスタンスに配置する方法 (Fargate を含む)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [AWS Lambda での回復力](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3: オブジェクトレプリケーションの概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon ECR でのプライベートイメージレプリケーション](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [グローバルテーブル: DynamoDB を使用した複数リージョンレプリケーション](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Elasticache for Redis OSS: グローバルデータストアを使用した AWS リージョン 間のレプリケーション](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Amazon RDS の耐障害性](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Amazon Aurora Global Database の使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [AWS Global Accelerator デベロッパーガイド](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [AWS KMS のマルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53: DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Amazon Application Recovery Controller (ARC) デベロッパーガイド](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS リージョン間での Amazon EventBridge イベントの送受信](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
+ [AWS のサービスによるマルチリージョンアプリケーションの作成 (ブログシリーズ)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)
**関連動画:**
+ [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: AWS グローバルネットワークインフラストラクチャの革新性とオペレーション](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 単一のロケーションに制約されるコンポーネントのリカバリを自動化する
ワークロードのコンポーネントを実行できるのが単一のアベイラビリティーゾーンまたはオンプレミスのデータセンターでのみである場合は、定義した復旧目標内でワークロードを全面的に再構築する機能を実装する必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
技術的な制約のためにワークロードを複数のロケーションにデプロイするベストプラクティスが不可能な場合は、回復性を確保するための代替パスを採り入れる必要があります。このような場合、必要なインフラストラクチャを再作成し、アプリケーションを再デプロイし、必要なデータを再作成する機能を自動化する必要があります。
例えば、Amazon EMR は同じアベイラビリティーゾーンで特定のクラスターのすべてのノードを起動します。これは、同じゾーンでクラスターを実行すると、データアクセス率が高くなり、ジョブフローのパフォーマンスが向上するためです。このコンポーネントがワークロードの回復力のために必要な場合は、クラスターとそのデータを再デプロイする方法が必要です。また、Amazon EMR では、マルチ AZ を使用する以外の方法で冗長性をプロビジョニングする必要があります。[複数のノード](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html)をプロビジョニングすることが可能です。[EMR File System (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html) を使用することで EMR のデータを Amazon S3 に保存することができ、そのデータを、今度は複数のアベイラビリティーゾーンまたは AWS リージョンを横断してレプリケートすることができます。
同様に、Amazon Redshift でも、選択した AWS リージョン内の、ランダムに選択されたアベイラビリティーゾーンにクラスターがデフォルトでプロビジョニングされます。すべてのクラスターノードが同じゾーンにプロビジョニングされます。
オンプレミスのデータセンターにデプロイされたサーバーベースのステートフルなワークロードの場合、AWS Elastic Disaster Recovery を使用して AWS のワークロードを保護できます 既に AWS でホストされてる場合は、Elastic Disaster Recovery を使用することでワークロードを別のアベイラビリティーゾーンまたはリージョンに保護することができます。Elastic Disaster Recovery は、軽量のステージングエリアへの、ブロックレベルの継続的なレプリケーションを行い、オンプレミスおよびクラウドベースのアプリケーションの高速かつ信頼性の高い復旧を実現します。
**実装手順**
1. 自己修復を実装します。可能であれば自動スケーリングを利用して、インスタンスとコンテナをデプロイします。自動スケーリングを利用できない場合は、EC2 インスタンスの自動復旧機能を利用するか、Amazon EC2 または ECS のコンテナのライフサイクルイベントを利用して自己修復自動化を実装します。
+ 単一インスタンス IP アドレスや、プライベート IP アドレス、Elastic IP アドレス、インスタンスメタデータを必要としないインスタンスとコンテナのワークロードには、[Amazon EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)を使用します。
+ 起動テンプレートのユーザーデータを使用して、ほとんどのワークロードを自己修復できるオートメーションを実装できます。
+ 単一インスタンス IP アドレスや、プライベート IP アドレス、Elastic IP アドレス、インスタンスメタデータを必要とするワークロードには、[Amazon EC2 インスタンスの自動復旧機能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)を使用します。
+ 自動復旧は、インスタンスの障害が検出されると、復旧ステータスアラートを SNS トピックに送信します。
+ オートスケーリングや EC2 の復旧機能を利用できない場合は、[Amazon EC2 インスタンスのライフサイクルイベント](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)や [Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)を利用して自己修復を自動化します。
+ 必要なプロセスロジックに従ってコンポーネントを修復するオートメーションを呼び出すには、イベントを利用します。
+ 単一のロケーションに制限されているステートフルワークロードは [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) を使用して保護します。
## リソース
**関連ドキュメント:**
+ [Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Amazon EC2 Auto Scaling のライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [インスタンスの耐障害性](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon ECS サービスを自動的にスケールする](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Amazon EC2 Auto Scaling とは](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 バルクヘッドアーキテクチャを使用して影響範囲を制限する
バルクヘッドアーキテクチャ (セルベースアーキテクチャとも呼ばれる) を実装して、ワークロード内の障害の影響を限られた数のコンポーネントに制限します。
**期待される成果:** セルベースアーキテクチャでは、複数の分離されたワークロードのインスタンスを使用します。各インスタンスはセルと呼ばれます。各セルは独立しており、その他のセルとは状態を共有せず、ワークロードのリクエスト全体のサブセットを処理します。これにより、不適切なソフトウェア更新などの障害による個別のセルおよび処理中のリクエストへの予測される影響が軽減されます。例えばワークロードが 10 個のセルを使用して 100 個のリクエストを処理していると、障害が発生した場合、リクエスト全体の 90% は障害の影響を受けません。
**一般的なアンチパターン:**
+ セルを際限なく増殖させる。
+ コードの更新やデプロイをすべてのセルに同時に適用する。
+ セル間で状態またはコンポーネントを共有する (ルーターレイヤーを除く)。
+ 複雑なビジネスロジックやルーティングロジックをルーターレイヤーに追加する。
+ セル間のインタラクションを最小に抑えない。
**このベストプラクティスを活用するメリット:** セルベースアーキテクチャでは、多くの一般的な障害はセル自体に封じ込められるため、障害の分離を強化できます。このように障害を分離することで、コードのデプロイに失敗したり、リクエストが破損したり特定の障害モードを呼び出したり (ポイズンピルリクエスト) するなど、他の方法では封じ込めが難しい障害が起きても回復が可能になります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
船ではバルクヘッドが使用されており、船体が破損しても、船体の一部のセクションのみに封じ込めることができます。複雑なシステムでは、このパターンを模して障害分離を実現する場合がよくあります。障害部分を分離した境界は、ワークロード内の障害の影響を限られた数のコンポーネントに限定します。境界の外部のコンポーネントは、障害の影響を受けません。障害を分離した複数の境界を使用して、ワークロードへの影響を制限することができます。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/)」を参照してください。
## リソース
**関連するベストプラクティス:**
+ [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)