Rabbit MQ คืออะไร

Rabbit MQ เป็น Software จำพวก Message Broker ซึ่งรับ Message จากระบบหนึ่งแล้วส่ง Message ต่อไปยังอีกระบบหนึ่ง นึกภาพคล้ายกับที่ทำการไปรษณีย์ (Post Office) คือผู้ส่งจดหมายซึ่งระบุชื่อและที่อยู่ของผู้รับ นำจดหมายที่ต้องการส่งไปยังตู้ไปรษณีย์ จากนั้นบุรุษไปรษณีย์ (Postman) จะทำการนำจดหมายนั้นส่งไปถึงผู้รับ

Rabbit MQ เป็นเสมือนทั้งตู้ไปรษณีย์ ที่ทำการไปรษณีย์ และบุรุษไปรษณีย์ เพียงแต่ Rabbit MQ ไม่ได้ทำงานกับจดหมายกระดาษ เพราะเป็นข้อมูลอิเล็กทรอนิกส์

Credit: ภาพจาก https://www.youtube.com/watch?v=dTx4MONz9CQ

Rabbit MQ ใช้ทำอะไร

การมีระบบจัดการด้าน Messaging ช่วยให้ Software Application ต่าง ๆ สามารถ Connect หากันได้และสามารถ Scale ได้ การ Connect นี้ก็มีทั้ง Application หลาย ๆ ตัว Connect ถึงกันได้ (ซึ่งแต่ละชิ้นก็เป็นองค์ประกอบของ Application ที่ใหญ่กว่า) หรือ Application connect ไปหาอุปกรณ์ต่าง ๆ หรือข้อมูลต่าง ๆ

เราสามารถนำแนวคิดของ Message Queue มาใช้จัดการเรื่อง data delivery, Non-blocking operation หรือ Push Notification รวมทั้งสามารถใช้ในงานแบบ Publish/Subscribe, Asynchronous processing, Work queues

Rabbit MQ เป็น Message Broker ซึ่งเป็นตัวกลางของระบบ Messaging โดยช่วยให้ Application ของเรามี platform ร่วมกันสำหรับส่งและรับ Message นอกจากนี้ยังเป็นที่จัดเก็บ Message ที่ปลอดภัยจนกว่าผู้รับจะได้รับ Message

 

1. Data Delivery

บางครั้ง หลายระบบงานที่ทำงานร่วมกัน อาจมีการส่งข้อมูลปริมาณมาก ๆ ระหว่างกัน ซึ่งไม่สามารถทำงานแบบ Real-time ได้เสมอไป ในบางองค์กรใช้วิธีการ Batch โดยตั้ง Schedule ให้ระบบสร้างไฟล์ Batch ออกมา แล้วส่งให้อีกระบบหนึ่งตาม Schedule ที่ตกลงกัน (ตัวอย่างเช่นระบบงาน Human Resource ส่งรายชื่อพนักงานใหม่ทุกสิ้นวันผ่าน Batch File ซึ่งส่งกระจายให้กับระบบงานอื่น ๆ เพื่อไป Create user account ให้พนักงานใช้) หากทำ Message Broker มาช่วยจัดการ จะลดการทำงานแบบ Batch นี้ออกไปได้

 

 

2. Non-Blocking Operation และ Asynchronous Operation

บางระบบงานที่ประกอบด้วยหลาย Process ทำงานร่วมกันนั้น มักจะมีการเรียกใช้งานระหว่างกัน ซึ่งหลาย ๆ ครั้งเกิดปัญหา Blocking ได้

Credit: ภาพจาก: https://www.researchgate.net/figure/Blocking-and-non-blocking-operation-calls_fig18_312384750

 

Credit: ภาพจาก https://www.koyeb.com/blog/introduction-to-synchronous-and-asynchronous-processing

 

รูปด้านซ้ายแสดงการทำงานที่เกิด Blocking operations คือ Process A ส่งงานให้ Process B ทำงาน ระหว่าง B ทำงานอยู่ A จะต้องรอจน B ทำเสร็จ แล้ว A จึงจะทำงานต่อได้ (เรียกว่าเป็น Synchronous) จะเห็นได้ว่าระบบจะเสียทรัพยากรไปเปล่าประโยชน์ในช่วงที่ A รอ B เพราะ A ไม่ได้ทำงานช่วงนั้นเลย อีกทั้งหาก B ทำงานช้า จะทำให้ A ทำงานช้าไปด้วย และภาพรวมของระบบก็จะทำงานได้ Throughput น้อยลง

