Montag, 29. Oktober 2007

Ist Sharding dasselbe wie Partitionierung und Föderation?

Original: http://www.royans.net/arch/2007/09/09/sharding-different-from-partitioning-and-federation/ 9. September 2007 12:34
Autor: Royans Tharakan
Übersetzung: Sebastian Wallroth

Dieses Wort "Sharding"... ich höre es immer öfter. Es geht um wie ein Lauffeuer. Theo Schlossnagle, der Autor von "Skalierbare Internetarchitekturen", vertritt die Ansicht, dass ein föderiertes Informationssystem ein Form von Partitionierung und dass Sharding wiederum nichts anderes als eine Form von Partitionierung und Föderation ist. Schlossnagle meint, dass Sharding bereits seit sehr langer Zeit angewandt wird.

Ich bin weder beruflich noch privat Datenbankadministrator. Um also die Unterschiede zu verstehen, habe ich ein bisschen geforscht und ein paar interessante Artikel gefunden.

Das erste Mal hörte ich von "Sharding" im Blog "mySQL DBA" in einem Artikel über einen unorthodoxen Datenbankentwurf (Teil I und Teil II). Hier ist das exakte Zitat:
Teilt man die Benutzerdaten so auf, dass Benutzer A auf dem einen Server
existiert, während Benutzer B auf einem anderen Server existiert, so hält jeder
Server in diesem föderierten Modell einen Splitter (shard) der Daten vor.
Vor ein paar Monaten griff Highscalability.com das Thema Sharding auf und ließ es so aussehen (möglicherweise unabsichtlich) als ob Sharding eigentlich etwas anderes ist als Föderation und Partionierung. Todds Artikel weist darauf hin, dass Flickr Sharding verwendet. Die Suche nach Flickrs Architektur führte mich zu Colin Charles Artikel über das föderierte Informationssystem bei Flickr: Eine Führung durch die Architektur von Flickr, in der er Shards als eine Komponente des föderierten Schlüssels erwähnt. Auch er jedoch nennt Sharding nichts Neues. Zitat:
Schlüsselkomponenten eines föderierten Informationssystems:
  • Shards: Meine Daten werden in meinem Shard gespeichert, aber die Aufzeichnung über eine ausgeführte Tätigkeit steht in deinem Shard. Beispiel: Man macht einen Kommentar in jemandes anderen Blog.
  • Global Ring: Das ist wie DNS, Du musst wissen, wo Du hin musst und wer kontrolliert, wohin Du gehst. Bei jedem Seitenaufruf wird im selben Moment berechnet, wo deine Daten sind.
  • PHP-Logik, um die Shards zu verbinden und die Daten konsistent zu halten (10 Zeilen Code - mit Kommentaren!)

Ausgehend von den Diskussionen in diesem und anderen Blogs scheinen "Shards" eher eine Terminologie zu sein, um Datenfragmente zu beschreiben, die über mehrere Datenbanken hinweg föderiert sind, als eine Architektur an sich. Ich denke, Theo Schlossnagles Argument ist triftig. Wenn jemand anderer Meinung ist, dann würde ich gern davon hören. Eine klarere Definition von Sharding im Unterschied zu Föderation würde ebenfalls sehr hilfreich sein.

Weitere Referenzen zum Thema Shards/Sharding

Was ist Skalierbarkeit?

Original: http://www.royans.net/arch/2007/09/22/what-is-scalability/ 22. September 2007 18:14
Autor: Royans Tharakan
Übersetzung: Sebastian Wallroth

Gefragt, was sie denn mit Skalierbarkeit meinen, sprechen die Leute über Verbesserung der Leistung, Einführung von Hochverfügbarkeit oder sogar über spezielle Technologien oder Protokolle. Tja, Skalierbarkeit ist nichts davon. Versteh' mich nicht falsch. Man muss schon alles über Geschwindigkeit, Leistung, Hochverfügbarkeitstechnologie, Anwendungsplattformen, Netzwerk, etc. wissen. Aber das ist nicht die Definition von Skalierbarkeit.

Einfach ausgedrückt bezeichnet Skalierbarkeit die Möglichkeit, dein bisheriges Geschäft in einem größeren Rahmen zu betreiben. Eine Webanwendung zu skalieren bedeutet, mehr Leuten zu ermöglichen, die Anwendung zu benutzen. Wenn Du nicht erklären kannst, wie Du die Leistung verbesserst, wenn Du mehr Rechner einbindest, dann ist das okay. Und so lange Du skalieren kannst, um eine größer werdende Anzahl von Benutzern zu bedienen, ist es auch okay, manche Dinge nicht zu wissen. Alle anderen lesen bitte weiter.

Derzeit werden zwei Hauptarten der Webseitenskalierung angewandt.

  • "Vertikale Skalierung" - Das Hinzufügen von Ressourcen innerhalb einer logischen Einheit, um die Kapazität zu erhöhen. Ein Beispiel könnte das Hinzufügen von CPUs zu einem existierenden Server sein oder die Erweiterung des Speicherplatzes durch das Hinzufügen von Festplatten zu einer existierenden RAID/SAN-Installation.

  • "Horizontale Skalierung" - Das Hinzufügen mehrere logischer Ressourcen-Einheiten, die dazu gebracht werden, wie eine einzige Einheit zu arbeiten. Die meisten Cluster-Lösungen, verteilten Dateisysteme und Lastverteiler dienen der horizontalen Skalierung.
Alle Komponenten, seien es Prozessoren, Server, Speicherlaufwerke oder Lastverteiler, haben in irgend einer Form einen Verwaltungsüberbau. Wenn Du den skalieren willst, musst Du herausfinden, welcher Anteil der Ressource tatsächlich verwendbar ist. Das Ergebnis wird "Skalierbarkeitsfaktor" genannt. Wenn Du jedesmal 5% Prozessorleistung verlierst, wenn Du deinem System eine weitere CPU hinzufügst, dann beträgt dein Skalierbarkeitsfaktor 0,95. Ein Skalierbarkeitsfaktor von 0,9 bedeutet, dass Du nur 90% deiner Ressourcen verwenden können wirst.

Skalierbarkeit kann basierend auf dem Skalierbarkeitsfaktor weiter unterteilt werden.

  • Wenn der Skalierbarkeitsfaktor beim Skalieren konstant bleibt, nennt man das "lineare Skalierbarkeit".
  • Es kann aber sein, das manche Komponenten nicht so gut skalieren wie andere. Ein Skalierbarkeitsfaktor unter 1,0 wird "sub-lineare Skalierbarkeit" genannt.
  • Obgleich selten, ist es möglich eine bessere Leistung (einen besseren Skalierbarkeitfaktor) zu erhalten, indem man einfach mehr Komponenten hinzufügt (I/O zwischen Festplattenspindeln in einem RAID wird besser, wenn man mehr Spindeln hinzufügt). Das nennt man "supra-lineare Skalierbarkeit".
  • Wenn die Anwendung nicht auf Skalierbarkeit ausgelegt wurde, ist es möglich, dass das System sogar schlechter wird, wenn man es skaliert. Das nennt man "negative Skalierbarkeit".
Wenn Du dringend auf Skalierbarkeit angewiesen bist, dann ist vertikale Skalierung möglicherweise der einfachere Weg (vorausgesetzt, dass dein Kontostand dir das erlaubt). In den meisten Fällen kannst Du, ohne eine Zeile Code zu ändern, deine Anwendung auf einem superteuren 64-CPU-Server von Sun oder HP mit Speicher von EMC, Hitachi oder Netapp installieren und alles wird toll sein. Zu dumm, dass vertikales Skalieren immer teurer wird, je weiter Du es treibst.

Horizontale Skalierung hingegen nötigt dich nicht, immer teurere Server zu kaufen. Sie ist auf Skalierung mit normalen Speicher- und Serverlösungen ausgelegt. Aber horizontale Skalierung ist nicht automatisch billiger. Die Anwendung muss von Grund auf so konzipiert werden, dass einzelne Anwendungen auf mehreren Rechnern laufen können. Die zwei interessantesten Probleme, die die meisten Anwendungen in der Welt der horizontalen Skalierung fürchten müssen sind "Split Brain" und "Hardwareabsturz".

Während unendliche horizontale Skalierbarkeit schwierig zu erreichen ist, ist unendliche vertikale Skalierbarkeit unmöglich. Wenn Du Kapazitäten für eine vorher festgelegte Anzahl von Benutzern aufbaust, kann es weise sein, vertikal zu skalieren. Wenn Du aber eine Webanwendung baust, die von Millionen genutzt werden könnte, dann könnte die Entscheidung für vertikale Skalierung ein teurer Fehler sein.

Aber bei Skalierbarkeit geht es nicht nur um CPU (Rechenleistung). Für eine erfolgreich skalierbare Webanwendung müssen alle Schichten in gleichem Maße skalieren. Das schließt die Speicherschicht (geclusterte Dateisysteme, S3, etc.), die Datenbankschicht (Partitionierung, Federation), die Anwendungsschicht (Memcached, Scaleout, Terracotta, Tomcat Clustering, etc.), die Webschicht, den Lastverteiler, die Firewall und alle anderen ein. Wenn Du zum Beispiel nicht mehrere Lastverteiler einsetzen kannst um deine zukünftige Zugriffslast zu bewältigen, dann ist es wirklich egal, wie viel Geld und Aufwand Du in die horizontale Skalierbarkeit deiner Webschicht gesteckt hast. Deine Zugriffslast wird darauf beschränkt sein, was dein Lastverteiler stemmen kann.

Die Wahl der richtigen Art von Skalierbarkeit hängt davon ab, wie viel Du skalieren und wie viel Du ausgeben willst. Wenn jemand behauptet, es gäbe eine Lösung, die alle Bedürfnisse befriedigt - dann glaube ihm nicht. Und wenn jemand auf der nächsten Party eine Diskussion über "Skalierbarkeit" beginnt, dann frage ihn bitte zuerst, was er denn mit Skalierbarkeit meint.

Referenzen


  1. Cost and Scalability in Vertical and Horizontal Architectures, Implications for Database and Application Layer Deployments, Technical White Paper, Tom Atwood (Sun Microsystems), September 2004 (PDF, englisch)
  2. My Linear Scalability is bigger than yours! Posted at 07:30AM Dec 20, 2006 by Cameron Purdy on /dev/null

