Elastic Disaster RecoveryとDR戦略のシナリオ判断

拠点停止と誤更新を想定した設計相談を通じ、DR方式の費用・準備状態・復旧手順を比較します。DRSの導入だけでは残る作業も判断します。

この単元で学ぶこと

1. 安い方式を選ぶ条件月次集計なら数時間の復元を許容できる場合があり、常時同じ規模の環境を動かす必要はないかもしれません。バックアップと復元を候補にし、データ量の増加でも期限内に戻せるか試します。費用の比較は保存料金だけでなく、復元訓練、転送、作業時間を含めます。

2. 二つの待機方式設計AはDB複製だけ動き、アプリは障害時に起動します。設計Bは小規模なDBとアプリが一式動き、少数の要求なら処理できます。Aはパイロットライト、Bはウォームスタンバイの考え方です。両方とも本番容量への準備が必要ですが、追加構築の有無が停止時間へ影響します。

3. 平常時も双方で処理世界の利用者を複数リージョンで処理する構成はアクティブ／アクティブになり得ます。ただし同じ在庫が両方から売られる場合、書込みの衝突や整合性を扱う必要があります。障害で片方へ全負荷が集まったときに残存能力が足りるかも確認します。単にリージョンを二つ作るだけでは完成しません。

4. 既存サーバーの復旧オンプレミスの対応OSのサーバーを、アプリを大きく書き換えずAWSへ回復したい場合にDRSを検討できます。継続複製の帯域と遅延、起動設定、復旧先ネットワークを準備します。DBや外部機器等の依存まで一律に変換されると思わず、サーバーごとの復旧順序も定めます。

5. 訓練で見つかる不足 DRSの訓練インスタンスは起動したのに、オンプレミスの認証サーバーへ接続できず業務を開始できない場合があります。DNS、認証、証明書、鍵、許可リストを棚卸しし、災害時も利用可能な代替を用意します。本番サービスへ誤って通知や決済を送らない訓練環境の分離も必要です。

6. 最新が壊れている場合不正な更新が全複製先へ伝わったとき、最新のコピーへ切り替えても正常な業務は戻りません。破損開始前の復旧点を選び、正当な更新をどこまで戻せるか評価します。データの新しさだけでなく正常性を検査し、バックアップも同じ管理権限の事故で消えないよう保護します。

7. 拡張に失敗する場合縮小した待機環境が動いていても、障害時にEC2を追加できなければ全利用者へ提供できません。復旧先のクォータ、IP、容量、依存APIを事前に検証します。必要容量をあらかじめ持つ方式は費用が増えますが、障害時の新規作成への依存を減らせるという判断点があります。

8. 回復後の運用復旧先で受けた注文は元拠点にまだない可能性があります。元の環境へ戻す場合、同期方向を確認し、二か所で勝手に更新しないよう切替を統制します。フェイルオーバーだけでなくフェイルバックも訓練し、RTO、失う更新の範囲、利用者の接続変更を記録します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。