Original: http://natishalom.typepad.com/nati_shaloms_blog/2007/11/lessons-from--1.html 15. November 2007
Autor: Nati Shalom
Übersetzung: Sebastian Wallroth
Ich bin gerade von QCon in San Francisco zurückgekehrt. Mir hat die Konferenz wirklich gefallen. Die Präsentationen und Panels waren von hoher Qualität. Mir hat auch die Tatsache gefallen, dass es persönlich genug war, um interessante Personen aus der Wirtschaft zu treffen. Mit gefiel insbesondere die Diskussion mit Brian Zimmer von Orbitz, wo man Jini als Teil des Backbones verwendet, wie auch mit Randy Shoup (eBay), der am Freitag eine exzellente Präsentation über die eBay-Architektur gab. Ein "Gut gemacht!" geht an Floyd und Trifork (Aino, Roxanne und der Rest des Teams) für die Organisation dieses Ereignisses.
Im Track "Architekturen, über die Du dich schon immer gewundert hast" präsentierten Second Life, eBay, Yahoo, LinkedIn und Orbitz, wie sie mit den verschiedenen Aspekten ihrer Anwendungen umgehen, wie zum Beispiel der Skalierungsfähigkeit. Es sind einige Lektionen, die ich gelernt habe und die ich gerne teilen möchte.
Diclaimer: Die nachfolgenden Informationen basieren auf Notizen, die ich während der Sitzungen machte. Es handelt sich nicht um detaillerte Berichterstattungen der einzelnen Präsentationen sondern vielmehr um die Zusammenfassungen meiner persönlichen Interpretationen und Schlussfolgerungen. Lesen sie gerne auch die Präsentationen des Tracks "Architekturen. über die Du dich schon immer gewundert hast" im Original.
Der Stack
Dieses Thema scheint ganz schön emotional zu sein, hauptsächlich zwischen dem LAMP- und dem Java-Lager, wie ich erfahren musste, nachdem ich "Warum die meisten hochskalierten Webseiten nicht in Java geschrieben sind" veröffentlicht hatte. Obgleich der LAMP-Stack in im Bereich hochskalierter Webanwendungen sehr populär ist sind die Umgebungen sehr heterogen, insbesondere bei den großen Seiten: Yahoo und eBay natürlich und teilweise gilt das auch für Google und Amazon. Tatsächlich verwendet eine Anwendung von Google GigaSpaces. Eine offensichtliche Erklärung für diese Heterogenität ist der Fakt, dass viele der großen Seiten verschiedene Firmen übernommen und integriert haben, wovon jede ihre eigenen Implementierungsstack mitbrachte.
Es gibt nur einige wenige (LinkedIn, eBay, Orbitz, Yahoo Bix) die Java als ihre Kernsprache verwenden. (Beachte, dass die meisten Anwendungen von Yahoo LAMP als ihre Kern-Stack verwenden. Yahoo Bix ist eine Ausnahme.) Der Linux-Apache-Tomcat-Spring-Hibernate-Stack ist üblich bei den Java verwendenden Seiten. Wenn ich mich recht erninnere verwendet nur eBay den kompletten J2EE-Stack, aber eBay scheint nur einen kleinen Teil von dessen Funktionalität zu verwenden. Second Life hat eine ziemlich ungewöhnliche Architektur: man benutzt dort zumeist C++ und Python und sagte, dass man der Skalierungsfähigkeit wegen zu Web Services und SOA migrieren will. Bei Orbitz verwendet man Jini als Dienste-Framework und hat interessante Dinge mit Spring angestellt, um Jini für seine Entwickler zu vereinfachen. Man hat dort zudem mit Spring Remote-Funktionalität entwickelt, um die Dienste-Interaktion zu vereinfachen.
Integrationstrategie
Integration ist eine große Aufgabe für all diese Seiten, wenn aufgekaufte Firmen integriert werden. Im Falle von eBay und Yahoo hatten die Firmen, die sie gekauft hatten ganz andere Architekturen und in vielen Fällen auch andere Implementierungs-Stacks. Ihre Methode ist, sich nicht in die Implementierungsdetails einzumischen (wenigstens nicht zu Anfang), sondern sich auf eine schnelle Integation zu konzentrieren -- mit dem Endkunden im Blick. Sowohl Yahoo als auch eBay bauten ein allgemeines Framework, um diesen Integrationsanforderungen Genüge zu tun. Großen Aufwand kostete die Ermöglichen eines allgemeinen Benutzeridentifizierungssystems (Single Sign-On) wie auch ein Lastverteilungsschema. Bei eBay wählte man Apache als allgemeines Modul und erweiterte es ein bisschen mit eigenen Modulen. Yahoo baute einen Identifizierungsverwaltungsdienst, der auf Erweiterungsfähigkeit ausgelegt ist. Erweiterbarkeit meint hier die Möglichkeit der Anwendungen ihre eigenen Daten dem Benutzerprofil hinzuzufügen, dass dann für Personalisierung und andere Zwecke verwendet werden kann.
Anwendungsarchitektur
Niemanden wird überraschen, dass diese Anwendungen in einer schichtbasierten Architektur aufgebaut sind. Wenn man dort über Partitionierung spricht, meint man im Allgemeinen die Datenschicht.
Die Datenbankschicht
MySQL ist definitiv die beliebteste Datenbank. Es ist interessant (und überraschend) zu entdecken, wieviele Ressourcen Organisationen wie eBay und Google in die Erweiterung von MySQL gesteckt haben und es erfreut zu sehen, dass sie diese Erweiterungen der MySQl-Gemeinschaft übereignet haben. Nach Dan Pritchett (eBay) kann man eBay Erweiterungen mit MySQL dast dasselbe anstellen wie mit der Datenbank von Oracle. In "Die Zukunft ist wolkig" erfährt etwas man über den Kontext der MySQL-Erweiterungen von Google. Die Oracle-Datenbank wird weiterhin von einigen Seiten genutzt, aber überlicherweise gleichzeitig auch MySQL.
Die meisten Seitenbetreiber sagten, dass sie ihre Daten im Speicher hielten, um den Ein-/Auslese-Overhead der Datenbank zu minimieren. Das tun sie jedoch nur für Szenarios mit überwiegend Leseoperationen. Einer der Vortragenden (ich glaube es war Dan Pritchett) meinte dass der Grund für den begrenzten Gebrauch des Cachings in der Natur der Datenverwendungsmuster liege. Jeder ihrer Server könne jederzeit jedes Datum ohne bestimmte Reihenfolge anfordern. Weil die Datenvolumen mit denen sie es zu tun haben so gewaltig sind, können sie sie nicht komplett im Speicher halten. Die inkonsistenten Datenverwendungsmuster ihrer Anwendungen minimieren das Potenzial der Leistungsgewinne, die im Caching liegen.
Ich denke diese Aussage sollte erneut untersucht werden, weil es auf diesem Gebiet in den letzten Jahren große Fortschritte gegeben hat, die viele der Voraussetzungen ändern, die derzeit hier in Betracht gezogen werden (aber das ist ein anderes Thema). Viele Seiten benutzen Memcached als ihre Cachingschicht. Beispielsweise gibt es in dieser Studie über die Architektur von TypePad Hinweise darauf, dass Memcached verwendet wird, um Zähler, Sets, Status und heavyweight Daten zu speichern.
BenachrichtigungsschichtAutor: Nati Shalom
Übersetzung: Sebastian Wallroth
Ich bin gerade von QCon in San Francisco zurückgekehrt. Mir hat die Konferenz wirklich gefallen. Die Präsentationen und Panels waren von hoher Qualität. Mir hat auch die Tatsache gefallen, dass es persönlich genug war, um interessante Personen aus der Wirtschaft zu treffen. Mit gefiel insbesondere die Diskussion mit Brian Zimmer von Orbitz, wo man Jini als Teil des Backbones verwendet, wie auch mit Randy Shoup (eBay), der am Freitag eine exzellente Präsentation über die eBay-Architektur gab. Ein "Gut gemacht!" geht an Floyd und Trifork (Aino, Roxanne und der Rest des Teams) für die Organisation dieses Ereignisses.
Im Track "Architekturen, über die Du dich schon immer gewundert hast" präsentierten Second Life, eBay, Yahoo, LinkedIn und Orbitz, wie sie mit den verschiedenen Aspekten ihrer Anwendungen umgehen, wie zum Beispiel der Skalierungsfähigkeit. Es sind einige Lektionen, die ich gelernt habe und die ich gerne teilen möchte.
Diclaimer: Die nachfolgenden Informationen basieren auf Notizen, die ich während der Sitzungen machte. Es handelt sich nicht um detaillerte Berichterstattungen der einzelnen Präsentationen sondern vielmehr um die Zusammenfassungen meiner persönlichen Interpretationen und Schlussfolgerungen. Lesen sie gerne auch die Präsentationen des Tracks "Architekturen. über die Du dich schon immer gewundert hast" im Original.
Der Stack
Dieses Thema scheint ganz schön emotional zu sein, hauptsächlich zwischen dem LAMP- und dem Java-Lager, wie ich erfahren musste, nachdem ich "Warum die meisten hochskalierten Webseiten nicht in Java geschrieben sind" veröffentlicht hatte. Obgleich der LAMP-Stack in im Bereich hochskalierter Webanwendungen sehr populär ist sind die Umgebungen sehr heterogen, insbesondere bei den großen Seiten: Yahoo und eBay natürlich und teilweise gilt das auch für Google und Amazon. Tatsächlich verwendet eine Anwendung von Google GigaSpaces. Eine offensichtliche Erklärung für diese Heterogenität ist der Fakt, dass viele der großen Seiten verschiedene Firmen übernommen und integriert haben, wovon jede ihre eigenen Implementierungsstack mitbrachte.
Es gibt nur einige wenige (LinkedIn, eBay, Orbitz, Yahoo Bix) die Java als ihre Kernsprache verwenden. (Beachte, dass die meisten Anwendungen von Yahoo LAMP als ihre Kern-Stack verwenden. Yahoo Bix ist eine Ausnahme.) Der Linux-Apache-Tomcat-Spring-Hibernate-Stack ist üblich bei den Java verwendenden Seiten. Wenn ich mich recht erninnere verwendet nur eBay den kompletten J2EE-Stack, aber eBay scheint nur einen kleinen Teil von dessen Funktionalität zu verwenden. Second Life hat eine ziemlich ungewöhnliche Architektur: man benutzt dort zumeist C++ und Python und sagte, dass man der Skalierungsfähigkeit wegen zu Web Services und SOA migrieren will. Bei Orbitz verwendet man Jini als Dienste-Framework und hat interessante Dinge mit Spring angestellt, um Jini für seine Entwickler zu vereinfachen. Man hat dort zudem mit Spring Remote-Funktionalität entwickelt, um die Dienste-Interaktion zu vereinfachen.
Integrationstrategie
Integration ist eine große Aufgabe für all diese Seiten, wenn aufgekaufte Firmen integriert werden. Im Falle von eBay und Yahoo hatten die Firmen, die sie gekauft hatten ganz andere Architekturen und in vielen Fällen auch andere Implementierungs-Stacks. Ihre Methode ist, sich nicht in die Implementierungsdetails einzumischen (wenigstens nicht zu Anfang), sondern sich auf eine schnelle Integation zu konzentrieren -- mit dem Endkunden im Blick. Sowohl Yahoo als auch eBay bauten ein allgemeines Framework, um diesen Integrationsanforderungen Genüge zu tun. Großen Aufwand kostete die Ermöglichen eines allgemeinen Benutzeridentifizierungssystems (Single Sign-On) wie auch ein Lastverteilungsschema. Bei eBay wählte man Apache als allgemeines Modul und erweiterte es ein bisschen mit eigenen Modulen. Yahoo baute einen Identifizierungsverwaltungsdienst, der auf Erweiterungsfähigkeit ausgelegt ist. Erweiterbarkeit meint hier die Möglichkeit der Anwendungen ihre eigenen Daten dem Benutzerprofil hinzuzufügen, dass dann für Personalisierung und andere Zwecke verwendet werden kann.
Anwendungsarchitektur
Niemanden wird überraschen, dass diese Anwendungen in einer schichtbasierten Architektur aufgebaut sind. Wenn man dort über Partitionierung spricht, meint man im Allgemeinen die Datenschicht.
Die Datenbankschicht
MySQL ist definitiv die beliebteste Datenbank. Es ist interessant (und überraschend) zu entdecken, wieviele Ressourcen Organisationen wie eBay und Google in die Erweiterung von MySQL gesteckt haben und es erfreut zu sehen, dass sie diese Erweiterungen der MySQl-Gemeinschaft übereignet haben. Nach Dan Pritchett (eBay) kann man eBay Erweiterungen mit MySQL dast dasselbe anstellen wie mit der Datenbank von Oracle. In "Die Zukunft ist wolkig" erfährt etwas man über den Kontext der MySQL-Erweiterungen von Google. Die Oracle-Datenbank wird weiterhin von einigen Seiten genutzt, aber überlicherweise gleichzeitig auch MySQL.
Die meisten Seitenbetreiber sagten, dass sie ihre Daten im Speicher hielten, um den Ein-/Auslese-Overhead der Datenbank zu minimieren. Das tun sie jedoch nur für Szenarios mit überwiegend Leseoperationen. Einer der Vortragenden (ich glaube es war Dan Pritchett) meinte dass der Grund für den begrenzten Gebrauch des Cachings in der Natur der Datenverwendungsmuster liege. Jeder ihrer Server könne jederzeit jedes Datum ohne bestimmte Reihenfolge anfordern. Weil die Datenvolumen mit denen sie es zu tun haben so gewaltig sind, können sie sie nicht komplett im Speicher halten. Die inkonsistenten Datenverwendungsmuster ihrer Anwendungen minimieren das Potenzial der Leistungsgewinne, die im Caching liegen.
Ich denke diese Aussage sollte erneut untersucht werden, weil es auf diesem Gebiet in den letzten Jahren große Fortschritte gegeben hat, die viele der Voraussetzungen ändern, die derzeit hier in Betracht gezogen werden (aber das ist ein anderes Thema). Viele Seiten benutzen Memcached als ihre Cachingschicht. Beispielsweise gibt es in dieser Studie über die Architektur von TypePad Hinweise darauf, dass Memcached verwendet wird, um Zähler, Sets, Status und heavyweight Daten zu speichern.
Bei der Ermöglichung von Skalierbarkeit gibt es einen Trend weg von synchronen RPC-Amsätzen hin zu asynchroner Kommunikationen (Ich gehe später darauf ein, wenn ich mich der Skalierbarkeit zuwende.) Man könnte glauben, dass JMS überall verwendet wird um diese Anforderung zu erfüllen. Es scheint aber, dass fast jeder Vortragende sagte, dass sie ihren eigenen Banchrichtigungsstack gebaut hätten. Die Gründe scheinen zu sein:
- Die Anforderungen für effiziente inhaltsbasierte Benachrichtigungen: Der erforderliche Benachrichtigungstyp ist weder direkt Punkt-zu-Punkt noch pub/sub. Er ist mehr assoziativer Natur. Es ist eine häufige Anforderung, dass man erst die Nachricht ansehen und durch sie browsen will, bevor man sich entscheidet, ob man sie auswählen will (und die JMS-Auswahloberfläche ist genau darauf beschränkt)
- Konsistenz: Um Teilfehler und die Notwendigkeit verteilter Transaktionen zu vermeiden speichert man seine Events in der selben Partition wie die Daten. Auf diese Art kann man sicherstellen, dass die Nachrichten in die selbe PArtition wie die Daten geleitet werden (und vermeidet verteilte Transaktionen)
- Man konnte diese Schicht basierend auf spezifischen Anforderungen und Semantiken feinjustieren
Das erinnert mich an den ursprünglichen Grund für mein Interesse an JavaSpaces als ich an einem B2B-Exchange arbeitete und ähnliche Anforderungen hatte. JavaSpaces macht genau das. Es bietet beispielsweise einen Datenbus, der sowohl Benachrichtigungen und Daten in einer einzigen konsistenten Implementierung kombiniert.
An Skalierbarkeit nicht erst nachher denkenEin Botschaft, die während der Konferenz von fast allen Architekten immer wieder verkündet wurde, lautete, dass an Skalierbarkeit nicht erst nachher gedacht werden sollte. Während ich mit dieser Aussage übereinstimme, enthüllten alle Fallstudien auf der QCon eine interessante Tatsache: Die meisten der beschriebenen Seiten wurde ursprünglich nicht aus Skalierbarkeit ausgelegt (es gibt eine berühmte Geschichte, dass eBay als einzelne DLL-Datei gestartet sei). Trotzdem schienen alle in der Lage gewesen zu sein, durche mehrere Zyklen der Erneuerung der Architektur zu gehen, wann immer Skalierbarkeit ein großes Problem wurde. KAnn man daraus etwas lernen?
Meiner Ansicht nach werden , weil heutige Ansätze für Skalierbarkeit einen riesigen Grad an Komplexität aufweisen (nicht zu vergessen, dass viele Entwickler Skalierbarkeit nicht richtig verstehen), Skalierbarkeit und Time-to-Market als zwei sich widersprechende Ziele angesehen. Mit anderen Worten, der Versuch eins davon zu erreichen wird als ein Riskieren des anderen angesehen. Die Lehre könnte darum sein, dass man Skalierbarkeit nicht gleich vom ersten Tage an implementieren muss, sondern, dass man sich bewusst machen muss, was Skalierbarkeit bedeutet. Auch wenn man Kompromisse eingeht, um die Anforderungen der Time-to-Market zu berücksichtigen muss vorausplanen, um zur rechten Zeit umstellen zu können.
Werner Vogel (Amazon CTO) drückte ein ähnliches Gefühl aus als er sagte: "Skaliere später. Es ist soooo schwierig es richtig zu machen, dass manchmal der Aufwand es vorher zu erledigen nicht gerechtfertigt ist. Oder überlasse es jemandem, der die Kenntnisse besitzt und es bereits getan hat ... wie Amazon (denke an S3 - Virtual Disk, etc.)."
Skalierbarkeit -- Wie man es richtig macht
Und hier kommt, worauf Du gewartet hast:
- Asynchrone ereignisgesteuerte Entwürfe: Vermeide so gut es geht synchrone Interaktion mit der Daten- oder der Geschäftslogikschicht. Stattdessen verwende einen ereignisgesteuerten Ansatz und Workflow
- Partitionierung/Shards: Man muss das Datenmodell so modellieren, dass es mit dem Partitionerungsmodell zusammenpasst
- Gleichzeitige Ausführung: Gleichzeitige Ausführung sollte genutzt werden, um so viel wie möglich aus den verfügbaren Ressourcen herauszuholen. Ein guter Platz für gleichzeitige Ausführung ist die Verarbeitung der Benutzeranfragen. In diesem Fall können mehrfache Instanzen der Dienste die Anfragen vom Benachrichtigungsdienst entgegennehmen und sie gleichzeitig ausführen. Ein anderer Anwendungsfall für gleichzeitige Ausführung ist die Verwendung von MapReduce für die Ausführung aggregierter Anfragen auf partitionierter Daten.
- Replikation (vorwiegend lesender Zugriff): In Szenarios mit vorwiegend lesenden Zugriffen (LinkedIn scheint in diese Kategorie zu fallen) kann Datenbankreplikation helfen, die Lese-Last zu verteilen, indem man Lese-Anfragen zwischen den replizierten Datenbankknoten verteilt
- Konsistenz ohne verteilte Transaktionen: Das war einer der Hauptpunkte der Konferenz, der auch während eines Panels, an denen ich teilnahm, die Funken sprühen ließ. Ein Argument war, dass man, um Skalierbakeit zu erreichen, die Konsistenz opfern müsse und die Konsistenz in Anwendungen sicherstellen müsse mittels solcher Dinge wie optimistic locking und asynchroner Fehlerbehandlung. Man nimmt außerdem an, dass man Idempotenz im Code abhandeln muss. Meiner Meinung nach erzeugt dieses Softwaremuster zur Verbesserung der Skalierbarkeit zusätzliche Komplexität und ist deshalb fehleranfällig. Während eines anderen Panels behauptete Dan Pritchett, dass es Wege gäbe, diesen Grad von Komplexität zu vermeiden und trotzdem das gleiche Ziel zu erreichen, wie er es in seinem Blogartikel beschreibt.
- Schiebe die Datenbank in den Hintergrund - Es bestand eine starke Einstimmigkeit darüber, dass die Datenbankengstelle nur behoben werden kann, wenn die Datenbankinteraktionen im Hintergrund stattfinden
Andere Tips
- Yahoo Bix - entwickelte einen Netzwerk-Sniffer, um Datenbankaufrufe zu überwachen und die Verwendung von Hibernate zu optimieren. Das stellt eines der interessanten Tauschgeschäfte in der Datenbankabstraktionsschicht dar: indem man abstrahiert, was hinter den Kulissen passiert, erlaubt man den Entwicklern sozusagen nichtoptimierten Code zu schreiben. Der Sniffer-Ansatz hilft herauszufinden, was hinter den Kulissen passiert und verwendet diese Informationen, um den Code von Hibernate zu optimieren.
- LinkedIn - verwendet Lucene (und nicht die Datenbank) für die Indizierung. Wenn man nach einem effizienten Weg sucht, Indizierung und Suche in den Indexen zu betreiben, ist eine Datenbank wahrscheinlich nicht das Mittel der Wahl. Lucene bietet eine viel effizientere Implementierung für diese Zwecke. Ich würde auch empfehlen, Compass zu verwenden. Und hier kommen brandheiße Neuighkeiten: Ich habe gerade von Shay Banon, dem Besitzer des Compass-Projektes erfahren, dass er an einer Lucene-Integration in einen im Speicher geclusterten Index (GigaSpaces nutzend) arbeitet. Das ist sehr spannend, weil das ermöglichen wird, einen Lucene-Index verteilt zu speichern. Es wird außerdem ermöglichen, den Inhalt einer Webseite zu indizieren und eine Google-artige Suchanfrage zu stellen!
Die für Skalierbarkeit überwiegend verwendeten Softwaremuster führen zu mehr Komplexität. Beispielsweise muss man mit Teil-Fehler-Szenarios umgehen und Idempotenz im Code abhandeln. Das führt zu einem hohenGrad von Komplexität und ist der Hautpgrund, warum die meisten Architekten und Entwickler mit einfacheren Ansätzen beginnen, die nicht sklaierbar sind, wohl wissend, dass sie später einen kompletten Neuentwurf ihrer Anwendung machen müssen, um den Anforderungen gerecht zu werden. Second Life hielt einen ganzen Vortrag zu diesem Thema.
Ich sehe unsere Herausforderung bei GigaSpaces darin, diesen Widerspruch soweit wie möglich zu eleminieren, indem wir Skalierbarkeit zu einfach wie möglich machen, so dass Skalierbarkeitssoftwaremuster von Anfang an einfach implementiert werden können und so dem Geschäft ermöglicht wird auf die erforderliche inkrementelle Art zu wachsen. Das war tatsächlich der Hauptpunkt meiner Präsentation auf der QCon mit dem Titel "Drei Schritte um eine schichtenbasierte Ursprungsanwendung in dynamisch skalierbare Dienste umzuwandeln." Ich werde mehr Details zu diesem Ansatz in zukünftigen Artikeln beschreiben.
