Kafka'yı sıfırdan yeniden inşa edebilseydik ne olurdu?

• KIP-1150 (disksiz Kafka) ve AutoMQ'nun Kafka fork projesi üzerinden bulut için optimize edilmiş Kafka tartışmaları hız kazandı
• Kafka yeniden yapılsaydı mevcut partition yapısının kaldırılması ve anahtar merkezli yaklaşım öneriliyor
• Eşzamanlılık denetimi ve broker taraflı şema desteği işlevlerine ihtiyaç duyuluyor
• Ölçeklenebilirlik, snapshot, multi-tenancy gibi modern sistem özelliklerinin entegre edilmesi gereği de vurgulanıyor
• Kafka'yı temel alıp mevcut Kafka'nın sınırlarını aşan gerçek anlamda bulut yerel bir event log sistemi hayal ediliyor

---

Kafka yeniden inşa edilseydi?

• Yakın zamanda KIP-1150 (disksiz Kafka) ve AutoMQ'nun Kafka fork'u duyuruldu; bunlar S3 gibi object storage ile Kafka'yı entegre ederek bulut ortamında esnekliği artırmayı ve maliyetleri düşürmeyi hedefliyor
• Mevcut Kafka'nın sınırlarını aşan bulut yerel bir event log sistemi hayal edilerek çeşitli iyileştirmeler öneriliyor

Partitionsız yapı önerisi

• Bulut object storage neredeyse sonsuz depolama gibi davrandığı için topic partition ihtiyacı azalıyor
• Çoğu durumda önemli olan ya global mesaj sırası ya da aynı anahtara sahip mesajların sırası oluyor
• Partition kavramı kullanıcıdan gizlenerek daha sade bir kullanım deneyimi sunulabilir

Anahtar merkezli yaklaşım

• Partition taraması yerine belirli bir anahtara ait tüm mesajlara hızlı erişim ve replay sağlayacak bir tasarım öneriliyor
• Milyonlarca entity düzeyinde stream desteklenerek tüketici sayısı talebe göre esnek biçimde ayarlanabilir
• Hatalar anahtar bazında izole edildiği için sistem genelindeki işleme verimliliği artar
• Event sourcing veya actor model sistemleri için ideal bir yapıdır

Topic hiyerarşisi desteği

• Solace benzeri sistemlerde olduğu gibi, mesaj payload'ının bir bölümünü yapılandırılmış yol biçimindeki topic tanımlayıcısına yükselterek desen tabanlı aboneliklerin mümkün olması gerekir
• Broker, tüm mesajı parse etmeden de verimli abonelik filtrelemeyi destekleyebilir

Eşzamanlılık denetimi özellikleri

• Mevcut Kafka'da yazma sırasında eşzamanlılık çakışmalarını önlemenin bir yolu yok
• Anahtar başına optimistic locking desteği sağlanırsa, mesajın en güncel durumu gördükten sonra yazılıp yazılmadığı doğrulanabilir
• Lost update sorunu önlenebilir

Broker taraflı şema desteği

• Kafka şu anda mesajları basit bir byte array olarak ele alıyor ve harici schema registry'ye bağımlı
• Şema tutarlılığı sağlamak için broker düzeyinde AsyncAPI metadata gibi şema bilgilerinin varsayılan olarak desteklenmesi gerektiği öneriliyor
• Böylece Apache Iceberg gibi open table format'larla da kolay entegrasyon mümkün olabilir

Ölçeklenebilirlik ve eklenti yapısı

• Postgres ve Kubernetes gibi genişletilebilir ve eklentiye açık bir yapı öneriliyor
• Protocol-aware proxy'lere (Kroxylicious vb.) gerek kalmadan broker düzeyinde filtre veya dönüşümlerin kolayca uygulanabilmesi gerekir
• Rate limiting, topic şifreleme, Iceberg tablo tabanlı backend desteği gibi özellikler eklenti olarak uygulanabilmelidir

Senkron commit callback

• Mevcut Kafka yalnızca eventual consistency garantisi veriyor
• Producer mesajı gönderdikten sonra, ondan türeyen verinin güncellenip güncellenmediğinin hemen doğrulanabildiği bir yapıya ihtiyaç olduğu öneriliyor
• Read-your-own-writes guarantee desteği ile Kafka'nın gerçek bir veritabanı log'u gibi kullanılabilmesi amaçlanıyor

Snapshot özelliği

• Kafka'nın mevcut compaction mekanizması yalnızca son mesajı bırakıyor; bu da sadece tüm durumun o mesajda yer aldığı senaryolarda işe yarıyor
• Sadece değişiklikler kaydediliyorsa, her anahtar için tüm event'lerin yeniden oynatılması gerektiğinden süre uzuyor
• Anahtar bazında event'leri snapshot olarak özetleyen mantıksal compaction özelliğine ihtiyaç var

Yerleşik multi-tenancy desteği

