Dominando el Caos en Cargas de Trabajo Sin Servidores - Speaker Deck

La ingeniería del caos implica provocar intencionalmente interrupciones en las cargas de trabajo, generalmente en servidores tradicionales. En esta char…

speakerdeck.com

Dominando el Caos en Cargas de Trabajo Sin Servidores

La ingeniería del caos es la práctica de introducir fallos intencional y proactivamente en un sistema para identificar y solucionar debilidades. Esta definición suena contraintuitiva — ¿por qué romper algo que funciona? — pero la premisa es simple: si no pruebas cómo falla tu sistema en condiciones controladas, lo descubrirás en el peor momento posible.

Los beneficios son concretos: mejor resiliencia, mayor disponibilidad, experiencia de usuario más confiable, y equipos que confían en sus sistemas porque los han probado de verdad.

Pre-requisitos antes de introducir el caos

No se puede empezar a romper cosas sin preparación. Antes de ejecutar cualquier experimento de caos en un entorno serverless, hay cinco condiciones que deben estar cubiertas.

Primero, necesitas tener pruebas existentes — un suite de tests que defina qué es comportamiento correcto, para poder detectar desviaciones cuando introduces fallos.
Segundo, debes conocer a fondo la arquitectura: qué servicios están involucrados, cómo se comunican, qué dependencias existen.
Tercero, hay que determinar alcances y riesgos antes de ejecutar, no durante — saber exactamente qué se puede afectar y qué queda fuera de scope.
Cuarto, es preferible contar con entornos dedicados para los experimentos más agresivos; no todo debe probarse en producción desde el primer día.
Quinto, necesitas monitoreo y observabilidad en su lugar antes de comenzar, porque sin métricas no puedes saber qué está pasando durante el experimento.

El ciclo del caos

La ingeniería del caos no es caos sin estructura — es un ciclo bien definido. Empieza con una hipótesis: una pregunta específica sobre el comportamiento del sistema bajo estrés. A partir de ella se diseña un experimento, se crean los fallos, se analizan los resultados, se corrigen los fallos encontrados, se valida la hipótesis, y los aprendizajes alimentan mejora continua que genera nuevas hipótesis. El ciclo se repite.

El diseño de cada experimento sigue cuatro pasos: definir el estado estable (los KPIs que representan operación normal), formular la hipótesis (qué se espera que pase bajo estrés), especificar la definición y ejecución (tipos de fallo, sistemas a probar, condiciones), y establecer el monitoreo y análisis (cómo se verificarán los KPIs y las desviaciones).

Un ejemplo concreto: dado un API Gateway multi-región con funciones Lambda detrás de un enrutamiento basado en latencia, la hipótesis sería que inyectar latencia en una región no debería afectar el rendimiento de las demás, y que Route 53 debería detectar el aumento de latencia y redirigir el tráfico a una región más saludable. La ejecución del experimento tendría tres componentes: acción (inyectar latencia en Lambda), objetivo (funciones Lambda en una región específica), y condición de monitoreo (métricas de latencia en CloudWatch).

Técnicas de inyección de fallos

Hay tres categorías principales de fallos que se pueden inyectar en entornos serverless.

Resiliencia de red cubre latencia en respuestas y pérdida de paquetes — los fallos más comunes en sistemas distribuidos y los más fáciles de introducir de forma controlada.

Interrupciones simula servicios no disponibles y respuestas inesperadas — el escenario donde una dependencia simplemente deja de responder o responde con errores.

Límites prueba qué pasa cuando se alcanzan los topes de uso de APIs, memoria, o tiempo de ejecución — particularmente relevante en Lambda donde estos límites son hardcoded.

Más allá de la capa de red, los fallos también pueden inyectarse a nivel de código, de ambiente, o de configuración — tres vectores distintos que cubren la mayoría de los escenarios de fallo reales.

Herramientas disponibles en AWS

Para entornos serverless en AWS, hay cuatro opciones principales que vale comparar:

AWS Fault Injection Service (FIS) es el servicio nativo de AWS, 100% manejado e integrado con el ecosistema. Es programable desde consola, CLI y CDK, permite experimentos controlados tanto en secuencia como en paralelo, y opera a todos los niveles — red, infra, aplicación. Tiene excelente documentación pero tiene costo por uso.

Chaos Toolkit es una herramienta open source para caos en entornos generales. Documentación buena, facilidad media, gratuita.

Chaos_lambda está enfocada en fallos a nivel de runtime de Lambda. Documentación limitada, gratuita.

Failure Lambda opera a nivel de código de Lambda. También gratuita pero con documentación limitada.

Para la mayoría de los casos en AWS, FIS es la opción más práctica por su integración nativa y el nivel de control que ofrece.

AWS Fault Injection Service en detalle

Un experimento en FIS se construye con cuatro componentes: una plantilla de experimento que define todo lo que va a ocurrir, acciones que especifican qué fallos se van a introducir, objetivos que determinan sobre qué recursos se aplican (por ejemplo, instancias EC2 con tags específicos), y condiciones de paro vinculadas a alarmas de CloudWatch que detienen el experimento si las cosas se salen de control.

Para entornos serverless específicamente, FIS soporta los siguientes fallos: DynamoDB no responde, una región completa no funciona, Lambda tarda mucho en responder, Lambda responde con error, y throttling de API. Estos cubren los escenarios de fallo más comunes en arquitecturas event-driven y de microservicios sin servidor.

El monitoreo durante los experimentos se hace con CloudWatch para métricas, X-Ray para rastreo distribuido, y dashboards personalizados que permiten ver el comportamiento en tiempo real mientras el experimento está activo.

La arquitectura de implementación de FIS para Lambda sigue un flujo claro: FIS lee una plantilla de experimento, ejecuta una automatización que interactúa con Parameter Store para configurar el comportamiento de caos, y la Lambda bajo prueba reporta métricas a CloudWatch. En el caso del patrón Chaos Injection Lambda Layers, FIS orquesta a través de una plantilla y una automatización que actualiza Parameter Store, y la Lambda tiene un Chaos Lambda Layer adicional que lee esa configuración e inyecta el comportamiento anómalo antes de ejecutar el código de negocio. Esto permite activar y desactivar el caos sin modificar el código de la función.

La extensión chaos-lambda-extension es otro patrón que opera dentro del ambiente de ejecución de Lambda: se registra como una extension que se ejecuta junto al runtime, intercepta las invocaciones a través de la Extension API y la Runtime API, e inyecta los fallos configurados antes de que el código de la función se ejecute. Es más invasiva que las Lambda Layers pero también más precisa.

Técnicas de resiliencia para responder al caos

Identificar dónde falla el sistema es la mitad del trabajo. La otra mitad es construir resiliencia que haga que los fallos sean manejables. Hay tres principios fundamentales para aplicaciones serverless con tolerancia a fallos:

Redundancia significa tener múltiples instancias de los componentes críticos — en el contexto serverless, esto se traduce en deployments multi-región, DLQs para mensajes fallidos, y funciones de respaldo.

Degradación elegante implica mantener funcionalidad parcial cuando un componente falla. En lugar de retornar un error 500, la aplicación retorna una respuesta reducida pero funcional — datos en caché, respuestas por defecto, o funcionalidad limitada con un mensaje claro al usuario.

Recuperación automatizada significa que los procesos de recuperación de fallos no dependen de intervención manual. Los runbooks deben ejecutarse solos.

A nivel de código, las tres técnicas más importantes son lógica de reintento con backoff exponencial, circuit breakers, y throttling.

La lógica de reintento con backoff exponencial es el patrón básico de resiliencia para fallos transitorios. En Python con boto3, se traduce a reintentar la operación hasta N veces, con un time.sleep(2 ** attempt) entre intentos — los tiempos de espera crecen exponencialmente para no sobrecargar un servicio que ya está bajo presión.

Los circuit breakers son más sofisticados: un objeto que rastrea el número de fallos consecutivos y, cuando supera un umbral, abre el circuito durante un período de recuperación. Durante ese período, las llamadas fallan inmediatamente sin intentar la operación, dando tiempo al servicio dependiente de recuperarse. Una vez pasado el timeout de recuperación, el circuito se cierra y las operaciones se reanudan.

Los límites de throttling en API Gateway, configurados a través de UsagePlans con BurstLimit y RateLimit, protegen los backends de ser sobrecargados bajo picos de tráfico inesperados.

Mejores prácticas

Independientemente de las herramientas que uses, hay cinco principios que aplican a cualquier práctica de ingeniería del caos:

Comenzar pequeño. El primer experimento no debe ser "apagamos una región". Empieza con latencia en una función, en un ambiente de staging, con radio de blast controlado.

Automatizar. Los experimentos ejecutados manualmente son inconsistentes y difíciles de repetir. Automatizar la ejecución, el monitoreo y la condición de paro desde el principio.

Monitorear de cerca. No ejecutes un experimento y te vayas a hacer otra cosa. El valor está en observar el comportamiento en tiempo real.

Comunicar. El equipo necesita saber cuándo se está ejecutando un experimento, qué se está probando, y cuál es el plan de rollback. Los experimentos no anunciados generan pánico innecesario.

Documentar. Cada experimento, sus resultados, y los cambios que generó deben quedar registrados. La ingeniería del caos sin documentación es simplemente romper cosas.

Resumen

La ingeniería del caos en entornos serverless no es una práctica de nicho — es una necesidad para cualquier sistema que aspire a alta disponibilidad. AWS FIS hace que sea significativamente más accesible.