Umweltzone-Zeichen (Quelle: Wikipedia, gemeinfrei)

Von Tobias stammt die Wochenaufgabe, die sich zum Ziel gesetzt hat, mehr Umweltzonen in OpenStreetMap zu erfassen.

Seit 2008 existieren in Deutschland Umweltzonen. Diese wurden den europäischen Richtlinien folgend, eingerichtet, um die Grenzwerte für die Luftqualität einzuhalten. Zwischenzeitlich gibt es deutschlandweit in 48 Städten und Regionen Umweltzonen. Als Information für den Bürger veröffentlichen die Städte auf ihren Webseiten größtenteils Bilder, GIS-Anwendungen und in PDF verpackte Karten, auf denen der Verlauf der jeweiligen Umweltzone eingezeichnet ist. Oft sind diese digitalen Informationen schlecht nutzbar, weil der genaue Verlauf mangels hochauflösender Karte nicht erkennbar ist. Ein praktisches Problem ist zudem, dass sich diese Dateiformate auf einem Smartphone schlecht konsumieren lassen. Generell herrscht bei diesem Thema ein großer Mangel an offenen, maschinenlesbaren Daten.

Aus dieser Situation heraus entstand die Idee für die Android-Anwendung „Umweltzone“, die es seit Ende 2013 kostenfrei im Google PlayStore gibt. Die wenigsten Städte veröffentlichen die Geokoordinaten zum Verlauf der Umweltzone digital. Einige Städte verlangen Geld für die Bereitstellung dieser Informationen. Diese Einstellung verwundert, da der Verlauf der Umweltzone eigentlich jedem Bürger zugänglich sein müsste, was durch die offiziellen Veröffentlichungen oft nicht gegeben ist. Daher stützt sich die Anwendung maßgeblich auf in OpenStreetMap eingetragene Umweltzonen.

Im OpenStreetMap-Wiki findet sich eine Liste der deutschen Umweltzonen. Einen guten Gegenvergleich findet man auf der Seite des Bundesumweltamts und auf umwelt-plakette.de.

Der überwiegende Teil der in OpenStreetMap hinzugefügten Umweltzonen wurde als Umkreis eingezeichnet – einige wenige Städte haben die im Bereich befindlichen Straßen entsprechend gekennzeichnet. Ich hoffe dabei in der Diskussion auf einen Konsens für das erste Modell, da diese Variante auch in der mobilen Anwendung genutzt wird. Es gibt zwar eine Diskussion um die richtigen Tags, am verbreitetsten ist aber type=LEZ.

Über Overpass-Turbo kann man sich einen guten Eindruck über die bisher erfassten Umweltzonen machen. Im OpenStreetMap Forum kann über die Wochenaufgabe diskutiert werden. Ansonsten werde ich so oft wie möglich im IRC-Channel #osm-de auf irc://irc.oftc.net online sein.

Falls ihr auf Twitter über diese Wochenaufgabe berichtet, würde ich mich freuen, wenn ihr den Hashtag #osmwa3536 verwendet.

#osmwa3536 Tweets

Hier nochmal die wichtigsten Links:

• Umweltzonen-Wiki-Seite
• Thread im Forum zu dieser Wochenaufgabe
• Abfrage für Overpass-Turbo
• Seite des Bundesumweltamts
• Umweltzonen auf umwelt-plakette.de
• IRC-Channel #osm-de auf irc://irc.oftc.net

Wie Tobias, könnt auch ihr uns Vorschläge für die Wochenaufgabe zusenden. Wir haben derzeit noch ein paar Ideen auf Halde liegen. Euer Vorschlag wird für uns attraktiver, wenn ihr – wie Tobias – einen fertigen Text samt Overpass-Abfrage beilegt.

In der ersten Juni-Hälfte hat die Overpass API nicht so zuverlässig wie gewohnt gearbeitet. Mittlerweile konnte die Overpass API wieder zum Normalbetrieb zurückkehren. Wenn ich selbst anderswo solche Ausfälle erlebe, möchte ich eine Erklärung haben. Daher im Folgenden ein paar Details zu der Ausfallzeit:

Was ist passiert?

Am letzten Dienstag, 6. Juni, ist die Anzahl der Anfragen von ca. 50.000 – 80.000 pro Tag auf fast 1.000.000 pro Tag angestiegen. Erfreulicherweise hat sich auch die Anzahl unterscheidbarer IP-Adressen von 300 pro Tag auf etwa 6000 erhöht. Allerdings ist der Server mit dieser drastisch angestiegenen Last überfordert – ein Slashdot-Effekt. Fast alle Abfragen wurden mit einer HTML-Seite, dass der Server überlastet ist, beantwortet.

