Почему Azure CDN не ускоряет сайт: разбор типовых сбоев
Подключение Azure CDN само по себе не ускоряет сайт. Если правила кеширования, сертификаты и порядок сброса не настроены под реальную структуру статики, метрики не меняются: время ответа прежнее, нагрузка на источник не падает, часть посетителей видит сломанные страницы. Доставка контента — не переключатель, а набор связанных параметров конфигурации.
Самый частый сбой — кеш отдаёт устаревшую версию статики. Узел опирается на заголовки кеширования от источника: если их нет или время жизни выставлено неверно, файлы либо не кешируются, либо остаются в кеше после релиза. После выкладки новой версии браузер получает старый скрипт вперемешку с новым оформлением — интерфейс рассыпается, форма не отправляется.
Второй сбой — HTTPS отваливается на поддомене статики. Сертификат выпущен на основной домен и не покрывает отдельный поддомен, либо отдаётся неполная цепочка сертификатов. Браузер блокирует такие ресурсы: страница открывается, но остаётся без картинок и стилей.
Третий сбой — источник не разгружается. Если узел не отдаёт статику из кеша, каждый запрос уходит на сервер приложения, и пик трафика кладёт его так же, как без доставки контента. Отдельная причина — ручной сброс кеша после релиза: его выполняют не для всех путей, и часть пользователей ещё долго видит смесь версий. Разбираем, как каждый из этих сбоев закрывается.
Что даёт настроенное кеширование: измеримые эффекты
Периметр на Azure CDN меняет профиль нагрузки на источник: часть запросов до него просто не доходит. Ниже — три эффекта, которые видно в метриках после настройки, а не в отчёте о проделанной работе.
Разгрузка источника и снятие пиковой нагрузки
Статику — изображения, шрифты, скрипты, стили — отдаёт ближайшая к пользователю точка присутствия, а не сервер приложения. На источнике остаются запросы к динамике и API, поэтому в пик — запуск кампании, публикация каталога, массовый вход сотрудников — он получает в разы меньше одновременных соединений. Правила кеширования по расширению и отдельный короткий срок жизни для разметки дают предсказуемую долю попаданий вместо «кешируем всё подряд».
Стабильное время отклика страницы при всплесках трафика
Когда трафик вырастает кратно, отклик определяется наличием готовой копии и расстоянием до точки выдачи, а не мощностью сервера. Статика с длинным сроком жизни уходит из кеша без обращения к источнику, поэтому график времени отклика остаётся ровным вместо провала на пике. Нагрузочный прогон до и после настройки показывает разницу по хвостам распределения, а не по среднему — именно там видны проблемы.
Единый HTTPS и корректные перенаправления на всех доменах
Сертификат живёт на периметре: продление и смена ключей не зависят от конфигурации веб-сервера. Правило перенаправления сводит основной домен, алиасы и HTTP к одному каноническому виду с сохранением пути и параметров запроса, так что дублей у поисковых роботов не остаётся. Сброс кеша запускается из CI/CD сразу после релиза — обновлённые файлы доступны без ручных действий и без окна, когда часть пользователей видит старую версию.
Профили Azure CDN: сравнение вариантов доставки
Профиль доставки определяет, какие правила кеширования доступны: у стандартного набора это общие настройки, у расширенного — правила по путям, расширениям и заголовкам запроса. Выбор стоит зафиксировать до переключения домена: часть вариантов не взаимозаменяема без смены точки входа.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Стандартный профиль доставки | статика, одинаковая логика для всех разделов | общие настройки, правил по путям нет |
| Профиль с расширенными правилами | у API, статики и медиа разный срок жизни | правила нужно версионировать и тестировать |
| Свой обратный прокси с кешем | нужен контроль над ключом кеша и инвалидацией | отдельный узел, который надо эксплуатировать |
| Кеш на источнике | ответы под авторизацией, приватные данные | канал не разгружается, выигрыш только на повторах |
Правила кеширования по путям
Правило по пути привязывает поведение к префиксу адреса: /api/ — без кеша, /static/ — час, /media/ — сутки. Первое совпадение обычно останавливает разбор, поэтому исключения ставят выше общих масок, иначе персональные ответы уйдут в общий кеш.
Правила по расширениям файлов
Правила по расширениям (.css, .js, шрифты, изображения) читаются проще и покрывают сборку целиком. Слабое место — адреса без расширения и параметры версии в запросе: их описывают отдельно, иначе после обновления файла клиент получит прежнюю копию.
На практике расширенный профиль поверх кеша на источнике даёт предсказуемый срок жизни статики и сброс через программный интерфейс из сборочного процесса — без ожидания истечения срока после выкладки.
Порядок внедрения: от аудита контента до передачи
Кеширование в Azure CDN настраиваем итерациями: сначала фиксируем, что именно раздаётся, затем описываем правила и только потом включаем основной трафик. Порядок исключает случай, когда кеш уже отдаёт контент, а правила для него ещё не заданы.
- Инвентаризация доменов и типов контента. Собираем имена и поддомены, размечаем статику, медиа, файлы сборки и ответы сервисов. Для каждого типа отмечаем, кешируется он или идёт в обход.
- Схема кеширования. Задаём сроки хранения по группам файлов, правила учёта строки запроса и поведение при обновлении: версионированные файлы получают длинный срок, точки входа — короткий.
- Привязка домена. Подключаем точку присутствия, привязываем домен, сверяем соответствие доменных записей и порядок отдачи.
- Сертификат и HTTPS. Выпускаем сертификат, включаем принудительный HTTPS и перенаправления, проверяем цепочку на каждом поддомене.
- Очистка кеша в конвейере. Встраиваем шаг очистки после публикации — сборка сама сбрасывает изменившееся, без ручных действий дежурного.
- Проверка и передача. Прогоняем сценарии, фиксируем результат, передаём доступы, схему и регламент.
Проверка сценариев
Проверку строим на реальных путях: обновление отдельного файла, полный откат релиза, смена сертификата, очистка по маске. Сценарий считаем пройденным, только когда новая версия видна во всех точках, а старая не возвращается из промежуточных хранилищ.
Первый релиз и передача
Первый релиз ведём с пониженной долей трафика: часть запросов идёт через сеть доставки, часть напрямую. Когда доля попаданий в кеш и время отдачи совпадают с ожидаемыми, переводим весь поток и закрываем этап передачей доступов, схемы и регламента.
Документация, схемы и регламенты после внедрения
После запуска Azure CDN у команды заказчика остаётся комплект документов, по которому изменения вносят без нас. Это же точка входа для нового инженера: по нему видно, почему правило кеширования задано именно так и что произойдёт при откате.
Конфигурация и правила доступа
- Правила кеширования готовой конфигурацией: файл в репозитории, где по путям и расширениям заданы сроки хранения — статика с длинным сроком, HTML и ответы API с коротким или с полным обходом кеша.
- Карта точек присутствия: какие узлы обслуживают аудиторию, где включено сжатие и где возможности урезаны, чтобы не закладывать в правила то, что не сработает в части регионов.
- Настройки HTTPS и перенаправлений: привязка сертификата (управляемый или собственный), принудительный переход с HTTP, минимальная версия TLS, правила перезаписи путей.
- Матрица доступа: кто меняет правила, кто только смотрит метрики, кто запускает очистку кеша.
Регламент релиза
- Встроенный шаг очистки кеша: после выкладки конвейер вызывает очистку по маске путей и тегам, дожидается подтверждения и идёт дальше только при успехе — иначе релиз останавливается.
- Порядок выпуска версий: сборка, выкладка, очистка, прогрев, проверка — с пометкой, какие шаги безопасно повторять.
- Инструкция по проверке и снятию метрик: контрольные запросы к ключевым путям, состояние кеша в заголовке ответа, доля попаданий и время отклика узлов, с порогами для отката.
Кейс: как разгрузили источник и стабилизировали отклик
Что было до настройки
Витрина с тяжёлой статикой: изображения каталога, стили, скрипты, шрифты. Кеш на Azure CDN жил с одним коротким сроком для всех типов файлов и без привязки к версиям сборки — из кеша отдавалась лишь треть запросов, остальное уходило на источник.
В часы пик отклик рос вместе с трафиком, а после релиза всплывал отдельный класс отказов: разметка на несколько минут ссылалась на файлы, которых на периметре ещё не было.
Что сделали
Развели правила кеширования по типам контента: версионированные файлы сборки получили длинный срок жизни, HTML — короткий с обязательной ревалидацией, ответы API исключили из кеша. В конвейер добавили шаг очистки — кеш инвалидируется по маскам после публикации артефактов и до переключения трафика.
Какие метрики получили
Доля попаданий в кеш выросла с трети до большинства — около четырёх пятых запросов. Обращений к источнику стало примерно втрое меньше, и отклик при пике перестал расти: время ответа держится на уровне внепиковых часов.
Класс «битая статика после релиза» закрыт — окно рассогласования между выкладкой и инвалидацией устранено. Откатов не потребовалось: прежние артефакты живут в кеше до конца срока, поэтому возврат на предыдущую версию остаётся мгновенным.
Чем отличается очистка кеша от версионирования статики?
В Azure CDN принудительный сброс (purge) удаляет объект с узлов присутствия, не дожидаясь истечения срока жизни кеша. Операция асинхронная: ответ приходит сразу, а расходится по узлам минутами, поэтому между выкаткой и гарантированно новым контентом остаётся окно. Задаётся сброс по точному пути или по маске — маска удобнее, но задевает всё совпавшее с шаблоном.
Версионирование статики решает ту же задачу иначе: сборка кладёт хэш в имени файла, а разметка ссылается на новый адрес. Прежний файл остаётся доступным, новый на узлах ещё не встречался — инвалидация не нужна в принципе. Побочный эффект — старые версии копятся в хранилище, поэтому их вычищают отдельным правилом жизненного цикла.
Выбор диктует изменяемость имени. Скрипты, стили, шрифты и изображения версионируются, им ставится долгий срок жизни с признаком неизменяемости — браузер перестаёт переспрашивать. Адреса с фиксированным именем — разметка, манифест, конфигурации — так не версионируются, для них остаётся только сброс.
На практике это две политики в одной раздаче. Разметку отдают с коротким сроком жизни и сбрасывают по маске из конвейера сборки, ассеты — с длинным и без сброса вообще. Очистка кеша по маске вроде каталога со всеми ассетами рискованна: массовая инвалидация гонит трафик на источник и легко попадает на пик нагрузки.
Итог: смена имени — норма для собираемых файлов, сброс — для фиксированных адресов. Смешивать обе стратегии в одном правиле не стоит.
Частые технические вопросы по кешу и HTTPS
Кеш на кромке не отменяет логику приложения: сначала источник решает, зависит ли ответ от пользователя, и только потом ответ попадает в хранилище кромки. Поэтому почти все сомнения при передаче настроек — про то, где проходит граница между статикой и персональным ответом, и кто ей управляет: правило на кромке или заголовки источника.
Ниже — пять вопросов, которые чаще всего всплывают на приёмке и в первые недели эксплуатации.
Динамические страницы с персонализацией вообще можно кешировать?
Можно, но выборочно. Запросы с авторизационными cookie и заголовком авторизации уходят в обход кеша, кешируются только анонимные GET. Для персональных страниц источник отдаёт запрет на хранение — тогда кромка не держит ответ ни секунды, и данные не утекают между пользователями.
Почему после релиза часть пользователей видит старую версию страницы?
Расхождение версий возникает, когда разметка и файлы интерфейса живут с разным временем жизни. Разметку отдаём с коротким временем жизни, а файлы — с длинным и хешем в имени, чтобы старый и новый наборы не смешивались в одной странице. Сброс кеша по изменившимся путям выполняется в конвейере сборки до переключения трафика: инвалидация расходится по узлам не мгновенно.
Что произойдёт с сайтом при продлении сертификата?
Управляемый сертификат продлевается автоматически, если домен указывает на кромку записью CNAME и не проксируется сторонним сервисом — проверка владения проходит по DNS. С собственным сертификатом новый загружается заранее, а прежний остаётся активным до окончания перекрытия: разрыв соединения и предупреждения в браузере не возникают.
Правки на источнике не появляются — что проверять первым?
Сначала заголовки самого источника: они приоритетнее правил кромки. Затем — входит ли строка запроса в ключ кеша: при её отсутствии адреса с разными параметрами отдают один и тот же ответ. И третье — не слишком ли широко правило обхода по cookie, из-за которого кеш не наполняется вовсе.
Как убедиться, что кеш действительно работает?
Смотрим признак попадания и возраст ответа в заголовках, а не только время загрузки в браузере. Проверяем из нескольких регионов и по разным типам файлов, затем закрепляем в конвейере проверку: после сброса кеша ответ должен обновиться. Так регресс настройки ловится до жалоб пользователей.
Обсудим задачу: что подготовить к старту работ
Оценка настройки Azure CDN ускоряется ровно настолько, насколько полны входные данные. Когда домены, типы контента и схема окружений собираются по частям, мы тратим время на уточнения вместо проектирования правил кеширования. Ниже — минимальный набор, с которым можно сразу считать архитектуру.
- Перечень доменов и поддоменов — с пометкой, какие отдают статику, какие проксируют API и не должны кешироваться вовсе. Отдельно — планы по новым именам и порядку привязки сертификатов.
- Типы контента и доли статики — какие пути кешируем долго, какие перепроверяем на каждом запросе, где контент меняется часто. Это определяет правила по расширениям, путям и заголовкам ответа.
- Схема окружений — сколько сред, как стенды отделены от продакшена, нужны ли отдельные профили и как распределяется трафик между источниками.
- Текущее состояние HTTPS — где выпускаются сертификаты, есть ли собственные, требуется ли принудительная переадресация и минимальная версия протокола.
- Порядок выпуска версий — как сегодня выкладываются сборки, чем запускается сброс кеша и что должно произойти при откате на предыдущую версию.
- Правила доступа и роли — кто управляет профилем, как выдаются права и на какие среды, нужна ли изоляция между командами.
- Ограничения источников — закрытые хранилища, балансировщики, ограничения по географии и требования к журналам запросов.
Опишите задачу в этом объёме — вернёмся с оценкой и планом работ, включая схему кеширования, порядок подключения HTTPS и шаг сброса кеша в конвейере выпуска.
- Кешируют сайт целиком, вместе со страницами личного кабинета и корзиной — посетители получают чужие данные и устаревшие состояния заказа.
- Не разделяют статику и динамику: одинаковые правила для картинок и для откликов сервиса, из-за чего либо ускорения нет, либо ответы «залипают» и не обновляются.
- Назначают срок хранения «на глаз», без учёта того, как часто меняется контент, и потом вручную чистят кеш после каждой правки.
- Очистку после выкладки делают руками или забывают добавить в конвейер сборки — часть посетителей ещё долго видит прежнюю версию.
- Не проверяют цепочку сертификатов и перенаправление на защищённое соединение: часть страниц грузится по незащищённому каналу, браузер показывает предупреждение, посетитель уходит.
- Оставляют открытым доступ к исходному серверу — роботы и посетители обходят ускоритель по прямому адресу и получают медленный или устаревший ответ.
- Не следят за долей попаданий в кеш и не смотрят на поведение после правок: непонятно, работает ли ускорение вообще и не деградировало ли оно после очередного обновления.
- Сваливают в один профиль Azure CDN несколько несвязанных сайтов и окружений: сбой правил на одном проекте роняет ускорение на остальных, а разграничить ответственность внутри команды уже нельзя.
