‘Kafka’ öldü ama ‘Kafka’ sonsuza dek yaşayacak

• Kafka, veri merkezi çağının dağıtık log sistemi olarak başarılı oldu; ancak public cloud ortamında AZ'ler arası ağ maliyeti ve yerel disk işletim yükü büyüdü
• WarpStream, Apache Kafka protokolüyle uyumlu disksiz bir streaming platformu; S3 gibi nesne depolama üzerinde yerel disk ve broker rebalancing olmadan çalışıyor
• 3 erişilebilirlik bölgesine yayılan bir Kafka kümesinde, 1GiB streaming için en iyi durumda bile yaklaşık $0.053 AZ'ler arası aktarım maliyeti oluşuyor; bu da S3'te 1GiB veriyi bir ay saklama maliyeti olan $0.021'den yüksek
• WarpStream, durumsuz bir Go ikilisi olan Agent ile ayrı bir metadata deposu kullanarak storage-compute ve data-metadata ayrımını yapıyor; veriler ise kullanıcının bulut hesabındaki nesne depolamada kalıyor
• Maliyet çoğu Kafka iş yükünde 5–10 kat azaltılabiliyor; ancak mevcut uygulamada Produce isteklerinde yaklaşık P99 400ms, üreticiden tüketiciye uçtan uca yaklaşık P99 1 saniye gecikme göze alınmalı

---

Bulutta pahalı hale gelen Kafka'nın temel yapısı

• Apache Kafka, 2011'de açık kaynak olarak yayımlandıktan sonra streaming mimarilerinin temel altyapısı haline geldi
• Sorun Kafka'nın kendisinden çok, 2011'de LinkedIn veri merkezi için tasarlanmış yapısının modern bulut iş yükleriyle iyi örtüşmemesi
• Maliyet ve operasyon yükü özellikle burada belirginleşiyor
  • Bulut ekonomisi: Kafka'nın replikasyon modeli, AZ'ler arası bant genişliği maliyetini ciddi biçimde artırabiliyor
  • Operasyon yükü: Kendi Kafka kümenizi işletmek için özel bir ekip ve özelleştirilmiş araçlar gerekiyor
• Veriyi yerel diskte tutan benzer sistemler de aynı maliyet ve operasyon sorunlarını yaşayabiliyor

Kafka-nomics: AZ'ler arası aktarım maliyeti

• Tipik bir 3 erişilebilirlik bölgesi Kafka kümesinde, üretilen veri partition leader'ın konumuna bağlı olarak 2/3 olasılıkla bölge sınırını aşarak yazılıyor; ardından leader veriyi diğer iki bölgedeki follower'lara çoğaltıyor
• 1GiB verinin bölgeler arasında aktarım maliyeti $0.022 olarak hesaplanıyor
  • kaynak bölgeden egress $0.01
  • hedef bölgeye ingress $0.01
• En iyi durumda bile 1GiB streaming maliyeti 0.02 * 2/3 + 0.02 * 2 = $0.053 seviyesinde
• S3'te 1GiB veriyi bir ay saklamanın maliyeti $0.021; yani veriyi Kafka üzerinden üreticiden tüketiciye kopyalamanın maliyetiyle aynı veriyi S3'te iki aydan uzun süre tutmak mümkün
• Yüksek throughput'lu Kafka kümelerinde, donanımdan çok AZ'ler arası bant genişliği ücretleri maliyeti belirliyor ve iş yükü maliyetinin %70–90'ına kadar çıkabiliyor
• Throughput düşük olsa bile saklama süresi uzunsa depolama kapasitesi büyüyor; yerel SSD üzerinde 3 kopyalı yapı, disk kullanımının %100 olduğu varsayımında bile GiB başına S3 gibi nesne depolamadan yaklaşık 10–20 kat daha pahalı olabiliyor

Geliştiricinin sırtına binen küme işletimi

• Geliştiriciler iş problemlerini çözmek için Kafka'yı kullanıma alıyor; ancak önce Kafka ve ZooKeeper veya KRaft, leader election, partition'lar, consumer group'lar, rebalancing, broker tuning ve client tuning konularını öğrenmek zorunda kalıyor
• Kafka'nın veri düzlemi olan broker'lar ile uzlaşı tabanlı kontrol düzlemi olan controller'lar ve ZooKeeper gibi bileşenlerin tümü doğrudan yerel SSD üzerinde işletiliyor
• Kendi barındırdığınız Kafka kümesinde, düğüm değişimi veya küme genişletme gibi temel işleri bile güvenli yapmak için uzman bir ekip ve özel araçlar gerekiyor
• Apache Kafka'nın yerleşik partition yeniden atama aracı, broker devreden çıkarılırken otomatik yeniden atama planı oluşturamıyor; yöneticinin partition replica taşıma planını elle yazması gerekiyor
• AWS MSK gibi barındırılan hizmetler de operasyon yükünü tamamen ortadan kaldırmıyor
  • MSK'nin cluster rebalancing dokümanı Apache Kafka dokümantasyonuna bağlantı veriyor
  • Bu süreçte hangi partition'ın hangi broker'a taşınacağını belirleyen JSON'un elle düzenlenmesi de yer alıyor
• Cruise Control bu yükü azaltabiliyor; ancak ek kavramlar öğrenmeyi, ayrı bir servis dağıtımını/izlemeyi ve yeni operasyonel keskin köşeleri beraberinde getiriyor
  • Cruise Control'ün kendisi de Apache Kafka ve ZooKeeper'a bağımlı bir JVM uygulaması

Nesne depolama üzerine streaming kurma yaklaşımı

• Datadog'un geliştirdiği Husky, S3 üzerinde doğrudan çalışan gözlemlenebilirlik verileri için sütunlu bir veritabanıydı ve büyük ölçüde durumsuz, otomatik ölçeklenen bir veri gölü gibi çalışıyordu
• Husky kurulduktan sonra Kafka kümeleri karşılaştırmada eski bir yapı gibi görünmeye başladı
• Datadog'da Kafka bant genişliği çift haneli GiB/s düzeyindeydi; broker depolaması ise PiB ölçeğinde NVMe ile ölçülüyordu
• Büyük ölçekli depolama iş yüklerinde, bulut ortamında nesne depolamanın ekonomiklik, güvenilirlik, ölçeklenebilirlik ve esneklik avantajlarıyla rekabet etmek zor
• Snowflake ve Databricks gibi büyük veri teknolojileri de sistemlerini genel amaçlı nesne depolama etrafında tasarlıyor
• Kafka'ya benzer bir sistemi doğrudan S3 üzerinde kurmak, iki yükü aynı anda azaltabilir
  • maliyet düşüşü
  • geleneksel Kafka operasyon sorunlarının azalması
• Asıl zorluk, S3 gibi yüksek gecikmeli depolama ortamları üzerinde yerel disk olmadan Kafka protokolünün semantiğini koruyarak düşük gecikmeli bir streaming altyapısı kurmak

WarpStream mimarisi

• WarpStream; AWS S3, GCP GCS, Azure Blob Storage gibi genel amaçlı nesne depoları üzerinde doğrudan çalışan, Apache Kafka protokolüyle uyumlu bir streaming platformu
• AZ'ler arası bant genişliği maliyeti yok, yönetilecek yerel disk yok ve kullanıcının VPC'si içinde çalışabiliyor
• Kafka broker'ı yerine Agent kullanılıyor
  • Agent, durumsuz bir Go ikilisi
  • JVM kullanmıyor
  • Kafka protokolünü konuşuyor
  • Herhangi bir Agent; topic leader, consumer group offset commit ve cluster coordinator rolünü üstlenebiliyor
• WarpStream, Kafka'nın stateful yapısını iki ayrımla değiştiriyor
  • storage ile compute'u ayırıp veriyi S3'e offload ediyor
  • data ile metadata'yı ayırıp metadata'yı özel bir metadata deposuna offload ediyor
• Tüm depolamayı nesne depolamaya taşıdığınızda, yük değişimine göre Agent sayısını artırıp azaltırken data rebalancing gerekmiyor
• Arıza durumunda istekler başka bir Agent üzerinde anında yeniden denenebildiği için toparlanma daha hızlı
• Partition bazlı veri dengesizliği nedeniyle bazı Kafka broker'larında yükün yığılması şeklindeki hotspot sorunu da büyük ölçüde azalıyor
• WarpStream Virtual Cluster metadata'sı özel bir metadata veritabanında tutuluyor
• Veri replikasyonu, dayanıklılık ve erişilebilirlikten nesne depolama bucket'ı sorumlu; kullanıcının verisi de kendi bulut hesabında kalıyor
• Bulut hesabının dışına çıkan tek şey, partition içindeki batch sırası gibi uzlaşı için gerekli iş yükü metadata'sı
• Daha ayrıntılı yapı WarpStream mimari dokümanında anlatılıyor

