Amplification de la latence de queue : quand une requête attend la plus lente d'une centaine

Ce que c'est

Une requête qui se ramifie en parallèle vers N backends (shards, microservices, appels d'outils) se termine quand la plus lente des N réponses arrive. Si chaque backend répond lentement avec une probabilité p, indépendamment, la requête entière est lente avec une probabilité 1 − (1 − p)^N. Avec p = 1 % et N = 100, cela donne 1 − 0.99^100, soit environ 63 % (calcul arithmétique). « The Tail at Scale » de Dean et Barroso affirme que des épisodes temporaires de forte latence, négligeables dans des systèmes de taille modérée, peuvent en venir à dominer la performance globale d'un service à grande échelle, et plaide pour construire des systèmes tolérants à la queue de latence de la même manière que les systèmes tolérants aux pannes sont construits à partir de composants peu fiables. Le livre SRE affirme le même effet du côté de la surveillance : le 99e percentile d'un backend peut facilement devenir la médiane de réponse du frontend.

Pourquoi c'est important

Améliorer la médiane de chaque backend ne change rien pour la requête à ramification multiple. Toute composition d'appels parallèles y est exposée : une page qui interroge une douzaine de services, une recherche répartie sur des shards, un agent qui appelle plusieurs outils avant de répondre. Les chaînes séquentielles additionnent leurs latences au lieu d'en prendre le maximum, mais une longue chaîne de p99 n'est pas meilleure pour autant.

Comment l'appliquer

• Mesurer le p99 de la feuille et le p50 de la racine sur le même graphique ; si la médiane de la racine suit la queue de la feuille, c'est l'amplification qui en est la cause, pas le code propre de la racine.
• Réduire N : partitions plus grandes, moins de services par requête, résultats mis en cache pour les feuilles qui changent rarement.
• Hedger : après un délai égal, par exemple, à la latence p95 de la feuille, envoyer la même requête à une seconde réplique et prendre la première réponse. Hedger après le p95 duplique au plus 5 % des requêtes (calcul arithmétique). L'article décrit aussi les requêtes liées (tied requests), où la seconde copie est annulée dès que la première commence à s'exécuter.
• Fixer un délai limite au niveau de la racine et retourner un résultat suffisamment bon à partir des feuilles qui ont répondu à temps, marqué comme partiel, plutôt que d'attendre la dernière.
• Éliminer les queues de latence des feuilles à la source : pauses de garbage collection, compaction en arrière-plan, caches froids, voisins bruyants ; étaler le travail de fond planifié entre les répliques.
• Donner à chaque appel de feuille son propre timeout, et à la racine un budget global, afin qu'une feuille bloquée ne puisse pas retenir la requête.

Pièges

Hedger une opération non idempotente duplique son effet de bord. Hedger chaque requête double la charge et aggrave la queue en cas de saturation ; ne hedger qu'après un délai fondé sur un percentile et plafonner le taux de hedging. Les nouvelles tentatives à chaque niveau d'une ramification multiplient la charge sur un backend déjà lent. La formule suppose des feuilles indépendantes ; une base de données ou un hôte partagé corrèle leur lenteur, ce qui aggrave la queue par rapport à la formule, et non l'inverse.

Hedger en toute sécurité

Un délai de hedging calculé à partir de percentiles en direct se rétroalimente : les hedges ajoutent de la charge, ce qui fait monter le percentile, ce qui déplace le délai, et sous saturation chaque hedge est un travail que la feuille n'avait pas la capacité d'absorber. Utiliser un délai fixe choisi hors ligne à partir du percentile d'une période calme, annuler la copie perdante dès qu'une réponse arrive (les requêtes liées de l'article), et plafonner les hedges à une fraction explicite du trafic avec un budget qui arrête le hedging quand les échecs ou le temps de file augmentent ; la politique de hedging de gRPC (hedgingDelay, maxAttempts, limitation des nouvelles tentatives) et la politique de hedging par timeout par tentative d'Envoy implémentent exactement ces contrôles. Ne hedger que des appels idempotents, jamais à plus d'un niveau d'une ramification, et désactiver entièrement le hedging quand le temps de file de la feuille augmente, car alors la seconde copie attend dans la même file que la première.