ผู้ใช้ทักเข้ามาวันละหลักพันข้อความ แต่ Bot เริ่มค้างและตอบช้าเป็นบางช่วง เกิดจากอะไร

ธุรกิจจำนวนมากที่ยิงโฆษณาเข้า LINE ทุกวัน มักเจอคำถามเดียวกันซ้ำ ๆ คือ คนที่กดเข้ามาทักแชทแล้ว ไปถึงขั้นตอนไหนต่อ บางคนทักแล้วหายไปกลางทาง บางคนรอนานจนเปลี่ยนใจ ปัญหาเหล่านี้ส่วนหนึ่งไม่ได้มาจากตัวโฆษณาเลย แต่มาจาก Bot ที่ตอบช้าหรือจำบทสนทนาก่อนหน้าไม่ได้ ทำให้ผู้ใช้ต้องพิมพ์ซ้ำหรือรู้สึกว่าคุยกับระบบที่ไม่ฉลาด

หนึ่งในทางเลือกที่ทีมพัฒนาเริ่มพูดถึงกันมากขึ้นคือการสร้าง LINE Bot บน Cloudflare Workers แทน Serverless Function แบบดั้งเดิม เพราะ Workers มีจุดเด่นเรื่องความเร็วในการเริ่มทำงานที่แทบไม่มี Cold Start และมี Durable Objects ที่ช่วยจัดการสถานะการสนทนาได้ในแบบที่ Function ทั่วไปทำได้ยาก

บทความนี้จะพาดูว่า Workers และ Durable Objects เหมาะกับงานแบบไหนจริง ๆ ไม่เหมาะกับงานแบบไหน และทีมที่กำลังตัดสินใจเลือก Stack สำหรับ Bot ควรพิจารณาอะไรบ้าง โดยเทียบกับแนวทางอื่นที่เคยพูดถึงใน line-webhook-vercel และ line-bot-supabase เพื่อให้เห็นภาพรวมของตัวเลือกทั้งหมด

ทำไมความเร็วในการตอบของ Bot ถึงเกี่ยวกับจำนวนคนที่มาถึงหน้าร้านจริง

เมื่อผู้ใช้กดจากโฆษณาเข้า LINE พวกเขาอยู่ในช่วงที่ความสนใจสูงสุด ถ้า Bot ตอบช้าแม้เพียงไม่กี่วินาที ความสนใจนั้นอาจลดลงเร็วกว่าที่คิด โดยเฉพาะกับผู้ใช้ที่กำลังเปรียบเทียบร้านหลายร้านพร้อมกันในเวลาเดียวกัน การตอบช้าจึงไม่ใช่แค่เรื่องประสบการณ์ผู้ใช้ที่ไม่ดี แต่อาจเป็นจุดที่ทำให้คนที่สนใจจริงหลุดออกจาก Funnel ไปเลยตั้งแต่ขั้นตอนแรก

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

การเข้าใจว่าปัญหาความช้ามีผลจริงต่อพฤติกรรมผู้ใช้ตั้งแต่ขั้นตอนแรกของการสนทนา เป็นเหตุผลที่ทีมพัฒนาบางทีมเริ่มมองหา Runtime ที่ตอบสนองเร็วกว่าและกระจายอยู่ใกล้ผู้ใช้มากกว่า Serverless Function แบบรวมศูนย์จุดเดียว

Cloudflare Workers ทำงานต่างจาก Serverless Function แบบดั้งเดิมยังไง

Cloudflare Workers รันโค้ดอยู่บน Edge Network ที่กระจายอยู่หลายจุดทั่วโลก เมื่อมี Request เข้ามา ระบบจะเลือกจุดที่ใกล้ผู้ใช้ที่สุดให้ประมวลผล ต่างจาก Serverless Function แบบดั้งเดิมที่มักรันอยู่ที่ Region ใด Region หนึ่งเป็นหลัก ทำให้ผู้ใช้ที่อยู่ไกลจาก Region นั้นเจอ Latency สูงกว่า

อีกความต่างสำคัญคือ Workers ออกแบบมาให้เริ่มทำงานเร็วมาก ใช้ V8 Isolate แทนการสร้าง Container หรือ Virtual Machine ใหม่ทุกครั้งเหมือน Serverless Function บางแพลตฟอร์ม ทำให้ปัญหา Cold Start ที่เคยเป็นปัญหาใหญ่ของ Serverless แทบไม่มีผลกับ Workers เลย ซึ่งสำคัญมากสำหรับ Webhook ที่ต้องตอบให้ทันเวลาที่ LINE กำหนด

ข้อจำกัดที่ต้องรู้ก่อนคือ Workers มีข้อจำกัดเรื่อง CPU Time ต่อ Request ที่เข้มงวดกว่า Serverless Function ทั่วไป งานที่ต้องประมวลผลหนักต่อเนื่องนาน ๆ เช่นการประมวลผลไฟล์ขนาดใหญ่ อาจไม่เหมาะกับการรันบน Workers โดยตรง ต้องแยกงานประเภทนี้ออกไปทำที่อื่น

