La surveillance continue des logiciels de Klever pour améliorer la qualité du service, par l'ingénieur en fiabilité du site Kadu Barral

Vous avez probablement entendu parler des pratiques DevOps et de la façon dont elles aident à fournir en permanence de meilleurs produits et services. Sinon, je vous invite à lire cet article, avec une explication un peu plus approfondie à ce sujet.

Aujourd'hui, nous allons parler de Monitoring, qui est une partie importante du cycle de vie des applications utilisé dans DevOps.

Pendant des années, la surveillance était simplement considérée comme un moyen de découvrir quand des problèmes surviennent et n'avait qu'une seule fonction - alerter l'équipe responsable pour le résoudre - les équipes travaillaient généralement comme des pompiers et après cela, personne n'en parlait.

Nous ne pensons pas que ce soit une façon intelligente de travailler, car la surveillance nous donne beaucoup d'informations et le simple fait de l'utiliser lors des dépannages est un tel gaspillage de données et d'informations précieuses.

Dans cette série d'articles, notre objectif n'est pas (du moins pour l'instant 😉) d'écrire sur la façon dont nous mettons en œuvre les pratiques d'ingénierie de la fiabilité des sites, mais plutôt de vous montrer deux optimisations de performances récemment effectuées par l'équipe Klever DevOps, fournies à l'écosystème Klever et pourquoi cela n'était possible qu'avec l'observabilité.

Services distribués à l'échelle mondiale

Une méthode que nous utilisons pour surveiller la disponibilité de nos services consiste à tester chacun d'eux avec des tests synthétiques.

La surveillance synthétique est une technique qui utilise des moyens d'émuler le comportement de l'utilisateur pour assurer le fonctionnement des systèmes surveillés.

Le flux d'actions de l'utilisateur est émulé via un autre logiciel, généralement des scripts, et s'exécute de manière répétée à des intervalles de temps spécifiés pour des mesures de performances telles que : fonctionnalité, disponibilité et temps de réponse.

En bref, nous avons des « robots » dans différentes parties du monde émulant les fonctionnalités de nos applications, et si un bot ne peut pas terminer la tâche, une alerte est envoyée à notre équipe qui prend alors des mesures proactives.

Cela fonctionne très bien pour découvrir les problèmes au moment où cela se produit, mais nous donne également le temps de réponse de nos services dans tous les emplacements, et plus encore, l'outil de surveillance divise également le temps passé dans chaque partie des transactions HTTP.

• connexion

• traitement

• résolution

• tls

• transfert

Avec ces données, nous avons pu observer que pour certains emplacements, les demandes prenaient trop de temps en trois phases : connexion, tls et transfert.

Solution au problème de latence globale

Réduire le temps de connexion et de transfert est un défi. La solution consiste à « déplacer » les applications backend aussi près que possible des clients pour réduire la latence du réseau.

Comme Klever dispose d'une base d'utilisateurs et de clients dans le monde entier, la réplication de nos services dans toutes les régions peut s'avérer coûteuse et difficile à maintenir. Pour cette raison, nous avons décidé de migrer de notre équilibre de charge traditionnel vers le GCLB de Google qui fournit un équilibrage de charge entre régions avec des points de présence (PoP) dans le monde entier.

Une fois les connexions établies dans le PoP le plus proche, tout le trafic vers notre backend kubernetes et nos bases de données transitent sur le réseau interne de Google, nous avons également déplacé la terminaison TLS d'ingress-nginx vers l'équilibreur de charge Edge pour réduire le temps TLS. Avec cette décision, le temps de réponse moyen a été réduit de moitié, comme le montre le graphique ci-dessous.

Échanger le temps de réponse de l'API

Cette optimisation du temps de réponse de l'API Klever Swap est intrinsèquement différente du premier exemple car elle n'implique aucun changement d'infrastructure.

Notre pile de surveillance nous a aidés à identifier les goulots d'étranglement et, avec l'équipe Swap, nous avons apporté des modifications au code source, ce qui a permis d'améliorer de 60% le temps de réponse pour la méthode API la plus appelée - celle qui est responsable de la liste des paires de clés actives de Swap.
Avec un mouvement Klever et une diminution de la consommation du processeur du serveur, la vitesse de tous les swaps dans Klever a considérablement augmenté.

Dans les architectures logicielles distribuées telles que celles utilisées par Klever pour servir nos utilisateurs dans le monde, il est parfois difficile de trouver quelle étape exacte de l'ensemble du processus informatique distribué est à l'origine de toute lenteur potentielle détectée.

Pour cette raison, le traçage distribué est essentiel pour comprendre comment une demande se déplace entre plusieurs services, packages et composants d'infrastructure.

Dans ce scénario spécifique, avec le traçage distribué, nous réalisons que l'API a été constamment appelée, même sans transaction Swap, et a trouvé une solution.

Optimisation du temps de réponse de l'API Swap

Il s'agit d'un cas typique de monolithe où un service est responsable de plus d'un objectif. Notre fonctionnalité Swap est fantastique, facile à utiliser et a été l'un de nos premiers services dans l'application. À cette époque, la fonctionnalité permettant de renvoyer les prix des pièces était intégrée à l'API Swap.

Avec l'évolution de nos produits, la croissance des utilisateurs et l'augmentation des pièces disponibles pour Swap, nous avons réalisé qu'il était nécessaire de scinder cette fonctionnalité dans un autre service. Essentiellement pour séparer et distribuer les prix et les services d'échange pour rendre l'ensemble de la fonction d'échange plus rapide, plus fiable et plus efficace.

Après ce changement, d'autres écrans de l'application peuvent consulter les prix actuels sans impacter les performances globales du Swap et nous avons pu adapter le service séparément en fonction de la demande.

Conclusion

Dans cet article, nous avons présenté deux exemples de la façon dont la surveillance continue de nos services nous aide à proposer des produits de haute qualité et en constante évolution à notre communauté d'utilisateurs Klever.

Bien sûr, cette surveillance implique beaucoup plus que ce que nous avons couvert aujourd'hui et les bases sont également très importantes :

Veiller à ce que tous les services Klever soient opérationnels est le cœur qui fait couler notre sang.

Une bonne stratégie de surveillance réduit notre MTTA et MTTR et permet à notre équipe d'astreinte 24h/24 et 7j/7 répartie dans le monde entier de rester toujours au courant des problèmes possibles et de mieux évoluer pour l'avenir grâce à des mesures proactives. Notre CTO Bruno en a parlé un peu dans son article ICI

Garder le suivi des microservices est un défi dans les architectures logicielles distribuées et la surveillance est un cycle de progrès ininterrompu pour l'équipe Klever DevOps. Mais c'est un discours pour une autre fois !

Sincèrement,

Kadu Relvas Barral

Ingénieur en fiabilité du site de Klever

Kadu a plus de 15 ans d'expérience professionnelle dans l'informatique et a passé les 10 dernières années à travailler dans des sociétés d'assurance, de télécommunications et financières à essayer de trouver ce qui ne fonctionnait pas dans leurs systèmes avant que d'autres ne le découvrent. Marathoniste à temps libre, aime courir et faire tourner les applications.

Télécharger Klever