Ontdek de volledige potentie van een event-driven architectuur: Hoe ontwikkel je een stream processor met eMagiz?

Een event-driven architectuur is vereist om snel en effectief te reageren op real-time gebeurtenissen in je landschap. Voorheen hebben we al eens geschreven over de voordelen van een event-driven architectuur, en hebben we benadrukt dat er verschillende architectuur componenten en investeringen nodig zijn om de voordelen van dit concept te benutten. Stream processing is zo’n component en is een geweldig hulpmiddel om met real-time gebeurtenissen te werken terwijl ze worden geproduceerd. In een eerdere blog hebben we het concept van stream processing uitgelegd. In deze technische blog lichten we de basisprincipes van het ontwikkelen van een streamprocessor toe en lees je waar je rekening mee moet houden tijdens het ontwikkelproces.

Om een streamprocessor in eMagiz te ontwikkelen zijn enkele belangrijke componenten vereist. Je begint met het bouwen van je fundament, een messaging infrastructuur. Vervolgens definieer je de stream processor logica, waarna je vervolgens een deployment infrastructuur benodigd bent. Ten slotte, moet je je stream processing applicatie beheren om beveiliging en toegang in al je applicaties af te dwingen.

Begin bij de basis, je event streaming infrastructuur

Voordat je kunt beginnen met stream processing, is het een vereiste om een event broker te hebben die events in real-time distribueert. Zo’n event broker moet zeer schaalbaar en fouttolerant zijn en moet ‘exact één keer’ leveringsgaranties bieden. Het kan zijn dat je nog nooit van deze drie attributen hebt gehoord, vandaar dat we ze eerst even kort toelichten.

Hoge schaalbaarheid

Een hoge schaalbaarheid betekent dat een hoge datadoorvoer ondersteunt moet worden zonder vertragingen te veroorzaken. Daarnaast moet een horizontale schaalvergroting van berichten van producers en consumers worden ondersteunt om bottlenecks te voorkomen. Bijvoorbeeld door inkomende events te verdelen over verschillende instanties van een bepaalde consumer. Schaalbaarheid in de broker wordt meestal bereikt door meerdere broker instanties te lanceren en inkomende evenementen parallel aan de subscribers te distribueren.

Fout tolerantie

Dit betekent dat je je kunt herstellen van storingen, hetzij in je infrastructuur of binnen een van je consumers. Wat infrastructuur betreft, zou fouttolerantie ervoor moeten zorgen dat wanneer een deel van de hardware-infrastructuur van de eventbroker uitvalt, de eventbroker kan blijven functioneren zonder gegevensverlies en zonder een significante impact op de prestaties. Afkomst (Lineage) en duplicatie zijn twee essentiële technologieën die worden gebruikt om dit te bereiken. Wanneer consumers offline gaan, moet de event broker ervoor zorgen dat er geen data verloren gaan. Retentie is een essentiële techniek die hiervoor kan worden gebuikt om ervoor te zorgen dat consumers tijdelijk offline kunnen gaan en vervolgens weer data kunnen verwerken waar ze waren gebleven.

Afleveringsgaranties

Afleveringsgaranties zorgen ervoor dat alle inkomende events exact één keer worden verwerkt. Fouttolerantie is een van de belangrijkste factoren om ‘exact één keer’ levering te garanderen. Veel frameworks ondersteunen ‘hoogstens één keer’ of ‘minstens één keer’ levering. Voor cruciale bedrijfsgegevens zoals financiële transacties, is echter een striktere verwerkingssemantiek benodigd.

Kafka is de meest populaire event broker die al deze eisen ondersteunt, als een open-source framework dat kan worden gebruikt om een gedistribueerde publish/subscribe gebasseerde messaging infrastructuur voor real-time communicatie te creëren. Kafka gebruikt een concept genaamd partitioning om ervoor te zorgen dat klanten data van veel event brokers tegelijkertijd kunnen lezen en schrijven. Deze partities worden gerepliceerd om beschikbaarheid en fouttolerantie te garanderen.

Kafka is open source en te implementeren op je eigen hardware of cloudomgeving naar keuze. Voor bedrijfstoepassingen kan het echter voordelig zijn om te kiezen voor Kafka als een service, om uptime stabiliteit en beheerfunctionaliteit op bedrijfsniveau te garanderen, zoals eMagiz Even Streaming.

Vervolgens, definieer je stream processor

Je bent klaar met het opzetten van je streamingsinfrastructuur, de volgende stap is het definiëren van je stream processor. Er zijn verschillende opties beschikbaar voor het definiëren van je stream processing applicaties. We moeten nogmaals rekening houden met niet-functionele attributen voor onze stream processor zoals fouttolerantie, schaalbaarheid en leveringsgaranties. Daarnaast moeten we rekening houden met andere aspecten zoals deployment models, batch use-cases en lookups.

Net als bij je event streaming infrastructuur moet je processor fouttolerantie, schaalbaarheid en leveringsgaranties garanderen. Dit kan worden bereikt met gedistribueerde instanties van de processor, deze werken samen naar een gemeenschappelijk doel. Sommige processors zijn sterk afhankelijk van de distributiemogelijkheden van de event-streaming infrastructuur, zoals Kafka Streams, om schaalbaarheid te bereiken, terwijl andere processors interne distributiemechanismen gebruiken, zoals Apache Flink. Door gebruik te maken van shared state stores, lineage en andere foutherstel methoden, bereiken stream processors ook fouttolerantie op een gedistribueerde manier.

De deployment modellen

