Архитектура и оркестрация multi-CDN

Кратко

Архитектура multi-CDN доставляет ваше видео сразу через две и более сети доставки контента (CDN), а слой оркестрации – движок решений плюс steering-сервис – выбирает, какая сеть обслужит каждого зрителя, исходя из текущей производительности, доступности и цены. К ней приходят потому, что один CDN – это два риска в одной обёртке: единая точка отказа, которая роняет весь каталог в свой плохой час, и единственный вендор, у которого нет повода точить цену. Современный, стандартный способ переключать зрителей между сетями прямо в потоке – это content steering, описанный для HTTP Live Streaming (HLS) во втором издании его спецификации и для MPEG-DASH в ETSI TS 103 998: маленький JSON-файл, который игрок перечитывает каждые несколько минут и который перечисляет сети по приоритету. Статья объясняет простым языком, что именно решает слой оркестрации, три способа переключать сети, как система измеряет, какой CDN лучше, какая математика доступности и цены оправдывает все эти усилия, и главную ловушку, в которую попадает большинство команд: сплит трафика между сетями тихо разбавляет тот самый кэш, который и сделал доставку дешёвой.

Почему это важно

Если вы ведёте стриминговый продукт, CDN – это и причина гладкой картинки у зрителя, и крупнейшая регулярная строка в счёте за доставку, а решение «весь трафик через одного провайдера» вы принимаете один раз, а платите за него при каждом сбое и каждом продлении контракта. Плохой день у единственного CDN – не гипотеза: когда в октябре 2025 крупный облачный провайдер дал сбой, платформы с одной сетью доставки не могли сделать ничего до устранения аварии, а те, у кого была вторая сеть, переключились и остались в строю. Статья – для основателя, продакт-менеджера или стримингового CTO, который решает, стоит ли усложнение из двух-трёх сетей того, и которому нужно понимать слой оркестрации достаточно, чтобы говорить с вендорами и инженерами, а не покупать чёрный ящик. К концу вы сможете задать пять вопросов, которые определяют дизайн multi-CDN: как мы переключаемся, что измеряем, как ведёт себя failover, что сплит делает с нашим cache-hit ratio и достаточно ли вообще велик наш трафик, чтобы всё это оправдать.

Один CDN – это два риска в одной обёртке

Начнём с того, зачем вообще держать больше одной сети: затраты на multi-CDN реальны, и платить за них стоит только ради реальной причины.

Сеть доставки контента – глобальный парк кэширующих серверов, сокращённо CDN, который держит копии вашего видео рядом со зрителями – это инфраструктура одной компании. Как устроена одна такая сеть от начала до конца, мы разобрали в статье как CDN доставляет видео. Когда вы направляете свой стриминговый хостнейм на одного провайдера, вы наследуете два его свойства, хотите вы того или нет.

Первое: он становится единой точкой отказа – тем компонентом, чей сбой роняет всё, что ниже по цепочке. CDN строятся ради отказоустойчивости: внутренние health-проверки и автоматическая перемаршрутизация внутри своей сети, и хороший CDN держит порядка 99,9% доступности. Но 99,9% – это не 100%: недостающая десятая доля процента – это около 8,8 часов недоступности в год, и приходят они не вежливо размазанными по тихим ночам. Региональный обрыв оптики, кривой деплой конфигурации, спор с транзитным провайдером или DDoS-атака могут на час уронить или просадить целый регион одного CDN – и если это ваша единственная сеть, ваша платформа в этом регионе на этот час тёмная, ровно во время премьеры, которую не переиграть.

Второй риск тише и стоит вам каждый месяц: один CDN – это ценовая ловушка. Доставка через CDN продаётся по байтам, отданным зрителям – регулярная плата, называемая egress, – и это доминирующая постоянная статья расходов стриминговой платформы, которую мы разбираем в cost engineering для CDN. У вендора, который знает, что он ваш единственный вариант и что уход от него означает перетестирование всей доставки, мало причин давать вам лучшую ставку. Рычаг, который сбивает цену egress – достоверная способность завтра увести трафик в другое место – существует только если это «другое место» уже подключено.

Multi-CDN – это архитектура, которая снимает оба риска разом: доставляйте через несколько сетей и поставьте впереди слой решений, который отправляет каждого зрителя в сеть, которая прямо сейчас жива, быстра и разумна по цене. Через всю статью повторяется одна фраза – направлять в лучшую доступную: контент уходит в ту сеть, что для этого зрителя в этот момент здоровее и дешевле.

