Skalierung / Elastizität

Unter der Skalierung auf Makroarchitekturebene versteht man die Fähigkeit eines Systems, durch Hinzufügen von zusätzlichen Ressourcen (Hard- und / oder Software) mehr Leistung zur Verfügung stellen zu können, um somit mit mehr Last umgehen zu können. Im Idealfall werden bei weniger Ressourcennutzung die zusätzlichen Ressourcen dynamisch auch wieder abgebaut, um beispielsweise Kosten zu sparen.

Horizontale versus vertikale Skalierung

Zur Skalierung gibt es prinzipiell zwei unterschiedliche Strategien auf Systemebene, um mehr Leistung zur Verfügung stellen zu können - die sogenannte vertikale und horizontale Skalierung.

Vertikale Skalieriung (Scale Up)

Bei der vertikalen Skalierung wird die Hardware / Software eines Rechners / eines Knotens verbessert, in dem dieser beispielsweise mehr RAM oder mehr CPU-Leistung erhält. Die Verbesserung durch bessere Hardware ist hierbei die einfachste Möglichkeit. Vertikale Skalierung funktioniert eigentlich immer, ist allerdings auch immer (sehr) begrenzt.

Bei Hochlast-Situationen innerhalb eines Rechners bedeutet beispielsweise das Hinzufügen mehrerer MessageConsumer an den MessageBroker RabbitMQ, dass diese sich prinzipiell mehr Arbeit nehmen. Gleichzeitig bedeutet das dann, das andere Prozesse runterskaliert oder beendet werden müssen, da sich mehr Threads / Prozesse die CPU teilen müssen und das System in Summe sonst zu langsam würde. Ein typisches Beispiel für ein hohes Risiko von Timeouts

Vertikale Skalierung beim Messaging: Oft können Nachrichten schneller erzeugt als verarbeitet werden. Das System skaliert besser, wenn abhängig von der Anzahl der Nachrichten in der Queue und den zur Verfügung stehenden System-Ressourcen, mehr Consumer zur Abarbeitung der Nachrichten gestartet werden. In Schleupen.CS agieren Consumer daher als Competing Consumers. Die Plattform verfügt über eine Komponente, den Autoscaler, der abhängig von der Auslastung des Hosts und der Anzahl der Nachrichten in dem Warteschlangen, die Anzahl der Consumer so regelt, dass der Host sich nicht selbst überlastet. Umgekehrt erhöht er aber auch die Consumer, wenn der Host nicht ausgelastet ist.

Horizontale Skalierung (Scale Out)

Unter der horizontalen Skalierung versteht man die Steigerung der Leistung eines Systems durch das Hinzufügen zusätzlicher Rechner / Knoten oder Container. Um dies zu nutzen, muss die Software hier geeignet vorbereitet sein. Schleupen.CS unterstützt horizontale Skalierung, so dass prinzipiell beliebig horizontal skaliert werden kann. In der "Cloud" bedeutet das, dass fast beliebig hochskaliert werden kann - und das sehr dynamisch.

Horizontale Skalierung beim Messaging: In unserem Beispiel von oben, kann die Anzahl der Message Consumer auch erhöht werden, wenn weitere Rechner / Knoten zum System hinzugefügt werden, so dass die parallele Ausführung auf mehrere Hosts verteilt wird. Dies ermöglicht die Nutzung elastischer Cloud Umgebungen und eröffnent einen erheblich größeren Raum für die Skalierung.

Derzeit ist Schleupen.CS noch nicht vollständig in dem Sinne Cloud-fähig, dass sehr dynamisch auf Basis von Containern horizontal skaliert werden kann. Dies wird mit hoher Priorität vorangetrieben!

Horizontale Skalierung durch Cluster

Für die interaktive Nutzung von Schleupen.CS als Anwender wünscht man sich kurze Antwortzeiten (Qualitätsmerkmal der Benutzbarkeit). Um mit mehr Last umgehen zu können, kann Schleupen.CS horizontal hochskaliert werden. Da die gute Bedienbarkeit aus Benutzersicht dabei in Konkurrenz zur zuverlässigen Prozessverarbeitung steht, werden diese Verarbeitungen getrennt. Daher gibt es in Schleupen.CS das Konzept der sogenannten Deploymentrollen. Jeder Host bekommt dabei eine oder mehrere Deploymentrollen zugewiesen.

In Schleupen.CS 3.0 gibt es u.a. folgende Deploymentrollen:

• BusinessProcessServer - Rolle für einen sogenannten Geschäftsprozess-Server für Hintergrundverarbeitungen (= GPS)
• PresentationServer - Rolle für Präsentationsserver für Prozesse, die im unmittelbaren Zusammenhang mit Benutzerinteraktionen stehen (= PRS)
• WorkflowInteractiveServer - Rolle für Workflows, die auf Servern für interaktiven Betrieb installiert werden sollen, erweitert die weiter unten beschriebene Rolle BusinessProcessServer (= WF-I)
• WorkflowBackendServer - Rolle für rechenintensive Workflows, die auf Servern für den nichtinteraktiven Betrieb genutzt werden sollen, erweitert die weiter unten beschriebene Rolle BusinessProcessServer (= WF-D)
• BirtServer - Rolle für CS 3.0-Reportingserver
• CS2ApplicationServer - Rolle für CS 2.0-Applikationsserver
• DataWarehouseServer - Rolle für CS 3.0-Data-Warehouse-Server

Diese Deploymentrollen werden im Standard wie folgt gebündelt:

• GPS-I: interaktiver Server - besitzt die Rollen BusinessProcessServer, PresentationServer, WorkflowInteractiveServer
• GPS-D: Dienste-Server - besitzt die Rollen BusinessProcessServer, CS2ApplicationServer, WorkflowBackendServer

Wird mehr Leistung und höhere Verfügbarkeit benötigt, so kann das System einfach durch Zuschaltung weiterer Knoten horizontal hochskaliert werden:

Aber auch ein Stand-Alone-Betrieb ist möglich, wenn wenige Verträge etc. abgerechnet werden müssen. Hierfür wird vertikale Skalierung und aktives Ressourcen-Management sehr relevant.

Exemplarische Nachrichtenflüsse durch ein System

Im Folgenden sind einige exemplarischen Nachrichtenflüsse durch das System aufgeführt.

PRS ruft synchronen Service der Geschäftslogik auf

1. Nutzer ruft Funktionalität im Browser auf.
2. Der (optionale) Load-Balancer verteilt die Aufrufe auf die vorhandenen Presentation-Server.
3. Die Presentation-Engine ruft einen synchronen Service auf, indem die ServiceId an den lokalen (Service-)Broker übergeben wird.
4. Der Broker löst über die Service Registry auf, auf welchen Hosts der Service zu finden ist. Synchrone Services werden als Teil der GPS-Deployment-Rolle auf allen Servern installiert, auf denen Broker laufen. Hier wird der Service auf localhost gefunden und dort aufgerufen.

PRS startet ProcessService (Übergang vom Dialogablauf zum interaktiven Workflow)

1. Nutzer ruft Funktionalität im Browser auf.
2. Der (optionale) Load-Balancer verteilt die Aufrufe auf die vorhandenen PRS.
3. Die Presentation-Engine ruft einen Process Service (implementiert als Workflow) auf, indem die ServiceId des Services an den lokalen Broker übergeben wird.
4. Der Broker löst über die Service Registry auf, auf welchen Hosts der Service tatsächlich zu finden ist.
5. Process-Services (interaktive Workflows) werden auf solchen Servern installiert, denen die Deployment-Rolle WF-I zugewiesen ist. Daher wird die Zieladresse des Service in diesem Beispiel auf dem lokalen Host 1 gefunden und dort aufgerufen.

Workflow wird über ein Start-Event gestartet

1. Nutzer ruft Funktionalität im Browser auf.
2. Der (optionale) Load-Balancer verteilt die Aufrufe auf die vorhandenen PRS.
3. Die Presentation-Engine ruft einen Activtiy Service auf.
4. Der Broker löst den Service mithilfe der ServiceId und der Service Registry auf.
5. Der Activity-Service löst einen Start-Event für einen Workflow aus.
6. An der Ziel-Message-Queue melden sich alle Business Event Dispatcher (Dienst) (hier von Host 3 und 4) an und warten auf das Eintreffen einer Nachricht. Nach dem Zufallsprinzip wird die Nachricht einem lauschenden Business Event Dispatcher exklusiv zugestellt (first-come-first-serve).
7. Der Business Event Dispatcher gemäß Schritt 6 liest die Nachricht aus der Queue und ruft über den Broker an einen lokalen oder einen entfernten Process Service (Workflow) auf.
8. Der Business Event Dispatcher ruft den diensteartigen Workflow auf dem Host 3 oder 4 entfernt auf (weil er nur dort laufen kann).

Reguläres Business Event mit n Subscribern wird ausgelöst

1. Der Nutzer ruft Funktionalität im Browser auf.
2. Der (optionale) Load-Balancer verteilt die Aufrufe auf die vorhandenen PRS.
3. Die Presentation-Engine ruft einen Activtiy Service auf.
4. Der Broker löst den Service mithilfe der ServiceId und der Service Registry auf.
5. Der Activity Service löst ein Business Event aus, indem die Message an das RabbitMQ übergeben wird.
6. Es sind drei Subscriber registriert. Für jeden Subscriber ist je eine Queue vorhanden.
7. An jeder Queue lauscht je ein Thread des Business Event Dispatchers und wartet auf das Eintreffen von Nachrichten.
8. Der Business Event Dispatcher ruft den Service über den Broker auf, möglichst auf localhost.