Qu'est-ce que le scalability testing ? Test de scalabilité

Qu'est-ce que le scalability testing (test de scalabilité) ?

Le test de scalabilité mesure comment la performance d'un système évolue quand on ajoute ou retire des ressources : plus de pods, plus de nœuds, des instances plus grosses, plus de réplicas de base de données. Le but est de savoir si doubler l'infrastructure double à peu près le débit (scalabilité linéaire), ou si le gain s'aplatit (sous-linéaire) voire s'inverse à cause du coût de coordination. Il montre ce que la capacité supplémentaire apporte vraiment.

Test de scalabilité et test de charge

Un test de charge mesure le comportement pour une taille d'infrastructure fixe. Un test de scalabilité répète le même test de charge à plusieurs tailles et compare les résultats. Proche mais distinct, le test de capacité demande quelle charge une configuration supporte avant de manquer ses objectifs.

Exemple avec des chiffres d'illustration : avec 1 nœud, le système traite 1 000 requêtes par seconde pour une latence p95 de 600 ms. Avec 8 nœuds, une scalabilité linéaire donnerait 8 000 requêtes par seconde à latence égale. Si vous mesurez 6 000, la scalabilité est sous-linéaire ; si la latence monte à 1 200 ms pour 4 000, la coordination absorbe le gain.

Scalabilité horizontale et verticale

• Horizontale : ajouter des instances. Lancez la même charge sur 1, 2, 4, 8 instances derrière un répartiteur de charge.
• Verticale : donner plus de CPU, de mémoire ou de débit disque à une instance. Lancez la même charge sur des tailles petite, moyenne et grande.

Les couches web sans état passent généralement bien à l'échelle en horizontal. Les bases de données et autres composants avec état montent souvent d'abord en vertical, puis demandent des réplicas ou du sharding : ce sont justement ceux qu'il faut tester.

Comment réaliser un test de scalabilité

1. Choisir une charge fixe. Un mélange de parcours scriptés, un jeu de données, les mêmes régions de charge, pour que l'infrastructure soit la seule variable.
2. Choisir les paliers. Par exemple 1, 2, 4 et 8 nœuds, ou trois tailles d'instance.
3. Mener chaque palier jusqu'au régime stable. Pour chaque taille, trouvez la charge maximale qui respecte encore vos objectifs de temps de réponse et d'erreurs.
4. Tracer la courbe. Débit, débit par nœud et latence p95 en fonction de la taille.
5. Chercher le goulot là où la courbe plie. Examinez connexions à la base, verrous, caches partagés, réseau et répartiteur de charge.

Ce qu'il faut mesurer

• Facteur de scalabilité : débit à 2N divisé par débit à N. Proche de 2,0, c'est linéaire.
• Débit par nœud : doit rester à peu près constant. Une baisse signale un surcoût.
• Latence p95 par taille : doit tenir ou s'améliorer, pas grimper.
• Coût par requête : le résultat pratique, car une courbe sous-linéaire signifie que chaque nœud en plus coûte davantage par unité de travail.
• Comportement de l'autoscaling : le délai avant que les nouvelles instances aident, ce que révèle le test de pic.

Erreurs fréquentes

• Changer le test entre deux exécutions. Un autre script, d'autres régions ou un autre volume de données rendent la courbe inutilisable.
• Ne monter que la couche applicative. La base ou un cache partagé devient le plafond et la courbe s'aplatit tôt.
• Démarrer à froid. Réchauffez d'abord caches et pools de connexions, sinon le premier palier paraît pire qu'il n'est.
• Limites du générateur de charge. Si le générateur sature, vous mesurez le générateur, pas le système.
• Trop peu de paliers. Deux tailles donnent un rapport, mais pas l'endroit où la courbe plie.

Outils et pour aller plus loin

Les mêmes scripts servent à chaque palier : tout outil de test de charge convient, avec en général JMeter et k6. LoadFocus exécute les deux depuis 25 régions cloud, ce qui garde une génération de charge constante sur toute la série. Pour des conseils selon l'architecture, voyez le guide du test de charge des microservices dans le cloud (en savoir plus sur les microservices) et le tour d'horizon des types de tests de performance.

Questions fréquentes : scalability testing

Quelle différence entre test de scalabilité et test de charge ?

Le test de charge vérifie la performance à une taille fixe. Le test de scalabilité enchaîne des tests de charge à différentes tailles pour voir comment la performance évolue avec les ressources.

Qu'est-ce que la scalabilité linéaire ?

Le débit croît proportionnellement aux ressources : deux fois plus de nœuds, environ deux fois plus de requêtes par seconde à latence égale.

Scalabilité horizontale ou verticale : laquelle tester ?

Celle sur laquelle repose votre architecture. Beaucoup de systèmes utilisent les deux : horizontale pour les services sans état, verticale (puis réplicas ou sharding) pour les bases de données.

Un test de scalabilité valide-t-il l'autoscaling ?

En partie. Il montre si la capacité ajoutée sert à quelque chose. Pour voir à quelle vitesse l'autoscaling réagit, associez-le à un test de pic et observez la latence pendant le démarrage des nouvelles instances.

Combien de paliers faut-il ?

Au moins trois ou quatre, par exemple 1, 2, 4 et 8 nœuds, pour voir la forme de la courbe et pas seulement un rapport.