G-gen の佐々木です。当記事では、Google Cloud のサーバーレスコンテナサービスである Cloud Run の機能の一つ、Cloud Run worker pools について解説します。

注意点

当記事の内容は、2025年7月3日現在パブリックプレビュー版のサービスに関するものです。したがって、当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。

プレビュー版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。

blog.g-gen.co.jp

Cloud Run worker pools とは

概要

Cloud Run worker pools とは、サーバーレスなクラウドインフラでコンテナを実行することができる Cloud Run の実行モデルのうちの一つです。

Cloud Run には他にも Cloud Run services、Cloud Run jobs、Cloud Run functions（旧 Cloud Functions）といった実行モデルがありますが、これらはいずれも HTTP リクエストの受信や API 経由の手動実行、Cron によるスケジュール実行など、外部からの何かしらのトリガーによりコンテナ化したアプリケーションを実行するものです。

Cloud Run worker pools はこれらの実行モデルと異なり、Pub/Sub や Kafka のようなメッセージキューなどに対して、アプリケーションが能動的にメッセージやタスクの取得を行う pull 型のワークロードを実行するモデルとなっています。

参考 : Deployment options and resource model - Cloud Run worker pools

後述しますが、Cloud Run worker pools は実行形態が他のモデルとは異なるものの、サービスの仕様は Cloud Run services と共通する箇所が多くなっています。Cloud Run services については以下の記事もご一読ください。

blog.g-gen.co.jp

ユースケース

Cloud Run worker pools では、以下のような pull 型ワークロードをサーバーレスで実現することができます。

Pub/Sub の pull サブスクリプションからメッセージを取得して処理を実行する
Kafka キューからタスクを取得して処理を実行する
GitHub Actions の Runner をホスティングしてワークフローを実行する

このようなワークロードを Google Cloud で実現する場合、GKE や Compute Engine など、ユーザー側でインフラをある程度管理する必要があるサービスを利用する必要がありました。

Cloud Run worker pools を使用することで、インフラ管理が不要かつ、垂直・水平方向のスケーリングを容易に行えるといったサーバーレスのメリットを享受することができます。

Cloud Run services と共通の仕様

リビジョン単位の管理

新規作成や構成の変更など、Cloud Run worker pools でワーカープールをデプロイするたびにリビジョン（バージョン）が作成されます。

このリビジョンを使用することで、新しいリビジョンへの段階的な移行や、新旧リビジョンのインスタンスを一定の割合で起動するインスタンス分割、リビジョンのロールバックなどを容易に行うことができます。

参考 : Manage worker pool revisions

CPU、メモリ容量の制限

Cloud Run ではコンテナインスタンスに割り当てる CPU 数、メモリ容量について、上限・下限が存在します。

また以下のように、CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。

CPU（個）	メモリ容量
1	512 MiB ~ 4 GiB
2	512 MiB ~ 8 Gib
4	2 GiB ~ 16 GiB
6	4 GiB ~ 24 GiB
8	4 GiB ~ 32 GiB

CPU、メモリの設定値は Cloud Run の利用料に直結する要素であり、ワークロードの実行に必要な量を適切に見積もる必要があります。

デフォルトでは、1 vCPU、メモリ容量512 MiB がワーカープールに設定されます。

参考 : Configure memory limits for worker pools
参考 : Configure CPU limits for worker pools

ボリュームマウント機能

ボリュームマウント機能により、Cloud Storage バケット、NFS ボリューム、インメモリボリュームなどの外部のボリュームを、ワーカープールのコンテナインスタンスにマウントすることができます。

マウントしたボリュームは、コンテナ内のディレクトリとしてローカルファイルシステム同様にアクセスすることができます。

参考 : Configure Cloud Storage volume mounts for worker pools

Cloud Run におけるボリュームマウントについては以下の記事もご一読ください。

blog.g-gen.co.jp

VPC へのプライベート接続

Cloud SQL データベースへの読み書きを行う場合など、ワーカープールのコンテナインスタンスから VPC 内のリソースにアクセスする必要がある場合は、Direct VPC Egress やサーバーレス VPC アクセスを使用することで、プライベート IP アドレスによる接続を実現することができます。

参考 : Direct VPC egress with a VPC network

Cloud Run における VPC へのプライベート接続については、以下の記事をご一読ください。

blog.g-gen.co.jp

サイドカーコンテナの使用

