Ingeniería del caos: Un paso hacia la fiabilidad

La transición hacia los microservicios

Las organizaciones de IT han experimentado una transformación masiva en términos de personas, procesos y tecnología para abordar sus necesidades comerciales, como lograr un tiempo de comercialización más rápido. Las personas han completado y ampliado sus capacidades; los procesos han pasado de cascada a iterativos y ágiles; los equipos se han vuelto lineales, y las prácticas de DevOps se han aplicado a la automatización del desarrollo y la implementación de software. Aunque la arquitectura monolítica permite la modularidad lógica independientemente de cualquier mejora o nueva característica, sigue implementándose como una sola unidad, lo que hace que la implementación continua resulte tediosa y consuma mucho tiempo. Para superar este reto, las organizaciones han migrado de la arquitectura monolítica a la arquitectura orientada a los servicios y, en la mayoría de los casos, a los microservicios. El cambio a los microservicios ha ayudado a los equipos a desarrollar, probar e implementar aplicaciones con más eficiencia, rapidez y frecuencia. Además, la adopción de microservicios ha mejorado significativamente los indicadores clave de rendimiento (KPI), como la frecuencia de implementación y el tiempo de espera para el cambio, lo que ayuda a que las funciones salgan al mercado en un plazo más corto y a que el negocio se vea favorecido.

Retos tecnológicos de la arquitectura de microservicios

Las empresas de TI que han adoptado los microservicios han visto enormes beneficios. Sin embargo, siguen existiendo retos a la hora de gestionar las complejidades operativas y técnicas. Un aumento del número y de las interdependencias de los microservicios también puede aumentar los puntos de fallo, que luego afectan a las siguientes métricas:

• Tiempo medio de resolución (MTTR): el tiempo medio entre el inicio de una incidencia y su resolución
• Tiempo medio entre fallos (MTBF): el tiempo medio transcurrido entre fallos

Estas métricas miden la disponibilidad de los sistemas y son utilizadas por los equipos de desarrollo y de operaciones de fiabilidad de los sistemas para respaldar los contratos con acuerdos de nivel de servicio (SLA). Un mayor tiempo de recuperación del sistema/MTTR y los fallos frecuentes en el sistema/MTBF pueden afectar a la disponibilidad y fiabilidad del sistema, lo que afecta significativamente a los compromisos SLA/SLO (acuerdo de nivel de servicio/objetivo de nivel de servicio) en los contratos.

Adopción de la ingeniería del caos para mejorar la disponibilidad

La ingeniería del caos implica una serie de experimentos prácticos realizados en los sistemas para comprobar y aumentar la confianza en su capacidad para soportar condiciones turbulentas en la producción.Según un informe de 2021 realizado por Gremlin¹, el 23 % de los equipos que realizaban frecuentemente proyectos de ingeniería del caos tuvo un MTTR inferior a una hora; el 60 % tuvo un MTTR inferior a 12 horas. Por ello, la implementación de experimentos de caos en una fase temprana y frecuente del ciclo de vida del desarrollo de software (SDLC) permite lo siguiente:

• Mejora del MTTR: en el entorno de no producción, la corrección de defectos prepara a los equipos y mejora su velocidad para resolver las incidencias en los entornos de producción.
• Mejora del MTBF: en el entorno de no producción, los fallos pueden identificarse de forma proactiva y resolverse, reduciendo así los fallos en la producción.

Hoy en día, muchas empresas de primera línea tienen asegurada una disponibilidad y fiabilidad sin precedentes mediante la implementación de experimentos del caos como parte de su SDLC. Por lo tanto, mejorar el MTBF y el MTTR repercute en una alta disponibilidad del sistema y no se desvía de los SLAs/SLOs comprometidos.

Las pruebas de caos pueden revelar los puntos débiles del sistema

Las organizaciones pueden introducir la ingeniería del caos utilizando una estrategia de seis pasos, representada en el siguiente gráfico:

Vamos a profundizar en los seis pasos mencionados anteriormente. Utilizaremos la ayuda de un ejemplo de aplicación de reserva de películas basada en microservicios. Se despliega en un clúster Kubernetes en un proveedor de nube pública, como se muestra en la Figura 2 a continuación.

Varios servicios, como los horarios, la clasificación de las películas, la compra de entradas, los pagos, el correo electrónico y los SMS, se despliegan en contenedores individuales, cada uno de ellos envuelto en un pod independiente. La interfaz de usuario del front-end y la base de datos también se ejecutan en los pods. 

Paso 1: Descubrimiento

Durante esta fase, los equipos deben colaborar para obtener los detalles necesarios sobre una aplicación y su entorno. Para ello, deben:

• Analizar todos los servicios/componentes, la funcionalidad, los puntos de contacto y las dependencias entre servicios, incluidos los servicios ascendentes y descendentes, los servicios independientes, las configuraciones y los almacenes de datos 
• Explorar la infraestructura y el enfoque de implementación
• Identificar los puntos de fallo de cada componente/servicio
• Determinar el impacto en el negocio para cada punto de fallo 

Paso 2: Definir el estado estable

Durante esta fase, los equipos deben:

• Definir de forma medible el comportamiento del estado normal de la aplicación 
• Medir las métricas empresariales y operativas (por ejemplo, la latencia, el rendimiento, la tasa de errores, etc.)
• Para las métricas identificadas, marcar el rango de valores aceptables 

