Notre réunion de juin dans Test in Production était consacrée à l'ingénierie du chaos. L'ingénieur logiciel principal Norah Jones a commencé par la façon dont Netflix effectue les tests en production.
«L'ingénierie du chaos ... ce sont des expériences en production pour trouver des vulnérabilités dans un système avant de rendre un service inadapté aux clients. Chez Netflix, nous les exécutons à l'aide d'un outil appelé ChAP ... [il] détecte les vulnérabilités et nous permet de mettre en œuvre des défaillances dans les services et la production. Ces échecs confirment les hypothèses sur ces services avant d'entraîner des pannes complètes. »
Regardez une présentation (ou lisez la transcription) sur la façon dont son équipe aide les utilisateurs - les ingénieurs de Netflix - à tester en toute sécurité en production et à identifier activement les vulnérabilités de leurs systèmes.
Décryptage
Je suis très heureux d'être ici aujourd'hui.
Netflix utilise activement des tests en production. Nous le faisons grâce à l'ingénierie du chaos, et nous avons récemment renommé notre équipe Resiliance Engineering [développement durable] parce que l'ingénierie du chaos est un moyen d'atteindre la durabilité globale. Je vais en parler aujourd'hui.
Notre objectif est d'augmenter la disponibilité en recherchant de manière proactive les vulnérabilités des services. Nous le faisons à travers des expériences de production. L'équipe est convaincue qu'une certaine classe de vulnérabilités et de problèmes ne peut être détectée que sur le trafic réel.
Tout d'abord, vous devez vous occuper de la sécurité et de la surveillance, sinon vous ne pourrez pas déployer des tests normaux en production. De tels tests peuvent être effrayants: s'ils font peur, vous devez écouter cette voix et découvrir pourquoi. Peut-être parce que vous n'avez pas un bon système de sécurité. Ou parce qu'il n'y a pas de bonne surveillance. Dans nos outils, nous nous soucions vraiment de ces choses.
Si nous formulons l'ingénierie du chaos en une phrase, alors c'est la discipline des expériences en production pour trouver des vulnérabilités dans le système avant qu'elles ne rendent le service inapproprié pour les clients. Chez Netflix, nous les exécutons à l'aide d'un outil appelé ChAP, ce qui signifie la Chaos Automation Platform (Chaos Automation Platform). ChAP détecte les vulnérabilités et permet aux utilisateurs d'implémenter des défaillances dans les services et la production. Ces échecs confirment les hypothèses des utilisateurs sur ces services avant de conduire à des pannes à grande échelle.
Je vais vous expliquer comment fonctionne la plateforme à un niveau élevé. Il s'agit d'un ensemble hypothétique de dépendances de microservices. Il existe un certain proxy. Il envoie une demande au service A, qui diffère ensuite sans ventilateur pour les services B, C et D, et il y a toujours un niveau de persistance. Le service D accède à Cassandra, puis le service B accède au cache.
Je me précipite et résume tout, car l'essence commence plus loin. Nous voulons nous assurer que le service D est robuste contre une panne de cache. L'utilisateur entre dans l'interface ChAP et sélectionne le service D comme un service qui observe les échecs de cache et un service d'échec. ChAP clone en fait le service B en deux exemplaires. Nous les utilisons pour le contrôle dans des clusters expérimentaux: d'une certaine manière, ils fonctionnent comme des tests A / B ou des tests canaris. Ces répliques sont beaucoup plus petites que le service B. Nous n'envoyons qu'un très, très petit pourcentage de clients à ces clusters parce que, évidemment, nous ne voulons pas d'un échec complet. Nous calculons ce pourcentage en fonction du nombre actuel d'utilisateurs utilisant le service à l'heure actuelle.
ChAP demande ensuite au système de basculement de signaler les demandes qui correspondent à nos critères. Cela se fait en ajoutant des informations aux en-têtes de demande. Deux ensembles de balises sont créés. Dans le premier ensemble d'instructions pour l'échec et le routage vers la réplique canari, et dans le second - uniquement des instructions pour le routage vers l'élément de surveillance.
Lorsque le client RPC et le service A reçoivent les instructions nécessaires pour acheminer la demande, ils dirigent en fait le trafic vers le cluster de surveillance ou le cluster expérimental. Ensuite, le système d'implémentation d'échec au niveau RPC du cluster expérimental voit que la demande est marquée pour échec et renvoie une réponse ayant échoué. Comme précédemment, le cluster expérimental exécutera du code pour gérer l'échec comme une réponse infructueuse du cache. Nous faisons cela en supposant qu'il est tolérant aux pannes, non? Mais parfois, nous voyons que ce n'est pas le cas. Du point de vue du service A, tout ressemble à un comportement normal.
Nous contrôlons soigneusement l'ingénierie du chaos, qui peut très mal se passer. Lorsque Netflix a commencé ces expériences pour la première fois, nous n'avions pas de bon système de contrôle. Nous avons lancé un problème artificiel et nous nous sommes assis dans la pièce, les doigts croisés et vérifiant que tout fonctionnait bien. Maintenant, nous accordons beaucoup plus d'attention à la sécurité.
Nous examinons les principaux paramètres commerciaux. L'un d'eux est appelé SPS (flux commence par seconde), c'est-à-dire démarre les flux vidéo par seconde. Si vous pensez à ce qui est le plus important pour les activités de Netflix, c'est pour que les utilisateurs puissent exécuter n'importe quelle série à tout moment.
Dans les graphiques, vous voyez une véritable expérience. Il montre la différence de SPS entre les clusters expérimental et contrôle pendant le test. Vous pouvez remarquer que les graphiques diffèrent considérablement les uns des autres, ce qui ne devrait pas être le cas, car le même pourcentage de trafic est envoyé aux deux clusters.
Pour cette raison, le test utilise une analyse canarienne automatisée. Cela donne un signal indiquant que les graphiques mêmes s'écartent considérablement les uns des autres. Dans ce cas, le test est immédiatement interrompu afin que les gens puissent travailler normalement avec le site. Du point de vue de l'utilisateur, cela ressemble plus à un problème à court terme lorsque cela se produit.
Nous avons de nombreux autres recours. Nous limitons le volume de trafic de test dans chaque région, donc nous ne menons pas l'expérience uniquement dans la zone US West 2. Nous les faisons partout et limitons le nombre d'expériences qui peuvent être effectuées dans la région à la fois. Les tests ne passent que pendant les heures de travail, donc nous ne réveillerons pas les ingénieurs en cas de problème. Si le test échoue, il ne peut pas être redémarré automatiquement jusqu'à ce que quelqu'un le corrige explicitement manuellement et confirme: "Hé, je sais que le test n'a pas réussi, mais j'ai corrigé tout ce qui était nécessaire."
Il est possible d'appliquer des propriétés personnalisées aux clusters. Cela est utile si le service est divisé en fragments, comme de nombreux services Netflix. De plus, vous pouvez implémenter des échecs en fonction du type de périphérique. Si nous supposons des problèmes sur les appareils Apple ou un certain type de téléviseur, nous pouvons effectuer des tests spécifiquement pour eux.
ChAP a trouvé de nombreux bugs. Voici l'un de mes favoris. Nous avons mené une expérience pour vérifier le chemin de sauvegarde du service, qui est crucial pour sa disponibilité, et y avons identifié un bogue. Le problème a été résolu avant qu'il n'entraîne l'incident de disponibilité du service. C'est un cas vraiment intéressant, car ce chemin de sauvegarde n'a pas été effectué souvent. Par conséquent, l'utilisateur ne savait pas vraiment si cela fonctionnait correctement et nous avons pu l'imiter. Nous avons en fait provoqué une panne de service et vérifié pour voir si cela s'est passé sur un revêtement et si cela fonctionne correctement. Dans ce cas, l'utilisateur pensait que son service n'était pas critique ou secondaire, mais en fait c'était un service critique.
Voici un autre exemple. Nous avons mené une expérience pour reproduire le problème lors du processus d'enregistrement, qui est apparu la nuit sur certains serveurs. Quelque chose d'étrange se passait avec le service. Le problème a été reproduit après l'introduction d'un délai de 500 millisecondes. Pendant le test, le problème a été détecté dans les journaux téléchargés sur le portail Big Data. Cela a permis de comprendre pourquoi, dans certains cas, l'enregistrement n'a pas fonctionné. Ce n'est que grâce à l'expérience ChAP que nous avons pu voir ce qui se passait et pourquoi.
La configuration du test ChAP nécessite beaucoup d'informations. Nous devons trouver les points appropriés pour introduire des bogues. Les équipes doivent déterminer si elles veulent planter ou retarder. Tout dépend du point d'injection. Vous pouvez planter Cassandra, Hystrix (notre système de sauvegarde), le service RPC, le client RPC, S3, SQS ou notre cache, ou ajouter un délai à partir d'eux. Ou faites les deux. Vous pouvez également proposer des combinaisons de différentes expériences.
Ce que vous devez faire, c'est vous réunir avec une équipe de service et trouver un bon test. Cela prendra beaucoup de temps. Lors de la mise en place d'une expérience, vous devez également définir des configurations ACA (Automated Canary Analysis) ou des configurations canaries automatiques.
Nous avions des configurations ACA prêtes à l'emploi. Il y avait une configuration ChAP pour SPS. Il y en avait un avec des indicateurs du système de suivi. Un autre qui a vérifié les plantages RPS. Un autre s'est assuré que notre service fonctionne correctement et implémente correctement les bogues. Nous avons réalisé que la conception d'un test peut prendre beaucoup de temps, et c'est ce qui s'est passé. Il n'y a pas eu beaucoup de tests créés. Il est difficile pour une personne de garder à l'esprit tout ce qui est nécessaire pour une bonne expérience. Nous avons décidé d'automatiser quelque chose avec ChAP. Nous avons examiné les indicateurs: où et à qui s'adressent les appels, fichiers avec délais d'attente, appels répétés. Il est devenu clair que toutes les informations proviennent de différents endroits. Il fallait l'agréger.
Nous avons adapté l'analyse au niveau ChAP, où il est beaucoup plus pratique de travailler avec des informations et vous pouvez utiliser Monocle. Maintenant, toutes les informations sur l'application et le cluster peuvent être étudiées en un seul endroit. Ici, chaque ligne représente une dépendance, et ces dépendances représentent un terrain fertile pour des expériences d'ingénierie du chaos.
Nous avons collecté toutes les informations en un seul endroit pour le développement de l'expérience, mais nous n'avons pas compris qu'une telle agrégation est très utile en soi, c'est donc un effet secondaire intéressant. Vous pouvez aller ici et voir réellement les anti-modèles associés à un service particulier. Par exemple, une dépendance est détectée qui n'était pas considérée comme critique, mais qui n'a pas de route de secours. De toute évidence, maintenant elle devient critique. Les gens pouvaient voir des décalages de timeout, des décalages de rappel. Nous utilisons ces informations pour évaluer la criticité d'une expérience d'un certain type et les saisir dans un algorithme qui détermine les priorités.
Chaque ligne représente une dépendance et ces lignes peuvent être développées. Voici un exemple intéressant.
Ici, la ligne bleue en haut indique le délai d'expiration de quelqu'un et la ligne violette en bas indique le temps d'exécution habituel. Comme vous pouvez le voir, c'est très, très loin du timeout. Mais la plupart de ces informations n'étaient pas disponibles. Que se passe-t-il si nous exécutons le test juste sous le délai? Qu'en penses-tu? Va-t-il passer? C'est une question intéressante. Nous essayons de fournir aux utilisateurs ce niveau de détail avant d'exécuter les tests afin qu'ils puissent tirer des conclusions et modifier les paramètres.
Je veux jouer à un petit jeu. Il existe une vulnérabilité dans ce service Netflix, essayez de la détecter. Prenez une seconde et regardez.
Pour vous donner un peu de contexte, la commande Hystrix distante contient à la fois sample-rest-client et sample-rest-client.GET. Le délai d'expiration Hystrix est défini sur 500 millisecondes. Sample-rest-client.GET a un délai d'expiration de 200 ms avec une nouvelle tentative, ce qui est bien, car le total est de 400 millisecondes, ce qui correspond à la limite Hystrix. Le deuxième client a des délais d'attente de 100 et 600 avec une nouvelle tentative.
Dans ce cas, la nouvelle tentative ne peut pas être effectuée en tenant compte du délai d'expiration du shell Hystrix, c'est-à-dire que Hystrix refuse la demande avant que le client puisse recevoir une réponse. C'est là que réside la vulnérabilité. Nous fournissons ces informations aux utilisateurs. Fait intéressant, la plupart de la logique dans la mise en œuvre de ces fonctions se trouve à différents endroits, et avant, ils ne pouvaient pas comparer ces choses. Ils pensaient que tout fonctionnait bien, mais voici un bug.
Pourquoi est-ce arrivé? Bien sûr, il est facile pour un développeur de voir le conflit et de changer le délai, non? Mais nous voulons découvrir la raison. Nous pouvons changer le délai, mais comment pouvons-nous garantir que cela ne se reproduira plus? Nous aidons également à découvrir les raisons.
Lors de la création de tests automatisés, nous utilisons également Monocle. L'utilisateur crée une expérience sur de nombreux types de données d'entrée. Nous prenons tout cela et automatisons la création de tels tests pour que les utilisateurs ne s'en soucient pas. Nous créons et hiérarchisons automatiquement les expériences Hystrix et les expériences RPC avec des retards et des échecs dus aux retards. Les configurations ACA sont ajoutées par défaut. Nous avons SPC, les métriques du système, les statistiques de requête et les expériences exécutées automatiquement. Des priorités d'expérimentation sont également créées. Un algorithme de haut niveau fonctionne pour eux. Nous utilisons un compartiment avec des statistiques RPS. Nous utilisons plusieurs tentatives et commandes Hystrix associées. L'ensemble est pondéré de manière appropriée.
De plus, le nombre d'équipes sans chemins d'exécution de sauvegarde et tout impact externe (impact curatif) que le client ajoute à sa dépendance sont pris en compte. Les influences externes affectent considérablement l'autorisation, l'enregistrement et les procédures SPS. Et nous mesurons vraiment son effet et ne menons pas d'expériences si le résultat est négatif. Ensuite, les tests sont classés et exécutés par ordre décroissant de criticité. Plus le score de criticité est élevé, plus le test commence tôt et souvent.
Ironiquement, Monocle nous a fourni des commentaires qui nous permettent d'exécuter moins de tests en production. Nous avons effectué tellement de tests qu'en conséquence une boucle de rétroaction s'est formée: nous avons vu les connexions entre les tests. Vous pouvez maintenant regarder des fichiers de configuration spécifiques et voir des anti-modèles spécifiques. Même sans tests pour ces informations, il est possible de comprendre exactement ce qui provoquera l'échec, à ce moment-là, nous ne l'avions pas compris auparavant.
Cela a conduit à un nouveau niveau de sécurité. Auparavant, une expérience infructueuse était marquée comme résolue. Maintenant, il est marqué comme résolu avant de relancer. Mais maintenant, nous pouvons explicitement ajouter des influences externes (curatoriales) à la dépendance. L'utilisateur entre dans son Monocle et indique: ce facteur influence précisément la procédure d'autorisation. Celui-ci est sur SPC. Et nous travaillons sur un cycle de rétroaction, de sorte qu'en cas d'échec, un tel effet curatorial soit également ajouté.
Ainsi, Monocle in ChAP est un outil important dans lequel toutes les informations sont collectées, il génère automatiquement des expériences, hiérarchise automatiquement et recherche les vulnérabilités avant qu'elles ne conduisent à des arrêts à grande échelle. Pour résumer, il est important de se rappeler pourquoi nous sommes engagés dans l'ingénierie du chaos et conduisons toutes ces expériences en production. Ceci est fait pour comprendre comment les clients utilisent le service et non pour les perdre de vue. Vous voulez offrir aux gens le service le plus pratique. La surveillance et la sécurité sont donc primordiales. Netflix devrait toujours montrer la vidéo.
Je vous remercie