← กลับไปหน้าบทความ
ขั้นสูง (MarTech)

นักพัฒนาคนเดียวดูแล API วันละหมื่น Request จะเลือก Vercel หรือ Cloudflare Workers ดี

ทีมบรรณาธิการ linli12 ส.ค. 04:52อัปเดต 12 ส.ค. 04:52อ่าน 5 นาที
นักพัฒนาคนเดียวดูแล API วันละหมื่น Request จะเลือก Vercel หรือ Cloudflare Workers ดี
บทความนี้จัดทำเพื่อความรู้ ชื่อธุรกิจ ตัวเลข หรือบทสนทนาที่ไม่มีแหล่งอ้างอิงกำกับเป็นกรณีตัวอย่างเพื่ออธิบายแนวคิด ดูรายละเอียดที่ นโยบายกองบรรณาธิการ

สรุปสั้น ๆ

Vercel เหมาะกับทีมที่สร้างเว็บแอปเต็มรูปแบบด้วย Next.js และต้องการ Developer Experience ที่ครบวงจร ส่วน Cloudflare Workers เหมาะกับ Workload ที่เป็น API เบา ๆ ทำงานสั้น ๆ จำนวนมากและต้องการต้นทุนต่ำที่สุดต่อ Request เพราะ Cloudflare คิดราคาตาม CPU Time จริงไม่ใช่ตามเวลาที่ Function ทำงานทั้งหมด ซึ่งถูกกว่ามากสำหรับงานที่รอ I/O นาน

นักพัฒนาอิสระคนหนึ่งที่ดูแล API สำหรับแอป Mobile ของตัวเองเขียนมาถามว่า 'ผมมี Request เข้ามาวันละประมาณหมื่นครั้ง ตอนนี้ใช้ Vercel อยู่ แต่เห็นเพื่อนบอกว่า Cloudflare Workers ถูกกว่าเยอะ ควรย้ายไหม' คำถามนี้ฟังดูง่ายแต่คำตอบขึ้นอยู่กับรายละเอียดของ Workload จริง ๆ ที่ API นั้นทำอยู่ ไม่ใช่แค่ดูราคาต่อ Request เปรียบเทียบกันตรง ๆ

ทั้ง Vercel และ Cloudflare Workers ให้บริการรันโค้ดแบบ Serverless ที่กระจายอยู่ใกล้ผู้ใช้ทั่วโลก แต่สถาปัตยกรรมเบื้องหลังต่างกันพอสมควร Vercel เติบโตมาจากการเป็นแพลตฟอร์ม Deploy เว็บแอป โดยเฉพาะ Next.js ส่วน Cloudflare Workers เติบโตมาจาก CDN และ Edge Network ที่เดิมทำหน้าที่ป้องกัน DDoS และ Cache เนื้อหา ความต่างของจุดเริ่มต้นนี้ส่งผลถึง Runtime, Pricing และข้อจำกัดที่ต่างกันอย่างมีนัยสำคัญ

บทความนี้จะไล่เทียบทีละมิติที่นักพัฒนาคนเดียวหรือทีมเล็กควรรู้ก่อนตัดสินใจ โดยเฉพาะกรณี API ที่มี Traffic สูงแต่ Logic แต่ละ Request ไม่ซับซ้อนมาก

รากฐานสถาปัตยกรรมที่ต่างกันตั้งแต่ต้น

Vercel รัน Serverless Function บน AWS Lambda เป็นหลักสำหรับ Node.js Runtime และมี Edge Runtime แยกต่างหากที่เบากว่าสำหรับงานที่ต้องการ Latency ต่ำเป็นพิเศษ ทำให้ทีมเลือกได้ว่าจะรัน Logic ส่วนไหนบน Node.js Runtime เต็มรูปแบบ และส่วนไหนควรรันบน Edge Runtime ที่จำกัด API บางตัวแต่เร็วกว่า

Cloudflare Workers ใช้ V8 Isolate เป็นพื้นฐานทั้งหมด ไม่ใช่ Container หรือ VM แบบ Lambda ทำให้ Cold Start เร็วกว่ามากในระดับมิลลิวินาที เพราะไม่ต้อง Boot ทั้ง Container ขึ้นมาใหม่ทุกครั้งเหมือน Serverless Function แบบดั้งเดิม แต่ข้อแลกเปลี่ยนคือ Workers ไม่รองรับ Node.js API ทั้งหมด ต้องเขียน Code ให้เข้ากับข้อจำกัดของ V8 Isolate Runtime โดยเฉพาะ

ความต่างนี้ส่งผลตรงกับประเภทงานที่แต่ละแพลตฟอร์มเหมาะ Vercel เหมาะกับงานที่ต้องใช้ Library ฝั่ง Node.js เต็มรูปแบบ เช่นการประมวลผลไฟล์ที่ซับซ้อนหรือเชื่อมต่อ Service ที่ต้องใช้ SDK เฉพาะ ส่วน Cloudflare Workers เหมาะกับ Logic ที่เบา ทำงานเร็ว ไม่ต้องพึ่ง Library หนัก ๆ ที่ออกแบบมาสำหรับ Node.js โดยเฉพาะ

Pricing Model ต่างกันตรงไหน ทำไม Traffic สูงถึงมีผลมาก

จุดที่ทำให้เพื่อนของนักพัฒนาในตัวอย่างต้นบทความบอกว่า Cloudflare Workers ถูกกว่า มาจากวิธีคิดราคาที่ต่างกัน Cloudflare คิดราคาตาม CPU Time ที่ Code ใช้จริงในการประมวลผล ไม่นับเวลาที่ Function รอ I/O เช่นรอ Response จาก Database หรือ API ภายนอก ทำให้ถ้า Logic ส่วนใหญ่คือการรอข้อมูลจากที่อื่นมากกว่าการคำนวณหนัก ต้นทุนจะต่ำกว่ามาก

ในขณะที่ Vercel ในรุ่นที่ใช้ Node.js Serverless Function คิดราคาตามเวลาที่ Function ทำงานทั้งหมดรวมเวลาที่รอ I/O ด้วย ถ้า API ของทีมมีจุดที่ต้องรอ Database Query นาน ๆ หรือรอ External API ตอบกลับ เวลารอนั้นก็ถูกนับรวมเข้าไปในต้นทุนด้วย ทำให้ Workload ประเภทที่มี I/O เยอะแต่ Logic เบา มักมีต้นทุนสูงกว่าเมื่อรันบน Vercel Node.js Function เทียบกับ Cloudflare Workers

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

ตารางเทียบตามมิติที่นักพัฒนาต้องรู้ก่อนเลือก

สรุปความต่างหลักในตารางนี้เพื่อให้เห็นภาพรวมชัดขึ้น:

มิติVercelCloudflare Workers
Runtime พื้นฐานAWS Lambda (Node.js) + Edge RuntimeV8 Isolate ล้วน
Cold Startช้ากว่าเล็กน้อยบน Node.js Functionเร็วมาก ระดับมิลลิวินาที
วิธีคิดราคานับเวลารวมทั้ง I/Oนับเฉพาะ CPU Time ที่ใช้จริง
จุดแข็งหลักDeveloper Experience สำหรับ Next.js เต็มรูปแบบต้นทุนต่ำสำหรับ API เบาที่ Traffic สูง
รองรับ Node.js Libraryรองรับเต็มรูปแบบบน Node.js Functionจำกัด ต้องเข้ากับ V8 Isolate

สถานการณ์ที่ Vercel ยังเป็นตัวเลือกที่ดีกว่า