Sonntag, 28. Oktober 2007

Scale-Out vs. Scale-Up - Skalierung durch Vermehrung statt Verbesserung

Original: http://oracle2mysql.wordpress.com/2007/08/22/12/ Mittwoch, 22. August 2007 19:26
Autor: Ben Krug
Übersetzung: Sebastian Wallroth

Scale-Up versus Scale-Out - Worum geht's?

Grundsätzlich geht es um die Skalierung, das heißt die Verbesserung oder Vergrößerung eines Serversystems um zum Beispiel eine größere Datenmenge oder mehr Zugriffe verarbeiten zu können oder die vorhandenen Daten oder Zugriffe schneller zu bearbeiten. "Scale-Up" und "Scale-Out" sind neue geschaffene Wörter, die sich an den englischen Wörtern "build up", "aufbauen; das Vorhandene verbessern" und "build out", "ausbauen; das Vorhandene erweitern" orientieren.
"Scale-up" oder "Scaling up" ("vertikale Skalierung") bedeutet, Server aufzurüsten oder einen größeren Server einzusetzen, also eine qualitative Veränderung.
"Scale-out" oder "Scaling out" ("horizontale Skalierung") bedeutet, neue Server hinzuzufügen, also eine quantitative Änderung.

Oracle wirbt für beide Methoden. Man soll RAC auf großen Servern oder "Blades" oder "Grids" einsetzen.

MySQL wirbt im Allgemeinen für Scale-Out und die meisten der großen Seiten, die MySQL verwenden setzen auf Scale-Out. Meiner Erfahrung nach und in Einklang mit Jay Pipes exzellentem Blog-Artikel zu diesem Thema ist das teilweise so, weil MySQL nicht so gut vertikal skaliert wie horizontal. (Ein anderer Grund, den Jay erwähnt und der sich auch mit meinen Erfahrung deckt, ist, dass Leute, die eine Oracle-Lizenz kaufen meist auch teure Maschinen bezahlen, um es darauf laufen zu lassen.)

Mit Oracle, egal ob Du vertikal oder horizontal skalierst, wirst Du normalerweise RAC verwenden, was das Aufsetzen von private-Verbindungen und ein Grundsätzliches "alles gemeinsam nutzen" für deine Server bedeutet. Das ist immer noch irgendwie ein vertikales Skalieren der Datenbank, ein Wachsen mit einer bestehenden Anzahl von Servern. (Korrigiere mich, wenn ich falsch liege...)

Mit MySQL neigen die Leute dazu, ihre Datenbanken aufzuteilen, sie in Teile zu "sharden", die in verschiedene Datenbanken auf verschiedenen Servern getan werden. Beispielsweise könntest Du eine kleine globale Datenbank haben, die Informationen darüber enthält, auf welchem Server die Daten eine Benutzers gespeichert sind und dann mehrere "Benutzer"-Datenbanken auf verschiedenen Servern. Deine Datenbank würde im Grunde nach Benutzern in kleinere Datenbanken aufgeteilt sein. (So machen wir das.) Das ist horizontales Skalieren. Wenn Du dann mehr Benutzer kriegst und Du wachsen musst, fügst Du einfach neue Server hinzu.

(Wenn Du auf der anderen Seite eine kleine Datenbank hast - die komplett in den RAM passt - kannst Du MySQLs Clustering-Technologie und die NDB-Speicher-Engine verwenden, um einen Cluster einzurichten, der mehr wie RAC ist. Mit MySQL 5.1 kannst Du das mit Festplatten-basierten Datenbanken machen - aber wieso?) (Lies die Kommentare unten, wenn Du wissen willst, warum...)

Ein anderer Aspekt des horizontalen Skalierens kann sein, MySQLs Replikationstechnologie auf die eine oder andere Art zu verwenden. Du kannst die Master-Master-Replikation einsetzen, um zwei (oder ein paar mehr) Datenbanken aufzusetzen, die im Wesentlichen Kopien voneinander sind und sie synchron miteinander halten. Oder, und das ist üblicher, (und wir machen das so) Du verwendest die Master-Slave-Replikation, um Kopien deiner Datenbanken (shards) zu machen, die Du verwenden kannst, um deine Lese-Zugriffe darauf zu verteilen (und für eine Wiederherstellung im Falle einer Katastrophe: wenn der Master abstürzt - ernenne einen Slave zum neuen Master). Die meisten großen LAMP-Webseiten scheinen das so zu machen.

Zusammenfassend kann man sagen, dass der übliche Ansatz ist, deine Datenbank so zu entwerfen, dass sie in mehrere Shards (Server/Datenbanken) aufgeteilt wird, und Du dann die Replikation verwendest, um Kopien der Shards für weitere Lastverteilung und Verfügbarkeit herzustellen.

Das sagen einige andere Quellen:

Definitionen nach Wikipedias Eintrag zu Skalierbarkeit:

Vertikal skalieren (scale vertically)
Vertikal zu skalieren (scale-up) bedeutet, dass man einem einzelnen Knoten in einem System Ressourcen hinzufügt, typischer Weise gehört dazu das Hinzufügen von CPUs oder RAM zu einem einzelnen Computer. Es kann auch die Erhöhung der Anzahl der laufenden Prozesse, wie zum Beispiel der Erhöhung der Anzahl der Apache-Daemons bedeuten.

Horizontal skalieren (scale horizontally)
Horizontal zu skalieren (scale-out) bedeutet, einem System mehr Knoten hinzuzufügen, wie zum Beispiel das Hinzufügen eines neuen Computers zu einer verteilten Softwareanwendung. Ein Beispiel könnte das horizontale Skalieren von 1 auf 3 Webserver sein.
Nach MySQL: (aus der ersten Seite von "12 Tage des Scale-Out")
Was ist Scale-Out von Datenbanken?

Scale-Out ist eine moderne Rechnerarchitektur, die Organisationen in die Lage versetzt, die Anwendungsleistung und die Skalierbarkeit auf einer inkrementellen, auf die Anforderungen zugeschnittenen Basis zu verbessern, indem mehrere replizierte Datenbankserver auf einer niedrigpreisigen normalen Hardware hinzugefügt werden. Dies steht im Kontrast zu einem Scale-Up-Ansatz, der Organisationen nötigt, eine gewaltige Vorabinvestition in teurere und komplexere Serverhardware und Datenbanklizenzen zu tätigen, um mehr Kapazität hinzuzufügen.
Der exzellente Blog-Artikel von Jay Pipe: Das uneindeutig unklare Duo: Horizontales Skalieren und Vertikales Skalieren

Eine Produktinformation von MySQL: Guide to Cost-effective Database Scale-Out using MySQL (Anleitung für kosteneffektives Scale-Out mit MySQL)

Kommentar von Keith Murphy vom 23. August 2007 1:26

Ich habe ein paar Anmerkungen. Zum einen... MySQL 5.0 hat ein totales RAM-internes Clustering unter Verwendung der NDB-Engine. Mit MySQL 5.1 kann man auf der anderen Seite nur die Indizes im RAM halten. Tatsächlich können die Daten auf der Festplatte gehalten werden.

Warum würdest Du das tun? Nun, vor allem wegen der Verlässlichkeit. Wenn Du mehrere SQL- und Datenknoten hast und sie angemessen konfiguriert sind, dann kann jeder Server abstürzen und der Cluster läuft trotzdem weiter.

Theoretisch erlaubt Dir das, deine Anwendung nach Bedarf zu skalieren. Das ist meines Wissens derzeit eher theoretisch, aber ich bin sicher, dass das weiter besser wird.

Ich führe die Diskussion derzeit auch - Scale-Out vs. Scale-Up. Ja, Scale-Out ist billig(er), weil höherwertige Hardware teurer ist. Aber mehr Server brauchen mehr Leute, um sie zu verwalten (Systemadministratoren) und mehr Datenbankadministratoren, um mit ihnen zu arbeiten. Also fischt man im Trüben, wenn es darum geht, was besser ist.

Es ist wieder und wieder bewiesen worden, das MySQL ausskalieren kann. Nicht so viele Informationen stehen über das Aufskalieren zur Verfügung. Ich habe die Artikel, auf die Du verweist, noch nicht gelesen, aber ich werde es tun. Ich habe gehört, dass MySQL unter Linux ohne viel Effizienzverlust mit ungefähr 64 GB RAM und ungefähr 8 Cores umgehen kann. Das ist eine ganz schön heftige Maschine... eine, die einige kleinere Server ersetzen könnte.

Ein anderes Argument außer den reduzierten Administrationskosten ist, dass manche Anwendungen sich einfach nicht so leicht sharden lassen. In manchen Anwendungen steckt eine so große Komplexität, dass sie das unmöglich macht.

Ich hoffe, einiges davon durchtesten zu können. Ich werde auf jeden Fall darüber bloggen, wenn es so ist.
Kommentar von Matthew Montgomery vom 23. August 2007 4:24
Ich muss dich in einem Punkt korrigieren... Festplatten-basierte Spalten für
NDB-(MySQL-Cluster)-Tabellen sind in Version 5.1 verfügbar.

Siehe: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html

Die NDB-Engine gibt dir die Möglichkeit, auszuskalieren, während Du ein einzelnes logisches Image deiner Daten konservierst, ohne Sharding in deine Anwendung hinein programmieren zu müssen. Außerdem bietet es Hochverfügbarkeit mit synchroner Replikation, Aktivierung eines Ersatzsystems in unter einer Sekunde und automatische Wiederherstellung.

Wikimedia Architecture

Original: http://highscalability.com/wikimedia-architectureInformationsquellen
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.

Dienstag, 23. Oktober 2007

PlentyOfFish Architecture

Original: http://highscalability.com/plentyoffish-architecture
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

PlentyOfFish ist ein äußerst populäres Online-Datingsystem, dass von 45 Millionen Besuchern im Monat überrannt wird und mehr als 30 Millionen Zugriffe pro Tag verzeichnet (500 - 600 Seiten pro Sekunde). Aber das ist nicht der interessanteste Teil der Geschichte. All das wird von einer Person betreut, mit einer Handvoll Servern, mit nur ein paar Arbeitsstunden pro Tag, und dabei 6 Millionen US-Dollar im Jahr mit Google AdSense generierend. Eifersüchtig? Ich bin's jedenfalls. Wie werden all diese Liebesbeziehungen mit nur so wenigen Ressouren hergestellt?

