Tests de charge et profils de stress

Résumé succinct

Les tests de charge sont des tests systématiques de performance et de stabilité sous des scénarios réalistes et extrêmes. Base du succès : modèle de trafic correct (open vs closed) fixé par SLO, métrique propre (latency/throughput/bugs/saturation), données représentatives, automatisation et répétabilité. Le résultat n'est pas un « chiffre RPS », mais une solution : où les goulots d'étranglement, combien coûte la performance, où le seuil de défaillance et comment le déplacer.

SLO/SLI et métriques cibles

SLO (exemple) : API p95 ≤ 250 ms, p99 ≤ 600 ms ; Erreur ≤ 0. 3 %/30 jours.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Budgets d'erreur et déclencheurs de saturation (par exemple CPU> 75 % ou queue depth> X → dégradation).

Types de tests

1. Baseline/Benchmark - service unique/endpoint, conditions « idéales ».
2. Load est un « jour ouvrable » réaliste + ramp-up/ramp-down.
3. Stress - nous augmentons la charge de travail jusqu'à la dégradation et la fixation de breakpoint.
4. Spike est un bond brusque (x2-x10 en secondes/minutes).
5. Soak/Endurance - longue course (8-72 h) : fuites de mémoire, dérive de latence.
6. Capacity : Charge par étapes pour la courbe des performances et la planification de la capacité.
7. Degradation/Chaos-mix - charge + pannes partielles (OBD ralentie, chute du cache, aplinc « arraché »).

Modèles de trafic : Open vs Closed

Modèle ouvert (plus réaliste pour Internet) : les utilisateurs viennent avec une intensité de λ (Poisson-like stream). Si le système freine, les requêtes s'accumulent et non « gelées ».
Modèle fermé : nombre fixe d'utilisateurs virtuels (VU) avec think-time. Lorsque le délai augmente, le RPS tombe artificiellement - prudent avec les conclusions.
Recommandation : pour les API de première ligne, utiliser open model (k6 'arrival-rate'), pour les scénarios synchrones internes - combiner avec closed.

Profils de charge (modèles)

« Journée normale » : fond de base + fluctuations diurnes.
« Pic-event » : 10-30 min avant le départ (chauffage), spike au départ, plateau, queue.
« Tournoi/stream » : échafaudage, pics répétés dans les intervalles.
« Dégradation des infrastructures » : la moitié du cache est vide, une région est éteinte, augmentation de la latence du PSP.
« Failover » : le trafic passe à la réserve en 1 à 5 min ; nous vérifions les tempêtes auto-skale/HPA/Retry.

Données et préparation de l'environnement

Données de test : cardinalité réaliste (fournisseurs, devises, pays), champs « sales », distributions de demandes (Pareto/Zipf).
Secrets/PII : anonymisation ; clés/PSP - sandbox.
Environnement : stand perf dédié, isolation des intégrations (mock/meute), versions fixes.
Observabilité : métriques (Prometheus), logs (Loki/ELK), tracés (OTel). Enregistrer le build-id dans les réponses.

Antistorme des rétrogrades et idempotence

Retraits uniquement pour les opérations idempotentes ; mettez retry-budget (par exemple, ≤ 10 % du trafic).
Exponential backoff + jitter; « collapsing » de GET identiques.
Pour les paiements - clés idempotent et statuts explicites.
Protection contre le thundering herd : Cache loki, SWR, sémaphores locaux.

Outils et modèles

k6 (script, open-model, bons rapports), Locust (Python-scripts), Gatling (Scala), JMeter (un large éventail de protocoles).
Protocoles : HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; Ne testez pas le serveur push « comme GET ».
Génération de trafic : mise à l'échelle horizontale des générateurs, contrôle du goulot d'étranglement du réseau.
Mangeons les profils : pprof/async-profiler/ebpf sous charge, pistes OTel.

Mini-exemple k6 (open-model + spike) :

javascript import http from 'k6/http';
import {check, sleep} from 'k6';

export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};

export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}

Méthode d'exécution

1. L'hypothèse → quels goulots d'étranglement sont probables (CPU, OBD, cache, réseau, TLS, GC).
2. Profil → scripts/itinéraires, part du trafic, modèles (ouverts/fermés), données.
3. Échauffement → cache/connexions/TLS/interprètes.
4. L'augmentation de l'étape → à l'intensité cible.
5. Le plateau → la collecte de métriques et de pistes stables.
6. Stress/déclin → recherche d'un point de fracture, observation de l'auto-skate.
7. Analyse → corrélation des métriques, flamegraph, rapport et plan de changement.
8. Le republication → une répétition via le pipline CI (Région Perf).

Analyse des résultats

Courbe « Charge → retard/erreur » : recherchez un genou (capacity).
Breakdown de latence : réseau (DNS/TLS/connect), proxy, application, OBD, appels externes.
Saturation : CPU> 75-85 %, GC pause> p95, I/O-anticipation, file d'attente de tâches.
Élasticité : temps de réaction du skate automatique (HPA/KEDA), « démarrage à froid », échauffement du cache.
Coût : $/1000 RPS avec SLO cible, prévisions budgétaires par pic.

