Brokerconfiguratie en tuning

Elke broker in een Kafka-cluster heeft een unieke identificatie nodig. Je stelt deze in met de parameter broker.id in server.properties.

De waarde moet een niet-negatief geheel getal zijn en in het hele cluster uniek zijn. Kafka gebruikt deze ID om brokers te identificeren voor replicatie, leiderverkiezingen en meer.

De parameter log.dirs bepaalt waar Kafka zijn logsegmenten opslaat (de daadwerkelijke gegevens voor topics en partities). Dit is een cruciale instelling voor prestaties en betrouwbaarheid.

• Meerdere schijven: Gebruik een door komma's gescheiden lijst met mappen op verschillende fysieke schijven voor betere I/O-paralleliteit.
• Afzonderlijke schijven: Gebruik bij voorkeur schijven die uitsluitend voor Kafka-logs zijn bestemd, gescheiden van het besturingssysteem en andere applicaties.

Kafka-brokers communiceren via netwerklisteners. De parameters listeners en advertised.listeners bepalen hoe clients en andere brokers verbinding maken.

• listeners: De interfaces waaraan de broker zich bindt (bijvoorbeeld PLAINTEXT://:9092).
• advertised.listeners: Het adres dat clients en brokers gebruiken om verbinding te maken (bijvoorbeeld PLAINTEXT://your.host.name:9092). Dit is cruciaal voor externe toegang of omgevingen met meerdere hosts.

Wanneer een topic wordt aangemaakt zonder expliciete instellingen voor partities of replicatie, gebruikt Kafka de standaardwaarden op broker-niveau. Deze configureer je via num.partitions en default.replication.factor.

• num.partitions: Stelt het standaard aantal partities voor nieuwe topics in. Meer partities betekenen meer parallellisme.
• default.replication.factor: Stelt het standaard aantal replica's voor nieuwe topics in. Meer replicatie betekent een betere fouttolerantie.

Over het algemeen wordt aangeraden deze waarden per topic expliciet in te stellen, maar deze standaardwaarden dienen als terugvaloptie.

Kafka bewaart berichten gedurende een instelbare periode of totdat ze een bepaalde omvang bereiken. Deze instellingen voorkomen dat je schijven vollopen en zijn cruciaal voor het beheren van opslag.

• log.retention.hours: Hoe lang berichten worden bewaard (bijvoorbeeld 168 uur = 7 dagen).
• log.retention.bytes: De maximale omvang van een logsegment voordat het in aanmerking komt voor verwijdering.

Kafka verwijdert berichten op basis van de limiet die het eerst wordt bereikt.

Om te voorkomen dat extreem grote berichten de prestaties van brokers beïnvloeden of netwerkproblemen veroorzaken, kun je in Kafka op broker-niveau een maximale berichtgrootte instellen via message.max.bytes.

Deze limiet geldt voor de totale omvang van een gecomprimeerde berichtenbatch. Als een producer een groter bericht probeert te versturen, wordt dit geweigerd. Producers hebben ook hun eigen max.request.size.

Naast server.properties moeten ook de onderliggende Java Virtual Machine (JVM) en het besturingssysteem (OS) worden afgestemd voor optimale Kafka-prestaties.

• JVM-heapgrootte: Configureer KAFKA_HEAP_OPTS om voldoende geheugen toe te wijzen (bijvoorbeeld 5-8 GB voor speciale brokers).
• Garbagecollection: Kies een efficiënt GC-algoritme (bijvoorbeeld G1GC) en stem de parameters ervan af.
• Bestandsdescriptors: Verhoog de OS-limieten voor geopende bestandsdescriptors, omdat Kafka er veel gebruikt voor logs en verbindingen.

We hebben de belangrijkste Kafka-brokerconfiguraties behandeld die invloed hebben op prestaties, stabiliteit en resourcegebruik.

• Het bestand server.properties vormt de basis voor het gedrag van een broker.
• Belangrijke parameters zoals broker.id, log.dirs, listeners, log.retention.hours en message.max.bytes zijn essentieel voor een goede configuratie.
• Houd ook rekening met afstemming op JVM- en OS-niveau voor een echt geoptimaliseerd cluster.

Door zorgvuldig af te stemmen zorg je ervoor dat je Kafka-cluster je gegevensstromen efficiënt en betrouwbaar kan verwerken.