2024年7月9日 【Google Cloud】M2VM で Azure・AWS からのお引越し Compute Engine Google Cloud 検索する Popular tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL Category Google Cloud Author りなぺん SHARE 目次 Migrate to Virtual Machine (M2VM) とは? 移行準備(Azure 編) 移行準備(AWS 編) 移行準備(Google Cloud 編) 移行開始! まとめ 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つです。 1.アプリの作成 2.カスタムロールの作成 1.アプリの作成 外部からAzureのリソースを操作するために「アプリケーション」を登録する必要があります。 【注意点】 Azure(Microsoft Entra ID)の既定では、すべてのユーザーがアプリケーションを登録し、作成したアプリケーションのすべての側面を管理できます。 しかし、環境によってはアプリケーションの登録が制限されている場合があります。 組み込みロールで制御する場合は、以下のいずれかを持つユーザーで操作が必要です。 ・アプリケーション管理者 ・クラウドアプリケーション管理者 ・グローバル管理者 注意点を踏まえたうえで、Azure アプリケーションを作成していきます。 まず、アプリの登録ページに飛び、「新規登録」をクリックします。 次に、アプリの設定内容を入力し、「登録」をクリックします。 ※設定内容は環境に応じて変更してください。 設定内容 設定値 名前 Migration to Google Cloud サポートされているアカウントの種類 この組織ディレクトリのみに含まれるアカウント リダイレクト URI (省略) 最後に、作成したアプリを開き、「証明書とシークレット」にて新しいクライアント シークレットを作成します。 ※シークレットの値は M2VM の設定において必要になるので必ず控えてください。 シークレットの値は作成時のみ確認できる仕様のため、忘れてしまった場合は新しいクライアント シークレットを再発行してください。 2.カスタム ロールの作成 まず、移行対象 VM が所属するサブスクリプションに移動し、「カスタム ロールの追加」をクリックします。 次に、JSON ページに移動して「編集」をクリックし、 JSON を貼り付けます。 roleName、description、assignableScopes の subscriptionID は環境に応じて変更してください! 内容確認後、「作成」をクリックするとカスタム ロールが作成されます。 (作成完了まで約 10 分ほどかかる可能性があります。) 作成完了後は「ロールの割り当ての追加」より、「1.」で作成したアプリに対してカスタムロールの付与を行います。 これで Azure 側の手順は完了です。 後の Google Cloud 側の手順にて Azure で準備した以下情報が必要になるので控えておいてください。 移行対象 VM が所属するロケーション テナント ID サブスクリプション ID 作成したアプリのクライアント ID 作成したアプリのクライアント シークレットの値 移行準備(AWS 編) 次に、AWS 側の準備です。必要な手順は以下2つです。 1.IAM ポリシーの作成 2.IAM ユーザーの作成 それぞれの作成手順について記載していきます。 1.IAM ポリシーの作成 JSON にてアクセス許可を設定し、IAM ポリシーを作成します。※ポリシー名は任意の名前 2.IAM ユーザーの作成 まず、移行で使用する IAM ユーザ名を指定します。※ユーザー名は任意の名前 次に、本章の「1」で作成したポリシーをユーザにアタッチし、IAM ユーザーを作成します。 最後に、作成した IAM ユーザのシークレットアクセスキーを作成します。 ※シークレットアクセスキーは M2VM の設定にて必要になるので必ず控えてください。 シークレットの値は作成時のみ確認できる仕様のため、忘れてしまった場合は新しいシークレットアクセスキーを再発行してください。 これで AWS 側の手順は完了です。 後の Google Cloud 側の手順にて AWS で準備した以下情報が必要になるので控えておいてください。 移行対象 VM が所属するリージョン 作成した IAM ユーザーのアクセスキー 作成した IAM ユーザーのシークレットアクセスキー 移行準備(Google Cloud 編) 次に Google Cloud 側の準備です。必要な手順は以下3つです。 1.ターゲットの作成 2.ソースの追加 3.レプリケーションの開始 それぞれの作成手順について記載していきます。 1.ターゲットの追加 実際に移行する Google Cloud Project を指定します。 2.ソースの追加 移行元のソースを指定します。 ◆ 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リストが表示されることを確認します。 3.レプリケーションの開始 移行対象のソースアセットが表示されるので、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 分ほどかかりました。 ※移行時間については転送効率など、環境によって異なります。 まとめ Migrate to Virtual Machines (M2VM)を使用すれば、各プロバイダ間の仮想マシン移行は比較的簡単に実現でき、以下利点があると感じました。 事前テスト機能を用いることで、本移行前にテストを実施することができ、移行後の問題発生リスクを低減できる Google Cloud が提供するソリューションであるため、信頼性とサポート体制が充実している 但し、M2VMがサポートしているOSは Azure と AWS で異なります。 環境で適用できるかの詳細は公式ドキュメントをご確認ください。 また、以前検証した Veeam と特徴を比較すると、M2VM は事前テスト機能が挙げられるのではないでしょうか。 移行ソリューションの比較はいずれ検証してみたいと思います。 ソリューションごとのメリット・デメリットを理解したうえで、環境に合わせた最適な方式で、安全に移行を実現させてください。 当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。 クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします! Google Cloud 導入についてのお問い合わせはこちら 関連コンテンツ 【Google Cloud】第1回:Veeamを使ったGoogle移行~方式比較してみた!~ by りなぺんon 2023年12月19日 頂きましたご意見につきましては、今後のより良い商品開発・サービス改善に活かしていきたいと考えております。 Author りなぺん BI事業部 2023年中途入社。好きな分野はインフラ、ネットワーク。すみっコぐらしに囲まれて生活してます。 Compute Engine Google Cloud 2024年7月9日 【Google Cloud】M2VM で Azure・AWS からのお引越し Category Google Cloud 前の記事を読む 【Google Cloud】OracleとGoogle Cloudがパートナーシップを発表 ~Google CloudでOracle Databaseの利用方法について解説~ 次の記事を読む 【参加無料】typeエンジニア転職フェア 出展のお知らせ(2024/7/13) Recommendation オススメ記事 2023年9月5日 Google Cloud 【Google Cloud】Looker Studio × Looker Studio Pro × Looker を徹底比較!機能・選び方を解説 2023年8月24日 Google Cloud 【Google Cloud】Migrate for Anthos and GKEでVMを移行してみた(1:概要編) 2022年10月10日 Google Cloud 【Google Cloud】AlloyDB と Cloud SQL を徹底比較してみた!!(第1回:AlloyDB の概要、性能検証編) BigQuery ML ワークショップ開催のお知らせ 生成AI導入支援パッケージ Discovery AI導入支援パッケージ Google Cloud ホワイトペーパー 新着記事 2024年9月2日 4koma 【4コマ漫画】SEひつじは定時退社の夢を見る ~ダウングレード~ 2024年8月29日 Google Cloud 【Google Cloud】Cloud NGFW Standard を試してみた 2024年8月29日 Google Cloud 【Google Cloud】Cloud Storage FUSE Read Cache を試してみた HOME Google Cloud 【Google Cloud】M2VM で Azure・AWS からのお引越し ご意見・ご相談・料金のお見積もりなど、お気軽にお問い合わせください。 お問い合わせはこちら HOME Categories お知らせ イベント・セミナー Google Cloud Google Workspace モバイル インフラ 技術開発 ブログ 4koma Tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL STSエンジニアリングマガジン 「サイタル」