เปิดใช้งาน Bot ได้ไม่ถึงเดือน ผู้ใช้เริ่มบ่นว่าทักไปแล้วเงียบ ต้องแก้ยังไง

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

หลายทีมเลือกแก้ปัญหาด้วยการย้ายฐานข้อมูลมาใช้ Supabase เพราะเห็นว่าเป็นแพลตฟอร์มที่ตั้งค่าง่ายและมี Edge Functions ในตัว แต่การย้ายมาใช้ Supabase เพียงอย่างเดียวไม่ได้แก้ปัญหาทุกจุดโดยอัตโนมัติ ถ้าไม่เข้าใจว่าอะไรคือคอขวดจริงของระบบตัวเอง อาจย้ายมาแล้วเจอปัญหาเดิมในรูปแบบใหม่

บทความนี้จะพาไล่ดูว่า Postgres และ Edge Functions ของ Supabase ช่วยแก้จุดไหนได้จริง จุดไหนที่ยังต้องออกแบบ Logic เพิ่มเติมเอง และวิธีวัดว่าปัญหาความช้าที่เจออยู่มาจากฝั่งไหนกันแน่ รวมถึงส่วนที่เชื่อมกับการรับ Event จาก LINE ตามที่พูดถึงใน line-webhook-vercel และทางเลือก Runtime แบบ Edge อีกแบบใน line-bot-cloudflare-workers

ก่อนย้ายอะไร ต้องรู้ก่อนว่าคอขวดจริงอยู่ตรงไหน

ปัญหาที่พบบ่อยที่สุดของทีมที่แก้ปัญหา Bot ช้าคือรีบเปลี่ยนเครื่องมือทั้งระบบโดยไม่ได้วัดก่อนว่าเวลาที่หายไปอยู่ตรงจุดไหน บาง Bot ช้าเพราะ Query ฐานข้อมูล บาง Bot ช้าเพราะเรียก API ภายนอกอย่าง AI Model ที่ตอบช้า และบาง Bot ช้าเพราะ Logic ในโค้ดเองมีการวนลูปหรือคำนวณที่ไม่จำเป็น

วิธีที่ตรงไปตรงมาที่สุดคือใส่การจับเวลา (Timing) ไว้ในแต่ละขั้นตอนของการประมวลผล Event ตั้งแต่รับ Webhook ไปจนถึงส่งข้อความตอบกลับ แล้วเก็บตัวเลขไว้ดูว่าขั้นตอนไหนกินเวลามากที่สุด ถ้าไม่ทำขั้นตอนนี้ก่อน การย้ายไป Supabase อาจแก้ปัญหาแค่บางส่วนหรือไม่แก้อะไรเลยถ้าคอขวดจริงอยู่ที่อื่น

ในหลายกรณีที่ทีมพบว่า Database คือคอขวดจริง มักมาจากสาเหตุที่ซ้ำกัน เช่น ไม่มี Index บนคอลัมน์ที่ใช้ค้นหาบ่อย เช่น User ID หรือใช้ Connection แบบเปิดใหม่ทุกครั้งที่มี Request เข้ามาแทนที่จะใช้ Connection Pool ทำให้เสียเวลาเชื่อมต่อซ้ำ ๆ โดยไม่จำเป็น

Index และโครงตารางที่ถูกต้องช่วยได้มากกว่าที่คิด

Postgres ของ Supabase เป็นฐานข้อมูลเชิงสัมพันธ์ที่ทำงานเร็วมากถ้าออกแบบ Index ถูกต้อง แต่ก็ช้าได้ไม่ต่างจากฐานข้อมูลอื่นถ้าตารางไม่มี Index บนคอลัมน์ที่ Query บ่อย สำหรับ LINE Bot คอลัมน์ที่ควรมี Index แทบทุกกรณีคือ LINE User ID เพราะแทบทุก Query ของ Bot จะเริ่มจากการค้นหาข้อมูลผู้ใช้คนนี้ก่อนเสมอ

อีกจุดที่มักถูกมองข้ามคือการเก็บ Conversation History ไว้ในตารางเดียวที่โตขึ้นเรื่อย ๆ โดยไม่มีการจัดการ ถ้า Query ประวัติแชทของผู้ใช้แต่ละครั้งต้องสแกนตารางที่มีข้อมูลหลายล้านแถวโดยไม่มี Index หรือไม่มีการจำกัดช่วงเวลา ความเร็วจะแย่ลงเรื่อย ๆ ตามจำนวนข้อมูลที่เพิ่มขึ้น ไม่ใช่คงที่

