광고 워크로드를 처리하기 위한 인프라 옵션(1부)

이 도움말에서는 광고 서버 및 입찰자를 비롯한 다양한 광고 기술 플랫폼에서 공유되는 요소에 대해 설명합니다. 이 기사에서는 이러한 구성요소를 구현하기 위한 옵션을 제공합니다.

광고 서버와 입찰자는 기술이 겹치는 보완적인 플랫폼입니다. 콘텐츠 중복을 피하기 위해 이 도움말과 동반 도움말인 2부는 시리즈에 대한 컨텍스트를 제공합니다.

전체 시리즈의 대략적인 개요와 시리즈 전반에서 사용되는 용어광고 플랫폼 구축(개요)을 참조하세요.

플랫폼 고려사항

플랫폼의 구매 또는 판매 측면을 다룰 때 다음을 고려하세요.

  • 컴퓨팅 플랫폼: 프로그래매틱 방식의 광고 플랫폼은 여러 서비스를 포함하며 각 서비스는 하나 이상의 기능을 제공합니다. 이러한 기능 중 일부 또는 전부를 컨테이너화할 수 있는지 또는 서비스가 가상 머신(VM) 인스턴스에서 직접 실행되어야 하는지를 일찍 판단하세요.
  • 지리적 위치: 인프라를 고객 및 제공업체와 가깝게 배치하면 네트워크 지연 시간을 줄일 수 있습니다.
  • 재현성: 전 세계 여러 지역에 시스템을 복제할 때 동일한 인프라를 일정하게 배포할 수 있으므로 플랫폼 전체에 일관성이 유지됩니다.
  • 부하 분산: 단일 머신으로는 광고 기술 부하를 처리할 수 없습니다. 내부 및 외부 요청을 여러 서버에 분산하세요.
  • 자동 확장: 광고 요청 부하는 하루 동안 변동합니다. 시스템을 자동으로 확장 및 축소하여 비용을 줄이고 가용성을 높일 수 있습니다.
  • 네트워크 통신: 분산 시스템에서는 통신이 문제가 됩니다. 예를 들어 오리건에서 입찰하는데 캠페인 관리 데이터베이스는 유럽에 있다고 가정해 보겠습니다. 통신이 오프라인 동기화로 구성되어 있더라도 공용 인터넷을 통해 통신하지 않는 것이 좋습니다.

컴퓨팅 플랫폼

Google Cloud는 컴퓨팅 워크로드를 실행하기 위한 몇 가지 옵션을 제공합니다. 다음 옵션을 고려하세요.

  • App Engine: 운영 오버헤드의 대부분을 제외한 웹 사용자 인터페이스(UI)를 실행합니다.
  • Compute Engine: App Engine에서 지원하지 않는 일부 관계형 데이터베이스 또는 커스텀 코드를 설치 및 관리합니다.
  • Google Kubernetes Engine(GKE): 상태 비추적 프런트엔드를 설정하거나 컨테이너식 애플리케이션을 실행합니다.

이러한 옵션은 권장 사항이며 바꿔서 사용되는 경우도 종종 있습니다. 해당 요소가 비용, 운영 오버헤드 또는 성능 중 어느 것이든 궁극적으로 요구사항이 결정 요소입니다.

Compute Engine과 GKE 모두 광고 기술 작업 부하에 사용되어 비용을 절감하는 선점형 VM을 지원합니다. 그러나 선점형 VM은 1분 경고만으로도 선점될 수 있으므로 다음을 수행하는 것이 좋습니다.

  • Compute Engine을 사용하는 경우, 두 개의 서로 다른 관리형 인스턴스 그룹(하나는 선점형, 다른 하나는 표준 VM)이 동일한 부하 분산기에 속할 수 있습니다. 그룹 하나를 표준 VM으로 구성하면 프런트엔드에서 수신 요청을 항상 처리할 수 있게 됩니다. 다음 다이어그램에서 이 접근 방식을 볼 수 있습니다.

    동일한 부하 분산기에 있는 두 개의 서로 다른 관리 인스턴스 그룹

  • GKE를 사용하는 경우 GKE 클러스터에 비선점형 노드 풀과 선점형 노드 풀을 모두 만들어 가용성을 유지하면서 비용을 줄일 수 있습니다.

지리적 위치

광고주는 전 세계 모든 지역의 고객을 타겟팅할 수 있습니다. 플랫폼의 UI 프런트엔드 중 하나에 몇 밀리초를 추가해도 실적 데이터를 시각화하는 등 광고주의 경험이 저하되지 않습니다. 그러나 추가 네트워킹 거리가 입찰 응답에 몇 밀리초를 추가하는 경우 주의하세요. 몇 밀리초가 지나면 광고주의 입찰가가 승인되고 광고가 고객에게 게재되는지 여부가 달라질 수 있습니다.

Google Cloud는 us-east, us-west, europe-west, asia-southeast, asia-east를 포함한 여러 리전에서 운영됩니다. 각 리전에는 고가용성 및 확장성을 제공하는 여러 영역이 있습니다.

