Názory k článku Kafka Connect: tvorba producentů a konzumentů bez zdrojového kódu

Článek, jako vždy, perfektní. Děkuji pane Tišnovský.

Zajímalo by mě k čemu se Apache Kafka v praxi používá? Nenapadá mě k čemu bych ho využil.

My ji používáme namísto message brokerů typu AMQ/Artemis nebo RabbitMQ, protože více abstrahuje producenty od konzumentů (přidání dalšího typu konzumenta je naprosto triviální a nemusí se řešit na straně producenta a/nebo message brokera).

+ možnost replayingu je taky dobrá, když se někde něco po...kazí :-)

* není dobré Kafku používat jako storage pro všechno, surová data si můžete meziuložit do Minia, dokumentové databáze atd. On ten defaultní limit 1MB na zprávu sice jde změnit, ale má význam.

U nás kafku používáme na real time analytiku. Proháníme tím ~200 000 zpráv za sekundu

Kolik na to máte replik?

To je zajímavá otázka. My od doby, kdy jsme Kafku skutečně začali používat (což je na současném projektu 3 roky) vidíme její "use cases" skoro všude, takže zkusím alespoň stručně vypsat:

1. jako sofistikovanější náhradu za klasické message brokery, protože Kafka spojuje strategii PUSH-PULL s PUB-SUB a to nám vyhovuje

2. dále jak psal předřečník, to umožňuje zcela oddělit producenty a konzumenty. Tj. producent něco posílá do zvolených témat a nestará se, kolik a jakých tam má konzumentů. Přidání dalšího konzumentata se vůbec nepozná a nemusí se nikde konfigurovat (vytvoří si automaticky svůj consumer group)

3. notifikační služba, co dále rozesílá informace mailem, po Slacku, přes web hooky atd., akceptuje notifikace posílané do Kafky. Takže univerzální a relativně snadno otestovatelné řešení.

4. taky tady existuje/existovala snaha tak řešit logy. Podle mě to není ideální řešení, ale uvidíme, jak se to vyvine (chybí mi tady určitá lepší úroveň abstrakce).

5. jedna mikroslužba používá Kappa architekturu, tj. Kafka je "source of truth", ostatní storage (RDS, tedy vlastně Postgres, je tady ve funkci sofistikovanější cache). Migrace atd. tedy mohou proběhnout prostým "replayem" zpráv z Kafky

6. celé ingress (tedy nepřesně řečeno proxy pro data, co k nám chodí od zákazníků) je na tom postaveno taky. Služba, která nějaká tato data potřebuje konzumovat, si prostě udělá další consumer groupu a je hotovo.

používám často pro asynchronní integraci systémů, databází. Dá se velice dobře škálovat, data drží jak divá a snadno se pro to navrhuje HW, zdroje.

Stejně tak se mi osvědčila jako ingress, a to i pro logy. Důležité je, že nelze čekat moc realtime a ani konzistenci.

U Kafky je asi největší nevýhoda, že velká část logiky je na straně klienta, jakýkoliv upgrade nebo změna je dlouhý rolling release. Stejně tak jeden špatně napsaný klient umí shodit celý cluster kafek, nelze to nikdy přímo pouštět ven.

Presne tak...vsetko ma aj svoje nevyhody...my sme naopak uprednostnili RabbitMQ pre Kafkou, ma pre komunikaciu medzi sluzbami pre nas lepsie vlastnosti.

Ono....aj ten replay v Kafke (a v rabbitmq cez streams) ma aj svoje uskalia....ako uz kolega napis, konzument musi podporovat dalsie verzie kontraktu / dat.... proste cena za replay je zvyseny maintenance z pohladu udrziavania spracovania verzii sprav (zmena na urovni kontraktu). Vsetko sa da nejako riesit...ale v praxi to znamena, napr. viacero queues per verzia udalosti (kontraktov) alebo v horsom pripade ta ista queue ale backward compatibilita (to nie je vzdy mozne)...

A teraz si to predstavte, ze vasa sluzba musi historicky s tym pocitat a ak sa za tych par rokov zmeni kontrakt bez backward kompatibility - nova sluzba s tym musi pocitat a teda musi akceptovat null hodnoty "priliz novych vlastnosti" na kontrakte....aby skratka spracovanie sprav zpred 3 rokov nepadalo ;-)

BTW...rad by som vedel, ako v praxi riesite tranzakcnost z pohladu producenta (v queue take "neviditelne" markeri) a nasledne problem z pohladu DEVOPS ?