Seite: http://www.plentyoffish.com/

Informationsquellen
Die PlattformDie Fakten
  • PlentyOfFish (POF) hat nur einen Angestellten: den Gründer und CEO Markus Frind
  • POF bringt bis zu 6 Millionen US-Dollar im Jahr mit Google-Werbung bei nur zwei Arbeitsstunden am Tag
  • Mehr als 30 Millionen Zugriffe am Tag (500 - 600 Seiten pro Sekunde)
  • 1,1 Milliarden Seitenaufrufe und 45 Millionen Besucher im Monat
  • POF ist unter den Top 30 Seiten der USA (nach Messungen von Competes Attention), Top 10 in Kanada und Top 30 in Großbritannien
  • 2 Webserver mit Lastverteilern, zwei Quad Core Intel Xeon X5355 @ 2,66 GHz, 8 Gigabyte RAM (etwa 800 MB in Benutzung), zwei Festplatten, Windows x64 Server 2003
  • 3 Datenbankserver. (Über deren Konfiguration liegen keine Daten vor.)
  • Annähernd 64.000 gleichzeitige Verbindungen und 2 Millionen Seitenaufrufe pro Stunde.
  • Die Internetverbindung ist eine 1 GBps-Leitung, von der 200 MBps verwendet werden
  • 1 Terabyte pro Tag kommen von 171 Millionen Bildern, die Akamai ausliefert
  • 6 Terabyte Festplattenspeicher, die Millionen Bilder in Originalgröße vorhalten, die jeden Monat auf die Seite hochgeladen werden.
Was steckt drin
  • Das Einkommensmodell ist es, Google-Werbung zu verwenden. Match.com generiert im Vergleich dazu 300 Millionen US-Dollar im Jahr, vorwiegend über kostenpflichtige Registrierungen. POFs Einkommensmodell ist gerade dabei, sich zu ändern, um mehr Einkommen über die Benutzer zu erzielen. Der Plan ist, mehr Angestellte in Bord zu holen, Sales-Leute einzustellen und Werbung direkt zu verkaufen, statt nur von AdSense abhängig zu sein.
  • Mit 30 Millionen Seitenaufrufen pro Tag kann man mit Werbung gutes Geld verdienen, auch mit nur 3 - 5 Cent pro CPM (Cost-per-million; synonym zu Tausender-Kontakt-Preis, TKP)
  • Akamai wird verwendet, um mehr als 100 Millionen Bilderabfragen pro Tag zu bedienen. Wenn Du acht Bilder hast und jedes 100 Millisekunden braucht, dann redest Du von einer zweiten Last nur durch Bilder. Also ist es sinnvoll auch die Bilder zu verteilen.
  • Mehrere 10 Millionen Bilderabfragen werden direkt von POFs Servern geliefert, aber die Mehrzahl dieser Bilder sind kleiner als 2 Kilobyte und können meistens im RAM gehalten werden.
  • Alles ist dynamisch, nichts ist statisch.
  • Alle rausgehenden Daten sind gzipped, was 30% der CPU-Last erzeugt. Das verlangt eine Menge Rechenleistung auf diesen Servern, aber es vermindert wirklich die Bandbreitenauslastung.
  • Es wird keine Caching-Funktionalität von ASP.NET verwendet, weil die Daten bereits veraltet sind, sobald sie im Cache landen.
  • Keine der vorhandenen Komponenten von ASP.NET werden verwendet. Alles ist von Grund auf selbst programmiert. Nichts ist komplexer als ein einfaches IF...THEN...AND für Schleifen. Immer schön einfach.
  • Lastverteilung
    • IIS begrenzt die Anzahl der Verbindungen willkürlich auf 64.000, so dass ein Lastverteiler hinzugefügt werden musste, um eine riesige Anzahl gleichzeitiger Verbindungen zu bearbeiten. Das Hinzufügen einer zweiten IP um dann Rechnerzuordnungen für Indexpartitionen durch Datenverteilung (round robin DNS) zu verwenden wurde in Betracht gezogen, aber der Lastverteiler erschien besser für eine mehrfache Vorhaltung der Daten und ein einfacheres Hinzuschalten neuer Webserver. Und die Verwendung von ServerIron bot erweiterte Funktionalitäten, wie Bot-Blockierung und Lastverteilung basierend auf weitergeleiteten Cookies, Sessiondaten und IP-Daten.
    • Die Netzwerklastverteilung (network load balancing, NLB) von Windows wurde nicht verwendet, weil es keine "sticky sessions" unterstützt. Um das zu umgehen, kann man den Sessionzustand in einer Datenbank oder in einem gemeinsam genutzten Dateisystem speichern.
    • 8 - 12 NLB-Server können in einer Farm zusammen gefasst werden. Die Anzahl der Farmen ist unbegrenzt. Ein Round-Robin-DNS-Schema kann zwischen den Farmen benutzt werden. So eine Architektur wurde verwendet, um 70 Front-End-Webserver zu ermöglichen, um über 300.000 gleichzeitige Benutzer zu ermöglichen.
    • NLB kennt eine Ähnlichkeitsfunktion, so dass ein Benutzer immer einem bestimmten Server zugeordnet wird, weswegen kein externen Speicherplatz verwendet wird, um den Sessionzustand zu speichern. Wenn der Server abstürzt gehen jedoch die Sessionzustandsdaten verloren und der Benutzer muss sich neu einloggen. Wenn der Sessionzustand auch einen Warenkorb enthält oder andere wichtige Daten, dann ist dieser Lösung wirklich schwach, aber für eine Dating-Seite scheint es Okay zu sein.
    • Man war der Ansicht, dass die Kosten des Speicherns und Gewinnens der Sessiondaten zu teuer ist. Hardwarelastverteilung ist einfacher. Ordne Benutzer einfach spezifischen Servern zu und wenn der Server abstürzt, fordere die Benutzer einfach auf, sich neu einzuloggen.
    • Die Kosten von ServerIron sind jedoch niedriger und es ist einfacher zu benutzen als NLB. Bedeutende Seiten verwenden es für TCP-Verbindungsbündelung (TCP connection pooling), automatische Bot-Erkennung, etc. ServerIron kann weit mehr als Lastverteilung und diese Features sind wegen der niedrigen Kosten sehr attraktiv.
  • Es ist ein großes Problem, einen Adserver auszuwählen. Adserverfirmen wollen mehrere Hunderttausend Dollar pro Jahr und sie wollen Mehrjahresverträge.
  • POF ist dabei die ASP.NET Repeater loszuwerden und statt dessen dieses Append-String-Dings oder response.write zu verwenden. Wenn Du jeden Tag Millionen Seitenaufrufe auslieferst, dann schreib einfach den Code, um es am Bildschirm auszugeben.
  • Der größte Teil der Hardwarekosten stecken in einer SAN. Redundanz im jeden Preis.
  • Das Wachstum kam durch Mundpropaganda. Die Kanadier drehten völlig durch, dann schwappte es nach Großbritannien, Australien und dann in die USA.
  • Datenbanken
    • Eine Datenbank ist die Hauptdatenbank
    • Zwei Datenbanken dienen der Suche. Die Lastverteilung zwischen den Suchservern basiert auf der Art der Suche.
    • Die Leistung wird mit dem Taskmanager überwacht. Wenn sich Spitzen zeigen, wird das untersucht. Übliche Probleme sind Blockierungen in der Datenbank. Es sind immer Datenbankprobleme. Ganz selten sind es Probleme mit .NET. Weil POF die .NET-Bibliothek nicht verwendet, ist es recht einfach, Leistungsprobleme zurückzuverfolgen. Wenn man viele Framework-Schichten verwenden würde, wäare ganz schön hart und frustrierend herauszufinden, wo sich die Probleme verstecken.
    • Wenn Du die Datenbank 20mal pro Seitenaufruf ansprichst, bist du angemeiert, egal was Du versuchst.
    • Trenne Datenbank-Lese- von -Schreib-Zugriffen. Wenn Du nicht viel RAM hast und Du Lese- und Schreib-Zugriffe brauchst, wird das Paging eingeschaltet, was deine Datenbank für Sekunden hängen lassen kann.
    • Versuche eine Nur-Lesen-Datenbank einzurichten, wenn es geht.
    • Denormalisiere die Daten. Wenn Du viel Zeug aus 20 verschiedenen Tabellen holen musst, versuche eine einzige Tabelle zu erstellen, die nur zum Lesen da ist.
    • Einen Tag geht es, aber wenn deine Datenbank ihre Größe verdoppelt, wird sie nicht mehr funktionieren.
    • Mach nur eine Sache im System und es wird alles ganz prächtig laufen. Schreibe in die Datenbank - das geht gut. Lese aus der Datenbank - das geht gut. Mische die Aufgaben und es wird alles durcheinander bringen. Du wirst Locking- und Blocking-Probleme kriegen.
    • Wenn Du an die Grenzen der CPU-Leistung stößt, dann hast Du entweder etwas falsch gemacht oder es ist in höchsten Maße optimiert. Wenn Du die Datenbank in den RAM kriegst, tu es.
  • Der Entwicklungsprozess sieht so aus: Hab eine Idee. Lass sie 24 Stunden online. Das funktioniert in der Hälfte der Fälle. Beobachte die Benutzerakzeptanz, indem Du analysierst, was sie tatsächlich auf deiner Seite machen. Erhöht sich die Anzahl der Nachrichten pro Benutzer? Bleiben sie länger auf deiner Seite? Wenn die Leute es nicht mögen, schalte es ab.
  • Systemabstürze sind selten und von kurzer Dauer. Die größten Probleme sind DNS-Probleme, wenn einige ISP (internet service provider) melden, dass die POF-Seite nicht mehr existiere. Weil die Seite jedoch kostenlos ist, akzeptieren die Leute eine kleine Auszeit. Die Leute bemerken Auszeiten meist gar nicht, weil sie denken, es sei ihr Problem.
  • Das Wachstum von 1 Million auf 12 Millionen Benutzer war ein großer Sprung. POF könnte mit 2 Webservern bis zu 60 Millionen Benutzern skalieren.
  • POF schaut oft bei Mitbewerbern nach neuen Ideen und Features.
  • POF wird Amazons S3 in Betracht ziehen, wenn es geografische Lastverteilung unterstützt.
