OpenFreeMap, retour d'expérience sur la gestion de 100 000 requêtes par seconde
(blog.hyperknot.com)- OpenFreeMap a géré avec succès jusqu'à 100 000 requêtes par seconde et 300 millions de requêtes quotidiennes.
- La hausse soudaine de popularité de Wplace.live et les requêtes massives automatisées sont à l'origine du pic de trafic.
- Le taux de cache CDN de Cloudflare est de 99,4 %, et le serveur a absorbé sans difficulté les 1 000 rps restants.
- Cela n'a provoqué que de petites pannes, comme des tuiles manquantes, et le service est resté globalement opérationnel.
- À l'avenir, des améliorations de gestion automatique du trafic sont prévues, notamment la limitation de la bande passante basée sur le référent.
Expérience d'OpenFreeMap des 10 derniers mois face à un trafic de très grande ampleur
OpenFreeMap a accumulé une expérience d'exploitation très stable ces 10 derniers mois. La fiabilité du système est démontrée grâce au soutien de bande passante de Cloudflare, à la stabilité des serveurs Hetzner, au service de tuiles sur Btrfs, et à l'efficacité de nginx. Cependant, un jour, il a reçu un signalement selon lequel certaines tuiles ne se chargeaient pas. Ce problème est généralement dû à un bug d'algorithme, mais cette fois-ci, l'erreur open() "Too many open files" a été trouvée dans les journaux nginx.
La surveillance du trafic a montré qu'il y avait eu 3 milliards de requêtes sur 24 h, et que 215 TB de trafic avaient été enregistrés avec seulement de petits fichiers de tuiles. Au cours des cinq dernières minutes, il y a eu 30 millions de requêtes, soit une hausse atteignant 100 000 requêtes par seconde. Ce trafic aurait coûté plus de 6 millions de dollars par mois sur un service de cartographie commerciale.
Le tableau de bord Cloudflare affichait 96 % de réponses 200 OK, et seulement 3,6 % étaient anormales (206 Partial Content). La majorité des requêtes était correctement servie, et à part quelques tuiles manquantes, le système dans son ensemble fonctionnait correctement.
Cause de la hausse de trafic : Wplace.live
La cause de cette hausse est Wplace.live, un nouveau site de dessin collaboratif. Il a attiré de nombreux utilisateurs dès son lancement et a été conçu pour utiliser une carte basée sur OpenFreeMap. Les utilisateurs ont généré des requêtes en masse via des outils automatisés (par exemple Puppeteer/Chromium, rotation d'IP, etc.) pour contourner la limite de 1 pixel/30 s.
Le mainteneur souligne, citant son expérience passée avec Neal.fun, l'importance d'une communication en amont avant la survenue d'un pic. Cette fois-ci, comme le fonctionnement du service en a souffert, il a appliqué pour la première fois des règles Cloudflare pour bloquer le trafic. Par la suite, il prévoit des solutions de contrôle automatique du trafic basées sur le referer ou des headers personnalisés (incluant l'utilisation de l'API Cloudflare).
Support de Cloudflare et performances de l'architecture OpenFreeMap
Cloudflare a approuvé le support de bande passante dans un délai très court (moins de 48 h, week-end inclus), et a même discuté avec les ingénieurs de la compatibilité de l'architecture. Malgré sa taille, le groupe a montré une grande réactivité.
Le propriétaire se félicite d'avoir atteint un taux de cache CDN de 99,4 % et que le serveur a tenu une charge de 1 000 rps. C'est une performance élevée pour un service qui propose des mises à jour de données hebdomadaires.
Échanges avec le développeur de Wplace.live et propositions de correction
Par la suite, un échange a été possible avec le développeur de Wplace.live, qui a compris qu'il n'était pas préparé à une hausse soudaine à 2 millions d'utilisateurs. Une discussion a eu lieu pour proposer le support d'instances self-hosting OpenFreeMap, afin d'éviter la concentration du trafic et d'améliorer l'efficacité.
De plus, le fait que 3 milliards de requêtes aient été générées pour les 2 millions d'utilisateurs réels indique que des requêtes massives automatisées par scripts dominaient. Puisque l'utilisateur moyen se limite à 10 à 20 requêtes, il recommande de modifier la politique du service pour empêcher les requêtes automatisées inutiles.
Prochaines améliorations et apprentissages
Le mainteneur annonce deux améliorations à apporter :
-
Limitation de la bande passante basée sur le référent (Referer)
- Mise en place prévue sur Cloudflare d'une limitation de 100 à 200 millions de requêtes par référent et par 24 h
- Les applications natives devraient être orientées vers l'utilisation d'un custom header
-
Gestion des tuiles manquantes et amélioration de la configuration serveur
- Mesures prévues pour éviter la génération de tuiles vides dues à une mauvaise configuration serveur
OpenFreeMap fonctionne actuellement grâce à des dons mensuels de 500 dollars. Les coûts d'infrastructure sont suffisamment couverts, mais les nouveaux développements dépendent d'un temps personnel limité. Avec un soutien supplémentaire, il serait possible d'accélérer le rythme de développement et d'élargir la stabilité du service.
Vous pouvez participer au soutien du projet via GitHub Sponsors : https://github.com/sponsors/hyperknot
1 commentaires
Avis de Hacker News
Je suppose que certaines images ont été dessinées par des script kiddies. Cette plateforme n’autorise qu’un pixel toutes les 30 secondes par utilisateur, donc je pense que chacun a lancé une automatisation en ouvrant un nouveau navigateur avec Puppeteer ou Chromium, en cliquant sur un pixel, puis en fermant le navigateur. Ils ont peut-être aussi fait de la rotation d’IP, mais cette étape n’était peut-être pas nécessaire. J’espère qu’on ne sous-estime pas l’ampleur qu’a prise ce phénomène en une seule nuit. Quand j’ai mentionné à quelques personnes un dessin près de chez moi, tous ont tout de suite compris de quoi il s’agissait sans que je cite le site. Les gens adorent vraiment les projets de type /r/place tous les quelques années, et cette fois-ci, le fait de pouvoir dessiner près de chez soi sur une carte du monde entier a probablement créé une très forte adhésion.
Je me demande quelle différence cela ferait si maplibre lisait directement des fichiers pmtiles statiques. En important des pmtiles depuis Bunnycdn via des range requests, j’ai constaté une latence quasi identique à celle d’un vrai tile server.
Avec wplace, une seule pmtiles statique personnalisée pourrait suffire à couvrir tous les besoins. C’est un cas où il ne serait absolument pas nécessaire de traiter 150 Go de données OSM.
Lien associé
Je trouve ces explications très détaillées et cette transparence précieuses. J’envisage d’adopter OpenFreeMap pour la carte de panne de StatusGator plutôt que MapTiler.
En ne regardant que les captures d’écran, cela semblait pouvoir tenir avec un seul VPS, et l’architecture paraissait trop complexe. Puis j’ai réalisé que les pixels étaient superposés à une carte globale. Je me demande quel pourrait être le débit maximal. Cela pourrait être du niveau d’un serveur web de base, facilement benchmarkable. Bien sûr, selon la nature de l’application, la dégradation de performance peut être importante. Avec 64 pixels au km, il faudrait 8 To pour couvrir le globe en couleur non compressée (un problème à envisager sur le long terme !). Chez Hetzner, une box de 10 To coûte 20 € par mois ; le cache semble indispensable. wplace utilise des PNG de 1000x1000 pixels pour la couche de dessin, et l’image apparaît immédiatement, mais la carte en elle-même est extrêmement lente et certains segments ne s’affichent pas du tout.
Je me demande si le problème ne venait pas de la limite du nombre de fichiers ouverts, et s’il n’aurait pas été possible de le gérer en augmentant simplement cette limite. Je comprends le besoin de bloquer le trafic spam, mais je me demande si, en théorie, relever cette limite n’aurait pas permis de gérer davantage.
Je me demande si les sites qui n’implémentent pas de cache ne le font pas simplement par flemme. Pourquoi wplace.live envoie autant de trafic vers OpenFreeMap, alors qu’un seul serveur de cache sur son propre serveur pourrait offrir un service aussi rapide, voire plus rapide, qu’OpenFreeMap ?
OpenFreeMap est derrière un CDN, et la page d’accueil indique : « Instance publique gratuite, aucune limite de vues/requêtes, aucune inscription/cookie/clé API requise. Les coûts sont couverts par des dons. L’usage commercial est autorisé. » à la lecture, on a l’impression qu’on peut l’utiliser tel quel. Il ne semble donc pas logique d’ajouter un serveur de cache en frontal du CDN. Bien sûr, on peut vérifier et réfléchir à la bande passante, mais en cas de viralité inattendue, on peut être distrait par d’autres tâches.
Je peux répondre précisément à cette question : c’est une question de priorité. Je gère un site d’enchères assez populaire et je récupère les tuiles depuis stadia maps. Je paie 80 USD par mois, je sais que je pourrais les mettre en cache et les servir depuis un proxy pour réduire les coûts, mais il y a toujours quelque chose de plus urgent, donc je n’ai pas encore mis en place le cache.
Le volume de données géré ici est énorme. Un pic de 56 Gbps (56 serveurs à 100 % de consommation de trafic !) a été observé. C’est au-delà de ce qu’un simple serveur de cache peut couvrir. Ce type de charge demande un réseau CDN de type Cloudflare.
Le site a l’air intéressant et semble non commercial. Sur ce genre de site, l’objectif principal est souvent de « faire en sorte que ça fonctionne bien », pas de prioriser la gestion de trafic massif. Le nombre d’utilisateurs a doublé du jour au lendemain, et la maintenance semble assurée par une seule personne ou un petit groupe.
Je n’ai jamais utilisé Cloudflare directement et je ne suis pas familier avec la techno web mapping. Si le site ne sert quasiment que des fichiers statiques, je me demande pourquoi continuer avec Hetzner. Je me demande s’il serait possible de migrer entièrement vers Cloudflare Pages.
La limitation basée sur le referrer me paraît étrange. Si un utilisateur légitime fait 10 à 20 demandes par minute, ne pourrait-on pas bloquer la plupart des cas avec une limite de 100 requêtes par minute par IP (5x la moyenne) ? Ou, pour quelques utilisateurs malveillants, ne pourrait-on pas bloquer par des patterns JA4/JA3 ?
Il peut aussi y avoir une personne qui veut vraiment explorer la planète entière. Je me souviens avoir passé une demi-journée sur Google Earth. Je pense qu’une limitation basée sur le referrer est préférable ; on peut orienter les utilisateurs à forte consommation vers un hébergement personnel plutôt que vers l’instance publique.
La limitation via le referrer est une bonne première étape (il faudrait aussi modifier le message d’alerte de la page d’accueil). Suivre l’usage par site est plus efficace. Du côté des sites, on peut demander de changer leur pattern d’utilisation, mais cela reste difficile pour chaque utilisateur individuel. Ajouter aussi une limite par IP serait bienvenu, mais si elle est trop basse, elle n’aurait pas d’effet dans ce cas.
Je pense que le filtrage a été très bien fait. C’est clairement une attaque DDoS. Heureusement qu’il n’y a pas de facturation supplémentaire de bande passante ; sinon, cela aurait été une vraie attaque qui vide les portefeuilles.
Le taux de hit du cache est extrêmement élevé. Je me demande s’il existe une technique particulière implémentée.