การย้ายการสร้างรูปภาพตัวอย่าง (thumbnail) จาก PHP backend ไปยัง Cloudflare Workers ช่วยกำจัดภาระการทำงานของ CPU บน origin server ทั้งหมดสำหรับเว็บไซต์โฮสต์วิดีโอที่ให้บริการรูปภาพหลายล้านรูปต่อวัน การเปลี่ยนครั้งนี้ยังช่วยย้ายความหน่วง (latency) ในการประมวลผลรูปภาพจาก data center ไปยัง edge ซึ่งช่วยลดเวลาในการตอบสนองและทำให้ค่าใช้จ่ายด้านแบนด์วิดท์คาดการณ์ได้ง่ายขึ้น

ทำไมโมเดลแบบเดิมถึงพัง

เว็บไซต์นี้เป็นแพลตฟอร์มที่แสดงวิดีโอหลายหมื่นรายการ โดยมีการฝังรูปภาพตัวอย่างสูงสุดถึง 40 รูปในหน้าเดียว รูปภาพตัวอย่างแต่ละรูปจะถูกปรับขนาดตามคำขอ (on demand) โดยสคริปต์ PHP ที่อ่านไฟล์ต้นฉบับและทำการปรับสเกลใหม่ เมื่อมี crawler เข้ามาเยี่ยมชมเว็บไซต์ เซิร์ฟเวอร์ backend จะเกิดอาการค้าง

การประมวลผลที่ Edge ช่วยแก้ปัญหาความต้องการหลัก 5 ประการ

Thumbnail API ระดับใช้งานจริง (production-grade) ต้องจัดการสิ่งต่อไปนี้ได้:

  • Fan-in – การดึงรูปภาพต้นฉบับจากโฮสต์ภายนอก (third-party hosts) จำนวนมาก
  • Fan-out – การสร้างรูปภาพหลายขนาด (เช่น การ์ดขนาด 320 px, รูป hero ขนาด 640 px)
  • Format negotiation – การเลือกใช้ฟอร์แมต WebP หรือ AVIF เมื่อเบราว์เซอร์รองรับเพื่อลดการใช้แบนด์วิดท์
  • Cache – การทำให้มั่นใจว่าแม้การเรียกใช้งานครั้งแรกอาจมีต้นทุนสูง แต่การเรียกใช้งานครั้งต่อๆ ไปจะไม่มีค่าใช้จ่าย
  • Security – การป้องกันไม่ให้ใครก็ตามนำบริการไปใช้ในทางที่ผิดเพื่อประมวลผลรูปภาพใดๆ ก็ตาม

Cloudflare Workers สามารถจัดการแต่ละประเด็นได้โดยไม่รบกวน CPU ของ origin:

  1. Proximity – Workers ทำงานใน data center ที่อยู่ใกล้กับผู้ใช้ ดังนั้นรูปภาพที่ประมวลผลแล้วจึงเดินทางในเส้นทางที่สั้นกว่า
  2. Built-in Image Resizing – ฟีเจอร์ Image Resizing ของแพลตฟอร์มจะจัดการเรื่องพิกเซลให้เอง ทำให้ไม่จำเป็นต้องใช้ library ที่เขียนขึ้นเอง
  3. Cache API – Workers จะเก็บรูปภาพที่ปรับขนาดแล้วไว้ที่ edge หลังจากคำขอแรก edge จะส่งรูปภาพนั้นให้โดยตรง
  4. Programmable security – สคริปต์ขนาดเล็กจะทำการตรวจสอบ HMAC signatures, บังคับใช้ allow-list ของ hostname และความกว้าง (width), และทำ cache key normalization เพื่อป้องกัน cache poisoning

