2024年7月9日

【Google Cloud】M2VM で Azure・AWS からのお引越し

Popular tags

Content

こんにちは。りなぺんです。

Google Cloudへの移行にあたっては、Google Cloud が提供している「Migrate to Virtual Machines（以下、M2VM と記載します）」を使うと簡単にリフト移行することができます。

なんと M2VMは、vSphere 環境だけでなく、他のクラウド環境、つまり Azure や AWS からの移行にも対応しているのです。

本記事では、M2VM を使って Azure と AWS の環境からVMを移行する方法について解説していきます。

Migrate to Virtual Machine (M2VM) とは？

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

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

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

移行準備（Azure 編）

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

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

１．アプリの作成

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

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

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

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

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

設定内容	設定値
名前	Migration to Google Cloud
サポートされているアカウントの種類	この組織ディレクトリのみに含まれるアカウント
リダイレクト URI	（省略）

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

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

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

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

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

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

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

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

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

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

移行準備（AWS 編）

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

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

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

１．IAM ポリシーの作成

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

２．IAM ユーザーの作成

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

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

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

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

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

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

移行準備（Google Cloud 編）

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

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

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

１．ターゲットの追加

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

２．ソースの追加

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

◆ Azure 側設定値

設定内容	設定値
GCP リージョン	asia-northeast1
Azure ロケーション	VM が所属するロケーションを設定
サブスクリプション ID	VM が所属するサブスクリプションの ID
クライアント ID	作成したアプリの ID
テナント ID	VM が所属するテナントの ID
クライアントシークレットの値	本記事「移行準備（Azure 編）」で作成したクライアントシークレット値

◆ AWS 側設定値

設定内容	設定値
GCP リージョン	asia-northeast1
Azure リージョン	VM が所属するリージョンを設定
アクセスキー ID	本記事「移行準備（AWS 編）」で作成したアクセスキーID
シークレットアクセスキー	本記事「移行準備（AWS 編）」で作成したシークレットアクセスキー値

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

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

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

設定内容	設定値
インスタンス名	im-vm-01
プロジェクト	sts-im-rd
ゾーン	asia-northeast1-b
マシンタイプ	E2
マシンサイズ	e2-small
ネットワーク	vpc-im-rd
サブネットワーク	public-subnet

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

移行開始！

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

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

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

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