DR戦略(AWS)

基本用語

• DR(Disaster Recovery): 災害時などにおけるシステムの復旧について考えること

• BCP(Business continuity plan): システムの復旧を含む事業全体の継続について考えること

• RTO(Recovery Time Objective): 復旧までかかる時間

• RPO(Recovery Point Objective): 復旧時の最新状態。5分間隔でバックアップを取っていれば失われるデータは5分に抑えられるが、1日単位のバックアップだと24時間分失う可能性がある。

• RLO(Recovery Level Objective): どこまで復旧させるかのレベル。障害発生時の復旧優先度を決めておく

AWSにおける戦略

引用元：https://aws.amazon.com/jp/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/

マルチAZ戦略

すべてのAWSリージョンは、複数のアベイラビリティーゾーン（AZ）で構成されています。
各AZは、1つ以上のデータセンターで構成されており、地理的に離れた場所にあります。
これにより、単一のイベントが複数のAZに影響を与えるリスクが大幅に減少します。
したがって、停電、フラッディング、その他の局所的な混乱などのイベントに耐えるDR戦略を設計している場合は、AWSリージョン内でマルチAZDR戦略を使用することで必要な保護を提供できます。

マルチリージョン戦略

AWSは、ワークロードに対してマルチリージョンアプローチを可能にする複数のリソースを提供します。
これにより、別々の異なる場所にある複数のデータセンターに影響を与える可能性のある十分な範囲のイベントに対するビジネス保証が提供されます。

DRにおける4つの戦略

Backup&Restore

バックアップとリカバリの戦略は、RTOにとって最も効率が悪いと考えられています。
ただし、Amazon EventBridgeなどのAWSリソースを使用してサーバーレス自動化を構築できます。
これにより、検出とリカバリが改善され、RTOが削減されます。 これについては、今後のブログ投稿で詳しく説明します。

Pilot Light

パイロットライト戦略では、データはライブですが、サービスはアイドル状態です。
ライブデータとは、データストアとデータベースがアクティブなリージョンで最新（またはほぼ最新）であり、読み取り操作を処理する準備ができていることを意味します。図6では、Amazon Auroraグローバルデータベースが、リカバリリージョンのローカル読み取り専用クラスターにデータを複製しています。ただし、すべてのDR戦略と同様に、バックアップ（図6のAurora DBクラスタースナップショットなど）も必要です。データを一掃または破損する災害イベントの場合、これらのバックアップにより、最後の既知の良好な状態に「巻き戻す」ことができます。

パイロットライト戦略では、図6のElasticLoadBalancingやAmazonEC2Auto Scalingのような基本的なインフラストラクチャ要素が配置されていますが、機能要素（コンピューティングなど）は「シャットオフ」されています。
クラウドでは、Amazon EC2インスタンスをシャットオフする最善の方法は、デプロイしないことです。
図6は、デプロイされたインスタンスがゼロであることを示しています。これらのインスタンスを「オン」にするには、以前にビルドされてすべてのリージョンにコピーされたAmazon Machine Image（AMI）を使用します。このAMIは、必要なオペレーティングシステムとパッケージを正確に使用してAmazonEC2インスタンスを作成します。トリガーされるまで家を暖めることができない炉のパイロットライトのように、パイロットライト戦略は、残りのインフラストラクチャを展開するためにトリガーされるまで要求を処理できません。

Warm stanby

パイロットライト戦略と同様に、ウォームスタンバイ戦略は定期的なバックアップに加えてライブデータを維持します。
2つの違いは、インフラストラクチャとその上で実行されるコードです。
ウォームスタンバイは、要求を処理できる最小限のデプロイメントを維持しますが、容量は減少します。
本番レベルのトラフィックを処理することはできません。 これを図7に示します。ティアごとに、1つのAmazonEC2インスタンスがデプロイされています。 これにより、パッシブエンドポイントが合成テストトランザクションを送信する前に処理するための追加の作業が不要になるため、ウォームスタンバイのテストが容易になります。 フェイルオーバーの前に、インフラストラクチャは本番環境のニーズを満たすためにスケールアップする必要があります。

Multi-site active/active

マルチサイトアクティブ/アクティブでは、2つ以上のリージョンがアクティブにリクエストを受け付けています。
フェイルオーバーは、リクエストを処理できないリージョンからリクエストを再ルーティングすることで構成されます。
ここでは、データはリージョン間で複製され、それらのリージョンで読み取り要求を処理するために積極的に使用されます。
書き込み要求の場合、ローカルリージョンへの書き込みや、特定のリージョンへの書き込みの再ルーティングなど、いくつかのパターンを使用できます。これらについては、今後のブログ投稿で詳しく説明します。
DRの場合と同様に、偶発的な削除や破損を修正するためにデータを復元する必要がある場合に備えて、データもバックアップされます。
図8は、データベース層として使用されるAmazonDynamoDBグローバルテーブルを示しています。
これは、マルチサイトアクティブ/アクティブに最適です。
任意のリージョンのテーブルに書き込むことができ、データは通常1秒以内に他のすべてのリージョンに伝播されるためです。