Migrate to Virtual Machines

解決する課題

• オンプレや他クラウドの稼働中サーバーを止めずに Compute Engine へ移したい
• 移行のたびに OS を再構築・再インストールするのは手間が大きく、構成のズレも生まれる
• 大量の VM をまとめて移行したいが、台数が増えると手作業では追従できない
• 本番を切り替える前に、移行先の VM が問題なく動くか安全に検証したい
• 切り替え時のダウンタイムを最小化し、業務影響を抑えたい

Migrate to Virtual Machines は、ソースの VM を稼働させたままディスクを継続的にレプリケーションし、短い停止で Compute Engine へ切り替えることでこれらを解決します。AWS で言えば Application Migration Service（MGN）に相当する位置づけです。

主要概念と用語

• ソース（Source）: 移行元の環境。VMware vSphere、AWS、Azure、または物理サーバーなどを指す
• マイグレーション（Migration）: 1 台のソース VM を Compute Engine へ移す処理の単位。状態（レプリケーション中、テストクローン中、カットオーバー済みなど）を持つ
• レプリケーション: ソース VM のディスク内容を移行先へコピーし続ける処理。初回の一括コピー後は差分だけを同期する
• エージェントレス移行: 多くの構成で、ソース VM にエージェントを常駐させずに移行できる方式。VMware ではコネクタ経由で連携する
• テストクローン（Test-clone）: 本番を切り替えずに、移行先の VM を試験的に起動して検証するための複製
• カットオーバー（Cut-over）: 本番をソースから移行先の Compute Engine VM へ切り替える操作。ここで実際の停止が発生する
• コネクタ / マイグレーションコネクタ: ソース環境（vSphere など）と Google Cloud をつなぐ仮想アプライアンス
• グループ（Group）: 複数のマイグレーションをまとめて扱う単位。アプリ単位での一括カットオーバーに使う

仕様・制限・クォータ

• 移行元として VMware vSphere、AWS、Azure、物理サーバーなどをサポートする（対応バージョンや OS は構成により異なる）
• 移行先は Compute Engine。ターゲットのプロジェクト・リージョン・マシンタイプ・ネットワークなどを指定する
• 移行できる OS や構成には条件があり、サポート対象の OS かどうかを事前に確認する必要がある
• レプリケーション速度はソース側のディスク書き込み量とネットワーク帯域に依存する
• 同時に移行できる VM 台数やストレージには上限・クォータがあり、大規模移行では事前確認と引き上げ申請が必要
• 具体的な対応 OS 一覧や上限値は変動しうるため、設計時には公式ドキュメントで最新の対応表とクォータを確認すること

内部の仕組み

Migrate to Virtual Machines は、ソース VM を稼働させたままディスクをレプリケーションし、移行先で起動可能なディスクに変換する仕組みで動作します。

• 初回は全ディスクを一括コピーし、その後は差分のみを継続同期する。これによりソースを止めずに移行先を最新状態へ近づけ続ける
• レプリケーション中はテストクローンを作成でき、本番に影響を与えずに移行先 VM の動作を検証できる
• カットオーバーでは、直近の差分を反映してから移行先 VM を正式に起動する。停止が発生するのはこのタイミングに限定される
• VMware からの移行では、ソース環境に**コネクタ（仮想アプライアンス）**を配置し、Google Cloud と安全に連携してレプリケーションを行う

設計パターン / ベストプラクティス

• 波（ウェーブ）に分けて移行: 全 VM を一度に移さず、依存関係の小さいグループから段階的にカットオーバーする
• テストクローンで事前検証: 本番切り替え前に必ずテストクローンを起動し、アプリの起動・接続性・ライセンスなどを確認する
• アプリ単位でグループ化: 相互に依存する VM はグループにまとめ、まとめてカットオーバーして整合性を保つ
• 移行後に最適化: まず動く状態へ移し（リフト＆シフト）、その後マシンタイプの適正化やマネージドサービスへの置き換えを検討する
• ネットワークと権限を先に整える: 移行先の VPC、ファイアウォール、サービスアカウントを事前に用意し、切り替え時に詰まらないようにする

運用・監視

• 移行コンソールで各マイグレーションの状態とレプリケーションの進捗を監視する
• 初回の一括コピーには時間がかかるため、ネットワーク帯域と所要時間を見積もっておく
• Cloud Logging / Cloud Monitoring で移行イベントや切り替え後の VM の挙動を確認する
• カットオーバー後は、移行先 VM のアプリ動作・パフォーマンス・接続性を継続的に確認する
• 移行完了後は不要になったレプリケーション資源やコネクタを片付け、コストの取りこぼしを防ぐ

コスト

• Migrate to Virtual Machines の利用自体は、多くの構成で追加料金なしで提供される
• 実際に課金されるのは、移行先で起動した Compute Engine の VM・ディスク・ネットワークなどの通常リソース
• レプリケーション中に移行先側で保持するストレージや、テストクローンを起動した分のリソースには課金が発生する
• 移行に伴うデータ転送（下り通信など）の費用が発生する場合があるため、帯域と転送量を見込んでおく
• 移行後はマシンタイプの適正化や、継続利用割引・確約利用割引（CUD）の活用で定常コストを下げられる

セキュリティ

• 移行先 VM に割り当てるサービスアカウントは最小権限にし、移行のついでに過剰権限を引き継がないようにする
• コネクタやレプリケーション経路では、ソースと Google Cloud 間の通信を保護する（プライベート接続や暗号化を検討）
• 移行先の VPC・ファイアウォールルールで通信を最小化し、テストクローンや本番の到達範囲を制御する
• 移行・カットオーバーを実行できる操作は IAM で制御し、誰がどの VM を切り替えられるかを管理する
• 移行先ディスクは Compute Engine と同様に既定で暗号化され、必要に応じて CMEK で自前鍵も利用できる

関連サービス・比較

オンプレや他クラウドからのデータベースやコンテナを含めた移行は、関連サービスと役割が分かれます。VM そのものの移行を担う Migrate to Virtual Machines と、関連する移行サービスを整理します。

ハンズオン / CLI例

# 1. 移行元（ソース）の登録状況を確認する
gcloud migration vms sources list \
  --location=asia-northeast1

# 2. 特定ソース配下のマイグレーション一覧を確認する
gcloud migration vms migrating-vms list \
  --location=asia-northeast1 \
  --source=my-vsphere-source

# 3. テストクローンを作成して移行先 VM を検証する
gcloud migration vms migrating-vms clone-jobs create test-clone-01 \
  --location=asia-northeast1 \
  --source=my-vsphere-source \
  --migrating-vm=app-server-01

# 4. 検証後、本番をカットオーバーする
gcloud migration vms migrating-vms cutover-jobs create cutover-01 \
  --location=asia-northeast1 \
  --source=my-vsphere-source \
  --migrating-vm=app-server-01