はじめに
Google Cloud PaltformのCloud Runのサービスについて確認したいことがあり、試行して確認しましたので、それについて記述します。
なお、2022年11月6日に確認した結果です。
確認したかったこと
Cloud Pub/Subを利用するCloud Runの「サービス」においてサービスの同時実行数を超えるリクエストを送るとどうなるかです。
公式のドキュメントでは同時実行数は「コンテナあたりの最大リクエスト数」のことのようです。ただ、「インスタンスの最大数」というパラメータもあり、同時に処理できるリクエストの数は「コンテナあたりの最大リクエスト数」×「インスタンスの最大数」（ここではサービスの 同時実行数と呼ぶことにします）ということになると思います。
予想としては、Cloud Pub/Subはメッセージング・サービスであり、リクエスト（メッセージ）がキューイングされ（Queueに入れられ）、Cloud Runで処理できるようになったら順次リクエストが処理されると思っていました。
結果
リクエスト（メッセージ）がキューイングされ（Queueに入れられ）、Cloud Runで処理できるようになったら順次リクエストが処理されました。
予想と違っていたのは、サービスの同時実行数の上限一杯まで処理が行われていると、Pub/Subによるサブスクライバーへのpush配信によるサービス起動のリクエストに対し「429 Too Many Requests」が返ってきます。Pub/Subによるリトライが何度か行われて、最終的には空きができ、処理が実行されるという結果になりました。
確認方法
チュートリアルの実施
基本的に以下の公式のチュートリアルを参考に試行を行いました。
コードとしては、チュートリアルにあるとおり、以下のリポジトリにあるコードを使いました。
実施した修正
そのままでは検証をやりにくいので、いくつか修正を行いました。
まず、サンプルのコードに少し修正を入れました（修正はこちら）。30秒の待ち時間を入れるためにこのページを参考にしました（コードを参考にしました）。
次はCloud Runの「同時実行」（コンテナあたりの最大リクエスト数）と「最大インスタンス数」をそれぞれ1にしました。つまり、サービスの同時実行数は1です。
確認の実施
チュートリアルにあるとおり、以下のコマンドで3つのメッセージを連続で送りました。
gcloud pubsub topics publish myRunTopic --message "Runner"
オペレーションのロギング（Cloud Logging）で見ると以下のようになっています。
最終的に3つのリクエストが処理されましたが、途中では「429 Too Many Requests」が返ってきており、リトライが行われています。
考察
リトライが行われたのは、サブスクリプションの設定でリトライを行うようになっているからです。参考ですが「デッドレタリング」のところで「配信の最大試行回数」を設定できます。
補足
GCPコンソールの画像は、公開したくない情報をマスクするため、一部白抜きにしてあります。