В эпицентре нагрузок: как команда Okko готовится к трансляциям на миллионы зрителей

Когда происходит большая спортивная трансляция, у технической команды есть примерно 15 минут, которые особенно важно пережить. Эти 15 минут решающие — ведь миллионы зрителей почти одновременно открывают приложение, авторизуются, проверяют подписку или покупают ее, находят матч и нажимают Play. На отдельных участках нагрузка в это время может вырасти в 10–20 раз, а иногда и в 50 раз по сравнению с обычной. Видео-сервису важно выдержать этот вызов и не расстроить никого из болельщиков.

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

В основе материала — выступление команды Okko на ИТ-Пикнике. В беседе участвовали:

• Иван Карев — технический директор, CTO Okko;

• Николай Животворев — директор департамента разработки продукта и продуктовой платформы;

• Евгений Курочкин — директор департамента обеспечения надежности и платформы разработки;

• Андрей Перекрест — директор департамента эксплуатации;

• Евгений Ильюшин — директор департамента управления данными и разработки систем AI;

• Георгий Евграфов — директор департамента архитектуры и прямых трансляций;

• Владимир Стогниенко — главный редактор Okko Спорт и спортивный комментатор.

Спорт в Okko развивается уже много лет. За это время масштабы серьезно выросли: команда, инвестиции, количество трансляций, их качество и сложность. Мы внутри команды оцениваем рост примерно в двадцатикратный.

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

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

Почему первые 15 минут самые сложные?

У спортивного эфира довольно специфический профиль нагрузки. Человек может заранее знать, что матч начинается в 22:00, но это вовсе не значит, что он откроет приложение за час и будет спокойно ждать. Большая часть зрителей вспоминает о трансляции уже перед самым стартом.

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

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

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

Именно поэтому показ большого спорта — это не просто задача плеера или CDN. Первый серьезный пик приходится на обычные продуктовые системы.

Продукт нужно вовремя упрощать

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

Если в течение года ни разу не задуматься о нагрузке и надежности, то потом наступают последствия. Шансов нормально показать крупное событие практически не остается. Поэтому в продукте есть механизмы, которые позволяют временно снимать часть нагрузки в пиковые периоды.

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

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

В приложении такие данные можно раздавать как заранее подготовленную статику, а в вебе — через простую HTML-страницу. Этот сценарий намного меньше зависит от динамической части сервиса и способен переживать очень большую нагрузку. Даже если у основного контура серьезные проблемы, человеку можно оставить базовый путь к контенту.

За самой идеей стоит много менее заметной работы. Статические данные нужно регулярно обновлять, режимы — корректно переключать, а после окончания пика все вернуть обратно. Важен сам принцип: деградация не всегда означает, что сервис перестал корректно работать и что-то сломалось. Иногда он на короткое время осознанно умеет меньше.

Снаружи пользователь видит обложки, карточки и кнопки. Но ведь под ними находится API, и практически любой заход в сервис означает десятки разных запросов.

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

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

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

На обычной нагрузке разница может быть почти незаметной. На спортивном пике стоимость одного запроса приходится умножать на огромную аудиторию.

Нагрузочный тест может показать идеальный результат… и это ничего не доказывает

Логичный способ проверить систему заранее — нагрузочное тестирование. Но мало просто создать большое количество виртуальных пользователей.

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

Проблема в том, что реальные люди ведут себя не так идентичного. У одного уже есть активная подписка, и он сразу открывает матч, другой уходит через главную, третий ищет событие, а четвертому нужно зарегистрироваться и оформить подписку, и так далее. Множество разных сценариев умножаем на сотню другую тысяч болельщиков и на число запросов к API. Цифры получатся катастрофическими.

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

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

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

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

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

Данные собираются автоматически. Часть результатов может разобрать автоматика, но не все — весомая часть требует оценки человека, поэтому утро у команды начинается в том числе с анализа таких отчетов. Это позволяет увидеть крупные проблемы и небольшие изменения, которые постепенно утяжеляют конкретные сценарии.

Для подготовки к Лиге чемпионов и Олимпиаде много работы было связано именно с построением правильного пользовательского профиля и тестовых данных. Само количество запросов еще ничего не гарантирует, если синтетика не похожа на реальную аудиторию.

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

Допустим, конкретный клуб сейчас играет неудачно и его матч не собирает особенно большую общую аудиторию. С точки зрения глобальной популярности событие можно поставить ниже. Но для человека, который болеет именно за эту команду, этот матч может быть главным событием дня.

Одновременно у сервиса есть собственные фильмы и сериалы, спортивные права и другой закупаемый контент. Во все эти направления инвестируются деньги, и у бизнеса, естественно, есть задачи по их продвижению.

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

После Play начинается другая нагрузка

Для спорта внутри команды используется метафора цунами. Огромная волна быстро накатывает, а затем так же быстро откатывается. После нее остаются ресурсы, которые специально выделяли под пик, и изрядное количество уничтоженных нервных клеток инженеров.

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

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

Особенно высокую нагрузку обычно дает футбол: четвертьфиналы, полуфиналы и финалы Лиги чемпионов, чемпионаты Европы и другие крупные матчи. Поэтому часть инфраструктурного плана формируется заранее, в том числе на основании календаря мероприятий и спортивных прогнозов на год.

У проблемы есть и обратная сторона. Допустим, мы правильно спрогнозировали большое событие и подготовили под него много ресурсов. Матч закончился, волна ушла. Теперь эти мощности нужно эффективно использовать дальше.

У нас гибридная инфраструктура: есть собственные площадки и облака. Это позволяет перераспределять ресурсы и балансировать между разными вариантами. Возможность такого маневра особенно полезна в ситуации, когда оборудование нельзя быстро купить и поставить. А спортивный бизнес порой ставит инфраструктуру именно в такую ситуацию.

