Cloudflare Workers налаштування: де рветься віддача контенту
Поки навантаження рівномірне, вузьке місце не видно: сервер встигає віддати і розмітку, і статику, і відповіді інтерфейсу.
За пікового навантаження паралельних звернень стає в рази більше, черга на обробку зростає, і затримка відповіді сервера виходить за межі, які закладали під час проєктування.
Помітно це не за графіками, а за поведінкою користувачів: інтерфейс підвисає саме в ті години, коли надходить основний трафік, частина запитів обривається за часом очікування й іде на повтор — а повтор знову лягає на той самий перевантажений вузол.
Друга половина проблеми — географія. Запити з віддалених регіонів ідуть через весь маршрут до єдиного вузла, і лише там починається обробка. Кожен перехід за маршрутом додає час до відгуку, а обрив каналу на одній ділянці залишає без сервісу цілий регіон.
Віддача статики підсилює ефект: картинки, скрипти й шрифти запитуються окремо від розмітки і щоразу проходять той самий шлях до центру. Між релізами їхній вміст не змінюється — вони не потрібні вузлу, який зайнятий логікою та роботою з базою.
Так складається точка відмови: один сервер відповідає і за обчислення, і за роздачу контенту, і за запити з усіх регіонів одразу.
Розбираємо, як Cloudflare Workers знімає це навантаження з центру й переносить частину обробки ближче до користувача — туди, де він відкриває сторінку.
Що змінюється після перенесення логіки на межу мережі
Коли обробка запиту переноситься у найближчий до користувача вузол мережі, основний сервер перестає бути точкою входу для всього трафіку.
Редиректи, розбір заголовків, розгалуження варіантів для тестів, склеювання фрагментів сторінки й віддача статики вирішуються на периферії — Cloudflare Workers виконує цей код у тому самому вузлі, де стоїть з’єднання користувача. До сервера доходять лише запити, яким дійсно потрібна база.
Розвантаження вимірюється часткою знятого трафіку: на типовому каталозі або промо-сторінці 60–80% запитів до сервера не доходять — їх закривають правила кешування на межі.
Ключ кешу задається правилами: що вважати за адресою сторінки, що враховувати за cookies, що не кешувати взагалі. Звідти ж береться час відповіді — обчислювальний вузол у регіоні користувача відповідає кратно швидше, ніж сервер на іншому континенті.
Стійкість до піків змінюється структурно. Раніше сплеск від розсилки або публікації впирався в кількість робочих процесів і чергу запитів; тепер важка частина обчислень масштабується на боці межі, а сервер отримує рівномірний потік.
Ми окремо виносимо правила на «гарячі» маршрути — так сплеск не перетворюється на каскад повільних відповідей і помилок.
Окремий ефект — вартість простою. Якщо основний сервер недоступний, межа продовжує віддавати закешовані сторінки та статику: вітрина залишається читабельною, відвідувач не бачить порожнього екрана й не йде до конкурента.
Це не замінює резервування, але переводить збій із класу «сайт лежить» у «частина сценаріїв недоступна», а відновлення вкладається в хвилини замість годин.
Режими роботи та точки підключення: порівняння підходів
На межі задачу вирішують трьома способами, і вибір визначається не модою, а тим, де закінчується декларативний опис і починається код. Кешування та правила маршрутизації описуються конфігурацією — їх править той, хто веде інфраструктуру.
Власна логіка — це виконуваний код: він працює ближче до користувача, але бере на себе відповідальність за поведінку.
Різниця видна в момент відмови. Декларативні режими передбачувані й відтворюються з файлу конфігурації, але не ухвалюють рішень за вмістом запиту. Код уміє більше — і тому потребує тестів, версіонування та плану відкату: помилка тиражується на всі точки присутності одразу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кешування на межі | Статика, зображення, відповіді API, однакові для всіх | Не годиться для персоналізованих відповідей: рішення ухвалюється за адресою та заголовками, тіло запиту не аналізується |
| Правила маршрутизації | Перенесення трафіку, розділення середовищ, переадресація, канаркові частки | Логіка лінійна: немає розгалужень за даними та звернень до зовнішніх сервісів |
| Власна логіка на межі | Перевірка токенів, перемикання варіантів, складання відповіді з кількох джерел | Обмежене середовище виконання та ліміти за часом і пам’яттю; складніше налагоджувати |
На практиці режими поєднують: маршрутизація надсилає на функцію лише ті шляхи, де дійсно потрібна логіка, а решту віддають кешу.
У Cloudflare Workers усі три рівні описуються в одному конфігураційному файлі, тому обмеження кожного підходу залишаються локальними й не перетворюються на спільні для всього трафіку.
Налаштування та запуск: етапи інженерної роботи
Порядок робіт під час налаштування Cloudflare Workers важливіший за швидкість: зміни на периметрі бачать усі користувачі одразу, тому йдемо від фактів до конфігурації.
Спочатку розбираємо реальний трафік — які маршрути дають навантаження, яка частка запитів кешується, звідки приходять клієнти. Схема рішення будується на цих даних, а не на звичці «зробити як завжди».
- Розбір трафіку. Знімаємо логи, групуємо запити за маршрутами й типами, відзначаємо, де віддача просідає першою — джерело, точка входу або один перевантажений маршрут.
- Схема рішення. Фіксуємо, що йде на периметр, що залишається на джерелі, як маршрутизуються запити й за яким сценарієм відбувається відкат. Схема узгоджується до першої правки конфігурації.
- Тестовий стенд. Піднімаємо середовище попереднього перегляду з копією робочих правил і проганяємо сценарії: холодний кеш, оновлення контенту, пік навантаження. Робочий домен стенд не зачіпає.
- Налаштування конфігурації. Описуємо маршрутизацію, правила кешування, заголовки й обробку помилок; значення виносимо в змінні середовища, щоб стенд і робоче середовище не розходилися.
- Перевірка відмов. Гасимо джерело, віддаємо застарілий кеш, ламаємо окремий маршрут — дивимося, що бачить користувач і як середовище відновлюється саме.
- Випуск у робоче середовище. Переводимо частку трафіку, стежимо за метриками й логами, за відхилень повертаємо попередню версію однією дією.
- Передача. Віддаємо конфігурації, схему й порядок відкату, показуємо команді, як дивитися стан периметра після правок.
Такий порядок дає передбачуваний випуск: кожен етап закінчується перевірюваним результатом, а не обіцянкою.
Що залишається в репозиторії та документації після здачі
Здача — це не момент, коли трафік пішов через межу мережі, а стан репозиторію, у якому наступна правка безпечна для інженера, який відкрив його через пів року.
Тому перелік артефактів узгоджуємо до старту й закриваємо за чек-лістом: без будь-якого пункту робота не вважається завершеною.
- конфігурація проєкту повністю, з розділенням тестового й продуктивного середовищ: розгортання відтворюється однією командою, без ручних правок у панелі;
- правила маршрутизації — які шляхи й хости йдуть у Cloudflare Workers, що залишається на основному сервері, як задано пріоритет збігів;
- вихідні коди обробників з описом точок входу: запит, задача за розкладом, черга;
- схема рішення: шлях запиту від DNS до відповіді, межі кешування, час життя даних у шарах, точки відмови;
- конфігурації сховищ і прив’язок: простори ключ-значення, об’єктне сховище, виставлені ліміти;
- регламент оновлення й відкату: як випускається версія, як перемикається трафік, за який час повертаємося на попередню;
- правила роботи з секретами: що лежить у змінних середовища, у кого доступ, як проходить ротація;
- документація: локальний запуск, схема середовищ, порядок моніторингу та контакти відповідальних.
Окремим блоком передаємо порядок спостережуваності: метрики, пороги алертів за помилками й затримкою, посилання на панелі моніторингу. Такий комплект дозволяє змінювати маршрути й логіку без нас — правка не перетворюється на дослідження чужого проєкту.
Кейс: скоротили час відповіді та зняли навантаження з сервера
До
Проєкт — сервіс з особистим кабінетом і зовнішнім програмним інтерфейсом: уся логіка жила на одному кластері в одному регіоні. Кожен запит, включно зі статикою та довідковими даними, доходив до сервера, а в пікові години звернення вишиковувалися в чергу.
Час відповіді на 95-му процентилі тримався на рівні 0,8 секунди, у користувачів із віддалених регіонів — понад секунду; три чверті потужності сервера йшло на повторювані відповіді.
Після
Обчислення для запитів без стану винесли на межу, на Cloudflare Workers: маршрутизацію, редиректи, вибір версії інтерфейсу, складання відповіді з кешу та довідкових даних.
Ключ кешу збирали з урахуванням заголовків і ознак сесії, щоб персоналізовані відповіді не змішувалися між користувачами. Запитам, яким потрібна база, залишили проксіювання до сервера з обмеженням повторів і таймаутів — недоступність межі не перетворюється на помилку в клієнта.
Час відповіді на 95-му процентилі — 0,18 секунди, на межі обробляється 72% запитів, кількість звернень до сервера скоротилася вчетверо. Кластер перестав бути вузьким місцем: за подвоєння трафіку черга на сервері не з’являлася. Окремо пішов клас відмов, пов’язаний із перевантаженням на повторюваних запитах.
Що робити, якщо контент уже роздається через зворотний проксі
Найчастіше межа обчислень стає не на порожнє місце: трафік уже йде через зворотний проксі, де термінується шифрування, живуть кеш, стиснення, редиректи та правила доступу. Зносити цю схему не потрібно — пограничний шар вбудовується поверх неї, а не замість неї.
Перший крок — інвентаризація: вивантажуємо правила маршрутизації з конфігурації проксі та звіряємо їх із тим, що реально видно в логах.
Значна частина правил виявляється спадщиною, яку ніхто не наважується видалити, і саме на них найпростіше зловити розходження в поведінці після перенесення.
Далі вмикається дзеркальний режим: запит іде і в нову межу, і в наявну схему, відповіді порівнюються за кодом, заголовками й тілом. Розходження стають видні до того, як їх побачать користувачі, а не після.
Поетапне перенесення йде від простого до складного: спочатку на межу йдуть статика, редиректи й віддача зображень, потім маршрути з авторизацією, і лише потім усе інше. Відкат на будь-якому етапі — правка одного правила маршрутизації, а не перерозгортання інфраструктури.
На проксі залишаються задачі, яким там і місце: внутрішні сервіси, перевірка прав, інтеграції із закритим контуром.
Маршрутизація при цьому сходиться до однієї точки правди — дублі з конфігурації прибираються, поведінка перевіряється на живому трафіку, і Cloudflare Workers перестає бути окремим островом поруч з основною роздачею.
Технічні сумніви: ліміти, відмови та порядок відкату
Ліміти платформи впираються не в трафік, а в тривалість обробки запиту, обсяг зібраного коду й кількість одночасних звернень до зовнішніх сервісів. Важкий синхронний виклик усередині обробника першим впирається в стелю за часом: клієнт отримує помилку замість відповіді.
Тому ми виносимо важке за межі запиту — в кеш, чергу та фонові задачі, залишаючи в обробнику лише маршрутизацію й видачу.
Що відбувається, коли воркер падає?
Кожен запит виконується в окремому ізольованому середовищі, тому збій одного виклику не валить сусідні й не зупиняє сервіс повністю. Платформа піднімає виконання на наступному запиті, але вже без стану, який був у пам’яті.
Отже, усе критичне — лічильники, кошики, прогрес — має жити в зовнішньому сховищі, а не в змінних модуля.
Як повернутися до попередньої версії?
Історія розгортань зберігається на боці платформи: повернення робиться перемиканням на минулу збірку, а не повторною збіркою з репозиторію.
Ми тримаємо маршрутизацію за частками трафіку, тому відкат спочатку перевіряється на невеликій частині запитів і лише потім вмикається повністю. Вікно відкату обмежене: старі версії з часом витісняються, тому значущі релізи ми закріплюємо окремо.
Як зрозуміти, що щось пішло не так?
Дивимося на три величини: частку відповідей із помилкою, час відповіді та кількість винятків в обробнику. Події йдуть у загальний потік, де за ідентифікатором запиту відновлюється весь ланцюжок — від маршруту до звернення до сховища.
Алерт ставимо на зростання помилок вище звичайного фону, інакше шум від поодиноких збоїв закриває реальну деградацію.
Обговоримо задачу та повернемося з оцінкою й планом
Оцінка виходить предметною, коли є що оцінювати: як влаштований поточний потік запитів, яка логіка має виконуватися на краю, до яких сервісів і сховищ вона звертається. Тому перший крок — короткий розбір задачі разом із вашою командою, без змін у робочому контурі. Від вас потрібні опис задачі, тестовий контур і доступи; решта — наша робота.
У відповідь повертаємо:
- Склад робіт — розкладений за напрямами: маршрутизація й розподіл трафіку, кешування відповідей, перевірка доступу на краю, обробка відмов і логування.
- План впровадження — етапами з перевірюваним результатом на кожному: пілот на одному маршруті, переведення частки трафіку, повне виведення. Між етапами залишається точка повернення до попередньої схеми.
- Строки — за кожним етапом, з окремою позначкою того, що залежить від вашої сторони: записи DNS, сертифікати, вікно змін, тестові дані.
- Конфігурації та політики — правила кешування, обмеження частоти запитів, розмежування середовищ, схема відкату розгортання на попередню версію.
- Критерії приймання — які метрики вважаємо результатом: час відповіді, частка запитів, оброблених на краю, відсутність зростання помилок після перемикання.
- Ризики та обмеження — що в поточній архітектурі завадить переведенню і яким способом це обходимо.
Опишіть задачу — що має змінитися в поведінці системи і до якого строку це потрібно. Повернемося з оцінкою робіт, планом впровадження та зрозумілим складом.
