Kafka je izvrstan alat, vrlo otporan na greške, nedostupnost i incidente. Ali, ako se poklopi nekoliko standardnih postavki sa određenim događajima, mogli bi ostati bez podataka u Kafki. Iz tog razloga u nastavku ću vam pokušati približiti najčešće standardne postavke za koje bi trebali razmisliti da li ih je potrebno izmijeniti (osim u specifičnim situacijama).

Naravno, preporuke koje ću dati za podešavanje tih postavki uzmite razumno i prilagodite, ako je potrebno, za vaše okruženje. Niti je svako okruženje isto, niti se u svakom okruženju očekuju isti outputi a i hardverski resursi s kojima raspolažete mogu biti veći ili manji. Neko okruženje zahtijevati će veći resiliency dok će neka okruženja zahtijevati nižu latenciju. Na vama je da procijenite i odredite što je potrebno u vašem okruženju.

auto.create.topics.enable

Standardno je postavljena na “true” a preporučam postaviti na “false”.

Iako potencijalno zgodna opcija za razvojna i testna okruženja, nikako poželjna za produkcijska okruženja. Ova opcija kontrolira da li će Kafka samostalno kreirati novi topic u slučaju da producer ili consumer zatraže topic koji ne postoji. Nekoliko negativnih efekata će se manifestirati ako se ostavi na “true”:

• pojaviti će se cijela šuma topica za koje će gotovo nemoguće biti ući u trag da li su potrebni ili nisu,
• dodatno se komplicira ako je primjerice na testnom okruženju dozvoljeno kreiranje topica a na produkciji nije. Mali tipfeler će na testu kreirati novi topic, sve će izgledati kao da funkcionira a kod migracije na produkciju dočekati će greške da topic ne postoji,
• jedan dio parametara topica će se popuniti standardnim vrijednostima koje nisu optimalne (više o tim parametrima niže u tekstu)

offsets.retention.minutes

Ovaj parametar definira koliko dugo Kafka čuva offsete tj. discarda offsete za topice na kojima nema aktivnosti. Primjer, na nekom okruženju nema aktivnosti po topicu više od nekoliko dana. Kada se ponovo pojavi nova aktivnost, a offset je resetiran, consumeri će početi ponovno procesuirati podatke koji još uvijek postoje u topicu (ako je retencija podataka u topicu veća od ovog parametra). To se često može dogoditi na okruženjima kao što je razvojno okruženje. U novijim verzijama (2 na više) ta vrijednost je povećana na 7 dana a za starije verzije bila je 1 dan pa provjerite tu vrijednost.

partitions

Inicijalni broj particija kada se kreira topic je 1. Proširivanje particija nije kompleksna operacija ali nije ni da se atribut –partitions postavi na željenu vrijednost pa Kafka proširi broj particija. Za proširenje broja particija potrebno je kreirati json dokument sa brojem particija te definicijom replikacije na brokere. Ja ne vidim štetu ukoliko u startu je definirano više particija kako jedan producer i jedan consumer mogu raditi sa više particija ali više consumera na jednu particiju onemogućava paralelizam obrade podataka iz topica. Dakle, minimalno bih definirao 2 particije priliko kreiranja topica.

replication-factor

Još jedna standardna postavka koje je postavljena na 1. U stvarnosti to znači da se particije topica ne repliciraju na više brokera. Idealno je da se sve particije svih topica repliciraju na sve brokere pa prilikom kreiranja topica postavite ovu vrijednost na broj brokera. Osim u iznimnim situacijama kada primjerice nije optimalno replicirati sve particije na sve brokere (npr. izdvojeni data centri sa visokom latencijom, itd) te je tada potrebno naknadno proširiti particije sa json dokumentom.

min.insync.replicas

