- En entornos de microservicios y cloud, las fallas son inevitables, por lo que es necesario fortalecer de antemano la resiliencia del sistema mediante Chaos Engineering
- Chaos Toolkit y Chaos Monkey se usan como potentes herramientas de pruebas de fallas, destacando respectivamente por su versatilidad y por su especialización en Java (Spring Boot)
- Mediante experimentos basados en Kubernetes e Istio es posible simular diversos escenarios reales de fallas, como latencia de red, interrupción de servicios y fallas regionales
- Al integrar Chaos Engineering en el pipeline de CI/CD, se puede validar automáticamente la capacidad de respuesta ante fallas antes de producción
- La clave no es la “destrucción”, sino la “construcción de confianza”, y se recomienda una estrategia de empezar en pequeño y aumentar gradualmente el nivel de caos
Chaos Engineering para microservicios
¿Qué es Chaos Engineering?
- Chaos Engineering es una metodología que simula fallas reales para descubrir de antemano las debilidades del sistema y mejorarlas
- Ejemplos principales de simulación:
- Fallas de región o de centro de datos
- Latencia de red entre servicios
- Sobrecarga de CPU y fallas de I/O
- Indisponibilidad de servicios dependientes
- Errores del sistema de archivos
- Objetivo: reducir el tiempo de recuperación, mejorar la disponibilidad y minimizar el impacto en el usuario antes de que ocurra una falla
Ciclo de vida de los experimentos de Chaos Engineering
- Mediante un procedimiento de experimentación estructurado se aplica un proceso cíclico de planificación → ejecución → observación → mejora
- Operación continua basada en experimentos para mejorar sistemáticamente la confiabilidad
Chaos Toolkit vs. Chaos Monkey
-
Uso
- Chaos Toolkit: framework general de experimentos de Chaos que puede usarse en diversas plataformas y entornos
- Chaos Monkey (solo para Spring Boot): herramienta de simulación de fallas exclusiva para aplicaciones Java Spring Boot
-
Forma de configuración
- Chaos Toolkit: define experimentos usando una configuración declarativa basada en JSON/YAML
- Chaos Monkey: se configura mediante el archivo
application.yml y la integración con Spring Boot Actuator
-
Lenguajes y entornos compatibles
- Chaos Toolkit: compatible con entornos multilenguaje y multiplataforma (Node.js, Java, Kubernetes, etc.)
- Chaos Monkey: especializado en aplicaciones basadas en Java (Spring Boot)
-
Tipos de fallas soportadas
- Chaos Toolkit: admite amplios experimentos de fallas, como fallas de red, terminación de Pod, estrés de CPU/memoria y fallas personalizadas
- Chaos Monkey: inyección de fallas centrada en la capa de aplicación, como latencia (Latency), excepciones (Exceptions) e interrupción del servicio (KillApp)
-
Sistemas integrables
- Chaos Toolkit: puede integrarse con Kubernetes, Istio, Azure, Prometheus, entre otros
- Chaos Monkey: se integra directamente con la API de Spring Boot Actuator para actuar sobre componentes internos de Spring
Cuándo se recomienda usar cada uno
- Chaos Toolkit
- Entornos de despliegue basados en Kubernetes
- Servicios multicloud o multilenguaje
- Cuando se necesiten escenarios de falla complejos
- Chaos Monkey
- Apps Spring Boot basadas en Java
- Pruebas de excepciones/latencia a nivel de método
- Cuando se prefiere un enfoque simple e integrado
Ejemplos prácticos con Chaos Toolkit (Java/Node.js/Kubernetes)
Experimentos en entornos Kubernetes
- Experimento de terminación de Pod: validación de resiliencia con
pod-kill
- Experimento de latencia regional: inyección de latencia de red en servicios virtuales de Istio
- Experimento de agotamiento de recursos: consumo forzado de CPU/memoria
- Simulación de caída de DB: prueba de respuesta ante fallas de servicios dependientes
- Partición de red: experimento de interrupción de comunicación entre servicios
- Falla basada en tiempo: inyección de fallas durante horas pico de tráfico
Inyección de latencia basada en Istio
- Inyección de latencia de red en la capa de service mesh
- Control de latencia/tasa de errores mediante configuración de Istio
Generación y análisis de reportes
- Resumen de resultados de experimentos con el comando
chaos report
- Interpretación de resultados:
- Se mantiene el estado normal → resiliencia asegurada
- Se detectan anomalías → se requiere análisis de logs y monitoreo
- Ocurren fallas en cascada → considerar circuit breaker y refactorización
Chaos Monkey en Spring Boot
- Objetivos monitoreados:
@Controller, @Service, @Repository, @RestController
- Fallas que se pueden inyectar:
- Latency Assault: latencia artificial
- Exception Assault: generación de excepciones
- KillApp Assault: interrupción completa de la aplicación
Forma de ejecución
- Activar el perfil
chaos-monkey en application.yml
- Control dinámico mediante la API de Spring Boot Actuator
Chaos Engineering en Node.js
Uso de Chaos Monkey para Node.js
- Instalación de una librería Chaos Monkey de terceros
- Funciones:
- Inyección de latencia
- Generación de excepciones
- Simulación de fallas de red
Ejemplo de uso de Chaos Toolkit
- Configuración de experimentos en formato JSON
- Ejemplo: inyección de 200 ms de latencia en una API específica de Node.js
Integración de Chaos en el pipeline de CI/CD
Objetivos de la integración
- Validación automática de resiliencia antes del despliegue
- Identificación de cuellos de botella de rendimiento
- Mejora del MTTR (Mean Time to Recovery)
- Automatización del rollback sin intervención manual
Ejemplo de integración con GitHub Actions
- Ejecución automática de experimentos al hacer commit de código
- Ejecución de experimentos tras instalar Chaos Toolkit
- Detención del despliegue si falla el health check
Mejores prácticas para experimentos de Chaos Engineering
- 1. Definir una hipótesis de estado estable: establecer claramente cuál es el estado normal del sistema
- 2. Comenzar con experimentos de baja intensidad: 100 ms de latencia → incremento gradual
- 3. Integración obligatoria con monitoreo: observación en tiempo real con Prometheus, Grafana, etc.
- 4. Configurar rollback automático: construir un mecanismo de recuperación rápida ante fallas
- 5. Ampliar el alcance gradualmente: de nivel servicio → a nivel clúster
Conclusión
- Chaos Engineering no busca romper el sistema, sino construir confianza
- En Java, Node.js, Kubernetes o Istio, se puede comenzar con experimentos pequeños y expandirlos gradualmente
- Aprovecha herramientas como Chaos Toolkit y Chaos Monkey para simular de forma segura situaciones reales de falla
- Al integrar y automatizar los experimentos en CI/CD, se puede asegurar de antemano una operación más estable
Material de referencia
1 comentarios
Al escuchar el término ingeniería del caos, por un momento pensé que hablaban del backend de nuestra empresa que yo programé;