대기 시간이 중요한 경우 다른 지역의 해당 영역에 일부 서비스를 배포할 수 있습니다. 필요에 따라 설정을 맞춤설정할 수 있습니다. 예를 들어 일부 프런트엔드 서버를 us-east4us-west1에 두고 데이터는 us-central의 데이터베이스에 저장할 수 있습니다. 경우에 따라 일부 데이터베이스 데이터를 프런트엔드 서버에 로컬로 복제할 수 있습니다. 멀티 리전 Cloud Spanner 인스턴스를 고려해 볼 수도 있습니다.

재현성

재현성은 유지관리 및 배포를 단순화하며, 모든 관련 지리적 위치에서 플랫폼을 실행하는 것은 중요한 마감 기한 전에 입찰가를 반환하는 데 매우 중요합니다. 재현성을 보장하기 위해 모든 지역에서 유사한 작업을 수행해야 합니다. 가장 큰 차이점은 작업 부하와 지역 수요를 충족시키기 위해 필요한 머신 및 구역의 수를 결정하는 것입니다.

Compute Engine을 사용하면 인스턴스 템플릿을 기반으로 유사한 리전별 관리형 인스턴스 그룹을 설정할 수 있습니다. 이러한 그룹은 SSP와 인접한 다른 지역에 위치할 수 있으며 고가용성을 위해 여러 영역으로 확장될 수 있습니다. 다음 다이어그램에서 이 프로세스를 확인할 수 있습니다.

인스턴스 템플릿을 사용하여 리전 관리 인스턴스 그룹 설정

컨테이너는 머신 가상화보다 높은 추상화 수준을 제공합니다. Kubernetes는 서로 다른 클러스터에서 일관성을 유지하면서 pod, 서비스, 배포를 정의할 수 있는 YAML 구성 파일을 통해 기본적으로 애플리케이션 재현성을 지원합니다.

부하 분산

두 가지 주요 시나리오에 부하 분산이 필요합니다.

  • 광고 또는 입찰 요청과 같은 외부 트래픽의 경우 HTTP(S) 및 네트워크 부하 분산 기능을 제공하는 Cloud Load Balancing을 사용할 수 있습니다. 사전 가동과 전역 부하 분산 및 단일 Anycast IP가 없는 경우 시스템은 전 세계 어디에서든 초당 수백만 건의 요청을 받을 수 있습니다.
  • 서비스 간 내부 트래픽의 경우 Google Cloud에서는 내부 부하 분산이 가능합니다.

인프라의 일부에 Kubernetes를 사용하려고 한다면 GKE를 사용하는 것이 좋습니다. 공급자가 기본적으로 지원하지 않는 일부 Kubernetes 기능의 경우 추가 구현이 필요할 수 있습니다. Kubernetes는 GKE를 통해 다음과 같은 기본 Google Cloud 기능을 사용할 수 있습니다.

또한 GKE는 컨테이너 기본 부하 분산을 지원하여 네트워킹 시간 및 발생 가능한 추가 네트워킹 홉을 최소화합니다. 부하 분산기는 높은 수준에서 요청이 요청된 서비스의 포드를 호스팅하지 않는 인스턴스로 라우팅되는 것을 방지합니다.

확장

플랫폼이 하루에 수십억 개의 광고 요청을 파싱하고 계산할 수 있어야 하므로 부하 분산 조정이 필수입니다. 게다가 단일 머신은 그 작업에 부적합합니다. 그러나 요청 수가 하루 종일 변화하는 경향이 있습니다. 즉, 인프라가 수요에 따라 확장 및 축소될 수 있어야 합니다.

Compute Engine을 사용하기로 결정한 경우 인스턴스 템플릿을 사용하여 자동 확장 관리형 인스턴스 그룹을 만들 수 있습니다. 그런 다음 HTTP 부하, CPU, Cloud Monitoring 커스텀 측정항목(예: 애플리케이션 지연 시간)과 같은 다양한 측정항목에 따라 이러한 그룹을 확장할 수 있습니다. 또한 이러한 측정항목을 조합하여 이러한 그룹을 확장할 수도 있습니다.

자동 확장 결정은 지난 10분 동안의 측정항목 평균을 기반으로 하며 슬라이딩 창을 사용하여 매분 이루어집니다. 모든 인스턴스 그룹은 고유한 확장 규칙 세트가 있을 수 있습니다.

GKE, 즉 Kubernetes의 Cluster Autoscaler를 사용하기로 결정했다면 GKE Cluster Autoscaler를 사용하여 기본적인 구현이 가능합니다. GKE 클러스터 자동 확장 처리는 Compute Engine 자동 확장 처리와 다르게 동작하며 기본 노드의 CPU 또는 메모리 부족으로 인해 기존 노드에서 더 이상 새 포드를 예약할 수 없는 경우 새 노드를 회전시킵니다. CPU 또는 메모리를 다시 출시하면 자동으로 축소됩니다.

네트워크 통신

Virtual Private Cloud(VPC)는 여러 리전으로 확장될 수 있습니다. 즉, us-east의 데이터베이스 읽기 복제본과 asia-southeast의 마스터 데이터베이스가 동일한 VPC 내에 있으면 Google 네트워크를 벗어나지 않고도 비공개 IP 또는 호스트 이름을 사용하여 안전하게 통신할 수 있습니다.

