Business Continuity要件から構成を選択する

1. 同じ要件へすべての制御を接続する

マルチAZ、マルチリージョン、レプリケーション、バックアップ、トラフィック 切り替え、監視が個別に存在していても、それぞれが異なる障害範囲を前提にしていればビジネス継続性は成立しません。

リージョン規模の障害を守る要件
        ↓
アプリケーション   → 復旧リージョンあり
データベース      → 復旧リージョンあり
認証→ プライマリリージョンのみ
        ↓
ビジネスサービスはリージョン規模の障害で再開できない

制御の有無ではなく、同じ障害範囲とRTO / RPOに対してエンドツーエンドで整合しているかを確認します。

2. 重要復旧経路を作る

ビジネスサービス再開に必要な依存関係を並べ、復旧の順序・並列性・依存関係を確認します。

障害検知
        ↓
データベース準備完了 ─────┐
認証準備完了 ├→ アプリケーション準備完了
ネットワーク準備完了 ──────┘
        ↓
トラフィック 切り替え
        ↓
ビジネス検証

重要なのは単純な「最も遅いコンポーネント」ではなく、ビジネスサービス再開をゲートする重要復旧経路上の依存関係 / 抜けです。

順番に実行する処理は時間が積み上がり、並列に復旧できる処理は必ずしも単純加算されません。またビジネスサービス再開に不要な任意コンポーネントは重要経路から外れる場合があります。

3. ゲート制御 依存関係が1つでも要件未達ならアーキテクチャ全体を失敗にする

一部のコンポーネントが非常に高速に復旧しても、必須依存関係がRTO / RPOを満たさなければビジネスサービスは要件を満たしません。

ビジネス RTO 15分

アプリケーション準備完了       6分
データベース準備完了          8分
認証準備完了   35分  ← ゲート制御 不足

→ ビジネスサービスは15分以内に再開できない

同様に、ビジネストランザクションに必要な重要データの一部だけRPOを満たしていても不十分です。

4. 配置とデータ継続性を同じ復旧経路で監査する

コンピューティングだけマルチリージョンでもデータがプライマリリージョンに残ればリージョン規模の復旧は成立しません。逆にデータだけ複製しても復旧リージョンでアプリケーションを実行できなければ利用者へサービスを戻せません。

5. 障害モードごとの制御抜けを探す

同じデータ保護制御ですべての障害モードを守れるとは限りません。

リージョン規模の障害
→ レプリケーションで別リージョンのデータを利用

論理破損 / 誤削除
→ 過去の復旧ポイントへ戻れるバックアップ

クロスリージョンレプリケーションが存在していても、誤削除や論理破損までレプリカへ伝播するなら、その障害モードには別の復旧ポイントが必要です。アーキテクチャ選択では制御を単独評価せず、要件に残る抜けを探します。

6. 復旧リージョン準備状態をキャパシティ・クォータ・設定まで監査する

リソース定義が存在するだけでは本番負荷を処理できるとは限りません。復旧先について次を確認します。

• 必要なAWSサービス / 機能を利用できるか
• 必要キャパシティへRTO内に到達できるか
• 対象サービスのリージョン固有のサービスクォータが十分か
• アプリケーションバージョン、IAM、ネットワーク、実行時設定に有害なドリフトがないか

復旧リージョン
リソースあり
        ↓
リージョン固有の クォータ不足
        ↓
必要キャパシティへスケールできない
        ↓
リージョン規模の復旧失敗

7. 設定の同等性と常時同一キャパシティを混同しない

復旧リージョンを常時プライマリと同一キャパシティで稼働させることが目的ではありません。

プライマリ
200 インスタンス

復旧リージョン
平常時 50 インスタンス
        ↓ フェイルオーバー
RTO内に200へスケール可能

設定 / IAM / ネットワークは整合
        ↓
要件を満たせる候補

設定の同等性 ≠ 常時同一キャパシティです。必要なのは、復旧時に正しい設定で必要キャパシティへRTO内に到達できることです。

8. 復旧宛先の準備状態をトラフィック 切り替えのゲートにする

プライマリ障害を検知しただけでトラフィックを無条件にセカンダリへ送ると、データ同期・アプリケーションキャパシティ・依存関係準備が完了していない環境へ利用者を誘導する可能性があります。

障害検知
        ↓
復旧宛先
├─ データ準備完了?
├─ アプリケーション準備完了?
├─ 依存関係準備完了?
└─ キャパシティ準備完了?
        ↓
