ELITE NETZWERK BAYERN

English  Sprachen Icon  |  Gebärdensprache  |  Leichte Sprache  |  Kontakt


Forschungsarbeit


Wie viele Server braucht man, um Wikipedia zu betreiben?

von Tobias Rosenberger, Pascal Schliski, Maximilian E. Schüle, Thomas Hutzelmann

Ein einziger Server reicht aus! Diesen Gedanken hatten vier Studenten des Elitestudiengangs Software-Engineering, als es im Rahmen des „Pushing the Limits“-Seminars darum ging, eine selbst gewählte Grenze des „aktuell Machbaren“ zu berühren oder zu überschreiten.

Mit rund 50.000 Anfragen pro Sekunde liegt Wikipedia laut Alexa-Page-Rank auf Platz 6 der meistbesuchten Webseiten im Internet. Trotzdem setzt Wikimedia, die Organisation hinter dem Onlinelexikon, auf einen sehr klassischen Aufbau bei ihrer Serverlandschaft. Im Wesentlichen erfüllen alle Server je eine von drei Aufgaben: Auf Datenbankservern liegen alle Lexikon-Artikel auf großen Festplatten. Webserver nehmen die Anfragen der Besucher entgegen und leiten diese an die Datenbank weiter. Um sich möglichst viele der langwierigen Datenbankabfragen zu sparen, gibt es zudem noch Cacheserver, die häufige Anfragen zwischenspeichern, so dass zum Beispiel ein mehrfacher Aufruf des gleichen Artikels in sehr kurzer Zeit nur eine Anfrage an die Datenbank auslöst.

Jeder Server erfüllt also eine kleine Teilaufgabe, die für die Antwort an einen Besucher benötigt wird. Dies bietet den Vorteil, dass man relativ einfach auf große Aufrufzahlen reagieren kann. Wenn ein Server der Last nicht mehr gewachsen ist, wird ein zweiter, identischer Rechner daneben gestellt und die Anfragen abwechselnd von einem der beiden beantwortet. Wikimedia betreibt auf diese Art insgesamt über 300 Server, die sich die Arbeitslast teilen. Allerdings werden bei diesem Ansatz alle benötigten Daten dutzendfach kopiert und redundant an verschiedenen Orten gespeichert. Außerdem legen die Daten einer Anfrage ziemlich weite und vor allem auch langsame Wege zurück, bis sie zu einer vollständigen Antwort zusammengestellt werden.

Diese klassische Webscale-Infrastruktur haben die Studenten in ihrem Projekt durch einen neuen monolithischen Ansatz ersetzt, bei dem nur ein einzelner, dafür sehr leistungsfähiger Server zum Einsatz kommt. Bei Rechnern mit moderner Hardware sind heute bereits Systeme mit über einem Terabyte Arbeitsspeicher keine Seltenheit mehr. Damit steht dort genug Platz für die inzwischen fast 50 Millionen Lexikonartikel zur Verfügung und man könnte auf langsamere Festplatten theoretisch komplett verzichten. Genau diesen Vorteil haben die Studenten sich zu Nutze gemacht.

Ihr monolithisches System basiert auf HyPer, der Hauptspeicherdatenbank, die am Lehrstuhl für Datenbanksysteme der TUM unter Federführung von Prof. Neumann und Prof. Kemper enwickelt wird. Der Geschwindigkeitsvorteil, der sich dadurch ergibt, ist enorm. Statt wie bisher weniger Millisekunden benötigt eine einzelne Anfrage im Hauptspeicher nur Nanosekunden. Zum Vergleich: Anstatt seine Unterlagen aus einem Nebenraum zu holen, unternimmt eine klassische Datenbank jedes Mal einen Flug zum Mond. Dank dieser Geschwindigkeit können nicht nur die Klone des Datenbankservers eingespart werden, sondern auch das Zwischenspeichern der Antworten auf eigenen Cacheservern bringt kaum noch Vorteile mit sich. Das System der Studenten besteht daher nur noch aus einem zentralen Datenbankserver, der von mehreren Webservern genutzt wird.

