Contexte des tempêtes de retry

Chez Uber, un retry storm se déclenche lorsqu’une défaillance d’un service en aval entraîne une multiplication exponentielle des requêtes en amont. L’article illustre ce phénomène avec une chaîne d’appels linéaire de sept nœuds (A‑G) où chaque nœud effectue un appel unique (fan‑out 1:1). Si le nœud D échoue et que chaque service est configuré pour un seul retry (R = 1), le nombre de requêtes traitées passe de N à 2 × N pour B, 4 × N pour C, 8 × N pour D, et reste 8 × N pour les nœuds suivants, soit une croissance de 

R^d × N
où d est la profondeur du nœud.

Cette amplification surcharge les services sains, prolonge la durée de l’incident et détériore l’expérience utilisateur. Les réglages classiques – limites de retries et budgets de retry par service – sont manuels, ne tiennent pas compte du contexte d’erreur et ne donnent aucune visibilité sur l’effet d’amplification à travers les dépendances.

Mécanisme de budgets de réessai et propriété d’erreur

Uber a introduit un budget de retry partagé, exprimé en pourcentage B du trafic de base. En appliquant B = 10 % à chaque niveau, la formule devient 

(1+B)^d × N
. Le tableau de l’article montre que, pour la même chaîne, les facteurs de charge passent de 1,1 × N à 1,33 × N au niveau du nœud D, puis se stabilisent à 1,33 × N pour les nœuds en aval, limitant ainsi l’explosion du trafic.

Le concept d’error ownership restreint les retries aux segments où ils sont les plus utiles. En limitant les retries entre le nœud C et le nœud D (où l’erreur apparaît), les nœuds A et B ne réémettent aucune requête supplémentaire, ce qui maintient le trafic total à N pour ces deux premiers niveaux et à 1,1 × N pour les nœuds suivants. Cette approche garantit que le nombre de requêtes supplémentaires ne dépasse jamais 10 % du trafic de base, même en présence d’erreurs persistantes.

Le tableau d’availability montre l’impact quantitatif : avec une disponibilité de base de 99,9 % (taux d’erreur 0,1 %), un budget de 10 % porte l’erreur après retries à 0,0001 % et la disponibilité perçue à 99,9999 %. Lorsque la disponibilité du service en aval chute à 80 % (taux d’erreur 20 %), le même budget ne suffit plus, la disponibilité perçue chute à 88 %.

Analyse d’impact et limites

Le mécanisme améliore la résilience en empêchant la propagation d’une surcharge locale. En limitant les retries, il réduit la charge CPU, la latence réseau et le risque de saturation des bases de données en aval. Cependant, l’efficacité dépend de deux hypothèses : (1) les erreurs sont indépendantes et (2) chaque retry aboutit à une récupération. Dans des scénarios de surcharge du service, de pannes de bases de données ou de problèmes de sharding, les retries restent susceptibles d’échouer, ce qui rend le budget de retry moins bénéfique.

De plus, la mise en œuvre nécessite une instrumentation fine‑grained pour identifier le point d’origine de l’erreur et appliquer le budget uniquement à la branche concernée. Cette complexité peut augmenter le coût de maintenance du système de contrôle des retries et nécessite une surveillance continue pour ajuster B en fonction des variations de charge.