Что на самом деле значит multi-CDN

Термин употребляют вольно, так что зафиксируем. Есть две вещи, которые называют multi-CDN, и сложна только одна.

Простой вариант – статический сплит: вы отдаёте Европу в CDN A, а Азию в CDN B, потому что у каждого там лучше присутствие, и распределение почти не меняется. Это полезно – решает покрытие и ёмкость – и это чуть больше, чем два контракта и правило маршрутизации. Как формулируют инженеры доставки Amazon, в такой ситуации «балансировка между CDN довольно проста и статична».

Сложный, интересный вариант – тот, о котором эта статья – это динамический multi-CDN: балансировка трафика между сетями по их мгновенной производительности и цене, так что когда edge CDN A во Франкфурте проседает в час пик, зрители там за секунды уходят на CDN B, а когда CDN B в этом месяце дешевле для бразильского длинного хвоста, этот трафик смещается к нему. Это и есть вариант, которому нужен слой оркестрации, и существует он ради четырёх целей, примерно в таком порядке по тому, как часто они оправдывают сборку:

Первая – отказоустойчивость: пережить плохой час любой одной сети, держа наготове другую. Вторая – производительность: в любой момент какой-то CDN самый быстрый в конкретном городе, и это не всегда один и тот же CDN, так что направление в текущий лучший поднимает ваш QoE. Третья – ёмкость: на очень больших масштабах одно live-событие может потребовать в одном регионе больше ёмкости доставки, чем выделит любой один CDN, так что её берут у нескольких. Четвёртая – коммерческий рычаг: две сети позволяют смешивать трафик так, чтобы добивать у каждой скидку за объём-коммит и уводить дорогие регионы тому, кто дешевле, и держат обоих вендоров в тонусе при продлении.

Нажмите, чтобы увеличить

Обратите внимание, что НЕ меняется. За CDN у вас по-прежнему один origin – авторитетный источник файлов – обычно прикрытый origin shield, средним кэшем, который защищает его от толпы; об этом – статья origin и origin shield. Multi-CDN умножает сети доставки перед shield; он не умножает ваш origin. Эта одна деталь рождает и главную выгоду (origin питает много сетей из одной мастер-копии), и главную скрытую цену (каждая сеть держит свой кэш, так что ваш контент приходится кэшировать по нескольку раз – проблема разбавления, к которой мы вернёмся).

Слой оркестрации: кто решает, какой CDN обслужит запрос

Ключевое слово в «оркестрации multi-CDN» – решает. Два и более CDN – это просто два контракта; архитектура – это слой, который решает для каждого зрителя или каждого запроса, какую сеть использовать, и продолжает решать по мере изменения условий.

У этого слоя две части, и держать их раздельно – значит сделать всю тему понятной.

Первая часть – движок решений: логика, которая оценивает доступные сети и ранжирует их. Он принимает сигналы (какой CDN быстр в этом городе прямо сейчас, какой жив, какой под своим коммитом по цене, какой оператор хочет здесь предпочесть или избежать) и выдаёт упорядоченный список предпочтений: для этого зрителя – сначала CDN B, потом CDN A, потом CDN C. Движок может жить в трёх местах – сторонний сервис, ваш сервер или сам игрок – и где он живёт, это ровно тот выбор, который разбирает следующий раздел.

Вторая часть – механизм steering: как это ранжированное предпочтение реально доходит до игрока и меняет, из какой сети он тянет. Ранжирование, по которому никто не может действовать, бесполезно; механизм steering – это провод от решения к байтам.

Нажмите, чтобы увеличить

Думайте о слое оркестрации как о диспетчере для ваших байтов. Самолёты (зрители) могут сесть в нескольких аэропортах (CDN). Диспетчер следит за погодой и загрузкой полос (производительность и нагрузка), знает, какой аэропорт сколько берёт за посадку (цена), и говорит каждому самолёту, какой аэропорт использовать – и перенаправляет его прямо на подлёте, если первый выбор закрылся. Диспетчер не пилотирует самолёты и не владеет аэропортами; он лишь решает и сигналит. Это в точности работа слоя оркестрации: он никогда не трогает сами байты видео, он лишь решает, какая сеть их доставит.

Три способа переключать сети

Есть три места, где решение о переключении можно принять и привести в действие, и они меняют контроль на скорость реакции. Большинство реальных платформ используют комбинацию. Вот они от старого к новому.

Первый – переключение на уровне DNS, изначальный подход. Вспомним: когда игрок хочет видео, он сперва ищет адрес для вашего стримингового хостнейма; multi-CDN-сервис на уровне DNS отвечает на этот запрос адресом того CDN, который он сейчас предпочитает для этого зрителя. Сервисы вроде NS1, Amazon Route 53 и Citrix Intelligent Traffic Management – продукт, выросший из сети real-user-measurement Cedexis, которую Citrix купил в 2018-м, теперь часть NetScaler – работают так: они сидят в шаге разрешения имени, до установления соединения, и выдают зрителю выбранный CDN. Сила – в простоте и в том, что это работает для любого контента, не только адаптивного видео. Слабость – в грануляции и скорости: ответ DNS кэшируется на свой time-to-live (часто 60 секунд и больше), решение принимается один раз на сессию в начале, и оно довольно грубое – двигает зрителя, а не отдельный сегмент, и не может среагировать на сеть, просевшую через две минуты потока.

Второй, и тот, что стоит понять глубже – content steering: метод переключения прямо в потоке, встроенный в оба формата адаптивного стриминга и являющийся стандартным ответом на грубость DNS. Поскольку это современный дефолт и спецификация, которую большинство понимает неверно, ему посвящён следующий раздел.

Третий – переключение на стороне клиента (децентрализованное), где сам игрок держит список CDN и логику решения, измеряет условия со своей точки и переключается, не спрашивая сервер. Это реагирует быстрее всего и не требует обращения к серверу, но кладёт бизнес-логику в код игрока на каждом устройстве – веб, iOS, Android и парк ТВ и приставок – так что каждое изменение правил переключения означает обновление и перевыпуск множества сборок. Streaming Video Technology Alliance аккуратно описывает спектр как централизованный (один сервис или манипуляция манифестом на стороне оператора делает всё), централизованно-децентрализованный (игрок выбирает из заранее заданного списка CDN по сторонней аналитике от вендора вроде Mux, Conviva или NPAW) и полностью децентрализованный (игрок решает по своим данным). Content steering – это стандартизированная середина: игрок действует, но логику держит сервер.

Нажмите, чтобы увеличить

Таблица 1. Три метода переключения: где каждый принимает решение и как быстро может среагировать. Реальные платформы их сочетают – например, DNS для грубого регионального распределения и content steering для коррекции в потоке. Оговорка «поддержка?»: content steering помогает только на игроках, которые его реализуют; ТВ-приложение на старом рантайме может требовать путь DNS или клиента.

Content steering: стандартный способ переключаться в потоке

Content steering стоит понять точно – потому что это та часть multi-CDN, которая наконец-то получила стандарт, и потому что популярные обзоры размывают, что это такое.

Вот версия простым языком. Ваше видео описывается игроку манифестом – маленьким индексным файлом, который перечисляет доступные уровни качества и URL сегментов. Content steering добавляет в этот манифест одну строку, указывающую на steering-сервер, и группирует варианты доставки в pathways (пути), где каждый pathway на практике – это один CDN. Игрок периодически забирает со steering-сервера крошечный JSON-файл – steering-манифест – который перечисляет pathways по приоритету. Игрок использует первую сеть в списке; если та начинает сбоить, игрок помечает её как оштрафованную и спускается к следующей; и каждые несколько минут он перечитывает список, потому что steering-сервер мог переранжировать сети. Видео при всём этом продолжает играть – переключение это лишь смена хоста, с которого тянется следующий сегмент.

Механизм задан форматом, и назвать спецификацию важно, потому что детали нормативны. Для HLS content steering – часть спецификации HTTP Live Streaming (второе издание, опубликовано в 2026-м, наследует RFC 8216): мультивариантный плейлист несёт тег EXT-X-CONTENT-STEERING с SERVER-URI, указывающим на steering-сервер, а каждый вариантный поток несёт PATHWAY-ID, привязывающий его к CDN. Для MPEG-DASH content steering стандартизирован как ETSI TS 103 998 (версия 1.1.1, январь 2024), разработанный DASH Industry Forum поверх стандарта DASH ISO/IEC 23009-1; манифест (MPD) несёт элемент ContentSteering и помечает каждый BaseURL атрибутом serviceLocation с именем его CDN, плюс необязательный queryBeforeStart, велящий игроку спросить steering-сервер ещё до старта. Сам кросс-форматный steering-манифест – тот JSON, что перечитывает игрок – описан в общей спецификации автором HLS, Роджером Пантосом из Apple, сейчас это информационный Internet-Draft (draft-pantos-content-steering, последняя ревизия – март 2026); это ещё не консенсус-стандарт IETF, так что относитесь к форме JSON как к стабильной-но-меняющейся и перепроверяйте перед сборкой.

Steering-манифест достаточно мал, чтобы показать целиком. Прочитанный прямо из спецификации, вот он весь:

{
  "VERSION": 1,
  "TTL": 300,
  "RELOAD-URI": "https://steering.example.com/v1?session=abc123",
  "PATHWAY-PRIORITY": [
    "cdn-a",
    "cdn-b"
  ]
}

Работают четыре поля. VERSION – версия формата. TTL – сколько секунд игрок должен подождать перед новым запросом; спецификация рекомендует 300 секунд (пять минут), и сервер может варьировать его по клиенту, чтобы размазать свою нагрузку. RELOAD-URI – куда спрашивать в следующий раз, и он может нести session-токен, чтобы steering-сервер знал, кто спрашивает. PATHWAY-PRIORITY – ранжированный список: здесь игрок должен предпочесть cdn-a и откатиться к cdn-b. Когда сервер хочет сдвинуть трафик, он просто переупорядочивает этот массив при следующем запросе, и игроки мигрируют в течение следующих нескольких минут, по мере истечения их TTL. Есть даже механизм PATHWAY-CLONES, позволяющий steering-серверу ввести совершенно новый CDN на лету – клонируя существующий pathway и переписывая его хостнейм – не трогая исходный манифест; так операторы добавляют сеть посреди события.

Две вещи делают это правильным дефолтом. Первое: логика живёт на сервере – чтобы изменить поведение переключения, вы правите то, что возвращает один steering-сервер, а не код игрока на тысяче моделей устройств. Второе: это обратно совместимо – игрок, не понимающий тег steering, просто игнорирует его и играет со своей сети по умолчанию, так что добавление steering не ломает старые клиенты. Протокольные внутренности – как оценка битрейта игрока питает steering-запрос, как настраивается тайминг штрафа – это глубокая тема, которую мы разбираем в глубоком разборе multi-CDN раздела Video Streaming; здесь вывод в том, что решение слоя оркестрации доходит до игрока как переупорядоченный список, который тот перечитывает по таймеру.

Как система измеряет, какой CDN лучше

Движок решений хорош ровно настолько, насколько хороши его сигналы. «Какой CDN лучше прямо сейчас» – это задача измерения, и есть четыре вида измерений, у каждого своё смещение, о котором стоит знать до того, как ему довериться.

Первый – community real-user measurement (RUM): данные о производительности, собранные с реальных браузеров на множестве сайтов; этот датасет первой собрала Cedexis (теперь Citrix ITM), запустив маленький JavaScript-зонд на популярных сайтах, который замеряет, как быстро каждый CDN отдаёт тестовый объект. Он широк и прост в потреблении, и хорош для отслеживания тренда производительности CDN. Но, как предупреждают инженеры доставки Amazon, он несёт два смещения при сравнении CDN для вашего сервиса: методологическое (он мерит маленькие горячие объекты около 100 КБ, тогда как ваше видео – смесь крупных тёплых и холодных сегментов) и конфигурационное (измеряемая конфигурация CDN – не ваша). Community RUM показывает погоду над городом, а не полосу, на которую вы сейчас садитесь.

Второй – private RUM: та же идея, но измеряет вашу доставку: зонд, замеряющий пропускную способность и доступность по вашим реальным хостнеймам CDN на объектах ближе к вашим сегментам (500 КБ и выше). Он репрезентативнее и есть правильный вход для алгоритма переключения, ценой того, что его надо запускать самому.