Die neu auflaufenden Abfragen sind alle von der Form xapi?*[amenity=*][bbox=...]. Erfreulicherweise wird eine Kennung des User Agents mitgeschickt, so dass ich die Abfragen der iOS-App „Geomon“ zuordnen kann. Es sieht so aus, als wenn die Timeout-Meldungen keinerlei Effekt auf das Verhalten der App haben.

Unabhängig davon fällt am Freitag aus ungeklärten Gründen die Rambler-Instanz aus: die erste Unregelmäßigkeit ist, dass ein Durchlauf des Compilerwerkzeugs make mit einer nicht reproduzierbaren Fehlermeldung abstürzt. Danach gibt es Konsistenzehler bei der Area-Erzeugung, ebenfalls nicht reproduzierbar. Einige Stunden später gelingt es mir nicht mehr, mich per ssh einzuloggen, und der Webserver zeigt nicht einmal mehr die statische Website. Im Gesamtbild spricht fast alles für einen Hardware-Schaden. Im Nachhinein stellt es sich als ein Problem mit dem Rambler-internen NFS heraus; mein Home-Verzeichnis liegt nicht physisch auf dem gleichen Server wie der Overpass-Server, so dass dieser mein Home-Verzeichnis nicht mehr lesen konnte. Ich frage einen Reboot an, aber der Server bleibt unerreichbar.

Um die Performance für die meisten Anwendungen zu erhalten, auch wenn die Benutzerzahl von Geomon die aller anderen Anwendungen dominiert, habe ich daher zu diesem Zeitpunkt spezifisch die XAPI-Anfragen auf maximal 3 parallele Anfragen gedrosselt, so dass Overpass-QL-basierte Anwendungen weiterhin etwa die gewohnte Leistung erreichen.

Parallel dazu beginne ich für overpass-api.de einen Umzug vom vier Jahre alten Hetzner DS5600 (4 GB RAM, AMD K5600+) auf einen aktuellen Hetzner EX6S (32 GB RAM, Xeon E3-1245). Auf dem neuen Server habe ich diese Grenze auf 10 parallele Anfragen anheben können, so dass jetzt auch 90%-95% der Anfragen im XAPI-Format wieder ausgeführt werden.

Am 14. Juni ist dann das NFS-Problem auf dem Rambler-Server wieder behoben – der zuständige Administrator war nicht im Büro, und die Nachrichten-Weiterleitung hat nicht wie erwartet funktioniert. Jetzt funktioniert auf overpass.osm.rambler.ru wieder alles normal.

Ist overpass-api.de generell überlastet?

Generell muss sich niemand, der weniger als 10.000 Anfragen pro Tag erzeugt, darüber Gedanken machen. Die Leistungsgrenze des alten Servers liegt bei etwa 100.000 Anfragen pro Tag, die des neuen etwa bei 1.000.000 Anfragen pro Tag. Bei Lasttests haben sich auf dem neuen Server bis zu 10.000 Abfragen pro Minute als handhabbar herausgestellt, je nach Größe der Anfragen.

Knapp sind auf dem Server vor allem Festplattenzugriffe, im Englischen, der Server ist „I/O bound“. Die eigentlich gute Performance von Overpass API beruht darauf, Geodaten in Blöcken von 512KB statt einzeln zu lesen. Eine typische Anfrage wird das Lesen von 3-4 Blöcken auslösen, und der Server kann etwa 10 pro Sekunde lesen. Die beobachtete Geschwindigkeit liegt aber deutlich darüber, was dafür spricht, dass sehr viele Blöcke erfreulicherweise statt von der Festplatte aus dem RAM-Cache gelesen werden. Sehen kann man dies am Munin-Diagramm: es werden sogar mehr Daten geschrieben als gelesen.

Nicht knapp ist dagegen die CPU-Zeit. Das Munin-Diagramm zeigt uns, dass die Prozessoren ganz erheblich Zeit für die Area-Aktualisierung verwenden können und zu noch mehr Anteilen unbeschäftigt sind, was der gezeigte, orange bzw. gelbe Nice-Anteil ist.

Die eigentliche Schwierigkeit liegt jedoch darin, dass Anfragen schubweise kommen, zum Teil bis zu 5000 pro Minute. Für statische Webseiten wäre dies nicht viel, für Datenbankabfragen ist es allerdings sehr viel. Während solcher Schübe ist es unter Umständen nicht möglich, alle Abfragen zu bearbeiten, während dies im Normalbetrieb gewährleistet ist.

