Apache Kafka :: Remember, remember, the velvet November


node:	Apache Kafka
template:	4
parent:	open source a slobodny softver
owner:	DreeStyler
viewed by:
created:	14.11.2022 - 22:00:25
updated:	15.11.2022 - 13:57:11

cwbe coordinatez:
101
63540
63542
63747
9018633

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

Ak by ste sa niekedy stretli s touto technologiou(na SVK to uz dorazilo) a citili sa ako Zememerac K v Der Schloss, dajte vediet, mozem poradit.
Postavil som nakompletku backend messagingu z clusterov Apache Kafka, Kafka Connect, ZooKeeper, Logstash a Librdkafka. Stalo ma to 18mesiacov casu, nieco uz o tom viem. Vsetko bezi na TLS.
Hrdo s enforcing selinux(striktne dodrzane FHS) a lokalnym firewall a to sa uz dnes vidi malokde.
Redhat AMQ a Confluence Kafka to tiez pouzivaju.

000001010006354000063542000637470901863309018893

Jo, v RH na tom vali napriklad vulnerability management. A cez RH AMQ si napriec produktami triggerujeme jenkins pipeliny.

000001010006354000063542000637470901863309018872

v prvom rade gratulujem. znie to cele dost komplexne ;)
v druhom rade by ma celkom zaujimal konkretny use case

00000101000635400006354200063747090186330901887209052426

use case je nativne pre event based architekturu.
a druha vec je ze kafku nasadzujes do masivne distribuovaneho prostredia. my sme takto riesili problemy disaster recovery, kde nam aplikacia sedela v roznych datacentrach, v kazdom mala rozne vela instanci (autoscaler podla potreby), potrebujes byt fault tolerant, a to vsetko tak, aby si si nekafral do kapusty - aby ti instancie aplikacie navzajom nepocitali to iste a netrigerovali rovnake eventy.

a ako bonus brutalny throughput ked vies spracovat petabajt dat denne doslova "na kolene".

00000101000635400006354200063747090186330901887209019069

Vdaka, ved som za ten cas stihol aj 2x vyhoriet(riesil som este dalsie 2 subprojekty subezne a este robil Linux admina).

Kafka je na messaging. Taka vodárenská sieť na JSON/textove spravy.

Konkretny usecase su bankomatove karty a operacie pocas a po platbe kartou. U nas sa to pouziva minimalne na "bodiky zbierate" zakaznicke konta. Zakaznik prilozi kartu na terminal -> prebehne proces platby -> autorizacie od VISA/MC -> prachy sa zablokuju na karte -> obchodnik dostane prachy.
Kafkove moduly si potom nezavysle na tomto procese vytiahnu z DB konkretne info a nechavaju ich dostupne v Kafkovi pre ine aplikacie "na potom" bez narusenia platobneho procesu. Tato filozofia sa vola decoupling - rozviazanie uzkeho spojenia dvojic(DB -> Kafka a Kafka -> client) na to, aby sa vyhlo strate dat pri timoutoch, sietovych problemoch a setrili sa spojenia, kedze "bodiky zbierate" nieje az take dolezite mat hotove v realnom case na rozdiel od samotnej platby.

Dalsi klienti, napr. banka, si moze v uzkej dvojici Moja Kafka -> Ich Kafka vytiahnut rovnake data a robit si programy na spracovanie, napr. webgui, kde si moze zakaznik sledovat historiu platieb. Tym, ze je Kafka extremne rychla(kvoli priamemu pouziti volani kernelu pre sietovku a diskove operacie - sietovka priamo zapisuje na disk), tak si moze tie iste data vycitavat backend pre webgui obsluhujuci 10tis uzivatelov naraz.

Konkretnejsie:
Mas napr. Oracle DB a aplikaciu, ktora potrebuje data z DB. Kafka Connect ma modul OJDBC. Zapnes kafka connector, ktory si otvori trvale spojenie do DB a kazdych 5s posle dotaz. Ak su nove zaznamy, conector tie zaznamy nacita z DB a produkuje do Kafku. Ked uz to v Kafkovi je, tak hocjaky pocet konzumerov moze tieto spravy odobrat. Napr. Cckova kniznica Librdkafka je pouzita v C++ programe pre klientov banky, aby skonzumoval nove spravy z Kafku a klientovi vypisal ich obsah, alebo poslal SMSku. Kafka sa pritom stara o to, aby konzumujuci client dostal vzdy vsetky spravy a len raz(idempotencia), teda odlahcuje samotnu aplikaciu o kontroly celistvosti a kontrolnu logiku a tiez odlahci DB.

