Apache Kafka Architecture: เจาะลึกโครงสร้างภายในและกลไกการทำงาน

1. Apache Kafka คืออะไร?

Apache Kafka คือแพลตฟอร์มสำหรับรับ จัดเก็บ และส่งต่อข้อมูลเหตุการณ์แบบกระจายศูนย์ โดยออกแบบมาเพื่อรองรับข้อมูลปริมาณมากและการประมวลผลแบบต่อเนื่อง

Kafka ไม่ได้เป็นเพียง Message Queue แต่สามารถทำหน้าที่เป็น Distributed Event Log ซึ่งเก็บข้อมูลไว้ตามนโยบายที่กำหนด และเปิดโอกาสให้ Consumer อ่านข้อมูลย้อนหลังได้ตราบเท่าที่ข้อมูลยังคงอยู่

ตัวอย่างการใช้งาน ได้แก่

ระบบซื้อขายสินค้าออนไลน์
ระบบติดตามธุรกรรมทางการเงิน
ระบบวิเคราะห์ข้อมูลแบบ Real-time
ระบบรวบรวม Log จากเซิร์ฟเวอร์
ระบบ Data Pipeline
ระบบส่งข้อมูลจากฐานข้อมูลไปยัง Data Warehouse
ระบบ Event Streaming สำหรับ AI และ Machine Learning

แนวคิดสำคัญของ Kafka คือการแยกผู้ผลิตข้อมูลออกจากผู้บริโภคข้อมูล โดยมี Kafka Cluster เป็นโครงสร้างพื้นฐานกลางสำหรับรับและจัดเก็บ Event Streams

2. ภาพรวมสถาปัตยกรรม Kafka

สถาปัตยกรรม Kafka ประกอบด้วยองค์ประกอบหลายส่วนที่ทำงานร่วมกัน

DATA PRODUCERS

+-------------------+

| Kafka Producers |

+-------------------+

+-------------------------+

| Kafka Cluster |

| |

| Broker 1 |

| Broker 2 |

| Broker 3 |

| |

| Topics / Partitions |

| Replication / Storage |

+-------------------------+

+-------------------+

| Kafka Consumers |

+-------------------+

+-----------+-----------+

| | |

v v v

Database Analytics AI Pipeline

ในระบบจริง Producer และ Consumer สามารถทำงานบนเครื่องหรือบริการที่แยกจาก Kafka Cluster ได้

ภายใน Cluster นั้น Broker ทำหน้าที่จัดเก็บและให้บริการข้อมูล ขณะที่กลไกควบคุม Cluster ทำหน้าที่จัดการ Metadata และการประสานงานตามสถาปัตยกรรมของ Kafka รุ่นที่ใช้งาน

3. Kafka Broker: โหนดหลักของระบบ

Broker คือเซิร์ฟเวอร์ที่เป็นส่วนหนึ่งของ Kafka Cluster

หน้าที่หลักของ Broker ได้แก่

รับข้อมูลจาก Producer
จัดเก็บ Record ลง Partition
ให้บริการอ่านข้อมูลแก่ Consumer
จัดการ Replica ของ Partition
ประสานงานตามสถานะและ Metadata ของ Cluster

ตัวอย่าง Cluster ที่มี Broker 3 เครื่อง

Kafka Cluster

+------------------+

| Broker 1 |

| Partition 0 |

| Partition 1 |

+------------------+

| Broker 2 |

| Partition 1 |

| Partition 2 |

+------------------+

| Broker 3 |

| Partition 0 |

| Partition 2 |

+------------------+

แผนภาพนี้เป็นตัวอย่างการกระจาย Partition และ Replica โดยไม่ได้ระบุว่าแต่ละชุดเป็น Leader หรือ Follower

การกระจายข้อมูลไปยังหลาย Broker ช่วยให้ระบบสามารถใช้ทรัพยากรหลายเครื่องร่วมกัน และรองรับการทำ Replication ได้

อย่างไรก็ตาม การเพิ่ม Broker ไม่ได้ทำให้ประสิทธิภาพเพิ่มขึ้นโดยอัตโนมัติ เพราะต้องพิจารณาการกระจาย Partition, Network, Disk I/O และภาระของ Producer และ Consumer ด้วย

4. Topic: การจัดหมวดหมู่เหตุการณ์

Topic คือชื่อเชิงตรรกะที่ใช้จัดกลุ่ม Record ซึ่งมีลักษณะหรือวัตถุประสงค์ร่วมกัน

ตัวอย่าง Topic ในระบบอีคอมเมิร์ซ

Topic	ข้อมูลที่จัดเก็บ
orders	เหตุการณ์คำสั่งซื้อ
payments	เหตุการณ์การชำระเงิน
inventory	เหตุการณ์สต็อกสินค้า
shipments	เหตุการณ์การจัดส่ง
user-events	เหตุการณ์จากผู้ใช้งาน

การแยก Topic ช่วยให้สามารถกำหนดนโยบายการเก็บข้อมูลและสิทธิ์การเข้าถึงให้เหมาะกับข้อมูลแต่ละประเภทได้

ตัวอย่างเช่น Topic orders อาจเก็บข้อมูลไว้ 7 วัน ขณะที่ Topic สำหรับเหตุการณ์ทางธุรกิจบางประเภทอาจต้องเก็บไว้นานกว่านั้น โดยขึ้นอยู่กับข้อกำหนดของระบบ

ทั้งนี้ Retention ของ Kafka ไม่ใช่กลไกทดแทนการจัดเก็บข้อมูลถาวรหรือข้อกำหนดด้านการเก็บรักษาข้อมูลทางกฎหมายทั้งหมด

5. Partition: หน่วยจัดเก็บข้อมูลภายใน Topic

Topic สามารถแบ่งออกเป็นหลาย Partition ได้

ตัวอย่าง Topic orders ที่มี 3 Partition

Topic: orders

Partition 0

Offset 0 -> Order A

Offset 1 -> Order D

Offset 2 -> Order G

Partition 1

Offset 0 -> Order B

Offset 1 -> Order E

Offset 2 -> Order H

Partition 2

Offset 0 -> Order C

Offset 1 -> Order F

Offset 2 -> Order I

แต่ละ Partition เป็น Log ที่มีลำดับของตัวเอง

ประโยชน์ของ Partition ได้แก่

กระจายข้อมูลไปยังหลาย Broker
รองรับการอ่านและเขียนแบบขนาน
เพิ่มขีดความสามารถในการประมวลผล
แบ่งขอบเขตของการเรียงลำดับข้อมูล

Kafka รับประกันลำดับ Record ภายใน Partition แต่ไม่รับประกันลำดับรวมระหว่างทุก Partition

หากต้องการรักษาลำดับของเหตุการณ์คำสั่งซื้อเดียวกัน อาจกำหนด order_id เป็น Partition Key เพื่อให้เหตุการณ์ของคำสั่งซื้อเดียวกันถูกส่งไปยัง Partition เดียวกันตามกลยุทธ์การเลือก Partition

ข้อควรระวังคือ การเพิ่มจำนวน Partition อาจเปลี่ยนการกระจาย Key สำหรับ Record ใหม่ จึงควรวางแผนการขยายระบบโดยคำนึงถึงข้อกำหนดด้าน Ordering ด้วย

6. Producer: ระบบที่ส่งข้อมูลเข้าสู่ Kafka

Producer เป็น Client ที่ส่ง Record ไปยัง Topic

ตัวอย่างข้อมูลคำสั่งซื้อ:

{

"event_id": "evt-1001",

"event_type": "OrderCreated",

"order_id": "ORD-1001",

"amount": 1500,

"currency": "THB"

}

เมื่อ Producer ส่ง Record ไปยัง Kafka จะมีกระบวนการสำคัญ ได้แก่

เลือก Topic ปลายทาง
กำหนด Key และ Value
เลือก Partition ตามกลยุทธ์ที่ใช้
ส่ง Record ไปยัง Broker ที่เป็น Leader ของ Partition
รับผลการยืนยันตามการตั้งค่า Producer

Producer สามารถส่งข้อมูลเป็นชุด หรือ Batching เพื่อช่วยลดต้นทุนการส่งข้อมูลและเพิ่ม Throughput ได้

6.1 Producer Acknowledgment

การตั้งค่า acks มีผลต่อการยืนยันการเขียนข้อมูล

