บทวิเคราะห์: Offline-First และ CRDT — เมื่อโรงงานหลายไซต์เลิกรอเน็ตจึงจะ sync ข้อมูลได้

คำถามคลาสสิกของโรงงานหลายไซต์คือ “ข้อมูลควรอยู่ที่ไหน” — คำตอบยุคก่อนมักเป็น centralized ทั้งหมดขึ้น cloud แล้วให้ทุกไซต์ดึงจากศูนย์กลาง แต่ทุกคนที่เจอ WAN ล่มตอนกลางกะดีนหรือ fiber ถูกขุดด้วยคนงานหน้างานรู้ว่าสถาปัตยกรรมแบบนั้นแพงเกินไป บทวิเคราะห์นี้มองไปอีกทาง: Offline-First โดยใช้แนวคิด CRDT (Conflict-free Replicated Data Type) ที่กำลังเป็นกระแสในวงการ software เพื่อโรงงาน

Store-and-Forward แก้ได้ครึ่งเดียวของปัญหา

แนวทางที่โรงงาน IIoT ใช้กันทุกวันนี้คือ store-and-forward: edge gateway เก็บข้อมูลไว้ในเครื่อง เมื่อเน็ตกลับมาค่อยส่งขึ้น cloud แบบไม่สูญหาย วิธีนี้แก้ปัญหา ทิศทางเดียว — ข้อมูลจาก sensor ขึ้น cloud ได้ครบ แต่ทิศกลับกันไม่ได้ถูกออกแบบ ถ้าสองไซต์ต้อง “เขียน” ข้อมูลชุดเดียวกันขณะออฟไลน์ (เช่น ปรับ production order, บันทึกผลแม่พิมพ์ หรือแก้ setpoint) เมื่อเน็ตกลับมา ระบบส่วนใหญ่จะเลือกวิธีง่ายที่สุด: Last-Writer-Wins (LWW) เก็บเฉพาะฝั่งที่เขียนทีหลัง และทิ้งอีกฝั่งเงียบๆ

CRDT คืออะไร

CRDT ถูกนิยามอย่างเป็นทางการเมื่อปี 2011 โดยกลุ่มนักวิจัยนำโดย Marc Shapiro โดยมีคุณสมบัติ 3 ข้อที่น่าสนใจสำหรับโรงงาน:

• แต่ละสำเนา (replica) แก้ข้อมูลได้อิสระ โดยไม่ต้องประสานงานกับสำเนาอื่นระหว่างทำงาน
• อัลกอริทึมเป็นส่วนหนึ่งของโครงสร้างข้อมูลเอง ที่ resolve ความขัดแย้งโดยอัตโนมัติ
• ทุกสำเนาจะ converge ไปสู่ค่าเดียวกันในที่สุด (strong eventual consistency) โดย merge function ต้องเป็นไปตามคุณสมบัติ commutative, associative และ idempotent — ทำให้ลำดับและการซ้ำของการ sync ไม่กระทบผลลัพธ์

มีสองตระกูลหลัก: state-based (CvRDT) ที่ส่งสถานะเต็มไป merge และ operation-based ที่ส่งเฉพาะคำสั่งการเปลี่ยนแปลง รวมถึงรุ่นปรับปรุงอย่าง delta CRDT ที่ส่งเฉพาะส่วนที่เปลี่ยน เหมาะกับลิงก์ WAN ที่แพงและไม่เสถียรแบบที่โรงงานต่างจังหวัดเจอกันจริง

ตารางวิเคราะห์: 3 แนวทาง sync ข้อมูลโรงงานหลายไซต์

มุมมองของเรา: เริ่มจากข้อมูลที่ “ควรเป็น CRDT” ไม่ใช่ทั้งหมด

สิ่งที่ต้องพูดกันตรงๆ คือ CRDT ไม่ใช่คำตอบสำหรับทุกข้อมูล — sensor stream ที่เป็น append-only ใช้ store-and-forward ก็เพียงพอแล้ว จุดที่ CRDT ให้คุณค่าจริงคือข้อมูลที่ หลายฝ่ายแก้พร้อมกัน เช่น production order ที่ทั้ง planner ที่สำนักงานใหญ่และ supervisor หน้าไซต์ต่างปรับสถานะ, maintenance log ที่ช่างหลายคนจดพร้อมกัน หรือ master data ของสูตรที่ engineer หลายไซต์ดูแลร่วมกัน แนวคิดนี้ไม่ใช่ของใหม่ในโลก software — ฐานข้อมูล distributed สมัยใหม่หลายตัวใช้ CRDT ในการ sync ระหว่าง replica และแอปพลิเคชันจดบันทึกยอดนิยมบนมือถือก็ใช้แนวคิดเดียวกันให้ผู้ใช้แก้ note ออฟไลน์หลายเครื่องแล้ว merge ได้ไม่มีข้อมูลหาย แต่ในโลกโรงงานมันยังใหม่พอที่จะเป็นความได้เปรียบ

ในงานออกแบบระบบ IoT และ Edge Monitoring ให้ลูกค้าหลายไซต์ ทีม Honey Corporation เห็นซ้ำๆ ว่าปัญหาไม่ใช่การเก็บข้อมูลขึ้น cloud แต่คือการทำให้ข้อมูล “เขียนได้ทุกที่ ชนกันไม่พัง” การออกแบบ data architecture ที่คำนึงถึงวันที่เน็ตหลุดตั้งแต่ต้น จึงเป็นสิ่งที่เราย้ำกับลูกค้าเสมอ

Key Takeaways

1. Store-and-Forward แก้เฉพาะทิศ sensor-to-cloud ส่วนการเขียนข้อมูลพร้อมกันจากหลายไซต์ยังชนกันเมื่อ sync
2. CRDT (นิยามปี 2011) อนุญาตให้ทุก replica แก้ข้อมูลอิสระ แล้ว merge อัตโนมัติโดยทุกสำเนา converge ค่าเดียวกัน
3. หัวใจทางคณิตศาสตร์คือ merge ที่ commutative, associative, idempotent — ลำดับ/การซ้ำของ sync ไม่กระทบผลลัพธ์
4. LWW ทิ้งการเขียนของฝั่งหนึ่งเงียบๆ และทำให้ audit trail ขาดช่วง — จุดเสี่ยงจริงในงานที่ต้อง trace ได้
5. ไม่ควรยก CRDT มาใช้กับข้อมูลทั้งหมด — เริ่มจากข้อมูลที่หลายฝ่ายแก้พร้อมกัน เช่น production order, maintenance log, master data
6. สถาปัตยกรรม local-first ทำให้หน้างานอ่าน-เขียนเร็วที่สุดและทนต่อ WAN ล่มโดยไม่ต้องหยุดงาน