Kafka pri spravnom nastaveni garantuje, ze cokolvek tam pride, tak bude citatelne, ze rovnaky vstup da vzdy rovnaky vystup(idempotencia), ze poradie prichodzich a odchodzich sprav je nemenne, ze pri vypadku 1 z 3 datacentier budu vzdy data dostupne zo zvysnych 2(clustrove quorum, leaders atd), horizontalna skalovatelnost(mozes pocas behu pridavat n dalsich nod), rolling update. Navrhnute tak, ze ked sa to raz dobre nakonfiguruje a zapne, tak to ma bezat 10 rokov dokial sa to nevypne.

Filozofia je tu: https://uloz.to/file/g8NpMRZa5DV8/designing-event-driven-systems-for-streaming-services-with-apache-kafka-ben-stopford-2018-o-reilly-20220311-eb-pdf#!ZGpjZmR2Zwt5BQZmL2MzBQHmLJL3ZwuJEQIDFKcKBUbhHGMyAD==

Konkretna realizacia je tu(treba sa zaregistrovat na stiahnutie): https://www.confluent.io/resources/kafka-the-definitive-guide-v2/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.content-search_mt.xct_rgn.emea_lng.eng_dv.all_con.ktdg-v2&utm_term=kafka%20the%20definitive%20guide&creative=&device=c&placement=&gclid=EAIaIQobChMIxdzl88ey-wIVsI9oCR1jXQyYEAAYASAAEgIRMPD_BwE

0000010100063540000635420006374709018633090188720901906909052430

hehe, ta garancia poradia nie je taka easy. da sa to garantovat len na particiu, tj default ak mas topic s 1 particou, tak order vies garantovat. sranda nastane, ak mas tak 90 particii. tam uz ten order potrebujes prehnat cez dalsi level

000001010006354000063542000637470901863309018872090190690905243009052514

Ordering fakt nieje easy. Pochopil som to az tak v 50% projektu, ked si zacali DEVs stazovat, ze to je rozhadzane. Trebalo mat v poradi aspon male zhluky operacii(napr. ked zakaznik pri platbe urobil storno a potom znovu zaplatil to muselo byt v poradi).
Nakoniec som pouzil ordering podla kluca na vstupe do topic, tzn. spravy, ktore maju byt podla poradia, maju rovnaky kluc a ak maju rovnaky kluc, musia byt zapisane a citane z 1 particie. Stacilo pridat 1 riadok do config. DEVs a ja sme na to prisli v rovnaky cas.

0000010100063540000635420006374709018633090188720901906909019531

s tym vyhoretim sa Ti nedivim
aspon dufam ze si to nemusel riesit v time s bandou kretenov, nieco take by minimalne mna doviedlo priamo na "oddelenie"

a verim ze Ti za to aspon adekvatne zaplatili

000001010006354000063542000637470901863309018872090190690901953109019554

Spolupracovnici boli nastastie v pohode, moc tomu nerozumeli, co mohli, to spravili, vsetko fajn ludia. Potom mi dali pristup na skoro uplne vsetko, tak som si to robil sam. Akurat jeden sefik si neuvedomoval rozsah toho, co vsetko som robil, tak sa spraval obcas jak curak.

Prave tie prachy boli problem - ked som videl, aky zahul to je a kam ma to privedie, tak som sa chcel dohodnut na bonusoch za projekt a aby boli papiery, co mi odmietli, takze od aprila som pracoval 8-16hod/tyzden(takze 3-4 vyplaty mam za nic) a ked som sa dal ako tak dokopy a odpocinul si, tak som tento pondelok dal vypoved a este aspon tak 2-3 mesiace a budem ok.

00000101000635400006354200063747090186330901887209019069090195310901955409020090

Ma to po tebe kto spravovat?

0000010100063540000635420006374709018633090188720901906909019531090195540902009009020281

Ma. Kolega, ktory nastupil pred 8 mesiacmi a ktory to dodnes studuje to po mne preberie. Akurat ze ked som odmietol pracovat ako Linux admin(aby som mal cas na Kafku), tak prebral po mne adminovanie a nemal na Kafku velmi cas. Este do toho stihol spravit minimalne celoprojektovy Prometheus monitoring(nic zlozite, len kopiroval exportery a otvaral porty, ale ajtak velky kus prace) a nejake clustrovanie a docker veci.
Kafku urcite zvladne, lebo ja som to urobil tak, ze najblizsi rok na tom nebude treba robit vobec nic. Este keby som to stihol zansiblit, ako som planoval, tak by to bolo uz fakt easy.

