RTO、RPO、復旧ティアの定義

事業継続計画（BCP）とは、災害の発生中および発生後も重要な業務機能を継続できるようにするプロセスです。クラウドコンピューティングでは、許容できる時間とデータ損失の範囲内で障害から復旧できるシステムを設計することを意味します。2つの重要な指標であるRTOとRPOによって、各ワークロードで「許容できる範囲」が定義されます。

目標復旧時間（RTO）とは、災害発生後にシステムがオフラインになっていても許容される最長時間です。これは、「このアプリケーションが停止している状態を、業務上どれくらいの時間まで許容できるか」という問いに答えるものです。RTOは時間（時間、分、秒）で表します。決済処理システムのRTOが15分である一方、社内の人事ポータルのRTOは24時間という場合があります。

目標復旧時点（RPO）とは、時間で測定した場合に許容されるデータ損失量の最大値です。これは、「業務上、どれだけのデータ損失まで許容できるか」という問いに答えるものです。RPOが1時間の場合、最大1時間分のトランザクションを失うことを許容します。RPOによって、データのバックアップまたはレプリケーションを実行する頻度が決まります。RPOが0の場合は同期レプリケーションが必要となるため、コストが高く、書き込みパフォーマンスに影響する可能性があります。

RTOとRPOを混同しないことが重要です。

• RTOは時間に関する指標です — システムがどれだけの時間停止するかを示します
• RPOはデータに関する指標です — どれだけのデータが失われるかを示します

短いRTO（迅速な復旧）と長いRPO（大きなデータ損失を許容）を組み合わせることも、その逆も可能です。理想は両方を短くすることですが、そのためにはレプリケーションやウォームスタンバイ容量への大きな投資が必要です。

すべてのワークロードの重要度が同じとは限りません。一般的には、業務への影響に基づいてワークロードを復旧ティアに分類します。

• ティア1（ミッションクリティカル） — 厳格なRTO/RPO、最も高いコスト（例：決済、取引プラットフォーム）
• ティア2（ビジネスクリティカル） — 中程度のRTO/RPO（例：CRM、ERP）
• ティア3（非クリティカル） — 緩やかなRTO/RPO、最も低いコスト（例：開発環境、アーカイブ）

復旧ティアごとに、対応するAzureの機能が異なります。

• ティア1 — Cosmos DBのマルチリージョン書き込み、SQLの自動フェイルオーバーグループ、アクティブ-アクティブアーキテクチャ、Traffic Manager
• ティア2 — セカンダリリージョンへのAzure Site Recovery、SQLのgeoレプリケーション（読み取りレプリカ）、30日間保持する日次バックアップ
• ティア3 — 週次スケジュールのAzure Backup、レプリケーションなし、スナップショットからの復元

RTOの短いアーキテクチャへの投資を正当化するには、ワークロードのダウンタイムコストを計算します。これには、失われる収益、顧客に対するSLA違反のペナルティ、スタッフの生産性低下、評判の低下が含まれます。1時間のダウンタイムのコストが500,000ドルであれば、アクティブ-アクティブ構成に月額50,000ドルを費やすことは容易に正当化できます。これらの数値を使用して、適切な復旧ティアのビジネスケースを作成します。

Azure Site Recovery（ASR）は、Azureでティア2のRTO/RPO目標を達成するための主要なサービスです。ASRはVMをセカンダリリージョンに継続的にレプリケートし、数分以内にフェイルオーバーを開始できます。Azure VMのレプリケーション頻度は、30秒ごと（クラッシュ整合性）または1～4時間ごと（アプリケーション整合性）であり、構成に応じて通常はその範囲のRPOになります。

RPOを時間単位で測定するワークロードでは、適切なスケジュールを設定したAzure Backupで十分です。たとえば、RPOが4時間の場合、少なくとも4時間間隔でバックアップする必要があります。Azure Backupでは、Azure VMを対象に1時間ごとのバックアップスケジュールを設定できる拡張ポリシーがサポートされています。データベースでは、トランザクションログバックアップを使用したポイントインタイムリストア（PITR）により、ASRより低コストで1時間未満のRPOを実現できます。

RTOとRPOの目標は、ビジネスインパクト分析（BIA）に正式に文書化し、技術担当者と業務担当者の双方で確認する必要があります。BIAでは、各アプリケーションを復旧ティアに対応付け、RTO/RPO目標を文書化し、その目標を達成するAzureサービスを特定するとともに、テストスケジュール（訓練によってDR計画を検証する頻度）を指定します。

RTOとRPOの目標は、DRテストによって検証されるまでは、達成したい目標にすぎません。DRテストでは、実際の復旧時間（定めたRTOを満たしているか）と、復旧時点での実際のデータ損失（定めたRPOを満たしているか）を測定します。テストで差異が明らかになった場合は、目標を安定して達成できるまでアーキテクチャまたは手順を更新します。コンプライアンス監査に備えて、テスト結果を文書化します。

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認しましょう。

このレッスンでは、RTOが許容される最大ダウンタイム、RPOが時間で測定した許容される最大データ損失を表すこと、ワークロードが特定のAzureサービスに対応する復旧ティアに分類されること、そしてRTO/RPO目標を達成可能か検証するにはテストが不可欠であることを学びました。次は、Azure Site Recoveryを使用した復旧計画と自動フェイルオーバーについて学びます。