Autor: Jay Pipes
Übersetzung: Sebastian Wallroth
So, eine Anzahl von Leuten verlangte ein paar mehr Informationen, als in der an CIOs gerichteten MySQL-Marketing-Kampagne von neulich angeboten wurden: "Die zwölf Tage des MySQL Scale-out". Ich wollte einen Blog-Artikel schreiben, der sich der nach Inhalten lechzenden MySQL-Community annimmt, in dem ich diskutiere, was genau der Begriff "scale-out" (horizontales Skalieren) bedeutet.
Vergleiche zwischen horizontalem im Unterschied zu vertikalem Skalieren
Was ist überhaupt Skalieren? Einfach ausgedrückt ist es die Fähigkeit einer Anwendung wachsende Anforderungen an Durchgang, Nutzung und Kapazität zu verkraften. Sowohl horizontale als auch vertikale Skalierungsstrategien dienen der Fähigkeit eines Systems dieses Wachstum zu verkraften. Ich sehe eine Tendenz, auf die auch Jeremy hinwies, die Beziehung zwischen den Strategien zu vereinfachen und die horizontale Skalierungsarchitektur auf ein Podest zu erheben, ohne die Herausforderungen, die mit seiner Implementierung einhergehen wirklich zu verstehen.
Manchmal glaube ich, dass die Leute "scale out" hören und diese Strategie mit einem Ansatz mit Computerclustern verwechseln, bei dem Hunderte von Billigcomputern und große Speicherbänke und Festplatten sich wie ein einziger Computer verhalten. Skalieren bedeutet nicht Computercluster - weder horizontales noch vertikales Skalieren.
Im Allgemeinen bezieht sich der Term "vertikales Skalieren" (Scale-up) auf die Strategie, Kapazität hinzuzufügen, indem man die Kapazität der darunter liegenden Hardware erhöht - man kauft eine größere Kiste mit mehr Prozessoren oder Speicher, um die Anwendung darauf laufen zu lassen. Horizontale Skalierungsansätze auf der anderen Seite kann man sich im Allgemeinen als das Hinzufügen von Kapazität durch das Hinzufügen zusätzlicher Server zur Anwendungsarchitektur vorstellen. Einfach ausgedrückt sind dies die drei wichtigsten Dinge, die meinem Gefühl nach vertikale von horizontale Skalierungsansätzen unterscheiden:
- Vertrauen auf Hardware vs. Vertrauen auf Software
- Enterprise-Hardware vs. normaler Hardware
- Plötzliche vs. schrittweiser Kapazitätssteigerung
- Zentralisierte vs. verteilte Anwendungsarchitektur
Vertrauen auf Hardware vs. Vertrauen auf Software
Für Shops mit einem vertikalen Skalierungsansatz ist die Lösung, wenn der Durchsatz der datenbankzentrierten Anwendungen auf der vorhandenen Hardware die Obergrenze erreicht, die Kapazität der Datenbankserver so zu erhöhen, so dass sie mehr Such- und Transaktionsanfragen verkraften können, ohne den Anwendungscode verändern zu müssen. Der fettgedruckte Punkt ist wichtig: indem man die Kapazität der Hardware erhöht, auf der der Datenbankserver läuft, muss man den Anwendungscode überhaupt nicht ändern; das ist natürlich ein Vorteil für die Entwicklungsabteilung, es bedeutet weniger Arbeit für sie!
Tja, aber es gibt eine paar Probleme mit diesem Ansatz, auf die man achten muss, die ich in den Abschnitten über das schrittweise Hinzufügen von Kapazität und gewachsener Anwendungskomplexität hervorhebe.
Enterprise-Hardware vs. normaler Hardware
Wie ich im vorigen Abschnitt beschrieb, bedeutet vertikales Skalieren typischer Weise das Erhöhen der Kapazität durch die Erhöhung der Kapazität der zugrundeliegenden Hardware. Es gibt einen weiteren Punkt: Die Hardware selbst unterscheidet sich bei vertikalen und horizontalen Skalierungsmodellen. Vertikale Modelle tendieren zu "Enterprise-Hardware", während horizontale Modelle zu "normaler Hardware" tendieren. Ich möchte zwei Zitate von Jeremy Cole und Raj Thukral von Pythian hierzu anführen, die meiner Meinung nach etwas Licht auf diesen Unterschied zwischen vertikaler und horizontaler Skalierung werfen.
Zuerst Jeremys Versuch, den Mythos zu widerlegen, dass mit normaler Hardware "superbillige" Hardware gemeint ist. (Die Hervorhebungen stammen von mir.)
Oft hört man den Begriff "normale Hardware" im Zusammenhang mit horizontaler Skalierung. Während mistige Hardware durchaus auch normal ist, ist eigentlich gemeint, dass wenn man mit einer low-end $40k-Maschine feststeckt und mit dem Gedanken auf ein Upgrade auf eine $250k- und später vielleicht auf eine $1M-Maschine spielt, man Datenverteilung (data partitioning) und einige, nun ja, $5k-Maschinen verwendet. Es ist keine $1k-1-Festplatte-Mist-Maschine gemeint, wie ich bereits sagte. Was ist nun mit einer "normalen" Maschinen gemeint? Nun, eine Maschine mit standardisierten, üblichen Komponenten, bei der der Preis vom Markt und nicht von einer einzelnen Maschine festgelegt wird. Man verwendet normale Hardware mit einem ausgewogenen Preis-Leistungsverhältnis.
Ich stimme im höchsten Maße mit Jeremys Einschätzung überein. Standardisierte, übliche Komponenten, die nicht von einer einzelnen Firma kontrolliert werden, sind unlösbar mit dem horizontalen Skalierungsmodell verbunden, wie auch "Enterprise-Hardware" mit vertikalen Skalierungsmodellen verbunden ist. Raj bot mir eine Erklärung in einer Mail, die er mir neulich sandte:
... die meisten Leute, die Oracle zu laufen haben, tendieren dann auch dazu, auf Markenkisten mit vielen Pferdestärken zu setzen. Ich schätze, wenn man sechs Dinger für eine Lizenz bezahlt, dann kann man sich auch eine gute Kiste leisten. Mit MySQL tendiert man im Allgemeinen zu lower-end Hardware der Weißwarenklasse.
Vielleicht hat Raj es auf den Punkt gebracht. Vielleicht hat der Grund, warum vertikale Skalierungsmodelle mit higher-end Maschinen verknüpft sind einfach mit dem Vergleich der Kosten der Software und den Kosten der Hardware zu tun? Schlussendlich liegt es wohl in der Natur des Menschen zu denken, dass je teurer etwas ist, desto mehr es auch von teureren Sachen umgeben sein muss... :-)
Ich denke, dass es einen weiteren Grund gibt: Oracle kann bessere Hardware effizienter nutzen als MySQL. Mehr darüber später...
Kapazität schrittweise hinzufügen?
In einem vertikalen Skalierungsmodell ist es sehr unwahrscheinlich, dass der Anwendung Kapazität schrittweise hinzugefügt wird. Beispielsweise angenommen, dass man eine Anwendung hat, die auf Oracle 10g Enterprise Edition auf einer ordentlichen Sun-Kiste mit 16GB RAM und, nun ja, 4 Prozessoren läuft. Jetzt erreicht man einen Punkt, an dem die Anwendungsleistung leidet, weil Oracle die Hardware bis ins Letzte ausnutzt und mehr Speicher braucht. Man muss also die Leistung verbessern und anstatt irgendwelche Änderungen am Anwendungscode vorzunehmen beschließt man, die Kapazität der Hardware zu erhöhen, indem man einen neuen Sun-Server mit 8 Prozessoren und 32GB RAM anschafft.
OK, jetzt hat man das Leistungsproblem gelöst, weil Oracle jetzt mehr Speicher und mehr Prozessoren zu Verfügung stehen, um die Anfragen zu bearbeiten. Es ist nur eben unwahrscheinlich, dass der neue Server richtig ausgelastet wird und man einen guten Gegenwert für das Geld kriegt, dass man für die neue Hardwarekapazität ausgegeben hat. Angenommen man braucht zwei Jahre, um die Kapazität des ursprünglichen 4 Prozessor/16GB RAM Sun-Servers auszulasten. Man wird etwa ein Jahr oder mehr brauchen, die neue Hardware voll auszulasten. Es ist ja schön und gut, dass man sich für eine Weile keine Sorgen mehr über die Leistung meines Datenbankservers machen muss. Aber es ist im Grunde eine Vergeudung von Hardwareleistungskraft in der Zeit, in der der Durchsatz sich innerhalb des nächsten Jahres erhöht. Die Grafik unten illustriert den Punkt: Hardwarekapazität und Rechenleistung werden vergeudet, während man darauf "wartet", dass die neue Hardware voll ausgelastet wird - wenn das jemals eintritt... Die lila Fläche zeigt die vergeudete Rechnerleistung der Hardware über die Zeit.
In einem horizontalen Skalierungsmodell wird Hardwarekapazität nicht auf so dramatische Art hinzugefügt. Server mit jeweils weniger Kapazität als die oben beschriebenen vertikalen Skalierungsserver werden der Anwendung mit der Zeit schrittweise, auf gestaffelte und konsistentere Art hinzugefügt. Wenn man eine horizontale Skalierungsstrategie anwendet, um dieselbe Steigerung der Anwendungslast zu bewältigen, wird man Kapazität 13k-Schritten hinzufügen. Wie man sehen kann, ist die lila Fläche, die die vergeudete Rechnerleistung darstellt, deutlich kleiner.
Der Gewinn der verminderten Vergeudung ist ziemlich offensichtlich. An Stelle einer einmaligen großen Ausgabe für die kräftigere Sun-Kiste verteilen sich die Kosten über die Zeit. Investoren und Vorstände sind froh, wenn Kosten kontrolliert und schrittweise ansteigend sind und das Ausgleichsrisiko der Sofortkosten minimiert ist, falls die Anwendungsbelastung langsamer steigt als erwartet, was zusätzliche Rechenleistung unnötig werden lassen kann.
Angestiegene Komplexität der Anwendung?
Schrittweise ansteigende Kosten und Kapazität führen jedoch zu anderen Aufwänden - insbesondere eine angestiegene Komplexität der Anwendungsarchitektur um die Aufteilung der Anwendungsanfragen der verschiedenen Server unserer Architekturtopologie zu verarbeiten. Es ist aufwändiger mit dieser horizontalen Skalierungsarchitektur umzugehen, sowohl konzeptionell als auch bei der Implementierung. Kenntnis der horizontale Anwendungsskalierungsarchitektur ist notwendig und die Profis, die diese Kenntnisse haben, sind nicht billig.
Die horizontale Skalierungsfähigkeit von MySQL kann nicht mit der von Oracle verglichen werden
Hier ist eine Henne-Ei-Frage für dich. Was war zuerst da: die horizontale Skalierungsarchitektur die MySQL bietet oder das Design von MySQL für horizontales Skalieren? Lustige Frage? Nicht wirklich. So sehr ich MySQL auch liebe, glaube ich doch nicht, dass MySQLs Fähigkeit, eine horizontalen Skalierungsarchitektur zu unterstützen dem Konzept von MySQL bevorzugter horizontaler Skalierungsarchitektur vorausging.
Tatsächlich glaube ich, dass das, was wir heute das "horizontale Skalierungsmodell" nennen - das Modell, für das mit der "Der zwölf Tage der Scale Out"-Kampagne geworben wurde - der Unfähigkeit MySQLs entspringt im gleichen Maße vertikal zu skalieren, wie Oracle das kann.
Schockiert über meine Blasphemie? :-) Musst Du nicht sein. Das ist nur eine Beobachtung, die ich für richtig halte: das horizontale Skalierungsmodell - ein Modell, von dem ich ehrlich glaube, dass es das Skalierungsmodell der Zukunft ist - ist das einzige Modell, mit dem MySQL Erfolg haben kann. MySQLs Architektur und inneren Eigenschaften fehlen in einigen Schlüsselgebieten bestimmte Features, die Oracle vorweisen kann, die ein vertikales Skalierungsmodell für MySQL zu einer überflüssigen Übung machen:
- Ineffiziente Nutzung mehrerer Prozessoren
- weniger in der Lage, eine schlecht formulierte Anfrage davon abzuhalten, allen anderen den Tag zu verderben
Wegen dieser Defizite ist der Gewinn durch den Einsatz besserer Hardware bei MySQL geringer als bei Oracle. In einer horizontalen Skalierungsarchitektur werden diese Defizite jedoch gemildert. Das Problem ineffizienter Nutzung mehrerer Prozessoren verschwindet in einem horizontalen Skalierungsmodell fast völlig, weil die Server normaler Weise in einem Mix von einem bis vier Prozessoren auftreten und MySQL lokal auf den Servern läuft. Bei ein bis vier Prozessoren ist die Ineffizienz von MySQL beim Verwalten von zusätzlichen Prozessoren nicht so offensichtlich. Das Problem mit der schlecht formulierten Anfrage, die allen anderen den Tag verderben will ist minimiert, weil die verschiedenen Datenbankserver in der horizontal skalierten Architektur immer nur einen Teil der Anwendungsanfragen bearbeiten. Im Wesentlichen isoliert die horizontale Skalierungsarchitektur schlechte Anfragen bei einer kleinen Anzahl der Benutzer; etwas, was bei einem vertikal skalierten, einzelnen MySQL-Datenbankserver nicht möglich wäre.
Zentralisierte vs. verteilte Anwendungsarchitektur
Der vierte Hauptunterschied zwischen vertikaler und horizontaler Skalierungsarchitektur hat mit der Gesamttopologie der Anwendungen der jeweiligen Strategien zu tun. In vertikalen Skalierungsmodellen tendieren die Anwendungen mehr zu Zentralismus als in horizontalen Skalierungsmodellen. Mit "Zentralismus" meine ich nicht, dass der Anwendungscode selbst auf einem einzelnen Server läuft. Ich meine, dass die Daten allgemein auf einem einzelnen Datenbankserver liegen und dass ein oder mehrere Anwendungsserver sich nach Bedarf zu diesem einzelnen Datenbankserver verbinden.
Mit "verteilt" meine ich, dass die Daten selbst dazu tendieren, auf mehrere "Shards" verteilt zu sein, mit einer oder mehreren Anwendungen, die ihre Anfragen zu einem oder mehreren der Datenbankteile richten. Die Verteilung der Daten über die Datenbankserver kann mit einer selbstgestrickten Lösung oder mit den Verteilungsfeatures von MySQL 5+ erledigt werden.
In beiden Fällen wird das Verteilungsmodell so gewählt, dass die Daten über die Anwendung konsistent und gleichmäßig verteilt werden. Manchmal werden Benutzeraccount-IDs verwendet um die Daten zwischen den verschiedenen Servern aufzuteilen. In anderen Fällen werden Hashing-Funktionen oder Datenbereiche verwendet. Dessen ungeachtet ist es so, dass die horizontale Skalierungsarchitektur die Aufteilung der Daten in einer nicht-zentralisierten, verteilten Topologie fördert.
Viel der zusätzlichen Anwendungskomplexität, über die ich weiter oben schrieb, rührt von dieser Verteilung auf Datenebene her. Zusätzlicher Code ist notwendig, der als Verkehrspolizist die Anfragen zum richtigen Datenspeicher leitet. Zudem ist es tendenziell schwieriger aggregierte Daten zu erhalten, weil Prozesse eingerichtet werden müssen, um Daten aus den einzelnen Shards zur Analyse in ein zentrales Datenwarenhaus zu holen. Ich erachte diesen Nachteil als vernachlässigbar, da auch in vertikalen Skalierungsmodellen Daten oft für Offlineanalysen aus der zentralen Datenbank in ein separates Warenhaussystem gezogen werden.
Aber zusammen mit dieser gestiegenen Komplexität kommen die Vorteile des horizontalen Skalierungsmodells: schrittweise Zunahme der Kapazität und die Möglichkeit, Last auf eine Datenbankserverfarm zu verteilen. Zudem neigt ein horizontales Skalierungsmodell nicht zu Engpässen, da es keinen einzelnen monolithischen Datenbankserver gibt, der als Datenspeicher für die gesamte Anwednung dient.
Keine Kommentare:
Kommentar veröffentlichen