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.

1 Kommentar:

Anonym hat gesagt…

Wahnsinn, das war mir irgendwie garnicht so bewusst, dass Amazon so wahnsinnig ausgetüftelte Systeme hat.