En la aplicación de ejemplo de reserva de películas (figura 2), el servicio (reserva de películas) es un componente esencial para el negocio, ya que está ligado a la generación de ingresos. Normalmente, durante los primeros días del estreno de una película, este componente recibe visitas masivas simultáneas. Por lo tanto, el rendimiento (la capacidad de dar servicio a estas solicitudes sin degradación) se convierte en la métrica más importante, y el equipo de gestión de productos define el rendimiento aceptable dentro del rango de 50 a 65 solicitudes por segundo para el servicio de reserva de películas.

Paso 3: Desarrollar una hipótesis

Una vez definido el estado estable para los servicios, identifique los experimentos que se inyectarán y formule una hipótesis sobre lo que puede salir mal (por ejemplo, ¿qué podría afectar al servicio, al sistema y a los clientes?) Además, priorice los experimentos en función del impacto en el cliente y la alta frecuencia de ocurrencia.

Vamos a terminar el pod que está ejecutando el servicio de Book Movie en la aplicación de ejemplo. Nuestra hipótesis es que Kubernetes detectará automáticamente la terminación y aprovisionará un nuevo pod.

Paso 4: Realizar el experimento, medir y analizar los resultados 

Comience a realizar experimentos en un entorno que no sea de producción. Sin embargo, es vital entender cómo se comporta el sistema antes de realizar el experimento. Mida las métricas necesarias en condiciones normales y, a continuación, mida las mismas métricas después de inyectar los experimentos. Si hay un impacto significativo después de ejecutar el experimento, abórtelo y ejecute el plan de reversión para volver a un estado estable.

Pasos para realizar un experimento POD kill en reservas de películas:

• Hemos creado Grafana, una herramienta de análisis, visualización y monitorización multiplataforma y de código abierto. Supervise el rendimiento, la tasa de error y la latencia antes de realizar el experimento, como se destaca en las figuras 5 y 6.

• Aproveche la herramienta de rendimiento de código abierto, Apache JMeter, para simular la carga concurrente durante una duración determinada en las solicitudes de servicio de Book Movie.
• Realice el experimento del caos —la terminación del pod de reserva de películas— aprovechando cualquier herramienta del caos.
• Observe el rendimiento, la tasa de error y la latencia después del experimento, como se destaca en las figuras 7 y 8 (en Grafana).

• Analice la tasa de error, el umbral y el rendimiento (registrados antes y después del experimento) para verificar las desviaciones 

Los datos muestran que cuando el pod de reserva de películas termina, la tasa de error y la latencia están por encima del rango normal. El rendimiento disminuye hasta que Kubernetes detecta que ha terminado y saca automáticamente un pod que contiene el servicio de reserva de películas; este fallo debe solucionarse.

Paso 5: Arreglar y volver a probar

En este caso, una de las posibles soluciones es escalar el número de réplicas; esto garantiza que un número determinado de pods se ejecute continuamente. Incluso si uno de los pods falla, los demás se encargarán de la solicitud. Observe que después de la corrección, en la imagen de abajo, no hay errores. El rendimiento y la latencia son los esperados y están dentro del rango. 

Además, con la implementación de patrones de diseño resistentes a los microservicios, los fallos en la aplicación pueden resolverse. Los desarrolladores pueden crear aplicaciones de microservicios resistentes a los fallos mediante el uso de patrones de resiliencia, como un interruptor, un reintento y un tiempo de espera.

Paso 6: Aumentar de forma iterativa el radio de explosión

Una vez que el experimento empieza a funcionar correctamente, la recomendación es aumentar gradualmente el radio del experimento. Por ejemplo, en el experimento de muestra anterior, damos por terminado un servicio y luego damos por terminado otro progresivamente. Por lo tanto, hay que empezar a experimentar en entornos de ensayo y luego pasar a producción.

Las mejores prácticas de la ingeniería del caos 

• Segmente los experimentos en un entorno de preproducción: inicie los experimentos en el entorno de desarrollo o de ensayo. Después de ganar confianza en el entorno inferior y de comprender el impacto de los experimentos, ejecute los experimentos en entornos de producción.
  
• Aproveche la automatización: Empiece con una prueba manual utilizando herramientas, pero aproveche la automatización para obtener una respuesta más rápida.
• Realice experimentos de forma continua: A medida que vaya ganando confianza con los experimentos, asegúrese de que los experimentos del caos se ejecuten de forma continua en la canalización CI/CD.
• Aumente de forma iterativa el radio de explosión: Céntrese en los experimentos conocidos y empiece con experimentos pequeños (por ejemplo, empiece con un contenedor, mida la latencia de la red entre dos servicios, etc.)
• Plan de recuperación: Garantice un plan de recuperación para cada experimento.

Reflexiones finales

Para garantizar la satisfacción y la retención de los usuarios en el mundo digital, las empresas deben tener en cuenta ciertos factores (tiempo de comercialización, experiencia del usuario, sistema fiable y capacidad de recuperación rápida) para llevar a cabo las operaciones y proporcionar valor a los usuarios finales. La incorporación de la ingeniería del caos en el SDLC permite obtener beneficios tanto operativos como técnicos, como la prevención de pérdidas de ingresos, la reducción de los costes de mantenimiento, la mejora de la gestión de incidentes, la disminución de los incidentes negativos, la reducción de la carga del personal de guardia y una mejor comprensión de los modos de fallo del sistema y la mejora del diseño del mismo.

Debido a sus numerosas ventajas, las organizaciones deberían dar un paso hacia la ingeniería del caos para facilitar la creación de sistemas de software fiables.

Referencias:

1. Horgan, Aileen. “The State of Chaos Engineering in 2021.”Publicado el 26 de enero de 2021. The State of Chaos Engineering in 2021 (gremlin.com)