冒頭でも触れましたが、Migrate to Virtual Machine (M2VM) は Google Cloud への仮想マシンの移行を行うための便利なマイグレーションツールです。
このツールを使えば、既存の仮想マシンを簡単に Google Cloud へ移行することができます。

M2VM 自体は無料で使用できることや、直感的な GUI で簡単に操作できることが特徴です。
移行後は VM のサイズと使用時間に基づいて従量課金されますので、
詳細な料金については公式サイトの料金ページの確認や料金計算ツールにて試算してください。

ここからは、実際に M2VM を使った操作手順について詳しく説明していきます。
本記事で検証する環境構成は以下図になります。

まずは Azure 側の準備です。必要な手順は以下2つです。

１．アプリの作成
２．カスタムロールの作成

１．アプリの作成

外部からAzureのリソースを操作するために「アプリケーション」を登録する必要があります。

【注意点】
Azure（Microsoft Entra ID）の既定では、すべてのユーザーがアプリケーションを登録し、作成したアプリケーションのすべての側面を管理できます。
しかし、環境によってはアプリケーションの登録が制限されている場合があります。
組み込みロールで制御する場合は、以下のいずれかを持つユーザーで操作が必要です。
・アプリケーション管理者
・クラウドアプリケーション管理者
・グローバル管理者

注意点を踏まえたうえで、Azure アプリケーションを作成していきます。

まず、アプリの登録ページに飛び、「新規登録」をクリックします。

次に、アプリの設定内容を入力し、「登録」をクリックします。
※設定内容は環境に応じて変更してください。

最後に、作成したアプリを開き、「証明書とシークレット」にて新しいクライアント シークレットを作成します。

※シークレットの値は M2VM の設定において必要になるので必ず控えてください。
シークレットの値は作成時のみ確認できる仕様のため、忘れてしまった場合は新しいクライアント シークレットを再発行してください。

２．カスタム ロールの作成

まず、移行対象 VM が所属するサブスクリプションに移動し、「カスタム ロールの追加」をクリックします。

次に、JSON ページに移動して「編集」をクリックし、 JSON を貼り付けます。
roleName、description、assignableScopes の subscriptionID は環境に応じて変更してください！

内容確認後、「作成」をクリックするとカスタム ロールが作成されます。
（作成完了まで約 10 分ほどかかる可能性があります。）

作成完了後は「ロールの割り当ての追加」より、「１．」で作成したアプリに対してカスタムロールの付与を行います。

これで Azure 側の手順は完了です。

後の Google Cloud 側の手順にて Azure で準備した以下情報が必要になるので控えておいてください。

• 移行対象 VM が所属するロケーション
• テナント ID
• サブスクリプション ID
• 作成したアプリのクライアント ID
• 作成したアプリのクライアント シークレットの値

次に、AWS 側の準備です。必要な手順は以下2つです。

１．IAM ポリシーの作成
２．IAM ユーザーの作成

それぞれの作成手順について記載していきます。

１．IAM ポリシーの作成

JSON にてアクセス許可を設定し、IAM ポリシーを作成します。※ポリシー名は任意の名前

２．IAM ユーザーの作成

まず、移行で使用する IAM ユーザ名を指定します。※ユーザー名は任意の名前

次に、本章の「１」で作成したポリシーをユーザにアタッチし、IAM ユーザーを作成します。

最後に、作成した IAM ユーザのシークレットアクセスキーを作成します。

※シークレットアクセスキーは M2VM の設定にて必要になるので必ず控えてください。
シークレットの値は作成時のみ確認できる仕様のため、忘れてしまった場合は新しいシークレットアクセスキーを再発行してください。

これで AWS 側の手順は完了です。
後の Google Cloud 側の手順にて AWS で準備した以下情報が必要になるので控えておいてください。

• 移行対象 VM が所属するリージョン
• 作成した IAM ユーザーのアクセスキー
• 作成した IAM ユーザーのシークレットアクセスキー

次に Google Cloud 側の準備です。必要な手順は以下3つです。

１．ターゲットの作成
２．ソースの追加
３．レプリケーションの開始

それぞれの作成手順について記載していきます。

１．ターゲットの追加

実際に移行する Google Cloud Project を指定します。

２．ソースの追加

移行元のソースを指定します。

◆ Azure 側設定値

◆ AWS 側設定値

約10分後、ソースのステータスが「有効」になり、VMリストが表示されることを確認します。

３．レプリケーションの開始

移行対象のソースアセットが表示されるので、VMサイズやネットワークを設定します。
※本記事では必須項目のみを設定しますが、設定内容は環境に応じて変更してください。

VMの設定が完了すれば、「レプリケーションの開始」を実施し、「有効（アイドル状態）」になれば移行準備完了です！

レプリケーションが完了すると移行開始できます。
ここで、M2VM には「事前テスト」という便利な機能があります。
この機能を活用すると、テストクローンを作成して移行のシミュレーションを行うことができます。

移行するにあたり、特段気になるのは IP アドレス関連でしょう。
事前テスト機能では、実際にテストクローンを作成するので、事前に IP アドレスを確認することができます。
※詳細は省きますが、Google Cloud 側で事前予約し、レプリケーション開始前の VM 詳細の設定時に予約した IP アドレスを指定することも可能です！
また、同じネットワーク体系を使用したい場合は HA VPN 設計などの事前準備が必要です。

本記事では依存関係のない VM1 台を移行しているため、事前テスト機能は飛ばしても問題はありません。
しかし、実際の移行では多くのケースで依存関係が存在すると思います。
そのため、事前テスト機能を利用して、依存関係の確認や問題の特定等を行うことを推奨します。

事前テストで問題がないことを確認したら、いよいよ本移行の開始です。
本移行を実施すると、ソース VM（本記事では Azure または AWS 上の VM）の停止が発生します。
本記事の VM 移行は約 30 分ほどかかりました。
※移行時間については転送効率など、環境によって異なります。

Migrate to Virtual Machines (M2VM)を使用すれば、各プロバイダ間の仮想マシン移行は比較的簡単に実現でき、以下利点があると感じました。

• 事前テスト機能を用いることで、本移行前にテストを実施することができ、移行後の問題発生リスクを低減できる
• Google Cloud が提供するソリューションであるため、信頼性とサポート体制が充実している

但し、M2VMがサポートしているOSは Azure と AWS で異なります。
環境で適用できるかの詳細は公式ドキュメントをご確認ください。

また、以前検証した Veeam と特徴を比較すると、M2VM は事前テスト機能が挙げられるのではないでしょうか。
移行ソリューションの比較はいずれ検証してみたいと思います。

ソリューションごとのメリット・デメリットを理解したうえで、環境に合わせた最適な方式で、安全に移行を実現させてください。

当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします！