PinPrint

ปัญหาเริ่มจากสิ่งเล็กๆ: Production Order จาก ERP ถึง MES ค้างอยู่สถานะ “กำลังส่ง” เป็นครั้งที่สามในเดือน ทีม IT ตรวจ log พบว่า REST call ระหว่างระบบ timeout ช่วง 03:00 ตาม batch backup — ไม่มี retry ที่เชื่อถือได้ ไม่มีการันตีว่าข้อมูลถึงครบหรือไม่ และเมื่อลองส่งซ้ำ บางครั้ง order ถูกสร้างสองรายการ นี่คือจุดที่หลายโรงงานเริ่มมองหา message backbone ระดับ enterprise แทนการเขียน point-to-point interface เพิ่มเรื่อยๆ

ทำไม MQTT อย่างเดียวไม่พอ

MQTT เป็นโปรโตคอลที่เหมาะกับงาน telemetry อย่างยิ่ง: header เล็ก 2 ไบต์, QoS 0–2, retained message และ last will สำหรับอุปกรณ์จำนวนมาก แต่เมื่องานคือ เอกสารธุรกิจ (production order, work order, genealogy, invoice) สิ่งที่ต้องการไม่ใช่แค่ “ส่งถึง” แต่คือ:

  • Transaction — จัดกลุ่มหลายข้อความให้สำเร็จหรือล้มพร้อมกัน
  • Exactly-once delivery — ไม่มี duplicate, ไม่มีหาย
  • Store-and-forward — ปลายทางล่ม ข้อความรอได้เป็นวันโดยไม่สูญ
  • Rich routing — แยกปลายทางตาม header/topic/content แบบหลายชั้น
แผนภาพเปรียบเทียบ AMQP Exchange-Binding-Queue กับ MQTT Topic Tree
AMQP แยกการ routing (Exchange) ออกจากการเก็บ (Queue) — ต่างจาก MQTT ที่ผูกกับ topic tree เดียว

สถาปัตยกรรมที่เลือก: MQTT ที่ขอบเครือข่าย, AMQP ที่แกนหลัก

ตามข้อมูลจำเพาะ OASIS AMQP 1.0 (มาตรฐาน ISO/IEC 19464) AMQP คือ wire-level binary protocol บน TCP ที่แยกการทำงานเป็น connection → session → link หลายชั้น รองรับ SASL สำหรับ authentication และ TLS สำหรับ encryption จุดเด่นคือโมเดล Exchange → Binding → Queue: producer ส่งข้อความเข้า exchange จากนั้น binding rules ตัดสินว่าข้อความจะไปที่ queue ไหน — ทีม integration จึงเปลี่ยน routing logic ได้โดยไม่แก้ code ฝั่ง producer

ตารางเปรียบเทียบ MQTT กับ AMQP ว่าเหมาะกับงานใดในโรงงาน
MQTT เหมาะกับ telemetry ปลายทางจำนวนมาก AMQP เหมาะกับเอกสารธุรกิจที่ต้อง delivery guarantee สูง

ผลลัพธ์หลังวางระบบ

ปัญหาเดิม หลังใช้ AMQP Backbone
Order หาย/ซ้ำจาก timeout ไม่มี retry Settled delivery: at-least-once พร้อม idempotent consumer → ไม่มีหาย ไม่มีซ้ำ
Interface 17 คู่ point-to-point แก้ยาก Producer/Consumer ผ่าน exchange เดียว เพิ่ม consumer ใหม่ไม่ต้องแก้ฝั่งส่ง
MES ล่ม → IT batch ค้างทั้งกระบวนการ Durable queue store-and-forward — ระบบกลับมาแล้วข้อมูลไหลต่ออัตโนมัติ
ไม่รู้ว่าใครยังไม่ได้รับข้อมูล เห็น queue depth และ settlement state ของทุก consumer แบบ real-time

ในทางปฏิบัติ ทีมงาน Honey Corporation ออกแบบสถาปัตยกรรมแบบผสมให้ลูกค้าอุตสาหกรรมหลายราย: เซ็นเซอร์และ edge gateway พูด MQTT เข้า broker ที่ขอบเครือข่าย จากนั้น bridge ขึ้น AMQP backbone เพื่อกระจายข้อมูลไปยัง MES, ERP, data lake และระบบ analytics พร้อมกัน — สอดคล้องกับแนวคิด Unified Namespace ที่เราเคยนำเสนอในบทความก่อนหน้า แนวทางนี้ทำให้ทุกระบบเห็นข้อมูลชุดเดียวกันในเวลาใกล้เคียงกัน โดยที่ความหายของ order กลายเป็นเรื่องในอดีต

Key Takeaways

  • MQTT เก่ง telemetry, AMQP เก่ง business messaging: อย่าบังคับโปรโตคอลเดียวทำทุกงาน
  • Exchange/Binding/Queue แยก routing จาก storage: เปลี่ยน routing ได้ไม่ต้องแก้ code ฝั่งส่ง
  • Transaction + settlement ให้ exactly-once จริง: จบปัญหา order ซ้ำ/หายจาก retry แบบลวกๆ
  • Store-and-forward คือป้องกันภัยระดับสถาปัตยกรรม: ปลายทางล่มชั่วคราวไม่ทำให้ข้อมูลสูญ
  • สูตรลับคือ hybrid: MQTT ที่ขอบเครือข่าย + AMQP ที่แกนหลัก ทำงานร่วมกันผ่าน bridge

Honey Corporation พร้อมให้คำปรึกษา

ทีมงานของเรามีความเชี่ยวชาญด้านระบบ Data Pipeline และ Enterprise Integration สำหรับโรงงาน IIoT พร้อมออกแบบและติดตั้งระบบให้เหมาะกับธุรกิจของคุณ

📞 โทร: 09-23242995 | อีเมล: support@honey.co.th
เว็บไซต์: www.honey.co.th

PinPrint