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% 削減します。このアダプティブ アプローチにより、リクエスト レートが最適化されると同時に、ユーザー向けアクションのレイテンシが短縮されます。