Aller au contenu principal

Comment une entreprise de jeu de premier plan utilise l'ingénierie du chaos pour améliorer ses tests

· 5 minutes de lecture
Hui Zhang
Fuxi Lab, NetEase
Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Comment-une-entreprise-de-jeu-de-premier-plan-utilise-l'ingénierie-du-chaos-pour-améliorer-ses-tests
Comment-une-entreprise-de-jeu-de-premier-plan-utilise-l'ingénierie-du-chaos-pour-améliorer-ses-tests

NetEase Fuxi AI Lab est la première institution de recherche professionnelle en IA pour jeux en Chine. Les chercheurs utilisent notre plateforme Danlu basée sur Kubernetes pour le développement d'algorithmes, l'entraînement et le réglage, ainsi que la publication en ligne. Grâce à l'intégration avec Kubernetes, notre plateforme est beaucoup plus efficace. Cependant, en raison de problèmes liés à Kubernetes et aux microservices, nous testons et améliorons constamment notre plateforme pour la rendre plus stable.

Dans cet article, je vais vous présenter l'un de nos outils de test les plus précieux : Chaos Mesh. Chaos Mesh est un outil open source d'ingénierie du chaos qui offre un large éventail d'injections de fautes et une excellente surveillance des défaillances via son Dashboard.

Pourquoi Chaos Mesh

Nous avons commencé notre recherche d'un outil d'ingénierie du chaos en 2018. Nous cherchions un outil avec :

  • Une prise en charge cloud-native. Kubernetes est pratiquement la norme de facto pour l'orchestration et la planification des services, et le runtime des applications est entièrement standardisé. Pour les applications qui s'exécutent entièrement sur K8s, le support cloud-native est indispensable pour tout outil qui les accompagne.

  • Des types d'injection de fautes suffisants. Pour les services avec état, la simulation de défaillance réseau est particulièrement importante. La plateforme doit pouvoir simuler des défaillances à différents niveaux, tels que les Pods, le réseau et les E/S.

  • Une bonne observabilité. Savoir quand une faute est injectée et quand elle peut être récupérée est essentiel pour nous afin de détecter d'éventuelles anomalies dans l'application.

  • Un support communautaire actif. Nous voulions utiliser un projet open source rigoureusement testé et maintenu de manière constante. C'est pourquoi nous valorisons un soutien communautaire soutenu et réactif.

  • Aucune intrusion dans les applications existantes, sans nécessiter de connaissances spécifiques au domaine.

  • Des cas d'utilisation réels pour évaluer et construire.

En 2019, lorsque Chaos Mesh, une plateforme d'ingénierie du chaos pour Kubernetes, a été open-sourcée, nous avons trouvé l'outil que nous cherchions. Il en était encore à ses débuts ; cependant, nous avons été immédiatement frappés par la richesse des types de fautes qu'il prenait en charge. C'était un grand avantage par rapport aux autres outils d'ingénierie du chaos, car cela détermine dans une certaine mesure le nombre de problèmes que nous pouvons localiser dans le système. Nous avons immédiatement réalisé que Chaos Mesh répondait à nos attentes à presque tous les égards.

Architecture de Chaos Mesh
Architecture de Chaos Mesh

Notre parcours avec Chaos Mesh

Chaos Mesh nous a aidés à découvrir plusieurs bugs importants. Par exemple, il a détecté un problème de split-brain dans rabbitMQ, le logiciel open source de mise en file d'attente de messages pour Danlu. Selon Wikipedia, "une condition de split-brain indique des incohérences de données ou de disponibilité provenant de la maintenance de deux ensembles de données distincts avec un chevauchement de portée." Lorsqu'un cluster rabbitMQ rencontre une erreur de split-brain, des conflits ou des erreurs d'écriture de données se produisent, ce qui entraîne des problèmes plus graves tels que des incohérences de données dans le service de messagerie. Comme le montre notre architecture ci-dessous, lorsque le split-brain se produit, les consommateurs ne fonctionnent pas normalement et signalent continuellement des exceptions serveur.

Architecture d'un cluster RabbitMQ
Architecture d'un cluster RabbitMQ

Avec Chaos Mesh, nous avons pu reproduire ce problème de manière stable en injectant des fautes pod-kill dans notre cloud d'instances de conteneurs.

Chaos Mesh a également détecté plusieurs autres problèmes, notamment des échecs de démarrage, des échecs de jonction pour les clusters de brokers écrasés, des dépassements de délai de heartbeat et des fermetures de canaux de connexion. Au fil du temps, notre équipe de développement a corrigé ces problèmes et a grandement amélioré la stabilité de la plateforme Danlu.

Un projet en pleine croissance

Chaos Mesh est constamment mis à jour et amélioré. Lors de notre première adoption, il n'avait même pas atteint une version stable. Il ne disposait pas d'outil de débogage ou de collecte de journaux, et le composant Dashboard ne fonctionnait qu'avec TiDB. La seule façon de tester d'autres applications avec Chaos Mesh consistait à exécuter le fichier de configuration YAML via kubectl apply.

Chaos Mesh 1.0 a corrigé ou amélioré la plupart de ces limitations. Il offre désormais un support du chaos plus précis et puissant, un Chaos Dashboard désormais généralement disponible, une observabilité renforcée et un contrôle plus précis de la portée du chaos. Ces avancées sont toutes portées par une communauté ouverte, collaborative et dynamique.

Le Chaos Dashboard est désormais généralement disponible
Le Chaos Dashboard est désormais généralement disponible

Perspectives futures

C'est impressionnant de voir l'évolution de Chaos Mesh et l'engouement qu'il suscite. Nous sommes également satisfaits des résultats obtenus grâce à lui.

Cependant, l'ingénierie du chaos reste un vaste domaine. À l'avenir, nous aimerions voir les fonctionnalités suivantes :

  • Injection de fautes atomiques

  • Injection de fautes automatisée combinant des types de fautes personnalisés avec des méthodes standardisées pour valider les objets expérimentaux

  • Cas de test standardisés pour des composants génériques comme MySQL, Redis et Kafka

Nous avons discuté de ces fonctionnalités avec les mainteneurs de Chaos Mesh, qui nous ont indiqué qu'elles figuraient sur la feuille de route de Chaos Mesh 2.0.

Si vous êtes intéressé, rejoignez la communauté Chaos Mesh via Slack (#project-chaos-mesh) ou GitHub.