Opciones de infraestructura para entregar cargas de trabajo de publicidad (Parte 1)

En este artículo, se explican los componentes que se comparten entre las plataformas de tecnología de anuncios, incluidos los servidores y los ofertantes. El artículo te ofrece opciones para implementar esos componentes.

Por lo general, los ofertantes y servidores de anuncios son plataformas complementarias con tecnología que se superpone. Para evitar duplicar contenido, este artículo y la sección complementaria, parte 2, proporcionan el contexto necesario para las series:

Para obtener una mejor descripción general de la serie entera y de la terminología que se usa, consulta Compila plataformas publicitarias (descripción general).

Consideraciones de la plataforma

Cuando trabajas tanto con la parte de compras como de ventas de las plataformas, ten en cuenta lo siguiente:

  • Plataforma Compute: Las plataformas de publicidad programáticas constituyen varios servicios, y cada servicio ofrece una o más funciones. Decide de manera temprana organizar en contenedores algunas de estas funciones o todas, o si el servicio se debe ejecutar directamente en instancias de máquina virtual (VM).
  • Ubicaciones geográficas: Implementar la infraestructura cerca de los clientes y proveedores ayuda a reducir la latencia de herramientas de redes.
  • Reproducibilidad: Cuando replicas un sistema en diferentes regiones del mundo, la capacidad de implementar de manera consistente la misma infraestructura proporciona coherencia entre las plataformas.
  • Balanceo de cargas: Una máquina sola no puede manejar cargas de ad-tech. Distribuye solicitudes internas y externas a través de varios servidores.
  • Ajuste de escala automático: Las cargas de solicitud de anuncios varían durante el día. Puedes reducir costos y aumentar la disponibilidad si ajustas el escalamiento de tu sistema automáticamente.
  • Comunicación en red: Con un sistema distribuido, llegan las preguntas sobre comunicación. Por ejemplo, imagina que estás ofertando en Oregón, pero tu base de datos de administración de campañas está en Europa. Incluso si la comunicación consiste en la sincronización sin conexión, es probable que no quieras comunicarte de manera pública en Internet

Plataforma de Compute

Google Cloud ofrece varias opciones para ejecutar tus cargas de trabajo de procesamiento. Considera las opciones siguientes:

  • App Engine para ejecutar una interfaz de usuario web (IU) sin muchas de las sobrecargas operativas
  • Compute Engine para la instalación y la administración de algunas bases de datos relacionales o códigos personalizados no compatibles con App Engine
  • Google Kubernetes Engine (GKE) para establecer frontends sin estado o ejecutar aplicaciones en contenedores

Estas opciones son recomendaciones y generalmente se pueden intercambiar. Por último, tus requisitos son el factor decisivo, ya sea que el factor sea costo, sobrecarga operativa o rendimiento.

Compute Engine y GKE son compatibles con VM interrumpibles, que a menudo se usan en cargas de trabajo de tecnología publicitaria para ahorrar costos. Sin embargo, las VM interrumpibles pueden ser interrumpidas solo con una advertencia de un minuto. Por esta razón, se recomienda lo siguiente:

  • Si usas Compute Engine, dos grupos de instancias administrados diferentes (uno interrumpible y el otro con VM estándar) pueden residir detrás del mismo balanceador de cargas. Si te aseguras de que un grupo consiste en VM estándares, garantizas que tu frontend siempre esté disponible para manejar solicitudes entrantes. En el siguiente diagrama, se muestra este enfoque.

    dos grupos de instancias administrados diferentes en el mismo balanceador de cargas

  • Si usas GKE, puedes mitigar costos con disponibilidad mediante la creación de grupos de nodos interrumpibles y no interrumpibles en tu clúster de GKE.

Ubicaciones geográficas

Es posible que los anunciantes deseen alcanzar clientes de todo el mundo. Si agregas algunos milisegundos adicionales a uno de los frontends de IU de la plataforma, no disminuirá la experiencia de tus anunciantes, por ejemplo, cuando visualizan los datos de rendimiento. No obstante, ten cuidado si la distancia de herramientas de redes adicionales agrega algunos milisegundos más a la respuesta de la oferta. Esos pocos milisegundos podrían ser la diferencia entre la aceptación de las ofertas de los anunciantes y la entrega de los anuncios al cliente.