Gelernte Lektionen
  • Du brauchst keine Millionen Gründerkapital, keine auswuchernde Infrastruktur und kein Haus voller Angestellter um eine Weltklassewebseite zu erschaffen, die einen Strom von Besuchern bewältigt während Du gutes Geld verdienst. Alles was Du brauchst ist eine Idee, die eine Menge Leute anlockt, eine Seiten, die per Mundpropaganda weiterempfohlen wird und die Erfahrung und die Vision, eine Seite aufzubauen, ohne in die typischen Fallen des Handels zu treten. Das war's schon ;-)
  • Bedarf ist die Mutter aller Änderungen
  • Wenn Du schnell wächst, aber nicht zu schnell, dann hast Du die Chance zu wachsen, dich zu ändern und dich anzupassen.
  • RAM löst alle Probleme. Danach wächst man einfach mit größeren Maschinen.
  • Wenn Du startest, dann halte alles so einfach wie möglich. Nahezu alle geben diesen Ratschlag und Markus Frind sagt ganz klar, dass alles was er tut, ganz einfach simpler gesunder Menschenverstand ist. Aber zu finden, was das Einfachste ist, schafft man nicht nur mit gesundem Menschenverstand. Einfache Dinge zu schaffen ist das Ergebnis von Jahren praktischer Erfahrung.
  • Ermögliche einen schnellen Datenbankzugriff und Du wirst keine Probleme haben.
  • Ein wichtiger Grund, warum POF mit so wenig Leuten und so wenig Ausrüstung auskommt ist, dass POF ein Medienverteilernetzwerk (content delivery network, CDN) für die Auslieferung großer, viel genutzter Medien benutzt. Die Verwendung eines CDN könnte die geheime Zutat einer Menge großer Webseiten sein. Markus Frings glaubt, dass es keine einzige Seite unter den Top 100 gibt, die kein CDN benutzen. Ohne ein CDN, glaubt Markus Frings, würde die Ladezeit in Australien wegen all der Bilder bis auf 3 bis 4 Sekunden ansteigen.
  • Werbung auf Facebook bringt fast nichts. Aus 2.000 Klicks wurde nur eine Anmeldung. Mit einem CTR von 0,04% bringt Facebook 0,4 Klicks pro 1.000 Anzeigen oder 0,4 Klicks/CPM. Bei 0,05 USD/CPM = 0,125 USD/Klick; 0,50 USD/CPM = 1,25 USD/Klick; 1 USD/CMP = 2,50 USD pro Klick; 15 USD/CPM = 37,50 USD/Klick
  • Es ist einfach ein paar Millionen Seitenaufrufe mit hohen CPMs zu verkaufen. Es ist VIEL schwerer, Milliarden von Seitenaufrufen mit hohen CPMs zu verkaufen, wie man bei Myspace und Facebook sehen konnte.
  • Das werbegestützte Modell begrenzt deine Einahmen. Du brauchst ab einer bestimmten Größe ein Bezahlmodell. 100 Millionen im Jahr mit einer kostenlosen Seite zu generieren ist praktisch unmöglich, weil Du einen zu großen Markt bräuchtest.
  • Die Anzahl der Seitenaufrufe via Facebook zu erhöhen funktioniert nicht für eine Dating-Seite. Besucher auf Deiner Webseite zu haben, ist viel profitabler. Die meisten Seitenaufrufe auf Facebook kommen von außerhalb der USA und Du musst 0,05 USD/CPM mit Facebook teilen.
  • Co-Req ist eine potenziell große Einkommensquelle. Du bietest dem Benutzer interessante Informationen über andere Produkte an, wenn er sich bei Dir anmeldet.
  • Du kannst nicht immer auf die Benutzer hören. Manche Benutzer wollen immer neue Features haben und andere werden neue Features hassen. Nur ein Teil wird sich beschweren. Analysiere stattdessen, welche Features die Leute auf deiner Seite tatsächlich benutzen.

Montag, 22. Oktober 2007

Digg Architecture

Original: http://highscalability.com/digg-architecture Dienstag, 7. August 2007 01.28
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

Der Traffic, der von Diggs über 1,2 Millionen für ihren Informationshunger berühmten Benutzern generiert wird, kann eine nicht vorbereitete Webseite wegen ihrer CPU-, Speicher und Bandbreitenbeschränkungen kopfüber zum Absturz bringen. Wie kommt Digg mit dieser Last zurecht?

Seite: http://digg.com

Informationsquellen
Plattform
  • MySQL
  • Linux
  • PHP
  • Lucene
  • APC PHP Accelerator
  • MCache
Die Fakten
  • Gestartet Ende 2004 mit einem einzelnen Linux-Server mit Apache 1.3, PHP 4 und MySQL 4.0 mit der Standard-MyISAM Speicherengine
  • Über 1,2 Millionen Benutzer
  • Über 200 Millionen Seitenaufrufe pro Monat
  • 100 Server in mehreren Datenzentren
    • 20 Datenbankserver
    • 30 Webserver
    • einige Suchserver mit Lucene
    • der Rest dient der Mehrfachverfügbarkeit (Redundanz)
  • 30 GB Daten
  • Keine der Skalierungsherausforderungen hatte etwas mit PHP zu tun. Die größten Aufgaben, denen Digg gegenüberstand, hatten alle etwas mit der Datenbank zu tun.
  • Die leichtgewichtige Natur von PHP erlaubte es Digg Berechnungsaufgaben aus der Datenbank nach PHP zu verlagern, um die Skalierung zu verbessern. eBay macht das in radikaler Weise. Sie haben nahezu alle Arbeit aus der Datenbank in die Anwendung verschoben, einschließlich von Joins, einer Operation, die normaler Weise als Job der Datenbank angesehen wird.
Was steckt drin
  • Vorn ein Lastverteiler (load balancer), der die Anfragen an die PHP-Server schickt
  • Eine MySQL-Master-Slave-Installation
    • transaktionslastige Server benutzen die InnoDB-Speicherengine
    • OLAPlastige Server benutzen die MyISAM-Speicherengine
  • Memcached wird für das Caching verwendet
  • Sharding wird verwendet, um die Datenbank in mehrere kleiner zu zerlegen
  • Diggs Anwendungsmuster macht es ihm leicht, zu skalieren. Die meisten Leute sehen sich nur die ersten Seiten an und verlassen Digg dann wieder. Deshalb sind 98% der Datenbankzugriffe bei Digg Lesezugriffe. Mit diesem Schwerpunkt der Arbeiten muss sich Digg keine Gedanken über die komplexe Arbeit des Entwurfs von Schreibzugriffen machen, was es Digg viel einfacher macht, zu skalieren.
  • Digg hatte Probleme mit seinem Speichersystem, weil es Schreibzugriffe als abgeschlossen meldete, die es aber noch nicht waren. Kontroller tun dass, um die gefühlte Leistungsfähigkeit zu erhöhen. Das führt jedoch zu einem gigantischen Leck in der Datenintegrität. Das ist ein wirklich weit verbreitetes Problem und kann schwer zu beheben sein, abhängig von den Hardwaregegebenheiten.
  • Um die Datenbanklast zu verringern, verwendet Digg den APC PHP Accelerator MCache.
  • Man kann PHP mit eine Kombination aus Apaches 2 worker threads, FastCGI und einem PHP Accelerator so konfigurieren, dass es nicht bei jeder Anfrage parst und kompiliert. Beim ersten Laden einer Seite wird der PHP-Code kompiliert, so dass jeder weitere Aufruf viel schneller ist.
Gelernte Lektionen
  • Verbessere MySQL mit der Wahl der richtigen Datenbankengine. Verwende InnoDB, wenn Du Transaktionen brauchst und MyISAM, wenn nicht. Zum Beispiel können Transaktionstabellen auf dem Master MyISAM als Nur-Lesen-Slave verwenden.
  • An einem Punkt ihrer Wachstumskurve konnte Digg nicht mehr durch das Hinzufügen von mehr RAM wachsen, deshalb musste es durch die Architektur wachsen.
  • Die Leute beschweren sich oft über die Langsamkeit von Digg. Das liegt vielleicht eher an Diggs riesigen JavaScript-Bibliotheken als an Diggs zu Grunde liegender Architektur.
  • Ein Weg, wie Digg skaliert, ist, dass es genau bedenkt, welche Anwendung es in seinem System installiert. Digg passt genau auf, damit keine Anwendungen installiert werden, die zuviel CPU-Last erzeugen. Digg verwendet ganz klar eine Standard-LAMP-Architektur, aber ich denke es gibt noch einen interessanten Punkt. Entwickler haben oft eine Riesenmenge cooler Features, die sie installieren wollen. Aber diese Features können eine Infrastruktur lahm legen, wenn die Infrastruktur nicht zusammen mit den Features wächst. Also stelle die Features zurück, bis dein System mit diesen Features umgehen kann. Das könnte man mit Kapazitätsplanung machen, etwas, das Flickr in seinem Skalierungsprozess betont.
  • Glaubst Du, Digg würde, weil es, um seine Infrastruktur nicht zu belasten, neue Funktionen begrenzt, Boden an sich schneller entwickelnde soziale Lesezeichendiesnte verlieren? Vielleicht könnte, wenn Digg seine Infrastruktur einfacher skalieren könnte, es Features schneller hinzufügen, was ihm gegenüber seiner Konkurrenz helfen würde? Andererseits macht es auch nicht viel Sinn, Features nur hinzuzufügen, weil man es kann.
  • In der Datenbankschicht liegen die größten Skalierungs- und Leistungsprobleme, die man finden kann und das unabhängig von der Programmiersprache. Du wirst auf sie treffen, egal ob Du Java, PHP, Ruby oder deine Lieblingssprache verwendest.

Sonntag, 21. Oktober 2007

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
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.

Freitag, 19. Oktober 2007

Google Architecture

Google Architecture
Artikel von Todd Hoff, Montag, 23. Juli 2007 - 04:26
Quelle: http://highscalability.com/google-architecture

