API เรียกไว on localhost แต่ทำไม Edge Function จริงกลับหน่วงกว่าที่คิด

การทดสอบ API บนเครื่อง localhost มักให้ผลลัพธ์ที่เร็วเสมอ เพราะไม่มี network latency ระหว่างเครื่องกับตัว function เลย โค้ดรันในเครื่องเดียวกันกับที่เรียกใช้ ทำให้นักพัฒนาหลายคนคาดหวังว่าเมื่อ deploy จริงแล้ว performance จะใกล้เคียงกับที่ทดสอบบนเครื่อง แต่ในทางปฏิบัติกลับพบว่า response time ช้าลงอย่างเห็นได้ชัด บางครั้งจากหลักสิบมิลลิวินาทีกลายเป็นหลายร้อยมิลลิวินาที

ทั้ง Cloudflare Workers และ Supabase Edge Functions ต่างโฆษณาตัวเองว่าเป็น edge computing ที่รันใกล้ผู้ใช้ แต่สถาปัตยกรรมเบื้องหลังของทั้งสองแพลตฟอร์มต่างกันมาก ซึ่งส่งผลโดยตรงต่อพฤติกรรมด้าน latency และ cold start ที่นักพัฒนามักไม่รู้จนกว่าจะเจอปัญหาจริงหลัง deploy

บทความนี้จะอธิบายความต่างของสถาปัตยกรรมทั้งสองแพลตฟอร์ม สาเหตุที่ response time ช้าลงหลัง deploy จริง วิธีวัดและวินิจฉัยปัญหา และแนวทางเลือกใช้ที่เหมาะกับแต่ละสถานการณ์

สถาปัตยกรรมของ Workers กับ Supabase Edge Functions ต่างกันตรงไหน

Cloudflare Workers รันบนเทคโนโลยี V8 isolate ซึ่งเป็นกลไกเดียวกับที่ใช้แยก process ใน Chrome browser ทำให้ isolate แต่ละตัวเริ่มทำงานได้เร็วมากโดยไม่ต้องบูต container หรือ virtual machine เต็มรูปแบบ Cloudflare กระจาย isolate เหล่านี้ไปยัง data center หลายร้อยจุดทั่วโลก ทำให้ Worker สามารถรันที่จุดใกล้ผู้ใช้ที่สุดได้จริง

Supabase Edge Functions รันบน Deno runtime ซึ่งเป็น JavaScript/TypeScript runtime ที่ออกแบบมาให้ปลอดภัยและทันสมัยกว่า Node.js แบบดั้งเดิม แต่ Supabase deploy function เหล่านี้ไปยังจำนวน region ที่จำกัดกว่าเครือข่ายของ Cloudflare มาก เพราะ Supabase พึ่งพา infrastructure ของผู้ให้บริการ cloud รายใหญ่ในบาง region เท่านั้น ไม่ได้กระจายทั่วโลกในระดับเดียวกับ Cloudflare

ความต่างนี้หมายความว่าผู้ใช้ที่อยู่ไกลจาก region ที่ Supabase Edge Function ถูก deploy ไป อาจต้องเดินทางข้ามเครือข่ายไกลกว่าที่คำว่า 'edge' สื่อความหมายไว้ ในขณะที่ Worker ของ Cloudflare มีโอกาสสูงกว่าที่จะรันใกล้ผู้ใช้จริง เพราะจำนวนจุดให้บริการที่มากกว่ามาก

Cold Start ของทั้งสองแพลตฟอร์มต่างกันแค่ไหน

Cold start คือช่วงเวลาที่ระบบต้องเตรียม environment ใหม่ก่อนเริ่มรันโค้ดจริง เกิดขึ้นเมื่อไม่มี instance ที่พร้อมใช้งานอยู่แล้วสำหรับ request ที่เข้ามา V8 isolate ของ Workers มี cold start ที่เร็วมากเมื่อเทียบกับ container-based runtime ทั่วไป เพราะไม่ต้องบูตระบบปฏิบัติการหรือโหลด runtime environment ขนาดใหญ่ ทำให้ cold start มักอยู่ในระดับหลักมิลลิวินาที

Deno runtime ที่ Supabase Edge Functions ใช้มี cold start ที่ช้ากว่า V8 isolate โดยธรรมชาติ เพราะต้องเตรียม runtime environment ที่ซับซ้อนกว่า แม้จะเร็วกว่า container แบบดั้งเดิมมาก แต่ก็ยังไม่เร็วเท่า V8 isolate ล้วน ๆ ของ Workers ความต่างนี้ชัดเจนที่สุดในช่วง traffic ต่ำที่ instance ถูกปิดบ่อยแล้วต้อง cold start ใหม่บ่อยตาม

สำหรับแอปที่มี traffic สม่ำเสมอตลอดเวลา ความต่างของ cold start อาจไม่รู้สึกได้มาก เพราะ instance มักถูกเรียกใช้บ่อยพอที่จะอยู่ในสถานะ warm ตลอด แต่สำหรับแอปที่มี traffic ไม่สม่ำเสมอ เช่นมี burst การใช้งานเป็นช่วง ๆ ความต่างของ cold start จะสังเกตเห็นได้ชัดเจนกว่า

ทำไมทดสอบบน Localhost ถึงไม่สะท้อนความจริงหลัง Deploy

การทดสอบบนเครื่อง localhost ไม่มี network latency ระหว่างผู้เรียกกับ function เลย และมักไม่มี cold start เพราะ dev server รันค้างอยู่ตลอดเวลาระหว่างทดสอบ ทำให้ตัวเลข response time ที่เห็นบนเครื่องต่ำกว่าความเป็นจริงมากเมื่อเทียบกับสภาพแวดล้อม production ที่มี network latency จริงและมีโอกาสเจอ cold start

อีกปัจจัยที่มักถูกมองข้ามคือการเรียกฐานข้อมูลระหว่างทดสอบบนเครื่อง มักเป็นการเชื่อมต่อกับฐานข้อมูล local หรือฐานข้อมูล development ที่อยู่ในเครือข่ายเดียวกัน แต่พอ deploy จริง function อาจต้องเรียกฐานข้อมูล production ที่อยู่คนละ region กับจุดที่ function รันอยู่ ทำให้เกิด network latency เพิ่มขึ้นในทุก query ที่เรียก

ทีมที่วัด performance เฉพาะบนเครื่อง localhost แล้วสรุปว่าแอปพร้อม production มักเจอความประหลาดใจหลัง deploy จริง ควรวัด performance จากสภาพแวดล้อม staging ที่ deploy จริงและเรียกฐานข้อมูลจริงเสมอ ไม่ใช่วัดจากเครื่อง dev เพียงอย่างเดียว

ระยะห่างระหว่าง Function กับฐานข้อมูลสำคัญแค่ไหน

Supabase Edge Functions มักถูกใช้คู่กับฐานข้อมูล Postgres ของ Supabase เอง ซึ่งถ้า function กับฐานข้อมูลอยู่ใน region เดียวกัน การเรียก query จะมี latency ต่ำมากเพราะไม่ต้องเดินทางข้ามเครือข่ายไกล แต่ถ้าผู้ใช้ที่เรียก function อยู่ไกลจาก region นั้น ผู้ใช้จะยังเจอ latency จากระยะทางเครือข่ายไปยัง region ที่ function รันอยู่

Cloudflare Workers ที่รันใกล้ผู้ใช้มากกว่า แต่ถ้าต้องเรียกฐานข้อมูล Postgres ภายนอกที่อยู่ region เดียว (เช่นผ่าน Hyperdrive) จุดที่ latency ต่ำคือระหว่างผู้ใช้กับ Worker เท่านั้น ส่วนการเรียกฐานข้อมูลยังต้องเดินทางไปยัง region ที่ฐานข้อมูลตั้งอยู่เหมือนเดิม ทำให้ latency รวมทั้งหมดขึ้นอยู่กับทั้งสองช่วงนี้รวมกัน

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

วัด Latency จริงหลัง Deploy อย่างเป็นระบบ

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

1. deploy function เดียวกันหรือ logic เทียบเท่ากันไปยังทั้งสองแพลตฟอร์มในสภาพแวดล้อม staging ที่ใกล้เคียง production มากที่สุด
2. ใช้เครื่องมือทดสอบจากหลายภูมิภาคทั่วโลก เช่นบริการทดสอบ latency แบบ multi-region เพื่อจำลองผู้ใช้จริงที่กระจายอยู่คนละที่ ไม่ใช่ทดสอบจากจุดเดียว
3. วัดทั้ง cold start latency (เรียกครั้งแรกหลังไม่มี traffic มาสักพัก) และ warm latency (เรียกต่อเนื่องหลาย request) แยกกัน เพราะพฤติกรรมทั้งสองแบบให้ข้อมูลคนละมุม
4. รวม latency ของการเรียกฐานข้อมูลเข้าไปในการวัดด้วย ไม่ใช่วัดแค่เวลาตอบสนองของ function เปล่า ๆ เพราะ query จริงที่เรียกฐานข้อมูลคือส่วนที่มักกินเวลามากที่สุดในหลายกรณี
5. เก็บผลวัดต่อเนื่องเป็นระยะเวลาหนึ่ง ไม่ใช่วัดครั้งเดียวแล้วสรุปทันที เพราะ network latency และพฤติกรรม cold start อาจแปรผันตามช่วงเวลาและปริมาณ traffic จริง