Google Cloud tiene presencia en varias regiones, incluidas us-east, us-west, europe-west, asia-southeast y asia-east. Cada región incluye varias zonas para ofrecer gran disponibilidad y escalamiento.

Si la latencia es crítica, te recomendamos distribuir algunos de tus servicios en esas zonas en diferentes regiones. Puedes personalizar tu configuración según tus necesidades. Por ejemplo, puedes optar por tener algunos servidores de frontend en us-east4 y us-west1, pero tener datos almacenados en una base de datos en us-central. En ciertos casos, puedes replicar algunos de los datos de la base de datos de manera local en los servidores de frontend. Como alternativa, puedes considerar usar una instancia de Cloud Spanner multirregional.

Reproducibilidad

La reproducibilidad ofrece implementación y mantenimiento más simple, y que la plataforma se ejecute en todas las ubicaciones geográficas relevantes es clave para mostrar ofertas antes de la fecha límite crítica. Para asegurar la reproducibilidad, cada región debe realizar el mismo trabajo. La principal diferencia es la carga de trabajo y cuántas máquinas y zonas se necesitan para escalar y, así, satisfacer la demanda de la región.

Con Compute Engine, las plantillas de instancias son la base para configurar grupos de instancias administrados regionales similares. Estos grupos se pueden ubicar en regiones diferentes por proximidad al SSP y pueden intercalar varias zonas para mayor disponibilidad. En el diagrama siguiente, se puede ver cómo funciona este proceso.

Usa una plantilla de instancias para configurar grupos de instancias administrados regionales

Los contenedores ofrecen un nivel mayor de abstracción que la virtualización de máquinas. Kubernetes facilita la reproducibilidad de la aplicación de manera nativa mediante los archivos de configuración YAML que pueden definir pods, servicios y, también, implementaciones con coherencia en diferentes clústeres.

Balanceo de cargas

Se requiere el balanceo de cargas en dos situaciones principales:

Si decides usar Kubernetes para algunas partes de la infraestructura, recomendamos que uses GKE. Algunas características de Kubernetes pueden requerir implementación adicional si no son compatibles con tu proveedor de manera nativa. Con GKE, Kubernetes puede usar características de Google Cloud nativas:

GKE también es compatible con el balanceo de cargas nativo del contenedor con el fin de reducir el tiempo de la red y sus posibles saltos adicionales. A mayor escala, el balanceador de cargas evita que una solicitud se enrute a una instancia que no aloja un pod del servicio solicitado.

Escalamiento

Ya que tu plataforma debe poder analizar y calcular miles de millones de solicitudes de anuncios por día, el balanceo de cargas no puede faltar. Además, una sola máquina no sería adecuada para esta tarea. Sin embargo, la cantidad de solicitudes tiende a cambiar durante el día, lo que significa que tu infraestructura debe poder ajustar el escalamiento vertical según la demanda.

Si decides usar Compute Engine, puedes crear grupos de instancias administrados de ajuste de escala automático desde plantillas de instancias. Luego, puedes escalar esos grupos en diferentes métricas, como carga HTTP, CPU y métricas personalizadas de Cloud Monitoring, como la latencia de la aplicación. También puedes escalar estos grupos en una combinación de estas métricas.

Las decisiones de ajuste de escala automático se toman cada minuto con una ventana diapositiva y tienen base en la métrica promedio de los últimos diez minutos. Cada grupo de instancias puede tener su propio conjunto de reglas de escalamiento.

Si decides usar GKE, el escalador automático del clúster de Kubernetes, puedes implementarlo de manera nativa con el escalador automático del clúster de GKE. El escalador automático de clúster de GKE se comporta diferente al escalador automático de Compute Engine y también inicia nodos nuevos cuando los pods nuevos no se pueden programar más en los nodos existentes debido a una escasez de CPU o memoria en los nodos subyacentes. El escalamiento disminuye automáticamente cuando la CPU o la memoria se actualizan nuevamente.

Comunicación de red

Las nubes privadas virtuales (VPC) pueden abarcar varias regiones. Es decir, si tienes réplicas de lectura de base de datos en us-east y una base de datos principal en asia-southeast dentro de la misma VPC, estas se pueden comunicar de manera segura con sus IP privadas o nombres de host sin salir de la Red de Google.

