方式Aは「オンプレミスにNAS、クラウドにそのNASのソフトウェア版を使用する」または「オンプレミスとクラウドに同一のNASソフトウェアを使用する」方式である（図6）。

図6　方式A：NASまたはNASソフトウェアのレプリケーション機能《クリックで拡大》

　ファイルサーバは、この方式が適している。NASを使用するシステムは個別に切り替え方式を検討する必要がある。

方式B：DB／アプリケーションのレプリケーション機能

　方式Bはオンプレミスとクラウドに同一のDBまたはアプリケーションを構築し、そのレプリケーション機能を使用する方式である（図7）。

図7　方式B：DB／アプリケーションのレプリケーション機能（図中の「AP」はアプリケーション）《クリックで拡大》

　静止点を確保したり、RPO／RTO（目標復旧時点／目標復旧時間）を最適化したりできるため、重要度の高いシステムは本方式を検討すべきだ。パブリッククラウドのマネージドサービスを使用する場合は、オンプレミスとのレプリケーション機能を利用できるかどうかをクラウドベンダーに確認する必要がある。

方式C：レプリケーション製品＋HAクラスタ製品on仮想マシン

　方式Cは、保護対象の仮想マシンとクラウドのスタンバイシステムにレプリケーション製品をインストールし、切り替えは手動またはHAクラスタ製品を使用する方式である（図8）。

図8　方式C：レプリケーション製品＋HAクラスタ製品on仮想マシン（図中の「AP」はアプリケーション、「レプリ製品」はレプリケーション製品）《クリックで拡大》

　オンプレミスで複数台の仮想マシンによるクラスタを構成し、サイト（データセンター）障害発生時に、クラウドへフェイルオーバーするように設計するのが一般的だ。なぜなら、オンプレミスの単一仮想マシンが障害になるだけで、クラウドへのフェイルオーバーに大きな影響が及ぶからである。また稼働系、待機系のそれぞれのシステムを管理したり、切り替えたいシステムごとにクラスタを構成したりする必要があり煩雑になる。そのため大規模な環境では本方式はお薦めしない。

方式D：バックアップデータのレプリケーション／リストア

　方式Dはオンプレミスのバックアップデータをクラウドへレプリケーションし、クラウドのスタンバイシステムにリストアする方式である（図9）。

図9　方式D：バックアップデータのレプリケーション／リストア《クリックで拡大》

　バックアップデータのレプリケーションは、重複排除機能を備えたストレージシステムや、オンプレミスのサーバとクラウドストレージを接続するクラウドゲートウェイも使用できるが、バックアップ製品のレプリケーション機能を使用する方が製品数を減らせシンプルな構成になる。リストア容量が大きくなると復旧に長時間を要するため、短時間のRTO（復旧時間）を求めるシステムには不向きである。

　注意してほしいのが、本方式の対象データが「ユーザーデータ」であることだ。AWS、Azure、GCPなどのパブリッククラウドで稼働するバックアップサーバに、VMware仮想マシンのバックアップAPI「VADP」（VMware vSphere Storage APIs - Data Protection）で取得したデータをレプリケーションしても、そのままではシステムをリストアできない。バックアップデータを利用したクラウドへのシステム切り替えは、方式G、方式Hを参照してほしい。

2－2．DR方式2（レプリケーション対象：OSを含めたシステム全体）

　システムをオンプレミスからクラウドへ切り替える方式は、ほとんどのケースでオンプレミスのシステムが仮想化されていることを前提としている（表2）。

方式E：ハイパーバイザー機能によるレプリケーション／切り替え

　方式Eはオンプレミスとクラウドで同一のハイパーバイザーを使用し、そのハイパーバイザーの機能でレプリケーションと切り替えをする方式である（図10）。

図10　方式E：ハイパーバイザー機能によるレプリケーション／切り替え《クリックで拡大》

