Bajo la arquitectura del sistema distribuido, el enlace de llamada y la relación de acceso entre los componentes del servicio se vuelven cada vez más complejos y es difícil evaluar el impacto de la falla de un solo componente del servicio en todo el sistema. El monitoreo y las alarmas incompletas hacen que sea más difícil encontrar y localizar problemas. Al mismo tiempo, las iteraciones comerciales y tecnológicas son rápidas, y cómo garantizar continuamente la estabilidad y alta disponibilidad del sistema es un gran desafío. Por esta razón, el surgimiento de la ingeniería del caos es particularmente importante: en un rango o entorno controlable, la inyección de fallas se utiliza para mejorar continuamente la estabilidad del sistema y la alta disponibilidad, y mejorar la continuidad del negocio.
1. Introducción a la Ingeniería del Caos
1.1 Introducción a la ingeniería del caos
Chaos Engineering es un experimento controlado guiado por la experiencia en un sistema distribuido para observar el comportamiento del sistema y descubrir sus debilidades con el fin de desarrollar la capacidad y la confianza de que el sistema causará caos debido a condiciones inesperadas cuando la escala aumente. Su objetivo es aumentar la resiliencia de los sistemas ante eventos inciertos.
La ingeniería del caos es una ciencia experimental que se lleva a cabo en sistemas distribuidos, cuyo objetivo es mejorar la tolerancia a fallos del sistema y generar confianza en el sistema frente a problemas impredecibles en el entorno de producción.
La ingeniería del caos fue creada por primera vez por los ingenieros de Netflix durante el proceso de migración del sistema a AWS. Para garantizar que la falla de la instancia EC2 no afectara el negocio, se creó Chaos Monkey, que finalizaría aleatoriamente las instancias EC2 que se ejecutan en el entorno de producción. . Los ingenieros pueden comprender rápidamente si los servicios que están creando son lo suficientemente sólidos y resistentes como para tolerar fallas no planificadas. En este punto, la ingeniería del caos comenzó a surgir. En China, empresas de Internet como Alibaba han explorado y practicado la ingeniería del caos durante más de diez años y han proporcionado algunas plataformas de ingeniería del caos de código abierto, como Chaos Blade. [1]
Después de comprender la historia del desarrollo de la ingeniería del caos, echemos un vistazo a lo que la ingeniería del caos puede hacer en la infraestructura distribuida y el valor que aporta. Desde dos perspectivas diferentes de las funciones de los productos del sistema y los escenarios de aplicación, la ingeniería del caos puede verificar la estabilidad y confiabilidad del sistema y mejorar la previsibilidad y la previsibilidad del sistema. [2]
- La ingeniería del caos mejora diferentes funciones en el desarrollo de sistemas
- Para los arquitectos de sistemas y aplicaciones, es posible verificar la tolerancia a fallos de la arquitectura del sistema.
- Para operación, mantenimiento y desarrollo, puede mejorar la eficiencia de emergencia de fallas y realizar alarmas oportunas, posicionamiento preciso y recuperación rápida de fallas.
- Para las pruebas, pruebe desde la perspectiva de la arquitectura del sistema para llenar los vacíos de las pruebas de escenarios desconocidos.
- Para productos y diseños, verifique el rendimiento del producto mediante pruebas para mejorar la experiencia del cliente.
- Escenarios de aplicación de la ingeniería del caos
- Prueba de capacidad de recuperación ante desastres: mediante la inyección de fallas, verifique el impacto de las fallas de componentes individuales en todo el sistema, así como la efectividad de las medidas de emergencia, como la limitación y degradación de corriente, la fusión, la conmutación y la conmutación por error;
- Gobernanza de dependencia fuerte y débil del microservicio: al inyectar y eliminar fallas en el servicio llamado, observe el rendimiento del indicador del servicio de llamada, obtenga la relación de dependencia y el grado de acoplamiento entre los servicios principales y los servicios no principales, y optimice aún más las dependencias que lo hacen. no cumplir con las expectativas;
- Verifique la racionalidad de la configuración del sistema: al simular la disponibilidad de los recursos del sistema, observe la racionalidad de la configuración del servicio del sistema, la configuración de réplicas y las restricciones de recursos.
- Monitoreo y alarmas: verifique si los indicadores de monitoreo son precisos, si las dimensiones de monitoreo están completas, si el umbral de alarma es razonable y la puntualidad de la información de alarma mediante la inyección de fallas;
- Simulacros de emergencia: A través de simulacros en escenarios reales como enfrentamiento rojo-azul, verificar si las capacidades de respuesta a emergencias, planes de emergencia y procedimientos de emergencia para temas relacionados están completos.
1.2 Cinco principios de la ingeniería del caos
Al desarrollar un experimento de ingeniería del caos, tener en cuenta los siguientes principios ayudará en el diseño del experimento.
- Supuestos para establecer un estado estable: en primer lugar, definir indicadores que puedan reflejar directamente el estado de la operación empresarial, como el TPS de la transacción y los cambios en el tiempo de respuesta; en segundo lugar, cuando se activa una falla, se pueden generar las respuestas esperadas a los cambios del sistema y de los indicadores.
- Utilice una variedad de eventos del mundo real para la verificación: tiene sentido introducir eventos que existen y ocurren con frecuencia en el mundo real, no imaginados de la nada, como retrasos en las llamadas de servicio, fallas de disco, etc.
- Experimente en un entorno de producción: intente realizar pruebas en un entorno similar a la producción. La diversidad del entorno de producción no tiene comparación con otros entornos. Sin embargo, si el sistema de producción no tiene capacidades de recuperación ante desastres en ciertos escenarios de falla, no se pueden realizar experimentos de caos para evitar pérdidas.
- Experimentos automatizados para operación continua: los experimentos de fallas continuamente automatizados pueden reducir la tasa de recurrencia de fallas y detectar fallas con anticipación, lo que garantiza en la mayor medida la verificación de la continuidad del negocio.
- Minimizar el radio de explosión: durante la implementación de la ingeniería del caos, es necesario garantizar que se minimice el impacto comercial en la producción, por lo tanto, durante el experimento, comience desde un área pequeña y amplíe el alcance continuamente, como hacer un buen trabajo aislamiento ambiental y ejecución durante horas de menor actividad comercial.
El propósito de la ingeniería del caos es verificar la estabilidad y disponibilidad del sistema de producción y garantizar la continuidad del negocio, por lo que al diseñar experimentos de ingeniería del caos, siga los cinco principios básicos anteriores como base para mejorar el valor del experimento.
1.3 Modelo de madurez de la ingeniería del caos
El Modelo de Madurez de Ingeniería del Caos (CEMM) es un marco para evaluar y mejorar las capacidades de ingeniería del caos, cuyo objetivo es ayudar a las empresas a establecer capacidades confiables de ingeniería del caos y mejorar la estabilidad y confiabilidad de los sistemas de software. CEMM incluye cinco niveles de madurez, cada nivel corresponde a diferentes requisitos y objetivos de capacidad, desde el nivel inicial (Nivel 1) hasta el nivel de optimización (Nivel 5), mejorando gradualmente la madurez de las capacidades de ingeniería del caos. [3]
- Nivel inicial (Nivel 1): intenta realizar experimentos del caos, pero carece de estrategias y especificaciones unificadas de ingeniería del caos, y se encuentra en la etapa exploratoria de los experimentos del caos.
- Nivel certificado (Nivel 2): Completó la exploración de experimentos del caos, comenzó la gestión estandarizada de experimentos del caos y comenzó a construir su propia plataforma de ingeniería del caos.
- Nivel definido (Nivel 3): se ha establecido el proceso estandarizado y el sistema de gestión de los experimentos del caos, se ha comenzado el análisis cuantitativo de los experimentos del caos y se ha comenzado a construir su propia plataforma de ingeniería del caos.
- Nivel administrado (Nivel 4): se ha establecido una plataforma completa de ingeniería del caos, que puede realizar análisis cuantitativos integrales y monitoreo de experimentos de caos, e iniciar la gestión y optimización automática de experimentos de caos.
- Nivel de optimización (Nivel 5): ha alcanzado el nivel más alto de capacidades de ingeniería del caos, tiene capacidades de gestión de experimentos de caos totalmente automatizadas y puede optimizar y mejorar integralmente los experimentos de caos para garantizar la estabilidad y confiabilidad del sistema de software.
CEMM puede ayudar a las empresas a evaluar su propio nivel de capacidades de ingeniería del caos y guiarlas para mejorar gradualmente la madurez de las capacidades de ingeniería del caos, a fin de lograr la estabilidad y confiabilidad de los sistemas de software.
1.4 Proceso de práctica de ingeniería del caos
Basado en la ingeniería del caos, las fallas se inyectan aleatoriamente en los sistemas de aplicaciones y servidores a través de un entorno similar a la producción para detectar si el sistema puede proporcionar servicios externos normalmente cuando algunos objetos o funciones son anormales. Al simular los escenarios de fallas en el entorno de producción real, se establece la capacidad de inyección de fallas, incluidas la capa de aplicación, la capa de sistema y la capa de contenedor, y se proporcionan las capacidades de operación y mantenimiento de coordinación de emergencias, localización de fallas y recuperación de fallas. El proceso de práctica de la ingeniería del caos consta de las siguientes cuatro etapas:
- Etapa de preparación: preparativos antes de los simulacros de fallas, como preparación del entorno y del tráfico, configuración de elementos del índice de monitoreo, etc., para garantizar que el sistema cumpla con los requisitos especificados antes de la inyección de fallas, correspondientes al supuesto de estabilidad de la ingeniería del caos.
- Fase de ejecución: Ejecute el experimento de acuerdo con el alcance del experimento establecido y los indicadores de seguimiento. En la etapa de ejecución, es necesario prestar atención al rango de impacto controlable del simulacro de falla y los escenarios de falla configurables.
- Etapa de verificación: verifique si los resultados del experimento cumplen con las expectativas, si los indicadores de monitoreo son perfectos y el impacto en el sistema y el negocio; si cumple con las expectativas, considere ampliar el alcance del experimento para verificar completamente la estabilidad del sistema.
- Fase de recuperación: realice operaciones de recuperación para la inyección de fallas y restaure el sistema y el negocio al estado anterior al simulacro.
En la práctica real, cada empresa construirá una plataforma de ingeniería del caos basada en sus propios escenarios de operación y mantenimiento para simular escenarios de fallas reales e indicadores de monitoreo del sistema. Por ejemplo, China Electronics Financial Trust combinó las características del sistema bancario para crear una biblioteca de casos de caos adecuada para el sistema bancario y llevó a cabo simulacros de confrontación rojo-azul mediante gestión experimental. [4]
En la práctica de ingeniería del caos que se muestra arriba, los casos de alta disponibilidad relacionados con la industria financiera se empaquetan en una biblioteca de casos de caos, que incluye casos relacionados con la alta disponibilidad de detención de aplicaciones, detención de servicios, detención de tarjetas de red, tiempo de inactividad, animación suspendida, etc., así como casos de eventos de producción, casos abstractos de emergencia en el plan, como almacenamiento lleno, daños, consistencia de transacciones, etc.
1.5 Escenarios de fallas de ingeniería del caos
1.5.1 Escenarios de falla de la ingeniería del caos
En el escenario de inyección de fallas de Chaos Engineering, los perfiles de fallas se dividen en la industria según la capa IaaS, la capa PaaS y la capa SaaS, como se muestra en la siguiente figura, como fallas de disco en la capa de infraestructura, anomalías de la red, conexión de la base de datos. El grupo lleno, el consumo anormal de CPU y los subprocesos comerciales, el grupo lleno, la actividad falsa del proceso, etc., son escenarios de falla comunes. Los fallos de diseño se simulan frente a estos escenarios de fallo conocidos para verificar la estabilidad de los sistemas empresariales reales. [5]
1.5.2 Indicadores de observabilidad
El diseño del índice de observabilidad es uno de los indicadores clave para el éxito del experimento de ingeniería del caos. Una buena observabilidad del sistema brindará un fuerte respaldo de datos al experimento de ingeniería del caos y proporcionará una base para la interpretación posterior de los resultados experimentales, el seguimiento de problemas y análisis final La resolución proporciona una base sólida. Los indicadores observables comunes incluyen las siguientes partes:
- Observabilidad del sistema: incluye principalmente Métricas (indicadores), Registro (registros) y Seguimiento (seguimiento), etc.
- Indicadores comerciales: estos indicadores suelen estar directamente relacionados con el valor comercial y la experiencia del usuario, y son uno de los indicadores de observación más importantes en los experimentos de ingeniería del caos.
- Indicadores de salud de la aplicación: reflejan el estado de salud del sistema de la aplicación, incluidas excepciones de error, cuellos de botella en el rendimiento, vulnerabilidades de seguridad, cambios en el tiempo de respuesta y TPS, fluctuaciones en la tasa de éxito, etc.
- Otros indicadores del sistema: reflejan el estado operativo de la infraestructura y los sistemas, incluido el uso de CPU, el consumo de memoria, el retraso de la red, etc.
Estos indicadores pueden proporcionar un sólido respaldo de datos para experimentos de ingeniería del caos, ayudando al equipo a interpretar los resultados experimentales, rastrear problemas y finalmente resolverlos. En la observación de indicadores, algunos métodos estadísticos como la detección bayesiana, el suavizado exponencial, el análisis PCA, etc. también se pueden combinar para realizar análisis de correlación en múltiples elementos de indicadores para determinar el impacto preciso del sistema.
2. Práctica de plataforma de ingeniería del caos de código abierto
2.1 Plataforma Espada del Caos
Chaosblade es un proyecto de código abierto del MonkeyKing interno de Alibaba, basado en los más de diez años de pruebas y simulacros de fallas de Alibaba. La dirección de GitHub es https://github.com/chaosblade-io/chaosblade. Los escenarios experimentales actualmente admitidos por Chaosblade incluyen recursos de infraestructura, aplicaciones Java, aplicaciones C++, contenedores Docker y plataformas nativas de la nube.
2.1.1 Experiencia ChaosBlade
1) Descargue el paquete del experimento Chaosblade
##下载路径
https://github.com/chaosblade-io/chaosblade/releases
##解压安装包
# tar -xzvf chaosblade-1.7.2-linux-amd64.tar.gz
[root@tango-DB01 chaosblade-1.7.2]# pwd
/usr/local/chaosblade/chaosblade-1.7.2
[root@tango-DB01 chaosblade-1.7.2]# ls -l
total 39324
drwxr-xr-x 2 root root 111 May 19 11:36 bin
-rwxr-xr-x 1 root root 40265968 May 19 11:32 blade
drwxr-xr-x 4 root root 34 May 19 11:44 lib
drwxr-xr-x 2 root root 316 May 19 11:44 yaml
2) Utilice Chaosblade para simular escenarios de falla.
##1、模拟CPU满载实验
##执行命令./blade create cpu load，code=200表示执行成功，
{"code":200,"success":true,"result":"9eb3770e8fa40287"}
##使用TOP显示执行效果，CPU使用率已经接近99%
Tasks: 163 total, 2 running, 161 sleeping, 0 stopped, 0 zombie
%Cpu0 : 98.9 us, 0.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
KiB Mem : 1867024 total, 600356 free, 639152 used, 627516 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1040792 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2003 root 20 0 710452 9632 3008 R 98.7 0.5 2:16.89 chaos_os
##销毁实验
# ./blade destroy 9eb3770e8fa40287
{"code":200,"success":true,"result":{"target":"cpu","action":"fullload","ActionProcessHang":false}}
再次查看CPU使用率，已经恢复正常
##2、指定百分比负载
# ./blade create cpu load --cpu-percent 60
{"code":200,"success":true,"result":"847419202a931560"}
##查看CPU使用情况
top - 19:30:23 up 26 min, 2 users, load average: 1.24, 1.31, 0.81
Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie
%Cpu0 : 59.4 us, 0.3 sy, 0.0 ni, 40.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1867024 total, 602488 free, 636560 used, 627976 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1043252 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2111 root 20 0 710452 7352 2880 S 59.5 0.4 0:24.80 chaos_os
Chaosblade proporciona las capacidades básicas de los experimentos del caos, en las que está empaquetado en una plataforma de ingeniería del caos para simulacros. Los escenarios de falla admitidos incluyen:
- Chaosblade: herramienta de gestión de experimentos del caos, que incluye la creación de experimentos, la destrucción de experimentos, la consulta de experimentos, la preparación del entorno del experimento, la cancelación del entorno del experimento y otros comandos, es una herramienta de ejecución para experimentos del caos, y los métodos de ejecución incluyen CLI y HTTP. Proporcione comandos completos, escenarios experimentales y descripciones de parámetros de escenarios, y la operación es concisa y clara.
- Chaosblade-spec-go: definición del lenguaje Golang del modelo de experimento del caos. Las escenas que son fáciles de implementar en el lenguaje Golang se basan todas en esta especificación.
- caosblade-exec-os: Implementación de escenarios de experimentos de recursos básicos.
- caosblade-exec-docker:: Implementación del escenario del experimento del contenedor Docker, implementación estandarizada llamando a la API de Docker.
- caosblade-exec-cri:: Implementación del escenario del experimento de contenedor, implementada llamando a la estandarización CRI.
- Chaosblade-operator: implementación de escenarios experimentales en la plataforma Kubernetes. Los experimentos de caos se definen a través del método CRD estándar de Kubernetes. Es muy conveniente utilizar las operaciones de recursos de Kubernetes para crear, actualizar y eliminar escenarios experimentales, incluida la ejecución usando kubectl, client-go , etc. Y también se puede ejecutar utilizando la herramienta cli Chaosblade mencionada anteriormente.
- Chaosblade-exec-jvm: implementación del escenario experimental de la aplicación Java, que utiliza la tecnología del Agente Java para montar dinámicamente, sin ningún acceso, uso sin costo, admite la desinstalación y recicla completamente varios recursos creados por el Agente.
- Chaosblade-exec-cplus: Implementación de la escena del experimento de la aplicación C ++, utilizando tecnología GDB para implementar la inyección de la escena del experimento a nivel de línea de código y método.
2.1.2 Modelo experimental de caos de Chaosblade
Antes del experimento del caos de Chaosblade, era necesario responder varias preguntas, como el objetivo del experimento, el alcance de la implementación, los pasos específicos de la implementación y las condiciones de coincidencia efectivas. En base a estas preguntas, el objetivo, el alcance, el comparador, y Se resumieron los modelos de acción.
- Objetivo: el objetivo experimental se refiere a los componentes donde se produce el experimento, como contenedores, marcos de aplicaciones (Dubbo, Redis, Zookeeper), etc.
- Alcance: el alcance de la implementación del experimento, que se refiere a la máquina o clúster específico que desencadena el experimento.
- Matcher: el comparador de reglas experimentales, de acuerdo con el objetivo configurado, define reglas de coincidencia experimentales relacionadas y se pueden configurar múltiples configuraciones. Debido a que cada objetivo puede tener sus propias condiciones de coincidencia especiales, como HSF y Dubbo en el campo RPC, se puede comparar de acuerdo con el servicio proporcionado por el proveedor de servicios y el servicio llamado por el consumidor del servicio, y Redis en el campo de caché. se puede combinar de acuerdo con las operaciones set y get.
- Acción: Se refiere al escenario específico de la simulación experimental. El objetivo es diferente y el escenario de implementación es diferente. Por ejemplo, el disco se puede perforar, el disco está lleno, el IO del disco lee y escribe alto y el hardware del disco falla. Si se trata de una aplicación, se pueden abstraer escenarios experimentales como retrasos, excepciones, devolución de valores específicos (códigos de error, objetos grandes, etc.), manipulación de parámetros y llamadas repetidas.
Basado en el modelo anterior, se lleva a cabo el experimento de simulación del escenario de falla de Chaosblade.
Referencias:
- [1] Práctica de ingeniería del caos de Alibaba, Alibaba Cloud Yunqi
- [2] https://cloud.tencent.com/developer/article/1828940
- [3] Modelo de madurez de ingeniería del caos de Netflix
- [4] Plataforma de práctica de ingeniería del caos financiero CLP
- [5] Cómo utilizar la ingeniería del caos para abordar fallas desconocidas, base nativa de la nube
- [6] https://github.com/chaosblade-io/chaosblade