Por Agustin Castaño (Infraestructura)

Lanzar un nuevo servicio al mercado es un gran desafío que pasa por varias etapas como el planeamiento estratégico, la arquitectura, su desarrollo, diseño y despliegue, entre otras. Durante ese proceso es necesario probar el funcionamiento del servicio en condiciones similares a las del posible uso real, con lo que se denomina stress test.

Las herramientas de stress test permiten probar porciones de la plataforma de Toolbox a través de una serie de requerimientos que simulan las acciones que harían los usuarios, con un volumen de carga de trabajo similar o superior al que deberán enfrentar en condiciones reales. Esta clase de pruebas permiten estimar cuánto soporta una determinada configuración de la infraestructura o APIs que se está ejecutando, ubicar cuellos de botella, entender qué servicios son los más requeridos y si hay alguna manera de escalar cuando la capacidad de respuesta actual se ve superada.

No sólo es un procedimiento útil en las etapas previas a la salida a producción, sino que también permite mejorar las resolusiones de los issues de nuestros productos, destacándolos cada vez más por su tecnología constantemente actualizada. En este sentido, los stress tests honran, de alguna forma, la cultura de DevOps, porque deben ser trabajados colaborativamente por las áreas responsables de las operaciones y del desarrollo.
Las herramientas que se utilizamos en Toolbox para el stress test incluyen:

  • Tsung: Se trata de una herramienta multiprotocolo y distribuida, de código abierto, para testeo de carga. Puede ser usada para estresar servidores HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, MQTT y Jabber/XMPP. A través de un script (una pieza de código de programación) escrito en XML es posible indicarle a la herramienta qué debe hacer (la receta de qué es lo que hace el usuario al utilizar ese servicio, para que la herramienta lo imite), y luego es posible escalar la cantidad de usuarios a miles, o cientos de miles.
  • Apache JMeter: es un software de código abierto, 100% Java, que al igual que la anterior permite hacer test de carga, a finde medir el comportamiento o el desempeño. Si bien fue diseñada originalmente para aplicaciones Web, su campo de acción se fue expandiendo (hoy incluye servicios Web SOAP/REST, FTP, bases de datos vía JDBC, middleware orientado a mensajes a través de JMS, mail y objetos de Java, entre otros escenarios de test). Cuenta con una interfaz que permite construir el script que se usará para atacar la aplicación a testear.
  • New Relic: No se trata de una herramienta de testeo, sino de una herramienta de APM (Application Performnance Monitoring), y es la que usamos para monitorear los sistemas en Toolbox. Si bien las dos anteriores ofrecen reportes y gráficas de cómo están corriendo los tests y el estado de los nodos, la visión holística que nos da New Relic permite entender cómo está funcionando el sistema, cuánto del tiempo de respuesta corresponde a los accesos a las bases de datos, cuánto a la ejecución del código, o cuánto se va en llamados a servicios de terceros por mencionar algunas de sus funcionalidades.

Claro está, los resultados de New Relic no son lo único que tenemos en cuenta. Las métricas de Tsung, por ejemplo, nos permiten saber si el test está corriendo correctamente, incluso que no haya errores de diseño en la prueba, ni lo que se llama back pressure, que es cuando no se llega a estresar el sistema porque éste sencillamente deja de atender los requests de la herramienta de test para mantenerse estable.

¿Quién se ha llevado mi tiempo de respuesta?

A diario, miles de usuarios/suscriptores acceden a las plataformas de nuestros clientes (proveedores de contenido y operadores de TV). Uno de nuestros servicios permite que esa página se arme rápidamente mediante un único request (en la práctica, se brinda toda la información de la página ya procesada, y de esa forma no hace falta buscar las partes de la página en distintos requests). Este desarrollo forma parte de nuestro producto Cloud Experience.

Al probar este servicio, notamos que el tiempo de respuesta era alto, en el orden de un segundo. Entonces generamos un stress test contra ese servicio en particular. En este caso utilizamos Tsung. Diseñamos el script en XML para simular el comportamiento de los usuarios, y escalamos a unos 100.000 usuarios simulados por minuto.

A través de los resultados de New Relic comprobamos que había un consumo alto de la base de datos: no sólo era mayor al esperado, sino mucho más frecuente. Luego de un análisis, llevado a cabo en conjunto por las áreas Arquitectura e Infraestructura, se comprobó que había información necesaria para la construcción de la plataforma que era requerida todo el tiempo (por ejemplo, los datos del evento deportivo que el suscriptor quería ver), pero esa información no estaba previamente procesada en un caché.

Una vez que se creó el caché y se configuró que esta información fuera extraída desde el caché en lugar de hacerlo desde la base de datos, los tiempos de respuesta bajaron a la mitad. Volvimos a correr el test, que ahora mostró resultados dentro de los márgenes esperados, y el servicio pasó a producción.

VOLVER