En el diagrama siguiente, todas las instancias están en la misma VPC y se pueden comunicar directamente sin la necesidad de una VPN, incluso si están en diferentes regiones.

Todas las instancias están en la misma VPC y en diferentes regiones

A los clúster de GKE se les asigna una VPC cuando se crean y pueden usar varias de esas características de red existentes.

Google también ofrece dos tipos de infraestructura de red:

  • Premium: Usa la red privada global de Google. Prioriza esta opción para cargas de trabajo críticas, como la replicación de base de datos entre regiones.
  • Estándar: Prioriza esta opción si te preocupan los precios y puedes usar la Internet pública.

Cuando usas productos administrados, como Cloud Bigtable, Cloud Storage o BigQuery, Google Cloud proporciona acceso privado a estos productos a través de VPC.

Frontend de usuario

Tu usuario de frontend es importante, pero requiere la menor sobrecarga técnica, ya que controla cargas de trabajo mucho menores. El frontend de usuario ofrece a los usuarios de la plataforma la capacidad de administrar recursos de publicidad, como campañas, creatividad, ofertas o facturación. El frontend también brinda la capacidad de interactuar con las herramientas de informes, por ejemplo, para supervisar el rendimiento de los anuncios o campañas.

Ambas características requieren servicio web para proporcionar una IU al usuario de la plataforma, y almacén de datos con el fin de almacenar datos analíticos o transaccionales.

Servicio web

Es posible que tu frontend de publicidad necesite:

  • Ofrecer disponibilidad alta
  • Controlar cientos de solicitudes por segundo
  • Estar disponible de manera global a una latencia aceptable para ofrecer una experiencia del usuario satisfactoria
  • Proporcionar una IU

Es posible que tu interfaz incluya funcionalidades como un panel y páginas para configurar anunciantes, campañas y los componentes relacionados. El diseño de la IU es una disciplina aparte y está fuera del alcance de este artículo.

Para minimizar la sobrecarga técnica, recomendamos usar App Engine como una plataforma de frontend. Esto te ayudará a reducir el tiempo que empleas en administrar la infraestructura de tu sitio web. Si necesitas un entorno de ejecución personalizado, considera usar Entornos de ejecución personalizados. De manera alternativa, puedes usar GKE o Compute Engine si la pila de tu aplicación preferida tiene otros requisitos.

Almacenes de datos

Existen dos tipos de almacenes de datos en frontends de usuarios:

  • Almacenes de datos de administración que requieren bases de datos de procesamiento de transacción en línea (OLTP). Las opciones se detallan en la sección almacén de administración de metadatos.
  • Almacenes de datos de informes que requieren bases de datos de procesamiento analítico en línea (OLAP). Las opciones se detallan en la sección almacén de paneles/informes.

Cómo controlar solicitudes

Frontends

Para ser procesadas, las solicitudes se envían a un extremo HTTP(S) que proporciona tu plataforma. Los componentes clave son los siguientes:

  • Un balanceador de cargas capaz de procesar cientos de miles de QPS.
  • Un grupo de instancias que puede ajustar el escalamiento rápidamente según varios KPI.
  • Una API que pueda regular o autenticar al extremo.

Tanto Compute Engine como GKE son buenas opciones como plataformas de computación:

  • Compute Engine usa Cloud Load Balancing y grupos de instancias administrados que se mencionan en la sección escalamiento.
  • GKE usa Ingress (o puerta de enlace de Istio Ingress), Cloud Load Balancing, el escalador automático de pod horizontal y el escalador automático del clúster.

Como el escalamiento de pod es más rápido que el escalamiento de nodo, GKE puede ofrecer ajuste de escala automático más rápido a nivel de cada servicio. GKE también es compatible con el balanceo de cargas nativo del contenedor para optimizar solicitudes que se enrutan directamente a una instancia que aloja un pod del servicio relevante.

La regulación y autenticación se pueden administrar con tecnologías como Apigee o la infraestructura de servicios.

Análisis

Normalmente, las solicitudes de anuncio se formatean en formato protobuf o JSON con información como dirección IP, usuario-agente y categoría de sitio. Es crucial que se extraiga esta información, que también puede contener detalles del usuario (único), para luego recuperar los segmentos que seleccionarán y filtrarán anuncios.