ส่วนรูปด้านขวาแสดงการทำงานแบบ Non-blocking operations (เป็นแบบ Asynchronous) คือ Process A ส่งงานให้ Process B ทำงาน ระหว่างที่ B ทำงานอยู่ A ก็สามารถทำงานอื่นของตนต่อได้ เมื่อ B ทำเสร็จก็จะแจ้งกลับมาที่ A จะเห็นได้ว่าระบบใช้ทรัพยากรคุ้มค่ากว่า

เราสามารถนำ Software จำพวก Message Broker มาช่วยปรับปรุงระบบในลักษณะนี้ได้ โดยให้ Message Broker รับคำสั่งจาก Process A แล้วให้ Broker ส่งให้ Process B เมื่อ A ส่งให้ Broker แล้ว A สามารถทำงานอื่นต่อได้โดยไม่ต้องรอ (แต่มีเงื่อนไขว่างานอื่นที่ A หยิบมาทำระหว่างนั้น ไม่จำเป็นต้องใช้ผลลัพธ์จาก B)

 

3. Push Notification

Push Notification เป็นการส่งข้อความจากระบบไปยังอุปกรณ์หรือเครื่องคอมพิวเตอร์ของ User เพื่อแจ้งข้อมูล ข่าวสาร หรือร้องขอให้ทำ Action บางอย่างกลับไป ในระบบที่มีปริมาณการใช้งาน Notification สูง ๆ อาจะเกิด Blocking ขึ้นในจุดนี้ได้ ดังนั้นการนำ Message Broker มาช่วยจัดการส่วนนี้ จะลด Blocking Operation จากการที่ระบบต้นทางต้องรอ Push Server ทำงาน

 

4. Publish/Subscribe

Credit: ภาพจาก https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

ในเชิง Software Architecture นั้น Publish/Subscriber จัดว่าเป็นรูปแบบหนึ่งของ Messaging ซึ่งผู้ส่ง Message (เรียกว่า Publisher) จะไม่ถูกกำหนดให้ส่ง Message ให้หาผู้รับ (Subscriber) โดยตรง แต่ละจัดแบ่งหมวดหมู่ของ Published Message โดยมักจะไม่สนใจว่า Subscriber คือใคร ส่วน Subscriber จะรับ Message เฉพาะที่ตนเองสนใจเท่านั้น โดยไม่ต้องรับรู้ว่ามาจาก Publisher รายใด ดังนั้น Message Broker จึงทำหน้าที่เป็นตัวกลางอย่างดีในการจัดการ Message เหล่านี้ ระหว่าง Publisher และ Subscriber โดย Publisher ทำการ Publish Message ไปยัง Input Channel ของ Broker และ Subscriber จะคอยรับ Message จาก Output Channel ของ Broker

 

Rabbit MQ เหมาะกับงานลักษณะใด

  • Data Delivery
  • Non-blocking operation
  • Push notification
  • Publish/Subscribe
  • Asynchronous Processing
  • Work Queues

 

Case Study

1. การส่งข้อความแจ้งเตือนเมื่อมีการ Login เข้าใช้งานระบบ

ระบบงานหนึ่งมี Requirement ว่า เมื่อ User ได้ Login ผ่านแล้ว ระบบจะต้องส่ง Email แจ้งไปยังผู้ใช้งานว่ามีการ Login ซึ่งจะช่วย User ในกรณีมีผู้อื่นแอบนำ Credential ของตนเองไปแอบใช้ การส่งแจ้งเตือนจะทำให้ User ตัวจริงทราบว่ามีการเข้าใช้งาน และดำเนินการระงับการใช้งานได้ทัน ก่อนจะเกิดความเสียหายได้

