Почему edge и origin почти никогда не рассказывают одну и ту же историю
Когда сайт или API защищены Cloudflare, возникает естественное искушение судить о результате теста по тому, что показывает edge: низкая latency, хороший cache hit ratio и устойчивость публичного домена под ростом трафика. Проблема в том, что edge может выглядеть отлично, пока origin уже начинает страдать на некэшируемых путях, miss-запросах, админских маршрутах или API-вызовах с персонализированным контентом.
Именно поэтому нагрузочное тестирование за CDN всегда начинается с вопроса: какую часть цепочки мы сейчас проверяем? Если цель состоит в оценке кэша, WAF и edge-limiters, это одна гипотеза. Если нужно понять поведение приложения, базы и внутренних сервисов, то без наблюдаемости на origin вы увидите только половину картины. Сам по себе хороший ответ Cloudflare ещё не означает, что ваше приложение готово к настоящему пику.
Английская пара этой статьи находится в Stress testing behind Cloudflare CDN. Для связки с веб-подготовкой полезно также прочитать Stress test сайта перед Чёрной пятницей, потому что именно на пиковых распродажах контраст между edge и origin проявляется сильнее всего.
Сначала формулируйте гипотезу, потом выбирайте маршрут трафика
Без чёткой гипотезы тест за Cloudflare быстро превращается в шум. Например, одна команда хочет убедиться, что каталог выдержит всплеск кэшируемого трафика. Другая хочет понять, хватит ли origin для авторизованного API. Формально обе задачи можно назвать «нагрузочным тестом сайта», но архитектурно это совершенно разные упражнения и разные критерии успеха.
Если вы исследуете CDN-поведение, маршрут должен включать cacheable ресурсы и проверку правил кэширования, purge и edge throttling. Если цель — application path, придётся идти по маршрутам, которые обходят кэш естественным образом: login, checkout, персонализированный контент, поиск или внутренний API. Важно не пытаться объединить оба сценария в один средний тест. Тогда станет непонятно, какой именно слой породил деградацию.
Помочь в выборе слоя может и статья L4 и L7 нагрузочное тестирование. За CDN почти всегда нужен L7-подход, но даже внутри L7 вы должны ясно разделять проверку edge-оптимизаций и проверку origin-логики.
Какие метрики смотреть одновременно у Cloudflare и у origin
Со стороны Cloudflare полезно смотреть cache hit ratio, challenge rate, частоту блокировок, аномалии по маршрутам, распределение статусов и latency на edge. Эти данные помогают понять, как ведёт себя публичный вход в систему. Но без зеркального набора метрик на origin вы не узнаете, куда ушёл некэшируемый трафик и как он повлиял на реальные серверы.
На origin минимумом являются CPU, память, сеть, ошибки приложения, saturation connection pool, очереди, file descriptors, latency по endpoint и всё, что связано с базой данных и upstream-зависимостями. Если edge уже фильтрует часть нагрузки, это не отменяет обязанности смотреть на backend. Наоборот, именно за Cloudflare особенно легко недооценить локальную деградацию, потому что внешний фасад остаётся красивым дольше обычного.
Отдельно отслеживайте время восстановления после остановки. Иногда тест формально завершается успешно, но origin потом ещё десять минут разгружает очередь или догоняет реплики базы. Такие хвосты очень важны для оценки реальной устойчивости и часто влияют на решение о масштабе релиза или маркетинговой кампании.
Как проводить тест безопасно и управляемо
Защищённый периметр не делает тест автоматически безопасным. Всё равно нужен согласованный scope, подтверждённые цели, понятное окно и уведомление ответственных команд. Особенно важно заранее определить, что считается красной зоной: рост ошибок на origin, слишком агрессивные challenge для легитимных клиентов, saturation базы или нежелательные эффекты на смежных маршрутах.
Поскольку тест идёт через рабочий edge-слой, любые резкие изменения WAF-режимов во время прогона ухудшают качество результата. Намного полезнее зафиксировать конфигурацию, провести измерение, а потом уже вносить изменения и повторять тест на тех же маршрутах. Этот цикл даёт воспроизводимость и позволяет отличать реальное улучшение от случайности. Все такие действия должны оставаться в рамках /legal и только на авторизованных целях.
Если вы регулярно проверяете CDN-путь, разумно подобрать план на /pricing по длительности и concurrency, а рабочий доступ оформить через /register. При работе за Cloudflare удобство пошагового прогона и мгновенной остановки часто ценнее агрессивного выхода на максимум.
Как интерпретировать результат без ложной уверенности
Наиболее частый анти-паттерн выглядит так: команда видит, что публичный домен отвечает быстро, и делает вывод, что инфраструктура готова к росту трафика. Но если при этом растёт latency на miss-path, распухают очереди на origin или начинает страдать авторизованный API, то тест на самом деле выявил проблему, а не подтвердил готовность. Просто проблема скрыта за хорошим edge-фасадом.
Полезный итог такого прогона всегда конкретен. Например: «CDN выдерживает каталог, но персонализированный API требует увеличения pool size», или «WAF корректно фильтрует аномалии, но checkout-path теряет SLA при росте concurrents». Именно такие выводы потом превращаются в задачи для платформенной и продуктовой команды. Не бойтесь результата «не готово»; бойтесь только неопределённости, когда тест прошёл, а инженерных решений из него не появилось.
Хороший stress test за Cloudflare учит разделять внешний комфорт пользователя и внутреннюю реальность origin. Как только команда начинает думать этими двумя слоями одновременно, качество подготовки к релизам и пиковым событиям заметно растёт.