ถ้าทีมกำลังสร้างเว็บแอปเต็มรูปแบบด้วย Next.js ที่มีทั้ง Server Component, Route Handler, Image Optimization และ ISR (Incremental Static Regeneration) การอยู่บน Vercel ยังคุ้มกว่าเพราะ Feature เหล่านี้ถูกออกแบบมาให้ทำงานร่วมกันอย่างไร้รอยต่อ ไม่ต้องต่อประกอบเองหลายส่วน

งานที่ต้องพึ่ง Library ฝั่ง Node.js เฉพาะทาง เช่นการประมวลผลรูปภาพหนัก ๆ การสร้าง PDF หรือเชื่อมต่อ SDK ของ Service ที่ยังไม่รองรับ Edge Runtime ก็ยังเหมาะกับ Vercel มากกว่า เพราะ Cloudflare Workers มีข้อจำกัดเรื่อง Library ที่ใช้ได้ค่อนข้างมาก

ทีมที่ให้ความสำคัญกับ Developer Experience โดยเฉพาะ Preview Deployment ที่เชื่อมกับ GitHub อัตโนมัติ และเครื่องมืออย่าง v0 ที่ผูกเข้ากับ Ecosystem เดียวกัน ก็ได้ประโยชน์จากการอยู่ใน Ecosystem ของ Vercel มากกว่าแยกไปใช้หลายแพลตฟอร์มพร้อมกัน

สถานการณ์ที่ Cloudflare Workers เหมาะกว่า

สำหรับกรณีของนักพัฒนาคนเดียวที่ดูแล API วันละหมื่น Request ตามคำถามต้นบทความ ถ้า Logic ของแต่ละ Request เบา เช่นตรวจสอบ Token, Query ข้อมูลสั้น ๆ หรือ Redirect ตาม Rule ที่กำหนดไว้ Cloudflare Workers มักให้ต้นทุนต่อ Request ที่ต่ำกว่าอย่างชัดเจน โดยเฉพาะเมื่อ Traffic เพิ่มขึ้นเรื่อย ๆ ตามการเติบโตของแอป

งานประเภท Edge Middleware ที่ต้องทำงานเร็วมากและกระจายอยู่ใกล้ผู้ใช้ทั่วโลก เช่นการตรวจสอบ A/B Testing Rule หรือ Geo-based Redirect ก็เป็นจุดแข็งของ Cloudflare Workers เพราะ Cold Start ที่ต่ำมากทำให้ผู้ใช้แทบไม่รู้สึกถึง Latency เพิ่มขึ้นเลย

ทีมที่มีงบจำกัดและต้องการควบคุมต้นทุนให้แม่นยำที่สุดต่อ Request ที่เพิ่มขึ้น ก็มักได้ประโยชน์จากโมเดลราคาแบบคิดตาม CPU Time ของ Cloudflare มากกว่า เพราะคาดการณ์ต้นทุนได้ตรงกับ Logic จริงที่ Code ทำงาน ไม่ปนกับเวลาที่รอ I/O ซึ่งควบคุมได้ยากกว่า

ใช้ทั้งสองแพลตฟอร์มพร้อมกันได้ไหม แบบไหนที่ทีมจริงทำกัน

คำตอบคือได้ และหลายทีมก็ทำแบบนี้จริง โดยวาง Next.js App หลักไว้บน Vercel เพื่อใช้ประโยชน์จาก Developer Experience เต็มรูปแบบ แล้วแยกเฉพาะ API Endpoint ที่มี Traffic สูงและ Logic เบาไปรันบน Cloudflare Workers ต่างหาก เชื่อมกันผ่าน HTTP Request ปกติ

วิธีนี้ต้องแลกกับความซับซ้อนที่เพิ่มขึ้นเรื่องการดูแลสอง Codebase และสอง Deployment Pipeline แยกกัน ทีมต้องมีความชัดเจนว่า Logic ส่วนไหนอยู่ที่ไหน และต้องดูแล Environment Variables แยกกันทั้งสองฝั่งด้วย ไม่ใช่แค่คัดลอกค่าจากที่หนึ่งไปอีกที่หนึ่งครั้งเดียวแล้วจบ เพราะเมื่อ Rotate Key ก็ต้องอัปเดตทั้งสองฝั่งให้ตรงกัน

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

ตัวอย่างสมมติ: คำนวณต้นทุนก่อนตัดสินใจย้าย

ลองสมมตินักพัฒนาคนเดียวที่มี API วันละหมื่น Request ตามคำถามต้นบทความ แต่ละ Request ใช้เวลาเฉลี่ยประมาณ 200 มิลลิวินาที ซึ่งส่วนใหญ่เป็นเวลารอ Database ตอบกลับมากกว่าการคำนวณหนัก ถ้ารันบน Vercel Node.js Function ต้นทุนจะคำนวณจากเวลารวมทั้ง 200 มิลลิวินาทีนั้น แต่ถ้ารันบน Cloudflare Workers ต้นทุนจะคำนวณเฉพาะ CPU Time ที่ใช้จริงซึ่งอาจเหลือแค่ไม่กี่มิลลิวินาทีต่อ Request เพราะเวลาที่เหลือเป็นการรอ I/O ล้วน ๆ (ตัวเลขเวลาที่ยกมาเป็นตัวอย่างสมมติเพื่อประกอบการอธิบาย ไม่ใช่ Benchmark จริงของ Workload ใดโดยเฉพาะ)

ก่อนตัดสินใจย้ายจริง นักพัฒนาควรวัด CPU Time จริงของ Workload ตัวเองก่อน ไม่ใช่เดาจากตัวเลขทั่วไป เพราะถ้า Logic มีการคำนวณหนักแฝงอยู่ เช่นการ Parse ข้อมูลขนาดใหญ่หรือเข้ารหัสข้อมูลก่อนตอบกลับ ต้นทุนบน Cloudflare Workers ก็อาจไม่ต่างจาก Vercel มากอย่างที่คาดไว้ในตอนแรก การวัดจริงก่อนตัดสินใจสำคัญกว่าการเชื่อคำแนะนำทั่วไปที่ไม่ได้ดูรายละเอียด Workload ของตัวเอง

ถ้าตัดสินใจย้ายจริง ต้องเตรียมอะไรบ้าง

การย้าย API จาก Vercel ไป Cloudflare Workers ไม่ใช่แค่ Copy Code ไปวางแล้วรันได้เลย เพราะ Runtime ต่างกัน โดยเฉพาะถ้า Code เดิมใช้ Node.js API บางตัวที่ V8 Isolate ไม่รองรับ ต้องไล่ตรวจและปรับ Code ให้เข้ากับข้อจำกัดใหม่ก่อน

  1. ไล่ตรวจ Dependency ทั้งหมดที่ API ใช้อยู่ว่าตัวไหนพึ่ง Node.js API ที่ Workers ไม่รองรับ แล้วหา Alternative ที่ทำงานบน V8 Isolate ได้
  2. วัด CPU Time จริงของ Endpoint ที่จะย้ายก่อน ไม่ใช่ประเมินจากความรู้สึกว่า Logic เบาหรือหนัก
  3. ทดสอบ Endpoint ที่ย้ายแล้วบน Environment ทดสอบให้ครบทุก Edge Case ก่อนสลับ Traffic จริงเข้าไป
  4. วางแผน Rollback ไว้ล่วงหน้า เผื่อกรณีที่พบปัญหาหลังย้ายจริงแล้วต้องสลับกลับมาใช้ Vercel ชั่วคราวระหว่างแก้ไข