Durable Objects แก้ปัญหาการจำสถานะการสนทนาที่ Serverless ทั่วไปทำได้ยาก

ปัญหาคลาสสิกของ Serverless Function คือแต่ละ Instance ไม่มีหน่วยความจำที่ใช้ร่วมกัน ทำให้การเก็บสถานะการสนทนาแบบ Real-time เช่น ผู้ใช้กำลังอยู่ขั้นตอนไหนของการกรอกแบบฟอร์มหลายขั้นตอน ต้องพึ่งการอ่านเขียน Database ทุกครั้ง ซึ่งเพิ่ม Latency และความซับซ้อนของโค้ด

Durable Objects แก้ปัญหานี้ด้วยการให้แต่ละ Object มีหน่วยความจำและสถานะเป็นของตัวเองที่คงอยู่ระหว่าง Request ต่าง ๆ ได้ และรับประกันว่า Request ที่เกี่ยวกับ Object เดียวกัน เช่น การสนทนาของผู้ใช้คนเดียวกัน จะถูกส่งไปประมวลผลที่ Instance เดียวกันเสมอ ไม่กระจายไปหลาย Instance พร้อมกันจนสถานะสับสน

สำหรับ LINE Bot ที่มี Flow การสนทนาซับซ้อน เช่น ระบบจองคิวที่ต้องถามหลายคำถามต่อเนื่องกัน หรือระบบที่ต้องล็อกไม่ให้สองข้อความจากผู้ใช้คนเดียวกันถูกประมวลผลพร้อมกันจนข้อมูลขัดแย้งกัน Durable Objects ช่วยให้ออกแบบ Logic ได้ตรงไปตรงมากว่าการพยายามจำลองพฤติกรรมนี้ผ่าน Database เพียงอย่างเดียว

Workers กับ Durable Objects เหมาะกับ Bot แบบไหน ไม่เหมาะกับแบบไหน

Bot ที่เหมาะกับแนวทางนี้มักมีลักษณะร่วมกันคือต้องการความเร็วในการตอบสนองสูงมาก มี Traffic กระจายทั่วประเทศหรือหลายประเทศ และมี Flow การสนทนาที่ต้องจำสถานะระหว่างหลายข้อความต่อเนื่องกัน เช่น Bot จองคิวคลินิก Bot ทำแบบทดสอบก่อนเสนอราคา หรือ Bot ที่ต้องล็อกการทำรายการไม่ให้ซ้ำกัน

ในทางกลับกัน Bot ที่ทำงานง่าย ๆ เช่นตอบคำถามที่พบบ่อยแบบไม่ต้องจำบริบทมาก หรือ Bot ที่ Traffic ยังไม่สูงพอจะรู้สึกถึงความต่างของ Latency อาจไม่จำเป็นต้องลงทุนความซับซ้อนในการเรียนรู้ Workers และ Durable Objects ตั้งแต่ต้น เพราะ Stack ที่คุ้นเคยอยู่แล้วอย่าง Node.js Function ธรรมดาก็เพียงพอ

อีกปัจจัยที่ต้องพิจารณาคือทีมมีความคุ้นเคยกับ Ecosystem ของ Cloudflare มากแค่ไหน เพราะ Workers มีวิธีคิดและข้อจำกัดที่ต่างจาก Node.js แบบดั้งเดิมพอสมควร ทีมที่ไม่เคยใช้มาก่อนต้องใช้เวลาเรียนรู้เพิ่ม ซึ่งควรชั่งน้ำหนักกับประโยชน์ที่จะได้จริงก่อนตัดสินใจย้าย Stack ทั้งระบบ

เชื่อม Workers กับฐานข้อมูลภายนอกอย่าง Supabase ต้องระวังอะไร

แม้ Durable Objects จะเก็บสถานะระหว่างการสนทนาได้ดี แต่ข้อมูลระยะยาวอย่างประวัติผู้ใช้หรือข้อมูลออเดอร์ยังต้องเก็บในฐานข้อมูลภายนอกอยู่ดี ซึ่งการเชื่อม Workers กับฐานข้อมูลอย่าง Postgres มีข้อจำกัดที่ต้องรู้ล่วงหน้า เพราะ Workers รันอยู่ใน Edge Network ที่ไม่ได้ใช้ Node.js Runtime เต็มรูปแบบ Library บาง Library ที่เชื่อมต่อ Database แบบดั้งเดิมอาจใช้ไม่ได้ตรง ๆ

ทางแก้ที่ใช้กันบ่อยคือใช้ Client Library เวอร์ชันที่ออกแบบมาสำหรับ Edge Runtime โดยเฉพาะ หรือเชื่อมผ่าน HTTP API แทนการเชื่อมต่อ Database แบบ Connection ตรง ซึ่งช่วยให้ทำงานร่วมกับข้อจำกัดของ Edge Runtime ได้โดยไม่ต้องเปลี่ยนฐานข้อมูลหลักที่ใช้อยู่

จุดที่ควรทดสอบให้แน่ใจก่อนใช้งานจริงคือ Latency ของการเชื่อมต่อจาก Workers ไปยังฐานข้อมูล เพราะถ้าฐานข้อมูลอยู่ไกลจากจุดที่ Workers ประมวลผล ข้อได้เปรียบเรื่องความเร็วที่ Workers มอบให้อาจถูกหักล้างด้วยเวลาที่เสียไปกับการรอฐานข้อมูลตอบกลับ ควรเลือก Region ของฐานข้อมูลให้ใกล้กับกลุ่มผู้ใช้หลักของ Bot ให้มากที่สุด

ทดสอบและ Monitor Bot บน Workers ให้มั่นใจก่อนใช้งานจริง

การทดสอบ Bot ที่ใช้ Durable Objects ต้องครอบคลุมสถานการณ์ที่ผู้ใช้ส่งข้อความหลายข้อความพร้อมกันหรือติด ๆ กันเร็วมาก เพราะเป็นสถานการณ์ที่ต้องพิสูจน์ว่า Object เดียวกันถูกจัดการแบบเรียงลำดับจริง ไม่เกิดการประมวลผลสลับลำดับจนสถานะการสนทนาผิดเพี้ยน ซึ่งเป็นจุดที่ Bug มักซ่อนอยู่และตรวจพบยากถ้าทดสอบแบบส่งข้อความทีละข้อความช้า ๆ

Cloudflare มีเครื่องมือ Analytics และ Logs ในตัวที่ช่วยดูจำนวน Request ความเร็วในการตอบ และ Error Rate ของ Workers ได้ ทีมควรตั้ง Dashboard ติดตามตัวเลขเหล่านี้ตั้งแต่วันแรกที่ Deploy ใช้งานจริง เพื่อจับความผิดปกติได้เร็วก่อนที่ผู้ใช้จำนวนมากจะเจอปัญหา

อีกจุดที่ควรทดสอบคือพฤติกรรมเมื่อ Durable Object ตัวใดตัวหนึ่งเจอ Error ระหว่างประมวลผล เพราะถ้าออกแบบไม่ดี Error ในการสนทนาของผู้ใช้คนหนึ่งอาจทำให้ Object นั้นค้างอยู่ในสถานะผิดปกติต่อไปเรื่อย ๆ จนกว่าจะมีการรีเซ็ต ควรมีกลไก Timeout หรือ Reset สถานะที่ชัดเจนสำหรับกรณีที่ผิดพลาดระหว่างทาง

นอกจากทดสอบด้วยตัวเอง ควรทำ Staging Environment แยกจาก Production ไว้เสมอสำหรับทดลอง Flow การสนทนาใหม่ ๆ ก่อนปล่อยจริง เพราะการแก้ Logic ของ Durable Objects บางครั้งกระทบพฤติกรรมของสถานะเดิมที่ผู้ใช้กำลังสนทนาค้างอยู่ ถ้าไม่มี Staging ทดสอบก่อน ความเสี่ยงที่จะกระทบผู้ใช้จริงระหว่างการปรับปรุงระบบจะสูงขึ้นมาก

เทียบ Cloudflare Workers กับ Serverless Function แบบดั้งเดิมสำหรับ LINE Bot

ตารางนี้สรุปจุดต่างหลักที่ควรใช้ประกอบการตัดสินใจเลือก Stack สำหรับ Bot แต่ละประเภท:

สรุป

ปัญหาคนทักเข้า LINE แล้วหายไปกลางทางไม่ได้มาจากคุณภาพโฆษณาเสมอไป บ่อยครั้งมาจาก Bot ที่ตอบช้าหรือจำบทสนทนาก่อนหน้าไม่ได้ Cloudflare Workers ช่วยแก้ปัญหาความเร็วด้วยการรันใกล้ผู้ใช้ ส่วน Durable Objects ช่วยแก้ปัญหาการจำสถานะที่ Serverless ทั่วไปทำได้ยาก

แต่ทั้งสองเครื่องมือมาพร้อมความซับซ้อนที่ต้องเรียนรู้เพิ่ม เหมาะกับ Bot ที่มี Traffic สูงและ Flow สนทนาซับซ้อนจริง ๆ มากกว่า Bot ทั่วไปที่ยังไม่เจอปัญหานี้ ทีมควรประเมินจากอาการจริงของ Bot ตัวเองก่อนตัดสินใจย้าย Stack ทั้งระบบ

• Workers ตอบเร็วเพราะแทบไม่มี Cold Start และรันใกล้ผู้ใช้หลายจุดทั่วโลก
• Durable Objects เหมาะกับ Flow สนทนาที่ต้องจำสถานะต่อเนื่องและกันการประมวลผลสลับลำดับ
• ยังต้องมีฐานข้อมูลหลักแยกต่างหากสำหรับข้อมูลระยะยาว Workers ไม่ได้แทนที่ Database

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