Compartir a través de


Validación continua con Azure Load Testing y Azure Chaos Studio

A medida que las aplicaciones y los servicios nativos de la nube se vuelven más complejos, la implementación de cambios y nuevas versiones para ellos puede ser difícil. Las interrupciones suelen deberse a implementaciones o versiones erróneas. Pero también se pueden producir errores después de la implementación, cuando una aplicación comienza a recibir tráfico real, especialmente en cargas de trabajo complejas que se ejecutan en entornos de nube multiinquilino muy distribuidos y que mantienen varios equipos de desarrollo. Estos entornos requieren más medidas de resistencia, como la lógica de reintento y el escalado automático, que se suelen ser difíciles de probar durante el proceso de desarrollo.

Por eso la validación continua en un entorno similar al entorno de producción es importante, para que pueda encontrar y corregir cualquier problema o error tan pronto como sea posible en el ciclo de desarrollo. Los equipos de carga de trabajo deben probar pronto durante del proceso de desarrollo (desplazarse a la izquierda) y hacer que sea fácil que los desarrolladores realicen pruebas en un entorno cercano al entorno de producción.

Las cargas de trabajo críticas tienen requisitos de alta disponibilidad con objetivos de 3, 4 o 5 nueves (99,9 %, 99,99 % o 99,999 % respectivamente). Es fundamental implementar rigurosas pruebas automatizadas para alcanzar esos objetivos.

La validación continua depende de cada carga de trabajo y de las características arquitectónicas. En este artículo se proporciona una guía para preparar e integrar Azure Load Testing y Azure Chaos Studio en un ciclo de desarrollo normal.

1. Definición de pruebas basadas en los umbrales esperados

Las pruebas continuas son un proceso complejo que requiere una preparación adecuada. Lo que se probará y los resultados esperados deben estar claros.

En PE:06: recomendaciones para pruebas de rendimiento y RE:08: recomendaciones para diseñar una estrategia de pruebas de confiabilidad, el Marco de arquitectura de Azure recomienda empezar por identificar escenarios clave, dependencias, uso esperado, disponibilidad, rendimiento y objetivos de escalabilidad.

A continuación, debería definir un conjunto de valores de umbral mensurables para cuantificar el rendimiento esperado de los escenarios clave.

Sugerencia

Algunos ejemplos de valores de umbral incluyen el número esperado de inicios de sesión de usuario, solicitudes por segundo de una API determinada y las operaciones por segundo de un proceso en segundo plano.

Debería usar los valores de umbral para desarrollar un modelo de estado de la aplicación no solo para las pruebas, sino también para operar la aplicación en producción.

Visualization of key system flows using green and red connected circles.

A continuación, use los valores para definir una prueba de carga que genere tráfico realista para probar el rendimiento de la línea base de la aplicación, validar las operaciones de escalado esperadas, etc. Se necesita tráfico artificial sostenido de usuarios en entornos de preproducción, ya que sin el uso es difícil revelar problemas en tiempo de ejecución.

Las pruebas de carga garantizan que los cambios realizados en la aplicación o en la infraestructura no causan problemas y que el sistema sigue cumpliendo los criterios de rendimiento y pruebas esperados. Una serie de pruebas con error que no cumple los criterios de prueba indica que debe ajustar la línea base o que se produjo un error inesperado.

Load test run results screen showing failed load test run.

Aunque las pruebas automatizadas representan el uso diario, debería ejecutar periódicamente pruebas de carga manuales para comprobar cómo responde el sistema a picos inesperados.

La segunda parte de la validación continua es la inserción de errores (ingeniería del caos). Este paso comprueba la resistencia de un sistema probando cómo responde a los errores. Y también que todas las medidas de resistencia, como la lógica de reintento, el escalado automático y otras, funcionan según lo previsto.

2- Implementación de la validación con Load Testing y Chaos Studio

Microsoft Azure proporciona estos servicios administrados para implementar pruebas de carga e ingeniería del caos:

  • Azure Load Testing genera una carga de usuario sintética en las aplicaciones y los servicios.
  • Azure Chaos Studio proporciona la capacidad de llevar a cabo la experimentación del caos mediante la inserción sistemática de errores en los componentes y la infraestructura de la aplicación.

Puede implementar y configurar tanto Chaos Studio como Load Testing a través de Azure Portal, pero, en el contexto de la validación continua, es más importante que tenga API para implementar, configurar y ejecutar pruebas de una forma programada y automatizada. Mediante estas dos herramientas puede observar cómo reacciona el sistema ante los problemas y su capacidad de recuperación automática en respuesta a errores de infraestructura o aplicación.

En el vídeo siguiente, se muestra una implementación combinada de Chaos y Load Testing integrada en Azure DevOps:

Si va a desarrollar una carga de trabajo crítica, aproveche las arquitecturas de referencia, las instrucciones detalladas, las implementaciones de ejemplo y los artefactos de código proporcionados como parte del proyecto del proyecto crítico de Azure y el marco de arquitectura de Azure.

La implementación crítica implementa el servicio de Load Testing mediante Terraform y contiene una colección de scripts de contenedor de PowerShell Core para interactuar con el servicio mediante su API. Estos scripts se pueden insertar directamente en una canalización de implementación.

Una opción de la implementación de referencia es ejecutar la prueba de carga directamente desde dentro de la canalización completa (e2e) que se usa para poner en marcha entornos de desarrollo individuales (específicos de la rama):

Run pipeline screen with the load testing checkbox ticked.

La canalización ejecutará automáticamente una prueba de carga, con o sin experimentos de caos (según la selección) en paralelo:

Azure DevOps pipeline run with chaos and load testing.

Nota:

La ejecución de experimentos de caos durante una prueba de carga puede dar lugar a una mayor latencia, tiempos de respuesta más altos y aumentos temporales en las tasas de errores. Observará cifras más altas hasta que se complete una operación de escalabilidad horizontal o se haya completado una conmutación por error, en comparación con una ejecución sin experimentos de caos.

Chart showing increased response time during chaos experiment.

En función de si la prueba de caos está habilitada y de la elección de experimentos, las definiciones de línea base pueden variar, ya que la tolerancia a errores puede ser diferente en estado "normal" y de "caos".

3 – Ajustar umbrales y establecer una línea base

Finalmente, ajuste los umbrales de prueba de carga para las ejecuciones normales para comprobar que la aplicación (todavía) proporciona el rendimiento esperado y no produce ningún error. Disponga de una línea base independiente para las pruebas de caos que tolere los picos esperados en las tasas de errores y un rendimiento reducido temporal. Esta actividad es continua y se debe realizar con regularidad. Por ejemplo, después de introducir nuevas características, cambiar las SKU de servicio y otros.

El servicio Azure Load Testing proporciona una funcionalidad integrada llamada criterios de prueba que permite especificar determinados criterios que debe superar una prueba. Esta funcionalidad se puede usar para implementar diferentes líneas base.

Test criteria screen with response time and error criteria marked as Failed.

La funcionalidad está disponible mediante Azure Portal y la API de pruebas de carga, y los scripts de contenedor desarrollados como parte del marco crítico de Azure proporcionan una opción para entregar una definición de línea base basada en JSON.

Se recomienda integrar estas pruebas directamente en las canalizaciones de CI/CD y ejecutarlas durante las primeras fases del desarrollo de características. Para obtener un ejemplo, consulte la implementación de ejemplo en la implementación de referencia crítica de Azure.

En resumen, el error es inevitable en cualquier sistema distribuido complejo y, por tanto, la solución se debe diseñar (y probar) para controlar los errores. La guía de carga de trabajo crítica del marco de arquitectura de Azure y sus implementaciones de referencia pueden ayudar a diseñar y operar aplicaciones altamente confiables para conseguir el máximo valor de la nube de Microsoft.

Paso siguiente

Revise el área de diseño de implementación y pruebas para cargas de trabajo críticas.