В предыдущей заметке я рассказал начало истории создания нашего первого продукта - WMSPanel, панели управления медиа-серверами Wowza. Рассказ остановился на осени 2012 года, когда мы получили статус Wowza Product Partner.
Функциональность росла, как на дрожжах. К началу 2013 года панель уже умела через установленного агента не только снимать статистику, но и защищать потоки от hotlinking-а, а так же управлять настройками сервера. Поскольку панель давала централизованный доступ ко всем серверам, то работа "больших парней" с большим числом серверов сильно упрощалась. Например, чтобы создать новое приложение с потоками для нового клиента на 20 серверах, нашему пользователю достаточно определить через конфигурацию приложения один раз и отметить галочками, на каких серверах потоки этого клиента будут обслуживаться.
В общем, клиентов на пробный период прибывало всё больше, многие после двух пробных недель оставались и подписывались. Устойчивая обратная связь давала пищу для планов на будущие фичи и даже позволяла грамотно расставлять приоритеты - чем больше что-то просят, тем выше стоит задача.
Однако стал заметен и другой процесс. Многие начали интересоваться поддержкой других продуктов, где есть работа с progressive download, также известный как псевдо-стриминг. К сожалению, при всей универсальности Wowza, она с этим протоколом не работает. Поэтому нас начали спрашивать - а не планируем ли мы поддержать эти продукты, также, как мы сделали поддержку Wowza и Windows Media? Самый популярный продукт из этой ниши - Nginx, у него есть соответствующие модули - как для MP4, так и для FLV. Также массово спрашивали и про работу с ShoutCast / IceCast - это протоколы вещания онлайн-радио, до сих пор весьма популярные во многих странах.
Со стороны расчёта статистики - многим нравится наш облачный подход, когда не надо ставить себе на сервер "ещё одну парсилку логов", а можно просто заплатить мелкую денежку и смотреть отличные графики через удобный интерфейс. Да и защита от ре-стриминга многим понравилась, не на всех платформах она есть, прямо скажем.
Вот тут мы встали на распутье. Вроде очевидно, что можно воспользоваться нашим же принципом встраивания агента и просто написать свой модуль для nginx. Он бы перехватывал всё что нужно, отдавал статистику и тем самым восполнял пробел в возможностях.
Мы к вопросу подошли более системно и обдумали, что же нужно будет типичному клиенту на самом деле. "Им ведь не nginx нужен" - подумали мы. А что же было нужно типичному клиенту, уходящего в сторону дешевого решения?
В общем, взвесив все "за" и "против", было решено сделать свой стриминг-сервер, заточенный только под передачу медиаданных. В качестве целевой платформы рассматривался Linux, как доступный на подавляющем большинстве серверов, стоящих на вооружении в медиа-индустрии. Требования, перечисленные выше, не поменялись. Сервер должен быть простым в установке, быстрым и не требующим большого количества ресурсов.
Для начала реализации выбрали несколько сценариев, которые хотелось бы покрыть в первую очередь.
Итак, было принято решение "писать своё". Именно этим и занялись. В январе 2013 была начата работа, а уже в апреле был выложен первый релиз, умевший не только очень хорошо работать с большим числом входящих соединений, но и производить полезную работу - ре-стримить HLS и раздавать контент через псевдостриминг. Надо ли говорить, что с первого дня этот сервер умел выдавать статистику для WMSPanel с последующим её показом в контрольной панели? Там же, в панели, можно было задавать основные настройки работы. Первая версия ставилась только на Ubuntu в силу её популярности и удобства пакетной установки. Именно так сразу и была сделана установка - пара команд в консоли для менеджера пакетов, запуск сервиса - и всё, он уже ждёт поступающих запросов. Итого, меньше 4 месяцев - и у нас есть базис для дальнейшей работы.
После определённых раздумий было принято название Nimble Streamer. Nimble - значит шустрый, юркий, быстрый. Тот, кто решает вопросы быстро, но без лишней суеты - в общем, "сращивает", как говорят у нас во Владивостоке.
Так что "шустрый стример" начать жить и активно двигаться вперёд. К настоящему моменту панель даёт всю статистику, доступную для Wowza Media Server. Сам Нимбл предоставляет защиту от ре-стриминга и фреймворк для построения систем pay-per-view - аналогичная функциональность уже была создана для Wowza, мы реализовали её на новой платформе, заодно несколько улучшив.
Наиболее популярны сценарии, связанные с HLS.
В первую очередь, это создание своих сетей доставки контента, где Wowza выступает в качестве центра подготовки стримов, а Nimble ставится между этим центром и конечными пользователями для равномерного распределения нагрузки и увеличения отказоустойчивости. Этот сценарий популярен среди компаний, занимабщихся живыми трансляциями. В этом случае и управление Вовзой, и снятие статистики с Нимбл-серверов производится в одной и той же панели.
Второй популярный сценарий - раздача VOD-контента из файлов MP4 в поток HLS. Это разнообразные "ютюбоподобные" сервисы, которые зарабатывают на подписке для доступа к контенту.
Также появились ряд "побочных" юзкейсов, которые немедленно или были реализованы, или поставлены в очередь задач.
Аппетиты клиентов, конечно же, не уменьшаются - новые идеи приходят регулярно. Ну и хорошо. Хуже всего в работе над новым продуктом - отсутствие обратной связи. Если её нет - что-то явно идёт не так. Ну а раз она есть и не ослабевает - мы на правильном пути.
Кроме того, открылась возможность использовать Нимбл с совершенно другого ракурса - для проверки целостности потоковой передачи данных.
Но об этом в следующей заметке.
Функциональность росла, как на дрожжах. К началу 2013 года панель уже умела через установленного агента не только снимать статистику, но и защищать потоки от hotlinking-а, а так же управлять настройками сервера. Поскольку панель давала централизованный доступ ко всем серверам, то работа "больших парней" с большим числом серверов сильно упрощалась. Например, чтобы создать новое приложение с потоками для нового клиента на 20 серверах, нашему пользователю достаточно определить через конфигурацию приложения один раз и отметить галочками, на каких серверах потоки этого клиента будут обслуживаться.
В общем, клиентов на пробный период прибывало всё больше, многие после двух пробных недель оставались и подписывались. Устойчивая обратная связь давала пищу для планов на будущие фичи и даже позволяла грамотно расставлять приоритеты - чем больше что-то просят, тем выше стоит задача.
Однако стал заметен и другой процесс. Многие начали интересоваться поддержкой других продуктов, где есть работа с progressive download, также известный как псевдо-стриминг. К сожалению, при всей универсальности Wowza, она с этим протоколом не работает. Поэтому нас начали спрашивать - а не планируем ли мы поддержать эти продукты, также, как мы сделали поддержку Wowza и Windows Media? Самый популярный продукт из этой ниши - Nginx, у него есть соответствующие модули - как для MP4, так и для FLV. Также массово спрашивали и про работу с ShoutCast / IceCast - это протоколы вещания онлайн-радио, до сих пор весьма популярные во многих странах.
Со стороны расчёта статистики - многим нравится наш облачный подход, когда не надо ставить себе на сервер "ещё одну парсилку логов", а можно просто заплатить мелкую денежку и смотреть отличные графики через удобный интерфейс. Да и защита от ре-стриминга многим понравилась, не на всех платформах она есть, прямо скажем.
Вот тут мы встали на распутье. Вроде очевидно, что можно воспользоваться нашим же принципом встраивания агента и просто написать свой модуль для nginx. Он бы перехватывал всё что нужно, отдавал статистику и тем самым восполнял пробел в возможностях.
Мы к вопросу подошли более системно и обдумали, что же нужно будет типичному клиенту на самом деле. "Им ведь не nginx нужен" - подумали мы. А что же было нужно типичному клиенту, уходящего в сторону дешевого решения?
- Лёгковесный софт, поднимающийся на дешевом железе - хоть реальном, хоть виртуальном. В этом nginx силён, как никто другой.
- Софт, который сможет принимать и раздавать медиаданные по самым ходовым протоколам. Да, с правильными модулем nginx умеет процессить псевдостриминг, но не ShoutCast.
- Некое решение, которое позволит собирать статистику. Сейчас всё, что есть у пользователей nginx - это стандартные "парсилки логов", умеющие далеко не всё из того, что нужно рядовому стримеру. То есть потребовалось бы написать плагин для связи с нашим сервисом по аналогии с плагином для Wowza.
- Это некое решение должно ставиться на сервер легко и просто. Это проблема, т.к. установка плагина для nginx требует пересборки этого веб-сервера.
- Кроме того, от нас явно хотели поддержки нашей технологии защиты от ре-стриминга. А значит, опять таки, нужно сильно "допиливать" плагин nginx.
- Также шли другие запросы на функциональность, которые также требовали плотного ознакомления с кодовой базой сервера и серьёзной разработки в рамках его архитектуры. Например, раздача HLS потока из обычных MP4 медиа-файлов. Это есть и в Wowza, а в nginx это было реализовано только в рамках платной версии Nginx Plus.
В общем, взвесив все "за" и "против", было решено сделать свой стриминг-сервер, заточенный только под передачу медиаданных. В качестве целевой платформы рассматривался Linux, как доступный на подавляющем большинстве серверов, стоящих на вооружении в медиа-индустрии. Требования, перечисленные выше, не поменялись. Сервер должен быть простым в установке, быстрым и не требующим большого количества ресурсов.
Для начала реализации выбрали несколько сценариев, которые хотелось бы покрыть в первую очередь.
- Progressive download.
- ShoutCast и IceCast.
- Стриминг предварительно подготовленных статических файлов MP4 в HLS.
- Ре-стриминг HLS с уже работающих медиа-серверов вроде Wowza.
- Стриминг в HLS из входящего потока RTMP.
- Работа с прочими протоколами на базе HTTP, в первую очередь SmoothStreaming и MPEG-DASH.
Итак, было принято решение "писать своё". Именно этим и занялись. В январе 2013 была начата работа, а уже в апреле был выложен первый релиз, умевший не только очень хорошо работать с большим числом входящих соединений, но и производить полезную работу - ре-стримить HLS и раздавать контент через псевдостриминг. Надо ли говорить, что с первого дня этот сервер умел выдавать статистику для WMSPanel с последующим её показом в контрольной панели? Там же, в панели, можно было задавать основные настройки работы. Первая версия ставилась только на Ubuntu в силу её популярности и удобства пакетной установки. Именно так сразу и была сделана установка - пара команд в консоли для менеджера пакетов, запуск сервиса - и всё, он уже ждёт поступающих запросов. Итого, меньше 4 месяцев - и у нас есть базис для дальнейшей работы.
После определённых раздумий было принято название Nimble Streamer. Nimble - значит шустрый, юркий, быстрый. Тот, кто решает вопросы быстро, но без лишней суеты - в общем, "сращивает", как говорят у нас во Владивостоке.
Так что "шустрый стример" начать жить и активно двигаться вперёд. К настоящему моменту панель даёт всю статистику, доступную для Wowza Media Server. Сам Нимбл предоставляет защиту от ре-стриминга и фреймворк для построения систем pay-per-view - аналогичная функциональность уже была создана для Wowza, мы реализовали её на новой платформе, заодно несколько улучшив.
Наиболее популярны сценарии, связанные с HLS.
В первую очередь, это создание своих сетей доставки контента, где Wowza выступает в качестве центра подготовки стримов, а Nimble ставится между этим центром и конечными пользователями для равномерного распределения нагрузки и увеличения отказоустойчивости. Этот сценарий популярен среди компаний, занимабщихся живыми трансляциями. В этом случае и управление Вовзой, и снятие статистики с Нимбл-серверов производится в одной и той же панели.
Второй популярный сценарий - раздача VOD-контента из файлов MP4 в поток HLS. Это разнообразные "ютюбоподобные" сервисы, которые зарабатывают на подписке для доступа к контенту.
Также появились ряд "побочных" юзкейсов, которые немедленно или были реализованы, или поставлены в очередь задач.
Аппетиты клиентов, конечно же, не уменьшаются - новые идеи приходят регулярно. Ну и хорошо. Хуже всего в работе над новым продуктом - отсутствие обратной связи. Если её нет - что-то явно идёт не так. Ну а раз она есть и не ослабевает - мы на правильном пути.
Кроме того, открылась возможность использовать Нимбл с совершенно другого ракурса - для проверки целостности потоковой передачи данных.
Но об этом в следующей заметке.
0
