จะเป็นอย่างไรถ้าสร้าง Kafka ขึ้นมาใหม่ตั้งแต่ต้น?

 (morling.dev)
13 คะแนน โดย GN⁺ 2025-04-26 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • การพูดคุยเรื่อง Kafka ที่ปรับให้เหมาะกับคลาวด์ กำลังคึกคักมากขึ้นผ่าน KIP-1150 (Kafka แบบไม่มีดิสก์) และโปรเจกต์ Kafka fork ของ AutoMQ
  • หากสร้าง Kafka ขึ้นมาใหม่อีกครั้ง มีข้อเสนอให้ ตัดโครงสร้างพาร์ทิชันแบบเดิมออก และใช้ แนวทางที่ยึดคีย์เป็นศูนย์กลาง
  • มีความต้องการฟีเจอร์ การควบคุมการทำงานพร้อมกัน และ การรองรับสคีมาที่ฝั่งโบรกเกอร์
  • ยังเน้นย้ำถึงความจำเป็นในการผสานคุณลักษณะของระบบสมัยใหม่อย่าง ความสามารถในการขยายตัว, snapshot, multi-tenancy
  • เป็นการจินตนาการถึง ระบบ event log แบบ cloud-native ที่แท้จริง ซึ่งต่อยอดจาก Kafka และก้าวข้ามข้อจำกัดของ Kafka เดิม

ถ้าจะสร้าง Kafka ขึ้นมาใหม่?

  • ไม่นานมานี้มีการประกาศ KIP-1150 (Kafka แบบไม่มีดิสก์) และ Kafka fork ของ AutoMQ ซึ่งมีเป้าหมายเพื่อผสาน Kafka เข้ากับ object storage อย่าง S3 เพื่อเพิ่มความยืดหยุ่นและลดต้นทุนในสภาพแวดล้อมคลาวด์
  • บทความนี้จินตนาการถึง ระบบ event log แบบ cloud-native ที่ก้าวข้ามข้อจำกัดของ Kafka แบบเดิม พร้อมเสนอแนวทางปรับปรุงหลากหลายด้าน

ข้อเสนอเรื่องสถาปัตยกรรมแบบไม่มีพาร์ทิชัน

  • เนื่องจาก object storage บนคลาวด์สามารถทำงานได้เสมือนเป็นสตอเรจไม่จำกัด ความจำเป็นของ topic partition จึงลดลง
  • หลายกรณีสิ่งสำคัญมีเพียงลำดับข้อความแบบ global หรือเฉพาะลำดับของข้อความที่มีคีย์เดียวกัน
  • สามารถซ่อนแนวคิดเรื่องพาร์ทิชันจากผู้ใช้และมอบประสบการณ์การใช้งานที่เรียบง่ายขึ้นได้

แนวทางที่ยึดคีย์เป็นศูนย์กลาง

  • เสนอการออกแบบที่ทำให้เข้าถึงและ replay ข้อความทั้งหมดของคีย์ใดคีย์หนึ่ง ได้อย่างรวดเร็ว แทนการสแกนพาร์ทิชัน
  • รองรับสตรีมระดับเอนทิตีนับล้านรายการ ทำให้ปรับจำนวน consumer ได้อย่างยืดหยุ่นตามความต้องการ
  • เมื่อความล้มเหลวถูกแยกในระดับคีย์ ประสิทธิภาพการประมวลผลโดยรวมของระบบก็เพิ่มขึ้น
  • เป็นโครงสร้างที่เหมาะอย่างยิ่งกับ event sourcing หรือ ระบบ actor model

รองรับโครงสร้างลำดับชั้นของท็อปปิก

  • ควรยกระดับบางส่วนของ message payload ให้กลายเป็นตัวระบุท็อปปิกในรูปแบบเส้นทางที่มีโครงสร้าง เช่นเดียวกับระบบอย่าง Solace เพื่อรองรับการ subscribe แบบอิงแพตเทิร์น
  • โบรกเกอร์จะสามารถรองรับการกรอง subscription ได้อย่างมีประสิทธิภาพโดยไม่ต้อง parse ข้อความทั้งหมด

ความสามารถด้านการควบคุมการทำงานพร้อมกัน

  • ปัจจุบัน Kafka ยังไม่มีวิธีป้องกันการชนกันของงานพร้อมกันในขณะเขียนข้อมูล
  • หากรองรับ optimistic locking แยกตามคีย์ ก็จะสามารถตรวจสอบได้ว่าข้อความถูกเขียนหลังจากเห็นสถานะล่าสุดแล้วหรือไม่
  • ซึ่งช่วยป้องกันปัญหา lost update ได้

