メインコンテンツまでスキップ

DR（Disaster Recovery）

「サーバーが1台落ちた」は障害対応で復旧できます。では「リージョン全体が使えなくなった」「DB のデータが壊れた」ときは？

このセクションでは、障害対応の範囲を超えた大規模障害からの復旧を学びます。

障害対応と DR の違い​

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  障害対応（Incident Response）:                              │
│  ├── アプリが1台落ちた → 再起動、スケールアウト              │
│  ├── DB が遅い → スロークエリ対応、フェイルオーバー          │
│  ├── リリースで壊れた → ロールバック                        │
│  └── 既存のインフラ内で復旧できる                           │
│                                                             │
│  DR（Disaster Recovery）:                                   │
│  ├── リージョン全体が使えない → 別リージョンに切り替え       │
│  ├── DB のデータが壊れた → バックアップから復元              │
│  ├── データセンターが物理的に被災 → 遠隔地で復旧            │
│  └── 既存のインフラ自体が使えない状況からの復旧             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

なぜ学ぶのか​

「うちのデータセンター（リージョン）が使えなくなることなんてあるの？」

  過去の大規模障害の例:
  ・クラウドプロバイダーのリージョン障害（数時間〜半日）
  ・認証基盤の全リージョン障害（全ユーザー影響）
  ・データセンターの電源障害、ネットワーク障害
  ・自然災害（地震、洪水、台風）によるデータセンター被災

  → リージョン / データセンター障害は
    「起きるかどうか」ではなく「いつ起きるか」

基盤サービス（認証、決済等）が復旧できないと:
  → 全ユーザーがサービスを利用できない
  → 依存する他のサービスも連鎖的に停止
  → 復旧に数時間かかると、ビジネス影響は甚大

オンプレミスとクラウドで何が変わるか​

DR の目的（データを守り、サービスを復旧する）は同じですが、手段とコスト構造が大きく異なります。

観点オンプレミスクラウド
物理障害自分で部品交換・調達プロバイダーが対応。AZ 冗長で自動復旧
DR サイト遠隔地にハードウェアを購入・設置別リージョンを API で構築
復旧時間数日〜数週間（機材調達含む）数分〜数時間（事前準備次第）
コスト構造初期投資が大きい（ハードウェア + DC 契約）従量課金（Pilot Light なら停止中はほぼ無料）
データ同期自前でレプリケーション構築マネージドサービス（Global Database 等）
テストDR サイトの維持コストが高くテストしにくい一時的に DR 環境を起動してテスト可能
オンプレの DR:
  本番 DC (東京) ──── 専用線 ──── DR DC (大阪)
  ├── ハードウェア購入・設置         ├── 同等ハードウェアが待機
  ├── OS / ミドルウェアの構築         ├── 同じ構成を維持
  └── データのレプリケーション構築    └── 定期的に同期

  → コスト: 数千万〜数億円（DC 契約 + ハードウェア + 回線）
  → 維持: DR サイトの陳腐化防止が課題

クラウドの DR:
  Primary Region ──── マネージドレプリケーション ──── DR Region
  ├── API / IaC で構築                              ├── 最小構成 or 停止
  ├── マネージド DB レプリケーション                  ├── 自動同期
  └── 必要なときだけ DR 環境を起動                   └── 使った分だけ課金

  → コスト: Primary の 35〜100% 増（戦略次第）
  → 維持: IaC で Primary と DR を同じコードで管理

このセクションのドキュメントはクラウド環境を前提に書いていますが、RPO/RTO の設計や DR 戦略の考え方はオンプレミスでも共通です。

学習の流れ​

┌─────────────────────────────────────────────────────────────┐
│                    学習ロードマップ                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  基礎                                                       │
│  ├── RPO / RTO の設計                                       │
│  │   └── どこまでデータを失っていいか、何分で復旧するか     │
│  └── DR 戦略の選択                                          │
│      └── コストと復旧速度のトレードオフ                     │
│                                                             │
│  実践                                                       │
│  ├── マルチリージョン構成                                   │
│  │   └── Active-Passive / Active-Active の設計              │
│  ├── バックアップと復元                                     │
│  │   └── 何を、どこに、どの頻度でバックアップするか         │
│  └── フェイルオーバー手順                                   │
│      └── 切り替えの判断基準、手順、テスト                   │
│                                                             │
│  訓練                                                       │
│  └── DR テスト（Game Day）                                  │
│      └── 本当に復旧できるか定期的に検証                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

ドキュメント一覧​

基礎​

#ドキュメント説明
01RPO/RTO と DR 戦略復旧目標の設計、4つの DR 戦略の比較

実践​

#ドキュメント説明
02マルチリージョン構成Active-Passive / Active-Active の設計パターン
03バックアップと復元何を・どこに・どの頻度でバックアップするか
04フェイルオーバー手順切り替えの判断基準と手順

AWS 実践​

#ドキュメント説明
06AWS での DR 構成Aurora Global Database、Route 53、ECS の具体的な構成とコスト

訓練​

#ドキュメント説明
05DR テスト（Game Day）本当に復旧できるか定期的に検証する方法

関連ドキュメント​

障害対応​

インフラ​