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

Architektur und Design für Cloud Computing

Es würde den Rahmen dieses Artikels sprengen, wenn wir versuchten, eine umfassende Abhandlung über Architektur und Design von Cloud-Anwendungen zu schreiben. Deshalb beschränken wir uns hier darauf, einige wichtige Designprinzipien vorzustellen und zu erläutern. Abbildung 1 gibt einen Überblick über die zuvor beschriebenen Treiber von Cloud-Anwendungen (in Rot dargestellt) und deren Bezug zu den im Folgenden näher beschriebenen Designprinzipien. Wie man in der Abbildung sieht, sind die ganzen Designprinzipien eng miteinander verwoben. Es ist also für den Entwurf einer Cloud-Architektur nicht sinnvoll möglich, diese Prinzipien isoliert voneinander zu betrachten, sondern man muss das gegenseitige Beeinflussen und die Wechselwirkungen stets im Blick behalten.

Abb. 1: Wichtige Treiber und Prinzipien von Cloud-Anwendungen im Überblick
Verfügbarkeit

Hat man in normalen Unternehmensanwendungen hohe Verfügbarkeit als Anforderung, so greift man üblicherweise auf die Cluster- und Hochverfügbarkeitsangebote (HA, High Availability) der Hardware- und Softwareinfrastrukturanbieter zurück. Das Problem solcher Lösungen besteht darin, dass sie zum einen nicht beliebig skalieren und zum anderen die Kosten für diese Lösungen mit der Skalierung überproportional ansteigen. Das geht soweit, dass solche Lösungen jenseits einer bestimmten Skalierungsgrenze in der Regel nicht mehr wirtschaftlich vertretbar sind.
Damit fallen diese Lösungen für nahezu beliebig skalierbare Anwendungen aus. Stattdessen setzt man in Cloud-Umgebungen in der Regel auf einfache Standardhardware und auf Redundanz zur Sicherstellung der Verfügbarkeit. Das bedeutet im Gegenzug aber auch, dass man aus Anwendungssicht immer damit rechnen muss, dass eine Systemkomponente im nächsten Moment nicht mehr verfügbar ist. Ausfälle werden damit nicht mehr transparent für die Anwendungslogik behandelt, sondern müssen explizit beim Design der Anwendung betrachtet werden. Einige der folgenden Konzepte zeigen weiterführende Ideen auf, wie man so etwas umsetzen kann.

Transaktionen

Einer der wahrscheinlich am heftigsten diskutierten Aspekte sehr großer Anwendungen ist das Problem, dass man die unbedingte Datenkonsistenz zu jedem Zeitpunkt aufgeben muss, wie man sie von den bekannten RDBMS-Systemen kennt. Die Annahme des klassischen Konsistenzmodells auf der Basis von ACID-Transaktionen [1] erleichtert bekanntlich nicht nur die Entwicklung, sondern hat auch eine beruhigende Wirkung auf Kunden.

Unter der Anforderung einer beliebigen Skalierbarkeit ergibt sich aber aus dem so genannten CAP-Theorem [2], dass die Konsistenz nicht uneingeschränkt aufrechterhalten werden kann. Gemäß CAP-Theorem kann ein System zum verteilten Rechnen nicht gleichzeitig die Anforderungen Konsistenz (Consistency), Verfügbarkeit (Availability) und Toleranz gegenüber partiellen Systemausfällen (Partition Tolerance) erfüllen, sondern nur maximal zwei von ihnen. Klassische RDBMS haben sich immer auf die Aspekte Konsistenz und Verfügbarkeit fokussiert. Hohe Verfügbarkeit wird natürlich auch in der Cloud erwartet. Da aber in einer Cloud-Infrastruktur immer mit Ausfällen von Knoten zu rechnen ist, ohne dass deswegen die ganze Applikation still stehen darf (Partition Tolerance), bleibt nichts anderes übrig, als die vollständige Datenkonsistenz aufzugeben.

Das bedeutet jetzt aber nicht, dass beliebiger Datenmüll entsteht, sondern dass zugunsten der Verfügbarkeit darauf verzichtet wird, immer sofort die Konsistenz der Daten zu garantieren. Stattdessen wird in Kauf genommen, dass die Daten irgendwann konsistent (eventually consistent) sind. Brewster nannte diesen veränderten Konsistenzbegriff BASE (Basically Available, Soft State, Eventually Consistent) [2].

Für das Design von Cloud-Anwendungen bedeutet das insbesondere, dass man eine Robustheit gegenüber eventuell Dateninkonsistenzen vorsehen muss, da es passieren kann, dass gelesene Werte nicht den aktuellen Stand wiederspiegeln oder dass eine Entität einen anderen Zustand darstellt als eine zweite bezogene Entität. Eine Pauschalregel für die Reaktion auf solche temporären Zustandsinkonsistenzen gibt es leider nicht, da sie immer aus anwendungsfachlicher Sicht definiert werden muss. Man sollte aber auf keinen Fall Mechanismen in die Anwendung einbauen, die sich blind auf die Konsistenz der verarbeiteten Daten verlassen.

Kommentare

Schreibe einen Kommentar

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