เชื่อมต่อแอปพลิเคชันบน Multi-cloud ด้วยโซลูชัน VMware RabbitMQ -

ณ ปัจจุบันในโลกของ Multi-cloud แอปพลิเคชันขององค์กรได้กระจายตัวกันอยู่ตามที่ต่าง ๆ ทั้ง Public Cloud , Private Cloud รวมถึง On-Premise เองก็ตาม บ่อยครั้งที่แอปพลิเคชันเหล่านี้ต้องมีการส่งต่อคำสั่งเพื่อทำงานร่วมกัน ดังนั้นนักพัฒนาจึงจำเป็นต้องออกแบบวิธีการสื่อสารกันระหว่างแอปพลิเคชันเหล่านี้ ซึ่งครอบคลุมทั้งวิธีการรับส่งข้อมูลและกลไกที่จะทำให้ข้อมูลส่งถึงผู้รับได้อย่างแม่นยำ นอกจากนี้ยังมีความซับซ้อนของการทำงานที่ต้องใช้เวลานานและการทำงานประเภทสตรีมมิ่งที่ต้องการตอบสนองอย่างรวดเร็ว ด้วยเหตุนี้การใช้ Message Broker จึงถูกสร้างขึ้นมาเพื่อจัดการกับฟังก์ชันเหล่านี้ และหนึ่งในโซลูชันล่าสุดของ VMware ก็คือ Managed Service RabbitMQ เรามาเจาะลึกกันครับว่าโซลูชันนี้เป็นอย่างไร และจะนำไปใช้งานในแง่ใดได้บ้าง?

Message Broker คืออะไร

หากท่านมีแอปพลิเคชันมากกว่าหนึ่งตัวที่ต้องการสื่อสารกันท่านจะทำอย่างไร นี่เป็นคำถามสำคัญที่ง่ายแต่ยากมากสำหรับการพัฒนาแอปพลิเคชัน คำตอบคือผู้พัฒนาแอปต้องมีการตกลงโครงสร้างของสารที่จะใช้สื่อสารกันให้ได้เสียก่อนว่าภายในจำเป็นต้องประกอบด้วยอะไรบ้าง โดยสามารถอาศัยโปรโตคอลมาตรฐานเพื่อส่งสารเช่น HTTP (ตัวอย่างเช่น API ก็ทำงานอยู่บนโปรโตคอลนี้) หรือ MQTT และ SMTP เป็นต้น

แต่ความซับซ้อนของแอปพลิเคชันไม่ได้จบลงเพียงเท่านี้ เนื่องจากยังมีความท้าทายอีกหลายด้าน เช่น ความหลากหลายของแพลตฟอร์ม ระบบปฏิบัติการ และภาษาที่ใช้ในการพัฒนาโปรแกรมที่ย่อมสร้างภาระให้แก่นักพัฒนาอีกมาก ไม่นับรวมความซับซ้อนในเงื่อนไขของการส่งสารเช่น สาร ‘AA’ จะถูกส่งให้แอปพลิเคชัน ‘X’ และ ‘Z’ เท่านั้นแต่สารข้อความ ‘AB’ จะส่งให้กับ ‘X’ และ ‘Y’ เป็นต้น ตลอดจนหากแอปปลายทางต้องใช้เวลามากเพื่อประมวลผลหลังได้รับสารเข้ามา แอปต้นทางจะทำอย่างไร ต้องรอจนกว่าจะได้รับคำตอบหรือไม่ และยิ่งในธุรกิจที่มีโหลดงานมากระบบของท่านอาจเกิดความผิดพลาดได้ ซึ่งนักพัฒนาต้องดักจับความผิดพลาดนี้ แถมแอปต้นทางยังเสียเวลาเพื่อรอจนกว่าจะได้รับคำตอบ

credit : https://betterprogramming.pub/

