Stefan Zörner
02.06.2021
Beim Architektur-Midsommar 2021 spricht Susanne Braun über Eventual Consistency. Ich habe mich dazu mit ihr unterhalten.
(StefanZ) “Susanne, was machst Du so?"
Susanne: “Ich bin aktuell am Fraunhofer IESE als ‘Expert Data-Intensive Systems Design’ unterwegs. In diesem Umfeld forsche ich im Rahmen meiner PhD, verschiedener Forschungsprojekte, und betreue außerdem auch noch Kundenprojekte, die in diesem Themenkomplex angesiedelt sind. Im Moment ist bei mir der Forschungsanteil etwas höher, es gab aber auch schon Phasen, wo es umgekehrt war.
Bevor ich bei der Fraunhofer Gesellschaft eingestiegen bin, war ich einige Jahre als Software Engineer und Managing Consultant bei Capgemini sd&m und Accso tätig.”
Dein Vortragsthema auf dem Architektur-Midsommar lautet “Eventual Consistency – Du musst keine Angst haben”. Kannst Du kurz erklären, was Eventual Consistency ist, und warum man davor Angst haben könnte?
Susanne: “Heute bauen wir üblicherweise verteilte Systeme und setzen dabei auf schwache und nicht auf starke Konsistenz. Stark konsistente verteilte Systeme maskieren, dass es sich eigentlich um ein verteiltes System handelt. Bei schwach konsistenten Systemen gibt es immer eine gewisse Unsicherheit im System, weil es keinen eindeutigen globalen Zustand mehr gibt. Je nachdem, bei welchem Knoten ich gerade rauskomme, kann ich eine andere Antwort erhalten.
Bei schwach konsistenten Systemen gibt es immer eine gewisse Unsicherheit im System …
Eventual Consistency ist nur eine von vielen Formen der schwachen Konsistenz. Eine sehr minimalistische Form, die mir als Anwendungsentwickler nur wenige Garantien gibt. Genau genommen bekomme ich als Garantie nur, dass die Zustände der Systeme aufeinander hin konvergieren, bis sie schließlich irgendwann identisch sind. Spätestens dann, wenn es keine neuen Updates mehr gibt. Das heißt, ich habe in so einem “eventually consistent system” sehr viel Parallelität, die erstmal nicht global koordiniert wird. Dies kann dann zu verschiedenen Anomalien führen, die auf die Anwendungsebene durchschlagen und um die ich mich als Entwickler kümmern muss.
Bezüglich der Angst erlebe ich da zwei Lager. Die einen unterschätzen das Thema total und sehen das Problem erstmal gar nicht. Die anderen glauben, dass Eventual Consistency nicht reicht, wollen verteilte Transaktionen, globale Koordination … Meiner Meinung nach hängt es stark ab von der Domäne und von den zu verarbeitenden Daten. Also wie immer: It depends! Man muss einfach sehr genau hinschauen und die größten Stolpersteine kennen.”
Warum machen wir das dann überhaupt, wenn wir uns soviele Probleme damit einfangen?
Susanne: “Eigentlich ist es meiner Meinung nach nur gerechtfertigt, wenn wir schwache Konsistenz wirklich benötigen, um bestimmte Qualitätsziele zu erreichen. Dazu gehören hohe Verfügbarkeit und hohe Skalierbarkeit. Beispiel: Amazon! :-) Ein Amazon-Architekt hat das mal so ausgedrückt:
“The first principle of successful scalability is to batter the consistency mechanisms down to a minimum, move them off the critical path, hide them in a rarely visited corner of the system, and then make it as hard as possible for application developers to get permission to use them.” [1]
Nun sind wir nicht alle Amazon. Gleichzeitig haben verteilte Transaktionen mittlerweile einen schlechten Ruf, weil sich 2-Phase-Commit zum Beispiel negativ auf die Verfügbarkeit auswirken kann. Wenn ein Knoten ausfällt, sind die Transaktion und alle anderen Knoten erstmal blockiert. Außerdem benötigt es sehr viel Kommunikation (Latenz!) und wirkt sich daher negativ auf den Durchsatz aus.
Häufig ist das Problem eher, dass wir uns von falschen Paradigmen leiten lassen, wie beispielsweise der Glaube, dass auch “langlaufende Prozesse”, wie beispielsweise ein ganzer Bestellvorgang, atomar in einer Transaktion laufen müssten. Das ist aus fachlicher Sicht ganz oft nicht der Fall [2]. Daher erstmal die Fachlichkeit genau verstehen, damit nicht aus falschem Verständnis Transaktionen eingesetzt werden, wo es gar nicht angezeigt ist. Jetzt machen wir Sagas. Da fallen dann einige dieser Probleme weg, aber wir fangen uns natürlich neue ein.
Also zusammenfassend: meistens sind die folgenden Qualitätsattribute im Spiel: Hohe Verfügbarkeit, hohe Skalierbarkeit, Resilienz und lose Kopplung. Da sollte man dann hellhörig werden und sehr genau hinterfragen, was tatsächlich benötigt wird und welche Konsistenzstufen dann noch möglich sind.
Ein anderes Beispiel, wo man schwer um Eventual Consistency rumkommt, ist Offline-Fähigkeit. Wenn meine Anwendung mit erwarteten Netzwerkpartition oder geringer Bandbreite klarkommen muss, aber trotzdem nahtlos flüssig laufen soll, muss ich wohl oder übel die Daten auf das Edge-Device mit schwacher Konsistenz replizieren.
In Deinem Abstract für den Vortrag beim Midsommar taucht der Begriff “Lost Updates” auf. Was bedeutet das?
Susanne: “Der Begriff kommt aus der Datenbankwelt und ist eine spezielle Nebenläufigkeitsanomalie, die auf einen Schreib- und einen Schreib-Lese-Konflikt zurückgeht. Von diesen Anomalien gibt es ganz viele. Bei dieser Anomalie können einzelne Änderungen verloren gehen, wenn Daten parallel verarbeitet werden. Wenn einzelne Änderungen verloren gehen, so ist dies meistens auch aus Sicht der Fachabteilung ein Problem. Es gibt aber auch andere Anomalien, wo dies nicht so offensichtlich ist. Daher sind dies auch alles fachliche Entscheidungen und nicht jede Anomalie muss technisch verhindert oder nachträglich aufgelöst werden. Daher ist hier Abstimmung und Kommunikation mit den Domain Experten gefragt.”
Wie sehen vereinfacht Lösungen dazu aus?
Susanne: “Beim fachlichen Modellieren kann man den Schnitt so machen, dass es möglichst wenig Konfliktpotential gibt. Konkrete Beispiele für “konflikt-freie” Daten sind unveränderliche Daten (immutable) und Daten, die mit monotonen Funktionen stets on-the-fly berechnet werden können.
Ganz allgemein habe ich eine Taxonomie und Guidelines dazu aufgestellt und Entwurfsmuster beschrieben, die Entwickler und Architekten nutzen können, um zu einem nöglichst optimalen Schnitt zu kommen:
ECD3-Data-Model-Design-Guide-v1.0.pdf
Das Ganze macht ungefähr die Hälfte der Dissertation aus, die ich gerade abschließe.”
Du hast die Sachen auch in Projekten erprobt. Was wären allgemein verständliche Beispiele. Was war die spannendste Fachlichkeit, die Du so gesehen hast?
Susanne: “Reflexartig wird der Warenkorb in einem Online-Shop als Beispiel genannt. Das funktioniert auch immer toll. … New Work und verteilt gemeinsam Arbeiten sind ein spannendes Thema wegen Anforderungen wie Offline-Fähigkeit. Ich möchte ja von überall aus arbeiten können. Idealerweise von dort, wo ich meine jeweilige Aufgabe am besten erledigen kann. Es gibt Menschen, die sind am kreativsten, wenn Sie sich in die Natur zurückziehen können.
Die bei weitem anspruchsvollste Domäne, die ich bisher kennenlernen durfte, ist die der Landwirtschaft. Super komplex und wird total unterschätzt. Traktoren waren die ersten autonomen Fahrzeuge. Hightech pur. Das Gegenteil von dem, was die meisten erwarten. Im Moment laufen da sehr viele spannende Projekte in Richtung Nachhaltigkeit, also auch eine sinnstiftende Tätigkeit. Diese Domäne kann ich jedem nur empfehlen.”
In Deinem Vortrag erklärst Du das bestimmt genauer. Welche Vorkenntnisse sollten Teilnehmende mitbringen?
Susanne: “Grundverständnis von verteilten Systemen, Nebenläufigkeit und Transaktionen. Ein bisschen DDD wäre auch nicht verkehrt.”
Vielen Dank, dass Du Dir die Zeit für das Interview genommen hast! Ich freue mich schon auf den Vortrag auf dem Architektur-Midsommar!!
[1] Joseph M. Hellerstein and Peter Alvaro. Keeping CALM: when distributed consistency is easy. Commun.ACM, 63(9):72–81, 2020.
[2] Gregor Hohpe. Starbucks Does Not Use Two-Phase Commit, 2004
Mehr Anregungen könnt Ihr am 24. Juni 2021 bei unserem Architektur-Midsommar 2021 bekommen. Einfach anmelden! Neben dem Vortrag von Susanne Braun gibt es noch einige weitere spannende Programmpunkte dort zu entdecken. Save the date…