Pratiques d'ingénierie

Indicateurs de dégradation : « queues » p99, augmentation des files d'attente, chute de hit-ratio, augmentation des tentatives de rétraction.
Excluez les confounders : limites des descripteurs de fichiers, sysctl, bou-pool, « reuseport », chaîne TLS, OCSP.
Bases de données : index/plans/cache de requêtes, pool de connexions, opérations batch, backpressure sur les vendeurs.
Caches : Taille/stratégie d'évaluation, clés chaudes, réplications.
Réseau/edge : HTTP/2/3, resumption≥70 %, Brotli, clé CDN de cache, tiered-cache.

Observabilité sous charge

Métriques : système (CPU/mem/IO), runtime (GC/heap), réseau (RTT/loss/ECN), L7 (p95/99, 5xx/429), files d'attente, clusters OBD/cache.
Tracés : inclure l'échantillonnage sur les « queues » (tail-based), les marques build-id/canari.
Logs : agrégation d'erreurs avec limitation de volume (afin de ne pas « pourDOSou » log-pipline).
Expériences : feature-flags et configi doivent être enregistrés dans le rapport.

Automatisation et CI/CD

Perf-jobs en CI (smoke 3-5 min, nightly 30-60 min, weekly soak).
Limites de tolérance : latence/erreurs/ressources → « casser le billet » en cas de régression.
Artefacts : graphiques, flamegraphes, profils, rapports JSON (k6/jtl).
La versionation des données et des scripts, la réécriture PR des scripts perf.

Spécificité pour iGaming/fintech

Tournois/matchs : spike + plateau ; échauffement TLS/DNS/CDN, limites de pools augmentées, itinéraires « gris » pour les bots.
Paiements/PSP : limites de sandbox, idempotence, délais stricts ; validation du mode degrade (cache des guides, files d'attente).
Jackpots/ivents : atomicité et cohérence, absence de prises, charge sur les RNG/leaders.
Antifrod/AML : charge sur les règles/ML-scoring, backpressure, déduplication des événements.
Réglementation : Logique des métriques et des versions en cas de pics, rapports d'audit.

Chèque de démarrage

SLO/SLI et « lignes rouges » (erreur/latence/saturation) sont fixes.
Scripts et profils de charge approuvés (open/closed, spike/soak/stress).
Les données sont réalistes, les PII sont masqués, les intégrations sont sandbox/mock.
L'observabilité est prête : métriques/remorques/logs, étiquettes de sortie.
Les configurations des systèmes (ulimit/sysctl/pools) sont documentées.
Plan auto-skale/chauffage cache et critères rollback.
Alerts de seuil et plan de communication des commandes (on-call).
Un modèle de rapport (graphiques, conclusions, actions) a été préparé.

Erreurs typiques

Le test closed-model produit un résultat « vert » et le prod tombe (vous ne pouvez pas ignorer le modèle ouvert).
Les données non représentatives (une monnaie/un fournisseur) → de fausses conclusions.
La préparation nulle : les caches/TLS/konnekty froides → la latence surévaluée sur le départ.
Retrai sans limites → tempête et chutes en cascade.
Les mêmes profils pour tous les services → l'omission de vrais « points chauds ».
L'absence des soak-parcours → les fuites de la mémoire et la dérive ne sont pas visibles.
Résultats opaques : il n'y a pas de pistes/flûtes → impossible de localiser un goulot d'étranglement.

Mini-playbooks

Détermination de la bande passante limite (breakpoint)

1. Étapes de 10 à 20 % de charge toutes les 5 à 10 min 2) Nous enregistrons un moment où p95 augmente fortement et les erreurs> SLO. 3) Nous filmons les profils CPU/OBD/cache. 4) Plan d'optimisation et répétition.

Maîtriser les tempêtes rétractées

1. Limitez retry-budget et activez backoff + jitter. 2) Entrez request-collapsing/SWR. 3) Autoriser le « mode dégrade » (fonctionnalité limitée). 4) Revérifier l'idempotence.

Pic-event (tournoi) - avant-plan

1. Réchauffer le CDN/DNS/TLS/pools. 2) Augmenter le target HPA, récolter la réserve. 3) Limites de taux séparées pour les bots. 4) Dashboards « mode pic », pont de communication sur appel.

Soak-nuit

1. 8-12 heures de charge stable. 2) Monitoring heap/FD/bou/GC-pauses. 3) Nous vérifions le delta p95 et le hit-ratio. 4) Nous enregistrons les fuites et la dérive.

Total

Le test de charge est un processus de décision d'ingénierie, pas une « course pour le RPS ». Modélisez les profils réels (en particulier le modèle ouvert), fixez le SLO, enlevez les métriques et les pistes, recherchez le genou de la performance et comptez le coût de la performance. Automatisez les runs, gardez les rétracteurs anti-tempête et planifiez les événements de pointe - de sorte que la plate-forme sera prévisible et stable aux moments les plus stressants.