Cloud Runは、Google Cloudが提供するフルマネージドなコンテナ実行基盤です。Dockerコンテナをデプロイするだけでスケーリング・負荷分散・TLS終端が自動化されるため、インフラ運用の負荷を大幅に削減できます。

一方で、本番環境に耐えうるシステムを構築するには、ネットワーク設計・セキュリティ・コスト管理・可用性確保など多角的な設計判断が求められます。本稿では、Cloud Runを中心としたアーキテクチャ設計のポイントを体系的に整理します。

Cloud Runの基本構造とリソースモデル

Cloud Runにはサービスとジョブの2つのリソースタイプがあります。

項目Cloud Run サービスCloud Run ジョブ
用途HTTPリクエスト処理、Webアプリ、APIバッチ処理、データ変換、定期タスク
トリガーHTTPリクエスト手動実行、Cloud Scheduler、Eventarc
スケーリングリクエスト数に応じた自動スケール（0〜最大インスタンス数）タスク並列数を指定して実行
課金モデルリクエストベースまたはインスタンスベースタスク実行時間に基づく従量課金
最大実行時間最大60分（デフォルト5分）最大168時間（7日間）、デフォルト10分

サービスは常時リクエストを待ち受けるワークロード、ジョブは有限時間で完了する処理に適しています。両者を組み合わせることで、WebアプリのバックエンドAPIとバッチ処理を同一のCloud Runプラットフォーム上で統合管理できます。

リビジョンとトラフィック管理

Cloud Runサービスはデプロイごとにリビジョンが作成されます。複数のリビジョンにトラフィックを分割できるため、カナリアリリースやブルーグリーンデプロイが容易に実現できます。

# 新しいリビジョンへのトラフィックを段階的に移行する例
gcloud run services update-traffic my-service \
  --to-revisions=my-service-00002-abc=10 \
  --region=asia-northeast1

この機能を活用すると、新バージョンにまず10%のトラフィックを流して動作を確認し、問題がなければ100%に切り替えるといった段階的デプロイが可能です。

アーキテクチャパターン別の設計指針

パターン1：Webアプリケーション＋API（3層構成）

SPAやSSRフレームワークのフロントエンドとAPI層をCloud Run上に配置する構成です。

構成要素：

  • フロントエンド用Cloud Runサービス（Next.js、Nuxt.jsなど）
  • API用Cloud Runサービス
  • Cloud SQL（PostgreSQLまたはMySQL）
  • Cloud Load Balancing + Cloud CDN

