- Pendant que le fil d’accueil de Twitter est resté indisponible pendant la majeure partie de la matinée ce jour-là, il a été observé que le client web répétait sans cesse les requêtes de contenu, semblant provoquer lui-même un DDOS
- Même sur un écran qui ne chargeait pas, les tentatives ne s’arrêtaient pas, et la première vidéo montrait une erreur rate limited ainsi qu’une barre de défilement qui tremblait
- Dans la deuxième vidéo, on voit Twitter s’envoyer à lui-même environ 10 requêtes par seconde en essayant de récupérer un contenu qui n’arrive jamais
- La limitation de lecture pour les utilisateurs non connectés appliquée récemment est pointée comme cause possible, car elle aurait créé une condition inattendue
- Dans une vidéo de suivi, la console réseau de Firefox montre également un déluge continu de requêtes, interprété comme une situation d’auto-DDOS où le navigateur de l’utilisateur répétait les requêtes vers Twitter
Requêtes répétées observées dans le client web de Twitter
- Le fil d’accueil de Twitter est resté indisponible pendant la majeure partie de cette matinée, et même lorsqu’aucun contenu ne se chargeait, le site ne cessait pas de réessayer les requêtes
- La première vidéo montre un message d’erreur indiquant que l’utilisateur était en état de rate limited, ainsi qu’une barre de défilement à droite qui tremble
- La deuxième vidéo montre pourquoi la barre de défilement tremblait, avec Twitter s’envoyant à lui-même environ 10 requêtes par seconde pour tenter de récupérer du contenu
- Le changement empêchant les utilisateurs non connectés de lire Twitter est désigné comme la raison pour laquelle le contenu n’arrivait pas
Vérifications de suivi et documents joints
- Une publication de suivi montre en plus, via l’écran de la console réseau de Firefox, que les requêtes réseau continuaient à se produire
- L’interprétation avancée est que le code déployé a provoqué une condition de concurrence (race condition), ce qui a fini par amener les utilisateurs à exécuter des requêtes de type DDOS vers Twitter
- L’auteur indique avoir d’abord fermé la connexion, mais qu’ensuite Twitter a continué à provoquer ces requêtes pendant un certain temps
- Documents joints :
2 commentaires
Twitter passe temporairement en mode de limitation du débit
Commentaires sur Hacker News
D’après une expérience personnelle très douloureuse, peu de choses vous ébranlent autant que d’être forcé d’exécuter ce que vous savez clairement être une idée terrible
C’est encore pire quand vous avez essayé d’expliquer cela à la personne qui vous mettait la pression pour aller contre votre meilleur jugement, sans succès, puis qu’ensuite cette personne nie avec aplomb avoir jamais demandé cela alors qu’il existe des preuves écrites
Impossible de savoir si les gens qui travaillent actuellement chez Twitter ont averti que les mesures récentes pouvaient entraîner ce genre d’effets secondaires massifs, mais vu la manière dont la direction opère, ce ne serait pas du tout surprenant
Je déteste profondément ce qu’est devenu Twitter ces derniers mois, et même avant le rachat je n’aimais déjà pas son format court, qui efface les nuances et permet à quelques tweets faciles à intégrer de servir de base à des articles, mais j’ai vraiment de la peine pour les gens qui doivent travailler sous une telle direction
Si je devais deviner, Elon a dit que « le site est trop lent », les ingénieurs ont vu que les requêtes du fil d’accueil étaient lentes, mais ils ne comprenaient pas l’architecture, n’avaient pas d’outils de profiling, et subissaient une pression pour corriger ça dans des délais irréalistes
Du coup, la seule chose ou presque qu’ils pouvaient faire, c’était lancer plusieurs requêtes en parallèle en espérant que l’une d’elles soit rapide
Après avoir travaillé dans l’industrie du jeu vidéo, j’ai compris pourquoi on sort parfois des jeux après avoir dépensé énormément d’argent et de temps, alors que même les fonctions de base sont cassées
Ce genre de pression extrême sur les délais crée paradoxalement un immense bourbier où changer une chose en casse dix autres, et au final toute progression s’arrête
C’est une gestion d’erreur de base qui aurait dû être là depuis des années
Une réponse 403, ou n’importe quelle autre réponse bloquant les tweets, ne devrait absolument jamais provoquer des tentatives infinies à intervalles très courts
J’ai créé un outil pour gérer les tickets de vulnérabilité de l’équipe, et le premier cas d’usage a été, malgré mon opposition, la suppression de tous les tickets de vulnérabilité
La personne qui le fait se soucie davantage de rendre les choses belles sur le papier que d’améliorer réellement la sécurité
C’est le cas quand on sait depuis longtemps, qu’on l’a proposé à répétition, mais qu’on n’a même pas le droit d’essayer, et qu’au contraire on se fait marginaliser, traité comme « cette personne-là »
J’ai déjà vu cette approche technique et métier, celle de « l’ancienne manière », qui continue tant bien que mal à fonctionner tout en tuant lentement l’entreprise
En revanche, quand un supérieur assume clairement la responsabilité d’une décision qu’il juge risquée mais nécessaire, cela laisse bien plus de marge pour réagir si quelque chose tourne mal, et les développeurs ont moins à subir les sarcasmes après coup
Bien sûr, c’est plus facile à critiquer
Il faut regarder le fait que c’était un week-end férié
Elon a imposé une grosse mise en production, ce qui a forcé des ingénieurs à venir travailler et à enchaîner plusieurs correctifs pendant les 12 dernières heures
Je m’inquiète pour les programmeurs
Ce qui est encore plus frappant, c’est à quel point l’ingénierie chez Twitter semble aujourd’hui faite de rustines
Les problèmes viennent du fait qu’au lieu d’investir des efforts pour comprendre en profondeur la base de code, ils choisissent toujours le correctif le plus simple et le plus court
À ce stade, les conditions d’emploi comme les attentes du patron sont parfaitement claires
Pour quelque raison que ce soit, il est difficile d’avoir beaucoup d’empathie pour ceux qui continuent à rester
Il est très peu probable que ce bug en soit la cause
Le rate limiter côté serveur a un coût faible, et le bug frontend ne se déclenche que lorsque la limitation de débit est active
J’ai déjà vu des bugs similaires dans les systèmes que j’administre, car les bibliothèques réseau aiment parfois retenter des requêtes sans limitation raisonnable par défaut
Mais ces nouvelles tentatives n’ont jamais mis le rate limiter en difficulté
Si on frappe une API qui effectue réellement un travail coûteux avant de renvoyer une erreur, c’est un peu plus gênant, mais c’est précisément pour cela qu’on met une limitation de débit sur tous les endpoints publics
Il est probable que l’application web ne représente que la plus petite part du trafic de Twitter, et les applications natives n’ont probablement pas ce problème
Il est possible que le blocage de l’accès anonyme ait provoqué un DDoS, entraîné un énorme pic sur certaines métriques, puis qu’Elon en ait conclu qu’il s’agissait d’une hausse du scraping, avant de punir les scrapers avec une limite de 600 tweets par jour
Mon quota semble avoir été réinitialisé, ou bien la politique a changé, car je peux de nouveau accéder au site
Je suis d’accord pour dire qu’il est peu probable que ce bug soit la cause profonde de l’ensemble du problème
Mais je ne crois pas non plus au récit par lequel Musk justifie la fermeture de fait du site
Les deux peuvent être vrais à la fois, et on continue alors à imaginer d’autres raisons possibles, ce qui est une perte de temps totale, mais ressemble à une sorte d’appât mental étrange
Le livre "Nothing is true and everything is possible" traite de la manière dont Poutine utilise la désinformation pour contrôler le public et éliminer la politique démocratique, et j’ai l’impression que cela s’applique aussi ici
Les fans de Musk répéteront mot pour mot ce qu’il leur dit de répéter, mais la plupart savent sûrement qu’il raconte surtout n’importe quoi pour servir ses propres intérêts
Et ceux qui cherchent la cause profonde se laissent facilement entraîner vers des récits comme celui de ce bug, qui semblent plausibles mais ne reposent sur absolument aucune donnée
Si vous voulez voir un chemin possible pour l’avenir des États-Unis, je recommande vivement ce livre
https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
J’ai déjà vu et tenté d’atténuer des cas dégénérés où ce genre de retries surchargeait tellement le backend que les serveurs n’arrivaient même plus à rejeter les requêtes
La situation empirait à cause des retries à plusieurs niveaux dans les appelants en amont, au point que les requêtes expiraient en pratique dans les buffers/files TCP avant même d’être traitées par l’application
Je ne sais pas si le backend de la page d’accueil de Twitter est d’une ampleur comparable
Situation intéressante
D’après la capture d’écran, une quantité énorme de
GET /TweetDetailest générée, et comme on le voit avec les 429, cela semble déclencher une forme de limitation de débitSi cela vient de la décision récente d’imposer l’authentification sur tous les appels API, le coupable pourrait en réalité être l’API gateway ou un composant similaire situé en dessous
De plus, ce comportement ne semble pas s’arrêter, ce qui n’est pas ce qu’on attendrait d’une logique de retry avec backoff exponentiel
Je ne prétends pas être meilleur ingénieur que les gens qui travaillent chez Twitter, mais même en laissant de côté toute considération liée à Musk, c’est intéressant de voir ce genre de phénomène en production
J’ai trop souvent vu des cas où l’on jugeait plus important de traiter les requêtes utilisateur avec une faible latence, et où l’on préférait donc un backoff aléatoire constant plutôt qu’un backoff exponentiel
J’ai vu, dans plusieurs réunions de conception et documents, des décisions explicites de ne pas utiliser le backoff exponentiel, en comprenant bien le compromis entre surcharge et reprise du système
Un changement côté backend, à savoir authentification obligatoire + limitation de débit, a peut-être été déployé sans tests suffisants entre frontend et backend
Ça ressemble à un suspect plausible
Il est possible que des instances Twitter soient arrêtées de force
Il est question d’un article de Platformer du 10 juin affirmant que « Twitter refusait de payer les services cloud de Google à l’approche de la date de renouvellement du contrat, le 30 juin »
Il est aussi indiqué que « le contrat Google Cloud de Twitter remontait à 2018 »
https://www.engadget.com/twitter-has-supposedly-started-payi...
Ah, on dirait que ça explique tout ce chaos
Ils essaient probablement de sortir de GCP, mais cela ne serait sans doute pas dû à une perte soudaine d’accès à GCP causée par un refus de paiement
C’est un article d’il y a une semaine
Tout est auto-hébergé
Gcloud ne sert qu’aux batchs et à l’analyse de données
Théorie intéressante, mais le DDoS est antérieur à la décision de désactiver l’accès anonyme
En réalité, cette décision a été prise pour atténuer le DDoS en cours[0][1]
Donc une logique de retry douteuse dans le frontend web a peut-être aggravé la situation, mais ce n’est pas la cause profonde
[0] https://twitter.com/elonmusk/status/1674865731136020505
« Mesure d’urgence temporaire. Le pillage de données était tellement important que cela dégradait la qualité de service pour les utilisateurs normaux ! »
[1] https://twitter.com/elonmusk/status/1674942336583757825
« Ce sera bientôt levé. Comme indiqué dans le précédent post, un niveau extrême de scraping de données a nécessité une action drastique et immédiate. »
« Presque toutes les entreprises faisant de l’IA, des startups à certaines des plus grandes sociétés de la planète, scrapent d’énormes volumes de données. »
« Devoir monter en urgence un grand nombre de serveurs juste pour aider à la valorisation absurde d’une startup IA, c’est assez agaçant. »
Il doit sûrement déjà exister quelque part d’énormes archives contenant tous les tweets antérieurs à une certaine date, et ces startups les utilisent
Quelqu’un sait si ces requêtes existaient déjà avant le passage au mode connexion obligatoire ?
Ce serait vraiment drôle si cette énorme opération de scraping était en réalité leur bug JavaScript
Je ne serais absolument pas surpris que l’essentiel du « trafic de scraping » soit en fait de la faute de Twitter lui-même
C’est stupide, mais c’était prévisible
Cela devait envoyer des dizaines de requêtes en quelques secondes, jusqu’à ce que la limitation de débit se déclenche
Beaucoup de petits bugs de ce genre accumulés ont pu ressembler à un DDoS ou à du scraping
On dirait que ce n’est peut-être même pas un bug
Elon a dit avoir limité à 600 le nombre de tweets vus par jour, ce qui est une limite délirante
La plupart des gens dépasseraient ça en cinq minutes de scroll
Quand Tweetbot m’indiquait qu’il y avait plus de 500 éléments dans mon fil, j’avais le souvenir que c’était largement assez d’absurdités à lire pour quelques trajets de 20 minutes en tram
Je ne doute pas que Twitter ait constaté une énorme hausse du trafic récemment, mais je suis assez convaincu qu’une grande partie du problème a été causée par Twitter lui-même
Elon n’avait qu’à ne rien faire, mais ah oui, il y avait 44 milliards de dollars en jeu
Parag Agrawal et son équipe savaient exactement ce qu’ils faisaient
C’est littéralement le dicton selon lequel un imbécile et son argent sont vite séparés
Après qu’Elon a été contraint par le tribunal du Delaware d’acheter Twitter, il serait allé voir des dictateurs riches, aurait pris leurs 44 milliards de dollars et leur aurait promis de brûler Twitter jusqu’à sa disparition à leur place
Sans Twitter, pas de Printemps arabe, pas de mises à jour en temps réel lors de catastrophes, et plus besoin de couper Internet pour empêcher la diffusion des voix dissidentes
Ce n’est pas très important, mais la limitation de débit est en train d’être relevée à nouveau
6k/600/300 → 8k/800/400 (vers midi) → 10k/1k/500 (vers 15 h)
https://twitter.com/elonmusk/status/1675214274627530754 et d’après ses propres réponses
« Something went wrong » s’affiche
Avec cette nouvelle règle réservée aux utilisateurs connectés, je pense qu’on n’aurait pas pu lire même si le site était en ligne
Les liens Twitter sont désormais des liens contaminés et sont de fait inutiles
C’est un cirque total