クラウド災害復旧とは

クラウド災害復旧は、ダウンタイムを最小限に抑え、システム障害、自然災害、サイバー攻撃などの危機が組織に与える影響を軽減することを目的としています。

組織がクラウド災害復旧を導入するために利用できる戦略は複数ありますが、いずれも混乱に直面した際にビジネスの回復力を確保することを目的としています。IBMの2026年データ侵害のコストに関する調査によると、データ侵害による世界平均コストは499万米ドル、米国では平均1,150万米ドルとなっています。ダウンタイムにより、組織は1時間あたり推定1,100米ドルのコストを被り、その後は評判の低下や今後のビジネスの損失につながる可能性があります。クラウド災害復旧は、このリスクの一部の軽減に役立ちます。

これは、物理的なデータセンターではなく、クラウドベースのインフラストラクチャを利用するという点で、従来の災害復旧戦略とは異なります。クラウドベースの災害復旧ソリューションには、物理的なバックアップよりも高い柔軟性と拡張性を備えていること、初期投資の削減、サイト障害に対する保護など、いくつかの重要なメリットがあります。

あらゆる災害復旧プログラムにおいて最も重要な2つの指標は、復旧時点目標（RPO）と復旧時間目標（RTO）です。これらの指標を組み合わせて、クラウド災害復旧戦略の設計やその有効性の測定に活用されます。

通常、大規模な組織では、データの種類ごとに異なるRPOおよびRTO目標を設定する多層的な戦略を採用します。組織は、異なる部門やデータの対象を特定するためにビジネスインパクト分析(BIA)を用いることがあります。

RPOは、組織が許容できるデータ損失の最大量を表します。これはファイル、データベース、アプリケーションなどのデータを複製する頻度を決定するために使用されるため、時間で測定されます。RPOが1時間に設定されている場合、システムは1時間に1回バックアップを更新し、その結果最大1時間分の新しいデータを失う可能性があります。これは、文書やゲームの自動保存のようなものです。RPOが小さければ小さいほど、失われる進捗は少なくなります。

RPOは、データのアップロード頻度が高まるため、コストが下がるにつれて高額になります。幸いなことに、1分から数秒という非常に短いRPO目標は、すべてのクラウド災害復旧運用において必要とされるわけではありません。

例えば、大規模なeコマース事業では販売データの最新化を確実にするために非常に低いRPOが必要かもしれませんが、同じ事業では人事ファイルや分析アーカイブなど他のデータに対しては24時間のRPOで十分かもしれません。これらのRPO（目標復旧時点）が長い例では、大きなネットワーク帯域幅や超高速ネットワーク接続を必要としないため、コストが低くなります。

一部のクラウドDRソフトウェアには、データの微小変更をローリングし、有効期限が切れるログ・エントリーに継続的にストリーミングするポイント・イン・タイム・リカバリー・メカニズムが含まれています。これにより、組織は災害が発生する直前まで「巻き戻す」ことができます。

クラウド・ベースのシステムを選択することで、組織はこの柔軟性を活かせます。組織はクリティカルデータに対してほぼゼロのRPOを運用しつつ、アーカイブのより安価で長いRPO複製を活用でき、 過剰プロビジョニングの心配をする必要がありません。この弾力性により、効率性を高め、コストを削減することができます。

RTOとは、障害発生後にシステムやプロセスがオフラインの状態にあることが許容される最大時間を指し、そのダウンタイムが許容できない損害をもたらす前の時間を定めたものです。これは、災害が発生した瞬間から、業務が完全に復旧するまでの期間を指します。RPOとRTOはどちらも分、時間、日などの時間で測定されますが、RPOは最大のデータ損失の目標であり、RTOはダウンタイムの目標です。

「稼働開始」は、見た目ほど単純なものではありません。単にハードウェアを再起動するだけで、RTO測定を終了するべきではありません。顧客が利用できるよう事業を完全に復旧させるには、いくつかのチェックポイントをクリアする必要があります。ハードウェアの再起動に加えて、バックエンドサービス、ネットワークルーティング、 DNSもすべて正常に動作している必要があります。

クラウド災害復旧は、復旧作業の大部分を専用のプロバイダーにアウトソーシングすることで、RTOの削減に貢献できます。オンプレミスの災害復旧環境では、エンジニアが物理的に建物に入り、手動で再起動またはハードウェアを交換しなければならない場合があります。クラウドのDRではそうではありません。即時の拡張性とは、必要な新しいサーバーやストレージをいつでも利用できることを意味します。

