azure - Azure EventGrid Webhook タイムアウト

Question

Webhook のタイムアウトが 60 秒であることをドキュメントから知りました。その場合、開発者が非同期操作を行うことを期待していますか? Webhook の一部として実行したい作業に 60 秒以上かかる場合はどうなりますか? しかし、その操作を非同期にし、Webhook の一部として実行したい作業が失敗した場合、イベント グリッド 200 OK に既に応答しているため、その状況からどのように回復するのでしょうか。その場合、イベントに負けますか?

Answer 1

60 秒を超えるイベント ハンドラー処理などのシナリオでは、再試行と配信不能の手法に基づいて、次のことを実装できます。

• 再試行ポリシーと配信不能でプライマリ イベント サブスクリプションを使用します。ストレージ テーブルにバインドされたこのサブスクライバー (関数) は、長時間 (最大 24 時間) のイベント処理の状態を処理し、最初のイベント メッセージをストレージ キューに転送して長時間実行プロセスをトリガーします。このプライマリ サブスクライバーからの応答は、StorageQueueTrigger 関数の状態によって異なります。

• すべての新しい再試行イベント メッセージは、実行時間の長いプロセスの状態をチェックし、それに基づいて、応答コード (たとえば、OK(200) または Service.Unavailable(503)) が Event Grid に送り返されます。

上記のシナリオでは、再試行メカニズムは、長時間実行されるイベント メッセージ処理を監視するための「ウォッチドッグ タイマー」を表しています。QueueTrigger 関数などの 2 番目の関数は、Event Grid と実行時間の長いプロセスの間のプロセスを生成します。

要約すると、シナリオには次のものが必要です。

• Webhook の再試行ポリシーと配信不能機能を備えた EventSubscriber (EventGridTrigger または HttpTrigger 関数)
• EventGridTrigger または HttpTrigger 関数
• 収納テーブル
• QueueTrigger 関数

ウォッチドッグ タイマー中に何か異常が発生した場合、deadLetterReason を使用してデッド レタリングがコンテナー ストレージに送信されます。

実行時間の長いプロセスが 5 分または 10 分を超える場合は、App Service プランで、またはカスタム ワーカー プロセッサを使用して、StorageQueue トリガーを考慮する必要があることに注意してください。

アップデート：

次の画面スニペットは、ウォッチドッグ タイマーを使用した「長時間実行サブスクライバー」に対する上記のソリューションを示しています。

また、StorageQueue イベント ハンドラーを直接使用して、EventGrid から長時間実行されるプロセスを生成することもできますが、この場合、関数には、再試行、通知、配信不能など、より多くの責任があります。次の図を参照してください。