重要: Play EMM API の新しい登録受け付けは終了しました。
詳細
使用制限
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Google Play EMM API には、各 EMM で 1 分あたり 60,000 件のクエリのデフォルト上限があります。
割り当てを超過した場合、Google Play EMM API は HTTP 429 Too Many Requests を返します。
定められた使用上限を超えないようにし、ユーザーに最適なエクスペリエンスを提供できるよう、以下のセクションで説明するおすすめの方法を実装することを検討してください。
API の使用上限を下回るための推奨事項
Google Play EMM API を使用する際に、リクエストを分散して使用量上限を超えるリスクを軽減するために実装できるおすすめの方法がいくつかあります。
開始時間と間隔をランダムに設定する
デバイスの同期やチェックインなどのアクティビティを同時に行うと、リクエスト数が大幅に増加する可能性があります。これらのアクティビティを定期的にスケジュールされた間隔で実行する代わりに、これらの間隔をランダムにすることで、リクエスト負荷を分散できます。たとえば、各デバイスを 24 時間ごとに同期するのではなく、23 ～ 25 時間の間でランダムに選択された時間に各デバイスを同期できます。これにより、リクエスト数を分散できます。
同様に、多数の API 呼び出しが連続して行われるジョブを毎日実行する場合は、企業のすべての顧客に同時に大量のリクエストが行われないように、毎日ランダムな時間にジョブを開始することを検討してください。
指数バックオフを使用してリクエストを再試行する
多くの API 呼び出しで構成されるジョブを実行する場合は、割り当てに達したときに指数バックオフ戦略を使用します。指数バックオフは、指数関数的にリクエストを再試行するアルゴリズムです。単純な指数バックオフを実装するフローの例を次に示します。
- Google Play EMM API にリクエストを送信します。
HTTP 429 レスポンスを受け取ります。- 2 秒 +
random_time 秒待ってから、リクエストを再試行します。
HTTP 429 レスポンスを受け取ります。- 4 秒 +
random_time 秒待ってから、リクエストを再試行します。
HTTP 429 レスポンスを受信します。- 8 秒 +
random_time 秒待ってから、リクエストを再試行します。
random_time は通常、-0.5 * 待機時間～+0.5 * 待機時間 の範囲のランダムな数値です。リクエストを再試行するたびに新しい random_time を再定義します。ユーザー向けアクションの完了に必要な API 呼び出しは、より頻繁なスケジュール（0.5 秒、1 秒、2 秒など）で再試行できます。
バッチ処理のレート制限
バッチ処理で割り当てに達するたびに、API を呼び出すユーザー アクションのレイテンシが増加します。このような状況では、指数バックオフなどの戦略では、ユーザー操作の低レイテンシを維持するのに十分な効果が得られない可能性があります。
API の使用上限に繰り返し達し、ユーザー向けアクションのレイテンシを増やさないようにするには、バッチ処理プロセスにレート リミッタを使用することを検討してください（Google の RateLimiter をご覧ください）。レートリミッタを使用すると、API リクエストのレートを調整して、使用量の上限を常に下回るようにすることができます。
たとえば、デフォルトのレート制限の 50 QPS でバッチ処理を開始します。API がエラーを返さない限り、レート制限を徐々に増やします（1 分あたり 1%）。割り当てに達するたびに、リクエスト レートを 20% 減らします。この適応型アプローチにより、ユーザー向けのアクションのレイテンシを短縮しながら、最適なリクエスト レートを実現できます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-11-09 UTC。
[null,null,["最終更新日 2024-11-09 UTC。"],[[["\u003cp\u003eThe Google Play EMM API has a default limit of 60,000 queries per minute per EMM, exceeding which results in an HTTP 429 Too Many Requests error.\u003c/p\u003e\n"],["\u003cp\u003eTo avoid exceeding the usage limit, randomize device sync intervals and job start times to distribute the request load.\u003c/p\u003e\n"],["\u003cp\u003eImplement exponential backoff to retry requests with increasing wait times after receiving HTTP 429 errors.\u003c/p\u003e\n"],["\u003cp\u003eFor batch processes, utilize a rate limiter to adjust the request rate dynamically and prevent consistently hitting the usage limit, ensuring low latency for user actions.\u003c/p\u003e\n"]]],[],null,["# Usage Limits\n\nThe Google Play EMM API has a default limit of 60,000 queries per minute for each EMM.\n\nIf you exceed the quota, then the Google Play EMM API returns `HTTP 429 Too Many Requests`.\nTo help ensure that you don't exceed the stated usage limits and offer an optimal experience for\nyour users, consider implementing some of the best practices described in the section below.\n\nRecommendations for staying below the API usage limits\n------------------------------------------------------\n\nWhen using the Google Play EMM API, there are some best practices that you can implement to\ndistribute requests and reduce your risk of exceeding the usage limits.\n\n### Randomize start times and intervals\n\nActivities such as syncing or checking-in devices at the same time are likely to result in a\nsignificant increase in request volume. Instead of performing these activities at regularly\nscheduled intervals, you can distribute your request load by randomizing these intervals. For\nexample, rather than syncing each device every 24 hours, you can sync each device at a randomly\nchosen time period between 23 and 25 hours. This helps spread out the number of requests.\n\nSimilarly, if you run a daily job that makes many API calls in quick succession, consider\nstarting the job at a random time each day to prevent making a high volume of requests for all\nyour enterprise customers at the same time.\n\n### Use exponential backoff to retry requests\n\nIf you run jobs that consists of many API calls, use an exponential backoff strategy in\nresponse to reaching the quota. Exponential backoff is an algorithm that retries requests\nexponentially. An example flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the Google Play EMM API.\n2. Receive an `HTTP 429` response.\n3. Wait 2 seconds + `random_time`, then retry the request.\n4. Receive an `HTTP 429` response.\n5. Wait 4 seconds + `random_time`, then retry the request.\n6. Receive an `HTTP 429` response.\n7. Wait 8 seconds + `random_time`, then retry the request.\n\nThe `random_time` is typically a random number ranging from ***-0.5 \\* wait time***\nto ***+0.5 \\* wait time*** . Redefine a new `random_time` each time you retry your\nrequest. API calls that are required to complete user-facing actions can be retried on a more\nfrequent schedule (0.5s, 1s, and 2s, for example).\n\n### Rate-limit batch processes\n\nEach time a batched process reaches the quota, the latency of user actions that call the API\nincreases. In situations like these, strategies such as exponential backoff may not be effective\nenough in maintaining low latency for user actions.\n\nTo avoid reaching the API's usage limits repeatedly and increasing latency for user-facing\nactions, consider using a rate limiter for your batched processes (see [Google's RateLimiter](https://google.github.io/guava/releases/19.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html)).\nWith a rate limiter you can adjust the rate of your API requests so that you consistently remain\nbelow the usage limits.\n\nFor example, start a batched process with a default rate limit of 50 QPS. As long as the API\ndoesn't return an error, increase the rate limit slowly (1% every minute). Each time you reach\nthe quota, reduce your request rate by 20%. This adaptive approach results in a more optimal\nrequest rate while reducing latency for user-facing actions."]]
