ทีมเล็กที่ยังไม่มี DevOps ควรลงมือกับ Cloudflare Workers ตอนไหนถึงจะคุ้ม

ทีมพัฒนาขนาดเล็กทีมหนึ่งที่ผมเคยคุยด้วยมีปัญหาคล้ายกันแทบทุกทีม คือมี API ตัวหนึ่งที่ต้องรับ Webhook จากผู้ให้บริการชำระเงิน แล้วต้องตอบกลับให้เร็วมากภายในไม่กี่วินาที ไม่งั้นฝั่งผู้ให้บริการจะยิงซ้ำจนข้อมูลซ้ำกันในระบบ ปัญหาคือ Server เดิมของพวกเขาตั้งอยู่ Region เดียว และบางช่วงมี Cold Start ของ Container ที่ทำให้ตอบช้าเกินเวลาที่กำหนด

หลังจากย้าย Endpoint นั้นมาที่ Cloudflare Workers ปัญหาเรื่องความช้าหายไปเกือบหมด เพราะโค้ดรันอยู่ใกล้จุดที่ Webhook ยิงเข้ามาที่สุด และไม่มี Cold Start แบบ Container ทั่วไปให้ต้องกังวล แต่นั่นไม่ได้แปลว่าทุกส่วนของระบบพวกเขาควรย้ายมาด้วย บางส่วนที่ต้องประมวลผลข้อมูลหนักต่อเนื่องยังคงอยู่บน Server เดิมเหมือนเคย

บทความนี้จะอธิบายว่า Cloudflare Workers คืออะไรในเชิงเทคนิค ทำงานต่างจาก Server หรือ Container แบบเดิมยังไง เหมาะกับงานแบบไหน และที่สำคัญคือไม่เหมาะกับงานแบบไหน เพราะการเลือกใช้ผิดประเภทงานคือสาเหตุอันดับต้น ๆ ที่ทำให้ทีมผิดหวังกับเทคโนโลยีนี้

Cloudflare Workers คืออะไร ต่างจาก Server ทั่วไปตรงไหน

Cloudflare Workers คือแพลตฟอร์ม Serverless Compute ที่ให้คุณอัปโหลดโค้ด แล้วมันจะถูกรันบนจุดให้บริการของ Cloudflare ที่กระจายอยู่ทั่วโลก โดยไม่ต้องเช่าเซิร์ฟเวอร์ ไม่ต้องตั้งค่า Load Balancer เอง และไม่ต้องดูแลเรื่อง Scaling เพราะระบบจัดการให้อัตโนมัติตามทราฟฟิกที่เข้ามาจริง

ความต่างสำคัญจาก Server แบบเดิมหรือแม้แต่ Container-based Serverless (เช่น AWS Lambda) คือ Workers ไม่ได้รันบน Virtual Machine หรือ Container แต่รันอยู่ใน Isolate ซึ่งเป็นเทคโนโลยีเดียวกับที่ V8 Engine ใช้แยกโค้ด JavaScript แต่ละหน้าใน Browser ออกจากกัน การใช้ Isolate ทำให้เริ่มรันโค้ดได้เร็วกว่า Container มาก เพราะไม่ต้องบูตระบบปฏิบัติการหรือโหลด Runtime ใหม่ทุกครั้ง

ผลลัพธ์ที่ตามมาคือ Workers แทบไม่มีปัญหา Cold Start แบบที่ Serverless รุ่นก่อนเจอ ซึ่งสำคัญมากสำหรับงานที่ทราฟฟิกไม่สม่ำเสมอ เช่น Webhook ที่บางช่วงเงียบสนิทแล้วจู่ ๆ ก็มีคำขอเข้ามาพร้อมกันหลายร้อยครั้ง

โมเดลการทำงานเบื้องหลัง: V8 Isolate และข้อจำกัดที่ต้องรู้

การใช้ Isolate แทน Container มีข้อดีเรื่องความเร็ว แต่ก็มาพร้อมข้อจำกัดที่ทีมต้องเข้าใจก่อนออกแบบระบบ Workers แต่ละตัวมีขีดจำกัดเรื่องเวลาในการประมวลผล (CPU Time) และหน่วยความจำที่ใช้ได้ต่อ request ซึ่งเข้มงวดกว่า Server แบบเดิมพอสมควร

