사용량 한도
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Google Slides API는 공유 서비스이므로 할당량 및 한도가 적용됩니다.
모든 사용자가 공정하게 사용하도록 하고
Google Workspace 시스템의
상태를 관리할 수 있습니다
할당량을 초과하면 일반적으로
429: Too many requests
HTTP 상태 코드 응답입니다. 이 경우
지수 백오프 알고리즘을 비교할 수 있습니다.
확인할 수 있습니다 아래의 분당 할당량 내에 머무를 경우
하루에 요청할 수 있는 횟수를 제한합니다.
다음 표에서는 요청 한도를 자세히 설명합니다.
| 할당량 |
| 읽기 요청 |
| 프로젝트별 분당 할당량 |
3000 |
| 프로젝트별 사용자당 분당 할당량 |
600 |
|
|
많은 비용이 드는 읽기 요청
(presentations.pages.getThumbnail 요청에 사용됩니다.)
|
| 프로젝트별 분당 할당량 |
300 |
| 프로젝트별 사용자당 분당 할당량 |
60 |
|
| 쓰기 요청 |
| 프로젝트별 분당 할당량 |
600 |
| 프로젝트별 사용자당 분당 할당량 |
60 |
|
시간 기반 할당량 오류 해결
모든 시간 기반 오류 (X분당 최대 N개의 요청)의 경우
코드가 예외를 포착하고 잘린 지수 백오프를 사용하여
기기에서 과도한 부하를 생성하지 않습니다.
지수 백오프는 네트워크 애플리케이션의 표준 오류 처리 전략입니다.
지수 백오프 알고리즘으로 기하급수적으로 증가하는 대기 시간을 사용하여 요청 재시도
최대 백오프 시간까지 줄일 수 있습니다. 그래도 요청이 실패하면
요청이 성공할 때까지 요청 간 지연이 시간이 지남에 따라 증가한다는 것이 중요합니다.
예시 알고리즘
지수 백오프 알고리즘으로 기하급수적으로 요청을 재시도하여 대기 시간 증가
최대 백오프 시간까지 재시도할 수 있습니다. 예를 들면 다음과 같습니다.
- Google Slides API에 요청합니다.
- 요청이 실패하면 1 +
random_number_milliseconds를 대기한 후 재시도합니다.
요청을 처리합니다
- 요청이 실패하면 2+
random_number_milliseconds를 대기한 후 재시도합니다.
요청을 처리합니다
- 요청이 실패하면 4 +
random_number_milliseconds를 대기한 후 재시도합니다.
요청을 처리합니다
maximum_backoff 시간까지 이를 반복합니다.- 최대 재시도 횟수까지 계속 대기하고 재시도하되 대기 시간을 늘리지 않습니다.
최대 24시간이 필요합니다.
각 항목의 의미는 다음과 같습니다.
- 대기 시간은
min(((2^n)+random_number_milliseconds), maximum_backoff)입니다.
반복 (요청)할 때마다 n가 1씩 증가합니다.
random_number_milliseconds는 다음보다 작은 밀리초 단위의 임의 숫자입니다.
1,000과 같습니다. 이렇게 하면 많은 클라이언트가 서로 다른 클라이언트 간에
한 번에 재시도하고 요청을 동기화된 상태로
있습니다. random_number_milliseconds의 값은 다음 값이 될 때마다 다시 계산됩니다.
재시도 요청maximum_backoff는 일반적으로 32 또는 64초입니다. 적절한 값
사용 사례에 따라 다릅니다
클라이언트는 maximum_backoff 시간에 도달한 후 재시도를 계속할 수 있습니다.
이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 대상
예를 들어 클라이언트가 64초의 maximum_backoff 시간을 사용하는 경우
클라이언트는 64초마다 재시도할 수 있습니다. 언젠가는,
무제한 재시도를 방지해야 합니다
재시도 간 대기 시간과 재시도 횟수는 사용 사례에 따라 다릅니다.
네트워크 상태를 모니터링할 수 있습니다
가격 책정
Google Slides API는 모두 추가 비용 없이 사용할 수 있습니다. 할당량 초과
요청 한도는 추가 요금이 발생하지 않으며 계정에 요금이 청구되지 않습니다.
할당량 상향 조정 요청
프로젝트의 리소스 사용량에 따라 할당량을 요청할 수 있음
증가할 수도 있습니다 서비스 계정에 의한 API 호출은
단일 계정으로 액세스할 수 있습니다. 할당량 상향을 신청해도 승인이 보장되는 것은 아닙니다. L 사이즈
할당량 상향 조정 승인에 시간이 더 걸릴 수 있습니다.
모든 프로젝트의 할당량이 동일하지는 않습니다. Google Cloud를 점점 더 많이 사용함에 따라
할당량을 늘려야 할 수도 있습니다 앞으로 주목할 만한
사용량이 늘어나더라도
할당량 조정을 요청하고
할당량 페이지에서
Google Cloud 콘솔에서 확인할 수 있습니다
자세한 내용은 다음 리소스를 참고하세요.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-03-21(UTC)
[null,null,["최종 업데이트: 2025-03-21(UTC)"],[],[],null,["# Usage limits\n\nAs the Google Slides API is a shared service, we apply quotas and limitations\nto make sure it's used fairly by all users and to protect the overall\nhealth of the Google Workspace system.\n\n\nIf you exceed a quota, you'll generally receive a\n`429: Too many requests`\nHTTP status code response. If this happens, you should use an\n[exponential backoff algorithm](#exponential) and try again\nlater. Provided you stay within the per-minute quotas below, there's no\nlimit to the number of requests you can make per day.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|------| | Per minute per project | 3000 | | Per minute per user per project | 600 | |\n| Expensive read requests (Used for `presentations.pages.getThumbnail` requests.) | |---------------------------------|-----| | Per minute per project | 300 | | Per minute per user per project | 60 | |\n| Write requests | |---------------------------------|-----| | Per minute per project | 600 | | Per minute per user per project | 60 | |\n\nResolve time-based quota errors\n-------------------------------\n\n\nFor all time-based errors (maximum of N requests per X minutes), we recommend\nyour code catches the exception and uses a *truncated exponential backoff* to make sure your\ndevices don't generate excessive load.\n\n\nExponential backoff is a standard error handling strategy for network applications. An\nexponential backoff algorithm retries requests using exponentially increasing wait times\nbetween requests, up to a maximum backoff time. If requests are still unsuccessful, it's\nimportant that the delays between requests increase over time until the request is successful.\n\n### Example algorithm\n\n\nAn exponential backoff algorithm retries requests exponentially, increasing the wait time\nbetween retries up to a maximum backoff time. For example:\n\n1. Make a request to Google Slides API.\n2. If the request fails, wait 1 + `random_number_milliseconds` and retry the request.\n3. If the request fails, wait 2 + `random_number_milliseconds` and retry the request.\n4. If the request fails, wait 4 + `random_number_milliseconds` and retry the request.\n5. And so on, up to a `maximum_backoff` time.\n6. Continue waiting and retrying up to some maximum number of retries, but don't increase the wait period between retries.\n\n\nwhere:\n\n- The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n` incremented by 1 for each iteration (request).\n- `random_number_milliseconds` is a random number of milliseconds less than or equal to 1,000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of `random_number_milliseconds` is recalculated after each retry request.\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value depends on the use case.\n\n\nThe client can continue retrying after it has reached the `maximum_backoff` time.\nRetries after this point don't need to continue increasing backoff time. For\nexample, if a client uses a `maximum_backoff` time of 64 seconds, then after reaching\nthis value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying indefinitely.\n\n\nThe wait time between retries and the number of retries depend on your use case\nand network conditions.\n\nPricing\n-------\n\n\nAll use of the Google Slides API is available at no additional cost. Exceeding the quota\nrequest limits doesn't incur extra charges and your account is not billed.\n\nRequest a quota increase\n------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)"]]