クラウド災害復旧は、復旧時のRTOを短縮しますが、達成可能なRTOは、データ量、レプリケーション方式、フェイルオーバーシステムの構築方法（例えば、ウォームスタンバイであるか、あるいはすべてをコールド状態で起動する必要があるかなど）といった要因に依然として左右されます。これらの戦略については、次のセクションで詳しく説明します。

クラウド災害復旧には主に4つの戦略があり、帯域幅の使用量、速度要件、RPOとRTOの両方の目標に基づいて異なります。

クラウド災害復旧戦略の中で最もシンプルなものであるバックアップと復元は、サーバー・イメージ、ファイル、その他のデータの基本的なコピーを作成し、それらを定期的にクラウドに保存することで機能します。災害が発生した場合、自動化スクリプトはバックアップから復元し、運用サーバーを起動します。

バックアップは可変または不変のいずれかで、後者は書き込み保護があるため、編集、削除、上書きができません。不変バックアップは、変更できないためランサムウェアから守るのに特に有用です。バックアップと復元には、通常、他の戦略よりも高いRTOとRPOの両方が伴います。

バックアップおよび復元システムのRTOは、まだコンピューティングインフラが稼働していないため高くなります。このシステムは、単に後で復元するためにデータを保存するだけのものです。その復元には、新しいサーバーへコピーすべき膨大な量のデータが関わる可能性があり、システムを稼働させるためには、大規模なプロビジョニング、ルーティング、およびインデックス作成が必要になる場合があります。

バックアップが継続的ではなく定期的に取得されるため、バックアップおよび復元システムのRPOも高くなります。バックアップ間の間隔で取得されたデータが失われたデータとなります。これらのシステムはしばしばコールドストレージに依存しており、データはハードディスクドライブ(HDD)や磁気テープなどのハードウェアに書き込まれ、その後電源が切れます。これは、長時間にわたってエネルギーや帯域幅をほとんど必要としないという点で費用対効果が高いですが、データを取得するためにドライブを起動するのに時間がかかる場合があり、それがRTO（目標復旧時間）の増加につながります。

パイロットライトストラテジーの名前は、ガス炉や給湯器、暖炉のパイロットライトに由来します。これは、できるだけ燃料を節約しながらも瞬時に点火できる、小さく、常に燃え続ける炎です。クラウド災害復旧のコンテキストでは、パイロットライト戦略には、1つの要素をライブに維持することが含まれます。通常は、プライマリー・データベースの変更に応じて継続的に更新されるレプリカ・データベースです。

アプリケーションやウェブサーバーのイメージ、コンテナテンプレートなどのその他の要素は、より安価なクラウドストレージ（ウォームストレージと呼ばれることもある）に格納されます。ウォームストレージとは、頻度は低いが即時のアクセスを目的とした価格のストレージ（プロバイダーによって名称が異なる）ストレージ層を指します。これらのアイテムを常に更新し続けるよりも低コストですが、コールドストレージで取得が遅い場合とは異なり、非常に迅速にアクセスできます。

イメージとテンプレートは通常、基盤となるコードが変更された場合にのみ更新されます。災害が発生した場合、クラウド・プロバイダーは迅速に新しいサーバーを起動してデータベースに接続できるため、ダウンタイムを最小限に抑えることができます。

パイロットライト戦略では、アクセス頻度の低いストレージ層を安価な料金体系で利用しつつ、データベースを常に最新の状態に保ち、更新を続けます。これは多くの組織にとって理想的な「中間点」です。

ウォームスタンバイは、コストとRTOの両方の点でパイロットライトよりもワンランク上のものです。パイロットライトでは、アプリケーション・サーバーを再構築可能なイメージとして維持しますが、ウォーム・スタンバイ・セットアップでは、これらのサーバーをより小さいサイズで継続的に稼働させ、エネルギーとコストを節約できます。

これを理解する一つの方法は、パイロットライト戦略では、災害復旧時に保存された指示に基づいて環境を再構築するのに対し、ウォームスタンバイでは、トラフィックを受け入れるための小規模なインスタンスが常に利用可能であり、その一方でバックグラウンドでより多くのサーバーをスケールアップできる、という点にあります。これらのインスタンスは通常、ウォームスタンバイシステムとホットスタンバイシステムの両方において、仮想マシン（VM）上で実行されます。