ด้วยเหตุนี้เอง Message Broker จึงถูกคิดค้นขึ้นมาเพื่อแก้ปัญหาความยุ่งยากเหล่านี้ โดยความหมายคือเป็นซอฟต์แวร์ที่ช่วยให้แอปพลิเคชัน ระบบ และบริการสามารถสื่อสารกันเพื่อแลกเปลี่ยนข้อมูลได้ ด้วยการแปลสารข้ามระหว่างโปรโตคอลต่างๆกัน แม้กระทั่งแอปจะถูกเขียนจากคนภาษาหรือตั้งอยู่ต่างแพลตฟอร์ม ทั้งนี้ภายใน Message Broker จะมีโมดูลซอฟต์แวร์เพื่อบริการจัดการที่ชื่อว่า Message Middleware หรือ Message-oriented Middleware ซึ่งทั้งหมดนี้ทำให้ Message Broker มีความสามารถในการ เก็บ เลือกเส้นทาง นำส่งสารไปยังปลายทาง รวมถึงความสามารถพิเศษที่เรียกว่า Message Queue เมื่อการันตีให้แน่ใจว่าผู้รับปลายทางจะได้รับสารไปใช้แน่นอน

จะได้เห็นได้ว่าเพียงแค่แยกหน้าที่ของการจัดสรรระบบส่งสารอย่างชัดเจน ก็สร้างประโยชน์ให้แก่ระบบการใช้งานอย่างมากเช่น

1.) นักพัฒนาโปรแกรมไม่ต้องกังวลในเรื่องการสร้างวิธีการพูดคุยระหว่างแอปพลิเคชันด้วยตัวเองอีกต่อไป ไม่ว่าจะใช้ภาษาที่ต่างกัน คนละระบบปฏิบัติการ และแพลตฟอร์ม ก็สามารถคุยกันได้ผ่าน Message Broker ได้โดยตรง

2.) เมื่อฟังก์ชันถูกแยกจากกันการปรับเปลี่ยน การดูแล หรือขยายระบบเพื่อรองรับกับปริมาณงานก็ทำได้ง่ายขึ้น ไม่ต้องมาแก้ไขแอปพลิเคชัน

3.) ความสามารถของ Message Broker ทำให้แอปพลิเคชันสามารถแยกขาดการทำงานโดยไม่ต้องรอกัน (Asynchronous) โดยเพียงแค่แอปต้นทางส่งสารให้ Broker ก็ไปทำงานของตัวเองต่อได้ ยกระดับคุณภาพการทำงานได้อย่างเต็มประสิทธิภาพ

4.) ระบบ Queue จะมีการติดตามจนกว่าปลายทางยืนยันว่าได้รับสารแล้ว จึงมีการันตีให้การทำงานได้อย่างมั่นใจไม่ผิดพลาด แม้กระทั่งปลายทางใช้การไม่ได้ชั่วคราว เมื่อระบบกลับมาก็สามารถได้รับสารเพื่อดำเนินงานต่อไป เพราะสารจะไม่ถูกลบจนกว่าได้รับการยืนยัน

การทำงานของ Message Broker มีรูปแบบการทำงานหลักๆได้ 2 ทางคือ

Point-to-point เป็นการส่งสารแบบ 1:1 ระหว่างต้นทางและปลายทางเท่านั้น
Publish/Subscribe เป็นการส่งสารหาปลายทางได้หลายตัว โดยมีคำศัพท์ที่ต้องรู้ในโมเดลนี้คือ Publisher เป็นผู้ให้สารและ Subscriber เป็นผู้รับ ซึ่งสารจะถูกอ้างถึงด้วยหัวข้อ (Topic) ที่อาจถูกเขียนเข้ามาจากหลาย Publisher โดยผู้รับสามารถเลือกติดตามเฉพาะ Topic ที่ตัวเองสนใจได้แต่เลือกได้หลาย Topic เมื่อมีสารใหม่เข้ามาก็จะมีการอัปเดตสารใหม่ในหัวข้อที่ปลายทางสนใจ

Message Broker นำไปใช้งานจริงได้อย่างไรบ้าง

คุณสมบัติของ Message Broker มีความเหมาะสมกับแอปพลิเคชันอยู่หลายด้านดังนี้

1.) แอปพลิเคชันด้านการเงินซึ่งการจ่ายเงินควรจะต้องเกิดขึ้นเพียงครั้งเดียว นั่นแปลว่าต้องไม่มีการสูญหายหรือมีการสื่อสารซ้ำเกิดขึ้น พร้อมตอบสนองการร้องขอได้อย่างทันท่วงที และแทนการทำงานระบบ Batch แบบเดิมที่ตั้งเวลาทำวันละครั้ง กลายเป็นทำงานได้เรื่อยๆอย่างต่อเนื่อง

2.) อีคอมเมิร์ซก็เป็นอีกแอปพลิเคชันหนึ่งที่เหมาะสำหรับ Message Broker เนื่องจากมีการการันตีว่าปลายทางจะได้รับสารอย่างน้อยหนึ่งครั้ง

3.) การใช้งานที่เกี่ยวกับข้อมูลละเอียดอ่อนซึ่งต้องระวังทั้งเรื่องการส่งให้ปลอดภัย ในคุณสมบัติของ Message Broker หลายเจ้าก็เตรียมเรื่องการเข้ารหัสการสื่อสารไว้แล้ว รวมถึงการพิสูจน์ตัวตนของผู้ใช้ด้วยเช่นกัน

4.) Microservices หรือ Serverless ก็สามารถประยุกต์ใช้ Message Broker ได้ด้วยเช่นกัน โดยหลายท่านอาจคุ้นกับการใช้งานผ่าน API ซึ่งก็ทำได้เพียงแต่ว่าการทำงานบน HTTP นั่นหมายถึงมีความคาดหวัง Reply จากการ Request ทำให้เกิดข้อจำกัดแบบ Synchronous แต่การใช้ Message Broker ทำให้เกิดการทำงานแบบ Asynchronous.

5.) ระบบแอปพลิเคชันที่ต้องเกี่ยวข้องกับหลายฝ่ายเช่น เหตุการณ์แจ้งเวลาเครื่องบินที่ต้องมีการแจ้งให้ทีมภาคพื้นทราบ ทีมการจัดตารางของสนามบิน และประชาสัมพันธ์การแจ้งผู้โดยสารของสายการบินเป็นต้น

6.) ในกรณีของงานที่ต้องรอนานก็เหมาะสม เช่น การส่งไฟล์ไปสแกนไวรัสก่อนซึ่งผู้ใช้จะได้รับการแจ้งเตือนเมื่องานเสร็จ แต่ระหว่างนั้นก็ไม่ควรต้องมีการรอคำตอบ ปล่อยให้ไปทำงานอื่นได้

Message Broker ยี่ห้อ RabbitMQ

ในท้องตลาดมี Message Broker อยู่หลายยี่ห้อ โดยเกณฑ์การเลือกใช้งานก็ขึ้นอยู่กับโจทย์ทางธุรกิจ เช่น ความหลากหลายของภาษาโปรแกรมที่รองรับ มาตรฐานของระบบ Message (AMQP, STOMP หรือเป็นระบบของตัวเอง) ความสามารถในการเก็บข้อมูลลงหน่วยความจำถาวรแต่แน่นอนว่าต้องแลกมาซึ่งความเร็ว ตลอดจนความสามารถในการขยายตัวของระบบ และสุดท้ายคือสามารถการันตีว่าส่งถึงหรือไม่

หนึ่งในตัวเลือกที่น่าสนใจก็คือโอเพนซอร์สที่ได้รับความนิยมมากเป็นอันดับต้นๆนั่นก็คือ RabbitMQ แรกเริ่มเดิมทีเกิดขึ้นเพื่อรองรับโปรโตคอล Advance Message Queuing Protocol (AMQP) แต่ปัจจุบันมีส่วนต่อขยายที่ครอบคลุมถึง Streaming Text Oriented Messaging Protocol (STOMP) หรือแม้แต่ MQTT ที่เหมาะสำหรับการสื่อสารของอุปกรณ์ IoT (ไม่มีการจัดทำคิวเน้นเร็ว) ทั้งนี้ RabbitMQ มีกลุ่มผู้สนับสนุนจำนวนมากจึงมีฟีเจอร์เกิดขึ้นใหม่อย่างต่อเนื่อง แม้กระทั่งความสามารถในด้าน Streaming เช่น Append-only Log เป็นต้น

ในด้านความยืดหยุ่นทางการใช้งานที่ทำให้ RabbitMQ โดดเด่น เมื่อพิจารณาทางการใช้งานกับโปรโตคอล AMQP จะเห็นได้ว่า อันที่จริงแล้วภายในจะส่วนรับข้อความ Exchange จากผู้ส่งก่อนที่จะเลือกเส้นทางไปยัง Queue ซึ่งจะเห็นได้ว่า Exchange มีหลายประเภททำให้มีวิธีการใช้ Queue ต่างกัน อีกทั้งยังเป็นการรองรับเงื่อนไขที่ซับซ้อนมากขึ้นด้วย

credit : https://www.cloudamqp.com/

ความสามารถของ RabbitMQ มีหลายด้านดังนี้

Reliability – ตอบโจทย์ด้านประสิทธิภาพเช่น กระจายงานด้วย Round-robin ให้ Queue หรือเปิดให้ผู้รับอ่านสารจากหลาย Queue ได้ในคราวเดียว ข้อมูลจะถูกลบออกจาก Queue ก็ต่อเมื่อมี ACK จากปลายทางแล้วเท่านั้น
Security – รองรับการตรวจสอบ Client Certificate Checking และการสื่อสารบน SSL รวมถึงทำ RBAC การเข้าถึงสารได้
Flexible Routing – อย่างที่เห็นว่า Exchange มีหลายประเภทส่งผลต่อความยืดหยุ่นในการวางเงื่อนไขเพื่อการเลือกเส้นทางไปยัง Queue หรือผู้ใช้อาจจะพัฒนาปลั๊กอินของตัวเองก็ได้
Built-in Clustering – มีการสร้าง Object สำหรับคลัสเตอร์เสมอเพื่อรองรับกรณีหากมีตัวใดเกิดความผิดพลาด หรืออาจเพิ่มโหนดใหม่รองรับโหลดการทำงานได้
Support Language – รองรับภาษาการทำงานยอดนิยมเช่น Python, Ruby, Elixir, PHP, Swift, Go, Java, C, Spring, .Net และ JavaScript

RabbitMQ ในบทบาทของ Event Streaming

การทราบถึงการเปลี่ยนแปลงที่เกิดอย่างต่อเนื่อง ช่วยให้องค์กรสามารถเข้าใจสถานการณ์ ณ ปัจจุบันได้อย่างทันท่วงที ไม่เพียงเท่านั้นทุกครั้งที่มีอีเวนต์บางอย่างเกิดขึ้น ก็อาจส่งผลต่อเนื่องไปยังส่วนอื่นของแอปพลิเคชันหรือเงื่อนไขที่ต้องทำการตอบสนองบางอย่าง (Event Driven) คุณลักษณะสำคัญของ Event-streaming คือปริมาณข้อมูลกำเนิดขึ้นอย่างมหาศาลและต่อเนื่อง ยกตัวอย่างเช่น ข้อมูลความเร็วของรถ สุขภาพของผู้ป่วย หรือยอดเงินในบัญชี การติดตามข้อมูลต่อเนื่องเหล่านี้ได้จะช่วยให้ท่านตอบคำตอบว่าเกิดอะไรขึ้นบ้างตั้งแต่ช่วงเวลาในอดีตจนถึงปัจจุบัน หรือ ณ ช่วงเวลาใดๆ ดังนั้นดูเหมือนว่าอีเว้นต์จะเกิดขึ้นได้เรื่อยและไร้ที่สิ้นสุด

