Test de charge pour les APIs de microservices à haute scalabilité

Les microservices changent la surface de panne. Un monolithe sous charge ralentit ; un service mesh sous charge propage en éventail — un seul appel downstream lent immobilise les threads worker en amont, les pools se vident, les retries s'accumulent, et une seule dépendance emporte le cluster entier. Ce template charge les sauts inter-services tels que le trafic de production les façonne, pas comme des hits d'endpoints isolés.

Ce qu'il teste réellement

Les scripts montent du RPS de base à 2x puis 5x du régime permanent, en tenant chaque palier 8 à 12 minutes pour que les pools de connexions, les allocations runtime JVM/Go et les décisions HPA se stabilisent. Tailles de payload mixtes, vrais tokens d'auth par utilisateur virtuel, et appels chaînés — gateway, auth, deux ou trois services downstream, puis une écriture — exerçant le même call graph que vos traces affichent en prod.

Modes de défaillance à attraper

• Épuisement du pool de connexions sur la couche gateway ou BFF — les limites HTTP keep-alive sont atteintes avant le CPU. Surveillez les connexions actives, pas seulement le CPU.
• Cascade de downstream lent — un service ajoute 400ms de p95 et trois services en amont s'effondrent avec lui parce que leurs timeouts par requête sont à 2s mais la taille de pool est à 50.
• Tempêtes de retry — un backoff exponentiel bien intentionné mais sans jitter, qui frappe en cadence un service déjà dégradé.
• Battement de circuit-breaker — les probes half-open partent au même instant depuis chaque réplica.
• Limites de stream gRPC HTTP/2 — MAX_CONCURRENT_STREAMS vaut 100 par défaut sur la plupart des serveurs ; un client REST à haut RPS avec une connexion par pod n'y touchera pas, un client gRPC si.

Cibles de latence qui veulent dire quelque chose

Suivez p50, p95, p99 par saut, pas seulement end-to-end. Un seuil de départ pour le trafic est-ouest : p99 sous 50ms pour les lectures de cache, sous 150ms pour les lectures avec DB, sous 300ms pour les sauts inter-services qui eux-mêmes font de l'éventail. Un p99 end-to-end de 1s est acceptable pour un checkout qui touche huit services ; catastrophique pour un endpoint de status qui en touche un. Le burn de l'error budget pèse plus que le taux d'erreur brut — 0,5% sur un pic de 5 minutes n'est pas 0,5% en régime soutenu.

Comment l'exécuter

Le template existe en versions JMeter et k6. k6 convient mieux pour HTTP/2, gRPC, et les graphes de requêtes scriptés ; JMeter est plus sûr si vous avez déjà une bibliothèque JMX éprouvée. Lancez depuis LoadFocus sur plusieurs des 26+ régions cloud pour que la latence inter-régions apparaisse dans vos chiffres — les tests mono-région sous-estiment systématiquement la tail latency des services distribués globalement.

Branchez le run dans la CI : Jenkins, Azure Pipelines ou CircleCI peuvent déclencher un run smoke-scale à chaque merge sur main et un run full-scale chaque nuit. Faites échouer le build sur régression p99 ou burn d'error budget, pas sur seuils absolus — les absolus dérivent, les deltas ne mentent pas.

Lecture des résultats

Les graphiques temps réel attrapent l'évident — throughput plat quand le RPS monte = saturation en amont du load generator, latence en dents de scie = GC ou autoscaling. Le travail post-run consiste à corréler les timings avec les traces APM et les métriques pod : quel service a vu son p99 bouger en premier, ce qu'a fait sa profondeur de pool, si son downstream a vraiment ralenti ou s'il a juste pris le blâme.

Le template, les scripts et l'historique des runs vivent dans LoadFocus — clonez-le, pointez les variables sur votre gateway, réglez la concurrence, et laissez tourner.