Chaos engineering: herramientas y frameworks.

En posts anteriores (aquí podéis leer la Introducción a chaos engineering y en este información sobre planificación y estrategia) hemos dado una visión general sobre lo que la ingeniería del caos puede proporcionar a una organización y la metodología de desarrollo de sus equipos.

En este nuevo post, vamos a entrar más en materia y hacer una pequeña revisión de algunas de las herramientas y frameworks más extendidos para la ingeniería del caos, viendo para cada uno de ellos sus principales cualidades y los casos de uso donde mejor encajan. En concreto , veremos los siguientes frameworks:

• Chaos toolkit.
• Chaos mesh.
• Litmus.
• Kraken.
• Gremlin.
• Chaos monkey 4 spring boot.

Chaos toolkit

Chaos toolkit es uno de los frameworks de referencia para chaos engineering, siendo uno de los más generalistas y el que cubre mayor número de casos de uso.

Es un software Python independiente que ejecuta de forma externa a la plataforma sobre la que se desea realizar el caos.

Su sistema está basado en plugins extensibles, que funcionan a modo drivers para integrarse con los sistemas donde realizar los test de caos. Esto incluye integración sobre Kubernetes e infraestructura cloud (AWS, GCP, Azure…), herramientas de observabilidad (Prometheus, Open tracing) y otro tipo de servicios como Istio. Actualmente, ya existen un buen número de plugins desarrollados que pueden servir de base y que vale la pena revisar.

Chaos toolkit describe un ciclo de vida para le ejecución de los escenarios de caos de esta forma:

• Primero, se comprueba que el sistema se encuentra en una situación de ‘normalidad’ (en este caso, sería la situación en la que consideramos que el sistema es estable).
• A continuación, genera el test de caos y comprueba si el sistema sigue proporcionando servicio (esto podría significar que el sistema simplemente sigue en funcionamiento o que incluso es capaz de recuperarse del fallo).
• Por último, es posible definir una secuencia de acciones de rollback para deshacer el caos generado.

Chaos toolkit genera un informe con el resultado del escenario en el que se detalla lo ocurrido en cada una de las fases.

La forma en la que chaos toolkit entiende el caos significa que, en principio, chaos toolkit propone la ejecución de caos de forma puntual, con pruebas de ‘corta duración’ en el que, en el transcurso de segundos o unos pocos minutos, se comprueba si nuestro sistema es capaz de resistir o recuperarse de los fallos que se provocan.

Una de las principales limitaciones que tiene chaos toolkit desde nuestro punto de vista es, a su vez, una de sus ventajas: es un sistema que ejecuta de forma externa a la plataforma que se prueba, lo que limita la tipología de test que se pueden realizar (ej: inyección de errores de red). En esta situación la solución vendría por integrarse con una herramienta que permita realizar dichos test, convirtiendo a chaos toolkit en la plataforma que permitía orquestar todas las pruebas (independientemente de la herramienta que se utilice para generarlas).

Chaos mesh

Chaos mesh es una plataforma de ingeniería del caos centrada en Kubernetes.

Su funcionamiento se basa en un conjunto de operadores desplegados sobre el propio clúster donde se piensa ejecutar los experimentos.

Chaos mesh divide los experimentos en las siguientes categorías:

• Pod: fallo o eliminación de un pod o contenedor.
• Network: bloqueo de comunicaciones entre los pods, introducción de retrasos o duplicados en los mensajes, corrupción de los mensajes…
• Stress: Pruebas de carga (por ejemplo a nivel CPU del pod).
• Time: Altera la hora del proceso principal del contenedor.
• IO: Fallos en el sistema de IO, retardo en la lectura o apertura de ficheros, fallos, modificación de permisos…
• Kernel: Inyección de errores en el propio kernel.

Un punto muy interesante es que chaos mesh incluye algunas herramientas gráficas para la obtención de métricas de la plataforma en la que se ejecuta y dashboards para ver el estado de ejecución de las pruebas, pudiendo incluso programarlas.

A diferencia de chaos toolkit, la propuesta de chaos mesh, en principio, es generar experimentos de una duración más extensa donde el caos se genera de forma continuada durante un período de tiempo y evaluando cómo se comporta la plataforma. Las herramientas de medición mencionadas anteriormente proporcionan información en esta línea, facilitando la evaluación positiva o no del experimento.

Chaos mesh no proporciona como tal una salida de ‘experimento fallido o exitoso’, probablemente debido a esta orientación a pruebas de larga duración, lo que produce que no sea sencillo incorporar estos experimentos a un sistema automatizado que pueda evaluarlos.

Litmus

Al igual que chaos mesh, Litmus es un framework de chaos engineering que se enfoca en principio a Kubernetes.

Litmus define un conjunto de operadores que se despliegan sobre el propio clúster sobre el que se realizarán las pruebas.

