Настройка CDN Edge Functions (Cloudflare Workers / CloudFront Functions)

Edge functions: где периферия ломается под нагрузкой

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

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

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

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

Что меняется в работе сервиса после выноса логики на периферию

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

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

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

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

Подходы к обработке запросов: сравнение режимов и ограничений

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

Как только появляется логика — гео-переопределения, A/B-раздача, подпись ссылок, сборка ответа из нескольких источников — нужны периферийные вычисления. Лёгкие функции на краю рассчитаны на короткую правку запроса или ответа, полноценные среды выполнения вроде Cloudflare Workers дают обычный рантайм, но со своими лимитами. Общий набор ограничений среды выполнения одинаков: нет произвольных библиотек без сборки, нет прямого доступа к базе, отдельные модели деплоя, логирования и отката.

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

Этапы внедрения: от разбора трафика до передачи в эксплуатацию

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

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

Артефакты внедрения: конфигурации, политики, регламенты

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

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

Кейс: как сократили время отклика и убрали класс отказов

Что было на источнике

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

Что перенесли на периферию

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

Что стало после переноса

Медиана отклика сократилась в разы, 95-й процентиль — втрое. Доля ошибочных ответов упала с 2,4% до 0,15%, то есть класс отказов, который раньше проявлялся именно на пике, ушёл. Нагрузка на источник в часы распродаж снизилась более чем вдвое при том же трафике, а пиковый день прошёл без деградации и ручных вмешательств.

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

Чем edge functions отличаются от серверной прослойки

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

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

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

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

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

Технические сомнения перед запуском: среда, ограничения, откат

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

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

Можно ли перенести на периферию только часть маршрутов?

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

Как выглядит откат изменения?

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

Что будет при пиковой нагрузке?

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

Обсудим задачу: что нужно для оценки и плана работ

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

Что потребуется от вас на входе:

• Доступ только на чтение к панели CDN и DNS-зоне — посмотрим записи, правила кэширования, редиректы и привязку сертификатов.
• Репозиторий с конфигурацией периметра и сборочным конвейером: оценим, что разворачивается автоматически, а что правится руками.
• Список доменов и поддоменов с ролями — какие отдают статику, какие работают с API и личными кабинетами.
• Сценарии для edge-функций: A/B-раздача, гео-редиректы, проверка токенов, трансформация заголовков, отдача заглушки при сбое бэкенда.
• Профиль нагрузки: пиковые запросы, доля динамических ответов, география пользователей и чувствительность к задержке.
• Ограничения: окна изменений на боевом контуре, требования к откату и политика безопасности с логированием.
• Ответственные: кто владеет DNS и кто подтверждает выкатку в бой.

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