다음 다이어그램에서 모든 인스턴스는 동일한 VPC에 있으며 서로 다른 리전에 있더라도 VPN 없이 직접 통신할 수 있습니다.

모든 인스턴스가 동일한 VPC 및 다른 리전에 있음

GKE 클러스터는 생성될 때 VPC에 할당되며 기존의 많은 네트워킹 기능을 사용할 수 있습니다.

Google은 두 가지 유형의 네트워킹 인프라도 제공합니다.

  • Premium: Google 글로벌 비공개 네트워크를 사용합니다. 지역 간 데이터베이스 복제와 같은 중요한 작업 부하에 대해서는 이 옵션부터 고려하시기 바랍니다.
  • Standard: 가격에 민감하고 공용 인터넷을 사용할 수 있는 경우에는 이 옵션부터 고려하시기 바랍니다.

Cloud Bigtable, Cloud Storage, BigQuery 등의 관리형 제품을 사용하는 경우 Google Cloud는 VPC를 통해 해당 제품에 대한 비공개 액세스를 제공합니다.

사용자 프런트엔드

사용자 프런트엔드는 중요하지만 더 작은 작업 부하를 처리하기 때문에 최소한의 기술 오버헤드가 필요합니다. 사용자 프런트엔드는 플랫폼 사용자에게 캠페인, 광고 소재, 청구 또는 입찰과 같은 광고 리소스를 관리할 수 있는 기능을 제공합니다. 또한 프런트엔드는 보고 도구(예: 캠페인 또는 광고 실적 모니터링)와 상호작용할 수 있는 기능을 제공합니다.

이 두 가지 기능 모두 플랫폼 사용자에게 UI를 제공하기 위한 웹 서비스와 트랜잭션 또는 분석 데이터를 저장하는 데이터 저장소가 필요합니다.

웹 서비스

광고 프런트엔드는 다음 조건을 충족해야 할 필요성이 있습니다.

  • 고가용성을 제공해야 합니다.
  • 초당 수백 건의 요청을 처리합니다.
  • 적절한 사용자 환경을 제공하기 위해 수용 가능한 지연 시간에 전 세계적으로 이용 가능합니다.
  • UI를 제공합니다.

인터페이스에는 광고주, 캠페인 및 관련 구성요소를 설정하기 위한 대시보드 및 페이지와 같은 기능이 포함될 가능성이 큽니다. UI 디자인 자체는 별도의 분야이며 이 도움말의 범위에 포함되지 않습니다.

기술 오버헤드를 최소화하려면 App Engine을 프런트엔드 플랫폼으로 사용하는 것이 좋습니다. 이러한 선택은 웹 사이트 인프라 관리에 소요되는 시간을 최소화하는 데 도움이 됩니다. 커스텀 런타임이 필요하다면 커스텀 런타임을 고려하세요. 또는 원하는 애플리케이션 스택에 다른 요구사항이 있는 경우 GKE 또는 Compute Engine을 사용할 수 있습니다.

데이터 저장소

사용자 프런트엔드에는 두 가지 데이터 저장소 유형이 있습니다.

  • OLTP(온라인 트랜잭션 처리) 데이터베이스가 필요한 관리 데이터 저장소입니다. 옵션은 메타데이터 관리 저장소 섹션에 자세히 설명되어 있습니다.
  • OLAP(온라인 분석 처리) 데이터베이스가 필요한 보고 데이터 저장소입니다. 옵션은 보고/대시보드 저장소 섹션에 자세히 설명되어 있습니다.

요청 처리

프런트엔드

요청은 플랫폼이 제공하는 HTTP(S) 엔드포인트로 처리되도록 전송됩니다. 주요 구성요소는 다음과 같습니다.

  • 부하 분산기는 수십만 개의 QPS를 처리할 수 ​​있습니다.
  • 다양한 KPI를 기반으로 신속하게 확장 및 축소할 수 있는 인스턴스 풀입니다.
  • 엔드포인트를 조절 및/또는 인증하는 가능한 API입니다.

Compute Engine과 GKE는 모두 컴퓨팅 플랫폼으로 좋은 옵션입니다.

  • Compute Engine은 확장 섹션에서 설명한 대로 Cloud Load Balancing과 관리형 인스턴스 그룹을 사용합니다.
  • GKE는 Cloud Load Balancing 및 Ingress(또는 Istio Ingress Gateway), Horizontal Pod Autoscaler, Cluster Autoscaler를 사용합니다.

포드 확장은 노드 확장보다 빠르기 때문에 GKE는 서비스 수준에서 보다 빠른 자동 확장을 제공할 수 있습니다. 또한 GKE는 컨테이너 기본 부하 분산을 지원하여 관련 서비스의 포드를 호스팅하는 인스턴스로 직접 라우팅하는 요청을 최적화합니다.

제한 및 인증은 Apigee 또는 서비스 인프라와 같은 기술을 통해 관리할 수 있습니다.

파싱

광고 요청의 형식은 일반적으로 IP 주소, 사용자 에이전트 또는 사이트 카테고리와 같은 정보로 JSON 또는 protobuf 형식으로 지정됩니다. 광고를 선택하고 필터링하기 위해 세그먼트를 검색하려면 (고유) 사용자에 대한 세부 정보가 포함될 수 있는 이 데이터를 추출하는 것이 중요합니다.

