Прошедший Чемпионат мира по футболу FIFA 2018 в России принёс большие нагрузки не только на транспортные узлы страны, но и на ИТ-инфраструктуру крупнейшего российского телевещателя, которая сделала матчи доступными в формате онлайн-трансляций. Мы с интересом взялись за новый вызов, пришедший на обслуживаемые серверы вместе с футбольной лихорадкой.

Предисловие: высокие нагрузки?

Разговоры про highload зачастую начинаются с размышлений на тему, какие нагрузки можно по праву считать «высокими»: тысячи запросов в секунду на динамику? Или даже небольшое количество запросов в отношении к имеющимся ресурсам? Миллионы посетителей в сутки? Сотни загруженных работой узлов в кластере?..

Для получения представления о «масштабах бедствия» должно быть достаточно того факта, что речь идёт об одновременно просматривающих трансляцию пользователях, количество которых достигало отметки в 2 миллиона. Что же происходило, если посмотреть на трансляции матчей «изнутри», и как удалось справиться с небывалым трафиком?

Три кита

1. Архитектура сайта и системы трансляций

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

• Пользователь приходит на сайт, где запускается плеер для просмотра видео. Сам плеер написан на JavaScript и его загрузка приводит к множеству запросов к статике, а также различным API, связанным с трансляциями.
• Помимо прочего, происходит обращение к балансировщику за плейлистом для воспроизведения.
• Плейлист — это постоянно обновляемый набор из коротких фрагментов видео, которые кэшируются на CDN-серверах.
• Во время просмотра видео с пользователя в реальном времени собирается разнообразная статистика, которая, в частности, учитывается для распределения нагрузки по CDN (вместе с собственно доступной полосой пропускания).

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

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



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

2. CDN

Возвращаясь же собственно к просмотру видео, очевидно, что основная нагрузка приходится на CDN-серверы. В цифрах для минувшего ЧМ по футболу речь идёт о постоянном трафике, который измеряется терабитами в секунду. И во многом успех работы трансляций с пиковыми нагрузками обусловлен кэшированием на CDN всего, что может быть на них вынесено, и минимизацией ресурсных (сетевых, CPU, RAM, …) затрат на остальные операции.

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

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

1. По какой-то причине происходит лаг в трансляции.
   
   Например, настройки системы так «сыграли» на одном из матчей чемпионата, что сервис DDoS-защиты, не ожидавший внезапной нагрузки, начал расценивать происходящее как атаку, блокируя доступность CDN-серверов один за другим… пока его не уведомили о том, что ситуация в некотором смысле экстремальная, но всё-таки штатная (необходимые выводы были сделаны — в следующих трансляциях ситуация не повторялась).
   
   В такие моменты все пользователи, которых настигла массовая проблема, начинают обновлять страницу с плеером.
2. Забитый гол (особенно первый), как правило, провоцирует огромный приток зрителей в ограниченный промежуток времени.
   
   Если говорить о более конкретных числах, то такой приток составлял сотни тысяч пользователей за 1—1,5 минуты.

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

3. Мониторинг и статистика реального времени

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

Что за «иные обстоятельства»? На таких массовых мероприятиях заметно даже влияние погоды. Вот два примера с чемпионата, с которыми мы столкнулись:

1. Когда во время одного из матчей началась гроза, у провайдеров спутникового телевидения случились проблемы с оборудованием (не получалось отправить сигнал). Это привело к заметному всплеску трафика (примерно на 10 %) за короткое время, потому что в поисках срочного альтернативного решения зрители начали массово заходить в интернет и продолжать просмотр уже там.
2. Когда во время финального матча начался дождь, был заметен небольшой (около 3 %) скачок отключения и повторного (примерно через 5 минут) подключения пользователей. Никаких проблем в самой трансляции при этом не наблюдалось, то есть причины для скачка не имели технической основы. Предположение в том, что зрители, смотревшие футбол на улице (как это делал и я сам), из-за дождя переходили в помещение, а на это непродолжительное время отключались от трансляции.

Возвращаясь же к теме собственно мониторинга — на время всего чемпионата была принята за норму практика регулярных (после каждой пиковой трансляции) встреч вместе с разработчиками, на которых анализировались все критичные ситуации (или близкие к таковым) и их последствия — с целью минимизировать потенциальные проблемы в следующий раз. Какие серверы/сервисы были на пределе? Какие запросы оказались особенно требовательными? Какие запросы можно убрать (перенести на CDN, чтобы закэшировать на несколько секунд)? Какие запросы можно кэшировать дольше (раз в 3 минуты, а не в минуту)? Что произойдёт при прогнозируемом росте числа зрителей, потому что играть будет Россия?..

Кстати о России. Как легко догадаться, на матчи с участием сборной России в среднем приходило в несколько раз больше людей, чем на другие. И чем дальше наша сборная продвигалась по турнирной сетке, тем сложнее было совмещать свою радость по этому поводу с исполнением непосредственных обязанностей ­— ведь всё усложнялось неустанным ростом аудитории. Несмотря на то, что система была спроектирована так, чтобы выдерживать огромные нагрузки, в нормальном рабочем графике они случаются не так часто (менее 10 раз в год)… а в случае чемпионата мира по футболу мы наблюдали практически ежедневные highload-пики на протяжении месяца. Плюсом такого режима, впрочем, были широкие возможности по обнаружению актуальных узких мест, которые выявляются только в моменты подобных нагрузок.

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

Статистика реального времени

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

• собирает всевозможные доступные данные о пользователях (браузер, IP и т.п. ­— для простоты можно сказать, что это те характеристики, которые мы привыкли смотреть в статистике по аудитории сайта);
• дополняет их техническими данными о трансляции (битрейт и др.) и случившихся событиях/проблемах (переключения CDN, сбои при просмотре…);
• предоставляет балансировщику данные для оптимального распределения нагрузки по CDN-серверам (в соответствии с характеристиками каждого пользователя);
• отправляет необходимые алерты дежурным инженерам и создаёт полезные для бизнеса графики.

Последний пункт ­— самый интересный, потому что:

1. Алерты этой системы статистики — ключевая составляющая мониторинга, позволяющая «держать руку на пульсе» практических показателей во время трансляций. Анализируя их (в том, где не хватает автоматизации), дежурный принимает соответствующие решения для улучшения качества сервиса в режиме реального времени. Например:
   
   • У многих пользователей произошло переключение с одного и того же CDN-сервера? Надо его временно отключить из ротации (или связаться с провайдером для оперативной реакции).
   • Пользователи начали массово испытывать проблемы при просмотре видео? Время срочного анализа причин.
2. Графики — это генерируемая в режиме реального времени бизнес-статистика, позволяющая ответить на главные вопросы, такие как:
   
   • Сколько пользователей смотрели трансляцию последнюю минуту?
   • У какого процента пользователей были проблемы за последнюю минуту и какого они были характера?
   
   Поскольку у подобных событий наблюдается одинаковый профиль графиков, то сам график позволяет прогнозировать рост количества пользователей на ближайшие несколько минут и принимать проактивные действия при необходимости.

Поскольку эта статистика работает в реальном времени и является критичной для качественной работы всего сервиса, даже простой по своей природе просмотр видео миллионами пользователей не сводится к раздаче им контента через CDN. Добиться быстрой записи новых данных от многочисленных плееров (речь идёт о десятках тысяч запросов в секунду на запись на каждый сервер) помогает СУБД ClickHouse, а для графиков используется привычная Grafana.


Иллюстрация соотношения количества зрителей онлайн-видео до, во время и после матча

Кстати: Интересным workaround'ом на время пиковых нагрузок стало отключение HTTPS (в пользу HTTP) для запросов от системы статистики, что приводило к двукратному снижению нагрузки на CPU на некоторых из серверов.

Итоги

Успех онлайн-трансляций такого масштабного события (а с нагрузками не всегда справлялся даже YouTube TV!) был обеспечен тремя ключевыми факторами:

1. грамотной архитектурой (для системы трансляций и сайта), которая даже без использования современных систем вроде Kubernetes была изначально ориентирована на высокие нагрузки, масштабируемость и готовность к значительным всплескам;
2. CDN-серверами с достаточной пропускной способностью;
3. специализированному мониторингу, позволявшему: а) отслеживать проблемы в реальном времени, б) предоставлять необходимые сведения для того, чтобы избегать их в дальнейшем.

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

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