Трансляция концерта: падает не видео, а авторизация

MAATRIX

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

Не видео, а вход: где на самом деле рвётся трансляция

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

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

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

Что происходит за пять минут до начала концерта

Механика проста и предсказуема, если один раз её разложить по шагам.

Организаторы разослали напоминание за 15–30 минут до начала — почтой, в мессенджер, пуш-уведомлением. Люди читают его не сразу и не равномерно: основная масса открывает ссылку в узком окне за 3–7 минут до заявленного времени старта, а самый острый пик приходится на последнюю минуту — никто не хочет пропустить первые секунды выступления.

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

На практике всё разваливается в такой последовательности:

1. Растёт число одновременных HTTP-соединений к бэкенду — воркеры веб-сервера заканчиваются, новые запросы встают в очередь accept.
2. Каждая проверка оплаты — это, как правило, запрос к базе данных (билет привязан к заказу, заказ — к пользователю). При росте параллельных запросов упирается лимит подключений к базе (max_connections в PostgreSQL, например).
3. Если авторизация хранит сессии в общем хранилище (Redis, память процесса), это хранилище тоже получает всплеск операций записи-чтения ровно в ту же секунду.
4. Часть легитимных зрителей, которые просто нажимают «обновить» после ошибки, множит нагрузку — по сути превращая органический пик в самодельный DDoS от собственных же клиентов.

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

Где именно у авторизации не хватает мощности

Стоит разобрать четыре типичные точки отказа отдельно — почти всегда падает не всё сразу, а что-то одно, и после разбора инцидента полезно понимать, какое именно звено не выдержало в этот раз.

Пул соединений с базой данных. Каждый запрос на проверку доступа обычно открывает соединение к PostgreSQL или MySQL. Если сервис не использует пулер соединений, а полагается на пул самого фреймворка (например, дефолтный пул Django или Node.js-драйвера), число одновременных соединений быстро упирается в max_connections базы — а превышение лимита означает, что новые запросы получают ошибку подключения, а не медленный, но рабочий ответ.

Очередь на приём соединений у веб-сервера. У nginx и большинства бэкенд-серверов есть предел числа соединений, которые можно принять одновременно (worker_connections, backlog очереди accept). Когда входящих запросов больше, чем сервер успевает обработать, новые соединения не отбрасываются мгновенно — они встают в очередь и молча ждут, пока клиент не получит таймаут. Внешне это выглядит как «зависшая» страница загрузки, а не как явная ошибка — и именно поэтому дольше всего остаётся незамеченным. Механика такой очереди разобрана в статье про переполнение очереди accept и таймауты клиентов.

Хранилище сессий и токенов. Если проверка «залогинен ли зритель» идёт в общее хранилище (обычно Redis) на каждый запрос, а не читается из самого токена, всплеск логинов создаёт всплеск операций к этому хранилищу. При правильной конфигурации Redis выдерживает такую нагрузку без проблем — но если хранилище недооценено по памяти или соединениям, оно тоже может стать узким местом ровно в момент пика.

Rate limiting, настроенный против ваших же зрителей. Отдельная и обидная причина сбоя: защита от брутфорса или парсинга, настроенная разумно для обычного трафика (например, не больше N запросов в минуту с одного IP), при массовом легитимном входе начинает резать своих же зрителей — особенно тех, кто сидит за корпоративным NAT или мобильным оператором, где сотни человек выходят в интернет с одного и того же внешнего адреса. Как это работает и где чаще всего перегибают палку — в статье как работает rate limiting.

Архитектура авторизации, которая переживает пиковый вход

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

Разделите проверку личности и проверку права доступа. Если зритель уже был авторизован в системе (залогинен по cookie или токену с прошлой сессии), не нужно заново обращаться к базе на каждый чих — достаточно проверить подпись токена. Стоит использовать подписанные токены (JWT или аналог) с коротким сроком жизни для самого факта «эта личность подтверждена», и обращаться к базе только там, где без неё правда не обойтись — при подтверждении оплаты конкретного билета.

Кэшируйте статус оплаты, а не проверяйте его в базе на каждый запрос. Право доступа к конкретной трансляции для конкретного пользователя не меняется по десять раз в секунду — оно устанавливается один раз в момент покупки билета. Значит, его можно закэшировать в Redis с разумным TTL (например, на время самого мероприятия) сразу после оплаты и сверяться с кэшем, а не с базой, на пике входа. Это переносит нагрузку с диска на память, где порядки быстродействия совершенно другие.

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

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

Практические меры: очередь, кэш, лимиты

Три конкретных приёма, которые снимают основную часть риска без переписывания архитектуры с нуля.

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

Введите мягкую очередь на входе вместо жёсткого отказа. Вместо ошибки 502 или бесконечного спиннера при перегрузке лучше показать зрителю страницу «вы 143-й в очереди, вход через 20 секунд» с автообновлением через равные интервалы — это управляемо ограничивает поток запросов к бэкенду и не выглядит как поломка. Некоторые системы очередей на вход для мероприятий делают ровно это на уровне edge, ещё до того, как запрос доходит до вашего сервера.

Настройте лимиты отдельно для окна перед стартом. Пример конфигурации limit_req в nginx с более щедрым лимитом на burst, чем стандартный:

limit_req_zone $binary_remote_addr zone=auth_zone:20m rate=20r/s;

location /api/auth/verify-access {
    limit_req zone=auth_zone burst=60 nodelay;
    proxy_pass http://auth_backend;
}

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

Проверьте лимиты ОС и сервера заранее, а не в момент инцидента:

# текущий лимит открытых файловых дескрипторов
ulimit -n

# сколько соединений реально держит nginx сейчас
ss -s

# состояние очереди подключений к PostgreSQL
psql -c "SELECT count(*) FROM pg_stat_activity;"

Если ulimit -n стоит на дефолтных 1024, а вы ждёте несколько тысяч одновременных соединений на пике — это чинится за пять минут правкой /etc/security/limits.conf, но только если вспомнить об этом заранее, а не во время эфира.

Как готовиться заранее: нагрузочный тест и мониторинг в эфире

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

Нагрузочный тест стоит целиться именно в путь входа, с реалистичным профилем — не равномерный поток запросов, а резкий всплеск за короткое окно, имитирующий реальное поведение зрителей. Инструменты вроде k6 или wrk позволяют задать такой профиль:

# резкий всплеск: разгон до целевой нагрузки за 10 секунд,
# удержание пика 60 секунд — имитация "все зашли одновременно"
k6 run --stage 10s:2000,60s:2000,30s:0 auth-load-test.js

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

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

Частые вопросы