Planification de la capacité et tests de performances

La capacité est un plan, pas un espoir

La planification de la capacité répond à l’avance à une seule question : aurons-nous assez de tout quand la demande atteindra son pic ? Tout va bien au-delà des serveurs. Cela comprend les connexions à la base de données et le débit d’écriture, la mémoire du cache, les partitions du courtier de messages (message broker), les quotas du compte cloud, les limites de débit des tiers, les licences et les personnes d’astreinte. L’élasticité du cloud permet d’ajouter rapidement une partie de la capacité, mais pas toute : on ne double pas en quelques secondes une base de données primaire, un prestataire de paiement peut exiger plusieurs semaines de préavis pour relever une limite, et l’autoscaling (mise à l’échelle automatique, traité à la section 9.1) réagit en quelques minutes à un changement brutal qui survient en quelques secondes.

La méthode comporte quatre étapes, répétées selon un cycle régulier (chaque trimestre pour une croissance régulière, à chaque événement pour les lancements et les ouvertures de billetterie) :

Le calcul de dimensionnement avec la loi de Little a été détaillé à la section 9.1 ; cette section se concentre sur la manière d’obtenir des chiffres fiables à y injecter. L’erreur la plus courante en planification de la capacité n’est pas un mauvais calcul, mais une capacité par instance mesurée dans des conditions irréalistes ; la deuxième est d’oublier une contrainte partagée, comme une limite imposée par un tiers, qu’aucune marge de capacité (headroom) sur vos propres serveurs ne peut compenser.

Les types de tests de performances

Les tests de performances sont le seul moyen de mesurer la capacité, de trouver les goulots d’étranglement avant les clients et de vérifier qu’une version n’a pas aggravé la situation. Les tests diffèrent par la forme de charge qu’ils appliquent et par la question à laquelle ils répondent. Un test de charge vérifie le pic attendu ; un test de stress va au-delà pour voir comment le système défaille ; un test d’endurance (soak test) dure des heures pour révéler les fuites lentes ; un test de pic (spike test) vérifie les réactions à des sauts soudains ; un test de point de rupture augmente la charge jusqu’à ce que quelque chose cède, pour trouver la vraie limite.

Modèles de charge ouverts et fermés

Les générateurs de charge simulent les utilisateurs de l’une de deux manières, et choisir la mauvaise produit des résultats non seulement inexacts, mais dangereusement optimistes. Dans un modèle de charge fermé, l’outil fait tourner un nombre fixe d’utilisateurs virtuels ; chacun envoie une requête, attend la réponse, marque une pause (le temps de réflexion) et recommence. Si le système ralentit, chaque utilisateur virtuel envoie moins de requêtes, et la charge baisse d’elle-même. Dans un modèle de charge ouvert, les requêtes arrivent à un rythme fixé, indépendamment de la vitesse à laquelle les précédentes reçoivent une réponse, comme le font les vrais visiteurs d’un site web public : des milliers de fans qui appuient sur Acheter à 10:00 ne s’attendent pas les uns les autres.

Bianca Schroeder, Adam Wierman et Mor Harchol-Balter ont montré (Open Versus Closed: A Cautionary Tale, NSDI 2006) que les deux modèles peuvent donner des temps de réponse très différents pour le même système et la même charge moyenne, et que des décisions d’ordonnancement ou de capacité réglées avec l’un peuvent être fausses avec l’autre. Les systèmes internes dont la population de clients est fixe, comme une application de centre d’appels utilisée par 300 agents, sont raisonnablement fermés. Le trafic internet public, les consommateurs pilotés par les événements alimentés par une file et les ouvertures de billetterie sont ouverts, ou presque. Pour de tels systèmes, c’est un test en modèle ouvert qui est réaliste ; les exécuteurs constant-arrival-rate et ramping-arrival-rate de k6, par exemple, le mettent en œuvre, tandis que son exécuteur constant-vus est fermé.

Omission coordonnée (coordinated omission)