Maliyet örnekleri ve gecikme takası

• Test ortamındaki sürekli streaming iş yükü, 140MiB/s veriyi sürekli üretiyor ve buna adanmış 3 tüketici bunu işleyerek toplam 560MiB/s sürekli veri aktarımı oluşturuyor
• Tüm bulut hesabında AZ'ler arası ağ maliyeti günlük ortalama $15'in altında ölçülmüş
• Aynı iş yükü bir Kafka kümesinde çalıştırılırsa, yalnızca AZ'ler arası ağ maliyeti günlük $641 olarak hesaplanıyor
  • formül: 0.14GiB * $0.053/GiB * 60 * 60 * 24
• Aynı iş yükünde S3 API işlem maliyeti günlük $40'ın altında
• Agent donanımı olarak yalnızca 27 vCPU ölçeğinde VM gerekiyor
• Çoğu Kafka iş yükünde toplam sahip olma maliyeti WarpStream ile 5–10 kat daha düşük olabiliyor
• En büyük dezavantaj gecikme
  • Produce isteği P99 şu anda yaklaşık 400ms
  • çünkü veri S3'e dayanıklı biçimde yazılıp bulut control plane'ine commit edilmeden önce onay yanıtı verilmiyor
  • üreticiden tüketiciye uçtan uca P99 gecikme yaklaşık 1 saniye
• Eğer iş yükü üretici-tüketici arasında yaklaşık P99 1 saniyelik gecikmeyi tolere edebiliyorsa, GiB başına streaming maliyeti 5–10 kat azaltılıp operasyon yükü neredeyse ortadan kaldırılabiliyor
• Arayüz özel bir protokol değil, Kafka; ayrıca AWS S3, GCP GCS ve Azure Blob Storage kullanılan ortamlarda çalışabiliyor

Geliştirici deneyimi ve kullanım şekli

• WarpStream, Kafka'nın temel sorunları arasında önce bulut ekonomisi ve operasyon yükünü ele alıyor
• Kafka'nın geliştirici deneyimiyle ilgili sorunları da var; partition'lar, karmaşık stream processing uygulamaları yazmak için fazla düşük seviyeli bir soyutlama olarak görülüyor
• İleride stream processing uygulamalarını daha geleneksel uygulama geliştirmeye yaklaştırmanın yollarını ele almayı planlıyor
• Demo 30 saniye içinde çalıştırılabiliyor

$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo

• WarpStream, Apache Kafka için nesne depolama tabanlı bir alternatif satan bir şirketin ürün tanıtımı; metindeki sayılar ve karşılaştırmalar bu bağlamda değerlendirilmeli

[GN⁺]

Hacker News yorumları