정적 필터링

일반적으로 구매자 측에서 받은 일부 요청은 정적 규칙을 사용하여 폐기할 수 있습니다. 이러한 초기 필터링은 다운스트림에 필요한 복잡한 데이터 및 데이터 양을 줄일 수 있습니다.

규칙은 게시자 블랙리스트 또는 콘텐츠 유형 제외일 수 있습니다. 초기화하는 동안 작업자는 Cloud Storage에서 호스팅되는 파일에서 이러한 규칙을 가져와서 로드할 수 있습니다.

광고 선택

게시자 광고 서버, 광고주 광고 서버 또는 DSP를 비롯한 다양한 서비스 또는 플랫폼에서 광고를 선택할 수 있습니다. 광고를 선택할 때는 다양한 수준의 복잡성이 존재합니다.

  • 일부 경우에는 단순히 게시자 웹사이트 또는 페이지의 특정 카테고리에 대한 광고를 선택하기만 하면 될 수 있습니다. 이 경우 가격은 광고별로 다릅니다.
  • 고급 선택에는 사용자 속성 및 사용자 부문이 포함되며 잠재적으로 머신러닝 기반 광고 권장 시스템이 관련됩니다.
  • RTB 시스템은 대개 매우 복잡한 결정을 내립니다. 광고는 고유 사용자 부문 및 이전 입찰 가격과 같은 속성을 기반으로 선택됩니다. 이 선택에는 요청당 입찰 가격을 최적화하기 위한 입찰 계산이 포함됩니다.

관련 광고를 선택하는 것이 시스템의 핵심 기능입니다. 고급 규칙 기반 또는 ML 선택 알고리즘을 비롯하여 고려해야 할 여러 가지 요소가 있습니다. 그러나 이 도움말에서는 계속해서 상위 수준 프로세스와 다른 데이터 저장소와의 상호 작용에 중점을 둡니다.

광고 선택 프로세스는 다음 단계로 구성됩니다.

  1. (고유) 사용자 프로파일 저장소에서 대상 사용자와 연관된 세그먼트를 검색합니다.
  2. 사용자의 세그먼트에 가장 적합한 캠페인 또는 광고를 선택합니다. 이 항목을 선택하면 메타데이터 관리 저장소에서 메타데이터를 읽어야 하므로 이 저장소에서 대량 읽기 저장 패턴 중 하나를 구현해야 합니다.
  3. 컨텍스트 저장소 중 하나에 저장된 남은 예산과 같은 측정항목과 일치하도록 선택한 캠페인 또는 광고를 필터링합니다.
  4. 광고를 선택합니다.

입찰자는 입찰 및 경매와 관련된 단계가 더 많으며 대기 시간 요구사항이 더 큽니다. 광고 선택 중 입찰자 요구 사항에 대한 자세한 내용은 RTB 입찰자를 위한 인프라 옵션(4부)을 참조하세요.

대량 읽기 저장 패턴

광고를 선택할 때 내린 결정의 대부분은 다음과 같은 지능형 데이터가 필요합니다.

  • 밀리초 단위, 때로는 밀리초 이하 단위로 읽습니다.
  • 특히 시간에 민감한 카운터의 경우 가능한 한 빨리 작성됩니다.
  • 백그라운드 분석 또는 머신러닝 작업을 사용하는 오프라인 프로세스의 일부로 자주 작성됩니다.

데이터 저장소를 선택하는 방법은 다음 요구사항의 우선순위에 따라 다릅니다.

  • 읽기 또는 쓰기 지연 시간 최소화: 지연 시간이 중요한 경우 서버에 가깝고 대규모 읽기 또는 쓰기 작업을 빠르게 처리할 수 있는 저장소가 필요합니다.
  • 운영 오버헤드 최소화: 소규모 엔지니어링 팀이 있는 경우 완전 관리형 데이터베이스가 필요할 수 있습니다.
  • 확장: 하루에 수백만 명의 대상 사용자 또는 수십억 개의 이벤트를 지원하려면 데이터 저장소가 수평으로 확장되어야 합니다.
  • 쿼리 스타일 적용: 일부 쿼리는 다른 조건 집합을 충족하는 레코드를 검색해야 하는 특정 키를 사용할 수 있습니다. 경우에 따라 쿼리 데이터를 키에 인코딩할 수 있습니다. 다른 경우에는 쿼리에 SQL과 같은 기능이 필요합니다.
  • 데이터 신선도 극대화: 예산과 같은 일부 카운터는 가능한 한 빨리 업데이트해야 합니다. 잠재 고객 세그먼트 또는 카운터(예: 일일 한도)와 같은 기타 데이터는 나중에 업데이트할 수 있습니다.
  • 비용 최소화: DevOps를 최소화하기 위해 매일 수십억 개의 읽기 및 쓰기 작업을 단일 데이터베이스에서 강력한 일관성으로 처리하는 것이 항상 경제적이거나 실용적인 것은 아닙니다.

