EK-D Kafka Broker Failure Senaryoları — Soru & Cevap

Bu döküman, Kafka’da broker çökmesi durumlarını ve sistemin nasıl davrandığını soru-cevap formatında açıklamaktadır.

Senaryo Tanımı

• 3 Broker
• 4 Partition
• 1 Consumer Group (4 instance)
• Replication Factor: 3

Soru 1: Bir Broker Down Olursa Ne Olur?

Başlangıç Durumu

Cevap

Replication Factor = 1 ise (Kötü Durum):

Her partition’ın tek kopyası var. Broker 3 çökerse P2 ve P3 kaybolur. Veri kaybı yaşanır.

Replication Factor = 3 ise (Doğru Kurulum):

Broker 3 çöktüğünde:

1. Leader Seçimi: P2'nin leader’ı öldü, Kafka otomatik olarak Broker 1 veya 2'yi yeni leader seçer.
2. Consumer’lar Etkilenmez: Kafka client otomatik yeni leader’a yönlendirilir.
3. Under-Replicated Partitions: Her partition’ın artık 2 kopyası var, Kafka uyarı verir.
4. Broker Geri Gelince: Eksik verileri leader’lardan çeker, tekrar senkronize olur.

Soru 2: Çöken Broker Üzerindeki Partition’da Offset Sırası Ne Oldu?

Cevap

Broker 3 Çökmeden Önceki Durum:

Broker 3 Çöktükten Sonra:

Veri kaybolmadı! Follower’larda aynı mesajlar mevcut. Consumer kaldığı yerden devam eder.

Tehlikeli Durum: Follower’lar Geride Kaldıysa

Tehlike: “Zombi” Lider ve Veri Kaybı Riski

Görseldeki senaryoda temel sorun, sistemin yüksek trafik (High TPS) veya ağ gecikmesi nedeniyle senkronizasyon yeteneğini yitirmesidir.

