Dev

Tests de charge des microservices, enjeux et méthodologie

Par La rédaction, publié le 25 juillet 2024

Tandis que l’architecture de microservices acquiert ses lettres de noblesse, les développeurs s’aperçoivent que les méthodes de tests de charge « traditionnels » sont à repenser. Voici la méthodologie à suivre.

Par Paul-Henri Pillet, CEO de Gatling

Ces dernières années, nous constatons qu’une grande partie de l’architecture logicielle moderne s’articule autour des microservices. Cette approche permet d’isoler chaque composant logiciel. Corollairement, il est nettement plus simple d’ajouter de nouvelles fonctionnalités ou de les faire évoluer, qu’avec une approche du développement dite «monolithique».

Qu’est ce qu’un microservice, et pourquoi le tester indépendamment ?

Mais concrètement, qu’est ce que l’on appelle un microservice ? Un microservice est un petit service indépendant focalisé sur une fonction spécifique. Prenons l’exemple d’une application d’e-commerce. Dans ce contexte, un microservice peut désigner le module de gestion des stocks, de recommandations de produits… ou bien encore de traitement des paiements.

Un des avantages de l’architecture microservices est qu’il permet une plus grande résilience des applications : si un microservices ralentit ou même crashe, il n’entraîne pas le reste de l’application. En revanche, il peut impacter l’expérience utilisateur avec de forts ralentissements ou même l’impossibilité de réaliser certaines actions. Les architectures microservices ne sont donc pas l’abri des problèmes de charge et des pertes de revenus qui leur sont liés.

Mais alors pourquoi tester un microservice qui fonctionne très bien habituellement, plutôt que de réaliser un test de bout en bout ?

La mise en œuvre de tests de bout en bout pour les systèmes basés sur des microservices :
– est une procédure plus lourde,
– et le test ne permettra pas d’identifier avec précision les points de vigilance au sein de l’architecture, ni leurs impacts sur l’application

Qu’est ce qu’un test microservice ? Les trois types de tests…

De nombreux microservices interagissent les uns avec les autres, si bien qu’une dégradation des performances de l’un d’entre eux impactera les autres et plus largement la fiabilité du logiciel… Il est donc essentiel d’investir des ressources dans des tests qui permettent d’identifier le maillon faible et de le sécuriser.

Ces tests consistent à mesurer le temps de réponse d’un microservice en fonction d‘une charge (injectée) d’utilisateurs ou de requêtes simultanés, afin d’observer la charge maximale qu’il peut gérer avant l’altération des performances.

Il convient de réaliser trois types de test dans un ordre spécifique :

1) Le test unitaire – Ces tests adressent le microservice de manière isolée. Ils sont réalisés tôt et régulièrement dans le cycle de vie du développement, et sont exécutés dans le cadre de l’automatisation en intégration continue et la distribution/déploiement continus.

2) Le test d’intégration – ce domaine de test se concentre sur la capacité d’un microservice à interagir avec d’autres ainsi que leurs dépendances. Il porte sur les requêtes échangées entre les services, afin d’observer les performances des canaux de communication qui permettent la liaison entre ces services.

3) Le test de bout en bout ou end-to-end – ces tests couvrent l’ensemble du parcours de l’utilisateur de l’application, en utilisant tous les microservices pertinents. Les tests de bout en bout sont généralement effectués par le biais d’une interface utilisateur ou en déclenchant les appels API correspondant à un parcours utilisateur dans l’ordre prévu.

Bien évidemment, nous sommes ici en présence d’une approche en “entonnoir inversé”. En haut, le test le plus spécifique, en bas, celui de bout en bout, dont le coût, l’effort et la complexité augmentent, tandis qu’inversement, la fiabilité, la vitesse et l’isolation diminuent.

Nous savons désormais pourquoi et comment réaliser ces tests, il nous reste à déterminer leurs fréquences.

Mesurer la performance des microservices dans le temps

L’une des raisons du succès de l’architecture de microservices réside dans la rapidité des livraisons qu’elle induit. Le développement des microservices se fait à un rythme soutenu, avec généralement plusieurs versions différentes d’un même service, le tout réalisé sur une courte période. Il est donc essentiel de suivre les niveaux de performance du service dès la phase de développement afin de déterminer si les modifications ont entraîné une détérioration des performances

La simplicité des tests unitaires permet d’en faire de manière très régulière tout au long du cycle de développement. Réaliser des tests de charge sur des microservices isolés va ainsi cartographier avec précision les probables points de ruptures de votre application. Certaines organisations vont même jusqu’à automatiser les tests de charge à chaque commit, c’est-à-dire à chaque fois qu’un développeur modifie l’application. Cela permet aisément de voir exactement ce qui a introduit dans votre microservice un problème de performance. Il n’est ainsi pas rare de voir des organisations réaliser des centaines, voire des milliers de tests de charge par jour !

Anticiper et sécuriser la capacité des microservices à recevoir (sans faille) un afflux de requêtes, est la garantie d’une architecture logicielle efficiente et durable. Pour aider les développeurs dans cette tâche chronophage, il existe aujourd’hui des solutions qui permettent d’automatiser les tests, d’en retirer plus d’informations critiques, et ainsi d’éviter des crashs et, de facto, les pertes de revenus.

À LIRE AUSSI :