Comment Chaos Mesh aide Apache APISIX à améliorer la stabilité du système

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 →

Chaos Mesh aide Apache APISIX à améliorer la stabilité du système

Apache APISIX est une passerelle d'API microservices cloud-native, haute performance et évolutive. C'est l'un des projets de premier niveau de la Fondation Apache Software Foundation et elle sert des centaines d'entreprises dans le monde, traitant leur trafic critique, notamment dans les secteurs de la finance, d'Internet, de la fabrication, de la vente au détail et des opérateurs. Nos clients incluent la NASA, l'usine numérique de l'Union européenne, China Mobile et Tencent.

Alors que notre communauté grandit, les fonctionnalités d'Apache APISIX interagissent plus fréquemment avec des composants externes, rendant notre système plus complexe et augmentant les risques d'erreurs. Pour identifier les défaillances potentielles du système et renforcer la confiance dans l'environnement de production, nous avons introduit le concept de Chaos Engineering.

Architecture d'Apache APISIX

Dans cet article, nous partagerons comment nous utilisons Chaos Mesh pour améliorer la stabilité de notre système.

Nos points de difficulté

Apache APISIX traite des dizaines de milliards de requêtes par jour. À ce niveau de volume, nos utilisateurs ont remarqué quelques problèmes :

• Scénario n°1 : Dans le centre de configuration d'Apache APISIX, lorsqu'une latence réseau inattendue se produit entre etcd et Apache APISIX, Apache APISIX peut-il encore filtrer et transférer le trafic normalement ?

• Scénario n°2 : Lorsqu'un nœud du cluster etcd tombe en panne et que le cluster peut toujours fonctionner normalement, une erreur est signalée pour l'interaction du nœud avec l'API d'administration d'Apache APISIX.

Bien qu'Apache APISIX ait couvert de nombreux scénarios via des tests unitaires, de bout en bout (E2E) et de fuzzing dans l'intégration continue (CI), il n'a pas couvert le scénario d'interaction avec les composants externes. Si le système se comporte anormalement, par exemple si le réseau subit des perturbations, qu'un disque dur tombe en panne ou qu'un processus est tué, Apache APISIX peut-il fournir des messages d'erreur appropriés ? Peut-il continuer à fonctionner ou se rétablir à un état normal ?

Pourquoi nous avons choisi Chaos Mesh

Pour tester ces scénarios utilisateurs et découvrir des problèmes similaires avant la mise en production, notre communauté a décidé d'utiliser Chaos Mesh pour les tests de chaos.

Chaos Mesh est une plateforme de Chaos Engineering cloud-native qui propose des méthodes d'injection de fautes complètes pour les systèmes complexes sur Kubernetes, couvrant les fautes dans les Pods, le réseau, le système de fichiers et même le noyau. Il aide les utilisateurs à trouver les faiblesses du système et garantit que le système peut résister à des situations incontrôlables en production.

Comme Apache APISIX, Chaos Mesh dispose d'une communauté open source active. Nous savons qu'une communauté active peut garantir une utilisation stable du logiciel et une itération rapide. Cela rend Chaos Mesh plus attractif.

Comment nous utilisons Chaos Mesh dans APISIX

Le Chaos Engineering a dépassé la simple injection de fautes et forme désormais une méthodologie complète. Pour créer une expérience de chaos, nous avons déterminé ce que devrait être le fonctionnement normal ou "l'état stable" de notre application. Nous avons ensuite introduit des problèmes potentiels pour observer la réponse du système. Si les problèmes faisaient sortir l'application de son état stable, nous les corrigions.

Maintenant, nous allons prendre les deux scénarios mentionnés pour vous montrer comment nous utilisons Chaos Mesh dans Apache APISIX.

Scénario n°1

Nous avons déployé une expérience de Chaos Engineering en suivant ces étapes :

1. Nous avons identifié des métriques pour mesurer le bon fonctionnement d'Apache APISIX. Durant les tests, la méthode principale consiste à utiliser Grafana pour surveiller les métriques d'exécution d'Apache APISIX. Nous avons extrait des données de Prometheus dans l'Intégration Continue (CI) pour comparaison. Nous avons utilisé le routage, le nombre de requêtes de transfert par seconde (RPS) et la connectivité à etcd comme métriques d'évaluation. Nous avons analysé les journaux. Pour Apache APISIX, nous avons vérifié le journal d'erreurs de Nginx pour déterminer la présence d'erreurs et leur conformité à nos attentes.

2. Nous avons effectué un test avec groupe témoin. Nous avons constaté que les opérations create route et access route réussissaient, et que la connexion à etcd était fonctionnelle. Nous avons enregistré le RPS.

3. Nous avons utilisé le chaos réseau pour ajouter une latence réseau de 5 secondes puis refait le test. Cette fois, set route a échoué, get route a réussi, la connexion à etcd restait possible, et le RPS ne présentait pas de variation significative par rapport à l'expérience précédente. L'expérience a répondu à nos attentes.

Latence réseau élevée entre etcd et Apache APISIX

Scénario n°2

Après avoir reproduit le même test avec groupe témoin, nous avons introduit un chaos de type pod-kill qui a généré l'erreur attendue. Lors de la suppression aléatoire de quelques nœuds etcd dans le cluster, APISIX parvenait parfois à se connecter à etcd, parfois non, et les journaux affichaient de nombreuses erreurs de rejet de connexion.

Lors de la suppression du premier ou troisième nœud dans la liste des endpoints etcd, la commande set route retournait un résultat normal. En revanche, lors de la suppression du deuxième nœud, set route retournait l'erreur "connection refused".

Notre analyse a révélé que l'API Lua etcd utilisée par Apache APISIX sélectionnait les endpoints de manière séquentielle plutôt qu'aléatoire. Ainsi, lors de la création d'un client etcd, celui-ci se liait exclusivement à un seul endpoint etcd, entraînant des échecs systématiques.

Après correction, nous avons ajouté un health check à l'API Lua etcd pour éviter l'envoi massif de requêtes vers des nœuds etcd déconnectés. Pour prévenir la saturation des journaux d'erreurs, nous avons implémenté un mécanisme de fallback lors de déconnexions complètes du cluster etcd.

Erreur signalée lors de l'interaction avec un nœud etcd

Nos projets futurs

Exécuter des tests de chaos dans des scénarios de simulation E2E

Dans Apache APISIX, nous identifions manuellement les faiblesses du système pour les tester et les corriger. Comme dans la communauté open source, nos tests en CI éliminent les risques liés au rayon d'impact du chaos en production. Mais ces tests ne couvrent pas les scénarios applicatifs complexes et exhaustifs des environnements de production.

Pour couvrir davantage de cas, la communauté prévoit d'utiliser les tests E2E existants pour simuler des scénarios plus complets et mener des tests de chaos plus aléatoires et étendus.

Étendre les tests de chaos à d'autres projets Apache APISIX

Au-delà de la recherche de vulnérabilités dans Apache APISIX, la communauté prévoit d'ajouter des tests de chaos à d'autres projets comme Apache APISIX Dashboard et Apache APISIX Ingress Controller.

Ajouter des fonctionnalités à Chaos Mesh

Lors de notre déploiement de Chaos Mesh, certaines fonctionnalités n'étaient pas disponibles, comme la sélection d'un service comme cible de latence réseau ou l'injection spécifique sur les ports des conteneurs. À l'avenir, la communauté Apache APISIX contribuera à ajouter ces fonctionnalités dans Chaos Mesh.

Vous êtes invités à contribuer au projet Apache APISIX sur GitHub. Si Chaos Mesh vous intéresse et que vous souhaitez l'améliorer, rejoignez notre canal Slack (#project-chaos-mesh) ou soumettez vos pull requests et issues sur notre dépôt GitHub.