• Tehlikenin Nedeni: Follower’lar (Broker 1 ve 2), Leader’ın (Broker 3) hızına yetişemediği için In-Sync Replicas (ISR) listesinden düşmüşlerdir. Bu durumda sistem “Under-Replicated” durumuna geçer.
• Kritik An: Eğer bu noktada acks=1 (sadece liderin onayı yeterli) gibi gevşek bir konfigürasyon kullanılıyorsa, Producer 8 ve 9 numaralı mesajlar için "başarılı" onayı alır. Ancak bu veriler sadece Broker 3'ün RAM/Diskinde yaşar.
• Felaket Senaryosu: Broker 3 çöktüğünde, geride kalan (8 ve 9'u hiç görmemiş) Broker 1 veya 2 mecburen lider seçilir. Sonuç: Sessiz Veri Kaybı. Sistem çalışmaya devam eder ama o iki mesaj evrende hiç var olmamış gibi yok olur.

2. Çözüm: Disiplinli Mutabakat (acks=all & min.insync.replicas)

Bu veri kaybını önlemek için sistemi “Hata yapacağına dur” prensibine göre konfigüre etmemiz gerekir.

acks=all (Producer Katmanı)

Bu ayar, Producer’ın mesajı gönderdikten sonra “Tamam, verin güvende” diyebilmesi için sadece Leader’ın değil, o anki tüm ISR listesindeki broker’ların mesajı aldığını teyit etmesini bekler. Bu, en yüksek güvenlik seviyesidir.

min.insync.replicas=2 (Broker Katmanı)

Sadece acks=all kullanmak yetmez; çünkü ISR listesinde sadece 1 broker (Leader) kalsa bile acks=all başarı döner. min.insync.replicas=2 ayarı burada devreye girerek bir "güvenlik barajı" oluşturur:

• Sistemde en az 2 kopyanın (Leader + 1 Follower) senkron olduğunu doğrulamadan yazma işlemini kabul etmez.
• Eğer yukarıdaki örnekteki gibi ISR sadece [Broker 3] ise, sistem yeni mesaj kabul etmeyi durdurur ve hata döner.

Özet Tablo

Soru 3: Key Verilmiş Mesajların Durumu Ne Oldu? Sürekli Düşen Broker Üzerindeki Partition’a Giden Mesajlar?

Cevap

Bu durum, dağıtık sistemlerde mantıksal adresleme ile fiziksel yerleşimin birbirinden nasıl ayrıştırıldığını (decoupling) anlamak açısından kritiktir. İşte bu sürecin teknik dökümü:

1. Katmanlı Eşleşme (Two-Layer Mapping)

Sistemde iki bağımsız eşleşme mekanizması çalışır:

• Key → Partition (Deterministik / Sabit): Mesajın key değeri (örneğin "user-101"), bir Hash fonksiyonuna sokulur. Çıkan sonuç partition sayısına bölünür (modulo). Bu tamamen matematikseldir; broker'ların ayakta olup olmamasından bağımsızdır.
• Partition → Broker (Dinamik / Değişebilir): Hangi partition’ın hangi broker üzerinde “Leader” olacağı bilgisidir. Bu, cluster yönetimi tarafından belirlenir ve çökme (failover) durumunda güncellenir.

2. Failover Senaryosu (Broker 3 Çöktüğünde)

Örneğin üzerinden adım adım gidelim:

1. Öncesi: user-101 anahtarı hash edildiğinde Partition 2 sonucunu veriyor. Partition 2'nin lideri ise Broker 3.
2. Çökme Anı: Broker 3 fiziksel olarak düşüyor.
3. Yeni Lider Ataması: Kafka’nın kontrol mekanizması (Controller), Partition 2 için yeni bir lider seçer (Örneğin: Broker 1).
4. Sonrası: user-101 mesajı gelmeye devam eder. Hash fonksiyonu hala Partition 2 cevabını üretir. Sadece Partition 2'nin yeni evi artık Broker 1'dir.

Özet: Key routing kuralı (mantıksal yol) asla değişmez. Sadece o yolun sonundaki fiziksel durak (broker) değişir.

3. Producer’ın Adaptasyonu (Metadata Mekanizması)

Producer, mesajı yanlış yere göndermemek için şu süreci izler:

• Metadata Cache: Producer ayağa kalktığında cluster’dan bir “Metadata” tablosu çeker (Hangi partition hangi broker’da bilgisini içerir).
• Hata Yakalama: Broker 3 çöktüğünde, Producer ona yazmaya çalışır ve hata alır (Connection Timeout veya Not Leader for Partition).
• Refresh: Bu hatayı alan Producer, hemen cluster’dan güncel metadata’yı talep eder.
• Yönlendirme: Yeni tabloda Partition 2'nin liderinin artık Broker 1 olduğunu görür ve mesajları oraya göndermeye başlar.

Bu süreç sayesinde veri bütünlüğü (ordering) bozulmadan akış devam eder.

Soru 4: Aynı Anda Hem Broker Hem Consumer Çökerse Ne Olur?

Senaryo

Aynı anda:

• Broker 3 çöktü
• Consumer 4 çöktü

Cevap

Bu çift taraflı çökme senaryosu, dağıtık sistemlerde “Exactly-Once” işlemenin neden bu kadar zor olduğunu ve “At-Least-Once” garantisinin nasıl çalıştığını teknik olarak çok net özetliyor.

Süreci adım adım detaylandıralım:

1. Adım: Kümelenme Seviyesinde Kurtarma (Broker Failover)

Broker 3’ün çökmesiyle birlikte sistem, verinin sürekliliğini sağlamak için hemen bir lider seçimi (Leader Election) başlatır:

• Lider Değişimi: Partition 2'nin (P2) lideri artık yok. Kafka, ISR (In-Sync Replicas) listesine bakarak P2 için yeni bir lider atar (Örn: Broker 1).
• Hizmet Sürekliliği: Bu işlem milisaniyeler içinde gerçekleştiği için Producer’lar kısa bir duraksamanın ardından yeni lidere yazmaya devam eder.

2. Adım: Tüketici Seviyesinde Kurtarma (Consumer Rebalance)

Aynı anda Consumer 4'ün de çökmesiyle, Kafka Group Coordinator devreye girer ve grubu yeniden dengeler:

• Rebalance Tetiklenmesi: Tüketici grubundaki bir üyenin (Consumer 4) kalp atışı (heartbeat) kesildiği için Kafka bu partition’ı (P3) boşta bırakmaz.
• Yükün Paylaşılması: Mevcut tüketiciler (C1, C2, C3) arasında görev dağılımı yapılır. Örnekteki Consumer 3, kendi işine ek olarak P3'ün de sorumluluğunu üstlenir.

3. Adım: Veri İşleme ve Offset Çelişkisi (En Kritik Nokta)

Bu senaryonun en can alıcı kısmı, Consumer 4'ün “okuduğu ama henüz onaylamadığı (commit)” mesajlardır:

• Commit Mekanizması: Consumer 4, 66 ve 67 numaralı mesajları okudu ve işledi; ancak henüz “Ben bunları bitirdim” bilgisini (commit) Kafka’ya iletmeden çöktü.
• Baştan Başlama: Consumer 3, P3'ü devraldığında Kafka’daki __consumer_offsets tablosuna bakar. Oradaki son kayıt 65'tir.
• Duplicate Data (Mükerrer Veri): Consumer 3, mecburen 66 numaralı mesajdan itibaren okumaya başlar. Sonuç olarak 66 ve 67 numaralı mesajlar sistemde ikinci kez işlenmiş olur.

Mimari Sonuçlar ve Çözümler

Bu durum, dağıtık sistemlerin doğasındaki “At-Least-Once Delivery” (En az bir kere teslimat) garantisinin bir sonucudur. Bu riski yönetmek için şu iki yoldan biri seçilmelidir:

1. Idempotency : Consumer tarafındaki işlem “idempotent” tasarlanmalıdır. Yani 66 numaralı mesaj 10 kere de gelse, veritabanında sadece bir kere işlem yapmalı veya bir “transaction ID” kontrolü ile mükerrer işlem engellenmelidir.
2. Transactions: Kafka’nın enable.idempotence=true ve transactional mesaj özelliklerini kullanarak, mesaj okuma ve DB yazma işlemleri atomik bir bütün haline getirilmelidir.

Tüm Case’lerin Özeti

Duplicate İşleme Riski ve Çözümü

Consumer’lar idempotent olmalı:

// Kötü
processPayment(order);  // Tekrar çalışırsa iki kez ödeme alır!

// İyi (idempotent)
if (!isAlreadyProcessed(order.id)) {
    processPayment(order);
    markAsProcessed(order.id);
}

Soru 5: Key Verilmiş Mesajlarda Sıra Bozuldu mu?

Cevap

Bu kritik bir nokta, çünkü birçok kişi fiziksel yer değişikliğinin (failover) mesaj sırasını bozacağını düşünür. Ancak bu senaryodaki gibi Kafka’da mesaj sırası bozulmaz.

Bu durumu teknik olarak şu şekilde netleştirebiliriz:

Mesaj Sırasının Bozulmama Nedeni: Partition Bütünlüğü

Kafka’da sıralama garantisi (ordering guarantee) Broker seviyesinde değil, Partition seviyesinde verilir.

• Mantıksal Sabitlik: user-101 anahtarı için Hash fonksiyonu her zaman P2 (Partition 2) sonucunu üretir. Bu, verinin hangi fiziksel sunucuda olduğundan bağımsız bir kuraldır.
• Log Yapısı: P2 aslında bir “Append-only Log” dosyasıdır. Liderlik Broker 3'ten Broker 1'e geçtiğinde, bu log dosyası kaldığı yerden (offset) devam eder. Broker 1 zaten bir “Follower” olarak bu log dosyasının kopyasına sahipti.
• Kesintisiz Akış: Mesajlar her zaman P2 içindeki yerini korur. Producer yeni lider olan Broker 1'e bağlanıp yazmaya devam ettiğinde, yeni mesajlar eski mesajların tam arkasına (bir sonraki offset'e) eklenir.

