В Netflix множество грандиозных идей начинается с вопросов. Три года назад мы задали, возможно, самый смелый из них: если бы мы собрались развлекать весь мир с помощью прямых эфиров (этот формат ещё называют «Live», он почти такой же древний, как само телевидение) — как бы мы это сделали?
В начале всё выглядело как чисто техническая задача — подготовка к выпуску нашего первого комедийного шоу, идущего в прямом эфире — Chris Rock: Selective Outrage. А через некоторое время наши прямые эфиры исчислялись уже сотнями. Чего только среди них не было — от крупнейших комедийных представлений и рождественских матчей NFL, до боксёрских поединков, собравших рекордную аудиторию. Netflix даже стала эксклюзивной платформой для трансляции событий WWE.
Этот материал посвящён рассказу о той базе, которую мы создали для поддержки прямых трансляций, и о тех важных решениях, которые повлияли на то, как мы реализовали этот проект.
Особенности прямых эфиров
Хотя прямые эфиры — явление далеко не новое, стриминговый функционал, который мы намеревались создать, требовал инфраструктуры, которой мы в то время не располагали. К тому моменту мы уже обладали 15-летним опытом работы с потоковым видео, которое пользователи могли смотреть тогда, когда захотят. Но прямые трансляции предъявляли к платформе новые требования. Они повлияли на принятые нами архитектурные и технологические решения.
Показатель | Видео по запросу | Прямой эфир |
Время от видеосъёмки до просмотра пользователем | От дней до месяцев | Секунды |
Модели просмотра контента | Циклический рост пиков и спадов трафика; возможна проактивная оптимизация ресурсов | Неравномерный трафик; требуется реактивное масштабирование ресурсов |
Пользовательский опыт | Просмотр возможен в любое время | Просмотр в соответствии с расписанием трансляций |
Буфер воспроизведения контента | Минуты | Секунды |
Режим обслуживания системы | Определённый уровень устойчивости к кратковременным сбоям. | Проблемы, возникающие в ходе прямой трансляции, могут вызвать разрушительные последствия. Они требуют максимально быстрого разрешения. |
Прямые эфиры сильно отличаются от обычной потоковой передачи видео. А значит — нам нужно было проделать огромную работу для того чтобы они достойно работали бы на платформе Netflix. Эта работа началась с принятия решений о том, на чём будет основана архитектура нашей системы прямых трансляций.
Ключевые компоненты архитектуры, обеспечивающей проведение прямых эфиров
Наша система проведения прямых эфиров должна была следовать тому же подходу в работе с пользователями, который применяется при передаче видео по запросу: высокое качество материалов, воспроизводимых на максимально возможном числе устройств без прерываний. Прямые трансляции — это лишь один из многих форматов развлекательного контента Netflix. Поэтому нам, кроме прочего, нужно было сделать так, чтобы взаимодействие с таким контентом естественным образом встроилось бы в тот опыт, который получают наши пользователи. И это — учитывая то, что у нас имеется более 300 миллионов глобальных подписчиков.
Когда мы начали работу, в нашем распоряжении было девять месяцев до первого запуска системы. Нам, с одной стороны, нужно было действовать быстро. А с другой, мы стремились к тому, чтобы учитывать будущий рост системы, как в плане масштаба, так и в плане количества Live-событий. Уникальность нашей ситуации в том, что мы сами занимаемся поддержкой нашего единственного продукта — Netflix. Мы контролируем полный жизненный цикл контента — от стадии его производства, до стадии попадания на экраны зрителей. Всем этим мы в полной мере воспользовались, работая над системами, обеспечивающими ведение прямых трансляций.
Выделенные коммуникационные центры для приёма материалов прямых трансляций со съёмочных площадок
События, прямые трансляции которых мы ведём, могут происходить в любом месте планеты, но не везде имеется подходящее оборудование или хорошее соединение с интернетом. Для того чтобы обеспечить безопасную и надёжную передачу материалов прямых трансляций, мы используем распределённые и хорошо связанные друг с другом коммуникационные центры. В них имеется специализированное оборудование для приёма и проверки материалов, для работы с субтитрами, для управления графикой и рекламой. Наш приоритет — воспроизводимость процессов. Мы выстраиваем всё так, чтобы единообразно, надёжно и экономически эффективно обслуживать события, откуда ведутся прямые трансляции. Мы максимально опираемся на автоматизацию. В результате у нас получилось свести подготовку вещания некоего события к налаживанию передачи данных между местом съёмок и коммуникационным центром. Другие ресурсы, используемые различными событиями, являются для них общими.
Облачные отказоустойчивые конвейеры для перекодирования и упаковки материалов
Материалы, получаемые коммуникационными центрами, представляют собой полностью готовую программу. Но их ещё нужно закодировать и подготовить к стримингу на устройства пользователей. Тут мы используем облачный подход, позволяющий проводить динамическое масштабирование системы, гибкость её конфигурирования и простоту интеграции с другими нашими службами, уже развёрнутыми в облаке. Среди них — служба DRM (Digital Rights Management, управление цифровыми правами), служба управления контентом, служба доставки контента. Мы используем AWS Elemental MediaConnect и AWS Elemental MediaLive для приёма потоковых данных в облаке и их перекодирования в видеоформаты с различными уровнями качества, с битрейтом, настраиваемым для каждого мероприятия. Мы, чтобы лучше интегрировать новый функционал с нашими системами доставки и воспроизведения контента, создали собственный упаковщик материалов. Мы, кроме того, создали собственную систему, являющуюся источником готовых материалов (Live Origin), позволяющую обеспечить жёсткие SLA для чтения и записи сегментов прямых трансляций.
Масштабирование доставки материалов прямых эфиров миллионам пользователей с помощью CDN Open Connect
Для того чтобы организовать стриминг отснятых видеоматериалов, их нужно передать из нескольких хранилищ AWS, где развёрнута система Live Origin, на сотни миллионов устройств, разбросанных по всему миру. Для того чтобы масштабировать доставку материалов прямых трансляций мы используем Open Connect — это CDN компании Netflix. Серверы Open Connect расположены достаточно близко к людям, которые смотрят трансляции. Эти серверы размещены на более чем 6000 площадок, они связаны с хранилищами AWS посредством выделенной сети Open Connect Backbone.
Организовав передачу материалов прямых трансляций через Open Connect, мы воспользовались уже готовой инфраструктурой Netflix стоимостью более 1 миллиарда долларов. На её создание ушло около 12 лет, вложения в неё ориентированы на масштабирование сети и на оптимизацию производительности серверов, ответственных за доставку контента зрителям. Организовав совместное использование возможностей этой системы обычными стриминговыми материалами и материалами прямых трансляций, мы повысили уровень её использования. Кроме того, кешируя свежие материалы прямых трансляций на тех же серверах, что используются для обычного стриминга, мы без труда даём пользователям возможность смотреть то, что уже было показано в прямом эфире.
Оптимизация воспроизведения прямых эфиров: совместимость с устройствами, масштабирование, качество и стабильность
Для того чтобы прямые эфиры смогло бы смотреть большинство наших пользователей, не обновляя при этом свои устройства, мы остановились на стриминге прямых трансляций, основанном на HTTPS. Протоколы, основанные на UDP, могут дать дополнительные возможности, вроде сверхнизких задержек. А протокол HTTPS, во-первых, поддерживает множество устройств, а во-вторых — совместим с системами доставки и кодирования материалов. Более того — мы используем видеокодеки AVC и HEVC, преобразуем одни и те же записи в несколько форматов — от SD до 4K, используем сегменты длиной 2 секунды чтобы сбалансировать эффективность сжатия данных, нагрузку на инфраструктуру и задержки. Главное для нас — качество стриминга и стабильность воспроизведения материалов, но мы, кроме того, смогли добиться одних из самых низких в отрасли задержек сигнала на пути от камеры до устройство просмотра. Этот показатель наших систем мы продолжаем улучшать.
Для настройки проигрывания материалов устройство получает в начале воспроизведения контента так называемый «playback manifest» (манифест воспроизведения). Манифест содержит такие сведения, как битрейты кодирования материалов и адреса CDN-серверов, которые должен использовать проигрыватель. Мы отправляем файлы-манифесты не с CDN, а из облачного хранилища, так как это позволяет нам персонализировать настройки для каждого конкретного устройства. Для работы с сегментами видеопотока в манифест включён шаблон сегмента, который используется устройством для сопоставления реального календарного времени с URL-ссылками на CDN. Использование шаблона сегментов отличается определёнными преимуществами в сравнении с периодическим опросом сервера на предмет обновлений файла-манифеста. В частности, это минимизирует сетевые задержки, нагрузку на CDN-сервер и дополнительную нагрузку на устройства с ограниченными ресурсами, вроде умных телевизоров. В результате такой подход улучшает масштабируемость и стабильность нашей системы. В ходе обработки стриминговых данных проигрыватель наблюдает за эффективностью работы сети и динамически подбирает битрейт и CDN-сервер. Это позволяет максимизировать качество видеопотока и сводит к минимуму остановки видео для дозагрузки данных.
Облачные технологии и организация работы служб, ответственных за нахождение трансляций и за управление их воспроизведением
До сих пор мы обсуждали путь, который стримы проходят от камеры до устройств пользователей. Для того чтобы система стриминга оказалась бы полностью рабочей, нам ещё нужно согласовать работу всех систем и сделать так, чтобы зрители смогли бы находить прямые трансляции и запускать их просмотр. За этот функционал отвечают дюжины облачных служб. Они реализуют такие возможности, как настройка воспроизведения контента, персонализация, сбор различных метрик. Обычно случается так, что на подобные службы ложится непропорционально большая нагрузка во время начала прямых эфиров. То, что они развёрнуты в облаке, даёт гибкость в деле динамического масштабирования вычислительных ресурсов. Более того, так как прямые трансляции обычно вызывают особый интерес лишь в определённых регионах мира, мы можем балансировать нагрузку между множеством регионов AWS, более эффективно используя нашу глобальную инфраструктуру. Развёртывание служб в облаке, кроме того, позволяет нам встраивать контент прямых трансляций в более широкий набор материалов, вроде обычных видеоматериалов и игр, что расширяет пользовательский опыт зрителей.
Централизация систем обработки метрик реального времени в облаке
Под нашим контролем находятся процессы получение материалов прямых трансляций, конвейеры их кодирования, CDN Open Connect, проигрыватели, работающие на устройствах пользователей. Всё это позволяет нам «наблюдать» практически за всем происходящим. В ходе прямого эфира мы в реальном времени собираем метрики, относящиеся к системе и к пользователям (например — это сведения о том, где именно пользователи видят описание соответствующего материала на Netflix, и о том, каково их субъективное восприятие качества работы сервиса). Анализ подобных метрик даёт нам сигналы относительно плохого пользовательского опыта или относительно снижения производительности наших систем. Система мониторинга, работающая в режиме реального времени, использует набор инструментов нашей разработки. Среди них — Atlas, Mantis и Lumen. Мы применяем и опенсорсные технологии, вроде Kafka и Druid. В ходе некоторых прямых эфиров, отличающихся особым размахом, нам приходится обрабатывать до 38 миллионов событий в секунду, формируя за считанные секунды критически важные метрики и оперативные отчёты о работе системы. Более того, мы развернули специальные инструменты, называемые «Центрами управления», которые собирают вместе ключевые метрики и дают к ним доступ дежурной команде, которая, в реальном времени, мониторит то, что связано с прямыми эфирами.
Основные выводы о проделанной работе, сделанные на данный момент
Разработка нового функционала — это всегда невиданные ранее задачи, а так же — возможность научиться чему-то новому. Особенно — если речь идёт о чём-то столь же сложном, как система прямых трансляций. Даже спустя три года после её запуска мы каждый день узнаём что-то новое о том, как эффективнее делать прямые эфиры. Вот — некоторые вещи, на которые, как мы убедились за это время, нужно обратить особое внимание.
Всестороннее тестирование
До начала проведения прямых трансляций мы сильно полагались на предсказуемые потоки трафика, вызываемого материалами, воспроизводимыми по запросу пользователей. Мы использовали эти потоки для тестирования предрелизных («канареечных») версий продуктов и в A/B-тестировании. Но трафик прямых трансляций доступен далеко не всегда, особенно — в тех масштабах, который характерен для больших событий, привлекающих множество зрителей. В результате мы затратили немалые силы на решение следующих задач:
Генерирование внутренних «тестовых стримов», которые используются для выполнения интеграционных, регрессионных или «дымовых» тестов, являющихся частью жизненного цикла разработки продуктов.
Создание механизмов, позволяющих проводить синтетические нагрузочные тесты, предназначенные для стресс-тестирования облачных систем и CDN. Тут мы используем два подхода, что позволяет нам генерировать до 100 тысяч событий запуска просмотра контента в секунду:
Захват, модификация и повторное воспроизведение трафика уже прошедших прямых трансляций. Это позволяет отразить разнообразие пользовательских устройств и паттернов выполнения запросов.
Виртуализация устройств Netflix и генерирования трафика, проходящего через CDN или через облачные системы. Этот подход позволяет протестировать влияние свежих изменений на всю систему.
Выполнение автоматизированных тестов, основанных на создании искусственных сбоев и на проверке того, как они отразятся на системе. Искусственные сбои могут быть представлены следующими явлениями: отсутствующие или повреждённые сегменты видеопотока, получаемые из конвейера кодирования, потери регионов облачной службы, сетевые сбои, тайм-ауты серверов.
Регулярные исследования продакшн-среды и подготовка персонала
Несмотря на то, что наши продукты проходят серьёзное предрелизное тестирование, ничто не способно так же хорошо их испытать, как применение в продакшне. Особенно — когда они работают в рамках крупной платформы. Мы поняли, что регулярное проведение прямых эфиров — это важно, чтобы, с одной стороны, улучшать наши системы, и с другой — чтобы не подвергать ненужному риску пользователей. Исследуя продакшн-среду, мы проводим A/B-тестирование, хаос-тестирование, отрабатываем эксплуатационные процедуры, перед мероприятиями устраиваем тренинги для команд, отвечающих за поддержку продакшн-систем.
Прогнозирование параметров зрительской аудитории
Мы, основываясь на прогнозах аудитории, выполняем предварительное резервирование ёмкости облачных служб и CDN, а так же — заранее делимся прогнозами с интернет-провайдерами и операторами облачных служб, что позволяет им спланировать загрузку сетевых и вычислительных ресурсов. Мы дополняем эти планы реактивным масштабированием облачных служб, отвечающих за регистрацию пользователей и их вход в систему, за поиск и воспроизведение материалов. Делается это на тот случай, если фактическая аудитория превысит прогнозируемую. Нам удалось добиться хороших результатов, применяя опережающее прогнозирование аудитории, выполняемое в режиме реального времени — прямо во время проведения прямых трансляций. Это позволяет нам заблаговременно принимать меры, позволяющие заранее снизить риски, способные негативно повлиять на пользователей.
Мягкая деградация
Несмотря на все усилия, мы можем оказаться (и уже оказывались!) в ситуации, когда масштаб аудитории превышает и прогнозы, и выделенную ёмкость наших систем. Готовясь к подобному, мы разработали набор инструментов, который позволяет продолжать стриминг даже в том случае, если это означает постепенное отключение каких-то необязательных, хотя и полезных функций. Например, мы используем механизм сброса нагрузки на уровне служб, позволяющий дать приоритет трафику прямых эфиров в ущерб менее важному трафику (вроде того, что создаёт предварительная загрузка материалов). Помимо этого мы можем «обеднить» опыт взаимодействия пользователя и платформы — уменьшить уровень персонализации, отключить закладки, снизить максимальное качество видеопотока. В наши нагрузочные тесты входят сценарии, в которых мы даём системам недостаточный объём ресурсов и проверяем, ведут ли они себя так, как ожидается.
Лавины повторных запросов
В случаях, когда системы нагружаются до предела, наша главная задача заключается в том, чтобы избежать каскадных отказов, или дальнейшей перегрузки систем из-за повторных запросов. Помимо повторных запросов, выполняемых компонентами системы, такие запросы могут исходить и от самих пользователей. Мы видели десятикратный рост трафика из-за перезапуска стримов после прерываний просмотров материалов длительностью всего в 30 секунд. Мы потратили значительное время на то, чтобы понять особенности поведения устройств в плане выполнения повторных запросов при появлении каких-либо проблем. Проблемы возникают, например, при срабатывании сетевых тайм-аутов или из-за отсутствующих сегментов видеопотока. В результате мы реализовали особые стратегии, вроде управляемой сервером задержки перед повторным запросом. Это позволяет нашим системам поглощать всплески нагрузки посредством приоритизированного сброса трафика в системе Cloud Edge Gateway и с помощью перераспределения трафика между облачными регионами.
Планирование в расчёте на возникновение непредвиденных обстоятельств
Фраза Майка Тайсона «У каждого есть план, пока ему не дадут по морде» очень хорошо подходит для нашей системы прямых трансляций. Когда что-то ломается, у нас почти нет времени на поиск и устранение неполадок. При проведении крупных мероприятий мы создаём центры управления, в которых лично присутствуют инженеры, ответственные за функционирование тех или иных критически важных подсистем. Для того чтобы быстро обнаруживать и исправлять проблемы, мы разработали небольшой набор метрик, которые играют роль ранних индикаторов сбоев. Так же мы подготовили подробные инструкции по реагированию на типовые инциденты. Мы не занимаемся обучением сотрудников в дни запуска мероприятий. Вместо этого команды, ответственные за прямые трансляции, заблаговременно учатся реагировать на отказы в рамках тренингов Game Day. И наконец, содержание наших инструкций по реагированию на типовые инциденты выходит далеко за пределы чисто технических вопросов. В них имеются указания, касающиеся донесения проблемы до исполнительного руководства компании, а так же — сведения о координации между различными подразделениями компании, в частности, ответственными за поддержку клиентов, за связи с общественностью, за обеспечение работоспособности продакшн-версий наших продуктов.
Наше стремление к тому, чтобы платформа Netflix вызывала бы у пользователей положительные эмоции, не ограничивается надписью «Спасибо за просмотр!». Вскоре после завершения каждой из прямых трансляций мы, в поисках того, что можно улучшить, углубляемся в собранную аналитику. Команда, ответственная за анализ и оценку данных, тщательно рассматривает материалы, выполняет A/B-тестирование, проводит исследования потребительских настроений. Всё это делается для того, чтобы нашим зрителям было бы ещё приятнее смотреть следующий прямой эфир. Мы используем аналитические данные о поведении пользователей, об их предпочтениях и ожиданиях для улучшения платформы Netflix и для оптимизации системы прямых трансляций. Одним из примеров таких улучшений, достигнутых благодаря A/B-тестированию, является уменьшение задержки примерно на 10 секунд без ухудшения качества или стабильности системы.
Что дальше?
Несмотря на то, что мы занимаемся этим проектом уже три года, он ещё очень далёк от завершения! На самом деле, всё только начинается. Мы активно используем полученные знания, которыми поделились выше, стремясь доставлять нашим зрителям ещё больше удовольствия от прямых трансляций. Мы стремимся обеспечить поддержку растущего количества Live-событий, а так же — поддержку новых форматов трансляций, вроде FIFA WWC в 2027 году. Для этого мы продолжаем развивать инфраструктуру и постоянно работаем над тем, чтобы пользователям было бы приятнее смотреть наши прямые трансляции.
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.
