사용량 한도

Google Chat API는 공유 서비스이므로 모든 사용자가 공정하게 사용하도록 하고 Google Workspace의 전반적인 성능을 보호하기 위해 할당량 및 제한사항을 적용합니다.

할당량을 초과하면 429: Too many requests HTTP 상태 코드 응답이 표시됩니다. Chat 백엔드에서 추가 비율 제한 검사를 실행해도 동일한 오류 응답이 발생할 수 있습니다. 이 오류가 발생하면 지수 백오프 알고리즘을 사용하고 나중에 다시 시도해야 합니다. 다음 표에 나열된 분당 할당량 내에서만 사용할 수 있는 일일 요청 수에는 제한이 없습니다.

Chat API 메서드에는 스페이스별 할당량과 프로젝트별 할당량이라는 두 가지 할당량 유형이 적용됩니다.

스페이스별 할당량

스페이스별 할당량은 지정된 스페이스의 쿼리 비율을 제한하며, 해당 스페이스에서 작동하며 각 할당량에 대해 나열된 Chat API 메서드를 호출하는 모든 Chat 앱 간에 공유됩니다.

다음 표에는 스페이스별 쿼리 한도가 자세히 나와 있습니다.

공간당 할당량

Chat API 메서드

제한 (60초당, 스페이스의 모든 Chat 앱 간에 공유
됨)

분당 읽기

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

분당 쓰기

media.upload

spaces.delete

spaces.patch

spaces.messages.create (수신 웹훅에도 적용됨)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

프로젝트별 할당량

프로젝트별 할당량은 Google Cloud 프로젝트의 쿼리 비율을 제한하므로 각 할당량에 대해 지정된 Chat API 메서드를 호출하는 단일 Chat 앱에 적용됩니다.

다음 표에는 프로젝트별 쿼리 한도가 자세히 나와 있습니다. 할당량 페이지에서도 이러한 한도를 확인할 수 있습니다.

프로젝트별 할당량

Chat API 메서드

한도 (60초당)

분당 메시지 쓰기

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

분당 메시지 읽기 수

spaces.messages.get

spaces.messages.list

3000

분당 멤버십 쓰기

spaces.members.create

spaces.members.delete

300

분당 멤버십 읽기

spaces.members.get

spaces.members.list

3000

분당 스페이스 쓰기

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

분당 스페이스 읽기

spaces.get

spaces.list

spaces.findDirectMessage

3000

분당 첨부파일 쓰기

media.upload

600

분당 첨부파일 읽기

spaces.messages.attachments.get

media.download

3000

분당 리액션 쓰기

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

분당 리액션 읽기

spaces.messages.reactions.list

3000

추가 사용량 한도

spaces.create 또는 spaces.setup 메서드를 사용하여 GROUP_CHAT 또는 SPACE 유형의 스페이스를 만들 때는 추가 할당량 제한이 있습니다. 이러한 유형의 스페이스는 분당 35개 미만, 시간당 800개 미만을 만드세요. DIRECT_MESSAGE 유형의 스페이스에는 이러한 추가 할당량 제한이 적용되지 않습니다.

동일한 스페이스를 타겟팅하는 API 트래픽이 많으면 할당량 페이지에 표시되지 않는 추가 내부 제한이 트리거될 수 있습니다.

시간 기반 할당량 오류 해결

모든 시간 기반 오류(X분당 최대 N개의 요청)의 경우 코드에서 예외를 포착하고 단기 지수 백오프를 사용하여 기기가 과도한 부하를 생성하지 않도록 하는 것이 좋습니다.

지수 백오프는 네트워크 애플리케이션의 표준 오류 처리 전략입니다. 지수 백오프 알고리즘은 요청 간 대기 시간을 기하급수적으로 늘려 최대 백오프 시간까지 요청을 재시도합니다. 요청이 여전히 실패하는 경우 요청이 성공할 때까지 시간 경과에 따라 요청 간 지연 시간이 증가해야 합니다.

예시 알고리즘

지수 백오프 알고리즘이 재시도 간 대기 시간을 최대 백오프 시간까지 늘려서 기하급수적으로 요청을 재시도합니다. 예를 들면 다음과 같습니다.

  1. Google Chat API에 요청을 전송합니다.
  2. 요청이 실패하면 1초 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
  3. 요청이 실패하면 2초 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
  4. 요청이 실패하면 4 + random_number_milliseconds를 대기한 후 요청을 재시도합니다.
  5. maximum_backoff 시간까지 이를 반복합니다.
  6. 최대 재시도 횟수까지 계속 대기하고 재시도하지만 재시도 간 대기 시간을 늘리지는 않습니다.

각 항목의 의미는 다음과 같습니다.

  • 대기 시간은 min(((2^n)+random_number_milliseconds), maximum_backoff)이고, n은 반복(요청)할 때마다 1씩 증가합니다.
  • random_number_milliseconds는 1,000밀리초 이하의 임의 숫자입니다. 이렇게 하면 여러 클라이언트가 어떤 상황에 의해 동기화되고 모두 한 번에 재시도되어 동기화된 웨이브로 요청을 보내는 경우를 방지할 수 있습니다. random_number_milliseconds 값은 각 재시도 요청 후 다시 계산됩니다.
  • maximum_backoff는 일반적으로 32 또는 64초입니다. 적절한 값은 사용 사례에 따라 다릅니다.

클라이언트는 maximum_backoff 시간에 도달한 후 재시도를 계속할 수 있습니다. 이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 예를 들어 클라이언트가 maximum_backoff 시간으로 64초를 사용하는 경우 이 값에 도달한 후 클라이언트는 64초마다 재시도할 수 있습니다. 특정 시점에서 클라이언트가 무한정 재시도하지 못하게 해야 합니다.

재시도 간 대기 시간과 재시도 횟수는 사용 사례와 네트워크 조건에 따라 다릅니다.

프로젝트당 할당량 상향 요청

프로젝트의 리소스 사용량에 따라 할당량 증가를 요청할 수 있습니다. 서비스 계정의 API 호출은 단일 계정을 사용하는 것으로 간주됩니다. 할당량 증가를 신청해도 승인된다고 보장할 수 없습니다. 할당량을 크게 늘리려는 경우에는 승인을 받는 데 시간이 더 소요될 수 있습니다.

모든 프로젝트의 할당량이 동일하지는 않습니다. Google Cloud 사용량이 점차 늘어나면 할당량도 늘려야 할 수 있습니다. 앞으로 사용량이 현저하게 늘어날 것으로 예상되는 경우 Google Cloud 콘솔의 할당량 페이지에서 사전에 할당량 조정을 요청할 수 있습니다.

자세한 내용은 다음 리소스를 참고하세요.