REL10-BP03 単一のロケーションに制約されるコンポーネントのリカバリを自動化する - AWS Well-Architected Framework
実装のガイダンスリソース

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

ワークロードのコンポーネントが 1 つのアベイラビリティゾーンまたはオンプレミスのデータセンターでのみ実行できる場合は、定義された復旧目標内でワークロードを全面的に再構築する機能を実装する必要があります。

技術的な制約のためにワークロードを複数のロケーションにデプロイするベストプラクティスが不可能な場合は、弾力性を確保するための代替パスを採り入れる必要があります。このような場合、必要なインフラストラクチャを再作成し、アプリケーションを再デプロイし、必要なデータを再作成する機能を自動化する必要があります。

例えば、Amazon EMR は同じアベイラビリティーゾーンで特定のクラスターのすべてのノードを起動します。これは、同じゾーンでクラスターを実行すると、データアクセス率が高くなり、ジョブフローのパフォーマンスが向上するためです。このコンポーネントがワークロードの回復力のために必要な場合は、クラスターとそのデータを再デプロイする方法が必要です。また、Amazon EMR では、マルチ AZ を使用する以外の方法で冗長性をプロビジョニングする必要があります。複数のマスターノードを プロビジョニングできます.EMR ファイルシステム (EMRFS) を使用すると、EMR のデータを Amazon S3 に保存でき、次にそのデータを複数のアベイラビリティゾーンまたは AWS リージョン にわたってレプリケートできます。

Amazon Redshift も同様に、デフォルトでは、選択した AWS リージョン 内のランダムに選択されたアベイラビリティゾーンにクラスターをプロビジョニングします。すべてのクラスターノードが同じゾーンにプロビジョニングされます。

このベストプラクティスを活用しない場合のリスクレベル: ミディアム

実装のガイダンス

  • 自己修復を実装します。可能であれば自動スケーリングを利用して、インスタンスとコンテナをデプロイします。自動スケーリングを利用できない場合は、EC2 インスタンスの自動復旧機能を利用するか、Amazon EC2 または ECS のコンテナのライフサイクルイベントに基づいた自己修復自動化を実装します。

    • 単一インスタンス IP アドレスや、プライベート IP アドレス、Elastic IP アドレス、インスタンスメタデータを必要としないインスタンスとコンテナのワークロードには、Auto Scaling グループを使用します。

    • 単一インスタンス IP アドレスや、プライベート IP アドレス、elastic IP アドレス、インスタンスメタデータを必要とするワークロードには、EC2 インスタンスの自動復旧機能を使用します。

      • インスタンスの復旧

        • 自動復旧は、インスタンスの障害が検出されると、復旧ステータスアラートを SNS トピックに送信します。

    • オートスケーリングや EC2 の復旧機能を利用できない場合は、EC2 インスタンスのライフサイクルイベントや ECS イベントを利用して、自己修復を自動化します。

リソース

関連するドキュメント: