Google Chat API は共有サービスであるため、すべてのユーザーが公平に使用できるように、また Google Workspace の全体的なパフォーマンスを保護するために、割り当てと上限が適用されます。
割り当てを超えると、429: Too many requests HTTP ステータス コード レスポンスが返されます。Chat バックエンドに対する追加のレート制限チェックでも、同じエラー レスポンスが生成されることがあります。このエラーが発生した場合は、指数バックオフ アルゴリズムを使用して、後で再試行する必要があります。次の表に記載されている 1 分あたりの割り当て内であれば、1 日あたりのリクエスト数に上限はありません。
Chat API メソッドには、プロジェクトごと、スペースごと、ユーザーごとの割り当てなど、複数の割り当てタイプが適用される場合があります。
プロジェクトごとの割り当て
プロジェクトごとの割り当ては、Google Cloud プロジェクトのクエリ率を制限するため、割り当てごとに指定された Chat API メソッドを呼び出す単一の Chat 用アプリに適用されます。
次の表に、プロジェクトごとのクエリの上限を示します。これらの上限は、割り当てページでも確認できます。
プロジェクトごとの割り当て |
Chat API メソッド |
上限（60 秒あたり） |
|---|---|---|
1 分あたりのメッセージの書き込み数 |
|
3000 |
1 分あたりのメッセージの読み取り数 |
|
3000 |
1 分あたりのメンバーシップの書き込み |
|
300 |
1 分あたりのメンバーシップの読み取り |
|
3000 |
1 分あたりのスペースの書き込み |
|
60 |
1 分あたりのスペースの読み取り |
|
3000 |
1 分あたりの添付ファイルの書き込み |
|
600 |
1 分あたりの添付ファイルの読み取り数 |
|
3000 |
1 分あたりのリアクションの書き込み |
|
600 |
1 分あたりのリアクションの読み取り数 |
|
3000 |
スペースごとの割り当て
スペースごとの割り当ては、特定のスペースでのクエリのレートを制限し、そのスペースで動作するすべての Chat 用アプリ間で共有されます。各割り当てに対して、リストされている Chat API メソッドを呼び出します。
次の表に、スペースごとのクエリの上限を示します。
スペースごとの割り当て |
Chat API メソッド |
上限（60 秒あたり） |
|---|---|---|
1 分あたりの読み取り数 |
|
900 |
1 分あたりの書き込み数 |
|
60 |
ユーザーあたりの割り当て
ユーザーごとの割り当ては、Google Chat ユーザーのクエリ率を制限します。クエリは、ユーザーに代わって（ユーザー認証を使用して）Chat API メソッドを呼び出すすべての Chat 用アプリに関連します。
次の表に、ユーザーごとのクエリの上限を示します。
ユーザーあたりの割り当て |
Chat API メソッド |
上限（60 秒あたり） |
|---|---|---|
1 分あたりの読み取り数 |
|
900 |
1 分あたりの書き込み数 |
|
60 |
その他の使用量上限
GROUP_CHAT タイプまたは SPACE タイプのスペースを作成する場合（spaces.create メソッドまたは spaces.setup メソッドを使用）、割り当て上限が追加で適用されます。これらのタイプのスペースを 1 分あたり 35 個未満、1 時間あたり 800 個未満で作成します。タイプ DIRECT_MESSAGE のスペースは、これらの追加の割り当て上限の対象になりません。
同じスペースをターゲットとする API トラフィックが多いと、[割り当て] ページに表示されない内部制限が追加でトリガーされることがあります。
時間ベースの割り当てエラーを解決する
時間ベースのエラー（X 分あたり最大 N 回のリクエスト）については、コードで例外をキャッチし、切り捨てられた指数バックオフを使用して、デバイスが過剰な負荷を生成しないようにすることをおすすめします。
指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法です。指数バックオフのアルゴリズムは、リクエスト間の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。リクエストがまだ成功しない場合は、リクエストが成功するまでリクエスト間の遅延が時間とともに増加することが重要です。
アルゴリズムの例
指数バックオフのアルゴリズムは、再試行の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。次に例を示します。
- Google Chat API にリクエストを送信します。
- リクエストが失敗した場合、1 +
random_number_milliseconds秒待ってから、リクエストを再試行します。 - リクエストが失敗した場合、2 +
random_number_milliseconds秒待ってから、リクエストを再試行します。 - リクエストが失敗した場合、4 +
random_number_milliseconds秒待ってから、リクエストを再試行します。 - このようにして、最大
maximum_backoff時間まで繰り返します。 - 再試行の最大回数まで待機と再試行を続行しますが、再試行の間の待ち時間は増加させません。
ここで
- 待ち時間は
min(((2^n)+random_number_milliseconds), maximum_backoff)で、nは繰り返される（リクエスト）のたびに 1 増加します。 - 上記のフローで、
random_number_millisecondsは、1,000 ミリ秒以下の乱数です。これにより、ある状況で、多数のクライアントが同期して再試行を一度に実行し、リクエストが同時に次々と送信されるような状況を避けることができます。random_number_millisecondsの値は再試行リクエストの後に毎回再計算されます。 - 通常、
maximum_backoffは 32 秒または 64 秒です。適切な値はユースケースによって異なります。
クライアントは、maximum_backoff 時間が経過した後も再試行を続けることができます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントで 64 秒の maximum_backoff 時間が使用されている場合、この値に達した後は、クライアントは 64 秒ごとに再試行を繰り返します。無限に再試行することは、クライアントが、どこかの時点で止める必要があります。
適切な再試行間の待ち時間と再試行回数は、ユースケースとネットワークの状態により異なります。
プロジェクトごとの割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用していると見なされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が多くなるに伴い、割り当て値を増やす必要が生じることがあります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの割り当てページから割り当ての調整をリクエストできます。
詳細については、次のリソースをご覧ください。