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

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

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

このベストプラクティスを確立しない場合のリスクレベル: 中

実装のガイダンス

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

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

      • 起動テンプレートのユーザーデータを使用して、ほとんどのワークロードを自己修復できるオートメーションを実装できます。

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

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

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

      • 必要なプロセスロジックに従ってコンポーネントを修復するオートメーションを呼び出すには、イベントを利用します。

    • 単一のロケーションに制限したステートフルワークロードは、AWS Elastic Disaster Recovery を使用して保護します。

リソース

関連するドキュメント: