GKE・Cloud Run・Cloud Run Jobs：常時稼働とコストで選ぶ

Kubernetesを学んだからといって、すべてのコンテナをGKEへ載せる必要はありません。常時稼働が不要で、Kubernetes固有機能を使わない小〜中規模の処理は、Cloud Run ServiceやCloud Run Jobsへ移すと大幅にコストを下げられる場合があります。

ただし「Cloud Runなら常に安い」わけでもありません。トラフィック、最小インスタンス、CPU・メモリ、ネットワーク、ストレージ、運用工数を含む総コストで比較します。

3つの実行先

Cloud Runにも継続処理向けWorker poolがありますが、本記事ではWeb/APIと完了型バッチの移行判断に絞ります。

コスト差が生まれる理由

GKE Standard

Standardでは、ワークロードが少ない時間もNodeが存在すればCompute Engine資源の費用が発生します。加えてクラスタ管理料、ロードバランサー、永続ディスク、ログなどを考慮します。Cluster Autoscalerを使っても、システムPodや制約によりNodeを完全にゼロへできない構成があります。

GKE Autopilot

一般的なPodベース課金では実行Podのrequestsを基準に管理しやすくなりますが、クラスタ管理料や周辺サービス、最低要求値、特定ハードウェアのNodeベース課金などを確認する必要があります。既に多数の常時稼働Podがある場合、GKE内へ集約した方が効率的なこともあります。

Cloud Run Service

最小インスタンス数を0にすると、リクエストがない間にインスタンスをゼロへ縮退できます。アクセスが断続的なAPI、管理画面、Webhookなどで費用を下げやすい構造です。一方、最小インスタンスを維持する、常時CPUを割り当てる、トラフィックが多い場合は費用が継続します。

Cloud Run Jobs

タスク開始から終了までの実行資源が中心になるため、1日数回、週1回、月1回といったバッチに適します。Kubernetesクラスタをバッチのためだけに維持する必要がありません。

正確な料金体系は変更されるため、固定金額ではなく現行のGKE料金とCloud Run料金、Billingレポートで比較します。

選定の質問

Cloud Run Serviceを先に検討する条件

• HTTPまたはgRPCでリクエストを受ける
• トラフィックが断続的で、ゼロからの起動遅延を許容できる
• コンテナをステートレスにできる
• Kubernetes API、DaemonSet、hostPath、特殊なNode制御が不要
• 1サービスごとに独立してデプロイできる

Cloud Run Jobsを先に検討する条件

• 処理が完了して終了する
• cronや手動、イベントから起動できる
• 常時待受プロセスが不要
• タスクを再実行しても安全な冪等性がある
• 実行時間、CPU、メモリ、並列数がCloud Run Jobsの制約内

GKEを選ぶ理由

• Kubernetes API、Operator、CRD、Helm資産が中核
• 複雑なService間通信やネットワークポリシーが必要
• DaemonSet、特殊なデバイス、詳細なスケジューリングが必要
• 長時間・常時稼働の多数サービスを同じ基盤で管理する
• Cloud Runの実行制約やランタイムモデルに合わない
• 移行による改修・検証コストが削減額を上回る

Kubernetesオブジェクトとの対応

Cloud RunはKubernetesマニフェストをそのまま実行するサービスではありません。同じコンテナイメージを利用できても、実行・公開・認証の設定はCloud Run用に作り直します。

手動でCloud Run Serviceへ試験デプロイする

Cloud RunへGitLabの非公開イメージURLをそのまま渡す構成にはしません。Google Cloudの現行仕様では、外部の公開・非公開Registryは Artifact Registryのremote repository経由で利用するか、イメージを一時的にpullしてArtifact Registryのstandard repositoryへ手動pushします。最初の比較検証では後者が構造を理解しやすく、継続運用ではremote repositoryの対応条件と認証方法を確認します。

この場合もGitLabをイメージの正本にできますが、Cloud Runへ渡す YOUR_IMAGE_URI はArtifact Registry側のURIになります。Cloud Runはデプロイ時にイメージを取り込み、各インスタンス起動時にGitLabへpullし直す動作ではありません。

デプロイ構文の基本形は次のとおりです。

gcloud run deploy YOUR_SERVICE_NAME \
  --image=YOUR_IMAGE_URI \
  --region=YOUR_REGION \
  --project=YOUR_PROJECT_ID \
  --service-account=YOUR_RUNTIME_SERVICE_ACCOUNT \
  --min-instances=0 \
  --max-instances=YOUR_MAX_INSTANCES \
  --no-allow-unauthenticated

公開サービスにするかはセキュリティ要件で判断します。検証だからと --allow-unauthenticated を無条件に付けません。

手動でCloud Run Jobを作る

gcloud run jobs deploy YOUR_JOB_NAME \
  --image=YOUR_IMAGE_URI \
  --region=YOUR_REGION \
  --project=YOUR_PROJECT_ID \
  --service-account=YOUR_RUNTIME_SERVICE_ACCOUNT \
  --tasks=1 \
  --max-retries=3 \
  --task-timeout=30m

gcloud run jobs execute YOUR_JOB_NAME \
  --region=YOUR_REGION \
  --project=YOUR_PROJECT_ID \
  --wait

Cloud Run JobのコンテナはHTTP待受を必要とせず、処理が終わったら終了します。DB移行のような排他的処理は、同時実行や再試行による二重処理を必ず検討します。

比較は同じ観測期間で行う

少なくとも次の費用と工数を、1〜3か月など同じ期間で比較します。

• vCPU・メモリ・GPUなどの実行資源
• クラスタ管理料またはCloud Run実行料
• Load Balancer、外向き通信、固定IP、NAT
• 永続ストレージ、DB、バックアップ
• Logging、Monitoring、トレース
• パッチ、アップグレード、障害対応の人件費
• 移行開発、性能試験、切り戻し準備

月額請求だけでなく、運用担当者がNode、Kubernetesバージョン、Addon、Helm Releaseを保守する時間もTCOに含めます。

段階移行の進め方

1. 全ワークロードをDeployment、Job、CronJob、状態ありに分類する
2. 稼働時間、CPU・メモリ、リクエスト数、依存先を計測する
3. 低頻度で依存の少ないJobを最初の候補にする
4. 同じ固定タグのイメージでCloud Run Jobを手動検証する
5. IAM、Secret Manager、VPC、DB接続を最小権限で再構成する
6. 実行時間、失敗率、料金をGKE版と比較する
7. 切り戻し手順を残して段階的に切り替える
8. 不要になったGKEリソースと周辺LB・ディスクを確認して削除する

いきなりクラスタ全体を移すのではなく、最も独立した低頻度バッチから価値を検証すると安全です。

結論

Kubernetesはインフラとして強力ですが、運用対象でもあります。常時稼働、多数サービス、Kubernetes固有制御が必要ならGKEが適します。リクエストが少ないWeb/APIや、実行時だけ資源が必要なバッチならCloud Run Service / Jobsが有力です。

目標はKubernetesを使い切ることではなく、必要な信頼性を最小の運用負荷と総コストで実現することです。

参考資料

• GKE and Cloud Run — Google Cloud
• What is Cloud Run — Google Cloud
• Deploy container images to Cloud Run — Google Cloud
• Create jobs — Cloud Run
• Set minimum instances — Cloud Run
• GKE pricing — Google Cloud
• Cloud Run pricing — Google Cloud