Apache Kafka ve Apache Pulsar: Mimari, Tüketim ve İşletim Farkları

Ortak zemin: kalıcı log üzerinde yayınla ve abone ol

Kafka ve Pulsar, olayları üreten sistemlerle onları tüketen sistemleri birbirinden ayıran dağıtık olay akışı platformlarıdır. İkisinde de üreticiler topic'lere yazar, tüketiciler bu topic'lerden okur; olaylar okunduktan sonra hemen kaybolmaz, diske yazılmış ve çoğaltılmış bir log'da tutulur. İkisi de topic'i bölümlere (partition) ayırarak paralel yazma ve okuma sağlar, aynı anahtara sahip olayların sırasını bölüm içinde korur.

Bu yüzden "hangisi daha hızlı" sorusu eksik kurulmuş bir sorudur; ikisi de doğru ayarlandığında yüksek hacimli akışları taşır. Asıl fark, verinin nerede ve nasıl saklandığı, tüketicilere mesajın nasıl dağıtıldığı ve platformun birden çok ekip ya da bölge için nasıl yönetildiğidir.

Mimari: veri broker'da mı, ayrı depolama katmanında mı?

Kafka'da broker hem hesaplama hem depolama yapar. Her bölüm bir lider broker'ın diskinde log olarak durur, diğer broker'lardaki takipçi kopyalara çoğaltılır. Küme metadata'sı Kafka 4.0 ile birlikte tamamen KRaft denetleyicileri tarafından yönetilir; bu sürüm ZooKeeper olmadan çalışan ilk ana sürümdür. Sonuç olarak bir Kafka kümesini büyütmek, yeni broker eklemek ve bölümleri yeni broker'lara taşımak demektir; bu taşıma verinin de kopyalanmasını gerektirir.

Pulsar katmanları ayırır. Broker'lar durumsuzdur: istemcilerle konuşur, mesajları önbellekten sunar, kalıcı yazmayı Apache BookKeeper'a bırakır. BookKeeper, yalnız eklenen ve bookie adı verilen depolama düğümlerine çoğaltılan ledger'lardan oluşan dağıtık bir yazma öncesi günlüktür. Ayrıca bir metadata deposu (Oxia, ZooKeeper ya da tek düğümlü kurulum için RocksDB) bulunur. Bu ayrım sayesinde topic sahipliği broker'lar arasında veri taşımadan el değiştirebilir, depolama ve hesaplama ayrı ölçeklenir. Bedeli, işletilecek bileşen sayısının artmasıdır.

Tüketim modeli: tüketici grubu ve abonelik tipleri

Kafka'da tüketiciler bir tüketici grubunda toplanır ve topic'in bölümleri grup üyelerine paylaştırılır; her bölümü grupta tek bir tüketici okur. İlerleme, bölüm başına tutulan offset ile izlenir. Bu model sıralı ve yüksek hacimli işleme için güçlüdür ama paralellik bölüm sayısıyla sınırlıdır. Kafka 4.0 duyurusunda paylaşımlı tüketim için share group kavramı erken erişim olarak tanıtılmıştır.

Pulsar'da aynı topic'e farklı abonelik tipleri bağlanabilir: • Exclusive: abonelikte tek tüketici bulunur. • Failover: birden çok tüketici bağlanır, biri aktiftir, düşerse sıradaki devralır. • Shared: mesajlar tüketiciler arasında dağıtılır, sıra korunmaz. • Key_Shared: aynı anahtarlı mesajlar hep aynı tüketiciye gider.

Pulsar ayrıca tek tek mesaj onayı ile toplu (kümülatif) onayı, negatif onayla yeniden teslimi, ölü mesaj (dead letter) topic'ini ve gecikmeli teslimi yerleşik sunar. Bu özellikler, akış ile iş kuyruğu davranışını aynı platformda birleştirmek isteyen ekipler için Pulsar'ı çekici kılar.

Ölçüt ölçüt farklar

