¿Tu plataforma publicitaria no aguanta los picos de tráfico? Qué arreglar primero y quién puede ayudar

Si tu plataforma publicitaria falla en los picos de tráfico, los ingenieros que pueden ayudar son los que la miden durante un pico real y después la arreglan en un orden fijo. Detienen el trabajo que va a terminar después del deadline, limitan los reintentos y el tráfico que acepta la plataforma, y sacan de la ruta de la solicitud los contadores de presupuesto y de frecuencia. Después añaden capacidad antes de los picos que puedes prever. El código se reescribe al final, y solo donde apuntan las mediciones.

¿Cómo se manifiesta «no aguanta los picos de tráfico» en una plataforma publicitaria?

Un pico de tráfico da síntomas distintos en cada parte de una plataforma publicitaria:

• Bidder. Más respuestas llegan después del deadline del exchange, la tasa de pujas cae mientras sube el volumen de solicitudes, y el exchange puede empezar a enviar menos solicitudes
• Supply-side platform (SSP) o exchange. Las subastas se cierran antes de que respondan algunos bidders, y menos pujas compiten por cada impresión. En header bidding, las pujas que no llegan dentro del timeout de subasta de la página se quedan fuera de la llamada al ad server
• Ad server. Las llamadas al ad server se ralentizan y algunos espacios publicitarios se quedan vacíos
• Pipeline de eventos. Los recuentos de impresiones y clics llegan tarde o no coinciden entre sistemas
• Presupuestos y límites de frecuencia. Las campañas gastan de más o muestran el mismo anuncio demasiadas veces, porque los contadores se actualizan después de las decisiones que deberían haberlos leído

Los timeouts y los espacios vacíos aparecen durante el pico. Los problemas de eventos y de presupuesto pueden seguir ocultos hasta que los eventos retrasados llegan a los informes y a la facturación.

¿Por qué una plataforma publicitaria se rompe en un pico si con la carga media funciona bien?

En OpenRTB, el protocolo de IAB Tech Lab para real-time bidding, el exchange puede indicar el deadline en la propia solicitud: el «tiempo máximo en milisegundos que el exchange permite para recibir las pujas, incluida la latencia de Internet, para evitar el timeout». La documentación de Authorized Buyers de Google dice que el deadline suele ir de 80 a 1000 ms. Google exige que el 85 por ciento de las respuestas lleguen dentro de él, medido desde el trading location, y limita a los bidders que no lo logran de forma constante. Un bidder que se ralentiza en un pico pierde las subastas a las que llega tarde y después puede recibir menos tráfico.

Cerca de su capacidad máxima, un servicio empieza a encolar solicitudes. El libro Site Reliability Engineering (SRE) de Google señala que «las solicitudes encoladas consumen memoria y aumentan la latencia», y que los servidores gastan recursos en solicitudes que de todos modos van a incumplir su deadline. Salvo que el código compruebe el deadline, una solicitud que ha esperado demasiado se procesa igualmente entera y su respuesta se descarta.

Cuando una llamada a una base de datos, a una caché o a un socio agota el tiempo, quien llama lo intenta de nuevo, y los reintentos llegan justo cuando el sistema menos puede absorberlos. El libro de SRE echa las cuentas de una tormenta de reintentos: «100 QPS de reintentos en el primer segundo llevan a 200 QPS, luego a 300 QPS, y así sucesivamente».

Un exchange o una SSP envía cada solicitud a muchos bidders, y la subasta o bien espera a la respuesta más lenta, o bien se cierra sin ella. Jeffrey Dean y Luiz André Barroso, de Google, pusieron cifras a esto en Communications of the ACM en 2013. En su ejemplo, cada servidor responde normalmente en 10 ms, pero tarda un segundo en una de cada cien solicitudes. Una solicitud que tiene que reunir en paralelo las respuestas de 100 servidores así tarda entonces más de un segundo el 63 por ciento de las veces. Una subasta no espera tanto. Con el mismo cálculo, si cada uno de 100 bidders llega tarde en una de cada cien solicitudes, alrededor del 63 por ciento de las subastas se cierran con al menos una respuesta sin llegar.

El autoescalado que reacciona a la carga añade copias de un servicio solo después de haber medido esa carga. El Horizontal Pod Autoscaler de Kubernetes, por ejemplo, comprueba la carga cada 15 segundos por defecto y añade copias nuevas en incrementos limitados. Después, cada copia nueva tiene que arrancar, pasar sus comprobaciones y llenar sus cachés, y el libro de SRE señala que los procesos suelen ser más lentos justo después de arrancar que en régimen estable. Un pico que se mide en segundos puede terminar antes de que la nueva capacidad atienda tráfico real.

¿Qué deberíamos medir en un pico de tráfico antes de cambiar nada?

Mide esto en los minutos de más carga de un pico real:

• Solicitudes ofrecidas y solicitudes respondidas por segundo, para cada exchange o socio. La diferencia es tráfico que estás perdiendo, y su forma muestra si las solicitudes se descartan en la entrada o agotan el tiempo después de haber hecho el trabajo
• Los timeouts tal como los cuenta el socio. El exchange mide desde su lado, red incluida, y en Authorized Buyers de Google ese recuento decide si se limita a un bidder. Pregunta a cada exchange qué datos de timeouts puede compartir
• El percentil 99 de la latencia, desglosado en tiempo en la red, tiempo en cola y tiempo de trabajo
• Profundidad de cola por servicio. Una cola que crece durante el pico y se vacía despacio después señala el componente que marca tu techo
• Reintentos por segundo, según quién los hace. Si los reintentos suben a la vez que los timeouts, forman parte de la carga
• Retraso de contadores y eventos. Cuánto van por detrás del tiempo real, en el pico, los contadores de presupuesto y los logs de impresiones y clics

Reúne estas cifras de tu último gran pico en una sola página. Es el briefing para quien contrates y la línea base de cada arreglo.

¿Qué deberíamos arreglar primero, y en qué orden?

Trabaja en este orden, de los cambios baratos que cortan el trabajo desperdiciado a los caros que añaden capacidad o sustituyen código, y vuelve a medir después de cada paso.

• Detén el trabajo que va a terminar tarde. Lee el deadline cuando llega la solicitud, réstale el tiempo de red que mides para ese socio y responde con un no-bid rápido cuando el tiempo restante es demasiado corto. OpenRTB permite a un bidder declinar con una respuesta HTTP 204 vacía, que su guía de implementación califica como la opción más económica en ancho de banda
• Limita lo que entra. Pregunta a cada exchange cómo poner un tope a las solicitudes que te envía. La API de real-time bidding de Google, por ejemplo, permite a un bidder fijar, para cada endpoint que recibe sus solicitudes de puja, «el número máximo de consultas por segundo que se permite enviar a este servidor». Con un límite que fijas tú es más fácil planificar que con una limitación que te aplican después de incumplir deadlines
• Pon un presupuesto a los reintentos. Limita los reintentos por solicitud y da a cada servidor un presupuesto de reintentos, como recomienda el libro de SRE: una vez agotado el presupuesto, la solicitud falla en lugar de reintentarse. En las pujas, un reintento solo dispone del tiempo que queda hasta el deadline
• Saca los contadores compartidos de la ruta de la solicitud. Cuando cada decisión lee y actualiza los contadores de presupuesto y de frecuencia en un único almacén central, las campañas con más actividad se convierten ellas mismas en una cola. Da a cada servidor una parte local de los límites, concilia a intervalos cortos y acepta a cambio un riesgo pequeño y conocido de gastar de más
• Separa los eventos de las decisiones. Escribe los eventos de impresión y de clic en un buffer acotado por el que la solicitud no tiene que esperar, y cuenta cada evento que el buffer tenga que descartar. Así el pipeline absorbe el pico y se pone al día después, y una clave en cada evento le permite eliminar duplicados
• Prepárate para los picos que puedes prever. Muchos están en el calendario, como las rebajas de temporada y los eventos deportivos en vivo. Escala antes de que lleguen, calienta cachés y conexiones, y haz pruebas de carga contra una copia de producción con un generador que mantenga fija la tasa del pico
• Cambia al final el código que procesa cada solicitud. Hazlo cuando los números muestren que la causa es el propio código, como pausas del recolector de basura en la ruta de puja o una inferencia del modelo que se come el deadline

¿Hay que reescribir la plataforma para aguantar los picos?

Una reescritura completa rara vez es el primer paso correcto. Aparta a los ingenieros del trabajo en funcionalidades hasta que el código nuevo atienda tráfico de producción, y sin mediciones del pico nadie puede decir qué parte reescribir. Reescribe un componente cuando los números sigan señalándolo después de los arreglos más baratos, por ejemplo un bidder cuyas respuestas más lentas vienen de pausas de su runtime. Sustitúyelo detrás de la misma interfaz y compara las mismas cifras del pico antes y después.

Nuestra plataforma publicitaria no aguanta los picos de tráfico. ¿Quién puede ayudarnos a escalarla?

La ayuda para una plataforma publicitaria que falla en los picos de tráfico viene de cinco sitios, y cada uno cubre una parte distinta del problema:

• Tus propios ingenieros, con mejores mediciones. Conocen el código, y la página con las cifras del pico puede mostrarles el arreglo. Su límite es el tiempo, porque el trabajo para los picos compite con el roadmap
• Los exchanges y las SSP con los que trabajas. Sus recuentos de timeouts incluyen la red que hay entre ellos y tú, que tus propios dashboards no ven. Pregunta qué desglose pueden compartir: por ubicación, por tipo de solicitud, por hora
• El soporte de tu proveedor de nube. Útil para los límites de red, de balanceadores de carga y de instancias. La lógica de puja sigue siendo cosa tuya
• Empresas generalistas de outsourcing de software. Aportan ingenieros, lo que ayuda cuando la limitación es el tamaño de tu equipo. Pregunta si las personas que asignan han trabajado en un sistema en tiempo real bajo carga
• Empresas de ingeniería especializadas en ad tech e ingenieros de rendimiento independientes. Ayudan si han construido u operado el tipo de sistema que te está fallando. Tenlos en cuenta cuando la causa no está clara o los arreglos anteriores no aguantaron

¿Cómo comprobamos a una empresa que se ofrece a escalar nuestra plataforma publicitaria?

Haz estas preguntas antes de firmar. Las respuestas ayudan a ver si una empresa ha hecho este tipo de trabajo:

• ¿Qué necesitan primero de nosotros? Una buena respuesta nombra mediciones: timeouts por socio, percentiles, profundidad de cola, los minutos de más carga del último pico
• ¿Cómo sabremos que el trabajo está terminado? Espera un objetivo medible, acordado de antemano y comprobado en un pico real o reproducido: qué socio, qué percentil, qué margen frente al deadline, a qué tasa de solicitudes
• ¿Qué cambiarán antes de nuestro próximo pico previsible y qué después? Espera primero los arreglos baratos y una forma de desactivar cada cambio
• ¿Cuáles de estos han construido: un bidder, una SSP o un exchange, un ad server, un pipeline de eventos? Pregunta por el más cercano a tu problema y por lo que se rompió en él
• ¿Quién se queda después con el código, los dashboards y las pruebas de carga? Deberían quedarse en tus cuentas

¿Puede amBrain ayudar con una plataforma publicitaria que falla bajo carga?

amBrain es una empresa de ingeniería de software de Ereván, Armenia, que construye plataformas de trading de baja latencia, motores de casación y sistemas de real-time bidding en Rust.

amBrain diagnostica sistemas lentos en trading, apuestas y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo. amBrain se hace cargo de proyectos que se atascaron con otro equipo y los lleva a producción.

En AdTech, amBrain trabaja en desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange.

amBrain construye supply-side platforms (SSP) para editores. amBrain construye ad servers: segmentación, frequency capping e informes. amBrain construye pipelines de analítica de eventos para ad tech: recopilación, procesamiento e informes de eventos de impresión y de clic. amBrain construye inferencia de ML dentro del bidder: el modelo decide la puja dentro de la ventana de la subasta.

amBrain construyó RTBBidder, una demand-side platform, para un cliente. amBrain trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. El cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain.

Este artículo no es un caso de estudio. No afirma que amBrain haya resuelto fallos por picos de tráfico en la plataforma publicitaria de ningún cliente, y no da cifras sobre RTBBidder, ni precios ni plazos.

Si tu plataforma falló en su último pico, empieza con una página de mediciones de ese pico. Envíala a cada empresa que estés considerando, amBrain incluida, y compara cómo propone usarla cada una.

Preguntas frecuentes sobre plataformas publicitarias en picos de tráfico

• ¿Añadir servidores arregla los fallos en los picos? A veces: cuando a la plataforma se le acaba la capacidad de procesamiento en el pico y no hay nada más que falle. Cuando los timeouts vienen de tormentas de reintentos, de un almacén central de contadores o de un socio lento, más servidores suben la factura y dejan la causa donde está. Con un almacén central de contadores, además, añaden carga a la parte que ya es el límite
• Nuestra SSP agota el tiempo esperando a los bidders. ¿Qué podemos hacer? Da a cada bidder un timeout dentro de tu propio deadline de subasta y deja un margen antes de tener que responder al editor. Para los editores que usan Prebid.js con Prebid Server, Prebid dice que el timeout del lado del servidor «probablemente debería estar en el rango del 50%-75% del Auction Timeout», según el retraso de red del usuario, para que las pujas del servidor vuelvan al navegador a tiempo para la llamada al ad server
• ¿Hace falta Rust para aguantar los picos? No. El lenguaje importa cuando las mediciones muestran que la causa es el runtime, como las pausas del recolector en la ruta de puja. Las colas, los reintentos, los contadores compartidos y la capacidad se arreglan sin cambiar de lenguaje