Raft’ta Leader Election ve Log Replication: Kafka KRaft’in Kalbine Yolculuk

“Dağıtılmış sistemlerin fikir birliğine vardığını duyduğunuzda, perde arkasında küçük bir seçim olduğunu bileceksiniz.”

Bir önceki yazıda “Raft Algoritması ve Kafka’ya Kattığı Güç” başlığı altında, ZooKeeper döneminin karmaşık yapısını ve KRaft’ın Kafka’ya getirdiği sadeleştirilmiş, Raft tabanlı yeni mimariyi konuşmuştuk. O makale “neden KRaft var?” sorusuna yanıt veriyordu. Şimdi sıra “KRaft nasıl çalışıyor?” sorusunda. Bu yazı, o hikâyenin ikinci bölümü. Raft’ın iki kalp atışı olan Leader Election ve Log Replication mekanizmalarının Kafka dünyasındaki gerçek karşılığını anlatıyor.

Liderlik Yarışı: Kimin Sözü Geçecek?

Dağıtık sistemlerde herkes konuşursa kaos olur. Birinin “liderlik” etmesi gerekir. Raft’ın çözümü basit ama zekicedir: Her zaman tek bir leader vardır; diğerleri onu takip eder.

Bir follower belli bir süre boyunca liderden heartbeat alamazsa, “artık lider yok” der, candidate olur ve diğer node’lardan oy ister. Çoğunluğu kazanan node yeni lider olur, diğeri yeniden follower’a döner.

Kafka KRaft’ta da aynı prensip işler.

• Controller quorum içinde bir controller-leader seçilir.
• Bu node, cluster’daki tüm metadata kararlarını yönetir: topic oluşturma, partition liderliği atama, ACL güncelleme gibi tüm değişiklikler sadece onun üzerinden geçer.

Örnek: “Bir bankanın kart altyapısını düşünelim. Hangi işlem hangi partition’a yazılacak, hangi broker lider olacak gibi kritik kararları KRaft’taki controller-leader verir. Eğer bu lider düşerse quorum hemen devreye girer, birkaç saniye içinde yeni bir lider belirlenir ve hiçbir işlem yarıda kalmaz.Müşteri kredi kartını kullanmaya devam eder; sistemin içindeki seçim görünmez ama etkilidir.”

Logların Dansı: Herkes Aynı Melodiyi Söylemeli

Raft’ın asıl büyüsü, herkesin aynı “şarkıyı” aynı sırayla söylemesinde gizlidir. Bu şarkı aslında log’dur.

Bir client (Kafka’da bir broker) yeni bir kayıt gönderdiğinde:

• Leader bu isteği kendi log’una ekler.
• Diğer node’lara AppendEntries isteği yollar.
• Çoğunluk (quorum) “tamam” derse kayıt commit edilir.
• Herkesin log’u aynı sırayı paylaşır.

Kafka KRaft bunu “metadata log” üzerinden yapar. Controller-leader, her metadata değişikliğini bu log’a append eder. Follower controller’lar log’u replikasyonla alır. Yalnızca quorum commit ettikten sonra değişiklik geçerli sayılır ve broker’lar local state’lerini günceller.

Örnek: “Yeni bir müşteri hesap açtığında, bu aslında Kafka tarafında yeni bir metadata kaydıdır. Controller-leader bu kaydı log’a ekler, quorum onaylar ve birkaç milisaniye içinde tüm broker’lar bu müşteriyi tanır. Artık müşteri ister mobil uygulamadan ister şubeden giriş yapsın, sistemin her bileşeni aynı bilgiyi görür.”

AppendEntries mesajları 2 amaç için kullanılır;

a) Heartbeat (boş AppendEntries)

• Leader düzenli aralıklarla (örn: her 50–150ms) tüm follower’lara gönderir
• “Ben hala liderim, başka seçim yapma” mesajı
• Follower’lar bu mesajı alınca election timeout’larını sıfırlar

b) Log Replication (dolu AppendEntries)

• Client’tan yeni veri geldiğinde
• Leader bu veriyi kendi log’una ekler
• Sonra tüm follower’lara AppendEntries ile gönderir
• Follower’lar çoğunluk onayladığında entry “committed” olur.

AppendEntries Parametreleri:

AppendEntries: {
  term: 5,                   // Leader'ın term'i
  leaderId: "F3",            // Kimden geldiği
  prevLogIndex: 2,           // Önceki log entry'nin index'i
  prevLogTerm: 4,            // Önceki log entry'nin term'i
  entries: [{...}],          // Yeni log entry'ler (boş ise heartbeat)
  leaderCommit: 3            // Leader'in commit index'i
}

Follower Yanıtı:

AppendEntriesResponse: {
  term: 5,
  success: true             // Log tutarlı mı?
}

Arıza Çıktığında Ne Olur?

Dağıtık sistemlerde hata bir istisna değil, doğanın kuralıdır. Raft bunu olgunlukla karşılar. Lider düşerse seçimi yeniden yapar, ağ bölünürse çoğunluğu korur, geride kalan node’ları senkronize eder.

• Leader Crash: Heartbeat kaybolur, election başlar, yeni lider görevi devralır.KRaft’ta controller-leader düştüğünde quorum birkaç saniye içinde yeni bir lider seçer ve metadata log kaldığı yerden devam eder.
• Network Partition: Raft yalnızca çoğunluğu elinde tutan tarafın yazmaya devam etmesine izin verir. KRaft da aynı prensibi uygular split-brain riski engellenir.
• Lagging Follower: Geride kalan follower log’taki eksik entry’leri liderden alır. KRaft’ta bu durum otomatik metadata senkronizasyonuyla çözülür.

Örnek: “Bir bankanın İstanbul ve Ankara veri merkezleri arasında ağ kesintisi yaşandığında, çoğunluğu elinde tutan taraf işlemleri yürütmeye devam eder. Kart harcamaları, para transferleri, müşteri işlemleri kesintisiz sürer. Ağ yeniden kurulduğunda, diğer bölge eksik log’ları alarak senkronize olur.”

Güçlü Yanlar, Kaçınılmaz Bedeller

Avantajlar:

• Lider değişiminde deterministik ve hızlı toparlanma
• Quorum commit sayesinde strong consistency
• ZooKeeper bağımlılığı ortadan kalktığı için sade operasyon yönetimi

Bedeller:

• Quorum commit süresi latency’yi bir miktar artırabilir
• Metadata log zamanla büyür, snapshot/compaction yönetimi gerekir
• Election timeout ayarları doğru yapılmazsa yalancı seçimler olabilir

Raft’ın Nabzı, Kafka’nın Kalbinde

Raft’ın iki kalp atışı — Leader Election ve Log Replication — artık Kafka’nın içinde, KRaft adıyla atıyor. Kafka artık yalnızca bir mesajlaşma altyapısı değil; kendi consensus’unu yöneten olgun bir dağıtık sistem.

Bankacılık gibi yüksek güvenilirlik isteyen ortamlarda bile, KRaft mimarisi sayesinde sistemler node kaybetse bile ayakta kalıyor, hiçbir işlem kaybolmuyor, consistency bozulmuyor.

Kısacası;

KRaft, Kafka’nın kalbine Raft’ın ritmini yerleştirdi.

Serinin bir sonraki bölümünde işin operasyonel tarafına geçiyoruz:
“ZooKeeper’dan KRaft’a Geçiş: Migration Stratejileri ve Best Practices”
Bu bölümde, mevcut Kafka cluster’larını KRaft moduna geçirirken izlenecek adımları, olası riskleri ve en iyi uygulamaları anlatıp örneklerle göstermeye çalışacağım.