Kafka ile akış mimarisi: konu, bölüm ve tüketici tasarımı

Apache Kafka nedir, ne için kullanılır?

Apache Kafka, olayları (mesajları) kalıcı biçimde saklayan, birçok üretici ile tüketici arasında yüksek hacimde ileten dağıtık bir olay akış platformudur. Bir veritabanı gibi veriyi saklar, bir mesaj kuyruğu gibi ileten tarafa dağıtır, ama ikisinden farklı olarak olayları belirli bir süre boyunca sıralı bir kayıt olarak tutar ve tüketicilerin bu kaydı kendi hızlarında, gerekirse geriye dönerek okumasına izin verir.

Sık kullanım alanları: • Servisler arası olay iletimi ve gevşek bağlı entegrasyon. • Kullanıcı davranışı, işlem ve sensör verisinin gerçek zamanlı toplanması. • Log ve metrik verisinin merkezi toplanması. • Veri ambarı ya da veri gölüne gerçek zamanlı yükleme. • Akış halindeki veriyle anlık hesaplama, örneğin sahtecilik sinyalleri.

Kafka her sorunun yanıtı değildir. Basit, düşük hacimli bir kuyruk ihtiyacı için gereksiz karmaşıklık getirebilir. Asıl gücü, yüksek hacim, kalıcı kayıt ve birçok bağımsız tüketicinin aynı akışı okuması gereken senaryolarda ortaya çıkar.

Temel kavramlar: konu, bölüm, ofset ve tüketici grubu

Kafka'yı öğrenmenin ilk eşiği kavramları doğru oturtmaktır. • Konu (topic): olayların kategorisel adı. Örneğin "siparişler". • Bölüm (partition): konunun fiziksel parçaları. Her bölüm, sıralı ve yalnızca eklenen bir kayıt dizisidir. Bölümler paralelliği ve ölçeklenmeyi sağlar. • Ofset (offset): bölüm içindeki her kaydın sıra numarası. Tüketici, nerede kaldığını ofsetle takip eder. • Üretici (producer): konuya kayıt yazan uygulama. • Tüketici (consumer) ve tüketici grubu (consumer group): aynı grubun üyeleri bir konunun bölümlerini aralarında paylaşır; böylece iş paralel işlenir. Farklı gruplar aynı konuyu bağımsızca okur. • Aracı (broker) ve küme (cluster): kayıtları saklayan Kafka sunucuları ve bunların oluşturduğu topluluk. • Çoğaltma (replication): bir bölümün kopyalarının farklı aracılarda tutulması, bir aracı çökse bile veri kaybını önler.

Sıralama bölüm düzeyinde sağlanır: aynı bölümdeki kayıtlar yazıldığı sırayla okunur, farklı bölümler arasında genel bir sıra yoktur.

Adım adım: gerçek zamanlı veri akışı kurmak

Bir akış mimarisinin kurulumu şu sırayı izler.

Birinci adım, olay ve konu tasarımıdır. Hangi iş olguları akışa girecek, kaç konu olacak, olay biçimi nedir? Konular iş alanına göre kurulur; her şeyi tek bir konuya doldurmak ya da her küçük olay için ayrı konu açmak sorun yaratır.

Sonra bölümleme düşünülür: konu kaç bölüme ayrılacak, hangi alan anahtar olacak? Aynı anahtara sahip kayıtlar aynı bölüme gider, bu da o anahtar için sıralamayı korur. Örneğin sipariş kimliği anahtar yapılırsa, bir siparişin olayları sırayla okunur.

Üretici tarafında kayıt gönderimi, onay (acknowledgement) ayarları ve hata durumunda yeniden deneme kurgulanır. Tüketici tarafında tüketici grubu, ofset yönetimi ve işlenemeyen kayıtlar için strateji belirlenir.

Son olarak kaynakla ve hedefle entegrasyon gelir: veritabanından Kafka'ya ya da Kafka'dan veri ambarına veri taşımak için Kafka Connect gibi hazır bağlayıcı yapıları kullanılır. Akış üzerinde hesaplama gerekiyorsa akış işleme kütüphaneleri devreye girer.

Konu ve bölümleme stratejisi

Bölümleme kararları sonradan değiştirmesi pahalı kararlardır, bu yüzden dikkatli verilmelidir. Ana ilke: paralellik, bölüm sayısıyla sınırlıdır. Aynı tüketici grubunda bölüm sayısından fazla tüketici etkin çalışamaz. Bölüm sayısı çok az seçilirse gelecekte ölçeklenme tıkanır; gereksiz fazla seçilirse yönetim yükü ve kaynak tüketimi artar.

Anahtar seçimi sıralama ihtiyacına göre yapılır. Tüm kayıtların sırayla işlenmesi gerekiyorsa tek bölüm gerekir ama bu paralelliği öldürür. Çoğu iş durumunda tüm olayların değil, aynı müşteri ya da aynı sipariş gibi ilişkili olayların sıralı olması yeterlidir.

Dengesiz dağılım (hot partition) başka bir risktir: bir anahtar çok fazla trafik alırsa o bölüm aşırı yüklenir. Anahtarın dağılımı baştan düşünülmelidir. Ayrıca saklama süresi, sıkıştırma politikası ve çoğaltma düzeyi kapasite ile dayanıklılık planına göre belirlenir.

