Настройка CDN через BunnyCDN: Pull/Push зоны, Edge Rules и видео

Настройка BunnyCDN: где ломается отдача статики и видео

Пока трафик небольшой, отдача статики и видео выглядит здоровой: файлы уходят прямо из точки, где живёт приложение, и никто не замечает подмены. Но как только аудитория распределяется по регионам, картина меняется — пользователь из другого региона тянет тяжёлые файлы через длинный маршрут, напрямую с сервера-источника.

Первое, что видно в замерах, — время до первого кадра у видео и время до отрисовки у картинок растут вместе с расстоянием. Плеер уходит в буферизацию, часть запросов обрывается по превышению времени ожидания, а в поддержку приходят жалобы на «тормозит» без конкретики. Доля попаданий в кэш на периферии при этом остаётся почти нулевой: контент не задерживается рядом с пользователем.

Второе — нагрузка на сервер-источник. На пиках полоса выбирается целиком, и вместе с видео деградирует всё остальное: ответы приложения, выгрузки, обращения к базе. Медленная отдача видео перестаёт быть отдельной проблемой и становится триггером для всего сервиса — источник занят раздачей файлов вместо обслуживания логики.

Причина обычно не в мощности сервера, а в конфигурации раздачи: заголовки кэширования не выставлены, параметры запроса делают каждый адрес уникальным, а зоны раздачи не разделены по типам контента. Настройка BunnyCDN начинается с диагностики этой картины — разбираем, как закрыть каждую из точек отказа.

Что даёт правильно собранный CDN-слой: эффекты и метрики

Правильно собранный CDN-слой измеряется не фактом включения, а тремя цифрами: долей попаданий в кэш, временем отдачи с ближайшей точки и объёмом трафика, который вообще не доходит до источника. Ниже — что даёт каждый эффект и за счёт чего он достигается при настройке BunnyCDN.

Доля попаданий в кэш и время отдачи

На старте доля попаданий обычно держится на 60–70%: мешают разный вид ключа кэша при параметрах запроса, короткие TTL и динамические пути, которые кэшировать нельзя. Нормализация ключа, вынос статики на длинные TTL и аккуратные правила на границе поднимают показатель до 90–95% — край отдаёт контент из ближайшей точки, страница приходит заметно быстрее, а повторные запросы до источника не доходят вовсе.

Прогрев кэша после релиза снимает классический провал: первым посетителям не приходится ждать, пока граница наполнится. Отдача остаётся ровной и в мобильных сетях, где любая лишняя задержка видна сразу.

Разгрузка источника и исходящего трафика

Кэш на границе срезает основную часть исходящего трафика источника: сервер отдаёт только промахи, обновления контента и динамику. Источник перестаёт быть узким местом при пиках — распродажа, массовая рассылка или публикация в СМИ больше не превращаются в очередь запросов и отказы.

Заодно уходит целый класс сбоев: упор в лимиты соединений, таймауты при всплеске, отказы под нагрузкой. Раздача видео выносится в отдельную зону, и тяжёлый поток не конкурирует с сайтом за ресурс источника — пик распределяется по точкам присутствия, а не по одному серверу.

Как это собирается на практике — зоны, правила на границе и схема раздачи видео — разбираем дальше.

Настройка BunnyCDN: Pull-зоны, Push-зоны и Edge Rules

Выбор режима раздачи определяет, откуда периферия берёт контент и что делает с ним по пути. В BunnyCDN это задаётся типом зоны и набором правил — от них зависит и скорость отдачи, и поведение при обновлении файлов.

Кэширование по расширениям и кодам ответа

Правила задают масками с приоритетами: для стилей, шрифтов и сборок — длинный срок с меткой immutable, для видеоплейлистов и сегментов — секунды, для HTML — малый срок или отключённый кэш. Отдельно перечисляют коды ответа: 200 и 301 держат, 404 — недолго, чтобы не грузить origin, 5xx и 403 не кэшируют. Инвалидация кэша точечная — по URL или тегу; полная очистка зоны обнуляет прогрев и возвращает нагрузку на origin.

Edge Rules: заголовки, переписывание путей, ограничения

