Kafka a motorháztető alatt: architektúra, API-k és teljesítmény

HUP

Sokan azt gondolják, hogy a Kafka "csak" egy message queue, de ez olyan, mintha azt mondanánk, a Porsche csak egy autó.

A Kafka igazi ereje a motorháztető alatti architektúrájában rejlik, amellyel képes milliónyi üzenetet feldolgozni, szigorúan tartva a sorrendet. Mi ebben a kihívás? Megérteni, hogyan működnek a Kafka építőelemei: a partíciók, producerek, consumerek, topicok, replikáció és consumer groupok. Táskai Dominik a HWSW free! meetup-sorozat Kafka tematikájú állomásán elhangzott és alább megtekinthető előadása során elmélyedünk a Kafka központi elemeiben, elméleti és gyakorlati példákon keresztül egyaránt, és azt is megnézzük, miként működhet ez az egész Kubernetes alapokon. A végén azt is megtudod, hogyan kezdhetsz bele magabiztosan a használatába, elkerülve a leggyakoribb buktatókat.

Érdekel a téma mélyebben? Gyere el a HWSW 2025. szeptember 15-én kezdődő, 6 alkalmas, 18 órás Kafka alapozó online képzésére. A tanfolyam órái utólag felvételről bármikor visszanézhetők.

( willy v | 2025. 09. 10., sze – 16:55 )

a Porsche csak egy autó.

És igen, a Porsche egy autómárka. Tűpontos. 

( gabrielakos v | 2025. 09. 11., cs – 12:02 )

A Kafkának szerintem sokkal jobb a PR-ja mint amit megérdemel.

Például az olyan kijelentések mint "szigorúan tartja a sorrendet" ... erősen kiegészítésre szorulnak.
Tudom-tudom, részletkérdés, de valójában nagyon nem, és nagyon bele lehet szaladni. 

Azt gondolom 1-2 év testközeli Kafka tapasztalat kijózanító tud lenni, már ami az elvárásokat illeti.

Az a csapat aki mondjuk 2 év éles üzem után is még lelkesedéssel tud beszélni a Kafkáról az nagyon alaposan utánanézett előre a dolgoknak, nagyon jól letesztelt mindent - és esetleg egyszer-kétszer menet közben szerencsés döntéseket is hozott.

Olyan ez, mint a mindenféle sok buzzword. Kell NoSQL, kell blockchain, kell microservice, kell AI, kell Kafka, kell Kubernetes, kell terheléselosztó, kell minden. Miközben egy 15 user által használt belső toolról van szó, ami egy Excel-táblát vált ki. De tudod, ha nincs benne blockchain, NoSQL meg a többi szar, akkor a középvezetés nem tud a fejlesztésre büdzsét allokálni, mert ezekkel a buzzwordökkel lehet eladni a vezetőségnek, hogy kiváltunk egy Excel-táblát egy webes felülettel.

Dehogy, most az AI a divat, egy fejlesztést akkor tudnak eladni a (szükség esetén nemzetközi központi) vezetésnek, ha olyan eszköz készül, amiben van munkamegkönnyítő AI. Ha nincs benne AI, akkor nem lesz rá büdzsé. Mert a tanácsadók megmondták, hogy aki nem használ AI-t mindenre is, az lemarad.

Hozzátenném, hogy kurva drága, ha nem magadnak futtatod. Ha meg magadnak futtatod, akkor szopsz vele igen sokat, hogy stabil legyen egy kellően nagy Kafka cluster... :D

Meg azt is hozzátenném, hogy túl van használva, sokszor olyanra is előkerült a Kafka, amire egy kutyaközönséges MQ vagy egy REST hívás is tökéletes lenne, csak azt nem ismerik, illetve nem divatos, sokkal jobb a CV-ben a Kafka (CVDD - CV driven development), mint egy MQ. Mondok példát, egyik projekten az ütemezés úgy van megoldva, hogy egy külön ütemező microservice egy-egy Kafka topic-ba bedob egy üzenetet, amit kivesz a microservice és abból tudja, hogy most futnia kell.

https://iotguru.cloud

Használják még: 

- circuit breaker
- outbox 

pattern "kiváltására".

Miközben az a mondás hogy "garantáltan sorrendben érkeznek meg az üzenetek" egyáltalán nem is mindig igaz.

A vége mindig az, hogy a "smart endpoints, dumb pipes" alapigazság jegyében az idempotencyről meg a sorrendezésről úgyis alkalmazás szinten neked kell gondoskodni. 

Ha dumb pipe-nak van használva amibe bele lehet önteni gyorsan sokat meg ki lehet belőle önteni gyorsan sokat, arra oké.

Ja, a schema registry nevű csodáról még nem is esett szó. :)

Sok esetben nem a performance a legnagyobb probléma, emiatt aztán nem is az a lényeg, hogy hogyan teljesít egy ilyen cucc a benchmarkokon. Sokkal fontosabb az üzemeltetési, mennyi kavarás van vele, mennyire sok dologra kell odafigyelni, hogy jól működjön, mennyire van hozzá dokumentáció, mennyire jó a support stb.