Sıralamanın Korunması İçin Gereken Mimari Şartlar

Sıralamanın gerçekten bozulmaması için şu iki teknik ayarın doğruluğu kritiktir:

1. In-Sync Replicas (ISR): Broker 1'in lider seçilebilmesi için ISR listesinde olması gerekir. Yani Broker 3 ölmeden önce tüm mesajları Broker 1'e kopyalamış olmalıdır. Eğer kopyalayamadan ölürse ve biz unclean.leader.election.enable=true yapmışsak, o zaman veri kaybı ve sıra kayması riski doğar.
2. Max In Flight Requests: Producer tarafında max.in.flight.requests.per.connection değeri 1'den büyükse ve enable.idempotence=false ise, ağdaki paket gecikmeleri nedeniyle sıralama riske girebilir. Ancak modern Kafka sürümlerinde Idempotence açık olduğu için bu risk minimize edilmiştir.

Özetle: Bu senaryonda, partition bazlı hashing sayesinde user-101 mesajları her zaman aynı "mantıksal kuyruğa" girer. Liderin değişmesi sadece o kuyruğun hangi diskte tutulduğunu değiştirir; kuyruğun içindeki sıralamayı değiştirmez.

Neden Sıra Bozulmaz?

Soru 6: “Partition Sayısı Değişmediği Sürece Key ile Verilen Mesajların Sırası Asla Değişmez” Önermesi Doğru mu?

