Azure Managed Service Column ＜Azure運用コラム＞RPO(目標復旧時点)とは？RTOとの違いやAzureで目標達成する3ステップを解説

RPOを達成する具体的なAzureの構成

近年は業務のクラウド移行や BCP （ Business Continuity Plan ）対策の強化を背景に、 RPO （ Recovery Point Objective ）の短縮が求められる場面が増えています。 RPO は障害時に過去の「どの時点まで」のデータを復旧させるかの目標値であり、 RTO （ Recovery Time Objective ）と並んでシステムのバックアップやサービス維持の観点で重要な指標です。

本記事では RPO と RTO の違いから、 Azure を活用した RPO の要件を満たす構成パターン、段階的な導入ステップまでを体系的に解説します。

1. RPOとは

RPO （ Recovery Point Objective ） は、障害時に過去の「どの時点まで」データを復旧させるかを設定した目標値です。

例えば、 RPO を 1 時間に設定した場合「障害発生直前から最大で 1 時間分のデータが失われることを許容する」という意味になります。

事前に RPO を設定すると、システム設計におけるバックアップの取得頻度やレプリケーション構成、保存期間の設計方針を決定するための重要な判断基準となります。

RPOとRTOの違い

RPO は「障害発生時にどの時点のデータまで復旧するか」を示す指標ですが、 RTO （ Recovery Time Objective ）は「障害発生からシステムを復旧させるまでに許容される時間」を示します。つまり RTO は、システムがどの程度止まっても問題ないとするのか上限を定める指標になります。

どちらもシステム設計時の指標として重要です。

RPOが重視される背景

近年、人的ミスや自然災害に加え、サイバー攻撃などによるシステム障害のリスクも高まっています。システム障害は自社の機会損失や社会的信頼の失墜に直結するため、障害は必ず起こるという前提で、あらかじめ備えておく設計が重要です。

その備えの中で、失われるデータ量を最小限に抑えるための目安となる RPO は、復旧戦略の中核的な指標と位置づけられています。とくに、RPOの最小化は、復旧時の影響を抑えるうえで重要な判断基準となります。

業務の重要度に応じたRPO設定の考え方

RPO は業務の重要度やデータ更新頻度を基に、現実的な目標を設定することが重要です。

基幹業務や顧客情報を扱う業務は、データ損失が重大な影響を及ぼすため、できる限り短い RPO が求められます。一方で、非クリティカルな業務では数時間〜 1 日程度の RPO で許容されるケースもあります。

たとえば、銀行の送金システムのように高い信頼性が求められる業務では、RPOを 0 秒に近づける必要があります。一方、動画配信サービスのコメント機能なら数時間程度でも業務上の影響は限定的と考えるなど、業務の重要度や性質に応じて設計します。

2. AzureでRPOを実現できる構成の設計ステップ

Azure で RPO を実現できる構成を設計するには、以下の 3 つのステップで進めると効果的です。

ステップ1：RPO目標の設定と対象業務の整理

まず、自社システムに求められる可用性水準を踏まえ、業務ごとの RPO を設定します。

すべての業務に対して RPO をゼロに近づけることは、コストや運用負荷の面から非現実的です。業務の重要度やデータの更新頻度、他システムとの依存関係などを基に、現実的かつ実効性のある目標値を設定する必要があります。

例として、基幹系業務には数分以内の RPO を設定し、文書管理や開発支援などの補助業務には RPO を 1 日程度に設定するなど、用途に応じて保護レベルを使い分けます。

ステップ2：バックアップ取得タイミングやデータ同期の設計

業務ごとの RPO 目標に基づき、どのデータを、どのタイミング・頻度で取得、同期するかを設計します。

取得対象となるサーバーやストレージの選定に加え、バックアップ取得時間帯も考慮します。バックアップ取得自体もシステムに負荷がかかることから、取得タイミングは業務に影響が少ない時間帯に設定することが望ましいです。

RPO を短く設定している業務の場合、バックアップだけでなく、常時データを複製するリアルタイム同期の設計も必要となります。実現には、ストレージの書き込み性能やネットワーク帯域に負荷がかかるため、十分な性能の環境を確保しておくことが重要です。

ステップ3：Azureサービスの適用と検証の実施

設計した内容を基に Azure 上でサービスの導入・設定を行い、 RPO が達成できるか検証します。 Azure Backup や Azure Site Recovery は、導入直後にバックアップやレプリケーションを実行可能です。しかし、障害時に想定どおり復旧できるかを事前にテストすることが不可欠です。

テスト結果をもとに改良、修正を行い、最終的に RPO を実現するシステム構成を確立します。

3. RPO目標に応じたAzure機能の活用パターン

RPO の設定値に応じて、 Azure で活用できる機能例を解説します。どのようなサービスを組み合わせ、構成をすれば RPO を実現できるのか、目標値ごとに解説します。

RPOが1日：Azure Backupによる定期バックアップ

業務データの更新頻度が低く、 1 日 1 回のバックアップで問題ない業務の場合、 Azure Backup による定期バックアップが有効です。

Azure Backup は、オンプレミスのシステムや Azure 上の仮想マシンを対象に、バックアップを自動化できるサービスです。毎日1回、業務影響が少ない深夜や早朝にもバックアップを取得する設定ができます。

バックアップデータは Azure の Recovery Services コンテナーに保管され、地理冗長構成をとることで災害時のリスクにも対応可能です。

RPOが数時間：Azure Backup による高頻度バックアップ

業務データの更新が数時間おきに発生する場合、 Azure Backup の高頻度バックアップ機能が有効です。

Azure VM Backup では、仮想マシン全体のバックアップを最短 4 時間間隔で自動取得できます。一方、 Azure Disk Backup はマネージドディスク単位での保護に対応しており、 より柔軟なバックアップスケジュールを設計可能です。

両サービスとも差分バックアップを採用しており、ストレージコストを抑えつつ迅速なリカバリを実現できます。

RPOが数分以内：Azure Site Recoveryによる冗長構成

Azure Site Recovery（ ASR ）は、オンプレミスや Azure 上の仮想マシンを別リージョンへ非同期でレプリケートし、障害発生時に自動でフェイルオーバーを実行できるサービスです。構成によっては、最短30秒〜数分程度のRPOに対応でき、業務の継続性を高いレベルで確保できます。高可用性が求められるシステムのバックアップ構成や災害対策に有効です。

4. まとめ

RPO は「どの時点のデータまで復旧するか」を示す指標です。「復旧までに要する時間」を示す指標である RTO と同様に、システム設計時のバックアップや冗長性を検討する上で必要となります。

RPO は対象となる業務やシステムの重要性によって異なり、目標値によって Azure 上で利用すべきサービスも異なるため、業務特性に応じた RPO と適切な構成を検討しましょう。

なお、クラウド設計やバックアップ戦略に不安がある場合は、 Rworks へご相談ください。要件整理から設計・運用支援まで、業務特性に応じた最適な構成をご提案します。

Microsoft Azureを利用したシステムの設計・構築を代行します。お客様のご要件を実現する構成をご提案・実装いたします。

Tag： RPO

• 

  Azure AI Foundryとは？その機能や活用方法を解説

• 

  冗長化とは？構成パターンやAzureでの実現方法をわかりやすく解説