Event-Driven Architecture auf AWS, Teil I: Die Grundlagen

Komponenten eines ereignisgesteuerten Systems kommunizieren miteinander, indem sie Events veröffentlichen und abonnieren. Diese asynchrone Integration bringt erhebliche nicht-funktionale Vorteile mit sich. Sie entkoppelt zum Beispiel die Lebenszyklen der integrierten Komponenten. Das System kann bis zu einem gewissen Grad selbst dann weiterarbeiten, wenn einzelne Services nicht verfügbar sind. So sinkt zugleich der Koordinationsaufwand für das Deployment aktualisierter Komponenten und die Weiterentwicklung des Systems.

Eine grundlegende ereignisgesteuerte Integration besteht aus zwei Teilen: Eine Systemkomponente kann Events veröffentlichen, die wichtige Vorgänge in ihrem Lebenszyklus beschreiben, und sie kann auf Events reagieren (also abonnieren), die andere Teile des Systems veröffentlichen. Schauen wir uns an, welche Managed Services wir dafür nutzen können.

AWS Simple Notification Service (SNS) ist ein vollständig verwalteter Service, mit dem Sie Benachrichtigungen versenden können, die andere Komponenten des Systems konsumieren. Dank seines serverlosen Charakters und der günstigen Preise ist SNS bestens geeignet, um Events zu veröffentlichen. Abbildung 1 zeigt einen Service namens "Producer", der seine Events über ein SNS-Topic publiziert.

Abbildung 1: Der Service "Producer" veröffentlicht Events an ein SNS-Topic.

Aber was ist mit dem Service "Consumer" auf der rechten Seite der Abbildung? Wie kann er die vom Producer veröffentlichten Nachrichten abonnieren?

SNS unterstützt die Zustellung von Nachrichten über mehrere Protokolle, etwa HTTP, das Auslösen von AWS-Lambda-Funktionen, SMS und weitere. Auf dem Papier wirkt es naheliegend, dass der Consumer einen HTTP-Endpunkt bereitstellt und diesen als Ziel für das SNS-Topic nutzt, wie in Abbildung 2 dargestellt.

Abbildung 2: Ein SNS-Topic kann Nachrichten an HTTP-Endpunkte weiterleiten. Doch ist das die optimale Lösung?

Aber ist das wirklich die beste Lösung? Angenommen, die beiden Services Producer und Consumer gehören unterschiedlichen Teams – wer ist dann für das SNS-Topic zuständig? Das Producer-Team muss dafür sorgen, dass das Topic korrekt konfiguriert ist, um seine Nachrichten entgegenzunehmen, während die Teams hinter den konsumierenden Services darauf achten müssen, dass die Ziele jederzeit stimmen. Eine solche geteilte Verantwortung ist ein Garant für Reibungsverluste. Schauen wir uns deshalb eine andere Option an.

AWS SQS ist eine vollständig verwaltete Event-Queue, die Nachrichten (Events) von Producern temporär vorhält, bis sie von Consumern verarbeitet werden. Sie ermöglicht eine verteilte Event-Verarbeitung mit Load Balancing über mehrere Consumer hinweg – entscheidend für die Fehlertoleranz in ereignisgesteuerten Workflows. Aus meiner Sicht bietet SQS außerdem eine deutlich bessere Sicht auf die Queues als SNS-Topics sowie komfortable Steuerungsmöglichkeiten, wie Nachrichten an Consumer ausgeliefert werden.

Da SQS eines der von SNS-Topics unterstützten Ziele ist, richten wir eine Queue für die Nachrichten ein, die von den "Consumer"-Services verarbeitet werden sollen, wie in Abbildung 3 dargestellt.

Abbildung 3: SQS als Mechanismus zum Konsumieren von Events.

Mit diesem Setup haben Sie klare Verantwortungsgrenzen:

• Das SNS-Topic für das Veröffentlichen von Nachrichten gehört dem Team, das für den ursprünglichen Service (Producer) zuständig ist.
• Die SQS-Queue für das Konsumieren von Nachrichten gehört dem Team, das für den abonnierenden Service (Consumer) zuständig ist.

Diese Trennung der Zuständigkeiten zwischen den beiden Services muss sich auch in der Architektur des Systems widerspiegeln.

Es ist allgemein anerkannt, dass ein Microservice den Zugriff auf seine Daten über eine klar definierte öffentliche Schnittstelle bereitstellen sollte, während seine Datenbank als Implementierungsdetail gilt und vor Consumern verborgen bleiben sollte. Diese strikte Kapselung des Persistenzmechanismus sorgt für klarere Verantwortungsgrenzen, mehr Spielraum bei der Weiterentwicklung von Microservices und eine deutlich bessere Kontrolle über öffentliche Schnittstellen.