既存のサーバーの使用を拡大または拡張する場合、再構築の段階が不要になるため、新しいサーバーを作成して起動するよりも高速です。これにより、RTOをわずか数分に短縮でき、RPOはほぼゼロになります（インスタンスが常に稼働しているため）。しかし、こうした数字はコストの増加を伴います。

ウォームスタンバイでは、「サンダリング・ハード」問題、つまり大量のトラフィックが小型のスタンバイサーバーに過負荷をかける問題を回避するために、追加の検討が必要となります。クラウドプロバイダーには、トラフィックを移行する前にサーバーのスケールアップを行うなど、この問題に対処するいくつかの方法があります。これにより、初期のダウンタイムは短くなりますが、中央処理装置（CPU）への過度な負荷を防ぐことができます。

ホットスタンバイは、複数の物理的な場所で2つ以上のインスタンスを同時に使用し、すべてがライブで実行されます。ジェットエンジンのように、1つの環境がダウンしても、残りの機能環境は負荷を処理しながら、損傷を修復します。通常、組織は各インスタンスの負荷を制限し、唯一のインスタンスが残っている場合でも全ての操作を処理できる能力を確保します。

ホットスタンバイは通常、他の種類のバックアップ・システムと組み合わせて使用されます。これは、ハードウェア障害などの状況が発生した場合でも高可用性を維持するように設計されたシステムです。データの整合性を標的とするマルウェア攻撃の場合、すべてのデータが汚染されるため、ホットスタンバイだけでは不十分です。したがって、パイロットライト、スタンバイ、ホット・スタンバイはすべて、通常、何らかの形式のポイント・イン・タイムのスナップショット・バックアップと組み合わせられます。

クラウドDR、クラウドバックアップ、 ディザスター・リカバリー・アズ・ア・サービス(DRaaS)はいずれも緊急時にデータを保護するという似た目標を持っていますが、バックアップに含まれる環境やオートメーションの量、そして管理者が誰かという点で異なります。

クラウドバックアップは、データがクラウド・ストレージにコピーされる状況を表す基本用語です。クラウドバックアップでは、これらすべてのデータの安全なコピーが保持されますが、アプリ環境、サーバー、コンピューティングは含まれていないため、社内のディザスター・リカバリー・チームが手動でシステムをダウンロードして再構築する必要があります。

クラウドDRは、クラウドバックアップの上に自動化とオーケストレーション機能を追加します。アプリケーション環境全体に加え、サーバーのプロビジョニング、データの復元、トラフィックの迂回に用いられる自動化スクリプトやルールをすべて網羅します。そのため、限定的なクラウドバックアップよりもはるかに少ない手作業でシステムを復旧できます。

DRaaSは基本的に、クラウドDRのサードパーティ管理バージョンです。組織は、データ複製やフェイルオーバーのためのスクリプトやルールを独自に作成する代わりに、その作業をDRaaSプロバイダーに委託することができます。一部のDRaaSは、テストとトリガー用のセルフサービス・ダッシュボードの形式で提供されますが、他のDRaaSプラットフォームはサードパーティーによって完全に管理されます。

クラウド災害復旧は急速に成長している分野です。 H2Vantixによると、クラウドDR業界は2025年の121億米ドルから2026年には144.6億米ドルへと成長すると予想されています。組織では、災害復旧対策として、完全にクラウドベースのシステムか、ハイブリッドクラウドシステムのいずれかを選択するケースが増えています。Global Growthの洞察によると、59％の企業が復旧インフラストラクチャの少なくとも一部をクラウドに移行しています。クラウド災害復旧の人気が高まっている理由はいくつかあります。

従来の物理的な災害復旧構成に対するクラウド災害復旧の最大の利点の1つは、初期費用を削減できることです。従来の災害復旧構成では、所有者はすべてのハードウェアとインストールに加えて、継続的なユーティリティーと保守を購入する必要があります。クラウド災害復旧では、組織は使用した分だけ支払うことができます。

