SLA, RPO und RTO pragmatisch betrachten

Anwendungen für die Public Cloud entwickeln

19.06.2015
Von Robert Eichenseer

Compute: Scale-Up vs. Scale-Out

Um kosteneffizient arbeiten zu können, sollte der Compute Tier bei einem SaaS-Angebot dynamisch mit der Anzahl der User wachsen, aber auch wieder schrumpfen können. Häufig wird bei einem Anstieg der User-Zahlen ein Scale-Up durchgeführt. Das heißt, der Server wird mit mehr Hauptspeicher, einer größeren Anzahl an Prozessoren, mehr Festplattenkapazität und mehr aufgerüstet. Dieses Szenario sollte vermieden werden, da bei weiterem Wachstum des Service zu einem bestimmten Zeitpunkt eine Aufrüstung des Servers nicht mehr möglich beziehungsweise wirtschaftlich darstellbar ist. Auch kann der Compute Tier bei sinkender User-Zahl nicht dynamisch wieder verkleinert werden.

Eine Alternative stellt hierbei das Scale-Out dar. Hier wird nicht die Kapazität eines einzelnen Servers erhöht, vielmehr wird die Last auf eine (theoretisch unbegrenzte) Anzahl von zusätzlichen, gleichberechtigten Servern verteilt. Sollten die jeweiligen Server statusbehaftete Informationen (beispielsweise Inhalt eines Warenkorbes) benötigen, so kann dieser Status auf zentrale Dienste wie Cache Services oder Datenbanken ausgelagert werden. Durch dieses Verfahren wird das Scale-Out des Service ermöglicht.

Compute: Segregation of Concern

Nicht minder wichtig ist die Aufteilung des Service in Komponenten, welche eine eng eingegrenzte Problemstellung bearbeiten. Eine triviale Aufteilung in beispielsweise Frontend- und multiple Backend-Komponenten, welche unabhängig voneinander operieren können, kann als erster Schritt betrachtet werden. Diese Segregation of Concern ermöglicht es, rechenintensive Arbeiten sowohl asynchron als auch getrennt skalierbar von anderen Komponenten zu implementieren. Die notwendige Kommunikation der Komponenten untereinander kann durch bekannte Enterprise-Service-Bus-Technologien oder beispielsweise durch den Einsatz von internen Load-Balancern erreicht werden.

Durch Berücksichtigung von transienten Fehlern im Compute Tier wird eine weitere Stabilität erreicht. Hierbei handelt es sich um Fehler, die kurzfristig auftreten und durch einfache Wiederholung der Aktion gelöst werden. So kann zum Beispiel ein fehlerhafter Zugriff auf eine relationale Datenbank durch einfache Wiederholung gelöst werden, falls diese in einem Fail-Over-Cluster vom primären auf den sekundären Node gewechselt wurde.