DR戦略パターンの比較と選択

1. DR戦略は「復旧リージョンを平常時にどこまで準備するか」が大きな違い

AWSでは代表的なDR戦略として、バックアップと復元、パイロットライト、ウォームスタンバイ、マルチサイト アクティブ/アクティブがあります。

パイロットライトからマルチサイト アクティブ/アクティブへ進むほど、一般に復旧リージョンで平常時から稼働しているリソースが増え、復旧時に必要な運用を減らしやすくなります。

平常時から稼働するリソースが増える
        ↓
復旧時のデプロイ / 開始が減る
        ↓
短いRTOを狙いやすい
        ↓
稼働コスト / 複雑さが増える

バックアップと復元より常時準備を増やす代表的な戦略として、パイロットライト、ウォームスタンバイ、マルチサイト アクティブ/アクティブを比較します。

2. RTO / RPOの数字だけを暗記して戦略を選ばない

AWS公式ガイダンスでは、パイロットライトは数十分程度、ウォームスタンバイは分単位、マルチサイト アクティブ/アクティブはさらに短い復旧目標を狙う代表的なパターンとして整理されています。

ただし、これらはアーキテクチャパターンの代表的な傾向であり、保証値ではありません。

実際のRTO / RPOは、データレプリケーション、アプリケーションアーキテクチャ、復旧自動化、キャパシティ、トラフィック管理、依存関係などに左右されます。

したがって「ウォームスタンバイなら必ず5分」のように固定値として暗記せず、要件と復旧運用から判断します。

3. パイロットライトは「コアだけを生かしておく」

パイロットライトでは、復旧リージョンにワークロードのコアとなるインフラストラクチャとデータを準備し、データはプライマリリージョンから継続的にレプリケーションします。

一方、アプリケーションサーバーなど一部のリソースは平常時にはデプロイしない、または本番リクエストを処理できる状態までは稼働させません。

プライマリリージョン
   │
   │ データレプリケーション
   ▼
復旧リージョン
  コアインフラストラクチャ / データ  ← 準備完了
  アプリケーション階層            ← 追加デプロイ / 開始が必要

不足リソースはIaCなどから迅速にデプロイできる状態を準備しておきます。

4. パイロットライトは追加操作なしでは本番トラフィックを処理できない

パイロットライトの決定的な特徴は、復旧リージョンにデータやコアインフラストラクチャが存在していても、追加操作なしでは本番リクエストを処理できないことです。

災害検知
        ↓
不足リソースをデプロイ / 開始
        ↓
本番キャパシティへスケール
        ↓
アプリケーション検証
        ↓
トラフィック切り替え

この復旧運用が必要な分、ウォームスタンバイよりRTOが長くなりやすい一方、平常時の稼働コストは抑えやすくなります。

5. パイロットライトは稼働コストと復旧運用のトレードオフ

復旧リージョンで常時動かすリソースをコア中心に絞れるため、パイロットライトはウォームスタンバイやアクティブ/アクティブより稼働コストを抑えやすいパターンです。

ただし、災害時にはアプリケーションリソースのデプロイ / 開始やスケールが必要です。

低い稼働コスト
      ↕
多い復旧運用

「復旧時に追加デプロイしてよいか」が重要な選択基準になります。

6. ウォームスタンバイは「縮小版本番を常時動かしておく」

ウォームスタンバイでは、復旧リージョンに完全に機能する本番環境の縮小版を常時稼働させます。

プライマリリージョン
  完全本番キャパシティ
        │
        │ データレプリケーション
        ▼
復旧リージョン
  完全スタック
  縮小キャパシティ
  常時稼働

パイロットライトと異なり、復旧リージョンはすでにアプリケーションとして機能しています。

7. ウォームスタンバイは縮小キャパシティならすぐトラフィックを処理できる

ウォームスタンバイでは、災害直後から復旧リージョンが縮小キャパシティでリクエストを処理できます。

災害
   ↓
復旧リージョンへトラフィックを切り替え
   ↓
縮小キャパシティでサービスを提供
   ↓
本番キャパシティへスケール

そのためパイロットライトと比べると、新規デプロイや開始の運用が少なく、RTOを短くしやすくなります。

8. ウォームスタンバイは稼働コストとの交換で復旧運用を減らす

ウォームスタンバイはアプリケーション、コンピューティング、データベースなどを縮小構成ながら常時稼働させるため、パイロットライトより稼働コストは高くなりやすくなります。

9. 完全キャパシティのスタンバイとアクティブ/アクティブは同じではない

ウォームスタンバイの復旧環境を完全本番キャパシティまで常時稼働させる構成はホットスタンバイと呼ばれることがあります。

ただし完全キャパシティであることと、平常時から複数リージョンが本番トラフィックを処理することは別です。

ホットスタンバイ
プライマリリージョン    → トラフィックを処理
セカンダリリージョン  → 完全キャパシティだがスタンバイ

マルチサイト アクティブ/アクティブ
リージョン A → トラフィックを処理
リージョン B → トラフィックを処理

キャパシティの大きさだけでアクティブ/アクティブとは判断しません。

10. マルチサイト アクティブ/アクティブは複数リージョンが平常時からアクティブ

マルチサイト アクティブ/アクティブでは、複数リージョンへワークロードを展開し、複数リージョンが平常時から本番トラフィックを処理します。

             ユーザートラフィック
               /     \
              ▼         ▼
          リージョン A   リージョン B
           アクティブアクティブ

一方のリージョンを利用できなくなった場合は、失敗リージョンをトラフィック経路から外し、残ったアクティブリージョンでサービスを維持します。

11. アクティブ/アクティブではスタンバイを起動する復旧運用を減らせる

パイロットライトやウォームスタンバイではプライマリから復旧リージョンへ切り替えるアクティブ/パッシブの考え方が中心です。

アクティブ/アクティブでは複数リージョンがすでにアクティブなので、リージョン障害時は失敗リージョンを退避し、残存リージョンへトラフィックを収束させます。

リージョン障害
   ↓
失敗リージョンをトラフィック経路から除外
   ↓
残存リージョンへトラフィックを収束
   ↓
残存リージョンが必要な負荷を処理

そのため復旧時の新規プロビジョニングを減らせますが、残存リージョンのキャパシティ設計が必要です。

12. アクティブ/アクティブではデータアーキテクチャが難しくなる

アクティブ/アクティブの難しさは、コンピューティングを複数リージョンへ置くことだけではありません。

複数リージョンで書き込みを受け付ける場合は、同じデータへの同時書き込みや競合をどう防止・解決するかがアーキテクチャ責任になります。

書き込みグローバル
→ 書き込みリージョンを制御

書き込みローカル
→ 各リージョンで書き込み

書き込み 分断
→ キー等で書き込み先を分離

具体的なデータベースサービスの選定よりも、アクティブ/アクティブではデータ整合性と書き込み戦略まで複雑さに含まれることを押さえます。

13. データ保護要件はDR戦略と分けて確認する

既習のとおり、レプリケーションは過去時点への復旧を代替しません。マルチサイト アクティブ/アクティブを選んでもこの前提は変わらないため、DR戦略の比較ではデータ保護要件が別途満たされていることを確認します。

14. 初期コストと稼働コストを分ける

DR戦略のコストは、構築時の初期コストと平常運用中の稼働コストを分けて考えます。

初期コストには、IaC整備、デプロイパイプライン、データレプリケーション設計、トラフィックルーティング、DR 手順、テスト、アプリケーション改修などが含まれます。

稼働コストには、スタンバイコンピューティング、データベース、ストレージ、レプリケーション、クロスリージョンデータ転送、監視などが含まれます。

アクティブ/アクティブではアプリケーションやデータアーキテクチャ自体の変更が必要になる場合があり、初期コストと稼働コストの双方が高くなりやすくなります。

15. 3 戦略のコスト傾向

これは絶対的な金額ではなく、一般的な相対傾向です。

16. 戦略ごとに災害時の復旧運用が違う

復旧運用が少ないほど短いRTOを狙いやすい一方、平常時のリソースと運用の複雑さは増えやすくなります。

17. 制御プレーン運用への依存も選択基準

AWSでは、高いレジリエンスを求める復旧運用について、可能な限りデータプレーン運用を利用し、復旧時の制御プレーン依存を減らすことが推奨されています。

リソース作成、設定変更、スケールなどを災害後に大量実行するほど制御プレーンへの依存が増えます。

パイロットライトは不足リソースのデプロイ / スケール、ウォームスタンバイは主にスケールが必要です。アクティブ/アクティブは必要な本番インフラストラクチャを平常時から動かすことで、復旧時のプロビジョニング依存を減らせます。

18. サービスクォータとキャパシティも事前に確認する

災害時にスケールする設計でも、復旧リージョンで必要なキャパシティを確保できなければRTOを満たせません。

