翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# によるディザスタリカバリ AWS
バックアップと復元のアプローチとそれをサポートするサービスとテクノロジーを使用して、ディザスタリカバリ (DR) ソリューションを実装できます。多くの企業は、バックアップと復元、および DR サイトとして AWS クラウドを使用しています。 は、DR とビジネス継続性をサポートする多くのサービスと機能 AWS を提供します。
**Topics**
+ [オンプレミス DR から へ AWS](on-prem-dr-to-aws.md)
+ [クラウドネイティブワークロードの DR](dr-cloud-native.md)
# オンプレミス DR から へ AWS
オンプレミスワークロードのオフサイトディザスタリカバリ (DR) 環境 AWS として を使用することは、一般的なハイブリッドシナリオです。使用するテクノロジーを選択する前に、必要な復旧時間や復旧時点の目標などの DR 目標を明確にします。この定義に役立つのは、[「DR 計画チェックリスト」](https://pages.awscloud.com/rs/112-TZM-766/images/GEN_disaster-recovery-plan-checklist_May-2020.pdf)を使用することです。
AWSには、DR 環境を迅速にセットアップしてプロビジョニングするのに役立つオプションが多数用意されています。ワークロードの依存関係をすべて考慮し、DR 計画とソリューションを徹底的かつ定期的にテストして整合性を検証すること。
AWS では、ルートボリュームやオペレーティングシステムを含むオンプレミスサーバーの完全なレプリカ[AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)を作成できます AWS。Elastic Disaster Recoveryは、対象となるAWSアカウントと優先 AWS リージョンにある低コストのステージング・エリアに、マシンを継続的にレプリケートします。ブロックレベルのレプリケーションは、オペレーティングシステム、システム状態設定、データベース、アプリケーション、ファイルを含む、サーバーのストレージの正確なレプリカです。災害が発生した場合、Elastic Disaster Recoveryに指示して、数千台のマシンを数分で完全にプロビジョニングされた状態で迅速に起動させることができます。
Elastic Disaster Recoveryは、オンプレミスの各サーバーにインストールされたエージェントを使用します。エージェントは、オンプレミスサーバーの状態を、 AWS上で稼働している低性能の Amazon EC2 サーバーと同期させます。また、伸縮性ディザスタリカバリでは、DR のフェイルオーバーとフェイルバックのプロセスを自動化することもできます。フェイルオーバーとフェイルバックのプロセスを自動化することで、目標復旧時間 (RTO) をより短く、より一貫性のあるものにすることができます。
![\[データセンターと、Elastic Disaster Recovery、リカバリインスタンス、EBS ボリュームを備えた AWS 環境。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/backup-recovery/images/elastic-disaster-recovery.png)
1. レプリケーションサーバーのステータスレポート
1. ステージングエリア、リソースは自動的に作成され、終了されます。
1. RTO が分、RPO が秒で起動されたリカバリインスタンス
1. 継続的なブロックレベルのレプリケーション (圧縮および暗号化)
DR プロセスをテストし、ライブステージング環境がオンプレミス環境とコンフリクトを起こさないことを確認することが重要です。たとえば、オンプレミス、ステージング、開始した DR 環境で、適切なライセンスが利用可能で機能していることを確認します。また、作業をポーリングして中央データベースから取得する可能性のあるワーカータイプのプロセスが、重複や競合を避けるために適切に設定されていることも確認します。DR プロセスには、復旧用サーバーインスタンスをオンラインにする前に実行する必要のある必要な手順をすべて含めます。また、復旧用サーバーインスタンスがオンラインで利用可能になった後に実行する手順も含めます。[「AWS Elastic Disaster Recovery 計画自動化ソリューション」 ](https://github.com/aws-samples/drs-tools/tree/main/drs-plan-automation)のようなソリューションや、DR計画の自動化を支援する別のアプローチを使うことができます。
[「Storage Gateway ボリュームゲートウェイ」 ](https://docs.aws.amazon.com/storagegateway/latest/userguide/managing-volumes.html)を使用して、オンプレミスサーバーにクラウドベースのボリュームを提供できます。これらのボリュームは、Amazon EBS スナップショットを使用して Amazon EC2 で使用できるようにすばやくプロビジョニングすることもできます。特に、ストアドボリュームゲートウェイは、オンプレミスアプリケーションにデータセット全体への低レイテンシーアクセスを提供します。ボリュームゲートウェイは、オンプレミスまたは Amazon EC2 で使用するために復元できる、耐久性のあるスナップショットベースのバックアップも提供します。ワークロードのリカバリポイント目標 (RPO) に基づいて、ポイントインタイムスナップショットをスケジュールできます。
**重要**
ボリュームゲートウェイボリュームは、ブートボリュームとしてではなくデータボリュームとして使用することを目的としています。
オンプレミスのサーバーと同じ構成のAmazon EC2 Amazon マシンイメージ (AMI) を使用し、データボリュームを個別に指定することができます。AMI を設定してテストしたら、ボリュームゲートウェイのスナップショットに基づくデータボリュームとともに AMI から EC2 インスタンスをプロビジョニングします。このアプローチでは、特に Windows ワークロードの場合、EC2 インスタンスが適切に動作していることを確認するために、環境を徹底的にテストする必要があります。
# クラウドネイティブワークロードの DR
クラウドネイティブワークロードが DR 目標にどのように適合するかを検討してください。 は、世界中の リージョンで複数のアベイラビリティーゾーン AWS を提供します。 AWS クラウドを使用している多くの企業は、アベイラビリティ ゾーンの喪失に耐えられるようにワークロード アーキテクチャと DR の目標を調整しています。 AWS Well-Architected フレームワーク[の信頼性の柱](https://d1.awsstatic.com/whitepapers/architecture/AWS-Reliability-Pillar.pdf)は、このベストプラクティスをサポートしています。複数のアベイラビリティーゾーンを使用するように、ワークロードとそのサービスとアプリケーションの依存関係を構築できます。そうすれば、DR を自動化して DR の目標を最小限またはまったく行わずに達成できます。
しかし実際には、すべてのコンポーネントについて、冗長でアクティブで自動化されたアーキテクチャを確立できない場合があります。アーキテクチャのすべてのレイヤーを調べて、目標を達成するために必要な DR プロセスを判断します。これはワークロードによって異なり、アーキテクチャやサービスの要件も異なる可能性があります。このガイドでは、Amazon EC2 の考慮事項とオプションについて説明します。その他の AWS サービスについては、[「AWS のドキュメント」 ](https://docs.aws.amazon.com/)を参照して、高可用性とDRのオプションを決定することができます。
## 単一のアベイラビリティ・ゾーンにおける Amazon EC2 の DR
複数のアベイラビリティーゾーンのクライアントを積極的にサポートし、サービスを提供するようにワークロードを設計するようにします。Amazon EC2 Auto Scaling と Elastic Load Balancing を使用して、Amazon EC2 やその他のサービスのマルチ AZ サーバーアーキテクチャを実現できます。
使用しているアーキテクチャに、負荷分散できない EC2 インスタンスがあり、常に 1 つのインスタンスしか実行できない場合は、以下のオプションのいずれかを使用できます。
+ 最小、最大、および希望するサイズが1であり、複数の可用性ゾーン用に構成されたAuto Scalingグループを作成します。障害が発生した場合にインスタンスの交換に使用できる AMI を作成します。AMI から新しくプロビジョニングされたインスタンスが自動的に構成され、サービスを提供できるように、適切な自動化と構成を定義していることを確認します。Auto Scaling グループを指し、複数のアベイラビリティーゾーン用に設定されたロードバランサーを作成します。オプションで、ロードバランサーエンドポイントを指す Amazon Route 53 エイリアスを作成します。
+ アクティブなインスタンスの Route 53 レコードを作成し、クライアントにこのレコードを使用して接続させます。アクティブなインスタンスの新しい AMI を作成し、その AMI を使用して、別のアベイラビリティゾーンに停止状態の新しい EC2 インスタンスをプロビジョニングするスクリプトを作成します。スクリプトを定期的に実行し、以前に停止したインスタンスを終了するように設定します。アベイラビリティーゾーンに障害が発生した場合は、代替のアベイラビリティーゾーンでバックアップインスタンスを起動します。次に、この新しいインスタンスを指すように Route 53 レコードを更新します。
ソリューションが防ぐように設計された障害をシミュレートして、ソリューションを徹底的にテストします。また、ワークロードアーキテクチャが変更されたときに DR ソリューションが必要とする更新についても検討します。
## Amazon EC2 のリージョン別の障害時の DR
可用性要件が非常に高いお客様 (ダウンタイムを許容できないミッションクリティカルなアプリケーションなど) は、複数のリージョン AWS で を使用して、リージョンレベルでの問題に対する耐障害性を高めることができます。お客様は、マルチリージョン DR プランの確立と維持に必要な複雑さ、コスト、労力を利点と慎重に比較検討する必要があります。 は、グローバルな可用性、フェイルオーバー、DR のためのマルチリージョンアーキテクチャをサポートする機能 AWS を提供します。 このガイドでは、Amazon EC2 のバックアップとリカバリに固有の利用可能な機能のいくつかについて説明します。
AWS AMIs と Amazon EBS スナップショットは、1 つのリージョン内で新しいインスタンスをプロビジョニングするために使用できるリージョンリソースです。ただし、スナップショットと AMI を別のリージョンにコピーし、それらを使用してそのリージョンに新しいインスタンスをプロビジョニングすることはできます。リージョン障害 DR プランをサポートするために、AMIs とスナップショットを他のリージョンにコピーするプロセスを自動化できます。 AWS Backup Amazon Data Lifecycle Manager は、バックアップ設定の一部としてクロスリージョンコピーをサポートしています。
[「AWS Elastic Disaster Recovery」 ](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)は、あるリージョンの Amazon EC2 サーバーを自動化し、別の DR リージョンに継続的に複製するために使用できます。Elastic Disaster Recoveryは、マルチリージョンDRアプローチを簡素化し、ドリルを使用してクロスリージョンAmazon EC2 DRプランを定期的にテストするのに役立ちます。Elastic Disaster Recoveryは、バックアップとリカバリが RTO と RPO の目標を達成できない場合に役立ちます。Elastic Disaster Recovery は、RTO を数分に、RPO を 1 秒未満に抑えるのに役立ちます。
どのソリューションを使用する場合でも、障害発生時に使用するプロビジョニング、フェイルオーバー、フェイルバックのプロセスを決定する必要があります。Route 53 をヘルスチェックとドメインネームシステムのフェイルオーバーと組み合わせて使用すると、ソリューションをサポートしやすくなります。