RTO5分を成立させるまでの長い話

「このシステムのRTOは5分です」

要件定義書にそう書かれていると、かなり具体的に見えます。

5分以内にサーバーを再起動する。あるいは、待機系へ切り替える。

そのための構成を用意すれば、達成できそうにも思えます。

でも、RTO 5分の 「5分」 に入るのは、機械を動かす時間だけでしょうか。

障害に気づく。
影響を判断する。
切り替える。
データを確認する。
アプリケーションを確認する。
そして、業務を再開する。

5分という短い数字を成立させるためには、その裏側に長い設計と運用の話があります。

今回は、RTOとRPOを用語として覚えるのではなく、数字の裏側にある約束として見ていきたいと思います。

RTOとRPOは、何を約束する数字なのか

まず、言葉の意味を簡単に整理しましょう。

• RTO（Recovery Time Objective）
  障害が発生したあと、どのくらいの時間で業務を再開したいか

• RPO（Recovery Point Objective）
  障害が発生したとき、どの程度のデータ損失まで許容するか

業務の言葉に置き換えると、もう少しわかりやすくなります。

• RTO：業務が待てる時間
• RPO：失ってよいデータ量

つまり、RTO/RPOはシステムの速さを競う数字ではありません。

業務として、

• どのくらいの停止時間まで許容できるか
• どこまでのデータ損失なら受け入れられるか

を決めるための数字です。

ここまでは比較的シンプルですが、難しいのはその数字を実際の設計として成立させるところです。

「5分で復旧」の復旧とは、どこまでなのか

「止めないシステム」は、結局なにを守る設計なのか？で触れたように、システムが起動したことと、業務を再開できることは同じではありません。

RTO 5分と聞くと、サーバーやデータベースが起動するまでの時間を想像しがちです。
しかし、障害発生から業務再開までを並べると、次のようになります。

サーバーやデータベースが起動するのは、この流れの途中です。

仮に待機系への切替が2分で終わったとしても、

• アプリケーションから接続できない
• データの整合性を確認できない
• 外部システムとの連携状態がわからない
• 利用者が正常に操作できるかわからない

という状態であれば、業務はまだ復旧していません。

RTO 5分を決める前に、まず決めなければならないことがあります。

何ができたら、復旧完了とするのか。

ここが曖昧なままでは、同じ「5分」でも、関係者ごとに違うものを想像してしまいます。

障害に気づくまでの時間も、5分に入る

RTOを考えるとき、切替処理や再起動にかかる時間だけを見てしまうことがあります。
しかし、障害発生から測るのであれば、検知や判断の時間も5分に含まれます。

たとえば、次のような流れを考えてみます。
なお、RTOの起点や終点は、契約や要件定義によって異なる場合があります。本記事では、障害発生から業務再開までを例に考えます。

工程	所要時間
障害の検知	2分
影響確認と切替判断	1分
待機系への切替	1分
アプリケーション確認	1分
合計	5分

これで、余裕はありません。

障害の検知に4分かかったら、残りは1分です。

しかも、実際の障害では、すべての工程が予定どおり進むとは限りません。

• 夜間や休日には誰が判断するのか
• 担当者に連絡がつかなかったらどうするか
• 自動切替が誤作動しないか
• 切替後に別の異常が見つかったらどうするか
• 復旧したように見えて、データに問題があったらどうするか

このどこか1工程が想定より1分延びるだけで、RTOは達成できなくなります。

つまり、RTOを短くするには、機器を増やすだけでは足りないということになります。
監視、連絡、判断、自動化、手順、訓練まで含めて、5分の中に収める必要があります。

5分を成立させるのは、構成だけではない

可用性設計というと、冗長化や待機系の構成に目が向きます。
もちろん、それらは重要ですが、優れた構成を用意しただけで、RTOが自動的に守られるわけではありません。

たとえば、待機系が用意されていても、

• 切替手順を誰も実行したことがない
• 手順書が古い
• アプリケーションの接続先が切り替わらない
• 切替後に必要な確認項目が決まっていない
• 復旧訓練をしていない

という状態では、実際の障害時に5分で再開できるとは限りません。

RTOは、設計図に書かれた数字ではなく、実際の運用で守る数字です。
そのためには、少なくとも次のような準備が必要になります。

• 障害を早く検知する監視
• 迷わず判断するための基準
• 切替や復旧の自動化
• 復旧後の確認項目
• 担当者と連絡経路
• 定期的な復旧訓練
• 訓練結果を反映した手順の更新

短い5分の裏側には、こうした長い準備があります。

RPO 0にも、長い話がある

RTOが停止時間の話なら、RPOはデータ損失の話です。
たとえば、10時10分に障害が起きたとします。

RPOが10分であれば、障害発生前の最大10分間のデータ損失を許容する、という考え方になります。