До запуска трансляции основной удар получают продуктовые системы. После того как люди нажали Play, характер нагрузки меняется: теперь нескольким миллионам устройств нужно раздать само видео.

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

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

Балансировку мы тоже разработали своими силами внутри Okko. Система определяет, на какой кластер отправить конкретного пользователя, смотрит на состояние точек присутствия, ошибки, работу разных операторов связи и другие метрики.

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

При особенно большом потоке событий кластер обработки может начать отставать. Для таких сценариев в системе используется Kafka. Если часть событий не успели обработать в моменте, они могут остаться в очереди. После того как пиковая ситуация снята, цепочку можно дочитать и перестроить рекомендации уже с учетом накопленных данных.

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

Вызов: через три недели нужно показать Олимпиаду

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

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

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

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

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

Каждый сигнал нужно заранее принять и проверить, связать с нужной карточкой и дальше следить за ним. На одной трансляции нужен комментарий, на другой — титры, на третьей — и то и другое. Поэтому от нашей системы требуется работать сразу в двух режимах: показывать один большой матч огромному количеству людей и одновременно вести множество менее крупных трансляций. Георгий Евграфов сравнивает это с триатлоном: нужно уметь показывать много, качественно и при взрывной нагрузке. Показ Зимних Олимпийских игр 2026 года в Милане и Кортине-д’Ампеццо стал крупнейшим спортивным событием в истории Okko. За соревнованиями в прямом эфире следили более 8 миллионов пользователей.

Качество тоже может деградировать управляемо

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

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

Например, на части устройств можно временно убрать особенно тяжелый профиль качества. На небольшом мобильном экране зритель может почти не заметить разницу, а для общей емкости сети она ощутима. Когда нагрузка снижается, более высокий профиль возвращается. Иногда человеку вообще не нужно ничего делать: в приложении просто снова становится доступно более высокое качество. Такой подход в нашей практике позволял сэкономить порядка 10–20% сетевой емкости. С 4K есть и более простое ограничение: невозможно отдать зрителю 4K, если такой сигнал изначально не производится на стадионе и не приходит к нам.

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

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

Спортивный стриминг

Даже если идеально получить сигнал, пережить нагрузку и доставить видео на устройство пользователя, хороший спортивный продукт сам собой не появится. За другой частью процесса отвечает редакция. Когда Владимир Стогниенко возглавил спортивную редакцию в 2019 году, в штате было восемь человек и еще пять внештатных сотрудников. Сейчас речь идет примерно о 130 штатных и более чем 300 внештатных специалистах, а сама редакция разделена на 13 отделов. И около 60% контента приходится на футбол. Он же обычно вызывает самый большой ажиотаж и особенно хорошо показывает те самые пики перед стартом.

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

У онлайн-сервиса есть возможности, которых не было у классического спортивного телевидения. Если после матча есть что обсуждать, студию не обязательно заканчивать только потому, что через несколько минут по сетке должны начаться новости или реклама. Трансляцию можно продолжать столько, сколько это имеет смысл. Матч можно посмотреть в записи, что особенно полезно для событий в неудобном часовом поясе.

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

Стриминговый сервис не отменяет привычную модель телевидения, а позволяет существовать ей совместно с другими вариантами просмотра.

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

То же относится к звуку. Мы можем предлагать несколько комментаторских дорожек, в том числе пристрастный комментарий за разные команды, а также интершум стадиона без комментаторов.

С интершумом у редакции есть забавное наблюдение: в соцсетях его требуют очень активно, но фактическая доля пользователей такой дорожки может составлять около полутора процентов. Владимир сравнивает это с музыкой: люди могут рассказывать, что слушают что-то очень необычное, а затем «Руки Вверх!» собирают «Лужники».

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

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

Технически можно автоматически сообщить, кто получил мяч, какой счет или сколько времени осталось. Но живой комментарий состоит еще из реакции, интонации и общего контекста разговора со зрителем.

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

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

Это хорошо показывает границу, которая сейчас существует в редакционных процессах. Автоматизация снимает большую часть механической работы, но окончательное решение в ряде сценариев пока остается за редакторoм.

Инциденты оставляют шрамы

Многие механизмы надежности появились не из абстрактной архитектурной теории, а после реальных проблем. Таких шрамов на теле команды уже достаточно. У спортивного эфира высокая цена даже короткого сбоя. Фильм можно продолжить спустя несколько минут. В прямом матче за эти несколько минут может произойти главное событие вечера.

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

Это хорошо показывает, как проблему воспринимает пользователь. Болельщику не особенно важно, какой именно микросервис, дата-центр или участок доставки отвечает за сбой. Для него есть один Okko и один матч, который должен работать.

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

После прошлых инцидентов в структуре появились направления и люди, которые постоянно сфокусированы на надежности и внутренних инструментах. Но выделить отдельную команду и считать, что остальным теперь можно перестать об этом думать, не получится.

Вопрос о деградации возникает еще во время разработки. Что произойдет, если новая функция перестанет получать ответ от зависимости? Можно ли ее временно выключить? Что увидит человек? Как система восстановится после проблемы?

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

Пользователи все равно придут в последний момент

Мы не можем проектировать инфраструктуру под поведение, которое было бы удобно технической команде. Мы подстраиваем систему под то, как люди действительно смотрят спорт.

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

Работа кипит неделями и месяцами. Но все не зря. Ведь потом пользователь открывает Okko за минуту до матча, нажимает Play и наслаждается. И ничего из того, что происходило до этого внутри, он даже не замечает.