上限と割り当ては、アラート センター 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 は、API Console プロジェクトのリクエスト数を制限します。API プロジェクトの 1 秒あたりの最大リクエスト数（プロジェクト QPS）は 1,000 です。また、ユーザーごとの 1 秒あたりの最大リクエスト数（ユーザー QPS）は 150 です。 これらの上限を超えると、サーバーは HTTP |
| その他の種類の制限 | 制限事項とガイドライン |
|---|---|
| データ形式、デフォルト | デフォルトのデータ形式は JSON です。 |
| 承認されていないリクエスト | Google は、この API への不正なリクエストを許可していません。認証トークンが提供されていない場合、リクエストは未承認とみなされます。詳細については、リクエストの承認をご覧ください。 |
プロジェクトごとの割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用していると見なされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が多くなるに伴い、割り当て値を増やす必要が生じることがあります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの割り当てページから割り当ての調整をリクエストできます。
詳細については、次のリソースをご覧ください。