翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
REL10-BP02 マルチロケーションデプロイに適したロケーションを選択する
望ましい結果： 高可用性のために、常に (可能な場合) ワークロードコンポーネントを複数のアベイラビリティーゾーン () にデプロイしますAZs。回復力要件が極端に高いワークロードについては、マルチリージョンアーキテクチャのオプションを慎重に評価してください。
別の AWS リージョンへのバックアップを備えた回復力の高いマルチ AZ データベースデプロイ
一般的なアンチパターン:
-
マルチ AZ アーキテクチャで要件を満たせるときに、マルチリージョンアーキテクチャの設計を選択する。
-
回復力要件とマルチロケーション要件がアプリケーションコンポーネント間で異なる場合に、コンポーネント間の依存関係を考慮しない。
このベストプラクティスを活用するメリット: 回復力のためには、防御レイヤーを構築するアプローチを使用する必要があります。1 つのレイヤーは、複数の を使用して高可用性アーキテクチャを構築することで、より小さく、より一般的な中断から保護しますAZs。もう 1 つの防御層では、広範囲の自然災害やリージョンレベルの混乱など、まれな出来事に対して保護します。この 2 番目のレイヤーでは、複数の にまたがるようにアプリケーションを設計します AWS リージョン。
-
99.5% の可用性と 99.99% の可用性の違いは、1 か月あたり 3.5 時間に相当します。ワークロードの予想される可用性は、複数の にある場合にのみ「49」に達することができますAZs。
-
ワークロードを複数の で実行することでAZs、電力、冷却、ネットワーキングの障害や、火災や洪水などのほとんどの自然災害を分離できます。
-
ワークロードのためのマルチリージョン戦略の実装は、国の広い範囲に影響を与える自然災害や、リージョン全体に及ぶ技術的障害に対する保護に役立ちます。マルチリージョンアーキテクチャの実装はかなり複雑になることがあり、通常、ほとんどのワークロードには不要である点に注意してください。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
1 つのアベイラビリティーゾーンの中断または部分的な損失に基づく災害イベントの場合、可用性の高いワークロードを 1 つの 内の複数のアベイラビリティーゾーンに実装 AWS リージョン することで、自然災害や技術的災害を軽減できます。各 AWS リージョン は複数のアベイラビリティーゾーンで構成され、各ゾーンは他のゾーンの障害から隔離され、かなりの距離によって分離されます。ただし、相互にかなりの距離を隔てた複数のアベラビリティーゾーンコンポーネントの損失リスクがある災害については、リージョン規模の障害を緩和するディザスタリカバリオプションを実装する必要があります。極端に高い回復力を必要とするワークロードについては (重要なインフラストラクチャ、医療関連のアプリケーション、財務システムインフラストラクチャなど)、マルチリージョン戦略が必要なことがあります。
実装手順
-
ワークロードを評価し、マルチ AZ アプローチ (単一 AWS リージョン) でレジリエンスのニーズを満たせるかどうか、またはマルチリージョンアプローチが必要かどうかを判断します。これらの要件を満たすためにマルチリージョンアーキテクチャを実装すると、複雑性が増すため、ユースケースと要件を慎重に考慮してください。回復力の要件は、ほぼ常に、単一の AWS リージョンを使用して満たすことができます。複数のリージョンを使用する必要があるかどうかを判断するときには、次のような要件を考慮してください。
-
ディザスタリカバリ (DR): 1 つのアベイラビリティーゾーンの中断または部分的な損失に基づくディザスタイベントの場合、高可用性ワークロードを 1 つの 内で複数のアベイラビリティーゾーンに実装 AWS リージョン することで、自然災害や技術的災害を軽減できます。相互にかなりの距離を隔てた複数のアベイラビリティーゾーンコンポーネントの損失リスクがある災害については、リージョン規模の自然災害や技術的障害を緩和するために、複数のリージョンにまたがるディザスタリカバリを実装する必要があります。
-
高可用性 (HA): マルチリージョンアーキテクチャ (各リージョンAZsで複数の を使用) を使用して、4 つの 9 (> 99.99%) 以上の可用性を実現できます。
-
スタックローカリゼーション : ワークロードをグローバルオーディエンスにデプロイする場合、ローカライズされたスタックをさまざまな にデプロイ AWS リージョン して、それらのリージョンのオーディエンスにサービスを提供できます。ローカリゼーションには、言語、通貨、および保存されるデータのタイプが含まれます。
-
ユーザーへの近接性： ワークロードをグローバルオーディエンスにデプロイする場合、エンドユーザーがいる場所 AWS リージョン の近くにスタックをデプロイすることで、レイテンシーを短縮できます。
-
データレジデンシー: 一部のワークロードはデータレジデンシー要件の対象であり、特定のユーザーからのデータは特定の国境内にとどめる必要があります。問題の規制に基づいて、スタック全体、またはデータのみをそれらの境界 AWS リージョン 内の にデプロイすることを選択できます。
-
-
AWS のサービスによって提供されるマルチ AZ 機能の例をいくつか示します。
-
EC2 または を使用してワークロードを保護するにはECS、コンピューティングリソースの前に Elastic Load Balancer をデプロイします。次に Elastic Load Balancing は、異常なゾーンのインスタンスを検出し、トラフィックを正常なゾーンにルーティングするソリューションを提供します。
-
ロードバランシングをサポートしていない商用 off-the-shelfソフトウェアを実行しているEC2インスタンスの場合、マルチ AZ ディザスタリカバリ方法を実装することで耐障害性を実現できます。
-
Amazon ECSタスクでは、可用性とコストのバランスを実現するために、サービスを 3 つに均等AZsにデプロイします。
-
Aurora Amazon 以外の ではRDS、設定オプションとしてマルチ AZ を選択できます。プライマリデータベースインスタンスが失敗すると、Amazon はスタンバイデータベースRDSを自動的に昇格して、別のアベイラビリティーゾーンでトラフィックを受信します。マルチリージョンリードレプリカを作成して、回復力を高めることもできます。
-
-
AWS サービスが提供するマルチリージョン機能の例をいくつか示します。
-
マルチ AZ の可用性がサービスによって自動的に提供される Amazon S3 ワークロードの場合、マルチリージョンデプロイが必要な場合は、マルチリージョンアクセスポイントを検討してください。
-
マルチ AZ の可用性がサービスによって自動的に提供される DynamoDB テーブルの場合、既存のテーブルをグローバルテーブルに容易に変換して、複数リージョンの利点を活かすことができます。
-
ワークロードが Application Load Balancer または Network Load Balancer によってフロント処理されている場合は、 AWS Global Accelerator を使用して、正常なエンドポイントを含む複数のリージョンにトラフィックを誘導することで、アプリケーションの可用性を向上させます。
-
を活用するアプリケーションでは AWS EventBridge、クロスリージョンバスを検討して、選択した他のリージョンにイベントを転送します。
-
Amazon Aurora データベースの場合、複数の AWS リージョンにまたがる Aurora グローバルデータベースを検討してください。既存のクラスターを変更して、新しいリージョンも追加できます。
-
ワークロードに AWS Key Management Service （AWS KMS) 暗号化キーが含まれている場合は、マルチリージョンキーがアプリケーションに適しているかどうかを検討してください。
-
その他の AWS サービス機能については、AWS 「 サービスを使用したマルチリージョンアプリケーションの作成
」のブログシリーズを参照してください。
-
実装計画に必要な工数レベル: 中から高
リソース
関連ドキュメント:
関連動画:
関連する例:
