RTB 애플리케이션 권장사항

이 가이드에서는 RTB 프로토콜에 따라 애플리케이션을 개발할 때 고려해야 할 권장사항을 설명합니다.

연결 관리

연결 유지

새 연결을 설정하면 지연 시간이 증가하고 기존 연결을 재사용하는 것보다 양측에서 훨씬 더 많은 리소스를 사용합니다. 닫는 연결을 줄이면 다시 열어야 하는 연결 수를 줄일 수 있습니다.

첫째, 새로 연결할 때마다 추가 네트워크 왕복이 설정되어야 합니다. Google은 요청이 있을 때 연결을 설정하므로 연결의 첫 번째 요청은 유효 기한이 더 짧고 후속 요청보다 타임아웃될 가능성이 높습니다. 시간 제한을 추가하면 오류율이 높아져 입찰자가 제한될 수 있습니다.

둘째, 다수의 웹 서버는 설정된 연결마다 전용 작업자 스레드를 생성합니다. 즉, 연결을 닫고 재생성하려면 서버는 최종적으로 요청을 처리하기 전에 스레드를 종료했다가 삭제하고, 새 스레드를 할당하고, 실행 가능하게 만든 다음 연결 상태를 빌드해야 합니다. 이는 많은 불필요한 오버 헤드입니다.

연결 종료 방지

먼저 연결 동작을 조정하세요. 대부분의 서버 기본값은 각각 적은 수의 요청을 실행하는 많은 수의 클라이언트가 있는 환경에 맞게 조정됩니다. RTB의 경우 상대적으로 적은 수의 머신 풀이 다수의 브라우저를 대신하여 요청을 전송합니다. 이러한 조건에서는 연결을 가능한 한 많이 재사용하는 것이 좋습니다. 다음과 같이 설정하는 것이 좋습니다.

  • 유휴 상태 제한 시간을 2.5분으로 설정합니다.
  • 연결의 최대 요청 수이며 가능한 최대 값입니다.
  • RAM에서 수용할 수 있는 가장 높은 값의 최대 연결 수를 지정하는 동시에 연결 수가 이 값에 너무 근접하지 않게 해야 합니다.

예를 들어 Apache에서는 KeepAliveTimeout를 150으로, MaxKeepAliveRequests를 0으로, MaxClients를 서버 유형에 따른 값으로 설정해야 합니다.

연결 동작이 조정되면 입찰자 코드가 연결을 불필요하게 닫지 않도록 해야 합니다. 예를 들어 백엔드 오류나 시간 초과 시 기본 '입찰 없음' 응답을 반환하는 프런트엔드 코드가 있는 경우 코드가 연결을 닫지 않고 응답을 반환하는지 확인합니다. 이렇게 하면 입찰자가 과부하되어 연결이 종료되기 시작하고, 시간 초과 횟수가 증가하여 입찰자가 제한되는 상황을 피할 수 있습니다.

연결 균형 유지

Authorized Buyers가 프록시 서버를 통해 입찰자의 서버에 연결하는 경우, 시간이 지남에 따라 연결의 불균형이 발생할 수 있습니다. 프록시 서버의 IP 주소만 알면 Authorized Buyers에서 각 콜아웃을 수신하는 입찰자 서버를 파악할 수 없기 때문입니다. 시간이 지남에 따라 Authorized Buyers에서 연결을 설정하고 닫고 입찰자의 서버가 다시 시작되면 각 연결에 매핑되는 연결의 수가 크게 달라질 수 있습니다.

일부 연결이 많이 사용되는 경우 열려 있는 다른 연결은 현재 필요하지 않으므로 대부분 유휴 상태로 유지될 수 있습니다. Authorized Buyers의 트래픽이 변경되면 유휴 연결이 활성화되고 활성 연결은 유휴 상태가 될 수 있습니다. 이로 인해 연결이 제대로 클러스터링되지 않으면 입찰자 서버에 고르지 않은 로드가 발생할 수 있습니다. Google은 요청이 10,000회 발생한 후에는 모든 연결을 종료하여 시간이 지남에 따라 사용률이 높은 연결을 자동으로 재분산하여 이를 방지하려고 합니다. 환경에서 여전히 트래픽의 불균형이 확인되면 다음과 같은 추가 조치를 취할 수 있습니다.

  1. 프런트엔드 프록시를 사용하는 경우 연결당 한 번이 아니라 요청별로 백엔드를 선택하세요.
  2. 하드웨어 부하 분산기 또는 방화벽을 통해 연결을 프록시하고 연결이 설정된 후 매핑이 고정되는 경우 연결당 최대 요청 수를 지정합니다. Google에서는 이미 연결당 요청 상한값을 10,000개로 지정하므로 사용자 환경에서 핫 연결이 계속 클러스터링되는 것을 발견할 경우에만 더 엄격한 값을 제공해야 합니다. 예를 들어 Apache에서는 MaxKeepAliveRequests을 5,000으로 설정합니다.
  3. 입찰자가 경쟁업체보다 너무 많은 요청을 지속적으로 처리하는 경우 요청률을 모니터링하고 자체 연결을 닫도록 입찰자의 서버를 구성합니다.

적절한 과부하 처리

입찰자가 처리할 수 있는 모든 요청을 수신할 수 있도록 할당량을 높게 설정하는 것이 좋으며 그 이상은 허용되지 않습니다. 실제로 할당량을 최적의 수준으로 유지하는 것은 어려운 작업이며, 사용량이 많은 시간에 백엔드가 다운되거나, 각 요청에 더 많은 처리가 필요하도록 트래픽 믹스가 변경되거나, 할당량 값을 너무 높게 설정하는 등 다양한 이유로 과부하가 발생합니다. 따라서 너무 많은 트래픽이 유입될 때 입찰자가 어떻게 동작할지 고려해야 합니다.

리전 간 (특히 아시아 및 미국 서부와 미국 동부 및 미국 서부 간)의 일시적인 트래픽 이동 (최대 일주일)을 수용하려면 7일 피크 기간과 거래 위치당 QPS 사이에 15% 의 완충 효과를 적용하는 것이 좋습니다.

과부하 시의 동작과 관련하여 입찰자는 크게 세 가지 카테고리로 분류됩니다.

'전체 응답' 입찰자

이 입찰자는 구현하기에 간단하지만 과부하 시 최악의 성능을 발휘합니다. 들어오는 모든 입찰 요청에 관계없이 즉시 처리할 수 없는 요청을 큐에 추가하려고 합니다. 발생하는 시나리오는 다음과 같은 경우가 많습니다.

  • 요청 비율이 증가하면 모든 요청이 타임아웃되기 시작할 때까지 요청 지연 시간도 증가합니다.
  • 콜아웃 비율이 피크에 접근하면서 지연 시간이 급격히 증가함
  • 제한이 시작되어 허용되는 콜아웃 수가 급격히 줄어듭니다.
  • 지연 시간이 회복되기 시작하여 제한 수준이 감소합니다.
  • 생리 주기가 다시 시작됩니다.

이 입찰자의 지연 시간 그래프는 매우 가파른 톱니 패턴과 유사합니다. 또는 큐에 추가된 요청으로 인해 서버에서 메모리 페이징을 시작하거나 장기 속도 저하를 야기하는 다른 작업을 하며, 지연 시간은 피크 시간이 지날 때까지 전혀 복구되지 않아 전체 피크 기간 동안 콜아웃 비율이 떨어질 수 있습니다. 어느 경우든 할당량이 단순히 더 낮은 값으로 설정되었을 때보다 실행되거나 응답하는 콜아웃이 적습니다.

'과부하 시 오류' 입찰자

이 입찰자는 일정 비율까지 콜아웃을 수락한 후 일부 콜아웃에 대해 오류를 반환하기 시작합니다. 이는 내부 시간 초과, 연결 큐 사용 중지 (Apache의 ListenBackLog에서 제어), 사용률 또는 지연 시간이 너무 길어질 때 확률적 중단 모드 구현 또는 기타 메커니즘을 통해 실행될 수 있습니다. Google에서 15%를 초과하는 오류율을 발견하면 제한을 시작하기 시작합니다. '전체 응답' 입찰자와 달리 이 입찰자는 '손실을 줄이므로' 요청 비율이 감소하는 즉시 회복할 수 있습니다.

이 입찰자의 지연 시간 그래프는 과부하 도중의 얕은 톱니 패턴과 유사하며 최대 허용 속도에 맞춰 현지화됩니다.

'과부하 시 입찰 없음' 입찰자

이 입찰자는 특정 요율까지 콜아웃을 수락한 다음 모든 과부하에 대해 '입찰 없음' 응답을 반환하기 시작합니다. 이는 '과부하 시 오류' 입찰자와 마찬가지로 여러 가지 방법으로 구현할 수 있습니다. 차이점은 Google에 반환되는 신호가 없으므로 콜아웃을 조절하지 않는다는 점입니다. 과부하는 프런트엔드 머신에 흡수되어, 처리할 수 있는 트래픽만 백엔드로 계속 전달될 수 있습니다.

이 입찰자의 지연 시간 그래프는 피크 시간에 요청 비율에 대한 병렬화가 인위적으로 중단되는 정체기와 입찰이 포함된 응답 수의 이에 상응하는 하락을 보여줍니다.

다음과 같은 방법으로 '과부하 시 오류'와 '과부하 시 입찰 없음' 접근 방식을 조합하는 것이 좋습니다.

  • 프런트엔드를 오버프로비저닝하고 과부하 시 오류로 설정하여 특정 형태로 응답할 수 있는 연결 수를 최대화합니다.
  • 과부하 시 오류가 발생할 때 프런트엔드 컴퓨터는 미리 준비된 '입찰 없음' 응답을 사용할 수 있으며 요청을 전혀 파싱할 필요가 없습니다.
  • 충분한 용량이 없는 경우 '입찰 없음' 응답을 반환하도록 백엔드 상태 확인을 구현합니다.

