Cloudflare หรือ Fastly: คะแนนทั่วโลกเสมอกัน แต่ทราฟฟิกไทยอาจไม่เสมอ

Cloudflare กับ Fastly เคยได้ค่าหน่วงเวลาเท่ากันที่ 36 มิลลิวินาทีใน กราฟทั่วโลกของ RIPE Labs ปี 2019 ซึ่งวัด ping จากจุดสังเกตที่สุ่มเลือก ไม่ใช่เวลาโหลดเว็บของผู้ใช้ในไทย คะแนนนั้นจึงใช้ตัดสินไม่ได้ว่ารายใดจะส่งหน้าเว็บ รูปภาพ หรือ API จากกรุงเทพฯ ได้เร็วกว่า

หากต้องเลือก CDN สำหรับเว็บที่มีผู้ใช้ในไทย ให้ทดสอบ Cloudflare และ Fastly กับเซิร์ฟเวอร์ต้นทางและชุดคำขอเดียวกัน โดยแยกไฟล์ที่อยู่ในแคช ไฟล์ที่ต้องดึงใหม่ API และผลหลังล้างแคช จากนั้นเทียบเวลาตอบสนอง ความสดของข้อมูล ภาระที่กลับไปยังต้นทาง และค่าใช้จ่ายตามทราฟฟิกจริง ผลแต่ละงานอาจชี้ไปคนละผู้ให้บริการ จึงควรให้ความสำคัญกับงานที่ผู้ใช้ของเว็บพบมากที่สุด

คะแนนทั่วโลกบอกอะไรเกี่ยวกับเส้นทางในไทย

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

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

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

งานศึกษาระยะยาวของ Cicalese และ Rossi พบว่าในการติดตามกลุ่มที่อยู่ anycast ของ Fastly จากจุดวัด RIPE Atlas ระหว่างเดือนมิถุนายน 2016 ถึงมิถุนายน 2017 การเพิ่มจุดให้บริการสัมพันธ์กับค่าหน่วงเวลาเฉลี่ยที่ลดลงเพิ่มเติมราว 5% และค่าหน่วงเวลาที่เปอร์เซ็นไทล์ 95 ลดจาก 137 เหลือ 68 มิลลิวินาที ตัวเลขนี้เป็นผลของกลุ่มที่อยู่และช่วงเวลาที่ศึกษา ไม่ใช่ผลทดสอบการโหลดเว็บจากกรุงเทพฯ

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

แคชทำให้คำว่าเร็วมีหลายความหมาย

บทเปรียบเทียบของ iTechGuides อธิบายว่าผลของ Cloudflare และ Fastly เปลี่ยนตามสัดส่วน cache hit นโยบายแคช ตำแหน่งต้นทาง การกำหนดเส้นทาง และชนิดคำขอ จึงไม่มีผู้ชนะที่เร็วกว่าในทุกงาน ข้อแตกต่างเหล่านี้ควรแยกวัด เพราะค่าเฉลี่ยที่รวมไฟล์คงที่กับคำขอที่ต้องประมวลผลใหม่ตอบคำถามคนละเรื่อง

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

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

กฎแคชเปลี่ยนผลได้มากพอ ๆ กับเส้นทางเครือข่าย อายุของข้อมูลที่อนุญาตให้เก็บ ส่วนหัว Cache-Control และวิธีสร้าง cache key กำหนดว่าคำขอใดใช้สำเนาร่วมกันได้ พารามิเตอร์ใน URL หรือคุกกี้ที่ทำให้คำขอถูกแยกเป็นหลายรายการอาจลด cache hit แม้เนื้อหาที่ส่งกลับเหมือนกัน ในทางกลับกัน การรวมคำขอที่มีข้อมูลเฉพาะผู้ใช้ไว้ใต้ cache key เดียวกันอาจทำให้ส่งข้อมูลผิดคน จึงต้องรักษากฎความถูกต้องของข้อมูลระหว่างทดสอบ

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

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

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

ราคาเริ่มต้นเทียบกันตรง ๆ ไม่ได้

หน้าแผน Network & CDN ของ Cloudflare แสดง Free ที่ 0 ดอลลาร์ต่อเดือน, Pro ที่ 20 ดอลลาร์ต่อเดือนเมื่อชำระรายปีหรือ 25 ดอลลาร์เมื่อชำระรายเดือน และ Business ที่ 200 หรือ 250 ดอลลาร์ต่อเดือนตามวิธีชำระ แผนเหล่านี้แสดง CDN, DNS, ใบรับรอง SSL และการป้องกัน DDoS ในชุดความสามารถหลัก จึงเป็นราคาของแผนเว็บที่รวมหลายบริการ

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

ตาราง Full Site Delivery ของ Fastly แสดงแบนด์วิดท์ 100 GB แรกฟรีต่อเดือนและอัตราสำหรับเอเชียที่ 0.19 ดอลลาร์ต่อ GB ในช่วงถัดไปจนถึง 10 TB โดยแยกการคิดค่าคำขอและให้ 1 ล้านคำขอแรกฟรี ขณะที่แพ็กเกจ Network Services แบบจัดชุดบริการเริ่มที่ 1,500 ดอลลาร์ต่อเดือน ราคาแพ็กเกจดังกล่าวจึงไม่ใช่ราคาเริ่มต้นของการส่งเนื้อหาแบบคิดตามการใช้งาน

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

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

แผนทดสอบจากกรุงเทพฯ ที่ตอบคำถามได้จริง