Google ist der König der Skalierungsfähigkeit. Jeder kennt Google für seine riesige, ausgeklügelte und schnelle Suchmaschine, aber Google glänzt nicht nur bei der Suche. Googles Plattformansatz, skalierbare Anwendungen zu bauen, erlaubt Google, im Internet skalierende Anwendungen mit einer alarmierend hohen Konkurrenten-Plattwalz-Rate zu installieren. Googles Ziel ist immer eine noch leistungsfähigere, noch mehr skalierende Infrastruktur zur Unterstützung ihrer Produkte. Wie macht Google das?

Informationsquellen

Plattform
  • Linux
  • Eine große Bandbreite von Programmiersprachen: Python, Java, C++
Was steckt drin??

Die Fakten
  • Geschätzte 450.000 billige normale Server in 2006
  • 2005 indizierte Google 8 Milliarden Webseiten. Und heute ... wer weiß?
  • Zur Zeit gibt es über 200 GFS-Cluster (Google File System Cluster, Google Dateisystem-Cluster) bei Google. Ein Cluster kann 1.000 oder auch 5.000 Maschinen umfassen. Pools von zehntausenden Maschinen holen Daten von GFS-Clustern, die um die 5 Petabyte Speicher haben. Der zusammengefasste Lese-/Schreib-Durchsatz zwischen den Clustern kann bei um die 40 Gigabyte pro Sekunde liegen.
  • Zur Zeit gibt es 6.000 MapReduce-Anwendungen bei Google und hunderte neue Anwendungen werden jeden Monat geschrieben.
  • BigTable skaliert auf Milliarden von URLs, Hunderte von Terabytes von Satellitenbildern und Einstellungen für Hunderte von Millionen von Benutzern.
Der Stapel

Google visualisiert seine Infrastruktur als einen Drei-Schichten-Stapel:
  • Produkte: Suche, Werbung, E-Mail, Karten, Video, Chat, Blogs
  • Verteilte Systeminfrastruktur: GFS, MapReduce und BigTable
  • Rechnerplattformen: eine Menge Maschinen in einer Menge Rechenzentren
  • Mach es den Leuten in deiner Firma einfach, billig zu entwickeln.
  • Achte pro Anwendung auf die Preisentwicklungsdaten. Gib mehr Geld für Hardware aus, um keine Log-Daten zu verlieren, aber gib weniger für andere Arten von Daten aus. Hab ich schon erwähnt, dass Google keine Daten verliert?
Verlässlicher Speichermechanismus mit GFS (Google File System)
  • Verlässlicher skalierbarer Speicher ist eine Grundbedürfnis jeder Anwendung. GFS ist Googles Basisspeicherplattform.
  • Das Google-Dateisystem (GFS, Google File System) ist ein riesiges verteiltes loggendes strukturiertes Dateisystem, in das Google eine Mengen Daten reinschmeißt.
  • Warum sollte man so etwas bauen, statt etwas von der Stage zu nehmen? Weil sie alles kontrollieren und es ist die Plattform, die Google von allen anderen unterscheidet. Sie brauchen:
    • hohe Verlässlichkeit zwischen den Datenzentren
    • Skalierbarkeit auf Tausende von Netzwerkknoten
    • eine gewaltige Schreib-/Lese-Bandbreite
    • Unterstützung für große Datenblöcke bis zur Größe von Gigabytes
    • eine effiziente Aufgabenverteilung zwischen den Knoten, um Flaschenhälse zu vermeiden
  • Im System gibt es Master- und Chunk-Server
    • Master-Server halten Metadaten über die verschiedenen Datendateien vor. Die Daten im Dateisystem in 64 Megabyte-Stückchen ("Chunks") gespeichert. Die Clients kommunizieren mit den Master-Servern, um Metadatenoperationen an Dateien vorzunehmen und den Chunk-Server zu finden, der das Benötigte auf der Festplatte vorhält.
    • Chunk-Server speichern die tatsächlichen Daten auf der Festplatte. Jedes Daten-Stückchen ("Chunk") wird auf drei verschiedenen Chunk-Server gleichzeitig gespeichert (repliziert), um mehrfache Verfügbarkeit (Redundanz) für den Fall sicherzustellen, dass ein Server abstürzt.
  • Eine neue Anwendung, die online gestellt wird, kann einen existierenden GFS-Cluster verwenden oder die Entwickler können ihren eigenen Cluster einrichten. Es könnte interessant sein, den Versorgungsprozess zu verstehen, den Google zwischen seinen Datenzentren verwendet.
  • Der Schlüssel ist eine ausreichende Infrastruktur, um sicherzustellen, das die Leute für ihre Applikation eine Wahl haben. GFS kann so eingerichtet werden, dass es die Anforderungen der verschiedenen Anwendungen befriedigt.
Verwende MapReduce, um etwas mit den Daten zu machen
  • Nachdem Du jetzt ein gutes Speichersystem hast: wie kannst Du irgendetwas mit so vielen Daten anfangen? Nehmen wir an, Du hättest viele Terabyte Daten verteilt auf 1.000 Maschinen gespeichert. Datenbanken können nur bis diesem Level skalieren oder kostenmäßig effizient skalieren. Jetzt kommt MapReduce ins Spiel.
  • MapReduce ist ein Programmiermodell und eine assoziative Implementierung für die Verarbeitung und Generierung großer Datensätze. Der Benutzer gibt eine Abbildungsfunktion (mapping function) an, die alle Schlüssel/Wert-Paare verarbeitet, um einen Satz von Vermittlungs-Schlüssel/Wert-Paaren zu generieren und eine Reduzierungsfunktion (reduce function), die alle Vermittlungswerte mit den entsprechenden Vermittlungsschlüsseln verbindet. Viele Aufgaben aus der realen Welt lassen sich mit diesem Modell ausdrücken. Programme, die in diesem funktionalen Stil geschrieben sind, sind automatisch parallelisiert und können auf riesigen Clustern aus normalen Servern ausgeführt werden. Die Laufzeitsysteme achten auf die Details der Aufteilung (Partitionierung) der Eingabedaten, planen die Ausführung der Programme über mehrere Maschinen hinweg, sorgen sich um Maschinenausfälle und organisieren die benötigte Kommunikation zwischen den Maschinen. Das erlaubt Programmierern mit nur wenig Erfahrung mit parallelisierten und verteilten Systemen ganz leicht Ressourcen aus einem riesigen verteilten System zu verwenden.
  • Warum sollte man MapReduce verwenden?
    • Prima Weg um Aufgaben auf eine Menge Maschinen zu verteilen.
    • Sorgt sich selbst um Maschinenabstürze
    • Arbeitet zwischen verschiedenen Anwendungsarten, wie Suche und Werbung. Fast jede Anwendung beinhaltet Arbeiten vom Typ Map-Reduce. Du kannst nützliche Daten vorverarbeiten, Wörter zählen, Terabyte von Daten sortieren, etc.
    • Die Berechnungen können sich automatisch näher an die Ein- und Ausgabe-Schnittstelle bewegen.
  • Das MapReduce-System kennt drei verschiedene Serverarten.
    • Der Master-Server ordnet die Benutzeraufgaben den Map- und Reduce-Servern zu. Er überwacht außerdem den Status der Benutzeraufgaben.
    • Der Map-Server akzeptiert Benutzereingaben und führt zugehörige Zuordnungsaufgaben aus. Die Ergebnisse werden in die Vermittlungsdateien geschrieben.
    • Der Reduce-Server akzeptieren die Vermittlungsdateien, die von den Map-Servern kommen und führen Reduce-Aufgaben damit durch.
  • Du willst zum Beispiel die Anzahl der Wörter aller Webseiten zählen. Du würdest alle Seiten, die im GFS gespeichert sein ins MapReduce füttern. Dann würde alles gleichzeitig auf 1.000 Maschinen stattfinden und all die Koordination, die Aufgabenplanung, die Fehlerbehandlung und der Datentransport würden automatisch bewältigt.
    • Die Schritte sehen so aus: GFS -> Zuordnen -> Mischen -> Reduzierung -> Ergebnisse zurück ins GFS schreiben.
    • In MapReduce ordnet eine Zuordnung eine Datensicht der anderen zu, ein Schlüssel/Wert-Paar erzeugend, das in unserem Beispiel "Wörter" und die Anzahl sind.
    • Das Mischen vereinigt die Schlüssel-Arten.
    • Die Reduzierung summiert alle Schlüssel/Wert-Paare auf und erzeugt die endgültige Antwort.
  • Die Indizierungspipeline von Google kennt ungefähr 20 verschiedene Zuordnungsreduktionen. Eine Pipeline sieht die Daten mit einer Riesenmenge von Einträgen und Zuordnungsschlüsseln. Ein zweite Zuordnungsreduktion wird durchgeführt, nimmt das Ergebnis und macht dann das nächste. Und so weiter.
  • Programme können sehr klein sein. Bis hin zu nur 20 oder 50 Zeilen Code.
  • Ein Problem sind Bummler. Ein Bummler ist eine Berechnung, die langsamer läuft als andere, was alle aufhält. Bummler können vorkommen wegen langsamer Ein- und Ausgabe (zum Beispiel wegen eines defekten Kontrollers) oder wegen zeitweiligen CPU-Überlastung. Die Lösung ist, die Berechnung mehrmals gleichzeitig auszuführen und wenn eine fertig ist, die anderen einfach abzubrechen.
  • Die Daten, die zwischen Map- und Reduce-Servern übermittelt werden, sind komprimiert. Das ist so, weil die Server nicht CPUs zugeordnet sind und es also Sinn macht, in Kompression und Dekompression zu investieren statt in Bandbreite und Ein- und Ausgabe.
