インフラ

Compute Engineとは?GCPの仮想マシンの仕組み・マシンタイプと料金モデル・採用判断を実装者目線で解説

Compute Engineは、Google Cloudのインフラ上で仮想マシン(VM)を起動して使うIaaS型のサービスです。この記事では、用途別に分かれたマシンファミリーとvCPU・メモリを自由に決めるカスタムマシンタイプの仕組み、秒単位課金に継続利用割引・確約利用割引・Spot VMが乗る料金構造、ホストメンテナンスでもVMを止めないライブマイグレーションといった要素を一次情報で整理します。AWSのAmazon EC2やサーバーレスのCloud Run、マネージドKubernetesのGKEとの使い分け、そしてCompute Engineを採用すべき条件と見送るべき場面まで、構成設計で迷う論点を数値で示します。

まとめ:Compute Engineのマシンタイプ・料金と採用判断の要点

Compute Engineは、Google Cloud上でOSごと自分で握れる仮想マシンを秒単位で借りられるIaaSで、AWSでいえばAmazon EC2に当たる基盤サービスです。まず決めるのはマシンタイプで、汎用・演算特化型・メモリ特化型・アクセラレータ型というマシンファミリーから用途に合うシリーズを選び、事前定義タイプでは形が合わなければvCPUとメモリを任意に指定するカスタムマシンタイプを使います。ストレージは永続ディスクやローカルSSDを付け替え、水平スケールはマネージドインスタンスグループで台数を自動増減させる構成です。

料金は秒単位のオンデマンドが基準で、そこへ月内の稼働割合で自動適用される継続利用割引、1年・3年の確約と引き換えの確約利用割引、中断を許容する代わりに単価を大きく下げるSpot VMという3系統の割引が乗ります。コンテナを動かしたいだけならCloud Run、KubernetesならGKE、AWS前提ならAmazon EC2という選択肢もあり、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて判断してください。

Compute Engineの仮想マシンとマシンタイプの仕組みを理解する

Compute Engineを設計に落とすには、どんなVMを・どのストレージで・どう増減させるかという三つの軸を押さえます。IaaSという提供モデルの上で、仮想マシンそのものの概念を前提に読むと構造が整理できます。

用途別のマシンファミリーとシリーズ・世代でVMの性格が決まる

Compute EngineのVMは、まずマシンファミリーで性格が分かれます。汎用ファミリーはコストと性能のバランス型で、E2は低コスト志向、N系(N2・N4など)は汎用の主力、C4は高い演算性能を狙う世代です。これに加えて、CPU性能に振った演算特化型(compute-optimized・C2・C4系)、大容量メモリを要するインメモリ処理向けのメモリ特化型(memory-optimized・M系)、GPUやTPUを載せるアクセラレータ型(accelerator-optimized・A系・G2)があります。各ファミリーはシリーズ・世代・プロセッサでさらに細分化され、機械学習の学習や推論、SAPのような大規模インメモリDB、Web/APIの汎用ワークロードといった用途ごとに選ぶ設計です。まず用途からファミリーを決め、その中で世代とサイズを選ぶ順序で考えると迷いません。

マシンファミリー 代表シリーズ 向く用途
汎用 E2・N2・N4・C4 Web/API・汎用サーバー
演算特化型 C2・C4 高CPU負荷・バッチ演算
メモリ特化型 M系 インメモリDB・大容量メモリ
アクセラレータ型 A系・G2 GPU/TPUでのAI学習・推論

事前定義マシンタイプとカスタムマシンタイプをどう使い分けるか

マシンタイプには、vCPUとメモリの組み合わせが決められた事前定義タイプと、両者を任意に指定するカスタムマシンタイプがあります。事前定義タイプは選ぶだけで済む反面、必要なメモリに対してvCPUが過剰になるといった無駄が生じがちです。カスタムマシンタイプはワークロードの実測値に合わせてvCPUとメモリを刻めるため、余剰リソースへの支払いを削れます。ただしカスタムには一律の追加料金(プレミアム)が乗るため(2026年7月時点のGoogle Cloud公式)、事前定義で形がぴったり合うならそちらが割安です。実測でメモリ偏重やCPU偏重が明確なワークロードはカスタム、標準的な比率で足りるなら事前定義、という切り分けが起点になります。

永続ディスク・イメージとマネージドインスタンスグループの役割

