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

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 を使用して保護します。

リソース

関連ドキュメント: