API 요청 전반에서 사용자 인증 정보를 공유하면 성능이 향상되고 비율 제한 오류가 발생할 수 있는 과도한 오버헤드가 방지됩니다. 이 가이드에서는 앱이 Google Ads API와 효율적으로 상호작용할 수 있도록 OAuth2 사용자 인증 정보 관리를 최적화하는 방법을 설명합니다.
사용자 인증 정보 공유 전략은 앱이 멀티스레드인지 멀티 프로세스 (또는 배포)인지에 따라 다릅니다. 각 프로세스 내에서 멀티 프로세스이자 멀티스레드인 앱은 두 전략을 모두 사용해야 합니다. 이러한 전략은 여러 Google Ads 계정에 적용할 수도 있습니다.
멀티스레드
스레드에 의해 그려진 각 세션 또는 사용자는 동일한 사용자 인증 정보 객체를 사용해야 합니다. 액세스 토큰 갱신도 경합 상태를 방지하기 위해 동기식으로 수행되어야 합니다.
클라이언트 라이브러리는 사용자 인증 정보가 액세스 토큰이 만료되면 동기식으로 새로고침되는 스레드 안전 객체인지 확인합니다. 각 클라이언트 라이브러리에는 전체 기간 동안 재사용하는 사용자 인증 정보가 있는 세션 (또는 사용자) 객체가 있습니다. 스레드 간에 사용자 인증 정보를 공유하려면 동일한 사용자 인증 정보를 사용하여 각 세션을 구성하기만 하면 됩니다. 예를 들어 자바 클라이언트 라이브러리에서 Credential 싱글톤을 만들어 모든 세션에서 공유합니다.
멀티 프로세스 또는 분산
멀티 프로세스 또는 분산 프로세스의 경우 사용자 인증 정보를 공유하기 전에 유지해야 합니다. 여러 프로세스 또는 서버가 동시에 사용자 인증 정보를 새로고침하려고 하여 새로고침 요청이 과도하게 발생하지 않도록 하려면 새로고침을 단일 프로세스에 할당해야 합니다.
예를 들어 별도의 작업 또는 서비스가 사용자 인증 정보를 주기적으로 새로고침하고 이를 서버 풀에서 공유하는 데이터 저장소에 사전에 푸시하는 역할을 할 수 있습니다. 그러면 각 서버는 API 요청을 할 때 데이터 저장소에서 사용자 인증 정보를 검색할 수 있습니다.
작업 새로고침
새로고침 작업은 현재 사용자 인증 정보가 만료될 때까지 기다렸다가 새로고침을 시작해서는 안 됩니다. 이렇게 하면 유효한 사용자 인증 정보가 부족하여 앱이 중단될 수 있습니다. 하지만 API 요청이 처리되는 동안 사용자 인증 정보의 액세스 토큰이 만료되면 요청은 계속 완료되고 결과가 반환됩니다.
액세스 토큰이 마지막으로 새로고침된 시간을 추적하고 만료까지 5분 미만이 남은 경우 강제로 새로고침하는 것이 좋습니다.
액세스 토큰이 마지막으로 갱신된 시점을 알 수 없는 경우 액세스 토큰이 이미 만료되었다는 가정 하에 새로고침을 시도할 수 있습니다. 액세스 토큰이 랩에 가깝지 않은 경우 서버는 토큰이 만료될 때까지 남은 밀리초와 함께 동일한 액세스 토큰을 반환합니다.
데이터 저장소
기존 데이터 스토어를 활용하거나 서버 간 사용자 인증 정보 공유를 위한 데이터 스토어를 배포할 수 있습니다. 솔루션에는 Memcached 또는 Infinispan과 같은 캐싱 서버 또는 MongoDB와 같은 NoSQL 데이터 스토어가 포함됩니다.
쓰기보다 읽기 요청이 더 많기 때문에 데이터 저장소는 빠른 읽기 작업에 최적화되어야 합니다. 또한 사용자 인증 정보는 안전하게 저장되어야 합니다.
사용자 인증 정보를 저장할 때 계산된 expiry_time(현재 + expires_in) 및 refresh_token를 access_token와 함께 저장해야 합니다. expiry_time는 access_token 새로고침 요청 시간에 expires_in 시간을 더한 값으로 계산됩니다.
서버 풀
풀의 각 서버 또는 프로세스는 요청하기 전에 데이터 저장소에서 최신 사용자 인증 정보를 검색합니다. 새로고침 작업이 올바르게 실행되는 한 사용자 인증 정보가 유효합니다. 그러나 새로고침 작업 또는 데이터 저장소가 실패하면 대체 메커니즘이 있어야 합니다.
서버나 프로세스가 데이터 저장소에서 사용자 인증 정보를 가져올 수 없거나 사용자 인증 정보가 만료된 경우 서버에서 자체 사용자 인증 정보를 새로고침하여 문제가 해결될 때까지 앱이 API를 계속 사용할 수 있도록 해야 합니다.
여러 계정의 사용자 인증 정보 관리
Google Ads 관리자 계정용으로 생성된 사용자 인증 정보를 사용하여 모든 하위 계정에 액세스할 수 있습니다. 따라서 하나의 관리자 계정 계층 구조를 사용하는 사용자의 경우, 일반적으로 최상위 관리자 계정의 사용자 인증 정보를 생성하는 것만으로도 그 아래에 있는 모든 Google Ads 계정에서 사용할 수 있습니다.
앱이 관리자 계정 계층 구조에서 서로 관련이 없는 Google Ads 계정에 액세스해야 하는 경우, 액세스하는 각 Google Ads 고객 계정 또는 액세스하는 독립적인 계층 구조의 각 최상위 관리자 계정과 같이 계정마다 다른 사용자 인증 정보를 생성하고 유지해야 합니다.
사소한 수정사항만으로 멀티스레드 또는 멀티프로세스 / 배포 앱에 동일한 전략을 따를 수 있습니다. 공유 데이터 저장소를 사용하는 경우 사용자 인증 정보가 올바른 계정과 연결될 수 있도록 계정 식별자 customerId로 사용자 인증 정보의 색인을 생성해야 합니다.
또한 새로고침 작업을 통해 모든 사용자 인증 정보가 새로고침되어야 합니다. 새 계정이 연결되면 새로고침 작업을 트리거해야 할 수 있습니다.
마지막으로 멀티스레드 앱에서는 사용자 인증 정보 객체가 연결된 계정에서 작동하는 스레드 간에만 사용자 인증 정보 객체를 공유해야 합니다.