Qu'est-ce que le scalability testing ?

Qu'est-ce que le scalability testing ?

Le scalability testing mesure comment la performance d'un système change quand vous ajoutez des ressources : plus de pods, plus de nodes, instances plus grandes, plus de réplicas de base de données. L'objectif est de valider qu'ajouter 2× d'infrastructure donne près de 2× de throughput (scaling linéaire), pas 1,2× (sub-linéaire, scaling cher) ou 0,5× (scaling négatif par overhead de coordination).

Scalability testing vs load testing

Un load test mesure la performance à une taille fixe d'infrastructure. Le scalability testing mesure la performance à travers plusieurs tailles d'infrastructure :

• Load test à 1 000 RPS sur 1 node → p95 latency 600 ms.
• Scalability test à travers 1, 2, 4, 8 nodes → 8 nodes gèrent-ils 8 000 RPS à 600 ms (linéaire), 6 000 RPS à 600 ms (sub-linéaire) ou 4 000 RPS à 1 200 ms (overhead de coordination domine) ?

Le scalability test n'est pas un seul run. C'est une série de load tests à capacité croissante, avec les données tracées pour montrer la courbe de scaling.

Scalabilité horizontale vs verticale

• Scalabilité horizontale : ajouter plus de nodes / pods / containers. Test en exécutant la même charge contre 1, 2, 4, 8, 16 instances.
• Scalabilité verticale : augmenter les ressources d'un node (CPU, mémoire, disk IOPS). Test en exécutant la même charge contre des instances small, medium, large, xlarge.

La plupart des systèmes modernes devraient scaler horizontalement proprement. Les systèmes stateful (bases de données surtout) scalent souvent verticalement jusqu'à atteindre des limites hardware, puis ont besoin de sharding ou read-replicas pour plus de scale.

Quand exécuter des scalability tests

• Avant d'engager un budget infrastructure. Si vous avez besoin de 10 000 RPS et que chaque node en gère 1 000, vous faut-il 10 nodes ou 15 ? Le scalability testing vous dit le vrai ratio.
• Valider l'autoscaling. L'autoscaling suppose qu'ajouter des pods ajoute une capacité proportionnelle. Le scalability testing confirme (ou trouve l'overhead de coordination qui casse l'hypothèse).
• Pre-changement-architecture. Migration de monolithe vers microservices ? Les caractéristiques de scaling de la nouvelle architecture sont inconnues jusqu'au test.
• Validation de scaling DB. Ajouter des read replicas, du sharding ou aller vers un managed scaling service ? Valider que la nouvelle topologie scale comme annoncé.
• Évaluation de vendor. Comparaison Aurora vs RDS vs DynamoDB ? Exécutez la même workload contre chacun à scale croissant et comparez.

Métriques clés de scalability test

1. Facteur de scaling. Throughput à 2N nodes / throughput à N nodes. Devrait être ~2,0 pour un scaling linéaire.
2. Throughput par node. Throughput à scale divisé par le nombre de nodes. Devrait rester constant ; s'il chute, vous touchez l'overhead de coordination.
3. Latence par node. Latence à scale vs latence single-node. Devrait rester constante ou s'améliorer ; si elle grimpe, la coordination est chère.
4. Décomposition de l'overhead de coordination. Où va le temps quand le scale grandit ? Appels réseau cross-node ? Distributed locks ? Protocoles de consensus ? Identifier la source de l'overhead vous dit ce qu'il faut corriger.

Comment exécuter un scalability test

La mécanique : exécutez le même load test contre le système à plusieurs tailles d'infrastructure. Tracez throughput, throughput par node et p95 latency à travers les tailles.

Dans JMeter ou k6, le script reste identique entre runs. Changez seulement l'infrastructure (scaler le deployment, changer la classe d'instance, ajouter des read replicas). Le load test mesure alors la performance résultante.

Exécutez depuis LoadFocus pour une génération de charge consistante à travers la série de tests. Utiliser les mêmes régions et le même VU count garantit que la seule variable est votre infrastructure, pas le test harness.

Pour des scalability tests qui informent la planification d'infrastructure pluriannuelle, LoadFocus propose des load testing services où des ingénieurs conçoivent les points de scale, exécutent la série de tests et produisent l'analyse de courbe de scaling avec des implications coût-par-RPS.