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

Entitäten

In sehr großen Systemen ist es ab einer bestimmten Datenmenge nicht mehr möglich, alle Daten in einer Lokation, d. h. in einer Datenbank zu speichern. Stattdessen muss man die Daten über eine Menge von Speicherorten verteilen. Da verteilte Transaktionen nicht beliebig skalierbar sind (zumindest wenn man die Systemverfügbarkeit hoch halten will), muss man zu einer weitestgehend unabhängigen Verteilung und Speicherung der Daten übergehen.

Pat Helland empfiehlt, die Daten in Form von Entitäten zu organisieren, die man unabhängig verteilen kann [3]. Typischerweise sollte man dabei darauf achten, dass eine Entität nicht zu groß ist, um in einer Datenbank gespeichert zu werden. Dann kann man davon ausgehen, dass sich eine einzelne Entität jederzeit in einem für sich konsistenten Zustand befindet, was die Entwicklung erleichtert.

Eine Entität sollte man in diesem Kontext auch nicht mit klassischen Datenbankentitäten gleichsetzen. In diesem Zusammenhang versteht man unter einer Entität typischerweise einen Ordnungsbegriff inklusive aller zugeordneten Daten. Im Sinne klassischer relationaler Datenbanksysteme kann eine solche Entität aus einer Top-Level-Entität und einem ganzen Baum zugehöriger bzw. abhängiger Entitäten bestehen.

Shared Nothing

Klassische Clusterarchitekturen, in denen der Zustand (Daten) über den gesamten Cluster repliziert wird, skalieren nur bis zu einem gewissen Punkt. Jenseits dieses Punkts wird der Kommunikationsaufwand für die Replikation so groß, dass die Verfügbarkeit der Anwendung nicht mehr gewährleistet werden kann.

Um nahezu beliebig skalierbare Anwendungen zu entwickeln, muss man stattdessen auf so genannte Shared-Nothing-Architekturen setzen. Den Begriff gibt es auf verschiedenen Architekturebenen von der Hardware bis zur Anwendung. Allgemein bedeutet „Shared Nothing“, dass die Komponenten auf der bezogenen Ebene keinerlei Zustand miteinander teilen. Damit kann man das Replikationsproblem effizient lösen. Kommunikation zwischen den Komponenten findet nur in Form von Nachrichten statt.

Lose Kopplung

Lose Kopplung ist eine Voraussetzung für die zuvor beschriebenen Shared-Nothing-Systeme. Wir werden nur in der Lage sein, eine Anwendung nahezu beliebig zu skalieren, wenn ihre Bausteine sowohl auf fachlicher als auch auf technischer Ebene möglichst unabhängig voneinander sind. Auf fachlicher Ebene haben wir das im Zusammenhang mit den Entitäten zuvor schon betrachtet. Man kann (und muss) das natürlich auch noch bis auf die Ebene der Anwendungslogik weitertreiben. Je besser ich einen Block von Anwendungslogik von dem Rest der Logik abkoppeln kann, desto leichter kann ich diesen Block bedarfsgerecht skalieren. Außerdem hilft einem die Entkopplung der Bausteine, die Anwendung robuster zu gestalten und damit die Verfügbarkeit zu erhöhen [4].

Auch auf technischer Ebene muss lose Kopplung umgesetzt werden. Das bedeutet in Verbindung mit dem Shared-Nothing-Gedanken, dass die einzelnen Blöcke nur noch über Nachrichten miteinander kommunizieren. Das hat weitreichende Folgen für die Softwareentwicklung. Tatsächlich stellt die nachrichtenbasierte asynchrone Kommunikation einen Paradigmenwechsel gegenüber der klassischen Call-Stack-basierten Softwareentwicklung dar. Das Problem für die Entwicklung besteht darin, dass einerseits dieses Paradigma weniger bekannt ist, sodass die Entwicklungszeiten steigen können. Andererseits ist das Verständnis des Verhaltens von unabhängigen, über Nachrichten kommunizierenden Einheiten für Menschen ziemlich schwierig. Damit müssen wir zusätzliche Überwachungsmechanismen und Sicherungsmechanismen vor dem Bearbeiten von Nachrichten vorsehen.

Kommentare

Schreibe einen Kommentar

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