• “Neredeyse her teknoloji şirketi Kafka kullanıyor” sözü bence yanlış
  Birbirimize kanıt sunmuş değiliz ama yakın zamanda çalıştığım 6 şirketin Kafka kullananı 0’dı; ondan önceki şirkette ise geçişe ben öncülük etmiştim ama sonra bıraktık
  LinkedIn, insanların %99’unda olmayan hiper ölçekli sorunları çözmek için Kafka’yı yaptı; mühendislerin ihtiyaç duymadıkları teknolojileri kullanma gibi bir ünü olsa da çoğunun Kafka kullanmaktan kaçınmayı başardığını düşünüyorum

  • Kafka’dan nasıl nefret edilebildiğini pek anlamıyorum. Kafka, kelimenin tam anlamıyla yayınlama/abonelik semantiğiyle veriyi A’dan B’ye taşır
    İhtiyacınız olan tek şey buysa, saklama süresi olmayan basit bir mesaj aracısı gibi kullanmak kolaydır; kalıcılıktan yararlanan sıra dışı işler gerekiyorsa da o yöne gidebilirsiniz
    Temel haliyle bile sağlam ve yaygın kullanılan bir açık kaynak araca karşı olumsuz hisler besleniyorsa, bunun genelde bazı özel işlevlerden veya kullanım örneklerinden kaynaklandığını sanırım
    Hatta bu tür bir ifade bu satıcı için iyi görünmüyor. Kafka’yı teknik artı ve eksileri üzerinden eleştirebilir ya da onunla rekabet edebilirsiniz ama pazardaki konumunu çarpıtmak pek hoş değil
  • Kafka bir mesaj kuyruğundan çok kalıcı bir WAL’a daha yakın. İşiniz için WAL gerekmiyorsa neredeyse kesinlikle fazla gelecektir ve ondan hoşlanmayacaksınız; WAL gerekiyorsa da en iyi araç olur
  • Sözleşmeli çalıştığım için birçok şirket arasında dolaşıyorum; Kafka’yı devreye almak isteyen şirketleri birkaç kez gördüm ve her seferinde sorun arayan bir çözüm gibi göründü
    İyi kullanım örnekleri olduğundan şüphem yok ama bugüne kadar onu her duruma zorla sokmaya çalışan hevesli kullanıcılar gördüğüm için ağzımda kötü bir tat kaldı; bu yüzden “sevmeyenler” tarafındayım
  • Katılmıyorum. İnsanlar Kafka’yı gerekmediği yerlere uydurmaya çalışabilir ama event streaming olan uygulamalarda Kafka hâlâ ilk tercihtir. Analitik, mesajlaşma, sensörler vb. buna girer
    “Accidental SRE” kısmına katılıyorum ama Kafka sağlam bir teknoloji; bu yüzden Redpanda gibi “Kafka’dan daha iyi Kafka” araçları da ortalıkta bolca var
    Sonda konu biraz dağılmış gibi. Yaygın kullanılmıyor olsa bile bu, onun kutuplaştırıcı bir teknoloji olup olmamasından ayrı bir mesele. Bahsedilen %1’lik ölçek sorununu çözenler için hâlâ sevilen ya da nefret edilen bir şey olabilir
    Bu, “Lamborghini tartışmalı bir araçtır” sözünün, çoğu insanın Lamborghini’si olmadığı için yanlış olduğunu söylemeye benziyor. Yazar da açıkça “veri alanında” diyerek kapsamı sınırlandırmış
  • Bu ifadenin kişisel ağım ve iş deneyimimden epey etkilendiği doğru gibi görünüyor

• Birkaç sorum var

  1. Her mesajı doğrudan S3’e koyarsanız S3 API çağrısı maliyeti muazzam olmaz mı? Yerel depolama olmadan mesajları nasıl dayanıklı biçimde buffer/queue/merge ediyorsunuz?
  2. Her availability zone için birer Kafka cluster çalıştırıp, ETL zamanına kadar availability zone’lar arasında replikasyon yapmamanın sorunu ne? AZ1 istemcileri AZ1 cluster’ına, AZ2 istemcileri AZ2 cluster’ına gönderecek şekilde
  3. Kafka partition’ı içinde işlem sırası nasıl korunuyor?
  • WarpStream Agent, son yaklaşık 100 ms içinde istek almış tüm topic-partition’ların verisini tek bir dosyada birleştirip S3’e flush eder
    Bu yüzden S3 PUT maliyeti topic-partition sayısına değil, çalışan Agent sayısına ve flush aralığına bağlıdır. Veri S3’te ve bulut kontrol düzleminde dayanıklı biçimde saklanmadan Produce isteklerini onaylamaz
    Güvenilirlik ile maliyet arasında seçim yapmak zorunda kalınmaması gerektiğini düşünüyoruz. WarpStream, 3 availability zone’da çalıştırma seviyesinde güvenilirlik ve erişilebilirliği tek availability zone maliyetiyle sunar
    Sıralamayı bulut kontrol düzleminde çalışan özel bir metadata veritabanı yönetir
  • Kafka’nın çalışma biçimi gereği mesajlar broker’a ulaşmadan önce doğal olarak buffer’lanıp birleştirilir; dolayısıyla mesajlar zaten birleştiriliyor
    Her availability zone’da Kafka cluster bulundurup daha sonra birleştirene kadar replikasyon yapmakta başlı başına bir sorun yok. Ancak dağıtık sistemler ve availability zone’lar söz konusu olduğunda mühendisler ve iş gereksinimleri çoğunlukla çoklu availability zone yapılandırmasını seçer. Region için de aynı şey geçerli
    Bu yüzden çoğu Kafka cluster’ı çoklu availability zone’dadır ama aslında çoğu durumda buna gerek yoktur; bunun faturası da Kafka’ya kesilir
    Kafka protokolü, Kafka partition’ı içindeki işlem sırasını gerçekte korumaz. Producer-partition çifti içindeki işlem sırasını korur; o da ancak belirli şekilde yapılandırıldığında mümkündür
    Standart uygulama, broker’ın producer’dan mesajları aldığı sırayı korur; ancak harici sistem açısından bu, doğru yapılandırıldığında belirli bir key ve belirli bir producer’a ait mesajların alınma sırasıyla korunduğu anlamına daha yakındır
  • Özellikle 3. maddeyi merak ediyorum. Mimari genel bakışına bakınca tüm Agent’ların aktif olarak yazıp sıkıştırma yaptığı anlaşılıyor; hangi topic-partition’ın sıkıştırılacağını nasıl koordine ediyorsunuz?
    Cloud Metadata Store fiilen offset’leri dağıtan rolü mü üstleniyor?
  • 1. maddeyle ilgili olarak, Kafka AWS içinde barındırılıyorsa Amazon’un AWS içi data transfer için ücret almadığını biliyorum

