انتقال تولید تامنیل (thumbnail) از بک‌اِند PHP به Cloudflare Workers، بار پردازشی CPU را در سرور اصلی (origin) برای یک سایت میزبانی ویدیو که روزانه میلیون‌ها تصویر سرو می‌کند، به طور کامل از بین برد. این تغییر همچنین تأخیر (latency) پردازش تصویر را از مرکز داده به لبه (edge) منتقل کرد که باعث کاهش زمان پاسخ‌گویی و پیش‌بینی‌پذیر شدن هزینه‌های پهنای باند شد.

چرا مدل قدیمی از کار افتاد

این سایت که پلتفرمی برای نمایش ده‌ها هزار ویدیو است، تا ۴۰ تامنیل را در یک صفحه واحد قرار می‌دهد. هر تامنیل بر اساس درخواست، توسط یک اسکریپت PHP که فایل اصلی را می‌خواند و آن را تغییر اندازه می‌دهد، بازسازی می‌شود. زمانی که خزنده‌ها (crawlers) از سایت بازدید می‌کردند، سرور بک‌اِند دچار توقف (stall) می‌شد.

پردازش در لبه (Edge) پنج نیاز اصلی را برطرف می‌کند

یک API تولید تامنیل در سطح عملیاتی (production-grade) باید موارد زیر را مدیریت کند:

  • Fan-in – دریافت تصاویر منبع از چندین میزبان شخص ثالث.
  • Fan-out – تولید چندین اندازه مختلف (مثلاً کارت‌های ۳۲۰ پیکسلی یا تصاویر اصلی ۶۴۰ پیکسلی).
  • Format negotiation – ارائه فرمت‌های WebP یا AVIF در صورت پشتیبانی مرورگر برای کاهش پهنای باند.
  • Cache – اطمینان از اینکه اگرچه درخواست اول می‌تواند هزینه‌بر باشد، اما تمام درخواست‌های بعدی رایگان (بدون هزینه پردازشی) باشند.
  • Security – جلوگیری از سوءاستفاده کاربران برای پردازش تصاویر دلخواه.

Cloudflare Workers بدون درگیر کردن CPU سرور اصلی، هر یک از این موارد را پوشش می‌دهند:

  1. Proximity – ورکرها در مراکز داده نزدیک به کاربر اجرا می‌شوند، بنابراین تصویر پردازش‌شده مسیر کوتاه‌تری را طی می‌کند.
  2. Built-in Image Resizing – قابلیت Image Resizing این پلتفرم کار پردازش پیکسل‌ها را انجام می‌دهد و نیاز به کتابخانه سفارشی را از بین می‌برد.
  3. Cache API – ورکرها تصویر تغییراندازه یافته را در لبه ذخیره می‌کنند؛ پس از اولین درخواست، لبه تصویر را مستقیماً سرو می‌کند.
  4. Programmable security – یک اسکریپت کوچک امضاهای HMAC را تأیید می‌کند، لیست مجاز (allow-list) نام‌های میزبان و عرض‌ها را اعمال می‌کند و کلیدهای کش را برای جلوگیری از مسمومیت کش (cache poisoning) نرمال‌سازی می‌کند.

سیستم چگونه کار می‌کند

  1. Origin creates signed URLs – بک‌اِند یک کلید مخفی نگه می‌دارد و یک امضای HMAC به هر درخواست تامنیل اضافه می‌کند. URL همچنین شامل عرض و فرمت مورد نظر است.
  2. Worker verifies the signature – پس از دریافت، ورکر امضای HMAC را با استفاده از کلید مشترک مجدداً محاسبه می‌کند. اگر امضا موجود نباشد یا اشتباه باشد، درخواست رد می‌شود تا از سوءاستفاده جلوگیری شود.
  3. Allow-list enforcement – اسکریپت بررسی می‌کند که نام میزبان منبع در لیست از پیش تعریف‌شده باشد و عرض درخواستی نیز یکی از اندازه‌های پشتیبانی‌شده باشد. این کار از ذخیره شدن میزبان‌های مخرب در کش جلوگیری می‌کند.
  4. Cache key normalization – خودِ امضا از کلید کش حذف می‌شود؛ کلید فقط شامل URL منبع، عرض و فرمت است. این کار احتمال اینکه کاربران مختلف با درخواست یک تصویر مشابه، به یک ورودی کش شده برخورد کنند را افزایش می‌دهد.
  5. Edge fetch and resize – اگر تصویر از قبل در کش نباشد، ورکر فایل اصلی را از میزبان شخص ثالث دریافت کرده، API Image Resizing را اجرا می‌کند و نتیجه را در کش لبه ذخیره می‌کند.
  6. Cache warming – پس از هر بار خزیدن (crawl)، یک اسکریپت سبک پایتون، جدیدترین تامنیل‌ها را از قبل درخواست می‌کند. بنابراین اولین کاربر واقعی به جای انتظار برای عملیات تغییر اندازه، یک پاسخ کش‌شده دریافت می‌کند.

تأثیرات قابل اندازه‌گیری پس از یک ماه

  • Origin CPU for images – به صفر رسید؛ بک‌اِند دیگر هرگز بایت‌های تصویر را پردازش نمی‌کند.
  • HTML serving speed – به طور محسوسی بهبود یافت، زیرا سرور دیگر درگیر پردازش تصاویر نمی‌شود.
  • Edge cache hit rate – به ۹۶٪ رسید، به این معنی که تقریباً تمام درخواست‌ها بدون نیاز به فراخوانی از بک‌اِند، از لبه پاسخ داده شدند.
  • Latency – کاهش یافت، زیرا تصاویر اکنون به جای یک سرور اصلی مرکزی، از یک مرکز داده نزدیک به کاربر سرو می‌شوند.
  • Bandwidth predictability – با کش کردن در لبه، ترافیک خروجی از سرور اصلی پایدار و پیش‌بینی‌پذیر است.

خلاصه کلام

سپردن وظیفه تولید تامنیل به Cloudflare Workers، یک گلوگاه محدود به CPU را به یک کش لبه با هزینه نزدیک به صفر تبدیل کرد. اکنون سرور اصلی فقط URLهای امضا شده را صادر می‌کند، در حالی که لبه وظایف دریافت، تغییر اندازه، مذاکره بر سر فرمت‌ها و سرو کردن نتایج کش‌شده را بر عهده دارد. برای هر سایتی که به شدت به تصاویر متکی است — به‌ویژه پلتفرم‌های ویدیویی که ده‌ها تامنیل در هر صفحه نمایش می‌دهند — رویکرد «اول لبه» (edge-first) باعث سرعت بیشتر صفحات، هزینه‌های قابل پیش‌بینی و جداسازی تمیزتر بین «چه چیزی نمایش داده شود» (origin) و «چگونه تحویل داده شود» (edge) می‌شود.