권장사항

이 페이지에는 RTB 프로토콜에 따라 애플리케이션을 개발할 때 고려해야 할 권장사항이 나와 있습니다.

연결 관리하기

    1. 연결 유지
    2. 효과적인 과부하 처리
    3. 핑 응답
    4. 피어링 고려

연결 유지

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

먼저, 새로 연결을 할 때마다 왕복 네트워크를 추가로 구축해야 합니다. Google은 요청이 있을 때마다 연결을 구축하므로 첫 번째 연결 요청은 실제 제한시간이 더 짧고 후속 요청보다 제한시간을 초과할 가능성이 더 큽니다. 시간 초과가 발생하면 오류율이 올라가고, 이는 다시 입찰자 조절로 이어질 수 있습니다.

두 번째로 많은 웹 서버는 구축되는 연결별로 전담 작업자 스레드를 생성합니다. 즉, 연결을 닫고 재생성하려면 서버가 스레드를 닫고 폐기한 다음, 새 스레드를 할당하고, 실행 가능한 상태로 만든 다음, 연결 상태를 유지합니다. 그런 다음 마지막으로 요청을 처리합니다. 이 과정은 많은 자원을 낭비하는 불필요한 오버헤드라고 할 수 있습니다.

연결 닫기를 방지하는 방법

먼저 연결의 작동 방식을 조절해 보세요. 기본적으로 대부분의 서버는 다수의 클라이언트가 있고, 각 클라이언트가 소수의 요청을 하는 환경에 맞춰져 있습니다. 하지만 RTB에서는 상대적으로 소수의 컴퓨터가 다수의 브라우저를 대신하여 요청을 전송합니다. 이러한 조건에서는 연결을 최대한 많이 재사용하는 것이 좋으므로 다음과 같이 설정할 것을 권장합니다.

  • 유휴 시간제한을 2분으로 설정
  • 연결에 대한 최대 요청수를 설정할 수 있는 최고값으로 설정
  • 최대 연결수를 RAM에서 수용할 수 있는 최대값으로 설정하고, 연결수가 이 최대값에 너무 근접하지 않도록 관리

예를 들어 Apache에서는 KeepAliveTimeout을 120으로, MaxKeepAliveRequests를 0으로, MaxClients을 서버 유형에 맞는 값으로 설정하면 됩니다.

또한 연결 작동 방식이 조절되면 입찰자 코드가 연결을 불필요하게 닫지 않도록 설정해야 합니다. 예를 들어 백엔드 오류 또는 시간 초과 시 기본값인 '입찰 없음' 응답을 반환하는 프론트엔드 코드가 있으면 코드가 해당 연결을 닫지 않고 응답을 반환하게 하세요. 이러한 방식으로 입찰자에게 과부하가 걸려서 연결이 닫히기 시작하고, 시간 초과 횟수가 증가하여 입찰자가 조절되는 상황을 피할 수 있습니다.

맨 위로

효과적인 과부하 처리

이상적으로는 입찰자가 처리할 수 있는 모든 요청을 수신할 수 있는 수준으로 할당량이 설정되지만, 실제로는 할당량을 최적의 수준으로 유지하는 것이 힘든 작업이어서 정점 시 백엔드가 작동을 멈추거나, 요청별로 더 많은 처리가 필요하도록 트래픽 구성이 변경되거나, 할당량 값이 너무 높게 설정되는 등의 이유로 인해 과부하가 발생합니다. 따라서 매우 많은 트래픽이 유입될 때의 입찰자 작동 방식을 미리 생각해두면 도움이 됩니다.

과부하 시의 작동 방식과 관련하여 입찰자는 크게 3개의 카테고리로 분류됩니다.

'전체 응답' 입찰자

이 입찰자는 구현하기에는 쉽지만 과부하 시 가장 낮은 성능을 보여줍니다. 입찰 요청의 유형에 상관없이 바로 처리할 수 없는 요청까지도 대기시키는 등 유입되는 모든 입찰 유형에 응답하려고 합니다. 일반적으로 이후의 상황은 아래와 같습니다.

  • 요청 비율이 증가하면서 요청 지연 시간도 늘어나며, 결국에는 모든 요청에서 시간 초과가 발생하기 시작합니다.
  • 콜아웃 비율이 최대치에 접근하면서 지연 시간도 급격히 늘어납니다.
  • 입찰자 조절이 시작되면서 허용되는 콜아웃이 급격하게 줄어듭니다.
  • 지연 시간이 회복하기 시작하면서 입찰자 조절이 감소합니다.
  • 위 과정이 다시 반복됩니다.

이 입찰자에 대한 지연 시간 그래프는 급격한 변화가 이루어지는 톱니바퀴 모양으로 나타납니다. 또는 대기 상태의 요청으로 인해 서버가 메모리 페이징을 시작하거나 장기 둔화를 촉발하는 작업을 하게 되며, 지연 시간은 정점이 지날 때까지 전혀 회복하지 않아서 정점 기간에 콜아웃 비율이 줄어들게 됩니다. 어느 경우든 할당량이 단순히 더 낮은 값으로 설정될 때보다 실행되거나 응답하는 콜아웃이 줄어듭니다.

'과부하 시 오류' 입찰자

이 입찰자는 일정 비율까지 콜아웃을 수락하고, 그 다음부터는 일부 콜아웃에 대해 오류를 반환하기 시작합니다. 이 과정은 내부 시간 초과를 통해 이루어지며, 그 결과로 연결 대기(Apache의 경우 ListenBackLog가 제어)가 정지되고, 활용 및 지연 비율이 너무 높아질 때 개연적인 하락 모드가 구현되거나 일부 다른 메커니즘이 구현됩니다. Google에서 확인된 오류율이 15%를 넘으면 입찰자 조절이 시작됩니다. '전체 응답' 입찰자와는 달리 이 입찰자는 '손실을 줄이며', 그 결과로 요청 비율이 하락할 때 응답 수준이 바로 회복됩니다.

이 입찰자의 지연 시간 그래프는 과부하 시 얕은 톱니바퀴 모양으로 나타나며, 최대 허용 비율 근처에서 해당 수준에 맞게 조절됩니다.

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

이 입찰자는 일정 비율까지 콜아웃을 수락하며, 그 다음부터는 모든 과부하에 대해 '입찰 없음' 응답을 반환하기 시작합니다. '과부하 시 오류 입찰자'처럼 이 입찰자는 많은 방식으로 구현될 수 있습니다. 차이점은 Google로 반환되는 신호가 없어서 Google이 콜아웃을 조절하지 않는다는 점입니다. 과부하는 프론트엔드 컴퓨터에 의해 흡수되며, 그 결과로 처리할 수 있는 트래픽만 백엔드를 계속 통과합니다.

이 입찰자에 대한 지연 시간 그래프는 정점 시의 요청 비율과 그에 상응하는 하락이 입찰을 포함하는 응답의 일부에서 나타나는 동일화가 인위적으로 중단되는 수평선으로 나타납니다.

아래와 같이 '과부하 시 오류' 방식과 '과부하 시 입찰 없음' 방식을 병행하여 사용하시기 바랍니다.

  • 프론트엔드를 오버프로비져닝하고 이를 과부하 시의 오류로 설정하여 일부 형태로 응답할 수 있는 연결의 수를 극대화하세요.
  • 과부하 시 오류가 발생할 때 프론트엔드 컴퓨터가 정형화된 '입찰 없음' 응답을 사용할 수 있고, 입찰 요청을 전혀 파싱하지 않아도 됩니다.
  • 백엔드에 대한 성능 확인을 구현하고, 충분한 용량이 없을 경우 '입찰 없음' 응답을 반환하게 하세요.

이렇게 하면 일부 과부하가 흡수되고 백엔드가 정확히 처리할 수 있는 만큼의 요청에만 응답할 수 있게 됩니다. 이러한 상황을 입찰 요청 집계가 예상보다 훨씬 더 높을 때 프론트엔드 컴퓨터가 '과부하 시 오류'로 돌아가는 '과부하 시 입찰 없음' 상태로 생각할 수 있습니다.

'전체 응답' 입찰자를 사용하는 경우 연결 작동 방식을 조절하여 과부하 상황을 거부하여 '전체 응답' 입찰자를 '과부하 시 오류' 입찰자로 변환해 보세요. 이를 통해 더 많은 오류가 반환되면 시간 초과가 줄어들며, 서버가 입찰 요청에 전혀 응답하지 못하는 상태가 되는 것을 방지할 수 있습니다.

맨 위로

핑 응답

입찰자가 핑 요청에는 응답하고 연결 관리에 대해서는 응답하지 않도록 설정하는 것은 디버깅에 있어서 매우 중요한 작업입니다. Google은 입찰자 상태, 연결 닫음 작동 방식, 지연 시간 등의 상태 확인과 디버깅을 위해 핑 요청을 이용합니다. 핑 요청의 형태는 아래와 같습니다.

  BidRequest <
    id: "1234567890123456"
    is_test: true
    is_ping: true
>

예상과는 달리 핑 요청에는 광고 슬롯이 전혀 포함되지 않을 수 있습니다. 위에 자세한 내용이 나와 있지만 핑 요청에 응답한 후에는 해당 연결을 닫아서는 안 됩니다.

맨 위로

피어링 고려

Google과의 피어링을 통해서도 네트워크 지연 시간 또는 가변성을 줄일 수 있습니다. 피어링을 이용하면 트래픽이 입찰자에 도달할 때까지 거치는 경로를 최적화할 수 있습니다. 연결 최종점은 동일하지만 중간 링크는 변합니다. 자세한 내용은 피어링 가이드를 참조하세요. 다음은 피어링을 최적의 방법으로 권장하는 이유에 대한 간략한 설명입니다.

  • 인터넷에서 기본적으로 통과 링크는 Google 네트워크의 외부에서 패킷을 도착 지점으로 보내고 링크를 통해 라우팅할 수 있는 가장 가까운 링크를 찾는 '핫 포테이토 라우팅'을 통해 선택됩니다. Google이 피어링 관계를 갖고 있는 제공업체가 소유한 백본의 한 섹션을 트래픽이 지날 경우 선택한 링크는 패킷이 시작한 지점과 가까울 가능성이 큽니다. 이 지점을 넘으면 패킷이 입찰자까지의 경로에 대해 권한을 Google이 가지지 않으므로 중간에 트래픽이 다른 자율 시스템(네트워크)로 이탈할 수 있습니다.

  • 반대로 직접 피어링 계약이 체결된 경우에는 패킷이 항상 피어링 링크를 따라 전송됩니다. 출발 지점에 상관없이 패킷은 Google이 소유하거나 대여한 링크를 지나고 입찰자 위치에 근접한 공유 피어링 지점에 도착합니다. 역방향 이동은 Google 네트워크로 짧게 호핑하여 이루어지고, 그 이후에는 Google 네트워크를 벗어나지 않습니다. 대부분의 이동 경로가 Google이 관리하는 인프라에 제한되어 있으면 패킷이 지연 시간이 낮은 경로를 거칠 수 있고, 가변성도 상당 부분 피할 수 있게 됩니다.

맨 위로

다음에 대한 의견 보내기...

DoubleClick Ad Exchange Real-Time Bidding Protocol