https://www.google.com/search?q=kafka+transactions+offset+not+increment+by+one

9. 2. 2023, 20:02 editováno autorem komentáře

ono stačí u kafky nepoužívat slovo kontrakt a nedělat z ní něco zářivějšího než je, kafka není moc dobrý message broker jak ho chápeme jinde.

Na offset se nemůžeš spolehnout, stejně je inkrementální jen v rámci každé partition zvlášť a neplatí, že doménová data jsou vždy v jedné partition, to je naopak bottleneck pro kafku.

Většinou každá zpráva má svůj obal s metadaty, kde máme primární klíč, podle něho deduplikujeme v cílí. Pokud chce nějaká aplikace udělat replay, musí umět zahodit duplicitiní data a umět příjmout změť všeho a pouze si z toho vybrat ty chybějící či navázat na předchozí stav. Pro lepší retenci a práci používáme i atribut effective date, který určuje čas zapsání do kafky (generujeme to před tím, než producent vezme data), váže se k tomu retence a shard/partition v cílí, tím je možné snadno identifikovat, co se bude muset přegenerovat.

Ke kafce je vždy nutné mít externě postavený systém na ověření integrity a konzistence dat, kafka nic z toho nezaručuje. Opět používáme atribut effective date, ke kterému děláme buď statistiky nebo full scan pro porovnání.

To je asi nejčastější schéma, které navrhuji, ale samozřejmě se to drobně může lišit projekt od projektu. Vždy je půl týmu překvapených jak je kafka vlastně hloupá a co se musí udělat navíc. Nelze věřit producentovi, že data doručí do kafky, nelze věřit že konzument správně data zpracuje a posune offset.

Při replay čteme offset vždy od začátku a zahazujeme nehodící se. Několikrát jsem na projektech dělal pokusy s indexováním offsetu pro každou partition a message a poté dohledával message, ale vedlo to jen k náhodnému přístupu do kafky, což zabilo performance, přečtení všeho se ukázalo rychlejší. Replay se nedělá denně, ale párkrát do měsíce zejména při DR testech.

> "Vždy je půl týmu překvapených jak je kafka vlastně hloupá a co se musí udělat navíc"

tesat do kamene. Je nutné znát vlastnosti a úskalí dané technologie a prostě brát Kafku jako rychlý append-only log, který nezaručuje sám o sobě pořadí zpráv (a hlavně Kafku nebrat jako čistou frontu).

> "nelze věřit že konzument správně data zpracuje a posune offset"

popravdě to je problém i u všech klasických message brokerů, proto se rozlišuje minimálně jedno doručení od doručení max. jednomu konzumentovi (ale vy to znáte, to píšu jen pro úplnost).

co rikate na DDS, ktery nepotrebuje centralniho brokera, ale uzly pub/sub se samy pripoji multicastem.

ale to je trochu jiný use case, ne? DDS slouží pro realtime komunikaci služeb mezi sebou, kafka je spíše velký zásobník zpráv, které je možné doručovat N uzlům rovnou, zpožděně nebo i zpětně.

Článek pěkný, ale pokud by někdo vážně uvažoval o použití Kafka Connect, tak doporučuji podívat se raději po něčem pořádném (Vector.dev) z hlediska výkonu, univerzálnosti, absence technology lock-inu, škálovatelnosti, atd. a neztrácet s Kafka Connect vůbec čas (vlastní zkušenost).

9. 2. 2023, 21:46 editováno autorem komentáře

Částečně souhlasím :-) [i když mnohdy je vývojář omezen tím, co je nasazeno]

Tím vendor lock-inem myslíte vlastní Kafka Connect nebo spíš nějaké konkrétní konektory?

Myslím spíš lock-in na Kafku jako takovou, případně na konektory, které Connect podporuje. Já se snažím designovat architekturu tak, abych kdykoliv mohl kterýkoliv blok nahradit něčím jiným, navíc komponenta typu Vector je velice flexibilní i co se týká nějakých přechodných řešení z jedné technologie na jinou, atd. A samotný Vector v architektuře, o které píši, nahradil Fluentd, který zastával stejnou funkci :-)

Jinak ten Vector.dev vypadá zajímavě! Od DataDogu používám(e) nějaké knihovny a nástroje a mají to kvalitní, takže prozkoumájm a díky za upozornění.

vector.dev je zlatý grál poslední doby, pěkně napsaný projekt a už na tom také letím jak diví.