前回との接続とこの講義の役割
前回のS-08では、キャッシュとCDNで速さと負荷を両取りする仕組みを見ました。今回は運用の備えの中でも最も重い、データを失う、あるいは止まるという事態への準備です。L-10で「バックアップを取る」ことは学びましたが、取るだけでは設計になりません。いつの時点まで戻せて、どれくらいの時間で復旧するのか。その目標を決めるのが、この講義の役割です。
このスライドのポイント
- 前回S-08: キャッシュとCDNで速さと負荷を両取りする仕組み
- 今回: データを失う・止まるという最悪の事態への備え
- L-10で「バックアップを取る」ことは学んだが、取るだけでは設計にならない
RPOとRTOの定義
まず用語を定義します。RPOは目標復旧時点と訳し、失ってよいデータの範囲を指します。最後のバックアップからの時間で表し、たとえば日次バックアップなら、最大で24時間ぶんのデータを失う覚悟という意味になります。RTOは目標復旧時間と訳し、止まってから復旧し終えるまでの目標時間を指します。L-10で学んだ「バックアップを取る」に、このRPOとRTOという2つの目標値を与えて初めて、設計と呼べる状態になります。これはM-06で学んだ、非機能要件は測れる形にするという原則の実践です。
このスライドのポイント
- RPO（目標復旧時点）＝失ってよいデータの範囲。最後のバックアップからの時間で表す（日次なら最大24時間ぶん失う）
- RTO（目標復旧時間）＝止まってから復旧し終えるまでの目標時間
- L-10の「バックアップを取る」に、この2つの目標値を与えて初めて設計になる
- M-06の「非機能要件は測れる形にする」原則の実践
なぜRPOとRTOが必要か
この2つを決めないと何が起きるでしょうか。「バックアップはあります」という言葉だけで安心してしまい、いざ障害が起きたときに問題が発覚します。ひとつは、気づけば昨日までのデータしか残っていない、というRPOを検討していなかった失敗です。もうひとつは、復元に三日かかってしまう、というRTOを検討せず、手順も練習していなかった失敗です。取れていることと戻せることは別だ、と繰り返し確認してください。
このスライドのポイント
- 「バックアップはあります」だけで安心すると、障害時に問題が発覚する
- RPO未検討: 気づけば昨日までのデータしか残っていない
- RTO未検討・手順未練習: 復元に三日かかる
- 取れていることと戻せることは別
RPOとRTOで決まる構造
構造を時間軸の図で捉えます。左に最後のバックアップの時点、中央に障害発生、右に復旧完了、と一本の線に並べます。最後のバックアップから障害発生までの幅がRPO、障害発生から復旧完了までの幅がRTOです。この2つの目標値が決まると、バックアップをどれくらいの頻度で取るか、どんな手段で復旧するかが、逆算で決まります。目標が先、手段は後、という順序が大切です。
このスライドのポイント
- 時間軸の一本線: 最後のバックアップ ←RPO→ 障害発生 ←RTO→ 復旧完了
- 最後のバックアップから障害発生までの幅がRPO
- 障害発生から復旧完了までの幅がRTO
- 2つの目標値が決まると、バックアップの頻度と復旧手段が逆算で決まる
経費アプリでの設計例
経費アプリで具体的に設計してみます。RPOは1時間と決めます。月末の申請を失うわけにはいかない、という業務要件がM章から来ているためです。これを満たすには、1時間ごとの自動バックアップが要ります。マネージドなデータベース、R-02で学んだ借りる形なら、多くは設定ひとつで実現できます。RTOは4時間と決め、これを満たすために復元手順書を用意し、年2回の復元練習を行います。練習していない復旧手順は無いのと同じ、だからです。
このスライドのポイント
- RPO=1時間（月末の申請を失えない＝業務要件M章から）→ 1時間ごとの自動バックアップ
- 手段: マネージドDB（R-02の借りる形）なら多くは設定ひとつ
- RTO=4時間 → 復元手順書＋年2回の復元練習
- 練習していない復旧手順は無いのと同じ
技術サンプル: RPO/RTO記入例と復元練習チェックリスト
サンプルは、RPOとRTOの記入例と、復元練習のチェックリストを表にまとめました。数値だけを決めて満足せず、それを満たす手段と、実際に戻せることの確認までを一組にするのが狙いです。読み方の要点は2つです。まず、RPOとRTOそれぞれに、根拠となる業務要件と、逆算される手段が紐づいている点です。次に、チェックリストが「取ったか」ではなく「戻せたか」を問うている点です。AIには、業務要件からRPOとRTOを提案させ、それを満たすバックアップ設定と復旧手順書まで作らせるとよいでしょう。
このスライドのポイント
- 種別: table
- 目的: RPO/RTOの目標値と、それを満たす手段・戻せることの確認を一組にする
- サンプル本体:
混同しやすい概念: バックアップがある vs 復旧できる
混同しやすいのは、バックアップがあることと、復旧できることの違いです。前者はデータが取れている状態、後者は実際に戻せて、しかも手順を練習済みの状態を指します。この2つは別物です。L-10で「復元手順を試したことがあるか」と予告しましたが、この講義がその正式版にあたります。バックアップの存在は出発点にすぎず、戻せることの確認までいって初めて、備えが完成します。
バイブコーディングでの確認点
運用での確認点です。半期に1回、ステージング環境、R-07で学んだ本番そっくりの練習場に、バックアップから実際に復元してみる練習を組み込みます。これをS-01で作った運用の定期作業リストに追加してください。本番を触らずに復元を試せるのが、ステージングの価値です。AIには「この復元手順を、ステージングで試せる形の手順書にしてください」と頼むとよいでしょう。
このスライドのポイント
- 半期に1回、ステージング（R-07）にバックアップから実際に復元してみる練習を組み込む
- S-01で作った運用の定期作業リストへ追加する
- 本番を触らずに復元を試せるのがステージングの価値
- AIへの質問例: 「この復元手順を、ステージングで試せる形の手順書にしてください」
まとめと次回への橋渡し
最後に一問一答です。失ってよいデータの範囲を表す目標値は何でしょうか。……答えはRPOです。復旧までの時間の目標はRTO、と対で覚えてください。30秒まとめです。バックアップは取るだけでは設計になりません。RPOとRTOという2つの目標値を与え、逆算で頻度と手段を決め、そして復元練習で戻せることを確かめる。ここまでが備えです。次回はカテゴリS最終回、費用の構造を扱います。関連資料は「バックアップと復旧入門」「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答: 失ってよいデータの範囲を表す目標値は？ → RPO（復旧までの時間の目標はRTO）
- 30秒まとめ: バックアップは取るだけでは設計にならない。RPO/RTOを与え、逆算で頻度と手段を決め、復元練習で戻せることを確かめる
- 次回: カテゴリS最終回、費用の構造（固定費・従量課金）へ
- 関連資料: 「バックアップと復旧入門」「アプリ運用チェックリスト」