대량의 읽기 요구사항을 처리할 수 있는 옵션은 여러 가지가 있습니다. 여기에는 읽기 복제본, 캐싱 시스템, 메모리 내 NoSQL 데이터베이스 및 관리형 와이드 열 NoSQL 데이터베이스가 포함됩니다.

RDBMS 읽기 복제본

Cloud SQL(또는 Compute Engine에 설치되고 관리되는 이와 동등한 RDBMS)을 사용할 때 마스터 인스턴스에서 읽기를 오프로드할 수 있습니다. 많은 데이터베이스가 기본적으로 이 기능을 지원합니다. 근로자는 필요한 정보를 다음과 같이 쿼리할 수 ​​있습니다.

  • 작업자 수와 일치하는 읽기 복제본 사용.
  • 풀링 프록시 사용.

다음 다이어그램에서 이 프로세스를 확인할 수 있습니다.

읽기가 마스터 인스턴스에서 오프로드되는 데이터베이스

읽기 복제본은 대량 읽기 트래픽을 처리하도록 설계되었지만 확장성은 선형이 아니며 많은 수의 복제본으로 인해 성능이 저하될 수 있습니다. 전역 일관성 및 최소 운영 오버 헤드로 확장 가능한 읽기 또는 쓰기가 필요한 경우 Cloud Spanner 사용을 고려하세요.

로컬 캐싱 레이어

Compute Engine의 Redis와 같은 캐싱 레이어를 사용하여 작업자에 대한 선택적 로컬 복제본을 사용할 수 있습니다. 이 레이어는 읽기 및 네트워킹 모두에서 대기 시간을 크게 최소화할 수 있습니다. 다음 다이어그램에서 이 레이어를 확인할 수 있습니다.

캐싱 레이어를 활용하여 지연 시간 최소화

이 경우에 Kubernetes를 사용하기로 결정했다면 DaemonSet과 연관성을 확인하여 다음을 확인하세요.

  • 복제된 데이터의 양을 제한합니다.
  • 데이터는 게재 포드에 가깝게 유지됩니다.

인메모리 키-값 NoSQL

Aerospike 또는 Redis와 같은 메모리 내장 데이터베이스를 배포하여 빠른 읽기 속도를 제공합니다. 이 솔루션은 지역 데이터 및 카운터에 유용할 수 있습니다. 저장된 데이터 구조의 크기에 관심이 있다면 SSD 디스크에 쓸 수 있는 인메모리 데이터베이스를 활용할 수도 있습니다. 다음 다이어그램에서 이 솔루션을 확인할 수 있습니다.

SSD 디스크에 쓸 수 있는 인메모리 데이터베이스

관리형 와이드 칼럼 NoSQL

와이드 칼럼 데이터 저장소는 빠른 읽기 및 쓰기를 제공할 수 있는 키-값 저장소입니다. Cassandra 또는 HBase와 같은 일반적인 오픈소스 데이터베이스를 설치할 수 있습니다.

이러한 저장소를 사용하려면 Bigtable을 사용하여 운영 오버헤드를 최소화하는 것이 좋습니다. 이러한 저장소를 사용하면 입력/출력 작업(IOP)을 노드 수와 선형으로 확장할 수 있습니다. 올바른 키 디자인을 통해 광고 선택기를 읽을 수 있고 데이터 파이프 라인은 페타바이트 단위의 첫 번째 바이트에 한 자릿수 밀리초 속도로 쓸 수 있습니다. 다음 다이어그램에서 이 프로세스를 확인할 수 있습니다.

와이드 칼럼 데이터 저장소

정적 객체 저장소

protobuf, AVRO 또는 JSON 형식으로 저장할 수 있는 정적 데이터의 경우 작업자는 초기화 중에 Cloud Storage에서 로드하고 콘텐츠를 RAM에 유지할 수 있습니다. 다음 다이어그램에서 이 프로세스를 확인할 수 있습니다.

Cloud Storage에서 데이터 로딩

모든 경우에 적합한 솔루션은 존재하지 않습니다. 우선 순위에 따라 솔루션을 선택하고 대기 시간, 비용, 운영, 읽기/쓰기 성능 및 데이터 크기를 조정합니다.

솔루션 지연 시간 비용 운영 오버헤드 읽기/쓰기 성능 데이터 크기
RDBMS 읽기 복제본 밀리초 서비스 또는 컴퓨팅 기반 높음 제한적 이용 제한적 이용
Cloud Spanner 밀리초 서비스 기반 낮음 노드 수가 있는 선형 스케일 페타바이트
인메모리 저장소 밀리초 이하 컴퓨팅 기반 높음 노드 수로 확장 노드 수로 확장
Cloud Bigtable 한 자릿수 밀리초 서비스 기반 낮음 노드 수가 있는 선형 스케일 페타바이트

광고 데이터 저장소

