G-gen の佐々木です。当記事では、Cloud Run の新しい実行モデルである Cloud Run Worker Pools を、実際に使ってみます。

注意 : 当記事の内容について

当記事の内容は、2025年6月26日現在パブリックプレビュー版のサービスに関するものです。

したがって、当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。

はじめに

Cloud Run Worker Pools とは

Cloud Run は Google Cloud のサーバーレスコンテナコンピューティングサービスです。HTTP リクエストベースでコンテナを実行する Cloud Run services、スケジュールやワークフローベースのバッチ実行に特化した Cloud Run jobs、そして HTTP リクエストやイベントベースで関数を実行する Cloud Run functions（旧 : Cloud Functions）といった実行モデルがあります。

Cloud Run Worker Pools は、Google Cloud Next '25 で発表された Cloud Run の新たな実行モデルであり、外からのリクエストを受けて実行される従来の実行モデルとは異なり、タスクやメッセージを能動的に取得する Pull ベース の実行モデルとされています。

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

サービスの詳細については、以下の記事で解説しています。

blog.g-gen.co.jp

また、Cloud Run の基本については、以下の記事をご一読ください。

blog.g-gen.co.jp

想定ユースケース

Cloud Run で Pull ベースの実行モデルが利用可能になると、従来の実行モデルでは実装が難しかった以下のようなユースケースが Cloud Run で実現できます。

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

従来、このようなユースケースでは GKE で Kubernetes クラスタ上にワーカーを展開するケースなどが一般的でしたが、Cloud Run Worker Pools の登場により、サーバーレスのメリットを享受しながらワーカーを展開することができます。

GKE 上のワーカーで Pub/Sub のメッセージを Pull するケースについては、以下の記事で紹介しています。

blog.g-gen.co.jp

当記事の構成

当記事では、Pub/Sub から Pull したメッセージの処理を行う Cloud Run Worker Pools を作成してみます。

繰り返しになりますが、当記事で解説する内容は2025年6月25日現在利用できるパブリックプレビュー版のものであり、一般提供の際に変更される可能性があります。

Pub/Sub の作成

gcloud CLI で Pub/Sub のトピックと pull サブスクリプションを作成します。

