RTOとRPOの違いとは？

今日のデジタル市場において、顧客の期待は飛躍的に高まっています。取引が遅れることや、サービスに求めていた水準とのギャップに対する許容度は非常に低くなっているため、ごくわずかな時間のデジタルダウンタイムであっても、生産性、売上、そして顧客ロイヤルティの低下につながる可能性があります。そのため、堅牢な災害復旧（DR）計画があらゆる組織で必要となります。

災害復旧計画とは、特に重要なアプリケーションやデータが予期せぬ形でアクセス不能となった場合に、その事態からどのように、そしてどの程度短時間で復旧するかを明確にしておくものです。そのような災害復旧計画を策定しておけば、ユーザーが迅速にオンライン復帰できるようにする準備体制を整い、事業への損害を最小限に抑えることが可能となります。

主要復旧目標

DR計画の構成要素の中でも、他よりも重要性の高いパラメーターが2つあります。これら2つは、事業がオフライン状態を許容できる最長時間と、許容できるデータ喪失の最大量を定義します。目標復旧時間（RTO）と目標復旧時点（RPO）がこれらに該当します。

RTOとは、組織がサービス停止またはデータ喪失の発生後に正常な業務を復旧させるためにかかってもよい最大所要時間として設定する目標のことです。
RPOとは、組織が喪失を許容できる最大データ量のことです。このパラメーターは、時間単位で、すなわち、障害発生時点から、直近の有効なデータバックアップ時点までの時間で測定されます。たとえば、現在障害が発生していて、直近のフルデータバックアップが24時間前であった場合、RPOは24時間ということになります。

アプリケーションに応じたRTO/RPOを設定する

会社でデータ生成に使用する各種アプリケーションごとに異なるRTOとRPOを設定することになる可能性が高いことでしょう。アプリケーションがミッションクリティカルなものであるほど、RTOとRPOはより低く（よりゼロに近く）設定すべきです。重要度が低いアプリケーションほど、許容度は高くなります。

自分の組織に適したRTOとRPOを算定するには、事業部門の責任者や上級管理職と話し合って意見を求め、ビジネスを推進し収益の最大化を実現させるアプリケーションおよびシステムを選び出しましょう。それらは稼働を維持する上で最も重要なものであり、低いRTOとRPOを設定しておくべきです。このようなビジネス影響度分析を作成しておけば、重要度レベルに基づいて全システムを階層分けし、階層ごとに適切な復旧目標を設定することができます。

実施：重要度とコストのバランスを取る

RTOとRPOが厳格であればあるほど、それらの達成に必要なコストは上がります。たとえば、低いRPOを設定して会社データのフルバックアップを日次で実行する場合、週次で実行する場合と比べてより多くのストレージとネットワークリソースを消費することになり、費用がつり上がりします。

コストを把握し管理するため、目標とするRTO/RPO値を重要度階層に基づいて決定し、災害復旧戦略の一部として、それらを可能な限り費用対効果の高いやり方で達成する方法を詳しく検討してください。

以下に例を挙げます。

ミッションクリティカルなデータは、どの程度の頻度でバックアップしたらよいでしょうか？プライマリストレージから常時稼働のセカンダリストレージへの継続的データ複製は、高可用性を実現可能な手法の1つです。この構成には、ハイパフォーマンスなストレージシステムと最大ネットワーク帯域幅が必要となるため、高額なものとなる可能性があります。データのフルバックアップを実行したら、その後は増分バックアップの実行を検討してください。これらによって新規と変更後のデータのみをバックアップすれば、バックアップ時間を短縮しつつコストを抑える体制を確保しやすくなります。
バックアップをどこに配置すれば迅速かつ容易にアクセス可能になりますか？クラウドバックアップロケーションにした方が、自社の設備、不動産、電力を使ってセカンダリITスタック全体を構築・維持するよりも、費用が高くならない可能性があります。ただし、データバックアップは、拠点内の別の建物やセカンダリデータセンターのようなオンプレミス環境でも効果的に保管可能です。プライマリデータセンター内に保管することも可能ですが、別室に、または少なくとも別のラックに保管して分散させておく必要があります。なお、こうしたバックアップは、拠点全体に、あるいは都市・地域レベルで影響をもたらす自然災害が発生した場合、地理的に分散した各拠点にデータコピーを保管する手法よりも、その有効性は低いものとなります。

オンプレミスバックアップのセットアップでは、仮想化ストレージクラスターが採用されていることもあります。これは、データベースとファイルサービスを複数のノードに分散しておき、そのノードがそれぞれ、複数のワークロードを同時にバックアップできるようにする手法です。さらに多くの容量が必要となった場合にはノードを追加します。クラスター規模が大きくなるほど、並列での取り込みが可能なデータ量が増すため、バックアップ時間は短縮されます。これらのシステムをパブリッククラウドインフラサービスと連携させれば、ハイブリッドクラウド環境によって分散性とデータ保護を実現することが可能になります。

サービス中断の発生中にシステムのオンライン復帰のために必要なその他の対応はどのようなもので、その所要時間はどれほどでしょうか？たとえば、業務再開前に、損傷したコンポーネントの交換、ソフトウェアの再プログラミングや、システムテストの実行が必要となる場合もあります。クラウドシナリオではハードウェアについて心配する必要はありませんが、クラウド利用に伴い、IPアドレスの再設定や再構成作業に必要な作業量が増えることになるかもしれません。運用する災害復旧計画を、セカンダリデータセットへのフェイルオーバーを行うものにするのか、それともインプレースで復旧を行うものにするのか、という問題に答えを出して、計画を立案・実施できるようにする必要があります。

詳細を知りたい方は、こちらから、ほぼゼロのRTOを実現して、データへのアクセスと復旧プロセスの所要時間を大幅に減少させ事業運営を復旧できるようにする方法をご確認ください。