Communiceren met Kafka: Wat is de beste manier?

Event streaming kan helpen om de datastromen binnen uw organisatie te identificeren en managen en helpt om deze in te zetten voor real-time decision making, business intelligence en een naadloze data integratie. In vorige blogs besproken we al eens de waarde van event streaming  en stream processing om real-time inzichten te verkrijgen in uw data.

Maar voordat u van deze voordelen kunt genieten moeten uw applicaties in staat zijn om data uit te wisselen met behulp van Kafka. Dus hoe kunt u uw apps de Kafka taal laten spreken? Daar zijn twee mogelijkheden voor. Of u zorgt ervoor dat uw app Kafka spreekt, of u maakt gebruik van een vertaler tussen uw app en Kafka. In deze blog bespreken we de implicaties van beide opties en bespreken we wat benodigd is voor implementatie.

Optie 1: Maak je app Kafka native

Wanneer je native Kafka nastreeft, implementeer je de Kafka Consumer en/of Publisher APIs direct in uw app. Kafka heeft een dumb broker/smart consumer architectuur, dit betekent dat uw app een hoge mate van controle heeft over de wijze waarop berichten worden geconsumeerd en gepubliceerd. Dit zorgt ervoor dat uw app volledig gebruik kan maken van Kafka features zoals retentie, met de mogelijkheid om elk bericht te herlezen, en near-real time consumptie gezien je app op eigen snelheid direct contact kan leggen met het cluster.

Maar met macht komt verantwoordelijkheid, en wanneer u consumers of publishers op zet, zijn er veel configuratie opties die moeten worden geoptimaliseerd afhankelijk van de vereisten aan uw app. We zullen hier een aantal belangrijke configuratie opties toelichten die vaak wat fine tuning nodig hebben:

Voor consumers:

• Doorvoer en latency: Events in Kafka worden in (kleine) batches geleverd aan consumenten. Developers kunnen het minimale aantal berichten dat in één batch wordt teruggestuurd verhogen en kunnen de tijd tussen batchverzoeken verkorten. Het vergroten van de batchgrootte verbetert ook het resourceverbruik en de algehele efficiëntie, en heeft ook invloed op de latency. Het instellen van een minimale batchgrootte helpt ook om de doorvoer te vergroten, en door uw maximale batchgrootte te vergroten, helpt dit ook de latentie te vergroten door het aantal verzoeken te verlagen.
• Rekening houden met data verlies: Afhankelijk van de duurzaamheidsvereisten, kunnen consumers meer controle nemen door hun consumptie voortgang vast te leggen. Het is het gemakkelijkst om het auto-commit-systeem van Kafka te gebruiken, door deze interval te verkorten of te vergroten, kunt u een afweging maken tussen data duplicatie en data verlies. Als geen data duplicatie of data verlies (tenminste aan de kant van de consument) acceptabel is, kunt u ook handmatig de commit APIs van Kafka gebruiken om de voortgang van de consumer vast te leggen aan Kafka.
• Herstel: wanneer een van uw consumer groepen faalt, is er wat tijd om te herstellen, zodat ze vervolgens weer kunnen deelnemen aan de berichten consumptie. Als het herstel echter te lang duurt, kan er ook een herbalancering plaatsvinden en kunnen het overnemen. Door de hartslaginterval te wijzigen, kunt u ook optimaliseren hoe vaak u wilt controleren of consumer groepen actief en levend , zodat u sneller kunt reageren op falende consumers. Dit gaat natuurlijk gepaard met een prijs van extra overhead.
• Herbalancering en schaalbaarheid: In Kafka kunnen consumers in groepen samenwerken om gelijktijdig berichten van topic partities te consumeren. Hoewel het inschakelen van consumer groepen eenvoudig is, kan het herbalanceren van werk tussen consumer groepen lastig zijn. Met herbalancering worden de partities van een onderwerp toegewezen aan leden in een consumer groep, afhankelijk van de workload die ze aankunnen. Herbalancering heeft invloed op de prestaties van een consumer groep, en hoewel herbalancering nodig is in dynamische omgevingen met variabele workloads, kunnen statische groepslidmaatschappen en kortere intervallen van herbalancering bijdragen aan betere prestaties in minder dynamische omgevingen.

Voor producers:

• Duurzaamheid: om te voorkomen dat berichten verloren raken, kunt u uw producer configureren om te wachten op volledige of gedeeltelijke bevestiging van de broker dat de events zijn ontvangen en gereproduceerd voor een bepaald aantal replica’s. Het wachten op deze bevestiging verhoogt de latentie maar verhoogt ook de duurzaamheid.
• Volgorde: Door de volledige bevestiging in te zetten bent u ervan verzekerd dat uw events in de juiste volgorde aankomen op de broker. Hierdoor kan de producer meerdere berichten tegelijkertijd sturen. Wanneer u volledige bevestiging niet gebruikt kunt u niet meerdere berichten tegelijkertijd sturen als u ook de volgorde van de berichten wilt behouden.
• Betrouwbaarheid: Transacties kunnen worden gebruikt om ervoor te zorgen dat gebeurtenissen exact één keer worden geschreven over partities heen in combinatie met idempotentie. Transacties in Kafka zorgen ervoor dat events binnen een transactie exact één keer, of helemaal niet, worden geproduceerd. Idempotentie moet ook worden ingeschakeld, dit zorgt ervoor dat nieuwe leveringen nooit leiden tot dubbele berichten op partitie niveau. Over het algemeen zal uw keuze voor leveringssemantiek zowel uw consumenten- en producentenconfiguraties als uw prestaties beïnvloeden.
• Doorvoer en latentie: Batching zorgt ervoor dat een producer meerdere events kan bundelen in een enkele request naar de broker. Dit zorgt ervoor dat de latentie toeneemt, maar ook dat de doorvoer versnelt. Vergelijkbaar met batching wordt ook compressie ondersteunt, dit zorgt ook voor een hogere latentie en verhoogt tegelijkertijd de doorvoer doordat de request sizes zijn afgenomen.

