광고 서버를 위한 인프라 옵션(3부)

이 문서에서는 광고 게재 플랫폼을 구축할 때 사용할 수 있는 Google Cloud의 기능과 제품에 대해 설명합니다.

이 문서는 다음 시리즈의 일부입니다.

이 시리즈에서 사용하는 광고 기술 용어의 개요를 참조하세요.

광고 게재란 게시자의 지면에서 여러 광고주 중 하나의 광고(일반적으로 가장 관련성 높은 광고)를 고객에게 표시하는 과정입니다. 이 지면은 웹사이트, 앱, 게임 등일 수 있습니다.

광고 서버의 복잡성은 제공하는 기능에 따라 다릅니다. 업계에서 통용되는 광고 서버의 의미는 게시자와 광고주가 캠페인, 광고, 광고 집행을 관리하는 도구입니다. 광고 서버의 역할은 도로변의 광고판처럼 정적인 광고를 게재하는 데 그치지 않습니다. 광고 표시가 핵심 기능인 것은 맞지만, Google Ad Manager와 같은 광고 기술 플랫폼은 단순히 사용자에게 독특한 광고를 표시하는 것 이외에 다양한 기능과 장점을 제공합니다.

이 문서에서는 다음과 같은 주요 기능을 포함하는 견고한 광고 게재 플랫폼을 구축하는 접근 방식을 살펴봅니다.

  • 캠페인, 계정, 결제, 보고 관리
  • 가장 관련성 높은 광고 선택
  • 타겟 사용자에게 광고 표시
  • 노출, 클릭, 전환 등의 이벤트 관리
  • 분석 데이터 저장소에 관련 작업 게시

광고 서버는 일반적으로 초당 수만 개의 광고 요청을 처리하면서 각 응답을 수 밀리초 이내에 전송합니다. 이렇게 많은 요청에 빠르게 응답할 수 있어야 하므로 가용성, 확장성, 낮은 지연 시간은 광고 게재 솔루션의 핵심적인 요구사항입니다. 단일 서버 솔루션으로는 이러한 요구사항을 모두 해결할 수 없으므로 이 문서에서는 분산형 시스템 설계에 대해 고찰합니다.

광고 서버에는 두 가지 유형이 있습니다.

  • 판매측: 게시자가 광고 수익을 극대화할 수 있도록 광고 서버의 UI에서 직접 광고주를 관리할 수 있는 서버입니다. 판매측 서버는 광고를 호스팅하는 경우가 많지만 광고에 대한 참조를 호스팅할 수도 있습니다. 일부 광고 서버는 구매자용 셀프서비스 UI를 제공하기도 합니다.
  • 구매측: 광고주, 마케팅 부서, 광고 대행사가 광고 업데이트를 관리할 수 있는 서버입니다. 이러한 플랫폼의 사용자는 게시자에게 실제 광고를 제공하는 대신 구매측 광고 서버와 통신하여 광고를 검색하는 코드 스니펫을 제공합니다.

아래 다이어그램은 광고 서버 시스템의 가능한 아키텍처 중 하나를 보여줍니다.

광고 서버 시스템의 가능한 구현

광고 서버 플랫폼의 기본 진입점은 Cloud Load Balancing에 의존하여 다음과 같은 작업을 수행합니다.

  • 광고 요청
  • 광고 소재 가져오기. 가장 가까운 Cloud CDN 캐시에서 광고를 가져옵니다.
  • 노출 또는 (고유) 사용자의 작업/클릭과 같은 이벤트 추적

부하 분산기에 대한 요청은 HTTP(S) 부하 분산 로깅 및 모니터링 또는 수집기에서 실행되는 커스텀 코드를 통해 로깅되며 Pub/Sub에 게시된 후 분석 및 사용자 프로파일링을 위해 Dataflow에서 처리됩니다.

요청을 처리하는 작업자는 다음을 활용합니다.

  • 예산 정보
  • (고유) 사용자 프로필
  • 캠페인 세부정보
  • 카운터
  • 학습 모델을 통한 선택

