Imagen de Markus Spiske en Pexel
¿Qué es la ingeniería del caos?
Es la práctica de someter aplicaciones y servicios a las tensiones y errores del mundo real para compilar y validar la resistencia a condiciones inestables y a la falta de dependencias.
Y como me gusta dejar definciones más formales, aquí está: https://principlesofchaos.org/es/
La ingeniería del caos tiene que ver con la experimentación contra producción para indentificar y encontrar problemas.
Cuantos más problemas encontremos más fiable será el sistema. Si introducimos simulaciones de incidencias basadas en casos reales que ocurrienron antes o bien simulamos interrupciones o cargas de trabajo no deseadas, etc. nos servirá para aprender del impacto en producción.
Por ejemplo, supongamos que una carga de trabajo va bien durante meses, mantiene la CPU con un promedio dentro de los párametros considerados normales, es decir el sistema funciona de forma saludable. Pero, de repente, se produce un pico de CPU y se bloquean solicitudes. Además de solucionar el problema, una de las tareas de nuestro equipo debería ser averiguar por qué ocurrió este problema. Pero si añadimos a esto una prueba de simulación de pico de CPU, los equipos podríamos haber encontrado una solución a un posible pico de CPU y haber mejorado nuestro sistema siendo tolerante a picos de CPU.
Pero no nos quedemos con que la ingeniería del caos es poner zancadillas a nuestro sistema para ver su comportamiento. Es más complejo, ya que retomando nuestro ejemplo anterior, una interrupción no es causa de una sola variable, pueden estar involucrados muchos elementos y simular un pico de CPU implica que elementos secundarios podrían ser los causantes y la zancadilla al final serían muchas zancadillas, es decir, que debemos estudiar la resilencia del sistema.
La ingeniería del caos no es nueva, ya lo lleva usando Netflix desde el 2008, os recomiendo la lectura de:
Un ejercito de simios al servicio de Netflix
Muy conocido es el caso de Netflix: Chaos Engineering Upgrade:
Chaos Monkey: deshabilita aleatoriamente las instancias de producción para asegurarse de que el sistema puede sobrevivir a este tipo de falla sin ningún impacto en el cliente.
Chaos Gorilla: similar al anterior, pero simula la interrupción de toda una zona de disponibilidad de Amazon. Verifica que los servicios automáticamente se balanceen con las zonas de disponibilidad operativas sin impacto visible en el usuario o requieran una intervención manual.
Chaos Kong in Operations, es muy raro que AWS tenga una caída mundial de un servicio en todas las regiones, pero sucedió en 2015 con DynamoDB. Y gracias a este ejercicio de Chaos Kong el impacto fue mínimo, podéis leer más en el link anterior.
No es mi objetico parafrasear lo que nos cuenta Netflix o los que podemos leer en el manifiesto de https://principlesofchaos.org, vamos a centrarnos en un ejemplo con Azure.
Manos a la obra con Azure Chaos Studio Architecture
Puedes realizar experimentos en diversos recursos:
- AKS, donde la tecnología subyacente es Chaos Mesh.
- En Azure Cosmos DB.
- En VM.
- Para probar directorio activo.
Pero vamos a lo que nos importa, a nuestro ejemplo paso a paso para la CPU de una VM:
Y ya tenemos acceso a Chaos Studio:
Previamente vamos a crear una VM con Ubuntu, alguna sencilla, y un disco standar.
Creamos una Managed Identity:
Creamos un Azure Application Insights:
Desde la opción Chaos Studio > Target, seleccionamos nuestra VM:
Establecemos los valores de los recursos que hemos creado previamente:
Revisamos que fue asignada la identidad a la VM:
Desde Chaos Studio vamos a decirle al agente de la VM sus capacidades:
Vamos a crear un experimento:
Añadimos un permiso IAM a la VM:
Ahora sí, con los permisos establecidos vamos a el experimento:
Entramos en el experimento y lo lanzamos:
Y a esperar 10 minutos al resultado:
Tambien puede ir a la VM y ver la métrica una vez finalizado el test:
