RPO/RTOと災害復旧の設計判断

災害復旧は「目標値」から逆算する

災害復旧（DR: Disaster Recovery）の設計は、方式から入ると必ず迷子になります。「バックアップを取る」「レプリケーションを張る」「待機系を建てる」——どれも手段であって目的ではありません。正しい順序は逆で、まず二つの目標値を決め、そこから許される方式を逆算します。

**RPO（Recovery Point Objective）**は許容できるデータ損失量です。「障害時に何秒ぶん／何分ぶんの書き込みまで失ってよいか」を時間で表します。RPO=0 なら一件も失えない、RPO=5分 なら直近5分ぶんの喪失は許す、という意味です。**RTO（Recovery Time Objective）**は許容できる復旧時間です。「障害発生からサービス再開まで何分／何時間かけてよいか」を表します。

この二つは別物で、別々のメカニズムに支配されます。混同が最も多い誤りなので、まずここを峻別します。RPO は「過去のどこまで戻るか」、RTO は「未来のどこで戻るか」。RPO はデータの鮮度、RTO は復旧の速さの問題です。

            障害発生(t=0)
過去 ←───────┼───────→ 未来
   │RPO     │      RTO│
   最後に守れた   サービス再開
   データ地点    した時点

RPO = 0 − (最後に保全されたデータの時刻)   … データ損失量
RTO = (再開時刻) − 0                        … 停止時間

RPO を決めるのは「レプリケーションの同期性」

RPO の大きさは、データを複製する仕組みの同期性でほぼ決まります。

• 定期バックアップ：1日1回／1時間ごとにスナップショットを取る方式。RPO はバックアップ間隔に等しく、最悪「次のバックアップ直前に落ちる」と1間隔ぶん全部失います。安いが RPO は大きい。
• 非同期レプリケーション：書き込みをローカルで即コミットし、背後で複製先へ流す。RPO は**障害時のレプリケーション遅延（lag）**ぶん。低レイテンシだが未転送分を失う。
• 同期レプリケーション：複製先へ届いて確認が返るまでコミット完了とみなさない。RPO はゼロに近づくが、毎回の書き込みに複製先までの往復（RTT）が上乗せされる。

ここで原理の肝は、RPO を厳しくするほど書き込みパスのレイテンシが上がるという直接のトレードオフです。同期レプリケーションで RPO=0 を狙うと、書き込みごとに複製先までの RTT がコミット時間に乗ります。同一データセンタ内のレプリカなら1ミリ秒未満で済みますが、別リージョンへ同期で複製すると書き込みごとに数十〜100ミリ秒級の遅延が乗り、スループットも往復で律速されます。だから「RPO=0 を全データに要求する」のは、たいてい過剰でコストに見合いません。

RTO を決めるのは「待機系をどこまで暖めておくか」

RTO は、障害検知のあとどれだけ速くサービスを立ち上げ直せるかで決まります。これを支配するのが待機系（standby）の準備度合いで、四段階のモデルで整理できます。RTO とコストはこの段階で逆相関します。

段階の本質は「復旧の瞬間に、どこまでの作業が残っているか」です。バックアップのみの方式は、障害時にインフラのプロビジョニング・OS/ミドルウェアの構成・データのリストアという長い手順がまるごと残るため RTO が最も長い。pilot light は名前のとおり「種火」——データだけは複製で生かし続け（消えると復旧不能なため）、計算層は止めておく。復旧時はアプリ層を起動してスケールさせる作業が残ります。warm standby は縮小版の本番が動いているので、残るのは容量のスケールアップだけ。hot standby はフル容量が既に動いており、トラフィックを向け直すだけなので RTO が最短です。

RTO ≈ 検知時間
    + インフラ起動/プロビジョニング   ← cold で最大、hot でゼロ
    + データのリストア/同期追いつき   ← バックアップ方式で最大
    + アプリ層の起動・暖機・スケール   ← pilot light/warm で残る
    + トラフィック切替の収束           ← DNS/経路の収束（全方式共通）

