Disaster Recovery Testing

1. 本番で使う復旧経路をテストする

DR テストでは、本番災害時に使う復旧経路を可能な限り再現します。

本番復旧経路
クロスアカウントバックアップ
↓
復旧アカウント
↓
復元
↓
ネットワーク / IAM / 依存関係
↓
アプリケーション
↓
トラフィック 切り替え

本番ではクロスアカウント復旧を使うのに、テストでは本番アカウント内のローカルスナップショットだけを復元した場合、クロスアカウント権限、ボールト、IAMロール、復旧アカウント側のネットワークや設定を検証できません。

復旧経路の一部だけを省略して成功しても、実際の復旧手順が動くことの証明にはなりません。

2. 復元テスト・フェイルオーバーテスト・フェイルバックテストを分離する

「復元できた」と「サービスをフェイルオーバーできた」は別の成功 基準です。さらに、フェイルオーバー後に元環境へ戻す必要があるアーキテクチャではフェイルバックも独立したテストゲートにします。

3. 復元成功とアプリケーション復旧を分ける

復元ジョブがCOMPLETEDでも、復旧したリソースがビジネスサービスとして使えるとは限りません。

復元ジョブ COMPLETED
↓
インフラストラクチャ検証
↓
ネットワーク / 依存関係検証
↓
アプリケーション検証
↓
ビジネストランザクション検証
↓
データ検証

リソース状態だけでなく、アプリケーション接続、認証、必要な依存関係、重要ビジネストランザクション、復旧したデータポイントまで確認します。

4. サービス固有のテスト機能は「1つのゲート」として使う

AWSサービスが提供するテスト機能は有効ですが、エンドツーエンド DR テストそのものではありません。

AWS Backup 復元テストやAWS DRS 復旧訓練が成功しても、DNS、クライアント、依存関係、本番相当キャパシティまで自動的に証明されるわけではありません。

5. 無停止テストと制御されたフェイルオーバーを使い分ける

本番トラフィックを変更せず復旧環境を起動する無停止テストは、日常的な復旧準備状態確認に有効です。

本番継続
        │
        ├─ 送信元 / レプリケーションは継続
        │
        └─ 復旧環境を起動
                    ↓
             内部検証

ただし、このテストだけでは本番 DNS / ルーティング、実クライアント、本番相当負荷、運用手順のすべてを証明できない場合があります。リスクとビジネス要件に応じて、無停止テストと制御されたフェイルオーバー 演習を組み合わせます。

6. RTOはサービス中断からビジネスサービス 復元まで測る

RTOの起点は単なるテスト開始時刻ではなく、模擬障害によってサービス中断が発生した時点です。

模擬サービス中断
↓
検知
↓
復旧判断
↓
復元 / 開始
↓
依存関係復旧
↓
トラフィック 切り替え
↓
アプリケーション / ビジネス検証
↓
ビジネスサービス復元済み

このエンドツーエンド実測時間をビジネス RTOと比較します。

データベース復元が20分でも、アプリケーション起動10分、トラフィック切替5分、検証10分ならサービス復旧は45分です。RTOが30分なら未達です。

7. RPOは復旧済み データポイントで検証する

RPOは復元にかかった時間ではありません。復旧環境にどの時点までのデータが存在するかを検証します。

模擬 中断 10:00
↓
復旧済み 最新 トランザクション 09:57
↓
復旧ポイント 不足 約3分
↓
ビジネス RPOと比較

レプリケーション遅延やバックアップジョブ成功だけを見てRPO達成とせず、テストで実際に利用可能になったデータポイントを確認します。

8. フェイルオーバーテストでは復旧サイトのキャパシティと依存関係まで確認する

復旧リソースが起動しただけではフェイルオーバー成功ではありません。

復旧サイト
├─ データ
├─ アプリケーション
├─ ネットワーク
├─ 認証 / シークレット
├─ 外部依存関係
├─ 本番相当キャパシティ
└─ トラフィックルーティング
        ↓
重要ビジネストランザクション

ウォームスタンバイが正常に起動していても、本番負荷へスケールできなければビジネス RTOを満たせない場合があります。依存関係や認証情報も復旧経路の一部としてテストします。

9. テスト環境ではビジネス上の副作用を制御する

本番データを復元してアプリケーション検証を行う場合、テスト環境から実ビジネスアクションを発生させないようにします。

ネットワーク分離、テストエンドポイント、認証情報制御、外部統合の切替などで、本番相当検証と副作用防止を両立させます。

10. フェイルバックはトポロジーに依存しないにテストする

フェイルバックを「復旧サイトからプライマリへ手動でデータコピーする手順」と固定しません。利用サービスやレプリケーショントポロジーによって戻し方は異なります。

