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.

Keine Kommentare: