Edge Computing สำหรับเว็บไซต์อิสระ: กรณีใช้งานและประสิทธิภาพของ Cloudflare Workers/Vercel Edge
หนึ่ง Edge Computing คืออะไรกันแน่ และเกี่ยวข้องกับ CDN อย่างไร
CDN แบบเดิมแค่แคชไฟล์ static เมื่อผู้ใช้ส่งคำขอมาก็คืนค่าแคชทันที ส่วน Edge Computing จะรันโค้ด JavaScript สั้น ๆ บนโหนด CDN เพื่อตัดสินใจเชิงลอจิกก่อนส่งคำตอบกลับ เช่น เปลี่ยนหน้าเว็บตามตำแหน่งภูมิศาสตร์ของผู้ใช้ เลือกเวอร์ชันที่จะแสดงตาม cookie หรือตรวจสอบว่า JWT ยังใช้ได้หรือไม่ ลอจิกชั้นนี้ทำงานบนโหนดที่ห่างจากผู้ใช้แค่ไม่กี่สิบมิลลิวินาที จึงไม่ต้องกลับไปที่เซิร์ฟเวอร์ต้นทาง
ข้อแตกต่างจาก Server-Side Rendering (SSR): SSR รันบนเซิร์ฟเวอร์ของคุณเอง ผู้ใช้ทั่วโลกต้องเชื่อมต่อข้ามทวีปมาที่เซิร์ฟเวอร์เครื่องนั้น ส่วน Edge Functions รันพร้อมกันบนโหนดกว่า 300 แห่งทั่วโลก ผู้ใช้แค่เชื่อมต่อกับโหนดที่ใกล้ที่สุด สำหรับเว็บไซต์ B2B อิสระที่ทำการค้าข้ามพรมแดน ความต่างของระยะทางนี้ตัดสินโดยตรงว่า TTFB จะเป็น 100 มิลลิวินาทีหรือ 800 มิลลิวินาที ดูความสัมพันธ์ระหว่าง CDN กับ Edge ได้ที่CDN เร่งความเร็วทั่วโลก。
ข้อสังเกตที่ขัดกับสัญชาตญาณ: Edge Computing ไม่ใช่ “เซิร์ฟเวอร์ที่เร็วกว่า” แต่เป็น “เซิร์ฟเวอร์ที่เล็กกว่า” Edge Function แต่ละตัวมีเพดานเวลา CPU ที่เข้มงวด ทำการประมวลผลหนัก ๆ ไม่ได้ ถ้าคุณย้ายลอจิกคิวรีฐานข้อมูลที่ใช้เวลา 200 มิลลิวินาทีไป Edge ผลลัพธ์จะช้ากว่ารันบนเซิร์ฟเวอร์ต้นทางถึง 3 เท่าขึ้นไป เพราะระยะทางเครือข่ายจากโหนด Edge ไปฐานข้อมูลไกลกว่า
| สภาพแวดล้อมที่รัน | ตำแหน่งที่รัน | เพดานเวลา CPU | การเริ่มต้นจากศูนย์ | การเข้าถึงฐานข้อมูล | รูปแบบค่าใช้จ่าย |
|---|---|---|---|---|---|
| เซิร์ฟเวอร์แบบเดิม (VPS) | ศูนย์ข้อมูลเดียว | ไม่มีเพดานตายตัว | ไม่มี (ทำงานตลอด) | ในเครื่อง/เครือข่ายภายใน เร็ว | รายเดือน คงที่ |
| Cloudflare Workers | โหนดทั่วโลก 300+ แห่ง | ฟรี 10 มิลลิวินาที/แบบเสียเงิน 30 มิลลิวินาที | ใกล้ศูนย์ (V8 isolate) | ต้องเชื่อมต่อฐานข้อมูลภายนอก ช้า | คิดตามจำนวนคำขอ |
| Vercel Edge Functions | โหนดทั่วโลก 25+ แห่ง | สูงสุด 30 วินาที | 10 ถึง 50 มิลลิวินาที | รองรับ Edge DB | คิดตามระยะเวลาที่เรียกใช้ |
| AWS Lambda@Edge | โหนด CloudFront ทั่วโลก | สูงสุด 5 วินาที | 10 ถึง 100 มิลลิวินาที | ต้องเชื่อมต่อ RDS ผ่านอินเทอร์เน็ตสาธารณะ | คิดตามคำขอ+ระยะเวลา |
สอง สามกรณีที่คุ้มค่าจะใช้ Edge Computing จริง ๆ
สถานการณ์แรก: รีไดเรกต์ตามตำแหน่งทางภูมิศาสตร์และภาษา เว็บไซต์ที่ออกสู่ตลาดต่างประเทศ ผู้ใช้จากเยอรมนีเข้ามาจะถูกพาไปที่เวอร์ชันภาษาเยอรมัน /de/ โดยอัตโนมัติ ส่วนผู้ใช้จากตะวันออกกลางจะไปที่เวอร์ชันภาษาอาหรับ /ar/ วิธีแบบเดิมคืออ่านฐานข้อมูล IP บนเซิร์ฟเวอร์เพื่อตัดสินใจ ทุกคำขอต้องกลับไปที่ต้นทาง แต่ถ้าใช้ Cloudflare Workers เขียนโค้ดแค่ 10 บรรทัด ก็สามารถคืนค่า 301 ตามประเทศของ IP ได้ที่เอดจ์โดยตรง ทำให้ TTFB ลดจาก 400 มิลลิวินาทีเหลือ 50 มิลลิวินาที วิธีตั้งค่า hreflang สำหรับเว็บไซต์หลายภาษา ดูที่การติดตั้ง hreflang สำหรับหลายภาษา。
สถานการณ์ที่สอง: การแบ่งทราฟฟิกสำหรับ A/B Testing คุณอยากทำหน้าแรกเป็นสองเวอร์ชัน ให้ผู้ใช้ 50% เห็นเวอร์ชัน A และอีก 50% เห็นเวอร์ชัน B วิธีแบบเดิมคืออ่าน cookie ฝั่งเซิร์ฟเวอร์แล้วตัดสินใจว่าจะเรนเดอร์เวอร์ชันไหน วิธีแบบเอดจ์ง่ายกว่า: Workers ใช้ค่าแฮชของ cookie เขียนทับเส้นทางทรัพยากรใน HTML โดยตรง หรือฉีดตัวแปรที่แตกต่างกันเข้าไป โดยต้นทางไม่รับรู้เลย การแบ่งทราฟฟิกเสร็จภายใน 10 มิลลิวินาที ไม่กระทบ TTFB
สถานการณ์ที่สาม: การยืนยันตัวตนแบบเบาและการป้องกันบอต คำขอที่ผู้ใช้ส่งมาหลังล็อกอิน จะถูกตรวจสอบความถูกต้องของ JWT ที่เอดจ์ก่อน ถ้าไม่ถูกต้องจะคืนค่า 401 ทันทีโดยไม่กลับไปที่ต้นทาง วิธีนี้ต้นทางจะจัดการเฉพาะคำขอที่ถูกต้องเท่านั้น ประหยัดทั้งแบนด์วิดท์และ CPU การป้องกันบอตก็ทำที่เอดจ์ได้เช่นกัน: ถ้าตรวจพบ UA ที่น่าสงสัยหรือความถี่คำขอสูงเกินไป จะคืนหน้าท้าทายทันที ไม่ปล่อยให้คำขอไปถึงต้นทาง
| สถานการณ์ | วิธีทำที่เอดจ์ | ผลตอบแทนด้านประสิทธิภาพ | ปริมาณงานพัฒนา | ลำดับความสำคัญที่แนะนำ |
|---|---|---|---|---|
| รีไดเรกต์ตามภูมิศาสตร์ | Workers อ่าน request.cf.country | TTFB ลดลง 50 ถึง 150 มิลลิวินาที | ครึ่งวัน | สูง |
| การแบ่งทราฟฟิก A/B Testing | Workers แบ่งตามแฮชของ cookie | ไม่เพิ่ม TTFB | 1 ถึง 2 วัน | ปานกลาง |
| การยืนยันตัวตน JWT ที่เอดจ์ | ตรวจสอบ token ที่เอดจ์ ถ้าไม่ถูกต้องปฏิเสธทันที | โหลดต้นทางลดลง 20% ถึง 40% | 2 วัน | สูง |
| การป้องกันบอต/จำกัดอัตรา | ตรวจสอบ UA และความถี่ที่เอดจ์ | คำขออันตรายไม่กลับไปที่ต้นทาง | 1 วัน | สูง |
| การเรนเดอร์หน้าแบบเฉพาะบุคคล | ประกอบชิ้นส่วน HTML ที่เอดจ์ | ได้ผลเฉพาะชิ้นส่วนที่ซ้ำกัน | 3 ถึง 5 วัน | ต่ำ |
สาม กับดักสองข้อที่ไม่ควรใช้เอดจ์คอมพิวติ้ง
กับดักแรก: ย้ายการคิวรีฐานข้อมูลไปที่เอดจ์ หลายคนคิดว่า “เอดจ์คอมพิวติ้งล้ำมาก” เลยย้ายตรรกะการคิวรีของศูนย์ผู้ใช้ขึ้นไปด้วย ผลคือโหนดเอดจ์เชื่อมต่อกับฐานข้อมูลระยะไกล การคิวรีหนึ่งครั้งใช้เวลาไปกลับบนเครือข่ายถึง 200 มิลลิวินาที ช้ากว่าการคิวรีในเครื่องที่ต้นทาง 5 เท่า ฟังก์ชันเอดจ์เหมาะกับตรรกะแบบ “ไร้สถานะ คำนวณเบา พึ่งพาแคช” ไม่เหมาะกับตรรกะที่ “ต้องคิวรีฐานข้อมูล”
กับดักที่สอง: ย้าย SSR ทั้งหมดไปที่เอดจ์ โหมด Edge Runtime ของ Next.js รัน React rendering บนโหนดเอดจ์ของ Vercel ได้จริง แต่การเรนเดอร์หน้าที่ซับซ้อนอาจใช้ CPU เกิน 100 มิลลิวินาที ชนเพดานของแพ็กเกจฟรี หรือไม่ก็ cold start ทำให้ผู้ใช้ที่เข้าครั้งแรกต้องรอนานขึ้น 50 มิลลิวินาที การเรนเดอร์ฝั่งเซิร์ฟเวอร์ที่ซับซ้อนยังควรทำที่ต้นทาง เอดจ์ทำแค่ชั้นกลางแบบเบา ๆ เท่านั้น วิธีจัดการสคริปต์ของบุคคลที่สาม ดูที่การจัดการสคริปต์ของบุคคลที่สาม。
ตัวอย่างสถานการณ์จริง: ผลิตภัณฑ์ SaaS ที่ออกสู่ตลาดต่างประเทศ มีหน้าแดชบอร์ดผู้ใช้ที่ต้องดึงข้อมูลจากฐานข้อมูลมาเรนเดอร์ ทีมงานเริ่มต้นด้วยความตื่นเต้นโดยเขียนหน้านี้ใหม่ด้วย Vercel Edge Runtime แต่กลับพบว่าโหนด Edge มี latency ไปยังฐานข้อมูล AWS RDS ของพวกเขาสูงถึง 80 มิลลิวินาที เมื่อรวมกับเวลาเรนเดอร์แล้ว TTFB กลับเพิ่มจาก 250 มิลลิวินาทีเป็น 450 มิลลิวินาที ต่อมาพวกเขาย้ายแดชบอร์ดกลับไปที่ต้นทาง และให้ Edge ทำเพียงตรวจสอบการเข้าสู่ระบบและแบ่งเส้นทาง TTFB จึงกลับมาอยู่ที่ 250 มิลลิวินาที
| หลุมพราง | ข้อดีที่ดูเหมือนจะได้ | ผลลัพธ์ที่ตามมา | วิธีที่ถูกต้อง |
|---|---|---|---|
| ย้ายการคิวรีฐานข้อมูลไปที่ Edge | “ใกล้ผู้ใช้มากขึ้น” | เครือข่ายจาก Edge ไปยัง DB ไกล latency เพิ่มขึ้น 3 ถึง 5 เท่า | เก็บการคิวรี DB ไว้ที่ต้นทาง Edge ทำเพียงอ่านจากแคช |
| รัน SSR ทั้งเว็บบน Edge | “เร่งความเร็วทั่วโลก” | CPU เกินขีดจำกัด / cold start ช้า TTFB กลับเพิ่มขึ้น | Edge ทำเพียงชั้นกลาง การเรนเดอร์เก็บไว้ที่ต้นทาง |
| อ่านเขียนไฟล์จำนวนมาก | “ประมวลผลในเครื่อง” | Edge ไม่มีดิสก์ถาวร หน่วยความจำจำกัด | การจัดการไฟล์ใช้ API ของ object storage |
| งานคำนวณระยะยาว | “ขนานกันเร็วขึ้น” | CPU หมดเวลาเกิดข้อผิดพลาด 1102 ทันที | แยกเป็นงานย่อยหรือส่งผ่าน message queue |
สี่、ต้นทุนและการเลือกใช้: Cloudflare Workers vs Vercel Edge
Cloudflare Workers และ Vercel Edge Functions เป็นสองแพลตฟอร์ม Edge ที่เว็บไซต์อิสระนิยมใช้มากที่สุดในตอนนี้ การเลือกใช้หลัก ๆ ดูจาก tech stack และขนาดทราฟฟิกของคุณ Cloudflare Workers ใช้ V8 isolate cold start เกือบเป็นศูนย์ แพ็กเกจฟรีให้ 100,000 คำขอต่อวัน เหมาะมากสำหรับทำ routing และ authentication แบบเบา ๆ ส่วน Vercel Edge Functions ผสานรวมกับ Next.js อย่างลึกซึ้ง ถ้าคุณใช้ Next.js อยู่แล้ว ต้นทุนการย้ายต่ำที่สุด แต่ cold start ช้ากว่า Workers
ด้านต้นทุน Cloudflare แพ็กเกจเสียเงินเริ่มที่ 5 ดอลลาร์/เดือน รวม 10 ล้านคำขอ ส่วน Vercel Pro เริ่มที่ 20 ดอลลาร์/เดือน ฟังก์ชัน Edge คิดค่าบริการตามเวลาที่ประมวลผล ถ้าทราฟฟิกเยอะบิลจะพุ่งเร็ว เว็บไซต์อิสระ B2B ขนาดกลางที่มี PV ต่อเดือนไม่เกิน 100,000 แพ็กเกจฟรีของ Cloudflare ก็เพียงพอแล้ว จะมอนิเตอร์ประสิทธิภาพอย่างไร ดูที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์。
| มิติ | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| การเริ่มต้นจากศูนย์ | เกือบเป็นศูนย์ (V8) | 10 ถึง 50 มิลลิวินาที | 10 ถึง 100 มิลลิวินาที |
| โควตาฟรี | 100,000 คำขอ/วัน | 100GB-hours/เดือน | 1 ล้านคำขอ/เดือน |
| จุดเริ่มต้นแบบเสียเงิน | 5 ดอลลาร์/เดือน | 20 ดอลลาร์/เดือน | ตามการใช้งาน ไม่มีรายเดือน |
| ภาษาที่ใช้พัฒนา | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| เฟรมเวิร์กที่เหมาะ | ฟังก์ชันล้วน/มิดเดิลแวร์ | ผสานรวมกับ Next.js อย่างลึกซึ้ง | เว็บในระบบนิเวศ AWS |
| ความครอบคลุมของโหนด | 300+ เมือง | 25+ ประเทศ | CloudFront ทั่วโลก |
FAQ คำถามที่พบบ่อย
แพ็กเกจฟรีของ Cloudflare Workers พอใช้จริงหรือ?
ฟังก์ชัน Edge กับแคช CDN มีความสัมพันธ์กันอย่างไร?
Vercel Edge Functions กับ Cloudflare Workers อันไหนเร็วกว่ากัน?
edge function ทำ SEO optimization ได้ไหม?
edge function เกิดข้อผิดพลาดแล้ว rollback ยังไง?
กรณีไหนที่ edge computing ไม่ได้ทำให้เว็บเร็วขึ้น?
ทิ้งท้าย
edge computing เป็นวิธีปรับแต่งแบบ “เล็กแต่สวย” ไม่ใช่การปฏิวัติสถาปัตยกรรมทั้งเว็บไซต์ มันแก้คอขวดเฉพาะเจาะจงอย่าง “ทุก request ต้องกลับไปที่ origin” เหมาะกับงานอย่าง routing เบาๆ, authentication, การแบ่ง traffic ถ้าคุณทำด้วยความคาดหวังว่า “ขึ้น edge แล้วทั้งเว็บจะเร็วขึ้นเป็นเท่าตัว” มีโอกาสสูงที่จะผิดหวัง — เพราะความช้าส่วนใหญ่ช้าที่การ query ฐานข้อมูลและสคริปต์ของบุคคลที่สาม ไม่ใช่ระยะทางเครือข่าย
คำแนะนำในการเริ่มต้นคือเริ่มจากสถานการณ์ที่เล็กที่สุดก่อน: ใช้ Cloudflare Workers ทำการเปลี่ยนเส้นทางตามภูมิศาสตร์ เพื่อพาผู้ใช้ชาวเยอรมันไปยังหน้าเวอร์ชันภาษาเยอรมันโดยอัตโนมัติ การแก้นี้ใช้เวลาครึ่งวันก็ขึ้นระบบได้ ผลตอบแทนด้านประสิทธิภาพเห็นได้ทันที และความเสี่ยงต่ำที่สุด พอรันนิ่งสองสัปดาห์แล้วค่อยพิจารณาเพิ่มการแบ่งทราฟฟิกแบบ A/B หรือการยืนยันตัวตนที่ edge อย่าเพิ่งคิดย้ายทั้งเว็บไปที่ edge ตั้งแต่แรก
ประโยคที่จำง่ายๆ: edge computing คือจุดรับส่งพัสดุที่ใกล้ผู้ใช้ที่สุด ไม่ใช่คลังสินค้าที่ใกล้ฐานข้อมูลที่สุด — เอาวิธีคัดแยกไปไว้ที่นั่น อย่าเอาวิธีเก็บคลังสินค้าย้ายไปด้วย