Standardno postavljeno na 1. Definira koliki je minimalan broj brokera koji će potvrditi da su zapisali poruku prije nego Kafka potvrdi zapisivanje poruke. Idealna brojka bi bila n-1 gdje je n broj brokera (npr. u klasteru od 3 brokera, idealna vrijednost bi bila 2). Međutim, to dovodi do određene latencije pa nije idealno za situacije gdje se traži niska latencija. Također, ukoliko je broj dostupnih brokera (npr. zbog redovnog održavanja ili incidenta) manji od ovog broja Kafka će odbiti zapisati poruku. Postavka je tanak balans između redundancije, fleksibilnosti i latencije.

segment.bytes

Maksimalna veličina log datoteke nakon koje će Kafka kreirati novu datoteku. Vrlo važna postavka obzirom na količinu podataka koji pristižu u topic te performansi doslovnog podsustava. U većini slučajeva 1GB bi trebala biti optimalna veličina kako neće kreirati vrlo velik broj malih datoteka na sustavu niti preveliku datoteku za održavanje retencije.

segment.ms

Definicija vremenskog roka nakon kojeg će Kafka kreirati novi log na diskovnom podsustavu. Standardno je 7 dana što bi moglo biti previše ako se podatci čuvaju kraće. Primjerice ako se podaci čuvaju ukupno 7 dana a ova postavka je definirana na 7 dana znači da će retencija obrisati podatke u logu koji je stariji od 14 dana a smanjiti ukupnu veličinu podataka na disku za 1/3. 1 dan je optimalna veličina ako se podaci čuvaju do 30 dana a 7 dana ako ne više od navedenog.

retention.ms

Parametar koji definira vrijeme čuvanja podataka. Standardna vrijednost je 7 dana. Nakon 7 dana od vremena kreiranja poruke (ako je message.timestamp.type=CreateTime) nakon čega Kafka počinje odbacivati stare poruke iz topica. Uvijek provjerite potrebne retencije podataka u topicima i prilagodite prema potrebi.

retention.bytes

Parametar kojim se ograničava maksimalna količina podataka koju će Kafka pohraniti na diskovni podsustav. Obratite pozornost da se ukupno zauzeće računa kao umnožak ove vrijednosti puta broj particija topica (npr. ako topic ima 6 particija a vrijednost ovog parametra je setupirana na 500MB, tada će ukupno zauzeće na diskovnom podsustavu biti 3GB). Ova vrijednost može biti kao dobar fail-safe mehanizam zaštite diskovnog prostora na poslužitelju u slučaju naglog rasta poruka u topicu (ukratko: izračunajte za svaki topic broj particija * retention.bytes te usporedite sa diskovnim prostorom). Standardna vrijednost je -1 što znaći neograničeno pa svakako promijenite ovu vrijednost.

log.retention.hours

Standardno je definirano da se logovi čuvaju 7 dana. Ovisno o potrebama čitanja podataka iz topica provjerite da li je ovo dovoljno. Naročito ukoliko postoji potreba za čitanjem podataka od “nule” tj. od inicijalnog offeta.

__consumer_offset topic

Prvi topic koji se kreira prilikom instalacije Kafka klastera je __consumer_offset. U navedeni topic se upisuju vrijednosti offseta po particiji za svaki consumer te je taj topic kao takav iznimno važan za ispravno funkcioniranje cijelog klastera. Kako je Kafka predviđena da radi već sa samo jednim brokerom, replikacijski faktor jer 1 i min.insync.replicas je također 1. Ukoliko se ne izmijene ove postavke, u slučaju da prvi broker nije dostupan niti jedan consumer neće moći upisati offset na kojem je stao što čini cijeli klaster beskorisnim. Obavezno korigirajte replikacijski faktor i min.insync.replicas prema svojem okruženju.

Svi parametri brokera dostupni su ovdje, a svi parametri topica dostupni su ovdje. Preporučam proučiti sve parametre i izmijeniti prema potrebama svojeg okruženja (naravno testirajte :))

Postoji li neki parametar brokera ili topica koji smatate da treba obavezno izmijeniti a da nije ovdje naveden?