• WarpStream’in kurucu ortağı ve CTO’su Ryan Worl. S3’ün üzerine doğrudan inşa ettiğimiz Kafka protokolü uyumlu streaming sisteminin geliştirici ön izlemesini duyurmaktan çok mutluyum.
  Çalıştırılacak durum tutan disk/düğüm yok, veri yeniden dengeleme yok, ZooKeeper yok ve kullanılabilirlik bölgeleri arası bant genişliği maliyeti olmadığı için 5–10 kat daha ucuz.
  WarpStream hakkında sorularınız varsa kurucu ortağım richieartoul ile birlikte yanıtlayacağım.

  • Tebrikler. Yan proje listemdeki “Kafka’nın SQLite’ı” maddesini silebildiğim için mutluyum.
    Bunu yapmamamın nedenlerinden biri, ölçek önemli değilse kullanıcıların küçültülmüş bir Kafka istemek yerine doğrudan SQLite kullanmasının daha mantıklı olup olmadığı paradoksuydu.
    Ama insanlar Kafka protokolünün semantiğini seviyor olabilir ya da zaten Kafka kullanırken düşündükleri ölçekte olmadıklarını ve karmaşıklığı taşımaları gerekmediğini fark etmiş olabilirler. Bol şans.
  • S3 uyumlu servisleri, özellikle Cloudflare R2’yi destekliyor mu? S3 uyumlu sağlayıcıların API davranışları ve tutarlılık modelleri biraz farklı olabildiğinden özel işlem gerekebileceğini duymuştum.
    Cloudflare R2’yi destekliyorsa çoklu bulut için de iyi olur gibi görünüyor.
  • Blog yazısında partition’ların programların doğrudan ele alması için fazla düşük seviyeli bir soyutlama olduğu söylenmişti; bu, WarpStream’in partition kullanmadığı anlamına mı geliyor?
    Kafka’nın partition düzeyinde sağladığı türden sıralama garantileri de sağlıyor mu?
  • Producer artık S3 yazımını beklemek zorunda olduğundan gecikme çok daha yüksek olmayacak mı?
    “5–10 kat daha ucuz” olmasının büyük kısmı kullanılabilirlik bölgeleri arası maliyet tasarrufundan geliyorsa, AWS MSK de bunu sunmuyor mu?
  • ZooKeeper’ın yerini nasıl alıyor?