Concibe los experimentos como pruebas de corta duración con principio y fin, obteniendo a la finalización un informe de resultados y detalle de las pruebas realizadas para facilitar el análisis de los posible problemas que puedan encontrarse.

Litmus tiene un sistema de plugins para poder desarrollar y ampliar el set de pruebas y este es uno de los puntos más interesantes, ya que estos plugins están agrupados en el “Litmus Hub” donde, además de los experimentos habituales en este tipo de herramientas, han implementado algunos para otros productos como kafka, cassandra… o infraestructura cloud (AWS), sumando en total un buen número de posibilidades.

Kraken

Kraken es un framework desarrollado por Red Hat para ejecución de experimentos de caos en Kubernetes y Openshift.

Permite un despliegue tanto interno como externo al clúster de k8s, lo que le dota de más flexibilidad que otras alternativas.

Propone escenarios de principio a fin, pudiendo componer una ‘autoevaluación’ del resultado. Para ello divide los escenarios (experimentos en la nomenclatura de Kraken) en tres tipos: Pod Scenarios, Node Scenarios y Time Scenarios, aunque al menos por ahora cubre únicamente los casos más básicos de caos.

Uno de los puntos más interesantes es que Kraken da soporte para los operadores propios de Openshift, lo que en ciertos entornos empresariales donde soluciones como Openshift está muy extendido puede ser de una gran ayuda.

El punto más flojo de Kraken es la documentación. Se ve bastante movimiento a su alrededor, por lo que es conveniente no perderlo de vista. Pero, a día de hoy, no hay mucha información al respecto.

Gremlin

Gremlin es la única herramienta comercial que hemos tenido en cuenta para este análisis. Pone a nuestra disposición en modo SaaS, o como ellos denominan FaaS (Failure as a Service), una completa plataforma de chaos engineering.

Gremlin permite experimentar en todo nuestro sistema, incluidos servidores baremetal, los proveedores de cloud público líderes del mercado, entornos en contenedores, Kubernetes, aplicaciones e incluso servicios serverless.

Al ser modelo SaaS, nos provee de mucha funcionalidad out-of-the-box. Una vez dados de alta en el servicio con uno de los planes disponibles, solamente tendremos que realizar la instalación de Gremlin sobre, al menos, uno de los sistemas operativos soportados. Desde aquí tendremos disponible un agente desde el que se ejecutarán los experimentos en las distintas plataformas soportadas. A partir de este momento, tendremos acceso al catálogo de ataques predefinidos tanto a nivel de infraestructura como a nivel de aplicación.

Dispondremos también de un dashboard donde se puede consultar de un vistazo bastante información: destinos atacados, número de experimentos ejecutados, listado de últimos ataques realizados, así como una vista del planificador de ejecuciones.

Como puntos menos destacados, a pesar de que se puede parar la ejecución de los experimentos, no se puede definir un procedimiento de rollback alternativo. No será necesario en muchos casos, pero en algunos sí nos puede venir bien. También señalar que al tratarse de un producto comercial, para dar soporte a nuevas plataformas o experimentos dependemos del avance que tenga el producto.

Chaos monkey 4 spring boot

Chaos monkey 4 spring boot es una rareza dentro de las soluciones de chaos engineering que hemos estado evaluando, pero justo por su punto de vista tan distinto al resto puede resultar de ayuda en determinadas situaciones.

Como su nombre indica, ayuda a realizar experimentos sobre aplicaciones desarrolladas sobre el framework de Spring, incluyendo en fase de compilación las librerías necesarias para ejecutarlo.

Las librerías aprovechan la inyección de dependencias del Spring para ejecutar pruebas sobre un cierto conjunto de componentes anotados (@Controller, @Services, @Repository…), y permitiendo realizar pruebas de incremento de latencia, generación de excepciones, ‘muerte de la aplicación’...

La librería inyectada habilita una serie de endpoints dentro de la aplicación para poder iniciar/parar/controlar las pruebas.

Por último, indicar que chaos toolkit tiene un plugin para chaos monkey 4 spring boot, consiguiendo una integración bastante sencilla.

Conclusión

En este post hemos repasado varias de las opciones más extendidas actualmente para chaos engineering. Tras analizarlas, podemos ver fácilmente que cada una de ellas se ha centrado en un conjunto de casos de uso y una forma de entender la ingeniería de caos particular.

Viendo los casos de uso que mejor aplican a cada una de las opciones, podríamos decir que el ideal vendría por utilizar de forma coordinada varias de estas herramientas, de forma que podamos estudiar el comportamiento de nuestro sistema con errores puntuales junto con otros de mayor duración a la vez que probamos tanto situaciones internas a nuestro clúster como externas sobre la infraestructura en la que ejecuta.

¡Seguiremos atentos la evolución de todas estas herramientas!