Cloud Functions / Cloud Run

解決する課題

サーバーを常時立てておくのはもったいない/面倒 → リクエストやイベント時だけ動かす
急なスパイクに自動でスケールしてほしい（リクエスト数に応じて水平スケール）
「Cloud Storage にファイルが上がったら処理」「Pub/Sub にメッセージが来たら処理」を接着剤的に書きたい
既存の Docker コンテナをそのままサーバーレスで動かしたい（→ Cloud Run）

主要概念と用語

関数 / サービス: 実行単位。Cloud Run functions では「関数」、Cloud Run では「サービス（リビジョン）」
トリガー / イベントソース: HTTP、Pub/Sub、Cloud Storage、Eventarc 経由の各種イベント
Eventarc: GCP の各サービスや監査ログ（Cloud Audit Logs）からのイベントを CloudEvents 形式で配信する基盤
エントリポイント: 入口の関数名（HTTP 関数 / CloudEvent 関数）
サービスアカウント: 関数/サービスの実行 ID。IAM 権限はこれに付与する
同時実行（Concurrency）: 1 インスタンスが同時に捌くリクエスト数。Cloud Run は 最大 1000、Cloud Functions 第1世代は常に 1
コールドスタート: 新しいインスタンスの起動・初期化にかかる初回遅延
最小/最大インスタンス数: スケールの下限（常駐させて温める）と上限

仕様・制限・クォータ

最大実行時間（タイムアウト）: Cloud Run / Cloud Functions 第2世代の HTTP は最大 60 分、イベント駆動は最大 9 分。第1世代は最大 9 分
メモリは構成可能（第2世代 / Cloud Run は 最大 32GiB、vCPU は最大 8）。メモリと CPU を独立に設定可能
同時実行: Cloud Run / 第2世代は 1 インスタンスあたり最大 1000 リクエストを同時処理できる（第1世代は 1 リクエスト/インスタンス）
リクエストボディ/レスポンスサイズの上限、/tmp（インメモリ tmpfs）の一時領域あり
最大インスタンス数・CPU などはプロジェクト/リージョン単位のクォータに従う（引き上げ可）

内部の仕組み

リクエストやイベントが届くと、GCP はコンテナイメージからインスタンスを起動（＝コールドスタート）し、処理後しばらくウォーム状態で再利用します。同時に多くのリクエストが来れば、同時実行数 を超えた分だけインスタンスを並列に増やして水平スケールし、トラフィックが無くなれば最小インスタンス数（既定 0）まで縮小します。Cloud Functions 第2世代は内部的に Cloud Run + Eventarc の組み合わせで実現されています。

コールドスタート対策

低レイテンシを安定させたいなら 最小インスタンス数（min-instances）を 1 以上にして常時温めておく。さらに Cloud Run では起動高速化のため **CPU を「リクエスト処理中のみ割り当て」か「常時割り当て」**かを選べます。重い初期化はグローバルスコープで一度だけ行うのが定石です。

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

ステートレスに作り、状態は Firestore / Cloud SQL / Cloud Storage へ
小さく・速く（依存を減らし初期化を軽く。重い初期化はグローバルスコープへ）
非同期＋Pub/Sub で疎結合化。失敗時は Pub/Sub の再試行とデッドレタートピックで退避
秘密情報は環境変数に直書きせず Secret Manager を参照（環境変数やボリュームとしてマウント）
VPC 内リソース（Cloud SQL のプライベート IP 等）へは Serverless VPC Access コネクタ / Direct VPC egress 経由で接続

運用・監視

ログは Cloud Logging、メトリクスは Cloud Monitoring、分散トレースは Cloud Trace
監視メトリクス例: リクエスト数、リクエストレイテンシ、インスタンス数、コンテナ CPU/メモリ使用率、エラー率
スロットリングや 429 多発時は、最大インスタンス数の上限やダウンストリーム（DB の最大接続数など）の限界を確認
Cloud Run はトラフィック分割でカナリア/段階的ロールアウトが可能（リビジョン間で % を配分）

コスト

リクエスト数＋リソース時間（CPU/メモリの割り当て時間）＋ネットワーク下りで課金されます。アイドル時（0 インスタンス）は実行課金が発生しないのが特徴です。

課金要素	内容	ポイント
リクエスト数	呼び出し回数に対する課金	毎月の無料枠あり
CPU 時間	割り当て CPU × 実行時間（vCPU 秒）	100ms 単位で計測
メモリ時間	割り当てメモリ × 実行時間（GiB 秒）	メモリと CPU を独立設定
最小インスタンス	常駐分のアイドル課金	温める代わりに常時課金が発生
ネットワーク下り	外部への送信データ量	同一リージョン内通信は安価/無料

CPU を「リクエスト処理中のみ割り当て」にするとアイドル中の CPU 課金を抑えられ、イベント駆動や低トラフィック用途で割安になります。

セキュリティ

最小権限のサービスアカウントを割り当てる（既定のサービスアカウントは権限過多になりやすいので専用を作る）
受信は IAM で認証必須にし、未認証の公開呼び出し（allUsers への run.invoker 付与）は必要時のみ
公開せず内部限定にしたい場合は Ingress 設定（内部のみ / ロードバランサ経由のみ） を利用
保存・転送データは既定で暗号化。鍵を自分で管理するなら Cloud KMS（CMEK）

アンチパターン

サービスアカウントの鍵（JSON キー）をコンテナや環境変数に埋め込むのは NG。Cloud Run / Cloud Functions では実行サービスアカウントの ID が自動で利用可能なので、キーをハードコードせずメタデータサーバー経由でトークンを取得しましょう（AWS の IAM ロール相当の考え方）。

観点	Cloud Functions / Cloud Run	AWS Lambda
位置づけ	GCP のサーバーレス実行基盤	AWS のサーバーレス代表
デプロイ単位	関数またはコンテナイメージ	関数（zip / コンテナイメージ）
最大実行時間	HTTP 60分 / イベント 9分（第2世代）	15分
同時実行	1 インスタンスで最大 1000（Cloud Run）	1 インスタンス 1 リクエスト
イベント基盤	Eventarc / Pub/Sub	EventBridge / SQS など
権限付与	サービスアカウント + IAM	IAM 実行ロール
秘密管理	Secret Manager	Secrets Manager / SSM

ハンズオン / CLI例

# HTTP トリガーの関数（第2世代）をデプロイ（Node.js）
gcloud functions deploy hello-http \
  --gen2 \
  --runtime=nodejs20 \
  --region=asia-northeast1 \
  --source=. \
  --entry-point=helloHttp \
  --trigger-http \
  --allow-unauthenticated

# Cloud Storage への書き込みをトリガーにする（Eventarc 経由）
gcloud functions deploy on-file-upload \
  --gen2 \
  --runtime=nodejs20 \
  --region=asia-northeast1 \
  --source=. \
  --entry-point=onUpload \
  --trigger-event-filters="type=google.cloud.storage.object.v1.finalized" \
  --trigger-event-filters="bucket=my-input-bucket"

# 既存のコンテナイメージを Cloud Run にデプロイ
gcloud run deploy my-api \
  --image=asia-northeast1-docker.pkg.dev/my-project/repo/my-api:latest \
  --region=asia-northeast1 \
  --min-instances=1 \
  --concurrency=80 \
  --no-allow-unauthenticated

# デプロイ済み関数を手動でテスト実行
gcloud functions call hello-http --gen2 --region=asia-northeast1