復旧サイトで本番継続
↓
元のプライマリ / 優先サイトを再利用可能にする
↓
サービス固有の方法で
データ / 状態 / レプリケーショントポロジーを整合
↓
戻り前検証
↓
トラフィック / ロールを安全に戻す
↓
通常の保護状態を再確立

AWS DRSでは逆方向 レプリケーションがフェイルバック仕組みになります。Aurora グローバルデータベースでは旧プライマリリージョンを再参加させ、正常な状態で切り替えする方式があります。マルチアクティブアーキテクチャでは「プライマリへ戻す」というフェイルバック自体が同じ意味を持たない場合があります。

11. 戻り前にデータ / 状態の整合を確認する

フェイルオーバー中に復旧サイトでビジネストランザクションが継続していれば、元のサイト復旧直後のデータ / 状態と一致しない可能性があります。

復旧側で新しいトランザクション
↓
元のサイト復旧
↓
データ / 状態 / レプリケーショントポロジーを整合
↓
同期 / 整合性検証
↓
トラフィック / ロール戻り

具体的な同期方法はサービス依存ですが、戻り先が最新のビジネス状態を処理できることを確認してから戻すというゲートは共通です。

12. フェイルバック後は通常の保護状態まで戻す

トラフィックが元のサイトへ戻っただけでは復旧演習は完了ではありません。

• プライマリ / 優先サイトが本番を正常処理する。
• 次回災害に備えるレプリケーション / 保護を再確立する。
• バックアップ / 監視 / アラームを正常化する。
• 復旧サイトを次回利用可能な状態へ戻す。
• 不要な訓練 / 一時的なリソースをクリーンアップする。

次の障害でも同じ復旧経路を使える状態まで戻してテスト完了とします。

13. 成功 基準をテスト前に定義する

テスト後に感覚で成功判定しないよう、ビジネス要件を測定可能な条件へ変換します。

RTO ≤ 30分
RPO ≤ 5分
重要ビジネストランザクション = 成功
データ完全性 = 合格
トラフィック 切り替え = 成功
戻り / 保護の再確立 = 成功

インフラストラクチャが起動したかだけではなく、ビジネスとして必要な復旧状態を合格 / 不合格条件にします。

14. 復旧 フェーズごとの時間と障害を記録する

合計復旧時間だけでなく、各フェーズを記録します。

RTO超過が発生したとき、どのフェーズがボトルネックなのかを特定できるようにします。権限エラー、キャパシティ 不足、手動手順なども記録します。

15. 定期テストとアーキテクチャ変更後の再テストを行う

復旧経路はアプリケーションやインフラストラクチャの変更で壊れる可能性があります。

定期DR テスト
+
重要なアーキテクチャ変更後の再テスト

テスト頻度はビジネス重要度、コンプライアンス要件、変更頻度、復旧複雑さから決めます。すべてのワークロードへ同じ頻度を固定しません。

16. 災害復旧テストの判断フロー

ビジネス RTO / RPO
        ↓
実際の復旧経路を特定
        ↓
テストゲートを決める
├─ 復元
├─ フェイルオーバー
└─ フェイルバック / 戻り
        ↓
無停止 または 制御された演習
        ↓
副作用 制御
        ↓
成功 基準を定義
        ↓
復旧実行
        ↓
インフラストラクチャ / アプリケーション / ビジネス検証
        ↓
復旧済み データポイント確認
        ↓
実際の RTO / RPOを計測
        ↓
戻り / 通常の保護状態再確立
        ↓
要件を満たしたか判定

17. 混同ポイント

18. まとめ

• 本番で使う復旧経路を可能な限りそのままテストする。
• 復元テスト、フェイルオーバーテスト、フェイルバックテストは別の成功ゲートとして扱う。
• サービス固有の復元テスト / 復旧訓練はエンドツーエンド DR テストの一部として使う。
• RTOはサービス中断からビジネスサービス 復元までを実測する。
• RPOは復旧済み データポイントをビジネス要件と比較する。
• フェイルオーバーテストではキャパシティ、依存関係、トラフィック、ビジネストランザクションまで確認する。
• テスト環境では本番相当検証とビジネス上の副作用防止を両立する。
• フェイルバックはトポロジーに依存しないに捉え、データ / 状態 / ロールを整合してから戻す。
• 戻り後はレプリケーション、バックアップ、監視など通常の保護状態を再確立する。
• 成功 基準を事前定義し、フェーズ別結果を記録する。
• DR テストは定期的に、重要なアーキテクチャ変更後にも再実行する。

19. 主要AWS公式資料

• AWS Well-Architected — 災害復旧の実装をテストする
• AWS Backup — 復元テスト
• AWS Backup — 復元テストの検証
• AWS Elastic Disaster Recovery — 復旧とフェイルバック
• AWS Elastic Disaster Recovery — 復旧計画の実行