【AWS】DR（災害対策）戦略設計

この記事について

AWSのDR戦略に関する勉強のアウトプットです。

参考ドキュメント

REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する

DR戦略

プライマリロケーションでワークロードを実行できなくなった時に、復旧サイトでワークロードに耐えられるようにする。

DR戦略の比較

実装コストがかかるほど、サービスが中断する時間が長くなり、ビジネスへの影響が増えるが、運用コストは安く済む。
運用コストがかかるほど、複雑さは増すが、サービスが中断する時間は短くなり、ビジネスへの影響は少なく済む。

DR戦略の選択

複数リージョンに跨るDR戦略設計では下記いずれかを選択する。

◆バックアップと復元（数時間でのRPO、24時間以下でのRTO)

■複雑さ：少ない
■コスト：安い
■復旧時間：多い（24時間以下)
■復旧労力：とても多い

＜復旧手順＞
1.データとアプリケーションを復旧リージョンにバックアップ
2.インフラデプロイ
3.コードをデプロイ
4.バックアップされたデータを復元
5.復旧リージョンで災害から復旧

◆パイロットライト(数分間のRPO、数十分間のRTO)

ホットスタンバイのように常に別の場所でシステムを動かすのとは異なり、最小限の核となる部分だけをスタンバイしておく方法。

■複雑さ：少ないがバックアップと復元より多い
■コスト：バックアップと復元より高い
■復旧時間：数十分
■復旧労力：バックアップと復元より少ないが、追加のリソースと依存関係が必要。

＜手順＞
1.コアワークロードインフラのコピーを復旧リージョンにプロビジョニング
2.データを復旧リージョンにレプリケートし、そこでバックアップを作成
3.データのレプリケーションとバックアップのサポートに必要なリソースは、常にオン
4.アプリケーションサーバーやサーバーレスコンピューティング等、その他の要素はデプロイされないので必要に応じて設定・作成

◆ウォームスタンバイ（数秒間のRPO、数分間のRTO）

予備機を最小限のリソースで起動させ、障害時に本番と切り替えられるように準備しておく方法。ウォームスタンバイの規模が大きいほどRTOは短くなる。

■複雑さ：パイロットライトより多い
■コスト：パイロットライトより高い
■復旧時間：数分間
■復旧労力：少ない

＜手順＞
1.データは復旧リージョンでレプリケートされ、使用できる。
2.復旧時にはシステムをすぐにスケールアップして本番環境の負荷を処理できるようにする。

◆マルチリージョン(マルチサイト)アクティブ/アクティブ(ほぼ0のRPO、ほぼ0のRTO)

複数のAWSリージョンにデプロイされているため、同時にワークロードを実行。一つのリージョンに障害が起きてもほぼ通常通りの運用が可能。
DR以外の理由でも選択される戦略（例：可用性を高める/グローバルオーディエンスにワークロードをデプロイする時）

■複雑さ：とても多い
■コスト：高い
■復旧時間：ほぼ0
■復旧労力：ほぼ0

＜手順＞
1.常にリージョン間でデータを同期する必要がある。
2.異なるリージョンレプリカ内の同じレコードへの書き込みによって生じる矛盾を回避する処理が必要。（複雑になることがある)
※データレプリケーションはデータの同期に便利。特定のタイプの災害から保護するが、ポイントインタイムリカバリ（※特定の時点までのデータ変更のリカバリ）のためのオプションを含む必要がある。含まないとデータの破損や破壊から保護しない。

ワークロードのリソースと、それらの設定がフェイルオーバー前に復旧リージョンでどうなるかを評価する

AWS CloudFormationやTerraformを使用する。
複数のアカウントとリージョンに単一の操作でデプロイするには、AWS CloudFormation StackSetsを使用。
パイロットライトとウォームスタンバイ戦略の場合、インフラを本番環境で使用するには追加のアクションが必要になる。
→CloudFormationのチューニングや条件付きロジックを使用し、デプロイされるスタックがアクティブかスタンバイかを単一のテンプレートで制御できる。

災害発生時に復旧リージョンをフェイルオーバーに備える方法を決定し、実装する

【マルチサイトアクティブ/アクティブの場合】
フェイルオーバーとはリージョンを隔離して残りのアクティブリージョンに頼ることを意味し、これらのリージョンはトラフィックを受け入れる準備ができている。

【パイロットライト or　ウォームスタンバイ】
不足しているリソースなどをデプロイしたり、スケールアップする。

災害時にフェイルオーバーするトラフィックを再ルーティングする方法を決定し、実装する。

自動または手動で実施できる。基本的には”手動”によるフェイルオーバを実施する。（フェイルオーバーのステップは自動化できるため、ボタンを押して手動開始するイメージ）
ヘルスチェックやアラームに基づくフェイルオーバーの自動開始は、”誤ったフェイルオーバー”によって”使用できないデータ”や”データ損失”などのコストが発生するので注意。

■トラフィック管理オプションを検討する
1つ以上のAWSリージョンの複数のIPエンドポイントをRoute53のドメインに紐づけられる。
手動フェイルオーバーを実装する際には「Amazon Route53 Application Recovery Controller」を使用する。
→高可用性データプレーンAPIを提供して、トラフィックを復旧リージョンに再ルーティングする。※コントロールプレーンは使用しない。

ワークロードをフェイルバックする方法のプラン設計

フェイルバックとは・・・
障害が終息したら、ワークロードの操作をプライマリリージョンに戻すこと。

インフラとコードをプライマリリージョンにプロビジョニングする時は、コードデプロイパイプラインに依存する。
フェイルバックで大事なことは、データストアを復元し、動作中の復旧リージョンを一貫性を確認すること。
　→復旧リージョンからプライマリリージョンへ再同期→最新であることを確認する。
　　DynamoDBグローバルテーブルはこれを自動的に行う。

【自動で行われない場合】
プライマリリージョンで、復旧リージョンのDBのレプリカとして、DBを再確立する必要がある。
　＜手順＞
　1.古いプライマリDBを削除
　2.新しいレプリカを作成

【復旧リージョンで実行を続行できる場合】
この場合は、復旧リージョン→プライマリリージョンとすることを検討する。前のプライマリリージョンは復旧リージョンとする。
一部の組織は、計画的にローテーションを実行し、定期的にプライマリリージョンと復旧リージョンを交換したりする。

【プレイブックの記載】
フェイルオーバーとフェイルバックに必要な全てのステップをプレイブックに記載し、チームメンバー全員が使用できるようにし、定期的にレビューすることが大事。