eBay Architecture

Quelle: http://highscalability.com/ebay-architecture Dienstag 10. Juli 2007
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

Wer hat sich nicht schon mal gewundert, wie eBay das so macht? Eine der größten, meistgeladenen Webseiten in der Welt zu betreiben kann nicht einfach sein. Und der Untertitel einer Präsentation verrät, dass die Erschaffung eines solchen Monsters wahre Ingenieurskunst verlangt: "Finde die Balance zwischen Seitenstabilität, Erneuerungsrate, Geschwindigkeit und Kosten".
Du kannst eBay vielleicht nicht nachmachen und dein System so skalieren, wie eBay seins skaliert, aber aus den Aufgaben und die möglichen Lösungen kann man lernen.

Seite: http://www.ebay.com

Informationsquellen

• Die eBay-Architektur - Finde die Balance zwischen Seitenstabilität, Erneuerungsrate, Geschwindigkeit und Kosten
• Podcast: eBays Transaktionen werden massiv skaliert
• Dan Pritchett über Architektur in einem eBay-Interview von InfoQ

Plattform

• Java
• Oracle
• Websphere, Servlets
• Horizontales Skalieren
• Sharding
• Eine Mischung aus Windows und Linux

Was steckt drin?

Diese Informationen wurden aus Johannes Ernsts Blog übernommen.

Die Fakten

• Pro Tag werden 26 Milliarden SQL-Abfragen durchgeführt und es werden 100 Millionen Artikel zum Verkauf vorgehalten
• 212 Millionen registrierte Benutzer, 1 Milliarde Fotos
• 1 Milliarde Seitenaufrufe pro Tag, 105 Millionen Produktdaten, 2 Petabyte Daten, durchschnittlich 100 Millionen API-Aufrufe pro Tag
• etwa 35facher Anstieg an Seitenaufrufen, versandten E-Mails und Bandbreite von Juni 1999 bis zum dritten Quartal 2006
• 99,94% Verfügbarkeit, gemessen als "alle Teile der Seite - verfügbar für alle" gegenüber mindestens eine Teil der Seite nicht verfügbar für einige Benutzer
• Die Datenbank ist virtualisiert und spannt sich über 600 Produktionsinstanzen in mehr als 100 Serverclustern
• 15.000 Anwednungsserver, alle J2EE. Ungefähr 100 Funktionsgruppen alias "Apps". Die Idee eines "Pools": "alle Maschinen, die mit Verkauf zu tun haben"...

Die Architektur

• Alles wird unter der Diktat der Frage geplant: "Was, wenn sich die Last verzehnfacht?". Es wird nur horizontal skaliert, nicht vertikal; viele parallele Boxen.
• Die Architektur ist strikt in zwei Schichten getrennt: Datenschicht (data tier), Anwendungsschicht (application tier), Suche, Aufgaben
• Leverages MSXML-Framework für die Präsentationsschicht (presentation layer) (auch in Java)
• Oracles Datenbank, WebSphere Java (immer noch 1.3.1)
• Getrennte Datenbanken nach primärem Zugangspfad, Modulo oder Schlüssel.
• Jede Datenbank umfasst mindestens drei Online-Datenbanken. Verteilt über acht Datenzentren.
• Einige Datenbankkopien laufen nach 15 Minuten, andere nach 4 Stunden
• Es werden keine gespeicherten Prozeduren (stored procedures) verwendet. Es gibt nur einige wenige Trigger.
• CPU-intensive Arbeit wird aus der Datenbankschicht in die Anwendungsschicht verlagert: referenzielle Integrität, Joins und Sortierungen werden in der Anwendungsschicht erledigt! Begründung: Anwendungsserver sind billig, Datenbanken sind der Flaschenhals.
• Keine clientseitigen Transaktionen, keine verteilten Transaktionen.
• J2EE: es werden Servlets, JDBC und Verbindungspools (mit Rewrite) verwendet. Nicht viel mehr.
• Keine Zustandsinformationen in der Anwendungsschicht. Flüchtige Zustände (transient state) werden in Cookies oder in einer Schmierzetteldatenbank verwaltet.
• Suche (2002): Die Neuindizierung läuft neun Stunden lang auf der größten verfügbaren Sunkiste - nichts wird aufbewahrt.
• Ein durchschnittlicher Produktdatensatz ändert seine Suchdatenfünfmal bevor er verkauft wird (zum Beispiel der Preis), drum sind Echtzeitsuchergebnisse extrem wichtig.
• "Voyager": eine Echtzeiteingabeinfrastruktur von eBay. Verwendet verlässliche Mehrfachaussendung (reliable multicast) von der Hauptdatenbank zu den Suchknoten, einen im Speicher gehaltenen Suchindex, horizontale Zerlegung, N slices, Lastverteilung über M Instanzen und speichert Suchanfragen zwischen.

