사용 제한
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Google Play EMM API의 기본 쿼리 한도는 EMM별로 분당 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 요청 비율을 조정할 수 있습니다.
예를 들어 기본 비율 제한이 50QPS인 일괄 프로세스를 시작합니다. API가 오류를 반환하지 않는 한 비율 제한을 천천히 늘립니다 (분당 1%). 할당량에 도달할 때마다 요청 비율을 20%씩 줄입니다. 이러한 적응형 접근 방식을 사용하면 더 최적화된 요청률을 얻고 사용자 대상 작업의 지연 시간을 줄일 수 있습니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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."]]
