受け側の能力が毎秒60件から45件に落ちただけで、直に呼ぶ形の待ちは100msから400秒になりました。
間に置けば送る側の待ちは100msのままです。代わりに18,000件がたまります。
余裕があるうちは直に呼ぶほうが速いです。足りなくなると、待ちの伸び方が別物になります。
Cloud Pub/Subは、100ミリ秒ほどの遅れで受け渡します。公式はPub/Subは、おおむね100ミリ秒ほどの遅れで、サービス同士が非同期にやり取りできるようにすると述べています。
その100ミリ秒に見合うのか。直に呼ぶ形と実際に並べて比べました。
1時間ぶん。送る側は毎秒 50件。間に置く場合の配送は 100ミリ秒
受け側の処理能力を変えて、直に呼ぶ場合と間に置く場合を比べる
受け側の能力 直に呼ぶ（送る側の待ち） 間に置く（送る側の待ち） たまった件数の最大 追いつくまで
100件/秒 20ms 100ms 0件 —
80件/秒 33ms 100ms 0件 —
60件/秒 100ms 100ms 0件 —
45件/秒 400秒 100ms 18,000件 7分
30件/秒 2400秒 100ms 72,000件 40分
余裕があるうちは直に呼ぶほうが速く、100件/秒なら20msです。間に置く100msより5倍速いことになります。
60件/秒でちょうど並び、45件/秒で逆転します。100msが400秒、4000倍です。
60件/秒と45件/秒の差は、能力にして25%です。それでも待ちは4000倍になりました。
少しずつ悪くなるのではありません。追いつくか追いつかないかで、振る舞いが切り替わります。
間に置いた場合の代償は、たまる18,000件です。7分あれば追いつきます。この形はジョブキューの記事でも扱いました。
追いつくかどうかで、直に呼ぶ形の待ちが段差で変わる。
Pub/Sub allows services to communicate asynchronously, with latencies typically on the order of 100 milliseconds.原文Google Cloud ドキュメント「What is Pub/Sub?」 この内容の有効期限2027-02-18
区画を使う仕組みでは、区画の数が並列度の上限です。鍵が偏れば、そこで頭打ちになります。
Cloud Pub/Subは、横に伸ばすために区画を使う方式とは別の道を取っています。公式は区画を使う仕組みについてこれは受け取る側に、各区画のメッセージを順に処理させ、同時に動く相手の数を区画の数までに制限すると述べています。
では区画を増やせばどこまで効くのか。比べる相手を知るために実際に振って数えました。
200,000 件・鍵 5,000種（出やすさは偏らせてある）。1件 4ミリ秒
同じ鍵の順を守るため、鍵ごとに区画を決める。区画の数だけ同時に処理できる
区画の数 いちばん多い区画 全部終わるまで 理想（均等なら） 遊んだ区画 理想との比
1区画 200,000件 800.0秒 800.0秒 0区画 1.00倍
4区画 62,618件 250.5秒 200.0秒 0区画 1.25倍
16区画 30,648件 122.6秒 50.0秒 0区画 2.45倍
64区画 23,579件 94.3秒 12.5秒 0区画 7.55倍
256区画 22,181件 88.7秒 3.1秒 0区画 28.39倍
16区画までは順調で、800.0秒が122.6秒になります。ここまでは増やした分だけ効きます。
64区画から鈍り、256区画では88.7秒です。16区画からの追加192区画で、34秒しか縮みませんでした。
いちばん多い区画の件数を見ると、64区画で23,579件、256区画で22,181件です。ほとんど減っていません。
よく出る鍵が1つの区画に固まっているためです。同じ鍵は分けられないので、そこが下限になります。
だから区画で伸ばす仕組みを選ぶなら、先に鍵の偏りを見ることになります。偏っていれば、増やしても頭打ちです。
This forces subscribers to process messages in each partition in order and limits the number of concurrent clients to the number of partitions.原文Google Cloud ドキュメント「What is Pub/Sub?」 この内容の有効期限2027-02-18
作る側と処理する側が切り離せます。処理する側の組み方で、待ちと合計が逆に動きます。
Cloud Pub/Subは、両側を切り離します。公式はPub/Subは、メッセージを作るサービスと、それを処理するサービスとを切り離す、非同期で大きくできる受け渡しの仕組みであると述べています。
切り離せるので、処理する側だけを組み替えられます。どう変わるのか実際に流して数えました。
全体の到着は毎分 0.32件。処理能力の合計はどの構成でも同じで、使用率は8割になる 1台にまとめると1件あたりは速く、分けると1件あたりは遅くなる 構成 1件あたり 実測の使用率 平均の待ち 95%点の待ち 合計の所要 1台（速い） 2.5分 78.9% 9.3分 32.8分 11.8分 2台（中くらい） 5.0分 78.9% 8.2分 31.0分 13.2分 4台（遅い） 10.0分 78.9% 6.8分 28.9分 16.8分 8台（もっと遅い） 20.0分 78.9% 5.2分 26.0分 25.2分
分けるほど平均の待ちは減り、9.3分から5.2分になります。処理能力の合計は同じです。
ところが合計の所要は11.8分から25.2分に伸びます。待ちと合計が逆に動きました。
待つ時間が短くても、処理そのものが遅ければ意味がありません。利用者が感じるのは合計の所要です。
分ける利点が出るのは、95%点を見た場合です。32.8分から26.0分に下がっており、いちばん待たされる人の待ちは短くなります。
3つの計測はいずれも手元で書いた模型で、実際のCloud Pub/Subを叩いたものではありません。配送100ミリ秒や1件4ミリ秒は置いた値です。直に呼ぶ場合の待ちは、追いつかない条件では1時間動かし続けた場合の値で、途中で止めればもっと小さくなります。鍵の偏りも順位の逆数に比例する形と置いており、実際の分布とは違います。ここで見せているのは、追いつくかどうかで待ちの伸び方が段差で変わるという点と、区画を増やしても偏った鍵が下限を作るという点の2つです。
Pub/Sub is an asynchronous and scalable messaging service that decouples services producing messages from services processing those messages.原文Google Cloud ドキュメント「What is Pub/Sub?」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る