VMに付けるストレージは、ネットワーク接続の永続ディスク(Standard/Balanced/SSD/Extreme)や高スループットのHyperdisk、VMに直結して高速だが揮発性のローカルSSDから選びます。起動元は公開イメージや、自社の構成を焼き込んだカスタムイメージで、インスタンステンプレートに設定をまとめておけば同じ構成のVMを何台でも量産できるのが利点です。台数を需要に合わせて増減させるのがマネージドインスタンスグループ(MIG)で、テンプレートを元にオートスケーラーがCPU使用率などの指標でVMを自動追加・削減し、ヘルスチェックで異常なVMを自動で入れ替えます。単発のVMではなく、テンプレート+MIGで水平スケールと自己修復を前提に組むと、本番運用が安定します。

Compute Engineの料金モデルと割引・付帯コストを実務目線で押さえる

Compute Engineのコストは、秒単位のオンデマンド料金という基準に、3系統の割引と付帯コストが重なって決まります。割引の効かせ方を設計に織り込むと、同じ構成でも総額が変わります。

秒単位のオンデマンド課金に3系統の割引を重ねる料金設計の考え方

基準となるオンデマンドは、VMの稼働に対して秒単位(1分の最低課金)で課金されます。ここへ乗る割引は三つです。継続利用割引(Sustained Use Discounts)は、対象VMを月内で長く動かすほど自動で適用される仕組みで、申請不要で単価が下がります(E2はこの割引が価格へ織り込み済み)。確約利用割引(Committed Use Discounts)は、1年または3年の利用を確約する代わりにリソースベースで最大57%程度の割引を受けられ、常時稼働の土台に効かせます。Spot VMは、Googleの余剰キャパシティを大幅な割引で使う代わりに、キャパシティが必要になると中断される方式で、中断に耐えるバッチや検証環境向けです。常時稼働は確約利用割引、断続的で止まってよい処理はSpot、というように稼働の性格ごとに割引を割り当てるとコストを削れます。

料金・割引 適用の条件 向くワークロード
オンデマンド 秒単位(申請不要) 変動が読めない稼働
継続利用割引 月内の稼働割合で自動 月の多くを稼働するVM
確約利用割引 1年/3年の確約 常時稼働の土台
Spot VM 中断を許容 止まってよいバッチ・検証

ライブマイグレーションを前提にした可用性とゾーン分散の設計の勘所

Compute Engineの特徴の一つが、ホスト側の計画メンテナンス時にVMを別の物理ホストへ無停止で移すライブマイグレーションです。既定の動作として、ハードウェア更新やパッチ適用の裏でVMが移動するため、メンテナンスのたびにVMを落とす手間を避けられます(Spot VMなど一部の構成は対象外)。可用性をさらに上げるなら、VMを複数ゾーンへ分散配置し、前段にCloud Load Balancingを置いてMIGで台数を維持する構成が定石です。単一ゾーンに1台だけ置く構成はゾーン障害に弱いため、本番はゾーン分散とロードバランサ、自己修復を前提に組みます。

コンピューティング費だけでは読み切れない付帯コストの見積もり方

VMの料金だけを見積もると総額を外します。VMに付ける永続ディスクやローカルSSDのストレージ費、外部公開に使うCloud Load Balancing、そして下り(外部)通信やリージョン間・ゾーン間のデータ転送料が別に積み上がるためです。停止したVMでも、確保したままの永続ディスクや予約済みの外部IPには課金が続く点も見落としがちです。使っていないディスクや外部IP、ロードバランサを棚卸しし、通信の多いVMは同一リージョンへ寄せて転送料を抑えると、請求の想定外を減らせます。VM単価の割引と付帯コストの削減は別の作業として、両方を設計に入れておくのが実務です。

Compute Engineの採用条件とEC2・Cloud Run・GKEの使い分け

ここでは判断を言い切ります。Compute EngineはOSごと自由に握れる強力な基盤ですが、その分だけOSやミドルウェアの運用責任を自社が負います。自社システムのどこにCompute Engineを差し込むかを、条件付きで見極めてください。

Compute Engineの採用が効くワークロードの具体条件

採用が効くのは、OSレベルの制御が要る、既存のオンプレVMやサーバーをそのままGoogle Cloudへ移す(リフト&シフト)、特定のミドルウェアやライセンス条件でコンテナ化しづらい、GPUを使うAI学習やHPCを回す、といった条件が重なるときです。とくに継続利用割引やSpot VMを効かせられる常時稼働・大規模並列の土台では、VMを直接持つコスト効率が出ます。こうしたGoogle Cloud上のインフラを自社に取り入れるなら、AWS・Google Cloud・Azureを横断したクラウドインフラ構築の相談窓口で、マシンタイプの選定やスケール設計、割引の効かせ方を含めた運用体制の妥当性を相談するとよいでしょう。

