← 概念辨析に戻る

Concept Contrast Fable

目標復旧時間と目標復旧時点

先に結論:RTO が問うのは「障害発生後どれだけで正常に戻るか」、RPO が問うのは「どれだけの時間のデータ損失を許容するか」だ。RTO は何台のマシンを用意するか、ホットスタンバイが必要かを決め、RPO はどれくらいの頻度でバックアップするか、増分でよいかリアルタイム同期が必須かを決める。顧客が二つの目標を同じ「復旧要件」として提示してきたら、あなたのアーキテクチャコストは五倍違うかもしれない。

RTO が問うのは「障害発生後どれだけで正常に戻るか」、RPO が問うのは「どれだけの時間のデータ損失を許容するか」だ。RTO は何台のマシンを用意するか、ホットスタンバイが必要かを決め、RPO はどれくらいの頻度でバックアップするか、増分でよいかリアルタイム同期が必須かを決める。顧客が二つの目標を同じ「復旧要件」として提示してきたら、あなたのアーキテクチャコストは五倍違うかもしれない。

寓話

消防隊と公文書館

銭荘は帳場の火災を恐れ、店主は二つのことを尋ねた。帳場頭は一見似ている二つの事柄を管理している。一つはどれだけ早く再開して収受できるか、もう一つは最大どれだけ前の帳簿を失ってよいか。新しい使用人は面倒くさがり、二冊の帳簿を一冊にまとめ、どうせどちらも成否に関係すると考えた。

最初は誰も反対しなかった。番頭は二つの問いを「バックアップは良好」にまとめ、鉄箱を買えば安心し、店主はページ数が減ったのを見て手間が省けたと褒めた。しかし繁忙期になると、古い帳簿は突然説明がつかなくなった。前の山が終わっていないのか、後の山が守られなかったのか、誰も答えられなかった。

彼らはまずより多くの印とスローガンを補い、各人にもっと詳しく書くよう求めた。結果、冊子は厚くなり、争いは増えた。事が起きたとき、誰もが自分をかばう一言を見つけられたが、どちらを先に救うべきかは誰も分からなかった。

老管事は皆を庭に呼び集め、実際の経過に沿って歩き直させた。目の前の動作に関心のあるものは第一冊に、後続の負担に関心のあるものは第二冊に入れた。二冊は互いに参照し合うが、もはや同じページに混ざることはない。

火災の後、鉄箱は三日前の帳簿を守ったが、カウンターは半日では組み立てられず、昨日の取引も取り戻せなかった。分けて考えると、多くの古い結論が変わった。忙しそうに見えても実は問題を防いでいない仕事もあれば、普段は目立たなくても災害時に全体を守る備えもある。

新人が再び混同しないよう、老管事は彼らにそれぞれ小さな案件を処理させた。二冊の帳簿がそれぞれ自分の問題に答えられ、かつ境界で互いに接続できたときだけ、その小さな案件は合格となる。もし誰かが依然として二つの事柄を一ページに書くなら、現場に戻って誰が先に動き、誰が最後に責任を負うかをもう一度見なければならない。はっきり見えないときは、一度多く問い合わせるほうがましで、曖昧な帳簿を一夜越しにしてはならない。本当に事故が起きる日には、一行の区別が欠けるだけで一隊の人が無駄に忙しくなるからだ。

店主は別々に規則を定めた。カウンターは一炷香のうちに臨時に開けられるようにし、帳簿は半時ごとに隣へ写しを取る。後に新人が入ると、老管事はただ一言だけ覚えさせた。素早く復旧することと、古い帳簿を失わないことは、二つの別の尺度である。

目標復旧時間

システムまたはサービスが中断状態から正常な動作状態に復旧するまでに許容できる最大時間。これは「どれだけ待てるか」を定義し、災害対策アーキテクチャでコールドスタンバイ、ウォームスタンバイ、ホットスタンバイのどれを選ぶかを決める。

復旧時点目標

障害後にシステムが許容できる最大のデータ損失ウィンドウで、通常は時間単位で表される。何を「どれだけ失ってよいか」を定義し、バックアップ頻度を決める——毎時バックアップ、リアルタイム同期、それとも日次バックアップか。

物語の対応

  • 消防隊が現場に到着するまでの時間:RTO——障害対応速度を測る。
  • アーカイブのバックアップ間隔:RPO——データ損失の上限を測る指標。
  • 4時間で復旧したが2時間分のデータを失った:RTOは達成したがRPOが定義されておらず、災害復旧の効果は大幅に低下した。
  • ホットスタンバイサーバーでRTOを1時間に短縮:復旧時間短縮に必要な技術投資。
  • 準リアルタイム同期に切り替えて RPO を5分に圧縮する:データ損失ウィンドウを短縮するために必要な技術的投資。

プロジェクトに落とし込む

災害対策要件を受けたら、RTO と RPO を二つの独立したパラメータに分けて顧客に尋ねる。同じシステムでもモジュールごとに異なる RTO/RPO があり得る。決済モジュールの RPO はゼロ損失を要求し、レポートモジュールの RPO は一日を許容できるかもしれない。分けておけば、アーキテクトは差異化した設計ができ、最も厳しい一つの数字で全モジュールを覆って全体コストが制御不能になるのを避けられる。

京ICP备2026014272号