Üretici ve tüketici tarafında dikkat edilecekler

Üretici tarafında en önemli konu, gönderilen kaydın ne zaman güvende sayılacağıdır. Onay ayarı, kaydın yalnızca lidere mi yoksa kopyalara da yazılana kadar mı bekleneceğini belirler; hız ve dayanıklılık arasındaki dengeyi kurar. Yeniden deneme etkinse aynı kaydın çift yazılma riski doğar, bu yüzden idempotent üretici ayarları değerlendirilir.

Tüketici tarafında teslim semantiği kritik önemdedir. Ofseti işlemeden önce kaydetmek veri kaybı yaratabilir; işledikten sonra kaydetmek ise çökme halinde aynı kaydı tekrar işlemeye yol açar. Çoğu pratik çözüm, "en az bir kez" işleme ve tüketicide eş değer (idempotent) işleme mantığıdır. İşlemsel yazma imkânları belirli koşullarda "tam bir kez" etkisini sağlamak için kullanılır, ancak bunların kapsamı ve sınırları sürüme göre resmî belgeden doğrulanmalıdır.

İşlenemeyen kayıtlar için ayrı bir hata konusu ve yeniden deneme akışı tasarlanmalıdır; bozuk tek bir kaydın tüketiciyi tıkaması önlenmelidir. Tüketici gecikmesi (lag) izlenmelidir, çünkü akışın sağlığını gösteren başlıca sinyallerden biridir.

Üretimde işletme: küme, güvenlik ve izleme

Kafka'yı üretime almak, sadece uygulama yazmak değildir. Küme boyutlandırma, çoğaltma düzeni, depolama, ağ ve güvenlik kararları gerekir.

Küme mimarisinde önemli bir değişiklik oldu. Kafka eskiden küme meta verisini ve denetleyici seçimini ayrı bir ZooKeeper topluluğuyla yönetiyordu. Güncel ana sürümler ZooKeeper olmadan, Kafka'nın kendi KRaft mekanizmasıyla çalışır; meta veri denetleyici rolündeki Kafka düğümlerinde tutulur. Bu nedenle eski eğitim kaynaklarındaki ZooKeeper kurulum adımları güncel sürümlere uymaz. ZooKeeper ile çalışan eski bir kümeyi yükseltmek için önce resmî belgede belirtilen köprü sürüme geçilip KRaft'a taşıma yapılır, sonra yeni ana sürüme çıkılır. Kimlik doğrulama, yetkilendirme ve trafik şifreleme, özellikle hassas veri taşınan akışlarda atlanmamalıdır.

İzlenecek başlıca sinyaller: tüketici gecikmesi, aracı sağlığı, bölüm dağılımı, disk kullanımı ve ağ gecikmesi. Bunlar için alarm eşikleri belirlenmeli, bakım ve sürüm yükseltme prosedürleri yazılmalıdır.

İşletme yükünü azaltmak isteyen kurumlar için yönetilen hizmetler de vardır; bu durumda kapasite ve maliyet kararları sağlayıcıya göre farklılaşır. Hangi seçenek seçilirse seçilsin olay şeması yönetimi (sürümleme, geriye uyumluluk) için bir kayıt mekanizması düşünmek, ileride yaşanacak entegrasyon sorunlarını azaltır.

Öğrenme yolu ve sık hatalar

Başlangıç düzeyinde kavramlar (konu, bölüm, ofset, tüketici grubu) öğrenilir ve yerelde bir örnek kurulur: bir üretici yaz, bir tüketici oku, tüketici grubuna ikinci tüketici ekleyip bölümlerin paylaşıldığını gözle. Orta düzeyde konu tasarımı, anahtar stratejisi, hata yönetimi ve Kafka Connect ile entegrasyon çalışılır. İleri düzeyde akış işleme, küme işletimi, güvenlik ve performans ayarı gelir.

Sık yapılan hatalar: • Bölüm ve anahtarı düşünmeden konu açmak, sonradan sıralama sorunlarıyla karşılaşmak. • Kafka'yı geleneksel veritabanı gibi görüp rastgele sorgulamayı beklemek. • Tüketici tarafında eş değer işleme yapmamak, çift olaylarda bozuk veri üretmek. • Tüketici gecikmesini izlememek. • Şema yönetimi olmadan olay yapısını serbestçe değiştirmek. • Küçük ve basit ihtiyaçlar için gereğinden ağır bir altyapı kurmak.

İlkeyi şöyle özetlemek mümkün: Kafka bir araçtır; asıl iş, olay ve konu tasarımını doğru yapmak ve hata durumlarını baştan düşünmektir.

Bu beceriyi Mindset programlarında geliştirmek

Apache Kafka ile Akış Mimarisi programı Kafka mimarisi ve temel kavramlar, konu yönetimi ve veri modelleme, producer API ve mesaj gönderme, consumer API ve tüketim stratejileri, Kafka Streams ve gerçek zamanlı işlem, Kafka Connect ile entegrasyon ile Kafka kümeleme ve üretim yönetimi modüllerini içerir.

Kafka Konusu Tasarımı ve Bölümleme Stratejisi programı ise konu tasarımı ilkeleri, bölümleme ve sıralama davranışı ile dayanıklılık ve kapasite planı konularına odaklanır.