Üretimde Kafka: Bölümleme, Consumer Lag, Güvenilirlik ve Olay Müdahalesi

Bir demoda üretici mesaj yollar, tüketici ekrana basar ve herkes mutlu olur. Gerçek ortamda ise bir broker kapanır, bir tüketici yavaşlar, bir olay şeması değişir ve yine de siparişlerin doğru işlenmesi gerekir. Kafka'nın başarısı, yalnızca kümenin ayakta kalmasıyla değil, iş sonucunu açıklayıp gerektiğinde güvenle düzeltebilmenizle ölçülür.

Bu rehberde orders.placed.v1 konusuna yazan bir sipariş servisi, stok ayıran bir consumer grubu ve analitik için ayrı bir grup düşünelim. Sayılar örnek amaçlıdır; kendi trafik, yük ve kurtarma hedeflerinizi ölçmeden kapasite kararı vermeyin.

Önce iş yükünü tanımlayın

Saniyedeki ortalama ve tepe olay sayısını, kayıtların ortalama ve yüksek yüzdelik boyutunu, kaç gün veri tutulacağını, kaç bağımsız grubun okuyacağını ve kabul edilebilir işleme gecikmesini yazın. Bir tüketici veya broker kaybından sonra ne kadar sürede normale dönmek istediğinizi de belirtin. Her siparişe ait olayların sıralı olması çoğu zaman yeterlidir; bütün siparişler için tek bir küresel sıra genellikle gerekli değildir.

Örneğin saniyede 2.000 adet, ortalama 1 KB olay yaklaşık 2 MB/s ham veri üretir. Yedi günlük ham yük kabaca bir terabaytı aşar. Bu, disk boyutlandırma formülü değildir: sıkıştırma, indeksler, replikalar, protokol ek yükü ve trafik patlamaları sonucu değiştirir. Gerçek kayıtlarla yük testi yapın ve boş kapasite bırakın.

Yalnızca normal trafik hızını karşılayan tüketici, bir saatlik kesintide oluşan kuyruğu hiçbir zaman eritemez. Yakalama kapasitesi için tüketim hızının yeni gelen olaylardan yüksek olabildiğini doğrulayın.

Partition anahtarı sıralama sözünüzdür

Kafka, bir konunun her partition'ı içinde sırayı korur. Aynı siparişin olayları sırayla işlenecekse anahtar olarak orderId seçmek mantıklıdır. customerId kullanmak müşteri bazında farklı bir sıralama sözü verir. Sabit anahtar tüm yükü tek partition'a yığar; rastgele anahtar dağılımı iyileştirirken ilişkili olayların sırasını kaybettirir.

Bir konu için sekiz partition, aynı consumer grubunda en fazla sekiz etkin tüketiciye iş dağıtabilir. Yine de sekiz tüketicinin eşit çalışacağını garanti etmez. Çok yoğun bir anahtar tek partition'ı tıkarken diğerleri boş kalabilir. Partition bazında giriş hızı, işlem süresi ve gecikmeyi izleyin.

Partition sayısını sonradan artırmak, bir anahtarın sonraki olaylarını farklı partition'a yönlendirebilir. Uzun süreli kesin anahtar sırası gerekiyorsa yeni konu ve kontrollü geçiş gibi bir strateji tasarlayın. İhtiyaç duymadan yüzlerce partition açmak da broker kaynaklarını ve işletme karmaşıklığını artırır.

Replikasyon ve teslim garantisini birlikte değerlendirin

Replikasyon faktörü, bir partition'ın kaç kopyasının tutulacağını belirtir. Üretimde uygun hata alanlarına dağıtılmış üç kopya yaygın bir tercihtir; gerçek dayanıklılık lider ve eşzamanlı replikaların sağlığına, yerleşime, üreticinin acks ayarına ve min.insync.replicas değerine de bağlıdır. Bu ayarları tek tek değil birlikte sınayın.

İdempotent üretici, Kafka'ya yapılan yeniden denemelerde oluşabilecek kopyaları azaltır. Aynı iş isteğinin iki kere gelmesini veya PostgreSQL işlemi ile Kafka yayınını tek bir atomik işlem haline getirmez. Kafka işlemleri, Kafka'dan Kafka'ya işleme sırasında çıktı kayıtları ile tüketilen offset'leri koordine edebilir. Ödeme, e-posta ve harici veritabanı etkileri için ayrıca idempotency ve işlem tasarımı gerekir.

Staging ortamında bir broker'ı kapatıp beklenen üretici hatalarını, toparlanma süresini ve tüketici davranışını ölçün. Tek broker'lı yerel kurulum öğrenmek içindir; broker kaybına dayanıklılığı kanıtlamaz. Kafka 4.x KRaft kullanır; ZooKeeper modu Kafka 4.0 ile kaldırıldı. Küme rehberinizi gerçekten kullandığınız sürüme göre güncel tutun.

Consumer lag tek başına yeterli değildir

Consumer grubu, ilerlediği konumu offset commit ederek saklar. Lag, partition'ın son offset'i ile grubun konumu arasındaki farkı gösterir. Bin küçük kaydın gecikmesi saniyeler içinde kapanabilir; yavaş bir dış API çağrısı aynı sayıda kaydı saatlere yayabilir. Offset farkıyla birlikte en eski işlenmemiş olayın yaşını ve olaydan iş sonucuna geçen süreyi ölçün.