Cevap

Genellikle doğru ama %100 değil. Birkaç edge case var.

Önermeyi Tehdit Eden Teknik Riskler ve Çözümleri

1. Producer Kaynaklı Sıralama Kayması (Retry Mekanizması)

En sinsi risklerden biridir. Eğer enable.idempotence kapalıysa, ağdaki bir paket gecikmesi veya geçici bir hata, mesajların disk üzerine yazılma sırasını geri dönülemez şekilde değiştirebilir.

• Senaryo: Mesaj A hata alıp yeniden deneme (retry) kuyruğuna girdiğinde, hemen arkasından gelen Mesaj B başarıyla yazılabilir. Mesaj A tekrar denendiğinde ise Mesaj B’den sonraki bir offset’e yerleşir.
• Çözüm: enable.idempotence=true ayarı, her mesaj paketine bir "Sequence Number" ekler. Broker, gelen mesajın numarasını kontrol eder; eğer beklediği sıradan sapma varsa (A gelmeden B gelmişse), B'yi kabul etmez ve sıralamayı korur.

2. Custom Partitioner ve Mantık Değişikliği

Varsayılan algoritma (MurmurHash2) stabildir. Ancak iş mantığı gereği yazılan Custom Partitioner kodunda yapılacak bir güncelleme (örneğin hash algoritmasının değiştirilmesi), aynı Key değerine sahip mesajların farklı Partition’lara dağılmasına neden olur. Partition’lar arası global bir sıralama garantisi olmadığı için “Order” tamamen kaybolur.

3. Unclean Leader Election (Veri Tutarlılığı Riski)

unclean.leader.election.enable = true ayarı, sistemin kullanılabilirliğini (availability) verinin doğruluğunun (consistency) önüne koyar.

• Risk: Eğer güncel veriye sahip olmayan (ISR dışı) bir follower lider seçilirse, eski liderdeki (Broker 3) son mesajlar (Offset 8, 9) yok sayılır. Yeni lider kendi offset 8'ini yazar. Bu sadece sıralamayı bozmaz, verinin kendisini de bozar.
• Çözüm: Kritik sistemlerde bu ayar mutlaka false kalmalıdır.

4. Log Compaction (Görünürlük Kaybı)

cleanup.policy = compact ayarı aslında sıralamayı bozmaz; ancak bir Key için gönderilen mesajların geçmişini (history) siler. Sadece en son "Update" kalır. Eğer iş akışınız mesajların ara durumlarına (intermediate states) ihtiyaç duyuyorsa, bu durum bir veri kaybı gibi algılanabilir.

Production Ready: %100 Güvenli Konfigürasyon

Önermenin %100 doğru kabul edilebilmesi için sistemin şu “altın ayarlar” ile zırhlandırılması gerekir:

KatmanParametreÖnerilen DeğerAmacıProducerenable.idempotencetrueSıralı yazım ve mükerrer kayıt engelleme.ProduceracksallTüm güvenli kopyalara (ISR) yazım onayı.Producermax.in.flight.requests5 (Idempotence ile)Performans ve sıralama dengesi.Brokermin.insync.replicas2En az iki kopyada veri güvenliği barajı.Brokerunclean.leader.electionfalseSenkron olmayan follower'ın liderliğini engelleme.

Özet : Partition sayısı sabit kalsa bile, Sıralama (Ordering) sadece bir Hash sonucu değil; Producer, Broker ve Replication konfigürasyonlarının bir bütünüdür. Bu ayarlar sağlandığında, user-101 anahtarlı mesajların sırası, sistem ne kadar yüksek TPS (7,000+ RPM) altında olursa olsun bozulmaz.