Gil Tene, d’Azul Systems, auteur de la bibliothèque HdrHistogram, a nommé une erreur de mesure qui touche de nombreux tests de latence et outils de supervision : l’omission coordonnée (coordinated omission). Un générateur de charge en boucle fermée attend chaque réponse avant d’envoyer la requête suivante. Quand le système se bloque, le générateur se bloque avec lui, si bien que les requêtes que de vrais utilisateurs auraient envoyées pendant le blocage, et qui auraient toutes été lentes, ne sont jamais envoyées ni mesurées. Le testeur se coordonne avec le système qu’il teste et omet précisément les mauvais échantillons.

Prenons un test qui prévoit d’envoyer une requête toutes les 10 ms pendant 100 secondes à un service qui répond normalement en 1 ms. À 50 secondes, le service se fige pendant 10 secondes (une longue pause du ramasse-miettes, par exemple). Le testeur en boucle fermée enregistre environ 9000 échantillons rapides et un échantillon de 10 secondes : il indique donc un p99 de 1 ms, et même un p99,9 de 1 ms. Selon le calendrier prévu, pourtant, environ 1000 requêtes seraient arrivées pendant le blocage, et auraient attendu entre 10 secondes et 10 ms, soit environ 5 secondes en moyenne. Dix pour cent de toutes les requêtes ont été fortement retardées : le vrai p95 est d’environ 5 secondes, et le vrai p99 d’environ 9 secondes.

Les remèdes consistent à utiliser des générateurs en modèle ouvert (à taux d’arrivée) pour les systèmes ouverts, à mesurer la latence à partir du moment où une requête devait être envoyée plutôt que du moment où elle l’a réellement été, à enregistrer des histogrammes complets plutôt que des moyennes, et à se méfier de tout rapport de latence dont le maximum est très au-dessus du p99,9 avec peu d’échantillons entre les deux. L’outil de benchmark HTTP modifié par Tene, wrk2, et les options de correction de HdrHistogram existent précisément pour cela. La même erreur apparaît dans la supervision en production lorsqu’une bibliothèque cliente ne mesure que les requêtes qu’elle a réussi à envoyer.

Les outils

Quatre outils open source couvrent la plupart des besoins. Apache JMeter est le vétéran : basé sur Java, avec un éditeur graphique de plans de test, de nombreux plug-ins de protocoles et des groupes de threads fermés par défaut. Gatling écrit les tests sous forme de code (Scala, Java et Kotlin, avec JavaScript et TypeScript ajoutés plus récemment), est efficace à forte charge et propose des profils d’injection ouverts et fermés. k6, maintenu par Grafana Labs, exécute des scripts de test en JavaScript sur un moteur écrit en Go, possède des exécuteurs explicites en modèle ouvert et fermé, et des seuils de réussite ou d’échec adaptés à l’intégration continue. Locust décrit le comportement des utilisateurs en Python et répartit la charge entre des processus de travail ; ses utilisateurs fonctionnent en boucle fermée. Des services commerciaux et hébergés dans le cloud ajoutent la génération de charge distribuée à grande échelle et les rapports.

L’outil compte moins que le scénario. Un bon script reproduit le mélange réel des parcours (d’après les statistiques de production : par exemple 70 % de navigation, 20 % de modifications du panier, 10 % de paiement), des temps de réflexion réalistes, des données réalistes (des utilisateurs, des restaurants et des places différents, et non le même 10 000 fois) et le bon modèle de charge ; il vérifie aussi que les réponses sont correctes, car une page d’erreur rapide n’est pas une requête réussie.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    onsale: {
      executor: 'ramping-arrival-rate',   // open model: arrivals per second
      startRate: 100, timeUnit: '1s',
      preAllocatedVUs: 2000, maxVUs: 20000,
      stages: [
        { target: 4900, duration: '2m' },  // ramp to 1.5x design load
        { target: 4900, duration: '20m' }, // hold
      ],
    },
  },
  thresholds: {                            // fail the run if missed
    http_req_failed: ['rate<0.005'],
    http_req_duration: ['p(99)<500'],
  },
};