0000010100063540000635420006374709018633090188720901906909019092

"aby konzumujuci client dostal vzdy vsetky spravy a len raz(idempotencia)" Toto nie je pravda. Idempotencia je nieco ine. Je to vlastnost, ze ak aplikujes nejake zmeny raz, alebo viac krat, tak vysledok je taky, ako keby si ich aplikoval iba raz. Kafka bola povodne nadesignovana tak, ze garantovala "at least once" delivery spravy, lebo ine sposoby dorucenia sprav je tazsie naprogramovat, ak skalujes cez mrde nod. Preto musia byt aplikacie pri takomto sposobe delivery idempotentne (hold na karte dva krat aplikovat nechces), ale spravy o tom istom holde im kafka moze viac krat dorucit. Ine sposoby delivery pridali az neskor a maju performance impact, lebo informaciu o delivery musis sirit cez viacero nodov.

000001010006354000063542000637470901863309018872090190690901909209019167

Noo, je to jedna z vlastnosti idempotencie, ze jednu spravu doruci iba raz. Vyrok dole uznas zapravdivy:
ze rovnaky vstup da vzdy rovnaky vystup(idempotencia)
https://cs.wikipedia.org/wiki/Idempotence

Viem, ze nizsie verzie Kafku idempotenciu nezarucovali. S vyssimi verziami to bola ziadana vlastnost a nevyhnutnost a podarilo sa im to zarucit vo verzii asi > 2.3 za cenu znizenia rychlosti. Teraz je to default, ktory sa da vypnut.

000001010006354000063542000637470901863309018870

vobec nemam tusenie co to robi, ale zarazilo ma ze tam je pouzita java
to preco preboha?

00000101000635400006354200063747090186330901887009019011

Message broker. High-performance messaging a queueing.
Posielanie správ medzi procesmi, ktoré bežia na rôznych počítačoch alebo virtuálnych strojoch.
Je okolo toho celá veda.

00000101000635400006354200063747090186330901887009018873

Asi kvoli lahsej integracii s inymi kniznicami, connectormi napr. OJDBC . Pouzili to, co uz je nakodene.

000001010006354000063542000637470901863309018757

ja sa pridavam do klubu s 30 mesiacmi a asi 5 roznych programovacich jazykov co som sa chytil napriec projektami.

momentalne som presedlal na rabbita

000001010006354000063542000637470901863309018710

Inak keby si to skusil s https://github.com/redpanda-data/redpanda, tak by ti to mohlo trvat o kusok kratsie (kedze ziadny ZooKeeper) a nepotreboval by si tolko nodov v clustri kvoli JVM ;)

00000101000635400006354200063747090186330901871009018786

Redpanda:
Basic 3 Nodes - 2 vCPUs, 16 GB - 3.5 TB total disk $1,500 $15,000

V mojom rieseni by to stalo 60000USD/rok . To uz by ma vyslo lacnejsie Redhat AMQ, co stoji 42tisUSD/rok .

000001010006354000063542000637470901863309018694

Používame to v práci na veľkom projekte, ale zatial sa tomu spokojne vyhýbam, lebo je mi jasné že to je skvelý nástroj ktorý je ale komplikovaný a istotne sa dá mesiac inštalovať a konfigurovať, a ďalší mesiac dolaďovať a inštalovať grafické nástroje na jednoduchšie managovanie.

Chvíľu sme na malom projekte chceli používať niečo podobné - RabbitMQ ale našťastie aj tomu sme sa vyhli. :-)

00000101000635400006354200063747090186330901869409018875

RabbitMQ je ok, nie je to taka tazkotonazna technologia ako Kafka.

0000010100063540000635420006374709018633090186940901887509018967

kafka je jednoznacne najprimitivnejsia z najprimitivnejsich. nieco ako redis, len zapojis a ides. naproti tomu rabbit musis pochopit schemy na exchange a queue aj pri 1 nodovej instalacii.

tazkotonazne to nastava az ked potrebujes ladit rozne variacie clusterov, optimalizovat rychlosti a stabilitu data flow. lenze to je potom uplne rovnake aj inde