OpenFreeMap teilt seine Erfahrung mit der Bewältigung von 100.000 Anfragen pro Sekunde

 (blog.hyperknot.com)
5 Punkte von GN⁺ 2025-08-10 | 1 Kommentare | Auf WhatsApp teilen
  • OpenFreeMap hat erfolgreich 100.000 Anfragen pro Sekunde und 300 Millionen tägliche Zugriffe verarbeitet
  • Der plötzliche Anstieg bei Wplace.live und automatisierte Massenanfragen waren die Ursache des Traffic-Spikes
  • Cloudflare erreichte eine CDN-Cache-Rate von 99,4 %; der Server verkraftete zusätzlich noch 1.000 RPS problemlos
  • Daraus resultierten nur kleinere Vorfälle wie fehlende Kacheln; der Service lief insgesamt weitgehend normal
  • Künftig sind Verbesserungen beim automatischen Traffic-Management geplant, unter anderem eine Referer-basierte Bandbreitenbegrenzung

Zehn Monate OpenFreeMap und die Bewältigung von Extrem-Traffic

OpenFreeMap hat in den letzten 10 Monaten eine sehr stabile Betriebszeit erlebt. Dank der Bandbreitenunterstützung durch Cloudflare, der Stabilität der Hetzner-Server, des Tile-Service über Btrfs und der Effizienz von nginx wurde die Systemzuverlässigkeit bestätigt. Eines Tages wurde jedoch plötzlich gemeldet, dass einige Kacheln nicht geladen würden. Normalerweise wäre das durch einen Algorithmusfehler verursacht, diesmal wurde im nginx-Log jedoch der Fehler open() "Too many open files" festgestellt.

Über das Traffic-Monitoring-Tool wurde festgestellt, dass in 24 Stunden 3 Milliarden Anfragen auftraten und allein die kleinen Tile-Dateien 215 TB Traffic erzeugten. In den letzten fünf Minuten gab es einen Peak von 30 Millionen Anfragen, also 100.000 Requests pro Sekunde. Für einen kommerziellen Kartendienst würden hier monatlich Kosten von über 6 Millionen US-Dollar anfallen.

Im Dashboard von Cloudflare wurden 96 % mit 200 OK beantwortet; nur 3,6 % wurden als abnormal (206 Partial Content) klassifiziert. Die meisten Anfragen wurden normal bedient, und außer einigen fehlenden Kacheln funktioniert das gesamte System ordnungsgemäß.

Ursache des Traffic-Spikes: Wplace.live

Die Ursache dieses Spikes war die neue kollaborative Zeichen-Webseite Wplace.live. Kurz nach dem Start kamen dort massenhaft Nutzer an, und sie wurde so ausgelegt, dass sie Karten auf OpenFreeMap-Basis verwendet. Nutzer erzeugten große Mengen an Requests mit automatisierten Tools (z. B. Puppeteer/Chromium, IP-Rotation usw.), um das Limit von 1 Pixel in 30 Sekunden zu umgehen.

Der Betreiber betont anhand früherer Erfahrungen mit Neal.fun, wie wichtig die Vorabkommunikation vor einem solchen Verkehrszuwachs ist. Da der Vorfall diesmal den Betrieb störte, wurde erstmalig eine Cloudflare-Regel eingesetzt, um zu blockieren. Für die Zukunft wird nach automatischen Traffic-Steuerungsansätzen auf Basis von referer oder custom header gesucht, inklusive der Nutzung der Cloudflare-API.

Unterstützung durch Cloudflare und die Leistung der OpenFreeMap-Architektur

Cloudflare hat die Bandbreitenunterstützung in einem sehr schnellen Prozess (innerhalb von 48 Stunden inkl. Wochenende) genehmigt und sogar mit den Engineers über die passende Architektur gesprochen. Auch als großer Anbieter zeigte Cloudflare bemerkenswerte Reaktionsfähigkeit.

Der Betreiber ist stolz darauf, eine CDN-Cache-Rate von 99,4 % erreicht zu haben und der Server habe auch eine Last von 1.000 RPS verkraftet. Für einen Dienst, der wöchentliche Datenupdates bereitstellt, sei das ein beachtliches Ergebnis.

Austausch mit den Wplace.live-Entwicklern und Lösungsvorschläge

Später wurde Kontakt mit den Entwicklern von Wplace.live aufgenommen, die verstanden, dass sie wegen des plötzlichen Anstiegs auf 2 Millionen Nutzer nicht ausreichend vorbereitet waren. Es wurde besprochen, Self-Hosting-Instanzen von OpenFreeMap anzubieten, um die Traffic-Konzentration zu senken und die Effizienz zu steigern.

Außerdem deutet die Tatsache, dass bei nur 2 Millionen Nutzern 3 Milliarden Anfragen auftraten, darauf hin, dass script-basierte Massenanfragen überwiegen. Da normale Nutzer bei nur 10 bis 20 Requests bleiben, wurde empfohlen, die Service-Politik zu ändern, um unnötige automatisierte Requests zu verhindern.

