Fastly Compute@Edge: чому віддалені користувачі чекають на відповідь
Логіка застосунку зазвичай живе в одному регіоні: там база, там сесії, там бізнес-правила. Користувач з іншої географії за кожен запит платить за відстань — запит іде до джерела й назад, і лише потім надходить перша відповідь.
Чим довший маршрут, тим вища затримка відповіді, причому нелінійно: що далі від джерела, то більше проміжних мереж і то сильніший розкид між окремими користувачами.
Джерело в такій схемі — єдина точка відмови для всіх одразу. Деградація каналу, перевантаження пулу з'єднань або планові роботи в регіоні однаково б'ють по користувачах у будь-якій географії, хоча локально все справно.
Кеш на периметрі проблему не знімає: персоналізовані відповіді, перевірка прав і звернення до даних усе одно тягнуться в центр, а отже, кожен такий запит знову йде через пів світу.
Якщо розрізати телеметрію за географією користувачів, картина стає наочною. Медіана відповіді в близького регіону та у віддаленого відрізняються в рази, а на хвості розподілу розрив ще більший — саме він відчувається як «сайт гальмує» за формально нормальних середніх.
Окремо видно, що частка повільних відповідей зростає синхронно з добовим піком, коли навантаження на джерело максимальне: повільніше стає не одному сегменту, а всім.
Прибирається це не оптимізацією коду, а перенесенням логіки на периметр. Частина обробки — маршрутизація, перевірка токена, збирання відповіді з кешу, переписування заголовків — виконується на вузлі, найближчому до користувача, і до джерела такий запит уже не доходить.
Розбираємо, як це влаштовано на Fastly Compute@Edge і що саме має сенс виносити на периметр, а що залишати в джерелі.
Що дає перенесення логіки на периметр мережі
Логіка, яка раніше жила лише в джерелі, переноситься на периметр — у точки присутності, найближчі до користувача.
У Fastly Compute@Edge вона збирається в компактний модуль і виконується в ізоляції поруч із кешем, тому обробка починається на десятки мілісекунд раніше, ніж запит встиг би дійти до вихідного регіону.
Ефект складається з трьох вимірюваних величин. Час відповіді на маршрутах, де раніше був зайвий круг до джерела, падає з сотень мілісекунд до десятків.
Частка запитів, обслужених на периметрі, після перенесення читання й правил кешування виходить на 90% і вище, а джерело бачить лише промахи кешу та записи.
Розвантаження джерела — прямий наслідок: замість потоку однотипних запитів до нього доходить мала частина, і на піках він перестає бути вузьким місцем.
Горизонтальне масштабування перестає впиратися в перезбирання й прогрів серверів — ємність додається на боці периметра, де реплік спочатку багато.
Окремо зникає клас відмов «упав регіон — упав сервіс»: трафік розподіляється між точками присутності, і випадіння одного майданчика не перетворюється на недоступність сервісу.
Кешування на периметрі працює і як прискорювач, і як елемент відмовостійкості — частину відповідей віддають навіть тоді, коли джерело недоступне.
Варіанти розміщення логіки: коли що підходить
Логіку можна розмістити на трьох рівнях: на периметрі провайдера, у шарі доставки контенту або в самому застосунку. Рівень визначає, що доступно коду — короткоживучі обробники запитів із доступом до сховищ ключ-значення або повноцінний рантайм із базою та фоновими задачами.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Edge-обчислення на периметрі (Fastly Compute@Edge) | Перевірка токенів, редіректи, нормалізація заголовків, збирання відповіді з кешу та ключ-значення | Пісочниця: немає довгих з'єднань і локального диска, урізаний набір системних викликів, ліміт часу на обробку запиту |
| Правила в шарі доставки | Маршрутизація, кеш-політики, роздача за регіонами | Лише декларативні правила — складну логіку не виразити |
| Мультирегіон із контейнерами | Довгі з'єднання, робота з базою, фонові задачі поруч із користувачем | Реплікація даних і маршрутизація між регіонами, складніша узгодженість стану, більше точок відмови |
| Ядро в одному регіоні | Єдина база, регуляторні вимоги, рідкісні піки | Затримка для далеких регіонів: периметр закриває лише статику та частину динаміки |
Вибір схеми розгортання — не «або-або»: периметр зазвичай закриває 70–90% запитів, а ядро залишається для того, що потребує стану. Переносимо маршрути по одному і на кожному кроці звіряємо відповідь із попередньою схемою — відкат тримається в одній правці конфігурації.
Як ми будуємо edge-шар: етапи інженерної роботи
Роботу починаємо з вимірювання, а не з налаштування: поки не видно реального профілю трафіку, винесення логіки на периферію залишається здогадом. Знімаємо картину за запитами і лише після цього збираємо схему.
- Аудит навантаження. Розбираємо журнали за характерний період: співвідношення статики й динаміки, географія, повторюваність відповідей, на якій ділянці втрачається час. На виході — список маршрутів, які виграють від периферії, і тих, що дешевше залишити як є.
- Схема маршрутизації. Фіксуємо, які шляхи обслуговує edge-шар, які йдуть на джерело, за якими ключами кешується відповідь і що відбувається при промаху. Схему узгоджуємо до робіт: переробити маршрути на живому сайті дорожче, ніж на папері.
- Налаштування edge-сервісу. Збираємо модулі на Fastly Compute@Edge: логіка компілюється у WASM і виконується поруч із користувачем. Тестове й бойове середовища розведені, конфігурація описана кодом — середовище відтворюється, а не налаштовується руками.
- Перевірка на бойовому трафіку. Вмикаємо на малій частці запитів і порівнюємо з поточним шляхом за часом відповіді, часткою помилок і влучаннями в кеш. Поріг відкату заданий заздалегідь: перевищення — автоматичне повернення на попередній маршрут.
- Передача в експлуатацію. Віддаємо документацію за маршрутами, політику кешування, панелі моніторингу, алерти й порядок відкату. Далі правила маршрутизації змінює ваша команда — без нашої участі.
Після передачі залишаємося на зв'язку щодо інцидентів, але шар уже живе своїм життям: він покритий перевірками і зрозумілий тим, хто чергує.
Комплект постачання: конфігурації, схеми та регламенти
Комплект документації — не додаток до здачі, а частина результату: з ним ваша команда сама править Edge-сервіс, публікує нову версію та відкочує невдалий реліз, не чекаючи на нас.
- Конфігурації розгортання — декларативні файли з описом сервісів, прив'язок доменів, маршрутів і змінних середовища; версіонуються разом із кодом і переносяться між середовищами без правок руками в панелі.
- Схема проходження запиту — від точки присутності до відповіді: де спрацьовує кеш, де виконується логіка на межі, які заголовки й кукі змінюються по дорозі.
- Політики доступу — ролі та області видимості в панелі, правила випуску ключів, схема зберігання секретів і порядок їхньої ротації.
- Регламент відкату — покрокове повернення на попередню версію, критерії запуску й граничний час, за який процедура має вкластися.
- Інструкції для команди — як зібрати й опублікувати зміну, як читати логи й метрики, що робити при деградації та кому передати питання.
- Порядок перевірок перед публікацією — збирання без попереджень, тести на сумісність, прогрів кешу й контрольні запити після перемикання трафіку.
- Схема моніторингу та оповіщень — які показники знімаються на межі, за яких порогів надходить сигнал і хто його розбирає.
Комплект живе разом із сервісом: при зміні архітектури ми оновлюємо схеми й регламенти, а не залишаємо їх у початковій редакції. Передача йде з розбором — ваші інженери проходять кожен пункт на своєму середовищі, а не читають теорію.
Кейс: зростання швидкості відповіді в розподіленої аудиторії
Що було до перенесення логіки на периферію
Аудиторія розподілена за трьома регіонами, а збирання відповіді відбувалося в одному місці. Узгодження з'єднання та зворотний шлях давали медіану відповіді 0,8 с, а в користувачів далекого регіону піки сягали 2,5 с.
Джерело приймало весь трафік — статику, персоналізацію, запити до даних, — тому потужність тримали із запасом під пік, а при відмові регіону до перемикання на резерв сервіс кілька хвилин віддавав помилки.
Що змінили і що стало
На периферію перенесли персоналізацію, склеювання відповіді з фрагментів, розрахунок ключів кешу та маршрутизацію між регіонами; модулі на WASM виконуються на вузлах поруч із користувачем.
Джерело залишили для запису даних і запитів з авторизацією — частка звернень до нього впала зі 100% до 18%, медіана відповіді за далекими регіонами — до 0,12 с.
Окремо перевірили поведінку при відмові регіону: сусідній вузол приймає трафік за секунди, частка помилок не виходить за звичайний фон, відкат робиться вмиканням попереднього збирання.
Збирання й порівняння метрик до та після вели на Fastly Compute@Edge — тому схожий кейс edge-обчислень відтворюється на іншому проєкті перенесенням конфігурацій, а не переписуванням логіки.
Що робити, якщо частину сервісів уже розгорнуто в одному регіоні?
Часткове перенесення — робоча схема, а не компроміс: ядро залишається в чинному контурі, а на периметр переїжджає те, що виграє від близькості до користувача — маршрутизація, віддача статики, перевірка токенів, нормалізація запитів. Це дає змогу почати перенесення без зупинки продукту і без переписування працюючих сервісів.
Гібридна схема будується на розборі вхідного запиту: за хостом, шляхом або заголовком трафік ділиться між чинним контуром і Fastly Compute@Edge.
Частка переводиться керованим перемикачем — від одного тестового маршруту до повного обсягу, і в будь-який момент повертається назад однією зміною конфігурації.
Поступова міграція йде по одному маршруту: обробник розгортається поруч із поточною логікою, відповіді порівнюються на однакових запитах, розбіжності розбираються до перемикання користувачів.
Потім маршрут переводиться на периметр, а старий шлях залишається холодним резервом на час спостереження.
Межі фіксуємо заздалегідь: стан, транзакції та фонові задачі залишаються в чинному контурі, на периметрі — логіка без стану. Інакше перенесення впреться в розсинхрон даних, і відкат перестане бути безпечним.
Підсумок: частина навантаження йде з ядра, відповідь для зовнішніх користувачів вирівнюється, а міграцію можна продовжувати частинами — без єдиної дати перемикання і без ризику для вже працюючих сервісів.
Технічні сумніви перед перенесенням логіки на периметр
Перенесення логіки на периметр — на Fastly Compute@Edge або аналогічній платформі — змінює не лише затримку, а й клас відмов: край мережі стає точкою, через яку йде весь користувацький трафік. Нижче — заперечення, які найчастіше виринають на етапі оцінки.
Що буде, якщо периферійний вузол відмовить?
Запити йдуть на здорові вузли тієї самої зони, а при недоступності всієї зони — у сусідню: зростає затримка, але не відмова сервісу. Вузли виводяться з ротації за станом, до того як почнуть віддавати помилки. Стан і сесії на периферії не тримаємо — виносимо у сховище.
Як оновлювати логіку без простою?
Нова версія збирається поруч із працюючою, трафік перемикається частками: спочатку контрольна частка, потім основна маса. Відповіді двох версій порівнюються на одному потоці, відкат займає секунди — попереднє збирання залишається доступним.
Чи можна протестувати зміни до бойового викочування?
Те саме збирання запускається локально, потім проганяється на записаному бойовому трафіку з порівнянням відповідей старої та нової версії — розбіжності видно до перемикання, а не після. Окремо перевіряємо таймаути й часткові відмови внутрішніх сервісів.
Як обмежити доступ до внутрішніх сервісів?
Логіка звертається до внутрішніх сервісів лише за дозволеними маршрутами, з підписом запитів і короткоживучими токенами; секрети підставляються під час виконання і до збирання не потрапляють.
Прямі адреси закриті, а через периметр іде лише те, що виграє від близькості до користувача: перевірка доступу, маршрутизація, збирання відповіді.
Обговоримо задачу: з чого почати перенесення логіки
Перенесення логіки починається не з коду, а з інвентаризації того, що вже працює на джерелі.
Щоб обговорити задачу предметно і повернутися з оцінкою впровадження та планом робіт, нам потрібен від вас набір вхідних даних — частина закривається доступом до репозиторію й конфігурації, частина коротким дзвінком з інженером, який веде поточний стек.
- Список маршрутів і правил, які зараз живуть на джерелі: редіректи, заголовки безпеки, роздача трафіку, гео- та мовні умови.
- Що критично за затримкою, а що можна залишити як є — із цього складається пілотна ділянка.
- Схема авторизації: де випускаються токени, як перевіряються підписи, де зберігаються ключі.
- Зовнішні залежності логіки: внутрішні API, кеші, черги, системи аналітики.
- Обмеження середовища виконання: припустимий час відповіді, обсяг пам'яті, розмір збирання при публікації.
- Вимоги до середовищ: скільки стендів потрібно, як випускаються зміни, як робиться відкат.
- Цільові показники: час відповіді на периферії, частка запитів без звернення до джерела, поведінка при збої джерела.
Після розмови ми збираємо план: пілотна ділянка з обмеженим набором маршрутів, критерії приймання, порядок перенесення решти та точки відкату. Оцінка впровадження рахується за обсягом правил і кількістю залежностей — чим повніша інвентаризація, тим точніші строки.