Gelernte Lektionen

• Skaliere in die Breite, nicht in die Höhe
• Horizontales Skalieren in jeder Schicht
• Funktionale Zerlegung
• Bevorzuge asynchrone Integration
• Vermindere die Kopplung von Verfügbarkeiten
• Verbessere die Skalierungsmöglichkeiten
• Virtualisiere Komponenten
• Vermindere physische Abhängigkeiten
• Verbessere die Deployment-Flexibilität
• Konstruiere Fehlertolerant
• Automatische Fehlererkennung und -meldung
• "Hinkender" Betrieb ("Limp mode") von Geschäftsfeatures
• Verschiebe Arbeit aus der Datenbank in die Anwendung, weil die Datenbank der Flaschenhals ist. eBay treibt das auf die Spitze. Wir kennen das aus anderen Architekturen, das Zwischenspeicherung und Dateisysteme verwendet werden, aber eBay erledigt sogar eine Menge der traditionellen Datenbankaufgaben in den Anwendungen (zum Beispiel Joins).
• Verwende was Du willst und schmeiß weg, was Du nicht brauchst. eBay fühlt sich nicht genötigt, den gesamten aufgeblasenen J2EE-Software-Stapel zu verwenden. eBay mochte Java und Servlets, also werden sie verwendet. Du musst kein gesamtes Framework kaufen. Verwende nur, was Du brauchst.
• Scheue nicht Lösungen zu bauen, die mit deinen Ansprüchen wachsen. Jede Lösung von der Stange wird irgendwann nicht mehr passen. Den Rest musst Du allein machen.
• Ausführungskontrolle wird wenn Du wächst ein größerer und größerer Teil der Skalierungsfähigkeit. Wie spielst Du Änderungen ein, wie konfigurierst und überwachst Du Tausende von Maschinen in einem laufenden System?
• Architekturen wachsen mit. Du musst in der Lage sein, dein neues System zu ändern, zu verbessern und zu entwickeln, während Du deine bestehende Seite am Laufen hälst. Das ist die Hauptherausforderung jeder wachsenden Webseite.
• Es sit ein Fehler, sich vom Start weg um Skalierungsfähigkeit Sorgen zu machen. Quäle dich nicht mit lähmenden Untersuchungen und mit Sorgen über Traffic, der vielleicht nie kommt.
• Es ist auch ein Fehler, sich niemals um Skalierungsfähigkeit zu sorgen. Du musst eine Organisation aufbauen, die in der Lage ist, mit einer sich weiterentwickelnden Architektur umzugehen. Mach dir klar, dass Du niemals fertig sein wirst. Dein System wird sich immer weiterentwickeln und sich ändern. Baue diese Erwartungen und Möglichkeiten von Anfang an in dein Geschäft ein. Lass die Leute und die Organisation nicht unangetastet, während deine Seite den Bach runter geht. Viele Leute glauben, das System müsste vom Start weg perfekt sein. So läuft das aber nicht. Ein gutes System wird mit der Zeit weiterentwickelt, indem man auf tatsächliche Aufgaben und Zwänge reagiert. Erwarte die Veränderung und pass dich den Veränderungen an.