ด้วยเหตุนี้เอง Event-streaming Broker จึงเป็นอีกหนึ่งโซลูชันที่ช่วยขับเคลื่อนกรณีการใช้งานต่างๆ ที่ชีวิตจริง ไอเดียความแตกต่างระหว่าง Message Broker และ Event-streaming ก็คือตัว Message Broker จะมีการลบสารออกจากระบบเมื่อได้รับผู้รับบอกว่าตนได้รับสารแล้ว ทั้งนี้ยังมีความสามารถเลือกเส้นทางตามการตั้งค่าเอาไว้ได้ กลับกันเนื่องจากด้วยปริมาณข้อมูลที่มหาศาล Event-streaming ทั่วไปจึงไม่มีฟังก์ชันนี้และผลักภาระให้เป็นหน้าที่ของแอปไคลเอ้นต์ อย่างไรก็ดีหัวใจสำคัญของ Event-streaming Broker คือจะไม่มีการลบสารที่ได้รับการยืนยันแล้ว ทำให้สามารถทำการ Replay อีเว้นต์ย้อนกลับไปได้นั่นเอง

ในอดีตที่ผ่านมา RabbitMQ มีความโดดเด่นอย่างมากกับการใช้งานในมุมของ Message Broker แต่ในเวอร์ชัน 3.9 ก็ได้ถูกเพิ่มให้เข้าสู่การทำงานกับ Stream ได้ ทำให้กลายเป็นโซลูชันที่สามารถรองรับการทำงานได้ทั้งสองด้าน (ตามภาพประกอบ)

อีกมุมหนึ่งหลายท่านคงตั้งคำถามระหว่างประสิทธิภาพของ RabbitMQ และ Kafka ซึ่งเป็นเรื่องราวเมื่อนานมาแล้ว ทีมงาน VMware เองได้คลุกคลีอยู่กับลูกค้าที่นำ RabbitMQ ไปใช้ในกรณีของ Event-streaming เช่นกัน อีกทั้งยังได้แสดงให้โลกเห็นว่า RabbitMQ ก็สามารถรองรับงานระดับหลายล้านอีเว้นต์ต่อวินาที่ได้ ซึ่งปัจจุบัน RabbitMQ ได้ถูกพัฒนาให้ก้าวหน้าไปมากกับการใช้งานในมุมนี้ เช่น การรองรับ FIFO เหมือน Kafka แต่สามารถสเกลการทำงานด้วยฟีเจอร์ Super Stream เป็นต้น

RabbitMQ ภายใต้การให้บริการของ VMware

Message Broker มีประเด็นอ่อนไหวอยู่เพียงเรื่องเดียวก็คือการเกิด Single Point of Failure ซึ่งหากท่านจัดตั้งเซิร์ฟเวอร์ขึ้นมาเอง ภาระของการดูแลก็จะตกอยู่กับทีมงานของท่าน และระบบนี้ถือเป็นสิ่งสำคัญอย่างยิ่ง ต่อการทำงานร่วมกันในแอปพลิเคชัน ด้วยเหตุนี้เองจึงไม่ใช่เรื่องที่จะย่อหย่อนได้เลย โดยเมื่อไม่นานมานี้ VMware ได้เปิดตัว RabbitMQ เวอร์ชัน Beta ภายใต้กลุ่มโซลูชัน Tanzu ที่ทีมงาน VMware ได้บริหารจัดการเซิร์ฟเวอร์เหล่านี้ให้ ผู้ใช้ไม่ต้องซ่อมบำรุง อัปเดต แถมใช้งานได้จากทุกที่อีกด้วย

