上限と割り当ては、Alert Center API を不適切な方法で使用する自動プロセスから Google のインフラストラクチャを保護します。API からの過剰なリクエストは、無害な入力ミスが原因である場合もあれば、不必要に API 呼び出しを行う非効率的な設計のシステムが原因である場合もあります。こうした原因とは無関係に、Google Workspace システムの全体的な正常性を維持するには、特定のソースからのトラフィックが一定のレベルに達した場合にトラフィックをブロックする必要があります。これにより、あるデベロッパーの操作によってコミュニティに悪影響が及ぶ事態を防ぐことができます。
API リクエストが失敗すると、HTTP ステータス コードのレスポンスが返されます。ステータス コード 403
には、入力が正しくないことに関するエラー情報が含まれ、HTTP ステータス コード 503 には、どの API
割り当てを超過したかを示すエラー情報が含まれます。これらのレスポンスにより、カスタム アプリケーションでこれらのエラーを検出し、適切なアクションを実行できます。
リクエストを一定期間内に完了する必要がある場合は、リクエストを並行して送信するか、Java または C# アプリケーションで複数のスレッドを使用します。並行リクエストの例としては、1 人のユーザーから大量のメールを追加または削除するのではなく、複数のユーザーから少量のメールをリクエストすることが挙げられます。スレッドの場合は、ユーザー メールごとに 1 つのスレッドで、10 個のスレッドから開始してみてください。なお、スレッドの推奨事項にはトレードオフがあり、すべての API の状況で役立つわけではありません。リクエストの数が多すぎると、割り当てエラーが発生します。
時間ベースのエラー（スレッドごとに N 秒間に最大 N 個）については、特に 503 ステータス コードのエラーの場合、コードで例外をキャッチし、指数バックオフ アルゴリズムを使用して、失敗した呼び出しを再試行する前に少し待つことをおすすめします。1 つのスレッドの Alert Center API の例では、5 秒待ってから失敗した呼び出しを再試行します。リクエストが成功した場合は、他のスレッドでもこのパターンを繰り返します。2 回目のリクエストが成功しなかった場合は、呼び出しが成功するまで、アプリケーションでリクエストの頻度を減らす必要があります。たとえば、最初の 5 秒の遅延を 10 秒に増やして、失敗した呼び出しをもう一度再試行します。また、再試行の上限を決定します。たとえば、アプリケーションがユーザーにエラーを返す前に、異なる遅延時間でリクエストを 5 ～ 7 回再試行します。
| API 上限カテゴリ | 上限 |
|---|---|
| アラート センターの QPS と QPD のレート | API は、Google Cloud プロジェクトのリクエスト数を制限します。API プロジェクトの 1 秒あたりの最大リクエスト数（プロジェクト QPS）
は 1,000 です。また、ユーザーごとの 1 秒あたりの最大リクエスト数
（ユーザー QPS）は 150 です。
これらの上限を超えると、サーバーは HTTP
|
| その他の種類の上限 | 制限事項とガイドライン |
|---|---|
| データ形式（デフォルト） | デフォルトのデータ形式は JSON です。 |
| 未承認のリクエスト | Google では、この API への未承認のリクエストは許可されていません。承認トークンが指定されていない場合、リクエスト は未承認とみなされます。詳細については、リクエストの承認をご覧ください。 |
プロジェクトごとの割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用しているとみなされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が増えるにつれて、割り当て値を増やす必要が生じる可能性があります。使用量の大幅な増加が見込まれる場合は、事前に [割り当て量の調整] を Google Cloud コンソールの [割り当てとシステムの上限] ページからリクエストできます。
詳細については、次のリソースをご覧ください。