Multi-CDN: архитектура, экономика и режимы отказа

TL;DR

Multi-CDN-архитектура – это стек доставки видео, в котором трафик одновременно распределяется между двумя и более Content Delivery Network (CDN), так чтобы один и тот же закэшированный объект мог отдаваться тем провайдером, который прямо сейчас быстрее, дешевле или просто остаётся живым. У архитектуры три разновидности, которые выглядят одинаково, а ведут себя совершенно по-разному: steering на уровне DNS (медленно, просто, в 2026 году не рекомендуется никем, но используется всеми), client-side steering со статическим манифестом (быстрее, но настолько же умное, насколько умён сам плеер), и standards-based content steering на базе Apple HLS Content Steering и ETSI / DASH-IF Content Steering для DASH, где плеер посреди сессии скачивает небольшой JSON и узнаёт, какой CDN использовать для следующего сегмента. История с деньгами – то, что чаще всего недооценивают: multi-CDN сам по себе не экономит – он экономит только тогда, когда коммиты выставлены под базовую нагрузку каждого провайдера, overage-условия переговорены против этого базового объёма, а 95-й перцентиль считается по каждому CDN отдельно, а не как один общий счёт. Режимы отказа конкретны и повторяются: агрессивный failover, пинг-понгом перебрасывающий зрителей между двумя нездоровыми краями; кэш DNS, держащий мёртвый edge ещё 15 минут после того, как дашборды покраснели; sticky-сессии, которые держатся достаточно долго, чтобы сломаться; и налог фрагментации кэша, превращающий 95% hit ratio в 60%, когда один сегмент лежит на двух origin'ах дважды. Эта статья проходит архитектуру, математику и режимы отказа – и заканчивается одностраничным чек-листом миграции, который можно передать архитектору перед следующим live-эфиром.

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

Большинство продуктовых команд берёт «давайте использовать multi-CDN» со слайда конференции, где соратник на встрече сказал, что это улучшило доступность или урезало счёт. Иногда это правда, иногда нет, и разница – в выборе архитектуры и условиях контракта, ни одного из которых на слайде не было. Плохо сделанный multi-CDN хрупче single-CDN, стоит дороже и приводит к разборам инцидентов с фразами «во время финала ЧМ мы переключились со здорового провайдера на деградирующий». Хорошо сделанный multi-CDN – обычно на HLS / DASH Content Steering по состоянию на 2026 – оправдывает себя на каждом live-событии и сбривает повторяющийся процент с месячного счёта. Эта статья – мост между слайдом и решением. Продакт-менеджер заканчивает её с возможностью спросить «какой у нас слой steering и по какому критерию failover?», не блефуя. Архитектор – с четырёхкомпонентным блюпринтом, картой возможностей по вендорам и чек-листом миграции. Лид эксплуатации – с каталогом режимов отказа и раннбуком для тестирования. В арифметике в конце показана повторяющаяся экономия на типовой нагрузке 10 PB в месяц и во что она испаряется, если перепутана одна строчка контракта.

Что такое multi-CDN, аккуратно

Начнём с определения. Single-CDN-архитектура отправляет каждый сегментный запрос одному провайдеру – один и тот же Akamai, Cloudflare, Fastly, CloudFront или Google Media CDN отвечает за ingest закэшированного объекта с origin, иерархию кэшей между origin и edge, и доставку на последнюю милю до плеера. Multi-CDN-архитектура публикует один и тот же контент параллельно через двух и более провайдеров и добавляет слой steering, который решает, на сессию или на зрителя, кто из провайдеров обслужит следующий запрос. Origin почти во всех реальных развёртываниях остаётся один; умножается путь между origin и зрителем.

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

Диспетчер – это то, что в литературе по стримингу называют traffic steering или CDN selection, и именно там живёт весь сюжет multi-CDN. Всё, что ниже – DNS, content steering, client-side, server-side, гибрид – это способ построить диспетчерскую.

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

Зачем вообще берут multi-CDN (три реальных причины)

Маркетинговая подача обычно говорит «отказоустойчивость, производительность и стоимость». Честный список короче и конкретнее.