이 섹션에서는 세 가지 시나리오 중 하나를 다루는 데이터 저장 옵션에 대해 설명합니다.

  • 광고 게재 저장소는 광고 선택과 관련된 서비스에서 사용됩니다. 작업 부하를 처리하려면 낮은 지연 시간으로 하루에 수십억 개의 읽기 작업을 처리할 수 있어야 합니다. 데이터 크기는 데이터 유형에 따라 다릅니다.
  • 분석 저장소는 임시 쿼리 또는 일괄 처리 데이터 파이프라인을 통해 오프라인으로 사용되며, 매일 수백 테라바이트의 데이터를 저장할 수 있습니다.
  • 보고/대시보드 저장소는 미리 만들어진 대시 보드, 시계열 또는 커스텀 보고서에 사용할 수 있습니다. 이러한 옵션은 프런트엔드를 차별화하여 플랫폼 사용자가 신속하게 정보를 얻고 비즈니스 수행 방법을 시각화할 수 있게 합니다.

광고 게재 저장소는 다음과 같이 세분화할 수 있습니다.

  • 메타데이터 관리 저장소는 관련 캠페인 및 광고를 선택할 때 사용됩니다. 사용자 프런트엔드는 데이터를 만들고 업데이트합니다. 이 데이터에는 지속성이 필요합니다.
  • 고유 사용자 프로필 저장소는 고유 사용자를 프로파일링하여 사용자와 광고를 일치시킬 때 사용됩니다. 데이터는 주로 이벤트(2부)를 사용하여 업데이트됩니다. 이 데이터에는 지속성이 필요합니다.
  • 제공 컨텍스트 저장소는 예산 또는 게재빈도 설정과 같은 여러 카운터를 기반으로 광고 및 캠페인을 필터링하는 데 사용됩니다. 데이터는 이벤트를 사용하여 업데이트됩니다. 이 데이터는 자주 덮어쓰기됩니다.

메타데이터 관리 저장소

메타데이터 관리 저장소에는 광고를 선택할 때 규칙을 적용할 참조 데이터가 들어있습니다. 여기에 저장된 일부 리소스는 플랫폼에 따라 다르지만 다른 리소스는 겹칠 수 있습니다.

  • 판매 측 광고 서버의 경우 게시자는 캠페인, 광고 소재, 광고주, 광고 슬롯 및 가격에 대한 데이터를 관리합니다. 일부 프런트엔드는 구매자에게 액세스 권한을 부여할 수도 있습니다.
  • 구매 측 광고 서버의 경우 구매자는 캠페인, 광고 소재, 광고주 및 가격에 대한 데이터를 관리합니다. 광고주가 UI를 통해 이 데이터를 직접 업데이트하는 경우도 종종 있습니다.
  • DSP의 경우 구매자는 캠페인, 광고 소재, 광고주 및 입찰 가격에 대한 데이터를 관리합니다. 광고주가 UI를 통해 데이터를 직접 업데이트하는 경우도 종종 있습니다.

메타데이터 저장소에는 관계형 또는 계층적 반정적 데이터가 포함됩니다.

  • 쓰기는 프런트엔드를 통한 플랫폼 사용자 편집의 결과이며 가끔 발생합니다.
  • 데이터 읽기는 광고 선택 서버에 의해 하루에 수십억 번 이루어집니다.

캠페인 메타데이터 데이터베이스는 사용자 프런트엔드에 중점을 두어 리소스 관계 및 계층을 관리하고 메가바이트를 몇 기가바이트의 데이터로 저장할 수 있어야 합니다. 또한 데이터베이스는 수백 개의 QPS 범위에서 읽기 및 쓰기를 제공해야 합니다. 이러한 요구사항을 해결하기 위해 Google Cloud는 관리형과 비관리형 모두에 대해 여러 가지 데이터베이스 옵션을 제공합니다.

  • Cloud SQL: MySQL 또는 PostgreSQL을 실행할 수 있는 완전 관리형 데이터베이스 서비스입니다.
  • Datastore: 확장성이 뛰어난 관리형 및 분산형 NoSQL 데이터베이스 서비스입니다. ACID 트랜잭션을 지원하고 SQL과 유사한 쿼리 언어를 제공하며 Strong Consistency 및 Eventual Consistency 수준을 제공합니다.
  • Spanner: 강력하고 일관된 읽기, 전역 트랜잭션 및 리전 간 복제를 제공하는 수평 확장 가능한 관계형 데이터베이스입니다. 대량 읽기 및 쓰기를 처리할 수 있습니다.
  • 커스텀: Compute Engine 또는 GKE에 MySQL, PostgreSQL, MongoDB, Couchbase 등의 여러 가지 오픈소스 또는 독점 데이터베이스를 설치하고 관리할 수 있습니다.

요구사항은 옵션의 범위를 좁히는 데 도움이 될 수 있지만, 관계형 데이터에 대한 지원으로 인해 전반적으로 Cloud SQL을 사용할 수 있습니다. Cloud SQL도 관리되며 읽기 복제본 옵션을 제공합니다.

앞서 언급했듯이 메타데이터 저장소는 플랫폼 사용자가 보고 또는 관리를 위해 사용할 뿐만 아니라 광고를 선택하는 서버에서도 사용됩니다. 그 읽기 하루에 수십억 번 이루어집니다. 대량 읽기 요구사항을 처리하는 데는 크게 두 가지 방법이 있습니다.

  • Spanner와 같이 일일 수십억 건의 읽기 작업을 처리할 수 있는 데이터베이스 사용
  • 읽기와 쓰기의 분리. 이 접근 방식은 메타데이터가 자주 변경되지 않기 때문에 가능합니다. 내보내기(2부)에서 이 접근 방식에 대해 자세히 확인할 수 있습니다.