Filtro estático

Algunas solicitudes, que típicamente reciben los compradores, se pueden descartar con el uso de reglas estáticas. Este filtrado temprano puede reducir la cantidad de datos y el procesamiento complejo que se necesita luego.

Las reglas pueden ser listas negras de publicador o exclusiones de tipos de contenido. Durante la inicialización, los trabajadores pueden extraer y cargar estas reglas desde un archivo alojado en Cloud Storage.

Selección de anuncios

La selección de anuncios se puede realizar en los diferentes servicios o plataformas, incluidos el servidor de anuncios del publicador, el servidor de anuncios del anunciante o la DSP. Existen niveles de complejidad diferentes cuando se selecciona un anuncio:

  • Algunas selecciones pueden ser tan simples como seleccionar un anuncio para una categoría específica de la página o sitio web del publicador. En este caso, los precios no difieren por anuncio.
  • Las selecciones más avanzadas incorporan segmentos y atributos de usuario que pueden involucrar sistemas de recomendaciones de anuncios basadas en aprendizaje automático.
  • Los sistemas RTB suelen tomar las decisiones más complejas. Los anuncios se seleccionan según atributos, como segmento de usuario (único) y precios de ofertas anteriores. Esta selección también incluye un cálculo de ofertas para optimizar el precio de la oferta a nivel de la solicitud.

Seleccionar el anuncio relevante es la función principal de tu sistema. Tienes que considerar varios factores, incluidos algoritmos de AA o basados en reglas avanzadas. Sin embargo, este artículo continúa enfocándose en el proceso de alto nivel y las interacciones con los diferentes almacenes de datos.

El proceso de selección de anuncios consiste en los pasos siguientes:

  1. Recuperar los segmentos asociados con el usuario objetivo desde el almacén de perfil de usuario (único)
  2. Seleccionar las campañas o anuncios que condicen con los segmentos del usuario En esta selección, se exige la lectura de metadatos del almacén de administración de metadatos, que es la razón por la que este almacén solicita que implementes uno de los patrones de almacenamiento con alto contenido de lectura.
  3. Filtrar las campañas o los anuncios seleccionados que concuerden con las métricas. Por ejemplo: el presupuesto restante almacenado en uno de los almacenes de contexto
  4. Seleccionar el anuncio

Los ofertantes tienen más pasos relacionados con las ofertas y subastas, y requisitos de latencia más complejos. Para obtener más detalles acerca de los requisitos de ofertante durante la selección de anuncios, consulta Opciones de infraestructura para ofertantes de RTB (Parte 4).

Patrones de almacenamiento con alto contenido de lectura

La mayoría de las decisiones que se toman cuando se selecciona un anuncio requieren datos inteligentes que:

  • Se lean en milisegundo, a veces submilisegundos.
  • Se escriban lo antes posible, especialmente para contadores que no pueden esperar.
  • Normalmente, se escriban como parte de un proceso sin conexión que usa tareas de aprendizaje automático o analíticas en segundo plano.

El modo en que seleccionas tu almacén de datos depende de cómo priorizas los requisitos a continuación:

  • Minimización de latencias de escritura o lectura: Si la latencia es crítica, necesitas un almacén cercano a tus servidores y que también pueda controlar escrituras o lecturas rápidas a gran escala.
  • Minimización de sobrecarga operativa: Si tienes un equipo de ingeniería pequeño, puedes necesitar una base de datos completamente administrada.
  • Escalamiento: Para admitir millones de usuarios objetivo o miles de millones de eventos por día, el almacén de datos debe escalar de manera horizontal.
  • Adaptación al estilo de consultas: Algunas consultas pueden usar una clave específica, mientras que otras puedan necesitar recuperar registros que cumplan con un conjunto de condiciones diferente. En algunos casos, los datos de consulta se pueden codificar en la clave. En otros casos, las consultas necesitan capacidades del tipo SQL.
  • Maximización de la actualización de datos: Algunos contadores, como el presupuesto, se deben actualizar lo más rápido posible. Otros datos como el segmento de público o los contadores (por ejemplo, límites diarios) se pueden actualizar con posterioridad.
  • Minimización de costos: Es posible que no siempre sea económico o práctico controlar miles de millones de lecturas y escrituras con coherencia sólida globalmente en una base de datos única para minimizar las operaciones de desarrollo.