ค่า	ความหมายโดยสรุป
acks=0	Producer ไม่รอการยืนยันจาก Broker
acks=1	รอการยืนยันจาก Leader
acks=all	รอการยืนยันตามเงื่อนไขของ Replica ที่กำหนด

acks=all ไม่ได้หมายความว่าต้องรอทุก Replica ที่มีอยู่เสมอ แต่ขึ้นอยู่กับ In-Sync Replicas และการตั้งค่าที่เกี่ยวข้อง

หากต้องการความทนทานต่อความล้มเหลว ควรพิจารณา acks, min.insync.replicas, Replication Factor และนโยบาย Retry ร่วมกัน

7. Consumer: ระบบที่อ่านข้อมูลจาก Kafka

Consumer เป็น Client ที่อ่าน Record จาก Topic แล้วนำไปประมวลผล

ตัวอย่าง:

Kafka Topic: orders

Consumer

Validate Event

Process Business

Save to Database

Consumer สามารถอ่านข้อมูลเพื่ออัปเดตฐานข้อมูล ส่งการแจ้งเตือน คำนวณข้อมูลวิเคราะห์ หรือส่งต่อไปยังระบบอื่นได้

สิ่งสำคัญคือ Kafka ไม่ได้กำหนดให้ Consumer ต้องลบ Record หลังอ่านเสร็จ ข้อมูลจะยังคงอยู่ตามนโยบาย Retention หรือ Compaction ที่กำหนด

7.1 Consumer Group

Consumer Group ช่วยให้ Consumer หลายตัวแบ่งกันอ่าน Partition ของ Topic เดียวกัน

ตัวอย่าง:

Topic: orders

+-- Partition 0 ---> Consumer A

+-- Partition 1 ---> Consumer B

+-- Partition 2 ---> Consumer C

ภายใน Consumer Group เดียวกัน แต่ละ Partition จะถูกจัดสรรให้ Consumer ได้ไม่เกินหนึ่งตัวในช่วงเวลาที่ Assignment นั้นมีผล

หากมี 3 Partition และ 5 Consumers ใน Group เดียวกัน จะมี Consumer บางตัวที่ไม่ได้รับ Partition ในช่วงนั้น

อย่างไรก็ตาม สามารถสร้าง Consumer Group หลายกลุ่มเพื่อให้ระบบคนละชุดอ่าน Topic เดียวกันได้อย่างอิสระ เช่น กลุ่มหนึ่งประมวลผลคำสั่งซื้อ อีกกลุ่มหนึ่งวิเคราะห์ยอดขาย

8. Kafka Offset: ติดตามตำแหน่งการอ่านข้อมูล

Offset คือหมายเลขตำแหน่งของ Record ภายใน Partition

ตัวอย่าง:

Partition 0

Offset 0 -> OrderCreated

Offset 1 -> PaymentRequested

Offset 2 -> PaymentCompleted

Offset 3 -> OrderShipped

Consumer สามารถบันทึก Offset ที่อ่านไปถึง เพื่อให้กลับมาอ่านข้อมูลต่อได้หลังหยุดทำงาน

อย่างไรก็ตาม ต้องแยกระหว่างตำแหน่งที่อ่านข้อมูลแล้วกับสถานะที่ประมวลผลธุรกิจสำเร็จแล้ว

หาก Consumer Commit Offset ก่อนบันทึกผลลัพธ์ลงฐานข้อมูลสำเร็จ อาจเกิดกรณีที่ข้อมูลถูกข้ามเมื่อกลับมาทำงานใหม่

ในทางกลับกัน หากบันทึกผลลัพธ์สำเร็จแล้วแต่ยังไม่ได้ Commit Offset ก็อาจประมวลผลเหตุการณ์เดิมซ้ำได้

แนวทางแก้ไข ได้แก่

ใช้ Idempotency Key
ออกแบบการประมวลผลซ้ำให้ปลอดภัย
จัดลำดับการ Commit Offset ให้เหมาะสม
ใช้ Transaction หรือ Outbox Pattern เมื่อจำเป็น

9. Replication: การทำสำเนา Partition

Kafka สามารถสร้าง Replica ของ Partition เพื่อเพิ่มความทนทานต่อความล้มเหลวได้

ตัวอย่าง:

Partition 0

Broker 1: Leader

Broker 2: Follower

Broker 3: Follower

