WebAssembly (Wasm) ที่ Edge ของโรงงาน: บทวิเคราะห์ Container Alternative ที่ Cold Start ต่ำกว่า 1 ms

ทำไมโรงงานปี 2026 ถึงพูดถึง Wasm ที่ Edge

หลายทีมที่ดูแลระบบ IIoT คุ้นเคยกับการ deploy โค้ดลง Edge Gateway ด้วยสองทางเลือกคลาสสิก คือคอมไพล์โปรแกรมลง OS ตรงๆ หรือห่อด้วย Linux Container แต่ทั้งสองวิธีมีข้อจำกัดที่เจ็บปวดเมื่อเครื่อข่าย Edge โตขึ้น โค้ดที่คอมไพล์ตรงๆ ย้ายระหว่างสถาปัตยกรรม CPU ไม่ได้ ส่วน Container กินทรัพยากรเริ่มต้นค่อนข้างมากและมีพื้นที่โจมตี (attack surface) กว้าง

WebAssembly หรือ Wasm คือ binary format มาตรฐานเปิดที่แก้ปัญหาเหล่านี้ได้พร้อมกัน ตัวเลขจาก State of WebAssembly Survey ปี 2026 ชี้ว่าผู้ใช้งานจริงใน production ขึ้นไปถึง 67% เพิ่มจาก 47% ในปี 2024 และเป็นครั้งแรกที่การใช้งานฝั่ง server-side แซงการใช้ในเบราว์เซอร์ โดย 52% ของ deployment ใช้งานในสภาพแวดล้อมที่ไม่ใช่เบราว์เซอร์

Wasm แตกต่างจาก Container ตรงไหน

หัวใจของ Wasm คือ sandbox ระดับสถาปัตยกรรมที่ออกแบบมาตั้งแต่แรก โมดูล Wasm แต่ละตัวทำงานแยกจากกันโดยสิ้นเชิง และไม่สามารถเข้าถึงไฟล์ เครือข่าย หรือ hardware ใดๆ ได้เลยจนกว่า host จะมอบสิทธิ์ (capability) ให้อย่างชัดเจน ลักษณะเช่นนี้ต่างจาก Container ที่ process ภายในแชร์ kernel ของ host และเคยมีช่องโหว่ container escape หลายครั้งในอดีต

สามเหตุการณ์สำคัญที่ทำให้ปี 2026 กลายเป็นจุดเปลี่ยนของ Wasm คือ WASI Preview 2 เสถียรในช่วงต้นปี 2026 หลังพัฒนาเกือบสองปี, Component Model ถึงเวอร์ชัน 1.0 ที่ทำให้โมดูลคนละภาษาเรียกใช้กันได้ผ่าน typed interface และ toolchain ด้าน container กระแสหลักเพิ่มการรองรับ Wasm แบบ native ทำให้ทีมที่มีระบบเดิมยังใช้งานต่อได้ทันที

สถาปัตยกรรม Wasm บน Edge Gateway อุตสาหกรรม

ในทางปฏิบัติ การนำ Wasm ลง Edge Gateway ไม่ได้แปลว่าต้องทิ้งทุกอย่างเดิม รูปแบบที่นิยมคือรัน Wasm runtime เป็น “host process” เดียวบน gateway แล้วโหลด logic การประมวลผลข้อมูลแต่ละงานเข้ามาเป็น module ตัวอย่างเช่น โมดูลแปลง raw data จาก Modbus RTU เป็น MQTT payload, โมดูลคำนวณ rolling average ของ vibration, และโมดูลตรวจจับ anomaly พื้นฐาน ทำงานอยู่ใน sandbox แยกกันภายใน runtime เดียว

ข้อดีที่ทีม OT สัมผัสได้จริง

• อัปเดต logic โดยไม่แตะ OS: ส่งไฟล์ .wasm ใหม่ให้ runtime แล้ว reload ได้ทันที ไม่ต้องแก้ base image หรือรีบูตเครื่อง
• โค้ดชุดเดียวกันทั้ง fleet: โรงงานที่มี gateway ทั้ง x86 และ ARM ใช้ binary เดียวกัน ลดขั้นตอน build หลายเท่า
• หลายภาษาในระบบเดียว: วิศวกรแต่ละคนใช้คนละภาษาในการเขียน logic ก็ทำงานร่วมกันได้ผ่าน Component Model
• ลดพื้นที่โจมตี: โมดูลที่ถูกโจมตีไม่สามารถกระโดดออกไปยังระบบอื่นได้เพราะถูกกรองสิทธิ์ไว้ตั้งแต่ต้น

ข้อจำกัดที่ต้องรู้ก่อนตัดสินใจ

Wasm ยังไม่ใช่คำตอบสำหรับทุกงาน งานที่ต้องการ GPU หรือ real-time deterministic ระดับ sub-millisecond ยังเป็นของ native code และ realtime OS ส่วน WASI Preview 3 ที่เพิ่ม native async ยังอยู่ในสถานะ draft คาดว่าจะเสถียรปลายปี 2026 ทีมที่วางแผนใช้งานจริงควรตรวจสอบว่า runtime ที่เลือกผ่าน WASI 0.2 แล้วหรือยัง

ทีมงาน Honey Corporation มีประสบการณ์ติดตั้งระบบ IoT และ Edge Gateway ในโรงงานอุตสาหกรรมหลายแห่ง เราเห็นปัญหาการจัดการโค้ดหลายสถาปัตยกรรมเป็นประจำ การประเมินว่า workload ใดเหมาะกับ Wasm และต้องเปลี่ยนแปลงสถาปัตยกรรมมากน้อยแค่ไหน สามารถปรึกษาทีมวิศวกรของเราได้โดยตรง

Key Takeaways

1. Wasm ให้ cold start ต่ำกว่า 1 ms และ memory footprint เพียง 1–10 MB เทียบกับ Container ที่ 500 ms ถึง 2 วินาที และ 100 MB ขึ้นไป
2. State of WebAssembly Survey 2026 พบการใช้งาน production 67% และ server-side แซง browser เป็นครั้งแรก (52%)
3. WASI Preview 2 เสถียรต้นปี 2026 พร้อม Component Model 1.0 และการรองรับ Wasm แบบ native ใน toolchain กระแสหลัก
4. binary เดียวรันได้บน x86, ARM, RISC-V ช่วยลดความซับซ้อนของ fleet ที่มี CPU หลากหลาย
5. sandbox แบบ capability-based ทำให้โมดูลที่ถูกโจมตีไม่ลุกลามไปยังระบบอื่น
6. งาน GPU-heavy และ hard real-time ยังคงเป็นอาณาเขตของ native code และ RTOS
7. รูปแบบที่เหมาะคือรัน Wasm runtime เป็น host เดียวแล้วโหลดหลาย logic เป็น module แยกกัน