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