Blog Archives

สวัสดีครับ ในตอนที่แล้ว เราได้แนะนำ Rabbit MQ กันไปแล้ว สำหรับตอนที่ 2 นี้ เราจะเจาะลึกให้ละเอียดขึ้นอีกว่า องค์ประกอบของ Rabbit MQ มีอะไรบ้าง

Rabbit MQ มีองค์ประกอบอย่างไร

ภาพจาก: Introduction to RabbitMQ, Randhir Kumar, Software Consultant, Knoldus Inc.

องค์ประกอบของ Rabbit MQ มีดังนี้

• Producer : โปรแกรมที่เป็นผู้ส่ง Message (Publish Message) โดยที่ Message อาจจะเป็นงานที่ต้องการส่งให้ระบบอื่นไปทำ หรืออาจเป็นการแจ้งข้อมูลข่าวสารให้ระบบอื่น ๆ รับทราบ
• Exchange : ทำหน้าที่รับ Message และนำส่ง Message ไปให้ Queue ต่าง ๆ โดยพิจารณาจาก Routing Key ซึ่งเป็น Attribute ในแต่ละ Message
• Binding : คือ การกำหนด “Link”  ว่า Queue ต่าง ๆ จะรับ Message ใดจาก Exchange โดย Binding จะเกี่ยวข้องกับ Routing Key และ Header
• Queue : ทำหน้าที่คล้ายตู้จดหมาย (Post Box) ซึ่งอยู่ภายใน Rabbit MQ  เป็นที่เก็บ Message ทุกอย่างที่ผ่าน Rabbit MQ เข้ามาและออกไปยัง application โดยอาศัย Memory และ Disk ของเครื่อง Host ทำหน้าที่เป็น Buffer สำหรับเก็บ Message ดังนั้นปริมาณ Message ที่เก็บได้ ก็จะขึ้นกับขนาดของ Memory และ Disk ที่มี ในการใช้งาน Queue นั้น สามารถให้หลาย ๆ Producer ส่ง Message เข้าไปที่ Queue เดียวกันได้ และสามารถให้หลาย ๆ Consumer รับ Message จาก Queue เดียวกันได้เช่นกัน
• Consumer : โปรแกรมที่เป็นผู้รอรับ Message (Consume Message) โดยอาจจะเป็นระบบที่รับงานจาก Producer มาดำเนินการ หรือรับข้อมูลข่าวสารมาอัพเดตในระบบ หรือส่งต่อให้ระบบอื่น

ประเภทของ Exchange

Rabbit MQ รองรับ Exchange ได้หลายประเภท เช่น Direct, Fanout, Topic, Header เป็นต้น แต่ละประเภทจะมีวิธีต่างกันในการกำหนด Binding เพื่อเชื่อมโยงกับ Queue

ภาพจาก: https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html

1. Direct Exchange

Direct Exchange จะส่ง Message โดยอาศัย Routing Key เป็นตัวกำหนดว่า Message จะถูกส่งอย่างเจาะจงไปยัง Queue ที่มี Binding Key ตรงกับ Routing Key เท่านั้น

ตัวอย่างเช่น ระบบงานเพื่อประมวลผล pdf_events ประกอบด้วย Direct Exchange 1 ตัว และ Queue 2 ตัว

• Queue A สำหรับทำงาน pdf create และมี routing key คือ pdf_create
• Queue B สำหรับทำงาน pdf log และมี routing key คือ pdf_log

การทำงานเริ่มจาก Exchange ได้รับ Message จาก Producer เข้ามา Exchange จะตรวจสอบ Binding key ที่แนบมากับ Message ถ้า Routing key เป็น pdf_create ก็จะส่ง Message ไปยัง Queue A (เนื่องจากมี Binding key = pdf_create ตรงกัน) หรือถ้า Routing key เป็น pdf_log ก็จะส่งไปยัง Queue B (เนื่องจากมี Binding key = pdf_log ตรงกัน)

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

2. Fanout Exchange

Fanout Exchange ทำการส่ง Message ไปยังทุก Queue ที่ผูกกับ Exchange นั้น โดยไม่สนใจ Routing Key วิธีการนี้เหมาะสำหรับงานลักษณะ Broadcasting

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

