Chaos Engineering son experimentos cuidadosamente pensados, planeados y diseñados para revelar debilidades en nuestros sistemas.

1. Chaos
Engineering
ANGEL NUÑEZ Enterprise Agility Consultant

2. ANGEL NUÑEZ
Enterprise Agility
Consultant
angel.nunez@kleer.la
@snahider

3. Las Aplicaciones Son Cada Vez
Más Complejas
Amazon Netflix Twitter
“Death Star” Architecture Diagrams

4. El mundo es naturalmente Complejo
• Los discos pueden fallar.
• La red no es confiable y se puede caer.
• Fallos en cascada por circunstancias no usuales.
• Los sistemas distribuidos tienen muchas partes movibles.
• Aumento inesperado en el tráfico.
• El ambiente está lleno de ‘unknows’.
• Muchas cosas están fuera de nuestro control.

5. AWS Outage: Feb 28, 2017
• Simple Storage Service (S3) se cayo en US-EAST.
• Otros servicios que dependían de S3 se vieron afectados
(EC2, EBS, Lambda, etc.).
• La caída duró aproximadamente 4 horas.
• 1,000,000 sitios al rededor US se vieron impactados.
Incident report: https://aws.amazon.com/message/41926

6. Las Caídas Ocurren
Hay muchos más casos que puedes leer aquí:
https://github.com/danluu/post-mortems

7. ¿Por qué tener miedo del Caos
cuando es Inevitable?
Failures are a given and
everything will
eventually fail over time
Werner Vogels
CTO - Amazon.com

8. Chaos Engineering
Thoughtful, planned experiments
designed to reveal
weaknesses in your system.
Kolton Andrus
CEO - Gremlin Inc.

9. Unit Tests e Integration Tests
Componente A
OutputInput
Unit Tests
Servicio A Servicio B
Input Output
Integration Tests

10. Chaos Experiments
Servicio A Servicio B
Input Output
No verificamos “Knows” sino exploramos “Unknows”

11. AWS Outage

12. Historia
2004 Amazon – Jesse Robbins. Master of disaster.
2010 Netflix – 1ra implementación de Chaos Monkey
para forzar el uso de auto-scaled staless services.
2012 NetflixOSS libera Simian Army (Open Source)
2014 Netflix decide crear el rol Chaos Engineer
2016 Gremlin Inc. se fundó.
2017 Netflix Chaos Engineering book.
Chaos Toolking (OSS project)
2018 1er Chaos Conference.
Año en que Chaos Eng. se ha difundido significativamente.

13. Mas Historia
(Empresas, Personas, Herramientas y Prácticas)
https://coggle.it/diagram/WiKceGDAwgABrmyv/t/chaos-engineering-companies%2C-people%2C-tools-practices

14. Un Caso Personal
Payment UI
Auth Service Payment Service
Message Queue (RabbitMQ)
Worker
Status
Listener
Notification
Service
Payments Core
Cache Service
(Redis)
Transaction Map
(MongoDB)
Publish
Consume Publish Consume
v1.1.8
(Dic. 2015)
Inhouse + Azure
Datacenter
Asynchronous Completion Token. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.44.9371&rep=rep1&type=pdf
Mediante la experimentación encontramos:
- Cuando varios contenedores se caían, la experiencia al
usuario se degrabada, por que demoraba mucho la
reconección.
- Cuando los contenedores se reprogramaban, la
redundancia se perdía, por que K8S redesplegaba varios
en el mismo nodo.
- Cuando se caía el 75% de instancias del Payment, la
experiencia se degrabada, por que las instancias restantes
no aguantaban la carga.
- Cuando la latencia del core es muy lenta, el pool de hilos
del worker se terminaba, por que los timeouts eran muy
grandes.
- Cuando un tópico de RabbitMQ se eliminaba, la cola
dejaba de funcionar, por que nadie recreaba el tópico.
…

15. Pre-requisitos
• Timeouts
• Retries & Bake-offs.
• Exception handling.
• Circuit breakers.
• Load Shedding
Application
• Redundancy
• Self-healing
• Bulkheads
• Infrastructure as
Code
Infrastructure
• Monitoreo y
Observabilidad.
• Incident
Management.
Operations

16. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

17. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

18. Definir un “Steady State”
Resultado medible del sistema que indica ‘salud’
(combinación de Business + Ops)
Netflix ‘stream starts per second’, comparando dos semanas (rojo = semana actual, negro = semana pasada)

19. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

20. Cómo diseñar un Experimento
• Identificar los top servicios/componentes críticos.
• Elegir un componente y entenderlo.
• ¿Qué puede salir mal?
¿Sabemos que pasará si esto rompe?
• Seleccionar el ataque.
• Determinar un Blast Radius pequeño.
• Determinar métricas adicionales a revisar.

21. Puedes inyectar chaos en cada capa
del sistema
• Application (CPU, Memory, Disk, I/O)
• API (fallbacks)
• Cache, Database, Queues (kill topics)
• Network (latency, dns, packet loss)
• Operating System (kill processes, shutdown, time travel)
• Cloud Infraestructure / Bare Metal (región outage)

22. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

23. Chaos Tools
https://github.com/dastergon/awesome-chaos-engineering#notable-tools

24. Simian Army
Conjunto de herramientas que ayudan a mantener
la nube operando en buena forma.
- Apagar servicios aleatoriamente (Chaos Monkey).
- Agregar lentitud a la comunicación (Latency
Monkey).
- Apagar servidores que no sigan mejores
prácticas (Conformity Monkey).
- Apagar instancias con violaciones de seguridad
(Security Monkey).
* Simian Army ya no se mantiene activamente. Nueva versión de Chaos Monkey está disponible como herramienta independiente, y las
otras funcionalidades se han movido a otros proyectos de Netflix.

25. Chaos Toolkit
Simplifica la adopción de Chaos Engineering:
- Open API declarativa para crear
experimentos de caos.
- Muchas extensiones para diferentes
herramientas, servicios clouds,
monitoreo.
- Se integra fácilmente con Pipelines de
CI/CD.

26. Gremlin
Chaos as a Service:
- Utiliza agentes en los hosts o
contenedores para realizar ataques.
- Se pueden programar ataques
utilizando UI, API o CLI.
- Provee muchos ataques de caja y se
integra con Chaos Toolkit para otros
ataques.

27. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

28. Cuantificar otros resultados
• ¿Time to detect?
• ¿Time to notification?
• ¿Time to self healing?
• ¿Time to recovery - partial, full?

29. Profundizar en los resultados
Resultados
del
Experimento
Porque …Porque …Porque …Porque …

30. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

31. Scale or Squash
¿Encontraste un problema? Buen trabajo.
Para el experimento. Sino incrementa el Blast Radius.

32. Run
Experiment
Cómo practicar Chaos Engineering
Scale or
Squash
Verify
Results
Steady
State
Improve
Hypothesis

33. Chaos Experiment (Demo)
Hypothesis No hay impacto en el cliente.
Attack Condition Duration: 180s (4 min)
Attack: Shutdown containers
Targets: 50% of available containers
Collect Data Latencia y Disponibilidad (Vegeta)
Reinicios del Container (Prometheus)
Logs de la Aplicación (Kubectl)
Result Latency: ?
Customer Impact: ?
Otros Hallazgos: ??

34. Introducir caos de manera
controlada conduce a tener
sistemas cada vez más resistentes.

35. ¿Cómo puedes continuar tu camino en
Chaos Engineering?
http://gremlim.com/slack

36. Ejecuta tu primer Chaos Day
Día dedicado de todo el equipo para enfocarse en utilizar
Chaos Engineering para revelar problemas, e implementar
resilencia en los sistemas.
https://www.gremlin.com/community/tutorials/planning-your-own-chaos-day/

37. Revisa las siguientes fuentes
Lista curada de recursos sobre Chaos Engineering
https://github.com/dastergon/awesome-chaos-engineering
Principles of Chaos Engineering
https://principlesofchaos.org
Chaos Engineering book
https://www.oreilly.com/library/view/chaos-engineering/9781491988459/

38. Preguntas
ANGEL NUÑEZ
Enterprise Agility
Consultant
angel.nunez@kleer.la
@snahider