비율 한도
Google Ads API는 클라이언트 고객 ID (CID) 및 개발자 토큰별 초당 쿼리 수 (QPS)에 따라 비율 제한을 위해 요청을 버킷화합니다. 즉, CID와 개발자 토큰 모두에 대해 독립적으로 계량이 적용됩니다. Google Ads API는 토큰 버킷 알고리즘을 사용하여 요청을 측정하고 적절한 QPS 한도를 결정하므로 정확한 한도는 특정 시점의 전체 서버 부하에 따라 달라집니다.
요청률 제한을 적용하는 목적은 한 사용자가 의도적으로 또는 의도치 않게 많은 요청으로 Google Ads API 서버를 압도하여 다른 사용자의 서비스를 방해하지 못하도록 하는 것입니다.
요청이 비율 제한을 위반하는 경우 RESOURCE_TEMPORARILY_EXHAUSTED 오류와 함께 거부됩니다.
요청 수를 적극적으로 줄이고 클라이언트 측에서 QPS를 제한하여 앱을 제어하고 비율 제한을 완화할 수 있습니다.
비율 제한을 초과할 가능성을 줄이는 방법은 여러 가지가 있습니다. 메시지, 재전송, 제한과 같은 엔터프라이즈 통합 패턴 (EIP) 개념을 잘 알고 있으면 더 강력한 클라이언트 앱을 빌드하는 데 도움이 됩니다.
다음은 복잡도 순으로 정렬된 권장사항입니다. 간단한 전략이 상단에 있고 더 강력하지만 정교한 아키텍처가 그 뒤에 있습니다.
동시 실행 태스크 제한
비율 제한을 초과하는 한 가지 근본 원인은 클라이언트 앱이 과도한 수의 병렬 작업을 생성하기 때문입니다. 클라이언트 앱이 가질 수 있는 동시 요청 수는 제한되지 않지만 개발자 토큰 수준에서 초당 요청 수 제한을 쉽게 초과할 수 있습니다.
요청을 수행할 동시 작업의 총수 (모든 프로세스 및 머신에 걸쳐)에 적절한 상한을 설정하고 비율 제한을 초과하지 않고 처리량을 최적화하도록 상향 조정하는 것이 좋습니다.
또한 클라이언트 측에서 QPS를 제한하는 것도 고려할 수 있습니다 (제한 및 비율 제한기 참고).
요청 일괄 처리
여러 작업을 단일 요청으로 일괄 처리하는 것이 좋습니다. 이는 MutateFoo 호출에 가장 적합합니다. 예를 들어 AdGroupAd의 여러 인스턴스에 대한 상태를 업데이트하는 경우 AdGroupAd마다 MutateAdGroupAds를 한 번 호출하는 대신 MutateAdGroupAds를 한 번 호출하고 여러 operations를 전달할 수 있습니다. 추가 예는 일괄 작업 가이드를 참고하세요.
요청을 일괄 처리하면 총 요청 수가 줄어들고 분당 요청 수 제한이 완화되지만, 단일 계정에 대해 많은 작업을 실행하면 분당 작업 수 제한이 트리거될 수 있습니다.
제한 및 비율 제한기
클라이언트 애플리케이션의 총 스레드 수를 제한하는 것 외에도 클라이언트 측에서 비율 제한기를 구현할 수 있습니다. 이렇게 하면 프로세스 및 / 또는 클러스터 전반의 모든 스레드가 클라이언트 측의 특정 QPS 제한에 따라 관리됩니다.
Guava Rate Limiter를 확인하거나 클러스터링된 환경을 위해 자체 토큰 버킷 기반 알고리즘을 구현할 수 있습니다. 예를 들어 토큰을 생성하여 데이터베이스와 같은 공유 트랜잭션 스토리지에 저장할 수 있으며 각 클라이언트는 요청을 처리하기 전에 토큰을 획득하고 사용해야 합니다. 토큰이 모두 사용된 경우 클라이언트는 다음 토큰 배치가 생성될 때까지 기다려야 합니다.
현재 재생목록
메시지 대기열은 작업 부하 분산 솔루션인 동시에 요청 및 소비자 비율을 제어합니다. 다양한 메시지 대기열 옵션이 있습니다. 일부는 오픈소스이고 일부는 독점적이며, 대부분은 다양한 언어로 작동할 수 있습니다.
메시지 대기열을 사용하면 여러 프로듀서가 대기열에 메시지를 푸시하고 여러 소비자가 이러한 메시지를 처리할 수 있습니다. 제한은 동시 소비자 수를 제한하여 소비자 측에서 구현하거나 생산자 또는 소비자를 위한 속도 제한기 또는 제한기를 구현할 수 있습니다.
예를 들어 메시지 소비자가 비율 제한 오류를 발견하면 소비자는 재시도할 수 있도록 요청을 대기열로 반환할 수 있습니다. 동시에 해당 소비자는 오류에서 복구하기 위해 다른 모든 소비자에게 몇 초 동안 처리를 일시중지하도록 알릴 수도 있습니다.