Google Ads API では、顧客 ID と Google Cloud プロジェクトの両方に対して、秒間クエリ数（QPS）によるレート制限が個別に適用されます。Google Ads API では、1 分あたりのリクエスト数（API 呼び出しの頻度を測定）に加えて、1 分あたりのオペレーション数（リクエスト全体の API オペレーションの合計数を測定）にも上限が適用されます。Google Ads API は、トークン バケット アルゴリズムを使用して リクエストを測定し、適切な QPS 上限を決定します。そのため、正確な上限は、その時点のサーバー全体の負荷によって 異なります。
レート制限を課す目的は、1 人のユーザーが（意図的にまたは意図せずに）大量のリクエストで Google Ads API サーバーに負担をかけて、他のユーザーのサービスを妨げることがないようにすることです。
レート制限に違反するリクエストは、エラー
RESOURCE_TEMPORARILY_EXHAUSTEDで拒否されます。
リクエスト数を積極的に減らし、クライアント側から QPS をスロットリングすることで、アプリを制御し、レート制限を緩和できます。
レート制限を超える可能性を減らす方法はいくつかあります。 エンタープライズ統合パターン（EIP） のメッセージング、再配信、スロットリングなどのコンセプトを理解すると、 より堅牢なクライアント アプリを構築できます。
次の推奨事項は、複雑さの順に並べられています。シンプルな戦略が最初に記載され、より堅牢で高度なアーキテクチャが後に記載されています。
指数バックオフ
アプリケーションが
RESOURCE_TEMPORARILY_EXHAUSTEDエラーを受け取った場合は、失敗した
リクエストを再試行する前に、ランダムなジッターを含む
指数バックオフ ポリシーを使用します。指数バックオフは、再試行間の待ち時間を徐々に増やします（たとえば、2 秒、4 秒、8 秒の待ち時間に加えて、わずかなランダムな遅延を追加します）。これにより、サーバーの負荷と割り当てバケットを回復させながら、クライアント インスタンス全体で同期された再試行スパイクを防ぐことができます。
同時タスクの数を制限する
レート制限を超える根本原因の 1 つは、クライアント アプリが過剰な数の並列タスクを生成していることです。クライアント アプリが持つことができる並列リクエストの数に制限はありませんが、Google Cloud プロジェクト レベルで 1 秒あたりのリクエスト数 の上限を超える可能性があります。
同時並行でリクエストを送信するスレッド数については、プロセスや機器全体で適切な上限を設けることをおすすめします。そのうえで上方修正を重ねていけば、レート制限を超過せずにスループットを最適化できます。
さらに、クライアント側から QPS をスロットリングすることもできます（ スロットリングとレート制限を参照）。
バッチ リクエスト
複数のオペレーションを 1 つのリクエストにバッチ処理することを検討してください。これは、さまざまなサービスの Mutate 呼び出しに最も適しています。たとえば、複数の AdGroupAd インスタンスのステータスを更新する場合は、MutateAdGroupAds を 1 回呼び出し、各 AdGroupAd に対して MutateAdGroupAds を 1 回呼び出すのではなく、複数の operations を渡すことができます。その他の例については、
バッチ オペレーションのガイダンスをご覧ください。
リクエストをバッチ処理すると、API 呼び出しの合計数が減り、 1 分あたりのリクエスト数 のレート制限が緩和されますが、単一の アカウントに対して多数のオペレーションを実行すると、1 分あたりの オペレーション数 のレート制限がトリガーされる可能性があります。
スロットリングとレート リミッター
アプリケーション内のスレッドの合計数を制限するだけでなく、クライアント側でレート制限を実装することもできます。これにより、プロセス、クラスタ、またはその両方のすべてのスレッドが、クライアント側から特定の QPS 上限によって管理されます。
Guava RateLimiter を確認するか、クラスタ環境用に独自の トークン バケット アルゴリズムを実装してください。たとえば、Redis や Memcached などの分散型の低レイテンシ インメモリ データストアでトークンを管理できます。各クライアントは、リクエストを処理する前にトークンを取得して使用します。トークンが使い果たされると、クライアントは次のトークン バッチが補充されるまで待機します。
キューイング
オペレーションの負荷を分散し、リクエストとコンシューマーのレートを管理する場合は、メッセージ キューを使用するのが得策です。オープンソースのものから商標権があるものまでさまざまなメッセージ キューがあり、その大部分は複数の言語に対応しています。
メッセージ キューを使用すると、複数のプロデューサーからキューにメッセージがプッシュされ、複数のコンシューマーがそれらのメッセージを処理します。スロットルは、同時コンシューマーの数を制限するか、プロデューサーまたはコンシューマーのいずれかにレート制限またはスロットルを実装することで、コンシューマー側で実装できます。
たとえば、メッセージ コンシューマーがレート制限エラーを検出した場合、そのコンシューマーは標準化された再試行遅延（指数バックオフを使用）でリクエストをキューに戻し、共有レート リミッター フィードバック ループを更新して、すべてのコンシューマーがエラーから回復しながら処理速度を自動的に低下させることができます。