導入
ここまでは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をゼロに近づけるほどコストは跳ね上がるため、「そのシステムに本当に必要な復旧速度は何か」を業務要件から見極めることが設計の出発点になります。
具体例
3つのシステムを、業務要件（RPO/RTO）に見合うDR戦略に振り分けてみましょう。同じ会社でも要求がまったく違います。
| システム | 業務要件 | 選ぶDR戦略 |
|---|---|---|
| 社内向けの技術ブログ | 半日止まっても、昨日時点に戻せれば実害なし | バックアップ＆リストア（最安・低速） |
| 一般向けECサイト | 数分の復旧、直近数分のデータ損失まで許容 | ウォームスタンバイ |
| 銀行の勘定系 | 復旧はほぼ即座、データ損失は一切許されない | マルチサイト・アクティブ/アクティブ（最速・最高コスト） |
ここで大事なのがトレードオフの見極め。銀行の要件をブログに適用すれば、たいして重要でない読み物のために2リージョンのフル本番を常時動かす莫大な無駄になります。逆にECサイトに「バックアップ＆リストア」を選べば、復旧に数時間かかり売上機会を失う。「業務要件が求めるRPO/RTOに、ちょうど見合う戦略」を選ぶのが正解です。問題文の「数分以内に復旧」「データ損失は許容できない」といった数値・言葉が、戦略選択の手がかりになります。
読んでみよう
問題文にRPO・RTOの具体的な数値（「数分以内に復旧」「データ損失は許容できない」など）が出てきたら、その厳しさに見合う戦略を4段階の表から選びます。「コストを最小限に」とあれば軽い戦略、「復旧はほぼ即座に」とあればアクティブ/アクティブ、という対応関係を押さえましょう。