Облачная платформа Synamedia Cortex: резервирование, CDN и доставка видео
Интервью с Тимуром Юсуповым, Pre-Sales Engineer Synamedia, о том, как операторы платного ТВ и OTT используют Synamedia Cortex для перегонов, мульти-CDN и отказоустойчивого вещания без полной перестройки инфраструктуры.
КТО ТАКИЕ SYNAMEDIA
– Для многих название Synamedia всё ещё не на слуху. Почему так?
К сожалению, компания Synamedia не так известна на нашем рынке, как могла бы быть. Причина в том, что долгое время мы находились «за ширмой» крупного бренда. Уже больше 30 лет мы занимаемся доставкой, компрессией, передачей и защитой видео.
– С чего всё начиналось?
История идёт с 1988 года — с создания компании News Datacom. Кто-то, возможно, помнит это название. Позже она была переименована в NDS. NDS до сих пор используется, например, в Castile Radio — это система закрытия видеоконтента.
ОБЪЕДИНЕНИЯ, ПОКУПКИ И CISCO
– Как из этого выросла нынешняя Synamedia?
Со временем начались слияния и поглощения. В структуру нынешней Synamedia, например, вошла компания BarcoNet. Потом была Scientific-Atlanta, которую купили.
А затем все эти компании были приобретены Cisco.
– И тут вы «пропали из виду»?
По сути — да. Когда Cisco купила весь этот видеобизнес, мы фактически оказались внутри большого сетевого вендора. Cisco активно продавала своё сетевое оборудование, но видеонаправление, особенно в нашем регионе, развивалось не так активно. До 2020 года здесь вообще не было ни одного человека, который бы официально отвечал за видео-направление Cisco / Synamedia. Мы существовали, но нас почти не было видно.
ОТ CISCO К НЕЗАВИСИМОЙ SYNAMEDIA
– Как произошёл переход к независимой компании?
Через несколько этапов трансформации Cisco приняла решение выделить видео-направление в отдельную структуру. Так появилась самостоятельная компания Synamedia. Сейчас мы уже несколько лет работаем как полностью независимая компания. И занимаемся только вопросами, связанными с доставкой видео — от захвата и обработки до защиты и монетизации.
СТРУКТУРА SYNAMEDIA: ТРИ НАПРАВЛЕНИЯ
– Из чего сегодня состоит Synamedia как структура?
В компании три больших подразделения.
Первое — Video Network. В нём работаю я и мой коллега Андрей.
Второе — Media Technologies.
Третье — Media Cloud Services.
MEDIA TECHNOLOGIES И MEDIA CLOUD SERVICES
– В чём разница между Media Technologies и Media Cloud Services?
Media Technologies занимается, грубо говоря, более «классическим» вещанием. Это: смарт-карты для set-top box, классическое middleware, традиционные решения для операторов платного ТВ.
Media Cloud Services — это всё, что связано с облачными платформами: облачные решения для стриминга, скремблирование и DRM, аналитика по доставке видео и поведению зрителей, рекламные технологии.
– Можно чуть подробнее про рекламу?
В рамках Media Cloud Services есть продукт IRIS. Это, по сути, комплексный рекламный комбайн: от планирования рекламной кампании до подготовки рекламных ассетов и точной вставки рекламы в нужный момент и в нужном месте. То есть это не просто «вырезать и вставить ролик», а полноценная платформа управления рекламой поверх видеосервиса.
VIDEO NETWORK: ЧТО МЫ ДЕЛАЕМ ПОСЛЕ ПРОДАКШЕНА
– Мы уже поговорили о Media Cloud Services и рекламе. Что такое направление Video Network?
Если коротко, Video Network — это всё про доставку контента. Мы занимаемся:
– point-to-point и B2B-доставкой;
– классическими линейными схемами;
– магистральной первичной дистрибуцией.
Важно, что мы не занимаемся продакшеном, в отличие от некоторых компаний, представленных сегодня. Мы подключаемся после продакшена.
Помогаем организовать «перегон» сигналов, первичную дистрибуцию контента:
– DTH-операторам,
– OTT-платформам,
– стриминговым сервисам,
– а также доставку через интернет с использованием CDN.
МАССШТАБ: СКОЛЬКО ТРАФИКА И ЗРИТЕЛЕЙ
– Можно немного цифр, чтобы понять масштаб?
Хотя бренд Synamedia не всегда на виду, объёмы очень серьёзные. Больше 100 Тбит/с видео трафика в пике проходит через спутник с использованием нашего оборудования. Сейчас более 100 миллионов абонентов по всему миру смотрят телевидение и видео, в тракте которого так или иначе участвуют наши решения.
КТО НАШИ КЛИЕНТЫ
– Для кого вы всё это строите?
В первую очередь — для традиционных вещателей. Мы работаем:
– с классическими телеканалами и сетями;
– с контент-провайдерами;
– с операторами платного ТВ (Pay TV);
– с правообладателями, особенно в спорте;
– со стриминговыми операторами, которым нужна стабильная OTT-доставка.
То есть наши клиенты — это весь спектр: от владельца прав на спортивную лигу до кабельного оператора и крупного национального телеканала.
КУДА СМОТРЯТ ВЕЩАТЕЛИ И ОПЕРАТОРЫ
– Какие тренды вы видите в поведении заказчиков? Во что они инвестируют?
Если по сегментам, картина такая.
Традиционные вещатели:
– всё активнее уходят от чисто классического эфирного вещания;
– смотрят в сторону IP и доставки через CDN;
– добавляют или строят параллельный IP-тракт.
Pay TV-операторы:
– прямо сейчас мигрируют от «железных» классических хэдэндов;
– сначала переходят на программные (software-based) решения on-prem;
– затем двигаются в сторону облачных сервисов.
Кабельные операторы:
– активно разворачивают доставку по IP в своей сети;
– HFC-сети постепенно вытесняются схемами «оптика до дома» (FTTH), и это меняет архитектуру.
КАНАЛЫ ИДУТ В СТРИМИНГ
– А что происходит на стороне самих телеканалов?
Почти каждый серьёзный телеканал сегодня имеет собственную онлайн-платформу или приложение. Это уже норма: вещатель хочет доставлять тот же контент, который идёт в эфире, и напрямую в интернет. Это один из самых устойчивых трендов, который мы видим.
ОТ СПУТНИКА К IP И MULTI-BITRATE
– Вы упоминали смену схем регионализации. Что это за кейс?
Один из крупнейших вещателей в Северной Америке полностью пересматривает схему доставки регионального контента. Раньше классическая модель выглядела так:
– через спутник доставляется множество региональных версий;
– регионализация делается в разных точках, много «разветвлённой» инфраструктуры.
Это дорого и неэффективно.
Сейчас они смотрят в сторону:
– миграции на IP-доставку,
– использования CDN и IP-сетей вместо спутниковых «вееров»,
– перехода на мультибитрейт (adaptive bitrate), чтобы оптимально обслуживать разные устройства и качества.
И вот как раз здесь мы и подключаемся — со стеком Video Network, который позволяет плавно уйти от чисто спутниковой модели к гибридной или полностью IP-архитектуре, без потери надёжности и управляемости.
CDN: ОТ СОБСТВЕННЫХ СЕТЕЙ К ГИБРИДНЫМ МОДЕЛЯМ
– Вы затронули тему CDN. Что там меняется сейчас?
Региональный контент всё чаще доставляется уже не старыми схемами, а совсем новыми технологиями. По CDN мы видим интересный двусторонний тренд.
С одной стороны, операторы, которые раньше пользовались только собственной CDN внутри своей сети, вдруг понимают, что им нужно расширять сервис за пределы своей территории,
выходить в другие страны или регионы, и им приходится подключать публичные CDN как партнёров. С другой стороны, те, кто раньше пользовался только публичными CDN «как сервисом», теперь замечают, что у них есть сегментация аудитории.
Им выгоднее: либо строить свой CDN-слой под конкретную страну, либо арендовать специализированную CDN в определённом регионе. Такую гибридную модель мы, например, наблюдаем в Италии. Часть трафика идёт через собственные ресурсы, часть — через публичные CDN, и всё это управляется как единый сервис.
ПЛАТФОРМА CORTEX: ДЛЯ ЧЕГО ОНА НУЖНА
– Перейдём к вашим решениям. Что такое Cortex и откуда он появился?
Cortex — это наше зонтичное название для платформы управления и оркестрации сервисов доставки видео. Мы, как Synamedia, позиционируем себя как компанию, которая помогает трансформировать или мигрировать сервисы в облако — но без фанатизма. То есть мы не говорим: «Завтра всё в cloud, иначе вы отстали». Мы смотрим на экономику и на реальные задачи. Если облако действительно необходимо или экономически оправдано — мы помогаем мигрировать. Если нет — можно оставаться на традиционных решениях, которые мы продолжаем поддерживать.
ЖЕЛЕЗО, СОФТ И ВИРТУАЛИЗАЦИЯ
– У вас по-прежнему есть «железные» решения или всё уже только в софте?
Есть и то, и другое. Во-первых, у нас остаются классические апплиансы — аппаратные решения: «железка» плюс предустановленный софт, есть порты, есть понятная схема подключения — многие операторы это любят.
Но на этом железе крутится ровно тот же софт, который может работать в вашем собственном дата-центре, в виртуализированной среде, в частном или публичном облаке.
Если у вас уже есть свой дата-центр, иногда просто нет смысла покупать отдельное железо.
Можно взять только программную часть, развернуть её у себя — и получить тот же функционал.
Фактически, первый шаг миграции — от чистого «железа» к виртуализированным софт-решениям.
ОБЛАЧНЫЕ СЕРВИСЫ: SELF-SERVICE И MANAGED
– А как выглядят ваши облачные сервисы? Все ли они «делай сам»?
Облака бывают разные — и сервисы в них тоже.
Есть модель self-service: у заказчика есть веб-интерфейс, есть набор инструментов, он сам конфигурирует сервис, как с обычным оборудованием.
А есть managed service: у нас есть глобальный круглосуточный операционный центр, наши сервисные инженеры настраивают всё за вас, мониторят, управляют, масштабируют. В такой модели клиент сосредоточен на бизнесе: например, ему нужно просто «перегнать» сигнал из точки А в точку Б, или обеспечить доставку матча, турнира, канала. А всё, что касается настроек, качества, резервирования, SLA — остаётся на нашей стороне.
– То есть это что-то вроде «транспорт под ключ»?
Именно. У нас есть реальные заказчики, которые пользуются таким сервисом: формулируют задачу по контенту и географии, а техническую часть полностью отдают нам. Есть и третий вариант — гибрид: часть функционала клиент ведёт сам, часть — отдаёт нам как managed-сервис.
Выбирается модель, которая оптимальна по деньгам, компетенциям и срокам запуска.
ГИБРИДНЫЕ МОДЕЛИ: «ВСЁ У СЕБЯ, НО НА ВАШЕМ СОФТЕ»
– А если заказчик не хочет отдавать контроль ни над платформой, ни над инфраструктурой?
Такой вариант у нас тоже есть. Некоторые клиенты говорят прямо: «Мы не хотим терять контроль ни над чем. Мы хотим, чтобы ваш софт работал в нашем собственном облаке или в нашем сегменте глобального облака». Это абсолютно возможный сценарий.
Система в этом смысле достаточно гибкая: можно мигрировать в облако, можно не мигрировать, можно комбинировать on-prem, приватное облако и публичный cloud.
ОТ «ЖЕЛЕЗНОГО» DCM К VIRTUAL DCM И ОБЛАКУ
– За счёт чего получается такая гибкость в технологиях?
Во многом благодаря эволюции наших продуктов. Раньше была чисто «железная» система DCM — аппаратный комплекс, разработанный много лет назад.
Первый шаг — мы полностью перенесли её в софт, так появился Virtual DCM. Тот же функционал, но уже в виде программного решения, которое можно запускать на стандартных серверах.
Следующий шаг — на этих же технологиях мы построили облачные сервисы.
То есть сегодня один и тот же стек может жить на «железном» апплиансе , в виде виртуальной машины в вашем дата-центре или как облачный сервис, управляемый через Cortex.
VORTEX PLAY И VORTEX LINK: ЭФИР ЗА ПЯТЬ МИНУТ
– Вы упоминали, что можно «за 5 минут» поднять вещание. Как это выглядит на практике?
У нас есть self-service-сервисы.
Первый — Vortex Play. Через него за буквально несколько минут можно: подцепить видеосигнал, организовать вещание телеканала или любого контента, задать регион доставки (весь мир или конкретный регион), и посмотреть его с мобильного телефона. При нормальном интернете это реально занимает около пяти минут.
Второй сервис — Vortex Link. Это тоже self-service: быстрая настройка перегона по SRT,
например, из Германии в Японию или между двумя городами внутри одной страны. Создаёте SRT-точку входа и SRT-точку выхода — и дальше работаете как с обычным линком.
MEDIA EDGE GATEWAY: БОЛЬШЕ, ЧЕМ ПРОСТО РЕСИВЕР
– Давайте вернёмся к «железу». Что такое ваши ресиверы Media Edge Gateway?
Это не просто классический ресивер, это Media Edge Gateway. Он умеет принимать сигналы:
со спутника, по IP, по SRT, по Zixi (ZIGZIG/ZIXI). Дальше он декодирует их в SDI или SDI over IP.
Но важнее то, что это больше, чем «просто IRD», он умеет переключаться между разными входами, может выступать как переходный элемент от спутника к публичному интернету.
Например: сегодня вы принимаете канал со спутника. Завтра вещатель говорит: «Переходим на SRT». Вам не нужно менять железо — Media Edge Gateway уже умеет и спутник, и SRT. И наоборот, — можете комбинировать разные входы и сценарии.
ДИСТРИБУЦИЯ B2B: VDCM, CORTEX, POWERVIEW, CORTEX LINK
– Как это всё собирается в решения для B2B-дистрибуции?
За бизнес-to-business дистрибуцию контента через спутник или IP у нас отвечает связка VDCM + Cortex. Virtual DCM — это «двигатель» обработки, компрессии, мультиплексации. На стороне сервисов ему соответствуют Cortex PowerView и Cortex Link.
Cortex Link — это как раз self-service для транспортировки. Заказчик сам настраивает точку входа SRT и точку выхода SRT, определяете параметры, резервирование и т. д.
PowerView и другие компоненты Cortex уже отвечают за управление, мониторинг и интеграцию в общую инфраструктуру.
В итоге у заказчика есть выбор «железный» приёмник + локальный VDCM, чисто софт в своём дата-центре или связка с облачными сервисами Cortex — в зависимости от задач и бюджета.
CORTEX LINK: ВКЛЮЧИЛИ МАТЧ – ВКЛЮЧИЛИ ПЕРЕГОН
– В реальной эксплуатации Cortex Link — это просто «одна труба» или может быть их много?
Таких «труб» может быть сколько угодно. Можно: создать множество SRT-линков, задать для них расписание, включать перегоны только тогда, когда они нужны. Например, у вас сетка футбольных матчей — вы включаете доставку сигнала только на время матча и выключаете в остальное время. Это позволяет не держать всё постоянно «горячим» и оптимизировать затраты.
CORTEX POWERVIEW: MANAGED-СЕРВИС ПОД КЛЮЧ
– Чем Cortex PowerView отличается от Link?
Cortex PowerView — это более расширенный вариант. Он не только даёт инструменты по управлению потоками, но и подключает наши managed-сервисы и операционный центр.
Хороший пример — компания Hearst Networks. Они много лет назад перенесли продакшен и плейаут в облако. Но для доставки использовали публичные сети «как есть», и результат их не устроил по надёжности. Примерно год назад они объявили тендер, где искали партнёра, который:
обеспечит доставку телеканалов, возьмёт на себя техническую часть, даст им возможность сосредоточиться только на бизнесе.
Мы предложили Cortex PowerView и выиграли тендер. За прошедший год у них: ноль отказов, ноль жалоб от получателей контента. Наш глобальный операционный центр мониторит все потоки и даже предупреждает «концовую» сторону. То есть получатели контента не успевают увидеть проблему — им заранее приходит уведомление: «Возможны перебои, переключитесь, пожалуйста, на резерв». В результате Hearst, как ни странно, даже «немного недовольны» в том смысле, что им теперь совсем нечего обсуждать с нами в части инцидентов — их просто нет.
СТРИМИНГ: МУЛЬТИБИТРЕЙТ, CATCH-UP И TIMESHIFT
– Что по стримингу и VOD?
В стриминге мы опираемся на ту же платформу DCM / VDCM. Она позволяет:транскодировать в мультибитрейт, пакетировать потоки, записывать контент для catch-up и time-shift. На стороне Cortex этому соответствует сервис Cortex Play.
Как я уже говорил: за пять минут можно развернуть OTT-вещание в мультибитрейте, выставить географию и параметры доставки, и вывести всё это на конечных пользователей.
EDGE CDN SYNAMEDIA: НЕ ЕЩЁ ОДИН PUBLIC CDN
– Вы сказали, что у вас есть собственное решение для CDN. Это ещё один публичный CDN?
Нет, публичный CDN мы специально не делали — их и так достаточно. Есть Akamai, CloudFront, много локальных игроков в разных странах. Мы подошли с другой стороны.У Synamedia есть собственное Edge CDN-решение: это полнофункциональная платформа, которую можно развернуть прямо в сети оператора, и использовать для доставки контента до абонента. То есть это «ваш собственный CDN под ключ», а не ещё один глобальный сервис.
МНОГО CDN ВМЕСТО ОДНОГО: ГЛАВНЫЙ ТРЕНД
– Зачем тогда ещё один CDN, если уже есть крупные игроки?
Ключевой тренд такой: операторы и стриминговые платформы хотят работать не с одним CDN, а сразу с несколькими. Им нужно: распределять нагрузку между разными CDN, оптимизировать маршрутизацию и стоимость, быть независимыми от одного поставщика.
Поэтому наша задача — дать им: собственный Edge CDN в их сети, и инструменты, чтобы сочетать его с публичными CDN, управляя всем этим как единой системой доставки.
Это уже не «ещё один CDN на рынке», а архитектурный слой для тех, кто хочет контролировать и качество, и экономику доставки своего видео-сервиса.
МНОГО CDN ДЛЯ ОДНОГО СЕРВИСА: SKY, DAZN И ИТАЛЬЯНСКИЙ КЕЙС
– Вы упоминали, что крупные игроки уже работают сразу с несколькими CDN. Можете привести примеры?
Хорошие примеры – Sky и DAZN. Оба активно выводят спорт «из облака в дом» через интернет. Они видят, что глобальная доставка, например только через Akamai, не всегда даёт нужный результат: в каких-то регионах есть всплески спроса; в каких-то странах резко растёт аудитория именно спортивного контента.
Нет смысла в таких случаях полагаться только на глобальный CDN. Гораздо эффективнее использовать CDN, который физически и логически ближе к зрителю – в сети местного оператора.
В Италии тот же DAZN арендует CDN-инфраструктуру у Telecom Italia. А CDN в сети Telecom Italia как раз построен на решениях Synamedia.
CORTEX SWITCH: БЕССШОВНОЕ ПЕРЕКЛЮЧЕНИЕ МЕЖДУ CDN
– Крупным сервисам важна бесперебойность. Как организовать переключение между CDN так, чтобы пользователь ничего не заметил?
Именно для этого мы сделали Cortex Switch – это наша свежая разработка. Он позволяет абсолютно бесшовно переключаться между разными CDN.
Для зрителя это выглядит так: он начал смотреть матч через CDN Akamai; нагрузка в регионе резко выросла; оператор решает перевести пользователей на локальный CDN в сети, скажем, Telecom Italia; Cortex Switch выполняет переключение прозрачно, без разрыва и «перезагрузки» плеера.
Конечный пользователь не увидит, что в какой-то момент трафик пошёл уже через другой CDN. Мы работаем по стандартным протоколам и интегрируемся с разными CDN. Если интересно «железо и протоколы», могу после выступления рассказать технические детали.
ПРОДУКТ, BLUEPRINT И СЛОЖНОЕ РЕШЕНИЕ
– Вы упоминали три «ипостаси» решений Cortex. В чём разница?
Мы предлагаем решения в трёх форматах: продукты, так называемые blueprint-конфигурации и сложные (custom) решения.
Если использовать автомобильную аналогию. Продукт – это готовая машина. Вы приходите в салон, выбираете конкретную модель, садитесь и едете. Четыре колеса, руль – всё предсказуемо и стандартизовано.
Blueprint – это та же модель, но с набором опций. Вы видите список доступных опций и выбираете: эту – да, эту – нет. Машина остаётся узнаваемой, но конфигурация подстраивается под ваши задачи и бюджет.
Сложное решение – это уже не «машина из каталога», а индивидуальная сборка под конкретную задачу. Когда стандартными средствами вендоров проблему не решить, мы вместе с заказчиком конструируем архитектуру, которая будет работать 24/7. Здесь мы можем использовать и наши продукты, и решения партнёров.
В табличном виде это выглядит так: в продукте все параметры и цена заранее предсказуемы; в blueprint-подходе есть регулируемые элементы, которые можно «крутить»; в сложном решении определённости меньше, потому что каждый проект уникален, – но именно поэтому он максимально точно попадает в требования заказчика.
МОДЕЛИ ОПЛАТЫ: PAY AS YOU GO, ПОДПИСКА И PREPAID
– Как устроена ценовая модель?
У нас три основных варианта.
Первый – Pay as you go (PSUGO). Платите только за фактическое использование. Условно: выпили бутылку воды – оплатили её; больше не хотите – ничего не платите. Это удобно, когда оператор никогда не работал, например, в ABR или с IP-перегонами и хочет просто попробовать. Он заходит на портал, настраивает перегон, проводит тест, платит только за этот перегон и, если ему не понравилось, может просто забыть о сервисе.
Второй – ежемесячная (или годовая) подписка, Monthly Recurring. Здесь логика другая: если вы вещаете 24/7 и понимаете, что сервис будет использоваться постоянно, выгоднее перейти на фиксированную подписку. У нас есть система скидок, и в итоге постоянным клиентам подписка обходится дешевле, чем оплата по факту. Такой моделью пользуются, например, оператор Yes в Израиле и тот же Hearst Networks – для доставки каналов «точка-точка» по Европе и Африке.
Третий – Prepaid-модель. Она появилась по запросу конкретного заказчика – Olympic Channel Services.
PREPAID ДЛЯ СПОРТА: OLYMPIC CHANNEL
– Чем prepaid отличается от pay as you go?
Pay as you go – это абсолютно «по факту», без заранее фиксированного объёма.
Prepaid – это модель для тех, у кого заранее известен объём событий.
Olympic Channel Services – это интернет-канал олимпийских видов спорта, базируется в Испании. Они сказали: «У нас в году есть заранее известное количество соревнований: такие-то этапы, такие-то турниры, такие-то города. Нам нужно их освещать, мы примерно знаем, сколько будет событий».
Мы специально разработали для них prepaid-модель: они заранее оплачивают известное количество событий или объём ресурса; спокойно планируют сезон; и не думают, сколько «накликают» по Pay as you go.
Для них это получилось и предсказуемо, и экономически комфортно.
МОДЕЛЬ ОПЛАТЫ И ВЫБОР ПРОДУКТА
– Объясните тарифную политику.
Если клиент выбирает Pay as you go, то доступны только готовые продукты. То есть то, что можно сразу взять и использовать, но нельзя гибко кастомизировать под себя. Если заказчик хочет более сложную конфигурацию, тот же blueprint или полностью кастомное решение,
то модель pay-as-you-go уже не подходит. Там появляются другие схемы ценообразования – подписка или prepaid.
Главная идея – быстро понять, какие комбинации «модель оплаты + тип решения» вообще возможны.
КАК РАБОТАЕТ MANAGED-SERVICE: ШЕСТЬ ШАГОВ
– Как выглядит работа с вами, если клиент выбирает управляемый сервис?
Обычно это шесть шагов.
Первый – анализ потребностей. Мы разбираемся, что именно нужно заказчику: доставка сигнала, стриминг, резервирование, география, SLA.
Второй – развёртывание инфраструктуры. Если нужно, поднимаем всё в облаке или в гибридной схеме.
Третий – интеграция. Подключаем все компоненты, в том числе сторонние решения –
в сложных проектах это почти всегда так.
Четвёртый – аналитика и отчётность. Настраиваем панели, графики, метрики в том виде,
который удобен именно этому заказчику: качество картинки, стабильность доставки, задержки и т. д.
Пятый – обучение. Мы обучаем команду заказчика и постепенно передаём им оперативное управление.
Шестой – совместное планирование развития. Наши сервисные инженеры и команда клиента вместе думают, как масштабировать сервис, какие функции добавить, куда двигаться с точки зрения технологий и бизнес-задач.
УРОВНИ ПОДДЕРЖКИ: ОТ ЧАТА ДО «НУЛЯ ПРОСТОЕВ»
– Поддержка всегда одна и та же или есть уровни?
Есть несколько уровней. В самом простом варианте, который частично всегда включён, если вы пользуетесь Cortex Play или Cortex Link по модели pay-as-you-go, у вас всё равно есть базовая поддержка – можно написать в чат, получить помощь.
Но если речь идёт, скажем, о крупном спортивном событии, где допустимый downtime равен нулю, такая поддержка, конечно, недостаточна. Там нужны другие SLA, другой уровень готовности и реакции, поэтому мы переходим к более дорогим, но и более серьёзным пакетам техподдержки.
АРХИТЕКТУРА CORTEX: CONTROL PLANE И DATA PLANE
– Если посмотреть внутрь Cortex как облачного решения, из чего он состоит?
Компонентов несколько. Есть так называемый customer-portal и два ключевых слоя:
control plane и data plane. Control plane – это уровень управления. Data plane – это уровень, где реально обрабатывается видео. Оба этих слоя могут находиться в одном облаке, а могут быть распределены по разным площадкам – в зависимости от требований по латентности, безопасности, юрисдикции.
ДВА ПОРТАЛА: ДЛЯ БИЗНЕСА И ДЛЯ ТЕХНИКИ
– Что видит бизнес-пользователь и что видит инженер?
Условно есть два портала.
Первый – бизнес-портал (customer portal). Это базовая веб-страница, где есть: логины, пароли, биллинговая система, отчёты по использованию. Это инструмент управления именно бизнес-частью сервиса: кто подключен, сколько потребил, сколько стоит.
Второй – портал приложений Cortex Applications. Там уже настраиваются сами сервисы:
точка–точка (point-to-point), стриминг, перегоны, профили, резервирование и т. д. Это рабочее место инженера или продвинутого оператора.
DATA PLANE: ГДЕ ЖИВЁТ ВИДЕО
– А что происходит на уровне data plane?
В data plane разворачиваются наши технологические компоненты. Там могут работать: модули Just-in-Time обработки, Virtual DCM, компоненты сторонних производителей, если того требует архитектура, а также слой управления облачной инфраструктурой.
Последнее важно для динамического масштабирования. Например, вырос трафик на матче – Cortex автоматически поднимает больше ресурсов. Событие закончилось – ресурсы освобождаются. Вся эта часть «под капотом» не требует вмешательства заказчика – он видит только стабильную доставку контента и контролирует сервис через порталы.
ПРОДУКТЫ: ВСЁ УЖЕ СОБРАНО И АВТОМАТИЗИРОВАНО
– Если говорить только о продуктах, вроде Cortex Link и Cortex Play, что получает оператор «из коробки»?
В случае продуктов всё уже реализовано нашими инженерами и службой поддержки.Это наша облачная инфраструктура, в которой крутится софт, полностью автоматизировано развёртывание, настроены процессы масштабирования и мониторинга.
С точки зрения пользователя это выглядит просто: через API или веб-интерфейс он нажимает «создать точку» – и автоматически в облаке поднимается нужный инстанс, накатывается ПО, выполняется конфигурация, и сервис готов к работе.
Оператор управляет только сервисом, а не инфраструктурой.
BLUEPRINT: ВАШ DATA PLANE В ВАШЕМ ОБЛАКЕ
– Чем blueprint отличается от чистого продукта?
Логика похожа, но появляется дополнительная гибкость.
В blueprint-схеме control plane и портал могут жить у нас, а data plane, то есть функции обработки видео, мы можем развернуть в облаке заказчика или в его сегменте глобального облака.То есть все те же технологии Cortex и Virtual DCM работают уже не в «нашем» облаке, а в том окружении, которое оператор сам арендовал или контролирует.
СЛОЖНЫЕ РЕШЕНИЯ: MULTI-TENANT, ОБЩИЕ И РАЗДЕЛЁННЫЕ КОНТУРЫ
– А как выглядят самые сложные проекты?
Там вариантов очень много. Может быть единый control plane в режиме multi-tenant для группы клиентов, с последующим логическим разделением по заказчикам; общий customer-portal на нашей стороне, потому что биллинг и сводная аналитика мы должны контролировать сами.
А портал управления приложениями может быть как наш, так и полностью в аккаунте заказчика в его облаке. Здесь комбинации действительно очень разные: какие-то вещи мы держим у себя,
какие-то — полностью отдаём в контур клиента.
КТО ОПЕРИРУЕТ СИСТЕМОЙ
– Кто фактически управляет системой в разных моделях?
— В случае продуктов оперирует системой сам оператор. Synamedia сюда не вмешивается в ежедневную эксплуатацию, мы только предоставляем автоматизированную инфраструктуру и техподдержку.
В варианте blueprint оператор также сам конфигурирует сервисы. Но появляется опция: наши инженеры могут помогать в настройке, плюс можно подключить наш NOC для проактивного мониторинга.
В сложных решениях операционное управление всегда на стороне заказчика. Вся инфраструктура может быть полностью под его управлением. Но мы можем подключиться как партнёр: мониторить, предупреждать, консультировать.
Каждый такой проект уникален, и модель взаимодействия тоже каждый раз настраивается отдельно.
ТРЕУГОЛЬНИК: БЫСТРО, УПРАВЛЯЕМО, ЭКОНОМИЧНО
– Вы упомянули свою версию классической формулы «быстро, качественно и дёшево – выберите два». Как это выглядит в вашем случае?
У нас немного другая триада: быстро, управляемо и эффективно по цене.
Продукт – это самое быстрое решение, входной порог по цене минимальный,
– можно буквально за 5 минут организовать вещание канала или перегон. Но при этом продукт не рассчитан на нетиповые, сильно кастомные задачи — он даёт стандартизованный, предсказуемый функционал. Blueprint – это шаг в сторону управляемости и гибкости: чуть дольше по запуску, чуть сложнее по конфигурации, но гораздо лучше адаптируется под инфраструктуру и процессы конкретного оператора.
Сложные решения – это максимум управляемости и адаптации: архитектура под конкретную задачу, использование разных технологий и партнёров, оптимизация экономики под конкретный бизнес-кейс. Они требуют больше времени и большей проработки, но именно в этом сегменте мы вместе с заказчиком можем выжать максимум из технологий, бюджета и тех ограничений, в которых он живёт.
– То есть логика такая: хочешь быстро попробовать – бери продукт; хочешь свой контур и контроль – blueprint; хочешь «идеально под себя» – идём в кастомные решения?
Да, примерно так. Главное, что у оператора есть выбор. Мы же можем работать во всех трёх форматах, в зависимости от того, на какой стадии он сейчас находится и какие задачи реально нужно решать.
Окей, давай сделаем аккуратное, «журнальное» редактирование без воды и повторов. Вот переработанный фрагмент про blueprint и резервирование как нормальное интервью с подзаголовками.
Продукты, blueprint и кастомные решения
– Если стандартного продукта уже не хватает, что дальше?
Тогда мы переходим к формату blueprint. Продукт – это готовое решение: быстро, недорого, но без глубокой кастомизации. Если нужно «взять и поехать» – это самый простой вариант, за пять минут можно запустить канал или перегон.
Blueprint стоит дороже, но позволяет адаптировать базовое решение под заказчика: добавить нужные опции, учесть особенности сети, подстроить архитектуру.
Если и этого недостаточно, переходим к сложным (кастомным) решениям. Это уже небыстро: анализируем задачу, проектируем архитектуру вместе с заказчиком, доводим до результата, который точечно закрывает его требования.
Зато в итоге система работает ровно так, как нужно конкретному оператору.
Требования к резервированию: спорт и «обычное» вещание
– Насколько разные бывают требования к резервированию?
Очень разные. У одного и того же оператора могут быть каналы, у которых даунтайм недопустим вообще (спорт, прямые трансляции). И каналы, где остановка на минуту–две некритична (сериалы, плейлистовый контент).
Для футбольного матча даже минутный перерыв – катастрофа. Для линейного канала с сериалами – это неприятно, но переживаемо. Под эти сценарии мы и подбираем тип резервной головной станции в облаке.
Три уровня резервной головной станции в облаке
– Какие варианты резервной головной станции вы выделяете?
Мы используем три основных модели:
- Холодный резерв (cold standby)
- Резерв в режиме ожидания (standby)
- Тёплый резерв (warm)
И отдельно – актив–актив.
Холодный резерв: поднять с нуля за 15 минут
– Что такое «холодный» вариант?
В холодном режиме резервной станции как таковой в этот момент нет. У нас есть: сохранённая конфигурация, API для автоматического развёртывания.
При аварии мы автоматически копируем конфигурацию с основной системы, поднимаем инфраструктуру в облаке, накатываем софт и запускаем сервис. В результате резервный хедэнд может быть поднят с нуля примерно за 15 минут. Это подходит тем, для кого такой даунтайм приемлем.
Режим ожидания: запустить за несколько минут
– Чем отличается резерв в режиме ожидания?
В standby-режиме резервная головная станция уже развернута. Все входящие каналы заведены и мониторятся – мы заранее знаем, что сигнал на входе есть. В момент аварии мы только запускаем нужные сервисы, и переключение занимает уже не 15 минут, а считаные минуты.
Тёплый резерв: сначала низкий битрейт, потом масштабирование
– А тёплый резерв?
Тёплый резерв нужен там, где важна очень быстрая реакция, но при этом есть желание экономить на облаке.
Схема такая:
– мы мониторим все входы,
– заранее транскодируем только самый низкий профиль ABR,
– не гоняем полный набор битрейтов во втором контуре.
В случае аварии:
– мгновенно переключаем вещание на резерв,
– пользователь сразу получает картинку в низком качестве,
– система автоматически масштабируется и за примерно минуту поднимает остальные профили.
То есть зритель не остаётся без картинки вообще, а качество дорастает вслед за масштабированием.
Active–active: полное дублирование
– Когда нужен актив–актив?
Active–active – это полный дубль.
Обе головные станции работают параллельно:
– все входы мониторятся в двух контурах,
– все сервисы активны в обоих окружениях,
– есть возможность мгновенного переключения без потери сервиса.
Это самый дорогой, но и самый надёжный вариант. Его выбирают там, где цена ошибки максимальна – прежде всего для топового спорта и премиальных событий.
