【Google Cloud/GCP】Google Compute Engineについて📝
まさぴょん🐱【Google Cloud/GCP】Google Compute Engineについて📝
まさぴょん🐱Cloud Run と Compute Engineの違いは？
ざっくり一言
| 観点 | Cloud Run | Compute Engine |
|---|---|---|
| サービス種別 | フルマネージド Serverless コンテナ | IaaS (VM インスタンス) |
| 管理責任 | OS パッチ・スケール・高可用性は Google が担当 | OS／ミドルウェア／スケール戦略まですべて 利用者が担当 |
| スケーリング | リクエストに応じて 0→n まで瞬時に自動 | オートスケール可だが最小台数>0（常時課金） |
| プロトコル | HTTP(s), gRPC, WebSocket が前提 | 任意 (TCP/UDP/ICMP など何でも) |
| 課金モデル | 従量課金：リクエスト実行時間・CPU/メモリ秒課金 | リソース課金：起動中の vCPU・RAM・Disk 分を秒単位請求 |
| 典型ワークロード | API/バックエンド、Webhook、バッチ Job（Cloud Run Jobs） | 長時間処理、特定 OS/カーネル、GPU HPC、ステートフル DB など |
それぞれの特徴
Cloud Run
- コンテナを置くだけで HTTP エンドポイントが完成。Knative ベースの完全マネージドで、インフラ運用は不要です。(Google Cloud)
- コールドスタート後でも 数秒でスケールイン／アウトし、リクエストがゼロになると課金もゼロになります。
- Gen 2 以降で GPU・サイドカー複数コンテナ・Direct VPC Egress が GA、Gemini Cloud Assist など AI 支援機能も登場（2025 年 4 月〜5 月）。(Google Cloud)
Compute Engine
- いわゆる仮想マシン (KVM)。好きな OS、カーネル、ネットワークポート を自由に設定可能。(Google Cloud)
- ゾーンやマシンタイプを選んで起動し、パッケージ更新・セキュリティパッチ・スケール戦略は自前。
- 2025 年 5 月のリリースノートでは Intel CPU の脆弱性パッチや MIG の “自動修復停止” オプションなど、IaaS ならではの細かな運用機能が追加されています。(Google Cloud)
使い分けの目安
| 選定クエスチョン | おすすめ |
|---|---|
| HTTP／gRPC の stateless API を手軽に運用したい？ | 🎯 Cloud Run |
| リクエストがない時間はゼロ円にしたい？ | 🎯 Cloud Run |
| 特定 OS イメージ／Kernel Module／ライセンス付きソフトが必要？ | 🎯 Compute Engine |
|
長時間バッチ・機械学習トレーニングを GPU で回したい？ (コスト最適化のため 24h 起動しっぱなしでも OK) |
🎯 Compute Engine ※Cloud Run でも GPU が GA になったが、常時オン用途なら VM の方が料金体系がフィット |
| フルカスタムのネットワーク（カスタムルーティング、UDP、VPN 終端など）が要る？ | 🎯 Compute Engine |
コストと運用の違い
-
課金単価の考え方
- Cloud Run は リクエスト単位＋実行時間、待機中は 0 円（Committed Use 割引あり）。(Google Cloud)
- Compute Engine は VM 起動中ずっと課金（秒単位）。長期利用なら Sustained/Committed Use 割引が効きます。(Google Cloud)
-
SRE/運用負荷
- Cloud Run は負荷テスト & サービス設定に集中できる反面、ssh で入ってチューニングする類の操作はできません。
- Compute Engine は Cloud Ops ツールでモニタリングしつつ、自身で構成管理（Ansible/Puppet など）が必要。
まとめ
- 運用を最小化しながら HTTP API を素早く出したい → Cloud Run
- VM をフルにカスタマイズして OS レベルから面倒を見たい／見られるチームがいる → Compute Engine
もし「React/Vite＋Hono API＋PostgreSQL」を GCP に載せる前提なら、
*Hono API ➜ Cloud Run、
*React/Vite ➜ Cloud Run または Cloud Storage + Cloud CDN、
*PostgreSQL ➜ Cloud SQL（または AlloyDB）
のような “ほぼフルマネージド構成” がシンプルです。Compute Engine を選ぶのは OS 制約や恒常的な長時間ジョブがある場合のみ、というイメージです。
気になる構成やコスト比較があれば、具体的なワークロード要件を教えてください。さらに詳しくプランニングをお手伝いします！
まさぴょん🐱Compute Engineでは、Docker ComposeのContaierをまとめてDeployできますか？
Compute Engine はただの VM なので、OS に Docker と Docker Compose を入れれば docker compose up -d で複数コンテナを一括起動できます。一方で GCE 自体に docker-compose.yml を読み込んでくれるマネージド機能はなく、スケールや更新はすべて自前運用になります。以下に代表的な方法・注意点をまとめます。
1. そもそも Compute Engine が提供する “コンテナ機能” の限界
-
gcloud compute instances create-with-container …やコンソールの 「Deploy container」 ボタンは 1 つのイメージしか指定できません。Compose 形式のマルチサービス構成は対応外です(Google Cloud)。 - Container-Optimized OS (COS) でも同様で、単一コンテナなら GUI/CLI だけで起動できますが、複数コンテナを走らせるには cloud-init などで自分で記述する必要があります(Google Cloud)。
2. 一般的な Linux イメージでの手順（Ubuntu/Debian など）
| ステップ | コマンド例 | 補足 | |
|---|---|---|---|
| VM 作成 | gcloud compute instances create my-vm --zone=asia-northeast1-b --machine-type=e2-small --image-family=debian-12 --image-project=debian-cloud --tags=http-server |
必要なファイアウォール ルールも追加 | |
| Docker/Compose インストール | ```curl -fsSL https://get.docker.com | sudo sh sudo apt-get install -y docker-compose-plugin``` | Compose v2 は “plugin” パッケージとして同梱されるディストリが多い |
| アプリ準備 | git clone … && cd app && docker compose pull |
イメージを Artifact Registry から pull する場合は docker login で gcloud helper を使う |
|
| 自動起動 | メタデータに startup-script を設定し、docker compose up -d を実行 |
GCE は起動時にシェルスクリプトを走らせられる(Google Cloud) |
ポイント
- Compose はローカルマシンと同じ挙動。VM を落とすと全部停止するので、永続ボリュームを使う DB などは Cloud SQL へ逃がすのが安全。
- VM を追加で複製したい場合は、Docker/Compose をインストールする Startup Script を含んだインスタンステンプレートを作り、Managed Instance Group にするのが定石。
3. Container-Optimized OS で使う場合
COS は Docker デーモン入りの軽量 OS ですが Compose は同梱されていません(Google Cloud)。
3-1. Compose v2 プラグインの配置
sudo curl -sSL \
https://github.com/docker/compose/releases/download/v2.23.3/docker-compose-linux-x86_64 \
-o /var/lib/google/docker-compose
sudo chmod +x /var/lib/google/docker-compose
mkdir -p ~/.docker/cli-plugins
ln -s /var/lib/google/docker-compose ~/.docker/cli-plugins/docker-compose
docker compose version
上記のように /var/lib/google 以下にバイナリを置き、CLI プラグインとしてリンクすれば動作します(Server Fault)。ファイルシステムが read-only な部分が多い COS では、このディレクトリが書き込み可能という点に注意してください。
3-2. 起動方法
- SSH で入って
docker compose up -d。 - または cloud-init の write_files + runcmd セクションに上記インストール手順と
compose upを記述し、VM 作成時に user-data として渡す。これで無人デプロイが可能です(Google Cloud)。
4. 運用上の注意と限界
- 横方向スケールやローリング更新は自前で書く必要があります。Compose は単一ノード前提のツールであり、VM をまたいだオーケストレーションは行いません(Stack Overflow, Reddit)。
-
create-with-containerで作った VM や Container-optimized OS の 単一コンテナ モードは、自動再起動や MIG 更新に対応しても Compose までは面倒を見てくれません。 - 本番で高可用性が必要な場合は Cloud Run でサービスを分割するか、GKE（Kubernetes） に移行した方が安全です。Compute Engine の「コンテナ」機能はあくまで簡易版であり、Kubernetes こそが Google の推奨スケジューラであると公式にも記載されています(Google Cloud)。
5. まとめ
| 選択肢 | 使いどころ | 利点 | 注意点 |
|---|---|---|---|
| Compute Engine + Ubuntu/Debian + Docker Compose | 小～中規模、単一リージョン、既存 Compose をそのまま持って行きたい | インストールが簡単、ローカルと同じ操作性 | スケール／更新／障害復旧は自前 |
| Compute Engine + Container-Optimized OS + Compose プラグイン | 軽量 OS が欲しい、セキュリティ更新を自動で受け取りたい | OS が自動パッチ、最小構成で高速起動 | Compose を手動配置、ファイルシステム制限 |
| Cloud Run / GKE | マネージドスケール、ゼロダウンタイム更新が必要 | オートスケール、LB、IAM、Cloud Logging が統合 |
docker-compose.yml は直接使えず、サービスごとにイメージを分割 |
結論
「VM に SSH してdocker compose up -d」は可能。ただしそれは “フル自己管理” モードです。
スケールや可用性をクラウドに任せたい場合は、Compose をばらして Cloud Run/GKE へ載せ替えることを検討してください。
参考文献
Compute Engine 単一コンテナ機能(Google Cloud) • COS で複数コンテナ (cloud-init)(Google Cloud) • COS とは (Google Cloud) • Compose プラグイン手順(Server Fault) • Compose を VM で使うべきとの回答(Stack Overflow) • Reddit での推奨事項(Reddit) • Linux VM の startup-script (Google Cloud) • Containers on Compute Engine 概要(Google Cloud) • StackOverflow startup-script 例(Stack Overflow) • コンテナ起動の高度設定ガイド(Google Cloud)