위 사항 중 일부는 구체적인 요구사항에 따라 조정되어야 합니다.

  • 광고 선택에 서로 다른 여러 데이터베이스를 사용할 필요가 없으며 단순성을 위해 계층형 또는 관계형 데이터베이스를 배제해도 무방할 수 있습니다. 이러한 경우 Cloud Bigtable 또는 Cloud Spanner를 사용할 수 있습니다.
  • 추가적인 운영 오버헤드를 감수하더라도 입찰 요청을 처리할 때 읽기 지연 시간을 1밀리초 미만으로 유지해야 할 수 있습니다. 이러한 경우 가능하다면 로컬 복제 기능이 있는 타사의 리전별 메모리 내 데이터베이스를 사용할 수 있습니다.
  • 선점형 VM에 이벤트 컬렉터를 설정하여 비용을 최소화할 수 있습니다. 온라인 처리가 필요하지 않은 경우 Cloud Logging으로 이벤트를 캡처하여 BigQuery로 분석할 수 있습니다.

캠페인 관리

광고주는 캠페인을 관리하기 위해 최소한 웹 프런트엔드와 사용자 인터페이스(UI)를 갖춘 사용자 프런트엔드가 필요합니다. 또한 광고주는 몇 가지 보고 기능을 제공해야 합니다. 권장되는 옵션은 사용자 프런트엔드(1부)를 참조하세요.

이 UI를 통해 설정되는 리소스의 공통 계층 구조에는 광고주, 캠페인, 예산, 광고 소재, 결제가 포함됩니다. 이 계층 구조를 만들면 시스템에서 광고 선택 결정 과정의 일부를 형성하는 일련의 규칙을 기록합니다. 이 데이터는 메타데이터 관리 저장소(1부)에 저장됩니다.

대부분의 광고 서버는 하루에 수십억 개의 광고 요청을 처리합니다. Cloud Spanner를 사용하는 경우가 아니라면, 광고주 규칙에 적용되는 메타데이터를 저장하는 데이터베이스에 이러한 부하를 직접 가하는 방법은 권장되지 않습니다. 대량 읽기 저장 패턴(1부)에서 설명하는 옵션 중 하나를 대신 사용해 보세요.

가장 관련성 높은 광고 선택

광고 요청 수신 및 파싱

요청은 게시자의 지면에 배치된 광고 태그를 통해 전송됩니다. 광고 태그는 다음과 같은 형태입니다.

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

태그가 로드되면 광고 서버에 대한 광고 요청이 실행됩니다. 요청은 HTTP 헤더, 사용자 에이전트, 페이지 컨텍스트, IP 주소, 타겟팅 정보, 사용자 ID(가능한 경우), 크기를 비롯한 광고 세부정보와 같은 다양한 정보를 포함합니다.

광고 서버는 이러한 요청을 수신하여 처리하는 HTTP 엔드포인트 [URL_TO_YOUR_AD_SERVER]를 제공해야 합니다. 권장되는 옵션은 요청 처리(1부)에서 자세히 설명합니다.

사용자 프로파일링

광고를 선택하는 방식은 광고 서버마다 다릅니다. 구체적인 로직은 이 문서에서 다루지 않습니다. 그러나 사용자를 이해하는 것은 관련성 높은 광고를 표시하는 데 필수적인 요소입니다. 이 솔루션에서는 고급 사용자 분류를 필수적인 요건으로 가정합니다.

여러 게시자가 사용하는 광고 서버는 서로 다른 지면에서 같은 사용자를 인식할 가능성이 높습니다. (고유) 사용자 ID는 웹 쿠키이거나 사용자가 교체 가능한 휴대기기 ID일 수 있습니다.

광고 서버는 광고 요청에서 제공한 정보(IP, 페이지 정보)에 이 사용자 ID를 더하여 데이터 저장소를 검색할 수 있습니다. 광고 서버는 테라바이트 규모에 이를 수 있는 수백만 행의 데이터에서 사용자 ID를 검색할 수 있어야 합니다. 또한 관리 오버헤드를 최소화하면서 수 밀리초 이내에 응답을 반환해야 합니다.

여기에 대한 개요는 (고유) 사용자 프로필 저장소를 (1부에서) 참조하세요. 해당 문서에서 설명하는 옵션을 사용할 수 있지만, 광고 게재용으로 다음과 같은 장점을 갖는 Cloud Bigtable이 권장됩니다.

  • 페타바이트 단위의 데이터를 저장할 수 있는 와이드 칼럼 NoSQL 데이터베이스
  • 10밀리초 미만으로 행 검색
  • 지역별 복제 지원
  • 완전 관리형

캠페인 및 광고 선택

광고 선택 프로세스는 광고 선택(1부)의 설명과 같이 몇 단계에 걸쳐 수행됩니다.

  1. (고유) 사용자 프로필 저장소(1부)로 사용자를 프로파일링합니다.
  2. 메타데이터 관리 저장소 데이터(1부)의 사본을 사용하여 일치하는 캠페인 및 광고를 선택합니다. 사본은 대량 읽기 저장 패턴(1부) 중 하나를 사용하여 작성됩니다.
  3. 컨텍스트 저장소(1부)를 사용하여 관련성 높은 캠페인 및 광고를 필터링합니다.
  4. 광고를 선택합니다.

광고 서버는 사용자 세그먼트와 일치하는 캠페인 및 광고를 선택한 후 컨텍스트 저장소의 데이터 값(예: 게재빈도 설정, 차단 목록, 소진된 예산)과 비교하여 검증합니다. 그런 다음 나머지 캠페인 및 광고 중에서 최선의 광고를 선택합니다. 이 최종 선택에 대한 로직은 전적으로 개발자가 좌우합니다. 예를 들어 캠페인을 서로 비교하여 CPM이 가장 높거나 잔여 예산이 가장 많은 캠페인을 선택할 수 있습니다. 광고의 CTR 잠재력을 계산하거나 여러 매개변수를 조합하여 혼합 가중치를 부여할 수도 있습니다.

더 진보된 선택 시스템에서는 머신러닝을 통해 각 사용자 또는 세그먼트를 기준으로 광고를 추천하기도 합니다. 머신러닝 워크플로는 이 문서에서 다루지 않으며 머신러닝 기능 구축(2부)에서 자세히 알아볼 수 있습니다.

선택된 광고를 타겟 사용자에게 게재

이 시점까지 진행된 세부 단계는 게시자측 광고 게재 작업에 속하는 것으로 볼 수 있습니다. 그러나 광고가 선택된 후 광고 서버는 다음 중 하나를 가리킬 수 있는 링크 또는 HTML 코드를 반환합니다.

  • 게시자의 광고 서버에 속하는 위치
  • 광고주에게 속할 수 있는 외부 위치. 이러한 광고 서버는 구매측 광고 서버로 간주되며 제3자 광고 게재(3PAS)라는 모델을 구현합니다. 광고주는 이 위치에서 게시자의 광고 서버와 접속하거나 통신할 필요 없이 광고를 업데이트할 수 있습니다. 또한 추적 정보를 스스로 관리할 수 있습니다.

광고 게재까지 이어지는 프로세스는 광고 소재를 직접 호스팅하는 방법과 게시자의 광고 서버에 호스팅하는 방법 중 마케팅 담당자가 무엇을 선호하는지와 관계없이 동일합니다.

광고 소재 저장

광고 소재는 동영상, 이미지 등의 미디어 파일입니다. 이러한 항목을 저장하려면 확장성과 고가용성을 갖춘 객체 저장소가 필요합니다.

이러한 저장소로 Cloud Storage가 권장됩니다. 이 저장소는 페타바이트 급의 원시 데이터 또는 비정형 데이터를 호스팅하도록 구축되었으며 백업 및 보관을 위한 옵션도 제공합니다. Cloud Storage만 사용해도 광고 소재의 수명 주기를 관리하고 핫 스토리지에서 콜드 스토리지로 이동하여 Nearline, Coldline, Archive로 비용을 절감할 수 있습니다.

광고 소재 배포

Cloud Storage 등의 객체 저장소는 전 세계를 대상으로 제공되지만 거리로 인해 네트워크 지연 시간이 가중되는 경향이 있습니다. 또한 객체 저장소는 콘텐츠 전송 네트워크(CDN)를 통해 광고를 게재하는 방법보다 비용이 높습니다.

광고 픽셀 및 소재는 공개 콘텐츠인 경우가 많으므로 두 가지 GCP 솔루션 중 하나를 사용하여 Cloud Storage의 콘텐츠를 캐ㅅ시할 수 있습니다.

  • 객체 공개: 캐시 제어를 사용하면 Cloud Storage에서 기존 Google 인프라를 사용하여 콘텐츠를 캐시할 수 있지만 CDN 유사 기능은 제한되며 광고 소재를 전 세계에서 강제로 만료시킬 수 없습니다.

  • Cloud Load Balancing과 Cloud Storage 결합: Cloud Storage에 호스팅된 콘텐츠에 Cloud CDN이 설정된 Cloud Load Balancing을 사용할 수 있습니다. Cloud Storage 이그레스와 비교하여 Cloud CDN은 할인된 네트워킹 가격과 함께 서명된 URL 지원, 캐시 키, 무효화 기능을 제공합니다.

    아래 다이어그램은 두 번째 솔루션을 보여줍니다.

    Cloud Load Balancing과 Cloud Storage 결합

다른 제공업체와의 성능 비교는 제3자 Cedexis 보고서를 참조하세요.

광고 이벤트 관리

시스템에 유용한 여러 가지 이벤트 유형의 예시는 다음과 같습니다.

  1. 광고 요청: 요리 웹사이트에서 user_ABC에 대한 광고 요청을 받은 시스템은 요리 > 인도 음식 같은 분류 또는 사용자의 관심사를 반영하는 기타 정보를 추가하여 user_ABC 세그먼트를 개선할 수 있습니다.
  2. 광고 노출: CPM 모델에서는 광고가 타겟 사용자에게 표시됩니다. 시스템은 잔여 예산을 업데이트할 수 있도록 노출을 기록합니다.
  3. 광고 클릭: 사용자가 광고를 클릭한 경우입니다. 특히 여러 (고유) 사용자가 일정 시간 동안 같은 광고를 클릭하는 경우 이 행동이 광고 최적화 결과에 영향을 줄 수 있습니다.
  4. 전환: 사용자가 광고를 클릭하고 광고주의 지면에서 구매, 가입 등의 기대 행동을 수행한 경우입니다.

이벤트를 처리할 때는 프로세스의 모든 단계, 특히 다음과 같은 단계에서 가격, 데이터의 신선도, 운영 오버헤드 간에 적절한 균형점을 찾는 것이 중요합니다.

  • 노출, 클릭, 전환, 광고 요청에 따라 고속으로 발생하는 대용량 이벤트 수집 및 처리
  • 값을 추출하고 예산, 한도, 클릭률 등의 카운터를 계산하기 위해 실시간 또는 오프라인으로 이벤트 처리
  • 결제를 정산하거나 적절한 게재 작업을 적용하기 위해 실시간 또는 오프라인으로 다양한 저장소에 결과 내보내기

자세한 내용은 이벤트 수명 주기(2부)를 참조하세요.

실시간 이벤트 캡처 및 처리를 위해 권장되는 아키텍처는 다음과 같습니다.

실시간 이벤트 캡처 및 처리를 위한 아키텍처

이 아키텍처의 특징은 다음과 같습니다.

  • 노출 및 클릭이 발생하면 Cloud Storage에 호스팅된 정적 코드 또는 Google Kubernetes Engine(GKE)에 호스팅된 웹 서버 컬렉터에 대한 HTTP 엔드포인트 요청이 전송됩니다.
  • 요청 이벤트가 부하 분산기 HTTP 로그를 통해 로깅되거나 컬렉터가 캡처한 이벤트가 Pub/Sub에 게시됩니다.
  • Dataflow는 Pub/Sub 주제를 구독하고 이벤트를 처리합니다.
  • 그런 다음 Dataflow는 원시 이벤트 또는 처리된 이벤트를 BigQuery로 내보내서 분석을 수행하고, 인텔리전스(컨텍스트) 데이터베이스로 내보내서 잔여 예산을 업데이트합니다.

정적 코드를 Cloud Storage에 호스팅할지 아니면 GKE 컬렉터에 호스팅할지는 요구사항에 따라 결정됩니다.

  • 추가적인 백엔드 작업을 수행해야 하는 경우 GKE를 사용합니다.
  • 운영 오버헤드가 염려되는 경우 Cloud Storage를 사용합니다.
  • GKE 또는 Compute Engine 컬렉터를 실행하는 비용을 줄일 필요가 있으며 요청이 가끔 재시도되어도 무방한 경우 컴퓨팅 플랫폼 섹션(1부)에서 제시하는 것처럼 선점형 VM을 사용합니다.

다음 단계