Jepsen: Bufstream 0.1 सत्यापन परिणाम

अपडेट_2024-11-13

• शुरुआती रिपोर्ट में दावा किया गया था कि auto-commit सक्षम consumer हाल की poll से लौटे offset को अपने-आप commit कर देता है, जिससे data loss हो सकता है.
• लेकिन कई पाठकों ने इसका खंडन करते हुए कहा कि auto-commit consumer वास्तव में सबसे हाल की poll नहीं, बल्कि उससे पिछली poll के offset को commit करता है.
• Java Kafka client पर किए गए प्रयोग भी इसे समर्थन देते हैं, हालांकि अलग-अलग client का व्यवहार अलग हो सकता है.
• auto-commit के बारे में यह विशिष्ट दावा रिपोर्ट से हटा दिया गया है, और आगे के अध्ययन की आवश्यकता है.

पृष्ठभूमि

• Kafka replication, sharding, और append-only log देने वाला एक लोकप्रिय streaming system है.
• Bufstream, cloud environment में data governance और cost efficiency को प्राथमिकता देने वाला Kafka का एक alternative solution है.
• Kafka की तरह, Bufstream topic कहलाने वाले आंशिक रूप से क्रमबद्ध log के संग्रह प्रदान करता है, और हर topic partition में विभाजित होता है.
• Bufstream standard Kafka client के साथ compatible है, और Kafka API देने वाली stateless service agent, data store करने वाला object store, तथा coordination service से मिलकर बना है.
• Bufstream data storage को सीधे object storage service में लिखकर लागत घटाता है, और इसे stateless, auto-scalable VM पर चलाया जा सकता है.

क्लाइंट सुरक्षा

• Bufstream विभिन्न streaming application के लिए डिज़ाइन किया गया है, और सुरक्षित व्यवहार के लिए कई client configuration option सेट करता है.
• Kafka की तरह यह डिफ़ॉल्ट रूप से acks = all का उपयोग करता है, और data loss रोकने के लिए enable.auto.commit = false सेट करता है.
• auto.offset.reset = earliest का उपयोग किया जाता है ताकि consumer पूरे log को देख सके.

ट्रांज़ैक्शन

• Bufstream Kafka के transaction system को support करता है, और जटिल configuration के माध्यम से atomicity का एक अपेक्षाकृत कमजोर रूप प्रदान करता है.
• Consumer को read_uncommitted या read_committed isolation level पर चलाया जा सकता है, और read_committed कुछ घटनाओं (G1a, G1c) को रोकता है.
• Kafka, Redpanda, और Bufstream तीनों में G0 phenomenon देखा गया, जो documented isolation level से मेल नहीं खाता.

टेस्ट डिज़ाइन

• Bufstream 0.1.0 से 0.1.3 तक का परीक्षण किया गया, जिसमें Jepsen test library और Java Kafka Client का उपयोग हुआ.
• टेस्ट में विभिन्न fault inject करके Bufstream की safety का मूल्यांकन किया गया.

क्यू

• Kafka के data model के अनुरूप queue workload तैयार किया गया और उसे Bufstream पर इस्तेमाल किया गया.
• हर logical process producer, consumer, और admin client चलाता है, और अलग-अलग key पर record भेजता है.

अबॉर्ट

• अप्रत्याशित परिणामों के आधार पर transaction abort करने और offset ट्रैक करने वाला workload डिज़ाइन किया गया.
• aborted transaction के बाद के offset को चार श्रेणियों में बाँटा गया: progress, rewind, further rewind, other.

Bufstream परिणाम