Leader รับผิดชอบการอ่านและเขียนตามกลไกของ Kafka ส่วน Follower จะติดตามข้อมูลจาก Leader

หาก Leader ล้มเหลว Kafka สามารถเลือก Leader ใหม่จาก Replica ที่มีสิทธิ์ตามเงื่อนไขของระบบได้

9.1 Replication Factor

Replication Factor	จำนวนสำเนา
1	1 ชุด
2	2 ชุด
3	3 ชุด

การใช้ Replication Factor เท่ากับ 3 หมายถึงมี Replica 3 ชุดต่อ Partition แต่ไม่ได้หมายความว่าทุกชุดต้องอยู่คนละเครื่องหรือคนละ Availability Zone โดยอัตโนมัติ

จึงควรจัดวาง Replica ให้เหมาะสมกับรูปแบบความล้มเหลวที่ต้องการรองรับ

10. Controller และ KRaft

Kafka ต้องมีกลไกควบคุม Metadata และสถานะของ Cluster เช่น การจัดการ Partition, Leader Election และการเปลี่ยนแปลงโครงสร้างระบบ

Kafka รุ่นใหม่ใช้สถาปัตยกรรม KRaft (Kafka Raft) ซึ่งใช้กลุ่ม Controller ทำงานร่วมกันเพื่อจัดการ Metadata โดยไม่ต้องพึ่ง ZooKeeper แบบสถาปัตยกรรมรุ่นเก่า

องค์ประกอบหลัก ได้แก่

Broker: ให้บริการรับส่งและจัดเก็บ Record
Controller: ดูแลการเปลี่ยนแปลง Metadata และการประสานงานของ Cluster
KRaft Quorum: กลุ่ม Controller ที่ทำงานร่วมกันเพื่อจัดการ Metadata ผ่านกลไกฉันทามติ

ใน Production สามารถกำหนดบทบาท Broker และ Controller ให้เหมาะกับขนาดระบบและความต้องการด้านความพร้อมใช้งาน

การออกแบบต้องคำนึงถึงจำนวน Controller การกระจายโหนด และการรับมือกับความล้มเหลวของ Quorum

11. Kafka Storage Engine: ข้อมูลถูกจัดเก็บอย่างไร?

Kafka จัดเก็บ Record ของแต่ละ Partition เป็น Log โดยแบ่งข้อมูลออกเป็น Segment เพื่อให้บริหารจัดการข้อมูลขนาดใหญ่ได้สะดวกขึ้น

โครงสร้างเชิงแนวคิด:

Kafka Partition

+------------------+

| Segment 0 |

| Older Records |

+------------------+

| Segment 1 |

| Recent Records |

+------------------+

| Active Segment |

| New Records |

+------------------+

เมื่อมีข้อมูลใหม่เข้ามา Record จะถูกเพิ่มเข้า Log ตามกลไกของ Partition และ Segment

การแบ่ง Segment ช่วยให้ Kafka จัดการ Retention, Index และการลบข้อมูลเก่าได้มีประสิทธิภาพมากขึ้น

Kafka ยังใช้กลไก Index เพื่อช่วยค้นหาตำแหน่งของ Record โดยไม่จำเป็นต้องอ่านข้อมูลทั้งหมดตั้งแต่ต้นทุกครั้ง

ในระบบจริง รายละเอียดการจัดเก็บขึ้นอยู่กับเวอร์ชัน Kafka และการตั้งค่าที่ใช้งาน

12. Kafka Data Flow: ตั้งแต่ Producer ถึง Consumer

ตัวอย่างการไหลของข้อมูลคำสั่งซื้อ

ขั้นตอนที่ 1: ลูกค้าสั่งซื้อสินค้า

Order Service สร้างเหตุการณ์ OrderCreated

ขั้นตอนที่ 2: Producer ส่งเหตุการณ์

Producer ส่ง Record ไปยัง Topic orders

ขั้นตอนที่ 3: Kafka จัดเก็บข้อมูล

Broker ที่เป็น Leader ของ Partition รับ Record และจัดเก็บตามกลไกของ Kafka

ขั้นตอนที่ 4: Replica ติดตามข้อมูล

Follower Replica ดึงหรือรับข้อมูลตามกลไก Replication ของ Kafka

ขั้นตอนที่ 5: Consumer อ่านข้อมูล

