15 000 одновременных подключений на Next.js SSR: кейс Judo Battle без 503
Финал турнира. Трансляция идёт, соцсети разносят ссылку, тысячи болельщиков одновременно открывают таблицу, профили спортсменов и ленту новостей. Сайт на Next.js с SSR — «тяжёлый»: 24 JS-чанка, динамика, CMS Strapi. CPU на сервере уходит в 100%, очередь растёт, пользователи видят белый экран или 502.
Именно так выглядел исходная точка портала Judo Battle. KPI проекта был жёсткий: 15 000 одновременных соединений без деградации. Ниже — что мы сделали, какие цифры получили на стресс-тесте и чеклист, который стоит пройти до вашего следующего пика.
Рис. 1. При достижении KPI по соединениям узким местом стал канал хостинга, а не CPU приложения
Почему SSR «убивает» сервер при пике
Для CEO и маркетинга сайт «просто должен открываться». Для инфраструктуры SSR — это генерация HTML на каждый запрос: Node.js рендерит страницу, тянет данные из Strapi, собирает бандлы. При 15 000 одновременных соединений даже 8 ядер CPU не спасут, если каждый запрос идёт в приложение.
Типичная ошибка: всё на одной машине — Nginx, Next.js, Strapi, PostgreSQL. Падение одного сервиса валит всё. Плюс открытый SSH и публичные IP между узлами — лишняя поверхность атаки.
| Симптом при пике | Что это значит для бизнеса |
|---|---|
| CPU 100% на фронте | Каждый визит стоит дороже — реклама и органика уходят в никуда |
| 502/504 при живом сервере | Пользователь уходит к конкуренту за 3–5 секунд ожидания |
| Сессии редакторов рвутся | Контент в момент события не обновляется — репутационный удар |
| Нет запаса до рекламного пика | Бюджет на трафик сгорает на ошибках (разбор потерь) |
Архитектура: три узла вместо монолита
Мы разделили контур на три независимых сервера во внутренней сети провайдера (172.16.0.0/28). Снаружи виден только Proxy на 443 порту.
1. Proxy — Nginx + Varnish (12 ГБ под кэш)
Кастомный VCL: статика и JS-чанки — 1 год, immutable. SEO-страницы (новости, участники, клубы) — 10 минут с учётом языковых cookie. RSC, prefetch, API и админка — мимо кэша, чтобы не сломать интерактив.
Grace mode: если бэкенд «задумался» или упал, Varnish ещё час отдаёт устаревшую, но рабочую страницу. Пользователи не видят 502/504 — критично в день финала.
2. Frontend — Next.js в PM2 Cluster (8 инстансов)
Кластер на все ядра CPU. max_memory_restart: 1G — утечка памяти не вешает ноду навсегда. CI/CD на bash по cron (каждые 5 минут): бэкап tar.gz → git pull → build → рестарт через отдельного пользователя pm2safe. Ротация логов при 5 МБ — диск не переполняется.
3. Backend — Strapi × 4 (порты 1337–1340)
Админ-панель жёстко на порту 1337 — сессии модераторов не рвутся из-за балансировки. Публичный API — round-robin по всем инстансам. max_memory_restart: 2G, systemd-служба resurrection после перезагрузки сервера.
Цифры стресс-теста: KPI достигнут, софт «отдыхает»
Проверка — Apache Bench: 15 000 одновременных соединений, 100 000 запросов на тяжёлый SSR-сайт. Результаты:
| Метрика | Значение |
|---|---|
| CPU Proxy (Nginx + Varnish) | ≤ 25% |
| CPU Frontend / Backend | 1–3% |
| RAM в штатном режиме | 2–6 ГБ на машину |
| Узкое горлышко | Канал ~1 Гбит/с хостинга |
Вывод: при целевой нагрузке приложение почти не работало — весь трафик разобрал Varnish. Ограничитель — физика канала, не Node.js.
Один час простоя медиа-портала в день крупного турнира легко обходится в сотни тысяч рублей упущенной рекламы, подписок и партнёрских показов — без учёта репутации. Инвестиция в edge-кэш и изоляцию узлов окупается одним избежанным инцидентом.
Когда Varnish на edge, а когда нет
| Ситуация | Рекомендация |
|---|---|
| Публичные SEO-страницы, каталоги, новости | Кэш на edge (Varnish/CDN), TTL 5–15 мин |
| Личный кабинет, корзина, оплата | Без кэша или сегментированный кэш по cookie |
| Next.js RSC / prefetch / API routes | Явный bypass в VCL — иначе сломаете гидратацию |
| Админка CMS | Sticky session на один инстанс, без балансировки сессий |
Чеклист перед турнирным или рекламным пиком
- ☐ Согласуйте прогноз трафика с техкомандой — в цифрах одновременных соединений, не только «ожидаем хайп»
- ☐ Прогоните стресс-тест с запасом ×2–3 от прогноза
- ☐ Проверьте, что публичные страницы отдаются из кэша (заголовки
X-Cache: HIT) - ☐ Убедитесь, что динамика (RSC, API, админка) обходит кэш по правилам VCL
- ☐ Включите grace mode / stale-while-revalidate — пользователь не должен видеть 502 при кратком сбое
- ☐ Настройте алерты по CPU, RAM и 5xx раньше, чем пожалуются в соцсетях
- ☐ Проверьте пропускную способность канала — софт может быть готов, а линия забита
Главное
HighLoad для «тяжёлого» Next.js — это не «купить сервер помощнее». Это вынести повторяющийся трафик на edge-кэш, изолировать узлы, кластеризовать приложение и подтвердить цифры стресс-тестом до того, как придут реальные 15 000 человек. В кейсе Judo Battle фронтенд и бэкенд в пике были в простое — работал прокси.
NineLab проектирует и внедряет такие контуры под ключ: архитектура, Varnish/Nginx, CI/CD, нагрузочные прогоны. Подробный разбор инфраструктуры — в кейсе Judo Battle. Нужен аудит перед пиком — закажите нагрузочное тестирование или опишите задачу инженеру.
Сервисы и материалы по теме
Вопросы о HighLoad для Next.js и SSR
Нет. Одновременные соединения — сколько клиентов держат открытый TCP/TLS-канал прямо сейчас. RPS — сколько HTTP-запросов в секунду. На одном соединении может идти несколько запросов (HTTP/2), поэтому цифры не взаимозаменяемы.
Вертикальное масштабирование помогает до порога, но SSR на каждый запрос съедает CPU. Edge-кэш снимает 80–95% трафика с приложения — это дешевле, чем линейно наращивать мощность фронтенда под каждый турнирный пик.
Для команды из 1–3 инженеров и фиксированного пула серверов PM2 + Nginx + Varnish проще эксплуатировать и дешевле в TCO. K8s окупается при частых релизах десятков сервисов и зрелой платформенной роли — не «потому что модно».
За 2–3 недели до маркетингового пика, рекламной кампании или трансляции финала. Прогон с превышением прогноза в 2–3 раза дешевле, чем один час простоя в момент максимальной конверсии.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Промышленный IoT: почему пилот с датчиками не доходит до production
Разбираем типичные ошибки промышленного IoT: от «умной розетки» до 1000+ датчиков. Считаем стоимость простоя оборудования, архитектура MQTT/edge/cloud и чеклист перед масштабированием.
Читать статьюМикросервисы для маркетплейса: когда это необходимость, а когда — лишние миллионы
Рамка решения для CEO и CTO: 5 сигналов, что пора дробить систему, 4 признака преждевременного перехода и честный расчёт — сколько стоит «архитектура как у Ozon» на старте маркетплейса.
Читать статьюRedis, очереди и кэширование: как сделать сайт в 10 раз быстрее без покупки нового железа
Разбираем, почему сайт тормозит при «нормальном» сервере, что кешировать в Redis, какие задачи уводить в очереди, когда подключать CDN — и какие цифры ждать после оптимизации без роста счёта за хостинг.
Читать статьюСколько стоит 1 час простоя вашего сайта: считаем на конкретных примерах
Формула расчёта стоимости простоя для e-commerce, B2B и SaaS: прямые и скрытые потери, коэффициент пика и чеклист подготовки к инцидентам. С привязкой к реальным сбоям инфраструктуры в 2026 году.
Читать статью