要求が0.001件/秒しか来ない場合、71.4%が立ち上げを待たされました。
立ち上げを5000msから50msにしても71.4%のままです。減るのは待つ長さだけでした。
使われなければ取り除かれます。次の要求は立ち上げから始まり、その割合は速さでは変わりません。
Cloud Runでは、使われていない入れ物は残りません。公式はあなたのサービスに入ってくる要求がなければ、最後に残った1つさえ取り除かれると述べています。
取り除かれたあとの要求は、立ち上げから始まります。どれくらい当たるのか実際に流して数えました。
6時間ぶん。300秒来なければ片付けられ、次は立ち上げからになる 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 （待たされた要求の割合） 50ms 71.4% 26.5% 0.7% 0.0% 300ms 71.4% 26.5% 0.7% 0.0% 1500ms 71.4% 26.5% 0.7% 0.0% 5000ms 71.4% 26.5% 0.7% 0.0%
縦に見ると、どの行も同じ値です。立ち上げを5000msから50msにしても71.4%のままでした。
当たるかどうかを決めているのは、前の要求からどれだけ空いたかだけです。立ち上げの速さは関係しません。
横に見ると大きく動きます。0.2件/秒なら0.0%です。5秒に1件来るだけで、取り除かれる機会がなくなります。
つまり手を入れる先は、要求の間隔か、片付けまでの時間です。速くする工夫は別の効き方をします。
同じ形の判断はサーバーレスの記事でも扱っていて、まばらな用途ほどこの割合が高くなります。
要求が増えるほど、立ち上げに当たる割合は急に下がる。
If there are no incoming requests to your service, even the last remaining instance will be removed.原文Google Cloud ドキュメント「What is Cloud Run」 この内容の有効期限2027-02-18
どの言語でも動かせます。ただし作った像の立ち上がりが、平均の応答にそのまま乗ります。
Cloud Runは、像さえ作れれば言語を選びません。公式はコンテナの像を作れるなら、どの言語で書いた符号でもCloud Run上に配置できると述べています。
選べる代わりに、その像の立ち上がりが効いてきます。同じ実行の後半を見ます。
平均の応答（立ち上げの分だけを足したもの） 立ち上げ 0.001件/秒 0.005件/秒 0.02件/秒 0.2件/秒 50ms 35.7ms 13.2ms 0.3ms 0.0ms 300ms 214.3ms 79.4ms 2.1ms 0.1ms 1500ms 1071.4ms 397.1ms 10.3ms 0.3ms 5000ms 3571.4ms 1323.5ms 34.3ms 1.2ms
こちらは縦にも大きく動きます。0.001件/秒では、50msなら35.7msですが5000msでは3571.4msです。
当たる割合は同じでも、1回あたりの待ちが100倍違うためです。
まばらな用途なら、立ち上げを速くする効果が大きく出ます。3571.4msと35.7msでは、体感が別物です。
よく使われる用途では、0.2件/秒の列のとおりほとんど差がありません。1.2msと0.0msの違いです。
だから像を小さくする作業は、まばらな用途にだけ効きます。使われている画面では、別の場所を見ることになります。
You can deploy code written in any programming language on Cloud Run if you can build a container image from it.原文Google Cloud ドキュメント「What is Cloud Run」 この内容の有効期限2027-02-18
要求に合わせて増えます。1つが同時に受ける数を変えると、費用と速さが逆向きに動きます。
Cloud Runは、要求に合わせて数を増やします。公式はCloud Runは、入ってくるすべての要求をさばくために、あるいは台ごとの課金にしている場合は要求の外で上がった処理の使用率をさばくために、素早く広がると述べています。
何台になるかは、1つが同時に何件受けるかで決まります。実際に計算して比べました。
1時間ぶん・要求 143,885件（毎秒 約40件）。1件の処理は 220ミリ秒
1つの入れ物が同時に抱える数を変える。抱えるほど1件は 6%ずつ遅くなるものとした
同時に受ける数 必要な入れ物の数 1件の処理時間 入れ物の秒数の合計 1件あたり
1件 9台 220ms 32,400秒 0.225秒
2件 5台 233ms 18,000秒 0.125秒
4件 3台 260ms 10,800秒 0.075秒
8件 2台 312ms 7,200秒 0.050秒
16件 2台 418ms 7,200秒 0.050秒
80件 1台 1263ms 3,600秒 0.025秒
同時1件だと9台必要で、1件あたり0.225秒ぶんの費用です。80件なら1台、0.025秒になります。
そのかわり1件の処理が220msから1263msに伸びます。5.7倍遅くなりました。
8件と16件は、どちらも2台で0.050秒です。費用が同じなら、遅くならない8件を選びます。
この表は台数が整数でしか増えないため、段になっています。だから設定値をわずかに変えても、費用が動かない範囲があります。
2つの計測はいずれも手元で書いた模型で、実際のCloud Runを動かしたものではありません。片付けまで300秒、1件220ミリ秒、同時に抱えるほど6%ずつ遅くなるという値はすべて置いたものです。実際の遅くなり方は処理の中身によって大きく違い、待ちが多い処理ならほとんど遅くなりません。要求の来る時刻も一定の割合で引いており、時間帯の波は含めていません。ここで見せているのは、立ち上げを速くしても当たる割合は変わらないという点と、同時に受ける数を上げると費用と速さが逆向きに動くという点の2つです。
Cloud Run rapidly scales out to handle all incoming requests or to handle increased CPU utilization outside requests if the billing setting is set to instance-based billing.原文Google Cloud ドキュメント「What is Cloud Run」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る