• Depolama: Kafka / bölümler broker diskinde. Pulsar / BookKeeper ayrı katmanda; eski veri katmanlı depolamayla S3, Google Cloud Storage, Azure Blob gibi nesne depolarına aktarılabilir.
• Ölçekleme: Kafka / broker eklenince bölüm yeniden ataması ve veri kopyalama gerekir. Pulsar / broker'lar durumsuz, depolama ve hesaplama ayrı büyütülür.
• Çok kiracılık: Kafka / topic adlandırma, kotalar ve erişim listeleriyle kurulur. Pulsar / kiracı ve ad alanı (namespace) modeli yerleşik; topic adı kiracı, ad alanı ve topic hiyerarşisini taşır, politikalar ad alanı düzeyinde uygulanır.
• Coğrafi çoğaltma: Kafka / genellikle ayrı bir çoğaltma aracıyla kümeler arasında yapılır. Pulsar / broker'larda çalışan çoğaltıcılarla yerleşik.
• Mesaj tutma: Kafka / tutma süresi ya da boyutu topic düzeyinde ayarlanır, olaylar tüketimden sonra da kalır. Pulsar / onaylanan mesajlar varsayılan olarak silinir; tutma politikası ve TTL ad alanı düzeyinde ayarlanır.
• Ekosistem: Kafka / Kafka Connect ile hazır bağlayıcılar, Kafka Streams ile akış işleme, geniş topluluk ve yönetilen hizmet seçenekleri. Pulsar / daha küçük ama aktif bir ekosistem.
• İşletim: Kafka / tek tip bileşen, yaygın bilgi birikimi. Pulsar / broker, bookie ve metadata deposu ayrı ayrı izlenir ve ayarlanır.

Hangi durumda hangisi?

Kafka'yı öne çıkaran durumlar: ekip olay akışını mikroservis entegrasyonu, değişen veri yakalama ve analitik hatlar için kullanacak; Kafka Connect ve Kafka Streams ekosisteminden yararlanmak istiyor; Kafka bilen mühendis bulmak ve yönetilen hizmet seçmek önemli. Tek bir kurum için tek bir kümede çok sayıda ekip yoksa Kafka'nın daha az bileşenli yapısı işletmeyi sadeleştirir.

Pulsar'ı öne çıkaran durumlar: platform ekibi birçok iş birimine ya da müşteriye ortak bir mesajlaşma hizmeti sunacak ve kiracı bazlı yalıtım istiyor; uzun süre saklanan veri için depolamayı hesaplamadan ayrı büyütmek gerekiyor; aynı platformda hem akış hem iş kuyruğu (paylaşımlı tüketim, gecikmeli teslim, ölü mesaj topic'i) ihtiyacı var; birden çok bölge arasında yerleşik çoğaltma isteniyor.

Örneğin bir bankanın platform ekibi, ödeme, kart ve dijital kanal ekiplerine ayrı kiracılar açıp her birine kendi kotalarını ve erişim politikalarını tanımlamak istiyorsa Pulsar'ın kiracı modeli doğal bir uyum sağlar. Tek bir ürün ekibinin siparişleri olay olarak yayınlayıp analitik platforma aktarması ise Kafka ile daha az bileşenle çözülür.

Seçim yaparken sık düşülen hatalar

• Kıyas testlerini kendi iş yükünüzle yapmamak: üretici tarafında toplu gönderim, sıkıştırma ve onay ayarları her iki platformda da sonucu değiştirir; genel kıyas yazıları sizin mesaj boyutunuzu ve dağılımınızı yansıtmaz.
• Kafka'da bölüm sayısını ileride gereken paralelliği düşünmeden belirlemek; bölüm sayısı sonradan artırılabilir ama anahtar bazlı sıralama bozulabilir.
• Pulsar'da BookKeeper'ı ayrı bir depolama sistemi olarak izlememek; disk, günlük (journal) ve çoğaltma ayarları broker kadar dikkat ister.
• Mesaj kuyruğu ihtiyacını akış platformuyla karıştırmak: yalnız iş kuyruğu gerekiyorsa daha basit bir kuyruk aracı yeterli olabilir.
• Ekip yetkinliğini hesaba katmamak: işletimi kimin yapacağı ve gece arızasında kimin müdahale edeceği, mimari üstünlük kadar belirleyicidir.

Mindset programlarında olay akışı

Mindset kataloğunda Pulsar'a ayrılmış bir program yoktur; olay akışı tarafındaki programlar Kafka üzerine kuruludur. Apache Kafka ile Akış Mimarisi programı, uygulama geliştiricileri ve veri mühendisleri için topic yönetimi ve veri modelleme, producer ve consumer API'leri, Kafka Streams ve Kafka Connect ile entegrasyonu ele alır.

Apache Kafka Küme İşletimi ve Kapasite Yönetimi programı ise platform ve operasyon ekiplerine yöneliktir; bölümleme stratejisi, tüketici grupları ve yeniden dengeleme, güvenlik ve çoklu kiracı yönetimi ile kapasite planlaması modülleri, yukarıdaki karşılaştırmada Kafka tarafında işletim yükünü belirleyen konuların tamamına denk düşer.