การรองรับสคีมาที่ฝั่งโบรกเกอร์

  • ปัจจุบัน Kafka ปฏิบัติต่อข้อความเป็นเพียงอาร์เรย์ของไบต์ จึงต้องพึ่งพา external schema registry
  • มีข้อเสนอว่าควรรองรับข้อมูลสคีมาอย่าง AsyncAPI metadata เป็นพื้นฐานในระดับโบรกเกอร์ เพื่อให้เกิด ความสอดคล้องของสคีมา
  • แนวทางนี้ยังช่วยให้เชื่อมต่อกับ open table format อย่าง Apache Iceberg ได้ง่ายขึ้น

ความสามารถในการขยายตัวและโครงสร้างปลั๊กอิน

  • มีข้อเสนอให้ใช้โครงสร้างที่มี ความสามารถในการขยายตัว และ รองรับปลั๊กอิน ได้เหมือน Postgres หรือ Kubernetes
  • ควรทำให้สามารถสร้างตัวกรองหรือการแปลงข้อมูลที่ระดับโบรกเกอร์ได้ง่าย โดยไม่ต้องมี protocol-aware proxy (เช่น Kroxylicious)
  • ฟีเจอร์อย่าง rate limiting, การเข้ารหัสท็อปปิก, และการรองรับแบ็กเอนด์ที่ใช้ตาราง Iceberg ควรถูกทำเป็นปลั๊กอินได้

synchronous commit callback

  • ปัจจุบัน Kafka รับประกันได้เพียง eventual consistency
  • มีข้อเสนอว่าควรมีโครงสร้างที่ทำให้ producer ตรวจสอบได้ทันทีหลังส่งข้อความว่า ข้อมูลอนุพันธ์ที่เกี่ยวข้องถูกอัปเดตแล้วหรือยัง
  • รองรับ read-your-own-writes เพื่อให้ Kafka ถูกใช้เป็น database log ที่แท้จริงได้

ฟีเจอร์ snapshot

  • ปัจจุบัน compaction ของ Kafka จะเก็บไว้เพียงข้อความล่าสุดเท่านั้น ซึ่งใช้ได้ก็ต่อเมื่อข้อความนั้นมีสถานะทั้งหมดอยู่ครบ
  • หากบันทึกเฉพาะการเปลี่ยนแปลง ก็จำเป็นต้อง replay event ทั้งหมดของแต่ละคีย์ ทำให้ใช้เวลามากขึ้น
  • จึงจำเป็นต้องมีฟังก์ชัน logical compaction ที่สรุป event ตามคีย์ให้อยู่ในรูป snapshot

รองรับ multi-tenancy เป็นพื้นฐาน

  • ระบบข้อมูลสมัยใหม่ทุกระบบควรออกแบบโดยคำนึงถึง multi-tenancy เป็นพื้นฐาน
  • ควรทำให้สามารถสร้างสภาพแวดล้อมสำหรับ tenant ใหม่ได้ทันทีและมีต้นทุนต่ำ พร้อมแยกทรัพยากร ความปลอดภัย และการควบคุมการเข้าถึงออกจากกันอย่างชัดเจน

หมายเหตุเพิ่มเติม

  • บางฟีเจอร์มีในระบบอื่นอยู่แล้ว เช่น S2 (high-cardinality stream), Waltz (optimistic locking), และ Apache Pulsar (multi-tenancy)
  • แต่ยังไม่มีระบบโอเพนซอร์สที่รองรับทุกฟีเจอร์ที่เสนอมาเหล่านี้พร้อมกัน
  • บทความนี้เป็นความเห็นส่วนตัวของผู้เขียนที่สังกัด Confluent และไม่ใช่จุดยืนอย่างเป็นทางการ
  • มีการกล่าวด้วยว่า ในเชิงทฤษฎีสถาปัตยกรรมแบบ LSM tree-based น่าจะเป็นตัวเลือกที่มีแนวโน้มมากที่สุด

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kaydash 2025-04-27

เราเรียกสิ่งนั้นว่า Redis อยู่แล้ว
 
