Passez au niveau supérieur de la culture DevOps et modernisez vos capacités de surveillance grâce à AWS X-Ray

Capacités DevOps : observabilité et surveillance

Les pratiques et les outils de DevOps se fondent sur les trois grands principes de cette culture : flux, rétroactions et apprentissage continu. Le principe de rétroaction et le principe d’apprentissage continu sont les moins connus, mais ce sont les plus importants quand on cherche la qualité et la résilience. Les méthodes de surveillance classiques permettent d’obtenir des rétroactions « après coup » en collectant et en rapportant simplement des données provenant d’artéfacts en cours d’exécution, généralement limitées à l’infrastructure. Le concept DevOps de l’observabilité, plus moderne, consiste à appliquer les principes de base de surveillance aux logiciels. Au lieu de se cantonner à la surveillance de l’infrastructure de production et aux rapports sur les indicateurs infrastructurels du processeur, de la mémoire et de l’espace disque, l’observabilité moderne permet également de suivre la performance d’une application. Dans ce billet de blogue, nous expliquons comment exploiter tout le potentiel de la surveillance de la performance des applications (APM) à l’aide d’AWS X-Ray.

Le problème que résout AWS X-Ray

La programmation logicielle s’accompagne d’une certaine forme d’opacité en raison de sa faible observabilité (on n’y priorise pas les exigences non fonctionnelles). Très souvent, on se contente de livrer une nouvelle fonctionnalité sans penser à son observabilité ni à sa durabilité.

Et si nous pouvions le faire facilement? C’est la promesse de AWS X-Ray : un outil accessible qui vous permet de commencer à surveiller la performance de vos applications.

Passer aux méthodologies de développement logiciel agile accélère le travail, et donc la cadence de production. Ce nouveau rythme ne fait qu’accentuer le besoin de capacités d’observabilité modernes en matière de performance des applications pour garantir la performance des objectifs de niveau de services (SLO) et des indicateurs de niveau de service (SLI). Cette réalité est d’ailleurs étayée par les résultats de recherche de DevOps Research and Assessment (DORA). Les travaux de recherche de DORA montrent qu’un système complet de surveillance et d’observabilité est à la fois une capacité d’importance vitale et un indicateur propre aux équipes particulièrement performantes. La surveillance des SLI clés, en synergie avec l’établissement de SLO sur la base des contrats de niveau de service (SLA), nous permet de comprendre comment les changements impactent nos applications. Ce concept est de plus en plus important, car nous nous séparons de nos systèmes monolithiques pour nous rapprocher d’architectures infonuagiques modulaires, avec beaucoup plus d’éléments à surveiller.

Fonctionnement d’AWS X-Ray

AWS CloudWatch permet d’observer des indicateurs computationnels sans configuration compliquée nécessaire, mais ne permet pas de surveiller la performance des applications. Utiliser la fonctionnalité d’indicateurs personnalisés (Custom Metrics) pour enregistrer un SLI, par exemple le temps de réponse d’un point de terminaison en particulier, offre une visibilité opérationnelle. Malheureusement, un tel indicateur ne vous dira pas pourquoi le temps de réponse est ce qu’il est. C’est là qu’intervient AWS X-Ray.

Pour faire simple, deux composantes d’AWS X-Ray s’intègrent dans les processus de l’application :

Une librairie fournie par AWS (compatible avec Java, JavaScript, .NET, Ruby, Go, PHP et Python). La complexité d’intégration dépend des langages sur lesquels repose l’application et de la profondeur d’instrumentation désirée.
Une infrastructure qui collecte les segments produits par la bibliothèque, lesquels sont ensuite envoyés à AWS. Ce démon se déploie assez facilement à partir d’un progiciel à installer dans le système d’exploitation ou d’un conteneur Docker. Les segments sont envoyés à AWS et leur console X-Ray permet de visualiser les traces assemblées.

Comment utiliser Amazon X-Ray

Dans notre exemple, nous utilisons un modèle de services principaux destinés aux frontaux (BFF, pour Backend for Frontend) dans le contexte factice d’une application sociale d’entreprise. Ce modèle permet assez bien d’observer un traçage distribué, ce qui devrait en faire un bon exemple.

Nous allons simplement porter notre attention sur un point de terminaison « home » de l’application, qui renvoie une liste de membres d’équipe, quelques tâches à effectuer (TODO) et les cinq derniers documents sur lesquels l’utilisateur a travaillé. Nous commençons par créer un SLO pour ce point de terminaison, qui mesure un temps de réponse ou un temps de chargement de 150 ms. Ce code a été intentionnellement mal optimisé de manière à ce qu’il génère des traces intéressantes.

Console AWS : carte de trace et document de segment

La trace créée par AWS X-Ray entre dans le système, puis collecte des segments provenant de nos services instrumentés pour nous donner une image complète de la requête. La console AWS X-Ray permet d’analyser deux sections principales, soit une carte de trace et un document de segment. La carte de trace est pratique, car elle offre une vue générale du système, calquée sur la structure de l’application illustrée en figure 1. Grâce à celle-ci, nous pouvons facilement visualiser la manière dont les différents services modulent le SLO du point de terminaison.

Problèmes avec l'application

D’emblée, cette trace souligne plusieurs problèmes avec notre application :

Comme le montre la carte de trace, un « service d’adressage » est appelé plusieurs fois, ce qui n’est pas intentionnel du point de vue de la conception.
Le temps de réponse moyen de 36 ms pour ce service, multiplié par les sept requêtes, devrait nous donner un temps de 256 ms, bien différent du total de 2,64 secondes rapporté par le service membre.
La chronologie du segment dans l’application BFF indique que les appels de services sont exécutés en série.
Une durée de 2,8 secondes dépasse largement le budget de 150 ms défini par le SLO.

Nous nous rendons évidemment compte que la meilleure manière de satisfaire les paramètres du SLO, c’est de réparer le service membre ou d’en optimiser le code. Comme nous travaillons ici avec un système de traçage distribué, la trace du service membre est accessible, et un coup d’œil rapide trahit un temps de traitement conséquent après chaque requête au service d’adressage.

Révision du code

Passer le code en revue permet de comprendre ce qui se passe entre chaque requête au service d’adressage, mais soulève aussi de nombreuses questions.

L’application BFF sera mise à jour pour que les requêtes puissent être parallélisées sur les services utilisés

Tout d’abord, si le service d’adressage est capable d’accepter une table des identifiants de membres, pourquoi envoyer les requêtes une par une?
Ensuite, le code du point de terminaison « team » semble avoir été copié depuis celui du point de terminaison « member ».
1. L’adresse du membre est-elle vraiment nécessaire quand on veut récupérer une liste de membres d’équipe?
2. Le service d’adressage semble assez fragile. Qu’arrivera-t-il une fois l’application manipulée par des centaines d’utilisateurs?

Ce sont des questions intéressantes, mais quoi qu’il en soit, la conception se passe du service d’adressage : autant le supprimer. En plus, l’application BFF sera mise à jour pour que les requêtes puissent être parallélisées sur les services utilisés.

Comme l’indique la mesure à 121 ms dans notre trace finale, nous avons satisfait les 150 ms du SLO. Les requêtes envoyées aux services dorsaux s’exécutent comme prévu, c’est-à-dire en parallèle. Il est toujours possible d’optimiser le code en scrutant l’activité du service TODO.

Instrumenter et surveiller la performance d’une application donne de bien meilleurs résultats que de simplement regarder si elle augmente ou diminue. Le traçage distribué offre une vue d’ensemble de l’infrastructure d’une application, nous permettant de cibler avec précision les transactions qui impactent les SLO.

AWS X-Ray est l’un des nombreux outils d’observabilité pouvant être utilisé pour instrumenter le code d’une application. Si ce service est limité dans ses fonctionnalités et dans les langages avec lesquels il est compatible, il est très accessible et demande très peu d’infrastructure pour atteindre ses objectifs.