(고유) 사용자 프로필 저장소

이 저장소에는 (고유) 사용자가 들어 있으며 요청 시 캠페인 또는 광고를 선택하기 위한 주요 정보를 제공하는 관련 정보도 들어 있습니다. 정보에는 (고유) 사용자의 속성, 자신의 세그먼트 또는 제3자로부터 가져온 세그먼트가 포함될 수 있습니다. RTB에서 가져온 세그먼트에는 입찰 가격 권장사항이 포함되는 경우가 많습니다.

이 데이터 저장소는 수백 기가바이트(테라바이트 단위의 데이터)를 저장할 수 있어야 합니다. 또한 Datastore는 단일 레코드를 한 자릿수 밀리초 이내의 속도로 검색할 수 있어야 합니다. 저장하는 데이터의 양은 (고유) 사용자 정보의 상세 내역에 따라 다릅니다. 최소한 대상 사용자의 세그먼트 목록을 검색할 수 있어야 합니다.

(고유) 사용자가 광고, 방문 사이트, 실행한 조치 등과 상호작용한 것을 기반으로 저장소가 자주 업데이트됩니다. 정보가 많을수록 타겟팅이 좋습니다. 또한 타사 데이터 관리 플랫폼(DMP)을 사용하여 자사 데이터를 풍부하게 만들 수 있습니다.

Bigtable 또는 Datastore는 (고유) 사용자 데이터에 사용하는 일반적인 데이터베이스입니다. 두 데이터베이스 모두 단일 레코드의 임의 읽기 및 쓰기에 적합합니다. 수백 기가바이트 이상의 데이터가 있는 경우에만 Bigtable 사용을 고려하세요.

MongoDB, Couchbase, Cassandra, Aerospike 등 다른 일반적인 데이터베이스도 Compute Engine 또는 GKE에 설치할 수 있습니다. 이러한 데이터베이스는 종종 더 많은 관리가 필요하지만, 일부는 유연성을 높이고 지연 시간을 줄이며 경우에 따라 리전 간 복제를 제공할 수도 있습니다.

자세한 내용은 사용자 일치(4부)를 참조하세요.

컨텍스트 저장소

컨텍스트 저장소는 흔히 게재 빈도 설정 및 잔여 예산과 같은 카운터를 저장하는 데 사용됩니다. 컨텍스트 저장소에서 얼마나 자주 데이터를 새로 고치는지는 차이가 있습니다. 예를 들어 일일 상한선을 매일 전파할 수 있지만 나머지 캠페인 예산은 최대한 빨리 재 계산하고 전파해야 합니다.

선택한 저장소 패턴, 업데이트하는 카운터 및 선택한 데이터베이스의 기능에 따라 데이터베이스에 직접 쓸 수 있습니다. 또는 계산 후 저장소를 업데이트하기 위해 Pub/Sub와 같은 메시징 시스템에서 게시-구독 패턴을 사용하여 구현을 분리할 수 있습니다.

컨텍스트 저장소에 적합한 후보는 다음과 같습니다.

  • Bigtable
  • 리전 인메모리 키-값 NoSQL 패턴
  • 지역 캐싱 패턴

수평 확장을 사용하면 이러한 저장소가 대규모 쓰기 및 읽기를 처리할 수 있습니다. 광고 서버를 위한 인프라 옵션(3부)RTB 입찰자를 위한 인프라 옵션(4부)에서는 이러한 옵션 중 일부에 대해 더 자세히 설명합니다.

분산 환경에서 예산 카운터를 관리하는 방법의 예

캠페인 관리 도구에서 예산을 설정합니다. 대부분의 경우 광고주는 추가 노출 수에 대해 비용을 지불하지 않으므로 캠페인을 너무 많이 낭비하지 않으려 합니다. 그러나 분산된 환경에서 잔여 예산과 같은 카운터를 집계하는 것은 어려울 수 있습니다. 특히 시스템이 초당 수십만 개의 광고 요청을 받을 수 있는 경우에는 더욱 그렇습니다. 전역 잔여 예산이 빠르게 통합되지 않으면 캠페인이 몇 초 내에 빠르게 초과 지출될 수 있습니다.

기본적으로 근로자는 동료가 얼마를 소비했는지 모른 채 예산을 지출합니다. 의사소통의 부족으로 인해 근로자가 더 이상 사용할 수 없는 돈을 지출하게 될 수 있습니다.