Amazon EC2・Cloud Run・GKEへ寄せるべき場面の見極め

クラウドの選択がAWS前提なら、同じIaaSでもAmazon EC2が土俵になります。Compute EngineとEC2はどちらもOSを自分で握るVMを提供しますが、マシンタイプの体系や課金の刻み、周辺サービス連携がクラウドごとに異なり、既存資産とチームの習熟がどちらへ寄っているかが選定の軸です。一方、コンテナを動かしたいだけでVMもOSも持ちたくないなら、リクエスト単位で自動スケールするCloud Runが向きます。Kubernetesでコンテナ群をオーケストレーションしたいなら、ワーカーノードにCompute Engineを使うGoogle Kubernetes Engine(GKE)が選択肢です。OSまで握る必要があるならCompute Engine、コンテナで足りるならCloud RunやGKE、という分岐が実務の起点になります。

Compute Engineを見送るべき場面と運用ではまりやすい失敗

見送るべきなのは、ステートレスなWebアプリやAPIをただ動かしたいだけの用途、OSやパッチを運用できる人員がいない小規模チーム、そして断続的にしか使わない処理に常時稼働のVMを立てておく構成です。これらをCompute Engineで抱えると、運用責任とアイドル時間の課金が回収できません。失敗パターンとして多いのは、割引を検討せずオンデマンドのまま常時稼働させて単価を取りこぼす、停止済みVMのディスクや外部IPを放置して課金を垂れ流す、下り・リージョン間通信を意識せず転送料を積み上げる、といった構成です。稼働の性格に割引を割り当て、不要リソースを棚卸しし、通信を局所化する前提で組めば、Compute Engineの自由度を過剰投資なしに使えます。要件がCloud Runで足りるなら、無理にVMを持つ必要はありません。

よくある質問

Compute Engineの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Compute EngineとAmazon EC2は何が違いますか?

どちらもクラウド上でOSを自分で握る仮想マシンを提供するIaaSで、VMを直接運用するという使い勝手は共通です。違いはマシンタイプの体系や課金の刻み、周辺サービスとの連携先で、Compute EngineはGoogle CloudのVPC・永続ディスク・Cloud Load Balancingと、EC2はAWSのVPC・EBS・ELBと統合します。選定は、既存インフラがGCPかAWSか、チームの習熟がどちらへ寄っているかで決めるのが実務的です。

Compute Engineの料金はどう決まりますか?

基準は稼働に対する秒単位(1分の最低課金)のオンデマンド料金で、ここへ3系統の割引が乗ります。月内で長く動かすほど自動で効く継続利用割引、1年・3年の確約でリソースベース最大57%程度になる確約利用割引、中断を許容する代わりに大幅に安いSpot VMです。これとは別に永続ディスクなどのストレージ費、ロードバランサ、下り・リージョン間通信のデータ転送料が積み上がるため、VM単価だけでなく付帯コストまで含めて見積もります。

事前定義マシンタイプとカスタムマシンタイプはどちらを選ぶべきですか?

標準的なvCPUとメモリの比率で足りるなら事前定義タイプが割安です。ワークロードがメモリ偏重やCPU偏重で、事前定義だと片方が過剰になる場合はカスタムマシンタイプでvCPUとメモリを実測値へ刻むと余剰への支払いを削れます。ただしカスタムには一律の追加料金が乗るため、実測で偏りが明確なときにカスタムを選ぶのが基本です。

ライブマイグレーションとは何ですか?

Googleがホスト側の計画メンテナンス(ハードウェア更新やパッチ)を行う際に、稼働中のVMを別の物理ホストへ無停止で移す既定の動作です。これにより、メンテナンスのたびにVMを落とす必要がなくなります。ただしSpot VMなど一部の構成は対象外のため、可用性はVMのゾーン分散やロードバランサ、マネージドインスタンスグループの自己修復と合わせて設計します。

Compute Engineでオートスケールはできますか?

マネージドインスタンスグループ(MIG)を使えば可能です。インスタンステンプレートを元に、オートスケーラーがCPU使用率やロードバランサの負荷といった指標でVMを自動追加・削減し、ヘルスチェックで異常なVMを入れ替えます。単発のVMではなく、テンプレートとMIGを前提に組むと、需要変動への追従と自己修復を同時に得られます。

関連記事

資料請求

RELATED POSTS 関連記事