• Tüm modern veri sistemleri multi-tenancy konusunu varsayılan olarak dikkate almalı
• Yeni tenant ortamları düşük maliyetle ve anında oluşturulabilmeli; kaynaklar, güvenlik ve erişim denetimi sıkı biçimde ayrıştırılmalı

Diğer notlar

• Bazı özellikler S2 (yüksek kardinaliteli stream), Waltz (optimistic locking), Apache Pulsar (multi-tenancy) gibi sistemlerde zaten destekleniyor
• Ancak önerilen tüm özellikleri aynı anda destekleyen bir open source sistem bulunmuyor
• Bu yazı, Confluent bünyesindeki yazarın kişisel görüşlerini yansıtıyor; resmî görüş değil
• Teorik olarak LSM tree tabanlı bir mimarinin güçlü bir aday olacağı belirtiliyor

[kaydash]

Biz buna zaten Redis diyoruz.

[GN⁺]

Hacker News görüşleri

• Katılıyorum. Belirli kullanım senaryoları için head-of-line sorununu çözmeye değer

  • Ancak bugün tüm streaming sistemleri (veya geçici çözümler), mesaj anahtarı bazında onay için O(n^2) maliyet çıkarıyor
  • Pulsar gibi sistemler bu özellik için sıkça kullanılıyor
  • Bu karmaşıklık her gün ortaya çıkmayabilir ama ortaya çıktığında beklemek gerekir
  • Ekip arkadaşlarımla bu sorunu uzun süre inceledikten sonra, ölçeklenebilir mesaj anahtarı bazında onayı desteklemek için temelde mimari değişiklikler gerektiği sonucuna vardık
  • Mimari, sıralı bir indeks gerektiriyor; bu da n mesajın O(n log n) ile işlenmesi anlamına geliyor
  • Bu konu hakkında bir blog yazmak istedim ama zamanım olmadı
  • Mesaj anahtarı bazında onaya güvenmeyi düşünüyorsanız, ara sıra kesintiler veya gecikmeler beklemelisiniz

• NATS.io, Kafka'ya göre kullanımı daha kolay ve partition'ların kaldırılması, anahtar tabanlı stream desteği, esnek konu hiyerarşisi gibi birkaç noktayı zaten çözmüş durumda

• Kafka ile yolculuğum büyük ölçüde benzerdi

  • Başta, "Ah, ölçeklenebilir append-only log, harika ve basit" diye düşünüyorsunuz
  • Ama kullanınca aslında çok karmaşık olduğunu fark ediyorsunuz

• Bazı kullanım senaryolarında, create isteği onaylandığında türetilmiş veri görünümünün güncellendiğini garanti edebilmek faydalı olurdu

  • Kafka kullanmayın; bunun yerine doğrudan alt veri deposuna yazın
  • Böylece verinin commit edildiğini bilir ve sorgulayabileceğiniz bir veritabanına sahip olursunuz

• Bu soruyu 6 yıl önce sormuştum

  • Bunu Rust ile yazıp WASM'dan yararlansak nasıl olur diye düşünmüştüm
  • Son 6 yıldır bunun üzerinde çalışıyorum
  • Son 2 yıldır Rust ve WASM kullanarak Flink inşa ediyorum

• Kafka'nın object storage'ı mı? Bu, gecikmeyi ve maliyeti 10 kat artırır

  • Kafka, başarısının kurbanı oldu
  • Tasarımı basit ve zarif olduğu için, başlangıçta tasarlanmadığı birçok farklı amaç için kullanılıyor
  • Elbette bu kullanım senaryoları için kusursuz değil

• "Partition'ların kaldırılması" ve "anahtar düzeyinde stream" hakkında

  • Storage backend'i fiziksel partitioning'e dayandırdığınızda, bu aslında sadece partition'ları anahtar, anahtarları da event olarak yeniden adlandırmak oluyor

• Northguard'a dikkat etmek gerek

  • Bu, LinkedIn'in Kafka yeniden yazımının adı ve yaklaşık bir hafta önce bir stream processing buluşmasında tanıtıldı

• Apache Kafka'nın sorunlarının ne kadarının Apache Pulsar'a geçilerek çözüldüğünü merak ediyorum

  • Kafka öğrenme sürecini atlayıp doğrudan Pulsar kullandım
  • Bizim kullanım senaryomuza çok iyi uyuyor
  • Hiç şikayetim yok
  • Ama neden bu kadar az kişi tarafından kullanıldığını merak ediyorum

• Faydalı bir düşünce deneyi

  • Kafka'yı yeni bir şeyle değiştirmek gerektiği sonucunu ima eden yanıtlar sessiz kalıyor
  • Kafka'nın en büyük gücü, üstüne kurulmuş geniş ve faydalı ekosistemdir
  • Bu aynı zamanda zayıf yönü
  • Bugün sıfırdan başlasaydı yapmayacağı bazı tasarım kararlarını korumak zorunda
  • Ya da geriye dönük uyumluluktan vazgeçip, zaten sahip olduğu ekosistemi yeniden kurması gerekir