Перенесення генерації мініатюр із PHP-бекенду на Cloudflare Workers повністю усунуло навантаження на CPU на сервері-джерелі для відеохостингу, який обслуговує мільйони зображень щодня. Ця зміна також перенесла затримку обробки зображень із дата-центру на edge, скоротивши час відгуку та зробивши витрати на пропускну здатність передбачуваними.

Чому стара модель перестала працювати

Сайт — платформа, що відображає десятки тисяч відео, — вбудовує до 40 мініатюр на одну сторінку. Кожна мініатюра змінює розмір за запитом за допомогою PHP-скрипта, який зчитує оригінальний файл і масштабує його. Коли на сайт заходили краулери, сервер бекенду зависав.

Edge-обробка вирішує п'ять основних вимог

API для генерації мініатюр промислового рівня має забезпечувати:

  • Fan-in — отримання вихідних зображень з багатьох сторонніх хостів.
  • Fan-out — створення кількох розмірів (наприклад, картки 320 px, головні зображення 640 px).
  • Format negotiation — надання форматів WebP або AVIF, якщо їх підтримує браузер, щоб зменшити споживання трафіку.
  • Cache — забезпечення того, щоб перший запит міг бути дорогим, але кожен наступний був безкоштовним.
  • Security — запобігання зловживанням сервісом для обробки довільних зображень.

Cloudflare Workers вирішують кожен із цих пунктів, не навантажуючи CPU сервера-джерела:

  1. Proximity — Workers працюють у дата-центрах поблизу користувача, тому оброблене зображення проходить коротший шлях.
  2. Built-in Image Resizing — функція Image Resizing платформи виконує роботу з пікселями, усуваючи потребу в кастомній бібліотеці.
  3. Cache API — Workers зберігають змінене за розміром зображення на edge; після першого запиту edge віддає його напряму.
  4. Programmable security — невеликий скрипт перевіряє HMAC-підписи, застосовує allow-list хостів і ширини, а також нормалізує ключі кешу, щоб уникнути отруєння кешу (cache poisoning).

Як працює система

  1. Origin створює підписані URL — бекенд зберігає секретний ключ і додає HMAC-підпис до кожного запиту на мініатюру. URL також містить бажану ширину та формат.
  2. Worker перевіряє підпис — після отримання Worker перераховує HMAC за допомогою спільного секрету. Якщо підпис відсутній або неправильний, запит відхиляється, що запобігає зловживанням.
  3. Застосування allow-list — скрипт перевіряє, чи входить хост-джерело до попередньо визначеного списку та чи є запитувана ширина одним із підтримуваних розмірів. Це запобігає кешуванню шкідливих хостів.
  4. Нормалізація ключів кешу — сам підпис видаляється з ключа кешу; ключ містить лише URL-адресу джерела, ширину та формат. Це підвищує ймовірність того, що різні користувачі, які запитують одне й те саме зображення, потраплять на той самий запис у кеші.
  5. Edge-завантаження та зміна розміру — якщо зображення ще не кешоване, Worker завантажує оригінал зі стороннього хоста, запускає Image Resizing API та зберігає результат у кеші edge.
  6. Cache warming — після кожного сканування легкий Python-скрипт робить попередні запити на нові мініатюри. Таким чином, перший реальний користувач отримує відповідь із кешу замість того, щоб чекати на операцію зміни розміру.

Вимірюваний ефект через місяць

  • CPU сервера-джерела для зображень — впало до нуля; бекенд більше ніколи не обробляє байти зображень.
  • Швидкість віддачі HTML — помітно покращилася, оскільки сервер більше не блокується через обробку зображень.
  • Edge cache hit rate — досяг 96%, що означає, що майже кожен запит був задоволений з edge без звернення до бекенду.
  • Latency — зменшилася, оскільки зображення тепер віддаються з дата-центру поблизу користувача, а не з центрального сервера-джерела.
  • Передбачуваність пропускної здатності — завдяки edge-кешуванню вихідний трафік із сервера-джерела є стабільним і його легко прогнозувати.

Підсумок

Перенесення генерації мініатюр на Cloudflare Workers перетворило вузьке місце, обмежене потужністю CPU, на edge-кеш із майже нульовою вартістю. Тепер сервер-джерело лише видає підписані URL, тоді як edge бере на себе завантаження, зміну розміру, узгодження форматів та віддачу кешованих результатів. Для будь-якого сайту, який сильно залежить від зображень — особливо відеоплатформ, що відображають десятки мініатюр на сторінку, — підхід edge-first забезпечує швидшу роботу сторінок, передбачувані витрати та чіткий розподіл між «що показувати» (origin) та «як це доставити» (edge).