KRaft กับ Cluster

ไอเดียในหนึ่งประโยค

Kafka cluster ต้องมีที่เก็บ metadata ของ cluster ว่า broker ตัวไหน lead partition ไหน, มี topic อะไรบ้าง, ใครอยู่ใน ISR และใน Kafka 4.x งานนี้ทำโดย KRaft ที่เป็น controller quorum แบบ Raft ที่ built-in เข้ามา โดย ZooKeeper ถูกถอดออกหมดแล้ว

ทำไมถึงเปลี่ยน

ตลอดประวัติศาสตร์ส่วนใหญ่ของ Kafka ใช้ ensemble ของ ZooKeeper ภายนอกเก็บ metadata ของ cluster เป็นระบบแยกต่างหากที่ต้อง deploy, secure, tune และทำความเข้าใจ แถมกลายเป็นคอขวดด้าน scalability เมื่อ cluster โตจนมี partition เยอะ KRaft (Kafka Raft) ย้ายการจัดการ metadata เข้ามาไว้ใน Kafka เอง ตั้งแต่ Kafka 4.0 KRaft เป็น mode เดียว ZooKeeper mode ถูกถอดออกทั้งหมด และ flag --zookeeper ของ CLI ก็หายไปแล้ว

metadata ก็เป็น log เหมือนกัน

KRaft เอาปรัชญาของ Kafka เองมาใช้กับการประสานงาน cluster โดยเก็บ metadata เป็น log ที่ replicate ได้ broker กลุ่มหนึ่งทำหน้าที่เป็น controller รวมกันเป็น quorum โดยมีตัวหนึ่งเป็น leader ที่ถูกเลือก ทุกการเปลี่ยน metadata ไม่ว่าจะ create topic, เลือก partition leader ใหม่ หรือ update ISR ล้วนเป็น event ที่ถูก append เข้า metadata log ภายในและ replicate ไปยัง controller ตัวอื่นผ่าน protocol แบบ Raft

ผลลัพธ์คือความ consistent และความเร็ว broker ตาม metadata ทันด้วยวิธีเดียวกับที่ consumer ตามข้อมูลทัน คืออ่าน log จาก offset การ failover ของ leader และการกระจาย metadata เร็วกว่าโมเดล watch สมัย ZooKeeper มาก

flowchart TB
  subgraph quorum["Controller quorum (KRaft)"]
    lead["Active controller (leader)"] -->|replicate metadata log| f1["Controller (follower)"]
    lead -->|replicate metadata log| f2["Controller (follower)"]
  end
  lead -->|metadata updates| brk["Brokers (data plane)"]
  brk --> cli["Clients discover leaders via bootstrap-server"]

KRaft: controller quorum ที่ replicate metadata log

KRaft หมายความว่าอะไรสำหรับคุณในฐานะ developer

ในชีวิตประจำวัน KRaft แทบมองไม่เห็นจากฝั่ง client คุณยังเชื่อมต่อด้วย --bootstrap-server, produce และ consume เหมือนเดิมเป๊ะ ที่เปลี่ยนคือ mental model กับงาน operations

ระบบเดียว ไม่ใช่สอง ไม่มี ZooKeeper ให้ deploy หรือ monitor broker และ controller เป็น process ของ Kafka cluster เล็ก ๆ รวมสองบทบาทไว้ด้วยกันได้เลย
recovery เร็วขึ้น การ failover ของ controller และการกระจาย metadata เร็วขึ้น ทำให้ leadership ของ partition ลงตัวเร็วขึ้นหลัง broker ตาย
default สมัยใหม่ Kafka 4.x ยังปล่อย KIP-848 next-generation consumer rebalance protocol เป็น GA และเสริมความแข็งแรงให้ transaction (KIP-890) ทั้งสองอย่างจะพูดถึงต่อในคอร์สนี้