เปรียบเทียบจุดสำคัญระหว่างสองแพลตฟอร์ม

ตารางด้านล่างสรุปความต่างหลักที่ส่งผลต่อการตัดสินใจเลือกใช้งานจริง

เลือกใช้แพลตฟอร์มไหนตามสถานการณ์จริง

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

ทีมที่ต้องการ latency ต่ำที่สุดสำหรับผู้ใช้ที่กระจายอยู่ทั่วโลกจริง หรือมี logic ที่ไม่ต้องพึ่งพาฐานข้อมูลของ Supabase โดยตรง เช่นงาน caching, redirect, หรือ middleware ที่ประมวลผลก่อนส่งต่อไปยัง backend อื่น Workers มักให้ผลลัพธ์ที่ดีกว่าเพราะเครือข่าย edge ที่กว้างกว่ามาก

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

ทำแบบนี้แล้วพัง เพราะเชื่อตัวเลข Localhost แล้วไม่ทดสอบสภาพแวดล้อมจริง

ทีมที่วัด performance เฉพาะบนเครื่อง dev แล้วสัญญากับลูกค้าว่า API จะตอบสนองเร็วในระดับที่วัดได้บนเครื่อง มักเจอปัญหาหลัง deploy จริงที่ response time สูงกว่าที่คาดไว้มาก เพราะไม่ได้นับรวม network latency และ cold start ที่เกิดขึ้นจริงใน production ทำให้ต้องกลับมาแก้ไข SLA ที่ตั้งไว้ผิดพลาดตั้งแต่ต้น

อีกอาการที่พบคือทีมเลือก Supabase Edge Functions เพราะสะดวกในการพัฒนา แต่ไม่ได้ตรวจสอบว่า region ที่ Supabase deploy ให้ตรงกับกลุ่มผู้ใช้หลักหรือไม่ ทำให้ผู้ใช้ที่อยู่ไกลจาก region นั้นเจอ latency สูงกว่าที่คาดไว้ ทั้งที่ชื่อ 'Edge Functions' ให้ความรู้สึกว่าควรรันใกล้ผู้ใช้ทุกที่เสมอ

อาการที่สามคือทีมย้ายจาก Supabase Edge Functions มา Workers เพื่อหวังผล latency ที่ดีขึ้น แต่ยังต่อฐานข้อมูล Postgres เดิมที่อยู่ region เดียวแบบไม่ผ่านการ pool connection ที่เหมาะสม ทำให้ latency ของการเรียกฐานข้อมูลยังสูงเหมือนเดิม เพราะปัญหาที่แท้จริงอยู่ที่ระยะห่างระหว่าง Worker กับฐานข้อมูล ไม่ใช่ตัวแพลตฟอร์มที่รัน function เพียงอย่างเดียว

สรุป

ความต่างระหว่างตัวเลขที่วัดได้บน localhost กับ latency จริงหลัง deploy มาจากสองปัจจัยหลักคือ network latency ที่ไม่มีตอนทดสอบบนเครื่อง และความต่างของสถาปัตยกรรม cold start ระหว่างแพลตฟอร์ม ทีมที่เข้าใจปัจจัยทั้งสองนี้จะตั้งความคาดหวังและ SLA ได้แม่นยำกว่าการเชื่อตัวเลขจากเครื่อง dev เพียงอย่างเดียว

การเลือกระหว่าง Cloudflare Workers กับ Supabase Edge Functions ควรพิจารณาจากตำแหน่งของฐานข้อมูลที่ต้องเรียกใช้และกลุ่มผู้ใช้หลักเป็นสำคัญ ไม่ใช่แค่เชื่อคำว่า 'edge' ในชื่อผลิตภัณฑ์ การทดสอบ workload จริงในสภาพแวดล้อม staging ก่อนตัดสินใจ ยังเป็นวิธีที่แม่นยำที่สุดเสมอ

• Workers รันบน V8 isolate กระจายหลายร้อยจุดทั่วโลก ส่วน Supabase Edge Functions รันบน Deno runtime ที่มี region จำกัดกว่า
• localhost ไม่มี network latency และมักไม่มี cold start จึงไม่สะท้อนความจริงหลัง deploy
• ระยะห่างระหว่าง function กับฐานข้อมูลสำคัญพอ ๆ กับระยะห่างระหว่างผู้ใช้กับ function
• ควรวัด latency จริงจากสภาพแวดล้อม staging หลายภูมิภาค แยกวัด cold start กับ warm latency
• เลือกแพลตฟอร์มตามตำแหน่งฐานข้อมูลและกลุ่มผู้ใช้หลัก ไม่ใช่เชื่อคำว่า edge ในชื่อผลิตภัณฑ์เพียงอย่างเดียว

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