Настройка Yandex Cloud CDN: origin, кеширование и TLS

Настройка Yandex Cloud CDN: узкие места раздачи

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

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

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

Третье — обрывы соединений и лишняя нагрузка на приложение. Если раздача статики и динамика идут через один и тот же вход, источник тратит ресурс на установку соединений вместо обработки запросов, а повторные попытки после таймаута удваивают и утраивают поток. Ограничение одновременных обращений к источнику и корректные таймауты убирают этот класс отказов. Разбираем, как это закрывается на уровне настройки Yandex Cloud CDN: правила кеширования, поведение при промахе и развязка статики с динамикой.

Что меняется после внедрения: скорость и устойчивость

После переключения трафика на сеть доставки Yandex Cloud запросы посетителей обслуживают ближайшие к ним узлы, а источник отвечает только на промахи кеша. Доля попаданий задаётся политиками: для статики — картинок, стилей, скриптов, шрифтов — она выходит на 85–95%, для страниц с персонализацией держится в районе 50–70%. Чем точнее кеш-ключ описывает вариант ресурса — query-параметры, языковые и региональные версии — тем выше попадания и тем меньше риск отдать разные версии одной страницы.

Время ответа страницы падает кратно: статика приходит с узла рядом с посетителем, защищённое соединение устанавливается на периметре, до источника запрос часто не доходит вовсе. В отчёте это видно не по среднему, а по 95-му перцентилю — именно он показывает, что тормозит не отдельный запрос, а хвост распределения.

Сильнее всего меняется класс отказов. Источник перестаёт быть единой точкой: пик трафика гасится на периметре, а не упирается в его потолок по соединениям и процессору. Если источник недоступен или отвечает медленно, периметр отдаёт ранее закешированное — посетитель видит страницу вместо ошибки.

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

Схемы раздачи: кеш на краю, прокси, гибрид

Схема раздачи в Yandex Cloud CDN определяет, какая доля запросов доходит до источника, а какая закрывается на ближайшем к пользователю узле. Выбор делают не «по вкусу», а по профилю трафика: доля статики, частота обновления, требования к приватности и допустимая задержка первого байта.

Три рабочие конфигурации закрывают почти все задачи, и внутри одного домена их комбинируют по путям или по типам контента. Гибрид снимает с источника большую часть трафика и при этом не требует единого времени жизни ответа на весь домен.

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

Как проходит внедрение: этапы и точки проверки

Настройка Yandex Cloud CDN — это не «включить ускорение», а перенос точки встречи трафика с источника на границу сети. Работы идут последовательно: сначала фиксируем, что реально отдаёт источник, затем строим схему, проверяем её на боевом и только потом переключаем пользователей.

1. Аудит источника. Смотрим, какие типы контента отдаёт сервер, какие заголовки кеширования ставит, как отвечает при ошибках и запросах с параметрами. Здесь же выясняем, что кешировать нельзя — иначе раздача начнёт отдавать устаревшие данные.
2. Схема раздачи. Разделяем домены и пути: что идёт через сеть, что остаётся на источнике, какие запросы обходят кеш и по какому признаку.
3. Настройка кеширования и сертификатов. Время жизни по типам контента, ключ кеша, правила сброса; сертификат на границе, цепочка доверия, перенаправление на защищённый протокол для всех поддоменов.
4. Проверка кеша. Доля попаданий, обновление после публикации, поведение при недоступном источнике — по каждому правилу прогоняем тестовые запросы до переключения.
5. Переключение трафика. Переводим постепенно: сначала часть запросов или неприоритетный домен, следим за долей ошибок и временем ответа, держим обратный перевод на прямую раздачу.
6. Передача. Конфигурация сохраняется как код, описываются дежурные сценарии — обновить контент, посмотреть статистику, снять нагрузку с источника при сбое.

Точки проверки — после аудита, перед переключением и через сутки после него: на них видно, что схема держит нагрузку и не ломает уже работающие сценарии.

Что остаётся у вас: конфигурации, схемы, регламенты

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

