久し振りに Service Bus について調べる機会があったので、適当にコードを書いてどのくらいのスループットが出るのかと、クォーターで引っかかった後にどうなるかなど、気になっていた挙動も調べました。
Service Bus は Premium で試しています。Standard でもパーティションを設定すれば近いような性能は出るのではないかと思いますが、Service Bus 自体がいいお値段するので確認はしてません。
課金体系がプランごとに異なっているので分かりにくいですが、Premium の場合はユニット数分の時間課金だけとなるみたいです。Standard でパーティション増やして処理するより、Premium 1 つに変えた方が良いパターンもありそうです。
容量課金はないですが、1 Queue / Topic 単位での上限が存在しています。Standard でパーティションを使った場合と Premium でも上限は 80GB となっています。
この辺り Storage Queue は上限がかなり多いので気にすることはなかったですが、Service Bus の場合はデータサイズに気を付けた方が良いかもしれません。
Storage Queue は Base64 されて格納されてましたが、Service Bus はバイナリで直接扱われるので、LZ4 などの高速な圧縮アルゴリズムを使うのも良さそうです。
とりあえず Service Bus の限界にチャレンジするために、適当に Topic と Subscription を作成して、目一杯データを投入してみることにします。
まずはメッセージサイズの上限を確認するために 1MB のペイロードで試しました。
メッセージサイズがオーバーしているという例外となりました。Service Bus Premium では 1MB まで対応しているはずですが、ペイロード以外の付随するデータ分も含まれるみたいなので、UserProperties とか使っている場合ははまるかも知れません。
Service Bus と同じリージョンに VM を作成して、そこから 4KB のデータを投入してみました。データサイズが小さいので送信トラフィックは 130Mbps 前後でした。App Service を使っている場合はプランによって帯域も変わるので、ここも注意するポイントですね。
Azure Portal から Service Bus Topic を開くと Active message count などが確認出来ますが、この値は色々試していると秒間のメッセージ数っぽさがありました。
実際に 1000 並列ぐらいでメッセージを送信していたので、数値としてはまあまあ合っています。
しばらくすると用意した 80GB を全て使い果たしました。4KB のデータを使ったので約 2000 万メッセージというのも、予想から大きなずれはないですね。
用意した容量を全て使い切ると、送信時にクォーターに達したという例外となりました。
ちなみにエラーメッセージからわかるように 80GB というのは 80 * 1024 * 1024 * 1024 B です。
この状態からでも問題なく Topic からメッセージの受信は行えますし、受信して余裕が出来れば新しくメッセージを送信することも出来ます。ちゃんと動いてくれてますね。
一応確認しておきたかったのが、新しく Subscription を追加した場合でした。追加したとしても、既存の Subscription に入っているメッセージがコピーされることはないです。
メッセージを新しく送信すると 2 つ Subscription があれば両方ともに追加されるので、1 メッセージで消費する容量は 2 倍になります。当たり前と言えば当たり前の挙動です。
思っていたよりも Service Bus Premium は良い性能が出ていました。不安定さもあると少し聞いていましたが、今回のテストではきっちりと約 2000 万メッセージの投入もエラーなく行えました。
TTL も確認しておきたかったのですが高いので止めておきました。他にも autoDeleteOnIdle*1 が気になりましたが、それはまた今後試そうかと思います。