In der Theorie klingt das alles vielversprechend, aber die Studenten haben ausprobiert, ob dieser Ansatz wirklich halten kann, was er verspricht. Dafür müssen zwei Aufgaben gelöst werden: Zum einen benötigt man eine eigene Installation der Wikipedia und zum anderen etwas, das die Aufrufe der Besucher möglichst realistisch simulieren kann. Bei beiden Punkten haben die Studenten von der Offenheit der Wikipedia profitiert. So stellt Wikimedia nicht nur eine Kopie ihrer Enzyklopädie zum Download zur Verfügung, sondern es gibt auch eine Zugriffsstatistik, welche die Aufrufe jedes Artikels in Intervallen von je einer Stunde wiedergibt.

Mit Hilfe dieser Daten konnten die Studenten ihre eigene Wikipedia in HyPer übertragen. Da das Einspielen der Kopien der Artikel so bereits mehrere Tage Rechenzeit benötigte, beschränkten sie sich dabei nur auf die englischsprachige Wikipedia. Auch wenn Bilder und Videos nicht in der Datenbank gespeichert waren, drohte der Platz im Arbeitsspeicher etwas knapp zu werden, denn zusätzlich zur aktuellen Version mussten dort auch alle früheren Versionen eines Artikels abgespeichert werden. Durch ein alternatives Speicherformat, bei dem nichts außer den Änderungen zwischen den Versionen gespeichert wurde, konnten die Studenten gut 80 % des benötigten Speichers des Archivs einsparen. Mit dieser Änderung reichte der Arbeitsspeicher ihres Servers aus und die Studenten hatten ihre eigene Umgebung, in der sie nun beliebige Testläufe und Messungen durchführen konnten.

Nun fehlte ein Lastengenerator, mit dem die tatsächlichen Aufrufe auf Wikipedia möglichst realistisch nachgestellt werden konnten. Die Studenten schrieben dafür ein Programm, das die öffentlich verfügbaren Webseitenstatistiken der Wikipediawebseite einlas und entsprechende Anfragen an den Datenbankserver stellte. Dabei wurden sowohl lesende als auch schreibende Zugriffe entsprechend der realen Zugriffsmuster durchgeführt. Zwar war nur ungefähr jeder tausendste Aufruf eine Änderung an einem Artikel, aber trotzdem waren gerade diese Zugriffe auf das Datenbanksystem besonders aufwendig für den Server. Am Ende hatten die Studenten damit ein Werkzeug zur Hand, mit dem sie nicht nur die Aufrufe nachspielen konnten, sondern mit einem Schieberegler die Last auf den Server solange erhöhen konnten, bis dieser an seiner Belastungsgrenze zusammenbrach.

Nach einigen Testläufen stand fest: Ein einzelner Rechner war tatsächlich den Aufrufen auf alle Artikel der Wikipedia gewachsen! Mit 1/60 seiner gesamten Rechenleistung konnte der Server bis zu 130 % der Last der englischsprachigen Wikipedia bewältigen. Insgesamt hätten die Kapazitäten also wahrscheinlich auch für die anderen Sprachen ausgereicht. Die Testergebnisse wiesen außerdem darauf hin, dass die Rechenkapazität des Servers nicht der begrenzende Faktor gewesen wäre. Vielmehr war nun die Verbindung zu den Webservern das Problem, da der verwendete Datenbankserver keine Anschlussmöglichkeit hatte, der über die notwendige Kapazität verfügte, die auftretenden Datenmengen der gesamten Wikipedia noch schnell genug weiterzuleiten.

Bei aller Euphorie sollte man nicht übersehen, dass reine Geschwindigkeit nicht der einzige Punkt ist, nach dem eine Architektur bewertet werden sollte. Ein Rechner alleine ist beispielsweise wesentlich anfälliger gegen eventuelle Hardwareausfälle. Um die notwendige Ausfallsicherheit zu gewährleisten müsste man also mindestens einen zweiten, identischen Server dauerhaft parallel betreiben. Preislich gesehen könnte man statt dutzenden herkömmlichen Servern, wie sie bei Wikimedia zum Einsatz kommen, auch einen einzelnen High-End-Server kaufen, aber wie sieht es dann mit Stromverbrauch, Kühlung und Wartungskosten aus? Auf der anderen Seite bedeuten weniger Server weniger Aufwand und damit Kosten für die Administration.

veröffentlicht am