Consumer Group อ่าน Record ตาม Offset ของแต่ละ Partition

ขั้นตอนที่ 6: ระบบปลายทางประมวลผล

Consumer นำเหตุการณ์ไปอัปเดตฐานข้อมูลหรือดำเนินการอื่นตามหน้าที่

ขั้นตอนที่ 7: Consumer ติดตามความคืบหน้า

ระบบจัดการ Offset เพื่อให้สามารถกลับมาอ่านข้อมูลต่อหรือจัดการการประมวลผลซ้ำได้อย่างเหมาะสม

13. Kafka กับระบบ Data Engineering

Kafka สามารถทำหน้าที่เป็นศูนย์กลางของ Data Pipeline ที่รับข้อมูลจากหลายแหล่งและส่งต่อไปยังระบบประมวลผล

ตัวอย่างสถาปัตยกรรม:

Database / API / Application

Data Producers

Apache Kafka

+-----+------+

| |

v v

Apache Flink Kafka Consumers

| |

v v

Real-Time DB Data Storage

Analytics / Dashboard

บทบาทของเทคโนโลยีในสถาปัตยกรรมนี้แตกต่างกัน

Kafka รับและกระจาย Event Streams
Flink ประมวลผลข้อมูลแบบ Stream
Consumer Services ทำงานตามเหตุการณ์
Database และ Data Storage เก็บผลลัพธ์ตามวัตถุประสงค์
Analytics และ Dashboard ใช้ข้อมูลที่ผ่านการประมวลผลแล้ว

การเลือกใช้เครื่องมือควรพิจารณาจาก Latency, Throughput, ความซับซ้อนของการประมวลผล และต้นทุนในการดูแลระบบ

14. การออกแบบ Kafka สำหรับ Production

ก่อนนำ Kafka ไปใช้งานจริง ควรวางแผนเรื่องสำคัญดังต่อไปนี้

ประเด็น	สิ่งที่ต้องพิจารณา
Partitioning	จำนวน Partition และการกระจาย Key
Replication	จำนวน Replica และการจัดวางโหนด
Durability	acks, min.insync.replicas และเงื่อนไขการยืนยัน
Consumer Processing	Offset, Retry และ Idempotency
Retention	ระยะเวลาเก็บข้อมูลและพื้นที่จัดเก็บ
Schema	ความเข้ากันได้ของรูปแบบข้อมูล
Security	Authentication, Authorization และ Encryption
Monitoring	Throughput, Latency, Consumer Lag และ Disk Usage
Recovery	การรับมือกับ Broker และระบบปลายทางที่ล้มเหลว

การตั้งค่าเหล่านี้ต้องพิจารณาร่วมกัน เพราะการปรับปรุงด้านหนึ่งอาจส่งผลต่อ Latency, Throughput, Durability หรือค่าใช้จ่ายของระบบในอีกด้านหนึ่ง

15. สรุป

Apache Kafka เป็นแพลตฟอร์ม Distributed Event Streaming ที่นำแนวคิด Distributed Log มาใช้จัดเก็บและกระจายข้อมูล

องค์ประกอบสำคัญ ได้แก่ Broker, Topic, Partition, Producer, Consumer, Offset, Replication และ Controller

การเข้าใจองค์ประกอบเหล่านี้ช่วยให้สามารถออกแบบระบบ Event-Driven Architecture, Data Pipeline และ Real-Time Analytics ได้อย่างมีประสิทธิภาพมากขึ้น

อย่างไรก็ตาม การสร้างระบบ Production ที่เชื่อถือได้ไม่ได้ขึ้นอยู่กับ Kafka เพียงอย่างเดียว แต่ยังต้องออกแบบการจัดการธุรกรรม การประมวลผลซ้ำ ความปลอดภัย การ Monitoring และการกู้คืนระบบ

ค..ตนดูระบบคอม

ค้นหาบล็อกนี้

Apache Kafka Architecture: เจาะลึกโครงสร้างภายในและกลไกการทำงาน

ป้ายกำกับ

ความคิดเห็น

แสดงความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

อะไรคือ NPU (Neural Processing Unit) มีความสำคัญอย่างไร แนวคิดมาจากไหน

TomCat สำหรับติดตั้ง แก้ไข คอนฟิก ใช้งาน JSP