Cómo Netflix Optimizó su Infraestructura con Chaos Engineering
Los sistemas actuales se han, y se vuelven, cada vez más complejos y sofisticados, basados en sistemas distribuidos para soportar la carga y aumentar la resiliencia de los mismos, para evitar las caídas potenciales, y, por lo tanto, la pérdida de confianza o valor aportado.
En el competitivo mundo del streaming y la tecnología, esta disponibilidad del servicio es crucial. Netflix, siendo uno de los líderes en la industria del entretenimiento en línea, planteó el uso del conocido como “Chaos Engineering” para optimizar su infraestructura y poder ofrecer un servicio de alta disponibilidad y rendimiento.
En este artículo, exploraremos qué es “Chaos Engineer”, los principios que pueden aplicarse a las diferentes organizaciones en el mercado y cómo Netflix utiliza Chaos Engineering para fortalecer su infraestructura
Qué es Chaos Engineering
Chaos Engineering es una disciplina que busca mejorar la resiliencia de los sistemas complejos mediante la introducción deliberada de fallos y perturbaciones en un entorno controlado. Está basada en la “Teoría del Caos”, cuya focalización reside en estudiar el impacto de comportamientos impredecibles en el funcionamiento de los sistemas,
El objetivo, por lo tanto, es observar cómo el sistema responde a estos fallos o comportamientos y utilizar los datos obtenidos para mejorar la capacidad del sistema para manejar problemas reales.
Está implementación, se basa en los siguientes principios, los cuales siguen de cerca, el método científico clásico: observación de fenómenos, formulación de hipótesis explicativas, y confirmación o refutación de las mismas mediante experimentación.
Principios Clave de Chaos Engineering:
Definición del estado normal: Inicialmente se debe definir las bases del experimento, indicando cual es el estado natural del sistema, sin la presencia de comportamientos no controlados. Una buena medida para estas cuestiones, suele ser definir los KPIs bases del sistema: tasa de errores, latencia…
Creación de hipótesis: se debe establecer unas hipótesis para definir la evolución de las cuestiones definidas con anterioridad (KPIs), o el comportamiento de las mismas, ante la implantación de comportamientos definidos en el sistema. Una hipótesis válida puede ser la siguiente: Si la base de datos primaria falla, el sistema realizará automáticamente una conmutación por error a la base de datos secundaria con un tiempo de inactividad mínimo.
Realización de experimentos en producción: a partir de la definición de hipótesis sobre los diferentes posibles comportamientos del sistema, se deben aplicar eventos reales que puedan ocurrir sobre el sistema, desde que la base de datos primaria falle, hasta que aumente el tráfico en un 20%, hasta que, en el caso de la nube, una región entera falle.
Estos, a su vez, se deben aplicar sobre sistemas reales, con tráfico real, para poder comprobar el comportamiento verídico del sistema ante estas cuestiones.
Automatización de experimentos: Estos experimentos, ya que, su realización manual conllevaría un coste muy alto, con la inclusión adicional de cuestiones subjetivas, o fallos humanos, se vuelve conveniente su automatización para su ejecución continua o en marcos de tiempo determinados.
Minimizar el impacto: al ser pruebas que se realizan directamente sobre el entorno de producción, son pruebas con el potencial de afectar notablemente la entrega de valor del proyecto, por lo que se vuelve necesario que estos experimentos se focalicen lo máximo posible para que, en caso de un fallo inesperado, la afectación del sistema sea lo más pequeña posible.
Si bien es cierto que no se tiene en cuenta como un principio clave, es importante señalar que la observabilidad y la monitorización de los sistemas es una cuestión básica y obligatoria para poder realizar estos experimentos, y, por lo tanto, tiene que estar definida con anterioridad. Ya que, sin esta cuestión, no podremos analizar y valorar cómo se está comportando el sistema de forma real ante los comportamientos introducidos.
Beneficios y Desafíos de abrazar el Caos
Aunque introducir el caos en los sistemas conlleva una serie notable de beneficios en diversos aspectos del sistema, el equipo y la evolución y seguridad del mismo (como se detallará a continuación, según la implementación realizada por Netflix), también surgen una serie de desafíos que deben ser cuidadosamente considerados
Beneficios de la ingeniería del caos
Mejora en la resiliencia y disponibilidad del sistema: La ingeniería del caos busca identificar posibles problemas cuando el sistema enfrenta circunstancias inesperadas. Este enfoque proactivo para detectar problemas ayuda a mejorar las estrategias de resiliencia existentes y a ganar confianza en la fiabilidad de los sistemas.
Prevención de pérdidas de ingresos: Dependiendo de la criticidad y el uso del sistema, una interrupción inesperada puede resultar en la pérdida de miles de millones de dólares en ingresos. Las pruebas de caos ayudan a prevenir estas pérdidas y a reducir los costos de mantenimiento.
Desarrollo de un conocimiento profundo del sistema: La ingeniería del caos genera nuevo conocimiento sobre los sistemas. Ayuda a las organizaciones a comprender mejor los comportamientos del sistema, sus dependencias y otras interacciones con diferentes componentes. Este conocimiento profundo facilita la creación de arquitecturas más robustas en el futuro.
Mejora en la recuperación ante fallos: Dado que las pruebas de caos proporcionan una comprensión clara del comportamiento del sistema en diferentes condiciones de interrupción, las organizaciones pueden acelerar la recuperación en caso de que ocurran fallos similares.
Incremento en la satisfacción del cliente: La ingeniería del caos mejora la recuperación ante fallos y reduce el tiempo de inactividad, fortaleciendo la reputación de la empresa como un sistema confiable y fomentando la satisfacción del cliente.
Desafíos de la ingeniería del caos
Riesgo de interrupciones: Dado que las pruebas de ingeniería del caos se realizan en sistemas de producción, existe el riesgo de pérdida de datos o interrupciones en el servicio, por lo que es crucial llevar a cabo una planificación y ejecución cuidadosas de las pruebas.
Limitaciones de recursos: La ingeniería del caos requiere herramientas y recursos humanos para planificar y ejecutar las pruebas, lo que puede ser un factor limitante para algunas organizaciones.
Necesidad de sistemas de monitorización robustos: Las pruebas de caos requieren sistemas de monitorización sólidos para observar la salud del sistema y otros indicadores clave, lo que hace crucial realizar inversiones previas y seleccionar cuidadosamente una herramienta de monitorización confiable para mejorar la efectividad de la ingeniería del caos.
El Enfoque de Netflix: Simian Army
Al realizar la migración a la nube, la cual no garantiza un tiempo de actividad del 100%, se vieron obligados a diseñar una infraestructura capaz de soportar el fallo de cualquiera de sus elementos, basándose en la siguiente premisa:
“Debemos ser más fuertes que nuestro eslabón más débil. Para afrontar esta problemática, surgió un ejemplo o perspectiva basada en el mundo real, sobre la cual, la mayoría de nosotros nos podemos sentir identificados: “Imagina que te quedas con una rueda pinchada. Aunque tengas una rueda de repuesto en tu maletero, ¿sabes si está inflada? ¿Tienes las herramientas para cambiarla? Y, lo más importante, ¿recuerdas cómo hacerlo correctamente? Una forma de asegurarte de que puedes manejar un pinchazo en la autopista, bajo la lluvia, en medio de la noche, es pinchar una rueda una vez a la semana practicar el proceso de reemplazo.”
Para seguir este principio en sus sistemas, realizaron la traducción del planteamiento al mundo técnico, lo que dio vida a la herramienta de “Chaos Monkey”: una herramienta que apaga de forma aleatoria las instancias de producción para asegurar que el sistema puede seguir funcionando en cualquier momento.
Si bien es cierto que este ha sido su punto de partida, este esquema inicial ha ido evolucionando notablemente con el tiempo, agrupando y dando vida a diferentes herramientas, las cuales tienen propósitos diferentes dentro del ecosistema, y se responsabilizan de realizar experimentos definidos en los diferentes aspectos tecnológicos dentro de la infraestructura, desde variación de latencia, hasta posibles vulnerabilidades de seguridad.
Esta evolución, y conjunto de herramientas, se ha agrupado en lo que han llamado “Simian Army”, y que actualmente se compone de las siguientes herramientas:
Latency Monkey induce retrasos artificiales en nuestra capa de comunicación cliente-servidor RESTful para simular la degradación del servicio y medir si los servicios ascendentes responden adecuadamente. Además, al generar retrasos muy grandes, podemos simular una caída de un nodo o incluso de un servicio entero (y probar nuestra capacidad para sobrevivir a ello) sin necesidad de apagar físicamente estas instancias. Esto resulta particularmente útil cuando se prueba la tolerancia a fallos de un nuevo servicio al simular la falla de sus dependencias, sin hacer que estas dependencias queden inaccesibles para el resto del sistema.
Conformity Monkey identifica instancias que no cumplen con las mejores prácticas y las apaga. Por ejemplo, si encontramos instancias que no pertenecen a un grupo de autoescalado, sabemos que se avecina un problema. Las apagamos para darle al propietario del servicio la oportunidad de realizarlas correctamente.
Doctor Monkey revisa las comprobaciones de salud que se ejecutan en cada instancia, así como otros signos externos de salud (por ejemplo, la carga de CPU), para detectar instancias no saludables. Una vez detectadas las instancias no saludables, se eliminan del servicio y, después de dar tiempo a los propietarios del servicio para identificar la causa del problema, se terminan eventualmente.
Janitor Monkey asegura que nuestro entorno en la nube esté libre de desorden y desperdicios. Busca recursos no utilizados y los elimina.
Security Monkey es una extensión de Conformity Monkey. Encuentra violaciones de seguridad o vulnerabilidades, como grupos de seguridad de AWS mal configurados, y termina las instancias problemáticas. También asegura que todos nuestros certificados SSL y DRM sean válidos y que no estén próximos a su vencimiento.
10–18 Monkey (abreviatura de Localization-Internationalization, o l10n-i18n) detecta problemas de configuración y de tiempo de ejecución en instancias que sirven a clientes en múltiples regiones geográficas, utilizando diferentes idiomas y conjuntos de caracteres.
Chaos Gorilla es similar a Chaos Monkey, pero simula una caída de toda una zona de disponibilidad de Amazon. Queremos verificar que nuestros servicios se redistribuyan automáticamente a las zonas de disponibilidad funcionales sin impacto visible para el usuario o intervención manual.
Conclusión
La práctica de Chaos Engineering no solo es efectiva para mejorar la resiliencia y la disponibilidad del sistema, sino que también puede ser una práctica necesaria en sistemas distribuidos, principalmente localizados en la nube, y que deben ser tolerantes a cualquier tipo de fallo, asegurando siempre la entrega de valor de forma confiable.
Aplicando está práctica, Netflix ha optimizado su infraestructura y asegurado que sus servicios permanezcan robustos frente a los desafíos inesperados, evolucionando esta práctica hasta poder cubrir de forma mayoritaria su stack tecnológico.
Siguiendo el ejemplo de Netflix y basándose en los principios de esta disciplina, otras organizaciones que busquen mejorar la resiliencia de sus sistemas pueden aplicar o adaptar estas prácticas para fortalecer su propia infraestructura.