Cloud Run / GKE

解決する課題

• コンテナを本番で安定運用したい（落ちたら再起動、負荷で自動増減）
• サーバー（VM）やクラスターの管理をしたくない → Cloud Run
• アイドル時はコストをゼロにしたい（ゼロスケール）→ Cloud Run
• Kubernetes の API・エコシステム（Helm / Operator / Istio など）を使いつつ、運用は任せたい → GKE
• マイクロサービスをスケーラブルかつ移植性高く動かしたい

主要概念と用語

Cloud Run

• サービス（Service）: HTTPS エンドポイントを持つ常駐型ワークロード。リクエスト駆動で自動スケール
• ジョブ（Job）: 実行して完了する処理（バッチ/データ処理）。エンドポイントは持たない
• リビジョン（Revision）: デプロイごとに作られる不変のスナップショット。トラフィックを割り当ててカナリア/ロールバック
• 同時実行数（concurrency）: 1 インスタンスが同時に捌くリクエスト数（既定 80、最大 1000）。Fargate との大きな違い
• min/max インスタンス: 最小（常時起動でコールドスタート回避）と最大（上限）

GKE

• クラスター: コントロールプレーン（Google 管理）＋ノード群
• Autopilot / Standard: Pod 単位課金でノード運用も任せる Autopilot と、ノードプールを自分で管理する Standard
• ノードプール: 同一構成ノードの束（マシンタイプ/Spot 等を指定）
• Pod / Deployment / Service / Ingress: Kubernetes 標準リソース
• Workload Identity: Pod に Google サービスアカウントを安全に紐付ける仕組み

仕様・制限・クォータ

Cloud Run

• コンテナは HTTP/gRPC でリッスンし、環境変数 PORT（既定 8080）で待ち受ける必要がある
• リクエストタイムアウトは最大 60 分。インスタンスあたり最大 8 vCPU / 32 GiB メモリ
• リージョン単位のサービス。スケールは 0〜最大インスタンス数まで自動
• CPU 割り当て: 「リクエスト処理中のみ」か「常時割り当て（always-on）」を選択

GKE

• リージョン × ゾーンに配置。コントロールプレーンの可用性に応じて Zonal / Regional を選択
• 1 クラスターあたりのノード数・Pod 数に上限（バージョン/構成で変動）
• vCPU・IP アドレス等にプロジェクト/リージョンクォータがあり、引き上げ申請が可能

内部の仕組み

Cloud Run はコンテナイメージからリビジョンを作り、受信リクエスト量に応じてインスタンス数を自動調整します。トラフィックが無ければ 0 までスケールイン（ゼロスケール）するため、アイドル時の課金が発生しません。基盤は Google の内製サーバーレス基盤（gVisor によるサンドボックス）上で動き、ノードのプロビジョニング・パッチ・スケールはすべて Google 側が担います。1 インスタンスが複数リクエストを同時処理できる点が、1 タスク=処理単位に近い Fargate と異なります。

GKE は Google が コントロールプレーン（API サーバー / etcd / スケジューラ）を完全マネージドで運用し、ワークロードは Pod としてノード上で動きます。Autopilot モードでは Google がノードの数・サイズ・スケールまで管理し、ユーザーは Pod のリソース要求を書くだけ。Standard モードではノードプールを自分で持ち、より細かい制御やコスト最適化ができます。

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

• 運用を最小化するなら Cloud Run、Kubernetes が必要なら GKE（まずは Autopilot）
• リビジョン＋トラフィック分割でカナリアリリース／即時ロールバック
• コールドスタートが問題なら min インスタンスを 1 以上に設定
• 同時実行数（concurrency）は、ワークロードの CPU/メモリ特性に合わせて調整（重い処理は小さく）
• 権限は 専用サービスアカウント（Cloud Run）/ Workload Identity（GKE）で最小限に
• 内部通信のみなら Ingress を internal に絞り、外部公開しない

運用・監視・トラブルシュート

• Cloud Monitoring / Cloud Logging でメトリクス（リクエスト数・レイテンシ・インスタンス数）とログを監視。標準出力ログは自動収集
• Cloud Run のリビジョンが起動しない → PORT でリッスンしているか、イメージ取得権限（Artifact Registry）、メモリ不足を確認
• デプロイ後にエラー → リビジョンのトラフィックを直前リビジョンへ戻すだけでロールバック
• GKE の Pod が CrashLoopBackOff → kubectl logs / kubectl describe pod でイベントとログを確認

コスト

セキュリティ

• 専用サービスアカウントを Cloud Run サービス／ GKE の Workload Identity で割り当て、鍵のハードコードを避ける（AWS の IAM ロール／タスクロール相当）
• イメージは Artifact Registry に保存し、脆弱性スキャンを有効化。Binary Authorization で署名済みイメージのみデプロイ
• シークレットは Secret Manager で管理し、環境変数や Volume として注入
• Cloud Run の Ingress を内部限定にし、認証は Cloud IAM（IAM Invoker） や IAP で制御。GKE は Network Policy で Pod 間通信を最小化

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# Cloud Run: コンテナイメージからサービスをデプロイ（HTTPS 自動付与）
gcloud run deploy web \
  --image=asia-northeast1-docker.pkg.dev/PROJECT_ID/repo/web:latest \
  --region=asia-northeast1 \
  --service-account=web-sa@PROJECT_ID.iam.gserviceaccount.com \
  --concurrency=80 \
  --min-instances=1 \
  --max-instances=10 \
  --no-allow-unauthenticated

# Cloud Run: 新リビジョンへ段階的にトラフィックを移す（カナリア 10%）
gcloud run services update-traffic web \
  --region=asia-northeast1 \
  --to-revisions=LATEST=10

# GKE: Autopilot クラスターを作成し、認証情報を取得して Deployment を作成
gcloud container clusters create-auto demo-cluster \
  --region=asia-northeast1
gcloud container clusters get-credentials demo-cluster \
  --region=asia-northeast1
kubectl create deployment web \
  --image=asia-northeast1-docker.pkg.dev/PROJECT_ID/repo/web:latest