Agregar pruebas de carga a los flujos de trabajo de CI/CD
Introducción
Las pruebas de carga son una técnica que se centra en evaluar el rendimiento de una aplicación en condiciones de carga normales o esperadas. El objetivo es determinar cómo se comporta la aplicación cuando está sujeta a los niveles esperados de uso y tráfico. Las pruebas de carga se utilizan a menudo para comprobar que un sistema puede controlar el número esperado de usuarios y transacciones, y para identificar cualquier cuello de botella o problema de rendimiento que pueda afectar a la experiencia del usuario.
Microsoft Azure ofrece un nuevo servicio (en versión preliminar), llamado Pruebas de carga de Azure. Uno de los beneficios clave de usar este servicio es que le permite probar el rendimiento de su aplicación a una escala sin tener que invertir en hardware e infraestructura costosos. Además, es altamente configurable y se puede usar para probar aplicaciones hospedadas en una variedad de plataformas, como Azure, servidores locales y proveedores de nube de terceros.
¿Qué necesitamos?
Además de una suscripción de Azure y una cuenta de GitHub, necesitaremos un Apache JMeter script, que normalmente consta de una serie de elementos de prueba, incluidos grupos de subprocesos, samplers, oyentes y aserciones. Los grupos de subprocesos definen el número y el tipo de usuarios virtuales que se simularán, mientras que los muestreadores definen las acciones o solicitudes específicas que realizarán los usuarios virtuales. Los oyentes capturan los datos de rendimiento generados por la prueba, y las aserciones definen los resultados esperados de la prueba y verifican que los resultados reales coincidan con las expectativas.
Aquí puedes encontrar el script que creé como parte de esta demo
Empezando
En el siguiente ejemplo, vamos a usar Azure Load Testing en nuestro flujo de trabajo desde GitHub Actions para detectar cuándo nuestra aplicación web ha alcanzado un problema de rendimiento. Vamos a definir un escenario de prueba de carga con un número y tipo específico de usuarios virtuales que se simularán, así como la duración de la prueba y el tipo de carga de trabajo a simular, que en este caso es solo una solicitud HTTP. Además, también puede usar Visual Studio o el Portal de Azure para crear y configurar el escenario de prueba de carga.
Una vez definido el escenario de prueba de carga, podemos revisar los resultados y los datos de supervisión, que incluyen métricas como el tiempo de respuesta, el uso de CPU y el tráfico de red, así como contadores de rendimiento personalizados que podemos definir. Con estos datos identificamos cuellos de botella y optimizamos el rendimiento de la aplicación.
El escenario
Desarrollé un simple Aplicación Web compilado con ASP.NET Core con .NET 7 que se conecta a Azure Cosmos DB y agrega un registro de cada visita a la página y recupera los datos de todas las visitas.
El entorno
Esta aplicación web se ejecuta en un Servicio de aplicaciones Básico y tiene Applications Insights para supervisar el rendimiento de la aplicación. Cosmos DB se establece con el comando Nivel gratuito (1000 RU/s y 25 GB). Quiero averiguar si la aplicación que se ejecuta en este entorno puede admitir hasta 100 usuarios simultáneos.
(https://loadtestingweb.azurewebsites.net)
El repositorio
Puedes consultar el Repositorio de GitHub aquí. Allí puede bifurcar el repositorio, use el botón Plantilla de ARM.
Nota: Microsoft Azure solo le permite crear un recurso de capa gratuita de Cosmos DB por suscripción, es posible que reciba un error si ya tiene una capa gratuita de Cosmos DB en su suscripción.
Este repositorio tiene un Acción de GitHub que compilan e implementan la aplicación y ejecutan la prueba de carga en Azure Load Testing.
La acción de GitHub
El Flujo de trabajo consta de tres pasos (compilación, implementación y pruebas de carga) y se ejecuta en cada inserción. El trabajo de prueba de carga utiliza los siguientes archivos en la carpeta raíz:
El inicio de sesión de Azure es necesario para comunicarse con el servicio Azure Load Testing para enviar el script de JMeter y la configuración de la prueba. En esta configuración podemos definir el número de motores Queremos ejecutar la prueba y los criterios de fallo, en este caso tenemos un tiempo de respuesta promedio inferior a 5 segundos y un porcentaje de error inferior al 20%.
Los resultados
Como puedes ver en la imagen de arriba, la prueba de carga fracasado dado que el tiempo de respuesta promedio fue superior al umbral (5 segundos), podemos obtener más detalles sobre la ejecución de la prueba en el Portal de Azure. Puedes descargar los resultados aquí.
En el Servicio de aplicaciones de Azure, podemos ver las métricas con los tiempos de respuesta (superiores a 5 segundos) y el número de solicitudes con los datos de entrada y salida.
Además, agregué Application Insights para monitorear la aplicación web, en el Portal de Azure podemos ver los problemas y errores de rendimiento.
En la imagen de arriba puede ver de dónde provienen las solicitudes, en este caso estoy ejecutando Azure Load Testing en la región Este de EE. UU. (Virginia).
Conclusiones
Las pruebas de carga no debe ser ejecutándose en un entorno de producción, pruébelo en un control de calidad o preproducción. Incluso si se ejecuta en ranuras de implementación, recuerde que la aplicación seguirá ejecutándose en el mismo plan del Servicio de aplicaciones, lo que podría afectar al entorno de producción o provocar un Ataque de denegación de servicio.
Si desea obtener más información sobre Azure Load Testing, le recomiendo que revise el Documentación de servicio.