導入
ここまではAZレベルの障害への備えでした。では「リージョンごと使えなくなったら」という、さらに大きな災害にはどう備えるべきでしょうか。ここで登場するのが RPO・RTO という2つの指標と、4つのDR戦略です。
説明
災害対策（DR: Disaster Recovery）を語るには、まず目標値を数値で決める必要があります。
- RPO（Recovery Point Objective・目標復旧時点）：どこまでのデータ損失を許容できるか。「直近◯分のデータは失ってもよい」という基準
- RTO（Recovery Time Objective・目標復旧時間）：障害発生からどれくらいの時間でサービスを復旧させるか
flowchart LR
D["障害発生"] -->|"RPO＝許容できるデータ損失の幅"| B["最後のバックアップ時点"]
D -->|"RTO＝復旧までにかけてよい時間"| R["サービス復旧完了"]
RPO・RTOをどれだけ短くしたいかによって、コストと構成が変わる 4つのDR戦略 があります。
| 戦略 | 概要 | RTO/RPO | コスト |
|---|---|---|---|
| バックアップ＆リストア（Backup & Restore） | 定期バックアップのみ保持し、障害時に一から復元 | 遅い（数時間〜） | 最も低い |
| パイロットライト（Pilot Light） | DB等の中核だけ常時起動、他は最小構成で待機し障害時にスケールアップ | 中程度（十〜数十分） | 低い |
| ウォームスタンバイ（Warm Standby） | 縮小版のフルシステムを常時稼働させ、障害時にスケールアウト | 速い（数分） | 中程度 |
| マルチサイト・アクティブ/アクティブ | 複数リージョンでフル規模の本番環境を同時稼働 | ほぼゼロ | 最も高い |
flowchart LR
A["Backup & Restore<br/>低コスト・低速"] --> B["Pilot Light"] --> C["Warm Standby"] --> D["Active-Active<br/>高コスト・高速"]
コストと復旧速度はトレードオフです。RPO/RTOをゼロに近づけるほどコストは跳ね上がるため、「そのシステムに本当に必要な復旧速度は何か」を業務要件から見極めることが設計の出発点になります。
読んでみよう
問題文にRPO・RTOの具体的な数値（「数分以内に復旧」「データ損失は許容できない」など）が出てきたら、その厳しさに見合う戦略を4段階の表から選びます。「コストを最小限に」とあれば軽い戦略、「復旧はほぼ即座に」とあればアクティブ/アクティブ、という対応関係を押さえましょう。