導入
「災害に備えたシステムを作ってください」とだけ言われても、設計は始められません。プロの設計者がまず聞くのは「止まってよい時間は？」「失ってよいデータは？」という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数時間でも問題ない、というようにシステムの重要度ごとに個別に目標値を決め、コストを最適配分します。
具体例
問題文には数字が明示されず、表現からRTO/RPOを読み取らせるのがSAPの常。ある企業の2システムで練習しましょう。
- 決済システム：問題文「顧客の取引データは一切失えず、障害時は数分で業務を再開する必要がある」。→ RPOはほぼゼロ（データを頻繁・リアルタイムに複製）、RTOは数分（待機系を温めておく）。厳しい＝高コストな戦略が要る。
- 社内の勤怠システム：問題文「復旧は翌営業日までにできればよく、前日分のデータが残っていれば十分」。→ RTOは数時間〜1日、RPOは1日。緩い＝安い戦略でよい。
ここで大事なのが、RTOとRPOは別の技術で縮めること。RTOを縮めるには「待機系をどれだけ起動・スケール済みにしておくか」、RPOを縮めるには「データをどれだけ頻繁に複製するか」。両者を混同せず、しかもシステムの重要度ごとに個別の目標値を置いてコストを配分するのがプロの設計。次のレッスンの4戦略は、この2数字から一意に選べます。
読んでみよう
SAPの問題文には「顧客はデータの喪失を許容できない」「数分以内に業務を再開する必要がある」のように、RTO/RPOを暗示する表現が埋め込まれています。数字が明示されていなくても、この表現から「RPOをほぼゼロにする戦略が要る」「RTOに数時間の余裕がある」と読み取れるようになると、次のレッスンの4戦略から正解を一意に絞り込めます。