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