準備完了
        ↓
トラフィック 切り替え

9. 監視と復旧手順も重要復旧経路へ入れる

監視は障害を見つけるだけではなく、復旧判断と復旧結果の検証へ接続します。また運用者承認、ランブック、制御プレーン運用などが必要なら、その時間もエンドツーエンド復旧へ影響します。

障害検知
+ 判断 / 承認
+ 復元 / 開始 / スケール
+ 依存関係復旧
+ トラフィック 切り替え
+ ビジネス検証
        ↓
実際のエンドツーエンド RTO

厳しいRTOに対して災害後の新規プロビジョニングや手動手順が多すぎる場合は、事前プロビジョニングや自動化などで復旧経路を短縮する候補を評価します。

10. 監視正常と復旧準備完了を分離する

レプリケーションが正常、バックアップジョブが成功、アラームがOKでも、復旧リージョンのクォータ不足や設定ドリフトが残っている場合があります。

運用上の正常性
≠
復旧準備状態

監視シグナルと復旧テストの両方を使い、実際の復旧経路が動作することを確認します。

11. 実際のテスト 結果をアーキテクチャ選択へ戻す

設計上のRTO / RPOではなく、実際の復旧テストで得た値をビジネス要件と比較します。

要件
RTO 15分 / RPO 5分

テスト 結果
実際の RTO 28分 / 実際の RPO 3分
        ↓
RPO 通過
RTO 失敗
        ↓
重要復旧経路を分析
        ↓
不足を修正
        ↓
再テスト

設計値を理由に実際の障害を無視せず、テスト結果をアーキテクチャへフィードバックします。

12. 必須制約を満たした後でコスト / 複雑さを比較する

より多くのリージョンやより高価なスタンバイ方式が常に正解ではありません。要件を満たす候補を残してから、コスト、運用の複雑さ、整合性、テスト負荷などを比較します。

必須制約
├─ 障害範囲
├─ RTO
├─ RPO
└─ 復旧準備状態
        ↓ 全部通過
候補 A / B / C
        ↓
コスト / 複雑さ比較
        ↓
必要十分なアーキテクチャを採用

AZ 障害までが要件で、マルチAZ構成が実測でRTO / RPOを満たしているなら、マルチリージョン化を無条件に追加する必要はありません。

13. ビジネス継続性制御マトリクス

14. アーキテクチャ選択フロー

ビジネス要件
        ↓
障害範囲 + RTO / RPO
        ↓
重要依存関係を列挙
        ↓
復旧順序・並列性・依存関係を確認
        ↓
重要復旧経路を特定
        ↓
配置 / データ / 依存関係
        ↓
キャパシティ / クォータ / 設定
        ↓
トラフィック / 監視 / 復旧手順
        ↓
復旧テスト
        ↓
実際の RTO / RPOで必須制約を満たす？
├─ いいえ
│   ↓
│ ゲート制御 不足を修正
│   ↓
│ 再テスト
└─ はい
    ↓
コスト / 複雑さを比較
    ↓
必要十分なアーキテクチャを採用

15. 混同ポイント

16. まとめ

• ビジネス継続性は個別制御ではなくエンドツーエンド復旧アーキテクチャとして評価する。
• 重要依存関係の復旧順序・並列性から重要復旧経路を特定する。
• 重要復旧経路上のゲート制御 依存関係 / 抜けがビジネス要件を制約する。
• 配置、重要データ、依存関係、トラフィックを同じ障害範囲へ整合させる。
• 復旧リージョンではサービス / 機能だけでなくキャパシティ、リージョン固有の クォータ、設定ドリフトを確認する。
• 設定の同等性は常時同一キャパシティを意味しない。RTO内に必要キャパシティへ到達できることが重要。
• トラフィックは復旧宛先の準備状態を確認してから切り替える。
• 手動手順や制御プレーン運用もエンドツーエンド RTOへ影響する。
• 監視正常と復旧準備完了を分離し、実際の復旧テストで証明する。
• 実際の RTO / RPOが必須制約を満たした候補から、コスト / 複雑さを比較して必要十分なアーキテクチャを選択する。

17. 主要AWS公式資料

• AWS Well-Architected Framework — 災害復旧の計画
• AWS Well-Architected Framework — 災害復旧サイトの設定ドリフト管理
• AWS Well-Architected Framework — 災害復旧実装のテスト
• AWS Service Quotas — 概要