Привет, Хабр! Меня зовут Дмитрий Новожилов, я руководитель онлайн-кинотеатра КИОН от МТС, отвечаю за направление, связанное с видео. Может показаться, что это почти весь сервис, но есть нюансы. Моя команда работает только с потоками видеоданных — непосредственно с видеорядом.
Если вы строите или выбираете видеоплатформу — продакт вы, техлид, архитектор или руководитель, — этот материал для вас. Для тех, кто стоит перед выбором — писать свое решение или покупать готовое, — наш опыт покажет подводные камни обоих вариантов. Тем, кто уже работает с вендором, расскажем, как мы готовились к риску потери поддержки. А если вы задумываетесь о миграции на собственные рельсы, покажем, с чего мы начинали и какие компоненты оказались самыми сложными.
Но для начала давайте кратко рассмотрим, как устроен типовой онлайн-кинотеатр.
Как устроен типовой (и наш) онлайн-кинотеатр
Вот схема с основными компонентами типового онлайн-кинотеатра, которую я возьму за основу в своем рассказе.
Компоненты 1 и 2 — источники контента, которые в дальнейшем мы раздаем нашим пользователям. Я разделил их на два типа.
Прямые эфиры. Это нескончаемый поток данных — 365 дней в году, 24 часа в сутки кто-то что-то транслирует, и эта информация поступает на нашу видеоплатформу. Для конечного пользователя этот сервис выглядит как эфирные каналы: всегда где-то идет какая-то передача, и ты можешь либо подключиться и смотреть ее в прямом эфире, либо не подключаться, но она все равно будет идти. То есть классический сервис телевидения.
«Статический» контент. Это фильмы, сериалы или те же передачи, но уже записанные на носитель — то есть видео по запросу (Video On Demand), классический сервис кинотеатра.
Компонент 3 — узел обработки поступающего видео. Здесь схематически показана его обработка: трансформация (кодирование), пакетирование, шифрование, хранение и доставка конечным потребителям. Серым прямоугольником я выделил ту часть онлайн-кинотеатра КИОН, за которую ответственна моя команда.
Компонент 4 — метаданные. Это названия, постеры, описания, а для эфирных каналов — программа передач (EPG). Без этих данных платформа не может сформировать витрину, а пользователь не поймет, что смотреть. По сути, это тот слой, который превращает хранилище файлов в полноценный каталог.
Компонент 5 — BSS (биллинг-система). Здесь обрабатываются все транзакции по оплате просмотра: подписки на каналы, покупки контента в пакетных предложениях, промоакции и промокоды. Этот узел связывает платформу с биллинговым контуром (в нашем случае – оператора).
Компонент 6 — сервис рекомендаций на основе ИИ. Он решает ключевую бизнес-задачу: удерживает пользователей, которые не знают, что посмотреть, и увеличивает время просмотра. По сути, это движок витрины — того самого экрана, который пользователь видит первым.
Фронтэнд — не выделен отдельным номером на схеме, но без него платформа не работает. Это и клиентские приложения (мобильные, Smart TV), и аппаратный highload-узел, обрабатывающий запросы пользователей. При пиковых нагрузках — десятки тысяч запросов в секунду. Фронтэнд взаимодействует с остальными компонентами платформы, которые для него являются бэкендом.
Теперь, когда мы понимаем, из каких компонентов состоит типовая видеоплатформа, перенесемся на несколько лет назад, когда кинотеатр КИОН только начинался и перед руководителями проекта встал вопрос.
Делать самим или положиться на партнеров?
Думаю, нет смысла расписывать, как принимаются решения такого рода — просто рассмотрим плюсы и минусы каждого выбора. Подчеркну: я сильно упростил методику и критерии выбора, но суть от этого не меняется.
Делать самостоятельно: плюсы и минусы
Решение, написанное своей командой, дает максимальную гибкость и независимость в развитии продукта.
Если у вас нет команды с нужной экспертизой, ее придется собирать с рынка и начинать разработку. А это время и деньги — и OPEX, и CAPEX. Грубо говоря, время = деньги, а значит, писать самим почти всегда дороже, чем купить готовое.
Положиться на партнера: плюсы и минусы
Что же по решению довериться партнеру?
Здесь по плюсам — время и надежность. Обязательный критерий - у партнера этот продукт уже есть и он работает.
По минусам — партнер запросит приличную стоимость за свой готовый продукт, и естественно, что работа с вендором по изменению функционала всегда сложна.
В итоге, если снова допустить максимальные упрощения, получается: одно решение — 2Х дорого, второе — 1Х дорого. Поэтому руководство КИОН выбирает довериться партнеру.
Когда мы выбрали путь с вендором, нужно было определиться, с каким именно будем иметь дело. Процесс тендера в крупных корпорациях затрагивать не буду, лишь подчеркну мысль, которую нужно всегда держать в голове в подобной ситуации:
Чтобы запуск на вендорском решении был успешным, этот сервис у вендора уже должен быть написан. Если вы выберете того, кто под ваши требования начнет писать решение с нуля, оно ничем не будет отличаться от того, которое вы написали бы сами, только выйдет дольше, а значит и дороже. Время = деньги, мы помним об этом.
Но что значит «готовое решение»? Нужен аналогичный и успешный опыт запуска у другой компании. Большой коммерческий проект, где такое решение уже работает и работает успешно.
Основные критерии выбора партнера
Онлайн-кинотеатр — достаточно узкая ниша, и очень мало компаний в России могут похвастаться таким успешным опытом. Чтобы расширить воронку партнеров, мы решили ориентироваться на успешный международный опыт. Да, сейчас в нашей геополитической ситуации такие критерии кажутся недостижимыми, но напомню: когда этот вопрос поднимался, был еще другой мир.
Есть еще один момент: даже если подходящая компания нашлась, где гарантии, что после заключения контракта или даже после запуска она не распадется или не закроется? Ведь так бывает. А мы останемся с неподдерживаемой системой, которую невозможно развивать.
Поэтому при выборе мы обращали внимание на то, как компания относится к своим репутационным рискам. Большие игроки всегда пойдут навстречу в сложной ситуации. Ведь провал нашего совместного сервиса, запущенного на их решении, будет равен и их провалу. Потом им будет сложнее продать свое решение другим заказчикам, если тот самый «успешный опыт запуска» окажется не таким уж и успешным.
И хочу подчеркнуть еще один важный момент: решение, которое предоставляет партнер, должно быть коробочным. В него должны входить все компоненты, которые мы перечислили выше. Иначе пришлось бы договариваться с несколькими вендорами и интегрировать их решения друг с другом, чтобы сервис работал как часы — а это снова долго и дорого. У каждого решения свои интерфейсы для интеграции, и не все подойдет один в один без «напильников». Но если один партнер дает свое коробочное решение, в которое уже входят все другие компоненты, и это проверено и отлажено — можно считать, что вы выбрали максимально комфортный для себя вариант. Просто заплатили деньги и получили хороший результат.
Международного партнера, подходящего по всем критериям, мы нашли. Запуск занял 1 год: нужна была интеграция с контуром МТС и миграция части сервиса с текущего решения.
Казалось бы, все — я рассказал про компоненты кинотеатра, про выбор и его причины. На этом можно было бы и закончить. Но нет. Помните про минус решения при выборе партнера — гибкость? Всегда есть плата за скорость и надежность — и в нашем случае это было развитие сервиса.
«Черный лебедь»
Так как был выбран очень крупный вендор, дорожащий своей репутацией, любые изменения (change request) всегда были долгими. Вендор построил решение уровня доступности 99.999% (carrier-grade), так что любое изменение проходило долгий процесс тестирования. Никакого аgile — только старый добрый waterfall.
С этим можно было бы мириться, что мы и делали, но в историю ворвался черный лебедь — санкции. Поначалу удавалось находить решения, но гайки закручивались, риски росли. Последней каплей стал осязаемый риск отказа полной поддержки решения. И перед руководством КИОН встал вопрос: «Теперь переписывать самим?»
А это значит — разработать те самые компоненты и, самое главное, мигрировать. На этом этапе было принято решение: делаем сами.
Давайте я еще раз пройдусь по компонентам. Источники контента (1 и 2) — с самого начала КИОН имел свой продакшн и создавал оригинальный контент (Original). Контракты с зарубежными правообладателями (например, Disney, Paramount Pictures, Warner Bros. и так далее) тоже имеются, но их контент сейчас недоступен, поэтому работаем с российским и дружественным.
Что же дальше? Компонент 4 — метаданные. С первого дня работы с вендорским решением мы столкнулись с тем, что часть функционала не покрывается. Платить за доработки было невыгодно, поэтому мы собрали свою команду, которая научилась работать с платформой и клиентскими данными. Теперь замена этого компонента не выглядит сложной.
То же самое — с BSS, пункт 5. При запуске нужно было интегрироваться с биллингами МТС, а их было много. Вендор не стал брать на себя разработку отдельного шлюза: эти наработки ему потом негде было бы применить, кроме нас. В таких случаях стандартный ход — завысить цену. Поэтому мы решили сделать модуль сами.
Сначала это был просто прокси, потом бизнес оброс функционалом, и сейчас все данные о подписках уже внутри этого узла. Мастер-базой на тот момент он не был, но если данные уже есть, перевести его в статус мастер-базы можно гораздо быстрее, чем писать с нуля. Так что с модулем BSS особых сложностей не возникло.
Теперь модуль рекомендаций, пункт 6. Вендорское Big Data- решение мы использовали, но любые новые алгоритмы давались с трудом — и по времени, и по деньгам. Поэтому мы постепенно перешли на свою систему, которая брала из вендорской (DWH) те же данные, но обрабатывала их по-своему. Оставалось научиться хранить эти данные самим — и все, компонент наш. Задача сложная, но решаемая.
Перейдем к фронтэнду. Напомню, в этом узле я объединил и клиентские приложения для телефонов и телевизоров, и аппаратный парк, который обрабатывает десятки тысяч запросов в секунду и проксирует их в бэкенд. Тут аналогично: с самого запуска мы дописывали приложения под себя, и сейчас все они наши. Все плееры под нашим контролем. Нам осталось построить собственный аппаратный узел под highload-требования — а это тысячи CPU. Мы справились с этим за короткое время, и этот компонент не стал проблемой при переходе на свое решение.
Оставался самый сложный компонент — пункт 3, за который отвечаю я. Давайте посмотрим детальнее, что именно в него входит.
Система видеоконтента
Тут я снова схематически разбил прохождение видео на несколько этапов: кодирование, пакетирование, шифрование, хранение и раздача через CDN. Каждый из этих компонентов — полноценная самодостаточная система, на написание каждой может уйти не один год. Разберем их по порядку — и сразу посмотрим, что мы решили делать.
Кодирование. Если говорить про видео VOD, мы из мастер-файла создаем нужный профиль видео, кодируем в нужный кодек (например, H.264) и меняем размер кадра. Именно здесь формируется адаптивный битрейт — плеер подстраивается под качество интернет-канала и выбирает видео выше или ниже качеством в зависимости от скорости канала. Просмотр при этом идет бесшовно, пользователь не видит ни бубликов — буферизации, ни подергиваний.
Пакетирование. Здесь мы подготавливаем контент в тот транспорт, который будет потреблять конечный пользователь. У нас это либо DASH, либо HLS-транспорт. По факту мы формируем короткие отрезки видео — чанки — которые пользователь потом может по отдельности скачивать и проигрывать.
Коробочное решение от вендора подразумевало уже отлаженную интеграцию с крупными игроками на рынке, которые узко специализировались на отдельных задачах.
Кодеры. У нас два типа контента: VOD и LIVE (прямые эфиры). Для VOD подходят offline-кодеры, где время кодирования не очень критично. Фильм на полтора часа можно кодировать и три часа, если в итоге получается минимальный размер и максимальное качество. В вендорском решении за это отвечал отдельный компонент транскодера, причем кодирование и пакетирование были склеены в одну систему.
LIVE (прямые эфиры) — другое дело. Тут каждая секунда видео должна обрабатываться быстрее этой секунды, иначе задержка растет, и отставание становится все больше. Для этого мы использовали решение от другого поставщика (российского), которое работает на всех наших эфирных каналах.
Что мы решили по кодерам? Мы не видели больших рисков, что эта компания не примет наши доработки или перестанет оказывать поддержку, поэтому написание собственного кодера для онлайн-трансляций можно было отложить. Offline-кодер от другого поставщика — промышленное и надежное решение, которое за годы эксплуатации практически не требовало вмешательства и не подводило, поэтому его переписывание мы отложили на другой этап.
Шифрование (DRM). Защита контента от несанкционированного просмотра. Все, что связано с шифрованием, — очень закрытые системы. В нашем решении мы использовали третьего поставщика.
Что мы решили по DRM? Здесь все сложно. Расшифровкой контента занимаются конечные устройства — десятки разных компаний, от Apple и Samsung до китайских ноунеймов. Внедрить свой DRM во все эти системы на сегодняшний момент без поддержки государства невозможно (работающий кейс такого у нас — автомобили и системы ГЛОНАСС), а замена DRM — полумера, которая выглядит достаточно дорого. А так как с компанией-поставщиком у нас прямые отношения, риски по этому компоненту были проанализированы и приняты как приемлемые.
Хранение (Origin). Если мы говорим про VOD, мы должны хранить всю библиотеку фильмов и сериалов.
Что мы решили? Мы посмотрели, что есть на рынке, и поняли: готовые решения есть, но все коробочные, и подгонять их под нас — снова дорого и долго. Поэтому мы решили писать сами. Сейчас этот компонент уже написал и работает.
Content Delivery Network (CDN). Компонент, который позволяет доставлять наши видео в любую точку России за максимально короткий срок.
Хранение и CDN — это было вендорское решение, и они настолько тесно связаны между собой, что замена только одного из них либо поломает работу сервиса, либо сильно ухудшит его.
Что мы сделали? Начали с CDN. Был сформирована отдельная команда, которая занималась этим проектом, и так как в какой-то степени они были независимы от всех других функций, то могли независимо проводить работы, и их никто не блокировал. Это позволило нам за хоть и продолжительный, но разумный период (около года) полностью отказаться от вендерского решения.
Логика нашего выбора
Тут я хочу немного раскрыть весь путь, который мы прошли. Сначала мы определились с функциональными требованиями: делать так же, как работает сейчас, ведь у нас уже есть работающая система, и нет задачи кардинально ее менять. А вот нефункциональные пришлось формулировать жестче: убрать все минусы текущей реализации и сохранить все плюсы.
Первое требование — простая и быстрая горизонтальная масштабируемость. Вендорское решение было построено на архитектуре bare metal: физические серверы со HDD- дисками, на Linux, с программной кодовой базой производителя. Если нам не хватало мощности, масштабирование занимало несколько месяцев — от закупки оборудования до вендорской поддержки по настройке и запуску. В быстро меняющемся мире такой time-to-market — серьезный минус.
Второе требование — надежность. Вендорское решение (Origin) было максимально надежным. Вендор разработал не только ПО, но и аппаратную часть: корпус, блоки питания, материнскую плату, RAID-систему — собственную разработку. Все драйверы и файловая система тоже были кастомизированы под это решение.
За все время эксплуатации у нас ни разу не было проблем с Origin-сервисом. Даже когда мы по неосторожности нагружали систему сверх лимитов, она не ломалась — излишки просто отбивались с ошибкой. Я бы назвал это автоматом Калашникова в мире ИТ.
Перед нами встал вопрос: как добиться такой же надежности при горизонтальном масштабировании? Какую выбрать архитектуру решения? Мы выбирали между решением Cloud Native, которое точно удовлетворяло требованию по масштабируемости, и копированием текущего решения (bare metal).
Мы провели много теоретических расчетов, привязанных к параметрам текущей системы и ограничениям будущей инфраструктуры. Было понятно, что оптимизировать работу RAID-системы с десятками шпиндельных дисков будет максимально сложно — такого уровня экспертизы у нас нет и найти ее на рынке сложно, значит, придется недостаток производительности компенсировать количеством ресурсов. Мы понимали, что при повторении решения от вендора автоматического масштабирования не будет — сервера придется добавлять вручную. Мы хотели максимально оптимизировать инфраструктуру и не держать ресурсы под новогодние пики весь год.
В итоге было принято решение идти в Cloud Native. Для СХД (системы хранения данных) мы выбрали S3 — объектное хранение. Суть S3 в том, что вы один раз записываете объект и потом много раз читаете его, не меняя. Это максимально хорошо ложится на логику VOD: при публикации мы один раз подготавливаем фильм и сохраняем на S3, а потом выдаем по запросу пользователей.
Для прямых эфиров S3 не подходит — там данные льются постоянно, 24/7, 365 дней в году. Идет непрерывная запись и перезапись. А отдать нужно только те фрагменты, которые кто-то запросил при просмотре. Для этого идеально подходит оперативная память (ОЗУ): эфирный чанк акутален для пользователя всего несколько секунд, дольше хранить его не нужно. Все, что старше, — это уже не прямой эфир, а совсем другие сервисы: такие как пауза или отложенное ТВ.
Поэтому мы решили разделить Origin на две системы: для VOD — S3-хранилище, для прямых эфиров — оперативная память.
Еще одной сложностью было понять, смогут ли доступные на рынке S3-решения обеспечить нужную производительность и, самое главное, latency (задержка на отдачу объекта). Ведь общее время получения контента клиентом складывается из времени отдачи контента Origin и доставки его через CDN. Мы оптимизировали работу нового CDN и тем самым минимум вдвое снизили нагрузку на Origin. Эти работы помогли нам уложиться в производительность S3.
На синтетических тестах получилась даже лучше latency, чем у текущего Origin. А с учетом того, что мы заложили георезервирование, то обеспечили тот же уровень отказоустойчивости.
Вместо вывода
Я поделился нашим опытом — от первого выбора вендора до решения писать критичные компоненты самим, от архитектурных компромиссов до практических результатов. Надеюсь, наш путь поможет вам, если вы стоите перед похожим выбором: строить свою видеоинфраструктуру с нуля или брать готовое.
Конечно, многое зависит от того, кто вы и как хотите позиционировать себя на рынке. Если вы молодой кинотеатр и планируете ворваться в уже сформированную и поделенную аудиторию на рынке, писать самим — значит отставать на много лет.
Второе — это деньги. Если их нет и вы не претендуете на долю рынка, то проще писать сами. А если крупная компания с практически неограниченными финансовыми ресурсами, и вы хотите быстро ворватьсяи завоевать свою долю, то проще и логичнее довериться вендору.
И мы поступили именно так. У нас не было времени писать самим, поэтому мы решили купить коробочное решение и быстро выйти на рынок с новым продуктом. Сначала отвоевать свою долю рынка, а уже затем заняться с переписыванием под себя.
Многие, кто работает на коробочных решениях, рано или поздно приходят к тому, что необходимо свое — это известная дорожка. Но нужно ли по ей идти? Решение за вами.