Drive Labels API は共有サービスであるため、すべてのユーザーがこの API を公平に使用し、Google Workspace エコシステム全体の健全性を保護するために、割り当てと制限が適用されます。
割り当てを超過すると、通常は 429: Too many
requests HTTP ステータス コード レスポンスが返されます。その場合は、指数バックオフ アルゴリズムを使用して、しばらくしてからもう一度お試しください。以下の 1 分あたりの割り当てを超えない限り、1 日に実行できるリクエストの数に制限はありません。
次の表に、リクエストの上限の詳細を示します。
| 割り当て | |||
|---|---|---|---|
| 読み取りリクエスト |
|
||
| 書き込みリクエスト |
|
||
時間ベースの割り当てエラーを解決する
すべての時間ベースのエラー（X 分あたり最大 N 件のリクエスト）については、コードで例外をキャッチし、切り捨て型指数バックオフを使用して、デバイスが過度な負荷を発生させないようにすることをおすすめします。
指数バックオフは、ネットワーク アプリケーションにおける標準的なエラー処理方法です。指数バックオフのアルゴリズムは、リクエスト間の待機時間を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。それでもリクエストが失敗する場合は、リクエストが成功するまで時間の経過とともにリクエスト間の遅延を長くすることが重要です。
アルゴリズムの例
指数バックオフのアルゴリズムは、指数関数的にリクエストを再試行し、再試行間の待機時間を最大バックオフ時間まで増加させます。例:
- Drive Labels 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 ミリ秒以下の乱数です。これにより、ある状況で多数のクライアントが同期され、すべてが同時に再試行され、リクエストを同期 Wave で送信するケースを回避できます。random_number_millisecondsの値は再試行リクエストごとに再計算されます。- 通常、
maximum_backoffは 32 秒または 64 秒です。適切な値はユースケースによって異なります。
maximum_backoff 時間に達した後も、クライアントは再試行を続行できます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントが 64 秒の maximum_backoff 時間を使用していて、この値に達した後は、クライアントは 64 秒ごとに再試行できます。ある時点で、クライアントが無期限に再試行できないようにする必要があります。
再試行の間隔と再試行回数は、ユースケースとネットワーク状態によって異なります。
料金
Drive Labels API はすべて追加料金なしでご利用いただけます。割り当てリクエストの上限を超えても、追加料金はかからず、アカウントに対して請求されません。
割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての増加をリクエストできます。サービス アカウントによる API 呼び出しは、1 つのアカウントを使用するものとみなされます。割り当ての増加を申し込んでも、承認が保証されるわけではありません。割り当ての増加が大きい場合は、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が増加するにつれて、割り当ての増加が必要になることがあります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当て] ページから割り当ての調整をリクエストできます。
詳しくは、次のリソースをご覧ください。