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からのメッセージの受信とロックを行います。
Service Busを利用していると際に、Service BusとFunctionsからのネットワークが切断されたりすると、
Message processing errorというエラーログが出力されます。
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 を有効にすると、セッションが付与されたメッセージを受信することが可能になります。
セッションを有効にするとFunctionsはメッセージ受信時に、セッションIDが同じメッセージを全て、排他ロックします。
Message processing error などエラーが発生した場合は、メッセージのロックを解除して、同じメッセージを受信するため、FIFOを維持することができます。
おわりに
この記事では、Service Bus Queues Triggerのメッセージ処理順がFIFOにならない事象と対策について、ご紹介しました。
Azureの各サービスは、多数のオプションが用意されているので、要件に応じて、適切なオプションを設定するようにしましょう。
