Vlákno názorů k článku JetStream: nová technologie brokeru NATS konkurující Kafce od atarist - Jak je to s resiliencí NATSu v porovnání...

Jak je to s resiliencí NATSu v porovnání s Kafkou? Kafka je po těch letech už hodně odladěná věc, ale zrovna ten JetStream bych se možná ještě bál nasadit - ať si to na produkci odladí někdo jinej :-)

Ale nějaký benchmarky si možná u nás uděláme, protože Kafka trošku zlobí ve chvíli, kdy se povolí objemné zprávy. Sice se tváří, že mají no-copy strategii (tedy že bytový blok zprávy nikdy nekopírují), ale ten systém to už zatěžuje

NATS jako takový na produkci klidně dejte, to je ověřené řešení (jen není dobré ukládat fronty na NFS, mají tam nějakou botu, která se semtam projeví - ne často, ale určitě to nepojede 356 dní v roce bez chyby*).

JetStream je dost nová věc, s tím bych osobně počkal, až to odladí. Obecně je NATS jedno z nejlepších OS co se týče stability a tak, ale skutečně je zrovna toto nová technologie, takže jestli vás netrápí paměť, tak "postačí" Kafka (až na ten problém s dlouhými zprávami - to je takovej trik, aby Kafka vypadala rychlejší :D).

* ale prostě v tomto kontextu je NFS stejně ...ehm... blbost

NATS na produkci používáme, dokonce v kritické infrastruktuře a je to spolehlivé, resp. musíš se o to starat, ale bugy se neobjevují.

JetStream je novinka, to dej jen do labu, na produkci to bude potřebovat mnohem víc dozoru.

Kafka velké zprávy neumí, má to vše v heapě, je tam vysoká fragmentace v paměti i na disku, je to by design. Velká data přes kafku posíláme jako referenci na uložiště (s3, ceph). Brokera chci mít co nejefektivnější a ho zatěžovat velkou spoustu zbytečných dat.

Jak moc se o to musíte starat? nějaký 1-2 denne se kouknu na Grafanu nebo na alerty a jdu na kafe? Nebo je to co týden, to výpadek?

Jinak my tak Kafku taky používáme. V podstatě zprávy/eventy obsahují identifikaci objektu v S3, asi přesně jako vy. Má to nevýhodu - je tam další komponenta, která nemusí fungovat. Jako S3 je stabilní a všechno, to zase jo, ale udělat developerskej setup chvíli trvá (+ nějaký ty výpadky DNS, to je klasika, + peníze, ale to není z mého účtu :). Pokud by něco (třeba JetStream) byl prostě jedinej zdroj dat (i když bychom ho museli naškálovat), možná by to bylo zajímavější řešení.

23. 9. 2022, 09:03 editováno autorem komentáře

hodně záleží jaký máš provoz, ono to je podobný i s jinou databází. Dokud máš provoz konstatní, uživatelé s tím umí, server má dostatek místa a výkonu, nevíš o tom asi klidně roky.

Jakmile ale uživatelé začnou s tím různě experimentovat, bezhlavě to DoSovat, začne ti docházet disk, občas i paměť, řešíš více socketový server a pinning na jádra, řešíš FC disky a failover, musíš na to koukat aspoň denně, řešit podporu uživatelů, vysvětlovat, sledovat.

Rozhodně s tím je méně starostí než s Kafkou, která moc provoz neřeší a ráda padá, když se jí něco nelíbí.

Jsem v prostředí, kde je běžný, že nějaký block/file storage je k dispozici, v cloudu to je naprosto všude, problémy s DNS snad v mém světě neexistují. Na kafku máme upraveného klienta (producer i consumer), kdy při větším souboru ho sám nahraje na uložiště a umístí odkaz, při čtení se to transparentně zase čte. Nemám s tím problémy, všechny části máme ale pod správou.

Jediný zdroj dat, to může být i nevýhoda, slabé místo, budeš od toho čekat příliš moc funkcí a to může mít vliv na spolehlivost a stabilitu provozu.

Dik za info!

Ad to DNS - tyjo to je u nás několikrát do roka. Fakt netuším, co s tím dělají, ale vždy do dvou-tří měsíců se DNS rozsype. Dají to dohromady rychle, to zase jo, ale spousta služeb to nerozchodí a musí se restartnout. Takže výpadek jedné, dvou serveroven po světě, je třeba i pár hodin...