• Kesin olan bir şey var: Kafka’yı bulut sağlayıcı üzerindeki ayrı VM’lerde “kitabına uygun” çalıştırmak gülünç derecede pahalı.
  Kafka ve Hadoop hakkında birçok müşteriyle yaptığım çok basit bir konuşmayı hatırlıyorum: Disk zaten tam bir yedekli sistem olarak sunuluyorken veriyi neden VM/disk düzeyinde tekrar çoğaltıyoruz?
  Burada söz konusu olan Azure Storage’dı; yerel yedeklilik, kullanılabilirlik bölgesi yedekliliği ve küresel yedekli depolama sunuyordu ve bunların önemli bir kısmı yönetilen diskleri çalıştırmak için kullanılabiliyordu.
  Bu yüzden doğru tasarlanmış Hadoop/Kafka bulut yönetimli servisleri, sağlayıcının yerleşik yedekliliğinden yararlanmak için depolama adaptörleri kullanır. Bazı bulut sağlayıcılarda Kafka uyumlu event broker’ların olmasının nedeni de aynı.
  WarpStream’in geri kalanı daha çok pastanın üzerindeki krema gibi, ama iç mimarisini ve kullanılabilirlik bölgeleri arası maliyetlerden nasıl kaçındığını merak ediyorum.
  Not: Microsoft’ta çalışıyorum, ama şirkete girmeden önce, neredeyse 10 yıl önce Hadoop/Spark/Kafka kümeleri kuruyordum.

  • Eskiden yedekli sistemleri, gerçek process’lerden çok daha az kaynak kullanan tie-breaker process ile hayata geçirirdik.
    Bazı Raft implementasyonları oy hakkı olan ama quorum lideri olamayan düğümlere izin verir. Örneğin tüm trafiğin asimetrik bir VPN tünelinden geçtiği bir şube lider seçilmemeli, ama hangi adayı görebildiğini bilir.
    Bu yüzden küme işletmenin temel maliyeti donanımda 3 kat değil 2,2 kata daha yakındı; bu da küçük çözümler veya geliştirici sandbox’ları için büyük fark yaratıyordu. 3 shard yük için biraz yetersiz ama 5 fazla olduğunda ya da 6 ile 7 arasındaki farkta da önemliydi.
    Sorun şu ki coğrafi replikasyonda bu, yazının ana argümanı olan iki problemi çözmüyor. Bulut ekonomisi açısından Kafka’nın replikasyon stratejisi tasarımı gereği devasa kullanılabilirlik bölgeleri arası bant genişliği maliyetleri yaratıyor; operasyon yükü açısından ise kendi Kafka kümenizi işletmek pratikte özel bir ekip ve gelişmiş özel araçlar gerektiriyor.
    Yine de bulutta bu özelliği geri kazanmaya ihtiyaç var. Özellikle geçmişte de hep olduğu gibi pendül tekrar self-hosting tarafına sallanmaya başladığında.
  • Ya da amaçlandığı gibi broker’larda geçici veri deposu kullanmak yeterli.
  • “Disk zaten tam bir yedekli sistem olarak sunuluyorken neden veriyi VM/disk düzeyinde çoğaltıyorsunuz?” sorusunun cevabı basit.
    EBS ve benzeri çözümlerin bir maliyeti var. Özellikle çok IOPS gerektiğinde çok pahalılar. Kullanılabilirlik bölgeleri arası trafik maliyetinden tasarruf edebilirsiniz, ama depolamaya akıl almaz para ödersiniz.
    Replikasyonu kendiniz yaptığınızda çok daha ucuz bağlı depolama kullanabilirsiniz.
  • Azure disk replikasyonu verinin dayanıklılığı içindir; Kafka açısından veri kullanılabilirliği için değildir.

• richieartoul’a: Blog yazısı biraz fazla baharatlı olmuş.
  Kafka, çok büyük kümeler işletmeye başlayana kadar doğası gereği uzmanlardan oluşan özel bir ekip ve milyonlarca dolar gerektirmez.
  Ancak 3 kullanılabilirlik bölgesine yayılan bir kümenin bölgeler arası aktarım maliyetiyle parayı emdiğine tamamen katılıyorum. AWS’nin MSK’yı satma biçimi de bu zaten. Kullanılabilirlik bölgeleri arası aktarımın “ücretsiz” olduğu söyleniyor, ama aslında fiyatın içine çoktan dahil edilmiş durumda.