रुका हुआ consumer (#1)

• 0.1.0 से 0.1.3-rc.8 तक consumer.poll() call तुरंत लौट आता था लेकिन कोई record नहीं देता था.
• Bufstream ने 0.1.3-rc.6 में cache refresh करके इस समस्या को ठीक किया.

रुके हुए producer और consumer (#2)

• 0.1.3-rc.6 में भी InitProducerId call fail होने या listOffsets call fail होने की समस्या थी.
• Bufstream ने अतिरिक्त polling logic जोड़कर इसे ठीक किया.

गलत 0 offset (#3)

• 0.1.0 से 0.1.3-rc.2 तक गलत 0 offset assign होने की समस्या हुई.
• Bufstream ने 0.1.3-rc.6 में इसे ठीक किया.

transaction write loss (#4)

• 0.1.2 में committed transaction के record गायब हो जाने की समस्या हुई.
• Bufstream ने 0.1.3-rc2 में इसे ठीक किया.

server-side filtering के कारण write loss (#5)

• 0.1.3-rc.8 में मामूली fault के जवाब में write loss हुआ.
• Bufstream ने 0.1.3-rc.12 में इस समस्या को ठीक किया.

Kafka परिणाम

भ्रामक error message (KIP-588)

• transaction timeout के दौरान भी ProducerFencedException आने की समस्या है.
• Kafka टीम को error message बदलने की सिफारिश की गई.

consumer shutdown के समय अनंत प्रतीक्षा की संभावना (KAFKA-17734)

• Consumer.close() call के network IO में अनंत समय तक अटकने की समस्या है.
• इस समस्या को KAFKA-17734 के ज़रिए ट्रैक किया जा रहा है.

transaction failure के बाद अनुमान से बाहर consumer offset (KAFKA-17582)

• transaction failure के समय consumer offset के intended behavior पर दस्तावेज़ीकरण की कमी है.
• Consumer aborted transaction के बाद offset को पीछे ले जा सकता है या आगे बढ़ता रह सकता है.

[GN⁺]

Hacker News राय

• Kafka में होने वाली समस्याओं की जांच के दौरान, अदृश्य writes पाए गए। इससे यह संभावना उठती है कि delayed Produce messages भविष्य के transactions में शामिल हो सकते हैं और transaction guarantees का उल्लंघन कर सकते हैं। यह शक भी है कि Kafka Java Client request timeout होने पर sequence numbers को दोबारा इस्तेमाल कर सकता है। Kafka पर और tests की ज़रूरत है

  • लगता है Jepsen को Kafka पर फिर से गहराई से जांच करनी चाहिए। पिछली जांच 2013 में हुई थी, और Kafka में खुद कई समस्याएं मिलने की संभावना है। "write की पुष्टि के बाद चुपचाप discard कर देना" जैसी समस्या बहुत गंभीर लगती है

• Bufstream के product page को देखकर यह समझ नहीं आया कि ये दो statements एक-दूसरे के साथ कैसे compatible हैं

  • Bufstream पूरी तरह AWS या GCP VPC के भीतर चल सकता है, जिससे data, metadata और uptime पर पूरा नियंत्रण रखा जा सकता है। Bufstream कभी भी बाहरी सिस्टम से communicate नहीं करता
  • Bufstream की pricing सरल है: uncompressed GiB पर $0.002 (लगभग $2 per TiB)। core, agent, या per-call charges नहीं हैं
  • ऐसा नहीं लगता कि पूरा business trust system के आधार पर चलाया जाएगा

• Kafka के auto-commit feature को लेकर हैरानी हुई

  • Kafka consumer इस बात से स्वतंत्र होकर कि processing वास्तव में हुई या नहीं, offsets को अपने-आप commit कर सकता है। इसका मतलब है कि अगर consumer ने records को poll किया, commit किया, और फिर crash हो गया, तो records खो सकते हैं
  • documentation के अनुसार, अगर auto-commit enabled है, तो हर बार poll method call होने पर लौटाए गए messages के offsets अपने-आप commit होने के लिए तैयार हो जाते हैं। अगर message processing पूरी नहीं हुई, तो crash की स्थिति में message progress खोने का जोखिम रहता है
  • auto-commit interval को adjust करने से duplicate processing में मदद मिल सकती है, लेकिन message loss में नहीं

• Kafka transaction protocol मूल रूप से समस्याग्रस्त है और इसे ठीक करने की ज़रूरत है

  • जांच और लेखन दोनों शानदार हैं

• सोच रहा हूँ कि क्या Kyle ने NATS Jetstream की समीक्षा की है

• bufstream का GitHub project नहीं मिला। सोच रहा हूँ क्या कोई सुराग है

• संबंधित blog posts और documentation पढ़ने के बाद, Kafka "exactly-once delivery" को "read-process-write operation" की एक property के रूप में परिभाषित करता है। लगता है इसे transaction के रूप में समझाना बेहतर होगा

• "transactions को आंशिक या पूर्ण रूप से observe किया जा सकता है" इस वाक्यांश को शायद "consumers आंशिक या पूर्ण रूप से observe कर सकते हैं" की तरह पढ़ा जाना चाहिए

• सोच रहा हूँ कि यह software किस काम आता है। instrumentation? black box?