• Конфигурации ресурсов Yandex Cloud CDN: origin-группы, источники, проверки доступности, таймауты и привязка к балансировщику — декларативными файлами с версионированием в репозитории.
• Правила кеширования: сроки жизни по типам контента, ключи кеша с учётом параметров строки запроса и заголовков, отдельное поведение для авторизованных запросов.
• Политики доступа: подпись запросов к источнику, защита от хотлинка, ограничения по реферу и гео, правила обхода кеша для отладочных проверок.
• Схема раздачи — маршрут запроса от клиента через точку присутствия до источника, с точками кеширования, зонами отказа и логикой переключения.
• Документация по TLS: цепочка сертификатов, порядок выпуска и продления, привязка к доменам и способ аварийной замены при истечении.
• Регламент дежурной смены: какие метрики смотреть, что считать инцидентом, пороги реакции, порядок инвалидации кеша и отката конфигурации.

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

Площадку доставки собирали на Yandex Cloud, но исходная схема кеширования работала против источника. Источник отдавал и статику, и API: правила кеша были общие, параметры запроса попадали в ключ, поэтому одинаковые скрипты считались разными объектами. В акционные часы источник получал почти весь трафик, отклик рос с доли секунды до нескольких, часть запросов завершалась ошибкой.

Контент разобрали по классам и прописали правила кеша в проекте. Версионированную статику отдаём с длинным сроком хранения, страницы и данные — с коротким, персональные ответы API идут мимо кеша. Из ключа убрали лишние параметры, оставив влияющие на содержимое, а сжатие перенесли на край — источник перестал тратить силы на то, что уже лежит в сети доставки.

Возврат к источнику в пиковые часы

На источник добавили резервную площадку и ограничили частоту обращений из сети доставки, чтобы всплеск промахов не сваливался одним потоком. Управляющие заголовки и метки версий формирует сама сборка: после релиза новый контент забирается один раз, а не на каждый запрос.

Результат в измеримых величинах

Доля ответов из сети доставки выросла с ~55% до 93%, пиковая нагрузка на источник упала вчетверо. Отклик статики сократился примерно в 2,5 раза, а отказы в пиковые часы ушли: раньше их было несколько эпизодов на акцию, теперь ноль. Схема держит всплеск в 3-4 раза выше обычного без правок в приложении — сайт не переписывали.

Чем пограничная сеть отличается от балансировщика?

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

Пограничная сеть решает другую задачу — отдача статики и закешированных ответов ближе к посетителю. Ближайшая к пользователю точка принимает соединение, завершает TLS на своей стороне и отдаёт готовый ответ из кеша, не поднимая запрос к исходному серверу (origin). Попадание в кеш обслуживается на границе, промах уходит в контур.

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

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

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

Частые технические вопросы перед внедрением

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

Как менять адресацию origin без простоя для посетителей?

Новый источник поднимается рядом и проверяется запросами доступности до переключения. Затем переводим трафик на коротком TTL, а старый держим горячим запасным — возврат записи даёт откат за минуты, без перенастройки посетителей на стороне Yandex Cloud.

Как клиент получает актуальную версию страницы, если контент обновили?

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

Что делать с сертификатами — выпускать новые или подключать свои?

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

Origin закрыт для внешнего доступа — прослойка сможет его забрать?

Да. Источник открываем только для адресов прослойки, остальные обращения получают отказ — напрямую в обход кеша попасть нельзя. Для приватных объектов выдаём подписанные ссылки с ограниченным сроком жизни.

Обсудим вашу схему раздачи контента

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

• Перечень доменов и поддоменов, для которых планируется раздача, с указанием основного и вспомогательных.
• Описание origin: статический бакет, собственный веб-сервер или несколько источников, и как между ними распределяется трафик.
• Объём контента и профиль нагрузки: доля статики и динамики, типы файлов, примерный объём отдачи в сутки и пиковые всплески.
• География аудитории и требования к TLS: свои сертификаты или выпуск на стороне сервиса, нужен ли принудительный переход на защищённый протокол.
• Правила обновления контента: как часто меняются файлы, нужна ли точечная очистка кеша по тегам и как быстро новая версия должна становиться видимой.
• Текущая схема защиты и доступов: кто управляет DNS-зоной, какие роли нужны нашим инженерам и что остаётся под вашим контролем.
• Ограничения и пожелания: допустимое время отклика, требования к отказу на резервный источник и режим работы при недоступности origin.

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