งานที่ต้องใช้เวลาประมวลผลนานต่อเนื่อง เช่น การแปลงไฟล์วิดีโอขนาดใหญ่ หรือ Batch Job ที่รันหลายนาทีรวดเดียว จึงไม่เหมาะกับ Workers โดยตรง เพราะจะชนขีดจำกัดเวลาได้ง่าย ต้องออกแบบให้แบ่งงานเป็นส่วนย่อย หรือส่งงานหนักไปให้ระบบอื่นที่ออกแบบมาสำหรับงานประเภทนั้นแทน

อีกจุดที่ต้องเข้าใจคือ Workers เป็น Stateless โดยธรรมชาติ หมายความว่าแต่ละ request ไม่มีการจำสถานะจากครั้งก่อนไว้ในตัวเอง ถ้าต้องการเก็บสถานะระหว่าง request เช่น Session หรือข้อมูลที่ต้องอัปเดตต่อเนื่อง จำเป็นต้องใช้ร่วมกับบริการอื่นอย่าง KV, D1 หรือ Durable Objects ซึ่งออกแบบมาสำหรับงานที่ต้องจำสถานะโดยเฉพาะ

งานแบบไหนที่ Workers แก้ปัญหาได้ดีกว่า Server แบบเดิม

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

• API ที่ผู้ใช้อยู่กระจายทั่วโลก — เพราะโค้ดรันใกล้ผู้ใช้แต่ละคน ลด Latency ได้มากกว่า API ที่รันจาก Region เดียว
• Webhook ที่ต้องตอบเร็วและทราฟฟิกไม่แน่นอน — เช่น Webhook จากระบบชำระเงินหรือระบบแจ้งเตือนที่บางช่วงเงียบ บางช่วงมาพร้อมกันเยอะ
• Edge Middleware — เช่น การตรวจสอบสิทธิ์ก่อนส่งต่อไป origin, การ Redirect ตาม Location ของผู้ใช้ หรือการ A/B Testing ที่ทำได้ตั้งแต่ชั้น Edge โดยไม่ต้องรอ origin ประมวลผล
• Static Site ที่มี Logic เล็กน้อยผสมอยู่ — เช่นเว็บที่ส่วนใหญ่เป็นเนื้อหาคงที่ แต่มีบางส่วนต้องคำนวณแบบไดนามิก ไม่คุ้มที่จะรัน Server เต็มรูปแบบทั้งระบบ

ธุรกิจ/งานแบบไหนที่ยังไม่ควรลงทุนกับ Workers ตอนนี้

แม้ Workers จะแก้ปัญหาได้หลายอย่าง แต่ไม่ใช่คำตอบสำหรับทุกงาน มีสถานการณ์ที่การย้ายมาใช้ Workers อาจสร้างความซับซ้อนโดยไม่ได้ประโยชน์คุ้มค่า

ทีมที่มีระบบ Monolith เดิมที่ทำงานได้ดีอยู่แล้ว และไม่มีปัญหาเรื่อง Latency หรือ Scaling จริง ๆ อาจยังไม่จำเป็นต้องรีบย้าย เพราะการแตกระบบมาใช้ Workers บางส่วนต้องออกแบบสถาปัตยกรรมใหม่ และทีมต้องเรียนรู้ข้อจำกัดของ Edge Runtime ซึ่งมีค่าใช้จ่ายด้านเวลาที่ต้องชั่งน้ำหนักกับประโยชน์ที่จะได้

งานที่ต้องใช้ Library หรือ Native Module เฉพาะทางที่ไม่รองรับ Edge Runtime เช่นบาง Library ด้าน Image Processing หรือ Machine Learning แบบดั้งเดิมที่ต้องพึ่ง Native Binding ก็ยังต้องรันบน Server หรือ Container แบบเดิมต่อไป

เทียบ Workers กับทางเลือกอื่นที่ทีมมักเปรียบเทียบกัน

