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% 減らします。この適応型アプローチにより、ユーザー向けのアクションのレイテンシを短縮しながら、最適なリクエスト レートを実現できます。