Edge Rules правят запрос и ответ: подставляют Cache-Control, CORS и HSTS, скрывают служебные заголовки, переписывают путь для версионированных сборок, делают редиректы с сохранением параметров. Срабатывает первое совпадение, поэтому частные условия ставят выше общих. Ограничения — конечное число правил на зону и отсутствие произвольного кода: сложную логику выносим на origin.

Порядок внедрения: от аудита трафика до передачи

Маршрут внедрения BunnyCDN строим так, чтобы раздача переключилась без простоя и без сюрпризов для сервера-источника. Сначала фиксируем, как трафик распределён сейчас, затем проектируем зоны и только после проверки переводим аудиторию.

Аудит текущей схемы раздачи

1. Инвентаризация раздачи трафика. Снимаем карту запросов: доля статики, изображений и видео, география, пиковые часы, какие пути чаще всего доходят до сервера-источника. На выходе — таблица объёмов и требований к кешу.
2. Проектирование зон. Под статику и видео — Pull-зоны, под крупные файлы с редкими обновлениями — Push-зоны с предварительной загрузкой. Здесь же определяем ключи кеша, сроки хранения и разделение по типам контента.
3. Настройка правил на границе. Заголовки кеширования, обработка параметров в адресе, сжатие, доступ к серверу-источнику по подписи и порядок принудительного обновления кеша.

Проверка на реалистичном профиле нагрузки

• Нагрузочная проверка. Воспроизводим пик: одновременные запросы к видео, всплеск на одном популярном файле, холодный кеш после очистки. Смотрим долю попаданий, задержку ответа и нагрузку на источник.
• Переключение трафика. Переводим долями через записи с коротким сроком жизни, наблюдая за ошибками и откликом источника. Прежняя схема остаётся рабочей до конца перевода — откат занимает минуты.
• Передача документации. Отдаём описание зон и правил, регламент обновления кеша, схему раздачи, доступы и порядок типовых операций.

Что заказчик получает на руки: конфигурации и регламенты

После внедрения у команды остаётся не набор настроек в веб-панели, а комплект, по которому инфраструктуру можно поднять заново и передать дежурной смене. Все артефакты лежат в репозитории и проходят ревью — правки руками в интерфейсе не остаются незамеченными.

Схема потоков и конфигурация зон

• Декларативные конфигурации зон: серверы-источники, тип зоны (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-зоны, если трафик переключаем на нашей стороне.

На выходе вы получаете оценку работ, схему зон и правил раздачи, а также план внедрения с порядком переключения трафика и точкой отката на прежнюю схему. Опишите задачу в свободной форме — где что лежит и что болит. Вернёмся с оценкой и планом.

• Отдают через сеть доставки только картинки и стили, а видео и тяжёлые файлы продолжают уходить напрямую с основного сервера — на пиках он снова упирается в предел, а выделенная пропускная способность простаивает.
• Ставят один срок хранения копий на весь сайт: страницы, статика, видео и персональные ответы требуют разного времени, а единое правило ломает либо свежесть, либо выгоду от кэширования.
• Кэшируют ответы, зависящие от пользователя — корзину, личный кабинет, персональные подборки. Посетитель получает чужие данные, и это уже не про скорость, а про утечку.
• Обратная ошибка: отключают кэширование «на всякий случай» и получают слой доставки, который честно пересылает каждый запрос на источник, не снимая с него никакой нагрузки.
• Не продумывают обновление контента: после правки статьи или замены файла посетители видят старую версию, а команда чистит кэш целиком и прогревает его заново с нуля.
• Путают назначение зон: отправляющие зоны заводят там, где нужна тянущая логика, и наоборот — видео идёт неоптимальным маршрутом, а источник нагружается лишним.
• Забывают про подготовку изображений и сжатие: тяжёлые исходники уходят в сеть как есть, и объём передаваемых данных не снижается.
• Не смотрят на отчёты: непонятно, какая доля запросов доходит до источника, где промахи кэша, какие адреса отдают ошибки, — решения принимаются вслепую.
• Не проверяют поведение при недоступности источника: запасной копии нет, поэтому короткий сбой источника превращается в полную остановку отдачи.
• Запускают без проверки под нагрузкой: слабые места в правилах вскрываются в разгар рекламной кампании, когда трафик максимальный и чинить некогда.