ระบบทำงานอย่างไร

  1. Origin สร้าง signed URLs – Backend จะถือครอง secret key และแนบ HMAC signature ไปกับทุกคำขอรูปภาพตัวอย่าง นอกจากนี้ URL ยังระบุความกว้างและฟอร์แมตที่ต้องการด้วย
  2. Worker ตรวจสอบ signature – เมื่อได้รับคำขอ Worker จะคำนวณ HMAC ใหม่ด้วย shared secret หาก signature หายไปหรือผิดพลาด คำขอจะถูกปฏิเสธเพื่อป้องกันการใช้งานในทางที่ผิด
  3. การบังคับใช้ Allow-list – สคริปต์จะตรวจสอบว่า hostname ต้นทางอยู่ในรายการที่กำหนดไว้หรือไม่ และความกว้างที่ขอมาเป็นหนึ่งในขนาดที่รองรับหรือไม่ เพื่อป้องกันไม่ให้โฮสต์ที่เป็นอันตรายถูกนำมาเก็บไว้ใน cache
  4. Cache key normalization – ตัว signature จะถูกตัดออกจาก cache key โดยที่ key จะประกอบด้วยเพียง URL ต้นทาง, ความกว้าง และฟอร์แมตเท่านั้น วิธีนี้ช่วยเพิ่มโอกาสที่ผู้ใช้ต่างคนกันซึ่งขอรูปภาพเดียวกันจะเข้าถึงข้อมูลใน cache ชุดเดียวกัน
  5. Edge fetch และการปรับขนาด – หากรูปภาพยังไม่ได้อยู่ใน cache, Worker จะไปดึงรูปต้นฉบับจากโฮสต์ภายนอก, เรียกใช้ Image Resizing API และเก็บผลลัพธ์ไว้ใน edge cache
  6. Cache warming – หลังจากทุกการ crawl, สคริปต์ Python ขนาดเล็กจะทำการส่งคำขอรูปภาพตัวอย่างใหม่ๆ ล่วงหน้า ดังนั้นผู้ใช้จริงคนแรกจึงจะได้รับคำตอบจาก cache แทนที่จะต้องรอการประมวลผลปรับขนาด

ผลลัพธ์ที่วัดผลได้หลังจากผ่านไปหนึ่งเดือน

  • Origin CPU สำหรับรูปภาพ – ลดลงเหลือศูนย์; backend ไม่ต้องประมวลผลข้อมูลไบต์ของรูปภาพอีกเลย
  • ความเร็วในการส่ง HTML – ดีขึ้นอย่างเห็นได้ชัด เนื่องจากเซิร์ฟเวอร์ไม่ต้องหยุดรอการประมวลผลรูปภาพอีกต่อไป
  • Edge cache hit rate – สูงถึง 96%, ซึ่งหมายความว่าเกือบทุกคำขอได้รับการตอบสนองจาก edge โดยไม่ต้องดึงข้อมูลจาก backend
  • Latency – ลดลง เนื่องจากรูปภาพถูกส่งจาก data center ที่อยู่ใกล้ผู้ใช้แทนที่จะเป็น origin ส่วนกลาง
  • ความสามารถในการคาดการณ์แบนด์วิดท์ – ด้วยการทำ edge caching ปริมาณ outbound traffic จาก origin จึงมีความเสถียรและคาดการณ์ได้ง่าย

บทสรุป

การย้ายภาระการสร้างรูปภาพตัวอย่างไปยัง Cloudflare Workers ได้เปลี่ยนคอขวดที่ติดขัดเรื่อง CPU ให้กลายเป็น edge cache ที่มีต้นทุนเกือบเป็นศูนย์ ปัจจุบัน origin มีหน้าที่เพียงแค่สร้าง signed URLs ในขณะที่ edge จะจัดการเรื่องการดึงข้อมูล, การปรับขนาด, การเลือกฟอร์แมต และการส่งผลลัพธ์จาก cache สำหรับเว็บไซต์ใดก็ตามที่ต้องพึ่งพารูปภาพจำนวนมาก โดยเฉพาะแพลตฟอร์มวิดีโอที่แสดงรูปภาพตัวอย่างหลายสิบรูปต่อหน้า แนวทางแบบ edge-first นี้จะช่วยให้หน้าเว็บโหลดเร็วขึ้น, ค่าใช้จ่ายคาดการณ์ได้ และมีการแยกส่วนที่ชัดเจนระหว่าง “สิ่งที่ต้องแสดง” (origin) และ “วิธีการส่งมอบ” (edge)