RTO
読み: アールティーオー
RTOとは復旧目標時間の設計
RTOはRecovery Time Objectiveの略で、障害が発生してからシステムを復旧させるまでの目標時間を指す。BCP策定やクラウドDR設計における基本指標であり、RPOと対になって災害復旧計画の骨格を形成する。RTOが短いほど高い可用性が求められ、その分コストも上がる。
かんたんに言うと
システムが止まったとき「何時間以内に復旧させるか」という目標値である。この数字がBCP全体の設計を左右する。
業務停止を最小化するRTOの時間軸の考え方
システム障害には2つの時間軸がある。「どこまでのデータを救えるか」と「いつまでに復旧するか」である。
前者がRPO、後者がRTOとなる。RPOが「データの巻き戻し限界」なら、RTOは「業務停止の許容時間」と言い換えられる。
ECサイトが1時間止まれば、その間の売上は全て消える。社内の経費精算システムが半日止まっても、業務への影響は限定的である。同じ「システム障害」でも、ビジネスへのインパクトは全く異なる。だからこそ、システムごとにRTOを設定する必要がある。
ここを曖昧にしたまま「とにかく早く復旧してくれ」と言うのは、設計者に白紙委任状を渡すようなものである。
RPOとの違いと両指標の関係性
RTOとRPOは混同されやすいが、性質が異なる。
RPOはデータの損失許容量を時間で表す。RPOが4時間なら、4時間前の状態までデータを巻き戻せればよい。つまり「最大4時間分のデータは失われる可能性がある」という合意である。
RTOは復旧完了までの制限時間を表す。RTOが2時間なら、障害発生から2時間以内にシステムを使える状態に戻す必要がある。
両者は独立した指標だが、設計上は連動する。RPOを短くするにはバックアップの頻度を上げなければならず、RTOを短くするにはフェイルオーバーの仕組みが要る。どちらも短縮すればするほどインフラコストが膨らむため、ビジネス要件とのバランスが欠かせない。
BCP策定での位置づけと目標値の決め方
RTOの設定は技術部門だけで決められるものではない。
経営判断が必要になる。「基幹システムが24時間止まった場合の損失額はいくらか」「顧客への影響はどの程度か」「レピュテーションリスクはどうか」。これらを踏まえて、許容できる停止時間を経営層が承認する。
実務的には、システムをティア分けするのが一般的である。ティア1は基幹業務システムでRTO4時間以内。ティア2は業務補助システムでRTO24時間以内。ティア3は開発環境や社内ツールでRTO72時間以内、といった具合に分類する。
全てのシステムにRTO1時間を設定すれば安心かもしれないが、その費用を負担できる企業は限られる。優先順位をつけることがBCP設計の出発点となる。
<a href="/ai-glossary/cloud/">クラウド</a>DR設計とRTOの実現手法
クラウド環境でのDR設計は、RTOの目標値によって構成が大きく変わる。
RTO数分を目指すなら、マルチリージョンのアクティブ-アクティブ構成が必要となる。常に2つ以上のリージョンで同じシステムを稼働させ、片方が落ちても即座に切り替わる。コストは単純計算で2倍以上になる。
RTO数時間であれば、パイロットライト方式が現実的な選択肢である。平常時はDRサイトに最小限のインフラだけを維持し、障害発生時にスケールアップして本番環境を復元する。AWSのCloudFormationやTerraformでインフラをコード化しておけば、復元作業の大半を自動化できる。
RTO24時間以上なら、バックアップからの復元で対応可能なケースが多い。S3のクロスリージョンレプリケーションでデータを複製し、障害時に新しいインスタンスを立ち上げてリストアする。
いずれの手法でも、年に1回はDR訓練を実施して復旧手順を検証することが欠かせない。計画上はRTO4時間でも、訓練してみたら8時間かかったという話は珍しくない。
AI基盤におけるRTO設計の特殊性
AI推論APIのRTO設計には、従来のシステムとは異なる考慮点がある。
まず、GPUインスタンスの調達に時間がかかる。CPUサーバーなら数分で起動するが、GPUインスタンスはリージョンや時間帯によっては在庫切れでプロビジョニングに失敗する。RTOを短くしたければ、DRリージョンにもGPUインスタンスを確保しておく必要があり、コスト面の負担は大きい。
モデルファイルのサイズも問題となる。数十GBのモデルをS3からダウンロードしてメモリにロードするだけで数十分かかることがある。事前にDRサイトのストレージにモデルを配置しておくか、コンテナイメージに含めておくかの設計判断が求められる。
こうした特殊性を踏まえたうえで、AI基盤のRTOは従来システムより長めに設定されることが多い。RTOを短くする技術的な手段はあるが、コスト対効果の見極めが必要になる。
当社の見解
当社はAIの安全運用のために3層防御を設計・実装している。万が一インシデントが発生しても数分以内に復旧できるバックアップ体制を持つ。実際にAIが暴走してテスト環境を停止させた経験があり、その教訓から「失敗を防ぐ」だけでなく「失敗しても戻せる」設計が本質だと確信している。加えて、AIは事実でないことを断定する。この前提で事実/推測の強制分離とファクトチェックを実装した。安全性は仕組みで担保するものだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。