Cloud SQL Auth Proxy や AlloyDB Auth Proxy、ログやメトリクスのエージェントなど、サイドカーコンテナが必要となるユースケースでは、マルチコンテナ機能により複数のコンテナイメージをリビジョンに設定することができます。

参考 : Deploy worker pools to Cloud Run - Deploy multiple containers (sidecars) to a worker pool

pull 型の実行モデル

Cloud Run worker pools には実行をトリガーするためのエンドポイント、URL がありません。Pub/Sub や Kafka などのメッセージキューに対して処理を行うために、コンテナインスタンスは常に起動されています。

したがって、HTTP リクエストの受信をトリガーとする Cloud Run services と異なり、デプロイするコンテナがポートでリクエストをリッスンする必要がありません。

参考 : Deployment options and resource model - Cloud Run worker pools

スケーリング

他の実行モデルとの重要な違いとして、Cloud Run worker pools には自動スケーリング機能がありません。

基本的にコンテナインスタンスの数は手動で調整する必要があり、インスタンス数が0のときはワーカープールが無効になります。

また、インスタンス数はリビジョン単位ではなくワーカープール単位で設定されるため、インスタンス数の変更により新たなリビジョンが作成されることはありません。

参考 : Manual scaling for worker pools

もしワーカープールの自動スケーリングを行いたい場合は、pull 対象（Pub/Sub や Kafka など）やワーカープールをモニタリングし、Cloud Run の API を利用してインスタンス数を自動で変更するような仕組みを独自に作り込む必要があります。

以下の公式ドキュメントでは、pull 対象である Kafka クラスターからメトリクスを読み取り、ワーカープールの自動スケーリングを行う仕組みが紹介されています。

参考 : Autoscale your Kafka consumer workloads

ワーカープールのデプロイ

ワーカープールはコンテナレジストリにあるコンテナイメージ、もしくはソースコードからそのままデプロイすることができます。

コンテナレジストリは Google Cloud のサービスである Artifact Registory の利用が推奨されます。それ以外には Docker Hub のイメージも利用できるほか、Artifact Registry のリモートリポジトリ機能を用いることで、様々なパブリック/プライベートリポジトリを利用することができます。

参考 : Deploy worker pools to Cloud Run
参考 : Create remote repositories

ソースコードからのデプロイでは、Google Cloud が提供している buildpacks を使用して、ワーカープールとしてデプロイされるコンテナイメージが自動で作成されます。

使用言語や依存関係などが自動で検出され、Google 管理の安全なベースイメージを用いてコンテナイメージのビルドが行われます。Dockerfile を使用しないため、ビルドの細かいカスタマイズはできない点に注意が必要です。

参考 : Deploy worker pools from source code
参考 : Google Cloud's buildpacks

Cloud Run worker pools のデプロイ方法については、以下の記事もご一読ください。

blog.g-gen.co.jp

料金

Cloud Run worker pools では、コンテナインスタンスが使用する CPU、メモリの実行時間ぶんの料金が発生します。Cloud Run services とは異なり、コンテナインスタンスがアクティブであってもアイドル状態であっても同様の料金が発生します。

また他の実行モデルとは異なり、外部からのリクエストによる実行ではないため、リクエスト単位の料金はありません。

以下は、2025年7月現在の東京リージョン（asia-northeast1）における料金表です。

	CPU	メモリ
無料枠	毎月最初の 240,000 vCPU 秒	毎月最初の 450,000 GiB 秒
通常料金	$0.000011244 / vCPU 秒	$0.000001235 / GiB 秒
FlexCUD（1年）	$0.00000809568 / vCPU 秒	$0.0000008892 / GiB 秒
FlexCUD（3年）	$0.00000607176 / vCPU 秒	$0.0000006669 / GiB 秒

vCPU 秒 : vCPU が 1 つのインスタンスを 1 秒間実行すること
GiB 秒 : メモリ容量が 1 GiB のインスタンスを 1 秒間実行すること

例えば、通常料金で 1 vCPU、メモリ1 GiB、コンテナインスタンス1つのワーカープールを実行する場合、1ヶ月（30日=2592000秒）あたりの料金は以下のようになります。

項目	計算式
CPU 料金	$0.000011244 * (2592000秒 - 無料枠240000秒) = $26.45/月
メモリ料金	$0.000001235 * (2592000秒 - 無料枠450000秒) = $2.65/月