GN⁺ 2025-04-26
ความเห็นจาก Hacker News

  • เห็นด้วย คุ้มค่าที่จะแก้ปัญหา head-of-line สำหรับบาง use case

    • แต่ปัจจุบันระบบสตรีมมิงทั้งหมด (หรือวิธีเลี่ยงปัญหา) มีต้นทุน O(n^2) สำหรับการ acknowledge แยกตาม message key
    • ระบบอย่าง Pulsar จึงมักถูกนำมาใช้เพื่อความสามารถนี้
    • ความซับซ้อนนี้อาจไม่ได้โผล่มาทุกวัน แต่ถ้าโผล่มา ก็ต้องรอ
    • หลังจากศึกษาปัญหานี้ร่วมกับเพื่อนร่วมงานมานาน ก็ได้ข้อสรุปว่าจำเป็นต้องเปลี่ยนสถาปัตยกรรมระดับรากฐานเพื่อรองรับการ acknowledge แยกตาม message key แบบที่ขยายได้
    • สถาปัตยกรรมดังกล่าวต้องใช้อินเด็กซ์ที่เรียงลำดับ ซึ่งหมายความว่าต้องจัดการ n message ด้วย O(n log n)
    • เคยอยากเขียนบล็อกเกี่ยวกับเรื่องนี้ แต่ไม่มีเวลา
    • ถ้าคิดจะพึ่งพาการ acknowledge แยกตาม message key ก็ต้องคาดไว้เลยว่าอาจมีการสะดุดหรือล่าช้าเป็นช่วงๆ

  • NATS.io ใช้งานง่ายกว่า Kafka และได้แก้หลายจุดไปแล้ว เช่น การตัดพาร์ทิชันออก การรองรับสตรีมแบบอิงคีย์ และโครงสร้างลำดับชั้นของหัวข้อที่ยืดหยุ่น

  • เส้นทางที่เจอกับ Kafka ก็คล้ายกันเป็นส่วนใหญ่

    • ตอนแรกคิดว่า "โอ้ append-only log ที่ขยายได้ เยี่ยมและเรียบง่าย"
    • แต่พอใช้งานจริงก็จะตระหนักว่ามันซับซ้อนมาก

  • สำหรับบาง use case จะมีประโยชน์มากถ้าสามารถรับประกันได้ว่าเมื่อคำขอสร้างข้อมูลได้รับการยืนยันแล้ว มุมมองข้อมูลอนุพันธ์ก็ได้รับการอัปเดตแล้วเช่นกัน

    • อย่าใช้ Kafka ให้เขียนลง data store ปลายทางโดยตรงแทน
    • แบบนั้นคุณจะรู้ว่าข้อมูลถูก commit แล้ว และจะมีฐานข้อมูลที่สามารถ query ได้

  • เคยตั้งคำถามนี้ไว้เมื่อ 6 ปีก่อน

    • ถ้าเขียนด้วย Rust และใช้ WASM จะเป็นอย่างไร
    • ตลอด 6 ปีที่ผ่านมาได้ลงมือทำสิ่งนี้อยู่
    • และในช่วง 2 ปีที่ผ่านมาได้สร้าง Flink ด้วย Rust และ WASM

  • Kafka บน object storage เหรอ? นั่นจะเพิ่มทั้ง latency และต้นทุน 10 เท่า

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

  • เรื่อง "การตัดพาร์ทิชันออก" และ "สตรีมระดับคีย์"

    • ถ้า storage backend ยังพึ่งพาการแบ่งพาร์ทิชันทางกายภาพอยู่ นี่ก็แทบไม่ต่างจากการเปลี่ยนชื่อพาร์ทิชันเป็นคีย์ และเปลี่ยนชื่อคีย์เป็นอีเวนต์

  • ควรจับตา Northguard

    • นี่คือชื่อโปรเจ็กต์เขียน Kafka ใหม่ของ LinkedIn ซึ่งมีการนำเสนอในมีตอัปด้าน stream processing เมื่อประมาณหนึ่งสัปดาห์ก่อน

  • สงสัยว่าปัญหาของ Apache Kafka จะถูกแก้ได้มากแค่ไหนถ้าเปลี่ยนไปใช้ Apache Pulsar

    • ผมข้ามช่วงเรียนรู้ Kafka ไปแล้วใช้ Pulsar ทันที
    • มันเข้ากับ use case ของเราได้ดี
    • ไม่มีอะไรให้บ่น
    • แต่ก็สงสัยว่าทำไมถึงมีคนใช้น้อยนัก

  • เป็นการทดลองทางความคิดที่มีประโยชน์

    • น่าสังเกตว่าคำตอบที่ชวนสรุปว่าควรแทนที่ Kafka ด้วยของใหม่กลับเงียบมาก
    • จุดแข็งที่สุดของ Kafka คือ ecosystem ที่กว้างและมีประโยชน์ซึ่งสร้างอยู่บนมัน
    • และนั่นก็เป็นจุดอ่อนด้วย
    • ต้องคงการตัดสินใจด้านดีไซน์บางอย่างไว้ ทั้งที่ถ้าเริ่มใหม่ในวันนี้ก็คงไม่ทำแบบนั้น
    • หรือไม่ก็ต้องยอมทิ้ง backward compatibility แล้วสร้าง ecosystem ที่มีอยู่ขึ้นมาใหม่