要約

  • Twilioは7月31日15:35:24.910 UTC、軽微な影響としてインシデント3n1zx76hv9hvを開始した。
  • 最初の告知は、RCSとWhatsAppの双方について受信・送信メッセージの配信遅延を対象とした。
  • 16:35:17.874の更新でも遅延は続き、状態は調査中のままだった。
  • 16:44:39.656に復旧傾向を確認し、状態を監視中へ変更した。
  • 17:14:27.140に遅延が解消したとして解決済みにし、公開記録の幅は約99分となった。
  • 原因、地域、件数、エラー率、チャネル別内訳、滞留メッセージの照合結果は示されなかった。

99分は個々の待ち時間ではない

公開時系列は15:35:24.910 UTCの調査開始、16:35:17.874の継続確認、16:44:39.656の監視移行、17:14:27.140の解決という四つの点で構成される。開始から解決までを計れば約1時間39分である。

ただし、これは運用者が共通インシデントを開いていた時間であり、すべてのメッセージが99分間止まったことを示さない。影響対象への出入りは取引ごとに異なり得るため、サービス状態と個別配信の所要時間は分けて扱う必要がある。

遅配と消失では必要な対応が違う

Twilioが使った表現は配信の遅れだった。遅れたメッセージは後から届く可能性がある。失敗であれば再試行が必要な場合があり、消失なら受信者まで届かない。ステータス記録は後二者を報告していない。

重複、順序逆転、内容破損についても記載はない。利用者が自社ログで確認する価値はあるが、確認すべきリスクと、プラットフォーム全体で実際に発生した事実を混同してはならない。

受信と送信は別の運用経路を持つ

受信側は外部の利用者やネットワークからTwilio顧客のアプリケーションへ入り、送信側はアプリケーションから最終受信者へ向かう。双方は異なるキュー、接続先、配信確認を経由する可能性がある。

今回の告知は両方向をまとめて対象にしたが、どちらが深刻だったかは示していない。顧客側の検証も、送ったメッセージだけでなく、Webhookなどで受け取るはずだったメッセージを含めた双方向で行う必要がある。

二つの製品名は原因名ではない

RCSは通信事業者を含むリッチメッセージングの仕組みで、WhatsAppはMetaが運営するサービスである。二つが同時に影響対象となったことで、Twilio内の共通処理層を疑う余地は生まれるが、それは証明ではない。

TwilioはMeta、Google、通信事業者、容量不足、設定変更、ソフトウェアのいずれも原因として挙げていない。製品名は影響範囲を示すものであり、責任の所在を確定するものではない。

時間制約のある用途ほど影響が大きい

日常会話の数分の遅れと、期限付き認証コードの数分の遅れは経済的に同じではない。障害通知、詐欺検知、予約変更、緊急連絡でも、到着した時刻によってメッセージの有効性が変わる。

今回は国、通信事業者、送信者種別、顧客層、影響件数が不明である。そのため、一部の時間依存フローで起こり得る重大性を、世界全体の損失額や利用者数へ拡大して推計する根拠はない。

監視移行後にも台帳確認は残る

16:44:39.656の更新は復旧を観測していると述べたが、キューの深さや排出速度、再送が必要な項目は明らかにしなかった。解決時の更新も、遅延がもはや観測されないことを示す一方、個々の取引照合までは示していない。

顧客はメッセージIDと受付、送信、配信の各時刻を突き合わせ、中間状態のまま残る項目を探すべきだ。自動再試行を使った場合は、遅れて届いた元メッセージと再試行分が同じ業務処理を二度起動しないかも確認したい。

判断を更新するために必要な情報

技術報告、遅延分布、影響件数、受信・送信別、RCS・WhatsApp別、国・通信事業者別のデータが出れば評価は変わる。滞留、失敗、再生されたメッセージについての明示的な説明も重要である。

現時点の結論は限定的だ。二つのチャネルで双方向の配信遅延が発生し、復旧監視を経てWave 45の固定時間窓内に解決された。時系列は確認できるが、原因、規模、最終的な取引整合性は公開資料だけでは確定しない。

出典