• İlginç görünüyor, ama “Accidental SRE”yi okuyunca aklıma iki soru geldi.
  Bare metal uzun zamandır var, ancak kendi bare metal yönetiminin özellikle çok daha kolaylaştığını sanmıyorum. Gerçekten kolay olsaydı son kullanıcılar bunları daha çok kendileri yönetirdi.
  O halde bu servisi nasıl yönetiyorsunuz? Bulut sağlayıcı üzerinde mi, bare metal üzerinde mi?
  İkinizin de genelde doğrudan yönetilen FoundationDB konusunda çok deneyimi var. Bu yüzden metadata deposu olarak yine FoundationDB’yi mi seçtiniz? Seçtiyseniz ya da seçmediyseniz nedenini merak ediyorum.

  • WarpStream’in mevcut sunum modeli hibrit BYOC yaklaşımı. Müşteri Agent’ı kendi bulut hesabında çalıştırıyor, biz ise metadata deposunu uzaktan yönetiyoruz.
    Böylece tüm müşteri verileri müşterinin bulut hesabı ve S3 bucket’ı içinde kalıyor; biz göremiyor veya dokunamıyoruz. Müşterinin WarpStream Agent’ı kendisinin çalıştırması gerekiyor, ama bu yalnızca yönetmesi kolay, durum tutmayan bir container.
    Metadata deposu olarak FoundationDB’yi değerlendirdik ama sonunda kullanmadık. Ücretsiz katmanı maliyet açısından verimli kılmak için metadata deposunu bu belirli kullanım durumu için mümkün olduğunca verimli hale getirmemiz gerekiyordu; bunun için de biraz daha özel bir şeye ihtiyaç vardı.
    Yine de FoundationDB harika bir teknoloji. Kullandığım dağıtık veritabanları arasında en iyilerinden biri.

• “Kaç partition kullanmalıyız? Belirsiz ama bir kez karar verdikten sonra asla değiştiremezsiniz, bu yüzden doğru seçmelisiniz” sözü düpedüz yanlış. Partition sayısı değiştirilebilir
  Ayrıca tekrar tekrar dile getirilen “Kafka işletmek için tüm bir mühendis ekibi gerekir” iddiasını da pek anlayamıyorum. Deneyimlerime göre doğru değil. İşletme maliyetinin yüksek olduğu doğru, ama bizim ekibimizde çok fazla mühendislik zamanı gerektirmiyor

• Çok ilginç. Ben de benzer bir şey tasarlamıştım ve Zig ile implemente etmeyi düşünüyordum https://github.com/fremantle-industries/transit
  Kafka’nın gücünün önemli bir kısmı API’sinden geliyor ve sonunda cluster yönetimi karmaşıklığının çeşitli implementasyonlar üzerinden soyutlanacağı yönünde benzer bir sonuca varmıştım
  Kafka kalıcılığı S3 key space üzerinde implemente edilebilirse, WarpStream gibi doğrudan S3’e kalıcı yazma yöntemiyle başlanıp daha sonra uçtan uca gecikmeyi düşürmek için daha hızlı hot disk ve bellek katmanlama mekanizmaları eklenebilir diye düşünmüştüm
  Yönü beğendim. Daha derin konuşmak istersen Twitter’dan ulaşabilirsin https://twitter.com/rupurt

• Eski iş yerimde muhtemelen bu ürüne çok benzeyen bir şey yapmıştım. Günlük iki haneli TB seviyesinde makine öğrenimi trafiği vardı ve gerçek zamanlı gecikme gerekmiyordu; hepsini S3’e taşıyınca yaklaşık %90 maliyet tasarrufu sağlandı
  JVM üzerinde geliştirmiştik ve metadata tutmak için hâlâ 6 broker’lı bir Kafka cluster’ı kullanıyorduk. Her şey Kafka’dayken muhtemelen 300 broker vardı
  Kafka’nın compute/storage modeli, gecikmeyi tolere edebilen uç kullanım senaryolarında iyi ölçeklenmiyor; Apache Pulsar modeli daha uygun oluyordu. Ancak o dönemde Pulsar, production’da kullanılacak kadar kararlı değildi
  Maliyet verimliliğinin kilit noktalarından biri, veri boyutunun ekonomik dosya boyutlarına ulaşmak için uzun süre beklemeyi gerektirmeyecek kadar büyük olmasıydı. Saniyede 10MB altındaki bir pipeline’ın bu yöntemle verimli çalışacağını hayal etmek zor

  • Bu alanda kendi çözümünü geliştirmiş epey kişiyle karşılaştım. “Geleneksel Kafka üzerinden S3 pointer’ları push etme” yaklaşımı çok pratik
    Bu Pinterest’in memq’suydu galiba, yoksa başka bir şey miydi?

• Yazının başlığı “Kafka is dead. Long live WarpStream.” olmalıydı. “long live” kısmı halefi işaret eder

  • İnce bir nüans var, ama burada Kafka implementasyonlarından daha uzun yaşayacağı için Kafka protokolünü halef olarak görüyoruz
  • Doğru. Ama bu ifadenin yalnızca paradoksal bir kalıp olarak kullanıldığını duymuştum
    https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!