La technique derrière One Million Checkboxes, passé à 650 millions de cases cochées

Cocher 650 000 000 de cases : faire face à une popularité inattendue

Le 26 juin 2024, lancement du site One Million Checkboxes (OMCB)

• Un site avec 1 million de cases à cocher globales, où cocher une case se répercute immédiatement chez tous les utilisateurs
• Quelques milliers d’utilisateurs ont coché des millions de cases en seulement 30 minutes après le lancement
• Arrivées de trafic depuis Hacker News, /r/InternetIsBeautiful, Mastodon, Twitter, etc.
• Mentionné aussi dans le Washington Post et le New York Times
• Plus de 50 millions de cases ont été cochées le premier jour
• Plus de 650 millions de cases ont été cochées avant la fermeture du site, deux semaines plus tard

Architecture d’origine

• L’état des cases à cocher est stocké sous forme de 1 million de bits (125 Ko)
• Les clients utilisent un bitset pour afficher les cases et signalent au serveur les changements d’état
• Le serveur utilise Redis pour mettre à jour les bits et diffuser les changements à tous les clients
• Le contenu statique est servi via nginx, tandis qu’un serveur Flask gère l’état du bitset et les connexions WebSocket
• Redis sert à la fois de stockage d’état et de file de messages

Principes de mise à l’échelle

• Limite de coût : calculer mathématiquement les coûts pour pouvoir monter en charge sans faire exploser la facture, en s’appuyant sur du serverless
• Accepter des solutions de court terme : partir du principe que la popularité du site serait temporaire et choisir des solutions rapides
• Utiliser des technologies simples et auto-hébergées : n’ajouter que des outils qu’on peut exploiter et déboguer soi-même
• Rechercher avant tout le plaisir : faire passer l’amusement avant l’argent
• Préserver l’état global : faire en sorte que tous les utilisateurs voient les changements immédiatement

Premier jour : succès explosif

• La charge serveur a fortement augmenté en 30 minutes
• Des serveurs supplémentaires ont été lancés pour répartir la charge
• Des mises à jour par lots ont été introduites pour résoudre des problèmes de connexions Redis
• L’instance Redis managée de Digital Ocean a été montée en gamme

Aucune vraie planification pour la nuit

• Un plan a été improvisé pour exposer un jeu Pacman à reconnaissance faciale au camp ITP
• Un iPad a été emporté pour lancer des serveurs
• Huit VM de workers ont été exploitées, avec une convention de nommage des serveurs devenue de plus en plus élaborée
• Le nombre de processus Flask a été réduit et la taille des lots de mise à jour augmentée pour diminuer la charge

Problème de bande passante

• Le prix de la bande passante chez Digital Ocean n’avait pas été pris en compte
• La fréquence des snapshots d’état a été réduite, ainsi que la taille des mises à jour
• L’utilitaire tc a été utilisé pour limiter la quantité de données envoyées par seconde

Deuxième jour : la croissance continue

• Le site est tombé à cause d’une validation d’entrée insuffisante
• Un réplica Redis a été ajouté pour répartir la charge
• Les processus Flask continuaient à planter, donc un script de redémarrage automatique a été écrit

Problème des mises à jour anciennes

• Les clients appliquaient d’anciennes mises à jour, ce qui affichait un état incorrect
• Des horodatages ont été ajoutés pour garantir l’ordre des mises à jour

Réécriture en Go

• Le backend a été réécrit en Go avec l’aide d’un ami ingénieur performance
• Les performances se sont nettement améliorées
• Les attaques DDoS ont été contrées via CloudFlare

Fermeture du site

• Le comportement a été modifié pour que les cases se figent si elles n’étaient pas décochées assez rapidement
• Redis a été utilisé pour gérer cet état figé
• Le site a été fermé au bout de deux semaines

Ce qui a été appris

• C’était la deuxième fois qu’un serveur avec un « vrai » backend était déployé sur l’Internet public
• Le choix de solutions de court terme s’est révélé pertinent
• Cela a confirmé une nouvelle fois la puissance de Redis et de nginx
• Cela a montré à quel point les gens ont envie de sites où ils peuvent interagir anonymement

Résumé GN⁺

• Cet article traite des problèmes techniques causés par la popularité inattendue d’un site web, ainsi que de la manière dont ils ont été résolus
• Il montre qu’une architecture simple reposant sur Redis et nginx peut malgré tout absorber un trafic à grande échelle
• Il explique comment résoudre rapidement les problèmes et stabiliser un site grâce à des solutions de court terme
• Il aborde divers défis techniques, comme une réécriture en Go et la défense contre les attaques DDoS via CloudFlare
• Parmi les projets aux fonctionnalités similaires, on peut citer des projets collaboratifs de grande ampleur comme /r/Place de Reddit

[GN⁺]

Commentaires sur Hacker News

• J’ai pu en tirer beaucoup d’enseignements et de connaissances historiques

  • Toutes sortes d’interruptions et de points de défaillance ont été abordés, mais le problème de l’espace de stockage n’a pas été mentionné
  • Je ne savais pas que Redis pouvait utiliser Lua, et ça m’intéresse de l’employer comme état de remplacement
  • Les problèmes de bande passante des services cloud sont l’un de mes plus gros griefs, car il n’existe pas de limite stricte permettant d’éviter un dépassement de facturation

• C’était un excellent article ! Félicitations aussi pour le site, mais le texte lui-même est la partie dont il faut être le plus fier

• Construire le site en seulement deux jours était un bon choix

  • C’est une leçon importante que les ingénieurs en début de carrière devraient apprendre
  • Les problèmes de passage à l’échelle ne sont pas vraiment des problèmes tant qu’ils n’en deviennent pas
  • À ce moment-là, c’est un bon problème à avoir, et il n’est pas aussi difficile à résoudre qu’on pourrait le penser

• Projet connexe récent :

  • "One Million Checkboxes" - lien - juin 2024 (305 commentaires)

• Projet amusant

  • Il y a 6 ans, j’ai lancé sur Android une application collaborative d’édition de pixels appelée Pixmap
  • J’utilisais une file d’attente pour appliquer chaque événement à une image PNG, et les clients chargeaient le PNG initial lors de la connexion
  • Chaque événement de dessin de pixel était envoyé aux clients sous la forme d’un petit objet
  • Le chargement initial profitait de la compression d’image, et les ensembles de modifications étaient très petits
  • Comme chaque événement est stocké dans un journal, il est possible de « rembobiner » l’image
  • Lien vers la démo

• C’était un excellent article — je me demande combien cela a coûté

• Cela a confirmé ma conviction que les gens ont soif d’interactions anonymes mais limitées

• En tant que débutant en backend, je me demande s’il existe une architecture alternative simple pour ce projet

  • J’aimerais qu’il y ait un moyen plus simple d’héberger un million d’états et de les synchroniser avec les clients
  • Certaines solutions présentées dans l’article étaient difficiles à comprendre
  • Bravo à l’auteur — le projet est excellent

• Sympa !

  • Je me demande si le prochain article portera sur une analyse statistique des cases à cocher
  • Je me souviens avoir été triste parce que la case que j’avais cochée a été décochée presque immédiatement

• Je me demande si le jeu est toujours en ligne

  • Quand j’ai accédé à One Million Checkboxes, rien n’était coché et je n’ai vu dans la console JS que le message suivant
  • {"total":0,"totalGold":0,"totalRed":0,"totalGreen":0,"totalPurple":0,"totalOrange":0,"recentlyChecked":false}