Speichern strukturierter Daten in BigTable
  • BigTable ist ein riesig skalierendes, fehlertolerantes, selbstverwaltendes System, das Terabyte flüchtigen Speichers und Petabyte festen Speichers beinhaltet. Es kann Millionen von Schreib- und Lesezugriffen pro Sekunde aushalten.
  • BigTable ist ein verteilter Hash-Mechanismus, der auf dem GFS (Google File System) aufbaut. Es ist keine relationale Datenbank. Es unterstützt keine Joins oder SQL-Abfragen.
  • Es bietet Suchmechanismen, um strukturierte Daten an Hand des Schlüssels zu suchen. Das GFS speichert undurchsichtige Daten und viele Anwendungsanforderungen drehen sich ja um strukturierte Daten.
  • Kommerzielle Datenbanken skalieren einfach nicht bis auf dieses Level und können nicht über 1.000 Maschinen hinweg arbeiten.
  • Indem Google sein eigenes Speichersystem bis in die Grundfesten kontrolliert, erhält es mehr Kontrolle und sitzt am Hebel, wenn es darum geht, das System zu verbessern. Wenn Google zum Beispiel neue Funktionen haben will, die die Aufgaben zwischen den Datenzentren einfacher macht, kann es sie einfach einbauen.
  • Maschinen können hinzugefügt und herausgenommen werden, während das System läuft und das ganze System einfach weiterarbeitet.
  • Jeder Datensatz wird in einer Zelle gespeichert, auf die mit einem Spalten- und einem Zeilen-Schlüssel oder einem Zeitstempel zugegriffen werden kann.
  • Jeder Zeile wird in einem oder mehreren Tablets gespeichert. Ein Tablet ist eine Folge von 64 Kilobyte-Blöcken in einem Datenformat namens SSTable.
  • BigTable kennt drei verschiedene Arten von Servern:
    • Die Master-Server (master server) ordnen Tablets den Tablet-Servern zu. Sie überwachen, wo die Tablets liegen und verteilen die notwendigen Aufgaben neu.
    • Die Tablet-Server (tablet server) nehmen Lese-/Schreib-Anfragen für die Tablets vor. Sie trennen Tablets auf, wenn die die Größengrenze erreichen (in der Regel 100 - 200 Megabyte). Wenn ein Tablet-Server abstürzt, dann übernehmen 100 Tablet-Server je ein neues Tablet und das System erholt sich wieder.
    • Die Sperr-Server (lock server) bilden einen verteilten Sperrdienst. Aufgaben wie das Öffnen von Tablets um hineinzuschreiben, Master-Entscheidungen und Zugriffskontrollüberprüfung erfordern einen gegenseitigen Ausschluss.
  • Eine Lokalitätsgruppe kann verwendet werden, um zusammengehörige Daten-Bits physisch zusammen zu speichern, um eine bessere Lokalitätseigenschaft zu erreichen.
  • Tablets werden so viel wie irgend möglich im RAM gecached.
Hardware
  • Wenn Du eine Menge Maschinen hast, wie konfigurierst Du sie, um kosten- und energieeffizient zu sein?
  • Verwende ultrabillige Standardhardware und baue dann eine Software, die mit deren Tod umgehen kann.
  • Einen tausendfachen Rechenleistungsanstieg kann man für 33-fach geringere Kosten haben, wenn Du eine fehleranfällige Infrastruktur einer Infrastruktur vorziehst, die aus hochzuverlässigen Komponenten besteht. Du musst Verlässlichkeit auf Unzuverlässigkeit aufbauen, damit diese Strategie funktioniert.
  • Linux, In-House-Racks, Hauptplatinen der PC-Klasse, billige Festplatten.
  • Der Preis pro Wattleistung je Rechenleistung wird nicht besser. Nimm hohen Wattleistung hin und beschaff Dir eine gute Kühlung.
  • Verwende eine Mischung aus gemeinschaftlichen und separaten Rechenzentren.
Verschiedenes
  • Schiebe Änderungen schnell raus, statt auf QA zu warten.
  • Bibliotheken sind der vorherrschende Weg, um Programme zu bauen.
  • Einige Anwendungen werden als Service angeboten, wie zum Beispiel das Crawling.
  • Die Infrastruktur besorgt die Versionierung der Anwendungen, so dass man etwas Veröffentlichen kann, ohne Angst davor haben zu müssen, dass man etwas kaputt macht.
Zukünftige Vorgaben für Google
  • Unterstützung weltweit verteilte Cluster.
  • Schaffung eines einzelnen globalen Namensraums für alle Daten. Zur Zeit sind die Daten nach Clustern getrennt.
  • Mehr und besser automatisierte Migration von Daten und Berechnungen.
  • Lösen von Konsistenzproblemen, die auftreten, wenn Du eine Breitbandreplikation mit Netzwerkaufteilung koppelst (zum Beispiel um Dienste am Laufen halten, auch wenn ein Cluster wegen Wartungsarbeiten oder wegen etwas anderem ausgeschaltet werden).
