Identifier les points de blocage et de défaillance d’une application est le premier souci des développeurs qui veulent assurer la livraison d’un produit fiable, réactif et robuste. Les tests de charge sont devenus une étape essentielle dans le cycle de développement logiciel, malgré la complexité de mise en place de la charge et des scénarios de test.
Ces configurations sont nécessaires pour simuler les différents cas d’utilisation de l’application et évaluer sa réactivité. Cet article approfondit les concepts des tests de charge au sein de l’écosystème Azure, en explorant ses détails et ses paramètres de configuration.
1. Qu’est ce que le service de test de charge Azure ?
C’est le service qui permet aux entreprises et développeurs de configurer et exécuter différents types de tests de charges sur leurs applications. Grâce à une multitude de configuration et paramétrages, ils pourraient identifier les défaillances de l’application, ainsi que les améliorations qui pourraient être apportées pour avoir une application plus résiliante.
2. Les concepts des tests de charge
2.1 – JMeter
JMeter est un logiciel Open Source qui sert à évaluer le comportement fonctionnel des applications en mesurant leurs performances dans diverses conditions. Son avantage le plus important est son degré de flexibilité qui permet aux développeurs d’ajuster leurs tests de charge en fonction de leurs scénarios et besoins spécifiques. Il s’agit de scripts de tests qui décrivent en détails les différents profils de charge (Load Test profile) pour les implémenter sur l’infrastructure d’Azure.
2.2 – Instance de moteur de test
C’est une ressource de type infrastructure, localisée dans le même conteneur logique (Resource group) que les tests de charge sur Azure, gérée par Microsoft et dont la tâche est d’exécuter les scripts de test Apache JMeter. Ce moteur sert donc à configurer les tests de charge, étant donné que les scénarios sont dépendants du nombre des instances provisionnées ainsi que du nombre des utilisateurs virtuels. Le service de test de charge Azure est, lui, chargé de la collection et l’agrégation des différentes logs générées par ces moteurs de tests lors de l’exécution des scénarios configurés.
2.3 – Simulation du Trafic
Le test de charge Azure permet aux développeurs de simuler différents scénarios d’utilisation avec un nombre variable d’utilisateurs ainsi que d’instances de serveur, tout en surveillant la réponse du système aux changements de l’environnement simulé.
2.4 – Débit
Nommé aussi Requête par seconde (RPS), le débit est l’indicateur du nombre des requêtes que le service de test de charge transmet au serveur en une seconde. Il est le résultat de division de nombre totale des requêtes à faire par le temps d’exécution (en secondes). Il faut prendre en considération que le temps d’exécution total inclus les pauses entre les threads si le script des tests JMX inclus des temporisations.
2.5 – Evaluation de la performance
Le service de test de charge ne cesse pas de présenter différents types d’indicateurs notamment les temps de réponses, le débit, l’utilisation des ressources et d’autres clés de performances, chaque 5 secondes afin de présenter l’évolution de consommation des ressources ainsi que le temps de réponse de l’application tout au long du test subi.
On peut identifier deux types de métriques :
Métrique serveur : Comme le service de test de charge Azure s’intègre aux services Azure Monitor, nous pourrons voir les journaux capturés en fonction du service en cours d’exécution (journaux de messages spécifiques définis dans l’application, consommation de ressources, requêtes de base de données ou requêtes HTTP).
Métrique client : Résultats fournis par le moteur de test, comprenant tous les aspects du test : nombre d’utilisateurs virtuels, nombre de requêtes par seconde, nombre de requêtes réussies/échouées, et bien plus encore.
2.6 – Utilisateurs virtuels
Dans Apache JMeter, ils sont appelés threads, aussi, un groupe d’utilisateurs virtuels est appelé Thread Group. Chaque utilisateur virtuel exécute un cas de test particulier sur l’application indépendamment des autres threads. Cependant, la gestion du nombre d’utilisateurs virtuels n’est pas toujours contrôlée directement, elle peut également être effectuée à travers le nombre d’instances du moteur de test. La formule pour calculer le nombre total d’utilisateurs virtuels est la suivante :
Nombre total d’utilisateurs virtuels = (utilisateurs virtuels dans le fichier JMX) * (nombre d’instances du moteur de test).
Figure 1: Architecture de test de charge dans un environnement Azure
3. Configurations du test de charge
3.1 – Profils de charge
C’est la définition des différents scénarios qui imitent l’intensité des interactions utilisateurs, les divers cas d’utilisation de l’application ainsi que la fréquence des requêtes. Cela permet d’avoir un environnement de test plus complet et réaliste.
Figure 2: Configuration de nombre de moteur d’exécution du test de charge
3.2 – Conditions réseau
La simulation de conditions telles que la latence, la bande passante et les protocoles aident à visualiser les performances de l’application dans des contraintes réseaux spécifiques.
3.3 – Durée des tests
Elle représente la période pendant laquelle le test de charge est effectué, pouvant varier de quelques secondes à plusieurs jours. C’est un facteur important du test de charge car il permet aux développeurs de tester le fonctionnement de l’application sous charge soutenue pendant des périodes prolongées (tests de stress), en détectant toute dégradation ou problème pouvant survenir au fil du temps.
3.4 – Temps de montée en charge (Ramp Up)
Dans le contexte des tests de charge, le temps de montée en charge est la durée nécessaire pour embarquer progressivement tous les utilisateurs virtuels du test de charge. Il contrôle la rapidité avec laquelle les utilisateurs commencent à interagir avec l’application testée. L’objectif est de simuler le scénario où la charge des utilisateurs augmente progressivement au lieu d’atteindre instantanément la capacité maximale. Par exemple, si nous avons 5 utilisateurs dans le test en question, et que nous voulons qu’un nouvel utilisateur rejoigne l’application toutes les 5 secondes, le temps de montée en charge sera de 5*5=25 secondes.
Figure 3: Configuration des paramètres du test de charge
3.5 – Critères de test
Ici, on peut spécifier les valeurs anticipées pour les différentes métriques tels que la latence, le temps de réponse, nombre des requêtes ou des erreurs au-dessous ou au-dessus desquelles le test sera défini comme test échoué et réussi. On peut aussi configurer le comportement de tests lors de l’atteinte de ces seuils et les arrêter grâce à l’option auto stop.
Figure 4: Configuration des critères de test de charge
4. Exécution des tests de charge dans Azure
Pour cet exemple, nous aurons besoin d’un abonnement Azure actif ainsi que du rôle RBAC approprié permettant la création et la gestion des ressources dans l’abonnement (Contributor/Owner).
4.1 – Création de la ressource de test de charge Azure
Après avoir connecté et filtré le service de test de charge Azure depuis le champ de recherche, vous pouvez procéder à la création du service en configurant l’abonnement, le groupe de ressources, le nom et la région. Enfin, vous pouvez appuyer sur le bouton de création pour provisionner votre ressource.
4.2 – Création du test de charge Azure
Pour poursuivre les tests, nous devons spécifier une URL spécifique de l’application ou du service qui sera testé. Aussi, nous aurons besoin de soit télécharger un script JMeter qui contient la configuration et les profils de charge du test, ou de configurer ces détails manuellement dans Azure. Pour cet exemple, nous opterons pour la dernière option.
4.3 – Configuration du profil de charge des tests
Sur la configuration du service de test de charge Azure, nous pouvons définir le profil de charge via le nombre d’utilisateurs virtuels ou les requêtes par seconde (RPS). Une fois que vous avez fait votre choix sur le type de charge, vous devrez configurer les paramètres en fonction de votre choix. Si nous optons pour les utilisateurs virtuels, nous devrons remplir le formulaire avec le nombre d’utilisateurs virtuels, la durée du test et le temps de montée en charge. Azure Load testing créera automatiquement un script Apache JMeter pour le test de charge en fonction de la configuration que nous venons de faire ; vous pouvez télécharger le script depuis l’exécution du test sur le tableau de bord.
Figure 5: Configuration du script JMeter du test de charge
Remarque : au lieu de configurer les paramètres du test sur le tableau de bord, nous pouvons définir la configuration dans le fichier de script JMeter et le télécharger vers le service de test de charge Azure.
4.4 – Surveillance des résultats du test
Une fois le test démarré, nous obtiendrons un tableau de bord qui affiche les métriques côté client, actualisées toutes les cinq secondes. Le tableau de bord offre plusieurs options et filtres pour adapter les métriques graphiques afin d’afficher différentes clés de performance, les agréger ou les filtrer.
Figure 6: Tableau de bord des métriques client du test de charge
5. Intégration des tests de charge Azure dans les pipelines CI/CD
Les tests de charge automatisés peuvent facilement être intégrés dans le processus de déploiement en utilisant Azure DevOps, car cela permet d’exécuter les tests de charge après chaque commit ou avant chaque version pour s’assurer que la livraison pourra gérer les cas d’utilisation couverts dans notre test de charge.
Avant de plonger dans la configuration du pipeline, nous devons nous assurer que notre configuration inclut les exigences suivantes : un abonnement Azure actif, un compte avec le rôle d’administrateur d’application, un projet et une organisation Azure DevOps connectés à un identifiant Microsoft Entra, et une ressource de test de charge.
Étapes à suivre :
Depuis l’interface de la ressource de test de charge, nous cliquons sur l’option Configurer CI/CD et remplissons les détails du formulaire avec l’organisation, les projets, le repository et la branche.
Figure 7: Configuration du chaine CI/CD du test de charge
Une fois la création du pipeline terminée, une notification apparaîtra dans votre portail Azure avec un lien vers le pipeline, à partir duquel vous pouvez exécuter le pipeline/modifier ses étapes ou déclencheurs.
Figure 8: Lancement du chaine CI/CD du test de charge
Lorsque vous accédez au pipeline et essayez de l’exécuter, vous devrez lui donner l’autorisation d’accéder à la ressource de test de charge et installer Azure Load Test à partir du visual studio Market Place.
Figure 9: Téléchargement du service Azure load testing de visual studio market
Une fois cela est fait, le pipeline CI/CD commence à exécuter le test.
Enfin, nous pourrons voir les journaux des tests et leurs résultats dans l’artefact du pipeline, et nous pourrons également le télécharger pour une analyse ultérieure.
Figure 10: Les logs d’exécution du chaine CI/CD du Test de charge
Les tests de charge ne sont plus une option dans le paysage numérique actuel, ils sont devenus une partie cruciale du flux de développement. Dans cet article on a exploré profondément les principes et concepts de ce genre de test en étudiant son intégration dans un environnement Azure ainsi que les chaînes CI/CD d’Azure DevOps, ce qui aide les développeurs à garantir la livraison continue des applications qui assurent une performance persistante sous différentes circonstances.