可用性と信頼性

Fallback URL

Twilio はサービスの高可用性を確実にするために、冗長したクラスター構成を維持しています。 しかし、これはまだ半分でしかありません。 Twilioアプリケーションの本質上、ユーザのWebアプリケーションも同様に、高い信頼性と高可用性が必要です。 この件でのユーザ支援として、Twilioは [アカウントポータル][2] や REST API の [IncomingPhoneNumbers][3] リソースから着信した電話番号に対し、Fallback URL の設定を許可しています。 アカウントポータル や REST API の IncomingPhoneNumbersリソースから着信した電話番号に対し、Fallback URL の設定を許可しています。

Fallback URL とは、音声通話におけるエラー発生時に Twilioがリクエストを送る先のURLです。 もし、TwilioがWebサーバからTwiMLを取得または実行できなかった場合、直ちに 適切な Fallback URL へリクエストが生成されます。 Twilioは、エラーコードとどのURLで失敗したのかを示す ErrorCode パラメータと ErrorURL パラメータを送信します。 更に追加の TwiML を使えば、この Fallback URL へのリクエストに応答することで独自のアプリケーションエラーメッセージを返したり、該当の音声通話やSMSのセッションを継続するためのリカバリを試行したりすることもできます。

ケース例

プライマリWebサーバのフェイルオーバー

問題: プライマリWebサーバがダウンした場合でも、確実にTwilioアプリケーションが音声通話を受信できるようにしたい。

解決: 受信電話番号の Voice URL を "http://www.mysite.com/index" に、Voice FallBack URL を "http://fallback.mysite.com/index" に設定します。 もし Twilio が "http://www.mysite.com/index" にリクエストをかけ、HTTPエラーが発生するか、接続が失敗した場合、"http://fallback.mysite.com/index" がリクエストされます。 もし、Fallback URL が有効なTwiMLを返した場合、Twilio はそのTwiMLを使って、エラーが無かったものとして処理を継続します。

エラーメッセージのカスタマイズ

問題: 発信者に、デフォルトのTwilioアプリケーションエラーメッセージを聞かせたくない。

解決カスタムエラーメッセージとして、<Say><Play> を使った TwiML を作成します。 対象電話番号の Voice Fallback URL をこのTwiMLへのURLに設定します。 もしTwilioがエラーに成った場合、デフォルトのエラーメッセージの代わりに、このカスタムエラーメッセージが流れます。

例:

<?xml version="1.0" encoding="UTF-8" ?>
<Response>
    <Say>
      An application error has occured.  
      Please call back later
    </Say>
</Response>
エラーキャッチ

問題: エラーの発生に気づきたい。

解決: ErrorCode と ErrorUrl を受け取れる URL を Fallback URL に設定します。 アプリケーションで、これらのエラーをロギングし、E-mailで通知するなどの処理をします。 このリクエストに対し、TwiMLを使って生じたエラーメッセージを含ませて応答したり、リカバリや通話の継続を試みたりすることができます。

ヘルプが必要ですか?

誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。