アプリケーション マイグレーション パターン
本節では、アプリケーションのマイグレーション パターンについて解説をしていきます。なお、ここではコンテナライズされたアプリケーションではなく、物理サーバや VM の環境に構築された、比較的レガシーなアプリケーションをマイグレーションする前提で記載します。
デザイン パターン詳細
仮想マシンの Google Compute Engine（GCE）への移行
解決する課題・使い所
既存のワークロードを異なる環境に移行する際には、ドライバのインストールなど、移行先の環境に合わせた変更作業が必要となります。Google Cloud では、元環境から GCE にワークロードを移行をする際に、GCE に必要なパッケージが自動的にインストールされるような移行ソリューションをいくつか用意しています。
クラウド移行の際のリスクと作業工数を最小化するためには、それらの移行ツールの選択肢を理解し、適切に選択を行うことが重要です。本節では、ワークロードの性質や要件に合わせてどんな移行選択肢が存在するかを列挙し、移行ツールを選定する上でのポイントを記載します。
Google Cloud への移行方法
GCE への VM 移行方法には大きく分けると 3 種類の方法があります。
1. Migrate for Compute Engine（M4CE）などの移行ツールを用いた移行
移行ツールを用いて、GCE 側にインスタンスをインポートするやり方です。Google Cloud では M4CE を提供していますが、他のサードパーティ ソリューションなどでも GCE への移行をサポートしているものがあります。
M4CE は現時点では VMware / AWS / Azure などの環境からの移行をサポートしています。このツールの特徴的なところは、まず GCE 側にインスタンスをたて、そのインスタンスからオンプレミス側のストレージにマウントを行うことで、ワークロードを稼働させることができる点です。これにより、移行の中で最も時間のかかるデータ転送を行う前からクラウド側にワークロードを起動できることです。稼働したワークロードは、この時点で使用開始することができ、その間にデータ移行もバックグラウンドで行われるようになります。移行が終わったら、切り離し作業を行い、ワークロードを完全に GCE 側に移すようにします。なお、移行の際に、GCE に必要なパッケージもインストールされるようになっています。詳細については、後ほど説明します。
2. OVF / OVAファイル、仮想ディスクを用いた移行
既存の環境から、OVF / OVA ファイルや、仮想ディスク（vmdk、vhd など）をエクスポートし、Google Cloud 側にデータを転送した後に GCE 側にインポートするやり方です。1 と比べ、作業を手動で行う必要があるのと（スクリプトなどを組むことで自動化は可能ですが）、ダウンタイムは長くなってしまいますが、ツールなどをセットアップする必要はなく、直感的にもわかりやすいので、オペレーションはシンプルに実現できます。なお、GCE へのインポートの際に、GCE に必要なパッケージがインストールされる仕組みになっています。
3. OS より上のレイヤーの機能を用いた移行
こちらは 1、2 とは毛色が異なりますが、GCE 側にインスタンスを立てて、OS の中身の機能でデータを移行するやり方です。この場合、データ移行部分以外は再構築になるため、作業やテストが多くなる可能性がありますが、1、2 と違い元環境専用のドライバなども移行してしまいゴミが残ってしまうことはないので、よりクリーンな環境でワークロードをスタートさせることができます。なお、もちろん GCE を立てるタイミングで GCE に必要なパッケージはプリインストールされています。
アーキテクチャ / 移行のステップ
上記の選択肢 1 に当たる、M4CE を用いた移行をする際の構成と、移行の流れを説明します。ここでは、オンプレミスの VMware vSphere® 環境からの移行ステップを示します。
移行に関する大きな流れは以下のようになります。
1. Migrate for Compute Engine Manager の設定
M4CE の動き全体を管理/コントロールする Manager を GCE 側にデプロイし、設定します。
2. Migrate for Compute Engine Backend のデプロイと設定
オンプレミス側にバックエンド サーバをデプロイし、設定します。バックエンドは、オンプレミス側のデータセンタの VM ディスクに接続し、Google Cloud に VM ディスクのストリーミング / 移行を行います。
3. 移行作業の実施
VM を選択し、実際に移行を行うフェーズです。移行は大きく分けると以下の複数工程に分かれています。
(a) Run-in-Cloud
データはオンプレミスに残したまま、GCE インスタンスを起動し、GCE からオンプレミスのストレージにマウントする状態にするフェーズです。データはオンプレにありますが、インスタンスはオンプレ側のデータを使ってワークロードが起動しているので、既にこの時点で GCE の利用を始めることができます。なお、やはりネットワーク越しで動作しているために、パフォーマンスが劣化する可能性があります。常にトランザクションが大量に走るようなワークロードであると、この状態での利用はあまりおすすめできません。
なお、移行を前提とせず、クラウド側の挙動を確認するための、テストクローン機能も提供しています。
(b) ストレージの移行
ストレージのデータをオンプレミスから Google Cloud へ移行を行います。この作業はバックグラウンドで行われるため、この間も(a)で立てたインスタンスを利用することが可能です。
(c) VM の接続解除
(a)、(b) の作業中、移行元/移行先のワークロードは M4CE に管理されている状態になるので、(b) の移行が終わったら、接続解除を行う必要があります。この作業を行う際、VM は再起動されるため、インスタンスの利用をすでに始めている場合は、ユーザに影響の少ないタイミングを見極めて行う必要があります。
大きな流れは上記の通りですが、オンライン / オフラインの移行など、移行オプションによって工程は異なってきます。また、プロダクト アップデートなどで必要作業に変更が出る可能性もあるので、必ず最新情報は公式ドキュメントを確認するようにしてください。
利点
- ドライバのインストールや、OS ライセンスの変換など、ツールの中で自動的に行われるため、より少ない手間で移行を実現することができます。
- 移行ウェーブ機能を利用し、移行順序などを定義することで、自動的にバッチ移行を行うことができます。
- Run-in-Cloud により、データを移行する前からワークロードを稼働させることができるため、わずか数分でクラウド側でワークロードを稼働開始させることができます。
- 移行前に、インスタンスのサイジングの推奨を出力する機能があります。これによりコスト / パフォーマンスの両観点から適切なマシンタイプの選択を行うことができます。
- 予想外の事態が発生した時には、数クリックでステートフルなロールバックを行うことができます。
- OS のリプラットフォーム（例: Windows Server 2008 R2 から 2012 へのアップグレード）も移行の中で自動的に実行することができます。
注意事項
- 移行元/移行先の間は Private IP による接続ができる必要があります。（Interconnect、 VPN など）
- OS や移行元オンプレミスの ESXi のバージョンなど、要件を満たしている必要があります。
- LINUX 系の VM については、事前にパッケージのインストールを行う必要があります。