Причина 1 – пережить отказ уровня CDN. Ни у одного крупного CDN нет идеальной истории. У AWS CloudFront была существенная multi-region-деградация в конце 2023; у Cloudflare – громкие инциденты в 2022 и 2023; падения edge-узлов Akamai и глобальный outage Fastly от 8 июня 2021 – достаточно свежи, чтобы помнить. Стриминговый продукт, гаснущий вместе с одним провайдером, в плохом коммерческом положении – возвраты по pay-per-view, нарушения SLA вещания, оптика в соцсетях – и «у нас есть CDN» больше не работает как защита перед финансовым комитетом, который читал post-mortem Fastly. Первая и наиболее защищаемая причина перейти на multi-CDN – пережить день, в который у одного из CDN случится региональный или глобальный инцидент.

Причина 2 – обогнать региональную производительность любого одного CDN. Никто не быстрейший везде. Akamai часто выигрывает на маршрутах вещания в зрелых рынках. Cloudflare часто выигрывает на потребительских рынках со средней задержкой, где у их anycast-сети плотное присутствие. Fastly выигрывает на developer-нагрузках и мгновенных purge. Google Media CDN выигрывает там, куда пиринговое наследие YouTube доходит туда, куда другие CDN – только через транзит. Архитектура multi-CDN, выбирающая правильного провайдера на регион и зрителя, может давать измеримо меньший rebuffering, чем лучший single-CDN из вашего контрактного списка. Литература по content steering реального времени – и DASH-IF Implementation Guidelines, и академические работы на Mile-High Video Conference – оценивает выигрыш в единицах процентов в среднем и в высоких единицах процентов на нижнем дециле зрителей, что как раз и есть источник жалоб на rebuffering.

Причина 3 – изогнуть кривую стоимости. Один CDN, везущий 100% трафика, имеет всё кредитное плечо на переговорах. Два CDN, делящих работу, каждый под своим коммитом, дают покупателю плечо на оба контракта – и опцию переложить трафик с более дорогого провайдера на более дешёвого, когда цены разъезжаются. У этой истории острый край: плохо переговорённые multi-CDN-контракты могут стоить дороже single-vendor-коммита, потому что нижний пол commit'а каждого провайдера лежит неиспользованным. К этому вернёмся в разделе про экономику.

Эти три причины неравнозначны. По нашему опыту в OTT и live-стриминге, причина 1 – отказоустойчивость – это та, что подписывается на уровне executive; причина 2 – производительность – оправдывает архитектуру на QoE-дашбордах; причина 3 – стоимость – требует самой аккуратной финансовой модели, чтобы реально материализоваться. Команда, берущая multi-CDN только по причине 3, без слоя steering, способного выигрывать по причине 2, или структуры контракта, выдерживающей перекидывание нагрузки причины 1, проиграет.

Слой steering – три архитектуры, у каждой свой режим отказа

Steering на уровне DNS

Самая старая архитектура и та, что до сих пор в большинстве легаси-стеков. DNS-сервер – пользователя, ресолвера или managed-продукта (NS1, Cedexis-теперь-Citrix-ITM, Akamai Global Traffic Management, Cloudflare Load Balancer) – отвечает на запрос плеера именем хоста манифеста другим IP или CNAME в зависимости от того, какой CDN сейчас предпочтительнее по политике steering.

Механизм простой, вендоронезависимый и работает с любым плеером. Проблема – время реакции. DNS-ответ несёт Time-To-Live (TTL), и рекурсивные ресолверы кэшируют ответ на этот TTL. Установить TTL низко (30 секунд, 60 секунд) – стандартный обходной приём, но две вещи его ломают. Во-первых, часть ресолверов игнорирует короткие TTL и принудительно ставит минимум в несколько минут – Internet Service Provider'ы делают это рутинно, чтобы снизить нагрузку на свои DNS. Во-вторых, у операционной системы плеера есть собственный DNS-кэш, который SDK стриминга не может сбросить посреди сессии.

Практическое следствие: когда CDN падает в 19:32 UTC, DNS-управляемый multi-CDN перекладывает новых зрителей с плохого CDN за секунды – но те, кто уже в сессии, держа кэшированный DNS-ответ на плохой CDN, продолжают долбить его до фактического TTL ресолвера. На крупном live-событии этот «хвост зрителей, застрявших на умирающем CDN» – самая болезненная операционная реальность DNS-управляемого multi-CDN и причина, по которой любой современный playbook требует ещё и application-layer steering.

