Apache Kafka je temelj modernih sistema za obradu podataka u realnom vremenu. Kao distribuirani sistem, Kafka mora da održava konzistentno i deljeno stanje na svim svojim čvorovima. Svaki broker u klasteru mora da se složi oko ključnih informacija, kao što su koji je broker lider za određenu particiju i kakva je trenutna konfiguracija. Ovaj zahtev za postizanjem dogovora, čak i u slučaju mrežnih grešaka ili otkaza brokera, naziva se konsenzus.
Godinama je Kafka ovaj kritični zadatak prepuštala zasebnom sistemu: Apache ZooKeeper-u. Međutim, ovaj pristup je uveo sopstvene složenosti i ograničenja. Sada, sa uvođenjem KRaft-a (Kafka Raft), Kafka se razvija u smeru samostalne arhitekture (bez ZooKeeper-a).
Ovde ćemo istražiti ovu temu, upoređujući zastarelu arhitekturu zasnovanu na ZooKeeper-u sa novim, moćnim KRaft sistemom.
Kafka sa ZooKeeper-om (Stari pristup)
Kafka klaster je distribuirani sistem i potreban mu je pouzdan način za upravljanje deljenim stanjem i osiguravanje da se svi čvorovi slažu oko njega. Sistemu je potreban konsenzus protokol kako bi se osiguralo da svi brokeri imaju konzistentan pogled na stanje, čak i u slučaju mrežnih particija ili otkaza brokera.
ZooKeeper je distribuirani servis za koordinaciju. On pruža key-value store i njegova svrha je rešavanje problema konsenzusa u distribuiranim sistemima. U ovom modelu, Kafka klaster se sastojao od dva odvojena distribuirana sistema kojima je trebalo upravljati.
Funkcionisanje ovog modela:
- Svi Kafka brokeri se registruju i održavaju “heartbeat” sa ZooKeeper kvorumom.
- ZooKeeper održava izbor za kontroler brokera, koji je odgovoran za upravljanje stanjem particija i replika.
- Sve promene stanja, kao što su kreiranje topic-a ili pridruživanje/napuštanje brokera, prvo se zapisuju u ZooKeeper.
- Kontroler broker prati promene u ZooKeeper-u i zatim šalje ažuriranja ostalim brokerima.
Mane ZooKeeper-a
Iako funkcionalna, ova arhitektura je imala značajne nedostatke:
- Operativna kompleksnost: Zahtevala je upravljanje i nadzor dva odvojena, složena distribuirana sistema. Bilo je neophodno imati stručnost i u Kafki i u ZooKeeper-u, sa odvojenim konfiguracijama, hardverom i načinima otkazivanja.
- ZooKeeper kao usko grlo: Sve promene metapodataka morale su proći kroz ZooKeeper, što je moglo postati usko grlo u performansama, posebno u veoma velikim klasterima sa hiljadama particija.
- Spor oporavak od otkaza (Failover): Proces oporavka kontrolera mogao je biti spor, ponekad više sekundi ili čak minuta, što je dovodilo do perioda nedostupnosti klastera. Ovo je bio kritičan problem za sisteme koji zahtevaju visoku dostupnost. Morali smo da instaliramo i upravljamo sa dva odvojena složena distribuirana sistema umesto samo jednim.
Kafka sa KRaft-om
KRaft je ugrađeni konsenzus protokol koji zamenjuje ZooKeeper. KRaft je implementacija Raft protokola koja se izvršava unutar samog Kafka klastera. Umesto da prebacuje odgovornost za konsenzus na spoljni sistem, Kafka sada upravlja sopstvenim stanjem.
Ovaj novi model uvodi koncept kontroler čvorova unutar Kafka klastera:
- Podskup brokera u Kafka klasteru je određen kao kontroler čvorovi (obično ih ima 3).
- Kontroler čvorovi formiraju sopstveni Raft kvorum za upravljanje konsenzusom i biraju lidera među sobom.
- Metapodaci klastera se više ne čuvaju u ZooKeeper-u. Čuvaju se u internom Kafka topic-u pod nazivom
__cluster_metadata. Ovaj topic služi kao event log za sve promene stanja. Aktivni kontroler upisuje u ovaj log, a svi ostali brokeri ga čitaju.
Koristeći interni topic, Kafka koristi svoj sopstveni, dokazano pouzdan protokol za replikaciju kako bi upravljala sopstvenim stanjem.
Poređenje: Performanse i jednostavnost
Prelazak na KRaft nije samo kozmetička promena. Donosi značajne prednosti u performansama, skalabilnosti i operativnoj jednostavnosti.
1. Pojednostavljena arhitektura
Najočiglednija prednost je uklanjanje velike zavisnosti. Više ne morate da instalirate, konfigurišete, obezbeđujete i nadzirete odvojeni ZooKeeper klaster. Ovo smanjuje potrebe za hardverom, složenost konfiguracije i potencijalne tačke otkazivanja.
2. Brži oporavak i Failover
Jedno od najznačajnijih poboljšanja je brzina oporavka od otkaza. Pošto se konsenzusom upravlja interno od strane posvećenog skupa kontroler čvorova koristeći visoko efikasan Raft protokol, promene lidera se dešavaju gotovo trenutno.
Ovaj grafikon jasno ilustruje dobitke u performansama:
- Vreme kontrolisanog gašenja: Sa KRaft-om, gašenje kontrolera je red veličine brže.
- Vreme oporavka nakon nekontrolisanog gašenja: Ovde KRaft zaista blista. Oporavak od iznenadnog kvara je dramatično brži nego sa ZooKeeper-om, smanjujući potencijalnu nedostupnost klastera sa minuta na svega nekoliko sekundi.
3. Poboljšana skalabilnost
Uklanjanjem ZooKeeper-a kao uskog grla, Kafka u KRaft režimu može podržati mnogo veći broj particija u jednom klasteru, skalirajući se na milione particija, u poređenju sa desetinama ili stotinama hiljada u sistemu zasnovanom na ZooKeeper-u.
Zaključak
Uvođenje KRaft-a označava novu eru za Apache Kafku. Preuzimanjem upravljanja konsenzusom, Kafka je postala jednostavniji, otporniji i performantniji sistem. Odbacivanje ZooKeeper-a pojednostavljuje operativni teret za inženjere i otvara put za klastere koji nisu samo veći, već i pouzdaniji.
Ako započinjete novu implementaciju Kafke, korišćenje KRaft-a je preporučeni put napred. To je fundamentalno poboljšanje koje učvršćuje poziciju Kafke kao vodeće platforme za strimovanje podataka u realnom vremenu.