เริ่มด้วยเซิร์ฟเวอร์ต้นทางเดียวกัน เนื้อหาเดียวกัน และภาระประมวลผลเดียวกันสำหรับ CDN ทั้งคู่ กำหนดอายุแคช ส่วนหัวตอบกลับ การบีบอัด รุ่นโปรโตคอล และกฎความปลอดภัยให้ใกล้เคียงกันที่สุด แล้วจดข้อแตกต่างที่ทำให้เหมือนกันไม่ได้ หากระบบหนึ่งเปิดการปรับภาพหรือการประมวลผลที่ edge เพิ่ม แต่อีกระบบไม่ได้เปิด ผลจะสะท้อนคุณลักษณะนั้นด้วย ไม่ใช่ความต่างของเส้นทางอย่างเดียว

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

1. เตรียมไฟล์ทดสอบที่มีขนาดและเนื้อหาเหมือนกัน รวมถึง API ที่คืนคำตอบแบบเดียวกันจากต้นทางเดียวกัน บันทึกเวลา เครือข่าย จุดสังเกต และการตั้งค่าของคำขอทุกชุด สลับลำดับการทดสอบผู้ให้บริการ เพื่อไม่ให้รายใดได้เปรียบจากช่วงเวลาที่เครือข่ายว่างกว่า
2. วัด warm cache หลังตรวจแล้วว่าคำขอเป็น cache hit จริง ใช้ส่วนหัวตอบกลับหรือบันทึกของ CDN ยืนยันสถานะแคช เก็บเวลาจนได้ไบต์แรกและเวลารับไฟล์ครบ โดยแยกผลของไฟล์ขนาดเล็กออกจากไฟล์ขนาดใหญ่ เพราะช่วงเริ่มตอบกับความเร็วส่งข้อมูลหลังจากนั้นเป็นคนละส่วนของประสบการณ์
3. วัด cold cache ด้วยไฟล์ใหม่หรือวิธีทำให้แคชยังไม่มีข้อมูลที่ควบคุมได้เหมือนกันทั้งสองฝั่ง ตรวจจำนวนครั้งที่ต้นทางถูกเรียกและเวลาที่ต้นทางใช้ตอบด้วย หากทำให้สภาพแคชเย็นเท่ากันไม่ได้ ให้เก็บผลแยกไว้แทนการนำตัวเลขมาจัดอันดับรวมกับ warm cache
4. ส่งคำขอ API ที่แคชไม่ได้และคำขอที่แคชได้แยกกัน รักษาวิธียืนยันตัวตน ขนาดคำตอบ และภาระของแอปพลิเคชันให้เหมือนกัน ดูความผิดพลาดพร้อมเวลาตอบสนอง เพราะคำขอที่ล้มเหลวเร็วไม่ใช่ผลด้านความเร็วที่มีประโยชน์ต่อผู้ใช้
5. เปลี่ยนเนื้อหาของไฟล์ทดสอบแล้วสั่ง purge ตามวิธีที่แต่ละบริการรองรับ วัดเวลาจนจุดสังเกตแต่ละเครือข่ายได้รับเนื้อหาใหม่ และตรวจว่าต้นทางต้องรับคำขอเพิ่มขึ้นเพียงใดหลังล้างแคช ผลนี้สำคัญกับเว็บที่แก้ข้อมูลบ่อย แม้การส่งไฟล์เดิมจากแคชจะเร็วมากอยู่แล้ว
6. ทำซ้ำในช่วงเวลาต่างกันและรายงานผลแยกตามเครือข่ายกับชนิดคำขอ ดูค่ากลางควบคู่กับคำขอที่ช้ากว่าปกติ แล้วถ่วงน้ำหนักภาพรวมตามสัดส่วนทราฟฟิกของเว็บจริง ค่าเฉลี่ยของบรอดแบนด์บ้านไม่ควรมีน้ำหนักเท่ากับมือถือโดยอัตโนมัติ หากผู้ใช้ส่วนใหญ่มาจากมือถือ

เมื่ออ่านผล ให้ดูว่าความช้าเกิดตรงไหนก่อนตัดสินผู้ให้บริการ หาก warm cache ใกล้กันแต่ cold cache ต่างกัน ให้ดูเส้นทางและการตอบสนองของต้นทาง หาก API ช้าทั้งคู่ ปัญหาอาจอยู่ที่แอปพลิเคชันหรือฐานข้อมูล การแยกส่วนเช่นนี้ช่วยให้รู้ว่าการปรับกฎแคชหรือต้นทางอาจให้ผลมากกว่าการเปลี่ยน CDN

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

เลือกจากงานที่เว็บต้องทำ

หากไฟล์คงที่เป็นทราฟฟิกหลัก ให้ให้น้ำหนักกับ cache hit ความเร็วส่งไฟล์ และปริมาณคำขอที่ CDN ช่วยรับแทนต้นทาง หากเว็บพึ่ง API หรือข้อมูลเฉพาะผู้ใช้ ให้ให้น้ำหนักกับเวลาตอบสนองของคำขอที่ไม่แคชและความผิดพลาดมากกว่า ส่วนเว็บที่เปลี่ยนข้อมูลถี่ต้องนำความเร็วในการเผยแพร่ฉบับใหม่เข้ามาอยู่ในเกณฑ์เดียวกับ latency

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

อ่านเพิ่มเติม:

• Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว
• ตั้ง Cloudflare Email Routing: MX เดิมอาจทำให้อีเมลหยุดเข้า