Existen diferentes opciones para tratar requisitos con alto contenido de lectura. Esto incluye réplicas de lectura, sistemas de almacenamiento en caché, bases de datos NoSQL en la memoria y bases de datos NoSQL de columnas amplias.

Réplicas de lectura de RDBMS

Si usas Cloud SQL (o un RDBMS equivalente instalado y administrado en Compute Engine), puedes aliviar la carga de las operaciones de lectura desde una instancia maestra. Muchas bases de datos son compatibles con esta característica de manera nativa. Para consultar por más información, los trabajadores deben:

  • Usar réplicas de lectura que coincidan con la cantidad de trabajadores.
  • Usar un proxy de agrupación.

En el diagrama siguiente, se puede ver cómo funciona este proceso.

Base de datos en la que las operaciones de lectura se descargan desde una instancia principal

Se designan réplicas de lectura para entregar tráfico de alto contenido de lectura, pero la escalabilidad no es lineal y el rendimiento puede verse afectado por una cantidad mayor de réplicas. Si necesitas escrituras o lecturas que puedan escalar, que tengan coherencia global y una sobrecarga operativa mínima, considera usar Cloud Spanner.

Capa de almacenamiento en caché local

Puedes usar una capa de almacenamiento en caché como Redis en Compute Engine con réplicas locales opcionales en los trabajadores. Esta capa puede minimizar en gran medida la latencia en la lectura y las herramientas de red. En el diagrama siguiente, se puede ver cómo funciona esta capa.

Minimizar la latencia mediante el aprovechamiento de capas de almacenamiento en caché

Si decides usar Kubernetes en este caso, consulta DaemonSet y la afinidad para asegurarte de lo que se menciona a continuación:

  • Tú limitas la cantidad de datos replicados.
  • Los datos permanecen cercanos a un pod servidor.

NoSQL de clave-valor en la memoria

Implementa una base de datos en la memoria, como Aerospike o Redis, para proporcionar lecturas rápidas a gran escala. Esta solución puede ser útil para contadores y datos regionales. Si te preocupa el tamaño de las estructuras de datos almacenadas, también puedes aprovechar las bases de datos en la memoria que pueden escribir en discos SSD. En el diagrama a continuación, se muestra cómo es esta solución.

Una base de datos en la memoria que puede realizar operaciones de escritura en discos SSD

NoSQL de columna amplia administrada

Las bases de datos de columnas amplias son almacenes de clave-valor que pueden ofrecer escrituras y lecturas rápidas a gran escala. Puedes instalar una base de datos de código abierto común, como Cassandra o HBase.

Si decides usar ese almacén, recomendamos también usar Bigtable para minimizar la sobrecarga operativa. Estos almacenes te permiten escalar tus operaciones de entrada y salida (IOPS) de manera lineal a la cantidad de nodos. Con un diseño clave adecuado, los selectores de anuncios pueden leer y la canalización de datos puede escribir a velocidades de milisegundos de un solo dígito en un primer byte de petabytes de datos. En el diagrama siguiente, se puede ver cómo funciona este proceso.

Almacenes de datos de columna amplia

Almacenamiento estático de objetos

En el caso de datos estáticos que se pueden guardar en formato protobuf, AVRO o JSON, los trabajadores pueden cargar desde Cloud Storage durante la inicialización y conservar el contenido en RAM. En el diagrama siguiente, se puede ver cómo funciona este proceso.

Carga datos desde Cloud Storage

No existe una solución que satisfaga todas las necesidades. Elige entre las soluciones que se basan en tus prioridades y haz un balance entre latencia, costos, operaciones, rendimiento de escritura y lectura, y tamaño de los datos.

Solución Latencia Costo Sobrecarga operativa Rendimiento de escritura y lectura Tamaño de los datos
Réplicas de lectura de RDBMS milisegundos Basado en computadora o servicio Alta Limitado Limitado
Cloud Spanner milisegundos Basado en servicio Baja Escala lineal a la cantidad de nodos Petabytes
Almacenes en la memoria submilisegundos Basado en computadora Alta Escala con la cantidad de nodos Escala con la cantidad de nodos
Cloud Bigtable milisegundos de un solo dígito Basado en servicio Baja Escala lineal a la cantidad de nodos Petabytes

