Jepsen: Bufstream 0.1 doğrulama sonuçları

Güncelleme_2024-11-13

• İlk raporda, auto-commit etkin tüketicilerin son poll çağrısında dönen ofsetleri otomatik olarak commit ederek veri kaybına yol açabileceği öne sürülmüştü.
• Ancak birçok okur, auto-commit tüketicilerin gerçekte son poll değil, ondan önceki poll çağrısının ofsetlerini commit ettiğini belirterek buna itiraz etti.
• Java Kafka istemcisiyle yapılan deneyler de bunu destekliyor; ancak davranış istemciye göre değişebilir.
• Rapordan auto-commit ile ilgili bu spesifik iddia kaldırıldı; ek araştırma gerekiyor.

Arka plan

• Kafka, replikasyon, sharding ve append-only log sağlayan popüler bir streaming sistemidir.
• Bufstream, bulut ortamında veri yönetişimi ve maliyet verimliliğini önceleyen, Kafka'ya alternatif bir çözümdür.
• Kafka'ya benzer şekilde Bufstream, topic adı verilen kısmen sıralı log kümeleri sunar ve her topic partition'lara ayrılır.
• Bufstream, standart Kafka istemcileriyle uyumludur ve Kafka API sunan durumsuz bir servis olan agent, veriyi depolayan object store ve bir coordination service bileşenlerinden oluşur.
• Bufstream, veri depolamayı doğrudan object storage servisine yazarak maliyetleri düşürür ve durumsuz, otomatik ölçeklenebilir VM'ler üzerinde çalıştırılabilir.

İstemci güvenliği

• Bufstream, çeşitli streaming uygulamaları için tasarlanmıştır ve güvenli davranış için çeşitli istemci yapılandırma seçenekleri belirler.
• Kafka'da olduğu gibi varsayılan olarak acks = all kullanır ve veri kaybını önlemek için enable.auto.commit = false olarak ayarlanır.
• Tüketicinin tüm logu gözlemleyebilmesi için auto.offset.reset = earliest kullanılır.

İşlemler

• Bufstream, Kafka'nın transaction sistemini destekler ve karmaşık yapılandırmalarla zayıf bir atomiklik biçimi sunar.
• Tüketiciler read_uncommitted veya read_committed yalıtım seviyelerinde çalışabilir; read_committed bazı olguları (G1a, G1c) önler.
• Kafka, Redpanda ve Bufstream'in tümünde G0 olgusu görülür; bu da belgelenmiş yalıtım seviyesiyle tutarlı değildir.

Test tasarımı

• Bufstream 0.1.0'dan 0.1.3'e kadar test edildi; Jepsen test kütüphanesi ve Java Kafka Client kullanıldı.
• Testler, Bufstream'in güvenliğini değerlendirmek için çeşitli arızalar enjekte eder.

Kuyruk

• Kafka'nın veri modeline uygun bir kuyruk iş yükü tasarlanarak Bufstream üzerinde kullanıldı.
• Her mantıksal süreç, üretici, tüketici ve yönetici istemcilerini çalıştırır ve çeşitli anahtarlar için kayıtlar gönderir.

İptal

• Beklenmedik sonuçlara dayanarak, işlemleri iptal eden ve ofsetleri izleyen bir iş yükü tasarlandı.
• İptal edilen işlemlerden sonraki ofsetler dört kategoriye ayrıldı: ilerleme, geri sarma, daha fazla geri sarma, diğer.

Bufstream sonuçları

Takılan tüketici (#1)

• 0.1.0'dan 0.1.3-rc.8'e kadar consumer.poll() çağrısının hemen dönüp hiçbir kayıt döndürmemesi sorunu görüldü.
• Bufstream, 0.1.3-rc.6'da önbelleği yenileyerek sorunu çözdü.

Takılan üretici ve tüketici (#2)

• 0.1.3-rc.6'da da InitProducerId çağrısının veya listOffsets çağrısının başarısız olması sorunu görüldü.
• Bufstream, ek polling mantığı ekleyerek sorunu çözdü.

Hatalı 0 ofseti (#3)

• 0.1.0'dan 0.1.3-rc.2'ye kadar hatalı 0 ofseti atanması sorunu yaşandı.
• Bufstream, bu sorunu 0.1.3-rc.6'da çözdü.

Transaction yazma kaybı (#4)

• 0.1.2'de commit edilmiş transaction kayıtlarının kaybolması sorunu yaşandı.
• Bufstream, sorunu 0.1.3-rc2'de çözdü.

Sunucu tarafı filtreleme nedeniyle yazma kaybı (#5)

• 0.1.3-rc.8'de hafif bir arızaya tepki olarak yazma kaybı oluştu.
• Bufstream, bu sorunu 0.1.3-rc.12'de çözdü.

Kafka sonuçları

Yanıltıcı hata mesajı (KIP-588)

• ProducerFencedException, transaction zaman aşımında da ortaya çıkabiliyor.
• Kafka ekibine hata mesajının değiştirilmesi öneriliyor.

Tüketici kapanışında sonsuz bekleme olasılığı (KAFKA-17734)

• Consumer.close() çağrısının ağ IO sırasında sonsuza kadar beklemesi sorunu var.
• Sorun KAFKA-17734 üzerinden takip ediliyor.

Transaction başarısızlığından sonra öngörülemez tüketici ofsetleri (KAFKA-17582)

• Transaction başarısız olduğunda tüketici ofsetlerinin amaçlanan davranışına ilişkin dokümantasyon yetersiz.
• Tüketici, iptal edilen bir transaction sonrasında ofsetleri geri sarabilir veya ilerlemeye devam edebilir.

[GN⁺]

Hacker News görüşleri

• Kafka’da ortaya çıkan sorunlar araştırılırken görünmez yazmalar tespit edilmiş. Bu, gecikmiş Produce mesajlarının gelecekteki transaction’lara dahil olarak transaction garantilerini ihlal edebileceğini düşündürüyor. Kafka Java Client’ın istek zaman aşımında sequence number’ı yeniden kullanabildiğine dair bir şüphe de var. Kafka üzerinde daha fazla test yapılması gerekiyor

  • Jepsen’in Kafka’ya yeniden derinlemesine bakması gerekiyor gibi görünüyor. Son inceleme 2013’te yapılmıştı ve Kafka’nın kendisinde daha pek çok sorun bulunabilir. "Yazmayı onayladıktan sonra sessizce atma" gibi sorunlar çok ciddi görünüyor

• Bufstream’in ürün sayfasına bakınca iki ifadenin nasıl birbiriyle uyumlu olduğu merak ediliyor

  • Bufstream, AWS veya GCP VPC içinde tamamen çalışabiliyor; böylece veri, metadata ve uptime üzerinde tam kontrol sağlanıyor. Bufstream asla dış dünya ile iletişim kurmuyor
  • Bufstream’in fiyatlandırması basit: sıkıştırılmamış GiB başına $0.002 (yaklaşık TiB başına $2). Çekirdek, ajan veya çağrı başına ücret yok
  • Tüm işi güven sistemine dayandırıyor gibi görünmüyor

• Kafka’nın auto-commit özelliği şaşırtıcı bulunmuş

  • Kafka consumer’ları, gerçekten işlenip işlenmediğine bakmaksızın offset’leri otomatik olarak commit edebiliyor. Bu da consumer kayıtları poll edip commit ettikten sonra çökerse kayıtların kaybolabileceği anlamına geliyor
  • Belgelerde belirtildiğine göre auto-commit etkinse, poll metodu her çağrıldığında dönen mesajların offset’lerini otomatik commit etmeye hazır hale geliyor. Mesaj işleme tamamlanmazsa, çökme durumunda mesaj ilerlemesinin kaybolma riski var
  • auto-commit aralığını ayarlamak yinelenen işlemeye yardımcı olabilir ama mesaj kaybına yardımcı olmaz

• Kafka transaction protokolünün temelden sorunlu olduğu ve düzeltilmesi gerektiği düşünülüyor

  • Harika bir araştırma ve yazım çalışması

• Kyle’ın NATS Jetstream’i inceleyip incelemediği merak ediliyor

• bufstream’in GitHub projesi bulunamamış. Bu konuda bir ipucu olup olmadığı soruluyor

• İlgili blog yazıları ve belgeler okunduktan sonra, Kafka’nın "exactly-once delivery" kavramını "read-process-write operation" özelliği olarak tanımladığı görülüyor. Bunu transaction olarak açıklamak daha doğru olur gibi görünüyor

• "Transaction’lar kısmen ya da tamamen gözlemlenebilir" ifadesinin aslında "consumer’lar kısmen ya da tamamen gözlemleyebilir" şeklinde okunması gerektiği düşünülüyor

• Bu yazılımın ne için kullanıldığı merak ediliyor. Telemetri? Kara kutu?