このドキュメントでは、Webhook への大量のメッセージを処理するための最適な準備方法について説明します。ビジネス メッセージ プラットフォームは、さまざまなシナリオに対応する本番環境向けのものです。特定のイベントを予想している場合は、サポートチームが準備をお手伝いすることもできます。簡単な手順で、Webhook の堅牢性を高めることができます。
ユーザーから Webhook へのトラフィック
ユーザーから Webhook へのトラフィックの場合は、ビジネスで想定されるトラフィック パターンを検討します。メッセージ量の急増や急激な変化を予測していますか？たとえば、夕食のみを提供するレストランでは、夕方に多くのメッセージが届き、それ以外の時間帯にはほとんどメッセージが届かない可能性があります。別の例として、特別なプロモーションを実施している店舗では、プロモーションの発表時に異常に多くのメッセージが送信される可能性があります。
一般に、Google インフラストラクチャは、トラフィックの急増に対応できるように準備されています。Business Messages は、Gmail や Google Cloud などの大規模なプロダクトと同じサーバー リソースを使用します。Webhook へのメッセージ数が非常に多くなり、ビジネス メッセージが障害となる可能性は低いです。また、ビジネス メッセージでは、各エージェントのメッセージが個別にキューに追加されます。エージェントのメッセージ キューのいずれかが輻輳状態になっても、同じ Webhook を共有している場合でも、他のエージェントに影響することはありません。
ただし、これはビジネス メッセージ インフラストラクチャのメッセージ キューにのみ適用されます。メッセージが Webhook に配信されたら、状況は異なります。キューの実装やリクエストの並列処理などにより、必要に応じて Webhook をスケーリングできるようにする必要があります。Webhook がメッセージに HTTP 500 で応答するか、まったく応答しない場合、ビジネス メッセージは Webhook へのメッセージ配信レートを指数関数的に減らします。メッセージはキューに 7 日間留まります。Webhook がその時間内に HTTP 200 で応答しなかった場合、ビジネス メッセージはメッセージを破棄します。
Webhook からユーザーへのトラフィック
Webhook から送信されるメッセージは、会話あたり 1 分あたり 60 件のメッセージの割り当てに従う必要があります。正当なメッセージ フローがこの割り当てに達することはほとんどありませんが、割り当て超過を示す Business Messages からの HTTP 429 エラーを処理する準備が必要です。
一般に、Webhook が Business Messages から HTTP 429 または HTTP 500 を受信した場合は、メッセージ送信レートに関連する一時的なエラーを示しています。このようなメッセージは、指数バックオフ戦略で再試行する必要があります。ただし、Webhook が HTTP 503 または HTTP 4xx（HTTP 429 以外）を受信した場合は、再試行を停止し、すぐにサポートチームに通知する必要があります。これらのエラーコードは、DOS インシデントなど、ビジネス メッセージ インフラストラクチャに問題があることを示している可能性があります。メッセージをさらに送信すると、問題が悪化するだけです。
メッセージ クォータの超過に関連する特定の停止基準はありませんが、ビジネス メッセージでは、異常な動作をしているエージェントや、あまりにも多くのメッセージを送信しているエージェントを停止することがあります。停止基準を確認し、エージェントが必要な基準を遵守していることを確認してください。
サポートの利用方法
問題が予想される場合は、できるだけ早くご連絡ください。広告宣伝が盛んなプロモーション キャンペーンなど、トラフィック量が非常に多い状況が予想される場合は、事前に準備できるよう、追加の配信リソースをスピンアップできます。ただし、ほとんどの場合、このような対策は必要ありません。
メッセージの読み込みに関する問題が発生している場合は、Google にお問い合わせください。解決に向けてサポートさせていただきます。