スケール可能なアーキテクチャ
≠
必要時にキャパシティを必ず確保できる

サービスクォータ、EC2 キャパシティなどを事前に評価し、必要に応じてキャパシティ予約等も検討します。

19. パイロットライトを選びやすい要件

リージョン障害へ対応し、データ損失は小さくしたい一方、数十分程度の復旧を許容し、復旧時のデプロイ / スケールを許容して稼働コストを抑えたい場合はパイロットライトが有力です。

決定打は復旧時の追加デプロイを許容できることと低い稼働コストを重視することです。

20. ウォームスタンバイを選びやすい要件

RTOが数分程度で、災害直後から復旧リージョンで一部トラフィックを処理したい一方、完全本番キャパシティを複数リージョンで常時維持するコストまでは許容しない場合はウォームスタンバイが有力です。

決定打はスタンバイがすでに完全に機能していることと、復旧時の主操作がスケールアップであることです。

21. マルチサイト アクティブ/アクティブを選びやすい要件

ミッションクリティカルでリージョン障害時の停止をほぼ避け、通常時から複数リージョンを利用し、高い稼働コストと運用の複雑さを許容できる場合はマルチサイト アクティブ/アクティブが候補になります。

決定打は複数リージョンが平常時から本番トラフィックを処理することです。

22. 「最も強いDR戦略」を選ぶ試験ではない

例えばRTO 45分で、稼働コストを可能な限り抑え、復旧時の自動デプロイを許容する要件にマルチサイト アクティブ/アクティブを選べば、技術的には復旧目標を満たせてもコスト / 複雑さが過剰になる可能性があります。

SAP-C02では、要件を満たす中で最も合理的なアーキテクチャを選びます。

最短RTO、最小RPO、最大冗長性を無条件で選びません。

23. 3 戦略を比較する

RTO / RPOは個々のアーキテクチャの保証値ではなく、代表的な傾向として判断します。

24. 代表シナリオ

ある注文システムに、リージョン障害へ対応、RPO数秒以内、RTO 5分以内、復旧リージョンは平常時でも少量トラフィックを処理可能、完全本番キャパシティを2リージョンで常時維持するコストは避けたい、という要件があります。

短いRPO
→ データを継続レプリケーション

RTO 5分
→ 災害後の大規模デプロイは避けたい

少量トラフィックを即時処理可能
→ 復旧リージョンは完全に機能している必要

完全キャパシティ常時稼働は不要
→ アクティブ/アクティブまでは不要

この場合、ウォームスタンバイが要件に最も合います。

25. 混同ポイント

26. SAP-C02判断フロー

DR要件
        ↓
RTO / RPO
        ↓
復旧リージョンは
平常時にトラフィックを処理する必要がある？
        │
        ├─ いいえ
        │   ↓
        │  復旧時にデプロイ / 開始を許容？
        │   ↓
        │  パイロットライト
        │
        └─ はい
            ↓
      縮小キャパシティでよい？
            │
            ├─ はい → ウォームスタンバイ
            │
            └─ いいえ
                ↓
      複数リージョンを平常時から
      本番として使う？
                ↓
      マルチサイト アクティブ/アクティブ

最後にコスト / 複雑さ / 復旧運用 /
キャパシティ / データアーキテクチャを確認

27. まとめ

3つのDR戦略の違いを決める最も重要な問いは、復旧リージョンが平常時にどこまで準備完了かです。

パイロットライト
→ コア / データは準備完了
→ アプリケーションは追加操作が必要

ウォームスタンバイ
→ 完全スタックが準備完了
→ 縮小キャパシティ
→ 復旧時は主にスケール

マルチサイト アクティブ/アクティブ
→ 複数リージョンが本番準備完了
→ 平常時からトラフィック処理

そのうえでRTO、RPO、初期コスト、稼働コスト、復旧運用、運用の複雑さを比較します。

最も強い戦略ではなく、ビジネス要件を必要十分に満たす戦略を選ぶことが判断軸です。

28. 主要AWS公式資料

DR戦略パターンを確認するための主要なAWS公式資料を以下に示します。

• SAP-C02 ドメイン 1 / タスク 1.3 — AWS Certification
• AWS Well-Architected — 定義済みの復旧戦略を使用して復旧目標を満たす
• AWS上のワークロードの災害復旧 — クラウドでの災害復旧オプション
• AWS上のワークロードの災害復旧 — ビジネス継続性計画