Nachdem ich beim letzten Mal beschrieben habe, warum ich glaube dass nur horizontale Skalierbarkeit auch eine problemlose Skalierbarkeit bedeutet, versuche ich heute einmal zu erläutern, warum es auch bei horizontaler Skalierbarkeit Unterschiede gibt.

Prinzipiell kann die Last auf dem System steigen, weil die einzelnen Aufgaben immer länger brauchen und entsprechend weitere Aufgaben warten müssen, bis das System dazu kommt diese auszuführen. Daneben kann es auch sein, dass die Dauer der einzelnen Aufgaben nicht ansteigt, dafür aber die Anzahl der Aufgaben derartig ansteigt, dass es ebenfalls zu Wartezeiten im System kommt. Grundsätzlich gilt, dass wenn während der Ausführungszeit einer Aufgabe mehr als eine weitere Aufgabe angefragt wird, die Antwortzeit im System ansteigt. Bei lang laufenden Aufgaben ist zum einen die Wahrscheinlichkeit höher, dass während der Ausführungszeit weitere Aufgaben angefragt werden, aber es kann sogar sein, dass die Ausführungszeit der einzelnen Aufgabe schon so lange dauert, dass es zu Problemen kommt.

Typische Fälle sind für die immer länger werdende Ausführungszeit etwa die Suche nach bestimmten Daten in einer ständig anwachsenden Datenmenge. Dagegen ist die Auslieferung einer statischen Webseite meist immer gleich schnell, der Webserver kann aber trotzdem durch zuviele Anfragen gleichzeitig überlastet werden. Im letzten Fall wird schon lange mit Load-Balancers gearbeitet, hier werden dann mehrere Webserver betrieben, die den gleichen Inhalt liefern, und der Load-Balancer verteilt die Anfragen auf die Webserver. Je mehr Anfragen gleichzeitig beantwortet werden müssen, desto mehr Webserver werden betrieben, eine horizontale Skalierung, dank der verbreiteten Load-Balancer auch sehr einfach implementiert.

Genau das macht sich eine Microservice Architektur die zum Beispiel via Kubernetes verschiedene Webservice per Container bereitstellt, zu Nutze. Die Aufrufe der einzelnen Webservices erfolgt letztendlich auf dem gleichen Weg wie der Aufruf einer Webseite. Um die Anwendung zu skalieren, können bestimmte Webservices einfach mehrfach parallel gestartet werden, dank Container-Images ohne spezielle Installationen. Um die Anfragen zu verteilen kann ein Loadbalancer eingesetzt werden, genau wie bei den Webservern.

Etwas anders sieht es bei den Aufgaben aus, deren Ausführung schlicht lang dauert. Durch das Abarbeiten von mehr als einer Aufgabe parallel kann man im besten Fall verhindern, dass die Antwortzeiten zusätzlich steigen, aber nicht die Ausführungszeit einer einzelnen Aufgabe reduzieren. Um hier skalieren zu können, muss man die Aufgabe selbst weiter aufteilen. Der Ansatz den eine typische Datenplattform dafür verwendet ist das Aufteilen der großen Datenmenge auf mehrere kleinere Datentöpfe, die dann parallel bearbeitet werden können. Das ist der Ansatz den eine Hadoop Installation verfolgt. Es handelt sich hier auch um eine horizontale Skalierung, aber da die Daten in kleinere Töpfe aufgeteilt werden müssen, kann diese Skalierung nicht ganz so ‚spontan‘ erfolgen, das System ist also nicht so elastisch. Die verfügbare Kapazität muss hier sinnvoll geplant werden.

In der Praxis hat man aber regelmäßig eine Mischung aus beiden Laststeigerungen. Mit mehr Anwendern kommen auch gerne mehr Daten. Was man dann häufig sehen kann, ist das die Daten nicht in Echtzeit für die Anwender zur Verfügung stehen, sondern mit einer passgenauen Vorverarbeitung die Datenmenge minimiert wird, die für die Anwender zur Verfügung stehen muss. In aktuellen Installationen gibt es oft eine horizontale Skalierbarkeit der Anwender oder Präsentationsschicht (sozusagen der Webserver), aber eine vertikale Skalierbarkeit der Datenschicht (des Datenbankservers). Insgesamt ein Design das gut mit einer steigenden Anzahl von Useranfragen klar kommt, aber bei steigenden Datenmengen nur begrenzt skalieren kann. Durch regelmäßige ‚Batchbeladung‘ der Datenschicht, kann man die Datenmengen einigermaßen kontrollieren.

Für die Analyse der vollständigen Datenmengen steht dann entweder ein DWH oder ein DataLake oder beides zur Verfügung, mit eigener Datenversorgung und die vielleicht sogar die Schnittstelle für weitere Systeme mit Daten versorgen.

Eine echtzeitfähige Datenplattform sollte auf beiden Seiten skalieren können, um mit einem zentralen Datenrepository sowohl die Anfragen der Enduser (via Webserver) schnell beantworten kann als auch mit steigenden Datenmengen skalieren kann. Parallele Datenhaltungen mit speziellen Vorverarbeitungen erhöhen grundsätzlich die Komplexität des Systems und verhindern eine problemlose Skalierbarkeit. Wie aus meiner Sicht die grundlegende Architektur einer solchen Datenplattform aussehen kann, werde ich in einem der nächsten Beiträge erläutern.