Глобальная доставка статики: настройка Cloud CDN в GCP

Настройка GCP Cloud CDN: где раздача статики ломается

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

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

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

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

Что даёт кеширование на границе сети

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

Время ответа и полнота загрузки страницы

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

Разгрузка источника и поведение под пиками

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

Способы раздачи статики: что выбрать под задачу

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

Прямая отдача из объектного хранилища

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

Собственная прослойка против управляемой раздачи

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

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

Порядок настройки: от аудита до передачи

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

Что фиксируем на этапе аудита

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

1. Инвентаризация контента. Типы файлов, сроки хранения, схема версионирования имён — от неё зависит, можно ли держать файл в кеше долго.
2. Схема маршрутизации запросов. Карта путей на бэкенд-бакеты и сервисы, порядок правил, поведение для несуществующих адресов.
3. Правила кеширования. Что входит в ключ кеша, какие заголовки и параметры игнорируются, сроки по умолчанию и переопределения для отдельных путей.
4. Подключение домена и сертификата. Привязка домена к раздаче, выпуск управляемого сертификата, проверка валидации и переключение трафика.
5. Проверка на контрольных сценариях. Холодный и повторный запрос, обновление файла, принудительный сброс кеша, корректность заголовков ответа.
6. Наблюдаемость. Журналы запросов, доля попаданий в кеш и время ответа по краю — по ним видно, что настройка работает, а не выглядит настроенной.
7. Передача и обучение. Регламент выкладки и сброса кеша, схема тестового окружения и разбор с командой, которая дальше ведёт раздачу сама.

Конфигурации, схемы и регламенты раздачи

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

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

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

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

Регламент обновления версий и инвалидации

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

Разгрузка источника: результаты внедрения

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

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

Метрики до и после

Замеры снимали на реальном трафике, сверяя метрики источника, попадания в кеш и ошибки публикации за одинаковые периоды до и после. Источник перестал быть узким местом и снова занялся динамикой, а выпуск новой версии больше не сопровождается разбором жалоб на «поехавшую» верстку.

Что делать, если статика уже отдаётся через сторонний CDN?

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

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

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

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

Технические сомнения перед внедрением

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

Что отдаётся, если источник недоступен?

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

Влияет ли CDN на сборку и выкладку?

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

Как ограничить доступ и уйти от горячих ссылок?

Закрытый бакет плюс подписанные ссылки с ограниченным сроком: посторонний ресурс не сможет встроить ваш файл и съесть трафик. Для потокового видео подпись выдаётся на сессию через cookie. Дополнительно отсекаем чужие домены проверкой источника запроса.

Где смотреть статистику кеша?

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

Обсудим задачу раздачи статики и план работ

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

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

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