ลดความหน่วง P99 ของ CDN ลง 91% ด้วยการรวมข้อมูลเป็นชิ้นขนาดพอดี: บทเรียนเรื่อง cache จาก Vercel

Vercel เล่าว่าลดเวลาค้นหาข้อมูลเส้นทางของ CDN ในกลุ่มคำขอที่ช้าที่สุด 1 เปอร์เซ็นต์ (P99) จาก 215.8 มิลลิวินาทีเหลือ 19.1 มิลลิวินาทีได้อย่างไร สิ่งที่น่าสนใจคือไม่ได้ใช้เซิร์ฟเวอร์ที่แรงขึ้น แต่เปลี่ยนวิธีจัดเก็บข้อมูลจากอ็อบเจกต์แยกทีละเส้นทางมาเป็นชิ้นข้อมูลขนาดราว 200 KB ที่ค้นหาแบบ binary search ได้ในตัว บทความนี้สรุปปัญหา วิธีแก้ ตัวเลขผลลัพธ์ และบทเรียนที่ทีมพัฒนาเว็บในไทยนำไปใช้กับระบบของตัวเองได้

ข้อมูลเส้นทางของ CDN คืออะไร และทำไมต้องค้นหาทุกคำขอ

CDN ของ Vercel ประมวลผลคำสั่งกำหนดเส้นทางมากกว่า 80 ล้านครั้งต่อวินาที ก่อนตอบคำขอแต่ละครั้ง ระบบต้องรู้ว่าเส้นทางที่ถูกเรียกมีอยู่จริงหรือไม่และต้องเสิร์ฟอย่างไร เช่น คำขอไปที่ /blog/hello-world ต้องถูกจับคู่กับเส้นทางแบบไดนามิก /blog/[slug] ของเฟรมเวิร์ก ข้อมูลที่ใช้ตัดสินใจนี้เรียกว่าเมตาดาต้าของเส้นทาง (path metadata)

ต้นเหตุ: ทุกการ deploy สร้าง cache ใหม่ทั้งหมด

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

สำหรับโปรเจกต์ใหญ่ที่มีหลายแสนเส้นทางและ deploy บ่อย ปัญหานี้ไม่ใช่เหตุบังเอิญแต่เป็นปัญหาเชิงโครงสร้าง ผู้ใช้ที่เรียกหน้าเป็นคนแรกหลัง deploy จะเจอความหน่วงสูงซ้ำไปเรื่อย ๆ ซึ่งสะท้อนออกมาที่ค่า P99 มากกว่าค่าเฉลี่ย

วิธีแก้: รวมเมตาดาต้าหลายเส้นทางเป็นชิ้นที่ค้นหาได้ในตัว

ทีมเปลี่ยนไปรวมเมตาดาต้าของหลายเส้นทางไว้ในไฟล์เดียวที่เรียกว่า shard ในรูปแบบ JSONL ภายในเรียงคู่คีย์และค่าตามลำดับ และมีดัชนีในตัวที่บอกตำแหน่งไบต์ของแต่ละรายการ โดยใช้ตัวชี้ขนาดคงที่ที่เข้ารหัสแบบ Base64 ทำให้กระโดดไปอ่านตำแหน่งใดก็ได้ทันที

เมื่อมีคำขอเข้ามา ระบบทำ binary search บนเส้นทางที่เรียงไว้ ใช้เพียงการอ่านตัวชี้และเปรียบเทียบสตริงระดับ O(log n) แล้วแยกวิเคราะห์ (parse) เฉพาะค่าของเส้นทางที่ตรงกันเท่านั้น ไม่ต้องอ่านทั้งไฟล์ ข้อดีสำคัญคือการดึง shard หนึ่งครั้งช่วยเติม cache ให้การค้นหาอีกหลายเส้นทางต่อจากนั้น

ขนาดของ shard คือจุดที่ต้องจูนจากข้อมูลจริง

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

ส่วนเว็บไซต์ของ Vercel เอง ค่า P99 ลดจาก 203 มิลลิวินาทีเหลือ 31 มิลลิวินาที ขณะที่ค่ามัธยฐานทรงตัวอยู่ที่ราว 0.7 มิลลิวินาที ซึ่งยืนยันว่าการเปลี่ยนแปลงนี้แก้ปัญหาที่ปลายหางโดยไม่ทำให้กรณีปกติแย่ลง โปรเจกต์ที่ build หลังวันที่ 17 กรกฎาคม 2026 ใช้รูปแบบใหม่นี้แล้วทั้งหมด

ผลพลอยได้อยู่ที่ฝั่ง build การเลิกอัปโหลดเมตาดาต้าแยกทีละเส้นทางช่วยประหยัดเวลาได้ราว 16.6 วินาที ขั้นตอน deploy เร็วขึ้นราว 10 เปอร์เซ็นต์ และสำหรับโปรเจกต์ที่มีเมตาดาต้ามากเร็วขึ้นใกล้ 25 เปอร์เซ็นต์

เปิดใช้อย่างไรให้ปลอดภัย

ก่อนเปิดใช้จริง ทีมรันแบบ shadow mode อยู่หลายสัปดาห์ คือสุ่มคำขอบางส่วนมาค้นหาทั้งวิธีเดิมและวิธีใหม่พร้อมกัน แต่ยังตอบผู้ใช้ด้วยผลจากวิธีเดิม แล้วเทียบผลกัน วิธีนี้ช่วยให้พบบั๊กเก่าเรื่องการตัดข้อความที่เข้ารหัสตาม RFC 2047 ซึ่งแบ่งอีโมจิผิดตำแหน่ง รูปแบบใหม่ที่ใช้ UTF-8 จึงแก้ปัญหานี้ไปด้วย ส่วนการบีบอัดเพิ่มอย่าง front-coding หรือการตัดข้อมูลซ้ำ ทีมประเมินแล้วว่าได้ความเร็วเพิ่มไม่มาก จึงไม่คุ้มกับงานเข้ารหัสและความเสี่ยงตอนเปิดใช้

บทเรียนที่ทีมพัฒนาเว็บในไทยนำไปใช้ได้

ข้อแรก วัดที่ P95 และ P99 ไม่ใช่แค่ค่าเฉลี่ย เพราะปัญหาเชิงโครงสร้างอย่าง cache พลาดหลัง deploy ซ่อนอยู่ที่ปลายหาง ข้อสอง ออกแบบ cache key ให้รอดจากการ deploy เพราะระบบที่ deploy บ่อยคือระบบที่ cache เย็นบ่อย ข้อสาม การดึงข้อมูลเป็นก้อนที่ใหญ่พอดีมักดีกว่าการดึงทีละชิ้นเล็ก แต่ขนาดที่ดีที่สุดต้องหาจากข้อมูลจริง ไม่ใช่จากทฤษฎี และข้อสี่ ใช้ shadow mode กับการเปลี่ยนแปลงที่กระทบทุกคำขอ

ทีมงาน Smart Cyber Tech รับทำเว็บไซต์และเว็บแอปพลิเคชันด้วย React และ Next.js ที่ออกแบบระบบ cache และวัดประสิทธิภาพจากผู้ใช้จริงตั้งแต่ต้น หากเว็บของคุณเร็วในวันปกติแต่ช้าลงทุกครั้งหลังอัปเดต ปรึกษาได้ที่ แบบฟอร์มติดต่อ