Jepsen: ผลการตรวจสอบ Bufstream 0.1

อัปเดต_2024-11-13

• ในรายงานฉบับแรกมีการอ้างว่าคอนซูเมอร์ที่เปิดใช้ auto-commit จะคอมมิตออฟเซ็ตที่ถูกส่งกลับมาจาก poll ล่าสุดโดยอัตโนมัติ จนอาจทำให้เกิดการสูญหายของข้อมูลได้
• อย่างไรก็ตาม ผู้อ่านหลายคนโต้แย้งว่าคอนซูเมอร์แบบ auto-commit แท้จริงแล้วคอมมิตออฟเซ็ตของ poll ก่อนหน้า ไม่ใช่ poll ล่าสุด
• ผลการทดลองกับ Java Kafka client ก็สนับสนุนข้อโต้แย้งนี้ และแต่ละไคลเอนต์อาจทำงานแตกต่างกันได้
• ได้ลบข้ออ้างเฉพาะเกี่ยวกับ auto-commit ออกจากรายงานแล้ว และยังต้องมีการศึกษาเพิ่มเติม

พื้นหลัง

• Kafka เป็นระบบสตรีมมิงยอดนิยมที่มีการทำ replication, sharding และ append-only log
• Bufstream เป็นทางเลือกแทน Kafka ที่ให้ความสำคัญกับ data governance และความคุ้มค่าด้านต้นทุนในสภาพแวดล้อมคลาวด์
• เช่นเดียวกับ Kafka, Bufstream มีชุดของล็อกที่เรียงลำดับบางส่วนซึ่งเรียกว่า topic และแต่ละ topic ถูกแบ่งออกเป็น partition
• Bufstream เข้ากันได้กับ Kafka client มาตรฐาน และประกอบด้วย agent ซึ่งเป็นบริการแบบ stateless ที่ให้ Kafka API, object store สำหรับเก็บข้อมูล และ coordination service
• Bufstream ลดต้นทุนด้วยการเขียนข้อมูลลงบริการ object storage โดยตรง และสามารถรันบน VM แบบ stateless ที่ขยายอัตโนมัติได้

ความปลอดภัยของไคลเอนต์

• Bufstream ถูกออกแบบมาสำหรับแอปพลิเคชันสตรีมมิงหลากหลายประเภท และตั้งค่าตัวเลือกการกำหนดค่าของไคลเอนต์หลายอย่างเพื่อให้ทำงานได้อย่างปลอดภัย
• เช่นเดียวกับ Kafka, ใช้ acks = all เป็นค่าเริ่มต้น และตั้ง enable.auto.commit = false เพื่อป้องกันการสูญหายของข้อมูล
• ใช้ auto.offset.reset = earliest เพื่อให้คอนซูเมอร์สามารถสังเกตเห็นล็อกทั้งหมดได้

ธุรกรรม

• Bufstream รองรับระบบธุรกรรมของ Kafka และให้ atomicity ในรูปแบบที่อ่อนกว่าผ่านการตั้งค่าที่ซับซ้อน
• คอนซูเมอร์สามารถทำงานที่ระดับการแยก read_uncommitted หรือ read_committed ได้ และ read_committed ป้องกันปรากฏการณ์บางอย่าง (G1a, G1c)
• ทั้ง Kafka, Redpanda และ Bufstream ต่างก็เกิดปรากฏการณ์ G0 ซึ่งไม่สอดคล้องกับระดับการแยกที่มีการระบุไว้ในเอกสาร

การออกแบบการทดสอบ

• ทดสอบตั้งแต่ Bufstream 0.1.0 ถึง 0.1.3 โดยใช้ไลบรารีทดสอบ Jepsen และ Java Kafka Client
• การทดสอบประเมินความปลอดภัยของ Bufstream ด้วยการฉีดความขัดข้องหลากหลายรูปแบบ

คิว

• ออกแบบ workload แบบคิวให้สอดคล้องกับโมเดลข้อมูลของ Kafka และนำมาใช้กับ Bufstream
• แต่ละ logical process จะรันไคลเอนต์ producer, consumer และ admin พร้อมส่งเรคอร์ดสำหรับคีย์ที่หลากหลาย

การยกเลิก

• จากผลลัพธ์ที่ไม่คาดคิด ได้ออกแบบ workload เพื่อติดตามการยกเลิกธุรกรรมและออฟเซ็ต
• ออฟเซ็ตหลังธุรกรรมที่ถูกยกเลิกถูกจัดเป็น 4 หมวด: เดินหน้า, ย้อนกลับ, ย้อนกลับมากขึ้น, อื่นๆ

ผลลัพธ์ของ Bufstream

คอนซูเมอร์ค้าง (#1)

• ตั้งแต่ 0.1.0 ถึง 0.1.3-rc.8 พบปัญหาที่ consumer.poll() คืนค่าทันทีแต่ไม่คืนเรคอร์ดใดๆ
• Bufstream แก้ปัญหานี้ใน 0.1.3-rc.6 ด้วยการรีเฟรชแคช

โปรดิวเซอร์และคอนซูเมอร์ค้าง (#2)

• แม้ใน 0.1.3-rc.6 ก็ยังพบปัญหาที่การเรียก InitProducerId ล้มเหลว หรือการเรียก listOffsets ล้มเหลว
• Bufstream แก้ปัญหานี้ด้วยการเพิ่ม logic การ polling เพิ่มเติม

ออฟเซ็ต 0 ที่ไม่ถูกต้อง (#3)

• ตั้งแต่ 0.1.0 ถึง 0.1.3-rc.2 พบปัญหาที่มีการกำหนดออฟเซ็ต 0 อย่างไม่ถูกต้อง
• Bufstream แก้ปัญหานี้ใน 0.1.3-rc.6

การสูญหายของการเขียนในธุรกรรม (#4)

• ใน 0.1.2 พบปัญหาที่เรคอร์ดของธุรกรรมที่คอมมิตแล้วหายไป
• Bufstream แก้ปัญหานี้ใน 0.1.3-rc2

การสูญหายของการเขียนจากการกรองฝั่งเซิร์ฟเวอร์ (#5)

• ใน 0.1.3-rc.8 เกิดการสูญหายของการเขียนเมื่อระบบตอบสนองต่อความขัดข้องเล็กน้อย
• Bufstream แก้ปัญหานี้ใน 0.1.3-rc.12

ผลลัพธ์ของ Kafka

ข้อความผิดพลาดที่ทำให้เข้าใจผิด (KIP-588)

• มีปัญหาที่ ProducerFencedException เกิดขึ้นได้แม้ในกรณี transaction timeout
• แนะนำให้ทีม Kafka เปลี่ยนข้อความผิดพลาด

ความเป็นไปได้ที่จะรอไม่สิ้นสุดเมื่อปิดคอนซูเมอร์ (KAFKA-17734)

• มีปัญหาที่การเรียก Consumer.close() อาจรอไม่สิ้นสุดใน network IO
• ติดตามปัญหานี้ผ่าน KAFKA-17734

ออฟเซ็ตของคอนซูเมอร์ที่คาดเดาไม่ได้หลังธุรกรรมล้มเหลว (KAFKA-17582)

• ยังขาดเอกสารเกี่ยวกับพฤติกรรมที่ตั้งใจไว้ของออฟเซ็ตคอนซูเมอร์เมื่อธุรกรรมล้มเหลว
• คอนซูเมอร์อาจย้อนออฟเซ็ตกลับหรือเดินหน้าต่อหลังธุรกรรมที่ถูกยกเลิกได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ระหว่างตรวจสอบปัญหาที่เกิดขึ้นใน Kafka มีการพบการเขียนที่มองไม่เห็น ซึ่งชี้ให้เห็นว่าข้อความ Produce ที่ล่าช้าอาจถูกรวมเข้าไปในทรานแซกชันในอนาคตและละเมิดการรับประกันของทรานแซกชันได้ นอกจากนี้ยังมีข้อสงสัยว่า Kafka Java Client อาจนำหมายเลขลำดับกลับมาใช้ซ้ำได้เมื่อคำขอหมดเวลา ต้องมีการทดสอบ Kafka เพิ่มเติม

  • ดูเหมือนว่า Jepsen ควรกลับไปตรวจสอบ Kafka แบบเจาะลึกอีกครั้ง การตรวจสอบครั้งล่าสุดเกิดขึ้นในปี 2013 และมีความเป็นไปได้ว่าจะพบปัญหาอีกมากในตัว Kafka เอง ปัญหาอย่าง "ยืนยันการเขียนแล้วแต่ทิ้งเงียบ ๆ" ดูร้ายแรงมาก

• เมื่อดูหน้าผลิตภัณฑ์ของ Bufstream ก็สงสัยว่าคำกล่าวสองข้อนี้สอดคล้องกันได้อย่างไร

  • Bufstream สามารถรันได้ทั้งหมดภายใน AWS หรือ GCP VPC ทำให้ควบคุมข้อมูล เมทาดาทา และเวลาทำงานได้อย่างสมบูรณ์ Bufstream จะไม่สื่อสารออกภายนอกโดยเด็ดขาด
  • ราคาของ Bufstream เรียบง่าย: $0.002 ต่อ GiB ที่ไม่บีบอัด (ประมาณ $2 ต่อ TiB) ไม่มีการคิดค่าคอร์ เอเจนต์ หรือค่าต่อการเรียกใช้
  • ไม่น่าจะดำเนินธุรกิจทั้งหมดโดยอาศัยระบบความเชื่อใจกันล้วน ๆ

• รู้สึกแปลกใจกับฟีเจอร์ auto-commit ของ Kafka

  • Kafka consumer สามารถคอมมิตออฟเซ็ตอัตโนมัติได้โดยไม่ขึ้นกับว่าประมวลผลจริงแล้วหรือไม่ ซึ่งหมายความว่าหาก consumer poll เรคคอร์ดและคอมมิตแล้วเกิดล่ม เรคคอร์ดนั้นอาจสูญหายได้
  • ตามเอกสาร หากเปิดใช้ auto-commit ก็จะเตรียมคอมมิตออฟเซ็ตของข้อความที่ถูกส่งกลับทุกครั้งที่มีการเรียกเมธอด poll หากการประมวลผลข้อความยังไม่เสร็จ ก็มีความเสี่ยงที่จะสูญเสียความคืบหน้าของข้อความเมื่อเกิดการล่ม
  • การปรับช่วงเวลา auto-commit ช่วยเรื่องการประมวลผลซ้ำได้ แต่ไม่ช่วยเรื่องการสูญหายของข้อความ

• โปรโตคอลทรานแซกชันของ Kafka มีปัญหาในระดับพื้นฐานและจำเป็นต้องแก้ไข

  • เป็นงานสืบสวนและการเขียนที่ยอดเยี่ยม

• สงสัยว่า Kyle เคยตรวจดู NATS Jetstream หรือไม่

• หาโปรเจกต์ GitHub ของ bufstream ไม่เจอ สงสัยว่ามีเบาะแสอะไรไหม

• หลังจากอ่านบล็อกโพสต์และเอกสารที่เกี่ยวข้อง Kafka นิยาม "ส่งมอบแบบ exactly once" ว่าเป็นคุณสมบัติของ "งานอ่าน-ประมวลผล-เขียน" ซึ่งดูเหมือนว่าจะอธิบายว่าเป็นทรานแซกชันจะเหมาะกว่า

• วลี "ทรานแซกชันสามารถถูกสังเกตได้บางส่วนหรือทั้งหมด" น่าจะควรอ่านเป็น "consumer สามารถสังเกตได้บางส่วนหรือทั้งหมด"

• สงสัยว่าซอฟต์แวร์นี้ใช้ทำอะไร การวัดผล? กล่องดำ?