Client-side steering со статическим манифестом

Следующая ступень. Плеер скачивает небольшой конфигурационный манифест из собственного сервиса платформы (не CDN), в котором перечислены базовые URL доступных CDN и статический приоритет. Затем плеер выдаёт манифест- и сегмент-запросы по выбранному базовому URL CDN. Когда плеер обнаруживает ошибки (5xx, TCP-таймаут, фетч сегмента медленнее порога), он откатывается на следующий CDN из списка.

Механизм быстрее DNS-управляемого на уровне сессии – плеер делает решение о переключении внутри своего процесса, без ресолверных кэшей на пути. У механизма есть свой потолок. Список приоритетов статичен; он не может реагировать на изменение глобального здоровья посреди сессии, если плеер периодически не обновляет конфиг-манифест. Failover реактивный (плеер должен сначала получить неудачный запрос) а не проактивный (steering-решение видит деградацию CDN до того, как туда попадёт хоть один зритель). И каждая реализация плеера делает это чуть по-своему, что не даёт QoE-дашборду легко сравнить like-for-like между iOS, Android, web и smart-TV приложениями.

HLS / DASH Content Steering (дефолт 2026 года)

Текущий стандарт и архитектура, на которую должен по умолчанию идти любой новый build. Два намеренно согласованных спецификационных документа.

Для HLS управляющий документ – Apple HLS Authoring Specification, секция Content Steering, наслоённая поверх IETF RFC 8216bis. Apple ввели Content Steering в редакции HLS Authoring Specification от сентября 2021 и с тех пор переиздавали; актуальная редакция 2026 года описывает тег #EXT-X-CONTENT-STEERING в multi-variant-плейлисте, указывающий на URL удалённого steering-манифеста, и атрибут PATHWAY-ID на каждом варианте, называющий CDN, который его обслуживает.

Для DASH управляющий документ – ETSI TS 103 998 (формально принятый из DASH-IF Content Steering Community Review draft, опубликованного в конце 2022), и DASH-IF ведёт implementation guidelines, которым следуют open-source dash.js и Shaka Player. DASH-IF разработали свою Content Steering специально согласованно с работой Apple над HLS, чтобы один и тот же steering-сервер мог управлять обоими клиентами.

Механизм – самый чистый из трёх. Плеер скачивает манифест, видит тег steering, скачивает steering-манифест маленьким JSON-документом и получает список pathway (базовых URL CDN) с упорядоченным приоритетом. Затем плеер начинает скачивать сегменты с pathway наивысшего приоритета. Steering-манифест содержит поле TTL – обычно 60–300 секунд для стриминга – и плеер перечитывает его по этому расписанию. Steering-сервер может обновить список приоритетов посреди сессии в ответ на real-time-метрики здоровья, производительности или стоимости, и плеер подхватит новый порядок на следующем рефреше.

Две ключевые сильные стороны архитектуры – mid-session-обновления и двусторонние измерения. Mid-session-обновления означают, что steering-сервер может увести зрителей с деградирующего CDN за минуты с момента детекции, а не за TTL ресолвера. Двусторонние измерения, в паре со спецификацией Common Media Client Data – CTA-5004, опубликованной Consumer Technology Association – дают steering-серверу real-time-метрики плеера (длина буфера, throughput, dropped frames) на каждом запросе сегмента, так что steering-решения становятся data-driven, а не слепыми.

Слабости архитектуры реальны и стоят названия. Steering-сервер сам становится критическим компонентом; если steering JSON падает, плееры откатываются к pathway-порядку манифеста и теряют пользу multi-CDN. Спецификация мягка по тому, как плеер реализует steering-логику, и dash.js, Shaka Player, hls.js и нативный Apple AVPlayer все ведут себя чуть по-разному на пограничных случаях. Покрытие на smart-TV отстаёт от web – в 2026 году крупные TV-платформы (Tizen, webOS, Vidaa) поставляют content-steering-совместимые нативные плееры, но старые прошивки в установленной базе не всегда обновляются.

Вендоронезависимое и протоколо-независимое сравнение трёх архитектур steering:

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

