Serverless Stream Processing bedeutet, Echtzeit-Datenpipelines zu betreiben, ohne die darunterliegenden Server oder Cluster bereitstellen, dimensionieren oder betreiben zu müssen. Die Plattform skaliert die Rechenleistung je nach Volumen der eingehenden Events nach oben und unten, und Sie zahlen nur für das, was Sie nutzen. Ihr Team schreibt die Verarbeitungslogik, ob als Funktion oder als SQL-Statement, und der Anbieter führt sie aus.
Der Ansatz ist attraktiv, denn Stream-Processing-Cluster gehören zu den Systemen, die sich am schwersten dimensionieren und stabil betreiben lassen. Doch „serverless“ umfasst im Streaming zwei recht unterschiedliche Ansätze, die nicht austauschbar sind. Die Wahl des falschen Ansatzes ist der häufigste Grund, warum Serverless-Streaming-Projekte an ihre Grenzen stoßen.
Ein Serverless-Service hat im Allgemeinen drei Merkmale. Es gibt keine Server oder Cluster, die Sie bereitstellen müssen. Die Kapazität skaliert automatisch mit der Nachfrage, teilweise bis auf null. Abgerechnet wird nach Nutzung statt nach reservierter Kapazität. Übertragen auf Stream Processing bedeutet das: Events werden beim Eintreffen gefiltert, transformiert, verknüpft oder aggregiert, ohne dass Ihr Team die Rechenleistung verwalten muss, die diese Arbeit erledigt.
Das erste Modell ist Functions as a Service. Eine Funktion wie AWS Lambda wird durch neue Datensätze in einem Stream ausgelöst, verarbeitet diese in kleinen Batches und beendet sich anschließend. Die Serverless Lens des AWS Well-Architected Framework beschreibt dieses Muster mit Amazon Kinesis als Stream, Lambda als Consumer und DynamoDB als Speicher für die Ergebnisse.
Das zweite Modell ist eine Serverless-Stream-Processing-Engine. Hier läuft ein vollständiges Stream-Processing-Framework, in der Regel Apache Flink, als Managed Service, der sich selbst skaliert. Ein Beispiel ist Confluent Cloud for Apache Flink: Sie übermitteln Flink-SQL-Statements, und der Service übernimmt Autoscaling, Parallelisierung und Lastverteilung, einschließlich der Skalierung auf null, wenn ein Workload ruht. Die Engine läuft kontinuierlich weiter, was für alles entscheidend ist, das auf State angewiesen ist.
Die meisten Serverless-Streaming-Architekturen haben denselben Aufbau. Producer wie Anwendungen, Geräte und Datenbanken veröffentlichen Events auf einer Event Streaming Platform wie Apache Kafka oder Amazon Kinesis. Ein serverloser Prozessor liest von dieser Plattform, wendet die Logik an und schreibt die Ergebnisse in eine Senke: ein weiteres Topic, eine Datenbank, ein Data Warehouse oder eine Anwendung, die darauf reagiert.
Der Unterschied zwischen den beiden Modellen liegt im Prozessor. Eine Funktion erhält einen Batch von Datensätzen, verarbeitet ihn und beendet sich. Jeder State, den sie zwischen den Batches benötigt, muss weitergereicht oder extern gespeichert werden. Eine Serverless-Engine läuft als langlebiger Job mit eigenem verwaltetem State. So kann sie den Kontext eines Windows oder eines Joins über Millionen von Events hinweg halten, ohne eine externe Datenbank.
Die richtige Wahl hängt davon ab, was sich die Verarbeitung merken muss. Diese Tabelle vergleicht die beiden Serverless-Modelle mit der selbst betriebenen Variante, die die meisten Teams kennen.
| Functions (z. B. AWS Lambda) | Serverless-Stream-Processing-Engine (z. B. Serverless Flink) | Selbst betriebene Engine (Flink, Kafka Streams) | |
|---|---|---|---|
| Infrastruktur | Nichts zu verwalten | Nichts zu verwalten | Cluster müssen dimensioniert, gepatcht und überwacht werden |
| State | Wird zwischen Aufrufen weitergereicht oder extern gespeichert | Wird von der Engine verwaltet | Wird von der Engine verwaltet, von Ihnen betrieben |
| Windowing | Kurze Tumbling Windows (bis zu 15 Minuten bei Lambda) | Tumbling, Sliding und Session Windows beliebiger Länge | Tumbling, Sliding und Session Windows beliebiger Länge |
| Skalierung | Pro Batch, gekoppelt an Shards oder Partitionen | Automatisch, innerhalb der von Ihnen festgelegten Grenzen | Manuell oder per Skript |
| Kostenmodell | Pro Aufruf und Laufzeit | Pro verbrauchter Recheneinheit | Reservierte Infrastruktur plus Personalaufwand |
| Am besten geeignet für | Zustandslose, sprunghafte Logik, Event für Event | Zustandsbehaftete Pipelines ohne Betriebsaufwand | Sehr große, gleichmäßige Workloads mit internem Know-how |
Zustandslose (stateless) Verarbeitung behandelt jedes Event für sich. Irrelevante Datensätze herausfiltern, Events an das richtige Ziel weiterleiten, personenbezogene Daten maskieren oder ein Event per Lookup anreichern: All das ist zustandslos. Diese Aufgaben eignen sich gut für Functions, insbesondere wenn der Traffic sprunghaft ist und zwischen den Spitzen keine Kapazität ungenutzt bereitstehen soll.
Zustandsbehaftete (stateful) Verarbeitung braucht ein Gedächtnis für frühere Events. Transaktionen pro Kunde und Stunde zählen, einen Bestellungs-Stream mit einem Lieferungs-Stream verknüpfen oder eine Abfolge von Events erkennen, die auf Betrug hindeutet: All das hängt von State ab, der über viele Events hinweg besteht. Eine Serverless-Engine ist genau dafür ausgelegt. Sie erstellt Checkpoints des States, stellt ihn nach einem Ausfall wieder her und verarbeitet verspätete Events, ohne dass Sie diese Mechanismen selbst entwickeln müssen.
Functions können einfache Aggregationen bewältigen, doch ihre Grenzen zeigen sich schnell, wenn die Anforderungen wachsen. Die Tumbling Windows von Lambda sind auf 15 Minuten begrenzt, und der State, der innerhalb eines Windows zwischen Aufrufen weitergereicht wird, ist in seiner Größe beschränkt. Alles, was länger oder größer ist, muss in einen externen Speicher, was Latenz, Kosten und eine weitere zu betreibende Komponente mit sich bringt.
Auch die Zustellsemantik verdient Aufmerksamkeit. AWS weist darauf hin, dass bei Kinesis doppelte Datensätze auftreten können, weshalb Consumer und Producer idempotent sein müssen. Die Parallelität ist an die Anzahl der Shards oder Partitionen gekoppelt. Die Durchsatzplanung ist also nicht verschwunden, sie hat sich nur verlagert.
Zuletzt sind die Kosten zu berücksichtigen. Nutzungsbasierte Abrechnung ist effizient für schubweise oder volumenschwache Streams. Bei einer Pipeline, die rund um die Uhr hohe Volumen verarbeitet, kann die Abrechnung pro Aufruf oder pro Recheneinheit teurer sein als reservierte Kapazität. Die Serverless-Engines begegnen dem teilweise, indem Sie die maximale Rechenleistung begrenzen können, die ein Workload nutzen darf.
Jede große Cloud bietet mindestens eine Möglichkeit, Streams zu verarbeiten, ohne Cluster zu verwalten:
Wenn Ihre Events bereits in Kafka liegen, vermeidet eine Serverless-Engine, die Kafka nativ liest, dass Daten zuerst in einen separaten Cloud-Stream kopiert werden müssen. Wenn Sie lieber visuell entwickeln statt Code zu schreiben, bieten Tools für No-Code Stream Processing einen weiteren Weg.
Beginnen Sie mit der Verarbeitungslogik, nicht mit der Plattform. Wenn jedes Event für sich verarbeitet werden kann und der Traffic schubweise eintrifft, sind Functions meist die einfachste und günstigste Option. Benötigt die Pipeline Joins, Windows von mehr als ein paar Minuten oder Exactly-once-Ergebnisse, nimmt Ihnen eine Serverless-Stream-Processing-Engine den Großteil der Betriebsarbeit ab, ohne Sie in die Grenzen von Functions zu zwingen.
Betrachten Sie anschließend Volumen, Kompetenzen und bestehende Systeme. Bei gleichmäßig sehr hohem Durchsatz kann selbst betriebene oder reservierte Kapazität wirtschaftlicher sein, sofern Ihr Team sie betreiben kann. Die meisten Unternehmen landen bei einer Kombination: Functions für die leichtgewichtige Event-Verarbeitung, eine Serverless-Engine für zustandsbehaftete Pipelines und eine klare Regel, welcher Workload wohin gehört.
Mimacom konzipiert, entwickelt und betreibt Data-Streaming-Plattformen auf Basis von Apache Kafka und Apache Flink. Als IBM-Partner mit Confluent-Beratungsleistungen unterstützen wir Teams dabei, Stream-Processing-Workloads nach Confluent Cloud zu migrieren, einschließlich Serverless Flink, und zu entscheiden, welche Logik in Functions, Managed Engines oder selbst betriebene Cluster gehört.
Unsere Teams haben produktive Streaming-Lösungen in den Bereichen Banking, Handel, Transport und Fertigung umgesetzt. Diese Erfahrung prägt, wie wir State, Zustellgarantien und Kosten angehen, bevor eine Pipeline live geht. So reduziert Serverless tatsächlich den Betriebsaufwand, statt die Probleme nur an eine andere Stelle zu verschieben.
AWS Lambda eignet sich gut für zustandsloses Stream Processing, etwa zum Filtern, Weiterleiten und Anreichern von Datensätzen aus Kinesis oder Amazon MSK, insbesondere bei sprunghaftem Traffic. Für zustandsbehaftete Verarbeitung ist es weniger geeignet. Tumbling Windows sind auf 15 Minuten begrenzt, und längere Windows oder Joins erfordern externen Speicher oder eine dedizierte Stream-Processing-Engine.
Ja, wenn Sie eine Serverless-Stream-Processing-Engine statt Functions einsetzen. Services wie Confluent Cloud for Apache Flink verwalten State, Checkpoints und Wiederherstellung für Sie und skalieren dabei automatisch. Functions können zwischen Aufrufen nur begrenzt State mitführen und eignen sich daher kaum für lange Windows, Joins oder Mustererkennung.
Das hängt vom Traffic-Muster ab. Nutzungsbasierte Preise sind bei schubweisen, geringen oder unvorhersehbaren Volumen meist günstiger, da Sie nicht für ungenutzte Kapazität zahlen, und der Personalaufwand für den Clusterbetrieb entfällt. Bei gleichmäßig sehr hohem Durchsatz kann reservierte oder selbst betriebene Kapazität günstiger sein. Es lohnt sich daher, beide Varianten durchzurechnen, bevor Sie sich festlegen.
Serverless Stream Processing zahlt sich aus, wenn Sie das Modell auf den Workload abstimmen: Functions für einfache, schubweise Event-Verarbeitung und Serverless-Engines für zustandsbehaftete Pipelines. Sprechen Sie mit unserem Confluent-Team darüber, welche Ihrer Streaming-Workloads serverless laufen können, oder entdecken Sie unsere Confluent-Beratungsleistungen.