Almacenes de datos de publicidad

Esta sección abarca las opciones de almacenamiento de datos que atienden una de tres situaciones diferentes:

  • A los almacenes de entrega de anuncios lo usan servicios que se involucran en la selección de anuncios. Entregar cargas de trabajo requiere una latencia baja y la capacidad de controlar miles de millones de lecturas por día. El tamaño de los datos depende del tipo de datos.
  • Los almacenes de estadísticas se usan sin conexión mediante consultas ad hoc o canalizaciones de datos en lote. Admiten cientos de terabytes de datos almacenados a diario.
  • Los almacenes de panel/informes se pueden usar para paneles prefabricados, series temporales o informes personalizados. Estas opciones diferencian tu frontend, ya que permite que los usuarios de tu plataforma obtengan estadísticas con rapidez y visualicen cómo está rindiendo su negocio.

Los almacenes de servicio de anuncios se pueden desglosar aún más de la siguiente manera:

Almacén de administración de metadatos

El almacén de administración de metadatos contiene los datos de referencia a los que les aplicas reglas cuando realizas una selección de anuncios. Algunos recursos almacenados aquí son específicos a una plataforma, pero otros se pueden superponer.

  • Para un servidor de anuncios del lado del comprador, los publicadores administran datos sobre campañas, creatividades, anunciantes, disponibilidad de anuncios y precios. Algunos frontends también pueden dar acceso a sus compradores.
  • Para un servidor de anuncios del lado del vendedor, los compradores administran datos sobre campañas, creatividades, anunciantes y precios. Los anunciantes pueden actualizar estos datos a menudo mediante una IU.
  • En caso de una DSP, los administradores administran datos sobre campañas, creatividades, anunciantes y precios de oferta. Los anunciantes pueden actualizar los datos a menudo mediante una IU.

El almacén de metadatos contiene datos semiestáticos jerárquicos o relacionales:

  • Las escrituras son el resultado de las ediciones de usuario de plataforma mediante el frontend y no suceden frecuentemente.
  • Los datos se leen miles de millones de veces por día mediante los servidores de selección de anuncios.

Si se enfoca en el frontend de usuario, la base de datos de metadatos de campaña debe poder administrar jerarquías y relaciones de recursos y almacenar megabytes en unos pocos gigabytes de datos. La base de datos también debe proporcionar operaciones de lectura y escritura en el rango de cientos de QPS. Para cumplir estos requisitos, Google Cloud ofrece varias opciones de bases de datos, administradas y no administradas:

  • Cloud SQL: Un servicio de base de datos completamente administrado que puede ejecutar MySQL o PostgreSQL.
  • Datastore: Un servicio de base de datos NoSQL altamente escalable, administrado y distribuido. Admite transacciones ACID, ofrece un lenguaje de consultas de tipo SQL y tiene niveles de coherencia eventual y sólida.
  • Spanner: Una base de datos relacional escalable de forma horizontal que proporciona operaciones de lectura coherentes y sólidas, transacciones globales y replicaciones entre regiones. Puede controlar operaciones de escritura y lectura complejas.
  • Personalización: También puedes instalar y administrar muchas de las bases de datos de propietario o código abierto (como MySQL, PostgreSQL, MongoDB o Couchbase) en Compute Engine o GKE.

Tus requisitos pueden ayudar a limitar las opciones, pero a mayor nivel puedes usar Cloud SQL debido a su compatibilidad con datos relacionales. Cloud SQL también administra y proporciona opciones de réplica de lectura.

Como se mencionó antes, al almacén de metadatos no solo lo usan los usuarios de plataformas para informar o administrar, sino que también lo usan los servidores que seleccionan anuncios. Esas lecturas suceden miles de millones de veces al día. Existen dos maneras principales de abordar esos requisitos de alto contenido de lectura:

  • Con bases de datos que manejen operaciones de escritura coherentes de manera global y miles de millones de operaciones de lectura por día, como Spanner
  • Mediante la separación de operaciones de escritura y lectura. Este enfoque es posible, ya que los metadatos no se cambian de manera frecuente. Puedes leer más acerca de este alcance en exportaciones (en la Parte 2).

Almacén de perfil de usuario (único)

