導入
「災害に備えたシステムを作ってください」とだけ言われても、設計は始められません。プロの設計者がまず聞くのは「止まってよい時間は？」「失ってよいデータは？」という2つの数字です。この数字がDR設計のすべての土台になります。
説明
DR設計は、次の2つの目標値をビジネス側と合意することから始まります。
| 指標 | 意味 | 決まると何が変わるか |
|---|---|---|
| RTO（Recovery Time Objective / 目標復旧時間） | 障害発生から復旧までに許容できる時間 | 復旧の自動化度合い・待機系の温め具合 |
| RPO（Recovery Point Objective / 目標復旧時点） | どの時点のデータまで戻ってよいか＝許容できるデータ損失量 | バックアップ・レプリケーションの頻度 |
RTOとRPOは独立した軸で、それぞれ小さくするほどコストが上がります。「RTOを短くする」ことと「RPOを短くする」ことは、実は要求される技術が違います。
- RTOを短くする → 待機系をどれだけ温めておくか（起動済み・スケール済みにしておくか）
- RPOを短くする → データをどれだけ頻繁に・リアルタイムに複製しておくか
flowchart LR
A["障害発生"] --> B["最後にバックアップ/複製した時点<br/>RPO=ここまで遡る"]
A --> C["復旧完了までの時間<br/>RTO=ここまで待つ"]
B -.時間軸.-> A
A -.時間軸.-> C
実務では「全システムを同じRTO/RPOにする」ことはしません。決済システムはRTO数分・RPOゼロ近くを求める一方、社内向けの日報システムはRTO数時間・RPO数時間でも問題ない、というようにシステムの重要度ごとに個別に目標値を決め、コストを最適配分します。
読んでみよう
SAPの問題文には「顧客はデータの喪失を許容できない」「数分以内に業務を再開する必要がある」のように、RTO/RPOを暗示する表現が埋め込まれています。数字が明示されていなくても、この表現から「RPOをほぼゼロにする戦略が要る」「RTOに数時間の余裕がある」と読み取れるようになると、次のレッスンの4戦略から正解を一意に絞り込めます。