Привет, Хабр! Меня зовут Дмитрий Новожилов, я руководитель одного из направлений в онлайн-кинотеатре KION. В прошлый постах рассказал, про попадание и нормализацию контента и про управление им в сердце киносервиса — элементе Middleware.
В этом посте я перейду к теме прохождения видеопотока: после пакетайзера «кадры» поступают на Origin, откуда и отправляются пользователям с помощью CDN.
Origin
Origin — это индустриальное название компонента, где хранятся оригиналы контента, который может получить пользователь. Словом «оригиналы» я отделяю этот контент от копии, тоже хранящейся на CDN (Content Delivery Network).
В подавляющем большинстве случаев Origin — подобие умной СХД (системы хранения данных). Объем контента в ней может исчисляться петабайтами.
Вот вам для наглядности. Представим, что средний фильм идет 90 минут, доступен в HD (High Definition) и имеет три профиля (это как раз копии фильма, что делает кодер для функционала ABR — адаптивного битрейта). Допустим, битрейт этих профилей 8 Мбит/с, 4 Мбит/с и 2 Мбит/с. Тогда размер одного фильма на Origin — это сумма произведений всех битрейтов на длительность (и переведем биты в байты): 9,45 Гбайт, округлим до 10. Если в кинотеатре 20 000 фильмов, то необходимы 200 Тбайт. Добавим трейлеры, копии в 4К — цифра лишь приблизительная.
И это только VoD-сервис. А как же Live (эфирные каналы)? Их тоже хранить?
В прошлом посте я затронул EPG (Electronic Program Guide), или программу передач. Она нужна, чтобы знать не только когда будет та или иная передача, но и когда она была. Это позволяет смотреть ее уже после трансляции в режиме отложенного ТВ, или CatchUp TV.
В большинстве случаев у каналов нет функции CU (CatchUp), поэтому нет смысла хранить на Origin больше данных, чем необходимо плеерам ваших устройств для правильной работы — это от 10 до 100 секунд видео в среднем.
Спойлер: как именно работает плеер и почему надо так долго хранить, опишу в завершающем этот цикл материале.
Но если канал позволяет записывать и предоставлять CU, то все его профили попадут на Origin. Обычно они хранятся 7 дней. Не все правообладатели телеканалов разрешают записывать свой эфир. Но для тех, кто так делает, было эмпирически выявлено, что держать более недели весь эфир нет смысла, а самые рейтинговые передачи проще сохранять отдельно.
Вернусь к расчетам. Представим, что эфирный канал в таком же качестве, как и VoD-контент, а именно — 14 Мбит/с на все профили. Неделя для одного канала, а их, допустим, 200. Получается еще порядка 200 Тбайт на Origin.
Есть еще один сервис — TimeShift, или ПаузаТВ. Вы можете поставить прямой эфир на паузу, на вашем экране он остановится, но на платформе продолжит идти и запишется на Origin. А когда вы возобновите проигрывание, то увидите запись этого эфира с задержкой, на которую отлучались. Обычно TS (TimeShift) предоставляется на 10–60 минут, после чего — только CU. Но TS не пишется автоматически для всех каналов и не занимает так много, чтобы заметно влиять на объем Origin.
Сложно назвать Origin обычным СХД. Набор HDD- или SSD-накопителей — это лишь часть Origin. Данные должны еще и раздаваться. В большинстве онлайн-кинотеатров — методом ОТТ (Over The Top). Другими словами — поверх протокола TCP. Или еще детальнее — по unicast. Каждый зритель одного и того же фильма поднимает отдельную TCP-сессию и скачивает свою копию. И если 1000 пользователей одновременно захочет посмотреть один и тот же фильм, то они создадут 1000 сессий и скачают 1000 копий одного и того же чанка. Если взять за максимальный битрейт фильма 8 Мбит/с — нагрузка от 1000 зрителей будет 8 Гбит\с. А если таких фильмов или эфирных каналов сотни? Никакой Origin не справится.
И тут мы плавно переходим к такому элементу онлайн-кинотеатра, как CDN (Content Delivery Network).
CDN
Многие не разделяют эти два узла (Origin + CDN) так как оба хранят контент и оба его раздают. Но требования у них разные.
Для начала опишу, почему CDN нужен онлайн-кинотеатру. Представьте, что Origin со всем контентом в Москве, а вы — в Норильске. Это где вечная мерзлота и куда добираются на самолете. А интернет там через спутник, чей канал сильно ограничен.
И вот пользователи Норильска хотят посмотреть какую-то передачу по эфирному каналу, и каждый запрашивает один и тот же контент с Origin. Общий канал связи Норильска не вместит эфир в хорошем качестве и без остановок (буферизации). Ставим в городе кеширующий сервер, который принимает и агрегирует запросы в сторону Origin, сохраняя видео на короткое время (обычно часы или дни).
Таким образом канал к этому кеш-серверу от пользователей будет такой же, а вот в сторону Origin — в разы меньше. Практика показывает, что для разного типа видео трафика CDN дает коэффициент кеширования 1:100. Другими словами, если пользователи запрашивают 100 Гбит/с, то на Origin уходит только 1 Гбит/с.
Главное для CDN — это территориально располагаться максимально близко к пользователю. Так видео грузится быстрее и в лучшем качестве, меньше нагрузка на Origin и, как следствие, на транспортные магистрали, что удешевляет доставку.
Почему не поставить Origin ближе к пользователю?
И ответ — математика. Требования к хранению на Origin максимальны. Нельзя потерять даже один чанк (фрагмент фильма), так как восстановить его невозможно, необходимо снова пройти публикацию, которую я осветил в первой статье. А система надежна настолько, насколько надежен ее самый слабый узел. Поэтому надежность повышают избыточными копиями узлов. А это дополнительные расходы.
Если чего-то нет на CDN-узле, это берут с Origin. И потеря или удаление данных на CDN растит нагрузку на связь с Origin и замедляет загрузку этих данных. Получается, что дешевле выносить ближе к пользователю узлы CDN, чем Origin.
А задержки — чистая физика. Магистральные каналы от Москвы до Владивостока — оптические. Учитывая скорость света и накладные потери, минимальная задержка — сотни миллисекунд. Вроде бы немного: фрагмент видео (чанк) обычно около 2 секунд, то есть у вас минимум секунда на доставку без влияния на сервис.
Но нельзя забывать про «последнюю милю». Почти всегда именно она задерживает сигнал сильнее всего. Что же такое «последняя миля»? Это канал от последнего управляемого узла до устройства клиента (смартфона или телевизора).
Managed и unmanaged сети в CDN
Интернет работает через сети. Представим онлайн-кинотеатр от оператора сетей, скажем МТС.
Сетевую инфраструктуру этой видеоплатформы контролируют работники МТС. Они могут настроить приоритеты для видео и оптимальные маршруты через незагруженные узлы связи, могут не тарифицировать трафик онлайн-кинотеатра. Эта сеть managed, то есть управляемая.
Что же такое unmanaged (неуправляемая) сеть? Если пользователь интернета от оператора не МТС (назову его «оператор Х») смотрит фильм с видеоплатформы МТС, то трафик идет по managed сети ровно до маршрутизатора, который подключен к сети оператора Х. Для онлайн-кинотеатра именно отрезок пути от своего последнего маршрутизатора до клиента и будет unmanaged сеть. Качество и доставку контента на ней невозможно гарантировать и оптимизировать.
Возвращаясь к «последней миле». Это отрезок сети от вашего устройства, где вы смотрите контент, до сети вашего оператора — точки доступа которую он вам выдал.
Если вы смотрите телевизор, подключенный по ШПД (широкополосному каналу данных), потери на «последней миле» минимальны, поскольку операторы оптимизируют свои проводные сети. А если вы используете мобильный телефон? Тогда «последняя миля» — канал от него до базовой станции. Ну или совсем понятный пример. Если ваш телевизор подключен по wifi то «последняя миля» — это радиоканал от телевизора до вашего wifi-роутера.
Вы можете спросить: зачем нам эта информацию? Подвожу к основной идее CDN-сервиса.
Там, где вы не контролируете доставку контента, там, куда managed сеть тянуть дорого и нерентабельно, там, где количество запросов на единицу контента велико, — там выгоднее и правильнее ставить узлы CDN. Чем они ближе к потребителю, тем быстрее отдают закешированные (а значит, самые популярные) данные.
Виды CDN
Поскольку я глубоко копнул эту тему, добавлю, что CDN делится на двухуровневые и трехуровневые. Если у нас один Origin и десятки выносных узлов CDN по всей стране (выносной узел назову Edge, еще один индустриальный термин) то данные, которых нет на Edge-узле, запросятся с Origin. Это двухуровневая схема. А если мы в крупных регионах поставим еще один промежуточный узел (назову его Shield), который принимает запросы от Edge и компонует в общий запрос к Origin, — то такая схема уже будет трехуровневой.
В трехуровневой схеме ряд плюсов: не нужно гонять много трафика на Origin, уменьшается время запроса одного и того же фрагмента в одном регионе, но с разных Edge-узлов.
На CDN всегда есть TTL (Time to Live) — срок жизни фрагментов. Его выставляют, чтобы не занимать драгоценное место фрагментами, которые запросили единожды. Допустим, на узлах Edge ставим день, а на Shield — 7 дней. Тогда Edge — горячее хранение (данные часто меняются и перезаписываются), а Shiled — холодное. Но это все же относительно, конечно, привожу скорее для сравнения.
Какие бывают еще варианты доставки контента
Это уже не про CDN в том виде, что я описал выше: там трафик доставляется как OTT, то есть поверх протокола HTTP, или можно сказать «unicast».
Есть еще вид доставки сервиса IPTV/DVB. И да, это «зрелый» транспорт. Немногие вспомнят, но в далекие времена можно было смотреть кабельное телевидение по коаксиальному кабелю (как антенный в доме), но данные передавались уже в цифре. Это и есть DVB (Digital Video Broadcasting). Такая схема доставки тоже делится на несколько вариантов: DVB-C/DVB-S/DVB-T. Немногие онлайн-кинотеатры предоставляют сервис по таким каналам связи, ведь это всегда managed сеть (для DVB-C, где C — cable). И строить такую инфраструктуру очень сложно. Только если она вам «досталась по наследству».
И второе направление — IPTV (скажу так: это эволюция DVB в IP-сети). IPTV работает по всем нам известному IP-протоколу, но все еще нужен кабель, уже не коаксиальный, а интернет (медный многожильный или современный оптический). Особенность IPTV-доставки — multicast-передача данных. Я затронул IPTV и multicast в этом разделе только потому, что такой способ существовал до CDN и заменял его на тот момент, поскольку концептуально делал то же самое.
Как же идет контент по IPTV-сетям? Все просто. Представим многоэтажный дом во Владивостоке, где в каждой квартире устройство приема IPTV и все смотрят одну и ту же телепередачу в прямом эфире. С первого устройства, владелец которого включил этот канал, идет запрос на центральный узел в Москве. Прямой поток данных отправляется во Владивосток — в этот дом, в локальный коммутатор этого дома/подъезда и, через медный кабель, — на приставку этой квартиры. Все, 10Мбит/с канал данных открыт на этом отрезке.
Как только вторая квартира включает этот же канал, домовой/подъездный коммутатор получает вопрос: «Такой канал на этом коммутаторе уже есть?». И если да, то все данные зеркалируются в другой кабель подъезда и попадают во вторую квартиру. Таким образом, неважно, сколько квартир смотрят одну и ту же передачу, — из Москвы пойдут все те же 10Мбит/с. Так работает multicast («от одного ко многим»).
Но что делать если вы хотите посмотреть один фильм (VoD), а в соседи — другой? В этом случае IPTV уже не может быть использовано, так как это уже не multicast а unicast («от одного к одному»). Но и такой сценарий раньше делали. Были каналы-карусели, где целый день (24\7) крутили одни и те же фильмы по кругу. Если один и тот же фильм запрашивали несколько квартир, то они подключались по multicast к этому каналу. Такой тип сервиса называется NVOD (Near Video on Demand).
И в завершение добавлю, что подавляющее число онлайн кинотеатров может работать с любым поставщиком сервиса CDN. То есть физических ограничений показывать контент в любой точке мира нет. Понимая работу CDN для онлайн-кинотеатра, вы можете лучше понять принцип работы интернета.
На этом у меня пока все. Спасибо! Подробнее о манифестах и чанках, о шифровании и дополнительных данных вроде субтитров, о форматах видеоконтента, а также о том, зачем плеер меняет качество при просмотре, расскажу в следующей статье. Задавайте вопросы в комментариях — с удовольствием отвечу!