「Cloud Runでトラフィックの急増に対応できるか不安」「ゼロスケールのコールドスタートでユーザー体験が悪化している」「請求額が予想以上に高い」
サーバーレスコンテナプラットフォームであるCloud Runは、正しく設定すればゼロからの自動スケールを実現できますが、設定を間違えるとコストが爆発したり、パフォーマンスが低下したりします。
本記事では、Cloud Runのオートスケーリングの仕組みから、同時実行制御・インスタンス設定・コールドスタート対策・コスト最適化まで、本番運用に必要な知識を網羅的に解説します。
この記事を3秒でまとめると
- Cloud Runはリクエスト数に応じてインスタンスを0〜1,000まで自動スケールする
- 同時実行数(concurrency)の設定がパフォーマンスとコストの鍵を握る
- 最小インスタンス数を1以上にするとコールドスタートを回避できる（ただしコスト増）
Cloud Runオートスケーリングの仕組み
スケーリングモデルの基本
Cloud Runのオートスケーリングは、受信リクエスト数に基づいてインスタンス（コンテナ）の数を自動調整します。
リクエスト数 → スケーラー → インスタンス数を決定
↓
[最小インスタンス] ≤ 実行数 ≤ [最大インスタンス]スケーリングの判断要素:
| 要素 | 説明 |
|---|---|
| 同時実行数(concurrency) | 1インスタンスが同時に処理するリクエスト数 |
| CPU使用率 | インスタンスのCPU使用率（ターゲット: 60%） |
| リクエストレート | 秒あたりのリクエスト到着数 |
| 最小インスタンス | アイドル時も維持するインスタンス数 |
| 最大インスタンス | スケールアウトの上限 |
ゼロスケール（Scale to Zero）
Cloud Runの最大の特徴は、リクエストがないときはインスタンスがゼロになることです。これにより、使っていない時間の課金が発生しません。
トラフィックなし → インスタンス数: 0（課金なし）
↓ リクエスト到着
コールドスタート → インスタンス数: 1（課金開始）
↓ トラフィック増加
スケールアウト → インスタンス数: N（需要に応じて増加）
↓ トラフィック減少
スケールイン → インスタンス数: 0（再びゼロに）同時実行数（Concurrency）の最適化
concurrencyとは
concurrencyは、1つのインスタンスが同時に処理するリクエストの最大数です。この設定がスケーリング特性を大きく左右します。
# concurrencyの設定
gcloud run deploy my-service \
--image gcr.io/my-project/my-app:latest \
--concurrency 80 \
--region asia-northeast1concurrency値の選び方
| アプリケーションタイプ | 推奨concurrency | 理由 |
|---|---|---|
| CPU集中型（画像処理等） | 1〜4 | 1リクエストでCPUを占有 |
| I/O集中型（API呼び出し） | 80〜250 | 待機中にCPUが空く |
| 一般的なWebアプリ | 50〜100 | バランス型 |
| WebSocket/ストリーミング | 100〜1000 | 長時間接続で待機が多い |
concurrencyが低すぎる場合:
- インスタンス数が不必要に多くなる → コスト増
- コールドスタートの頻度が増える
concurrencyが高すぎる場合:
- 1インスタンスあたりの負荷が高くなる → レスポンス遅延
- OOMKill（メモリ不足）のリスク
最適なconcurrencyの見つけ方
# 負荷テストで最適値を探る（hey / wrk などを使用）
hey -n 10000 -c 50 https://my-service-xxxxx.run.app/api/endpoint
hey -n 10000 -c 100 https://my-service-xxxxx.run.app/api/endpoint
hey -n 10000 -c 200 https://my-service-xxxxx.run.app/api/endpoint判断基準:
- p99レイテンシが許容範囲内（例: 500ms以下）
- エラー率が0.1%未満
- CPUスロットリングが発生しない
インスタンス設定の詳細
最小インスタンス（min-instances）
# 最小インスタンスの設定
gcloud run deploy my-service \
--min-instances 1 \
--region asia-northeast1| 設定値 | 効果 | コスト影響 |
|---|---|---|
| 0（デフォルト） | ゼロスケール有効、コールドスタートあり | 最低 |
| 1 | 常に1インスタンス稼働、コールドスタートほぼなし | +$20-40/月 |
| 3 | 3インスタンス常時稼働、高可用性 | +$60-120/月 |
コールドスタート対策としてmin-instances=1が有効なケース:
- ユーザー向けAPIでレスポンス速度が重要
- WebSocket接続が必要なサービス
- 初回リクエストの遅延が許容できない
最大インスタンス（max-instances）
# 最大インスタンスの設定（コスト保護）
gcloud run deploy my-service \
--max-instances 100 \
--region asia-northeast1注意: 最大インスタンスはコスト保護の安全弁として必ず設定しましょう。設定しないと、DDoS攻撃やバグによる無限ループで予想外の請求が発生する可能性があります。
CPU割り当て設定
Cloud Runには2つのCPU割り当てモードがあります。
# CPU常時割り当て（リクエスト処理外でもCPUを使用可能）
gcloud run deploy my-service \
--cpu-throttling=false
# CPUリクエスト時のみ割り当て（デフォルト）
gcloud run deploy my-service \
--cpu-throttling=true| モード | ユースケース | 料金 |
|---|---|---|
| リクエスト時のみ | 一般的なHTTP API | 安い |
| 常時割り当て | バックグラウンド処理、WebSocket | 高い |
コールドスタートの対策
コールドスタートとは
インスタンスがゼロの状態からリクエストを処理するまでの時間です。
コールドスタートの内訳:
- インスタンスの起動: 100-500ms
- コンテナイメージのプル: 500ms-5s
- アプリケーションの初期化: 100ms-30s（言語・フレームワーク依存）
対策1: イメージサイズの最小化
# ❌ 大きなイメージ（1.2GB → コールドスタート 5-10秒）
FROM node:22
# ✅ 最小イメージ（180MB → コールドスタート 1-2秒）
FROM node:22-alpine| ベースイメージ | サイズ | コールドスタート目安 |
|---|---|---|
| ubuntu:22.04 | 77MB | 2-4秒 |
| node:22-alpine | 180MB | 1-3秒 |
| python:3.12-slim | 150MB | 1-3秒 |
| golang (scratch) | 10-20MB | 0.5-1秒 |
| distroless | 20-50MB | 0.5-1.5秒 |
対策2: スタートアップCPUブースト
# スタートアップ時にCPUを追加割り当て
gcloud run deploy my-service \
--cpu-boostこの設定により、インスタンス起動時に一時的にCPUを追加割り当てし、初期化を高速化します。
対策3: アプリケーション側の最適化
# ❌ リクエストごとにDB接続を作成
def handle_request():
db = create_connection() # 毎回100ms
result = db.query(...)
return result
# ✅ グローバルスコープで接続プールを初期化
db_pool = create_pool(min_size=5, max_size=20) # 起動時に1回だけ
def handle_request():
async with db_pool.acquire() as conn:
result = await conn.query(...)
return resultリビジョンベースのトラフィック管理
カナリアデプロイ
Cloud Runのトラフィック分割機能を使えば、新しいリビジョンへの段階的なロールアウトが可能です。
# 新リビジョンにトラフィックの10%を振り分け
gcloud run services update-traffic my-service \
--to-revisions=my-service-00002=10 \
--region asia-northeast1
# 問題なければ50%に引き上げ
gcloud run services update-traffic my-service \
--to-revisions=my-service-00002=50
# 最終的に100%に切り替え
gcloud run services update-traffic my-service \
--to-revisions=my-service-00002=100ロールバック
問題が発生した場合は、即座に前のリビジョンに戻せます。
# 前のリビジョンに100%のトラフィックを戻す
gcloud run services update-traffic my-service \
--to-revisions=my-service-00001=100 \
--region asia-northeast1コスト最適化戦略
コスト構造の理解
Cloud Runの料金は以下の要素で決まります。
| リソース | 料金 | 無料枠 |
|---|---|---|
| vCPU | $0.00002400/vCPU秒 | 180,000 vCPU秒/月 |
| メモリ | $0.00000250/GiB秒 | 360,000 GiB秒/月 |
| リクエスト | $0.40/100万リクエスト | 200万リクエスト/月 |
コスト最適化のチェックリスト
1. 適切なリソース割り当て
# CPUとメモリの最適化
gcloud run deploy my-service \
--cpu 1 \
--memory 512Mi \
--concurrency 802. ゼロスケールの活用（開発・ステージング環境）
# 非本番環境はmin-instances=0
gcloud run deploy my-service-dev \
--min-instances 0 \
--max-instances 53. リクエストタイムアウトの設定
# タイムアウトを適切に設定（デフォルト300秒は長すぎることが多い）
gcloud run deploy my-service \
--timeout 304. Committed Use Discounts（CUD）
大規模利用の場合、確約利用割引で最大17%のコスト削減が可能です。
月額コスト見積もり
| 規模 | リクエスト/月 | 平均レスポンス時間 | 月額概算 |
|---|---|---|---|
| 小規模 | 100万 | 200ms | $5-15 |
| 中規模 | 1,000万 | 200ms | $50-150 |
| 大規模 | 1億 | 200ms | $500-1,500 |
監視とアラート
Cloud Monitoringとの連携
# アラートポリシーの作成（レスポンス遅延）
gcloud monitoring policies create \
--display-name="Cloud Run High Latency" \
--condition-filter='resource.type="cloud_run_revision" AND metric.type="run.googleapis.com/request_latencies"' \
--condition-threshold-value=1000 \
--condition-threshold-duration=300s監視すべきメトリクス:
request_latencies: リクエストレイテンシ（p50, p95, p99）request_count: リクエスト数container/instance_count: アクティブインスタンス数container/cpu/utilizations: CPU使用率container/memory/utilizations: メモリ使用率
Cloud Monitoringの詳細はGoogle Cloud Monitoring & Loggingを参照してください。
他のGCPサービスとの連携
Cloud SQL + Cloud Run
# Cloud SQL Proxyを使ったDB接続
gcloud run deploy my-service \
--add-cloudsql-instances my-project:asia-northeast1:my-db \
--set-env-vars DB_HOST=/cloudsql/my-project:asia-northeast1:my-dbCloud Pub/Sub + Cloud Run
イベント駆動のスケーリングにPub/Subを組み合わせます。
# Pub/SubトリガーのCloud Runサービス
gcloud run deploy message-processor \
--ingress internal \
--no-allow-unauthenticated
# Pub/SubサブスクリプションをCloud Runに紐付け
gcloud pubsub subscriptions create my-sub \
--topic my-topic \
--push-endpoint=https://message-processor-xxxxx.run.app/processPub/Subの詳細はGoogle Cloud Pub/Sub メッセージングガイドを参照してください。
SES案件でのCloud Runスキルの需要
Cloud RunはGCP案件で最も需要の高いサービスの一つです。
- APIバックエンド: REST/GraphQL APIのサーバーレス運用
- マイクロサービス: コンテナベースのサービス分割
- バッチ処理: Cloud Run Jobsによるスケーラブルなバッチ
- フルスタック: Next.js/Nuxt.jsのSSRデプロイ
まとめ — Cloud Runのスケーリングを制する
Cloud Runのオートスケーリングは強力ですが、デフォルト設定のままでは最適な結果が得られません。
- concurrency: アプリケーション特性に合わせて最適値を設定
- min/max instances: コスト保護とパフォーマンスのバランス
- コールドスタート: イメージ最小化 + スタートアップブースト + アプリ最適化
- トラフィック管理: カナリアデプロイで安全にリリース
- コスト最適化: 環境別の設定 + リソースの適正化
これらの知識は、GCPを使うSES案件で大きなアドバンテージになります。
SES BASEでは、Google Cloud関連のSES案件を多数掲載しています。
関連記事:
