Incident en US-East dû à l’épuisement des connexions Redis

Le 3 septembre 2025 (US-East), nous avons constaté des temps d’attente élevés et, par moments, un traitement des Jobs bloqué en raison de l’épuisement des connexions Redis. La situation a été stabilisée le jour même grâce à un correctif à chaud et à des changements de configuration. Cet article explique ce qui s’est passé, comment nous avons atténué l’incident et ce que nous faisons pour éviter qu’il se reproduise.

Résumé

Un point de terminaison d’un service interne laissait des connexions Redis ouvertes lorsqu’il était fortement sollicité. Un client a déclenché un afflux inhabituellement important de requêtes vers ce point de terminaison. Bien que notre régulateur de trafic ait isolé cet afflux dans une file de secours, la fuite de connexions a propagé la pression aux serveurs Redis partagés. Une fois leurs limites de connexions atteintes, les workers légitimes et les parcours d’exécution de l’API dans la région ne pouvaient plus obtenir de connexions, ce qui a ralenti les files et bloqué par intermittence le traitement des Jobs. Nous avons déployé un correctif à chaud pour fermer les connexions laissées ouvertes et ajusté les limites, après quoi le traitement est revenu à la normale.

Impact

• Période : 3 septembre 2025
  • 12:00 UTC : Encodage lent en US-East avec de nombreuses files d’attente
  • 19:50 UTC : Temps d’attente élevés et nombre excessif de connexions de mise en file observés
  • 21:24 UTC : Systèmes stabilisés ; poursuite de l’analyse de la cause profonde
  • 23:06 UTC : Cause identifiée et correctif à chaud déployé ; rétablissement confirmé
• Région : us-east-1
• Impact sur les utilisateurs :
  • Temps d’attente supérieurs à la normale pour les Assemblies
  • Dans certains cas, Jobs bloqués lorsque les serveurs Redis refusaient de nouvelles connexions
  • Webhooks, notifications et certaines interactions avec l’API retardés dans la région

Cause profonde

• Un parcours d’exécution dans un point de terminaison interne très sollicité ne fermait pas systématiquement les connexions Redis dans certaines conditions d’erreur.
• La charge d’un seul client a involontairement sollicité ce point de terminaison de façon excessive, accélérant le renouvellement des connexions et révélant la fuite.
• Les limites de connexions des serveurs Redis ont fini par être atteintes, empêchant les nouvelles connexions des workers légitimes et des nœuds de l’API.

Facteurs contributifs :

• Les pools Redis partagés ont étendu l’impact une fois les limites de connexions atteintes.
• Les tableaux de bord existants n’ont pas révélé la fuite de connexions, car les métriques des parcours d’exécution réussie étaient normales, tandis que le suivi des connexions dans les parcours de gestion des erreurs ne l’était pas.

Détection

Nous avons détecté le problème grâce aux alertes de latence des files et aux anomalies des signaux périodiques des workers. Les ingénieurs ont établi une corrélation entre les pics de connected_clients dans Redis, l’accélération du renouvellement des connexions et les erreurs ECONNREFUSED/max clients reached sur les serveurs affectés.

Atténuation et rétablissement

• Le trafic de la charge à l’origine de l’incident était déjà acheminé progressivement vers une file de secours isolée, ce qui limitait l’impact sans l’éliminer.
• Nous avons temporairement relevé les limites de connexions Redis pour disposer d’une marge pendant le diagnostic.
• Nous avons déployé un correctif à chaud pour garantir que les connexions du point de terminaison concerné sont toujours libérées, aussi bien en cas de réussite qu’en cas d’erreur.
• Nous avons redémarré les processus affectés pour fermer les connexions laissées ouvertes et vérifié le retour à un fonctionnement normal.

À 21:24 UTC, les systèmes se sont stabilisés. À 23:06 UTC, la fuite a été confirmée et le correctif à chaud déployé sur l’ensemble du parc. Les systèmes fonctionnent normalement depuis.

Communication avec les clients

Nous avons publié des mises à jour sur notre page d’état tout au long de l’incident et contacté les clients affectés. Après l’atténuation, nous avons conseillé de tenter une réexécution d’une Assembly pour récupérer les résultats qui auraient sinon été perdus, lorsque les fichiers d’entrée étaient encore disponibles.

Nos prochaines actions

• Ajouter des SLO relatifs aux fuites de connexions et des tableaux de bord qui suivent le cycle de vie des connexions dans les parcours d’exécution réussie et de gestion des erreurs.
• Introduire des budgets de connexions par point de terminaison et des disjoncteurs pour contenir les fuites.
• Renforcer la gestion des pools de connexions des clients Redis avec des délais stricts et des blocs finally vérifiables par un linter autour de l’acquisition des connexions.
• Répartir les rôles Redis critiques (files, verrous, métadonnées) entre des pools distincts avec des limites séparées.
• Renforcer la limitation du débit sur le point de terminaison affecté, avec une contre-pression permettant une dégradation progressive du service.
• Ajouter des tests de chaos pour simuler des pannes partielles de Redis et des afflux de connexions.

Si l’incident vous a affecté

Relancez les Jobs critiques lorsque c’est possible. Si vos fichiers d’entrée sont encore disponibles, vous pouvez réexécuter une Assembly ayant échoué via notre API, voir Réexécuter une Assembly. Si vous avez besoin d’aide pour identifier les Jobs affectés, veuillez contacter l’assistance et nous vous aiderons.

Mise à jour du 4 septembre 2025

Un jour plus tard, nous avons connu un autre incident. Bien que nous ayons réussi à corriger une source de fuite, il s’est avéré qu’il y en avait une autre. Cette fois, nous avons pu la détecter plus tôt et atténuer le problème en moins d’une heure.

Nous avons effectué des renforcements supplémentaires pour réduire le risque de récidive. Nous avons ajouté des limites de débit ciblées au point de terminaison concerné, amélioré la gestion des connexions dans les parcours de gestion des erreurs et réparti certaines fonctions Redis entre des pools séparés avec des limites plus claires. Ensemble, ces changements réduisent l’étendue de l’impact et rendent le système plus résilient face aux afflux de charge.

Nous avons également étendu la surveillance et les alertes pour nous concentrer sur les signaux précoces — tels qu’un renouvellement anormal des connexions et une pression sur les files d’attente — afin de réagir plus vite si des comportements similaires apparaissent. Ces améliorations sont maintenant en place en US-East et seront déployées dans les autres régions par précaution.

Conclusion

Nous sommes sincèrement désolés pour cette perturbation. La fiabilité est notre priorité absolue, et nous n’avons pas satisfait à nos propres exigences en US-East le 3 septembre. Les correctifs énumérés ci-dessus sont déjà en cours de mise en œuvre, et nous vous tiendrons informés de tout nouveau changement significatif.