Edge functions: де периферія ламається під навантаженням
Обробка запитів на периферії виглядає як безкоштовне прискорення: код ближче до користувача, джерело розвантажене, відгук рівніший. Ламається це на трьох речах — ініціалізації обробника, доступі до спільного стану й узгодженості з джерелом даних.
Cloudflare Workers і споріднені середовища виконання будувалися під короткі операції без пам’яті; щойно в них з’являється логіка зі станом, виявляються межі платформи.
Сплеск трафіку б’є першим: вузол обслуговує безліч обробників у спільному пулі, і поки одні прогріваються, інші чекають своєї черги. Далі спрацьовує ліміт на зовнішні підзапити — обробник переходить у помилку, і клієнт замість редіректу чи актуальної ціни отримує відповідь 5xx.
Помилки під час сплеску надходять пачками, а не розсипом: вузол, що вичерпав ресурс, відмовляє всім запитам підряд, зокрема тим, що могли б відпрацювати з кешу.
Друге вузьке місце CDN — конкурентні записи до спільного стану. Лічильник показів, ліміт за адресою, кошик: усе, що зберігається в пам’яті обробника, за паралельних запитів на різних вузлах читається й перезаписується одночасно, і частина змін зникає без жодного рядка в логах.
Закривається це винесенням стану в спільне сховище та ключем на користувача, але кожне звернення до нього додає затримку — її доводиться компенсувати локальним шаром із коротким часом життя.
Третій клас відмов — розсинхронізація з джерелом даних. Правила кешу й момент публікації на сервері жодним чином не пов’язані: поки периферія тримає стару версію, покупець бачить знятий з продажу товар, а підтримка отримує звернення, яких могло не бути.
Інвалідація за тегом і версіонування ключа це закривають, але вимагають дисципліни у формуванні імені об’єкта. Водночас перевантаження периферійного вузла — чесний сигнал: якщо частка відмов зростає за незмінного навантаження на джерело, справа не в трафіку, а в будові логіки. Розбираємо, як це закривається — від схеми стану до поведінки при деградації.
Що змінюється в роботі сервісу після винесення логіки на периферію
Логіка, винесена на периферію, виконується у вузлі мережі, найближчому до користувача, а не на джерелі.
Туди переїжджають перевірка токена, редіректи, нормалізація заголовків, розподіл трафіку між варіантами й відсікання сміттєвих звернень — усе, що раніше займало з’єднання з основним контуром.
Cloudflare Workers і споріднені середовища запускають такий код на кожному вузлі, тому він масштабується разом із географією аудиторії, а не з потужністю джерела.
Час відгуку перестає залежати від відстані до джерела: відповідь збирається в тому самому регіоні, де перебуває користувач. Статика й закешовані відповіді віддаються одразу, динамічні обчислюються на місці, а до джерела доходить лише те, що потребує доступу до бази. Розкид між ближніми й дальніми регіонами згладжується, і типові звернення прискорюються в рази.
Частка запитів, що не доходять до джерела, — головна метрика ефекту.
Редіректи, віддача кешу, перевірка сесії та фільтрація паразитного трафіку закриваються на периферії: до джерела доходить помітно менша частина звернень, і ця частка стійко тримається на рівні десятків відсотків від загального потоку.
Заодно зникає цілий клас відмов — джерело перестає бути єдиною точкою, куди сходяться всі запити одразу.
Під час піків — розпродаж, публікація, зовнішній сплеск — вузли поглинають навантаження й продовжують відповідати, поки джерело відновлюється, а саме джерело отримує рівний потік замість хвилі.
Навантаження на нього знижується настільки, що сезонні сплески перестають вимагати заздалегідь розгорнутого запасу потужностей.
Підходи до обробки запитів: порівняння режимів і обмежень
Правила кешування на боці CDN закривають більшість задач узагалі без коду: кеш за шляхом і розширенням, нормалізація ключа кешу, редіректи, різний час життя для статики й розмітки.
Поки логіка не залежить від вмісту запиту, край мережі передбачуваніший за будь-яке середовище виконання — немає чого збирати, немає чого оновлювати й відкочувати.
Щойно з’являється логіка — гео-перевизначення, A/B-роздача, підпис посилань, збирання відповіді з кількох джерел — потрібні периферійні обчислення.
Легкі функції на краю розраховані на коротку правку запиту або відповіді, повноцінні середовища виконання на кшталт Cloudflare Workers дають звичайний рантайм, але зі своїми лімітами.
Загальний набір обмежень середовища виконання однаковий: немає довільних бібліотек без збирання, немає прямого доступу до бази, окремі моделі деплою, логування й відкату.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила кешування без коду | Статика, редіректи, ключ кешу, заголовки | Логіка не залежить від вмісту запиту; порядок правил важко супроводжувати |
| Легкі функції на краю | Правка заголовків, перевірка підпису, редірект | Жорстка межа часу й розміру коду, немає мережевих викликів із функції |
| Середовище виконання на краю | Персоналізація, A/B-роздача, відповідь із кількох джерел | Ліміти процесорного часу й пам’яті, своє збирання й формат модулів |
| Серверний прошарок перед джерелом | Важка логіка, доступ до бази, довгі обчислення | Мережева затримка, ще одна точка масштабування й відмови |
Серверний прошарок знімає ліміти периферії, але додає мережеву затримку й другу точку відмови — його ставлять там, де край технічно не витягує.
Робоча схема зазвичай гібридна: край кешує й відсікає шум, прошарок робить важке, а правила кешування CDN і перевизначення на краю при цьому не конфліктують.
Етапи впровадження: від розбору трафіку до передачі в експлуатацію
Роботу ведемо послідовно: спочатку вимірюємо, що реально надходить на периферію, потім проєктуємо правила й лише після цього пишемо код. Так периферійна логіка не ламає наявні сесії та кеш, а результат видно в метриках, а не у відчуттях.
- Аудит трафіку. Знімаємо статистику за запитами: частка статики й динаміки, географія, повторюваність відповідей. Окремо рахуємо, які шляхи можна обслужити на периферії, а які зобов’язані йти на джерело.
- Схема маршрутизації. Готуємо карту правил: де працює кеш, який шлях обробляє функція, як передаються заголовки й cookie, щоб не розірвати авторизацію та персоналізацію.
- Налаштування периферійної логіки. Реалізуємо функції: редіректи й канонічні адреси, нормалізація заголовків, обмеження частоти, видача контенту з найближчої точки. Заздалегідь ураховуємо ліміти часу виконання й пам’яті.
- Перевірка на тестовому контурі. Проганяємо сценарії на копії конфігурації, звіряємо відповіді периферії та джерела, дивимося поведінку за недоступності джерела — має працювати коректний запасний шлях.
- Перевірка на бойовому трафіку. Спочатку вмикаємо в режимі логування, потім на малій частці запитів. Порівнюємо час відповіді, частку влучань у кеш і кількість помилок; відкат — перемиканням одного правила.
- Передача в експлуатацію. Віддаємо конфігурацію в репозиторії, викладку через конвеєр, дашборди й оповіщення, регламент відкату та інструкції для вашої чергової зміни.
Артефакти впровадження: конфігурації, політики, регламенти
Після впровадження edge-функцій у команди залишається не звіт для галочки, а робочий комплект: файли в репозиторії, схеми й регламенти. За ними зміну можна випустити й відкотити без нашої участі — це і є перевірка, що передача відбулася.
- Конфігурація маршрутів. Прив’язка шляхів і хостів до обробників, порядок їхнього спрацьовування, винятки для службових і статичних запитів. Файл лежить поруч із кодом і проходить рев’ю разом із ним.
- Схема обробки запиту. Шлях від браузера через точку присутності до джерела: де підставляються заголовки, де читається кеш, де запит іде на сервер застосунку.
- Політики доступу й ключів. Ролі, області видимості токенів, розділення середовищ, порядок ротації секретів і зберігання їх у захищеному сховищі замість коду функції.
- Набори перевірок. Тести поведінки функцій у передпродуктивному середовищі, звірка заголовків і кодів відповіді, прогін кешованими маршрутами під навантаженням.
- Регламент відкату. Покрокове повернення попереднього набору правил, умови спрацьовування й ознака, за якою видно, що периферія повернулася в робочий стан.
- Регламент випуску. Як зміна потрапляє на продуктив: гілки, рев’ю, порядок викладки, хто підтверджує готовність.
- Документація з інфраструктури. Опис середовищ, змінних, зон відповідальності й типових операцій — щоб новий інженер розібрався без листування з автором рішення.
Кейс: як скоротили час відгуку й прибрали клас відмов
Що було на джерелі
Джерело віддавало не лише дані, а й усе обрамлення запиту: редіректи, заголовки безпеки, вибір мови й валюти, статику, розмітку для тестів інтерфейсу.
Кожна така відповідь проходила повне коло до джерела, і в години розпродажів воно впиралося в межу не за даними, а за кількістю з’єднань. Частка відповідей із помилкою сягала 2,4%, а час відгуку на 95-му перцентилі зростав утричі щодо спокійних годин.
Що перенесли на периферію
На периферію Cloudflare винесли шар, якому не потрібна база: нормалізацію адрес і редіректи, заголовки безпеки, гео- та мовний роутинг, видачу статики, розмітку для тестів інтерфейсу.
Кеш-ключ зібрали з регіону, мови й ознаки авторизації — персональні відповіді, як і раніше, збираються на джерелі, решту віддають із найближчої до користувача точки присутності. Частина логіки на edge functions гасить короткі сплески повністю, не доходячи до джерела.
Що стало після перенесення
Медіана відгуку скоротилася в рази, 95-й перцентиль — утричі. Частка помилкових відповідей упала з 2,4% до 0,15%, тобто клас відмов, який раніше проявлявся саме на піку, зник.
Навантаження на джерело в години розпродажів знизилося більш ніж удвічі за того самого трафіку, а піковий день минув без деградації та ручних втручань.
Зміни на периферії викочуються окремим випуском і відкочуються за хвилини, тому правки в логіці більше не потребують перезбирання основного застосунку. Метрики відгуку й частка помилок за регіонами виведені в спільний дашборд — регрес видно до того, як його помітять покупці.
Чим edge functions відрізняються від серверного прошарку
Зворотний проксі перед джерелом і периферійна логіка розв’язують різні задачі, хоч зовні виглядають схоже. Проксі приймає запит, збагачує заголовки, відсікає сміття й передає далі — обробка все одно йде на конкретному сервері, а мережевий шлях до нього залишається повним.
Периферійна функція виконується там, де користувач віддає з’єднання: на вузлі присутності, поруч із точкою термінації TLS і кешем.
Затримка скорочується по-різному. Проксі прибирає один перехід до джерела й частину навантаження із застосунку, але не саму обробку. Периферійна логіка прибирає й її — поки обчислення замкнене на даних, що лежать на вузлі.
Щойно потрібен запис до бази або читання з джерела, запит усе одно йде назад, і виграш розчиняється в тому самому переході.
Доступ до даних — головний обмежувач. На периферії є розподілені сховища «ключ-значення» з узгодженістю зрештою: без блокувань, довгих транзакцій і звичних SQL-з’єднань. Туди переносять маршрутизацію, перевірку підпису токена, варіанти інтерфейсу, нормалізацію заголовків. Операції з балансами, замовленнями й правами залишаються на джерелі.
Налагодження розподіленої логіки дорожче. Локальне середовище відтворює вузол частково: поведінка кешу, географія й ліміти відрізняються, а стек викликів збирається з журналів кількох вузлів і джерела. На проксі залишається один процес зі звичним налагоджувачем і передбачуваним логом.
Вартість володіння рахують за інженерним супроводом, а не за тарифом за запити. Периферійний код виграє на великих обсягах однотипного трафіку, але додає точок відмови й потребує окремої дисципліни викочування.
Проксі підтримувати простіше, однак він залишається єдиною точкою на шляху запиту. Межа проходить по даних: логіка без узгодженого стану — периферія, з ним — джерело.
Технічні сумніви перед запуском: середовище, обмеження, відкат
Перед запуском edge-функцій технічний керівник перевіряє не код, а поведінку системи в поганих умовах: недоступність джерела, пікове навантаження, частково перенесені маршрути. Ці питання ми розбираємо на старті й фіксуємо відповіді в конфігурації, а не в листуванні.
Середовище виконання орендується в хмарного провайдера, але відповідальність за налаштування, ліміти й поведінку під навантаженням залишається на команді. Тому до викату визначаємо власника конфігурації, місце зберігання секретів і джерела телеметрії.
Що станеться, якщо джерело перестане відповідати?
Кожне правило отримує таймаут і резервну поведінку: віддати закешовану відповідь, повернути заглушку або пропустити запит напряму. Таймаут задаємо коротшим за бюджет очікування клієнта, щоб відвідувач не чекав на відмову.
Чи можна перенести на периферію лише частину маршрутів?
Так — маршрутизація налаштовується за префіксами шляхів: один розділ іде на периферію, решта працюють як раніше. Так ми порівнюємо метрики двох контурів на одному трафіку й поступово розширюємо охоплення.
Як виглядає відкат зміни?
Конфігурація живе в системі контролю версій, викат іде через перевірку зі збереженням попереднього стану. Відкат — повернення до минулої ревізії та повторний викат: хвилини на відновлення замість години ручних правок.
Що буде за пікового навантаження?
Ліміти одночасних виконань задаємо заздалегідь; коли вони вичерпуються, запити обслуговує основний контур застосунку — деградація замість відмови. Перед запуском проганяємо навантажувальний профіль і дивимося частку помилок і час відповіді.
Обговоримо задачу: що потрібно для оцінки та плану робіт
Розділ нижче — про те, як задача перетворюється на оцінку робіт і план впровадження. Щоб розрахунок спирався на фактичний стан периметра, а не на загальні міркування, нам потрібні доступи й ввідні: тоді ми бачимо реальні правила кешування, обсяг конфігурації та чинні обмеження.
Що потрібно від вас на вході:
- Доступ лише на читання до панелі CDN і DNS-зони — подивимося записи, правила кешування, редіректи й прив’язку сертифікатів.
- Репозиторій із конфігурацією периметра та складальним конвеєром: оцінимо, що розгортається автоматично, а що правиться руками.
- Список доменів і піддоменів із ролями — які віддають статику, які працюють з API та особистими кабінетами.
- Сценарії для edge-функцій: A/B-роздача, гео-редіректи, перевірка токенів, трансформація заголовків, віддача заглушки при збої бекенда.
- Профіль навантаження: пікові запити, частка динамічних відповідей, географія користувачів і чутливість до затримки.
- Обмеження: вікна змін на бойовому контурі, вимоги до відкату та політика безпеки з логуванням.
- Відповідальні: хто володіє DNS і хто підтверджує викатку в бій.
На виході ви отримуєте оцінку робіт, схему доопрацювання із зонами відповідальності та план впровадження за етапами — з тестовим контуром, точками відкату й перевірками на кожному кроці. Опишіть задачу й надішліть доступи — повернемося з оцінкою та планом.
