ISR-штормы и cold starts: самоDDoS, который вы назначили себе сами

Анатомия ISR-шторма

К концу урока вы будете точно знать, какое решение команды породило 8-секундный p95, — и какое одно инфраструктурное изменение не даст ему повториться при следующей рассылке. ISR (Incremental Static Regeneration — инкрементальная статическая регенерация) в установившемся режиме — машина размазывания нагрузки. Каждая запись несёт собственное окно revalidate, отсчитанное от момента генерации; запрос после окна мгновенно получает устаревшую копию и запускает одну фоновую регенерацию. Нагрузка на origin — один рендер на страницу за окно, размазанный трафиком по времени. Каждый шторм — одно и то же событие: что-то ломает размазывание и синхронизирует инвалидации.

Триггер первый: деплой сбрасывает кеш. На своём хостинге Full Route Cache и Data Cache по умолчанию живут в файловой системе в .next/cache внутри контейнера — раскатка заменяет контейнеры, и каждый новый стартует пустым. На managed-платформах новый деплоймент засеян только пререндерами времени сборки; все on-demand-записи, накопленные с прошлого деплоя, исчезают. В обоих случаях длинный хвост, который вы грели днями, испаряется за одну раскатку. Триггер второй: широкая ревалидация. CMS при массовой публикации шлёт вебхук на каждую запись, и обработчик зовёт revalidatePath для каждой; или кто-то «чинит устаревание» вызовом revalidatePath('/', 'layout'), инвалидирующим все маршруты приложения разом. Триггер третий: выровненные окна — после любого синхронного стирания все записи регенерируются в пределах нескольких минут, их окна теперь истекают вместе, и шторм повторяется каждое окно, пока трафик их не рассинхронизирует.

Арифметика и превращает это из «медленно» в инцидент. 30 000 страниц каталога по 4 запроса, перегенерированные за десять минут, — это 120 000 запросов к базе, выделенной под установившийся ручеёк: самоDDoS, где ботнет — ваш собственный путь рендеринга. Хуже: после стирания устаревшей копии нет, подушка stale-while-revalidate исчезла — первые запросы блокируются на рендере вместо старой страницы, поэтому шторм виден как пользовательская задержка, а не только как нагрузка на БД. С репликами всё умножается: три пода с тремя приватными файловыми кешами — это до трёх независимых рендеров на путь плюс мерцание контента, пока балансировщик чередует под, успевший перегенерировать, с подом, ещё отдающим старую копию. Механика ISR — в уроке о стратегиях рендеринга в начале трека; поверхность инвалидации по тегам — в юните про слой данных; этот урок — о том, что бывает, когда обоими управляют в масштабе флота.

Митигации, меняющие механизм

Прежде чем тянуться к «добавьте подов», спросите себя: поды с приватными кешами делят нагрузку или умножают рендеры? Каждая настоящая митигация убирает одно из предусловий шторма; ни одна из них не «добавьте подов» (поды с приватными кешами делают хуже).

Вынести кеш из процесса. Кастомный cacheHandler в next.config переносит Full Route Cache и Data Cache в Redis или другое общее хранилище. Умирают сразу два предусловия: кеш переживает деплои (новые контейнеры подключаются к тому же хранилищу, длинный хвост остаётся тёплым) и реплики делят записи (одна регенерация на путь, без мерцания). Каверза корректности, которая кусает команды: если деплой меняет форму страницы, старые записи теперь неверны — включайте build id в ключ или ревалидируйте изменённые разделы на деплое через очередь ниже, осознанно, вместо надежды на случайное полное стирание.

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

Очередь и кап регенерации. Массовые вебхуки не должны звать revalidatePath инлайн, по разу на событие. Складывайте слаги в очередь, дедуплицируйте и дайте воркеру разгребать её с конкурентностью, рассчитанной из свободного запаса базы: если у Postgres есть 500 QPS запаса, а рендер стоит 4 запроса, кап — около 100 одновременных регенераций, и массовая публикация на 5 000 SKU занимает спокойные несколько минут вместо одной горячей.

Отдавать устаревшее, пока штормит. CDN впереди со stale-while-revalidate и stale-if-error — внешний щит: во время шторма пользователи получают страницу ограниченной свежести вместо 8-секундного рендера. Назовите бюджет устаревания вслух: «во время штормов регенерации цены могут отставать до 10 минут» — это продуктовое решение, и его письменная фиксация делает митигацию легитимной.

Cold starts: на что на самом деле уходит инициализация

Cold start — всё между «инстанса не существует» и «ваш обработчик выполняется»: развернуть и распаковать бандл, распарсить и скомпилировать JavaScript — доминирующее, пропорциональное размеру слагаемое; десятки мегабайт зависимостей стоят секунды CPU до всякой логики запроса, — поднять фреймворк (манифесты маршрутов, инструментация), затем набрать соединения: TLS плюс рукопожатие с базой — 50–300 мс на инстанс, оплаченные до первого запроса. Поджарый маршрут укладывает инициализацию в низкие сотни миллисекунд; маршрут, тянущий тяжёлый ORM, AWS SDK и markdown-конвейер, платит 2–5 секунд.

Cold starts невидимы на p50 и владеют вашим p99, и кучкуются они ровно в двух предсказуемых местах. Час деплоя: раскатка заменяет каждый инстанс — весь флот холоден одновременно, и p99 на несколько минут становится гистограммой инициализации. Переход «впадина — всплеск»: ночное масштабирование в ноль означает, что всплеск 09:00 приземляется на ноль тёплых инстансов, а раз всплеск конкурентный, платформа поднимает N инстансов параллельно — N пользователей разом платят полный cold start; это и есть 8-секундный p95 из пролога. Честный список митигаций: меньшие бандлы маршрутов (главный рычаг — мерьте размер на маршрут, lazy-импортируйте тяжёлые пути, держите гигантские SDK вне общих модулей), provisioned concurrency (пол из всегда тёплых инстансов; реально работает и стоит как маленький постоянный флот — оцените против SLO, а не делайте вид, что бесплатно) и региональное размещение рядом с данными (cold start вдали от Postgres доплачивает межрегиональный RTT, а потом его платит и каждый тёплый запрос). Меряйте cold starts как полноправную метрику: долю инвокаций с фазой инициализации плюс гистограмму её длительности — алерт только на p99-задержку расскажет о шторме после пользователей.