Третий, и самый честный относительно того, что зритель реально чувствует – player quality-of-experience (QoE) телеметрия: агент внутри вашего игрока, сообщающий метрики, которые отображают боль зрителя: startup time, долю ребуферинга и реально отданный битрейт. Построенная самостоятельно или взятая у вендора вроде Mux, Conviva или NPAW, она мерит ваш контент, на устройствах ваших зрителей, по сетям, которыми те реально пользуются. Её слабость – зеркало силы community RUM: в регионе с малым числом зрителей точек данных может не хватить для надёжного решения, и именно там community RUM закрывает пробел. Эту телеметрию мы разбираем в статье наблюдаемость доставки.

Четвёртый – операционные данные от самих CDN: логи ошибок и производительности в реальном времени, которые предоставляют сами сети. Легко представить CDN пассивными сетями, между которыми оператор тасует трафик, но хороший провайдер – активный участник: во время live-события его логи реального времени позволяют триангулировать проблему с вашими данными игрока и подтвердить, что сеть восстановилась, прежде чем вернуть на неё трафик.

Практичный дизайн – смешивать их. Player QoE – правда о том, что чувствует зритель; private RUM даёт цифры качества сети там, где зрителей мало; community RUM покрывает длинный хвост; логи CDN подтверждают и объясняют. Движок решений оценивает сети из этой смеси и переранжирует их с какой-то частотой – а пятиминутный TTL steering-манифеста есть та скорость, с какой эти переранжирования доходят до игроков.

Математика вслух: доступность и цена

Multi-CDN оправдывают два числа, и оба стоит проговорить медленно, так, как реально движутся байты и доллары.

Начнём с доступности, измеряемой в «девятках». Один CDN при 99,9% доступности – три девятки – недоступен 0,1% года:

простой (1 CDN) = 0,001 × 8 760 часов/год
                = 8,76 часа/год

Теперь добавим второй, независимый CDN, способный отдать тот же контент, с failover достаточно быстрым, чтобы зритель проехал переключение. Платформа лежит, только когда обе сети лежат одновременно. Будь их сбои по-настоящему независимы, совокупная недоступность – это произведение двух:

совокупная недоступность = 0,001 × 0,001
                         = 0,000001  (т.е. 99,9999% — шесть девяток)
простой (2 CDN) ≈ 0,000001 × 8 760 ч ≈ 31 секунда/год

Эти шесть девяток – теоретический потолок, и обещать их не стоит, потому что реальные сбои не вполне независимы: два CDN могут делить вышестоящего транзитного провайдера, оба могут питаться от одного страдающего origin, может отказать сам steering-сервер, и failover никогда не мгновенен. Эти корреляции и само переключение тянут реальный результат вниз, примерно до четырёх девяток – около 99,99%, или 52 минут простоя в год. Но четыре девятки против трёх – это всё ещё 10-кратное сокращение времени простоя, и разница между «мы потеряли регион на всю премьеру» и «зрители увидели пару секунд буферизации, пока мы перенаправляли». Этот разрыв – кейс отказоустойчивости в одну строку.

Теперь цена. Перенесём рабочий пример из как CDN доставляет видео: сервис среднего размера, отдающий зрителям около 2,25 петабайта (ПБ) – 2 250 000 ГБ – в месяц. Пусть один CDN на pay-as-you-go-смеси по вашим регионам стоит эффективно $0,020 за ГБ:

egress на одном CDN = 2 250 000 ГБ × $0,020/ГБ
                    = $45 000 / месяц

Multi-CDN бьёт по этому счёту двумя путями. Первый – блендинг под коммит: каждый CDN круто скидывает, как только вы коммитите месячный объём, так что сплит трафика, добивающий коммит-тарифы двух провайдеров, покупает ставку ниже, чем счёт «частично-коммит-частично-burst» одного провайдера. Второй – региональное ценовое steering: премиальный CDN может брать в Азиатско-Тихоокеанском регионе и Южной Америке в два-три раза больше, чем в Северной Америке, так что этот дорогой хвост вы уводите в региональную сеть, которая там дешевле. Смешайте оба, и эффективная ставка около $0,014 за ГБ реалистична – публичные mid-market-ставки CDN идут примерно $0,01–$0,04 за ГБ после переговоров, так что это в диапазоне:

egress на multi-CDN = 2 250 000 ГБ × $0,014/ГБ
                    = $31 500 / месяц
экономия            = $45 000 − $31 500 = $13 500 / месяц
                    ≈ 30% ≈ $162 000 / год

