Базовые принципы работы Wowza Streaming Engine

2015-11-01 17:41:00

В данной статье мы рассмотрим базовые принципы применения Wowza Streaming Engine для построения медиа портала. Для того, чтобы не усложнять понимание, в рамках данной статьи мы не будем затрагивать вопросы биллинга и монетизации сервиса, а также глубоко разбирать техническую сторону.

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

У многих складывается впечатление, что продукт типа «Медиа сервер» должен обеспечивать и другие функции, либо предоставлять полный список средств создания портала. Но это не так, и за разные части единого решения отвечают свои компоненты, которые, однако, отлично интегрируются между собой. Итак, чего не предоставляет продукт Wowza Streaming Engine:

Интерфейс сайта для конечного пользователя.
Хранение описаний и метаданных медиа контента.
Сервер баз данных.
Передачу ссылок на просмотр контента напрямую конечному пользователю.
Интерфейс медиа плеера для воспроизведения материала и/или его сохранения на локальный диск.
Предоставление средств обеспечения монетизации и биллинга.

Медиа сервер Wowza Streaming Engine предназначен для выполнения следующих действий:

Прием IP-потоков в различных форматах (поддерживаются RTPM, RTP/RTSP, MPEG TS UDP Multicast/Unicast, Shoutcast/ICY, iOS устройства с помощью приложения GoCoder).
Доступ к VOD файлов (поддерживаются контейнеры mp4, mp3, flv, ism).
Осуществление транскодинга и трансрейтинга входящих IP-потоков с последующей генерацией потоков в различных битрейтах и разрешениях.
Осуществление операций перепакетирования и потоковой передачи Live и VOD контента на абонентские устройства.
Обеспечение защиты контента от несанкционированного просмотра (встроенными средствами Wowza или интеграцией со сторонними DRM/CAS системами).
Обеспечение резервированной отказоустойчивой системы раздачи медиа контента.

Рассмотрим подробнее, как происходит процесс обработки данных на сервере Wowza. Не будем рассматривать все возможные варианты, а остановимся на классическом UDP Multicast SPTS потоке с компрессией MPEG-2. Защиту от несанкционированного просмотра конечными пользователями также опустим (об этом см. статью «Шифрование данных Wowza»), а резервирование и балансировку нагрузки рассмотрим далее в рамках текущей статьи.

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

Итак, любой входящий Live поток, параметры которого соответствуют заявленным разработчиком (ранее в статье эти форматы перечислены), может быть преобразован с изменением протокола передачи, разрешения, битрейта, типа компрессии. В примере специально приведен именно MPEG2, чтобы показать, что все его параметры могут быть изменены. Также можно сгенерировать несколько дополнительных Live-потоков с более низкими параметрами качества. Это поможет передать контент по узким каналам связи (в том числе с переменной полосой пропускания), а также на различные типы клиентских устройств. При этом каждый поток будет упакован в нужный контейнер и передан согласно требуемому протоколу. Применение Wowza Streaming Engine позволяет:

Транскодинг любого потока производится только 1 раз, а не для каждого протокола передачи данных в отдельности.
Мастер-поток и сгенерированные потоки могут быть записаны и доступны пользователям в качестве VOD контента . Запись осуществляет в файлы MP4. При этом вычислительный ресурс использован тот же самый, что и для транскодинга потоков, без дублирования операций кодирования.
Вычисления могут производиться как с помощью процессорной мощности, так и на базе GPU, что позволяет распараллелить процесс обработки запросов и генерации Unicast потоков данных до абонентов и транскодинг/трансрейтинг контента.

Резервирование и распределение нагрузки.

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

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

Фактически это создание собственной сети доставки контента ( CDN ) с отказоустойчивым ядром. Само собой, сервис CDN можно просто арендовать у сторонних провайдеров и не заниматься проблемой доставки до конечного потребителя. Это вопрос, главным образом, финансовый. Возможные подходы к построению масштабируемого решения представлены на этой диаграмме.

Рассмотрим именно создание собственной инфраструктуры, чтобы понять, как могут работать несколько серверов Wowza в качестве единого решения.

Составной частью Wowza Streaming Engine является специальный модуль, Dynamic Load Balancing AddOn, который позволяет настроить правила распределения клиентских подключений между Edge серверами.

Рядовые Edge серверы периодически отправляют данные о загрузке и количестве подключений на Edge сервер с LoadBalancer модулем. Это позволяет иметь актуальные данные и мгновенно реагировать на поступающие запросы, распределяя нагрузку там образом, чтобы ни одно звено не оказалось перегруженным. После чего, в зависимости от загруженности и других параметров, он может быть перенаправлен на один из Edge Server-ов или обработан самим сервером. Данный сервис поддерживается как для Live, так и для VoD контента и доступен для всех поддерживаемых Wowza потоковых протоколов кроме MPEG DASH ( на момент написания статьи ).

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

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

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