เลือก Message Broker ให้ถูกตัว: Queue vs Topic vs Log
เจาะลึกความต่างระหว่าง Queue, Topic และ Log สามรูปแบบสถาปัตยกรรม Message Broker ที่นักพัฒนาต้องรู้เพื่อเลือกใช้ให้เหมาะกับระบบ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การเลือก Message Broker ไม่ใช่แค่เรื่องปริมาณทราฟฟิกและราคา
- Queue เหมาะกับงานเบื้องหลังที่ต้องการการันตีการส่งและการจัดการข้อความล้มเหลว
- Topic เหมาะกับการกระจายข้อความแบบ Fan-out ไปยังผู้บริโภคหลายรายพร้อมกัน
- Log เหมาะกับระบบที่ต้องการเก็บประวัติย้อนหลังและเล่นซ้ำข้อความได้
การตัดสินใจเลือกใช้ระบบ Message Broker ส่วนใหญ่มักจบลงด้วยการพูดคุยกันเพียงสิบนาทีแล้วเลือก Kafka ทันที หรือไม่ก็เลือก SQS เพราะราคาถูกและใช้งานง่าย แต่มุมมองเหล่านี้มอง Broker เป็นเพียงเรื่องของอัตราการส่งข้อมูลและต้นทุนเท่านั้น แท้จริงแล้วสิ่งที่กำลังเลือกคือรูปแบบสัญญาทางสถาปัตยกรรม ว่าใครคือเจ้าของข้อความหลังจากส่งมอบแล้ว ใครเป็นผู้ติดตามว่าผู้บริโภคอ่านไปถึงไหนแล้ว และเหตุการณ์ของเมื่อวานนี้ยังคงอยู่ในวันนี้หรือไม่
หากเลือกสัญญาผิดพลาด จะไม่มีการปรับแต่งจูนระบบใดช่วยแก้ไขได้ ทีมงานที่เลือก Queue แล้วภายหลังต้องการให้เซอร์วิสใหม่ดึงข้อมูลย้อนหลัง 30 วัน จะไม่เหลือข้อมูลให้เรียกดูซ้ำได้อีก ในทางกลับกัน ทีมงานที่เลือก Kafka สำหรับงานประมวลผลเบื้องหลังจะต้องมาปวดหัวกับการบริหารจัดการพาร์ทิชัน การปรับสมดุล และปัญหาคอขวดเพื่อแลกกับสิ่งที่ Queue มีให้พร้อมใช้งานตั้งแต่ต้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในด้านรูปแบบการส่งมอบข้อมูลมีความแตกต่างกันอย่างชัดเจน:
- Queue (Competing consumers): ผู้จัดการหนึ่งรายต่อหนึ่งข้อความ โดยข้อความจะถูกลบเมื่อได้รับการยืนยันการรับ
- Topic (Fan-out): ทุกการสมัครรับข้อมูลจะได้รับสำเนาของตัวเอง และข้อความจะถูกลบต่อเมื่อมีการยืนยันการรับในแต่ละสการ์เบอร์ชัน
- Log (Retained stream): ทุกกลุ่มผู้บริโภคจะอ่านสตรีมทั้งหมดอย่างเป็นอิสระ และข้อความจะถูกเก็บรักษาไว้จนกว่าจะหมดอายุการเก็บรักษา ไม่ว่าจะถูกอ่านไปแล้วหรือไม่ก็ตาม
แถวสุดท้ายของตารางเปรียบเทียบมักทำให้หลายทีมประหลาดใจ ในระบบ Queue หากข้อความที่ 7 เกิดความล้มเหลว จะไม่ส่งผลกระทบต่อข้อความที่ 8 แต่ในระบบ Log ตำแหน่งออฟเซ็ตของผู้บริโภคหมายถึงทุกอย่างก่อนหน้านี้เสร็จสมบูรณ์แล้ว ดังนั้นข้อความที่ล้มเหลวซ้ำๆ จะทำให้พาร์ทิชันนั้นหยุดชะงัก เว้นแต่จะสร้างหัวข้อการลองใหม่ขึ้นมาเอง
การเข้าใจสถาปัตยกรรมรากฐานทั้งสามนี้มีความสำคัญอย่างยิ่งต่อการออกแบบระบบขนาดใหญ่ เพราะข้อผิดพลาดจากการเลือกผิดประเภทตั้งแต่วันแรกจะกลายเป็นหนี้ทางเทคนิคที่แก้ไขได้ยากในอนาคต การผสมผสานระบบ เช่น การใช้ Log เป็นกระดูกสันหลังในการบันทึกข้อมูลร่วมกับ Queue ในส่วนปลายทาง จะช่วยให้ระบบมีความยืดหยุ่นและรองรับความล้มเหลวได้ดีขึ้น
รายละเอียดการแมปสามประการที่กำหนดการออกแบบจริงประกอบด้วย:
- SNS และ Service Bus: บน Azure การสมัครรับ Topic คือ Queue ที่มีตัวล็อค จำนวนการส่ง และคิวเก็บข้อความที่ล้มเหลวเป็นของตัวเอง แต่บน AWS จะใช้รูปแบบ SNS ดันข้อมูลไปยัง SQS ต่อผู้บริโภคหนึ่งราย
- EventBridge และ Event Grid: เป็นเราเตอร์ไม่ใช่แบ็คโบล เหมาะสำหรับปฏิกิริยาอีเวนต์บนคลาวด์ แต่ไม่เหมาะกับแบ็คโบลอีเวนต์ภายในองค์กรที่มีปริมาณมากซึ่งต้องการลำดับและความสามารถในการเล่นซ้ำ
- จำนวนพาร์ทิชัน: เป็นการตัดสินใจในการออกแบบไม่ใช่แค่ปุ่มปรับแต่ง พาร์ทิชันของ Kafka เพิ่มได้แต่ลดไม่ได้ ส่วน Event Hubs แบบ Basic หรือ Standard จะมีจำนวนพาร์ทิชันคงที่ตั้งแต่ตอนสร้าง
เมื่อมีหลายบริการต้องการอีเวนต์เดียวกัน ให้เผยแพร่ไปยัง Topic เพียงครั้งเดียวแล้วให้ผู้บริโภคแต่ละรายมี Queue ของตัวเอง เพื่อให้ผู้บริโภคแต่ละรายมีความเป็นอิสระ มีคิวข้อความล้มเหลวแยกกัน และปรับขนาดได้อย่างอิสระ ส่วนระบบ Log ควรเลือกใช้เมื่อความต้องการคือการเก็บรักษาข้อมูล เช่น เมื่อผู้บริโภครายใหม่ต้องอ่านประวัติ หรือระบบประมวลผลสตรีมต้องการสถานะที่มีลำดับตามคีย์
คำตอบสามารถผสมผสานกันได้ รูปแบบการผลิตทั่วไปคือการใช้ Log เป็นแบ็คโบลระบบบันทึกข้อมูล ร่วมกับ Queue ที่ปลายทางสำหรับผู้บริโภคที่ต้องการการลองซ้ำต่อข้อความและคิวข้อความล้มเหลว เพื่อป้องกันไม่ให้ข้อความที่เป็นพิษหนึ่งข้อความทำให้พาร์ทิชันหยุดทำงาน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น