En el mundo del audio programático, 101 ms significa cero ingresos. No es un problema de rendimiento, sino de existencia.  Operamos un DSP de publicidad de audio que procesa aproximadamente   Cada solicitud debe recibirse, evaluarse y responderse en menos de   Si se pierde ese plazo, la oferta se cancela. Con 101 ms, prácticamente no existimos. 350 millones de solicitudes al día, es decir, unos 2 mil millones a la semana. 100 milisegundos.  Lo hacemos con un equipo de ingeniería de tres personas y una factura de nube que se mantiene por debajo de los $10,000 al mes. El mismo equipo es responsable de todo: la infraestructura del licitador, la capa de aplicación, las bases de datos y las operaciones.   El ecosistema RTB  Si no estás familiarizado con la tecnología publicitaria, aquí tienes la versión resumida: la publicidad programática se ejecuta mediante pujas en tiempo real (RTB).  En el lado de la oferta se encuentran   . Se trata de plataformas como AdsWizz o Triton que agregan inventario publicitario de miles de aplicaciones y editores: reproductores de podcast, aplicaciones de streaming y otras plataformas de audio. las plataformas SSP (Supply-Side Platforms)  Del lado de la demanda están   sistemas como el nuestro que representan a los anunciantes y deciden, en tiempo real, si ofertan por una impresión determinada. las DSP (Demand-Side Platforms),  Cuando un oyente abre una aplicación de podcast y hay un espacio publicitario disponible, la aplicación se comunica con su SSP. Este envía solicitudes de puja a múltiples DSP. Nuestro sistema recibe la solicitud, evalúa al usuario y las campañas activas, calcula el precio de la puja y envía una respuesta. Todo esto debe suceder en menos de 100 ms, de principio a fin.  La latencia no es solo una métrica. Es el producto.  Una vez que aceptamos eso, era obvio que los patrones estándar de aplicaciones web no funcionarían. No podíamos permitirnos saltos de red entre microservicios, y definitivamente no podíamos afrontar la factura de la nube que conlleva una configuración de Kubernetes extensa. Para sobrevivir, primero tuvimos que diseñar teniendo en cuenta las limitaciones.  Esa restricción no era teórica. Al principio, cuando aún teníamos créditos en la nube, no nos preocupábamos mucho por la eficiencia. Una vez que se agotaron, cada decisión arquitectónica tuvo un coste real. Fue entonces cuando tuvimos que dar un paso atrás y rediseñar el sistema para optimizar la latencia, el coste y la simplicidad operativa.  Lo que sigue es la arquitectura que permite a un equipo de tres personas ejecutar un sistema RTB global a escala, sin gastar dinero ni perder el sueño.  1. La geografía como primer filtro: diseño para la física de redes  Los principales SSP de audio con los que nos integramos (   se encuentran alojados en EE. UU., Europa y el Sudeste Asiático. Nuestra capa de aplicación, que gestiona la lógica de las campañas para los anunciantes de India, se encuentra en India. Triton, AdsWizz, Magnite (anteriormente Rubicon) y MCTV)  El viaje de ida y vuelta de la red entre estas regiones solo dura unos   , incluso antes de que se ejecute la lógica de la aplicación. Esto ya nos supera con creces el presupuesto permitido. 240 milisegundos  La solución fue sencilla, pero innegociable. Implementamos nuestros clústeres de pujas en   : EE. UU. Oeste (Oregón), UE Central (Fráncfort) y Asia Pacífico (Singapur y Hong Kong). cuatro regiones estratégicas de AWS  Esto garantiza que cuando un SSP envía una solicitud de oferta, nuestra distancia al metal es insignificante (normalmente milisegundos de un solo dígito), lo que deja la mayor parte del presupuesto de 100 ms para el cómputo real.  2. El híbrido monolito-microservicio   Logramos una arquitectura que se sitúa a medio camino entre un monolito tradicional y una configuración de microservicios. En lugar de distribuir los servicios por la red, ubicamos un   y luego escalamos esas máquinas virtuales horizontalmente mediante un balanceador de carga global. pequeño clúster de servicios estrechamente acoplados en una sola máquina virtual  Dentro de cada VM (tratada como un nodo único) parece un sistema distribuido en miniatura:    : un único contenedor de ingreso que actúa como policía de tráfico interno. Nginx    : 3 a 5 réplicas del servicio de pujas Node.js ejecutándose en la misma máquina para utilizar completamente la CPU. Postor    : una instancia local de Redis que se ejecuta junto con el código. Redis  La recompensa es la localización de datos por defecto. El postor no cruza la red para obtener datos; los lee desde el host local. Esto también nos permite aumentar considerablemente   . Al usar máquinas virtuales más grandes (por ejemplo, c6i.xlarge) y compartir un único conjunto de datos en memoria entre varios trabajadores, obtenemos una relación RAM-CPU mucho mejor, lo que minimiza el desperdicio y maximiza el rendimiento. la densidad de recursos  3. La lógica: fallar rápidamente  Para cumplir con un plazo de 100 ms, no basta con tener un código rápido. El sistema debe decidir rápidamente cuándo no trabajar.  La mayoría de las solicitudes de puja entrantes nunca se adjudicarán. Dejar que estas solicitudes afecten el estado, las bases de datos o las rutas de escritura es la forma más rápida de sobrepasar el presupuesto de latencia. Estructuramos al pujador como un árbol de decisiones ordenado por probabilidad de fallo, ejecutando primero las comprobaciones más económicas.  Las comprobaciones se realizan aproximadamente en este orden:    : Un gran porcentaje de las ofertas fracasan en esta zona. Esta comparación es sencilla y arroja resultados casi de inmediato. Comprobación geográfica    : si la geografía pasa, validamos las restricciones de la plataforma y del dispositivo. Comprobaciones del sistema operativo y del dispositivo    : verifica si la aplicación coincide con nuestro inventario permitido. Segmentación de editor/aplicación    : solo si una solicitud sobrevive a estos filtros tocamos rutas más pesadas (datos a nivel de usuario, lógica de presupuesto y ritmo o cualquier cosa que requiera coordinación). Lógica con estado  Al fallar rápidamente, rechazamos el 90% del tráfico en microsegundos y reservamos ciclos de CPU para las ofertas que realmente se convierten.  4. La arquitectura de datos: Redis para reglas, Aerospike para perfiles  Dividimos nuestra arquitectura de datos en dos niveles según los patrones de acceso y el costo de la "obsolescencia".  Las reglas: Redis local  Cada nodo almacena metadatos relevantes (campañas activas y límites de presupuesto) en su Redis local. Un cronworker utiliza un   y accede a nuestra API central cada 60 segundos para descargar la información más reciente. modelo de extracción  A nuestra escala, este estancamiento de 60 segundos genera un riesgo:   . Si varios nodos actúan simultáneamente sobre los mismos datos presupuestarios obsoletos, podrían gastar más de lo asignado al cliente. el sobregasto  Gestionamos esto con un   : consideramos el tamaño de la flota como un factor para el control presupuestario. A medida que aumenta el número de nodos de puja activos, cada nodo reduce dinámicamente la porción de presupuesto que puede usar. Incluso si un nodo trabaja con datos obsoletos, sus límites locales ya están regulados según el tamaño actual de la flota. El gasto se reduce gradualmente en lugar de dispararse, y el sistema converge en el siguiente ciclo de actualización. mecanismo de frenado  Los perfiles: Aerospike (La ventaja de los SSD)  Las búsquedas de perfiles de datos de usuario, las limitaciones de frecuencia y la reorientación requieren acceso en menos de un milisegundo a conjuntos de datos masivos y mutables. Un RDBMS tradicional no puede gestionar esta carga a nuestro precio.  Usamos   para esta capa porque está optimizado para tratar los SSD como almacenamiento principal, en lugar de mantener todo el conjunto de trabajo en RAM. Esto nos proporciona una latencia predecible y, al mismo tiempo, reduce los costos de hardware a una fracción de una solución de RAM pura como ElastiCache. Aerospike  Para mantener esta capa asequible, somos estrictos con la higiene de los datos:  La regla de los 10 días: solo conservamos datos de los usuarios activos en los últimos 10 días.  El límite de 10 millones: podamos activamente el conjunto de datos hasta los primeros millones de usuarios más activos.  Si un usuario deja de interactuar, sus datos se eliminan. Esta disciplina garantiza que los costos de almacenamiento se mantengan estables mientras el postor se centra únicamente en los usuarios importantes.  5. El secreto de "Async": desacoplar la carga  Nuestra primera versión intentó ser asíncrona. Enviamos la respuesta a la oferta inmediatamente y dejamos que la función de Node.js siguiera ejecutándose en segundo plano para escribir el registro en MongoDB.    : El tráfico no es constante, sino que se dispara. Durante los picos, aunque la respuesta a la oferta ya no existía, nuestros contenedores Node.js se quedaban "flotando", manteniendo las conexiones abiertas y consumiendo ciclos de CPU intentando finalizar las escrituras en la base de datos. Esto provocó que nuestro escalador automático activara más máquinas virtuales solo para gestionar la   , lo que a su vez colapsó nuestra base de datos con conexiones. La trampa acumulación de escrituras    : Pasamos de "Código asíncrono" a "   ". Introdujimos   como un amortiguador entre el postor y la ruta de escritura. Ahora, el postor envía un mensaje a Kafka y libera inmediatamente sus recursos. La escritura es gestionada por una flota de consumidores independiente a un ritmo controlado. Solución Arquitectura asíncrona Kafka  6. Benchmarking: medir, no adivinar  A esta escala, calcular los tipos de instancias es costoso. Por eso, en lugar de basarnos en la teoría, realizamos pruebas comparativas.  Teníamos hipótesis: si el pujador estaba limitado por la computación o por la memoria, cuántos procesos de trabajo eran lógicos por nodo y cómo el tamaño de la instancia afectaba la latencia. Realizamos pruebas con múltiples familias y tamaños de instancias de AWS, y variamos la cantidad de servicios de puja que se ejecutaban en un solo nodo.  Adoptamos el mismo enfoque con la capa de datos, probando distintos tipos de máquinas para ver qué funcionaba mejor para MongoDB bajo carga real, priorizando la latencia estable sobre el rendimiento máximo.  Todo esto se validó con pruebas de carga que impulsaron QPS similares a los de producción a través del sistema y midieron los tiempos de respuesta y la latencia de cola. Algunas suposiciones se cumplieron. Muchas no.  La conclusión fue simple:   . con un presupuesto de 100 ms, los puntos de referencia superan a la teoría siempre  7. FinOps: Cómo mantenemos la factura en $10,000  Las startups no mueren cuando hay picos de tráfico. Mueren cuando se agotan los créditos de la nube. Para nosotros, el control de costos no es una idea de último momento; forma parte del diseño del sistema.  Algunos ahorros provienen de la negociación. Trasladamos la facturación a un revendedor para obtener un descuento fijo por volumen. Para el ancho de banda, nos comprometimos a   , lo que nos permitió negociar una reducción del precio de la CDN de más del 60 % en comparación con las tarifas bajo demanda. Con nuestros niveles de tráfico, ese único compromiso supuso un cambio significativo. aproximadamente 1 PB de transferencia mensual  También separamos las preocupaciones: los servidores de ofertas sin estado se ejecutan en capacidad spot con grandes descuentos, mientras que las bases de datos con estado utilizan instancias predecibles y de larga duración.  A nuestra escala, almacenar cientos de millones de registros al día es una bomba de relojería. Los registros detallados de pujas tienen una retención corta, del orden de días, no de meses. Los datos que queremos conservar se agregan cada hora en lugar de por evento, y se trasladan a almacenes más económicos y fáciles de consultar. Todo lo necesario únicamente para el cumplimiento normativo o las auditorías históricas se almacena en frío, donde los costes se reducen entre un 80 % y un 90 % en comparación con los niveles estándar.  Sin embargo, el mayor ahorro no es un descuento, sino la   . utilización  La mayoría de los sistemas utilizan las CPU al 20-30% por seguridad. El nuestro no tiene por qué hacerlo. Gracias a que la arquitectura es tolerante a fallos y está diseñada para liberar la carga con fluidez, nos sentimos cómodos utilizando las CPU al   . No pagamos por ciclos de inactividad. Si pagamos por un núcleo, ese núcleo está pujando. 80%  Esa mentalidad –tratar la eficiencia como una restricción de primera clase– es lo que mantiene la factura estable incluso cuando el tráfico crece.  8. Operando con tres personas: La filosofía de la "matrícula"  Operar a escala global con un equipo de tres personas solo funciona si los sistemas, y no las personas, asumen la carga. Diseñamos las operaciones para eliminar la intervención humana de la ruta crítica y eliminar los puntos únicos de fallo siempre que sea posible. También evitamos los silos de roles: cada ingeniero puede gestionar toda la pila, por lo que el conocimiento operativo nunca es un punto único de fallo.  La infraestructura es desechable por defecto. Si un nodo presenta un mal funcionamiento, no lo depuramos in situ, sino que lo eliminamos y dejamos que el escalador automático lo reemplace. La recuperación es más rápida que la investigación, y cada instancia proviene de un estado limpio y conocido.  La observabilidad es importante, pero los paneles por sí solos no ayudan a un equipo pequeño. Confiamos en alertas procesables (a través de Datadog) que se activan solo cuando se requiere atención humana. Si un clúster regional se ralentiza o un consumidor se retrasa, nos avisan. Todo lo demás está automatizado.  Sin embargo, la automatización no es magia. Todavía pagamos matrículas de vez en cuando.  En uno de los primeros incidentes, una tarea en segundo plano encargada de actualizar el estado del presupuesto falló silenciosamente. El postor siguió operando con datos obsoletos y gastó en una campaña que debería haber finalizado, un escenario clásico de "postor zombi". Reembolsamos al cliente, solucionamos el problema y reforzamos el sistema con comprobaciones de latidos monitoreadas por Datadog. La actualización del presupuesto ahora es explícita, y el silencio mismo activa una alerta. Si el postor no recibe una actualización válida, se cierra.  En un equipo pequeño, los errores son inevitables.  Repetirlos es opcional.  Reflexiones finales  Ninguna de las decisiones de este sistema es exótica por sí sola. Lo que lo hace funcionar es su composición.  La física de la red establece el límite. La localidad y la lógica de fallo rápido protegen la ruta de 100 ms. Los límites asíncronos absorben las ráfagas de tráfico. La medición reemplaza la intuición. La disciplina de costos y la alta utilización garantizan la honestidad económica. Las operaciones están diseñadas para que los humanos intervengan solo cuando el sistema no pueda recuperarse por sí solo.  Esta no es una historia sobre tecnología publicitaria ni sobre una pila específica. Es un recordatorio de que, a escala,   . Cuando se consideran la latencia, el coste y la plantilla como requisitos de primera clase, la arquitectura resultante tiende a ser más sencilla, no más compleja. las limitaciones no son obstáculos, sino elementos de diseño  El objetivo no era construir algo impresionante. Era construir algo que sobreviviera.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Este audio es producido en el idioma original de la historia!

2 mil millones de solicitudes, plazos de 100 ms, 10 000 USD al mes: Diseño de un sistema RTB global eficiente

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps