Une seule compte fantôme a fait s’effondrer un système—la solution qui l’a sauvé
Un système discret de surveillance en temps réel, conçu pour tenir les services d’urgence informés en continu, s’est soudain retrouvé submergé par un trafic huit fois supérieur à la normale—tout cela à cause d’un seul compte exécutant un code client obsolète en cache depuis des mois. L’incident ne s’est pas résolu en un pic suivi d’une reprise : il a persisté, révélant une faille critique dans l’architecture sous-jacente : une seule partition dans Azure Event Hubs.
Pendant des semaines, le système fonctionnait sans encombre, avec 51 000 à 58 000 pulsations par heure—stable, prévisible, presque anodin. Puis, le 5 janvier à 7 h (PST), il est devenu impossible à ignorer. À 21 h ce même jour, les pulsations avaient grimpé à 466 760 par heure, tandis que le nombre de connexions SignalR explosait à onze fois son niveau habituel. La cause n’était ni une cyberattaque ni un afflux de trafic, mais un seul compte utilisateur responsable de 33 % de tout le trafic d’API de jetons—un trafic généré par un code client périmé refusant de se mettre à jour. Le système était conçu pour gérer efficacement les pulsations et les sessions, mais il comportait un plafond caché : une seule partition dans son Event Hub.
Le goulot d’étranglement qui a brisé la boucle
Les partitions d’Event Hubs servent de voies parallèles pour l’ingestion des événements. Avec une seule partition, tous les événements convergent vers un seul groupe de consommateurs, traités séquentiellement par une seule instance à la fois. Même en tentant de faire monter en charge le système—plus d’instances, plus de CPU, code optimisé—rien ne pouvait contourner ce goulot. Le HeartbeatMonitor traitait les événements un par un, prenant toujours plus de retard à mesure que la file d’attente s’allongeait. L’état de connectivité des installations, résultat critique utilisé par les hôpitaux et les services médicaux d’urgence, commençait à se décaler par rapport à la réalité.
La situation ne s’est pas arrêtée là. Le plan de consommation Azure a ajouté une couche de défaillance supplémentaire : l’épuisement des ports SNAT. Sous une charge soutenue, les connexions sortantes consommaient les ports éphémères plus vite qu’ils n’étaient libérés. Les nouvelles connexions échouaient. Les clients relançaient leurs tentatives. Le cycle s’auto-alimentait, transformant une hausse gérable en une attaque par déni de service auto-infligée. Pire encore, le plan de consommation ne permettait aucune visibilité sur les travailleurs individuels ni aucun contrôle sur la mise à l’échelle—car même si plus d’instances avaient démarré, elles n’auraient pu aider sans voies supplémentaires pour traiter les événements.
Une solution rapide—and une leçon durable
Avant de reconstruire le système, l’équipe devait d’abord survivre. Elle a actionné un levier simple : l’intervalle des pulsations, déjà paramétrable via l’API. En augmentant cet intervalle (passé des 30 secondes par défaut), elle a gagné un répit temporaire tout en planifiant une solution plus robuste.
Cette solution s’est articulée en trois volets : plus de partitions dans Event Hubs, Azure Container Apps, et KEDA. Plusieurs partitions ont permis un traitement parallèle des événements entre les groupes de consommateurs. Container Apps a offert un meilleur contrôle sur la mise à l’échelle et une visibilité accrue sur les ressources. KEDA a automatisé la mise à l’échelle en fonction des files d’attente réelles, garantissant que la capacité s’ajustait à la demande. Ensemble, ces mesures ont éliminé le goulot à voie unique et ouvert la voie à une croissance durable.
Pourquoi cela compte
Ce n’était pas seulement un pic de trafic—c’était un test de résistance des hypothèses architecturales. Les systèmes qui scalent bien sous une charge régulière peuvent s’effondrer face à une demande irrégulière ou mal dirigée. La leçon est claire : le parallélisme n’est pas une option, et la visibilité sur le comportement de la mise à l’échelle est incontournable. Pour les équipes exploitant des systèmes temps réel sur des plateformes pilotées par événements, cette histoire souligne l’importance de concevoir en tenant compte de modes de défaillance imprévisibles—et d’intégrer des mécanismes de réponse lorsque ceux-ci surviennent.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.