Google Cloud VMware Engine

解決する課題

• オンプレの VMware 資産（VM・テンプレート・運用ツール）をそのままクラウドへ移したい
• 仮想マシンを 再構築・リプラットフォームせずに短期間でリホスト移行したい
• データセンターの退役・更改で、ハードウェア調達や保守を手放したい
• 災害復旧（DR）やバースト容量を クラウド側に確保したい
• VMware の操作感（vCenter, vSphere Client）を変えずに運用を続けたい

VMware Engine は、vSphere・vSAN・NSX といった VMware Cloud Foundation のスタックを Google が運用するベアメタル上に展開し、利用者に専用環境として提供します。アプリの作り替えを伴わない「リフト＆シフト」を最短経路で実現できるのが最大の価値です。

主要概念と用語

• プライベートクラウド（Private Cloud）: VMware Engine が提供する隔離された VMware 環境の単位。専用の vCenter・NSX Manager を持つ
• クラスタ（Cluster）: プライベートクラウド内のノードの束。ノードを追加・削除して容量を増減する
• ノード（Node）: クラスタを構成するベアメタルのホスト。CPU・メモリ・ローカルフラッシュを備え、vSAN のストレージにも寄与する
• vSphere / vCenter: VM を作成・管理する VMware の中核。利用者は使い慣れた vCenter で操作する
• vSAN: ノードのローカルストレージを束ねて作るソフトウェア定義の分散ストレージ
• NSX: ソフトウェア定義ネットワーク。論理スイッチ・ルーター・分散ファイアウォールを提供する
• HCX: オンプレと VMware Engine 間の VM 移行・ネットワーク延伸を行う VMware の移行ツール
• VMware Engine ネットワーク: Standard ネットワークは VPC Network Peering、2023年11月より前の一部プロジェクトに残る Legacy ネットワークは Private Service Access で接続する

仕様・制限・クォータ

• ノード単位での購入: 標準プライベートクラウドは3ノード以上、ストレッチ構成は6ノード以上。検証用の単一ノード構成は60日後に削除され、SLA対象外
• リージョン × ゾーンに配置される。可用性を高めるには対応構成でストレッチクラスタ等を検討する
• ストレージは vSAN が基本で、必要に応じてクラウド側のファイル/オブジェクトストレージを併用できる
• ノード数・プライベートクラウド数・ネットワーク関連にはクォータがあり、引き上げ申請が可能
• 利用できるリージョンやノードの世代・スペックは時期により異なるため、最新は公式ドキュメントで確認する
• 2025年11月1日以降の新規容量は、Broadcom から購入した VCF Portable ライセンスを持ち込む必要がある。Google Cloud のノード料金とは別に契約・数量を管理する

数値や対応リージョンは変動するため、正確な上限・SLA は公式ドキュメントを参照してください。

内部の仕組み

VMware Engine は、Google が運用するベアメタルのノード上に VMware Cloud Foundation（vSphere, vSAN, NSX）を構成し、利用者ごとに隔離されたプライベートクラウドとして払い出します。利用者は vCenter にログインし、オンプレと同じ操作で VM を管理します。基盤のハードウェア保守やファームウェア、ハイパーバイザのパッチ適用といった下回りは Google とパートナーが担います。

ストレージは各ノードのフラッシュを vSAN で束ねた分散ストレージが基本です。ノードを追加すると計算資源とストレージ容量が同時に増えます。ネットワークは NSX によるオーバーレイで提供され、論理セグメントや分散ファイアウォールをソフトウェア的に定義できます。

Standard VMware Engine ネットワークは VPC Network Peering で VPC と接続します。Cloud Storage や BigQuery など Google API へ非公開で到達するには、Private Google Access 用の DNS と VIP 経路を構成します。Cloud SQL など Private Service Access 側のサービスは対象ごとのピアリング経路を設計します。オンプレとの間は Cloud VPN / Cloud Interconnect で接続し、移行時は HCX で VM をライブ／一括移行したり L2 ネットワークを延伸したりします。

横にスクロール

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

• 段階移行: HCX でアプリ単位・依存関係単位に分けて移行し、切り戻し可能な状態を保つ
• リホスト → リファクタの順: まずそのまま移し、移行後に必要なものから Compute Engine / GKE / マネージドサービスへ載せ替える
• 可用性設計: 単一ノード構成は避け、本番は複数ノードで冗長化。要件次第でゾーンをまたぐ構成を検討する
• ネットワーク連携: Google Cloud のサービスを使う場合は VPC ピアリング経由で低遅延に寄せ、egress 経路を整理する
• DR 用途: オンプレの待機系を VMware Engine 側に置き、平常時はノードを絞ってコストを抑える

運用・監視

• 日常運用は使い慣れた vCenter / vSphere Client で行える。VM のメトリクスやアラートも従来ツールを継続利用できる
• 基盤の Cloud Monitoring / Cloud Logging と組み合わせ、ノードやネットワークの状態、課金に直結する容量を可視化する
• ノード使用率（CPU・メモリ・vSAN 容量）を監視し、逼迫前にクラスタへノードを追加する
• ハイパーバイザや基盤のメンテナンスは Google 側で実施されるため、メンテナンス通知を確認し業務影響を見積もる
• 移行作業中は HCX のレプリケーション状況と切り替えウィンドウを管理する

コスト

• 課金は基本的にノードの稼働時間に基づき、ノード数 × 時間で積み上がる。1ノードでも計算とストレージを内包するため、最小構成でも一定のコストが発生する
• 長期利用が見込めるなら確約利用割引（CUD）相当のコミットでオンデマンドより単価を下げられる場合がある
• Google Cloud の他サービス利用料、外部への通信（egress）、相互接続（Interconnect/VPN）の費用は別途かかる
• 新規容量では VCF Portable ライセンスをBroadcomから別途購入する。ノードのオンデマンド/CUD費用だけで見積もらない
• コスト最適化の要点は、ノード数の適正化（過剰なノードを持たない）と、DR など低稼働用途での最小構成維持

具体的な料金やコミット割引率は変動するため、見積もりは公式の料金ページと料金計算ツールで確認してください。

セキュリティ

• ネットワークは NSX の分散ファイアウォールでマイクロセグメンテーションを行い、東西方向の通信も最小化する
• 操作権限は Cloud IAM と vCenter のロールの二層で管理し、それぞれ最小権限にする
• vSAN は保存時暗号化が既定で有効。要件に応じて、プライベートクラウド単位の Cloud KMS / CMEK または対応する外部 KMS を選ぶ
• オンプレ・クラウド間は Cloud VPN / Interconnect の暗号化・専用経路で接続し、公開経路への露出を避ける

関連サービス・比較

純粋な IaaS である Compute Engine と比べると、VMware Engine は「既存 VMware をそのまま動かす」点に特化しています。

ハンズオン / CLI例

# Standard VMware Engineネットワークを先に作成
gcloud vmware networks create my-ve-network \
  --location=global \
  --type=STANDARD

# プライベートクラウドを作成（本番の標準構成は3ノード以上）
gcloud vmware private-clouds create my-private-cloud \
  --location=asia-northeast1-a \
  --cluster=my-cluster \
  --node-type-config=type=standard-72,count=3 \
  --management-range=192.168.0.0/24 \
  --vmware-engine-network=my-ve-network

# プライベートクラウドの一覧を確認
gcloud vmware private-clouds list \
  --location=asia-northeast1-a

# クラスタにノードを追加して容量を増やす
gcloud vmware private-clouds clusters update my-cluster \
  --private-cloud=my-private-cloud \
  --location=asia-northeast1-a \
  --update-nodes-config=type=standard-72,count=4