In der Vergangenheit hat es auch andere problematische Nutzungsmuster gegeben: allen voran ein offenbar auf Seiten des Client abgebrochener Download größerer Teile des Planeten, der vom Server weiterverfolgt, aber vom Client mehrfach erneut versucht worden ist.

Welche Maßnahmen bestehen?

Generell ist Overpass QL von vorneherein für die Ressourcen-Steuerung ausgelegt. Dazu wird für jede Abfrage zunächst der RAM-Bedarf und die Laufzeit geschätzt. Dies kann entweder explizit der Nutzer mit den entsprechenden Direktiven tun, oder der Server nimmt Default-Werte von 180 Sekunden und 512MB RAM an.

Überschreitet eine Anfrage den RAM-Bedarf oder ihre geschätzte Laufzeit, wird sie abgebrochen. Dies stellt sicher, dass große Abfragen von den Nutzern auch als große Anfragen gekennzeichnet werden. Umgekehrt entscheidet der Interpreter vor der Ausführung der Anfrage, ob noch genug Ressourcen für die Ausführung zur Verfügung stehen. Dies stellt sicher, dass zumindest nicht einzelne große Anfragen den Server blockieren können.

Overpass QL ist zudem defensiv entworfen: eine aufwendige Abfrage hat auch einen langen und umständlichen Quelltext, so dass nur sehr selten versehentlich große Anfragen gestellt werden.

Warum ist speziell XAPI problematisch?

Im Gegensatz zu Overpass QL ist XAPI dafür konzipiert, Resourcen-Grenzen vor dem Benutzer zu verbergen. Das führt dann dazu, dass ausgerechnet die einfachsten Abfragen wie „xapi?*[highway]“ viel zu große Ergebnisse sowohl für den Server als auch für den Client liefern.

Tatsächlich ist dieser Konflikt zwischen Konzept und Realität die Haupt-Antriebsfeder gewesen, anstelle von XAPI eine imperative Skriptsprache zu konzipieren.

Welche Maßnahmen bestehen nicht und warum?

Keine Filterung besteht nach IP, User Agent oder ähnlichem.

Scraping von einer einzelnen IP-Adresse in solchem Umfang, dass es den Server blockiert, habe ich noch nicht beobachtet. Auf der anderen Seite gibt es Implementierungen, die für die Overpass-API-Daten als Proxy agieren. Dann sehe ich von vielen Nutzer-IP-Adressen nur eine Proxy-IP-Adresse, was dann fälschlicherweise nach einem Scraper aussieht.

Ein ähnliches Problem stellt sich bei den User Agents: Fast alle Browser, einschließlich einiger Internet-Explorer-Versionen, beginnen den User-Agent mit „Mozilla“. Browser-Mash-Ups sind aber erwünschte Nutzer. Es ist sogar noch schlimmer: würden einzelne Browser als User-Agents blockiert, sieht ein Website-Entwickler nicht reproduzierbare Unterschiede zwischen verschiedenen Browsern oder Versionen, für die man üblicherweise in den Browsern und nicht bei einem Datenlieferanten nach den Ursachen suchen würde.

Wie geht es weiter?

Auch in Zukunft wird der Server auf hohe Last einer populär werdenden Anwendung nur mit Überlast-Meldungen reagieren können. Es gibt nach dem Umzug durchaus erhebliche Reserven für den Normalbetrieb, aber mehr als eine Zehnerpotenz Lastreserve lässt sich nicht sinnvoll vorhalten.

Anders ausgedrückt: bei einem öffentlichen, kostenlosen Server sollte niemand erwarten, dass der Server jederzeit problemlos funktioniert, eben weil andere Nutzer den Service überlasten könnten. Wer Zuverlässigkeit garantieren möchte, sollte eine eigene Instanz betreiben – dafür ist die Software Open Source und leicht zu installieren.

Für mich selbst habe ich den Anspruch, Störungen in weniger als 24 Stunden zu beheben, so dass auch weiterhin Projekte ohne Geld für einen Server trotzdem Zugriff auf ein leistungsfähiges Backend für OSM-Daten bekommen können.

In diesem Sinne möchte ich mit der guten Meldung schließen, dass dank dem Lastproblem die Software durch neue Optimierungen jetzt zum Teil erheblich schneller antworten kann. Das „Geomon“-Team ist mittlerweile auf einen eigenen Server umgezogen, so dass nun größere Server-Power mit effizienterer Software für die gleichen Nutzerzahlen auf Overpass API zur Verfügung steht.