Wikimedia Architecture

Original: http://highscalability.com/wikimedia-architecture Mittwoch, 22. August 2007 23:56
Autor: Todd Hoff
Übersetzung: Sebastian Wallroth

Wikimedia ist die Plattform, auf der Wikipedia, Wiktionary und viele Wikizwerge aufsetzen. Dieses Dokument ist eine exzellente Hilfe, wenn man wissen will, wie man zu Höhen gigantischer Webseiten skalieren will. Es ist voll von Details und innovativer Ideen, die von einigen der meist benutzten Webseiten im Internet bestätigt wurden.

Webseite: http://www.wikimedia.org

Informationsquellen

• Die Architektur von Wikimedia (PDF, englisch)
• Die von Wikimedia eingesetzten Server
• "Scale-Out vs. Scale-Up - Skalierung durch Vermehrung statt Verbesserung", Artikel aus dem Blog "from Oracle to MySQL"

Plattform

• Apache
• Linux
• MySQL
• PHP
• Squid
• LVS
• Lucene für die Suche
• Memcached für Distributed Object Cache
• Lighttpd Image Server

Die Fakten

• 8.000.000 Artikel in mehr als 100 nach Sprachen aufgeteilten Projekten (Englisch, Französisch, Schwedisch, ...)
• Platz 10 unter den Seiten mit den meisten Zugriffe (Quelle: Alexa)
• Exponentielles Wachstum: Verdopplung alle 4 bis 6 Monate in Bezug auf Besucher / Zugriffe /Server
• Bis zu 30.000 HTTP-Zugriffe/Sekunde
• 3 GBit/Sekunde Datenübertragungsvolumen
• 3 Datenzentren: Tampa, Amsterdam, Seoul
• 350 Server; von 1 x P4 bis 2 x Xeon Quadcore; 0,5 bis 16 GB RAM
• gewartet von etwa 6 Personen
• 3 Cluster auf 3 Kontinenten

Die Architektur

• Geografische Lastverteilung, die den Internetbenutzer auf Grundlage dessen IP zum nächstgelegenen Servercluster weiterleitet. Statische Zuordnung der IP-Adressen zu Ländern und damit zu den Clustern.
• HTTP Reverse-Proxy-Caching mit Hilfe von Squid, gruppiert nach Text für den Wikiinhalt und Medien für Bilder und große unveränderliche Dateien
• derzeit 55 Squid-Server, plus 20, die auf ihren Einsatz warten
• 1.000 HTTP-Anfragen/Sekunde pro Server; bis zu 2.500 zu Spitzenzeiten
• rund 100 bis 250 MBit/Sekunde pro Server
• rund 40.000 bis 32.000 offene Verbindungen pro Server
• bis zu 40 GB Festplattencache pro Squid-Server
• bis zu 4 Festplatten pro Server (1U-Rack-Server)
• 8 GB RAM; die Hälfte davon wird von Squid belegt
• Zugriffsraten: 85% Text, 98% Medien, seit CARP verwendet wird
• PowerDNS bietet die geografische Verteilung
• In den Haupt- und den regionalen Datenzentren entstehen Text- und Medien-Cluster unter Verwendung von LVS, CARP Squid und Cache Squid. IM Hauptdatenzentrum steht der Medienspeicher.
• Im sicher zu stellen, dass die letzte Version aller Seiten ausgeliefert wird, werden Annullierungsanfragen an alle Squid-Caches geschickt.
• Eine zentral verwaltete und synchronisierte Softwareinstallation für Hunderte Wikis.
• MediaWiki skaliert gut mit mehreren CPUs, deswegen werden Duale Quad-Core-Server angeschafft (8 CPUs pro Box)
• die Hardware wird sich geteilt; zusätzlich gibt es externen Speicherplatz und Memcached-Aufgaben
• Memcached wird verwendet, um Bildmetadaten, Parserdaten, Unterschiede, Benutzer, Sessions und Textversionen zu cachen. Metadaten, wie zum Beispiel Artikelversionsgeschichten, Artikelbeziehungen (Links, Kategorien, etc.), Benutzeraccounts und Einstellungen werden in der zentralen Datenbank gespeichert.
• Die aktuelle Textversion wird in Blobs im externem Speicher gespeichert.
• Unveränderliche (hochgeladene) Dateien, wie zum Beispiel Bilder, werden getrennt von den anderen Daten auf einem Bilderserver gespeichert - Metadaten (Größe, Typ, etc.) wird in der zentralen Datenbank und Objektcaches gecached.
• Jedes Wiki hat seine eigene Datenbank (keinen eigenen Server!).
• Ein Master, viele kopierte Slaves.
• Die Lesezugriffslast wird zwischen den Slaves verteilt, Schreibzugriffe gehen direkt an den Master.
• Der Master wird nur für Lesezugriffe verwendet, wenn die Slaves nicht auf dem aktuellsten Stand (lagged) sind.
• Externer Speicher
• Der Artikeltext wird in von den anderen Daten getrennten Speicherclustern gespeichert, einfach angehängter Blob-Speicher. Das spart Speicher auf den teuren und unter Last stehenden Zentraldatenbanken für sowieso weithin ungenutzte Daten.
• Erlaubt die Verwendung magerer Ressourcen auf den Applikationsservern (2 x 250 - 500 GB pro Server)
• Derzeit werden kopierte Cluster dreier MySQL-Hosts verwendet; das kann sic inder Zukunft zu Gunsten besserer Verwaltbarkeit ändern