ตัวอย่างการใช้งาน #1

เมื่อระบบประมวลผลข่าวกีฬา (Sports News)  ได้บันทึกข้อมูลข่าวกีฬาใหม่แล้ว ทำการ Publish Message นี้ (ซึ่งมีรายละเอียดของข่าว) ลงใน Fanout Exchange  จากนั้น Fanout Exchange ทำการ Broadcast ไปยังระบบช่องทางการรายงานข่าวต่างๆ เช่น ช่องทาง Web, Mobile, TV, Radio ซึ่งแต่ละช่องทางสามารถมีวิธีการนำข้อมูลรายละเอียดของข่าวไปใช้งานแตกต่างกัน

ตัวอย่างการใช้งาน #2

เมื่อระบบงาน HR ได้บันทึกข้อมูลพนักงานใหม่แล้ว ทำการ Publish Message ลงใน Fanout Exchange ซึ่ง Messageประกอบด้วยข้อมูลของพนักงานใหม่ จากนั้น Fanout Exchange ทำการ Broadcast ไปยังระบบงานอื่นที่เกี่ยวข้อง เช่น ระบบการจองคอมพิวเตอร์ เพื่อจองเครื่องให้กับพนักงานใหม่, ระบบการพิมพ์นามบัตร เพื่อจัดพิมพ์นามบัตรให้กับพนักงานใหม่, ระบบการฝึกอบรม เพื่อจองวันปฐมนิเทศพนักงานใหม่ เป็นต้น ระบบงานเหล่านี้สามารถรับ Message ไปประมวลผลได้ทันที นอกจากนี้ระบบงาน HR ซึ่งเป็น Publisher ก็ทำงานแบบ Asynchronous คือสามารถทำงานอื่นของตนเองต่อได้ โดยไม่ต้องรอผลลัพธ์จากระบบงานอื่นๆ กลับมาก่อน

3. Topic Exchange

Topic Exchange เหมาะสำหรับงานลักษณะ Multicast เพื่อส่ง Message ให้กับ Consumer บางส่วน โดยอาศัยการ Match Pattern ของ Routing Key กับ Binding Key โดย Routing Key มีลักษณะเป็นคำคั่นด้วยจุด เช่น agreements.eu.stockholm

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

ตัวอย่างเช่น ระบบงานสำหรับประมวลผล agreements  ใช้ Topic Exchange และ Queue 3 ตัว ดังนี้

หมายเหตุ:

• เครื่องหมาย * หมายถึงตำแหน่งนี้ต้องมีคำปรากฏ 1 คำ
  • เช่น binding key = “agreements.*.*.b.*” หมายถึง คำที่หนึ่งเป็น agreements, คำที่สี่เป็น b, ส่วนคำที่สอง สาม และห้า เป็นคำอะไรก็ได้แต่ต้องมี
• เครื่องหมาย # หมายถึงตำแหน่งนี้จะมีคำใดๆปรากฏหรือไม่มีเลยก็ได้
  • เช่น binding key = “agreements.eu.berlin.#” หมายถึง คำที่หนึ่งเป็น agreements, คำที่สองเป็น eu, คำที่สามเป็น berlin, ส่วนคำที่สี่จะมีหรือไม่มีก็ได้

Example Scenario

4. Header Exchange

Header Exchange อาศัยข้อมูลใน Header ในการกำหนดเส้นทางการส่ง Message โดยไม่ได้อาศัย Routing Key

ภาพจาก: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

ตัวอย่างเช่น ระบบงานสำหรับประมวลผล agreements  ใช้ Header Exchange และ Queue 3 ตัว

X-match = any หมายถึง ต้องมี Header value อย่างน้อย 1 ตัว ใน Message ที่จะต้อง Match กับ Binding

ส่วน X-match = all หมายถึงทุก Header value ใน Message จะต้อง Match กับ Binding

Example Scenario

ทั้งหมดนี้ก็คือส่วนสำคัญของ Rabbit MQ ครับ หากใครยังไม่ทันได้อ่านตอนที่ 1 ไปติดตามกันในลิ้งก์ https://www.stream.co.th/rabbit-mq-part1/ นะครับ

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

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

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