En 2023, la gloire n’est qu’à 11 Mo/s
(thmsmlr.com)- Même un site web du top 1000 avec 200 millions de visiteurs mensuels représente, si l’on ne considère que le HTML, environ 30 To/mois, soit un débit moyen de 11 Mo/s : une échelle qu’un seul serveur peut encaisser
- Le calcul part de Business Insider, avec l’hypothèse de 2 pages par visiteur, 400 millions de documents HTML par mois, du HTML compressé d’environ 75 Ko, et des JS, CSS et images confiés à un CDN
- L’exécution en edge a l’avantage de rapprocher le serveur de l’utilisateur, mais si le rendu implique des allers-retours vers la base de données, la latence est ramenée à l’emplacement de la base de données d’origine
- L’écart de coût est aussi important : Hetzner propose un serveur 16 cœurs, 64 Go de RAM et NVMe à 0,34 $/heure, avec 20 To de transfert inclus puis 1,5 $/To, tandis qu’AWS et Vercel facturent la bande passante bien plus cher
- Sauf besoin spécifique du cloud, une configuration serveur unique + SQLite + Litestream + CDN est plus simple et moins chère, et permet d’éviter une scalabilité horizontale inutile
La taille réelle d’un site web de premier plan vue à travers 11 Mo/s
- Business Insider est utilisé comme exemple de site web du top 1000
- Il était 587e mondial selon SimilarWeb, avec environ 200 millions de visiteurs mensuels
- Avec une moyenne de 2 pages par visiteur, il faut servir 400 millions de documents HTML par mois
- D’après un article échantillon, un document HTML standard pèse environ 75 Ko après compression
- En multipliant ces chiffres, le HTML seul nécessite environ 30 To/mois de bande passante
- 30 To/mois correspondent en moyenne à environ 11 Mo/s
- Dans le cas de Business Insider, cela représente environ 150 requêtes/s
- L’hypothèse est que le HTML n’utilise pas de CDN, tandis que JS, CSS et images peuvent être servis via un CDN
- 75 Ko de HTML compressé est plutôt élevé ; selon l’implémentation, il est possible d’ajuster en réduisant la taille du HTML ou en augmentant le nombre de requêtes
- Pour du matériel moderne, générer 11 Mo/s de HTML côté application est un seuil bas
- Les processeurs serveur AMD récents offrent 64 cœurs et 128 threads
- Les processeurs serveur Zen 5 Turin seraient, selon les rumeurs, dotés de 192 cœurs ; sur des serveurs bi-socket, on évoque des configurations proches de 400 cœurs et jusqu’à 768 threads
- De ce point de vue, Docker, le serverless et la scalabilité horizontale ne sont pas toujours des choix nécessaires
L’exécution en edge ne réduit pas toujours la latence
- La limite physique basse de la latence aller-retour à l’autre bout de la planète est d’environ 200 ms, d’après la vitesse de la lumière
- En pratique, il faut souvent environ 300 ms pour atteindre un bon datacenter situé à l’autre bout du globe
- Si les JS, CSS et médias sont servis via un CDN, réduire de 300 ms le temps de traitement serveur lors du rendu initial produit un effet comparable au fait de rapprocher le serveur de l’utilisateur
- Les technologies serverless de 2e génération ont fortement réduit le problème des cold boots, qui consommaient facilement le budget de latence de 300 ms par le passé, mais les allers-retours vers la base de données restent présents
- Si le rendu d’une page nécessite ne serait-ce qu’une requête à la base de données, le serveur edge doit refaire un aller-retour vers l’endroit où se trouve la base de données d’origine, par exemple us-east-1
- La latence est déplacée du trajet utilisateur–serveur d’origine vers le trajet serveur edge–serveur d’origine
- Les pages complexes nécessitent souvent 5 requêtes ou plus à la base de données pour le rendu
- De nombreux frameworks web exécutent les requêtes séquentiellement sur un seul thread ; plusieurs allers-retours entre datacenters peuvent donc être plus lents qu’un seul accès au serveur d’origine
- Une règle empirique veut que les communications entre datacenters soient 10 fois plus lentes que les communications à l’intérieur d’un datacenter, elles-mêmes 10 fois plus lentes que les communications au sein d’une même machine
- Dans ce contexte, SQLite en local apparaît comme un choix avantageux pour réduire la latence
Les écarts de coût entre Hetzner, AWS et Vercel
- Le serveur 16 cœurs de Hetzner inclut 64 Go de RAM et des disques NVMe pour 0,34 $/heure
- L’instance AWS EC2 m5a.4xlarge, comparée comme serveur x86 similaire, coûte 0,68 $/heure
- L’écart sur le prix de la bande passante est encore plus important
- Hetzner inclut 20 To de transfert gratuit, puis facture 1,5 $/To
- AWS inclut 100 Go gratuitement, puis facture 90 $/To
- Vercel est cité avec un exemple où le premier To est gratuit, puis 200 $/To
- Les quotas gratuits des fournisseurs cloud facilitent l’entrée au départ, mais peuvent se transformer en coûts élevés lorsque l’échelle augmente
Exploiter simplement une configuration à serveur unique
- À moins d’avoir un cas d’usage cloud spécifique, comme le transcodage vidéo, l’exécution de ses propres modèles d’IA ou des tâches qui imposent réellement une forte charge au système, un site web ou un SaaS peut tourner sur un seul serveur
- En plaçant le serveur en Virginie, il est possible d’offrir aux utilisateurs anglophones une latence inférieure à 100 ms
- La configuration recommandée reste simple, centrée sur une seule machine
- La base de données utilise SQLite sur la même machine
- Litestream assure la sauvegarde continue de SQLite
- CSS, JS et images sont mis en cache via un CDN
- Le rendu serveur est effectué près de SQLite afin de réduire les allers-retours et d’améliorer les performances
- Le déploiement n’a pas besoin d’être complexe
- Le CI peut envoyer le code sur le serveur via SCP
- NGINX prend en charge les déploiements sans interruption
- Docker et la virtualisation sont considérés comme des facteurs qui ralentissent l’exécution du code et le CI/CD
Quand la scalabilité horizontale est nécessaire, et quand elle ne l’est pas
- L’idée selon laquelle la scalabilité horizontale serait nécessaire est exagérée dans la plupart des cas
- Le postulat est que les performances des serveurs progressent plus vite que la croissance d’Internet
- Si la latence est vraiment critique, il est possible d’ajouter des serveurs en Allemagne et en Californie
- Les écritures sont routées vers le primary
- Les lectures utilisent un read replica local
- Une telle configuration est suffisamment scalable, peu complexe à administrer et nettement moins coûteuse
- Servir du HTML à l’échelle de 11 Mo/s n’a pas besoin d’être rendu inutilement difficile
1 commentaires
Commentaires sur Hacker News
Ma petite activité d’hébergement d’autrefois a justement prospéré puis décliné à cause de ça, sans que je comprenne à l’époque ce qui se passait
Lors de notre croissance au début des années 2000, les gros revenus venaient surtout de stacks complexes, avec beaucoup de configurations que les clients voulaient sans en avoir réellement besoin, comme des load balancers redondants et des pare-feu
La reprise sur incident coûtait souvent plus en complexité opérationnelle qu’elle ne rapportait quand un serveur tombait en panne de la manière prévue, et nous avons même créé une plateforme d’hébergement cloud basée sur API pour rivaliser avec AWS, mais le chiffre d’affaires a culminé en 2012
Les clients voulaient des solutions plus complexes, utilisant AWS en partie ou totalement, alors que nous pensions que le matériel étant devenu bien plus puissant qu’il y a 10 ans, même les gros clients voudraient moins de serveurs, plus simples
Mais ce n’était pas vendre de l’ingéniosité, c’était vendre du prix, et nous n’avions pas compris l’ambition financière nécessaire à ce virage. Personne ne faisait confiance à un serveur unique bon marché, et même avec deux serveurs, nous n’avions pas de vraie réponse sur la scalabilité
Au final, le chiffre d’affaires a tenu, mais nous n’avons pas pu bâtir une stack de services managés et un écosystème logiciel plus vite qu’Amazon, et après l’assèchement des nouveaux défis techniques, nous avons vendu l’entreprise en 2018
Comme nous avions grandi en bootstrap et qu’une facture d’hébergement sans plafond nous semblait un risque délirant, notre conception produit découlait aussi de cet état d’esprit, mais nous avons fini par voir que tout le monde acceptait ce risque
Si AWS s’est imposé, ce n’est pas seulement parce que le VC a rendu possible un produit cher, mais aussi parce que leur forme particulière d’ingéniosité s’est intégrée chez toute une génération de développeurs logiciels. En revanche, le savoir permettant de comprendre quand le cloud n’est pas nécessaire et quelles sont les alternatives semble désormais assez niche
Il y a plusieurs problèmes dans les chiffres
D’abord, le trafic ne se répartit pas uniformément. Le chiffre de 400 millions de chargements de page par mois dans l’article peut subir une loi de Pareto 80/20 récursive, et dans ce cas on se retrouve avec environ 205 millions de requêtes concentrées sur 5,8 heures, soit environ 9,7 k requêtes par seconde
C’est faisable sur un système unique, mais ce n’est plus trivial, surtout si on veut aussi une base de données unique sans réplica de lecture. Même à trafic total égal, la limite de bande passante nécessaire pour la charge de pointe devient bien supérieure aux 11 Mo/s obtenus par une moyenne optimiste
Ensuite, la latence aller simple de bout en bout ne s’applique qu’aux données en streaming. Dans un cold start réel, sans HTTP/3, il faut 3 allers-retours pour établir la connexion TCP, puis au moins 2 pour la connexion TLS, et ce n’est qu’ensuite que la requête et la réponse HTTP arrivent
Pour servir de vraies personnes, tout ce qui est observable doit se produire en moins d’une seconde, après quoi la proportion d’utilisateurs qui considèrent que le système est cassé et ferment l’onglet augmente brutalement
J’ai autrefois aidé à exploiter une bourse de paris, où le trafic connaissait des pics extrêmes et les exigences de latence étaient strictes, tandis que le volume des échanges se concentrait sur une toute petite portion de la fenêtre globale de l’événement. En trading en temps réel, l’utilisateur devait voir le résultat s’afficher à l’écran dans les 100 ms suivant le début de son action, et la latence réseau aller-retour grignotait le budget de traitement des événements
Référence : https://www.nngroup.com/articles/response-times-3-important-...
On peut toujours absorber une telle charge avec une grosse configuration à serveur unique, mais on n’est plus face à un simple serveur web : on construit en pratique un load balancer frontend assez costaud avec serveur web intégré
AWS facture cher, mais il y a énormément d’ingénierie derrière les load balancers et l’infrastructure réseau, ce qui évite à tout le monde d’avoir à devenir expert de toute cette partie de la stack
En pratique, combien de services ont réellement besoin d’une portée mondiale ? Ont-ils aussi été conçus avec la prise en charge de plusieurs langues ?
Si le service cible les États-Unis ou l’UE, un seul serveur central correct peut fournir une latence inférieure à 30 ms sur toute cette région
À moins d’avoir de vraies exigences mondiales et de devoir gérer une base de données globale, l’edge est plutôt surestimé
Vu le
500 Internal Server Error, l’auteur reçoit apparemment plus de trafic que 11MB/s. Une archive est disponible ici : https://archive.is/UVpg0PR_END_OF_FILE_ERRORpour la première fois. Sur divers sites, on dit que cela vient d’un proxy, d’un VPN ou du DNS-over-HTTPS, mais dans mon cas, ce n’est pas çaJe pense que cet article aborde le sujet sous le mauvais angle
Une meilleure approche serait : ne scalez pas trop tôt
Il suffit de construire ce dont on a besoin et, dans la plupart des cas, même un CDN est une dépense inutile, à condition de ne pas payer la taxe excessive sur la bande passante imposée par le fournisseur cloud
Quand des problèmes de performance commencent à apparaître, on les traite à ce moment-là, et si le cheval de trait ordinaire devient soudain la licorne que tout le monde veut, c’est un problème qu’on sera heureux d’avoir
Si le produit est bon, les utilisateurs réessaieront une heure plus tard au lieu de partir immédiatement chez un concurrent. Si des problèmes de scalabilité apparaissent, il suffit d’adopter un modèle hybride en ne faisant scaler que les parties gourmandes en ressources
Mais si vous voulez malgré tout du web scale dès le départ, des dizaines de microservices, des états de panne qui explosent entre eux, et brûler l’argent du VC en facture AWS avant même le premier client, faites donc
Gérer soi-même des serveurs physiques, c’est un problème pour plus tard, pas pour maintenant. Le jour où vous devrez choisir entre une facture AWS d’un million de dollars et un gros serveur unique, vous ne prendrez pas votre décision à partir d’un billet de blog, vous ferez vos propres tests
Avec AWS, on achète aussi un bouc émissaire. Une grosse panne d’un grand service cloud est facile à expliquer à son manager ou à ses investisseurs, mais il est bien plus difficile d’expliquer le même cumul d’indisponibilité quand il est causé par une erreur humaine dans l’équipe
Je me demande donc comment cela s’articule avec l’idée que le cloud sert de bouc émissaire
Si l’objectif est la montée en charge verticale, pourquoi SQLite ? Rien n’empêche d’exécuter un Postgres auto-hébergé ou Supabase sur le même serveur que l’app, et à part un effort de configuration plus important, il est difficile de voir de vrais inconvénients
On pourrait aussi se passer de DB, garder tout l’état global dans la mémoire réelle d’un gros serveur, le conserver sous forme d’objets internes au processus sans aller-retour Redis, faire de temps en temps des snapshots mémoire sur disque, et utiliser un langage multithread compilé ; avec ça, on pourrait saturer une NIC de plus de 1 Gbit et servir le monde entier depuis une seule machine
J’aimerais bien voir un cas réel qui adopte vraiment une telle architecture
En dehors des schémas classiques de persistance relationnelle, les écarts de fonctionnalités peuvent être importants et Postgres peut alors être préférable, mais pour certains patterns architecturaux, SQLite peut avoir l’avantage
Pour des applications centrées sur le contenu comme BusinessInsider, le pattern Baked Data fondé sur SQLite peut être meilleur en coût et en latence
simonw(datasette) a produit beaucoup d’outils et d’articles sur l’usage de SQLite en production pour des sites web riches en contenu ou en données : https://simonwillison.net/2021/Jul/28/baked-data/
C’est logique, puisque SQLite tourne dans le processus et ne nécessite pas de sérialisation. Il y a aussi l’avantage supplémentaire de pouvoir sérialiser les opérations, ce qui simplifie énormément les tests, le raisonnement et la construction d’une couche de cache
Il y a aussi le surcoût réseau si on n’utilise pas de socket Unix, mais comme on parle du même serveur, cela reste annexe. En pratique, il est très courant de placer Postgres sur une autre machine pour l’isolation, et c’est d’ailleurs l’un des principaux avantages d’une base de données réseau
Il a toutes les fonctionnalités nécessaires, avec en plus une meilleure simplicité et de meilleures performances. SQLite peut gérer des volumes de données de l’ordre du téraoctet, plusieurs lecteurs, des sauvegardes en streaming en temps réel, et c’est globalement une implémentation SQL assez équilibrée
Je ne considérerais Postgres/MySQL qu’au moment de dépasser la montée en charge verticale sur une seule machine
https://blog.cloudflare.com/introducing-d1
Beaucoup semblent penser que, puisque l’auteur met l’accent sur la latence, la bande passante et le coût, il faudrait défendre l’état actuel au nom de la disponibilité et de la fiabilité
Ma conclusion n’est pas qu’il faut nier les avantages du cloud face aux compromis, mais plutôt se demander si les patterns d’architecture cloud désormais omniprésents — et les dépendances qu’ils entraînent — sont réellement indispensables
L’opposition entre ceci et cela n’est qu’un procédé rhétorique pour présenter une alternative, et la bonne solution dépend d’innombrables facteurs liés au cas d’usage. C’est précisément à cause de ces facteurs que les ingénieurs ont du travail
Cela dit, même dans le pattern proposé par l’auteur, on peut répondre aux préoccupations SRE. « Et si le seul serveur tombe, qu’en est-il de la disponibilité ? » relève presque de l’homme de paille, dans la mesure où la disponibilité peut être traitée autrement que dans les systèmes auxquels nous sommes habitués, et la solution doit correspondre à ce qui compte vraiment
Avec un budget serré, il existe un moyen d’en faire juste un peu plus pour obtenir bien davantage : placer l’API et la base SQLite ensemble
Idéalement, l’API utiliserait un format de sérialisation binaire à faible surcoût et des connexions persistantes, tandis que la diffusion web pourrait profiter du free tier d’un service edge financé par du capital-risque qui brûle de l’argent. À l’heure actuelle, Cloudflare Workers est assez généreux et le trafic sortant y est gratuit
Le point clé, c’est que SQLite peut traiter un nombre énorme de requêtes par seconde, même sur un seul thread. On peut y faire passer beaucoup d’opérations en série, ce qui facilite le raisonnement et simplifie la mise en cache mémoire côté API ainsi que son invalidation
En séparant le serving web, on bénéficie des performances edge pour le handshake, et sur les pages statiques on peut même éviter complètement la DB. L’article sous-estime le problème des aller-retour, alors qu’en pratique les applications réelles en demandent plus qu’on ne le pense, ce qui en fait un sujet très concret
En dehors de la DB, l’essentiel de l’usage CPU vient du parsing, de la désérialisation, de la copie de données et de TLS ; donc si on enlève une grosse partie de cela, on peut facilement obtenir des dizaines de milliers d’écritures par seconde, même sur des machines d’entrée de gamme, et les lectures vont encore plus vite
Cela dit, les goulots d’étranglement classiques, notamment l’I/O, méritent toujours d’être benchmarkés. Les fournisseurs ont souvent tendance à exagérer ou à induire en erreur, donc il faut tester soi-même sur le free tier. Mieux vaut aussi préparer des tests d’intégration et des benchmarks pour le moment où il faudra migrer
C’est assez intéressant quand les résultats sont volumineux, mais j’espère que PostgreSQL lui-même ne deviendra pas le goulot d’étranglement lorsqu’il doit produire du JSON à partir de gros jeux de données
Les gens disent qu’il faut être à la périphérie, au plus près des utilisateurs, et réduire la latence.
Mais en pratique, à quel point la latence est-elle vraiment un problème ?
Le projet de recommandation de livres Gnooks, hébergé sur un serveur en Allemagne, en est un exemple : https://www.gnooks.com
Je me demande si quelqu’un le trouve vraiment trop lent.
Au cours des dernières années, ce projet a reçu des milliers de suggestions d’utilisateurs, mais de mémoire, personne n’a jamais soulevé le sujet de la latence. Et pourtant, le plus grand groupe d’utilisateurs se trouve aux États-Unis.
Il souffre donc bien moins des problèmes de latence que les PWA modernes, qui implémentent l’essentiel de la logique dans le frontend puis envoient plusieurs requêtes au backend pour récupérer les données nécessaires.
Malgré cela, le site reste correct. Le problème se pose surtout si le site est déjà lent à la base.
En faisant cela depuis l’Europe, on obtient à peu près le double de la latence perçue par un utilisateur australien, ce qui aide à se faire une idée du pire cas.
La bonne nouvelle, c’est qu’on peut tester cela de manière fiable et vérifier si c’est réellement important. On obtient alors une réponse concrète.
Le texte ne traite pas du tout de la disponibilité. Un service qui tourne sur une seule machine subira à la fois des interruptions planifiées et des interruptions imprévues.
Il faut aussi réfléchir aux RPO/RTO. Quand la machine tombe — ou plutôt lorsqu’elle tombera — il faut savoir combien de temps prendra la reprise et combien de données seront perdues.
À propos de l’idée que s’il y a ne serait-ce qu’une requête de base de données dans le rendu de page, il faut revenir vers une base en us-east-1, il existe aussi des options comme :
https://aws.amazon.com/rds/aurora/global-database/
https://aws.amazon.com/dynamodb/global-tables/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
Et il en existe beaucoup d’autres ; si vous essayez d’assembler vous-même quelque chose d’équivalent, vous allez souffrir.
Il y a 10 à 20 ans, j’aurais été d’accord. Internet était nouveau, les gens accusaient le site quand il tombait, et la situation se dégradait vite. Mais aujourd’hui, ils sont plus susceptibles de blâmer leur fournisseur d’accès ou de réessayer plus tard.
Tout le monde n’est pas Google, et les systèmes plus simples ont aussi moins de chances d’échouer au départ. Il suffit de conserver des sauvegardes et, si cela vous inquiète vraiment, de répliquer la base vers un site de reprise après sinistre à froid. Pour la plupart des entreprises et des situations qui ne sont pas du FAANG, c’est largement suffisant.
Tant que les données ne sont pas perdues, pour beaucoup d’entreprises cela ne sera qu’un bref clignotement. Avec une bonne communication et si l’événement est très rare, elles peuvent même supporter plusieurs jours d’indisponibilité, et dans certains cas même une perte de données.
On disait autrefois que chaque 9 supplémentaire en fiabilité doublait les coûts ; il faut absolument l’intégrer quand on calcule le ROI. Le niveau de fiabilité réellement nécessaire à l’entreprise dépend de son marché cible, et je pense que la réponse automatique de l’IT, 100 %, est erronée.
Un modèle à un ou deux serveurs est aussi bien moins complexe, c’est pourquoi des équipes d’exploitation comme celle de Let’s Encrypt ont elles aussi choisi cette architecture à deux serveurs physiques pour faire tourner un service mondial à l’échelle du web : https://letsencrypt.org/2021/01/21/next-gen-database-servers...
Grâce à la très faible latence interne d’une base dans le serveur ou juste à côté, le logiciel peut exécuter ses requêtes de base de données plusieurs ordres de grandeur plus vite, utiliser moins de ressources par utilisateur et offrir une expérience plus réactive que les services de base de données managés en pratique.
La complexité crée ses propres pièges, et je pense qu’il n’existe aucun service web qui n’ait jamais raté quelque chose à ce niveau. AWS lui-même provoque parfois des incidents.
On ne peut pas dire qu’un VPS soit forcément pire sur ce point.