RPOが5分であれば、障害発生から最大5分前までのデータ損失を許容する、という考え方になります。
ただし、実際にどの時点まで復旧できるかは、データ保護方式や障害の内容によって変わります。

では、RPO 0なら、すべてのデータを1件も失わないという意味になるのでしょうか。

ここでも、数字だけでは意味が決まりません。

RPO 0は「復旧時にデータ損失を許容しない」という目標ですが、実際にはどの範囲をデータとみなすかを決めなければ意味を持ちません。

システムの中には、さまざまな状態のデータがあります。

• データベースへの登録が完了した注文
• アプリケーションが受け付けたが、まだ登録されていない注文
• 外部の決済サービスでは処理済みだが、自システムには反映されていない取引
• バッチ処理の途中にあるデータ
• 画面上では完了に見えるが、裏側では処理中のデータ

どの時点を「確定済み」と考えるかによって、守る対象は変わります。

データベースに保存されたデータを失っていなくても、外部システムとの状態が食い違えば、業務上の問題は残ります。

そのため、RPO 0という数字を置くときも、

• 何のデータを対象にするのか
• どの処理地点を確定とするのか
• 外部システムとの整合性をどう扱うのか
• 処理途中のデータをどう判断するのか

まで考える必要があります。

RPO 0にもまた、数字の裏側に長い設計の話があるのです。

同じ5分でも、業務によって重さが変わる

RTO 5分の難しさは、技術構成だけでは決まりません。
同じ5分でも、対象となる業務によって意味が変わります。

システム	5分停止したときに起きること
社内ポータル	一時的に情報を閲覧できない
ECサイト	注文機会や売上を失う可能性がある
決済システム	処理途中の取引状態を確認する必要がある
製造システム	現場作業や設備に影響する可能性がある

社内ポータルであれば、5分停止しても影響が限定的な場合があります。
一方、決済システムでは、システムを再起動するだけでは業務を再開できません。

• 決済は成功したのか
• 注文は登録されたのか
• 二重処理になっていないか
• ユーザーには何が表示されたのか
• 外部サービスと状態が一致しているか

を確認する必要があります。

この確認に時間がかかれば、機械的な切替が速くてもRTOは短くなりません。
同じ「5分」でも、業務再開までに必要な確認が多いほど、その約束は重くなっていきます。

短い数字ほど、重い約束になる

RTOは5分より1分。
RPOは5分よりゼロ。

数字だけを見ると、小さい方が優れているように見えます。
しかし、数字を短くするほど、求められるものは増えていきます。

• 待機環境をどこまで常時稼働させるか
• データをどの頻度、どの方式で保護するか
• 切替をどこまで自動化するか
• アプリケーションの再接続をどう設計するか
• どこまでの運用負荷とコストを許容するか

RTO/RPOは、必要以上に短い数字を置けば、構成も運用もコストも重くなっていきます。
反対に、業務影響を考えずに長い数字を置けば、本当に守るべきものを守れない可能性があります。

必要なのは、最も小さい数字ではなく、業務に必要で、実際に守れる数字を適切に決めることです。

その5分を決める前に、確認したいこと

RTO/RPOを要件として使うなら、数字を書く前に、少なくとも次のことを確認する必要があります。

何を守るのか

• どの業務が対象なのか
• どのデータが重要なのか
• すべての機能を同時に復旧する必要があるのか
• 一部機能だけ先に再開できないか

どこからどこまで測るのか

• 障害発生から測るのか
• 監視による検知から測るのか
• システム起動までか
• アプリケーションの接続確認までか
• 利用者が業務を再開できるまでか

誰が、どうやって守るのか

• 自動化する工程はどこか
• 人が判断する工程はどこか
• 夜間や休日にも対応できるか
• 復旧後の確認を誰が行うか
• 定期的に復旧テストを行うか

ここまで決めて、RTO/RPOは初めて設計に使える数字になります。

まとめ

RTOは、業務が待てる時間。
RPOは、失ってよいデータ量。

ただし、「RTO 5分」「RPO 0」と数字を書くだけでは、その数字を守れる設計にはなりません。

5分で業務を再開するには、

• すぐに障害へ気づく
• 迷わず切替を判断する
• システムを復旧する
• データの状態を確認する
• アプリケーションを確認する
• 業務再開を判断する

という一連の流れを、構成と運用の両方で準備する必要があります。

RPOについても同じです。
守るデータの範囲や処理地点を決めなければ、数字だけが独り歩きします。

RTOやRPOは、数字を書くことが目的ではありません。

「その数字を、本当に守れるか。」

要件定義では、その問いに答えられる設計と運用まで考えて、初めて数字に意味が生まれます。

RTO 5分は短い数字です。
けれど、その5分を成立させるまでには、長い話があります。