Gözlem	Olası neden	İlk kontrol
Bütün partition'larda lag artıyor	Giriş yükseldi veya işleme yavaşladı	Giriş ve çıkış hızlarını karşılaştırın
Tek partition geride	Sıcak anahtar veya sorunlu kayıt	Anahtarı, offset'i ve hatayı bulun
Sık rebalance	Pod yeniden başlıyor veya poll gecikiyor	Üyelik ve işlem sürelerini inceleyin
Outbox yaşı artıyor	Kafka öncesindeki yayın hattı durdu	Publisher hatalarını kontrol edin
Yetersiz replikalı partition	Broker, disk veya ağ sorunu	Broker sağlığını inceleyin
Hata kuyruğu büyüyor	Geçersiz şema veya sorunlu olay	İlk başarısız sürümü belirleyin

Alarm eşikleri iş beklentisine dayanmalı. Stok ayırma iki dakika içinde tamamlanmalıysa olaydan rezervasyona kadar geçen süreyi izleyin. Panolara grup ve partition etiketleri ekleyin; her orderId için ayrı metrik etiketi oluşturmayın.

Rebalance, geri basınç ve tekrar işleme

Grup üyeliği değişince partition'lar yeniden atanabilir. Eski tüketici, elindeki batch'i artık sahip olmadığı partition için işlemeye devam etmemelidir. Kullandığınız istemcinin rebalance kancalarını inceleyin; tamamlanan işleri kaydedin ve offset'i yalnızca başarılı işten sonra commit edin. Uzun bloklayan işlemler poll döngüsünü bozuyorsa kontrollü bir işçi havuzu ve doğru offset takibi kurun.

Daha fazla tüketici ancak atanabilecek partition varsa ve darboğaz gerçekten tüketici tarafındaysa yarar sağlar. Her olay aynı yavaş veritabanına yazıyorsa tüketici sayısını artırmak arızayı büyütebilir. Eşzamanlılığı sınırlayın, yeniden denemeleri geciktirin ve gerekiyorsa partition okumasını duraklatın.

Veritabanına yazdıktan sonra, offset commit etmeden önce çökme olursa olay tekrar gelir. eventId gibi sabit bir kimlikle benzersizlik kısıtı veya işleme kaydı kullanın. Offset'i yan etkiden önce commit etmek ise çökme halinde işi kaybettirebilir. Harici yan etkiler için evrensel bir “exactly once” düğmesi yoktur.

Saklama, yeniden oynatma ve şema değişiklikleri

Kafka'nın saklama süresi tüketicinin okuyup okumamasından bağımsızdır. Süreyi beklenen kesintiden ve vaat edilen yeniden oynatma penceresinden uzun tutun. Bir grup en eski saklanan offset'in gerisine düşerse kaybolan geçmişi Kafka'dan geri okuyamaz. Eşiğe yaklaşmadan alarm verin; daha uzun geçmiş gerekiyorsa ayrı bir arşiv düşünün.

Compaction, anahtar başına en güncel değeri tutan durum konuları için yararlı olabilir; tam bir olay denetim izi değildir. Bir projeksiyon tablosunu yeniden oluşturmak güvenli olabilir, fakat e-posta veya ödeme olaylarını tekrar oynatmak ikinci bir yan etki yaratır. Hangi offset'ten, hangi grupla ve hangi yan etkiler kapalıyken replay yapılacağını yazılı hale getirin.

Olay sözleşmesinde sahibi, anlamı, anahtarı, eventId, olay zamanı, sürümü, zorunlu alanları ve uyumluluk kuralı bulunsun. “Yeni alan ekledim” demek eski, katı decoder'ların çalışacağını garanti etmez. Şema değişikliklerini geride kalmış tüketicilere karşı test edin. Bütün ORM nesnesini veya gizli bilgileri olay olarak yayımlamayın.

Güvenlik ve olay müdahalesi

İstemci trafiğini şifreleyin, kimlik doğrulaması kullanın ve konu ile grup izinlerini asgari yetkiyle verin. Kimlik bilgilerini Git yerine sır saklama sisteminde tutup düzenli yenileyin. Kişisel veriyi en aza indirin; olay gövdelerini ayrıntılı loglara yazmayın. Konu oluşturma, silme ve saklama ayarını değiştirme yetkilerini sahipleriyle birlikte tanımlayın.

Bir sürümden önce şema uyumluluğunu, yük testini, üretici hatalarını, outbox yaşını, lag'i, rebalance oranını ve iş tamamlama gecikmesini kontrol edin. Yeni consumer grubunun earliest mi latest mi başlayacağını açıkça seçin. Geri alma sırasında olay anlamını sessizce değiştirmeyin.

Lag aniden artarsa şu sırayı izleyin:

1. Etkilenen grup, konu ve partition'ları belirleyin. Giriş mi arttı, işleme mi yavaşladı?
2. Son deploy, şema değişikliği, broker bakımı, bağımlılık kesintisi ve yetki değişikliğini kontrol edin.
3. Hassas veri açığa çıkarmadan hatalı offset ve hata sınıfından güvenli bir örnek inceleyin.
4. Yeniden denemeler bağımlılığı boğuyorsa eşzamanlılığı azaltın veya ilgili partition'ı duraklatın.
5. Kod ya da veriyi düzeltin; idempotency kontrolüyle devam edin veya kontrollü replay yapın.
6. Lag'in düşmesiyle yetinmeyin. Stok rezervasyonu ve diğer iş sonuçlarını doğrulayın.

Canlıya çıkış için son kontrol: Anahtar dağılımını ölçtünüz mü? Broker kaybını, consumer çökmesini, bozuk olayı ve replay'i denediniz mi? Sorumlular ve kurtarma adımları yazılı mı? Bu soruların cevabı, çalışan bir demoyu güvenilir bir sisteme dönüştürür.

Kaynaklar

• Apache Kafka: Giriş
• Apache Kafka belgeleri
• Kafka yükseltme ve KRaft rehberi
• Confluent: Consumer tasarımı