ทำแบบนี้แล้วพัง เพราะอะไร

  • ตัดสินใจย้ายทั้งระบบไปหาแพลตฟอร์มใหม่ทันทีเพราะเห็นราคาต่อ Request ถูกกว่า โดยไม่ได้วัด CPU Time จริงของ Workload ตัวเองก่อน
  • ใช้ Library ที่พึ่ง Node.js API เฉพาะทางบน Cloudflare Workers โดยไม่ตรวจสอบความเข้ากันได้ก่อน ทำให้ Deploy แล้ว Error ทันทีเพราะ Runtime ไม่รองรับ
  • แยก API ไปรันบนสองแพลตฟอร์มพร้อมกันโดยไม่มีเอกสารชัดเจนว่า Logic ส่วนไหนอยู่ที่ไหน ทำให้ทีมใหม่ที่เข้ามาสับสนว่าต้องแก้ที่จุดไหน
  • ลืมอัปเดต Environment Variables ให้ตรงกันทั้งสองฝั่งหลังแยก API ออกไปรันบน Cloudflare Workers ทำให้เกิดปัญหา Config ไม่ตรงกันโดยไม่รู้ตัว
  • เปรียบเทียบราคาแค่ตัวเลขต่อ Request แบบผิว ๆ โดยไม่คิดต้นทุนเวลาที่ทีมต้องใช้ดูแลสอง Codebase เพิ่มขึ้น ซึ่งบางครั้งมีมูลค่าสูงกว่าเงินที่ประหยัดได้จากค่า Hosting เอง

สรุป

Vercel กับ Cloudflare Workers ไม่ใช่คู่แข่งที่ต้องเลือกอย่างใดอย่างหนึ่งเสมอไป แต่ละแพลตฟอร์มมีจุดแข็งต่างกันตามรากฐานสถาปัตยกรรมที่ต่างกันมาตั้งแต่ต้น Vercel เหมาะกับเว็บแอปเต็มรูปแบบที่ต้องการ Developer Experience ครบวงจร ส่วน Cloudflare Workers เหมาะกับ API เบาที่มี Traffic สูงและต้องการควบคุมต้นทุนต่อ CPU Time ให้แม่นยำ

นักพัฒนาคนเดียวที่ดูแล API วันละหมื่น Request ควรเริ่มจากการวัด CPU Time จริงของ Workload ตัวเองก่อนตัดสินใจย้าย ไม่ใช่เชื่อคำแนะนำทั่วไปที่ไม่ได้ดูรายละเอียดงานจริง เพราะต้นทุนที่ประหยัดได้ต้องคุ้มกับความซับซ้อนที่เพิ่มขึ้นจากการดูแลหลายแพลตฟอร์มพร้อมกันด้วย

  • Vercel เหมาะกับเว็บแอปเต็มรูปแบบด้วย Next.js ที่ต้องการ Developer Experience ครบวงจร
  • Cloudflare Workers เหมาะกับ API เบาที่ Traffic สูง เพราะคิดราคาตาม CPU Time จริงไม่นับเวลารอ I/O
  • วัด CPU Time จริงของ Workload ก่อนตัดสินใจย้าย ไม่ใช่ดูแค่ราคาต่อ Request แบบผิวเผิน
  • ใช้ทั้งสองแพลตฟอร์มพร้อมกันได้ แต่ต้องแลกกับความซับซ้อนในการดูแลสอง Codebase

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

Cloudflare Workers ถูกกว่า Vercel เสมอไปไหม

ไม่เสมอไป ขึ้นอยู่กับสัดส่วน CPU Time ต่อเวลารอ I/O ของ Workload ถ้า Logic มีการคำนวณหนักจริง ต้นทุนอาจใกล้เคียงกัน ควรวัด CPU Time จริงก่อนสรุปว่าถูกกว่าแน่นอน

ย้าย Next.js App ทั้งระบบไป Cloudflare Workers ได้ไหม

ทำได้ในบางส่วนผ่านการปรับ Config เฉพาะ แต่ Feature บางอย่างของ Next.js ที่ผูกกับ Vercel โดยตรง เช่น Image Optimization บางรูปแบบ อาจทำงานได้ไม่เต็มรูปแบบเท่าบน Vercel เอง

