Benutzer:DerIIIfranz/Skalierbarkeit Allgemein
Im Zusammenhang mit Software versteht man unter Skalierbarkeit ein System aus Hard- und Software, dessen Leistung durch das Hinzufügen von Ressourcen oder weiteren Knoten/Rechnern in einem definierten Bereich proportional (bzw. linear) zunimmt.
Eine allgemein gültige Definition dieses Begriffs ist allerdings nicht trivial[1]. Es ist erforderlich, für den jeweiligen speziellen Fall, stets einen Bereich anzugeben. (Z.B. muss ein System bei 100 gleichzeitigen Zugriffen nicht zwangsläufig gleich gut skalieren wie bei 100.000 Zugriffen)
Ressourcen können z.B. sein: CPU, RAM, Festplatten, Netzwerk-Bandbreite,...
Die Skalierbarkeit eines Systems wird mit dem Skalierungsfaktor (auch SpeedUp genannt) angegeben.
vertikale vs. horizontale Skalierung
Man kann die Leistung eines Systems auf zwei verschiedene Arten steigern:[2]
vertikale Skalierung (scale up)
Unter vertikaler Skalierung versteht man ein steigern der Leistung durch das Hinzufügen von Ressourcen zu einem Knoten/Rechner des Systems. Beispiele dafür wären das Vergrößern von Speicherplatz, das Hinzufügen einer CPU, oder das Einbauen einer leistungsstärkeren Grafikkarte.
Charakteristisch für diese Art von Skalierung ist, dass ein System unabhängig von der Implementierung der Software schneller gemacht werden kann. Das heißt, es muss keine Zeile Code geändert werden, um eine Leistungssteigerung durch vertikales Skalieren zu erfahren. Der große Nachteil dabei ist jedoch jener, dass man früher oder später auf ein Limit stößt, bei dem man den Rechner nicht mehr aufrüsten kann, wenn man bereits die beste Hardware verwendet die zu diesem Zeitpunkt am Markt ist.
horizontale Skalierung (scale out)
Im Gegensatz zur vertikalen Skalierung sind der horizontalen Skalierung keine Grenzen (aus Sicht der Hardware) gesetzt. Horizontale Skalierung bedeutet die Steigerung der Leistung eines Systems durch das Hinzufügen zusätzlicher Rechner/Knoten. Die Effizienz dieser Art der Skalierung ist jedoch stark von der Implementierung der Software abhängig, da nicht jede Software gleich gut parallelisierbar ist.
Arten von Skalierbarkeit
Grundsätzlich unterscheidet man vier Arten von Skalierbarkeit:[3]
Lastskalierbarkeit
Lastskalierbarkeit steht für ein konstantes Systemverhalten über größere Lastbereiche hinweg. Das bedeutet, dass ein System zum einen sowohl bei geringer, mittlerer, als auch bei hoher Last keine zu große Verzögerung aufweist und die Anfragen rasch abgearbeitet werden können.
Beispiel Museumsgarderobe
Bei einer Garderobe in einem Museum, bei welcher Besucher Jacken abgeben und wieder abholen, gilt das First In – First Out-Prinzip. Dabei gibt es eine beschränkte Anzahl an Kleiderhaken und eine größere Anzahl an Besuchern. Die Garderobe, an der sich die Besucher in einer Reihe anstellen, ist ein Karussell. Um einen freien Haken, bzw. seine Jacke zu finden, suchen die Besucher jeweils linear danach.
Unser Ziel ist es nun die Zeit, die ein Besucher tatsächlich im Museum verbringen kann, zu maximieren.
Die Performance dieses Systems ist unter hoher Last dramatisch schlecht. Erstens wird das Suchen freier Haken immer aufwändiger, je weniger freie Haken zur Verfügung stehen. Zweitens ist unter hohen Auslastung (z. B. im Winter) ein Deadlock vorprogrammiert. Während am Morgen sämtliche Besucher ihre Jacken abgeben, holen sie sich diese am Abend wieder alle ab. Ein Deadlock wird voraussichtlich mittags und am frühen Nachmittag auftreten, wenn keine freien Kleiderhaken mehr verfügbar sind und weitere Besucher am Ende der Schlange stehen um ihre Jacke abzuholen.
Personen die ihre Jacke abholen möchten könnten diesen Deadlock auflösen, indem sie die anreisenden Besucher bitten in der Schlange vorgelassen zu werden. Da die Personen, welche ihre Jacke abholen, erst nach einem gewissen Timeout danach fragen werden, ist dieses System höchst inperformant.
Das erhöhen der Anzahl an Kleiderhaken würde das Problem lediglich hinauszögern, jedoch nicht beheben. Die Lastskalierbarkeit ist folglich sehr schlecht.
räumliche Skalierbarkeit
Räumliche Skalierbarkeit weist ein System bzw. Anwendung auf, wenn der Speicherbedarf bei einer wachsenden Anzahl an zu verwaltenden Elemente nicht inakzeptabel hoch ansteigt. Nachdem "inakzeptabel" ein relativer Begriff ist, spricht man in diesem Zusammenhang in der Regel von akzeptabel, wenn der Speicherbedarf höchstens sub-linear ansteigt. Um das zu erreichen, kann z. B. eine dünnbesetzte Matrix (engl.
) bzw. Datenkompression angewendet werden. Nachdem Datenkompression eine gewisse Zeit in beansprucht, steht diese jedoch häufig in Widerspruch zur Lastskalierbarkeit.
zeitlich-räumliche Skalierbarkeit
Ein System verfügt über eine zeitlich-räumliche Skalierbarkeit, wenn sich das Erhöhen der Anzahl von Objekten die ein System umfasst, nicht erheblich auf dessen Performance auswirkt. Z. B. weist eine Suchmaschine mit linearer Komplexität keine zeitlich-räumliche Skalierbarkeit auf, während eine Suchmaschine mit indizierten, bzw. sortierten Daten, z. B. unter Verwendung einer Hashtabelle oder eines balancierten Baums, sehr wohl eine zeitlich-räumliche Skalierbarkeit vorweisen könnte.
strukturelle Skalierbarkeit
Strukturelle Skalierbarkeit zeichnet ein System aus, dessen Implementierung das Erhöhen der Anzahl von Objekten innerhalb eines selbst definierten Bereichs nicht maßgeblich behindert.
Abhängigkeit zwischen den Arten von Skalierbarkeit
Nachdem ein System natürlich mehrere Arten von Skalierbarkeit aufweisen kann, stellt sich die Frage, wie und ob diese miteinander zusammenhängen.
Die Lastskalierbarkeit eines System wird nicht zwangsläufig durch eine schlechte räumliche, oder strukturelle Skalierbarkeit negativ beeinflusst. Systeme mit schlechter räumlicher oder zeitlich-räumlicher Skalierbarkeit haben, aufgrund des Overheads an Speicherverwaltung bzw. des hohen Suchaufwands, möglicherweise auch eine schlechte Lastskalierbarkeit. Systeme mit guter zeitlich-räumlicher Skalierbarkeit haben unter Umständen eine schlechte Lastskalierbarkeit, wenn z. B. nicht ausreichend parallelisiert wurde.
Der Zusammenhang zwischen struktureller Skalierbarkeit und Lastskalierbarkeit sieht folgendermaßen aus. Während letztere keine Auswirkungen auf erstere hat, kann das umgekehrt sehr wohl der Fall sein.
Die verschiedenen Arten von Skalierbarkeit sind also nicht zur Gänze unabhängig voneinander.
Skalierungsfaktor
--> Abbildung: Datei:Graph Skalierbarkeit.jpg|miniatur
Der Skalierungsfaktor (SpeedUp) beschreibt den tatsächlich Leistungszuwachs einer zusätzlichen Ressourcen-Einheit. Z.B. kann eine zweite CPU 90% zusätzliche Leistung bringen.
Von einer super-linearen Skalierbarkeit spricht man, wenn der Skalierungsfaktor beim Hinzufügen von Ressourcen größer wird.
Lineare Skalierbarkeit bedeutet, dass der Skalierungsfaktor eines Systems pro hinzugefügter Ressourcen-Einheit gleich bleibt.
Sub-Lineare Skalierbarkeit steht im Gegensatz dazu für die Abnahme des Skalierungsfaktors beim Hinzufügen von Ressourcen.
Negative Skalierbarkeit wird erreicht, wenn sich die Leistung durch das Hinzufügen von Ressourcen/Rechnern sogar verschlechtert. Mit diesem Problem hat man zu kämpfen, wenn der Verwaltungsaufwand, welcher durch den zusätzlichen Rechner entsteht, größer ist als der dadurch erreichte Leistungszuwachs.
Amdahls Gesetz ist ein relativ pessimisitisches Modell zur Abschätzung des Skalierungsfaktors. Basierend darauf ist Gustafsons Gesetz eine weiteree Methode zur Berechnung dieses Faktors.
System als Schichtenmodell
Um ein System nun möglichst skalierbar aufzubauen hat sich in der Praxis bewährt, ein solches als Schichtenmodell umzusetzen, da mit diesem Ansatz die einzelnen Schichten logisch voneinander getrennt sind und jede Schicht für sich skaliert werden kann.
Eine sehr populäre Architektur im Web-Bereich ist die 3-Schichten-Architektur. Um eine dabei eine hohe Skalierbarkeit zu erzielen ist ein entscheidender Faktor jener, dass jede dieser 3 Schichten gut skaliert.
Während die Präsentationsschicht relativ einfach horizontal skaliert werden kann, ist bei der Logikschicht dafür eine speziell dafür ausgelegte Implementierung des Codes erforderlich. Dabei ist zu berücksichtigen, dass ein möglichst großer Anteil der Logik parallelisiert werden kann (siehe Amdahls Gesetz und Gustafsons Gesetz weiter oben). Am interessantesten ist jedoch die horizontale Skalierung der Datenhaltungsschicht, weshalb diesem Thema ein eigener Abschnitt (siehe horizontales Skalieren der Datenhaltungsschicht weiter unten) gewidmet ist.
praktische Methoden zur Verbesserung der Skalierbarkeit von Webseiten
Verbesserung der Skalierbarkeit von Webseiten kann durch Steigerung der Performance erzielt werden, da ein Server dadurch mehr Clients in der gleichen Zeit bedienen kann.
Martin L. Abbott und Michael T. Fisher haben 50 Regeln aufgestellt, die es in Bezug auf Skalierbarkeit zu beachten gilt[4]. Für Webseiten sind dabei unter anderem folgende Regeln relevant:
Reduzieren von DNS-Lookups und Anzahl von Objekten
Beim Betrachten des Ladens einer Seite in einem beliebigen Browser mit einem Debugging-Tool (z.B. Firebug) fällt auf, dass ähnliche große Elemente unterschiedliche lange Ladezeiten beanspruchen. Bei genauerer Betrachtung erkennt man, dass einige dieser Elemente einen zusätzlich DNS-Lookup benötigen. Dieser Vorgang der Adressauflösung kann durch Caching auf unterschiedlichen Ebenen (z.B. Browser, Betriebssystem, Internet Provider etc.) beschleunigt werden. Um die Anzahl der Lookups zu reduzieren, könnte man nun alle Javascript- und CSS-Dateien zu jeweils einer zusammenfassen und man könnte alle Bilder auf ein großes zusammenfügen und mittels CSS nur den gewünschten Bildausschnitt anzeigen. Allgemein kann man folgende Regel dazu aufstellen: Jede weniger DNS-Lookups beim Laden einer Seite erforderlich sind, desto besser ist die Performance. Die folgende Grafik veranschaulicht wie teuer der DNS-Lookup und der Verbindungsaufbau verhältnismäßig sind.
--> Abbildung: Datei:Object download time.gif
Moderne Browser können jedoch mehrere Verbindungen gleichzeitig zu einem Server offen halten um mehrere Objekte parallel herunterzuladen. Laut HTTP/1.1 RFC[5] sollte das Maximum an gleichzeitigen Verbindungen je Server im Browser auf 2 limitiert werden. Einige Browser ignorieren diese Richtlinie jedoch und verwenden ein Maximum von 6 gleichzeitigen Verbindungen und mehr. Reduziert man auf einer Webseite nun jedoch alle Javascript- und CSS-Dateien, sowie alle Bilder lediglich auf jeweils eine Datei, so entlastet man zwar die anbietenden Server, hebelt jedoch gleichzeitig diesen Mechanismus der parallelen Verbindungen des Browser aus.
Idealerweise nutzt man diese Parallelisierung im Browser zur Gänze aus und hat gleichzeitig möglichst wenige DNS-Lookups. Um das zu erreichen verteilt man eine Webseite am besten auf mehrere Subdomains (z.B. ruft man Bilder von einer Subdomain auf, während man Videos von einer anderen lädt). Durch diese Vorgehensweise lässt sehr rasch eine beachtliche Performance-Steigerung erzielen. Leider gibt es jedoch keine allgemeine Antwort darauf, wie viele Subdomains man verwenden sollte um die bestmögliche Leistung zu erzielen. Einfache Performance-Tests der zu optimierenden Seite sollten darüber jedoch rasch Aufschluss bieten.
horizontales Skalieren der Datenhaltungsschicht
Skalierung hinsichtlich Datenbankzugriffe
Der am schwierigsten zu skalierende Teil eines Systems ist meistens die Datenbank bzw. die Datenhaltungsschicht (s. o.). Der Ursprung dieses Problem kann bis zum Paper "A Relational Model of Data for Large Shared Data Banks"[6] von Edgar F. Codd zurückverfolgt werden, welches das Konzept eines Relational Database Management System (RDBMS) vorstellt.
Eine Methode um Datenbanken zu skalieren ist, sich den Fakt, dass die meisten Anwendungen und Datenbanken wesentlich mehr Lese- als Schreibzugriffe aufweisen, zu Nutze zu machen. Ein durchaus realistisches Szenario, das in dem Buch von Martin L. Abbott und Michael T. Fisher beschrieben wird, ist eine Buchreservierungsplattform welche ein Verhältnis zwischen Lese- und Schreibzugriffen von 400:1 aufweist. Diese Art von Systemen können relativ einfach skaliert werden, indem mehrere read-only Duplikate dieser Daten angefertigt werden.
Es gibt mehrere Wege um die Kopien dieser Daten zu verteilen abhängig davon, wie aktuell die Daten der Duplikate wirklich sein müssen. Grundsätzlich sollte es kein Problem sein, dass diese Daten lediglich alle 3, 30, oder 90 Sekunden synchronisiert werden. Bei dem Szenario der Buchplattform gibt es 100 000 Bücher und 10% davon werden täglich reserviert. Angenommen die Reservierungen sind gleichmäßig über den gesamten Tag verteilt, so findet ca. eine Resevierung pro Sekunde (0,86 Sek.) statt. Die Wahrscheinlichkeit dass zum Zeitpunkt (innerhalb 90 Sek.) einer Reservierung ein anderer Kunde das gleiche Buch reservieren möchte, beträgt 0,104%. Natürlich kann und wird dieser Fall irgendwann eintreffen, doch diesem Problem kann ganz einfach durch eine abschließende, erneute Überprüfung der Datenbank entgegentreten werden.
Eine Möglichkeit um diese Methode umzusetzen ist jene, die Daten, z.B. mit einem Key-Value-Store (z.B. Redis), zu cachen. Der Cache muss erst nach Ablauf seiner Gültigkeit erneuert werden und entlastet damit die Datenbank enorm. Der einfachste Weg diesen Cache zu implementieren, ist ihn in einer bereits bestehenden Schicht (z.B. der Logikschicht) zu installieren. Für eine bessere Performance und Skalierbarkeit verwendet man dafür jedoch eine eigene Schicht, bzw. eigene Server, zwischen der Logikschicht und der Datenhaltungsschicht.
Der nächste Schritt ist nun die Datenbank zu replizieren. Die meisten bekannten Datenbanksysteme verfügen bereits über eine solche Funktion. MySQL bewerkstelligt dies mit dem master-slave-Prinzip, wobei die master-Datenbank die eigentliche Datenbank mit Schreibrechten ist und die slave-Datenbanken die duplizierten read-only Kopien sind. Die master-Datenbank zeichnet sämtliche updates, inserts, deletes, etc. im sogenannten Binary-Log auf und die slaves reproduzieren diese. Diese slaves steckt man nun hinter einen Load Balancer (s. u.) um die Last entsprechend zu verteilen.
Diese Art von Skalierung lässt die Anzahl der Transaktionen relativ einfach skalieren. Je mehr Duplikate der Datenbank verwendet werden, desto mehr Transaktionen können auch parallel bewältigt werden. In anderen Worten bedeutet das, dass nun beliebig viele User (natürlich abhängig von der Anzahl der Server) gleichzeitig auf unsere Datenbank zugreifen können. Leider hilft uns diese Methode nicht dabei, auch die Daten an sich zu skalieren. Um nun auch beliebig viele Daten in der Datenbank speichern zu können, ist ein weiterer Schritt nötig. Dieses Problem wird im nächsten Punkt behandelt.
Skalierung hinsichtlich Datenbankeinträge - Denormalisierung
Was man hiermit erreichen möchte, ist eine Datenbank auf mehrere Rechner aufzuteilen und dessen Kapazität beliebig durch weitere Rechner zu erweitern. Dazu muss die Datenbank zu einem gewissen Grad denormalisiert werden. Unter Denormalisierung versteht man die bewusste Rücknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung.
Im Zuge der Denormalisierung muss die Datenbank fragmentiert werden.
Fragmentierung
Man unterscheidet horizontale und vertikale Fragmentierung.
Bei der Horizontalen Fragmentierung (Eng. sharding) wird die Gesamtheit aller Datensätze einer Relation auf mehrere Tabellen aufgeteilt. Wenn diese Tabellen auf demselben Server liegen, dann handelt es sich meistens um Partitionierung. Die einzelnen Tabellen können aber auch auf unterschiedlichen Servern liegen. So können z.B. die Daten für die Geschäfte in den USA auf einem Server in den USA gespeichert werden und die Daten für die Geschäfte mit Europa liegen auf einem Server in Deutschland. Diese Aufteilung wird auch als Regionalisierung bezeichnet.
Horizontale Fragmentierung schafft keine Redundanz der gespeicherten Daten, sondern der Strukturen. Wenn eine Relation geändert werden muss, dann muss nicht nur eine Tabelle geändert werden, sondern es müssen alle Tabellen geändert werden, über die die Daten aus der betreffenden Relation verteilt sind. Hier besteht die Gefahr von Anomalien in den Datenstrukturen.
Bei der Vertikalen Fragmentierung werden die abhängigen Attribute (nicht-Schlüssel-Attribute) einer Tabelle in zwei oder mehrere Gruppen aufgeteilt. Aus jeder Gruppe wird eine eigene Tabelle, die noch um alle Schlüssel-Attribute der Ursprungstabelle ergänzt werden. Das kann dann sinnvoll sein, wenn die Attribute einer Relation Datensätze mit einer sehr großen Satzlänge ergeben. Wenn zusätzlich noch die Zugriffe meistens nur einige wenige Attribute betreffen, dann kann man die wenigen häufig zugegriffenen Attribute in eine Gruppe zusammenfassen und den Rest in eine zweite Gruppe zusammenfassen. Die häufig auszuführenden Zugriffe werden dadurch schneller, weil eine geringere Menge an Daten von der Festplatte gelesen werden muss. Die selten auszuführenden Zugriffe auf die restlichen Attribute werden dadurch nicht schneller, aber auch nicht langsamer.
Ab welcher Satzlänge eine Aufspaltung in mehrere kleinere Tabellen sinnvoll ist, hängt auch von dem Datenbanksystem ab. Viele Datenbanksysteme speichern die Daten in Form von Blöcken mit einer Größe von 4KiB, 8KiB oder 16KiB ab. Wenn die durchschnittliche Satzlänge wenig größer als 50 % eines Datenblocks ist, dann bleibt viel Speicherplatz ungenutzt. Wenn die durchschnittliche Satzlänge größer als die verwendete Blockgröße ist, dann werden die Datenzugriffe aufwändiger. Wenn BLOBs zusammen mit anderen Attributen in einer Relation vorkommen, ist vertikale Fragmentierung fast immer von Vorteil.
Partitionierung
Partitionierung ist ein Spezialfall der horizontalen Fragmentierung.
Große Datenbestände lassen sich leichter administrieren, wenn die Daten einer Relation in mehrere kleine Teile (=Partitionen) aufgeteilt und diese separat gespeichert werden. Wenn eine Partition einer Tabelle gerade aktualisiert wird, dann können andere Partitionen der Tabelle zur selben Zeit reorganisiert werden. Wenn in einer Partition ein Fehler entdeckt wird, dann kann diese einzelne Partition aus einer Datensicherung wiederhergestellt werden, während Programme auf die anderen Partitionen weiter zugreifen können. Die meisten etablierten Datenbankhersteller bieten Partitionierung an, siehe z.B. Partitionierung bei DB2 und Partitionierung bei MySQL.
Die meisten Datenbanksysteme bieten die Möglichkeit, entweder einzelne Partitionen anzusprechen oder alle Partitionen unter einem einheitlichen Tabellennamen anzusprechen.
Durch Partitionierung können die Datenzugriffe beschleunigt werden. Der wesentliche Vorteil ist jedoch die leichtere Administrierbarkeit der gesamten Tabelle.
Einzelnachweise
- ↑ See for instance, Mark D. Hill, 'What is scalability?' in ACM SIGARCH Computer Architecture News, December 1990, Volume 18 Issue 4, pages 18–21, (ISSN 0163-5964) and Leticia Duboc, David S. Rosenblum, Tony Wicks, 'Doctoral symposium: presentations: A framework for modelling and analysis of software systems scalability' in Proceeding of the 28th international conference on Software engineering ICSE '06, May 2006. ISBN 1-59593-375-1, pages 949–952
- ↑ Michael, M., J.E. Moreira, D. Shiloach, R.W. Wisniewski: Scale-up x Scale-out: A Case Study using Nutch/Lucene. In: Parallel and Distributed Processing Symposium, 2007. IPDPS 2007.. IEEE International. March 26, 2007. Abgerufen am 23. Mai 2012.
- ↑ B. Bondi. 2000. Characteristics of scalability and their impact on performance. In Proceedings of the 2nd international workshop on Software and performance (WOSP '00). ACM, New York, NY, USA, 195-203. DOI=10.1145/350391.350432 http://doi.acm.org/10.1145/350391.350432
- ↑ Abbott L. M., M. T. Fisher 2011. Scalability Rules: 50 principles for scaling Web sites, Indiana: Addison-Wesley, ISBN 978-0-321-75388-5, S.12-34
- ↑ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, Network Working Group Request for Comments 2616, Hypertext Transfer Protocol-HTTP/1.1, Juni 1999, http://www.ietf.org/rfc/rfc2616.txt
- ↑ Edgar F. Codd: A Relational Model of Data for Large Shared Data Banks. In:Communications of the ACM. ACM Press, 13. Juni 1970, ISSN 0001-0782, S. 377–387.
Siehe auch
[[Kategorie:Softwaretechnik]]
