Zalando hace pruebas de carga en producción. Esta es la razón.

De 4200 a 7200 en un año

Zalando es una de las mayores plataformas de moda de Europa, y Cyber Week es el momento que define su año de ingeniería. En octubre de 2020, el executive principal engineer Bartosz Ocytko publicó en el Zalando Engineering Blog un relato detallado de cómo se preparó Zalando para la temporada. La cifra principal de 2019: los pedidos por minuto en el pico, medidos, llegaron a 7200, frente a 4200 en 2018. Es un aumento interanual del 71 % justo en el momento de máxima carga. El crecimiento anual de clientes rondaba el 20-25 %, con 840.000 clientes nuevos solo ese año.

Con esa trayectoria, la pregunta de planificación de capacidad cambia. Ya no es si tu servicio de checkout aguanta el tráfico. Es si lo sigue aguantando cuando todos los demás servicios a los que llama están a la vez en su pico, con efectos de interacción que nadie ha modelado porque nunca antes habían coincidido.

El límite de staging

La respuesta habitual es un entorno de staging: levantar una copia de producción, lanzarle tráfico sintético y observar qué se rompe. El problema es que un entorno de staging es un modelo de tu sistema de producción, no una copia. A la escala de Zalando, las interacciones entre mil servicios en pico simultáneo no se pueden reproducir fuera de la plataforma real. Dependencias, perfiles de latencia, tamaños de búfer, colas compartidas: nada de eso se replica fielmente en staging, y a suficiente escala la divergencia lo es todo.

El equipo de Ocytko llegó a una conclusión que se cita más que cualquier otra frase en el mundo de las pruebas de carga:

«La única forma que hemos encontrado eficaz para un sistema a gran escala como el nuestro son las pruebas de carga en vivo en producción».

No es una preferencia ni una comodidad. Es una restricción de la arquitectura, dicha sin rodeos tras años de aplicar ambos enfoques y comparar los resultados.

Lo que exige de verdad probar en producción

Decidir probar en producción es la parte fácil. El programa de Zalando tiene tres requisitos innegociables, y cada uno es más difícil de lo que parece.

El primero son pedidos sintéticos que se puedan separar de los reales en la fase de preparación de pedidos. Zalando lanza pedidos de productos de prueba contra el sistema de producción real y los separa de los pedidos de clientes auténticos más adelante en el pipeline, antes de que se envíe nada real. Esa marca tiene que sobrevivir a cada traspaso. La prueba es real; el envío no. Esta modificación del pipeline de preparación de pedidos es trabajo de infraestructura que hay que hacer antes de que la prueba pueda ejecutarse siquiera.

El segundo es la coordinación entre unos 100 equipos de guardia que saben que la prueba está en marcha. La mayoría de los programas de planificación de capacidad no lo presupuestan. Si el servicio de un ingeniero lanza alertas durante una prueba de carga en vivo y nadie le avisó, el programa no está probando la plataforma. Está generando incidencias falsas y gastando la buena voluntad que hará falta cuando lleguen las de verdad.

El tercero es la cifra que merece más atención. Zalando probó 1122 aplicaciones en su programa, de las más de 4000 de la plataforma. La mayoría de la planificación de capacidad prueba los tres servicios de los que todo el mundo ya sospecha. Los modos de fallo interesantes viven en los servicios que a nadie se le ocurrió revisar, porque nada en su comportamiento normal sugería que fueran un riesgo. Probar 1122 aplicaciones no es meticulosidad por la meticulosidad. Es la única forma de encontrar el servicio que nunca ha estado en el registro de riesgos de nadie y que se cae bajo una carga que nunca había visto.

La elección de herramienta: mantenibilidad antes que rendimiento bruto

En un segundo artículo, publicado en marzo de 2021, los ingenieros de Zalando Amila Kumaranayaka y Carsten Timpert describieron cómo pasaron de pruebas de carga lanzadas a mano a un sistema totalmente automatizado sobre Kubernetes. Su evaluación de herramientas incluyó JMeter, Vegeta y Locust. Eligieron Locust.

Merece la pena citar el motivo tal cual: Locust era «más popular entre nuestros equipos de desarrollo, así que la suite de tests sería más fácil de mantener». No la opción con mejor rendimiento. No la más completa. La que sus equipos podían usar de verdad, entender y mantener al día con el tiempo.

Es un principio infravalorado en todas las áreas de las pruebas. Una herramienta técnicamente superior que nadie del equipo puede editar sin dos horas de recuperar contexto no es superior en la práctica. El enfoque anterior, con pruebas lanzadas a mano, el equipo lo describió como «engorroso y caro». La automatización lo integró en el trabajo normal de ingeniería. Para las pruebas de carga de pagos en concreto, usaron Hoverfly para simular las dependencias de pago externas, y cada ejecución duraba unas dos horas. La elección de Locust fue lo que lo hizo mantenible después de la construcción inicial.

Dependencias aguas arriba: el Wrapped 2022 de Spotify

La lección de Zalando trata de lo que pasa dentro de una gran plataforma. La experiencia de Spotify con el Wrapped de 2022, descrita en un artículo de marzo de 2023 en el Spotify Engineering Blog, añade otra dimensión: qué pasa cuando el cuello de botella no es un servicio tuyo.

Wrapped es uno de los eventos anuales con más tráfico de Spotify. La edición de 2022 tuvo más de 150 millones de usuarios activos en 111 mercados, con decenas de millones llegando en las tres o cuatro primeras horas tras el lanzamiento. El equipo esperaba decenas de miles de peticiones por segundo a la vez en las regiones de EE. UU., la UE y Asia.

Los servicios propios de Spotify pasaron pruebas de carga. Pero Wrapped se apoya en muchos servicios que el equipo de Wrapped no opera. El trabajo de preparación consistió en identificar cada dependencia aguas arriba, coordinarse con cada uno de esos equipos, confirmar que cada uno había dimensionado para la carga prevista y verificar que el dimensionamiento estaba completo antes del día del lanzamiento. El lanzamiento no tuvo problemas técnicos importantes.

Un servicio que pasa su propia prueba de carga mientras los servicios de los que depende no se han dimensionado para el evento no se ha probado de principio a fin. Mapear el árbol de dependencias antes de un evento de carga, incluidos los equipos que no controlas, deja de ser opcional a partir de cierto nivel de integración.

Lo que Ticketmaster no ha publicado

Ticketmaster no ha publicado un postmortem técnico de ninguno de sus dos incidentes más citados. Lo que sigue se basa únicamente en las declaraciones públicas de Ticketmaster, su testimonio ante el Senado de EE. UU. e informaciones de terceros, y debe leerse con eso en mente.

En la preventa de la gira Eras Tour de Taylor Swift en noviembre de 2022, las declaraciones públicas de Ticketmaster y su testimonio ante el Senado de EE. UU. situaron la escala en 3500 millones de peticiones al sistema en un solo día, cuatro veces su pico anterior registrado, con 14 millones de usuarios y bots simultáneos en la plataforma. Las cifras declaradas por la empresa hablan de 2,4 millones de entradas vendidas; la venta general se canceló después. El fallo visible para los usuarios fue un contador de cola que iba hacia atrás.

Cockroach Labs publicó un artículo analizando el incidente. Ese análisis es un comentario de proveedor, de una empresa de bases de datos distribuidas con un interés comercial directo en las conclusiones a las que llega. Puede ser correcto; no se puede verificar de forma independiente, y debe tratarse como tal.

En la venta de entradas de Oasis de agosto de 2024, The Stack, una publicación tecnológica, informó de errores 503 y 500 generalizados y de un sistema antibots que marcaba a compradores legítimos como sospechosos de ser tráfico automatizado. Ningún postmortem técnico siguió a esas informaciones.

La observación más duradera no es técnica. Nadie fuera de Ticketmaster conoce la causa raíz real de ninguno de los dos fallos, porque Ticketmaster no ha publicado nada que permita al sector aprender de ellos. La cola que iba hacia atrás, los códigos de error, los usuarios legítimos marcados: son síntomas visibles. La causa técnica sigue sin documentar. Que una empresa de esa escala, tras fallos tan visibles, decida no publicar un postmortem ya es en sí un dato. Resiste la tentación de diagnosticar la causa raíz desde fuera. Lo que sí se puede decir es que en ambos casos el sistema no rechazó con elegancia las peticiones nuevas una vez superada la capacidad, y que todas las explicaciones técnicas en circulación vienen de partes que no estaban en la sala.