　オンプレミスとクラウドのストレージシステムを統一すれば、ストレージシステムのレプリケーション機能を使用することも可能だが、切り替えがストレージボリューム単位となるので注意してほしい。ハイパーバイザーのレプリケーション機能なら、仮想マシン単位での切り替えが可能になるが、大規模な場合は実績も確認してほしい。

　結局、ハイパーバイザーのベンダーロックインになることは意識しておく必要がある。Azureの機能をオンプレミスで利用可能にするMicrosoftの「Azure Stack」とAzureの組み合わせ、オンプレミスのVMware製品と今後、国内で利用可能になるVMware Cloud on AWS、VMware virtualization on Azureの組み合わせも本方式だと理解していいだろう。

方式F：マルチハイパーバイザー／マルチクラウド対応のマイグレーション製品

　方式Fはオンプレミスのハイパーバイザーとパブリッククラウドの両方にマイグレーション管理サーバを立て、レプリケーションおよびマシンイメージの変換、システムの切り替えをする方式である。

図11　方式F：マルチハイパーバイザー／マルチクラウド対応のマイグレーション製品（インスタンスのディスクを使用）《クリックで拡大》

　マルチハイパーバイザー／マルチクラウド対応のマイグレーション製品のベンダーは、ハイパーバイザーベンダー、ハイパーコンバージドインフラ（HCI）ベンダー、ソフトウェアベンダーなど多岐にわたる。

　パブリッククラウドでマシンイメージを変換する仕組みには2種類あり、インスタンスのディスク領域を使用する製品（図11）、クラウドストレージ（オブジェクトストレージサービス）を使用する製品（図12）がある。

図12　方式F：マルチハイパーバイザー／マルチクラウド対応のレプリケーション製品（クラウドストレージを使用）《クリックで拡大》

　クラウドストレージを使用するマイグレーション製品はマシンイメージの変換に時間を要する。容量によっては数時間を要する場合もある。それに比較して、インスタンスのディスク領域を使用する製品の場合、マシンイメージの変換は高速だ。この動作の違いは大きいため、どちらの動作になるか、または選択可能かをベンダーに確認してほしい。本方式の製品検討ポイントは下記になる。

• 製品検討ポイント
  • マシンイメージ変換にクラウドストレージを使用するか、インスタンスのディスクを使用するか
  • オンプレミス→クラウドの切り替え、クラウド→オンプレミスの切り戻しが可能かどうか
  • オンプレミスのシステムを稼働させたまま、切り替えのリハーサルが可能かどうか
  • オンプレミスとクラウドのシステムの稼働状況を可視化できるかどうか
  • データの同期状況（RPO）が可視化できるかどうか
  • 切り替え後のネットワーク変更／DNS変更が可能かどうか

　現在、「クラウドで構築したシステムからオンプレミスへの初期レプリケーション」の機能を提供しないマイグレーション製品が多いので注意が必要だ（注1）。異なるハイパーバイザー間でも移行可能な製品もあり、今後はクラウド間でのシステム移行も可能になるだろう。非常に楽しみな製品分野である。

※注1：オンプレミスからクラウドへレプリケーション／システム切り替えをした後、クラウドからオンプレミスへ逆向きのレプリケーション／切り戻しを可能にしているマイグレーション製品がある。その製品でも、クラウドで新規構築したシステムをクラウドからオンプレミスへ初期レプリケーションできないものが多いため、それぞれの製品で仕様を確認していただきたい。

方式G：仮想マシンのシステムバックアップをクラウドのインスタンスへ変換

　方式Gは、オンプレミスで取得した仮想マシンのシステムバックアップをクラウドストレージに転送し、パブリッククラウドのインスタンスに変換／起動する方式である（図13）。

図13　方式G：仮想マシンのシステムバックアップをクラウドのインスタンスへ変換《クリックで拡大》

　クラウドストレージに保存されたバックアップデータから、インスタンスへ変換するため、方式Fと同様に時間がかかるので注意してほしい。複数台のシステムを同時に切り替え可能かどうか、クラウドからオンプレミスへの切り戻しが可能かどうかは製品ごとに確認してほしい。

方式H：仮想マシンのシステムバックアップを同一ハイパーバイザーのクラウドで自動リカバリー

　方式Hは、オンプレミスで取得した仮想マシンのシステムバックアップを、同一ハイパーバイザーのクラウドにレプリケーションし、自動または手動でリカバリーする方式である（図14）。

図14　方式H：仮想マシンのシステムバックアップを同一ハイパーバイザーのクラウドで自動リカバリー《クリックで拡大》

　バックアップ製品と連携できるオーケストレーション製品を提供しているベンダーもある。リストア後の仮想マシンのIPアドレス変更まで可能な製品もある。クラウド側はオンプレミスと同一のハイパーバイザーであることが必須だが、システムリストアの権限が許可されるかどうかはクラウドベンダーに確認してほしい。

要件に応じた方式選定の指針

　DR方式を選定する前に、保護対象と対象ごとの復旧要件を検討する必要がある（表3）。

　方式選定の基本は、採用する方式の数を減らして、シンプルに構成することである。まず、上記の検討項目の大半を満たす共通の方式を1つ決める。ただしカバー範囲の広い方式はRPO／RTOが長くなる傾向にある。そのため重要度の高いDBなどのシステムは個別方式の採用を推奨する。ただしDB以外のアプリケーションについては、クラウドへのDRを検討するより、SaaS（Software as a Service）を選択するのも1つの手である。

　復旧要件から方式を選定し、DR製品を選択する流れとなる。その際、予算や製品の国内導入実績、ベンダーのノウハウ、今後の製品ロードマップを含めて検討する必要がある。次回は現実的な複数の方式の選択と、具体的な製品について言及する。

【コラム】「ハイブリッドクラウド対応」「マルチクラウド対応」という言葉の意味

　昨今「ハイブリッドクラウド対応」「マルチクラウド対応」という言葉は各ベンダーが都合よく使っている。プライベートクラウド（オンプレミス）とパブリッククラウド間で、またはパブリッククラウド間で、何をどこまで可能にしているのかを確認してほしい。下記をベンダーに確認し、「真のハイブリッドクラウド（下図参照）」を実現するDR製品を選ぶべきである。

• 確認事項
  • オンプレミスとクラウドを単に併用できるだけかどうか
    • 1つのGUI（グラフィカルユーザーインタフェース）でオンプレミスとクラウドを操作できるが、実際は双方を別々に利用するDR製品もある
  • オンプレミスとクラウド間の移行ができるかどうか。できる場合は片道か、双方向か
  • 対象がユーザーデータのみか、OSを含めたシステム全体か
  • RTOはどの程度か
    • 移行ツールとしてのみ使用可能か、DRツールとしても使用可能かなどを確認
  • 可視化が可能かどうか
    • システム稼働状況やRPO／RTOなどの可視化機能を確認
  • 統合管理が可能かどうか
    • 複数システムの制御、オンプレミスとクラウド間の切り替えのリハーサル、ネットワーク変更／切り替えなどの機能を確認

図15　真のハイブリッドクラウドとは《クリックで拡大》

　ハイブリッドクラウドでは、クラウドベンダーのロックイン、クラウドサービス障害／終了のリスクもあることから、複数のクラウドを利用するマルチクラウドも浸透しつつあるようだ。

図16　真のマルチクラウドとは《クリックで拡大》

　図16左のような単なるハイブリッドクラウドの併用では、クラウド間の移行はオンプレミスを経由することになる。また全体把握は難しく、運用管理は人手を介することになる。一方で真のマルチクラウドは、プライベートクラウドとパブリッククラウド間、複数のパブリッククラウド間で、システムおよびデータのシームレスな行き来や可視化ができるような状態だと、筆者は期待している（図16右）。皆さまもベンダー各社にロードマップを含め確認し、「真のマルチクラウド」を目指してほしい。