Este almacén contiene usuarios (únicos) y su información asociada que ofrece estadísticas clave para seleccionar una campaña o anuncio mediante solicitud. La información puede incluir los atributos de usuario (único), tus propios segmentos o los segmentos importados de terceros. En RTB, los segmentos importados suelen incluir recomendaciones de precio para ofertas.

Este almacén de datos debe poder almacenar cientos de gigabytes y, posiblemente, terabytes de datos. El almacén de datos también debe poder recuperar registros únicos en velocidades de milisegundos de un solo dígito como mucho. La cantidad de datos que almacenas depende de lo detallada que sea tu información de usuario (única). Como mínimo, debes poder recuperar una lista de segmentos para el usuario objetivo.

El almacén se actualiza con frecuencia según la interacción del usuario (único) con los anuncios, los sitios que visita o las acciones que realiza. Cuanta más información, mejor se llegará al objetivo. También puedes usar plataformas de administración de datos de terceros (DMP) para enriquecer los datos de origen.

Bigtable y Datastore son bases de datos comunes para usar en datos del usuario (únicos). Ambas bases de datos son adecuadas para las operaciones de escritura y lectura aleatorias de registros únicos. Considera usar Bigtable solo si tienes al menos cientos de gigabytes de datos.

Otras bases de datos comunes, como MongoDB, Couchbase, Cassandra o Aerospike, también se pueden instalar en Compute Engine o GKE. Aunque es usual que estas bases de datos requieran más administración, algunas ofrecen mayor flexibilidad, la posibilidad de obtener una latencia más baja y, en algunos casos, replicaciones entre regiones.

Para obtener más detalles, consulta coincidencia de usuario (en la parte 4).

Almacenes de contexto

El almacén de contexto se suele usar para almacenar contadores, como límites de frecuencia y presupuesto restante. La frecuencia con la que se actualizan los datos en el almacén de contexto varía. Por ejemplo: un límite diario se puede propagar a diario, mientras que el presupuesto de campaña restante requiere que se vuelva a calcular y propagar lo antes posible.

Según el patrón de almacenamiento que elijas, los contadores que actualizas y las capacidades de las bases de datos que seleccionaste, puedes escribir directamente en tu base de datos. También se recomienda separar la implementación mediante el uso de un patrón de publicación y suscripción con un sistema de mensajería, como Pub/Sub, a fin de actualizar el almacén luego del cálculo.

Los siguientes son candidatos adecuados para los almacenes de contexto:

  • Bigtable
  • El patrón NoSQL clave-valor en la memoria regional
  • El patrón de almacenamiento en caché regional

Si se usa escalamiento horizontal, estos almacenes pueden controlar escrituras y lecturas a gran escala. En Opciones de infraestructura para servidores de anuncios (Parte 3) y en Opciones de infraestructura para ofertantes de RTB (Parte 4), se abordan algunas de estas opciones en más detalle.

Ejemplo de cómo administrar un contador de presupuesto en un entorno distribuido

Estableces presupuestos en la herramienta de administración de la campaña. No quieres que tus campañas se excedan en gastos, ya que, la mayor parte del tiempo, los anunciantes no pagarán por esas impresiones adicionales. Sin embargo, en un entorno distribuido puede ser difícil agregar contadores como el presupuesto restante, especialmente cuando el sistema puede recibir cientos de miles de solicitudes de anuncios por segundo. Las campañas pueden gastar en exceso en unos pocos segundos si el presupuesto restante global no se consolida rápidamente.

De manera predeterminada, un trabajador invierte segmentos del presupuesto sin saber cuánto invierten trabajadores del mismo nivel. La falta de comunicación puede llevar a una situación en la que el trabajador gasta dinero que ya no está disponible.

