現在、一部のレポートタイプをオフライン レポートからインスタント レポートに移行中です。ユーザーの移行が完了すると、
queries.list
のレスポンスに既存のインスタント レポートが含まれます。詳しくは、
ブログ投稿をご覧ください。
割り当て
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
割り当ては、Google Bid Manager API を不適切な方法で使用する自動プロセスから Google のインフラストラクチャを保護します。開発者の行動が大規模なコミュニティに悪影響を与えることを阻止できる。
割り当て上限
以下のデフォルトの割り当て上限は、すべての Bid Manager API リソースとメソッドで共有されます。
- プロジェクトごとに 1 日あたり 2,000 リクエスト - 引き上げ可能
- プロジェクトごとの秒間クエリ数(QPS)は 4 件。
- Google API Console では、この割り当ては「ユーザーごとの 1 分あたりのクエリ数」と呼ばれ、240 に設定されています。
割り当ての上限を超えた場合
万が一、割り当て上限を超えたためにリクエストが失敗すると、API は HTTP ステータス コードとエラーの理由を返します。また、レスポンスの本文にはエラーの原因の詳細な説明が含まれています。エラー レスポンスの例については、エラー メッセージのガイドをご覧ください。
割り当て上限の超過が原因で発生する、リクエストが失敗する可能性のあるエラーと推奨される対応を以下に示します。
コード |
理由 |
メッセージ |
推奨される対応 |
403 |
dailyLimitExceeded |
1 日の利用時間の上限を超えました |
問題を解決してから再試行します。Google API Console で使用状況を確認し、リクエストが少なくなるようにワークフローを変更します。使用量が妥当であると思われる場合は、追加の割り当てをリクエストできます。 |
403 |
userRateLimitExceeded |
ユーザーレートの上限を超えました |
指数バックオフを使用して、リクエストの送信頻度を下げます。 |
指数バックオフとは
指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法で、クライアントはリクエスト間の遅延を増加させながら、失敗したリクエストを定期的に再試行します。大量のリクエストまたは大量のネットワーク トラフィックが原因でサーバーがエラーを返した場合、指数バックオフはこのようなエラーの処理に適した方法です。逆に、承認認証情報が無効である、ファイルが見つからないなど、ネットワークのボリュームまたはレスポンス タイムに関係のないエラーの処理には適していません。
指数バックオフを適切に使用すると、帯域幅の使用効率が高くなり、より少ないリクエスト数で正常なレスポンスを受け取ることができ、同時実行環境でのリクエストのスループットが最大化します。
シンプルな指数バックオフを実装するフローは次のとおりです。
- API へのリクエストを作成します。
- リクエストの再試行が必要であることを示す
HTTP 503
レスポンスを受信します。
- 1 秒 + random_number_milliseconds の間待機してから、リクエストを再試行します。
- リクエストの再試行が必要であることを示す
HTTP 503
レスポンスを受信します。
- 2 秒 + random_number_milliseconds の間待機してから、リクエストを再試行します。
- リクエストの再試行が必要であることを示す
HTTP 503
レスポンスを受信します。
- 4 秒 + random_number_milliseconds の間待機してから、リクエストを再試行します。
- リクエストの再試行が必要であることを示す
HTTP 503
レスポンスを受信します。
- 8 秒 + random_number_milliseconds の間待機してから、リクエストを再試行します。
- リクエストの再試行が必要であることを示す
HTTP 503
レスポンスを受信します。
- 16 秒 + random_number_milliseconds の間待機してから、リクエストを再試行します。
- フローを停止します。エラーをレポートまたはログに記録します。
上記のフローで、random_number_milliseconds は、1,000 ミリ秒以下の乱数です。この乱数は、ランダムな短い遅延を発生させることで負荷をより均等に分散し、サーバーの暴走を防ぐために必要です。random_number_milliseconds の値は、待機するたびに再定義する必要があります。
注: 待機時間は常に (2 ^ n) + random_number_milliseconds(n は 0 から始まる単調増加整数)です。整数 n は、繰り返し(リクエスト)のたびに 1 ずつ増えます。
このアルゴリズムは、n が 5 になると終了するように設定されています。この上限によって、クライアントが無限に再試行を繰り返すことを防ぎます。総遅延時間が約 32 秒になると、リクエストは「回復不能なエラー」と判断されます。再試行の最大回数を増やすこともできますが(特に、長いアップロードを行う場合)、再試行の遅延時間には合理的な上限(1 分以内など)を設定してください。
1 日の追加割り当てをリクエストする
アプリケーションで 1 日の割り当てを追加する必要があれば、以下の手順に従って追加割り当てをリクエストできます。
次の手順は、dailyLimitExceeded
エラーが発生したプロジェクトにのみ適用されます。その他の割り当てエラーに対するおすすめの対処方法については、上記の表をご覧ください。
- Google API Console で Bid Manager API に移動します。
- [指標] ページの使用統計情報を確認して、アプリケーションが期待どおりに動作していることを確認します。呼び出されているメソッドをよく確認し、予期しない使用や過剰な使用があれば対処してから続行してください。
- 使用量に問題がない場合は、[割り当て] ページに移動し、[Queries/day] の横にある編集アイコンをクリックし、[割り当ての増加を申し込む] リンクをクリックします。
割り当てリクエスト フォームに記載されている情報を確認し、その手順に沿って増加リクエストを送信してください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-08-22 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2024-08-22 UTC。"],[],[]]