Eine Gartner Umfrage aus dem Jahr 2014 zeigt auf, dass 26 Prozent der CIOs in deutschen Unternehmen bedeutende Investitionen in Public Cloud Technologien getätigt haben. Interessant ist hierbei, dass dieser Wert über dem globalen Wert von 25 Prozent liegt. Ein Viertel der Befragten hat dabei angegeben, dass sie in Services investiert haben. Wobei "Software as a Service" mit 73 Prozent das größte Augenmerk aufweist. Unter "Software as a Service" versteht man die zur Verfügungstellung von Softwarepaketen, bei der der Anwender in der Regel keine Installationsschritte durchführen muss. Ein Login für grafische Anwendung bzw. ein Connection String für Daten-, bzw. Applikationsdienste ist alles, was der Anwender benötigt um den Service zu konsumieren.
Derartige Dienstleistungen müssen ausfallsicher und skalierend aufgebaut werden, da der Anwender keine Unterbrechungen wegen Hardwareproblemen, eingeschränkte Performance wegen Kapazitätsproblemen, Serviceunterbrechungen wegen Updates oder ähnliche Probleme bei Benutzung des Service akzeptiert. Im Unterschied zu klassischer Software, die als Installationsmedium vorliegt und auf lokalen Ressourcen installiert wird, kommt bei "Software as a Service" dem Service Level Agreement (SLA) eine tragende Rolle zu.
Aus dem SLA können Recovery Point Objective (RPO) und Recovery Time Objective (RTO) erarbeitet sowie die passenden Building Blocks für die Architektur gewählt werden. Das SLA bestimmt letztendlich auch die Kosten für den Betrieb des Services. Auch wenn eine hundertprozentige Verfügbarkeit des Service angestrebt wird, ist dies mit einem finanziell vertretbaren Aufwand nicht zu erreichen. Da auch die Provider von Public Cloud-Infrastrukturen deren Dienste, auf denen der eigene Service aufbaut, kein SLA mit einer 100 prozentiger Verfügbarkeit anbieten.
Graceful Service Degredation
Vor Auswahl der Architekturkomponenten sollten pragmatische Abwägungen bezüglich der Absicherung des Service im Problemfall getroffen werden. Häufig beginnt die Entwicklungsabteilung motiviert mit der Erstellung einer Architektur, die eine Vielzahl von Unwägbarkeiten berücksichtig und damit die Funktionalität des Service im Problemfall sicherstellt. Hierfür existieren viele Komponenten beziehungsweise Konzepte, die Verwendung finden können. Einige dieser Best Practice-Ansätze finden sich auch im weiteren Verlauf dieses Artikels.
Bevor die Entwicklungsabteilung jedoch in die Erstellung der Gesamtarchitektur abtaucht, sollte pragmatisch die Möglichkeiten einer sogenannten "Graceful Service Degredation" betrachtet werden. Unter "Graceful Service Degredation" versteht sich die Möglichkeit, einen Service trotz Ausfall eines großen Teils seiner Infrastruktur beziehungsweise von Programmkomponenten eine zwar limitierte, aber dennoch ausreichende Funktionalität zur Verfügung zu stellen.
Beispielhaft kann ein E-Commerce System betrachtet werden, bei dem die Lagerhaltungskomponente nicht erreichbar oder ausgefallen ist. Anstelle dem Anwender eine Fehlermeldung bei der Ermittlung des aktuellen Lagerbestandes im Bestellprozess anzuzeigen und damit die Bestellung unmöglich zu machen, wird dem Anwender die Durchführung der Bestellung ohne Einschränkung ermöglicht. Allerdings wird zum Abschluss der Bestellung nicht die gewohnte Bestellbestätigung erzeugt, sondern eine Mitteilung, die sich für die Bestellung bedankt und darauf hinweist, den möglichen Liefertermin schnellstmöglich mitzuteilen. Diese Meldung kann, sobald die Lagerhaltungskomponente wieder erreichbar ist, erzeugt und versandt werden.
Durch solche Verfahren kann die Funktionalität des Gesamtsystems ermöglicht werden, auch wenn elementare Bestandteile aktuell nicht verfügbar sind oder fehlerhaft arbeiten. Die Berücksichtigung eines solchen Verhaltens im Fehlerfall kann, richtig angewendet, die Komplexität und die Kosten eines ausfallsicheren Systems im Praxisbetrieb deutlich reduzieren. Nach den Überlegungen zum möglichen Serviceverhalten können die technische Betrachtung und der Aufbau einer Architektur für einen hochverfügbaren und ausfallsicheren Service beginnen. Nachfolgend finden Sie einige grundlegende Konzepte, die für den Aufbau eines "Software as a Service"-Angebots (SaaS) berücksichtig werden sollten.
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.
Storage: Sharding, Master Slave und Peer-To-Peer-Speicherung
Der Storage Tier muss nicht minder aufmerksam betrachtet werden. Insbesondere relationale Datenbanksysteme wurden nicht in Hinblick auf Skalierung und verteilte Verarbeitung entwickelt. Hier helfen Konzepte wie Tenant Sharding, bei der die Daten des Service auf mehrere Datenbanken und auch auf mehrere Datenbankserver verteilt werden können. Auch eine Master/Slave-Konfiguration von Datenbanken, bei denen lesende Zugriffe von mehreren Servern übernommen werden, schreibende Zugriffe von einer vor Ausfall besonders abgesicherten Instanz gewährleistet werden, ist eine Möglichkeit. Daten zwischen den lesenden und dem schreibenden Node werden hierbei synchronisiert.
Peer-To-Peer-Konzepte nutzen ein ähnliches Schema, nur kann hier jeder Server lesende und auch schreibende Zugriffe entgegennehmen. Die Synchronisation der Datenbankinhalte wird dadurch komplexer. Auch die Wahrscheinlichkeit, dass ein Read nicht den aktuellen Datenstand wiederspiegelt, ist gegeben. Hier muss abgewägt werden, ob ein diesbezügliches Verhalten für den Service akzeptabel ist.
Fazit
Die Architektur von hochverfügbaren und skalierenden "Software as a Service"-Anwendungen sollte nicht alleinig im technischen Bereich mit Auswahl von Komponenten und Aufstellung einer ausfallsicheren Architektur beginnen.
Durch die Berücksichtigung von "Graceful Service Degredation" kann mit deutlich geringeren Kosten und Aufwand ebenfalls ein ausfallsicherer und skalierender Service entwickelt und betrieben werden. (cvi)