Nuestra reunión de junio en Test in Production se dedicó a la ingeniería del caos. La ingeniera de software principal Norah Jones comenzó con la forma en que Netflix realiza pruebas en producción.
“Ingeniería del caos ... estos son experimentos en producción para encontrar vulnerabilidades en un sistema antes de que hagan un servicio inadecuado para los clientes. En Netflix, los ejecutamos utilizando una herramienta llamada ChAP ... [detecta] vulnerabilidades y nos permite implementar fallas en los servicios y la producción. Estas fallas confirman las suposiciones sobre estos servicios antes de provocar interrupciones completas ”.
Vea una presentación (o lea la transcripción) sobre cómo su equipo ayuda a los usuarios, ingenieros de Netflix, a realizar pruebas de producción de forma segura e identificar activamente las vulnerabilidades en sus sistemas.
Descifrado
Estoy muy contento de estar aquí hoy.
Netflix usa activamente pruebas en producción. Los hacemos a través de la ingeniería del caos, y recientemente cambiamos el nombre de nuestro equipo de Ingeniería de Resiliencia [desarrollo sostenible] porque la ingeniería del caos es una forma de lograr la sostenibilidad general. Estoy a punto de hablar sobre esto hoy.
Nuestro objetivo es aumentar el tiempo de actividad mediante la búsqueda proactiva de vulnerabilidades en los servicios. Hacemos esto a través de experimentos en producción. El equipo confía en que una cierta clase de vulnerabilidades y problemas solo se pueden detectar en el tráfico real.
En primer lugar, debe ocuparse de la seguridad y la supervisión, de lo contrario no podrá implementar pruebas normales en producción. Tales pruebas pueden dar miedo: si dan miedo, debe escuchar esta voz y descubrir por qué. Quizás porque no tienes un buen sistema de seguridad. O porque no hay un buen monitoreo. En nuestras herramientas, realmente nos preocupamos por estas cosas.
Si formulamos la ingeniería del caos en una oración, entonces esta es la disciplina de los experimentos en producción para encontrar vulnerabilidades en el sistema antes de que el servicio sea inadecuado para los clientes. En Netflix, los ejecutamos utilizando una herramienta llamada ChAP, que significa Chaos Automation Platform (Chaos Automation Platform). ChAP detecta vulnerabilidades y permite a los usuarios implementar fallas en los servicios y la producción. Estas fallas confirman las suposiciones de los usuarios sobre estos servicios antes de provocar interrupciones a gran escala.
Te diré cómo funciona la plataforma a un alto nivel. Este es un conjunto hipotético de dependencias de microservicios. Hay un cierto proxy. Envía una solicitud al servicio A, que luego diverge sin ventilador para los servicios B, C y D, y todavía hay un nivel de persistencia. El servicio D accede a Cassandra, y luego el servicio B accede al caché.
Me apresuro y resumo todo, porque la esencia comienza más allá. Queremos asegurarnos de que el servicio D sea robusto frente a un error de caché. El usuario ingresa a la interfaz ChAP y selecciona el servicio D como un servicio que observa fallas de caché y un servicio por falla. ChAP en realidad clona el servicio B en dos copias. Los usamos para el control en grupos experimentales: de alguna manera funcionan como pruebas A / B o pruebas canarias. Estas réplicas son mucho más pequeñas que el servicio B. Solo enviamos un porcentaje muy, muy pequeño de clientes a estos clústeres porque, obviamente, no queremos una falla total. Calculamos este porcentaje en función del número actual de usuarios que utilizan el servicio en este momento.
ChAP luego le indica al sistema de conmutación por error que marque las solicitudes que coinciden con nuestros criterios. Esto se hace agregando información a los encabezados de solicitud. Se crean dos conjuntos de etiquetas. En el primer conjunto de instrucciones para falla y enrutamiento a la réplica canaria, y en el segundo, solo instrucciones para enrutar al elemento de monitoreo.
Cuando el cliente RPC y el servicio A reciben las instrucciones necesarias para enrutar la solicitud, en realidad dirigen el tráfico al clúster de monitoreo o clúster experimental. Luego, el sistema de implementación de fallas en el nivel RPC del clúster experimental ve que la solicitud está marcada por falla y devuelve una respuesta fallida. Como antes, el clúster experimental ejecutará código para manejar la falla como una respuesta fallida del caché. Hacemos esto asumiendo que es tolerante a fallas, ¿verdad? Pero a veces vemos que esto no es así. Desde el punto de vista del servicio A, todo parece un comportamiento normal.
Controlamos cuidadosamente la ingeniería del caos, que puede ir muy mal. Cuando Netflix comenzó por primera vez tales experimentos, no teníamos un buen sistema de control. Lanzamos una falla artificial y nos sentamos en la habitación, con los dedos cruzados y comprobando que todo funcionaba bien. Ahora tenemos mucha más atención a la seguridad.
Analizamos las métricas comerciales clave. Uno de ellos se llama SPS (la transmisión comienza por segundo), es decir, inicia las transmisiones de video por segundo. Si piensa en lo que es más importante para el negocio de Netflix, es para que los usuarios puedan ejecutar cualquier serie en cualquier momento que lo deseen.
En los gráficos ves un experimento real. Muestra la diferencia en SPS entre los grupos experimentales y de control durante la prueba. Puede observar que los gráficos se desvían mucho entre sí, lo que no debería ser así, porque el mismo porcentaje de tráfico se envía a ambos clústeres.
Por esta razón, la prueba utiliza análisis canario automatizado. Da una señal de que muy gráficos se desviaron mucho entre sí. En este caso, la prueba se interrumpe inmediatamente para que las personas puedan trabajar normalmente con el sitio. Desde el punto de vista del usuario, esto es más como una falla a corto plazo cuando esto sucede.
Tenemos muchos otros remedios. Limitamos el volumen de tráfico de prueba en cada región, por lo que no llevamos a cabo el experimento solo en la zona oeste de los Estados Unidos 2. Los hacemos en todas partes y limitamos el número de experimentos que se pueden realizar en la región a la vez. Las pruebas pasan solo durante las horas de trabajo, por lo que no despertaremos a los ingenieros si algo sale mal. Si la prueba falla, no puede reiniciarse automáticamente hasta que alguien la corrija explícitamente manualmente y confirme: "Oye, sé que la prueba no pasó, pero arreglé todo lo que se necesita".
Es posible aplicar propiedades personalizadas a los clústeres. Esto es útil si el servicio se divide en fragmentos, como muchos servicios de Netflix. Además, puede implementar fallas según el tipo de dispositivo. Si asumimos algún problema en los dispositivos Apple o en cierto tipo de TV, podemos realizar pruebas específicamente para ellos.
ChAP encontró muchos errores. Aquí está uno de mis favoritos. Realizamos un experimento para verificar la ruta de respaldo del servicio, que es crucial para su disponibilidad, e identificamos un error allí. El problema se resolvió antes de que condujera al incidente de disponibilidad del servicio. Este es un caso realmente interesante, porque esta ruta de respaldo no se realizó con frecuencia. Por lo tanto, el usuario no sabía realmente si funcionaba correctamente y pudimos imitarlo. En realidad, causamos una falla en el servicio y verificamos si se colocó en un revestimiento y si funciona correctamente. En este caso, el usuario pensó que su servicio no era crítico o secundario, pero en realidad era un servicio crítico.
Aquí hay otro ejemplo. Realizamos un experimento para reproducir el problema durante el proceso de registro, que apareció por la noche en algunos servidores. Algo extraño estaba sucediendo con el servicio. El problema se reprodujo después de introducir un retraso de 500 milisegundos. Durante la prueba, el problema se encontró en los registros cargados en el Big Data Portal. Esto ayudó a entender por qué en algunos casos el registro no funcionó. Solo gracias al experimento ChAP logramos ver qué estaba sucediendo y por qué.
La configuración de la prueba ChAP requiere mucha información. Necesitamos encontrar los puntos apropiados para introducir errores. Los equipos deben determinar si quieren estrellarse o retrasarse. Todo depende del punto de inyección. Puede bloquear Cassandra, Hystrix (nuestro sistema de respaldo), servicio RPC, cliente RPC, S3, SQS o nuestro caché, o agregar un retraso de ellos. O hacer las dos cosas. También puedes crear combinaciones de diferentes experimentos.
Lo que debe hacer es reunirse con un equipo de servicio y llegar a una buena prueba. Tomará mucho tiempo. Al configurar un experimento, también debe definir las configuraciones ACA (Análisis automático de Canarias) o las configuraciones automáticas canarias.
Teníamos algunas configuraciones ACA listas para usar. Había una configuración de ChAP para SPS. Había uno con indicadores del sistema de monitoreo. Otro que verificó los fallos de RPS. Otro se aseguró de que nuestro servicio realmente funcione bien e implemente los errores correctamente. Nos dimos cuenta de que diseñar una prueba puede llevar mucho tiempo, y así sucedió. No se crearon muchas pruebas. Es difícil para una persona tener en cuenta todo lo que se necesita para un buen experimento. Decidimos automatizar algo con ChAP. Observamos los indicadores: a dónde y de quién van las llamadas, archivos con tiempos de espera, llamadas repetidas. Quedó claro que toda la información proviene de diferentes lugares. Era necesario agregarlo.
Escalamos el análisis al nivel de ChAP, donde es mucho más conveniente trabajar con información y puede usar Monocle. Ahora, toda la información sobre la aplicación y el clúster se puede estudiar en un solo lugar. Aquí, cada línea representa una dependencia, y estas dependencias representan un caldo de cultivo para los experimentos de ingeniería del caos.
Recopilamos toda la información en un lugar para el desarrollo del experimento, pero no entendimos que dicha agregación es muy útil en sí misma, por lo que este es un efecto secundario interesante. Puede ir aquí y ver los antipatrones asociados con un servicio en particular. Por ejemplo, se detecta una dependencia que no se consideró crítica, pero que no tiene una ruta alternativa. Obviamente, ahora ella se está volviendo crítica. Las personas podían ver desajustes de tiempo de espera, desajustes de devolución de llamada. Usamos esta información para evaluar la importancia de un experimento de cierto tipo e ingresarlo en un algoritmo que determina las prioridades.
Cada línea representa una dependencia, y estas líneas se pueden expandir. Aquí hay un ejemplo interesante.
Aquí, la línea azul en la parte superior indica el tiempo de espera de alguien, y la línea púrpura en la parte inferior indica el tiempo de ejecución habitual. Como puede ver, está muy, muy lejos del tiempo de espera. Pero la mayor parte de esta información no estaba disponible. ¿Qué sucede si ejecutamos la prueba justo debajo del tiempo de espera? Que piensas ¿Pasará él? Esta es una pregunta interesante. Estamos tratando de proporcionar a los usuarios este nivel de detalle antes de ejecutar las pruebas para que puedan sacar conclusiones y cambiar la configuración.
Quiero jugar un pequeño juego Hay una vulnerabilidad en este servicio de Netflix, intente detectarlo. Tómate un segundo y mira.
Para darle algo de contexto, el comando remoto Hystrix contiene sample-rest-client y sample-rest-client.GET. El tiempo de espera de Hystrix se establece en 500 milisegundos. Sample-rest-client.GET tiene un tiempo de espera de 200 ms con un reintento, lo cual es bueno, porque el total es de 400 milisegundos, que se ajusta al límite de Hystrix. El segundo cliente tiene tiempos de espera de 100 y 600 con un reintento.
En este caso, el reintento no puede completarse teniendo en cuenta el tiempo de espera del shell Hystrix, es decir, Hystrix rechaza la solicitud antes de que el cliente pueda recibir una respuesta. Aquí es donde radica la vulnerabilidad. Proporcionamos esta información a los usuarios. Curiosamente, la mayor parte de la lógica en la implementación de estas funciones está en diferentes lugares, y antes no podían comparar estas cosas. Pensaron que todo estaba funcionando bien, pero aquí hay un error.
¿Por qué sucedió esto? Por supuesto, es fácil para un desarrollador ver el conflicto y cambiar el tiempo de espera, ¿verdad? Pero queremos descubrir la razón. Podemos cambiar el tiempo de espera, pero ¿cómo podemos garantizar que esto no vuelva a suceder? También ayudamos a descubrir las razones.
Al crear pruebas automatizadas, también utilizamos Monocle. El usuario crea un experimento con numerosos tipos de datos de entrada. Tomamos todo esto y automatizamos la creación de tales pruebas para que los usuarios no se molesten. Creamos y priorizamos automáticamente los experimentos de Hystrix y los experimentos de RPC con demoras y fallas debido a demoras. Las configuraciones de ACA se agregan por defecto. Tenemos SPC, métricas del sistema, estadísticas de consultas y experimentos que se ejecutan automáticamente. También se crean prioridades para los experimentos. Un algoritmo de alto nivel funciona para ellos. Usamos un cubo con estadísticas RPS. Utilizamos varios reintentos y comandos relacionados de Hystrix. Todo el conjunto se pondera adecuadamente.
Además, se tiene en cuenta la cantidad de equipos sin rutas de ejecución de respaldo y cualquier impacto externo (impacto curado) que el cliente agrega a su dependencia. Las influencias externas afectan en gran medida la autorización, el registro y los procedimientos de MSF. Y realmente medimos su efecto y no realizamos experimentos si el resultado es negativo. Luego, las pruebas se clasifican y se ejecutan en orden descendente de criticidad. Cuanto mayor sea el puntaje de criticidad, antes y con mayor frecuencia comienza la prueba.
Irónicamente, Monocle nos proporcionó comentarios que nos permiten ejecutar menos pruebas en producción. Realizamos tantas pruebas que como resultado se formó un circuito de retroalimentación: vimos las conexiones entre las pruebas. Ahora puede ver archivos de configuración específicos y ver antipatrones específicos. Incluso sin pruebas para esta información, es posible entender qué causará exactamente la falla, en ese momento no lo habíamos entendido antes.
Esto ha llevado a un nuevo nivel de seguridad. Anteriormente, un experimento fallido se marcaba como resuelto. Ahora está marcado como resuelto antes de reiniciar. Pero ahora podemos agregar explícitamente influencias externas (curatoriales) a la adicción. El usuario ingresa su Monóculo e indica: este factor influye con precisión en el procedimiento de autorización. Este está en SPC. Y estamos trabajando en un ciclo de retroalimentación, de modo que si falla, también se agrega dicho efecto curatorial.
Por lo tanto, Monocle in ChAP es una herramienta importante en la que se recopila toda la información, genera experimentos automáticamente, prioriza automáticamente y busca vulnerabilidades antes de que conduzcan a paradas a gran escala. Para resumir, es importante recordar por qué estamos involucrados en la ingeniería del caos y realizar todos estos experimentos en producción. Esto se hace para comprender cómo los clientes usan el servicio y no perderlos de vista. Desea proporcionar a las personas el servicio más conveniente. Por lo tanto, el monitoreo y la seguridad son de suma importancia Netflix siempre debe mostrar video.
Gracias