RTO (Recovery Time Objective) と RPO (Recovery Point Objective) は ディザスタリカバリ戦略の核心指標 です。この 2 つが DR パターンの選択、コスト、アーキテクチャをすべて決定づけます。本記事では RTO/RPO の本質と実践設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

RTO と RPO の定義

指標	略称	定義	意味
Recovery Time Objective	RTO	目標復旧時間	障害から復旧までの許容時間
Recovery Point Objective	RPO	目標復旧時点	復旧時に失っても良いデータの期間

SAA レベル：基礎概念

RTO と RPO の核心区別は 「時間」か「データ」か です。

RTO = 復旧にかける時間（「何分で復旧するか」）
RPO = 失うデータの量（「何時間前のデータまで復旧するか」） SAA ではこの 2 つの定義と違いが必ず問われます。

RTO/RPO の視覚的理解

タイムライン:
  過去 ──────────────── 障害発生 ────── 復旧完了 ── 未来
                          │                │
                          │←── RTO ──→│
                          │
              ←── RPO ──→│
              (この期間のデータは失われる可能性)

RTO が短い: 復旧が速い → ビジネス影響小
RPO が短い: データロスが少ない → データインパクト小

SAA 試験のポイント

RTO と RPO は 「ビジネス要件から決定し、技術要件ではない」 ことが重要です。「このアプリは 1 時間以上停止すると重大損失 → RTO = 1 時間」のように、ビジネスインパクトから逆算して設定します。SAA で頻出の考え方です。

RTO/RPO と DR パターンの対応

DR 4 パターンは RTO/RPO の許容値で選択します。

パターン	RTO	RPO	コスト
バックアップ & 復元	時間単位	時間単位	最低
パイロットライト	分〜十分	分	低
ウォームスタンバイ	分	秒	中
マルチサイト	リアルタイム	ほぼ 0	最高

SAA 頻出

「RTO/RPO が短いほどコストが高い」 は SAA の核心原則です。要件定義で「RTO 5 分、RPO 0」を設定すると、事実上マルチサイト一択になり高コスト。「RTO 1 時間、RPO 1 時間」ならバックアップ & 復元で低成本実現。この対応が頻出します。

SAP レベル：高度な設計シナリオ

RTO/RPO の要件定義プロセス

SAP では ビジネス要件から RTO/RPO を導出するプロセス を設計します。

SAP レベル：高度な設計シナリオ

SAP の RTO/RPO 設計プロセスは 「ビジネスインパクト評価 → 許容停止時間 → 許容データロス → RTO/RPO 設定 → DR パターン選択」 の流れです。ビジネス部門と合意の上で設定し、技術で実現可能かを確認する双方向プロセスが重要です。

1. ビジネスインパクト評価
   → 課金システム: 停止 1 時間で 1000 万円の損失
2. 許容停止時間の決定
   → 課金: 最大 15 分 (RTO = 15 分)
3. 許容データロスの決定
   → 課金: 注文データは 1 件も失いたくない (RPO = 0)
4. DR パターン選択
   → マルチサイト (アクティブ・アクティブ)

BIA (Business Impact Analysis)

ビジネスインパクト分析 (BIA) で各アプリの重要度を評価します。

評価項目	説明	設計論点
収益影響	停止による直接損失	課金アプリは高
コンプライアンス	規制違反リスク	金融・医療は高
ブランド影響	顧客信頼低下	公共面向は高
連鎖影響	他システムへの波及	依存システムは高

BIA の分類

BIA でアプリを Tier 1〜4 等に分類し、Tier 別に RTO/RPO を設定するのが SAP 定石です。

Tier 1 (ミッションクリティカル): RTO 分、RPO ほぼ 0
Tier 2 (業務クリティカル): RTO 時間、RPO 分
Tier 3 (一般): RTO 数時間、RPO 時間
Tier 4 (非クリティカル): RTO 日、RPO 日

RTO/RPO とコストの定量化

SAP では RTO/RPO の短縮に伴うコスト増を定量化 します。