อีกหนึ่งความท้าทายในการจัดตั้งระบบขึ้นด้วยตัวเองก็คือความยากในการตั้งค่าและบริหารจัดการ แต่บริการของ VMware ได้ลบความยุ่งยากด้วยเมนูง่ายๆผ่าน Web UI นอกจากนี้ยังเตรียม API เพื่อการจัดการได้อัตโนมัติ ตลอดจนความสามารถด้าน Observability ในหน้าแดชบอร์ด รวมไปถึงประหยัดค่าใช้จ่ายด้านทราฟฟิคเมื่อเทียบกับการตั้งเซิร์ฟเวอร์เองใน Public Cloud

สำหรับโมเดลการใช้งาน VMware RabbitMQ มีทางเลือกมากมายทั้งขนาดและราคา ท่านใดสนใจเพียงแค่เข้าไปลงทะเบียนทดลองได้ที่ https://tanzu.vmware.com/rabbitmq/rabbitmq-as-a-service

พร้อมใช้งานได้ทันทีอย่างง่ายดาย ด้วยบริการจาก Cloud HM

ในมุมของการบริหารจัดการสำหรับลูกค้าของ Cloud HM ท่านสามารถใช้งานผ่านหน้า Portal พิเศษเพื่อการบริหารจัดการได้อย่างง่ายดาย

โดยทาง Cloud HM ไม่เพียงแต่การนำ VMware RabbitMQ มาให้บริการเพื่อเพิ่มประสิทธิภาพให้แก่ธุรกิจองค์กรเท่านั้น แต่ Cloud HM ยังได้มีการเสริมบริการทั้งในส่วนของ VMware Tanzu และการดูแลรักษาระบบอย่างครบถ้วนจากผู้ให้บริการได้แบบ One-Stop Service เพื่อให้มั่นใจว่าการใช้งาน Rabbit MQ as a Service สามารถพัฒนาและเพิ่มประสิทธิภาพของแอปพลิเคชันได้ตอบโจทย์กับธุรกิจต่างๆ อย่างคุ้มค่า และเหมาะสม

Cloud HM เป็นผู้เชี่ยวชาญทางด้าน Multi-Cloud ที่ให้บริการ Sovereign Cloud ภายในประเทศไทย โดยมี Infrastructure เป็นของตัวเองบน Data Center มาตรฐาน Tier IV พร้อมทีมงาน Engineer Service 1st คอยดูแลตลอด 24/7 นอกจากนี้ยังมีการให้บริการด้านอื่น เช่น Cloud Native Application, Big Data Analytics และบริการเสริมอื่น ๆ บนระบบ Infrastructure ที่มีประสิทธิภาพและเสถียรสภาพสูง ภายใต้ Concept ‘Your Multi-Cloud Expert’

ทดลองใช้งาน VMware RabbitMQ ได้ทันที

หากท่านใดมีความสนใจในโซลูชันของ VMware RabbitMQ ทีมงาน CloudHM มีความยินดีเป็นอย่างยิ่งที่จะให้คำปรึกษาและเข้าไปช่วยเหลือในทุกความต้องการ โดยท่านสามารถติดต่อทีมงาน Cloud HM ได้ที่นี่

ที่มา :

https://www.rabbitmq.com/

https://tanzu.vmware.com/content/blog/vmware-rabbitmq-as-a-service-beta-news

https://tanzu.vmware.com/content/rabbitmq/announcing-vmware-rabbitmq-as-a-service-beta

https://betterprogramming.pub/why-do-we-need-message-broker-7382ce0e46c6

https://www.g2.com/articles/message-broker

https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html

https://www.simplilearn.com/kafka-vs-rabbitmq-article

https://www.ibm.com/topics/message-brokers

https://www.hivemq.com/blog/mqtt-vs-amqp-for-iot/

https://en.wikipedia.org/wiki/RabbitMQ

https://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol