Apache Kafka'nın KIP-1279'su kümeler arası mirroring'i doğrudan broker içine gömüyor

Apache Kafka, KIP-1279 kapsamında yerleşik kümeler arası mirroring kazanıyor; bu değişiklik, kümeler arası replikasyonu harici araçlardan alıp doğrudan broker'ın içine taşıyor. Hacker News'in ön sayfasına çıkan bir Red Hat Developer makalesine göre, hedef kümendeki bir broker, kaynak kümeden kaydedilmiş (committed) kayıtları follower'ların zaten dahili olarak kullandığı fetch protokolüyle çekiyor ve bunları yerel partition log'larına ham, değiştirilmemiş batch'ler olarak ekliyor — böylece offset'ler, sıkıştırma ve consumer group durumu korunuyor.

Harici araçtan broker'a gömülü replikasyona

Kafka, tek bir küme içindeki veri hareketini her zaman iyi yönetti: leader'lar follower'lara replike eder, consumer'lar da minimum yük ile herhangi bir replikadan veri çeker. Kümeler arası veri kopyalama — coğrafi dağıtım, uyumluluk sınırları, ekip izolasyonu veya sürüm ayrımı için gerekli — ise daha zordu. Kafka 2.4'ten beri standart araç, bir dizi Kafka Connect worker'ı olarak çalışan ve kaynak kümeden tüketip hedef kümeye üreten MirrorMaker 2 oldu.

Cluster mirroring bu katmanı ortadan kaldırıyor. Mirror fetcher thread'leri broker süreci içinde çalışıyor; yani provision edilecek, izlenecek veya ölçeklenecek Connect worker'ı yok. Tek bir CLI komutu olan kafka-cluster-mirrors.sh --create bir mirror kuruyor; --start topic'lerin replikasyonunu başlatıyor. Yaşam döngüsünün tamamı, topic'ler ve consumer group'lar için kullanılan aynı Admin API ile yönetiliyor.

Bayt bayt kopyalar ve birebir aynı offset'ler

Tasarımı iki özellik tanımlıyor. Sıkıştırılmış batch'ler ham baytlar olarak replike ediliyor; böylece gzip, snappy, lz4 veya zstd ile sıkıştırılmış bir batch hedefe özgün biçiminde ulaşıyor — sıkıştırma açıp yeniden sıkıştırma turu yok ve üreticinin sıkıştırma tercihi korunuyor. Offset'ler kümeler arasında birebir aynı; log compaction'ın bıraktığı boşluklar dahil. Böylece consumer group'lar offset çevirisi olmadan failover yapabiliyor: kaynak kümedeki committed offset, hedef kümedeki committed offset ile aynı.

Bir mirror'ın durdurulması deterministik bir dizi işlemi tetikliyor: fetcher'lar kaldırılıyor, son mirror epoch kalıcı hale getiriliyor, leader epoch artırılıyor, bekleyen transaction'lar iptal ediliyor ve bir control record tüm üretici durumunu geçersiz kılıyor. Partition ardından hedef kümede yazılabilir hale geliyor; harici bir koordinasyon veya offset sorgusu gerekmiyor.

Özellik, kaynak kümedeki temiz olmayan (unclean) leader seçimleriyle de başa çıkabiliyor. Hedef küme bir kurtarma durumuna giriyor ve devam etmeden önce tüm atanmış replikaların — yalnızca in-sync olanların değil — kesilmiş (truncated) offset'te birleşmesini bekliyor; böylece kaynak, eksik bir log'la leader seçse bile iki log tutarlı kalıyor. Makaledeki karşılaştırma tablosu, kaynak uyumluluğunun Kafka 2.1'e kadar geri gittiğini, MirrorMaker 2 içinse 2.0+ olduğunu listeliyor.

Broker içindeki üç bileşen

MirrorMetadataManager orkestratör. Her broker üzerinde çalışarak KRaft metadata log'unu izliyor ve controller bir MirrorTopicStateChangeRecord yazdığında durum geçişlerini — create, start, stop, pause, resume, recover, delete — yönetiyor. Ayrıca kaynak kümeyle bir Admin client bağlantısı tutuyor ve varsayılan olarak her 60 saniyede bir kaynak metadata'sını yeniliyor: yapılandırılmış include/exclude pattern'lerine uyan topic'leri keşfediyor, topic yapılandırmalarını eşitliyor, consumer group offset'lerini çekiyor ve kaynak küme ID'sinin değişmediğini doğruluyor. Bu son kontrol, biri bir mirror'ı farklı bir kümeye yönlendirirse sessiz veri bozulmasını önlüyor.

ClusterMirrorCoordinator kalıcılığı yönetiyor ve group ile transaction coordinator'larıyla aynı coordinator pattern'ini izliyor. Her mirror partition'ının durumu, __mirror_state adlı dahili compacted topic'te bir key-value record; 50 partition ve replikasyon faktörü 3 varsayılanlarıyla, leader epoch ve state epoch fencing yoluyla iyimser eşzamanlılık kontrolüyle korunuyor.

MirrorFetcherThread asıl replikasyonu gerçekleştiriyor. Kafka'nın AbstractFetcherThread sınıfını genişletiyor — küme içi replikasyonun da arkasındaki aynı temel sınıf bu — ve mirror başına kimlik doğrulama bilgileriyle ayrı bir NetworkClient tutarak SASL/SSL bağlamlarını mirror'lar arasında izole ediyor. Thread'ler fetcher ID, kaynak broker endpoint'i ve mirror adıyla anahtarlanıyor; bu da ince taneli yük dengelemeyi ve kaynak leader değişimlerine hızlı tepkiyi mümkün kılıyor.

Broker ayrıca metadata keşfi, yapılandırma eşitleme, consumer group offset eşitleme ve ACL yayılımını da üstleniyor. Bant genişliği her iki uçta da kontrol edilebilir: hedef taraf yapılandırılabilir bir replikasyon hız limiti uygularken, kaynak taraftaki mirror fetch trafiği sıradan consumer istekleri gibi göründüğünden mevcut client kota mekanizmaları değişmeden geçerli oluyor.

Tanımlı bir partition yaşam döngüsü

Mirror partition'ları bir state machine boyunca ilerler ve herhangi bir durum hatada FAILED'a geçebilir. LOG_ALIGNMENT önce yerel log'u kaynakla hizalar: yepyeni bir mirror sıfıra truncate olur ve her şeyi kopyalar; devam eden bir mirror ise yalnızca deltayı mirror'lar ve sapmaları çözmek için saklanan son-mirror offset ve epoch değerlerini kullanır. EPOCH_FENCING ardından yerel leader epoch'u 10 artırır; yeniden artırma eşiği 3'tür — bu olmadan, hedef consumer'lar kaynağın committed epoch'u ile başlatılabilir ve bu epoch yerel değerden büyük olduğu için leader'ı reddedebilir.

Red Hat makalesi iki pratik senaryoyu — felaket kurtarma ve küme göçünü — adım adım anlatıyor ve bir video demo ile kapanıyor.

Neden önemli

Kafka, gerçek zamanlı veri altyapısının büyük bir bölümünün temelini oluşturuyor ve can sıran kısımlar nadiren küme içi replikasyondur — asıl zorluklar felaket kurtarma, göç ve çok kümeli topolojilerdir. KIP-1279 bu iş akışlarını broker'a katıyor; Connect kümelerini, offset çevirisi topic'lerini ve kümeler arası kurulumları kırılgan hale getiren koordinasyonu ortadan kaldırıyor. Birebir aynı offset'ler ve dokunulmamış batch'ler, consumer'ların ve aşağı akış araçlarının bir failover sonrasında aynı şekilde davranması anlamına geliyor — tam da bu kurulumların daha önce sahip olmadığı garanti. Bu aynı zamanda Kafka'nın bir zamanlar çevresinde bir ekosistem gerektiren yetenekleri içine absorbsiyon etmesi yönündeki daha geniş bir pattern'i de sürdürüyor. Buradaki ayrıntılar tek bir satıcı makalesinden geliyor; dolayısıyla öneri olgunlaştıkça spesifik ayrıntılar değişebilir.