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-сессии, которые держатся достаточно долго, чтобы сломаться; и налог фрагментации кэша, снижающий hit ratio с 95% до 60%, когда один и тот же сегмент дублируется на двух origin’ах.

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

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

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

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

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

Такой подход позволяет:

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

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

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

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

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

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

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

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

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

Эти три причины не равны по значимости. На основе нашего опыта в OTT и live-стриминге: первая – отказоустойчивость – принимается на уровне топ-менеджмента; вторая – производительность – обосновывает архитектуру через QoE-дашборды; третья – стоимость – требует самой точной финансовой модели, чтобы реально реализовать выгоду. Команда, выбирающая multi-CDN исключительно из-за третьей причины, но без слоя 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 на низкое значение (30 или 60 секунд) – стандартный способ обхода, но две вещи его сводят на нет. Во-первых, часть резолверов игнорирует короткие TTL и принудительно устанавливают минимальное значение в несколько минут – интернет-провайдеры делают это регулярно, чтобы снизить нагрузку на свои DNS-серверы. Во-вторых, у операционной системы плеера есть собственный DNS-кэш, который SDK стриминга не может сбросить в ходе сессии.

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

Клиентское управление со статическим манифестом

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

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

HLS / DASH Content Steering (по умолчанию в 2026 году)

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

Для 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, опубликованного в конце 2022 года), а DASH-IF разрабатывает рекомендации по реализации, которым следуют open-source-проекты dash.js и Shaka Player. DASH-IF создала свой Content Steering с учётом работы Apple над HLS, чтобы один и тот же сервер управления мог работать с обоими клиентами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ловушка 3: ползучий 95-й перцентиль. Нагрузка, которая раньше 70% месяца держалась около пика в 200 Gbps и оплачивалась по 95-му перцентилю как 200 Gbps, теперь распределена между двумя CDN. Пик на каждой CDN снижается до 100 Gbps, и счёт по 95-му перцентилю у каждой – за 100 Gbps. Пока всё в порядке. Однако второй CDN работает по контракту с 95-ым перцентилем, но с минимальным обязательством (commit floor) в 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 Гбит/с в течение 2 часов; ежемесячное брендовое событие удваивает пиковую нагрузку до 400 Гбит/с на 4 часа.

Архитектура A: Single CDN, commit + overage. Фиксированная оплата: 50 000 долларов в месяц за 10 ПБ по смешанной ставке 0,005 доллара за ГБ. Ставка за превышение: 0,008 доллара за ГБ (на 60% выше, чем при фиксированной оплате). Брендовое событие добавляет 200 ТБ исходящего трафика сверх базового объёма 10 ПБ → 200 000 ГБ × 0,008 доллара за ГБ = 1 600 долларов за превышение. Месячный счёт: около 51 600 долларов.

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

Архитектура C: 70/30 multi-CDN, хорошо переговорённый контракт с Content Steering. Tier 1: $35 000 в месяц за 7,5 PB по согласованной ставке. Tier 2: $9 000 в месяц за 3 PB по более низкой ставке – $0,003/ГБ (выбран именно за конкурентную цену за гигабайт). Ставки за превышение: Tier 1 – $0,0065/ГБ (+30%); Tier 2 – $0,004/ГБ (+33%). Политика маршрутизации: базовый баланс 70/30 в периоды низкой нагрузки; во время пиковой активности брендового трафика сервер маршрутизации направляет дополнительные 200 ТБ на Tier 2 (где ставка за превышение ниже) → 200 000 × $0,004 = $800. Объём обязательств остаётся в пределах 1% от фактического базового уровня, потери по коммитам пренебрежимо малы. Месячный счёт: ~$44 800.

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

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

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

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

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

Политика steering переключает трафик с CDN A на CDN B при ошибках 5xx, а затем – обратно с CDN B на CDN A, если загрузка сегмента с CDN B замедляется на 50 мс. Сессии зрителей постоянно «прыгают» между двумя провайдерами: каждое переключение вызывает cache-miss на новом CDN и сброс состояния соединения для каждой сессии. В результате растёт rebuffering – и страдает качество просмотра у всех.

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

Отказ 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 для переключения в середине сессии. Управление на уровне приложения – например, HLS/DASH Content Steering или клиентская конфигурация с коротким интервалом обновления – позволяет перенаправлять пользователей быстрее, чем TTL-управление (обычно 60–300 секунд), независимо от DNS-кэшей. Управление через DNS остаётся полезным для первоначального выбора провайдера при старте сессии, но не должно быть единственным механизмом.

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

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

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

Отказ 4: Падение сервера управления рулём

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

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

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

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

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

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

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

Лечение – подключить сервер управления к источнику мониторинга состояния в реальном времени: синтетическим зондам, RUM-данным из CMCD или стороннему сервису мониторинга – и задавать политику управления как «использовать CDN X в регионе Y, если состояние здоровья выше порога Z», а не в виде статического веса.

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

Платформа подписывает URL с использованием схемы, специфичной для CDN. CDN A применяет подписи в стиле Cloudflare, CDN B – в стиле CloudFront. Решение по переключению (steering), перенаправляющее зрителя в середине сессии с A на B, передаёт плееру URL с подписью от CDN A, и запрос отклоняется CDN B.

Лечение – спроектировать схему подписи, независимую от CDN: подписывать путь в 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-провайдер и один более дешёвый или эффективный в конкретном регионе «вызывающий» игрок.

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

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

Origin-щит и пакер-вендоры. Архитектуры с несколькими CDN создают нагрузку на origin-сервер (каждый сдвиг в маршрутизации может вызвать всплеск cache-мисов), поэтому origin-щит и пакеры становятся всё более важными. В продакшене при использовании нескольких CDN применяются решения вроде Mediapackage (AWS), Unified Origin, Wowza, EZDRM и собственные пакер-щит-стеки.

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

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

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

• Multi-CDN – это три архитектуры, а не одна: DNS-управляемая, клиентская статическая и HLS / DASH Content Steering. Третья станет стандартом по умолчанию в 2026 году.
• Слой steering – это сама архитектура; выбирайте его в первую очередь, всё остальное строится вокруг него.
• Экономия не возникает автоматически – она зависит от commit-ов, условий превышения лимитов и политики управления затратами в steering.
• Пинг-понг при переключении, хвост DNS-кэша, фрагментация кэша и сбой сервера steering – четыре самых распространённых сценария отказа. Проектируйте систему с учётом каждого из них до запуска.
• HLS / DASH Content Steering в связке с CMCD upstream обеспечивает архитектуру с обновлением в реальном времени, на основе стандартов и в середине сессии; новые решения следует строить именно на ней.
• Проводите ежеквартальные учения по 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.