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:

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:

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:

Como ejemplo, utilizaremos los siguientes dashboard:

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

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

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.

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.

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!

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete

Estamos comprometidos.

Tecnología, personas e impacto positivo.