Estrategia de Performance Para un Ecommerce de Alta Demanda (Primera Parte)
El performance (rendimiento) es parte fundamental de la calidad de software; asegurar la disponibilidad de los diferentes componentes de un sistema es crucial para garantizar una experiencia de usuario fluida, segura y confiable. Un sistema resiliente, no sólo garantiza la fiabilidad, también nos permite asegurar (proyectivamente al menos) el cumplimiento de metas comerciales.
Para un equipo de performance, eventos como el Cyber Day es -por muchas razones- todo un desafío. Asegurar que los múltiples agentes que intervienen en un ecommerce (por ejemplo) interactuen fluida y eficientemente es vital para disminuir al mínimo el riesgo de caídas en las ventas producto de la indisponibilidad del sistema. Sin embargo, no basta con realizar pruebas de rendimiento utilizando escenarios idílicos para luego, durante un evento, chocar con la realidad, o con un comportamiento de usuarios que no es siempre lineal (como suelen ser las pruebas básicas), ni que comienza a escalar de a poco, ni que se agolpa por decenas de miles de usuarios esperando el “Go Live” del evento, la realidad es mucho más compleja.
En Haka Lab, nos encantan los desafíos, y hace ya un buen tiempo aceptamos uno tremendo; ayudar a uno de los e-commerce más grandes en Chile (con presencia en otros países como México, Estados Unidos y Canadá) a superar exitosamente el Cyber Day.
Desafíos de performance, de información y de negocio.
Tal vez se podría pensar que, con un plan robusto de pruebas y una infraestructura con gastos astronómicos es suficiente para asegurar los objetivos mínimos de estabilidad o rendimiento en un ecommerce de alta complejidad, pero nada más lejos de la realidad.
Antes de volverse nuestros partners, el mencionado ecommerce conoció en carne propia lo que es el colapso absoluto del ecosistema durante un evento Cyber Day, registrando pérdidas por varios miles de millones, esto sin contar, además, con el aumento exponencial de reclamos por temas como; pedidos anulados, cobros fallidos, falta de stock, entre otros.
Y si bien, se habían realizado “pruebas de performance” la interrogante era ¿Qué estuvo mal?
Para nosotros como Haka Lab el desafío inicial fue comprender el contexto, y cuando nos referimos a este “contexto” no solo hablamos de infraestructura, hablamos de sistemas, su interacción, sus relaciones, dependencias y límites.
Sin embargo, si queríamos tener éxito, software y hardware no eran los únicos campos a observar ¿Las pruebas de performance habían considerado las proyecciones de negocio para el evento? ¿Se tenían registros o proyecciones sobre el comportamiento de los usuarios? ¿El envío de notificaciones de ofertas y campañas consideraba los límites del ecosistema? Como puedes observar en este pequeño resumen, la problemática podría agruparse en 6 puntos claves.
Vamos revisando cada punto en cuestión para comprender cómo estos confluyen en el performance.
Software: Debemos conocer cómo “funciona” el software que estamos testeando, cuales son los requisitos de los servicios, errores controlados, time-outs configurados, rate-limits, qué impacto tiene su ejecución en la infraestructura, entre otros puntos relevantes. En este punto en cuestión podemos encontrar algunos aspectos curiosos -sobre todo en ecommerce grandes- tales como la desinformación sobre “los demás ranchos” o siendo más técnicos: servicios. Uno de los más llamativos es encontrar diferencias entre los tiempos de espera que dos servicios con una relación directa manejan, permítanme darles un ejemplo (típico en aplicaciones con modelo Back For Front -BFF):
El servicio “A” tiene un time out de 10 segundos y el servicio B un time out de 20 segundos. Durante el “día a día” estos servicios no presentan inconvenientes, la infraestructura del ecosistema garantiza que ambas respuestas ocurren dentro de lo esperado, mejor dicho, bajo los parámetros del servicio A.
Pero en un evento de alta demanda, (por favor, sígueme el juego) quien suele llevarse la carga alta es el servicio B, que es quien realmente hace consultas a otros servicios en la cloud, on premise, BD, etc.
Por su parte, “A” al ser un BFF, (normalmente) solo hace llamadas y espera respuestas para el front. Entonces los tiempos de respuesta -empujados por la alta demanda- de “B” superan por mucho el umbral de “A” obteniendo problemas difíciles de depurar. ¿Por qué?
En nuestras pruebas iniciales a este ecommerce detectamos que esta disparidad entre los servicios producía que al mirar los logs o herramientas de monitoreo, viéramos los errores en el servicio “A” pero al consultar el servicio “B” viéramos respuestas correctas. Esta disyunción no solo es costosa de debugear ya que el error, de buenas a primeras no es evidente, si no además, deja al descubierto que la falta de comunicación entre equipos o desconocimiento entre contratos de servicios es un problema mucho más profundo.
Adicionalmente, conclusiones aceleradas producto de las pruebas de performance, sin el debido análisis, podría empujarnos solicitar ajustes en la infraestructura en el servicio “A” debido a sus time-outs que suelen asociarse directamente a la sobrecarga.
Este ejemplo simplificado (lo más posible para no provocar somnolencia), demuestra como una revisión más profunda puede ir desentrañando problemáticas que capas más profundas permiten atacar los problemas de raíz, lo que, se traduce directamente en menor riesgo, ahorro en costos y una mayor fiabilidad en los servicios que componen la plataforma.
Te invitamos a quedarte atento a nuestras redes sociales, publicaremos la segunda parte en breve!