การใช้ Supabase Dashboard ดู Query Performance หรือใช้คำสั่ง EXPLAIN ANALYZE ตรวจ Query ที่สงสัยว่าช้า เป็นขั้นตอนที่ควรทำก่อนสรุปว่า 'Database ช้า' อย่างเลื่อนลอย เพราะบางครั้งปัญหาไม่ใช่ตัวฐานข้อมูล แต่เป็น Query ที่เขียนไม่ดีเพียงข้อเดียว

Connection Pooling สำคัญแค่ไหนเมื่อ Bot ทำงานบน Serverless

ถ้า LINE Bot รันอยู่บน Serverless Function เช่นบน Vercel หรือ Cloudflare ทุกครั้งที่มี Request เข้ามา Function อาจถูกสร้าง Instance ใหม่ ซึ่งถ้าแต่ละ Instance เปิด Connection ใหม่ไปยัง Postgres โดยตรง เมื่อมี Traffic เข้ามาพร้อมกันมาก จำนวน Connection ที่เปิดพร้อมกันอาจเกินขีดจำกัดที่ Postgres รองรับได้ ทำให้ Request บางส่วนถูกปฏิเสธหรือรอนาน

Supabase มี Connection Pooler ในตัวที่ช่วยแก้ปัญหานี้ โดยทำหน้าที่เป็นตัวกลางที่จัดการ Connection แทนที่แต่ละ Function จะต่อตรงไปยัง Database เอง ทำให้รองรับจำนวน Request พร้อมกันได้มากขึ้นโดยไม่ทำให้ Database ล้น การตั้งค่าให้ Bot ต่อผ่าน Pooler แทนการต่อตรงจึงเป็นขั้นตอนสำคัญที่มักถูกข้ามไปตอนเริ่มต้นพัฒนา

ทีมที่เพิ่งเริ่มพัฒนาบน Local มักต่อ Database แบบตรงเพราะสะดวกและไม่เจอปัญหาเพราะ Traffic น้อย แต่พอ Deploy ขึ้นใช้งานจริงและมีผู้ใช้เพิ่มขึ้น ปัญหา Connection ล้นมักโผล่มาแบบไม่ทันตั้งตัว ควรตั้งค่าให้ใช้ Pooler ตั้งแต่ตอน Deploy จริงครั้งแรก ไม่ใช่รอให้เจอปัญหาก่อนค่อยแก้

Edge Functions ช่วยตรงไหน และไม่ได้ช่วยตรงไหน

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

แต่ต้องเข้าใจให้ชัดว่า Edge Functions ไม่ได้ทำให้ Query ฐานข้อมูลที่ช้าอยู่แล้วเร็วขึ้นเอง และไม่ได้ทำให้การเรียก AI Model ภายนอกที่ตอบช้าเร็วขึ้นด้วย ถ้าคอขวดจริงอยู่ที่สองจุดนี้ การย้ายมาใช้ Edge Functions เพียงอย่างเดียวจะช่วยได้แค่ส่วนน้อย ไม่ได้แก้ปัญหาหลักที่ผู้ใช้รู้สึกว่า Bot ตอบช้า

จุดที่ Edge Functions เหมาะมากคืองานที่เป็น Logic เบา ๆ อย่างการตรวจสอบสิทธิ์ผู้ใช้ หรือการ Route Event ไปยังจุดประมวลผลที่เหมาะสม ส่วนงานที่ต้องประมวลผลหนักหรือเรียก AI ที่ใช้เวลานาน ควรพิจารณาว่าต้องแยกออกไปทำแบบ Background Task หรือผ่านคิว เหมือนหลักการที่ใช้ในระบบ Webhook ทั่วไป

Cache ข้อมูลที่ถูกเรียกซ้ำบ่อยแทนการ Query ทุกครั้ง

LINE Bot จำนวนมากมี Pattern การใช้งานที่ Query ข้อมูลเดิมซ้ำ ๆ ในช่วงเวลาสั้น ๆ เช่น ข้อมูลโปรไฟล์ผู้ใช้ หรือค่า Config ของ Bot ที่ไม่เปลี่ยนบ่อย การ Query ข้อมูลแบบนี้จาก Database ทุกครั้งที่มี Event เข้ามาเป็นการใช้ทรัพยากรเกินความจำเป็น

การเพิ่ม Cache Layer เช่นใช้ Redis หรือ Cache ในหน่วยความจำระดับ Edge สำหรับข้อมูลที่เปลี่ยนไม่บ่อย ช่วยลดจำนวน Query ที่ยิงไปยัง Postgres ได้มาก โดยเฉพาะในช่วง Traffic สูง ซึ่งเป็นช่วงที่ Database เสี่ยงเป็นคอขวดที่สุดพอดี

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

Row Level Security ของ Supabase สำคัญกับ Bot ที่มีหลายผู้ใช้

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

Supabase มีฟีเจอร์ Row Level Security ที่ตั้งกฎไว้ในระดับ Database ได้เลยว่าใครเข้าถึงแถวข้อมูลไหนได้บ้าง ทำให้แม้โค้ดฝั่งแอปพลิเคชันจะมีจุดผิดพลาด ฐานข้อมูลก็ยังปฏิเสธการเข้าถึงที่ไม่ได้รับอนุญาตอยู่ดี เป็นเกราะป้องกันอีกชั้นที่มีค่ามากสำหรับระบบที่มีข้อมูลผู้ใช้จำนวนมาก

การตั้งค่า RLS ต้องวางแผนตั้งแต่ตอนออกแบบ Schema เพราะถ้าเปิดใช้ทีหลังเมื่อระบบมีข้อมูลและ Logic ซับซ้อนแล้ว อาจต้องไล่แก้ Query จำนวนมากที่เขียนไว้โดยไม่ได้คำนึงถึงกฎการเข้าถึงตั้งแต่แรก

เทียบแนวทางแก้ปัญหา Bot ตอบช้าตามสาเหตุที่แท้จริง

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

ขั้นตอนย้ายจริงจากระบบเดิมมาใช้ Supabase โดยไม่ทำ Bot ล่มระหว่างทาง

ทีมที่มี Bot ใช้งานจริงอยู่แล้วมักกังวลว่าการย้ายฐานข้อมูลจะทำให้ระบบหยุดทำงานชั่วคราวหรือข้อมูลผู้ใช้เสียหาย วิธีที่ปลอดภัยกว่าการย้ายทีเดียวทั้งหมดคือแบ่งเป็นขั้นตอนที่ทดสอบได้ทีละจุด เริ่มจากตั้ง Supabase Project ใหม่และ Migrate โครงสร้างตารางไปก่อน โดยยังไม่ตัดการเชื่อมต่อกับระบบเดิม

ขั้นถัดมาคือทำสคริปต์ย้ายข้อมูลเก่าจากฐานข้อมูลเดิมไปยัง Supabase แบบ Batch เล็ก ๆ พร้อมตรวจสอบว่าจำนวนแถวและค่าที่สำคัญตรงกันทุกครั้งหลังย้าย แทนที่จะเชื่อว่าสคริปต์ทำงานถูกต้องโดยไม่ตรวจ ความผิดพลาดเล็ก ๆ ในขั้นตอนนี้ เช่น Encoding ของข้อความภาษาไทยผิดเพี้ยน มักตรวจพบยากถ้าไม่เทียบข้อมูลอย่างละเอียด

เมื่อข้อมูลย้ายครบและตรวจสอบผ่านแล้ว ให้เริ่มสลับ Traffic บางส่วนไปใช้ระบบใหม่ก่อน เช่น 5-10 เปอร์เซ็นต์ของผู้ใช้ แล้วเฝ้าดู Log และ Error Rate สักระยะก่อนค่อยขยับสัดส่วนเพิ่มขึ้น วิธีนี้ทำให้ถ้าเจอปัญหาที่ไม่คาดคิด ผลกระทบจะจำกัดอยู่แค่ผู้ใช้กลุ่มเล็ก ไม่กระทบทั้งระบบพร้อมกัน และยังเก็บระบบเดิมไว้เป็นทางถอยได้จนกว่าจะมั่นใจว่าระบบใหม่เสถียรจริง

สรุป

Supabase ช่วยแก้ปัญหา Bot ตอบไม่ทันได้จริงเมื่อคอขวดอยู่ที่ Database หรือ Connection ผ่าน Postgres ที่ปรับ Index และ Connection Pooling ได้ตรงจุด บวกกับ Edge Functions ที่ลด Latency เครือข่าย แต่ทั้งหมดนี้ต้องเริ่มจากการวัดว่าคอขวดจริงอยู่ตรงไหนก่อนเสมอ ไม่ใช่ย้ายทั้งระบบเพราะเชื่อว่าน่าจะช่วยได้

ทีมที่ประสบความสำเร็จในการแก้ปัญหานี้มักไม่ได้แก้ทีเดียวจบ แต่ค่อย ๆ วัด ปรับ และเฝ้าดูผลลัพธ์เป็นรอบ ๆ ตั้งแต่ Index, Pooling, Cache ไปจนถึง Row Level Security ซึ่งแต่ละส่วนแก้คนละปัญหาและควรใช้ร่วมกันไม่ใช่เลือกใช้แค่อย่างเดียว

• วัดเวลาแต่ละขั้นตอนก่อนสรุปว่าคอขวดอยู่ตรงไหน ก่อนตัดสินใจย้ายเครื่องมือ
• ต่อ Database ผ่าน Connection Pooler เสมอเมื่อรันบน Serverless Function
• Edge Functions ช่วยลด Latency เครือข่าย แต่ไม่ได้ทำให้ Query ช้าหรือ API ภายนอกเร็วขึ้น

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