ตัวอย่างสมมติ: ทีมอีคอมเมิร์ซย้าย Endpoint ตรวจสต๊อกมาที่ Workers

เพื่อให้เห็นภาพชัดขึ้น ลองดูสถานการณ์สมมติของทีมอีคอมเมิร์ซขนาดกลางทีมหนึ่ง ที่มี Endpoint ตรวจสต๊อกสินค้าแบบเรียลไทม์ถูกเรียกจากหน้าเว็บบ่อยมาก โดยเฉพาะช่วงแคมเปญลดราคาที่มีคนเข้าดูสินค้าพร้อมกันหลักหมื่นคนในเวลาไม่กี่นาที

ก่อนย้ายมา Workers Endpoint นี้รันอยู่บน Server ตัวเดียวใน Region เดียว ช่วงแคมเปญจึงมักเจอปัญหา Response Time พุ่งสูงเพราะ Server รับโหลดไม่ทัน ทีมต้องคอย Scale Server เพิ่มด้วยมือทุกครั้งที่มีแคมเปญใหญ่ ซึ่งทั้งเสียเวลาเตรียมการและมีความเสี่ยงเรื่องประเมินโหลดผิด

หลังย้าย Logic การตรวจสต๊อกบางส่วนมาที่ Workers โดยให้ Worker อ่านข้อมูลสต๊อกที่แคชไว้ใน KV ก่อน แล้วค่อย Sync กับฐานข้อมูลหลักเป็นระยะ (แทนที่จะ Query ฐานข้อมูลหลักทุก request) ทีมสามารถรองรับทราฟฟิกช่วงแคมเปญได้โดยไม่ต้องเตรียม Scale Server ล่วงหน้าอีกต่อไป เพราะ Workers สเกลตามทราฟฟิกจริงโดยอัตโนมัติ

สิ่งที่ทีมต้องแลกคือความซับซ้อนที่เพิ่มขึ้นเรื่องความสอดคล้องของข้อมูล (Data Consistency) ระหว่างค่าที่แคชไว้ใน KV กับฐานข้อมูลหลัก จึงต้องออกแบบรอบเวลา Sync ให้เหมาะกับลักษณะธุรกิจ เช่น สินค้าที่ใกล้หมดสต๊อกอาจต้อง Sync ถี่กว่าสินค้าที่มีจำนวนมาก ตัวเลขและรายละเอียดในตัวอย่างนี้เป็นกรอบสมมติเพื่อประกอบการอธิบาย ไม่ใช่ผลลัพธ์ที่รับประกันว่าทุกระบบจะได้ผลเหมือนกัน เพราะขึ้นอยู่กับลักษณะทราฟฟิกและโครงสร้างข้อมูลของแต่ละธุรกิจจริง

เริ่มต้นเขียนและ deploy Worker ตัวแรกในขั้นตอนคร่าว ๆ

การเริ่มต้นใช้งาน Workers ไม่จำเป็นต้องมีความรู้ Infrastructure ขั้นสูง เครื่องมือหลักที่ใช้คือ CLI ชื่อ wrangler ซึ่งจัดการตั้งแต่สร้างโปรเจกต์ไปจนถึง deploy ขึ้นระบบจริง

1. ติดตั้ง wrangler ผ่าน npm แล้วล็อกอินเข้าบัญชี Cloudflare ผ่านคำสั่งในเครื่องมือ ขั้นตอนนี้ใช้เวลาไม่กี่นาทีสำหรับทีมที่มีบัญชีอยู่แล้ว
2. สร้างโปรเจกต์ Worker ใหม่ด้วยเทมเพลตพื้นฐาน แล้วเขียน Function ที่รับ request และตอบกลับ response ตามที่ต้องการ โครงสร้างพื้นฐานคล้ายกับการเขียน Express Middleware แต่เรียบง่ายกว่า
3. ทดสอบ Worker บนเครื่องตัวเองผ่านโหมด Local Development ก่อนเสมอ เพื่อจับข้อผิดพลาดพื้นฐานโดยไม่ต้อง deploy จริงทุกครั้ง
4. ตั้งค่า Environment Variable หรือ Secret ที่จำเป็น เช่น API Key ของบริการภายนอก แล้วทดสอบว่า Worker เข้าถึงค่าพวกนี้ได้ถูกต้องในทั้งสภาพแวดล้อม Development และ Production
5. deploy Worker ขึ้นระบบจริงด้วยคำสั่งเดียว แล้วตรวจสอบ Log ผ่าน Dashboard เพื่อดูว่า request จริงเข้ามาทำงานตามที่คาดไว้หรือไม่ ก่อนจะผูก Route หรือ Custom Domain เข้ากับ Worker นั้นอย่างเป็นทางการ

ทำแบบนี้แล้วพัง เพราะทีมยกโค้ด Server เดิมมาใช้ตรง ๆ

• ยกโค้ดที่พึ่ง Node.js API บางตัวมาทั้งดุ้น — เพราะ Workers Runtime ไม่ใช่ Node.js เต็มรูปแบบ บาง Module ที่พึ่ง File System โดยตรงจะใช้งานไม่ได้ ต้องตรวจ Compatibility ก่อนย้ายโค้ดเสมอ
• ลืมออกแบบเรื่อง Retry และ Idempotency สำหรับ Webhook — เพราะทราฟฟิกที่ไม่แน่นอนอาจทำให้ request เดียวกันถูกยิงซ้ำ ถ้า Worker ไม่รองรับการเช็คความซ้ำ ข้อมูลปลายทางอาจผิดเพี้ยนได้
• เก็บสถานะไว้ในตัวแปรระดับ Global แบบผิดวิธี — เพราะ Isolate หนึ่งตัวอาจถูกใช้ซ้ำข้าม request ได้ในบางกรณี ถ้าเผลอเก็บข้อมูลเฉพาะผู้ใช้ไว้ในตัวแปร Global อาจเกิดข้อมูลรั่วข้าม request โดยไม่ตั้งใจ
• ไม่ตั้ง Rate Limit หรือ Budget Alert เมื่อ Worker เรียก API ภายนอกที่มีค่าใช้จ่าย — เพราะ Worker สเกลอัตโนมัติตามทราฟฟิก ถ้ามีทราฟฟิกผิดปกติเข้ามาจำนวนมาก ค่าใช้จ่ายฝั่ง API ภายนอกอาจพุ่งตามไปด้วยโดยไม่มีการควบคุม

สรุป

Cloudflare Workers เหมาะกับงานที่ต้องการ Latency ต่ำ ทราฟฟิกกระจายหลายภูมิภาค หรือทราฟฟิกไม่แน่นอนแบบ Webhook แต่ไม่ใช่ตัวแทน Server แบบเดิมสำหรับทุกงาน โดยเฉพาะงานที่ต้องประมวลผลหนักต่อเนื่องหรือพึ่ง Library เฉพาะทางที่ไม่รองรับ Edge Runtime

การตัดสินใจที่ดีที่สุดคือเริ่มจาก Endpoint หรือฟีเจอร์เดียวที่ได้ประโยชน์ชัดเจนก่อน ทดสอบให้มั่นใจว่าทีมเข้าใจข้อจำกัดของ Isolate Model แล้วค่อยขยายไปส่วนอื่นตามความจำเป็นจริง ไม่ใช่ย้ายทั้งระบบเพราะกระแสเทคโนโลยี

• Workers รันบน V8 Isolate ไม่ใช่ Container ทำให้แทบไม่มี Cold Start แต่มีข้อจำกัดเรื่องเวลาและหน่วยความจำต่อ request
• เหมาะกับ API Latency ต่ำ, Webhook ทราฟฟิกไม่แน่นอน และ Edge Middleware เป็นพิเศษ
• ไม่เหมาะกับงานหนักต่อเนื่องหรือ Library ที่พึ่ง Native Binding ซึ่งยังต้องรันบน Server แบบเดิม
• จุดพังที่พบบ่อยคือยกโค้ด Node.js เดิมมาใช้ตรง ๆ โดยไม่ตรวจ Compatibility กับ Edge Runtime ก่อน

คำถามที่พบบ่อย