この記事の要点
- RTO・RPO は、ITの担当だけでは決められません。業務への影響と、目標を短くするほど増える費用を並べ、業務の担当と経営が決めます。
- AWS は、バックアップから戻す型から複数のリージョンで同時に動かす型まで、4つの型を示しています。短い目標ほど、仕組みは複雑になり、費用も増えます。
- 訓練は、机上の確認、データを戻す訓練、別の場所への切り替えの訓練と段階を踏み、かかった時間を目標と比べて記録します。
復旧の目標（RTO・RPO）は、システムが止まったときに業務がどれだけ困るかと、目標を短くするための費用を見比べて、業務の担当と経営が決めるものです。決めた目標は、実際に訓練をして、その時間で戻せるかを確かめるまでは「希望」にすぎません。この記事では、クラウドで目標をどう仕組みに落とし、どう訓練するかを説明します。RTO・RPO の意味や、バックアップの取り方そのものは、バックアップと復旧の設計で説明しています。
目標は、誰がどう決めるのか
RTO・RPO は、業務の担当と経営が、ITの担当から示された選択肢と費用をもとに決めます。ITの担当だけで決めると、業務への影響の重さが反映されず、短すぎる目標で費用が膨らんだり、長すぎる目標で取引に影響したりします。
決める場では、次の3つを並べて話し合うと進めやすくなります。
- 止まったときの影響：何時間止まると、受注・出荷・お客様への対応に何が起きるか
- 失うデータの影響：何時間分のデータを失うと、入れ直しや取引先への説明が必要になるか
- 目標ごとの仕組みと費用：目標を短くすると、どの型の仕組みが要り、毎月の費用がどう変わるか
RTO・RPO の考え方は用語集でも説明しています。業務を続けるための計画全体はITのBCPを参考にしてください。
目標に合わせた4つの復旧の型
クラウドでは、目標の長さに合わせて、復旧の仕組みの型を選びます。AWS の災害対策の資料は、費用と複雑さの低いものから順に、4つの型を示しています。
1つ目は、バックアップを取っておき、障害のときに戻す型です。バックアップを取る間隔が、戻せる時点（RPO）を左右します。基盤をコードで作れるようにしておかないと、別のリージョンでの復旧が難しくなり、時間が延びるおそれがあるとされています。2つ目のパイロットライトは、データの複製と中心となる基盤だけを別のリージョンで常に用意しておき、障害のときにアプリのサーバーを起動して広げる型で、ふだんの費用を抑えられます。3つ目のウォームスタンバイは、縮小した規模の環境を別のリージョンで常に動かしておく型で、すぐに一部の処理を受けられ、復旧の時間が短くなります。4つ目のマルチサイト・アクティブ/アクティブは、複数のリージョンで同時に処理を受ける型です。多くの災害で復旧の時間をゼロに近づけられる一方、4つの中で複雑さも費用も大きい型とされています。
出典：Disaster recovery options in the cloud（AWS）
復旧の4つの型（AWS の災害対策の資料。上ほど費用と複雑さが低い）
- バックアップから戻す取る間隔が、戻せる時点（RPO）を左右する
- パイロットライトデータの複製と中心の基盤だけを常に用意。障害のときにアプリのサーバーを起動して広げる
- ウォームスタンバイ縮小した規模の環境を常に動かす。すぐに一部の処理を受けられる
- マルチサイト・アクティブ/アクティブ複数のリージョンで同時に処理を受ける。復旧の時間をゼロに近づけられるが、複雑さも費用も大きい
型はシステムごとに選べます。目標の値は、業務の担当と経営が決めます
型の選び方は、システムごとに変えて構いません。取引に直結するシステムだけを厚くし、社内の資料の置き場はバックアップから戻す型にする、といった分け方が現実的です。リージョンの考え方はリージョンとアベイラビリティゾーンで説明しています。
データの破損は、別に備える
別のリージョンへの複製は、データの破損や削除には効かないことがあります。同じ AWS の資料は、複製によって RPO をゼロに近づけられる型でも、データの破損・削除・改ざんのような災害では、復旧の時間はゼロより長くなり、戻せる時点は問題に気づく前のどこかになる、としています。
出典：Disaster recovery options in the cloud（AWS）
誤った削除やランサムウェアによる暗号化は、複製先にもそのまま伝わることがあります。リージョンの切り替えの仕組みとは別に、過去の時点に戻せるバックアップ、書き換えられない形のバックアップ（イミュータブルバックアップ）を組み合わせます。
訓練の種類
訓練は、いきなり本番を切り替えるのではなく、段階を踏んで進めます。AWS の資料は、復旧の仕組みを試して確かめ、目標を満たせるかを定期的に確かめることを求め、経験として、うまくいく復旧は、くり返し試している手順だけだと述べています。
出典：Testing disaster recovery（AWS）
| 訓練 | 内容 | 確かめること |
|---|---|---|
| 机上の訓練 | 手順書を関係者で読み合わせ、障害の場面を想定して動きを確かめる | 連絡の流れ、判断する人、手順書の抜け |
| データを戻す訓練 | バックアップを検証の環境に戻し、業務のシステムで使えるかを見る | 戻せる時点、戻す時間、手順の正しさ |
| 切り替えの訓練 | 別の場所の環境へ切り替え、処理を受けられるかを見る | 切り替えの時間、つながる先の設定、元に戻す手順 |
| 障害を起こす実験 | 計画した範囲で障害を起こし、システムの反応を見る | 自動の切り替えや、知らせる仕組みが動くか |
切り替えの訓練は、本番に影響しない形で行える仕組みもあります。Azure Site Recovery の「テストフェールオーバー」は、複製を止めずに、本番の環境に影響を与えずに切り替えを試せると説明されています。そのうえで、本番から切り離したネットワークに切り替えることを勧めています。
出典：Run a test failover (disaster recovery drill) to Azure（Microsoft Learn）
障害を起こす実験には、AWS Fault Injection Service のような仕組みがあります。止める条件を決めて実験を進められる一方、実際の資源に実際の操作を行うため、本番で使う前に計画を立て、本番の前の環境で試すことが強く勧められています。
出典：What is AWS Fault Injection Service?（AWS）
訓練で記録し、見直すこと
訓練の価値は、目標と実際の差が分かることにあります。訓練のたびに、次の点を記録に残します。
- 目標の RTO・RPO と、実際にかかった時間・戻せた時点
- 手順書のとおりに進まなかった箇所と、その理由
- 判断に迷った場面と、誰が決めたか
- 次回までに直すことと、その担当と期限
差が大きい場合は、手順を直すか、仕組みの型を見直すか、目標そのものを業務の担当と話し合い直します。システムの構成を大きく変えたときも、訓練をやり直します。障害のときの連絡の流れは障害が起きたときの一次対応で説明しています。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、業務の担当の方と一緒に復旧の目標を決める場の進行、目標に合わせた仕組みの設計と構築、訓練の計画・実施・記録をご支援しています。訓練の結果は、手順書と月次の報告に反映します。復旧の備えの整い具合を第三者の立場で点検したい場合は、システム監査の決まりにもとづいてご相談いただけます。
- クラウド
- RTO・RPO
- 災害対策
- 訓練
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。