RTO・RPO・SLOとは？目標値の決め方を基本設計の視点で整理する#

1. RTO・RPO・SLOの目標値って、何を根拠に決めるの？#

基本設計で非機能要件を整理していると、RTO・RPO・SLOという言葉が出てくる。

用語の定義は調べればわかる。でも実際に設計を進めようとすると、別の疑問が出てきた。

RTOは何分以内に設定すればよいのか？
データ損失は基本的に許容できないのに、RPOを決める必要があるのか？
目標値は業務側と設計者のどちらが決めるのか？

調べていくと、これらは技術的な性能だけでは決められないことがわかった。

この記事では、3つの用語の違いから、目標値を決める根拠、基本設計への落とし込み方までまとめていく。

2. RTO・RPO・SLOの違い#

まずは、それぞれが何を表すのかを整理する。

用語	意味	考えること
RTO	Recovery Time Objective（目標復旧時間）	障害発生後、どれくらいの時間で復旧する必要があるか
RPO	Recovery Point Objective（目標復旧時点）	障害発生後、どの時点までのデータを復旧できる必要があるか
SLO	Service Level Objective（サービスレベル目標）	サービスの品質をどの水準で提供するか

例えば、データベースを利用する業務システムで障害が発生した場合を考えると：

RTO： 30分以内に業務を再開できる状態にする
RPO： 障害発生時点から5分前までのデータを復旧できるようにする
SLO： 通常時のリクエストの99%が1秒以内に応答する

これらの数値は説明用の例で、一般的に推奨される基準値ではない。

RTOとRPOは障害からの復旧に関する目標、SLOはサービス品質に関する目標。SLOでは、応答時間だけでなく、可用性やエラー率なども指標にできる。

3. 目標値って誰が決めるの？#

ここで疑問になったのが、目標値を誰が決めるかという点。

結論からいうと、組織によって役割分担は異なるが、設計者が技術的な都合だけで業務上の許容範囲を決めるのはNG。

基本的な役割はこんな感じ。

役割	主な役割
業務側・業務責任者	停止やデータ損失が業務に与える影響、許容できる範囲を整理する
設計者・SE	要求を実現する方式、実現可能性、費用、技術的なリスクを整理する
プロジェクト・システム責任者	業務上の要求と費用・リスクを踏まえ、必要な合意や承認を行う

例えば、業務側から「障害が発生しても業務を継続したい」と言われたとする。

この要求だけでは、RTOを5分にすべきか、30分にすべきかは決まらない。停止中に代替手段を使えるのか、締め切りまでに処理を終える必要があるのか、といった条件を確認する必要がある。

設計者がやるべきは、業務側が判断できる材料を整理して、実現方法とその影響を提示すること。

4. 目標値を決める根拠は何か？#

RTOを決める材料#

RTOを考えるときは、次の点を確認する。

業務が停止すると、どのような影響が発生するか
何分・何時間までなら代替手段で業務を継続できるか
業務上の締め切りや再開期限はあるか
短時間で復旧するために、どの程度の費用をかけられるか

あと注意したいのが、RTOはデータベースの起動時間だけを指すわけじゃない。

障害検知 → 原因の切り分け → 復旧作業 → 動作確認 → 業務再開

この全体にかかる時間を考える必要がある。

RPOを決める材料#

RPOでは、データ損失の影響を確認する。

失われると業務に重大な影響があるデータは何か
データを再取得・再作成できるか
失われたデータを再入力・再処理できるか
法令、契約、監査などの制約があるか

「データ損失は許容できない」という要求も当然ある。ただし、すべてのデータについて、どの障害でも一切失われないことを保証するには、対応する構成や費用、検証が必要になってくる。

RPOを0に設定することと、実際にデータ損失を防げることは同じじゃない。目標を実現できる方式かどうかを、設計と復旧テストで確認する必要がある。

SLOを決める材料#

SLOでは、利用者が重要と考えるサービス品質を指標化する。

例えば、画面の応答速度を対象にするなら、「3秒以内」という数値だけでは条件が不足している。

どの画面・操作を対象にするか
通常時とピーク時のどちらを対象にするか
何件のリクエストが条件を満たせばよいか
どの期間で測定するか

指標と測定条件が曖昧なままだと、目標を達成できているか判断できない。

5. 業務側も目標値を決められない場合は？#

実際のプロジェクトでは、業務側も具体的な数値を決められないことがある。

「RTOは何分ですか？」といきなり聞いても、回答に困るケースはわりとある。

そういう場合は、質問を分解するのが有効。

システムが停止した場合、業務にどのような影響があるか
代替手段で業務を継続できるか
いつまでに業務を再開する必要があるか
データが失われた場合、再作成や再処理が可能か
より短時間で復旧するために、どの程度の費用を許容できるか

回答をもとに複数の構成案を用意して、それぞれの復旧時間、データ損失の可能性、費用、運用負荷を比較する。

目標値を決めるための情報が足りない場合は、数字を仮置きして終わらせるんじゃなくて、判断に必要な情報を明らかにすることが重要。

6. 基本設計では何を決めるのか？#

目標値が決まったら、実現するための方式と検証方法を設計に落とし込む。

項目	基本設計で検討すること
RTO	バックアップ、待機系、復旧手順、切り替え方式、復旧後の確認
RPO	バックアップ間隔、ログ保管、レプリケーション、復旧可能な時点
SLO	測定対象、指標、目標値、測定条件、監視方法

注意したいのは、目標値と実現方式を混同しないこと。

例えば「RTOは30分」と決めても、その構成で本当に30分以内に復旧できるとは限らない。障害を想定した復旧テストを行って、手順を含めて目標を達成できるか確認する必要がある。

7. PostgreSQLでバックアップと復元を試してみた#

RTOとRPOの考え方を理解するため、ローカルのPostgreSQL 18.6でバックアップと復元を試してみた。

実験内容#

実験用データベースに3件のデータを登録する
pg_dump でバックアップを取得する
バックアップ後に2件のデータを追加する
別のデータベースへ pg_restore で復元する
復元されたデータ件数を確認する

バックアップと復元には、PostgreSQL公式ツールの pg_dump と pg_restore を使用。復元先のデータベースを分けることで、元データを変更せずに比較できるようにしている。

実測結果#

項目	結果
バックアップ取得時間	約0.246秒
バックアップファイルサイズ	2,488バイト
`pg_restore` の実行時間	約0.193秒
バックアップ時点のデータ件数	3件
バックアップ後に追加したデータ	2件
復元後のデータ件数	3件