Налаштування BunnyCDN: де ламається віддача статики та відео
Поки трафік невеликий, віддача статики та відео виглядає здоровою: файли йдуть прямо з точки, де живе застосунок, і ніхто не помічає підміни.
Але щойно аудиторія розподіляється за регіонами, картина змінюється — користувач з іншого регіону тягне важкі файли через довгий маршрут, напряму із сервера-джерела.
Перше, що видно у вимірюваннях, — час до першого кадру у відео та час до відмальовування у зображень зростають разом із відстанню. Плеєр іде в буферизацію, частина запитів обривається через перевищення часу очікування, а до підтримки надходять скарги на «гальмує» без конкретики.
Частка влучань у кеш на периферії при цьому залишається майже нульовою: контент не затримується поруч із користувачем.
Друге — навантаження на сервер-джерело. На піках смуга вибирається повністю, і разом із відео деградує все інше: відповіді застосунку, вивантаження, звернення до бази.
Повільна віддача відео перестає бути окремою проблемою і стає тригером для всього сервісу — джерело зайняте роздачею файлів замість обслуговування логіки.
Причина зазвичай не в потужності сервера, а в конфігурації роздачі: заголовки кешування не виставлені, параметри запиту роблять кожну адресу унікальною, а зони роздачі не розділені за типами контенту.
Налаштування BunnyCDN починається з діагностики цієї картини — розбираємо, як закрити кожну з точок відмови.
Що дає правильно зібраний CDN-шар: ефекти й метрики
Правильно зібраний CDN-шар вимірюється не фактом увімкнення, а трьома цифрами: часткою влучань у кеш, часом віддачі з найближчої точки та обсягом трафіку, який взагалі не доходить до джерела. Нижче — що дає кожен ефект і за рахунок чого він досягається під час налаштування BunnyCDN.
Частка влучань у кеш і час віддачі
На старті частка влучань зазвичай тримається на 60–70%: заважають різний вигляд ключа кешу за параметрів запиту, короткі TTL і динамічні шляхи, які кешувати не можна.
Нормалізація ключа, винесення статики на довгі TTL і акуратні правила на межі піднімають показник до 90–95% — край віддає контент із найближчої точки, сторінка приходить помітно швидше, а повторні запити до джерела не доходять зовсім.
Прогрів кешу після релізу знімає класичний провал: першим відвідувачам не доводиться чекати, поки межа наповниться. Віддача залишається рівною і в мобільних мережах, де будь-яка зайва затримка видна одразу.
Розвантаження джерела та вихідного трафіку
Кеш на межі зрізає основну частину вихідного трафіку джерела: сервер віддає лише промахи, оновлення контенту та динаміку. Джерело перестає бути вузьким місцем на піках — розпродаж, масова розсилка або публікація в ЗМІ більше не перетворюються на чергу запитів і відмови.
Заодно зникає цілий клас збоїв: упирання в ліміти з'єднань, тайм-аути під час сплеску, відмови під навантаженням. Роздача відео виноситься в окрему зону, і важкий потік не конкурує із сайтом за ресурс джерела — пік розподіляється за точками присутності, а не за одним сервером.
Як це збирається на практиці — зони, правила на межі та схема роздачі відео — розбираємо далі.
Налаштування BunnyCDN: Pull-зони, Push-зони та Edge Rules
Вибір режиму роздачі визначає, звідки периферія бере контент і що робить із ним по дорозі. У BunnyCDN це задається типом зони та набором правил — від них залежать і швидкість віддачі, і поведінка під час оновлення файлів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Pull-зона | Контент на вашому origin, викладка деплоєм: статика, збірки, зображення | Кеш прогрівається на першому запиті в регіоні, при промахах origin тримає пік |
| Push-зона | Потрібна роздача без власного веб-сервера: файли лежать у сховищі | Публікація через API або панель, автоматичного зв'язку з репозиторієм немає |
| Pull-зона + Edge Rules | Заголовки, шляхи та політика кешу змінюються без правок у застосунку | Логіка живе на периферії — складні умови важче налагоджувати |
| Гібрид: Pull + сховище для відео | Відео відокремлено від веб-контенту, свій цикл публікації та роздача за діапазонами | Два контури налаштувань, синхронізація імен та інвалідації |
Кешування за розширеннями та кодами відповіді
Правила задають масками з пріоритетами: для стилів, шрифтів і збірок — довгий термін із міткою immutable, для відеоплейлистів і сегментів — секунди, для HTML — малий термін або вимкнений кеш.
Окремо перелічують коди відповіді: 200 і 301 тримають, 404 — недовго, щоб не вантажити origin, 5xx і 403 не кешують. Інвалідація кешу точкова — за URL або тегом; повне очищення зони обнуляє прогрів і повертає навантаження на origin.
Edge Rules: заголовки, переписування шляхів, обмеження
Edge Rules правлять запит і відповідь: підставляють Cache-Control, CORS і HSTS, приховують службові заголовки, переписують шлях для версіонованих збірок, роблять редіректи зі збереженням параметрів. Спрацьовує перший збіг, тому часткові умови ставлять вище за загальні.
Обмеження — скінченна кількість правил на зону та відсутність довільного коду: складну логіку виносимо на origin.
Порядок впровадження: від аудиту трафіку до передачі
Маршрут впровадження BunnyCDN будуємо так, щоб роздача переключилася без простою та без сюрпризів для сервера-джерела. Спочатку фіксуємо, як трафік розподілено зараз, потім проєктуємо зони і лише після перевірки переводимо аудиторію.
Аудит поточної схеми роздачі
- Інвентаризація роздачі трафіку. Знімаємо карту запитів: частка статики, зображень і відео, географія, пікові години, які шляхи найчастіше доходять до сервера-джерела. На виході — таблиця обсягів і вимог до кешу.
- Проєктування зон. Під статику та відео — Pull-зони, під великі файли з рідкими оновленнями — Push-зони з попереднім завантаженням. Тут же визначаємо ключі кешу, терміни зберігання та розділення за типами контенту.
- Налаштування правил на межі. Заголовки кешування, обробка параметрів в адресі, стиснення, доступ до сервера-джерела за підписом і порядок примусового оновлення кешу.
Перевірка на реалістичному профілі навантаження
- Навантажувальна перевірка. Відтворюємо пік: одночасні запити до відео, сплеск на одному популярному файлі, холодний кеш після очищення. Дивимося частку влучань, затримку відповіді та навантаження на джерело.
- Переключення трафіку. Переводимо частками через записи з коротким терміном життя, спостерігаючи за помилками та відгуком джерела. Попередня схема залишається робочою до кінця переведення — відкат займає хвилини.
- Передача документації. Віддаємо опис зон і правил, регламент оновлення кешу, схему роздачі, доступи та порядок типових операцій.
Що замовник отримує на руки: конфігурації та регламенти
Після впровадження в команди залишається не набір налаштувань у веб-панелі, а комплект, за яким інфраструктуру можна підняти заново та передати черговій зміні. Усі артефакти лежать у репозиторії та проходять рев'ю — правки руками в інтерфейсі не залишаються непоміченими.
Схема потоків і конфігурація зон
- Декларативні конфігурації зон: сервери-джерела, тип зони (pull або push), правила кешування за типами контенту, тайм-аути та повторні спроби.
- Правила на периметрі: редіректи, заголовки безпеки, обмеження за методом і гео, ліміти на розмір запиту та частоту звернень.
- Схема потоків трафіку: шлях запиту від клієнта до джерела, точки спрацювання кешу, сегмент відео-роздачі та порядок віддачі діапазонів файлу.
- Політики підписаних посилань і токенів доступу: термін життя підпису, прив'язка до адреси клієнта або джерела переходу, ротація ключів без простою.
Регламент оновлення кешу та ролей доступу
- Регламент інвалідації: що чиститься точково, що за префіксом, що живе до закінчення терміну, і очікуваний час до готовності.
- Матриця ролей і прав: хто змінює конфігурацію, хто лише інвалідує, хто бачить аналітику та вивантаження.
- Інструкції для чергової зміни: чек-лист діагностики за шарами, типові збої та порядок відкатів.
- Порядок аварійного переключення джерела та план деградації відео-роздачі.
Кейс: прибрали просідання віддачі на пікових навантаженнях
Клієнт — медіасервіс із каталогом і бібліотекою відео: записи лекцій, розбори, записи трансляцій.
Доставка йшла напряму з серверів застосунку, і на вечірніх піках, коли одночасно підключалися тисячі глядачів, частина запитів закінчувалася відмовою, а каталог відкривався помітно довше звичайного. Розбирали та переводили доставку на BunnyCDN.
Що було до
Один і той самий контур віддавав відеофрагменти, зображення каталогу та дані інтерфейсу. Заголовки кешування на сегментах відео не задавалися взагалі, а прев'ю перезапитувалися в застосунку при кожному оновленні стрічки.
Частка влучань у кеш трималася близько 55%, на піку опускалася до 40% — майже весь трафік ішов на сервери застосунку, і час відповіді на 95-му процентилі зростав у рази. У найгарячіші години відмови під час віддачі сягали 2% запитів.
Що стало після
Рознесли доставку за призначенням: відео — у тягнучу зону з тривалим терміном зберігання сегментів у кеші, статика — в окрему зону з версіонуванням за іменем файлу, щоб оновлення каталогу не скидало весь кеш.
Умовну логіку винесли в правила на периметрі: свій термін життя для зображень, окремий — для маніфестів, примусове кешування для запитів без заголовків. Окремо закрили захист від сплесків: обмеження частоти звернень до джерела та пріоритет відеофрагментів над службовими запитами.
Переключали поступово — спочатку мала частка трафіку, потім повністю, з готовим відкатом в один крок.
Зняли метрики після стабілізації: частка влучань у кеш зросла до 94%, навантаження на сервери застосунку на піку впало на порядок, час відповіді на 95-му процентилі скоротився втричі, відмови під час віддачі — з 2% до 0,05%.
Просідання на вечірніх піках перестали відтворюватися навіть при двократному зростанні одночасних глядачів.
Що робити, якщо CDN уже розгорнуто, але кеш не працює
Кеш «не працює» частіше не через налаштування сховища, а тому що джерело забороняє зберігання.
Дивимося заголовки відповіді: Cache-Control зі значеннями no-store, private або max-age=0, Set-Cookie на статиці, Vary за користувацькими даними — будь-який із них змушує периферію ходити на джерело за кожним файлом.
Перевірка конфігурації починається з двох запитів до однієї адреси — що віддає джерело і що віддає вузол після прогріву; розбіжність у заголовках показує, де губиться зберігання.
Друга причина — різні адреси для одного й того самого файлу. Параметри версії, мітки кампаній, слеш на кінці, варіанти з www і без — для кешу це різні об'єкти, тому частка влучань падає, а джерело отримує трафік, який до нього доходити не повинен.
Лікується канонікалізацією: одна адреса для ресурсу та правила, що ігнорують зайві параметри під час обчислення ключа.
Третя — обхід периферії на стороні застосунку. Шаблони збирають посилання прямо на джерело, застосунок ходить повз вузол, старі сторінки зберігають абсолютні адреси.
Кеш налаштовано коректно, але ним не користуються — це видно з журналів джерела: частка запитів із периферійних адрес після прогріву не зростає.
Четверта — відсутність правил для динаміки. Якщо HTML і відповіді API обробляються тими самими налаштуваннями, що зображення та скрипти, вони не кешуються: без окремого правила з коротким терміном і врахуванням cookies кожна сторінка йде на джерело.
І перевіряємо інвалідацію — після релізу старі об'єкти мають скидатися адресно, інакше правки не доходять до користувачів.
Технічні сумніви, які знімаємо до старту
Перед стартом інженери та керівники напряму ставлять майже ті самі питання — про стійкість роздачі, доступ до закритих файлів і швидкість оновлень. Нижче короткі відповіді без маркетингу: так, як це працює з Pull- і Push-зонами на практиці.
Що буде з роздачею, якщо вузол або цілий регіон вийде з ладу?
Трафік автоматично йде на найближчі живі вузли, а кеш периферії продовжує віддавати статику, поки джерело недоступне. Джерело ми дублюємо — другий сервер або об'єктне сховище, — тому для статики збій залишається непомітним для користувача.
Як обмежити доступ до закритих файлів?
Підписані посилання з обмеженим терміном життя та перевіркою токена на периферії, плюс заборона прямого звернення до джерела за адресою. Посилання перестає працювати після закінчення терміну, а чужий домен не зможе роздавати ваш контент.
Як швидко оновлюється контент після релізу?
Статика з хешем в імені файлу публікується одразу — нової адреси в кеші просто немає. Для решти задаємо керований час життя кешу та точкове скидання за маскою зі складального конвеєра.
Чи доведеться перебудовувати інфраструктуру та DNS?
Ні. Шар стає перед джерелом: домен переводиться на CNAME, сертифікати випускаються та продовжуються автоматично. Відкат — переключенням запису назад, це хвилини, а не вікно простою.
Що змінюється порівняно з роздачею напряму з сервера?
Статика йде на периферію, навантаження на джерело падає — сервер займається динамікою та API. Браузер отримує файли з найближчого вузла, а правила на периферії знімають зайві запити до того, як вони дійдуть до бекенду.
Опишіть вашу схему роздачі та обмеження за доступами — повернемося з оцінкою та планом робіт.Обговоримо задачу: які дані потрібні для оцінки
Щоб повернутися з оцінкою, а не з вилкою «від і до», нам потрібні вихідні дані щодо вашої роздачі. Чим точніший профіль трафіку та поточна схема, тим менше припущень в оцінці робіт і в плані впровадження — а отже, менше сюрпризів на етапі переключення.
- Профіль трафіку: середнє та пікове навантаження, добові й тижневі коливання, частка запитів, які взагалі підлягають кешуванню.
- Географія користувачів: регіони з основним обсягом, вимоги до близькості вузлів роздачі та до затримки віддачі.
- Типи контенту: статика, великі файли, відео — із зазначенням тривалості та того, чи потрібне перемотування всередині потоку.
- Поточна схема роздачі: джерела контенту, домени, як виставлені заголовки кешування та як зараз скидається застаріле.
- Обмеження: терміни, допустимі вікна недоступності, вимоги до доступності та поведінки майданчика при відмові окремого вузла.
- Доступи: панель керування, керуючий програмний інтерфейс і DNS-зони, якщо трафік переключаємо на нашій стороні.
На виході ви отримуєте оцінку робіт, схему зон і правил роздачі, а також план впровадження з порядком переключення трафіку та точкою відкату на попередню схему. Опишіть задачу у вільній формі — де що лежить і що болить. Повернемося з оцінкою та планом.
