翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
REL10-BP03 単一の場所に制約されたコンポーネントのリカバリを自動化する
ワークロードのコンポーネントを実行できるのが単一のアベイラビリティーゾーンまたはオンプレミスのデータセンターでのみである場合は、定義した復旧目標内でワークロードを全面的に再構築する機能を実装する必要があります。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
技術的な制約のためにワークロードを複数のロケーションにデプロイするベストプラクティスが不可能な場合は、回復性を確保するための代替パスを採り入れる必要があります。このような場合、必要なインフラストラクチャを再作成し、アプリケーションを再デプロイし、必要なデータを再作成する機能を自動化する必要があります。
例えば、Amazon は、同じアベイラビリティーゾーン内の特定のクラスターのすべてのノードEMRを起動します。これは、同じゾーンでクラスターを実行すると、データアクセスレートが高くなるため、ジョブフローのパフォーマンスが向上するためです。このコンポーネントがワークロードの回復力のために必要な場合は、クラスターとそのデータを再デプロイする方法が必要です。また、Amazon ではEMR、マルチ AZ を使用する以外の方法で冗長性をプロビジョニングする必要があります。複数のノードをプロビジョニングすることが可能です。EMR ファイルシステム (EMRFS) を使用すると、 のデータを Amazon S3 EMRに保存し、複数のアベイラビリティーゾーンまたは にレプリケートできます AWS リージョン。
同様に、Amazon Redshift の場合、デフォルトでは、選択した 内のランダムに選択されたアベイラビリティーゾーンにクラスターをプロビジョニング AWS リージョン します。すべてのクラスターノードが同じゾーンにプロビジョニングされます。
オンプレミスデータセンターにデプロイされたステートフルサーバーベースのワークロードの場合、 AWS Elastic Disaster Recovery を使用して のワークロードを保護できます AWS。ですでにホストされている場合は AWS、Elastic Disaster Recovery を使用して、ワークロードを代替のアベイラビリティーゾーンまたはリージョンから保護できます。Elastic Disaster Recovery は、軽量のステージングエリアへの、ブロックレベルの継続的なレプリケーションを行い、オンプレミスおよびクラウドベースのアプリケーションの高速かつ信頼性の高い復旧を実現します。
実装手順
-
自己修復を実装します。可能であれば自動スケーリングを利用して、インスタンスとコンテナをデプロイします。自動スケーリングを使用できない場合は、EC2インスタンスの自動復旧を使用するか、Amazon EC2またはECSコンテナのライフサイクルイベントに基づいて自己修復オートメーションを実装します。
-
Amazon EC2 Auto Scaling グループは、単一のインスタンス IP アドレス、プライベート IP アドレス、Elastic IP アドレス、インスタンスメタデータを必要としないインスタンスとコンテナワークロードに使用します。
-
起動テンプレートのユーザーデータを使用して、ほとんどのワークロードを自己修復できるオートメーションを実装できます。
-
-
単一のEC2インスタンス ID アドレス、プライベート IP アドレス、エラスティック IP アドレス、インスタンスメタデータを必要とするワークロードには、Amazon インスタンスの自動復旧を使用します。
-
自動復旧は、インスタンスの障害が検出されると、SNSトピックに復旧ステータスアラートを送信します。
-
-
Amazon EC2インスタンスのライフサイクルイベントまたは Amazon ECSイベントを使用して、自動スケーリングまたはEC2リカバリを使用できない自己修復を自動化します。
-
必要なプロセスロジックに従ってコンポーネントを修復するオートメーションを呼び出すには、イベントを利用します。
-
-
単一のロケーションに制限されているステートフルワークロードは AWS Elastic Disaster Recovery を使用して保護します。
-
リソース
関連ドキュメント: