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 los errores también pueden producirse 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 suelen ser difíciles de probar durante el proceso de desarrollo.

Por eso es importante la validación continua en un entorno similar al entorno de producción, de modo 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 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, Azure Well-Architected Framework recomienda empezar por identificar escenarios clave, dependencias, uso esperado, disponibilidad, rendimiento y objetivos de escalabilidad.

A continuación, debe definir un conjunto de valores de umbral medibles para cuantificar el rendimiento esperado de los escenarios clave.

Sugerencia

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

Debe usar valores de umbral para desarrollar un modelo de mantenimiento para la aplicación, tanto para probar como para operar la aplicación en producción.

Visualización de flujos clave del sistema mediante círculos conectados de color verde y rojo.

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 de 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 la infraestructura no provocan problemas y el sistema sigue cumpliendo los criterios de rendimiento y pruebas esperados. Una ejecución de prueba fallida que no cumple con los criterios de prueba indica que necesita ajustar la línea base o bien se produjo un error inesperado.

Pantalla de resultados de la ejecución de pruebas de carga que muestra la ejecución de pruebas de carga con errores.

Aunque las pruebas automatizadas representan el uso diario, debe ejecutar pruebas de carga manuales con regularidad 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 mediante la prueba de cómo responde a errores. Además, todas las medidas de resistencia, como la lógica de reintento, el escalado automático y otros, funcionan según lo previsto.

2- Implementación de la validación con Pruebas de carga y Chaos Studio

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

  • Azure Load Testing genera una carga de usuario sintética en aplicaciones y servicios.
  • Azure Chaos Studio proporciona la capacidad de realizar 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 Chaos Studio y 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 forma programática y automatizada. El uso de estas dos herramientas conjuntamente le permite observar cómo reacciona el sistema a los problemas y su capacidad de auto-recuperación 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 de Azure Mission-Critical y Azure Well-Architected Framework.

La implementación de Mission-Critical implementa el servicio Load Testing a través de Terraform y contiene una colección de scripts de contenedor de PowerShell Core para interactuar con el servicio a través de su API. Estos scripts se pueden incrustar 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):

Ejecute la pantalla del flujo de trabajo con la opción de pruebas de carga seleccionada.

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

Ejecución de canalización de Azure DevOps con pruebas de caos y carga.

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 tasas de error que aumentan temporalmente. 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.

Gráfico que muestra un mayor tiempo de respuesta durante el experimento de caos.

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

3 : ajuste los umbrales y establezca una línea base

Por último, 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. Tener una base de referencia independiente para las pruebas de caos que tolera los picos esperados en las tasas de error y un rendimiento reducido temporal. Esta actividad es continua y debe repetirse periódicamente. 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 denominada criterios de prueba que permite especificar determinados criterios que debe superar una prueba. Esta funcionalidad se puede usar para implementar diferentes líneas base.

Pantalla de criterios de prueba con el tiempo de respuesta y los criterios de error marcados como Error.

La funcionalidad está disponible a través de Azure Portal y a través de la API de pruebas de carga, y los scripts de contenedor desarrollados como parte de Azure Mission-critical proporcionan una opción para entregar una definición de línea base basada en JSON.

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

En resumen, el error es inevitable en cualquier sistema distribuido complejo y la solución debe diseñarse (y probarse) para controlar los errores. La guía de la carga de trabajo crítica de Well-Architected Framework y las implementaciones de referencia pueden ayudarle a diseñar y operar aplicaciones altamente confiables para derivar 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.