Chaos engineering: manos a la obra.

En anteriores post hemos vimos cómo planificar una estrategia de chaos engineering aplicada a una organización y hemos repasado las herramientas y frameworks más extendidos de esta ingeniería del caos.

Ahora, vamos a movernos al plano técnico y vamos analizar una pequeña infraestructura para ver cómo dividir en fases la implantación de las hipótesis.

Para ello, y sin querer simplificar demasiado y caer en el típico “hola mundo”, vamos a contar con una pequeña infraestructura sobre la que realizaremos el análisis.

Analizando nuestra aplicación

La aplicación se basa en la aplicación de ejemplo de Istio BookInfo, ya que nos permite contar un conjunto de servicios fácil de desplegar y preparados para su funcionamiento y, además, su funcionalidad es auto-explicativa.

Infraestructura

Nuestra pequeña aplicación de ejemplo se compone de los siguientes elementos de infraestructura:

Contamos con un cluster de Kubernetes proporcionado a través de un servicio gestionado de un proveedor cloud público (podríamos estar hablando de GKE, EKS o AKS, por ejemplo).

Disponemos de 3 nodos worker en configuración multi-AZ dentro de la región elegida para el despliegue de la aplicación.

Por ser un servicio gestionado por el proveedor cloud, vamos limitar la actuación de nuestras hipótesis de la siguiente manera:

Los nodos maestros son gestionados y se entiende la alta disponibilidad de los mismos, por lo que quedan fuera del ámbito de los experimentos que realicemos. De la misma forma, quedan fuera aspectos de comunicación entre ellos.

La comunicación entre los nodos worker, también quedará fuera del ámbito (si se buscara un testing avanzado se podrían realizar experimentos alterando permisos, por ejemplo, pero por ahora no los plantearemos).

Nos centraremos, por lo tanto, en el correcto funcionamiento de los nodos worker y asegurar que el sistema de detección / recuperación funciona adecuadamente en caso de fallo en alguno de ellos.

Arquitectura

A nivel aplicación, contamos con los siguientes componentes:

• Servicio ProductPage: es el punto de entrada a la aplicación y el microservicio de más alto nivel, proporciona la interfaz web y es el que se comunica con los servicios de Details y Reviews.
• Servicio Details: simplemente proporciona información detallada sobre los productos. No tiene ninguna dependencia, ya que almacena la información en la memoria y esta es inmutable (está hardcodeada).
• Servicio Reviews: proporciona información relativa a las opiniones de los productos. Al igual que el servicio de Details, almacena la información en memoria de forma inmutable. Aunque, en este caso, la enriquece a partir de los datos que proporciona el servicio Ratings.
• Servicio Ratings: aporta la puntuación de los usuarios sobre el producto (en realidad, sobre el detalle del producto). Almacena la información en una base de datos (MongoDB).

En necesario mencionar que todos los servicios se han desplegado en el mismo namespace de kubernetes sobre Istio.

Como vemos, la estructura es realmente reducida, pero nos permite apreciar algunas cosas que deberían llamar nuestra atención:

• Vemos que hay hasta tres niveles de llamadas en cascada: ProductPage - Reviews - Ratings. Esto podría traducirse en problemas debido a la acumulación de latencias por temas puramente de red (a las latencias de las llamadas, hay que añadir además el tiempo de comunicación con la base de datos del servicio Ratings).
• El camino más crítico desde el punto de vista de negocio sería ProductPage - Details. Es, por lo tanto, el que se debería priorizar y por el que empezaríamos nuestro análisis.
• La inmutabilidad de la información de los servicios Details y Reviews reduce la posibilidad de error de los mismos (básicamente los podríamos tomar casi como estáticos), por lo que habrá varias pruebas que no realizaremos.
• Por simplificar, la BD de ratings se encuentra desplegada dentro del cluster Kubernetes.

Observabilidad

El primer paso es comprobar que las herramientas y mecanismos de observabilidad son los adecuados.

Teniendo en cuenta la infraestructura y la arquitectura, debemos ser capaces de obtener información de monitorización en los siguientes puntos:

