Kafka ile Backpressure Yönetimi: Tıkanan Boruları Açmak

Kafka, modern veri mimarilerinin kalbinde yer alan, yüksek performanslı bir dağıtık log sistemidir. Ancak "yüksek performans" vaadi, doğru yönetilmediğinde bir kâbusa dönüşebilir. Özellikle producer'ların consumer'lardan daha hızlı veri ürettiği senaryolarda, sistemin tıkanması veya çökmesi kaçınılmazdır. Bu duruma "Backpressure" (Geri Basınç) diyoruz ve yönetimi, sağlıklı bir streaming mimarisi için kritiktir.

Backpressure Nedir ve Neden Oluşur?

Basitçe anlatmak gerekirse; bir musluktan akan suyu (producer), bir huniden (consumer) geçirmeye çalıştığınızı düşünün. Eğer su, huninin tahliye kapasitesinden daha hızlı akarsa, huni taşar. Yazılım dünyasında bu "taşma", bellek hataları (OOM), artan gecikmeler (latency) veya consumer grubunun rebalance döngüsüne girmesiyle sonuçlanır.

Kafka dünyasında backpressure genellikle şu sebeplerle oluşur:

1. Ani Yük Artışları (Spikes): Black Friday gibi özel günlerde veya ani trafik artışlarında.
2. Yavaş Tüketim (Slow Consumers): Consumer tarafındaki işlemlerin (DB yazma, harici API çağrıları) yavaşlaması.
3. Kaynak Yetersizliği: Consumer pod'larının CPU/Memory limitlerine takılması.

Strateji 1: Consumer Tarafında Hız Kontrolü (Throttling)

En temel yöntem, consumer'ın kendi hızını limitlemesidir. Kafka consumer'ı poll() metoduyla veri çeker. Eğer işleme süreniz uzuyorsa, max.poll.records ayarını düşürerek her seferinde daha az mesaj çekebilirsiniz.

Properties props = new Properties();
// Her poll işleminde en fazla 50 kayıt çek
props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, "50");
// Poll aralığını belirle
props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, "300000");

Bu, consumer'ın "çiğneyebileceği kadar ısırmasını" sağlar.

Strateji 2: Pause/Resume Mekanizması

Bazen sadece yavaşlamak yetmez, durmak gerekir. Kafka Consumer API, pause() ve resume() metodlarını sunar. Eğer consumer'ın içindeki buffer dolduysa veya bağımlı olunan bir servis (örneğin veritabanı) yanıt vermiyorsa, tüketimi geçici olarak durdurmak en sağlıklı yoldur.

// Buffer dolduysa tüketimi durdur
if (buffer.isFull()) {
    consumer.pause(consumer.assignment());
}

// Buffer boşaldığında devam et
if (!buffer.isFull()) {
    consumer.resume(consumer.assignment());
}

Bu yöntem, consumer'ın gruptan düşmeden (rebalance tetiklemeden) beklemesini sağlar.

Strateji 3: Topic Partitioning ve Ölçekleme

Eğer tek bir consumer yetmiyorsa, paralelliği artırmanız gerekir. Kafka'da paralellik birimi "Partition"dır. Topic'inizin partition sayısını artırarak ve aynı oranda consumer ekleyerek yükü dağıtabilirsiniz.

Ancak dikkat: Partition sayısını artırmak, anahtar (key) tabanlı sıralamayı etkileyebilir ve broker üzerindeki yükü artırır. Bu yüzden "daha fazla partition = daha iyi performans" denklemi her zaman doğru değildir.

Strateji 4: Reactive Streams ve Non-Blocking IO

Geleneksel bloklayan (blocking) işlemler yerine, Project Reactor veya Akka Streams gibi reaktif kütüphaneler kullanmak, backpressure yönetimini doğal bir şekilde ele almanızı sağlar. Bu kütüphaneler, subscriber'ın (consumer) publisher'a (producer) "bana şu kadar veri gönder" diyebildiği bir protokol uygular.

Spring Boot ile Reactor Kafka kullanarak:

ReceiverOptions<Integer, String> options = ReceiverOptions.<Integer, String>create(props)
    .subscription(Collections.singleton("my-topic"))
    .addAssignListener(partitions -> log.info("Assigned: {}", partitions))
    .addRevokeListener(partitions -> log.info("Revoked: {}", partitions));

KafkaReceiver.create(options)
    .receive()
    .delayElements(Duration.ofMillis(100)) // Yapay gecikme / backpressure simülasyonu
    .subscribe(record -> {
        // İşlemler
        record.receiverOffset().acknowledge();
    });

Sonuç: Dengeyi Bulmak

Backpressure yönetimi, sadece teknik bir ayar değil, mimari bir karardır. Sistemin en yavaş halkası kadar hızlı çalışabileceğini kabul etmek ve buna göre savunma mekanizmaları kurmak gerekir.

Unutmayın: Sistemin çökmesindense, yavaşlaması her zaman daha iyidir.