Сокращение на 30% точно внутри диапазона 25–40%, который, как сообщается, даёт оптимизация цены через multi-CDN, когда дорогие регионы уводятся к альтернативным провайдерам. Долларовые цифры иллюстративны и устаревают – ставки за ГБ договорные, региональные и меняются – так что относитесь к методу как к уроку, а не к точным числам, и моделируйте свои в статье cost engineering для CDN. И учтите одно честное вычитание, которое уточняет следующий раздел: сплит трафика может снизить ваш cache-hit ratio, что поднимает трафик к origin, так что истинная экономия – это выигрыш egress минус потеря offload.

Нажмите, чтобы увеличить

Ловушка, о которой молчат: multi-CDN разбавляет кэш

Вот цена, которую опускает вендорская презентация, и причина, по которой multi-CDN – не бесплатные деньги.

В статье как CDN доставляет видео мы показали, что стриминг дёшев из-за offload ratio – доли байт, отданных из кэша CDN, а не забранных из вашего origin – и что один популярный сегмент, закэшированный на edge один раз, может обслужить тысячи зрителей. Эта экономия держится на том, что зрители сходятся к одной кэшированной копии. Multi-CDN работает ровно против этого схождения.

Когда вы делите аудиторию тайтла на три сети, каждая сеть вынуждена кэшировать этот контент независимо. Первый зритель сегмента на CDN A вызывает запрос к вашему origin, чтобы заполнить кэш CDN A; первый зритель того же сегмента на CDN B вызывает второй запрос, чтобы заполнить кэш CDN B; CDN C – третий. Как прямо говорят инженеры Amazon, распределение трафика по нескольким CDN «снижает глобальный cache hit ratio», потому что вашему трафику теперь приходится наполнять несколько кэшей вместо одного. Эффект хуже всего для каталогов с длинным холодным хвостом – VOD и линейное ТВ, где многие тайтлы каждый смотрит относительно немного людей – и мягче всего для горячего live-события, где все хотят один и тот же сегмент в одну и ту же секунду на той сети, на которой они есть.

Это и есть напряжение в сердце экономики multi-CDN: экономию egress от ценового steering может частично съесть рост origin-egress от разбавленного кэша. Защиты конкретны. Держите origin shield перед origin, чтобы промахи нескольких CDN схлопывались об один средний кэш, а не штурмовали ваш origin – тот же shield из origin и origin shield, теперь работающий вдвойне. Не дробите чрезмерно: две хорошо выбранные сети обычно ловят большую часть отказоустойчивости и рычага с куда меньшим разбавлением кэша, чем пять. И взвешивайте сплит по типу каталога – горячее live-событие терпит агрессивный multi-CDN; глубокая VOD-библиотека с холодным хвостом хочет более консервативного сплита. Урок прошлой статьи держится здесь с удвоенной силой: offload ratio – это число, которое определяет маржу доставки, и multi-CDN – один из немногих архитектурных выборов, способных тихо двинуть его не туда.

Частая ошибка: «давка переключения» и ловушка панацеи

Самые вредные ошибки multi-CDN – не в проводке; они в вере, что переключение умнее и целебнее, чем оно есть.

Первая – давка переключения (switch stampede). Представьте навигатор, который видит пробку впереди и велит вам свернуть на следующем съезде – и велит то же самое всем остальным в тот же миг, так что объезд встаёт так же, как и дорога. Наивный multi-CDN делает ровно это: CDN A проседает, система разом переводит всех затронутых зрителей на CDN B, и теперь CDN B – рассчитанный на свою обычную долю – завален двойной нагрузкой и проседает тоже. Лекарство – относиться к переключению как к балансировке, а не выключателю: сдвигайте трафик отмеренными долями, следите за запасом целевой сети и примите, что CDN, выигрывающий на волосок в один миг, не повод слать ему всё. Хорошая оркестрация наращивает; она не сваливает.

Вторая – ловушка панацеи: использование переключения CDN как первого ответа на любую проблему доставки. Смена сети ничего не даёт проблеме, которая живёт в самом потоке: кривой манифест, плохой cache key, дробящий один сегмент на тысячи копий на зрителя (см. кэширование на edge, cache keys и токенизированные URL), или страдающий ISP, через которого пирится каждый CDN в этом регионе. Если корень выше CDN, перевод трафика между ними лишь переставляет симптом. Как формулирует Streaming Video Technology Alliance, multi-CDN «не панацея от проблем доставки» – это один инструмент в стратегии доставки, и сидит он поверх настоящего диагноза, а не вместо него.