이 문제를 처리할 수 있는 여러 가지 방법이 있습니다. 다음 두 가지 옵션 모두 전역 예산 관리자를 구현하지만 다르게 동작합니다.

  1. 근로자에게 예산 고갈에 대한 알림: 예산 관리자는 지출을 추적하고 캠페인 예산이 소진되면 각 근로자에게 통보 메시지를 보냅니다. 높은 수준의 QPS 가능성으로 인해 과다 지급을 신속하게 제한하려면 1초 내에 알림이 발생해야 합니다. 다음 다이어그램에서 이 프로세스가 어떻게 작동하는지 볼 수 있습니다.

    예산 고갈 알림

  2. 각 작업자에게 반복적으로 예산 분할 할당: 예산 관리자는 전체 잔여 예산을 작은 금액으로 나눠 각 작업자에게 개별적으로 할당합니다. 작업자는 자체 현지 예산을 지출하고, 소진되면 더 많이 요청할 수 있습니다. 이 옵션에는 다음과 같은 몇 가지 장점이 있습니다.

    1. 다시 지출할 수 있으려면 예산 관리자가 작업자에게 새로 금액을 할당할 때까지 기다려야 합니다. 이 방법은 일부 작업자가 잠시 동안 유휴 상태에 있어도 과다 지출을 차단합니다.
    2. 예산 관리자는 각 주기의 작업자 지출 행동을 토대로 각 근로자에게 할당되는 금액을 조정할 수 있습니다. 다음 다이어그램에서 이 프로세스를 볼 수 있습니다.

      예산 관리자가 각 노드에 예산을 할당함

어떤 옵션을 선택하든 예산 카운터는 게시자와 광고주가 합의한 가격 책정 모델을 기반으로 계산됩니다. 예를 들어 모델이 다음과 같은 경우입니다.

  • CPM 기반, 청구 가능 노출은 시스템에 이벤트를 보내 1000회 노출당 설정된 가격을 기준으로 나머지 예산을 줄입니다.
  • CPC 기반, 사용자 클릭은 클릭당 설정된 가격에 따라 잔여 예산을 줄이는 이벤트를 시스템에 보냅니다.
  • CPA 기반, 광고주 속성에 배치된 추적 픽셀은 액션 당 가격을 기준으로 예산을 줄이는 이벤트를 시스템에 보냅니다.

노출 수는 종종 클릭 수보다 몇 배 이상 높습니다. 그리고 클릭 수는 종종 전환보다 수십 배 더 높습니다. 이러한 이벤트를 수집하려면 확장 가능한 이벤트 처리 인프라가 필요합니다. 이 접근 방식은 데이터 파이프라인 도움말에 보다 자세히 설명되어 있습니다.

분석 저장소

분석 저장소는 일일 처리된 테라바이트의 데이터를 오프라인으로 저장하고 처리하는 데 사용되는 데이터베이스입니다. 즉 실시간 프로세싱 중에는 발생하지 않습니다. 예를 들면 다음과 같습니다.

  • (고유) 사용자 데이터는 오프라인으로 처리되어 연관된 세그먼트를 판별한 다음 사용자 프로파일 데이터베이스와 같은 보다 빠른 데이터베이스에 복사하여 제공됩니다. 이 프로세스는 내보내기에 설명되어 있습니다.
  • 컨텍스트 저장소에서 사용되는 오프라인 카운터를 집계하기 위해 노출 및 고유 사용자 작업으로 요청에 참여합니다.

보고/대시보드 저장소

보고/대시보드 저장소는 사용자 프런트엔드에서 사용되며 캠페인 또는 인벤토리 실적이 얼마나 좋은지 정보를 제공합니다. 다양한 보고 유형이 있습니다. 몇 초 또는 실시간으로 업데이트되는 커스텀 분석 기능 및 반 정적 대시보드를 포함하여 일부 또는 전체를 제공할 수 있습니다.

분석 기능으로 BigQuery를 사용할 수 있습니다. 를 활용하여 데이터 액세스를 제한하고 이에 따라 고객과 공유하는 경우 사용자 고유의 UI 또는 자체 시각화 도구를 통해 플랫폼 사용자에게 임시 분석 기능을 제공할 수 있습니다. 모든 회사가 이 옵션을 제공하는 것은 아니지만 고객에게 제공할 수 있는 훌륭한 기회입니다. 이 사용 사례에는 정액제 사용을 고려하세요.

밀리초에서 두 번째 대기 시간으로 고객에게 OLAP 기능을 제공하려면 BigQuery 앞에서 데이터베이스를 사용하는 것이 좋습니다. 보고용 데이터를 집계하여 BigQuery에서 선택한 데이터베이스로 내보낼 수 있습니다. Cloud SQL에서 지원하는 것과 같은 관계형 데이터베이스는 이 용도로 자주 사용됩니다.

App Engine 또는 서비스 계정을 사용하여 사용자 대신 역할을 하는 다른 프런트엔드 때문에 BigQuery는 쿼리가 단일 사용자로부터 오는 것으로 간주합니다. 결과적으로 BigQuery는 일부 쿼리를 캐시하고 이전에 계산된 결과를 더 빨리 반환할 수 있습니다.

또한 반정적 대시 보드가 일반적으로 사용됩니다. 이러한 대시보드는 데이터 파이프라인 프로세스로 작성된 사전 집계된 KPI를 사용합니다. 저장소는 더 간편한 실시간 업데이트를 지원하는 Firestore 또는 Memorystore와 같은 캐싱 레이어 등 NoSQL 기반일 가능성이 높습니다. 데이터의 신선도는 대개 업데이트 빈도와 데이터 집계에 사용된 기간에 따라 다릅니다.

다음 단계