当記事ではトピック名を worker-pools-topic、サブスクリプション名を worker-pools-sub とします。`

# Pub/Sub トピックの作成
$ gcloud pubsub topics create worker-pools-topic
  
# Pub/Sub サブスクリプションの作成
$ gcloud pubsub subscriptions create worker-pools-sub --topic=worker-pools-topic

Cloud Run Worker Pools の作成

使用するコード（Go）

Cloud Run Worker Pools にデプロイするコンテナイメージを用意します。

以下のコードでは、Pub/Sub の Streaming Pull API を使用してメッセージを Pull し、メッセージの内容をログ出力します。

package main
  
import (
    "context"
    "fmt"
    "io"
    "log"
    "os"
  
    "cloud.google.com/go/pubsub" // Pub/Sub クライアントライブラリ
)
  
// メッセージを StreamingPull する関数
func pullMessages(w io.Writer, c context.Context, projectId, subId string) error {
  
    // Pub/Sub Client
    client, err := pubsub.NewClient(c, projectId)
    if err != nil {
        return fmt.Errorf("pubsub.NewClient: %v", err)
    }
    defer client.Close()
  
    // サブスクリプションの参照
    sub := client.Subscription(subId)
  
    // メッセージを Pull し続ける
    err = sub.Receive(c, func(_ context.Context, msg *pubsub.Message) {
        fmt.Fprintf(w, "%v\n", string(msg.Data)) // メッセージを標準出力に出力
        msg.Ack()
    })
    if err != nil {
        return fmt.Errorf("sub.Receive: %v", err)
    }
  
    return nil
}
  
func main() {
    ctx := context.Background()
  
    // 環境変数からプロジェクト ID と PubSub トピック ID を取得
    projectId := os.Getenv("PROJECT_ID")
    subId := os.Getenv("SUBSCRIPTION_ID")
  
    err := pullMessages(os.Stdout, ctx, projectId, subId)
    if err != nil {
        log.Fatal(err)
    }
}

参考 : Pull subscriptions - StreamingPull API

コンテナイメージの作成

当記事では Dockerfile を使用せず、Cloud Build で Buildpack を使用してコンテナイメージをビルドします。

# Cloud Build で Buildpack を使用してコンテナイメージをビルド
$ gcloud builds submit --pack image=<Artifact Registory のパス>

参考 : Google Cloud's buildpacks

Cloud Run Worker Pools のデプロイ

ベータ版の API を使用して、Cloud Run Worker Pools をデプロイしていきます。

2025年6月26日現在では、gcloud beta run worker-pools deploy を使用して Cloud Run Worker Pools をデプロイすることができます。

# Cloud Run Worker Pools のデプロイ
$ gcloud beta run worker-pools deploy hello-worker-pools \
    --region=asia-northeast1 \
    --image=<Artifact Registory のパス> \
    --set-env-vars=PROJECT_ID=<Pub/Subがあるプロジェクト ID>,SUBSCRIPTION_ID=worker-pools-sub \
    --scaling=3

当記事では、hello-worker-pools という名前で Cloud Run Worker Pools を作成します。

--image には先ほど作成したコンテナイメージを指す Artifact Registory のパスを指定し、環境変数（--set-env-vars）としてプロジェクト ID と Pub/Sub のサブスクリプション ID（当記事では worker-pools-sub）を設定します。

最後にスケーリングの設定（--scaling）ですが、現在 Cloud Run Worker Pools では手動スケーリングのみサポートされているため、起動するインスタンス数をここで決定します。

当記事では Pub/Sub のメッセージが複数のコンテナインスタンスで分散処理されるかを確認するため、コンテナインスタンス数を3に固定して進めていきます。

参考 : gcloud beta run worker-pools deploy

コンソールから確認

2025年6月26日現在、Google Cloud コンソール上には Cloud Run Worker Pools の画面が存在していますが、サービスの作成や更新はできず、CLI でデプロイしたサービスの表示と削除のみが可能になっています。

他の実行モデル同様に、デプロイした内容がリビジョン単位で管理されていることがわかります。

動作確認

Pub/Sub にメッセージを送信し、Cloud Run Worker Pools がメッセージを処理できるかを確認してみます。

Pub/Sub トピックのコンソール画面から、100個の Hello, Worker Pools!! というメッセージをトピックにパブリッシュします。

パブリッシュ後、Cloud Run Worker Pools のログを確認してみると、Cloud Run 側からメッセージを能動的に取得（Pull）できていることがわかります。

今回はコンテナインスタンス数を3に設定しているため、各コンテナインスタンスでメッセージが分散処理されているかを確認してみます。

ログエクスプローラから、以下のクエリで Cloud Run Worker Pools のログを検索します。

resource.type = "cloud_run_worker_pool"
resource.labels.worker_pool_name = "hello-worker-pools"
resource.labels.location = "asia-northeast1"
textPayload="Hello, Worker Pools!!"

ログの label.instanceId フィールドにログを出力した（=メッセージを処理した）コンテナインスタンスの ID が記録されているため、以下のようにクエリに追加することで、各コンテナインスタンスで処理したメッセージ数を確認できます。

resource.type = "cloud_run_worker_pool"
resource.labels.worker_pool_name = "hello-worker-pools"
resource.labels.location = "asia-northeast1"
textPayload="Hello, Worker Pools!!"
labels.instanceId="<インスタンスIDの値>"

当記事では3つのコンテナインスタンスのそれぞれで、38件、34件、28件のメッセージが処理されていました。起動しているコンテナインスタンス間でメッセージがある程度分散されていることがわかります。