- AWS a signalé des problèmes opérationnels à partir de jeudi soir, avec une panne liée à une surchauffe dans un datacenter de la région US-East-1 en Virginie du Nord, affectant des plateformes de transaction comme Coinbase et FanDuel
- Dans une mise à jour publiée vendredi à 15 h 29 (ET), AWS a indiqué qu’un rétablissement complet devrait encore prendre plusieurs heures et que les travaux de restauration avançaient plus lentement que prévu initialement
- AWS a expliqué que le problème s’était produit dans une Availability Zone unique de cette région et qu’il remettait en ligne une capacité supplémentaire de systèmes de refroidissement pour restaurer le matériel restant
- FanDuel a indiqué, après avoir enquêté sur des difficultés techniques empêchant les utilisateurs d’accéder à la plateforme, que celles-ci étaient liées à la panne AWS plus large, tandis que des utilisateurs se sont plaints de pertes sur leurs paris faute de pouvoir encaisser
- Coinbase a déclaré que des pannes dans plusieurs zones AWS avaient provoqué une interruption prolongée des services de transaction essentiels, puis a publié que le principal problème avait été entièrement résolu
Progression du rétablissement
- Dans une mise à jour publiée vendredi à 9 h 51 (ET), AWS a déclaré : « Nous travaillons activement à remettre en ligne une capacité supplémentaire de systèmes de refroidissement, ce qui nous permettra de restaurer le matériel restant dans la zone affectée »
- AWS est en train de résoudre des pannes d’instances EC2, qui fournissent de la capacité de serveurs virtuels
- Le tableau de bord AWS Health a publié pour la première fois jeudi à 20 h 25 (ET) qu’il « enquêtait sur des pannes d’instances »
- AWS n’a pas fait de déclaration supplémentaire
Impact par service
- FanDuel a indiqué sur X jeudi à 21 h (ET) avoir connaissance de difficultés techniques actuelles empêchant les utilisateurs d’accéder à la plateforme et être en train d’enquêter
- Environ deux heures plus tard, FanDuel a mis à jour sa communication en indiquant que le problème était lié à une panne AWS plus large
- Des utilisateurs de FanDuel se sont plaints d’avoir subi des pertes sur leurs paris faute de pouvoir encaisser sur la plateforme
- Coinbase a également publié vendredi sur X que des pannes dans plusieurs zones AWS avaient provoqué une « interruption prolongée des services de transaction essentiels »
- Coinbase a précisé dans cette publication que le principal problème avait été entièrement résolu
Contexte du marché du cloud
- AWS représente environ un tiers du marché des technologies d’infrastructure cloud
- AWS fournit des services à plusieurs millions d’entreprises
1 commentaires
Réactions sur Hacker News
AWS US-East 1 reste le talon d’Achille d’Internet
On peut certes construire sur plusieurs régions et zones de disponibilité, mais AWS a déjà connu à plusieurs reprises des incidents où un problème en US-East 1 a eu des effets bien plus larges, ce qui rend la redondance et la résilience moins élevées que ce qu’AWS laisse entendre
Hors de Chine, tous les services publics d’identité et d’accès du cloud — ce que les employés appellent « IAM pour la partition AWS » — sont centralisés en us-east-1. Ce genre de centralisation est pratiquement nécessaire pour avoir une vue cohérente des comptes, de la facturation et des autorisations
IAM n’est pas non plus une pile logicielle totalement indépendante et dépend de certains services comme DynamoDB, lesquels dépendent à leur tour d’IAM
Lors d’une panne de us-east-1, il est parfois possible de continuer à utiliser des jetons d’authentification ou des sessions existants dans d’autres régions, mais l’émission de nouveaux jetons peut devenir impossible. Quand j’y travaillais, je me souviens qu’on disait aux personnes d’astreinte de ne pas fermer leur session SSH ni leur onglet de console AWS dans le navigateur, sous peine de rester bloquées jusqu’à la fin de l’incident
J’ai fait tourner presque toute une startup en use-1 pendant les trois dernières années, et il n’y a eu qu’une seule panne régionale, encore partielle, qui n’a touché qu’une minorité d’instances
Honnêtement, comme tout est aussi chez les clients en use-1, il y a au moins l’avantage que la panne soit corrélée à celle des clients
Dans un pays imaginaire merveilleux, la charge est répartie équitablement entre plusieurs fournisseurs cloud, et il n’existe aucun point de défaillance unique
Ça s’est aussi bien passé avec ma première petite amie, mes jumeaux parlent couramment anglais et coréen, et je sais qu’il ne faut pas dépendre d’un seul AWS pour déployer un service à grande échelle
Les frais de santé américains sont abordables aussi. Mais dans le monde réel, une journée de plus passe et un seul AWS US-East 1 peut encore mettre à terre une grande partie d’Internet
Avec 2 régions, il faut 2x la capacité ; avec 3 régions, 1,5x la capacité ; et dans une architecture multi-région, les machines doivent déjà être en cours d’exécution. Il ne faut pas s’attendre à pouvoir lancer des instances ou obtenir de la capacité pendant une panne, et il faut aussi absorber la complexité supplémentaire de l’hébergement multi-région
C’est assez drôle de voir tout le monde continuer à croire à la religion du cloud, alors que les architectures multi-région / multi-zone ressemblent si visiblement à de la façade
Ce genre de pari est dangereux. Parce qu’une personne comme un employé capable de faire tomber AWS peut parier
Ces paris ne sont pas aussi inoffensifs qu’ils en ont l’air, car la personne qui parie peut souvent influencer ou modifier le résultat
Plus largement, je suis d’accord avec l’idée que ce type de marché prédictif peut encourager le délit d’initié et les scénarios négatifs. Cela crée une incitation à profiter de telles situations
Le refroidissement d’un datacenter est généralement planifié à l’avance, et je pensais qu’on n’installait pas plus de matériel que ce que la capacité de refroidissement permettait
Ici, je me demande si c’est l’équipement de refroidissement qui est tombé en panne, s’il y a eu une cause externe à la surchauffe, ou si Amazon sur-réserve la capacité de refroidissement de ses datacenters
On ne nous a pas donné les détails, mais il semble que les canalisations entre les étages et le toit n’étaient pas redondées, et la réparation a pris presque 24 heures
Comme pour tout le reste dans les datacenters, le refroidissement est à la fois surprovisionné et sous-provisionné
Les gros équipements d’échange thermique sont en N+1, et les petits sites pour charges très critiques sont en 2N/3N, donc surprovisionnés. Il faut les arrêter pour les inspections régulières, leur taux de panne est supérieur à celui des composants classiques de datacenter, et ils exigent des réparations mécaniques par des spécialistes avec des délais d’approvisionnement longs
Dans les grandes installations, plus N est grand, plus il est courant d’avoir du refroidissement en N+3 ou davantage. Il y a toujours quelque chose en maintenance, ou des machines en attente de pièces qu’il faut parfois fabriquer sur mesure parce qu’elles n’existent plus, ce qui coûte moins cher qu’un remplacement complet
À l’inverse, si toute la capacité de calcul d’un site passe soudainement de sa consommation moyenne à 100 %, la capacité de refroidissement est dépassée, donc c’est aussi sous-provisionné. L’alimentation électrique et d’autres chemins critiques sont eux aussi souvent au-delà de leur charge nominale, et le secteur repose largement sur la survente
En général, ce n’est pas un gros problème. Les charges de calcul qui montent à 100 % de la capacité totale sont rares, et même quand ça arrive, ça ne dure pas longtemps ; en plus, on ne conçoit pas un site au ras du seuil critique en refroidissement ou en alimentation
Les ennuis commencent quand plusieurs événements se croisent. On peut avoir un système de refroidissement conçu pour encaisser 200 % de la charge moyenne, avec une bonne marge pour la maintenance et les pannes
Un mardi, un technicien vient voir une machine, détecte un roulement défectueux, doit faire venir une pièce d’un autre État, et laisse l’équipement à l’arrêt toute la nuit pour éviter de casser l’ensemble du ventilateur
Deux unités de refroidissement voisines travaillent alors un peu plus fort, mais l’une a un moteur légèrement déséquilibré ou un fusible un peu lâche qui chauffe, et une pièce qui tenait depuis des années finit par lâcher à cause du surcroît de charge
Dans un site N+2, deux unités sont maintenant perdues, mais comme le dimensionnement reposait sur 200 % de la charge moyenne, ce n’est pas encore critique
Si une troisième unité, de l’autre côté de la première en panne, révèle elle aussi un défaut sous l’effet de la charge accrue, on passe à trois unités perdues dans un site N+2. Même là, ce n’est toujours pas une catastrophe totale puisque le site était conçu pour 200 % de la charge moyenne
Sauf qu’il est 4 h du matin, l’opérateur sur site ne peut pas réparer ce défaut, et le prestataire ne se réveille qu’à 7 h pour arriver à 9 h. Entre-temps, la charge commence à grimper
Ce genre de chose arrive tous les jours dans un datacenter quelque part aux États-Unis, et probablement une fois par an dans presque tous les datacenters
Ce qui fait la une, c’est la conjonction avec l’événement suivant. Un gros client décide que c’est le bon moment pour lancer un énorme traitement batch. Une fintech veut exécuter un gros modèle avant l’ouverture des marchés, ou une compagnie pétrolière lance une analyse rapide sur un nouveau gisement
10 000 VM sont démarrées. En temps normal, il y a de la marge, donc ça passe
Mais le refroidissement n’a été planifié que pour 200 % de la capacité moyenne, et ici il ne s’agit pas de nœuds modérément occupés : ce sont des nœuds optimisés pour du calcul numérique intensif, qui tirent la puissance maximale et produisent le maximum de chaleur résiduelle
Ce n’est pas seulement la charge en nombre total de machines qui augmente, c’est aussi l’impact thermique moyen. Alors les pannes en cascade commencent et le refroidissement passe à N-4
Les ventilateurs des serveurs accélèrent, consomment plus d’électricité, et le refroidissement passe à N-5. Les alarmes sonnent de partout
Les sécurités des groupes froids se déclenchent les unes après les autres sous la charge et la hausse de pression du fluide frigorigène, et le refroidissement passe à N-6, N-7, puis à 0
Je me demande si, cette année dans l’UE, Hetzner a eu un meilleur uptime qu’AWS
Je trouve l’interface de Hetzner trop confuse et difficile à administrer
Article lié : AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
C’est toujours East 1. Blague à part, je ne comprends pas pourquoi east-1 tombe aussi souvent par rapport aux autres régions
Sur le plan architectural, ça devrait pourtant être assez similaire aux autres régions
La charge y est sans doute plus élevée que dans les autres régions, et comme il a été construit au début avec moins d’expérience, il doit aussi traîner davantage de dette technique et de dette d’architecture / d’ingénierie
De mémoire, certains services comme IAM ou certaines configurations S3 dépendent encore de east-1 comme point de défaillance unique
Coinbase a dit que plusieurs zones de disponibilité étaient tombées, alors que la communication d’AWS parlait d’une seule zone de disponibilité affectée
Je me demande si quelqu’un a plus de détails
Je fais tourner des systèmes en us-east-1 et, pendant l’incident, j’ai observé des problèmes intermittents de connectivité difficiles à expliquer en dehors d’az4, que je n’avais jamais vus auparavant
Dans plusieurs environnements, seuls quelques volumes EBS d’une zone de disponibilité unique se sont un peu dégradés ; c’était clairement un problème limité à une seule zone (use-az4)
J’avais vu un jour cette phrase : « si c’est un ami, on ne le laisse pas utiliser USE1 », et quand j’ai vu arriver sur Slack des messages disant que USE1 et tout ce qui y était déployé partaient complètement en vrille, j’y ai repensé
Dans les commentaires ici, on retrouve le discours habituel disant que us-east-1 est centralisé, que c’est le point de défaillance unique d’AWS, qu’il faut corriger ça et ne rien y déployer
Or cette fois, il s’agissait d’un problème sur un datacenter unique dans une seule zone d’une région multi-zone
Oui, IAM/R53 et d’autres services y sont centralisés, et ce serait une bonne chose de les décentraliser et de les rendre cross-region. Mais us-east-1 lui-même est déjà une région multi-zone avec 6 zones, et une 7e prévue pour 2026 ; et à l’intérieur des zones, il y a plusieurs datacenters
De mémoire, quand des services globaux comme IAM tombent, ce n’est pas tant parce qu’ils ne sont pas cross-region que parce qu’il y a des bugs d’implémentation ou de dépendances
Cette fois, ce n’était pas une panne globale des services AWS. Le seul service qui semblait plus fortement touché était MSK, et c’est probablement davantage un problème côté Kafka que côté AWS
Je me demande pourquoi on ne construit pas ce genre d’installations près de la mer. Les centrales nucléaires, par exemple, sont elles aussi des sites ayant besoin d’une forte capacité de refroidissement, non ?
Avec une circulation en deux boucles et un échangeur thermique, on devrait pouvoir évacuer la chaleur
Dans les années 1990, environ la moitié du trafic Internet mondial transitait par MAE-East, et c’est ce qui a conduit AWS à y installer sa première région. us-east-1 est arrivé deux ans avant eu-west-1 et trois ans avant us-west-1
Comme de plus en plus de gens savaient construire des datacenters et que davantage de fournisseurs savaient les alimenter, le corridor de Dulles est devenu un hub majeur de datacenters pour de nombreuses entreprises
Chez AWS, us-east-1 étant la première région, c’est de loin la plus complexe et la plus étrange, et de nombreux plans de contrôle d’autres services AWS en dépendent. C’est pour cela qu’elle tombe plus souvent que les autres régions, et que lorsqu’elle tombe, cela fait la une nationale, contrairement à eu-south-2 en Espagne
Le nord de la Virginie n’est pas un cas industriel, mais un exemple de cluster économique de datacenters, du même type que ceux étudiés par Paul Krugman dans les travaux qui lui ont valu le prix Nobel d’économie
L’un concernait le datacenter SOMA de Hosting.com, devenu si chaud qu’ils ont fini par l’arroser au tuyau depuis le toit ; l’autre concernait le datacenter de Chai Wan d’Alibaba, qui a tellement surchauffé que tout ce qui y tournait, y compris le plan de contrôle, est tombé
Donc je ne pense pas qu’être près de la mer apporte un avantage supplémentaire du point de vue de la dissipation thermique d’urgence. La capacité d’évacuation de chaleur reste finie, et que l’on soit en bord de mer ou au milieu du Nebraska, tout le système doit être conçu pour atteindre un certain niveau de performance
Les diapositives présentaient les facteurs qui influencent le choix d’implantation d’un datacenter, et plusieurs concernaient la disponibilité de suffisamment d’espace et de main-d’œuvre qualifiée pour y travailler. Il disait aussi que la politique intervenait parfois dans le choix du prochain site
Le foncier côtier est bien plus cher, et si l’on s’éloigne vers une côte isolée, l’accès à l’électricité risque d’être moins bon
Les sites côtiers sont généralement plus exposés à des phénomènes météorologiques violents
Il y a aussi l’imprévisible. La centrale nucléaire de Diablo Canyon a déjà eu ses prises d’eau de refroidissement à l’eau de mer obstruées par des débris et des mouvements de méduses
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
Il faut aussi que l’eau soit suffisamment profonde ; sinon on finit par la réchauffer jusqu’à la température de surface. Et il faut que cette approche reste compétitive en prix face au refroidissement évaporatif classique
Le cas d’école où cela fonctionne bien, c’est Toronto. Il y a à relativement courte distance du littoral un lac d’eau douce profond, et le centre-ville a un foncier si cher que les approches traditionnelles sont moins adaptées
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System