一般的なコンピューティングに関しては、クラウドは初期導入コストを削減できるものの、予測可能で大規模なワークロードについては、長期的なコストの観点からオンプレミス型ソリューションの方が有利であるというのが通説です。これは、クラウドコンピューティングに伴うデータ転送料、サブスクリプション料金、その他のコストに加え、初期投資が時間の経過とともに予測可能な固定費として償却されるためです。一方、災害復旧の場合、状況はそれほど単純ではなく、最終的には利用率と所有権の問題に帰着します。

多くの場合、災害復旧のリソースはほとんどの時間、遊休状態にあるため、長期的には総所有コストが低くなることもあります。また、クラウドを利用すれば、組織はこれらのリソースをまだ保有していない場合でも、それらを所有するための費用を支払う必要がなくなります。

しかし、組織がすでに第2の物理サイトを保有しており、単にその負荷に災害復旧機能を追加するだけで済む場合、あるいはハードウェアを十分に稼働させ続けるほど負荷の高い、安定した大容量の24時間稼働ワークロードを実行している場合は、物理的なバックアップの方がTCOが低くなる可能性があります。

オンプレミスのバックアップおよび災害復旧では、追加のストレージや演算能力の購入、ならびにインストールやセットアップが必要となるため、スケーラビリティが問題となる場合があります。上記に挙げた費用に加えて、これには時間もかかります。クラウド災害復旧では、拡張性が組み込まれており、多くの場合自動化されています。ストレージとコンピューティングは需要に応じて迅速に拡張できます。

このスケーラビリティは、災害復旧のニーズが変動する組織にとって特に有益です。特に未使用ハードウェアで顕著です。すでにハードウェアを所有している場合、未使用のストレージや計算コストを支払わずにダウングレードするのは非常に難しいのです。中古機器を売って、必要に応じて買い戻すか、あるいは必要のない機器にお金を払い続けるしかないでしょう。オーバープロビジョニングのコストを回避することは、クラウドDRの導入の主な要因です。

自然災害が発生した場合、オンプレミスの災害復旧環境を維持することは、リスクを伴う可能性があります。洪水や火災、その他の自然災害は、単一障害点として機能するオンプレミスのITインフラに壊滅的な打撃を与える恐れがあります。クラウド災害復旧により、組織はストレージを異なる物理的な場所に分離し、すべてネットワーク経由でアクセスできるようになり、個々のサイトの障害から保護され、事業継続性の維持が可能になります。

初期導入には、以下のような一般的な手順がいくつかあります。

リスクとビジネスへの影響の両方を最初に分析することは、データ保護の観点から組織が何を必要としているかを確立するための良い最初のステップです。これには、アプリケーションごとに目標となるRTOおよびRPOの指標を設定し、すべてのシステム間の依存関係を把握し、データを「コールド」「ウォーム」「ホット」の各ストレージカテゴリごとに優先順位付けすることが含まれる可能性があります。

リスク・アセスメントには、潜在的なリスクの種類（ランサムウェア攻撃、データ盗難、環境災害、人的ミスなど）の特定が含まれます。しかし、他にもアセスメントすべき点があります。サービス・プロバイダーやクラウドなどを選択する際には、ベンダー・ロックインが常にリスクとなり、マルチクラウド環境を導入する価値があるという事実です。さらに、パブリッククラウド上の特定の情報のストレージを管理する規制についても考慮が必要です。

組織が何を必要としているかを把握すれば、それらの目標を達成する方法を比較できます。バックアップと復元、パイロットライト、ウォームスタンバイ、ホットスタンバイといったさまざまな戦略は、災害復旧の異なるカテゴリーに応じて同時に活用することができます。

組織がDRaaSシステムを選択した場合、設定と管理の多くはプロバイダーによって行われることになります。それ以外の場合では、組織は独自のデータ同期間隔、フェイルオーバー・オーケストレーション、ストレージ・ルールを構成する必要があります。

クラウドDRシステムが適切に機能し、最悪のシナリオに備えていることを確認するには、クラウドDRシステムの定期的なテストと保守が不可欠です。社内のITチームとサードパーティーのDRaaS管理チームはどちらも、定期的に個別のテストを実施して、すべてが正常であることを確認できます。

これらのテストでは、RTOおよびRPOを測定し、災害発生後にアプリケーションが実際に動作することを確認し、フェイルオーバーが意図したとおりに機能することを保証できるほか、ITチームにとっての最終リハーサルとしても活用できます。このリハーサルは、フェイルバック（通常の運用状態に戻るプロセス）のテストにも役立ちます。