Webhookリトライポリシーとは？

ウェブフックリトライポリシーは、ウェブフックシステムが、送信が失敗した場合にウェブフックを再送するかどうかを決定するために使用する一連のルールです。この設定では、システムの試行回数の上限、各試行間の停止時間、失敗の基準、および中止の条件が指定されます。ほとんどのポリシーでは、短期間での連続した試行を防ぐために指数関数的バックオフが採用されており、恒久的に失敗するイベントはデッドレターキューに送られます。

ネットワークやサービスは信頼性にばらつきがあるため、リトライポリシーは重要な考慮事項です。配信中にネットワークやサービスに障害が発生した場合のデータ転送の完了は、アクティブなリトライポリシーの存在に依存します。リトライポリシーは、受信側が2xxを返さない場合に再試行を保証することで、配信の失敗によるデータ損失を防ぎます。

イベント配信の試行中に問題が発生した場合、システムのポリシーは通常、HTTPステータスコードを調べてこれを処理します。その後、リトライスケジュールに従って一時停止が導入され、イベントの再送信が試行されます。これらの構成要素は次のとおりです。

•       トリガー条件: リトライをトリガーする正確なHTTPステータス
•       リトライスケジュール：試行間の時間間隔。通常、指数バックオフまたはRetry-Afterヘッダーから抽出された値。
•       障害の顕在化：次回の再試行時間の表示など、即座の解決なしに問題を特定できる機能を含みます。
•       可観測性と冪等性：失敗分析のためのログ、メトリクス、リプレイツール、および重複を吸収するための冪等な処理。

ほとんどのリトライ戦略は、試行間の間隔に遅延を組み込んでいます。最も頻繁に採用されているのは指数バックオフです。これは、各試行ごとに待機期間を延長し、その結果、何らかの問題を抱えている受信側の負担を軽減します。

これは以下のことを意味します。

•       指数バックオフ: リトライの試行が、徐々に長くなる時間間隔で区切られる手法です。
•       ジッターの追加待機時間をランダムな要素で変化させることで、同時に再試行が集中するのを避けます。Twilio Event Streamsは、「サウザンディングハード現象」を回避するためにジッターの考え方を実装しています。
•       段階的なリトライ即時、短期、長期、およびデッドレターキュー。

このキューは、設定されたリトライプロセスを使い切っても完了ステータスに到達しなかったイベントを対象としています。これらのイベントは指定された場所に保持され、その詳細の調査、シーケンスの監視、または状況に応じて対応することが可能です。

積極的な再試行ポリシーをむやみに模倣するのではなく、優れた再試行設計では、多すぎる再試行によってシステムが過負荷になる可能性のある時期を考慮します。つまり、再試行回数の上限とインターバルタイミングを慎重に検討することが含まれます。

•       指数バックオフとジッターを組み合わせたものの使用を優先してください。
•       明確に定義されたリトライ制限と停止条件を確立する。
•       どの配信を再試行し、どれを再試行しないかについて、曖昧でないステータスコード規則を確立する。
•       冪等性キーは、再処理の一貫した管理に関係します。

監視プラクティスは、パイプライン配信における不一致を早期段階で特定することに関係します。問題を示すメトリクスを追跡し、アラートを通じて自動的に通知し、それらを運用ツールと連携させます。

•       ダッシュボード: 直近の期間における配信健全性の概要。
•       手動リプレイ: 根本原因が解決された後、イベントを再度送信できるオプション。
•       ランブック: オンコールエンジニア向けの事前定義されたアクションを提示し、トラブルシューティングプロセスをガイドすることを目的とする。

•       失敗した配信を組織的に再試行するプロセスは、イベントが処理されないままになる可能性のあるケースに対処することを目的としています。
•       これにより、短期的な中断や配信の遅延中にイベントデータが失われる可能性が低減されます。
•       連携機能は通常、短期間の障害から回復し、関連する問題は長期的な停止を引き起こすのではなく、一時的なものであることがよくあります。
•       注文や支払いといった重要なデータの一貫した配信は、統合への信頼度に影響を与える要因となります。