Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事

はじめに

Service Bus Queues Triggerを用いたAzure Functionsにおいて、メッセージ処理順がキューに送信された順番にならず、FIFOにならないケースがあります。

本記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介します。

Service Bus Queues Triggerのメッセージ処理順がFIFOにならない原因

Service Bus TriggerのFunctionsはPeek&LockというモードでService Busからのメッセージの受信とロックを行います。

https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock

Service Busを利用していると際に、Service BusとFunctionsからのネットワークが切断されたりすると、 Message processing errorというエラーログが出力されます。

https://stackoverflow.com/questions/65999984/azure-function-v3-net-core-3-1-servicebustrigger-message-processing-error-act

Peek&Lockモードの場合、特定のスレッド/プロセスにて受信対象のメッセージのロック中に Message processing errorが発生すると、次回起動時に当該メッセージがロックされたままになっているために、後続のメッセージを先に受信してしまいます。

Service Busのセッションを用いた対策

上記のケースへの対応として、Service Busにはセッションという機能があります。

https://devblogs.microsoft.com/premier-developer/ordering-messages-in-azure-service-bus/ https://docs.microsoft.com/ja-jp/azure/service-bus-messaging/message-sessions

上記のドキュメントの内容を要約すると、以下のような挙動になるものと思われます。

Service Busのキューを作成する際に、セッションを有効にして作成すると、送信側はメッセージをキューに挿入する際に、セッションIDを付与することが可能になります。

受信側のFunctionsでService Bus Triggerの属性 IsSessionsEnabled を有効にすると、セッションが付与されたメッセージを受信することが可能になります。

https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-service-bus-trigger?tabs=csharp#configuration

セッションを有効にするとFunctionsはメッセージ受信時に、セッションIDが同じメッセージを全て、排他ロックします。
Message processing error などエラーが発生した場合は、メッセージのロックを解除して、同じメッセージを受信するため、FIFOを維持することができます。

おわりに

この記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介しました。
Azureの各サービスは、多数のオプションが用意されているので、要件に応じて、適切なオプションを設定するようにしましょう。