Existen diferentes maneras de controlar este problema. Las dos opciones a continuación implementan un administrador de presupuesto global, pero se comportan de manera diferente.

  1. Notificación a los trabajadores sobre el agotamiento del presupuesto: El administrador de presupuesto rastrea gastos y emite notificaciones a cada uno de los trabajadores cuando el presupuesto de la campaña se agotó. Debido a que existe una posibilidad de niveles altos de QPS, las notificaciones suelen suceder al segundo para, de esta forma, limitar rápidamente el exceso de gastos. En el diagrama siguiente, se puede ver cómo funciona este proceso.

    Notificación de agotamiento de presupuesto

  2. Asignación de segmentos de presupuesto de manera recurrente a cada trabajador: El administrador de presupuesto divide todo el presupuesto restante en cantidades más pequeñas que se asignan a cada uno de los trabajadores de manera individual. Los trabajadores gastan su propio presupuesto local y, cuando se agota, pueden solicitar más. Esta opción tiene algunas ventajas:

    1. Antes de poder invertir nuevamente, los trabajadores deben esperar a que el administrador de presupuesto les asigne una cantidad nueva. Este enfoque evita que se excedan los gastos incluso si los trabajadores permanecen inactivos por un tiempo.
    2. El administrador de presupuesto puede adaptar la cantidad asignada enviada a cada trabajador según el comportamiento de gastos del trabajador en cada ciclo. En el diagrama a continuación, se muestra este proceso.

      El administrador de presupuesto asigna presupuesto a cada nodo

Cualquiera sea la opción que elijas, los contadores de presupuesto se calculan según el modelo de precios acordado entre el publicador y el anunciante. Por ejemplo, si el modelo es:

  • basado en CPM, una impresión facturable envía un evento al sistema que reduce el presupuesto restante según el precio establecido cada mil impresiones.
  • basado en CPC, el clic de un usuario envía un evento al sistema que reduce el presupuesto restante según el precio establecido por clic.
  • basado en CPA, un píxel de seguimiento ubicado en la propiedad del anunciante envía un evento al sistema que reduce el presupuesto según el precio por acción.

La cantidad de impresiones suele ser mayor en magnitud que los clics. Y la cantidad de clics suele ser más grande en magnitud que las conversiones. La transferencia de estos eventos requiere una infraestructura de procesamiento de eventos escalable. Este enfoque se abarca en más detalle en el artículo canalización de datos.

Almacén analítico

El almacén analítico es una base de datos que se usa para almacenar y procesar terabytes de datos transferidos a diario sin conexión. Es decir, no durante el procesamiento en tiempo real. Por ejemplo:

  • Los datos del usuario (único) se procesan sin conexión para determinar los segmentos asociados que, a cambio, se copian en bases de datos (como la base de datos de perfil del usuario) más rápida para la entrega. Este proceso se explica en exportaciones.
  • La unión de solicitudes con impresiones y acciones de usuario (único) para agregar contadores sin conexión que se usan en un almacén de contexto.

Almacén de informes y paneles

El almacén de informes y paneles se usa en el frontend de usuario y ofrece estadísticas acerca del rendimiento de las campañas o los inventarios. Existen diferentes tipos de informes. Recomendamos ofrecer algunos o todos, incluidas las capacidades de estadísticas personalizadas y los paneles semiestáticos actualizados cada varios segundos o en tiempo real.

Puedes usar BigQuery para las capacidades de estadísticas. Si aprovechas las vistas para limitar el acceso de datos y compartirlos como corresponde con tus clientes, puedes brindar a los usuarios de tu plataforma capacidades analíticas ad hoc mediante tu propia IU o sus propias herramientas de visualización. No todas las empresas ofrecen esta opción, pero es un gran adicional para poder ofrecer a tus clientes. Considera usar precios de tasa fija para este caso práctico.

Si deseas ofrecer capacidades de OLAP a tus clientes con latencia de milisegundo a segundo, considera usar una base de datos delante de BigQuery. Puedes agregar datos para informar y exportarla desde BigQuery a la base de datos seleccionada. Las bases de datos relacionales, como las compatibles con Cloud SQL, suelen usarse con este fin.

Debido a que App Engine o cualquier otro frontend actúan en nombre del usuario mediante una cuenta de servicio, BigQuery considera que las consultas provienen de un solo usuario. El resultado es que BigQuery puede almacenar en caché algunas consultas y mostrar resultados calculados antes de manera más rápida.

Los paneles semiestáticos también se usan con regularidad. Estos paneles usan KPI agregados previamente y escritos mediante un proceso de canalización de datos. Es muy probable que los almacenes sean NoSQL, como Firestore para actualizaciones en tiempo real más fáciles o capas de almacenamiento en caché como Memorystore. Por lo general, la actualidad de los datos depende de la frecuencia de las actualizaciones y duración del período que se usa para agregar tus datos.

Próximos pasos