История с деньгами – почему multi-CDN не экономит по умолчанию

Этот раздел вырезают из конференционных докладов и возвращают в post-mortem. Multi-CDN-архитектура сама по себе не снижает стоимость доставки за GB. Она может снизить счёт, если структура контракта и политика steering согласованы, и может поднять счёт – иногда существенно, – если что-то из этого неправильно настроено.

CDN-индустрия выставляет счёт за доставку видео в одной из трёх основных форм, и большинство контрактов смешивают.

Per-GB tiered – самая простая. Контракт задаёт стоимость за GB на первые N TB, переданных в месяц, более низкую ставку на следующий тир и так далее. Счёт – это суммарный egress за месяц, умноженный на ставку соответствующего тира, применённую по региону (Северная Америка, Европа, Asia-Pacific, Латинская Америка, Middle East-Africa), поскольку структура стоимости CDN сильно отличается по географии.

95-й перцентиль – модель, унаследованная из чистого транзита. CDN сэмплирует throughput в Mbps каждые 5 минут весь месяц, сортирует сэмплы, отбрасывает верхние 5% (примерно 36 часов месяца) и выставляет счёт по самому высокому оставшемуся сэмплу – так называемому пику 95-го перцентиля. Интуиция: 5% месяца, проведённых в самом крайнем пике, не платятся; всё остальное – да. Эта модель выгодна нагрузкам с одним коротким всплеском в месяц (брендовое live-событие) и наказывает нагрузки со стабильно высоким throughput.

Commit + overage – структура, используемая большинством enterprise-контрактов. Покупатель коммитится на минимальные месячные траты – скажем, $50 000 – по сильно дисконтированной ставке за GB; использование ниже коммита оплачивается по commit-ставке (в этом и смысл скидки), а использование выше – по ставке overage. Ставка overage – та клаузула контракта, которая определяет, выигрыш multi-CDN финансово или проигрыш. Хорошо переговорённая ставка overage сидит рядом с commit-ставкой (премия 10–30%); плохо переговорённая – на 100–200% выше, и перебрасывать неожиданный трафик такому провайдеру становится карательно дорого.

Три ценовых ловушки кусают каждую команду, которая запускает multi-CDN без аккуратной модели.

Ловушка 1: under-commit и накопление overage. Команда добавляет второй CDN и делит трафик 50/50. Их исходный CDN был коммитан под 100% нагрузки, так что теперь они на $25 000 недоиспользуют commit 1 (платя за непользованную ёмкость), а commit второго CDN был выставлен консервативно, и всплески в пик уходят в overage по контракту два. Совокупный счёт выше single-CDN-базы. Лечится перезаключением обоих контрактов на меньшие коммиты, сумма которых равна полному ожидаемому трафику – и оставлением запаса под steering-сдвиги.

Ловушка 2: всплеск летит не на тот CDN. Live-событие в 19:00 по местному. Политика steering сконфигурирована статическим весом отправлять 40% трафика на более дешёвый Tier 2 CDN. Commit Tier 2 был под baseline; всплеск проталкивает 40% события в overage по премии 200%. Счёт за одно событие – кратное тому, что обошлось бы 100%-Tier 1. Лечится: сделать политику steering трафик-осознанной – baseline на дешёвый CDN, всплески на CDN с наиболее выгодной overage-клаузулой, и использовать политики стиля IO River, комбинирующие производительность и стоимость в steering-решении.

Ловушка 3: ползучий 95-й перцентиль. Нагрузка, которая раньше сидела 70% месяца возле одного 200 Gbps пика – платя за 200 Gbps по 95-му перцентилю – делится между двумя CDN. Пик на CDN падает до 100 Gbps; счёт по 95-му перцентилю каждого CDN – за 100 Gbps. Пока всё хорошо. Но второй CDN на 95-percentile-контракте с минимальным commit-полом в 150 Gbps. Покупатель платит за 200 Gbps на первом контракте плюс 150 Gbps на втором, фактически 350 Gbps там, где было бы 200 Gbps на одном контракте. Лечится: указывать percentile-of-spillover вместо жёсткого пола или внимательно моделировать 95-й перцентиль на каждого провайдера при переговорах.

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

Математика – нагрузка 10 PB/месяц в трёх архитектурах