Le van szarva a benchmark, ha nem tud stabilan futni. A legtöbb helyen (az esetek 99.99 százalékában) nem kell olyan csúcsteljesítmény, mert nincsen ilyen terhelés (nagyon kevés Google-scale cég van), cserébe sokkal fontosabb a megbízható működés.

+1

Egyszer voltam egy interjún, valami olyasmi volt a kérdés, hogy onprem Oracle DB-t kimigrálni valahova felhőbe. Mivel architect pozira volt az intejú, nem Oracle szakértőire, így nyilván az Oracle-t annyira nem ismerem, de hát van ott is Oracle ZDM, meg fasztudja, de ha az nem jó, hát gondolom ott is lehet replikációt csinálni, onnan meg ugye ismerjük, hogyan tovább.

Kiderült, hogy a "jó" válasz a Kafka volt. Most vagy én értettem félre a kérdést, és kimaradt valami kulcsfontossűgú rész (mondjuk az Oracle DB-t CosmosDB SQL API-ra kell migrálni, vagy mittudomén), vagy valami nagyon félrement, de ha itt van az interjúztatóm, mondja már el, hogy mit néztem be! :D

Jah, a patternt értem, csak a Kafkát nem értem benne. Erre vannak natív megoldások, legalábbis SQL Server területen, Oracle-höz meg ugye segg vagyok. :) Azt gondolnám, hogy ahhoz is van valami, amihez nem kell külön egy kafkát setupolni.

Vagy a B opció, hogy már van Kafka, és akkor használjuk azt, de azt meg ugye utcáról beesett interjúzóként nem tudok :)

Oracle valószínüleg Kafka sink volt és egy másik (bárhol) futó rendszenek annyi dolga van ilyenkor hogy feliratkozzon a Kafka topicra aztán az is majd egyszer friss lesz.
Ez ilyen majdnem realtime reporting rendszer akar lenni ahol csak x óra/nap/hét adattal kell foglalkozni? Érdekes megoldás na.
A nehézség általában a konzisztencia megállapításában van ilyen migrációk során.

Ez ilyen majdnem realtime reporting rendszer akar lenni ahol csak x óra/nap/hét adattal kell foglalkozni?

Nem egészen. Hasamra ütök, és szándékosan más domaint mondok, de mondjuk képzeld el, hogy a Tesco egy Oracle-ben tárolja a teljes online rendelősdihez kapcsolódó adatait 10 évre visszamenőleg, és ezt ezt ki kéne rakni a felhőbe. Nem állhat meg sokáig, és a meglévő 425986239756329 rendelést is kezelni kell, az összes járulékos adatával együtt.

Nekem két dolog nem világos:

  1. ha ráborítok mondjuk egy 50 TB-s adatbázist Kafkára, mi fog történni (illetve: mennyibe fog kerülni)
  2. miért kell ehhez Kafka (vagy bármi), nincs az Oracle-nek valamilyen migrációs toolja?

1. önmagában az 50TB nem sokat mond, alapvetően a kafkának nem a sok adattal van problémája.
2. nem tudom hogy van-e de az onprem oracle-ről sokan felhős nem-oracle-be szeretnének migrálni, na oda kell valami "transport medium"

Ha mondjuk debezium-ban gondolkozunk akkor a "dumb pipe" a kafka, amire elvileg jó

  1. Nem konkrétan arra gondoltam, hogy sok-e – szó szerint értettem, hogy nem tudom, mi történik. Elkezdi átlapátolni a meglévő adatokat? Milyen logika szerint? Van egy kismillió táblás RDBMS, ott nem teljesen triviális soronként átmásolni a normalizált adatokat.
  2. Kevés konkrétumra emlékszem, de arra igen, hogy itt két Oracle-t kellett volna összehozni. Ezt a példát pont írtam is fentebb a SQL API-s CosmosDB-vel (nem a kisujjamból szopta ki sajnos :)), ami ugye nagyon messziről SQL csak.

Ezeket veheted költői kérdésnek is, nem veled akarom megcsináltatni a házi feladatot :)

Plusz nekem a fő kérdés még mindig az, hogy ha nincs Kafka a cégben, akkor jó ötlet-e, hogy egy egyszeri migrációs projekt miatt legyen. 

Én nem vagyok Kafka szakértő, de elvileg ez egy perzisztens queue néhány extrával. Tehát amit az egyik oldalon betöltesz, azt nagyjából sorrendben (ez elvileg partíciónként igaz), a másik oldalán ki tudod venni. De nem csak egyszer, hanem minden kliens saját maga menedzseli, hogy mit olvasott már ki belőle.

Szerintem egyik SQL-ből a másikba áttöltés az SQL szerver CDC interfészén keresztül tud jól működni, ahol kb. tranzakciókat kap meg az ember sorban, ezeket be lehet adagolni egy Kafka queue-ba, és a másik oldalon kiszedni. Ez pl. Postgres esetében gyakorlatilag WAL tranzakciókat jelent. Oraclenél is ezt tippelném be, de ~25 éve használtam utoljára Oracle-t, akkor is csak SQL szinten.