In dieser Kafka-Serie beschäftigen wir uns mit den Konzepten und Best-Practise-Beispielen rund um Apache Kafka. Im ersten Teil geht es um das grundlegende Konzept hinter der Technologie bzw. um dessen Abgrenzung und Einordnung in die Welt der Datenströme und Messaginglösungen. Aber wir beschreiben auch die Lücken, die nach der Implementierung der Technologie entstehen und die im Rahmen von Projekten berücksichtigt werden sollten.

Konzepte, um Daten und Informationen zwischen Computern zu verschieben oder einer Person oder einem Service bereitzustellen, haben sich stetig gewandelt. Dabei gibt es bis heute nur zwei konzeptionelle Verfahren, um Nachrichten (Messages) von A nach B zu übertragen. In der technischen Realisierung unterscheiden sich die Lösungen der Hersteller signifikant. Jedes technische Integrationssystem bzw. jede Softwarelösung hat ihre Stärken, aber auch Schwächen. Dessen sollte man sich bewusst sein. Die hinterlassenen Lücken müssen bekannt sein und je nach Anwendungsfall gegebenenfalls geschlossen werden – beispielsweise durch zusätzliche Software oder organisatorische Verfahren.

© Deepshore GmbH/sense:ability communications GmbH – Andreas Otto

Point-to-Point-Queuing
Zum einen spricht man von einer Point-to-Point-Kommunikation, d. h. eine Message kann man sich wie einen Zettel oder auch Ordner auf einem Stapel Papieranträge in einer deutschen Behörde vorstellen. Diese Zettel werden dann nacheinander durch jeweils einen Sachbearbeiter bearbeitet. Mit diesem Stapel an Zetteln verhält es sich ähnlich wie mit einer technischen Message-Queue (einer Message-Warteschlange), in der Daten oder Informationen immer nur nacheinander bearbeitet werden können: Dieselbe Nachricht kann nie durch zwei Personen oder Datenempfänger gleichzeitig prozessiert werden, da sie physikalisch nur einmal in der Queue vorhanden ist und auch von dort verschwindet, sobald sie konsumiert wurde.

Technisch begegnet uns dieses Verfahren in den klassischen JMS-Queues (Java Message Service) verschiedener Produkte und Hersteller. Der Vorteil des Verfahrens ist, dass bei einer Eins-zu-Eins-Übertragung von Daten die Sicherstellung der vollständigen Übertragung (Transaktionalität) leichter ist, weil auch definierte Qualitäts- und Sicherheitsmechanismen dediziert implementiert werden können. Zudem werden Daten asynchron verarbeitet. Das bedeutet, dass der Konsument nicht zum Bereitstellungszeitpunkt die Daten verarbeiten muss. Ein Nachteil ist sicherlich, dass es sich am Ende immer um eine proprietäre Schnittstelle zwischen dem Sender und einem Empfänger handelt. Ist eine Nachricht für mehrere Empfänger gleichzeitig bestimmt, muss sie irgendwie kopiert und entsprechend bereitgestellt werden. In der Realität übernehmen häufig sogenannte EAI- oder ESB-Systeme (Enterprise Application Integration; Enterprise Service Bus) diese integrative Aufgabe, um technische Lücken des Verfahrens zu schließen.

Publish-Subscribe
Der Gegenentwurf zum Point-to-Point-Queuing wird als „Publish-Subscribe“ (auch Pub-Sub) bezeichnet. Stellen wir uns eine Gruppe von Menschen vor, die im Kreis sitzen und eine Person teilt ihre Nachricht laut und gut hörbar für alle mit. Eine Nachricht kann somit von mehreren Empfängern gleichzeitig empfangen und verarbeitet werden. Wir alle kennen das Verfahren vom Radioprogramm oder einem Aushang am Schwarzen Brett. Der Unterschied zum technischen JMS-Queuing ist dabei offensichtlich. Eine Nachricht kann gleichzeitig von vielen Empfängern empfangen werden, jedoch weiß der Versender nicht genau, ob und wer genau die Nachricht wirklich erhalten hat, da es keinen Kanal für eine Rückmeldung des Empfängers gibt. Durch das Fehlen eins Feedbacks erschwert sich die Möglichkeit einer einfachen Transaktionsüberwachung, da nie klar ist, wer welche Nachricht empfing. Auch die per Definition asynchrone, also verzögerte Verarbeitung von Daten ist beim reinen „Pub-Sub“ nicht gegeben, da alle Konsumenten sofort und zeitgleich „informiert“ werden.

© Deepshore GmbH/sense:ability communications GmbH – Andreas Otto

Messaging bei Kafka
Kafka ist im Grunde eine technische Mischung dieser beiden zuvor skizzierten Verfahren. Daten werden serialisiert in ein sogenanntes Topic geschrieben. Aus einem Topic kann sich wiederum eine ganze Gruppe von Datenkonsumenten bedienen, ohne dabei zu konkurrieren. Rohdaten werden einfach aus einem Log gelesen, sodass dieser Vorgang beliebig oft wiederholt werden kann. Neue Nachrichten schreibt Kafka dabei jeweils an das vorhandene Log, sobald diese im System eintreffen. Durch die mögliche Aufteilung der Daten auf verschiedene Topics, ist auch eine fachlich differenzierte Verarbeitung möglich. Dadurch können für unterschiedliche Datentypen auch geschlossene Konsumentengruppen erstellt werden, die immer nur Zugriff auf bestimmte Nachrichten haben. Es ist also genau dieses Konzept der Topics mit ihren Konsumentengruppen, das eine Mischform eines dedizierten Queuings und Publish and Subscribe herstellt.

© Deepshore GmbH/sense:ability communications GmbH – Andreas Otto

Fazit
Ob Kafka sich dabei für einen bestimmten Anwendungsfall eignet oder eher weniger, hängt davon ab, was man genau erreichen möchte und wie sich die jeweiligen Anforderungen differenzieren. Kafka liefert das gesamte Potenzial eines verteilten Systems wie beispielsweise die Möglichkeiten einer horizontalen Skalierung. Die Leistungsfähigkeit zeigt sich in der Praxis an Beispielen wie LinkedIn, Twitter oder PayPal. Jedoch sollte man sich auf der anderen Seite auch der konzeptionellen Schwächen oder besser der vorhandenen Lücken bewusst sein. So ist man gut beraten, zu mindestens das CAP-Theorem im Zusammenhang mit einer ACID-Transaktion verstanden zu haben, um nicht löchrige und mangelhafte IT-Lösungen mit einer vielversprechenden Technologie zu bauen.

Vorschau Teil 2
Im nächsten Teil der Serie betrachten wir deshalb typische Einsatzszenarien und arbeiten die Stärken von Kafka heraus. Und wo Licht ist, ist auch Schatten. So wird es auch darum gehen, wofür dieses System im Standard nicht geeignet ist und welche Lücken es hinterlässt, die anderweitig gefüllt werden müssen. Wie so oft scheitern Implementierungen und Projekte nämlich an einem mangelnden Verständnis der Grenzen und Schwächen einer Technologie. Deshalb lohnt es sich, den Blickwinkel sowohl aus technischer als auch aus fachlicher und regulatorischer Sicht zu erweitern.