Gelernte Lektionen
  • Infrastruktur kann ein Wettbewerbsvorteil sein. Es ist gewiss einer für Google. Google kann neue Internetdienste so schnell, billig und skalierungssicher herausbringen, dass nur ein paar andere mithalten können. Viele Firmen haben einen komplett anderen Ansatz. Viele Firmen sehen Infrastruktur nur als Kostenfaktor an. Jede Gruppe verwendet komplett andere Technologien und es gibt nur wenig Planung und Öffentlichkeit was den Aufbau des Systems angeht. Google sieht sich selbst als eine Systemtechnikfirma, was ein erfrischender Blick auf die Softwareherstellung ist.
  • Die Verbindung mehrerer Datenzentren ist nach wie vor ein ungelöstes Problem. Die meisten Webseiten sind in einem oder höchstens zwei Datenzentren. Wie man eine Webseite komplett über mehrere Datenzentren hinweg herausbringt ist, sagen wir, knifflig.
  • Sieh dir Hadoop (das Produkt) an, wenn Du keine Zeit hast, die ganze Infrastruktur von Grund auf selbst aufzubauen. Hadoop ist eine Open Source-Implementierung, die viele der hier vorgestellten Ideen enthält. ( http://lucene.apache.org/hadoop/ )
  • Ein unterschätzter Vorteil des Plattform-Ansatzes ist, das unerfahrene Entwickler auf der Plattform aufbauend schnell und sicher robuste Anwendungen schaffen können. Wenn jedes Projekt dasselbe verteilte Infrastruktur-Rad neu erfinden muss, wirst Du Probleme kriegen, weil die Leute, die wissen wie das geht, ziemlich selten sind.
  • Synergie ist nicht immer Scheiße. Indem man alle Teile eines Systems dazu bringt zusammenzuarbeiten, hilft eine Verbesserung an einem Teil allen anderen auch. Verbessere das Dateisystem und alle profitieren sofort und klar erkennbar. Wenn jedes Projekt ein anderes Dateisystem verwendet, gibt es keine stetig wachsende Verbesserung im gesamten Stapel.
  • Baue selbstverwaltende Systeme, die arbeiten, ohne dass man das System herunterfahren muss. Das erlaubt dir, einfacher Ressourcen zwischen den Servern auszubalancieren, dynamisch mehr Kapazität hinzuzufügen, Maschinen abzuschalten und Upgrades elegant handzuhaben.
  • Schaffe eine darwinistische Infrastruktur. Führe zeitfressende Aufgaben parallel durch und nimm den Gewinner.
  • Ignoriere die Forschung nicht. Akademiker haben eine Menge guter Ideen, die leider nicht in Produktionsumgebungen übertragen werden. Das meiste von dem was Google tut, ist Stand der Technik, nicht nur die riesige Skalierungsfähigkeit.
  • Ziehe Kompression in Betracht. Kompression ist eine gute Option, wenn Du viele CPUs und wenig Ein-/Ausgabe-Bandbreite hast.

Mittwoch, 17. Oktober 2007

Amazon Architecture

Quelle: http://highscalability.com/amazon-architecture
Artikel von Todd Hoff, Dienstag, 18. September 2007 - 19:44
Übersetzung von Sebastian Wallroth

Dies ist ein wunderbarer informativer Artikel über Amazon basierend auf Joachim Rohdes Entdeckung eines Interviews mit Amazons CTO. Sie erfahren etwas darüber, wie Amazon seine Teams um die Dienste herum organisiert, etwas über das CAP-Theorem, über den Aufbau von skalierbaren Systemen, wie sie Software installieren und vieles mehr. Viele Ergänzungen aus dem ACM Queue-Artikel wurden mit einbezogen.

Amazon wuchs von einem kleinen Online-Buchladen zu einem der größten Läden der Welt. Auf dem Weg dorthin entdeckten sie neue und interessante Wege Produkte zu bewerten, zu besprechen und zu empfehlen. Greg Linden veröffentlichte seine Version über Amazons Geburtswehen in einer Serie von Blog-Artikeln.

Webseite: http://www.amazon.com

Informationsquellen
  • "Early Amazon" ("Das frühe Amazon") von Greg Linden
  • "How Linux saved Amazon millions" ("Wie Amazon mit Linux Millionen sparte")
  • Interview Werner Vogels - Amazons CTO
  • "Asynchronous Architectures" ("Asynchrone Architektur") - eine hübsche Zusammenfassung von Werner Vogels' Gespräch mit Chris Loosley
  • "Learning from the Amazon technology platform - A Conversation with Werner Vogels" ("Von Amazons Technologieplattform lernen - Ein Gespräch mit Werner Vogels")
  • Werner Vogels' Weblog - "building scalable and robust distributed systems" ("Skalierbare und robuste verteilte System bauen")
Plattform
  • Linux
  • Oracle
  • C++
  • Perl
  • Mason
  • Java
  • Jboss
  • Servlets

Die Fakten
  • Mehr als 55 Millionen aktive Benutzeraccounts
  • Mehr als 1 Millionen aktive Einzelhandelspartner weltweit
  • Zwischen 100-150 Dienste werden aufgerufen, um eine Seite aufzubauen
Die Architektur
  • Was meinen wir wirklich mit Skalierbarkeit? Ein Dienst wird skalierbar genannt, wenn hinzugefügte Ressourcen zu einem einigermaßen proportionalen Anwachsen der Leistung führen. Anwachsende Leistung bedeutet im Allgemeinen, dass mehr Arbeitseinheiten pro Zeiteinheit geleistet werden, aber es kann auch bedeuten, dass größere Arbeitseinheiten pro Zeiteinheit abgearbeitet werden, wenn zum Beispiel Datensätze anwachsen.
  • Die große Architekturänderung, die Amazon durchführte, war die Umstellung von einem Zwei-Schichten-Monolithen auf eine verteilte, dezentralisierte Dienste-Plattform, die viele unterschiedliche Anwendungen bedient.
  • Amazon startete als eine Anwendung, die mit dem Back-End kommunizierte; geschrieben in C++.
  • Es wuchs an. Für mehrere Jahre beschränkten sich die Skalierungs-Anstrengungen von Amazon darauf, Back-End-Datenbanken mehr Einträge vorhalten zu lassen, mehr Kunden, mehr Bestellungen und viele internationale Seiten zu unterstützen. 2001 wurde klar, dass sich die Front-End-Anwendung nicht mehr skalieren ließ. Die Datenbanken wurden in kleine Teile aufgetrennt und um jeden Teil wurde ein Dienste-Schnittstelle gebaut, die die einzige Möglichkeit wurde, auf die Daten zuzugreifen.
  • Die Datenbanken waren eine geteilte Ressource geworden, was es schwer machte, das Gesamtgeschäft zu skalieren. Die Front-End- und die Back-End-Prozesse waren in ihrer Evolution beschränkt, weil sie sich von vielen verschiedenen Teams und Prozessen geteilt wurden.
  • Ihre Architektur ist nun lose verbunden und um Dienste herum gebaut. Eine Dienste-orientierte Architektur verschaffte ihnen die Isolation, die es erlaubte, viele Softwarekomponenten schnell und unabhängig voneinander zu entwickeln.
  • Sie wuchsen zu hunderten von Diensten und mehreren Anwendungsservern an, die die Informationen der Dienste zusammenführen. Die Anwendung, die die Amazon.com-Webseite rendert ist so ein Anwendungsserver; genauso wie die Anwendungen, die Webservice-Schnittstelle, die Kundendienst-Anwendung und die Käufer-Oberfläche.
  • Viele Drittanbieter-Technologien können nur schwer bis zur Größe von Amazon skaliert werden; insbesondere Kommunikations-Infrastruktur-Technologien. Sie funktionieren gut bis zu einer bestimmten Größe und kommen dann nicht weiter. So war Amazon gezwungen, seine eigenen zu bauen.
  • Sie legten sich nicht auf einen speziellen Ansatz fest. An einigen Stellen verwenden sie JBoss/Java, aber dann verwenden sie nur Servlets, nicht den Rest des J2EE-Stapels.
  • C++ wird verwendet, um Anfragen zu verarbeiten. Perl/Mason wird verwendet, um Inhalte zu bauen.
  • Amazon mag keine Middleware, weil sie dazu tendiert, ein Framework zu sein und kein Werkzeug. Wenn Du ein Middleware-Paket verwendest, bist Du in den Software-Mustern gefangen, die dafür gewählt wurden. Du kannst nur ihre Software verwenden. Wenn Du also andere Pakete verwenden willst, kannst Du das nicht. Nur eine Ereignis-Schleife für Nachrichtenversand, Daten-Persistenz, AJAX usw. ist zu komplex. Wenn Middleware in kleineren Komponenten verfügbar wäre - mehr als Werkzeuge denn als Framework - wären sie mehr daran interessiert.
  • Der SOAP-Web-Stapel scheint alle Probleme der verteilten System noch einmal lösen zu wollen.
  • Biete sowohl SOAP- als auch REST-Webservices an. 30% verwenden SOAP. Das scheinen tendenziell Java- und .NET-Anwender zu sein, die WSDL-Dateien benutzen, um Remote-Objekt-Schnittstellen zu generieren. 70% benutzen REST. Das scheinen überwiegend PHP- und Perl-Anwender zu sein.
  • Sowohl SOAP- als auch REST-Entwickler können eine Objekt-Schnittstelle zu Amazon kriegen. Die Entwickler wollen nur, dass es irgendwie geht. Es ist ihnen egal, was durch's Kabel geht.
  • Amazon wollte eine offene Community um seine Webservices aufbauen. Webservices wurden gewählt, weil sie einfach sind. Aber das ist nur ein Nebeneffekt. Intern haben sie eine Dienste-orientierte Architektur. Du kannst auf Daten nur über die Schnittstelle zugreifen. Es wird in WSDL beschrieben, aber sie verwenden ihre eigenen Verkapselungs- und Transport-Mechanismen.
  • Die Teams sind klein und um die Dienste herum organisiert.
    • Die Dienste sind unabhängige Einheiten, die innerhalb von Amazon Funktionalitäten liefern. Genauso sind bei Amazon intern die Teams organisiert.
    • Wenn Du eine neue Geschäftsidee oder ein Problem hast, das Du lösen willst, dann stellst Du ein Team auf. Das Team ist auf 8-10 Leute begrenzt, weil die Kommunikation sonst schwer wird. Sie werden Zwei-Pizza-Teams genannt; die Anzahl von Leuten, die man mit zwei Pizzas verköstigen kann.
    • Die Teams sind klein. Sie haben alle Vollmachten und werden in die Lage versetzt, ein Problem auf die Art mit einem Dienst zu lösen, die ihnen passend erscheint.
    • Beispielsweise schufen sie ein Team, um Wortgruppen in Büchern zu finden, die den Text einzigartig machen. Dieses Team baute eine separate Dienste-Schnittstelle für dieses Feature und sie hatten die Vollmacht das zu tun, was sie für notwendig hielten.
    • Extensives A/B-Testen wird verwendet, um neue Dienste zu integrieren. Sie beobachten die Auswirkungen und nehmen extensive Messungen vor. (Web-Analytics.org: A/B Testreihen)
  • Deployment
    • Sie schaffen eine spezielle Infrastruktur, um Abhängigkeiten zu verwalten und das Deployment abzuwickeln
    • Ziel ist es, alle betreffenden Dienste in eine Box zu deployen. Der gesamte Anwendungscode, das Monitoring, die Lizensierung etc. soll in einer Box zusammengefasst sein.
    • Jeder hat sein gewachsenes System, um diese Probleme zu lösen.
    • Der Output des Deployment-Prozesses ist eine Virtuelle Maschine. Man kann sie mit EC2 benutzen.
  • Arbeite dich vom Kunden rückwärts vor, um sicherzustellen, dass eine neuer Dienst den Aufwand wert ist.
    • Beginne Deine Arbeit beim Kunden. Fokussiere Dich auf den Mehrwert, den Du den Kunden bieten willst.
    • Zwinge die Entwickler, sich auf den Mehrwert zu fokussieren anstatt zuerst eine Technologie zu bauen und sich dann auszudenken, wie sie verwendet werden könnte.
    • Beginne mit einer Pressemitteilung darüber, was der Kunde zu erwarten hat und arbeite dich von da aus vor, um sicher zu sein, dass Du etwas Sinnvolles baust.
    • Ziele auf ein Design ab, das so einfach wie möglich ist. Einfachheit ist der Schlüssel, wenn Du wirklich große verteilte Systeme aufbauen willst.
  • State Management (Zustandsverwaltung) ist das Kernproblem für große verteilte Systeme
    • Intern können sie unbegrenzten Speicherplatz zur Verfügung stellen.
    • Von den ganzen Operationen haben nicht alle eine Zustandsverwaltung. Bestellschritte haben immer eine Zustandsverwaltung.
    • Die zuletzt angeklickten Webseiten-Dienste haben Referenzen auf Basis von Session-IDs.
    • Sie speichern sowieso alles, also ist es egal, ob man den Zustand speichert. Es gibt nur wenige Extra-Zustände, die für eine Session gespeichert werden müssen. Die Dienste werden immer alle Informationen vorhalten, also benutze die Dienste einfach.
  • Eric Brewers CAP-Theorem oder Die drei Eigenschaften eines Systems
    • Die drei Eigenschaften eines Systems sind: Konsistenz, Verfügbarkeit und Tolerierung von Netzwerkaufteilung (network partition).
    • Du kannst höchstens zwei dieser drei Eigenschaften für ein System haben, das sich Daten teilt.
    • Aufteilbarkeit: trenne Knoten in kleine Gruppen, die andere Gruppen sehen können, aber nicht das ganze System.
    • Konsistenz: Wenn Du einen Wert schreibst und dann den Wert ausliest, erhälst Du den Wert, den Du geschrieben hast. In einem aufgeteilten System kann es vorkommen, dass diese Aussage nicht zutrifft.
    • Verfügbarkeit: vielleicht kannst Du nicht immer schreiben oder lesen. Das System wird Dir sagen, dass Du nicht schreiben kannst, weil es das System konsistent halten will.
    • Um skalieren zu können, musst Du aufteilen. Also musst Du dich entweder für hohe Konsistenz oder für eine hohe Verfügbarkeit eines bestimmten Systems entscheiden. Du musst die Balance zwischen Verfügbarkeit und Konsistenz finden.
    • Wähle einen bestimmten Ansatz anhand der Anforderungen an den Dienst.
    • Im Bestellprozess willst Du immer ganz sicher gehen, wenn dem Warenkorb Bestellungen hinzugefügt werden, weil es genau das ist, womit Du Geld verdienst. In diesen Fall wähle Hochverfügbarkeit. Fehler werden dem Kunden nicht angezeigt und später aussortiert.
    • Wenn ein Kunde eine Bestellung abschickt, wird Dir Konsistenz wichtiger sein, weil verschiedene Dienste -- Kreditkartenabwicklung, Lieferung und Versand, Reporting -- gleichzeitig auf die Daten zugreifen.
Gelernte Lektionen
  • Du musst Deine Geisteshaltung ändern, um ein wirklich skalierbares System bauen zu können. Nähere dich dem Chaos an, denn im Sinne der Wahrscheinlichkeitstheorie wird alles gut funktionieren. In herkömmlichen Systemen präsentieren wir eine perfekte Welt, wo kein System abstürzt und wir auf die Perfektheit vertrauende komplexe Algorithmen erstellen (auf Vereinbarungen basierende Technologien). Statt dessen geh' davon aus, dass Sachen schief gehen, das ist die Realität, freunde Dich damit an. Setze zum Beispiel eher auf schnell rebootende Systeme und eine schnelle Datenwiederherstellung. Mit einer anständigen Verteilung von Daten und Diensten kannst Du den 100% sehr nahe kommen. Schaffe selbstheilende und selbstorganisierende Transaktionen.
  • Schaffe eine Ich-teile-nicht-mit-Dir-Infrastruktur. Wenn die Infrastruktur gemeinsame Ressource für die Entwicklung und das Deployment wird, kommt es zu denselben Ausfällen wie bei den gemeinsamen Ressourcen in Deinen Logik- und Daten-Schichten. Dies wird zu Blockierungen (locking, blocking, dead lock) führen. Eine Dienste-orientierte Architektur erlaubt die Schaffung eines parallelen und isolierten Entwicklungsprozesses, der die Feature-Entwicklung passend zu deinem Wachstum skaliert.
  • Öffne dein System mit APIs und Du wirst ein Ökosystem rund um deine Applikation schaffen.
  • Der einzige Weg, um ein großes verteiltes System zu verwalten ist, alles so einfach wie möglich zu halten. Halte alles einfach, indem Du sicherstellst, dass es keine versteckten Anforderungen und keine versteckten Abhängigkeiten im Design gibt. Beschränke die Technologie auf das Minimum, das Du benötigst, um Deine vorhandenen Probleme zu lösen. Es hilft der Firma nichts, künstliche und unnötig Komplexitätsschichten zu schaffen.
  • Organisation um Dienste herum führt zu Beweglichkeit. Du kannst Dinge machen, weil die Ausgabe ein Dienst ist. Das erlaubt einen kurzen Weg auf den Markt. Schaffe eine Infrastruktur, die es erlaubt, Dienste sehr schnell zu bauen.
  • Vermeide alle Probleme mit Dingen, die Aufregung verursachen, bevor die tatsächliche Umsetzung begonnen hat.
  • Verwende interne Dienstleistungsverträge (SLA, Service Level Agreement).
  • Jeder kann sehr schnell Webservices für sein Produkt anbieten. Implementiere einfach einen Teil deines Produktes als Dienst und beginnen ihn zu benutzen.
  • Wegen Leistung, Verlässlichkeit und Kostenkontrolle solltest Du dir deine eigene Infrastruktur schaffen. Wenn Du sie selbst baust, musst Du nie sagen, das es abgestürzt ist, weil Firma X Mist gebaut hat. Deine Software ist vielleicht nicht verlässlicher als andere, aber Du kannst Fehlerbehebung, Fehlersuche und Deployment viel schneller durchführen als wenn Du mit Drittanbietern arbeiten würdest.
  • Benutze Messungen und sachliche Debatten, um Gutes und Schlechtes zu trennen. Ich saß in mehreren Präsentationen von Ex-Amazonern und das ist der Aspekt von Amazon, der mir interessanterweise als einzigartig gegenüber anderen Firmen erscheint. Der tiefverwurzelte Grundsatz ist, echten Kunden eine Wahl zu bieten und dann zu sehen, was am besten funktioniert und auf Grundlage dieser Tests Entscheidungen zu treffen.
    Avinash Kaushik nennt das "Den Einfluss der HiPPOs loswerden", der höchstbezahlten Anwesenden (HiPPO, Highest payed people in the room; Wortspiel mit "hippo" - Flusspferd). Das wird mit Techniken wie den A/B-Tests und mit Web-Analytics erreicht. Wenn Du wissen willst, was Du tun sollst, programmiere es, lass die Leute es verwenden, und vergleiche dann, welche Alternative die Ergebnisse liefert, die Du haben möchtest.
  • Schaffe eine Kultur der Genügsamkeit. Amazon verwendet Türblätter als Schreibtische.
  • Wisse darüber Bescheid, was Du brauchst. Amazon hat schlechte Erfahrungen mit einem früheren Empfehlungssystem, bei dem nichts herauskam: "Das war nicht das, was Amazon brauchte. Buchempfehlungen bei Amazon müssen mit spärlichen Daten funktionieren, nur ein paar Bewertungen oder Käufe. Es muss schnell sein. Das System muss mit einer riesigen Zahl von Kunden und einem gewaltigen Katalog skalieren. Und es muss die Entdeckungsfreude fördern, indem es Bücher aus den Tiefen des Katalogs an die Oberfläche befördert, die der Leser von sich aus nie gefunden hätte."
  • Die Nebenprojekte der Leute - die, denen sie nachgehen, weil sie sie interessieren - sind oft die, die den meisten Mehrwert und die höchste Innovation bieten. Unterschätze niemals die Macht des interessierten Herumstreunens.
  • Mach mit. Geh in die Lagerhalle und hilf während des Weihnachtsgeschäfts beim Bucheinpacken mit. Das ist Teamarbeit.
  • Baue eine Scheinseite, auf der Du Tests durchführen kannst, bevor Du eine Funktion ins wahre Leben entlässt.
  • Ein robustes, geclustertes, repliziertes und verteiltes Dateisystem ist perfekt für nur zu lesende Daten, die ein Webserver verwendet.
  • Halte Dir die Möglichkeit offen, ein Update wieder zu entfernen, wenn etwas damit nicht in Ordnung ist. Schreib Dir Werkzeuge dafür, wenn das nötig sein sollte.
  • Wechsle zu einer bis in die Grundfesten Dienste-orientierten Architektur (http://webservices.sys-con.com/read/262024.htm)
  • Achte auf drei Dinge bei Bewerbungsgesprächen: Enthusiasmus, Kreatitivät und Kompetenz. Bei Amazon stand Enthusiasmus als Vorzeichen für Erfolg an einsamer Spitze.
  • Stelle einen Bob ein. Jemanden, der von all dem Zeug Ahnung hat, unglaubliche Erfahrungen beim Fehlersuchen aufweisen kann und - vor allem - es drauf hat, die pressierendsten Probleme zu lösen, indem er einfach nur auf sie stößt.
  • Innovation kann nur von unten kommen. Die, die am nächsten am Problem dran sind haben die besten Ausgangsstellung, um es zu lösen.
  • Jede Organisation, die auf Innovation angewiesen ist, muss das Chaos lieben. Untertanentreue und Gehorsamkeit passen nicht dazu.
  • Kreativität muss von überallher fließen.
  • Jeder muss experimentieren, lernen und es noch einmal versuchen können. Standesdünkel, Gehorsamkeit und Traditionen dürfen keine Macht haben. Wenn Du Innovation brauchst, um zu florieren, dann müssen Messungen alles beherrschen.
  • Lebe Innovationen. Vor der gesamten versammelten Firma würde Jeff Bezos einen alten Nike-Schuh als "Just do it (Tue es einfach)"-Preis an den übergeben, der innovativ ist.
  • Zahle nicht für Leistung. Gib gute Sozialleistungen und hohe Löhne, aber nicht leistungsabhängig. Anerkenne außergewöhnliche Arbeit auf andere Art. Prämienzahlungen klingen gut, aber es ist in großen Organisationen fast unmöglich fair zu sein. Greife auf geldlose Preise zurück, wie einen alten Schuh. Das ist ein Weg "Danke" zu sagen und "Jemand hat Dein Tun bemerkt".
  • Werde schnell groß. Die großen Typen wie Barnes and Nobel sind hinter Dir her. Amazon war weder der erste, noch der zweite oder der dritte Buchladen im Internet, aber seine Vision und sein Schwung haben am Ende gewonnen.
  • Im Datenzentrum wird nur 30% der Personalzeit auf wertschöpfende Infrastrukturaufgaben verwandt. In den verbleibenden 70% wird sich um Hardwarebeschaffung, Softwaremanagement, Lastverteilung, Durchsicht, Skalierungsaufgaben etc. gekümmert.
  • Verbiete direkten Datenbankzugriff durch Kunden. Das bedeutet, dass Du deinen Dienst skalieren und verlässlicher machen kannst, ohne deine Kunden einzubeziehen. Das ist in etwa wie Google Fähigkeit, unabhängig Verbesserungen in ihrem System anzubringen - zum Vorteil aller ihrer Applikationen.
  • Schaffe einzelnstehende vereinheitlichte Dienst-Zugriffs-Mechanismen. Das erlaubt Dienste einfach zusammenzufassen, dezentrale Anfrage-Durchleitung, verteilte Anfrage-Verfolgung und andere fortgeschrittene Infrastruktur-Techniken.
  • Amazon.com über eine Webservice-Schnittstelle für jeden Entwickler in der Welt kostenlos verfügbar zu machen, war auch so ein großer Erfolg, weil es so viel Innovation hervorgebracht hat, die sie sich gar nicht hätten ausdenken oder gar selbst hätten programmieren können.
  • Die Entwickler wissen selber am besten, welche Werkzeuge sie am produktivsten machen und welche Werkzeuge die besten für die Aufgabe sind.
  • Zwing den Entwicklern nicht zu viele Einschränkungen auf. Biete Anreize für einige Dinge an, wie zum Beispiel die Anbindung an das Beobachtungssystem oder andere Infrastruktur-Werkzeuge. Für den Rest aber erlaube dem Team so unabhängig wie möglich zu funktionieren.
  • Entwickler sind wie Künstler; sie produzieren ihre beste Arbeit, wenn sie die Freiheit haben, sie zu tun. Aber sie brauchen gute Werkzeuge. Halte viele Unterstützungswerkzeuge vor, die die Selbsthilfe ermöglichen. Unterstütze eine Umgebung um die Dienste-Entwicklung, die nicht zum Gegenstand der Entwicklung wird.
  • Du hast es gebaut, Du betreibst es. Das bringt Entwickler in Kontakt mit dem Tag-für-Tag-Betrieb ihrer Software. Es bringt sie außerdem in den Tag-für-Tag-Kontakt mit dem Kunden. Diese Kundenfeedbackschleife ist grundlegend wichtig für die Verbesserung der Qualität der Dienste.
  • Entwickler sollten alle zwei Jahre einige Zeit im Kundenservice zubringen. Dort hören sie wirklich mal Kundendienstanfragen, beantworten Kundendienst-E-Mails und verstehen wirklich den Einfluss der Dinge, die sie als Technologen machen.
  • Benutze eine "Kundenstimme", eine reale Geschichte eines Kunden über einen bestimmten Teil des Produktes. Das hilft den Managern und Entwicklern sich mit dem Fakt auseinanderzusetzen, das wir etwas für echte Leute erschaffen. Kundendienststatistiken sind ein früher Anzeiger, wenn Du etwas falsch machst und dafür, was die wirklichen Schmerzpunkte für die Kunden sind.
  • Infrastruktur ist für Amazon, wie für Google, eine großer Wettbewerbsvorteil. Sie können sehr komplexe Applikationen aus sehr einfachen Diensten bauen. Sie können ihren Betrieb unabhängig skalieren, unabhängige Systemverfügbarkeit verwalten und neue Dienste schnell einführen ohne die Notwendigkeit einer umfangreichen Umstellung.