Расчёт с показанной арифметикой. Нагрузка: OTT-сервис, доставляющий 10 петабайт видео в месяц, дневной пик подталкивает 200 Gbps на 2 часа, ежемесячное брендовое событие удваивает пик до 400 Gbps на 4 часа.

Архитектура A: Single CDN, commit + overage. Commit: $50 000/месяц за 10 PB по смешанной ставке $0.005/GB. Ставка overage: $0.008/GB (премия 60% над commit-implied). Брендовое событие добавляет 200 TB egress поверх baseline 10 PB → 200 000 GB × $0.008/GB = $1 600 overage. Месячный счёт: ~$51 600.

Архитектура B: 50/50 multi-CDN, плохо переговорённый. Каждый CDN коммитан под 6 PB за $30 000/месяц. (Общий commit $60 000 за 12 PB, из которых используется 10 PB; over-commit на 2 PB или 20% ожидаемого объёма.) Ставка overage на Tier 2: $0.012/GB (плохо переговорено, +150% над commit). Брендовое событие толкает по 100 TB на каждый CDN; Tier 1 остаётся в commit, Tier 2 уходит 100 000 GB в overage → 100 000 × $0.012 = $1 200, но commit-waste – $60 000 платится за 10 PB фактического использования, или $6 000 чистых потерь на коммите. Месячный счёт: ~$61 200.

Архитектура C: 70/30 multi-CDN, хорошо переговорённый, с Content Steering. Tier 1 commit: $35 000/месяц за 7.5 PB по согласованной ставке. Tier 2 commit: $9 000/месяц за 3 PB по более дешёвой ставке $0.003/GB (Tier 2 выбран именно за конкурентную цену за GB). Ставки overage: Tier 1 $0.0065/GB (+30%); Tier 2 $0.004/GB (+33%). Политика steering: baseline 70/30 в off-peak; во время брендового всплеска steering-сервер отправляет лишние 200 TB на Tier 2 (у которого ставка overage ниже) → 200 000 × $0.004 = $800. Коммиты в пределах 1% от фактического baseline, commit waste пренебрежимо мал. Месячный счёт: ~$44 800.

Разлёт: Архитектура C экономит примерно 13% относительно single-CDN и примерно 27% относительно плохо переговорённого multi-CDN. Экономия целиком – функция соответствия коммитов реальности, тесных overage-клаузул и cost-aware steering-политики. Уберите любое из трёх – и Архитектура C коллапсирует в Архитектуру B.

Частая ошибка – моделировать multi-CDN по смешанной ставке за GB без учёта commit-полов и overage-потолков. Смешанная ставка хорошо смотрится на торговом слайде; счёт, приходящий 1-го числа, отражает структуру контракта, а не смешанную ставку.

Режимы отказа – что конкретно ломается

Список режимов отказа отсортирован по частоте в логах инцидентов команд, с которыми мы работали. У каждого пункта есть конкретное лечение.

Отказ 1: Пинг-понг агрессивного failover

Политика steering переключается с CDN A на CDN B по 5xx; затем переключается обратно с CDN B на CDN A, когда фетч сегмента CDN B на 50 мс медленнее. Сессии зрителей мечутся между двумя провайдерами, каждое переключение – cache-miss-штраф на новом CDN, каждое – сброс per-session-состояния соединения. Rebuffering растёт; проигрывают все.

Лечение – damped-политика failover. Переключаться по устойчивому сигналу: три подряд неудачных сегмента или moving average за 30 секунд выше порога, не по одному плохому. Применять back-off перед возвратом на исходный CDN: минимум 5 минут чистого поведения. Implementation Guidelines DASH-IF Content Steering упоминает это явно; аналогичные рекомендации Apple говорят о схожем dwell time на каждом pathway перед пересмотром.

Отказ 2: Хвост зрителей в DNS-кэше

CDN-уровневый инцидент бьёт CDN A в 19:00. TTL DNS – 60 секунд. К 19:01 новые зрители должны быть на CDN B. К 19:15 каждый зритель со свежим DNS-кэшем – на CDN B, но зрители за ISP-ресолверами, переопределяющими TTL до 5 минут, зрители на долгих плеерных сессиях и мобильные за carrier-grade NAT'ом, ещё агрессивнее кэшировавшим DNS, продолжают долбить CDN A. Дашборд показывает трафик к мёртвому CDN; плееры всё ещё видят ошибки.

