RTO(目標復旧時間)について

By: IBM Services

RTO(目標復旧時間)とは

RTOは、アプリケーションが停止するがビジネスに重大な損傷をもたらすことのない時間の長さ、またシステムの損失から復旧までにかかる時間を表します。 この復旧プロセスには、アプリケーションとそのデータを災害発生前の状態に戻すためにITが実行する必要があるいくつかのステップが含まれます。 IT部門がフェイルオーバー・サービスに投資している限り、高優先順位のアプリケーションのRTOは、間違いなく秒単位にすることができます。 IT部門は、RTOのために、まず優先順位とビジネス損失のリスクに基づき、アプリケーションを分類する必要があります。 その後、これらのアプリケーションに対し、企業の持つリソース、つまり時間、資金、ITインフラストラクチャーから、適切な量を割り当てます。

RTOの決定

RTOは、災害が発生した後に、IT部門がデータをリカバリーするのに要する時間を測定するために使用されます。 RTOを決定する際は、ビジネスの全体的なニーズを反映し、ITインフラストラクチャーとITサービスなしでビジネスがどのくらいの時間耐えることができるかを判断します。 RTOはまず、IT部門による実行可能な対応と整合させる必要があります。 IT管理者は、ビジネスのニーズを満たすRTOを計算するために、異なるタイプの復元速度を深く理解する必要があります。例えば、最短の復元時間が2時間の場合に、1時間のRTOを達成することはできません。

このプロセスではすべてのIT運用を復元する必要があるため、RTOは多くの場合複雑です。 IT部門は、可能な限り自動化を図ることによって、復旧プロセスを部分的に簡素化することができます。 RTOは、細分化されたRPOよりもコストが高くなる可能性があり、要求が厳しいRTOの場合は単にデータだけではなくビジネス・インフラストラクチャー全体を対象とする必要があります。 RTOまたはRPOを達成するためのコストは、IT部門によるアプリケーションとデータの優先順位に応じたものとなるようにします。 IT部門は、収益とリスクに基づいて、アプリケーションとデータの優先順位を決定します。 データが規制の対象となっているアプリケーションについては、そこからデータ損失が発生した場合に、アプリケーションの使用頻度にかかわらず高額な罰金が科される可能性があります。

ほぼゼロのRTOまたはRPOの達成

RTOとRPOは、アプリケーションとデータの優先順位に応じて異なりますが、どの企業にとっても、すべてのアプリケーションに対して、ほぼゼロのRTOまたはRPOを実現するのには非常にコストがかかります。 RTOでの100%のアップタイムとRPOでのデータ損失ゼロは、継続的なデータ複製と仮想環境に投資することによってのみ達成できます。

RTOの例

細分化された項目の復元は、RTOの1例です。 ここでは、多忙な企業のあるユーザーが重要なEメールを削除し、ごみ箱を空にしてしまった例を取り上げます。 この企業は、Microsoft Exchangeをビジネス上不可欠なアプリケーションとして使用しており、同社のIT部門は、細かいバックアップとリカバリー機能を備えたバックアップ・アプリケーションを使用して、Exchangeの差分レベルの変更を絶えずバックアップしています。 この機能を使用すると、IT部門は、1通のEメールのために仮想マシン全体を復元する代わりに、削除してしまった重要なEメールを約5分で迅速に取得できます。

目標復旧時間(RTO)と、それが企業の災害復旧に与える影響

災害復旧とRTO

停電。 盗難。 破損したサーバーやハード・ディスク。 サイバー攻撃とランサムウェア。 竜巻、地震、ハリケーン。 このように、適切に備えなければビジネスに大損害を与え得る災害は多種多様にわたります。 こうした災害は避けられないことが多いため、強靭なITインフラストラクチャーを保有し、規定の目標復旧時間と目標復旧時点を確立することは、復旧の強化に不可欠です。 IT部門がアプリケーションをフェイルオーバーし、データを複製してほぼゼロの損失を達成することは可能ですが、それには相当なリソースが必要となります。 IT部門は、アプリケーションの優先順位と、それに割り当てられた予算とリソースに基づいて、RTOを確立する必要があります。

RPOとは何か、またRTOはどのように異なるか

RTOは、障害、災害、または損失を発生させる類似の事象からの、時間の測定値という点で、目標復旧時点(RPO)と一致します。 RPOは、データが最後に使用可能であった時点(おそらく直近のバックアップ)まで逆算します。 RPOとRTOは、事業継続における重要な概念であり、企業がデータ・バックアップのスケジュール頻度を決定するために必要な、ビジネスの測定基準です。

レジリエンシー・オーケストレーションと災害復旧

災害復旧戦略、特にハイブリッドIT環境の災害復旧には、多くの課題があります。 これらの課題には、主に以下のようなものがあります。

  • 異なる環境にデプロイされたワークロード
  • ITインフラストラクチャーとアプリケーションの間の相互依存関係
  • すべてのデバイス、コンポーネント、アプリケーションのRPOへの復元と、業務の完全な復旧
  • システムとアプリケーションの復旧を誤った順序で行った場合の、システム復元のさらなる遅延の可能性

あらゆる障害を排して、効果的な災害復旧戦略を策定・実行するために、何ができるでしょうか。 適切なITチームがあれば、数時間以内にいくつかの重要なアプリケーションを復元することはこれまでも可能でしたが、多くの貴重なリソースを必要とします。 今日、RTOとRPOに対する要求はさらに高まっており、また複数の基幹業務アプリケーションの迅速な復元を実現するシステム復旧が求められています。 現在では、中断の影響を最小限に抑え、障害発生から数分以内にリカバリーを実行できるようになりました。 自動化は不可欠であり、ハイブリッド環境への移行においてさまざまなアプリケーション間のワークフローを迅速かつ確実に自動化することにより、災害復旧プログラムを拡張できます。

今日のレジリエンシー・オーケストレーション・テクノロジーは、災害復旧戦略の適切な実装を支援します。また、障害の結果として生じる、実稼働環境のダウンタイムの負担とビジネスのエクスポージャーを低減することができます。 準備の観点からは、レジリエンシー・オーケストレーションを活用することで、企業は災害復旧テストをより少ない担当者で適切に実行できるようになります。 レジリエンシー・オーケストレーションは、こうした企業が災害復旧訓練の準備と検証をより一層軽減するうえでも役立ちます。 レジリエンシー・オーケストレーション・テクノロジーの基本的な利点の1つは、アプリケーションの認識を維持しながら、物理環境、仮想環境、クラウド環境全体で機能することです。 クラウド・サービスに対し、エンド・ユーザーは着実に、セルフサービスと低いSLAのパラメーターを期待するようになっているため、オーケストレーション・ベースのレジリエンシー戦略が、クラウド環境を採用しようとする現代の企業にとって、ますます重要になりつつあります。