Der vom System genutzte Message Bus ist nichts anderes als ein weiterer Persistenzmechanismus – wenn auch ein deutlich eingeschränkter – und sollte entsprechend behandelt werden. Daher braucht jeder (Micro-)Service zusätzlich zur Datenbank ein SNS-Topic zum Veröffentlichen von Events und eine SQS-Queue zum Konsumieren von Events, wie in Abbildung 4 dargestellt:

Abbildung 4: Eine EDA erfordert klare Verantwortungsgrenzen – nicht nur für Datenbanken, sondern auch für deren Messaging-Mechanismen (SNS und SQS).

Die Pfeile zwischen den Services – die Subscriptions von Topics auf Queues – gehören zu einer höheren Abstraktionsebene der Architektur als die Services selbst. So könnte es zum Beispiel ein CloudFormation-Template für jeden einzelnen Service und ein übergeordnetes CloudFormation-Template für das resultierende Gesamtsystem geben. Letzteres ist für die Definition der Subscriptions zuständig.

Erwähnenswert ist, dass eine Subscription nicht bedeutet, dass alle veröffentlichten Events ungefiltert bei den Consumern landen; eine Subscription kann einen Filter festlegen, der nur die für den jeweiligen Consumer relevanten Events weiterleitet.

Dieser Ansatz folgt dem Prinzip smart endpoints, dumb pipes, das für die Einfachheit und Flexibilität verteilter Systeme essenziell ist. Demnach soll die Intelligenz – die Logik – in den Services selbst (den Endpunkten) liegen und nicht in den Infrastrukturkomponenten der Integration (den Pipes). Die Pipes – also Messaging-Infrastruktur und Kommunikationskanäle – sollen ausschließlich dafür sorgen, dass Daten zuverlässig zwischen Services transportiert werden. Ziel ist es, Abhängigkeiten zwischen Services zu reduzieren, um Skalierung, Debugging und schnellere Entwicklung zu erleichtern und zugleich die Engpässe und die Komplexität zu vermeiden, die typischerweise mit ausgefeilter Middleware einhergehen.

Damit wird es Zeit, einen Blick auf die übrigen Messaging-Optionen auf AWS zu werfen.

Wie in der Einleitung erwähnt, gibt es viele weitere AWS-Managed-Services rund um Messaging. An dieser Stelle möchte ich die anderen Optionen kurz beleuchten und erläutern, warum die oben beschriebene Lösung in 80 % der Fälle die bessere Wahl ist.

Das erste "S" in SNS und SQS steht für "simple" – und das aus gutem Grund. SNS und SQS sind einfache Services. EventBridge ist beim Filtern und Routen von Nachrichten deutlich flexibler. Aus meiner Sicht kommt es dem Konzept eines Enterprise Message Bus aus den SOA-Tagen näher. Statt "dumb pipes" erhalten Sie einen zentralen Knotenpunkt, der Events über alle Komponenten – und sogar über mehrere Systeme hinweg – entgegennimmt und routet. EventBridge hat selbstverständlich seine Anwendungsfälle – etwa wenn Sie Drittsysteme anbinden müssen.

Sowohl Kinesis als auch MSK sind Services für die Verarbeitung von Streaming-Daten. Man kann sagen, dass Streaming-Daten eine Teilmenge der Event-Driven Architecture sind. In beiden Fällen werden Nachrichten asynchron veröffentlicht und konsumiert. Das Nutzungsmuster ist jedoch ein anderes: Während sich klassische EDA auf einzelne Events oder Nachrichten konzentriert, geht es beim Arbeiten mit Streaming-Daten um die Verarbeitung kontinuierlicher Ströme zusammenhängender Events – und das lässt sich mit klassischen Message-Bus-Lösungen oft nicht so effizient bewältigen. Genau dafür gibt es Tools wie Kinesis und MSK. Wenn Sie keine kontinuierlichen Nachrichtenströme verarbeiten müssen, ergeben einfachere Tools wie SNS und SQS ein schlankeres System.

Amazon MQ ist ein verwalteter Message-Broker-Service für Protokolle wie ActiveMQ und RabbitMQ. Er ist besonders nützlich, wenn Legacy-Systeme in die Cloud migriert werden sollen oder Systeme unverändert in mehreren Cloud-Umgebungen laufen müssen. Amazon MQ bietet zwar einen vollwertigen Message Broker samt Unterstützung fortgeschrittener Patterns, bringt aber im Vergleich zur Schlichtheit von SNS und SQS zusätzlichen Betriebsaufwand und mehr Komplexität mit sich.

1. Event-Driven Architecture auf AWS, Teil I: Die Grundlagen (aktueller Beitrag)
2. Event-Driven Architecture auf AWS, Teil II: Die fortgeschrittenen Grundlagen
3. Event-Driven Architecture auf AWS, Teil III: Die anspruchsvollen Grundlagen

Ursprünglich veröffentlicht auf https://vladikk.com.