TwilioのWebHookでエラー時のリカバリ
Twilioでは着信等のイベントでのWebHookで指定のサーバのAPIにデータをPOSTしてくれるWebHookの仕組みがあり、WebHookの接続エラーのリカバリとしてFallBackの仕組みが提供されています。
今回WebHookのエラー時の振る舞いをカスタマイズし、処理改善を行う案件にて「Webhooks: Connection Overrides」を使用しました。
WebHookを利用するには上のTwiMLAppに登録するのが便利です。
・RequesutURL：着信などイベント発生時のWebHook先URL
・FallBackURL：WebHookエラー時のアクセス先URL
Twilio側のざっくりとしたフローは下図となり
赤字のエラー分岐のデフォルトは
・TCP接続：5000ms
・HTTPレスポンス待ち：15000ms
となり、リトライはありません。
この部分をカスタマイズ可能とする機能として「Webhooks: Connection Overrides」があります。
https://jp.twilio.com/docs/usage/webhooks/webhooks-connection-overrides
Connection Overridesの設定
設定可能なパラメータ
| パラメータ名 | 初期値 | 備考 |
|---|---|---|
| ct | 5000 | TCPコネクションのタイムアウト判定値 |
| rt | 5000 | HTTPリクエスト後レスポンスの待ち時間 |
| tt | 15000 | 上2つを含むトータルタイム |
| rc | 1 | エラー時リトライ数 |
| rp | ct | リトライを行うルール(4xx\5xx\ct\rt\allからカンマ区切りで複数の設定も可能) |
| sni | unset | y or nでサーバ環境に合わせて設定 |
| e | ashburn | 近いロケーションを選ぶと処理が若干早くなる可能性があるようです |
やりたいこと
・RequesutURLはデフォルト(15000ms)より早めにタイムアウトしてFallBackへ流したい
・FallBackURLも早めにエラー判定をしてリトライ処理をしたい
この点を踏まえパラメータを組みました(例は3000msを処理判定の基準としています)。
・RequesutURL：TCP接続、HTTPレスポンス待ちに関わらず3秒でダメならFallBackへ
->https://XXXXXXXXXXXXXX/#tt=3000
・FallBackURL：絶対受け取りたいのでTCP接続、HTTPレスポンス待ちに関わらず
3秒でダメならリトライする
->https://XXXXXXXXXXXXXX/#tt=3000(誤った設定)&rc=5&rp=all&sni=y
をTwiMLAppに設定して各WebHook先URLにWaitを入れてConnection Overridesが発火するようにして試験したところ、
・RequesutURL->パラメータ通りにFallBackへ
・FallBackURL->リトライが発生しない
となりました。Twilioのサポートに質問してみたところ、丁寧にご説明を頂きました(助かりました)。
ttはリトライも含めたトータル時間なので、tt=3000を設定すると3000msで処理を終了しリトライは発生しないので、
・FallBackURL：
->https://XXXXXXXXXXXXXX/#ct=3000&rt=3000&rc=5&rp=all&sni=y
このようにTCP接続3000ms(ct=3000)/HTTPレスポンス待ち3000ms(rt=3000)とパラメータを設定すると正常にリトライ処理が行われました。
言われてみればその通りなのですが、安直に考え勘違いをしました。
効果
この処理を行う事で、WebHook連携にてネットワークに起因してリクエストが届かないなど発生した際に、早めにリカバリ(FallBack)に回す事でサービスの提供が安定化します。
また、リトライ処理を組み込む事で取りこぼしリスクを最小に出来ます。
Twilioの詳細は下のURLになります。
https://cloudapi.kddi-web.com/