フロントエンドとAPIを別サービスに分けることで、それぞれ独立したスケーリングとデプロイサイクルを実現できます。Cloud Load Balancingのパスベースルーティングを使い、/api/* へのリクエストをAPI側へ、それ以外をフロントエンドへ振り分けます。

パターン2：イベント駆動型の非同期処理

リアルタイムに処理する必要がないワークロードは、Pub/SubやEventarcを介した非同期パターンが有効です。

構成要素：

  • HTTPリクエストを受け付けるCloud Runサービス
  • Cloud Pub/Sub（メッセージキュー）
  • 非同期処理用Cloud Runサービス（Pushサブスクリプション）
  • Cloud Storage（ファイル格納）

リクエスト受付サービスがPub/Subへメッセージを発行し、後続のCloud Runサービスが処理を引き受けます。この構成により、一時的なスパイクへの耐性が高まり、受付側のレスポンスタイムも安定します。

パターン3：定期バッチ＋ジョブ実行

データ集計やレポート生成などの定期バッチには、Cloud Run ジョブ + Cloud Schedulerの組み合わせが適しています。

# Cloud Run ジョブをCloud Schedulerから定期実行する設定
gcloud scheduler jobs create http daily-report \
  --schedule="0 3 * * *" \
  --uri="https://asia-northeast1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/PROJECT_ID/jobs/daily-report:run" \
  --http-method=POST \
  --oauth-service-account-email=scheduler-sa@PROJECT_ID.iam.gserviceaccount.com

Cloud Run ジョブはデフォルトで最大10分、設定変更により最大168時間（7日間）まで実行可能なため、長時間のデータパイプライン処理にも対応できます（出典: Google Cloud）。タスクの並列実行数を指定することで、大量データの分散処理も実現できます。

パターン4：マイクロサービス構成

複数のCloud Runサービスを組み合わせてマイクロサービスアーキテクチャを構築するパターンです。

設計上の注意点：

  • サービス間通信にはサービスアカウント認証を使用：各サービスに専用のサービスアカウントを割り当て、呼び出し先のIAM（roles/run.invoker）で制御します
  • サービスメッシュは不要：Cloud Runはサービス間の認証を組み込みで提供するため、Istioのようなサービスメッシュを別途導入する必要がありません
  • Ingress設定を「内部」に制限：外部公開が不要なサービスはIngress設定をinternalにして、VPC内部からのみアクセスを許可します

パターン5：AI/ML推論エンドポイント

2025年にCloud RunがGPUサポートを正式提供開始したことで、LLM推論やStable Diffusionなどの画像生成ワークロードもCloud Run上で稼働できるようになりました。

利用可能なGPU（出典: Google Cloud）：

  • NVIDIA L4（推論に最適化、24GB VRAM）：GA（一般提供）
  • NVIDIA RTX PRO 6000 Blackwell（96GB VRAM）：プレビュー

GPU利用時は最低4 vCPU・16GiBメモリが必要で、利用可能リージョンはus-central1、us-east4、europe-west1、europe-west4、asia-southeast1などに限定されます。asia-northeast1（東京）は2026年2月時点で未提供のため、レイテンシ要件を考慮したリージョン選択が求められます。

GPU利用時はインスタンスベース課金のみとなり、リクエストがない時間もGPUインスタンスが起動している間は課金対象です。最小インスタンス数を1以上に設定し、コールドスタートを回避しつつコストを制御する設計が重要です。

ネットワークとセキュリティの設計

VPC接続とプライベートネットワーク

Cloud Runはデフォルトでパブリックインターネット経由でアクセスされますが、本番環境では以下のネットワーク制御を組み合わせるのが一般的です。

Direct VPC Egress（推奨）：

Cloud RunからVPC内のリソース（Cloud SQL、Memorystore、GCEインスタンスなど）にアクセスする場合、Direct VPC Egressを利用します。従来のサーバーレスVPCアクセスコネクタと比較して、追加リソースのプロビジョニングが不要で、レイテンシも低減されます。

# Cloud Run サービスのYAML設定例（Direct VPC Egress）
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/vpc-access-egress: private-ranges-only
    spec:
      containers:
        - image: gcr.io/PROJECT_ID/my-image
      serviceAccountName: my-sa@PROJECT_ID.iam.gserviceaccount.com

Ingress制御

Cloud Runの上り（内向き）トラフィックは3段階で制御できます。

Ingress設定アクセス元用途
すべて許可インターネット全体公開API、一般向けWebサイト
内部とCloud Load BalancingVPC内部 + LB経由のみLB前段でWAF/CDNを利用する場合
内部のみ同一プロジェクトまたは共有VPCのみマイクロサービス間通信、管理系API

外部公開サービスであっても、Cloud Load Balancingを前段に配置してIngress設定を「内部とCloud Load Balancing」に制限するのがセキュリティ上のベストプラクティスです。直接インターネットからCloud RunのURLにアクセスすることを防げます。

IAMとサービスアカウント設計

Cloud Runにおけるアクセス制御は主に2つの軸があります。

  1. 誰がサービスを呼び出せるか（roles/run.invoker）
  2. サービスが何にアクセスできるか（サービスアカウントの権限）

設計原則：

  • デフォルトのCompute Engine サービスアカウントは使わず、サービスごとに専用のサービスアカウントを作成します
  • 最小権限の原則に基づき、必要なIAMロールだけを付与します
  • 未認証アクセスを許可（allUsers）するのは、一般公開するWebサイトやAPIに限定します
  • Secret Managerで機密情報を管理し、環境変数に直接シークレットを設定しないようにします
# 専用サービスアカウントの作成とCloud Runへの紐付け
gcloud iam service-accounts create my-service-sa \
  --display-name="My Service SA"

gcloud run services update my-service \
  --service-account=my-service-sa@PROJECT_ID.iam.gserviceaccount.com \
  --region=asia-northeast1

Cloud ArmorによるWAF保護

Cloud Load Balancingを前段に置く場合、Cloud Armorを有効にしてWAF（Web Application Firewall）保護を追加できます。SQLインジェクションやXSSなどのOWASP Top 10攻撃をルールベースでブロックし、地域制限やレートリミットも設定できます。

コスト最適化の設計戦略

課金モデルの選択

Cloud Runには2つの課金モデルがあり、ワークロード特性に応じて選択します。

課金モデル特徴適するワークロード
リクエストベースリクエスト処理中のみCPU/メモリ課金間欠的なアクセス、低トラフィックAPI
インスタンスベースインスタンス起動中は常時課金常時接続、WebSocket、バックグラウンド処理

リクエストベース課金では、リクエストが到着していない間はCPUが割り当てられず課金も発生しません。トラフィックが断続的なAPIやWebhookの受信処理に適しています。

一方、WebSocketやサーバー送信イベント（SSE）のような常時接続型ワークロード、またはバックグラウンドでキャッシュの更新やメトリクスの送信を行う場合は、インスタンスベース課金を選択します。

無料枠の活用

Cloud Runの「Always Free」枠は毎月以下が無料で提供されます（出典: Google Cloud）。

  • CPU: 180,000 vCPU秒
  • メモリ: 360,000 GiB秒
  • リクエスト: 200万リクエスト
  • ネットワーク: 北米から1GiBの下り

個人開発や検証環境であれば、この無料枠内に収まるケースが多いです。ただし、無料枠はリクエストベース課金の場合のみ適用されます。インスタンスベース課金では無料枠が適用されない点に注意が必要です。

コスト削減のための設計判断

最小インスタンス数の適切な設定：

最小インスタンス数を0にすると、トラフィックがない間のコストはゼロですが、コールドスタートが発生します。プロダクション環境では最小インスタンス数を1に設定してコールドスタートを回避しつつ、常時1インスタンス分のコストを許容するバランスが一般的です。

CPUとメモリの適正化：

Cloud RunのデフォルトはvCPU 1、メモリ512MiBですが、実際の使用量に合わせて調整することでコストを削減できます。Cloud Monitoringのメトリクス（CPU使用率、メモリ使用率）を確認し、余裕のある範囲で最小構成に絞ります。

同時実行数（concurrency）の調整：

1インスタンスあたりの最大同時リクエスト数（デフォルト: 80）を適切に設定することで、インスタンス数を抑えられます。ただし、高すぎるconcurrencyはリクエストあたりのレイテンシ増加を招くため、負荷テストで最適値を見極めます。

パフォーマンス最適化

コールドスタート対策

Cloud Runでコールドスタートが発生すると、コンテナの起動からリクエスト処理開始まで数百ミリ秒〜数秒のレイテンシが加わります。以下の対策を組み合わせて起動時間を短縮します。

1. コンテナイメージの軽量化

  • マルチステージビルドで最終イメージに不要なビルドツールを含めない
  • Alpine LinuxやDistrolessイメージをベースにする
  • 不要な依存パッケージを除外する
# マルチステージビルドの例（Go）
FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
CMD ["/server"]

2. 起動時CPUブーストの有効化

Cloud Runは起動時に通常より多くのCPUを一時的に割り当てる「スタートアップCPUブースト」機能を提供しています。コンテナの初期化処理を高速化し、コールドスタートのレイテンシを削減できます。

gcloud run services update my-service \
  --cpu-boost \
  --region=asia-northeast1

3. グローバル変数の遅延初期化

データベース接続やキャッシュクライアントの初期化は、起動時ではなく最初のリクエスト到着時に行います（Lazy Initialization）。これにより、コンテナ起動自体の所要時間を短縮できます。

同時実行の最適化

Cloud Runの同時実行設定は、パフォーマンスとコストの両方に影響する重要なパラメータです。

  • CPU集約型処理（画像変換、暗号処理など）：concurrencyを1〜4に設定
  • I/O待ち主体の処理（DB問い合わせ、外部API呼び出し）：concurrencyを50〜80に設定
  • 非同期フレームワーク（Node.js、Pythonのasyncio）：concurrencyを80〜最大1000に設定

メモリ割り当ては同時実行数に比例して増やす必要があります。concurrencyを80に設定する場合、1リクエストあたりのメモリ消費量 × 80がインスタンスのメモリ上限を超えないように設計します。

CI/CDパイプラインの設計

Cloud Buildを利用した自動デプロイ

Cloud RunへのCI/CDパイプラインは、Cloud Buildで構築するのが最もシンプルです。GitHubやCloud Source Repositoriesへのpushをトリガーにして、ビルド→テスト→デプロイを自動化します。

# cloudbuild.yaml の構成例
steps:
  # コンテナイメージのビルド
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA', '.']

  # Artifact Registry へプッシュ
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA']

  # Cloud Run へデプロイ
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'run'
      - 'deploy'
      - 'my-service'
      - '--image=asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA'
      - '--region=asia-northeast1'
      - '--platform=managed'

Terraformによるインフラ定義

Cloud Runのサービス構成をコードで管理する場合、Terraformが広く利用されています。リソースの依存関係が明示的になり、環境間の差異を防げます。

resource "google_cloud_run_v2_service" "api" {
  name     = "api-service"
  location = "asia-northeast1"

  template {
    scaling {
      min_instance_count = 1
      max_instance_count = 10
    }
    containers {
      image = "asia-northeast1-docker.pkg.dev/my-project/my-repo/api:latest"
      resources {
        limits = {
          cpu    = "1"
          memory = "512Mi"
        }
      }
      env {
        name = "DB_HOST"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.db_host.secret_id
            version = "latest"
          }
        }
      }
    }
    service_account = google_service_account.api_sa.email

    vpc_access {
      egress = "PRIVATE_RANGES_ONLY"
      network_interfaces {
        network    = google_compute_network.main.id
        subnetwork = google_compute_subnetwork.main.id
      }
    }
  }
}

Cloud Runと他サービスの比較と使い分け

Cloud Runを採用する前に、ユースケースに適したサービスかどうかを見極める必要があります。

観点Cloud RunGKE (Kubernetes)App EngineAWS Fargate
運用負荷低い（フルマネージド）高い（クラスタ管理が必要）低い中程度（ECS/VPC管理）
スケール速度秒単位で自動スケール分単位（Pod起動）秒単位分単位
ゼロスケール可能（0インスタンスまで縮退）不可（最低1ノード）不可（Standard）/ 可（Flex）不可（最低1タスク推奨）
カスタマイズ性コンテナ構成のみ全レイヤー制御可能制限ありコンテナ構成 + VPC
GPU対応L4（GA）/ RTX PRO 6000（Preview）幅広いGPU対応非対応非対応
最大リクエストタイムアウト60分制限なし60秒（Standard）/ 60分（Flex）制限なし

Cloud Runが適さないケース：

  • ステートフルなワークロード：永続的なローカルストレージやインスタンス固有の状態管理が必要な場合、GKEのStatefulSetの方が適しています
  • 複雑なネットワークポリシー：Pod間通信の細かい制御やサービスメッシュが必要な場合はGKEが向いています
  • 60分を超えるHTTPリクエスト処理：Cloud Runサービスの最大タイムアウトは60分のため、それ以上の処理はGKEまたはGCEを検討します

海外で注目されている設計アプローチ

米国のCloud Run活用事例から、日本ではまだ普及していないパターンをいくつか紹介します。

マルチリージョン構成によるグローバル展開

Cloud Load Balancingを使い、複数リージョンのCloud Runサービスにトラフィックを分散する構成です。ユーザーの地理的位置に基づいて最寄りのリージョンへルーティングすることで、レイテンシを削減できます。Cloud SQLのクロスリージョンリードレプリカやSpannerのマルチリージョンインスタンスと組み合わせることで、データ層も含めたグローバル展開が実現します。

サービスとしてのAIエージェントホスティング

Cloud Run上でLangChainやCrewAI、Google ADK（Agent Development Kit）などのAIエージェントフレームワークをホストするパターンが2025年以降急速に拡大しています。Cloud RunのGPUサポートとスケーリング機能を組み合わせることで、エージェントの推論処理をオンデマンドで実行し、リクエストがない期間はスケールダウンしてコストを抑える構成が可能です。

Cloud Run functionsによるイベントハンドラの統合

従来Cloud Functionsとして提供されていた関数ベースのサーバーレス実行環境が、Cloud Run functionsとして統合されました（出典: Google Cloud Blog）。これにより、同じCloud Runプラットフォーム上でHTTPサービスとイベント駆動型関数を統一的に管理でき、運用コストの削減と開発体験の一貫性を実現できます。

本番運用のためのオブザーバビリティ設計

ログ・メトリクス・トレースの3本柱

Cloud Runは標準出力・標準エラー出力に書き込んだログがCloud Loggingに自動転送されます。構造化ログ（JSON形式）を使用すると、ログの検索・フィルタリングが効率的になります。

{
  "severity": "ERROR",
  "message": "Database connection failed",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "/api/users"
  },
  "trace": "projects/my-project/traces/abc123"
}

Cloud Traceとの連携により、分散トレーシングも利用できます。複数のCloud Runサービスにまたがるリクエストのレイテンシ内訳を可視化し、ボトルネックを特定できます。

アラート設計

Cloud Monitoringでは、以下のメトリクスに基づいたアラートポリシーを設定することを推奨します。

  • レイテンシ: P95レスポンスタイムの閾値超過
  • エラー率: 5xxレスポンスの割合が一定値を超えた場合
  • インスタンス数: 最大インスタンス数に近づいた場合（スケール上限到達の予兆）
  • メモリ使用率: OOM（Out Of Memory）によるインスタンス停止の予兆

設計チェックリスト

本番リリース前に確認すべき項目を一覧にまとめます。

ネットワーク・セキュリティ：

  • サービスアカウントはサービスごとに専用のものを設定しているか
  • Ingress設定は最小限のアクセス元に制限しているか
  • Secret Managerでシークレットを管理しているか
  • 外部公開サービスにはCloud Load Balancing + Cloud Armorを配置しているか
  • VPC接続はDirect VPC Egressを使用しているか

パフォーマンス・コスト：

  • コンテナイメージは軽量化されているか（マルチステージビルド）
  • 最小インスタンス数は要件に合わせて設定しているか
  • 同時実行数はワークロードに応じて調整しているか
  • 課金モデル（リクエストベース or インスタンスベース）は適切に選択しているか
  • 起動時CPUブーストは有効化しているか

運用・可用性：

  • CI/CDパイプラインは構築済みか
  • 構造化ログを出力しているか
  • アラートポリシーは設定済みか
  • カナリアリリースの手順は確立しているか
  • Terraform等によるインフラのコード管理は導入しているか

まとめ

Cloud Runは「コンテナを動かすだけ」のシンプルなサービスに見えますが、本番環境で信頼性の高いシステムを構築するには、ネットワーク設計・セキュリティ・コスト最適化・オブザーバビリティといった多層的な設計が必要です。

本稿で紹介した設計パターンやチェックリストを参考に、ワークロードの特性に合ったアーキテクチャを組み立ててみてください。Cloud Runの公式ドキュメント（Cloud Run ドキュメント）では、各機能の詳細な設定手順やサンプルコードが提供されています。