La ingeniería del caos es una metodología proactiva que introduce intencionalmente interrupciones y fallas controladas en un sistema para descubrir debilidades, mejorar la resiliencia y garantizar un rendimiento sólido frente a interrupciones imprevistas.
Todo falla, todo el tiempo — Dr. Werner Vogels, director de tecnología de Amazon
Este es el mantra que los desarrolladores debemos repetir cada vez que planificamos un sistema distribuido, y es precisamente por eso que la ingeniería del caos es tan importante.
En esta publicación del blog, aprenderá sobre la ingeniería del caos y cómo complementa el ciclo de vida del desarrollo de software (SDLC) tradicional. Abordaremos los desafíos de implementar la ingeniería del caos en la arquitectura sin servidor y revisaremos algunos enfoques con sus ventajas y desventajas.
Tabla de contenido
Presentación del autor invitado: Koby Aharon
Koby Aharon es arquitecto de software principal en CyberArk . Es un ingeniero profesional práctico al que le encanta usar la tecnología para resolver problemas complejos.
Puedes seguir a Koby en sus cuentas de LinkedIn y Medium .
El desafío de la tecnología sin servidor
Las arquitecturas sin servidor han revolucionado la forma en que se desarrollan e implementan las aplicaciones, ofreciendo escalabilidad, rentabilidad y una gestión optimizada. Sin embargo, garantizar su resiliencia puede resultar aún más complicado, aunque AWS las gestione.
Veamos la siguiente arquitectura:
Nuestra arquitectura de muestra es una arquitectura clásica sin servidor que se ejecuta sobre AWS. Está construida a partir de los siguientes componentes:
API alojada en Amazon API Gateway . Nuestra API está implementada en dos regiones: us-east-1 y eu-west-1.
Función Lambda: activada por nuestra puerta de enlace API (explicada aquí ).
Dominio personalizado registrado en Amazon Route 53 .
Enrutamiento basado en latencia de Route53 para garantizar que nuestros clientes utilicen la API de menor latencia disponible.
Comprobación de estado de Route53 para verificar el estado de nuestras API.
Dada nuestra arquitectura, ¿cómo podemos estar seguros de que nuestros clientes estadounidenses puedan acceder a nuestro sistema en caso de una falla regional en Estados Unidos? Esto no es una teoría. Ocurrió el 13 de junio de 2023 (puede leer más aquí ).
Al igual que todos los desarrolladores, realizamos pruebas de integración y de extremo a extremo (puede leer más sobre las mejores prácticas aquí ), pero ¿es suficiente? La respuesta corta es no. Las pruebas generalmente se centran en verificar la funcionalidad y el comportamiento del sistema; sin embargo, queremos verificar la resiliencia de nuestro sistema. Queremos asegurarnos de que nuestra arquitectura sea resistente a una falla regional, e incluso si la región de EE. UU. no funciona, nuestra API de la UE seguirá funcionando y brindará servicio a todos los clientes.
Por eso la ingeniería del caos es esencial. Si seguimos sus principios, podemos realizar experimentos que simulen una falla en una región y verificar que nuestra API esté funcionando como se espera y que atienda las solicitudes de otra región.
Realizar esos experimentos e introducir interrupciones es relativamente fácil cuando se controla la infraestructura. Se puede “desconectar” una máquina para simular una falla. Sin embargo, utilizamos servicios administrados por AWS, lo que significa que no controlamos (ni siquiera tenemos acceso a) la infraestructura. Entonces, ¿cómo podemos simular una falla en una región?
Esperemos con esta pregunta y comencemos explicando cómo es un experimento de ingeniería del caos.
Experimento del caos
Un experimento de caos generalmente se construye a partir de los siguientes pasos:
Formular una hipótesis (plan),
Introducir estrés/fracasos (hacer),
Observar (verificar),
Mejorar (actuar).
1 - Formular una hipótesis
Utilicemos nuestra arquitectura de ejemplo y comencemos formulando una hipótesis:
Dado : tenemos una puerta de enlace API multirregional detrás del enrutamiento basado en latencia.
Hipótesis : el fracaso en una región no afecta a las demás.
2 - Introducir fallos
Como se mencionó anteriormente, introducir estrés y fallas en nuestra arquitectura sin servidor de ejemplo puede ser un desafío. Usamos servicios administrados por AWS, lo que significa que no controlamos (ni siquiera tenemos acceso a) la infraestructura. Entonces, ¿cómo podemos avanzar e introducir fallas?
El único componente que controlamos es el código de nuestra función Lambda. Nuestra función Lambda tiene dos responsabilidades principales:
Chequeo de salud
Implementación de API
¿Qué sucedería si cambiáramos nuestra función de salud en la región de EE. UU. para que muestre el error 404 (o cualquier otra respuesta de error)? Veamos qué sucederá:
La comprobación de estado de Route53 llama a nuestro Lambda y obtiene una respuesta de error.
Después de X intentos consecutivos (número configurado), Route53 marcará el punto final de EE. UU. como no saludable.
Ante una solicitud de resolución, Route53 buscará el punto final saludable más cercano y siempre utilizará la URL de la UE.
Misión cumplida. Ahora simulamos una falla en la región de EE. UU. en nuestra arquitectura.
Nos detendremos aquí con nuestro ejemplo y analizaremos cómo podemos cambiar nuestra función Lambda para que devuelva un código de error. En futuras publicaciones, proporcionaremos un ejemplo completo y analizaremos todos los pasos.
Inyección de fallos en la función Lambda
Al momento de escribir estas líneas, existen dos enfoques principales para simular fallas en una función Lambda:
Utilice una biblioteca en su código Lambda.
Utilice una extensión Lambda (también presentada en esta publicación del blog).
Entremos en más detalles y expliquemos cada enfoque.
Utilice una biblioteca en su código Lambda
Puede utilizar una biblioteca como chaos_lambda o failure-lambda en su código Lambda. Agregar esas bibliotecas le permite encapsular su controlador e inyectarle errores cuando sea necesario. Ambas bibliotecas son configurables y admiten lo siguiente:
Habilitado — Verdadero/Falso.
Tipo de error: código de error HTTP, excepción y más.
Valor de error: valor de retorno que coincide con el tipo. Por ejemplo, 404 en caso de un error de tipo HTTP.
Tasa: controla la tasa de falla. 1 significa que la falla se inyecta en todas las solicitudes, mientras que 0,5 significa que se inyecta en la mitad de las invocaciones.
Puede leer más sobre los valores de configuración admitidos utilizando los enlaces de arriba.
Volvamos a nuestro ejemplo y veamos cómo podemos simular una falla en la región de EE. UU.:
Agregue una de las bibliotecas a nuestra función Lambda en la región de EE. UU.
Habilítelo y configure el tipo de error HTTP con un valor 404.
Route53 llama a nuestra función, invocando la biblioteca.
La biblioteca devuelve inmediatamente 404, omitiendo el controlador.
Utilice una extensión Lambda
Este enfoque es similar al primero. La principal diferencia es que lo adjuntamos a nuestra función Lambda como una capa . sin cambiar su código.
Podemos utilizar chaos-lambda-extension como nuestra extensión. Para inyectar errores, debemos:
Añade la extensión como una capa.
Configure nuestro Lambda para usar la extensión configurando la variable de entorno AWS_LAMBDA_EXEC_WRAPPER (explicada en el archivo README de la extensión).
Habilite una falla de respuesta con un código de estado 404 configurando variables de entorno adicionales (explicadas en el archivo README de la extensión).
Y eso es todo. Ahora podemos simular un error 404 como en el primer enfoque.
Comparemos ahora ambos enfoques.
Comparación de enfoques
Acercarse | Ventajas | Contras |
Utilice una biblioteca en su código Lambda |
|
|
Utilice una extensión Lambda |
|
|
Como puede ver en la tabla anterior, el primer enfoque es más sencillo. Sin embargo, es posible que solo se adapte a aplicaciones que utilicen algunas funciones Lambda diferentes. Prefiero el segundo enfoque y me centraré en él en una próxima publicación.
Resumen
A medida que las arquitecturas sin servidor se vuelven cada vez más comunes, existe una necesidad cada vez mayor de verificar la resiliencia de nuestros sistemas. La ingeniería del caos surge como un aliado vital, ofreciendo un enfoque proactivo para validar nuestras suposiciones ante posibles fallas. Al adoptar la ingeniería del caos, las organizaciones pueden navegar con confianza por las complejidades de los entornos sin servidor, asegurando servicios ininterrumpidos incluso ante la adversidad.
En esta publicación, nos centramos en los desafíos que enfrentamos cuando queremos realizar experimentos de caos en una arquitectura sin servidor. Acompáñenme en mi próxima publicación, en la que repasaré todos los pasos presentados en esta publicación y les proporcionaré ejemplos de código.