Google Chat API は共有サービスであるため、Google Chat のメッセージには すべてのユーザーが公平に使用できるようにし、 パフォーマンスが向上します。
割り当てを超過すると、429: Too many requests HTTP が届きます。
ステータス コードのレスポンスが返されます。Chat でのその他のレート制限チェック
同じエラー レスポンスが生成される場合があります。このエラーが発生した場合は、
使用すべき
指数バックオフ アルゴリズム
しばらくしてからもう一度お試しください。記載されている 1 分あたりの割り当て内であれば、
表に示されているように、実行可能なリクエストの数に制限は
（1 日あたり）
Chat API メソッドには、スペースごととプロジェクトごとの 2 つの割り当てタイプが適用されます。 できます。
スペースごとの割り当て
スペースごとの割り当ては、特定のスペース内のクエリのレートを制限し、 そのスペースで動作しているすべての Chat アプリが、 各割り当ての Chat API メソッド。
次の表に、スペースごとのクエリの上限を示します。
スペースごとの割り当て |
Chat API のメソッド |
上限（60 秒あたり、スペース内のすべての Chat アプリで |
|---|---|---|
1 分あたりの読み取り数 |
|
900 |
1 分あたりの書き込み数 |
|
60 |
プロジェクトごとの割り当て
プロジェクトごとの割り当てにより、Google Cloud プロジェクトのクエリのレートが制限されます。 指定した API を呼び出す 1 つの Chat アプリが 各割り当ての Chat API メソッド。
次の表に、プロジェクトごとのクエリの上限を示します。また、 [割り当て] ページでこれらの上限を確認できます。
プロジェクトごとの割り当て |
Chat API のメソッド |
上限（60 秒あたり） |
|---|---|---|
1 分あたりのメッセージの書き込み数 |
|
3000 |
1 分あたりのメッセージの読み取り数 |
|
3000 |
1 分あたりのメンバーシップの書き込み数 |
|
300 |
1 分あたりのメンバーシップ読み取り数 |
|
3000 |
1 分あたりのスペース書き込み |
|
60 |
1 分あたりのスペース読み取り数 |
|
3000 |
1 分あたりのアタッチメントの書き込み数 |
|
600 |
1 分あたりのアタッチメントの読み取り数 |
|
3000 |
1 分あたりのリアクションの書き込み数 |
|
600 |
1 分あたりのリアクションの読み取り数 |
|
3000 |
追加の使用量上限
GROUP_CHAT タイプのスペースを作成する場合、追加の割り当て上限があります
または SPACE（spaces.create または spaces.setup メソッドを使用）。
1 分あたり 35 個未満のスペース、1 分あたり 210 個未満のスペースを作成可能
サポートしています。DIRECT_MESSAGE タイプのスペースはこれらの対象外です
追加の割り当て上限が適用されます。
同じスペースを対象とする API で秒間クエリ数（QPS）が大きいと、トリガーされる場合がある モジュールには表示されていない追加の内部制限が [割り当て] ページ。
時間ベースの割り当てエラーを解決する
すべての時間ベースのエラー（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 を使用する傾向にあるため、 割り当ての増加が必要になる場合があります今後のイベントで 使用量が増加した場合は、事前に 割り当ての調整をリクエストする [割り当て] ページで 確認できます。
詳細については、次のリソースをご覧ください。