Три меньших ловушки идут с этими. Минимальный общий знаменатель по фичам: ваша платформа может использовать только те фичи, что все ваши CDN поддерживают одинаково, так что умная оптимизация на одной сети может оказаться вне игры, как только вы добавите вторую без неё. Расхождение токен-авторизации: каждый CDN защищает URL своей схемой токенов, так что зритель, переведённый с одной на другую, может быть отвергнут, если ваши токены не работают на обеих – индустриальное лекарство, Common Access Token, стандартизируемый SVTA и CTA-WAVE, нацелен ровно на это. И цена самого решения: анализ данных, питающий умное переключение, не бесплатен, и система, тратящая на анализ «какой CDN дешевле» больше, чем экономит переключением, упустила суть. Каждая из этих ловушек переживаема при проектировании; ни одна не всплывает на демо вендора.

Когда multi-CDN оправдан – и когда правильный ответ один CDN

Поскольку затраты реальны, честный дефолт для новой или средней платформы – один хорошо настроенный CDN с origin shield, а не multi-CDN. Один зрелый CDN уже направляет зрителей в свой лучший PoP, перенаправляет вокруг своих сбоев внутри сети и даёт три девятки доступности – достаточно для большинства продуктов, и без накладных расходов на управление вендорами, без минимального общего знаменателя по фичам и без разбавления кэша.

Multi-CDN отрабатывает своё усложнение, когда верно одно или несколько из этого. Вы работаете на масштабе петабайт в месяц, где один CDN не может выделить нужную региональную ёмкость под пиковые события и где штраф за разбавление кэша мал относительно ценового рычага. Доступность контрактна – вы подписали SLA или ваш контент live и неповторим (спорт, финал), так что цена плохого часа одной сети мерится оттоком и компенсациями. Ваша аудитория по-настоящему глобальна и охватывает регионы, где ни один CDN не лучший везде. Или ваш счёт за egress велик настолько, что экономия 25–40% через ценовое steering превышает стоимость самой оркестрации. Если ничего из этого не верно, вторая сеть – это сложность, за которую вы платите, не используя её – а добавление её может даже внести новую точку отказа (слой steering) в систему, которой она была не нужна. Правильная архитектура – простейшая из тех, что удовлетворяют вашим требованиям по отказоустойчивости, охвату и цене – для многих платформ это один CDN, и дисциплина в том, чтобы знать, когда вы реально перешли черту нужды в двух.

Где здесь Фора Софт

Архитектура multi-CDN – это решение о масштабе прежде, чем техническое: она окупается на петабайтных объёмах, глобальном охвате и контрактной доступности, а ниже этой черты – это сложность без отдачи, так что первая задача – решить, перешли ли вы черту вообще. Фора Софт с 2005 года строит видеостриминг, OTT/Интернет-ТВ, e-learning, телемедицину и видеонаблюдение – 250+ выпущенных проектов для 400+ клиентов – и эта работа центрируется ровно на такой инженерии масштаба и цены: оценить, подходит ли платформе один CDN или несколько под её аудиторию и бюджет, развести слой steering, который наращивает трафик, а не сваливает его, держать origin shield впереди, чтобы сплит multi-CDN не убил offload ratio, и заставить токенизированный доступ работать между сетями, чтобы переведённый зритель никогда не оказался заблокирован. Когда медиакомпании нужен дизайн доставки, чья доступность и счёт за egress оба переживают реальную, растущую, глобальную аудиторию, эту инженерию оркестрации мы и приносим.

Главное

• Один CDN – единая точка отказа и ценовая ловушка; multi-CDN снимает обе.
• Динамическому multi-CDN нужен слой оркестрации: движок решений плюс механизм steering.
• Три способа переключаться: DNS (на сессию), content steering (в потоке, стандарт), клиент (мгновенно).
• Content steering – маленький JSON-список приоритетов, который игрок перечитывает каждые ~5 минут.
• Сплит трафика разбавляет кэш каждого CDN, поднимая origin egress – вычитайте это из экономии.
• Ниже петабайтного масштаба правильный ответ обычно – один настроенный CDN с origin shield.

Что почитать дальше

• Как CDN доставляет видео: origin, edge и кэш
• Cost engineering для CDN: egress, коммиты и 95-й перцентиль
• Origin и origin shield