Cold Start ของ Cloudflare Workers เร็วกว่า Vercel แค่ไหน

เร็วกว่ามากในระดับมิลลิวินาที เพราะใช้ V8 Isolate ที่ไม่ต้อง Boot Container ใหม่ทุกครั้ง ต่างจาก Serverless Function แบบดั้งเดิมที่อาจมี Cold Start นานกว่าในบางกรณี

ใช้ทั้ง Vercel และ Cloudflare Workers พร้อมกันคุ้มไหมสำหรับทีมเล็ก

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

Cloudflare Workers รองรับ Database แบบไหนบ้าง

รองรับการเชื่อมต่อผ่าน HTTP-based Database หรือ Service ที่ออกแบบมาให้ทำงานกับ Edge Runtime โดยเฉพาะ ส่วน Database แบบดั้งเดิมที่ต้องการ Connection แบบ Persistent อาจต้องใช้ Adapter เพิ่มเติมหรือผ่าน Pooler ที่รองรับ

ควรเริ่มจากแพลตฟอร์มไหนถ้ายังไม่แน่ใจ Workload ของตัวเอง

แนะนำให้เริ่มจาก Vercel ก่อนถ้ากำลังสร้างเว็บแอปเต็มรูปแบบด้วย Next.js เพราะ Developer Experience ครบกว่า แล้วค่อยวัดต้นทุนจริงเมื่อ Traffic เพิ่มขึ้น ก่อนตัดสินใจแยกบางส่วนไปรันบน Cloudflare Workers

วัด Conversion LINE ทุกแบรนด์ รวมศูนย์ที่เดียว

องค์กรที่มีหลายแบรนด์ หลายสาขา หลาย LINE OA — linli รวม Tracking และส่ง Conversion กลับทุกแพลตฟอร์ม พร้อม Custom Limit เริ่มฟรี 14 วัน

ติดต่อทีม Sales

บทความที่เกี่ยวข้อง

ทำไมทีมพัฒนาเริ่มย้าย AI Workflow มารันบน Supabase Edge Functions

ทำไมทีมพัฒนาเริ่มย้าย AI Workflow มารันบน Supabase Edge Functions

เมื่อ AI Model กลายเป็นส่วนหนึ่งของแอปแทบทุกตัว คำถามคือควรเรียกจากไหน บทความนี้เจาะเหตุผลที่ทีมจำนวนมากเลือกวาง AI Workflow ไว้ที่ Edge Functions แทนการยิงตรงจาก client
เปิด Database ให้ Frontend เรียกตรงได้ยังไงโดยไม่มีใครขโมยข้อมูลคนอื่นได้

เปิด Database ให้ Frontend เรียกตรงได้ยังไงโดยไม่มีใครขโมยข้อมูลคนอื่นได้

หลายทีมกลัวการให้ frontend เรียกฐานข้อมูลตรง ๆ เพราะกลัวข้อมูลรั่ว แต่ Row Level Security ของ Supabase คือกลไกที่ทำให้เรื่องนี้ปลอดภัยได้จริง บทความนี้อธิบายว่า RLS ทำงานยังไงและเขียน policy ถูกต้องแบบไหน
แชทสดหรือแดชบอร์ดที่อัปเดตเองต้องใช้ Supabase Realtime เมื่อไหร่ ไม่ใช่ทุกโปรเจกต์

แชทสดหรือแดชบอร์ดที่อัปเดตเองต้องใช้ Supabase Realtime เมื่อไหร่ ไม่ใช่ทุกโปรเจกต์

หลายทีมเปิด Supabase Realtime ทันทีที่เห็นว่ามีให้ใช้ โดยไม่ได้ประเมินว่าโปรเจกต์ตัวเองต้องการจริงไหม บทความนี้ชี้เงื่อนไขว่าเมื่อไรใช้ Realtime คุ้มค่า และเมื่อไรควรใช้ polling ธรรมดาแทน