Gelernte Lektionen

• Konzentriere dich auf die Architektur; nicht so sehr auf Verwaltung und nichttechnisches Angelegenheiten.
• Manchmal ist Caching aufwändiger als Neuberechnung oder ein Blick auf die Datenquelle ... Profiling (Analyse des Laufzeitverhaltens von Software)!
• Vermeide aufwändige Algorithmen, Datenbankabfragen, etc.
• Cache jedes Ergebnis, das aufwändig zu berechnen ist und nur zeitweise Gültigkeit hat.
• Konzentriere dich auf die heißen Stellen im Code (Profiling!).
• Skaliere, indem Du trennst:
• Lese- von Schreibzugriffen (Master/Slave)
• Aufwändige Operationen von einfachen und häufigen Operationen (query groups)
• Große, häufig besuchte Wikis von kleineren Wikis
• Verbessere das Caching: temporäre und räumliche Anordnung von Verweisen (memory locality) und Verminderung der Datensatzgröße pro Server
• Text wird komprimiert und nur die Unterschiede zwischen den Artikelversionen werden gespeichert.
• Einfach scheinende Bibliotheksaufrufe, wie die Verwendung von stat, um die Existenz einer Datei zu überprüfen, können zu lange dauern, wenn sie geladen werden.
• Begrenze die Zugriffszeit auf die Festplatten. Je mehr Spindeln, desto besser!
• Skalierung durch Vermehrung mit normaler Hardware bedeutet nicht, dass man unbedingt Billighardware nehmen muss. Wikipedias Datenbankserver sind heute 16 GB Dual- oder Quad-Core-Kisten mit 6 15.000 RPM SCSI-Festplatten in einer RAID 0-Konfiguration. Es hat sich einfach ergeben, dass dies die optimale Umgebung (Sweet Spot) für Wikipedias Working Set und das Lastverteilungssystem ist. Wikipedia würde kleinere und billigere Systeme verwenden, wenn es Sinn ergeben würde, aber 16 GB ist passend für die Größe des Working Sets und das führt den Rest der Spezifikation dazu, ein System mit so viel RAM zu verlangen. Ganz ähnlich dazu sind die Webserver derzeit 8 Core-Kisten, weil sich heraus stellte, dass das so mit der Lastverteilung gut funktioniert und einen guten PHP-Durchsatz mit einer verhältnismäßig einfachen Lastverteilung ergibt.
• Es ist viel Arbeit, durch Vermehrung zu Skalieren, und sogar noch mehr, wenn man das System nicht selbst entwirft. Wikipedias MediaWiki wurde ursprünglich für einen einzelnen Masterdatenbankserver geschrieben. Dann wurde die Unterstützung von Slaves hinzugefügt. Dann wurde die Unterteilung nach Sprache/Projekt hinzugefügt. Die Entwürfe von damals haben den Test gut bestanden, obgleich viel Verbesserungsarbeit an neu auftauchenden Engstellen nötig wurde.
• Jeder, der seine Datenbankarchitektur so entwerfen möchte, dass sie es ihm erlaubt, ohne großen Aufwand von einer Stufe mit nur einer Kiste auf die Stufe der Top 10 oder Top 100 der Webseiten des Internet zu wachsen, sollte damit anfangen, leicht veraltete Daten von Kopien-Slaves verwalten zu lassen, sollte wissen, wie man die Last der Lesezugriffe zwischen den Slaves verteilt und wann immer möglich so entwerfen, dass Datenbrocken (Bündel von Benutzern, Accounts, was auch immer) auf verschiedenen Serven landen können. Man kann das von Anfang an mittels Virtualisierung tun und die Architektur testen, solange man noch klein ist. Es ist VIEL einfacher, als wenn man es erst prüft, wenn sich die Last alle paar Monate verdoppelt.