export default function () {
  const res = http.get('https://perf.tickets.example/api/events/42/seats');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Des environnements et des données réalistes

Un test de performances ne vaut que ce que vaut son environnement. Une base de données de test de 10 000 lignes dont les index tiennent en mémoire ne dit rien de la production avec 200 millions de lignes dont les index n’y tiennent pas. La liste de contrôle ci-dessous repère les différences habituelles.

Taille et forme des données : des volumes à l’échelle de la production et des distributions réalistes, y compris les clés très sollicitées, comme les restaurants les plus populaires ou les meilleures places, qui créent une contention qu’un test uniforme ne voit jamais. Mêmes briques : les mêmes types d’instances, limites de conteneurs, configuration de base de données, tailles de pools de connexions et topologie réseau (y compris les sauts entre zones). État du cache : testez à la fois avec un cache chaud et un cache froid, car un déploiement ou un failover les vide (section 7.6). Dépendances : des services tiers remplacés par des bouchons qui reproduisent leur vraie distribution de latence et leurs limites de débit, pas des réponses instantanées. Isolement : aucun test d’une autre équipe partageant l’environnement, sinon les résultats ne sont que du bruit. Le générateur lui-même : une capacité de génération de charge suffisante, aux bons emplacements ; un générateur qui tourne à 100 % de CPU se mesure lui-même.

Certaines organisations testent en production, avec prudence, parce qu’aucune copie ne lui ressemble tout à fait : utilisateurs synthétiques et événements de test exclus des rapports métier, duplication du trafic (traffic shadowing : copie de vraies requêtes vers une nouvelle version dont les réponses sont jetées) et montées progressives avec conditions d’arrêt automatique. Cela exige les mêmes garde-fous que les expériences de chaos : un faible rayon d’impact (blast radius), un interrupteur d’arrêt d’urgence et une surveillance étroite des SLO.

Les budgets de performance

Un budget de performance est une limite qu’une modification ne doit pas dépasser, convenue à l’avance et vérifiée automatiquement, afin que les performances ne s’érodent pas une petite régression après l’autre. Pour les frontends web, les budgets portent sur le poids des pages, la taille des scripts et les Core Web Vitals, pour lesquels les seuils de Google pour une bonne expérience, mesurés au 75e percentile des chargements de pages, sont un Largest Contentful Paint de 2,5 secondes au maximum, un Interaction to Next Paint de 200 ms au maximum et un Cumulative Layout Shift de 0,1 au maximum.

Pour les backends, un budget de latence répartit un SLO de bout en bout entre les sauts d’un parcours. L’étape de paiement de la plateforme de livraison de repas a un objectif de p99 de 800 ms ; l’équipe attribue 20 ms à la passerelle, 60 ms au service de commandes, 80 ms à la tarification, 450 ms au paiement (dont l’essentiel pour le prestataire de cartes externe), 40 ms à la base de données, 100 ms au réseau et à la sérialisation, et garde 50 ms en réserve. Chaque équipe connaît désormais son propre objectif, et une modification qui pousse la tarification à 150 ms apparaît comme un dépassement de budget avant de devenir un non-respect du SLO. En toute rigueur, les percentiles des parties ne s’additionnent pas pour donner le percentile de l’ensemble : traitez donc cette répartition comme une allocation d’ingénierie, et vérifiez séparément le chiffre de bout en bout.

On fait respecter les budgets en exécutant un test de performances court et stable dans le pipeline de livraison et en faisant échouer le build lorsqu’un seuil est franchi, comme le font les seuils k6 ci-dessus. C’est une fonction d’aptitude pour les performances. Les tests du pipeline doivent être reproductibles plus que réalistes : même environnement, mêmes données, même charge, pour qu’une variation de 10 % signale une vraie régression et non du bruit.