¿Qué cosas aprendimos de las fechas especiales en Tienda Nube?
Hace unos años, allá por el 2015 cuando comencé a trabajar en Tienda Nube, cada fecha especial era un momento de gran preocupación. Seguro se preguntarán ¿qué son las fechas especiales para el equipo de Ingeniería? En orden cronológico, año tras año, son:
- HotSale (Mayo) en Argentina
- CyberMonday (entre Octubre y Noviembre) en Argentina
- BlackFriday (Noviembre) en Brasil
Son esos días particulares donde las tiendas bajan los precios, hacen promociones y reciben una cantidad mucho más alta de tráfico que cualquier otro día común y corriente.
Cuando estas fechas empezaron a ser más relevantes para nuestros clientes, decidimos prepararnos mejor para el desafío que venía por delante: lograr una excelente experiencia de uso de la plataforma.
“Casi” preparados
Lo primero que hicimos fue armar un calendario con las fechas especiales para organizarnos mejor.
Acercándose el primer HotSale luego de reorganizarnos hicimos algunas mejoras de performance que creíamos que iban a ayudar a afrontar el tráfico de las tiendas en esos días, pero no fue tan así. El día comenzó sin problemas, hasta que al mediodía, con el aumento de tráfico en las tiendas… la base de datos principal, no resistió el tráfico y dejó de responder.
Para poder pasar esa situación, nos habíamos armado una checklist que contemplaba cancelar las consultas que quedaban colgadas, y si era necesario reiniciar la base de datos junto con la aplicación con el objetivo que el sitio volviera a responder. Pensábamos que estábamos mejor preparados, pero no fue realmente así. Hasta llegamos a apagar ciertas funcionalidades que generaban problemas, cosa que generaba una gran frustración en los clientes, con toda la razón.
Entendiendo mejor el problema
Pasados esos días, nos pusimos a entender mejor los problemas que teníamos para definir un nuevo objetivo. Lo que nos pasó, no nos podía volver a pasar, teníamos que poder pasar estas fechas particulares sin ningún problema.
Para lograrlo, armamos un plan a seis meses con una serie de tareas que atacaban los problemas que fuimos detectando en producción con el incremento de tráfico repentino. Algunas de estas cosas fueron: cambiamos los discos de algunos servidores por unos más rápidos, analizamos consultas de la aplicación a la base de datos para detectar cuellos de botella (agregamos índices a algunas tablas), actualizamos MySQL a la versión 5.7 (la última en ese momento), balanceamos mejor las colas de trabajos, agregamos una nueva herramienta de monitoreo, cambiamos las operaciones recurrentes de sólo lectura para que lo hagan en una réplica, entre otras cosas.
Con todo esto que fuimos aprendiendo, armamos una checklist que describía todas las cosas que teníamos que tener en cuenta para llegar bien preparados a las fechas especiales. Algunos puntos eran: cómo debíamos escalar la arquitectura para poder soportar el tráfico, cuánto tiempo antes íbamos a dejar el código sin modificaciones para no introducir funcionalidad nueva que pueda generar problemas y quiénes iban a estar de guardia para que siempre haya un integrante del equipo atento.
Salimos a la cancha
Ahora sí, llegó una nueva fecha especial y estábamos mejor preparados. Todo arrancó sin ningún problema hasta que la base de datos, que habíamos escalado para que trabajara muy relajada, empezó a tener un comportamiento muy extraño. El uso de CPU comenzó a tener unos picos de uso que eran bastante extraños, no entendíamos porqué pasaba eso ya que era una instancia el doble de grande en CPU, RAM y disco de lo que usábamos normalmente…
Como este comportamiento no cesaba, decidimos volver a la instancia que usábamos antes de escalarla para ver qué podía pasar. Hablamos con nuestro soporte de Amazon Web Services porque no lográbamos entender qué sucedía. Mientras esperábamos la respuesta, leyendo un poco más a fondo las especificaciones de la instancia más grande, encontramos que no tenía una optimización de hardware que sí tenían las instancias más pequeñas. Acá aprendimos que hay que leer con detenimiento las características de los servidores y que no siempre un server “más grande” es mejor.
Estresando la plataforma
Como ven, fuimos aprendiendo un montón de cosas en el camino y fuimos haciendo un montón de mejoras. Ahora que estábamos un poco más sólidos, quisimos ir un poco más allá y realmente poder simular de antemano el tráfico que solemos tener en las fechas especiales.
Para poder lograr el objetivo, nos pusimos a investigar algunas herramientas de stress testing y terminamos usando en primera instancia una que se llama Gatling. Nos sirvió mucho para detectar algunos problemas de performance en producción que pudimos corregir antes de llegar a la próxima fecha especial.
Todo el trabajo que les fui contando hizo que a partir de acá, vivamos todas las fechas especiales sin ningún sobresalto :)
Acercándonos cada vez más a la realidad
Con la iniciativa de siempre iterar nuestro trabajo en busca de aprender más, pensamos qué cosas podíamos mejorar en lo que respecta a las pruebas de stress que teníamos y surgió la idea de poder armar un test de que sea más real, que podamos correr en cualquier momento sin afectar la plataforma. Dada esta premisa, buscamos una nueva herramienta que nos simplifique el objetivo, no porque con Gatling no lo pudiéramos lograr, sino porque habría que modelar todos los escenarios posibles y eso implica una gran inversión de tiempo asociado a poca felixibilidad.
Luego de investigar varias herramientas, nos encontramos con GoReplay que nos permitió capturar tráfico real y reproducirlo cuantas veces y con la frecuencia que queramos.
Entonces nos pusimos a trabajar en esta nueva forma de probar la plataforma, clonando la arquitectura con la mismas componentes que producción, pero corriendo en un ambiente aislado que no afecte a nuestros clientes. Lograr esto no fue tarea fácil, tuvimos muchas iteraciones hasta dejar todo funcionando.
Cuando logramos tener todo listo, hicimos las pruebas en el ambiente clonado sin problemas. Empíricamente llegamos a la conclusión de que como estaba la aplicación, podíamos soportar hasta seis veces el tráfico de un día normal, lo cual nos generó tranquilidad.
No tan aislado
Haciendo las pruebas con GoReplay, recibimos mensajes de algunos clientes que nos estaban informando que veían algunos comportamientos extraños en sus tiendas. Lo primero que hicimos fue detener todo para entender si nosotros con las pruebas estábamos generando un problema. A priori, como estaba todo replicado, entendíamos que no. Luego, buscando bien, vimos que un server de nuestro ambiente de stress, estaba atendiendo flujos de producción y ese era el problema.
Pasando un poco en limpio, armando una arquitectura en paralelo aprendimos que para no volver a tener el problemas, teníamos que crearla por completo en una VPC distinta para lograr un verdadero aislamiento. Vamos a trabajar en esto pronto.
Todo esto aprendimos en estos últimos años, ojalá en los años que viene podamos seguir mejorando y traerles esos nuevos aprendizajes en un post.