Künftige Verbesserungen und Learnings

Der Betreiber kündigt Verbesserungen in zwei Punkten an.

  1. Referer-basierte Bandbreitenbegrenzung

    • Geplant ist die Begrenzung von Requests pro Referer in Cloudflare auf etwa 100 bis 200 Millionen innerhalb von 24 Stunden
    • Native Apps sollen künftig auf die Verwendung von custom header gesetzt werden

  2. Umgang mit fehlenden Kacheln und Serverkonfiguration

    • Es werden Maßnahmen umgesetzt, damit durch fehlerhafte Serverkonfiguration keine leeren Kacheln mehr erzeugt werden

OpenFreeMap wird derzeit mit 500 US-Dollar monatlicher Spenden betrieben. Die Infrastrukturausgaben sind ausreichend gedeckt, aber neue Entwicklung hängt von begrenzter persönlicher Zeit ab. Zusätzliche Unterstützung könnte die Entwicklungsgeschwindigkeit und die Ausweitung der Service-Stabilität ermöglichen.

Über GitHub-Sponsoring kann man das Projekt unterstützen: https://github.com/sponsors/hyperknot

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-10
Hacker-News-Kommentare

  • Ich vermute, dass einige der Bilder von Script-Kiddies stammen. Da die Seite jedem Nutzer nur einen Pixel pro 30 Sekunden erlaubt, nehme ich an, dass viele die Automatisierung so gefahren haben: Neuen Browser mit Puppeteer oder Chromium öffnen, ein Pixel klicken und den Browser wieder schließen. Möglicherweise wurde sogar die IP-Adresse rotiert, wobei dieser Aufwand womöglich gar nicht nötig gewesen wäre. Ich hoffe, niemand hat unterschätzt, wie stark dieses Phänomen in einer Nacht angewachsen ist. Als ich ein paar Leuten ein Bild erwähnt habe, das in der Nähe meines Zuhauses gezeichnet war, wussten sie sofort, wovon die Rede ist, obwohl ich die Website gar nicht genannt habe. Menschen mögen /r/place-ähnliche Projekte anscheinend immer wieder alle paar Jahre, und diesmal hat es offenbar viel Anklang gefunden, weil man auf der Weltkarte zeichnen kann – direkt in der Nähe seines eigenen Standorts.

  • Ich frage mich, wie es gewesen wäre, wenn MapLibre stattdessen statische pmtiles-Dateien direkt gelesen hätte. Als ich pmtiles von BunnyCDN per Range-Request geholt habe, war die Antwortzeit fast die gleiche wie beim Abruf vom eigentlichen Tile-Server.

    • Ich glaube, wplace könnte alles mit einer benutzerdefinierten static pmtile-Datei lösen; in dem Fall müsste man gar nicht die 150 GB OSM-Daten verarbeiten.

    • Den entsprechenden Link habe ich geteilt.

  • Danke für die ausführliche Erklärung und die Offenheit. Ich überlege gerade, OpenFreeMap in die Ausfallkarte von StatusGator statt MapTiler zu integrieren.

    • Ein Umstieg ist jederzeit möglich. Wenn dich eine hohe Verfügbarkeit beschäftigt, kannst du selbst hosten. Ich bemühe mich weiterhin, die öffentliche Instanz so stabil wie möglich zu machen.

  • Als ich nur die Screenshots gesehen habe, wirkte es so, als reiche eine einzige VPS und die Architektur wirkte unnötig komplex. Erst dann wurde mir klar, dass die Pixel über die gesamte Weltkarte verteilt sind. Ich frage mich, wie hoch der Spitzen-Request-Durchsatz war. Vielleicht wäre ein Webserver, den man leicht benchmarken kann, nur knapp ausreichend gewesen. Natürlich kann die App je nach Lastprofil deutlich stärker einbrechen. Bei 64 Pixeln pro km wären bei unkomprimierter Farbgebung 8 TB für die Vollabdeckung der Erde nötig (eine längerfristige Überlegung!). Bei Hetzner kostet eine 10-TB-Box etwa 20 € pro Monat, Caching wirkt dafür Pflicht. wplace verwendet für die Zeichnungsebene ein 1000x1000-PNG: Die Zeichnung lädt sofort, aber die Karte selbst ist extrem langsam und manche Bereiche laden überhaupt nicht.

    • Bei 20 € für eine 10-TB-Box im Monat bei Hetzner klingt das zwar gut, aber ob es wirklich stabil läuft, wenn es wirklich gebraucht wird, ist eine andere Frage.

  • Es scheint so, als wäre die Beschränkung der offenen Dateien der Engpass gewesen. Ich frage mich, ob es nur gereicht hätte, dieses Limit zu erhöhen. Das Blockieren von Spam-Traffic ist nachvollziehbar, aber theoretisch hätte es vielleicht auch mit höherem Limit gereicht.

    • Nach längerer Fehlersuche mit mehreren LLMs habe ich im nginx-Community-Forum eine Frage gestellt. Aktuell tippe ich auf die Kombination aus multi_accept, open_file_cache und worker_rlimit_nofile. Details siehe hier. Der Server war bereits bei 200 Mbit/s ausgelastet, daher wäre es selbst mit höherem Limit vermutlich nicht lange durchzuhalten gewesen.

  • Ich frage mich, ob Seiten ohne Caching nur deshalb so gestaltet sind, weil es zu umständlich ist. Warum leitet wplace.live so viel Traffic an OpenFreeMap weiter, obwohl man mit einem einzelnen Cache-Server vor der eigenen Instanz ähnlich schnell oder schneller als OpenFreeMap selbst liefern könnte?

    • OpenFreeMap liegt hinter einem CDN, und auf der Homepage steht sinngemäß: "Kostenlose öffentliche Instanz, keine Begrenzung für Views/Requests, keine Registrierung, keine Cookies, kein API-Key erforderlich. Die Kosten werden durch Spenden gedeckt. Kommerzielle Nutzung ist erlaubt." Das liest sich wie sofortige Nutzbarkeit. Kein echter Grund, trotzdem einen Cache-Server vor das CDN zu hängen. Klar kann man die Bandbreite prüfen und entsprechend abwägen, aber bei einem unerwarteten Viral-Moment kann man mit anderen Dingen ausgelastet sein.

    • Auf genau diese Frage lässt sich die Antwort klar formulieren: Es ist eine Frage der Prioritäten. Ich betreibe eine ziemlich beliebte Auktionsseite und hole die Kartenkacheln über Stadia Maps. Ich zahle dafür 80 USD im Monat; ich weiß, dass es günstiger wäre, die Tiles zu cachen und über einen Proxy bereitzustellen, aber es gibt immer etwas Dringenderes, sodass das Caching noch nicht umgesetzt ist.

    • Das Datenvolumen hier ist riesig. Kurzfristig wurden 56 Gbps erreicht (56 Server mit 100 % Traffic-Verbrauch!). Das kann ein einzelner Cache-Server nicht mehr abdecken; dafür braucht man ein CDN-Netzwerk wie Cloudflare.

    • Es wirkt wie ein spaßiges Projekt und scheint nicht gewinnorientiert. Bei solchen Projekten steht meist „funktionieren lassen“ im Mittelpunkt, nicht vorrangig die Skalierung für Massen-Traffic. Die Nutzerzahl hat sich innerhalb einer Nacht verdoppelt, und die Wartung wirkt wie von einer Person oder einem sehr kleinen Team.

  • Ich habe noch nie mit Cloudflare gearbeitet und bin nicht besonders vertraut mit Web-Map-Technologien. Wenn die Seite überwiegend statische Dateien liefert, frage ich mich, warum man dann weiterhin bei Hetzner bleibt. Wäre eine vollständige Migration auf Cloudflare Pages nicht möglich?

    • Bei Tiles ist Rendering nötig. Häufig genutzte Tiles werden bereits gecacht, und diese Aufgabe übernimmt Cloudflare. Theoretisch lässt sich der Tileserver auf Cloudflare Pages portieren, aber der Portierungsaufwand bleibt bestehen, und die Kosten würden vermutlich nicht sinken.

  • Eine Referrer-basierte Beschränkung wirkt wie eine merkwürdige Wahl. Wenn ein normaler Nutzer 10–20 Requests pro Minute stellt, würde ein Limit von 100 Requests pro IP und Minute (ca. das 5-fache des Durchschnitts) nicht die meisten blockieren? Oder wären nur einige bösartige Nutzer nicht ohnehin mit JA4/JA3-Mustern zu blockieren?

    • Es gibt auch Nutzer, die wirklich rund um den Globus erkunden wollen. Ich erinnere mich daran, wie ich Google Earth schon mal einen halben Tag lang angeschaut habe. Ich halte eine Referrer-basierte Beschränkung für sinnvoller: Nutzer mit hohem Traffic kann man auf Self-Hosting statt der öffentlichen Instanz hinweisen.

    • Referrer-basierte Limits sind ein guter erster Schritt (die Startseiten-Hinweismeldung müsste dafür vermutlich angepasst werden). Der Verbrauch auf Site-Ebene zu verfolgen ist wirksamer. Auf Site-Seite kann man zu geänderten Nutzungsgewohnheiten aufrufen, aber für einzelne Nutzer ist das schwierig. Ein zusätzliches IP-Limit könnte helfen, aber wenn es zu niedrig gesetzt ist, nützt es in solchen Fällen wenig.

  • Ich finde, ihr habt es sehr sauber blockiert. Das ist ein DDoS-Angriff. Umso besser, dass dafür nicht separat Bandbreite gezahlt werden musste; sonst wäre es ein echter Wallet-Killer geworden.

  • Die Cache-Hit-Rate ist extrem hoch. Ich frage mich, ob es dafür eine besondere Technik gibt.

    • Ich habe die komplette Routing-Struktur und die location blocks bewusst mit Caching im Blick aufgebaut. Wenn du willst, schau dir das nginx.conf-Beispiel an.