Názory k článku Sledování činnosti systému Apache Kafka přes JMX i metriky Promethea (dokončení)

Trošku offtopic, ale moc by se mi líbilo porovnání Kafky a NATSu. Ano, každá ta technologie je určena pro mírně odlišné účely, ale ty účely se překrývají. A NATS má jedno velké plus - vůbec nemá centralizovanou komponentu tak, jako Kafka (zookeeper).

Má někdo reálné zkušenosti s NATSem? Na produkci?

Dva články o NATS už vyšly https://www.root.cz/clanky/nats-streaming-server/ https://www.root.cz/clanky/pouziti-message-brokeru-nats/, ale porovnání tam moc nebylo.

Zkusím něco napsat, protože jsme dělali obě technologie.

Souhlasím, že Kafka je super a neštěstí trochu je tam ten Zookeeper s nutností mít aktivní nadpoloviční počet uzlů zoo, aby to celé funfgovalo. Sice je deklarováno, že se pracuje na odstranění závislost na Zoo v Kafce, ale bude to ještě chvíli trvat. :-(
Experimentuji s použitím Apache Ignite v roli jako Kakfy, protože tam ten Zoo není (respektive se jeho zapojení doporučuje pro lokační služby až když mám 100+ serverů) a data z Kafky se stejně braly do Ignite, tak použít pár vyhrazených keší nebo queue v Ignite jako vstupní stream (protože i ten defaultní Kafka streamer v Ignite má svoje mouchy, pokud nemám komerční verzi od GridGainu nebo nepoužiju pro Kafka->Ignite transformaci něco jiného, ať už vlastní bastl nebo Apache Spark/Flink).

na zookeeper mám vyhrazené vlastní servery a používáme ho i na jiné služby než jen pro kafku. Za mě je výhoda, že se poměrně dobře provozuje, má poměrně robustní model hlasování, failoveru a jistotu zápisu.

U kafky Confluent pracuje na KRaft jako náhradě zookeeperu, zatím se mi to ale moc nelíbí, výhoda ZAB (použitém v zk) proti raftu je "async linearizability guarantee" (netroufnu si přeložit do češtiny), zatímco u raftu končí u block-wait události a u velkých clusterů (20 a více kafka nodů) to přináší výraznější komplikace při velkých úpravách topiců a rebalancingu, mimojiné. V early access verzi zatím nemají implementované ACL, není možné event-driven replikaci monitorovat jako u zk.

Zookeeper je v hledáčku spouště lidí kvůli složitosti na správu, přitom to považuji za škodu, že se tohle nevyladilo, aby to bylo jednodušší. Kafka se zookeeper z mojí zkušenosti je jedna z nejstabilnější technologií co používáme. KRaft ale třeba přinese zvýšení praktického limitu pro počet partitions, topiců a consumer group, což ale pro většinu nasazení není limitací.

Tak samotný Zoo mám rád a také provozuji na vyhrazených serverech (párově s redis-sentinel pro řízení radis HA setupu). Mám na zoo rád už jen to, že je k tomu knihovna pro C a není problém ho přímo používat z různých embedded krámů.
Limitující v té kombinaci s Kafkou je instalace, kde mám k dispozici jen 2 lokality. A u zoo mám problém, pokud přijdu o jednu celou lokalitu, tak zbylá lokalita nebude mít majoritu a zastaví se to (když nepočítám možnost read only přístupu k zookeeperu, který je možný po povolení i když není majorita). V Kafce, Couch, Cassandra je hlasování pak per stream/dokument, takže ztráta jedné lokality v dvoulokalitní konfiguraci nevadí při vhodném nastavení, ale pro Zoo je to konečná. Pak musím řešti tak, že v každé lokalitě mám samostantou instalaci Kafka+zoo, aplikace buď zapisují naráz do dvou Kafek nebo se přepíná dle dostupnosti a ztráta jedné celé lokality se pak dá přežít, jen to komplikuje aplikace. Kde mám k dispozici víc lokalit, tak už problém není, zookeeper se mezi ně rozloží a ztráta celé jedné lokality nemá dopad.

Zk ve více lokalitách je problém, jednak kvůli latency, tak i kvůli výpadku celé lokality, na tohle není navržený a je nerozumné se ho snažit ho to naučit. Takže asi jediné rozumné řešení je mít vždy v jedné lokalitě Zk + Kafku. U Kafky je pak možné mít clustery křížem.

Z principu mi ale nikdy nevadilo omezení Kafky na jednu lokalitu, nikdy jsem neměl ambice dělat Kafku jako centralizovaný (či globální) řešení pro distribuci stavů, ale vždy to je komponenta, která je na hranici lokality a zajišťuje řádné doručení zpráv do již replikovaných systémů pro svoje ovečky.

Pořád tady platí, že uložit něco globálně je drahé a plné rizik pro selhání, ale velice trvalé pro budoucí výpadkx, uložit něco lokálně je levné, s málo riziky, ale nedává mi to záruky při výpadku. Kafka a zk je právě ta vhodná komponenta pro to rychlé uložení lokální než se podaří stav na pozadí dostatečně zreplikovat, aby klient nemusel čekat s daty v paměti a otevrřenými spojeními příliš dlouho. Tuhle roli právě v kombinaci se zk plní velice dobře a spolehlivě, ale je to občas trochu na hlavu to správně navrhnout.