重要なのは、RTO 短縮は連続的な課金ではなく「方式の段差」で効くという点です。cold から hot へ近づけるほど、本番容量に近い資源を常時遊ばせることになり、コストは段階的に跳ね上がります。トラフィック切替そのものの収束（DNS の TTL キャッシュ滞留や経路再収束）は別の支配要因で、active-passive と active-active の選択を含め/devops/multi-region-failover/ で詳述しています。

費用対効果：どこで方式を止めるか

DR の方式選択は、突き詰めれば期待損失と防御コストの釣り合いです。原理はシンプルで、ある方式へ投資する価値は「その方式が防ぐ損失の期待値」が「その方式の年間コスト」を上回るかで決まります。

ある方式が正当化される条件:
  防げる損失の期待値  ＞  方式の年間コスト

  防げる損失の期待値 ≈ 障害の年間発生確率
                       × 1回あたりのダウンタイム損失
                       × （現状RTO − 改善後RTO の短縮分の価値）

ここから二つの実務原則が出ます。第一に、RPO/RTO をゼロへ近づけるほどコストは発散する。RPO=0（同期複製）はレイテンシ税を恒常的に払い、RTO=0（hot standby）は本番容量を二重に持ち続けます。一方で多くの業務データは「数分の損失」「数十分の停止」が事業的に許容できます。だから全データを最高ティアで守るのは、ほぼ常に過剰投資です。

第二に、目標値はデータとサービスのティアごとに階層化するのが鉄則です。決済元帳のように一件の損失も許されないデータは RPO≈0・hot standby、レポート用の集計データは日次バックアップで十分、といった具合に、ビジネス影響度（売上・法規制・信用）でティアを切り、ティアごとに方式を変えます。

設計を成立させる実務原則

目標値と方式を結びつけても、運用が伴わなければ DR は機能しません。

• 準同期（semi-synchronous）で中間点を取る：純粋な同期/非同期の二択ではなく「少なくとも1レプリカへ届いたらコミット」とすれば、RPO をほぼゼロに保ちつつ全レプリカ同期ほどレイテンシを払わずに済みます。書き込みごとに同期/非同期を選べる構成も同じ発想です。
• フェイルオーバは冪等に：切替の最中は再送・重複が必ず起き、リストアや複製の追いつき処理が同じ操作を二度適用しうる。受け側を冪等にしておかないと、復旧そのものがデータを壊します（/devops/idempotency-exactly-once/）。
• バックアップは「復元できて初めてバックアップ」：取得の成功は復元の成功を意味しません。リストア手順とバックアップの整合性を定期的に実地で検証する。
• DR 訓練（game day）を定例化する：使われない復旧手順は壊れています。実際に切り替えてみて初めて、リストア時間・暖機時間・複製の追いつきが目標 RTO/RPO に収まるかが分かります。エラーバジェットの範囲で計画的に行います（/devops/sre-slo/）。

まとめ

• DR は方式からでなく目標値から逆算する。RPO（許容データ損失）と RTO（許容復旧時間）は別物で、別々のメカニズムが支配する。
• RPO はレプリケーションの同期性が決める。定期バックアップ＝間隔ぶん、非同期＝障害時 lag ぶん、同期＝ほぼゼロ（代わりに書き込みごとの RTT を払う）。
• RTO は待機系の暖機度が決める。cold（バックアップのみ）→ pilot light → warm standby → hot standby の順に短くなり、常時稼働させる資源量に比例してコストが増える。短縮は連続課金ではなく方式の段差で効く。
• 費用対効果は「防げる損失の期待値 が 方式の年間コストを上回るか」で判断し、全データに RPO=0/RTO=0 を求めない。ビジネス影響度でティア分けする。
• RPO と RTO は独立レバーなので非対称に組み合わせる（例：同期複製＋pilot light）。冪等なフェイルオーバ、復元検証、定例 DR 訓練が運用を成立させる。