Case Study: Store-and-Forward กู้ข้อมูลหายช่วงเน็ตหลุด — เมื่อ Edge Gateway ของโรงงานอาหารต้องเก็บข้อมูล HACCP ให้ครบ

สถานการณ์: เมื่ออินเทอร์เน็ตโรงงานหลุดทุกเดือน ข้อมูลหายทุกครั้ง

โรงงานแปรรูปอาหารแห่งหนึ่งในภาคกลางติดตั้งระบบเฝ้าระวังอุณหภูมิตู้แช่ด้วย IIoT Gateway ส่งข้อมูลขึ้นคลาวด์ทุก 30 วินาที เพื่อใช้ตรวจสอบย้อนหลังตามข้อกำหนด HACCP ปัญหาเกิดขึ้นเมื่อลิงก์อินเทอร์เน็ตของโรงงาน (ทั้ง fiber หลักและ 4G backup) ล่มพร้อมกันในช่วงพายุฤดูฝน เป็นเวลาราว 4 ชั่วโมง ข้อมูลช่วงนั้นหายไปทั้งหมด และทีมคุณภาพต้องเขียนรายงานอธิบายช่องว่างข้อมูลให้ผู้ตรวจสอบฟังทุกครั้ง

วินิจฉัยต้นตอ: สถาปัตยกรรมสมมติว่าเครือข่ายไม่มีวันล่ม

การวิเคราะห์พบว่า gateway เดิมออกแบบแบบ “fire-and-forget” คืออ่านค่าเซ็นเซอร์แล้วส่งขึ้นคลาวด์ทันที หากส่งไม่สำเร็จก็ปล่อยข้อมูลนั้นหายไป ไม่มีการเก็บสำรองใดๆ บนตัวเครื่อง สถาปัตยกรรมลักษณะนี้ยอมรับได้กับ dashboard ดูสภาพแวดล้อมทั่วไป แต่ไม่เกิดผลกับงานที่ต้องมีหลักฐานข้อมูลต่อเนื่องตามกฎระเบียบ

ทางแก้: Store-and-Forward บน Edge Gateway

หลักการคือข้อมูลต้อง “เขียนลงดิสก์สำเร็จก่อน” แล้วจึงส่ง หากส่งไม่ได้ให้เก็บต่อในคิวจนกว่าเครือข่ายกลับมา ส่วนประกอบสำคัญมี 4 อย่าง

1. Local persistent queue เก็บข้อมูลเป็นไฟล์บนดิสก์ gateway (เช่น embedded database หรือ log-structured storage) แยกจาก RAM เพื่อรอดจากไฟฟ้าดับ
2. Send-then-acknowledge ข้อมูลถูกลบออกจากคิวเมื่อ server ปลายทางตอบรับสำเร็จเท่านั้น ไม่ใช่แค่ส่งออกไปแล้ว
3. Circular buffer policy กำหนดขนาดคิวสูงสุดและนโยบายเมื่อเต็ม เช่น เขียนทับข้อมูลเก่าที่สุด หรือหยุดรับและเปิด alarm
4. Timestamp ที่ต้นทาง ประทับเวลา ณ จุดอ่านค่าเซ็นเซอร์ ไม่ใช่เวลาที่ส่งสำเร็จ เพื่อให้ข้อมูลย้อนหลังยังถูกต้อง

ในทางโปรโตคอล การเลือกใช้ MQTT ระดับ QoS 1 ร่วมกับ persistent session และการตั้งค่า message expiry interval ช่วยให้ broker ทำหน้าที่คล้ายกันในระดับหนึ่ง แต่สำหรับ outage ยาวหลายชั่วโมง การมีคิวบนดิสก์ของ gateway เองยังจำเป็น เพราะไม่ต้องพึ่ง TCP connection ที่ต้องเชื่อมต่อใหม่ทั้งหมด

ผลลัพธ์: จากช่องว่างข้อมูลเป็นรายงานที่สมบูรณ์

หลังปรับระบบ ไฟฟ้าดับและเน็ตหลุดหลายครั้งถัดมาไม่ได้ทำให้ข้อมูลสูญหายอีกเลย gateway เก็บข้อมูลในคิวระหว่าง outage แล้วส่งสำรองอัตโนมัติเมื่อเครือข่ายกลับมา ทีมคุณภาพสามารถส่งออกกราฟอุณหภูมิต่อเนื่องได้ทั้งช่วง และการตอบคำถามผู้ตรวจสอบเร็วขึ้นมาก

งานติดตั้งระบบ IoT ตู้แช่ Freezer ของ Honey Corporation ใช้หลักการเดียวกันนี้ คือข้อมูลเซ็นเซอร์ต้องถูกเก็บอย่างต่อเนื่องบนอุปกรณ์ก่อนส่งขึ้นระบบ monitor ผ่านคลาวด์ เพื่อให้ลูกค้าเรียกดูประวัติได้ครบถ้วนแม้เครือข่ายขัดข้อง

Key Takeaways

1. สถาปัตยกรรม fire-and-forget ทำให้ข้อมูลหายทันทีที่เครือข่ายล่ม ไม่เหมาะกับงานที่มีข้อกำหนด compliance
2. หลัก store-and-forward คือเขียนลงดิสก์สำเร็จก่อน แล้วส่ง และลบจากคิวเมื่อได้รับ acknowledge เท่านั้น
3. Timestamp ต้องประทับ ณ จุดอ่านค่าเซ็นเซอร์ ไม่ใช่เวลาที่ส่งสำเร็จ
4. MQTT QoS 1 ร่วมกับ persistent session ช่วยได้ระดับหนึ่ง แต่ outage ยาวหลายชั่วโมงต้องมี disk queue บน gateway
5. Circular buffer policy ต้องถูกกำหนดตั้งแต่ออกแบบ เพื่อไม่ให้คิวเต็มโดยไม่มีใครรู้
6. การทดสอบที่สำคัญที่สุดคือ “ดึงสายแลนออกเอง” แล้วเสียบกลับ ดูว่าข้อมูลกลับมาครบหรือไม่
7. รายงาน compliance ที่สมบูรณ์ช่วยลดเวลาตอบคำถามผู้ตรวจสอบได้อย่างมีนัยสำคัญ