Ingeniería del caos en la práctica - Verificación de tolerancia a fallos con AWS Fault Injection Simulator
Aprenda sobre la práctica de ingeniería del caos con AWS Fault Injection Simulator (FIS). Cubre el diseño de escenarios de inyección de fallos, la inyección de fallos en EC2, ECS y RDS, y la realización de experimentos seguros.
La necesidad de la ingeniería del caos y el rol de FIS
Los fallos en entornos de producción ocurren en momentos impredecibles. Terminación repentina de instancias EC2, fallos de AZ, aumento de latencia de red, conmutaciones por error de bases de datos: la ingeniería del caos es la práctica de verificar de antemano si su sistema se comporta correctamente ante estos fallos mediante la inyección intencional de errores. Originada del Chaos Monkey de Netflix, este enfoque inyecta fallos intencionalmente para verificar la tolerancia a fallos del sistema. AWS Fault Injection Simulator (FIS), lanzado en 2021, es un servicio administrado de ingeniería del caos que ejecuta inyección de fallos contra recursos AWS de manera segura y controlada. Elimina la necesidad de construir y operar sus propias herramientas de ingeniería del caos, y mediante la integración nativa con servicios AWS, puede inyectar fallos en una amplia gama de recursos incluyendo EC2, ECS, EKS, RDS, ElastiCache y Systems Manager.
Diseño de plantillas de experimentos
Los experimentos de FIS se definen usando plantillas de experimentos. Una plantilla consta de tres elementos: acciones (qué hacer), objetivos (qué recursos afectar) y condiciones de parada (cuándo abortar). Ejemplos de acciones incluyen aws:ec2:stop-instances (detener instancias EC2), aws:ec2:send-spot-instance-interruptions (simular interrupciones Spot), aws:ssm:send-command (estrés de CPU/memoria vía SSM), aws:ecs:stop-task (detener tareas ECS), aws:rds:failover-db-cluster (conmutación por error de Aurora) y aws:fis:inject-api-internal-error (inyección de errores de API AWS). ```json { "description": "EC2 instance stop experiment", "targets": { "ec2Instances": { "resourceType": "aws:ec2:instance", "resourceTags": {"Environment": "dev"}, "selectionMode": "COUNT(1)" } }, "actions": { "stopInstances": { "actionId": "aws:ec2:stop-instances", "parameters": {"startInstancesAfterDuration": "PT5M"}, "targets": {"Instances": "ec2Instances"} } }, "stopConditions": [ {"source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:ap-northeast-1:123:alarm:high-error-rate"} ], "roleArn": "arn:aws:iam::123:role/FISExperimentRole" } ``` El selectionMode del objetivo controla cómo se seleccionan los recursos objetivo. COUNT(1) apunta a un solo recurso, mientras que PERCENT(50) apunta al 50% de los recursos. El filtrado basado en etiquetas permite limitar el alcance de los experimentos.
Realización de experimentos seguros
El aspecto más importante de la ingeniería del caos es garantizar la seguridad. FIS proporciona múltiples mecanismos de seguridad. Las condiciones de parada monitorean alarmas de CloudWatch y detienen automáticamente los experimentos cuando las tasas de error o la latencia superan los umbrales. Esto evita que los experimentos tengan un impacto excesivo en los servicios de producción. Los roles IAM restringen los permisos del experimento al mínimo necesario, previniendo el impacto en recursos fuera del alcance del experimento. La expansión gradual de los experimentos también es una práctica importante. Comience con experimentos a pequeña escala en un entorno de desarrollo (deteniendo una instancia), verifique los resultados y luego amplíe el alcance. A continuación, ejecute experimentos en un entorno de staging bajo condiciones cercanas a producción, y finalmente realice experimentos limitados en el entorno de producción. Formar una hipótesis antes del experimento (por ejemplo, "Incluso si una instancia EC2 se detiene, el ALB debería redistribuir automáticamente el tráfico y la tasa de error debería mantenerse por debajo del 1%") también es importante: cuando una hipótesis se refuta, identifica claramente áreas de mejora del sistema. Para conocimientos prácticos sobre diseño de tolerancia a fallos, libros relacionados en Amazon también pueden ser una referencia útil.
Escenarios prácticos de experimentos
A continuación se presentan algunos escenarios de experimentos representativos. Para la simulación de fallo de AZ, detenga simultáneamente instancias EC2 en una AZ específica y verifique que el Auto Scaling multi-AZ funcione correctamente. Para la inyección de latencia de red, ejecute comandos tc (traffic control) vía SSM para aumentar la latencia de red en instancias específicas. Esto permite verificar si la comunicación entre microservicios se maneja correctamente mediante timeouts y reintentos. Para la conmutación por error de RDS, ejecute una conmutación por error del clúster Aurora y verifique que la aplicación se reconecte automáticamente al nuevo endpoint de escritura. Para la simulación de interrupción de instancias Spot, simule el aviso de interrupción de 2 minutos y verifique que el apagado graceful de la aplicación funcione correctamente. El precio es de $0.10 USD por minuto de tiempo de ejecución de acción, por lo que un experimento de 5 minutos cuesta $0.50 USD.
Precios de FIS
Fault Injection Simulator se factura por minutos de acción. Cada minuto de acción cuesta aproximadamente $0.10, por lo que ejecutar 10 acciones durante 30 minutos cuesta aproximadamente $30. Los cargos de recursos objetivo (EC2, ECS, RDS) se aplican como de costumbre. No hay cargos adicionales por crear y almacenar plantillas de experimentos. Para experimentos en entornos de producción, diseñelos con alcance limitado y corta duración para gestionar tanto el costo como el riesgo.
Resumen - Directrices de uso de FIS
AWS Fault Injection Simulator es una herramienta que proporciona ingeniería del caos como servicio administrado, permitiendo la verificación segura de la tolerancia a fallos del sistema. Con la detención automática mediante condiciones de parada, restricciones de permisos vía IAM y expansión gradual de experimentos, puede practicar ingeniería del caos de forma segura. Recomendamos comenzar con detenciones de EC2 e inyección de latencia de red en un entorno de desarrollo, luego iterar en un ciclo de descubrimiento y mejora de debilidades del sistema. Al operar bajo la suposición de que los fallos inevitablemente ocurrirán y verificar de antemano, puede minimizar el impacto cuando ocurran fallos en producción.