Лечение – не зависеть от DNS для mid-session failover. Application-layer steering – HLS / DASH Content Steering или client-side конфигурация с коротким refresh – двигает зрителей за TTL steering (обычно 60–300 секунд) независимо от DNS-кэшей. DNS-управляемый steering остаётся полезным для начального выбора провайдера на старте сессии; он не должен быть единственным механизмом.

Отказ 3: Фрагментация кэша между провайдерами

Один и тот же сегмент теперь закэширован и на CDN A, и на CDN B. У edge каждого провайдера холодный кэш на ту долю зрителей, которая по steering-решению пришла впервые. Hit ratios падают на обоих провайдерах во время сдвигов трафика; origin egress прыгает на каждом steering-решении; защитный эффект origin shield, темы предыдущей статьи раздела, частично сводится на нет всякий раз, когда steering отправляет зрителя на провайдера, ещё не видевшего этот сегмент.

Лечение двойное. Во-первых, предпочитать steering-решения, sticky на время жизни сессии – переключаться на старте сессии, не в середине фетча сегмента, где возможно. Во-вторых, размерить origin shield на поглощение cache-miss-всплеска при steering-сдвигах и сконфигурировать shield так, чтобы оба CDN тянули из одного и того же закэшированного объекта, чтобы steering-сдвиг не превращался в origin fetch. Статья об origin shield в этом разделе разбирает геометрию shield подробно.

Отказ 4: Падение steering-сервера

Steering JSON-эндпоинт падает. Плееры откатываются на pathway-порядок манифеста по умолчанию, и все толпятся на первом pathway. Если первый – более дорогой, счёт скачет; если в регионе он менее производительный, QoE деградирует там.

Лечение – хостить steering-сервер с той же дисциплиной доступности, что и manifest-сервис – multi-region, за собственным load balancer'ом, в идеале с маленьким TTL-кэшем на отдельном CDN, чтобы даже падение steering-сервера сваливалось на свежий кэш steering-манифеста, а не в пустоту. Guidelines DASH-IF описывают именно этот паттерн.

Отказ 5: Stickiness, доживший до поломки

Политика steering привязывает каждую сессию к её начальному CDN на время её жизни. Чаще это правильно – см. Отказ 3. Но зритель на 6-часовом live-эфире держит один CDN 6 часов, и если этот CDN начинает деградировать в часе 4, sticky-правило мешает steering-серверу помочь. Зритель буферится; команда эксплуатации видит метрику и не может вмешаться.

Лечение – sticky-правило с escape: привязывать сессию к начальному CDN по умолчанию, но рвать привязку при устойчивых QoE-сигналах (длинные rebuffer, throughput collapse) выше порога. Implementation Guidelines DASH-IF называют это «hard switch» и дают язык спецификации для критериев выбора pathway.

Отказ 6: Запоздалая географическая политика

Региональный CDN-инцидент бьёт APAC. Политика steering настроена весить географии, но не детектить региональные изменения здоровья в реальном времени. Зрители APAC продолжают направляться на затронутый CDN, пока политику вручную не обновит человек; зрители Северной Америки не затронуты.

Лечение – подключить steering-сервер к источнику real-time-мониторинга здоровья – синтетическим зондам, RUM-данным из CMCD или третьестороннему сервису мониторинга – и выражать steering-политику как «использовать CDN X в регионе Y если health > порог Z», а не как статический вес.

Отказ 7: Несовпадение токенных подписей между CDN

Платформа подписывает URL CDN-специфичной схемой. CDN A использует Cloudflare-style signed URLs; CDN B – CloudFront-style. Steering-решение, перебрасывающее зрителя посреди сессии с A на B, отправляет плеер на CDN B с подписью CDN A, и запрос отклоняется.

Лечение – спроектировать схему подписи CDN-агностичной: подписывать path-часть URL ключом, разделённым между обоими CDN и валидируемым обоими, или использовать сервис валидации токенов между плеером и любым edge. Статья о token authentication и signed URLs в разделе подробно разбирает паттерны.

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

Ландшафт вендоров и инструментов (2026)

