使用量上限と割り当て

上限と割り当ては、Alert Center API を不適切な方法で使用する自動プロセスから Google インフラストラクチャを保護します。API から過剰なリクエストが発生するのは、無害なタイプミスや、システムが非効率な設計で不要な API 呼び出しを行うことが原因かもしれません。原因にかかわらず、Google Workspace システムの全体的な健全性を保つには、特定のソースからのトラフィックを特定のレベルに達したらブロックする必要があります。あるデベロッパーの行為が、より大きなコミュニティに悪影響を与えることがないようにする。

万が一 API リクエストが失敗した場合は、HTTP ステータス コード レスポンスが返されます。ステータス コード 403 には入力ミスに関するエラー情報が含まれ、HTTP ステータス コード 503 には超過した API 割り当てを示すエラー情報が含まれます。これらのレスポンスにより、カスタム アプリケーションでこれらのエラーを検出して適切な措置を講じることができます。

リクエストを一定時間内に完了する必要がある場合は、リクエストを並行して送信するか、Java または C# アプリケーションで複数のスレッドを使用します。並列リクエストの例としては、1 人のユーザーから大量のメールを同時に追加または削除するのではなく、異なるユーザーからのメールを少量ずつリクエストするというものがあります。スレッドの場合は、10 スレッド(ユーザーのメール 1 通につき 1 スレッド)から始めてみてください。スレッドの推奨事項にはトレードオフがあり、すべての API の状況に役立つわけではありません。リクエスト数が多すぎると、割り当てエラーが発生します。

時間ベースのすべてのエラー(スレッドあたり最大 N 秒、最大 N)、特に 503 ステータス コード エラーについては、コードで例外をキャッチし、指数バックオフ アルゴリズムを使用して少し遅延してから、失敗した呼び出しを再試行することをおすすめします。1 つのスレッドに対するアラート センター API の例では、5 秒待ってから失敗した呼び出しを再試行します。リクエストが成功したら、他のスレッドに対してこのパターンを繰り返します。2 番目のリクエストが成功しなかった場合、アプリケーションは呼び出しが成功するまでリクエストの頻度にスケールダウンします。たとえば、最初の 5 秒の遅延を 10 秒に増やして、失敗した通話を再試行します。また、再試行の上限も決定します。たとえば、遅延時間を変えてリクエストを 5 ~ 7 回再試行すると、アプリケーションからユーザーにエラーが返されます。

API 制限のカテゴリ 上限
アラート センターの QPS と QPD の料金 API は、API Console プロジェクトのリクエスト数を制限します。API プロジェクトの 1 秒あたりのリクエストの最大数(プロジェクト QPS)は 1,000 です。また、1 ユーザー 1 秒あたりの最大リクエスト数(ユーザー QPS)は 150 です。

これらの上限を超えると、サーバーは HTTP 503 ステータス コードを返します。リクエストを再試行する場合は、指数バックオフ アルゴリズムを使用します。

その他の制限の種類 制限事項とガイドライン
データ形式、デフォルト デフォルトのデータ形式は JSON です。
未承認のリクエスト この API への未承認のリクエストは許可されません。認証トークンが指定されていない場合、リクエストは承認されていないと見なされます。詳細については、リクエストの承認をご覧ください。

プロジェクトごとの割り当ての増加をリクエストする

プロジェクトのリソース使用量に応じて、割り当ての増加をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用しているとみなされます。割り当ての増加を申請しても、承認が保証されるわけではありません。割り当ての増加が大きい場合は、承認に時間がかかることがあります。

割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が多くなるに伴い、割り当ての増加が必要になる場合があります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当て] ページから割り当ての調整をリクエストできます。

詳細については、次のリソースをご覧ください。