高可用性、一貫性のあるパフォーマンス、動的スケールを目的として設計された Azure イベント ルーティング サービス。
こんにちは @Hiroaki Matsui ,
この動作は、メッセージの配信状況によっては仕様上発生し得ます。
Event Grid の MQTT ルーティングは、at-least-once(少なくとも1回)配信モデルを採用しています。そのため、設定されたルーティング先への配信に失敗した場合、Event Grid は指数バックオフ方式で配信を再試行します。この仕組みにより、同一メッセージが重複して配信される可能性があり、受信側(サブスクライバー)では重複メッセージを適切に処理できる設計が推奨されます。
したがって、MQTT クライアントがすでに切断されている場合でも、Event Grid がルーティング先への配信を完了できていない場合は、同一の LWT(Last Will and Testament)メッセージの再送が継続する可能性があります。
考えられる要因としては、以下が挙げられます。
配信先エンドポイント(例:Container Apps やその他のサブスクライバー)への配信が、認証・認可エラー、アプリケーションエラー、スロットリング、ネットワーク障害、一時的なサービス障害などにより失敗している。
設定されたルーティング先が利用できない、またはリトライ対象となるエラーを返しているため、Event Grid が配信を継続して試行している。
また、Event Grid はメッセージの順序を保証しません。そのため、重複配信や順序が入れ替わった配信が発生する可能性も仕様上考慮する必要があります。
ブローカー側でキューに残っているメッセージをクリアする方法はありますか?
現時点では、ブローカー側で保留中またはリトライ中の MQTT メッセージを手動でクリアするための操作は提供されていません。一般的には、メッセージの再試行は、配信が成功するか、リトライのライフサイクルが終了するまで継続します。
そのため、メッセージの再送が継続している場合は、ブローカー側のキューをクリアするのではなく、配信先で発生しているエラーの原因を特定・解消することが推奨されます。
クライアント切断後も再送は継続しますか?
はい。
Event Grid の再試行は MQTT クライアントの接続状態ではなく、ルーティング先への配信結果に基づいて行われます。そのため、メッセージがまだ正常に配信されていない場合は、メッセージを発行した MQTT クライアントが切断された後でも、同一メッセージの再送が継続する可能性があります。
また、サービスは at-least-once 配信を採用しているため、受信側アプリケーションでは必要に応じて重複メッセージを検出・無視できる実装を行うことが推奨されます。
ご確認いただきたい点
配信先エンドポイント(Container Apps や Python アプリケーションなど)が Event Grid からの配信を正常に受け付けているかご確認ください。
Event Grid の診断ログを確認し、スロットリングやサービスエラーなどの配信失敗が発生していないかご確認ください。
サブスクライバー側アプリケーションが重複メッセージを処理できる実装となっているかご確認ください。
- LWT 用トピックで MQTT の Retain が有効になっている場合は、その設定が今回の事象に影響していないかご確認ください。
お役に立てれば幸いです。
この回答がお役に立ちましたら、お手数ですが、をクリックし、「この回答は役に立ちましたか?」 の質問に対して 「はい」 をクリックしていただけますと幸いです。また、ご不明な点やご質問がございましたら、お気軽にお知らせください。