RPO/RTO と DR 戦略
README で「リージョン全体が使えなくなった」ときの復旧が DR だと学びました。ではその DR をどう設計するか？
出発点は「どこまでデータを失っていいか」と「何分で復旧するか」の2つの数字です。この2つが決まれば、必要な DR 戦略とコストが決まります。
RPO と RTO
障害発生
│
▼
───┬──────────────────┬──────────────────┬───
│ │ │
│◄── RPO ────────►│◄──── RTO ──────►│
│ (データ損失許容) │ (復旧時間目標) │
│ │ │
最後の 障害 復旧完了
バックアップ 発生
| 指標 | 意味 | 問い | 例 |
|---|---|---|---|
| RPO（Recovery Point Objective） | 失っていいデータの量（時間） | 「何時間前のデータまで戻れればいい？」 | RPO = 1時間 → 最大1時間分のデータを失う |
| RTO（Recovery Time Objective） | 復旧にかけていい時間 | 「何分以内に復旧すればいい？」 | RTO = 30分 → 30分以内にサービス再開 |
サービス種別ごとの目安
| サービス種別 | RPO 目安 | RTO 目安 | 理由 |
|---|---|---|---|
| 認証基盤 | 0〜数秒 | 5〜30分 | 止まると全サービ スが使えない |
| 決済 | 0 | 5〜15分 | データ損失 = 金銭損失 |
| ECサイト | 数分 | 30分〜1時間 | 売上に直結 |
| 社内ツール | 数時間 | 数時間 | 翌営業日に復旧でも許容 |
| バッチ処理 | 24時間 | 24時間 | 再実行可能 |
RPO/RTO とコストの関係
RPO/RTO が厳しいほどコストが高い:
RPO = 24時間, RTO = 数時間
→ 日次バックアップだけで OK → 安い
RPO = 1時間, RTO = 30分
→ 定期バックアップ + Warm Standby → 中程度
RPO = 0, RTO = 数分
→ リアルタイムレプリケーション + Active-Active → 高い
┌──────────────────────────────────────────┐
│ │
│ コスト │
│ ▲ │
│ │ ╱ │
│ │ ╱ │
│ │ ╱ ← 指数関数的に増加 │
│ │ ╱ │
│ │──╱─────────────────────► │
│ RPO/RTO の厳しさ │
│ │
└──────────────────────────────────────────┘
4つの DR 戦略
RPO/RTO の要件に応じて、4つの戦略から選択します。
┌─────────────────────────────────────────────────────────────┐
│ │
│ コスト低 ──────────────────────────────── コスト高 │
│ 復旧遅い ─────────────────────────────── 復旧速い │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Backup & │ │ Pilot │ │ Warm │ │ Multi- │ │
│ │ Restore │ │ Light │ │ Standby │ │ site │ │
│ │ │ │ │ │ │ │ Active │ │
│ │ 数時間 │ │ 数十分 │ │ 数分 │ │ 数秒 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
1. Backup & Restore
通常時:
Primary Region: [ アプリ] → [DB] → バックアップ → [別リージョンの S3]
障害時:
DR Region: バックアップから DB 復元 → アプリ起動 → DNS 切替
RPO: 最後のバックアップ時点（数時間）
RTO: 数時間（復元 + 起動 + 切替）
コスト: 最小（バックアップストレージのみ）
| メリット | デメリット |
|---|---|
| 最もシンプル、低コスト | 復旧に数時間かかる |
| 運用が簡単 | RPO が大きい（バッ クアップ間隔分のデータ損失） |
2. Pilot Light
通常時:
Primary Region: [アプリ] → [DB] ──レプリケーション──→ DR Region: [DB（稼働中）]
[アプリ（停止中）]
障害時:
DR Region: アプリ起動 → DNS 切替
RPO: ほぼ 0（リアルタイムレプリケーション）
RTO: 数十分（アプリ起動 + DNS 切替）
コスト: DB のレプリカ分
| メリット | デメリット |
|---|---|
| RPO がほぼ 0 | アプリ起動に時間がかかる |
| コスト中程度 | 起動確認の運用が必要 |
3. Warm Standby
通常時:
Primary Region: [アプリ ×4] → [DB] ──レプリ──→ DR Region: [アプリ ×1] → [DB]
↑ 最小構成で稼働中
障害時:
DR Region: アプリをスケールアウト（×1 → ×4）→ DNS 切替
RPO: ほぼ 0
RTO: 数分（スケールアウト + DNS 切替）
コスト: DR リージョンの最小構成分
| メリット | デメリット |
|---|---|
| 復旧が速い（数分） | 常時稼働のコスト |
| 切り替え前に動作確認できる | Primary と同じ設定の維持が必要 |
4. Multi-site Active（Active-Active）
通常時:
Region A: [アプリ ×4] → [DB] ←──双方向レプリ──→ [DB] ← [アプリ ×4] :Region B
↑ ↑
通常トラフィック 通常トラフィック
（50%） （50%）
障害時:
Region B: 全トラフィックを受ける（DNS 重み変更）
RPO: 0
RTO: 数秒〜数分（DNS TTL による伝搬時 間を含む）
コスト: 2倍（両リージョンがフル稼働）
| メリット | デメリット |
|---|---|
| 復旧が最速（数秒〜数分） | コスト 2倍 |
| 通常時も負荷分散 | 双方向レプリの複雑さ（コンフリクト対処） |
| DR テストが不要（常時稼働） | データ整合性の設計が難しい |
戦略の選択基準
| 判断軸 | Backup & Restore | Pilot Light | Warm Standby | Multi-site Active |
|---|---|---|---|---|
| RPO | 数時間 | ほぼ 0 | ほぼ 0 | 0 |
| RTO | 数時間 | 数十分 | 数分 | 数秒〜数分 |
| 月額コスト | $ | $$ | $$$ | $$$$ |
| 運用の複雑さ | 低 | 中 | 中 | 高 |
| 適用場面 | 社内ツール、バッチ | 一般的な Web サービス | 重要なサービス | ミッションクリティカル |
認証サービスの場合
認証サービスの要件:
・RPO: 0（ユーザーデータ・トークンの損失は不可）
・RTO: 5〜30分（全サービスが使えなくなるため短く）
・コスト: 抑えたい
→ Pilot Light or Warm Standby が現実的
→ DB はリアルタイムレプリケーション（Global Database 等）
→ アプリは最小構成 or 停止状態で DR リージョンに準備
まとめ
DR 設計の出発点:
1. RPO を決める（何時間分のデータを失っていいか）
2. RTO を決める（何分で復旧するか）
3. コストとトレードオフして戦略を選ぶ
4. 選んだ戦略に必要なインフラを構築
5. 定期的にテスト（→ Game Day）
次のステップ
- マルチリージョン構成: 具体的なインフラ設計