มีเหตุการณ์วันหนึ่งว่า Mail Gateway ซึ่งเป็นตัวกลางในการส่ง Email เกิดขัดข้อง ทำให้ระบบงานนี้ไม่สามารถเชื่อมต่อได้ ผลก็คือการ Login จะช้ามาก เพราะรอการเชื่อมต่อกับ Mail Gateway แล้วยิ่งมี User เข้า Login อย่างต่อเนื่องตลอดทั้งวัน ก็ยิ่งเกิด Bottleneck ให้การเข้าใช้งาน ทั้ง ๆ ที่ตัวระบบนี้เองไม่ได้มีปัญหาภายใน

การทำงานลักษณะนี้ สามารถปรับปรุงได้ โดยให้โปรแกรมส่วนหลักทำการ Publish ข้อมูลสำหรับการส่ง Email Notification ไปยัง Message Queue แล้วให้ Consumer ดำเนินการส่งอีเมลผ่าน Mail Gateway ส่วนโปรแกรมส่วนหลักก็ Execute ต่อไปโดยไม่ต้องรอผลการส่ง Email

2. การ Generate Report ผ่านหน้า Web Application

ระบบงานหนึ่งมี Requirement ให้สร้าง Export ข้อมูลธุรกรรมย้อนหลังจำนวนมาก และข้อมูลแต่ละ Row ก็มี Column จำนวนหลายร้อย Column จึงใช้เวลานานมากในการสร้างไฟล์ หากเราออกแบบให้ทำงานแบบ Synchronous ก็จะเกิด Waiting Time ยาวนาน และ User ต้องรอจนกว่าจะเสร็จ หน้าจอ ขึ้น pop-up ให้ Save แล้วกด Save File ได้ จึงจะไปทำงานหน้าจออื่นได้

การออกแบบ จึงเลือกใช้ Message Broker เข้ามาช่วย โดยโปรแกรมส่วนหลัก (Publisher) ทำการ Publish คำสั่ง Export ไปยัง MQ แล้ว Update สถานะของ Job นี้เป็น In Progress  จากนั้น Consumer Process ดำเนินการ Export ข้อมูลและ Save File ลงใน Disk จากนั้นจึง Update สถานะของ Job เป็น Finish เมื่อ User เห็นสถานะนี้แล้วจึงกด Link เพื่อ Download File นั้นไปใช้งานในช่วงเวลาหลังจากที่ Publish คำสั่งเข้า MQ นั้น ไปจนถึง Consumer ทำงานเสร็จนั้น ทาง User ไม่จำเป็นรออยู่ที่หน้าจอเดิม สามารถไปหน้าจออื่นเพื่อทำงานอื่นได้

3. การยืนยันตัวตนใน NDID Platform

ปัจจุบัน Mobile Banking Application ของสถาบันการเงินต่าง ๆ มี Feature เรื่อง NDID Service ซึ่งเป็นบริการยืนยันตัวตนและขอข้อมูลส่วนบุคคลระหว่างสถาบันการเงิน โดยลูกค้าของธนาคารสามารถขอให้ Application สถาบันการเงินที่ตนติดต่ออยู่ เชื่อมต่อไปยังระบบของอีกสถาบันการเงิน เพื่อให้ทำการยืนยันตัวตนให้ ซึ่งการยืนยันตัวตนนี้อาจใช้เวลานาน เพราะมีทั้งการตรวจสอบสิทธิ์ด้วย PIN หรือ One-Time Password, การตรวจทานข้อมูลส่วนตัว, การทำ Face Recognition ดังนั้นจึงมีการนำ MQ เข้ามาใช้ในการรับส่งข้อมูลการขอยืนยันตัวตนระหว่างสถาบันการเงินด้วยกัน

Credit: ภาพจาก NDID Platform

 

สำหรับในส่วน Introduction จะขอจบเพียงเท่านี้ ในตอนถัดไปจะกล่าวถึงการใช้งาน Rabbit MQ ในรูปแบบต่าง ๆ ครับ

เรื่องของ NDID สามารถอ่านได้ที่ https://www.stream.co.th/why-ndid/

หากสนใจโซลูชั่นด้านดิจิทัล สามารถติดต่อเราได้ที่อีเมล Marketing@stream.co.th หรือโทร. 02-679-2233 นะครับ

 

เรียบเรียงโดย Siripod Surabotsophon

Post Views: 11,795