Рынок multi-CDN-инструментов в 2026 включает четыре типа игроков, и архитектура обычно использует по одному из каждого.

Сами CDN. Akamai, Amazon CloudFront, Cloudflare, Fastly, Google Media CDN, Bunny, CDN77, KeyCDN, CDNetworks, EdgeNext, Tencent Cloud CDN и Alibaba Cloud CDN – самые часто упоминаемые комбинации в текущих production-развёртываниях multi-CDN. Большинство архитектур пары один tier-1-incumbent с одним challenger'ом, который дешевле или сильнее в конкретном регионе.

Независимые steering / load-balancing платформы. IO River, NPAW CDN Balancer, Cedexis (теперь Citrix Intelligent Traffic Management) и NS1 предоставляют steering-решение как сервис, часто комбинирующее данные синтетических зондов с RUM (Real User Monitoring) в steering-политику. Эти платформы обычно интегрируются как DNS-load-balancer или как content-steering-сервер, который опрашивает плеер.

RUM / мониторинг вендоры. Mux Data, Conviva, Bitmovin Analytics, Datazoom и NPAW дают per-session-телеметрию, питающую data-aware-steering. CMCD (CTA-5004) – стандартизованный формат для этой телеметрии по состоянию на 2024; большинство современных плееров поддерживает его из коробки.

Origin-shield и packager-вендоры. Multi-CDN-архитектуры давят на origin (каждый steering-сдвиг может породить всплеск cache-miss), и origin shield и packager становятся важнее. Mediapackage (AWS), Unified Origin, Wowza, EZDRM и self-built packager-shield-стеки встречаются в production multi-CDN-сетапах.

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

Multi-CDN-архитектура – тот тип работы, где ценность в операционных деталях, а не в слайде. Мы поставляем видеостриминг, OTT, телемедицину, e-learning и видеонаблюдение с 2005 года, и в каждом продукте, где доступность и стоимость за GB одновременно важны, решение про multi-CDN всплывает рано. Команды, которым мы помогали, делятся на два лагеря: команда, у которой multi-CDN работает, но непонятно, помогает ли (нет per-CDN QoE breakdown, нет cost-model, нет плана failover-теста), и команда, оценивающая первую multi-CDN-процедуру и нуждающаяся в архитекторе, чтобы написать контрактные клаузулы и steering-политику. В обоих случаях deliverable один: архитектурное ревью, называющее steering-слой, определяющее политику failover с конкретными порогами, моделирующее стоимость в трёх формах трафика и включающее ежеквартальный план учений для поддержания failover-механики в тонусе.

Ключевые тезисы

• Multi-CDN – это три архитектуры, а не одна: DNS-управляемая, client-side статическая и HLS / DASH Content Steering. Третья – дефолт 2026.
• Steering-слой – это и есть архитектура; выбирайте его первым, остальное следует.
• Экономия не автоматическая; она живёт в commit-полах, overage-клаузулах и cost-aware steering-политике.
• Пинг-понг failover, хвост DNS-кэша, фрагментация кэша и падение steering-сервера – четыре самых частых режима отказа; проектируйте против каждого до запуска.
• HLS / DASH Content Steering + CMCD upstream даёт real-time, standards-based, mid-session-обновляемую архитектуру; стройте новое на ней.
• Запускайте ежеквартальные multi-CDN-учения – непротестированный failover это не failover.

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

• Content Steering: стандартный способ делать multi-CDN – спеко-уровневый разбор steering-слоя, выбранного здесь дефолтом 2026.
• Origin shielding и многоуровневое кэширование – как shield поглощает cache-miss-всплески, которые порождает каждый steering-сдвиг.
• Экономика CDN: 95-й перцентиль, commit, overage, transit – расчётная финансовая модель, стоящая за вышеприведённой историей с деньгами.

CTA

• Поговорить с инженером стриминга – бронируйте 30-минутное архитектурное ревью текущего или планируемого multi-CDN-развёртывания.
• Посмотреть кейсы – OTT-, live- и телемедицинские проекты Фора Софт.
• Скачать: чек-лист миграции multi-CDN – одностраничный pre-launch-чек-лист нашей команды, включая контрактные клаузулы, пороги steering-политики и план failover-учений.