REL10-BP01 複数の場所にワークロードをデプロイする
ワークロードのデータとリソースを複数のアベイラビリティーゾーンに分散するか、必要に応じて複数の AWS リージョンにまたがって分散します。
AWS のサービス設計の基本的な原則は、基盤となる物理インフラストラクチャを含む単一障害点を回避することです。AWS は、リージョンと呼ばれる複数の地理的ロケーションで、クラウドコンピューティングリソースとサービスをグローバルに提供します。各リージョンは物理的および論理的に独立しており、3 つ以上のアベイラビリティーゾーン (AZ) で構成されています。アベイラビリティーゾーンは地理的には互いに近接していますが、物理的には分離され、隔離されています。アベイラビリティーゾーンとリージョン間でワークロードを分散すると、火災、洪水、気象関連の災害、地震、人為的ミスなどの脅威のリスクが軽減されます。
ワークロードに適した高可用性を提供するロケーション戦略を作成します。
期待される成果: 本番稼働ワークロードは、耐障害性と高可用性を実現するために、複数のアベイラビリティーゾーン (AZ) またはリージョンに分散されます。
一般的なアンチパターン:
-
本番稼働ワークロードを 1 つのアベイラビリティーゾーンにのみ存在させる。
-
マルチ AZ アーキテクチャでビジネス要件を満たせるときに、マルチリージョンアーキテクチャを実装する。
-
デプロイまたはデータが非同期化され、設定ドリフトやデータのレプリケート不足が発生する。
-
回復力要件とマルチロケーション要件がアプリケーションコンポーネント間で異なる場合に、コンポーネント間の依存関係を考慮しない。
このベストプラクティスを活用するメリット:
-
ワークロードは、電力や環境制御の障害、自然災害、アップストリームサービスの障害、AZ またはリージョン全体に影響を及ぼすネットワークの問題などのインシデントに対して、より耐性を持つようになります。
-
Amazon EC2 インスタンスの広範なインベントリにアクセスし、特定の EC2 インスタンスタイプを起動するときに InsufficientCapacityExceptions (ICE) が発生する可能性を減らすことができます。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
リージョンの少なくとも 2 つのアベイラビリティーゾーン (AZ) にすべての本番稼働ワークロードをデプロイして運用します。
複数のアベイラビリティーゾーンを使用する
アベイラビリティーゾーンは、火災、洪水、竜巻などのリスクによる相関障害を回避するために、物理的に互いに分離されたリソースホスティングの場所です。各アベイラビリティーゾーンには、ユーティリティ電源接続、バックアップ電源、機械サービス、ネットワーク接続などの独立した物理インフラストラクチャがあります。この配置により、これらのコンポーネントのいずれかの障害は、影響を受けるアベイラビリティーゾーンのみに制限されます。例えば、AZ 全体のインシデントにより、影響を受けるアベイラビリティーゾーンで EC2 インスタンスが使用できなくなった場合でも、他のアベイラビリティーゾーンのインスタンスは引き続き利用できます。
物理的に分離されているにもかかわらず、同じ AWS リージョン 内のアベイラビリティーゾーンは、高スループット、低レイテンシー (1 桁ミリ秒) のネットワークを提供できるほど近い位置にあります。ユーザーエクスペリエンスに大きな影響を与えることなく、ほとんどのワークロードのアベイラビリティーゾーン間でデータを同期的にレプリケートできます。つまり、アクティブ/アクティブまたはアクティブ/スタンバイの設定でリージョンのアベイラビリティーゾーンを使用できます。
ワークロードに関連するすべてのコンピューティングは、複数のアベイラビリティーゾーンに分散する必要があります。これには、Amazon EC2
また、ワークロードのデータをレプリケートし、複数のアベイラビリティーゾーンで使用できるようにする必要があります。Amazon S3
Amazon Elastic Block Store (EBS)
図 9: 3 つのアベイラビリティーゾーンにまたがってデプロイされる多階層アーキテクチャ。Amazon S3 と Amazon DynamoDB は常に自動的にマルチ AZ です。ELB も 3 つのゾーンすべてにデプロイされます。
複数の AWS リージョン を使用する
非常に高い耐障害性を必要とするワークロード (重要なインフラストラクチャ、医療関連のアプリケーション、厳格な顧客要件または義務付けられたアベイラビリティー要件を持つサービスなど) がある場合は、単一の AWS リージョン で提供できるものを超える追加の可用性が必要になることがあります。この場合、少なくとも 2 つの AWS リージョン にわたってワークロードをデプロイして運用する必要があります (データレジデンシー要件で許可されている場合)。
AWS リージョン は、世界中のさまざまな地理的地域と複数の大陸にあります。AWS リージョン は、アベイラビリティーゾーンのみよりもさらに物理的に分離および隔離されています。AWS サービスは、いくつかの例外を除き、この設計を利用して、異なるリージョン間で完全に独立して動作します (リージョンサービスとも呼ばれます)。AWS リージョンal サービスの障害は、別のリージョンのサービスに影響を与えないように設計されています。
複数のリージョンでワークロードを操作する場合は、追加の要件を考慮する必要があります。異なるリージョンのリソースは互いに独立しているため、各リージョンでワークロードのコンポーネントを複製する必要があります。これには、コンピューティングおよびデータサービスに加えて、VPC などの基盤インフラストラクチャが含まれます。
注: マルチリージョン設計を検討するときは、ワークロードが 1 つのリージョンで実行できることを確認します。あるリージョンのコンポーネントが別のリージョンのサービスまたはコンポーネントに依存するリージョン間に依存関係を作成すると、障害のリスクが高まり、信頼性体制が大幅に弱まる可能性があります。
マルチリージョンのデプロイを容易にし、一貫性を維持するために、AWS CloudFormation StackSets は AWS インフラストラクチャ全体を複数のリージョンにレプリケートできます。AWS CloudFormation
選択した各リージョンにもデータをレプリケートする必要があります。多くの AWS マネージドデータサービスは、Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache、Amazon EFS などのクロスリージョンレプリケーション機能を備えています。Amazon DynamoDB グローバルテーブル
AWS には、リクエストトラフィックをリージョンデプロイに非常に柔軟にルーティングする機能もあります。例えば、Amazon Route 53
高可用性のために複数のリージョンで運用しないことを選択した場合でも、ディザスタリカバリ (DR) 戦略の一環として複数のリージョンを検討してください。可能であれば、ワークロードのインフラストラクチャコンポーネントとデータを、セカンダリリージョンのウォームスタンバイまたはパイロットライト構成でレプリケートします。この設計では、VPC、Auto Scaling グループ、コンテナオーケストレーター、その他のコンポーネントなどのプライマリリージョンからベースラインインフラストラクチャをレプリケートしますが、スタンバイリージョンの可変サイズのコンポーネント (EC2 インスタンスやデータベースレプリカの数など) を最小操作可能なサイズに設定します。また、プライマリリージョンからスタンバイリージョンへの継続的なデータレプリケーションも用意します。インシデントが発生した場合は、スタンバイリージョンのリソースをスケールアウトまたは拡張し、プライマリリージョンに昇格させることができます。
実装手順
-
ビジネス関係者やデータレジデンシーのエキスパートと協力して、リソースとデータをホストするためにどの AWS リージョン を使用できるかを決定します。
-
ビジネスおよび技術の関係者と協力してワークロードを評価し、その耐障害性ニーズがマルチ AZ アプローチ (単一の AWS リージョン) で満たされるかどうか、またはマルチリージョンアプローチ (複数のリージョンが許可されている場合) が必要かどうかを判断します。複数のリージョンを使用すると可用性が高まりますが、複雑さとコストが増加する可能性があります。評価する際には、次の要素を考慮してください。
-
ビジネス目的と顧客要件: アベイラビリティーゾーンまたはリージョンでワークロードに影響を与えるインシデントが発生すると、どのくらいのダウンタイムが許容されますか? 「REL13-BP01 ダウンタイムやデータ損失に関する復旧目標を定義する」で説明されているように、復旧ポイントの目的を評価します。
-
ディザスタリカバリ (DR) の要件: どのような潜在的な災害に対して保険をかけたいですか? 単一のアベイラビリティーゾーンからリージョン全体まで、さまざまな影響範囲でデータ損失や長期的に利用不可になる可能性を考慮してください。アベイラビリティーゾーン間でデータとリソースをレプリケートし、1 つのアベイラビリティーゾーンで持続的な障害が発生した場合は、別のアベイラビリティーゾーンでサービスを復旧できます。リージョン間でデータとリソースをレプリケートする場合、別のリージョンでサービスを復旧できます。
-
-
コンピューティングリソースを複数のアベイラビリティーゾーンにデプロイします。
-
VPC で、異なるアベイラビリティーゾーンに複数のサブネットを作成します。インシデント発生時でもワークロードを処理するために必要なリソースを収容できる大きさになるようにそれぞれを構成します。詳細については、「REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う」を参照してください。
-
Amazon EC2 インスタンスを使用している場合は、EC2 Auto Scaling
を使用してインスタンスを管理します。Auto Scaling グループの作成時に前のステップで選択したサブネットを指定します。 -
Amazon ECS または Amazon EKSの AWS Fargate コンピューティングを使用している場合は、ECS Service の作成、ECS タスクの起動、または EKS の Fargate プロファイルの作成の最初のステップで選択したサブネットを選択します。
-
VPC で実行する必要がある AWS Lambda 関数を使用している場合は、Lambda 関数の作成時に最初のステップで選択したサブネットを選択します。VPC 構成を持たない機能については、AWS Lambda が自動的に可用性を管理します。
-
ロードバランサーなどのトラフィックディレクターをコンピューティングリソースの前に配置します。クロスゾーン負荷分散が有効になっている場合、AWS Application Load Balancer と Network Load Balancer は、アベイラビリティーゾーンの障害が原因で EC2 インスタンスやコンテナなどのターゲットに到達できない場合にそれを検出し、正常なアベイラビリティーゾーンのターゲットにトラフィックを再ルーティングします。クロスゾーン負荷分散を無効にする場合は、Amazon Application Recovery Controller (ARC) を使用してゾーンシフト機能を提供します。サードパーティーのロードバランサーを使用している場合、または独自のロードバランサーを実装している場合は、異なるアベイラビリティーゾーンにまたがる複数のフロントエンドでロードバランサーを設定します。
-
-
ワークロードのデータを複数のアベイラビリティーゾーンにレプリケートします。
-
Amazon RDS、Amazon ElastiCache、Amazon FSx などの AWS マネージドデータサービスを使用する場合は、そのユーザーガイドを読んで、データのレプリケーションと耐障害性の機能を理解します。必要に応じてクロス AZ レプリケーションとフェイルオーバーを有効にします。
-
Amazon S3、Amazon EFS、Amazon FSx などの AWS マネージドストレージサービスを使用する場合は、高い耐久性が求められるデータに対してシングル AZ または 1 つのゾーン構成を使用しないでください。これらのサービスにはマルチ AZ 設定を使用します。各サービスのユーザーガイドを確認して、マルチ AZ レプリケーションがデフォルトで有効になっているか、有効にする必要があるかを判断します。
-
セルフマネージド型データベース、キュー、またはその他のストレージサービスを実行する場合は、アプリケーションの手順またはベストプラクティスに従って、マルチ AZ レプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。
-
-
AZ の障害を検出し、正常なアベイラビリティーゾーンにトラフィックを再ルーティングするように DNS サービスを設定します。Amazon Route 53 を Elastic ロードバランサーと組み合わせて使用すると、自動的にこれを実行できます。Route 53 は、ヘルスチェックを使用して正常な IP アドレスのみを持つクエリに応答するフェイルオーバーレコードで設定することもできます。フェイルオーバーに使用される DNS レコードでは、レコードキャッシュが復旧を妨げるのを防ぐために、短い有効期間 (TTL) 値 (60 秒以下など) を指定します (Route 53 エイリアスレコードは適切な TTL を提供します)。
複数の AWS リージョン を使用する場合の追加ステップ
-
選択したリージョン全体で、ワークロードで使用されるすべてのオペレーティングシステム (OS) とアプリケーションコードをレプリケートします。必要に応じて、Amazon EC2 Image Builder などのソリューションを使用して Amazon EC2 マシンイメージ (AMI) をレプリケートします。Amazon ECR クロスリージョンレプリケーションなどのソリューションを使用して、レジストリに保存されているコンテナイメージをレプリケートします。アプリケーションリソースの保存に使用される Amazon S3 バケットのリージョンレプリケーションを有効にします。
-
コンピューティングリソースと設定メタデータ (AWS Systems Manager Parameter Store に保存されているパラメータなど) を複数のリージョンにデプロイします。前のステップで説明したのと同じ手順を使用しますが、ワークロードに使用するリージョンごとに設定をレプリケートします。AWS CloudFormation などの Infrastructure as code (IaC) ソリューションを使用して、リージョン間で設定を均一に再現します。ディザスタリカバリにパイロットライト設定でセカンダリリージョンを使用している場合は、コンピューティングリソースの数を最小値に減らしてコストを削減し、それに応じて復旧までの時間を長くすることができます。
-
プライマリリージョンからセカンダリリージョンにデータをレプリケートします。
-
Amazon DynamoDB グローバルテーブルは、サポートされている任意のリージョンから書き込むことができるデータのグローバルレプリカを提供します。Amazon RDS、Amazon Aurora、Amazon Elasticache などの他の AWS マネージドデータサービスでは、プライマリ (読み取り/書き込み) リージョンとレプリカ (読み取り専用) リージョンを指定します。リージョンレプリケーションの詳細については、各サービスのユーザーガイドとデベロッパーガイドを参照してください。
-
セルフマネージドデータベースを実行している場合は、アプリケーションの手順またはベストプラクティスに従って、マルチリージョンレプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。
-
ワークロードで AWS EventBridge を使用している場合は、選択したイベントをプライマリリージョンからセカンダリリージョンに転送する必要がある場合があります。そのためには、セカンダリリージョンのイベントバスをプライマリリージョンの一致イベントのターゲットとして指定します。
-
-
リージョン間で同じ暗号化キーを使用するかどうか、またどの程度使用するかを検討します。セキュリティと使いやすさのバランスをとる一般的なアプローチは、リージョンローカルデータと認証にリージョンスコープキーを使用し、グローバルスコープキーを使用して、異なるリージョン間でレプリケートされるデータの暗号化を行うことです。AWS Key Management Service(KMS)
は、リージョン間で共有されるキーを安全に分散および保護するためのマルチリージョンキーをサポートしています。 -
AWS Global Accelerator を検討して、正常なエンドポイントを含むリージョンにトラフィックを誘導することによって、アプリケーションの可用性を向上させます。
リソース
関連するベストプラクティス:
関連ドキュメント:
関連動画:
