RTOを理解する

RTOは「復元APIにかかった時間」ではなく、業務の停止をどれだけ短くするかの目標です。検知から確認までを分解し、時間を計算して改善箇所を見つけます。

この単元で学ぶこと

1. 完了条件を定義する EC2が起動した時刻を復旧完了とすると、DB接続やログインがまだできない時間を見落とします。必要な業務が利用可能となる条件を先に定義します。例えば「注文入力が成功し、保存結果を確認できる」です。RTOはこの業務回復までの許容停止時間として使います。

2. 直列工程の計算検知5分、切替判断5分、データ復元15分、業務確認5分が順に必要なら合計30分です。RTOが20分なら10分超過です。復元を高速化するだけでなく、検知や判断待ちが長い場合も改善対象になります。開始時刻と各工程の終了を記録して根拠を持たせます。

3. 並列工程の計算検知・判断に5分、その後にネットワーク準備10分とデータ復元20分を並行実行し、両方の完了後に業務確認5分なら、合計は5＋20＋5＝30分です。並行工程をすべて足して40分とはしません。実際に並行できるか、依存関係がないかを確認する必要があります。

4. 自動化の効果確認済みの手順をコード化して実行すれば、担当者の手入力や順序間違いを減らせます。ただし誤った条件で自動切替すると正常系を止める恐れがあります。切替開始の判断、実行処理、結果の確認を分け、承認が必要な業務でも実行部分は自動化する等の設計が可能です。

5. 平常時の準備鍵や証明書の手配、DNSや通信設定、復旧先クォータの不足が本番事故で初めて見つかると時間を失います。依存先を棚卸しし、必要資源を事前に置く方法を比較します。ウォームスタンバイ等は準備時間を減らせますが、常時費用と運用対象が増えることも評価します。

6. 障害時の作成依存災害時に大量資源の新規作成や設定変更を必須にすると、制御APIの利用可能性や容量調達へ依存します。事前配置された資源で切替できるほどその依存を減らせます。短いRTOにどれだけ常時容量が必要か、通常時の費用とのトレードオフとして決めます。

7. データ目標との違い毎分バックアップを取得していても、復元に2時間かかればRTO10分は達成できません。取得頻度を増やすのは主に失われるデータの範囲へ作用し、復旧時間短縮とは同一ではありません。逆に5分でアプリを起動しても古いデータしかなければRPO側の問題が残ります。

8. 継続的な測定前回の訓練が20分でも、データが倍に増えた後も同じとは限りません。実データ量に近い条件で再試験し、ピーク時の性能まで確かめます。RTOは平均だけでなくばらつきや手順の失敗も踏まえて評価し、手順変更の後には実績を更新します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。