RTO/RPO 設定	必要な DR パターン	概算コスト倍率
RTO 日、RPO 日	バックアップ & 復元	1.05x
RTO 時間、RPO 時間	バックアップ + IaC	1.1x
RTO 時間、RPO 分	パイロットライト	1.3x
RTO 分、RPO 秒	ウォームスタンバイ	1.5x
RTO 秒、RPO 0	マルチサイト	2.0x+

過剰 RTO/RPO 設定の罠

「全アプリ RTO 0、RPO 0」を設定するとコストが 2 倍以上に なります。 SAP では「Tier 別に段階設定」し、ミッションクリティカルだけ最高レベル、一般アプリは適正レベル、の層別が定石です。

データベースの RPO 実現方式

RPO を実現するための DB レプリケーション方式：

方式	RPO	適用	設計論点
定期バックアップ	時間	バックアップ & 復元	バックアップ頻度で決定
非同期レプリケーション	秒〜分	パイロットライト	Aurora Global DB
準同期レプリケーション	ほぼ 0	高信頼 DR	レイテンシとのトレードオフ
同期レプリケーション	0	Multi-AZ (同一リージョン)	リージョン間は不可

同期レプリケーションの限界

同期レプリケーションは同一リージョン内 (RDS Multi-AZ 等) で RPO=0 を実現 しますが、 リージョン間ではレイテンシが大きすぎて実用的でない です。リージョン間で RPO を最小化するには Aurora Global DB（1 秒未満）等の非同期方式が現実的。この限界を SAP では押さえます。

アプリ層の RTO 実現方式

RTO を実現するためのアプリ復旧方式：

方式	RTO	実装	設計論点
バックアップから復元	時間	AWS Backup	復元時間を含む
AMI / IaC で迅速構築	分	CloudFormation + AMI	事前準備必須
スタンバイ環境のスケール	分	Auto Scaling	常時小規模稼働
DNS 切替のみ	秒	Route 53 + マルチサイト	両サイト常時稼働

RTO 短縮のテクニック

「AMI の事前作成 + CloudFormation」 で RTO を大幅に短縮できます。バックアップから復元するより、AMI から起動する方が圧倒的に速い。 SAP では「バックアップ & 復元」パターンでも AMI 活用で RTO を分単位に短縮する設計が定石です。

DR 訓練と実測 RTO/RPO

設定した RTO/RPO が本当に達成できるかを訓練で検証 します。

訓練項目	目的	頻度
フェイルオーバー訓練	RTO 実測	半年に 1 回
データ復元訓練	RPO 実測	半年に 1 回
DR 設定ドリル	設定漏れ検出	四半期に 1 回
フル DR 訓練	全プロセス検証	年に 1 回

訓練しない RTO/RPO は無意味

「RTO 15 分と設定したが、実測 2 時間かかった」 は典型的な失敗です。訓練せずに設定した RTO/RPO は 目標であって保証ではない。 SAP では定期訓練で実測値を確認し、ギャップがあればアーキテクチャ or 設定を見直します。

コンプライアンスと RTO/RPO

業界規制によって RTO/RPO が要件化 されることがあります。

規制	RTO/RPO 要件	設計論点
PCI DSS	バックアップ復元可能	復元訓練必須
金融規制	営業継続計画	RTO/RPO の文書化
医療 (HIPAA)	データ保護	RPO の厳格化
SOX	財務システム可用性	RTO の保証

コンプライアンス対応の DR

コンプライアンス要件がある場合、RTO/RPO の設定 + 訓練記録 を監査に提示する必要があります。「設定だけでなく実証できること」が問われるため、SAP では訓練記録の保管も重要です。

RTO/RPO の段階的改善

SAP では 段階的に RTO/RPO を改善 する設計も取り入れます。

# 初期段階
RTO: 4 時間、RPO: 4 時間 (バックアップ & 復元)
  ↓ (運用安定化)
RTO: 1 時間、RPO: 1 時間 (IaC + 頻度増)
  ↓ (ビジネス成長)
RTO: 15 分、RPO: 1 分 (パイロットライト)
  ↓ (ミッションクリティカル化)
RTO: 5 分、RPO: ほぼ 0 (マルチサイト)