Configuraties van producers en consumers zijn zelden definitief en statisch. Zorg ervoor dat u uw Kafka oplossing regelmatig monitort om zeker te zijn dat uw consumers en producers werken zoals verwacht. Bijvoorbeeld wanneer u Kafka beheert met eMagiz, kunt u eenvoudig consumenten monitoren om te zien of ze goed werken en in staat zijn om berichten te consumeren zonder vertraging. Tools zoals eMagiz voor het beheren van uw Kafka cluster kunnen helpen om problemen te identificeren in uw data consumptie en productie, en de juiste acties te ondernemen.

Optie 2: Gebruik een vertalen

Hoewel het spreken van Kafka de meeste flexibiliteit geeft om doorvoer, latentie en betrouwbaarheid te maximaliseren, is het niet altijd wenselijk om applicaties te migreren om API’s te gebruiken die native Kafka spreken.

Een van de belangrijkste use cases om Kafka te gebruiken is het als gecentraliseerde communicatie laag in te zetten voor alle applicaties en services binnen een organisatie. Het is essentieel dat niet alleen native Kafka applicaties met elkaar connecteren maar dat legacy applicaties dat ook kunnen. Gelukkig is er een groot framework van connectoren beschikbaar die een vertaling kunnen maken tussen verschillende communicatie protocollen en Kafka. De meeste connectoren zijn gebouwd met Kafka Connect, een framework dat wordt aangeboden als onderdeel van het Kafka open source project. Kafka Connect biedt een basis om schaalbare, gedistribueerde en betrouwbare connectoren op te zetten. U kunt Kafka Connect API’s gebruiken om uw eigen connector te bouwen, maar in andere gevallen zijn pre-build Kafka Connect connectoren al beschikbaar om te gebruiken. Het voordeel van pre-build connectoren is dat de consumer/producer instellingen al zijn geoptimaliseerd voor de interfacing technologie en dat scaling wordt beschouwd als out-of-the-box, zodat u alleen die instellingen hoeft in te stellen die variabel zijn voor uw specifieke implementatie. Aangezien Kafka Connect een framework is in plaats van een platform, vereist de implementatie en configuratie van een Kafka Connect-cluster wel clusterbeheer of servicetoezicht.

Naast Kafka Connect zijn er ook platforms voor het bouwen van connectoren om te communiceren met andere applicaties. Met een platform kunt u een connector bouwen tussen Kafka en andere technologieën zonder dat u zich zorgen hoeft te maken over hoe deze connectoren worden geïmplementeerd en beheerd. Een voorbeeld hiervan is een REST-proxy/interface voor Kafka. Een dergelijke REST-proxy kan worden gebruikt om de productie en consumptie van berichten mogelijk te maken, zodat elke toepassing die HTTP-berichten kan verzenden en ontvangen, kan communiceren met Kafka. Integratieplatforms en API-beheerplatforms zoals eMagiz, kunnen u helpen om snel een REST-proxy voor uw Kafka-cluster te bouwen.

Wat is de beste optie voor u? Het is aan u!

Zowel native Kafka-consumers en producers als connectorapplicaties en -platforms zoals Kafka Connect en eMagiz zijn beide geweldige opties voor interfacing met Apache Kafka.

Voor toepassingen en services met hoge eisen voor het verbruik en de levering van evenementen, zoals banktoepassingen, biedt het gebruik van de native Kafka API’s de meeste controle over doorvoer, latentie en betrouwbaarheid. Ook voor nieuwe toepassingen kan een directe koppeling met Kafka een efficiënte manier zijn om met minimale inspanning te integreren met een groot aantal andere toepassingen.

Voor de meeste bestaande applicaties zijn connectoren de beste optie om eenvoudig in te pluggen in het Kafka event management platform. Met behulp van deze connectoren kunnen applicaties snel profiteren van de voordelen van het streamen van gebeurtenissen zoals datacentralisatie, realtime en hoge doorvoer datadeling, en data retentie.

eMagiz kan u helpen een Kafka oplossing op te zetten en te beslissen wat voor u de beste manier is om applicaties, consumers en producers te connecteren, of uw apps nu worden vertaald naar Kafka of dat er een vertaling wordt gemaakt. Mocht u vragen hebben over dit onderwerp of mocht u de mogelijkheden voor uw organisatie willen bespreken, dan kunt u contact met ons opnemen. We komen graag in contact om u te helpen met Kafka!

Door Mark de la Court, Product owner Event management @ eMagiz