Production Güvenli Ayarlar

Özet Tablo

Sonuç

Kafka, doğru konfigüre edildiğinde broker ve consumer çökmelerine karşı oldukça dayanıklıdır. Kritik noktalar:

1. Replication Factor = 3 kullan
2. acks=all ve min.insync.replicas=2 ayarla
3. enable.idempotence=true aç
4. Consumer’ları idempotent yaz
5. **Partition sayısını baştan iyi planla***

Partition sayısının baştan doğru planlanması, sistemin hem performansı hem de veri bütünlüğü açısından hayati önem taşır. Bir Software Architect olarak bu kararın neden “geri dönüşü zor” olduğunu şu teknik nedenlerle açıklayabiliriz:

* Partition sayısını baştan iyi planla

1. Key-to-Partition Mapping ve Sıralama Garantisi

Daha önce belirtildiği gibi, anahtarı (key) olan mesajların hangi partition’a gideceği hash(key) % partition_sayısı formülüyle belirlenir.

• Sorun: Eğer partition sayısını çalışma anında değiştirirseniz (örneğin 4'ten 5'e), aynı user-101 anahtarı için yapılan hesaplamanın sonucu değişecektir.
• Sonuç: Eski mesajlar Partition 2'de kalırken, yeni mesajlar Partition 0'a gidebilir. Bu durum, aynı anahtara sahip mesajlar arasındaki sıralama garantisini (ordering) tamamen bozar.

2. Ölçeklenebilirlik ve Tüketici Sınırı

Kafka’da paralellik birimi partition seviyesindedir.

• Consumer Sınırı: Bir tüketici grubunda (Consumer Group), partition sayısından daha fazla aktif tüketici olamaz. Örneğin 3 partition’ınız varsa, 4. bir consumer eklediğinizde o consumer boşta kalacaktır.
• Darboğaz: Eğer trafik beklediğinizden çok artarsa ve partition sayınız düşükse, tüketici sayısını artırarak (horizontal scaling) bu yükü karşılayamazsınız.

3. Kaynak Tüketimi ve Dosya Handle Sınırları

“O zaman en baştan binlerce partition açalım” demek de her zaman doğru çözüm değildir.

• Dosya Sayısı: Her partition, dosya sisteminde ayrı dizinler ve dosyalar (index, log vb.) anlamına gelir. Çok fazla partition, broker üzerindeki “open file handle” sınırlarını zorlayabilir.
• Replication Süresi: Broker çöktüğünde veya yeniden başladığında, binlerce partition’ın lider seçimi ve replikasyon senkronizasyonu (recovery time) sistemin ayağa kalkma süresini ciddi oranda uzatabilir.

4. Disk I/O ve İşletim Sistemi Performansı

• Ardışıl Yazma: Kafka disk üzerine ardışıl (sequential) yazma yaparak hız kazanır. Ancak aynı disk üzerinde binlerce farklı partition dosyasına aynı anda yazılmaya çalışılması, işletim sistemi seviyesinde disk kafasının çok fazla hareket etmesine (random I/O benzeri etki) ve throughput kapasitesinin düşmesine neden olabilir.

Karar Matrisi

Planlama yaparken şu formülü göz önüne alabilir:

Hedeflenen Partition Sayısı = Max(Hedeflenen Toplam Throughput / Tek Bir Consumer Kapasitesi)

Özetle: Partition sayısını artırmak teknik olarak mümkündür ancak yukarıda bahsettiğimiz “Key Routing” bozulması nedeniyle mevcut verilerin yeniden dağıtılmasını (resharding) gerektiren çok sancılı bir sürece dönüşür. Bu yüzden, projenin başında öngörülen 7,000 RPM ve 200,000 Concurrent User gibi hedefleri baz alarak, gelecekteki büyüme payını da kapsayan bir sayı seçmek en sağlıklı yaklaşımdır.

***İçindekiler… « Önceki [EK-C RabbitMQ Consumer Çalışma Prensibi: Push Modeli & QoS] » Sonraki ***[EK-E RabbitMQ Exchange: Kapsamlı Rehber ve Temel Kavramlar]