【GoogleCloud/GCP】Cloud Run のサービスのスケーリングの設定について、インスタンスの最小数は、どのような設定にすべきか？
まさぴょん🐱Cloud Run のインスタンスの最小数について📝
Cloud Run が ゼロからスケールアップする時間（いわゆる⾃動起動 / cold start）にどれだけ遅延を許容できるか と、アイドル中の課⾦をどこまで許容できるか のトレードオフを軸に決めます。
以下のフレームワークで検討すると、ほとんどのサービスで妥当な値に落ち着きます。
1. Cloud Run のスケールと min instances の役割
- デフォルトではリクエストがないときに インスタンス数 0 までスケールインし、次のリクエスト到着時に新しいコンテナを起動します。
- min-instances を 1 以上にすると “ウォーム” なインスタンス を常駐させ、cold start をほぼ解消できます。
- ウォーム状態でも vCPU には約 10 % の割引レート、メモリには通常レートが課⾦されます。
2. 判断基準
| 観点 | チェックポイント | 推奨 min |
|---|---|---|
| レイテンシ許容度 | 初回リクエストで 1–10 秒遅延しても良い？ | YES → 0 NO → 1 以上 |
| トラフィック頻度 | 全くリクエストが来ない時間帯がある？ | はい → 0 または 時限的に 0 いいえ → 1 以上 |
| 1 インスタンスでの同時処理数 |
concurrency を高く設定できるサービスなら 少ない min で良い |
|
| コスト許容度 | 1 vCPU/512 MiB を 24 h × 30 ⽇ウォームにした場合 ≒ 9.72 USD/月（free tier 控除後 約 8.4 USD） (Google Cloud, Google Cloud, pump.co) | 許容→ 1 以上 / 不許容→ 0 |
まさぴょん🐱概要
Cloud Run では 最小インスタンス数（min instances） を 0 にするとアイドル時は完全にスケールダウンし、コストは抑えられますがリクエストが来たときに コールドスタート が発生します。逆に min≥1 にすると常時ウォームなインスタンスが維持され、レイテンシは下がりますがアイドル状態でも vCPU・メモリの idle 課金 が発生します。
したがって 「許容できる起動遅延」と「アイドル時コスト」のトレードオフ を基準に、サービスごとに次のように決めるのが実務的な指針です。
1. 最小インスタンス設定を考慮すべき前提
| 観点 | min=0 (デフォルト) | min≥1 |
|---|---|---|
| コールドスタート | 数秒〜数十秒発生 | ほぼゼロ |
| アイドル時コスト | 課金なし | vCPU+RAM を 1 / 10 価格で課金 |
| SLA/UX | レイテンシ許容なら OK | サブ秒応答が必須なら必須 |
| 同時リクエスト | スパイク時は自動スケール | ウォーム分 × concurrency までは即時処理 |
Cloud Run は 15 分以内に不要と判断したインスタンスを自動終了します。最小数を超える分は従来どおりオートスケールします。
2. 決定フロー
2.1 レイテンシ要件
- >1 秒許容: min instances = 0 + Startup CPU Boost を併用するとほとんどの API で数秒以内に応答できます。
- サブ秒必須 (Webhook、チャット、決済コールバックなど): min instances ≥ 1 が安全。
2.2 トラフィックパターン
-
昼夜で大きく変動: Cloud Scheduler +
gcloud run services update --min-instances Nで営業時間だけ 1→0 に切替える運用も可能。 - 常時低〜中程度の負荷: concurrency を上げて (例: 40) min=1 のまま維持するとコストを抑えつつレイテンシを確保できます。
2.3 コスト試算
東京リージョン (Tier 1) で 1 vCPU / 512 MiB, min=1 の場合
$0.00000250 × vCPU-sec + $0.00000250 × GiB-sec
≒ $0.00000376 / 秒 ≒ ¥31/月
（30 日 24 h アイドルと仮定、為替 ¥150/USD）
この程度で UX が向上するなら min=1 は十分ペイします。
Medium の試算でも同規模で ≈$50/月 と報告されています。
3. 代表的な設定パターン
| ユースケース | 推奨 min | 補足 |
|---|---|---|
| バッチ API / 管理ツール | 0 | 月数百リクエスト。コスト優先 |
| 一般的な REST API | 0 or 1 | 体感 UX に合わせ A/B テスト |
| Webhook／チャット Bot | 1 | 外部サービスのタイムアウト短い |
| ゲームマッチング／音声配信 | 2〜N | 台数＝同時ゾーン障害許容量 |
| GPU 推論 (vLLM 等) | min≥1 + Instance-based billing | GPU 起動が数分かかるため必須 |
4. 設定方法
# 既存サービスを 1 台維持に変更
gcloud run services update my-api \
--min-instances=1 \
--region=asia-northeast1
YAML なら spec.template.metadata.annotations."autoscaling.knative.dev/minScale": "1" でも可。
5. まとめとベストプラクティス
-
まずは min=0 でデプロイし、実運用の cold start latency を計測。
-
SLA を満たせない場合だけ min を 1 ずつ増やし、Cloud Monitoring の p95 レイテンシ が収まる点を探る。
-
アイドル時コストが気になる場合は
- 営業時間帯だけ min を上げ下げ
- Recommender の 最適化提案 を活用
-
余裕があれば Committed Use Discount を購入して idle 課金をさらに 17–45 % 削減。
このように 最小インスタンス数は「0 → 計測 → 必要に応じて 1+」という漸進的チューニング が最も安全でコスト効率も高い運用になります。