Rien ne va plus – Umdenken für Architekten in der Cloud

Parallelisierbarkeit

Mit den zuvor beschriebenen Prinzipien geht die verstärkte Parallelisierbarkeit der Anwendung beziehungsweise von Anwendungsteilen einher. Gemäß dem Amdahlschen Gesetz [5] ist der Geschwindigkeitszuwachs bei der parallelen Bearbeitung von Aufgaben primär durch die Menge der sequenziellen, nicht parallelisierbaren Anteile eines Programms beschränkt. Je mehr nicht parallelisierbare Anteile ein Programm enthält, desto geringer ist der Geschwindigkeitsgewinn bei einer Parallelisierung der Ausführung.

Damit ist klar, dass man beim Design einer Anwendung darauf achten muss, die nicht parallelisierbaren Anteile einer Cloud-Anwendung möglichst gering zu halten. Nicht parallelisierbar sind dabei die Teile einer Anwendung, die Seiteneffekte haben. Dazu zählen insbesondere ein zwischen mehreren Ausführungs-Threads gemeinsam genutzter Zustand (Shared State) sowie Zugriffe auf externe Ressourcen. Das Problem besteht hier darin, dass Zugriffe darauf zur Vermeidung von Inkonsistenzen in kritischen Abschnitten gesichert werden müssen. Das bedeutet aber nichts anderes als eine Zwangssequenzialisierung. In dieser Situation sind Seiteneffekte möglichst zu vermeiden oder, wo unumgänglich, explizit zu machen. Dabei können funktionale Programmiersprachen helfen, da diese im Prinzip exakt so mit Seiteneffekten umgehen.

Zustand

Im Sinne des zuvor beschriebenen Shared-Nothing-Prinzips sollte man möglichst auf zwischen parallel ausgeführten Bausteinen geteilten Zustand verzichten. Aber auch darüber hinaus ist es im Sinne der Verfügbarkeit wichtig, möglichst wenig Zustand eines Bausteins im Hauptspeicher zu verwalten. Der Gedanke dahinter ist, dass man jederzeit damit rechnen muss, dass die eingesetzte Hardware ausfällt, da man zur wirtschaftlichen Realisierung der Elastizität ja typischerweise einfache Standardhardware einsetzt und keine speziellen HA-Systeme.

Bei Ausfall eines Knotens möchte man möglichst keine Daten verlieren. Andererseits bedeutet die Persistierung des Zustands eine Verlangsamung der Verarbeitungsgeschwindigkeit gegenüber der Variante, bei der die Daten im Hauptspeicher gehalten werden. Hier muss man je Komponente einen sinnvollen Kompromiss zwischen den Anforderungen Datensicherheit und Verarbeitungsgeschwindigkeit finden, bei dem in manchen Fällen der Einsatz verteilter Caches eine Lösung sein kann.

Fehlerbehandlung

Eine hohe Verfügbarkeit ist ein wichtiger Aspekt typischer Cloud-Anwendungen. Damit erhält auch die Fehlerbehandlung einen ganz anderen Stellenwert. Tatsächlich ist aus mehreren Gründen in jedem Fall eine explizite Fehlerbehandlungsstrategie erforderlich. Zunächst kann man aufgrund der komplexen Interaktion der lose gekoppelten Komponenten nicht mehr den einzelnen Entwicklern freie Hand lassen, wie sie auftretende Fehler behandeln möchten, da sie die Folgen für andere Komponenten in der Regel nicht abschätzen können. Aus diesem Grunde verbietet es sich auch, die Fehlerbehandlung dem Container oder Framework zu überlassen. Die Applikation zu beenden oder den Fehler zu ignorieren, ist bei der Anforderung an die Verfügbarkeit ohnehin keine Option.

Die speziell zu wählende Strategie ist natürlich anwendungsabhängig. Es gibt aber durchaus allgemeine Ansätze. Eine Möglichkeit besteht darin, Teilaufgaben in Worker und Supervisor zu zerlegen, wobei der Worker die Teilaufgabe erfolgreich erledigt oder im Fehlerfall einfach stirbt („Let it crash“). In letztem Fall kümmert sich der in einem eigenen Thread laufende Supervisor um die Fehlerbehandlung. Dieses Verfahren ist ein gängiges Muster in Erlang [6].

Das ist natürlich nicht die einzig mögliche Fehlerbehandlungsstrategie für hochverfügbare Systeme. So beschreibt z. B. R. Hanmer verschiedene Techniken zur Erkennung und Behandlung von Fehlern [4]. Aber für welche Strategie auch immer Sie sich entscheiden, der Umgang mit Fehlern hat in hochverfügbaren Cloud-Anwendungen einen ganz anderen Stellenwert als man es von klassischen Unternehmensanwendungen gewohnt ist.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.