Twilio を利用するということは、コミュニケーションというインフラを支えるサービスを開発する責務を負うことになります。人々にとって「動いていて当たり前」なサービスを実現するために、すぐにでも障害が検知できるような仕組みを整えましょう。
本記事では私が日頃からキャッチアップしている情報元をご紹介します。
Twilio Status
全国の Twilio の運営ステータスを共有するハブです。RSS なり Twitter なりでフォローしておくと良いでしょう。私は RSS を Slack で連携させていつでもキャッチできるようにしています。
ただ実際はほとんどが日本国外の障害通知であり、グローバルに Twilio サービスを展開していない限りはほとんど役になることはありません(それはそれで安定していいことです)。 Twilio Video や Chatといったサービスは、グローバルな情報となるので、基本的に電話以外をやっている場合はしっかりフォローしておいたほうが良いでしょう。
私たちの場合は Twilio Chat でこのアラートが役に立ったことがあります。
KDDI ウェブコミュニケーションズ社の障害報告
こちらが日本での障害通知を出していただいているページです。こちらも RSS で提供してくれているので、キャッチアップしておきましょう。
今年の 6,7月あたりは色々と工事があって大変だったみたいですが、最近は落ち着いています。いつもありがとうございます。
Twilio と接続するサーバーのエラー検知
不正な TwiML や、Webサーバ側のエラーで正しく電話ができない、という場合も当然あることでしょう。その場合は Twilio が原因ではなく、 Web サーバ側の問題です。この住み分けは簡単にできます。 Twilio では豊富なデバッグツールや検知の仕組みを用意してくれているためです。
特に大事なのがフォールバックURL です。これは最初の Twilio からの電話リクエストに失敗した時に限り、リクエストを送るセカンダリのような役割を果たします。TwiML を返すサーバーがそのものが落ちていたりする場合にフォールバックURLすらも動かなくなってしまうので、フォールバックURL先は別のサーバーを指定したいところです。
そんな時は是非 巷で話題のサーバーレスアーキテクチャを使いましょう。以前、私がハンズオンという形で紹介した Qiita の記事をシェアします。
そもそもの根幹をキャッチするには
Twilio から発せられる障害通知は、ユーザーからもしくは Twilio サーバ側でアラートを受け取って、運営元が確認が取れ次第出てくる情報のため、どうしてもタイムラグが発生します。まず気づかなければならないのは Twilio でサービスを提供している私たちです。
ほとんどの場合、問題の原因となっているのはアプリケーション開発者側の問題です。先ほどの説明の通り、 Twilio から受け取るリクエストを正しく返せていなかったり、Webサーバー自体が落ちていたりするような場合です。色々な原因を探った上で、明らかに Twilio で問題が起きている、とわかった時点で私は問い合わせるようにしています。
ここで私が行っているのは、問い合わせる前に、「今 Twilio 調子悪くないですか？」と言い合えるような他のTwilioユーザーさんと繋がっています。Twilio をかなり使い込んでいる会社さんと情報共有を密に取り、何かあればお互いがすぐに連絡を取り合って確認しあえるあような状態を作っています。このような関係をは Twilio ユーザー同士で作ることができると思いますので、共有できる間柄を増やしたいと思っています。もし興味あればご連絡いただければ幸いです。