Stream processors zijn erg verschillend in hun deployment modellen. Kafka Streams kan stand-alone per instantie worden geïmplementeerd. Meerdere instanties zullen elkaar automatisch herkennen om samen te werken aan hun gedeelde doel. Gewoonlijk hebben stream processing frameworks echter een centrale broker nodig om alle instances te beheren, zoals Zookeeper, die de afzonderlijke instances voor verwerking beheert. Apache Flink is hier een voorbeeld van. De geschiktheid van het deployment model hangt af van de taak die voorhanden ligt. Voor zeer variabele doorvoer snelheden kunnen geclusterde oplossingen uitstekend zijn vanwege hun vermogen om automatisch te schalen en communiceren wanneer dat nodig is. Wanneer de doorvoer echt stabiel is en de verwerking op verschillende locaties in de infrastructuur moet plaatsvinden, zijn zelfstandige processors geschikter.

Het deployment model is ook van invloed op de workload dat een stream processor aankan. Standalone processors zijn geschikter voor event-based workloads, zoals filtering en aggregaties, terwijl geclusterde oplossing ideaal zijn voor samenwerkingsgevallen zoals enrichment, maar ook voor events die door tijd worden getriggerd en batch cases, omdat ze niet afhankelijk zijn van inkomende events tot trigger jobs. Bovendien zijn stand-alone processors helemaal niet geschikt voor lookups, of iteratieve problemen die een analyse van de hele dataset vereisen, aangezien ze alleen toegang hebben tot individuele events in plaats van de volledige dataset.

Over het algemeen hangt het type processor dat je moet gebruiken af van je individuele gebruiksscenario en van je vermogen om individuele instanties te beheren of een cluster van verwerkingskracht te hosten. Hoewel zelfstandige processors gemakkelijker te implementeren zijn, zijn ze na implementatie moeilijker te onderhouden en te schalen. Geclusterde oplossingen hebben over het algemeen een hogere drempel om aan de slag te gaan. Om deze barrière te verlagen, zijn verwerkingsservices beschikbaar die abstraheren van implementatiekeuzes op infrastructuurniveau en die direct beheer implementatie en schaalbaarheid bieden.

Over het algemeen hangt het type processor dat je moet gebruiken af van je individuele gebruiksscenario en van je vermogen om individuele instanties te beheren of een cluster van verwerkingskracht te hosten. Hoewel zelfstandige processors gemakkelijker te implementeren zijn, zijn ze na implementatie moeilijker te onderhouden en te schalen. Geclusterde oplossingen hebben over het algemeen een hogere drempel om aan de slag te gaan. Om deze barrière te verlagen, zijn verwerkingsservices beschikbaar die abstraheren van implementatiekeuzes op infrastructuurniveau en die direct beheer implementatie en schaalbaarheid bieden.

Zorg ervoor dat de motor blijft lopen met: management, monitoring en governance.

Zodra je je infrastructuur hebt opgezet en je stream processing applicatie hebt geïmplementeerd, heb je je streamprocessor werkend. Maar blijft het ook werken? En wat gebeurt er als je omgeving groeit, hoe houd je het beheersbaar? Een cruciale stap die soms wordt vergeten in de levenscyclus van stroomverwerkingsapplicaties is de beheerfase. We bespreken een paar belangrijke zaken waarmee je rekening mee moet houden.

Testen & migratie

Voordat je een nieuwe versie implementeert, moet je je streamprocessor uitgebreid testen, niet alleen door de logica zelf te testen, maar ook door deze in een testomgeving te implementeren, zodat je streamprocessor kan worden getest met echte data. Aangezien streamprocessors live data verbruiken en lage criteria hebben voor downtime, kunnen testen je ook helpen om het deployment proces te optimaliseren en soepele migraties naar nieuwere versies met andere bedrijfslogica of andere inputvereisten te garanderen.

Monitoring

Afhankelijk van je keuze voor een stream processing framework en deployment model, heb je verschillende opties voor het bewaken van je applicaties. Zorg ervoor dat je een infrastructuur opzet voor het verzamelen, waarbij eventuele fouten onmiddellijk kunnen worden gedetecteerd. Alle stream processing frameworks bieden je de mogelijkheid om gebruik te maken van de uitzonderingsstroom, maar standaard negeren ze dit, waardoor de leveringsgaranties in gevaar komen. Houd hier rekening mee in je ontwerp. Het inrichten van deze stroom helpt tevens met het bewaken van de metrics stroom om uw applicatie op de juiste manier te schalen en ervoor te zorgen dat doorlooptijden kunnen worden gehandhaafd. Externe tools (bijv. Grafana) kunnen je helpen statistieken en uitzonderingen om te zetten in gebruiksvriendelijke dashboards met alarmering om je te helpen bij het monitoren van je streamprocessors.

Management

Management is belangrijk om te kunnen handelen wanneer dat nodig is en om de beveiliging en toegang in al uw applicaties af te dwingen. Vooral naarmate het aantal streamprocessors toeneemt is het essentieel om te beheren welke streamprocessors toegang hebben tot welke data en wie verantwoordelijk is voor het beheer van deze data en processorlogica. Dit omvat niet alleen toegangsrechten en beveiliging, maar ook verantwoordelijkheid en rollen voor schaalvergroting en monitoring.

Het monitoring- en management gedeelte van stream processors ontbreekt momenteel in de meeste grote streamprocessors. Daarom is het cruciaal om dit te integreren in je eigen stream processing oplossing of in andere monitoringtools binnen je applicatielandschap. Een platform als eMagiz kan je helpen bij het out-of-the-box ontwikkelen, bewaken en beheren van je stream-oplossingen, met een breed scala aan opties voor het implementeren, beveiligen, reguleren en bewaken van uw omgeving. eMagiz helpt je te focussen op jouw business en ontzorgt je wat betreft de fijne kneepjes van event processing. Benieuwd naar de mogelijkheden voor je organisatie? Geef ons een belletje, we helpen je graag!

Door Mark de la Court, Software Developer @ eMagiz