이렇게 하면 일부 과부하가 흡수되고 백엔드가 처리할 수 있는 만큼 정확히 많은 요청에 응답할 수 있습니다. 요청 수가 예상보다 훨씬 높은 경우 프런트엔드 머신이 '과부하 시 오류'로 되돌아가는 '과부하 시 입찰 없음'으로 생각할 수 있습니다.

'전체에 응답' 입찰자가 있는 경우, 연결 동작을 조정하여 과부하를 방지하는 '과부하 시 오류' 입찰자로 변환하는 것이 좋습니다. 이렇게 하면 더 많은 오류가 반환되지만 시간 초과가 줄고 서버가 요청에 응답할 수 없는 상태가 되지 않습니다.

핑에 응답

입찰자가 핑 요청에 응답할 수는 있지만 연결 관리 자체는 할 수는 없도록 하는 것이 디버깅에 매우 중요합니다. Google에서는 입찰자 상태, 연결 종료 동작, 지연 시간 등의 상태 확인 및 디버깅에 핑 요청을 사용합니다. 핑 요청은 다음 형식을 취합니다.

Google

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

예상과 달리 핑 요청에는 광고 슬롯이 포함되지 않습니다. 위에 자세히 설명된 대로 핑 요청에 응답한 후에는 연결을 종료해서는 안 됩니다.

피어링 고려

네트워크 지연 시간이나 변동성을 줄이는 또 다른 방법은 Google과 피어링하는 것입니다. 피어링은 트래픽이 입찰자에 도달하기까지 이동하는 경로를 최적화하는 데 도움이 됩니다. 연결 엔드포인트는 동일하게 유지되지만 중간 링크는 변경됩니다. 자세한 내용은 피어링 가이드를 참조하세요. 피어링을 권장사항으로 생각하는 이유는 다음과 같이 요약할 수 있습니다.

  • 인터넷에서 전송 링크는 주로 Google 네트워크 외부에서 패킷을 목적지로 가져올 수 있는 가장 가까운 링크를 찾아 해당 링크를 통해 패킷을 라우팅하는 '핫 포테이토 라우팅'을 통해 선택됩니다. 트래픽이 Google과 많은 피어링 연결을 보유한 제공업체가 소유한 백본의 한 섹션을 통과할 때 선택한 링크는 패킷이 시작되는 위치와 가까워질 가능성이 높습니다. 이 지점을 초과하면 Google에서 패킷이 입찰자까지 이동하는 경로를 제어할 수 없으므로 그 과정에서 패킷이 다른 자율 시스템(네트워크)으로 반송될 수 있습니다.

  • 반대로 다이렉트 피어링 계약이 체결되면 패킷은 항상 피어링 링크를 따라 전송됩니다. 패킷이 어디에서 시작되든 상관없이 패킷은 Google이 소유하거나 임대하는 링크를 통과하여 입찰자 위치와 가까워야 하는 공유 피어링 지점에 도달합니다. 역방향 이동은 Google 네트워크로 짧은 홉으로 시작해서 Google 네트워크에 그대로 유지됩니다. 대부분의 이동을 Google이 관리하는 인프라에 유지하면 패킷이 지연 시간이 짧은 경로를 사용하고 잠재적인 변동성을 크게 피할 수 있습니다.

정적 DNS 제출

구매자는 항상 단일 정적 DNS 결과를 Google에 제출하고 Google을 통해 트래픽 전송을 처리하는 것이 좋습니다.

다음은 부하 분산 또는 가용성을 관리하려고 할 때 입찰자의 DNS 서버에서 일반적으로 발생하는 두 가지 방법입니다.

  1. DNS 서버는 쿼리에 대한 응답으로 하나의 주소 또는 주소 하위 집합을 전달한 후 특정 방식으로 이 응답을 순환합니다.
  2. DNS 서버는 항상 동일한 주소 집합으로 응답하지만 응답에서 주소 순서를 순환합니다.

첫 번째 기법은 스택의 여러 수준에서 캐싱이 많이 발생하므로 부하 분산에 적합하지 않으며, Google에서 DNS 확인 시간을 입찰자에게 청구하므로 캐싱을 우회하려는 시도도 원하는 결과를 얻지 못할 수 있습니다.

두 번째 기법은 Google이 DNS 응답 목록에서 IP 주소를 무작위로 선택하여 응답의 순서가 중요하지 않게 하므로 부하 분산을 전혀 달성하지 않습니다.

입찰자가 DNS를 변경하면 Google은 DNS 레코드에 설정된 TTL(수명)을 따르지만 새로고침 간격은 불확실한 상태로 유지됩니다.