• Estado de cada uno de los nodos del cluster.
• Estado de cada uno de los servicios, así como número de réplicas de cada uno.
• Comunicaciones desde el exterior al servicio de ProductPage y entre los distintos servicios: resultado de las peticiones y latencias, principalmente.

Como ejemplo, utilizaremos los siguientes dashboard:

• Monitorización de nuestro cluster en EKS:

• Monitorización de la malla de Istio:

Definiendo los experimentos

Ahora vamos a definir nuestros experimentos teniendo en cuenta la plantilla que incluímos en el segundo post. En ella, vamos a recoger todos los datos que necesitamos para seguir nuestro método: definición de hipótesis, elemento sobre el que vamos a actuar, método a utilizar para ejecutar el experimento, así como las condiciones de rollback y cómo ejecutarlo.

Primero, debemos seleccionar qué herramienta o herramientas vamos a utilizar, ya que, al definir nuestro experimento, tenemos que ser objetivos. Para este caso, hemos optado por Chaos Toolkit.

Una de las ventajas que tiene Chaos Toolkit es que nos propone un completo framework de chaos, muy extensible mediante drivers, lo que nos va a permitir utilizar el mismo DSL para ejecutar nuestros experimentos en diferentes proveedores y plataformas. En Paradigma nos parece una opción muy interesante para incorporar a nuestros proyectos desde su etapa del desarrollo.

En nuestro caso, vamos a utilizar el driver de Kubernetes y el de Istio.

Teniendo delante la documentación de chaos toolkit, procedemos a dar forma a nuestros experimentos.

Atacando la infraestructura

• Drenar un nodo de kubernetes

Buscamos comprobar que el sistema tiene una alta disponibilidad real. Es decir, si un nodo cae, los restantes deben ser capaces de asumir la carga de trabajo total del sistema. En este caso, optamos por drenar uno de los nodos en vez de matarlo totalmente.

Más info sobre el método drain_nodes y el método uncordon_node.

Atacando la arquitectura

• Eliminar la mitad de los pods de un servicio (ratings)

Es una prueba sencilla de resiliencia. El sistema debe detectar que el pod ha caído y generar uno nuevo, manteniendo el servicio activo. Como punto de mejora, podríamos medir el número de peticiones erróneas máximas hasta que el sistema decide no enviar más carga de trabajo al pod caído.

Más info sobre método terminate_pods.

• Eliminar completamente un servicio (ratings)

Provocamos la pérdida de servicios total de uno de los servicios, buscando por un lado que el sistema se recupere normalmente y, por otro, que los servicios dependientes sean capaces de tratar esta situación, evitando así un posible fallo en cascada dentro del árbol de dependencias del sistema.

Más info aquí del método terminate_pods.

• Generar indisponibilidad en un servicio en base a incrementar latencia (reviews).

En esta situación, y a diferencia del caso anterior, el servicio afectado seguirá en funcionamiento, pero el tiempo de respuesta se eleva. Nuevamente buscamos que, ante un posible problema en uno de los servicios, el sistema en general siga funcionando adecuadamente. Una posible variante de este caso sería incrementar mucho la latencia para llegar a una situación de timeout. ¿El sistema seguiría funcionando si se disparan las latencias en cascada?

Más info sobre el método add_delay_fault y sobre el método remove_delay_fault.

Conclusión

En este post hemos querido mostrar cómo podría realizarse el análisis del sistema y la definición de las hipótesis que, dado nuestro caso de uso, creemos conveniente realizar en una primera fase. De esta forma, cubriremos esta línea de primera necesidad que nos permitirá confiar en la resiliencia de nuestro sistema en el flujo crítico que hemos identificado.

Obviamente, no se han cubierto todas las posibilidades, y nos hemos tomado ciertas libertades, sobre todo desde el punto de vista de la confianza en el servicio gestionado. Aún quedaría, por lo tanto, mucho trabajo que realizar. Pero creemos que este puede ser un buen comienzo.

Os animamos a que probéis a hacer este ejercicio de análisis e identificación de puntos críticos sobre los sistemas que habitualmente trabajáis, ¡los resultados suelen ser sorprendentes!