Origin Shield и Tiered Caching

TL;DR

Origin shield – это один выделенный кэш, расположенный в глубине CDN, через который проходит каждый запрос с каждого edge-сервера перед тем, как сеть сможет обратиться к origin-провайдеру. Tiered caching – более масштабная модель, при которой между edge и origin размещается несколько уровней кэшей, и почти ни один сегмент live-трансляции не доходит до origin дважды. Цель обоих подходов одинакова: свести тысячи дублирующихся запросов, возникающих при популярном стриме, к одному upstream-запросу, а остальных зрителей обслужить из кэша. На продакшене включение shield снижает исходящий трафик с origin на live-стриме в десятки раз и более: в приведённом ниже примере 4,5 Гбит/с трафика с origin падают до 360 Мбит/с при той же аудитории, а вся настройка занимает у инженера около полдня. Эта статья объясняет архитектуру, арифметику, названия и настройки у каждого вендора, а также четыре ошибки конфигурации, которые незаметно «съедают» экономию, ради которой shield и включали.

Зачем это вам

Если вы транслируете live-контент или популярный VOD, origin – это первая точка в сети, которая выходит из строя, самая дорогая по стоимости на гигабайт и имеющая наименьший запас прочности; shield – самая дешевая инфраструктура, решающая сразу все три проблемы. Команда без shield в день первого крупного эфира наблюдает, как origin перегружается, счёт взлетает вверх, а плеер постоянно ребуферит в регионе, который никто не планировал; команда с shield видит, что график почти не движется. Эта статья даёт продакт-менеджеру модель для обсуждения защиты origin с инженерной командой, архитектору – многослойную диаграмму и расчёты, а оператору – конкретные настройки в AWS CloudFront, Cloudflare, Fastly, Akamai и кастомном Varnish-shield. К концу вы должны уметь объяснить CFO, как строка egress на $180 000 в месяц превращается в $14 000, а младшему инженеру – почему «у нас уже есть CDN» не означает «у нас есть shield».

Что такое origin shield, точно

Начнём с определения, которое статья будет уточнять. Origin shield – это один из уровней кэша внутри CDN, как правило, выбранный регион или точка присутствия (Point of Presence, сокращённо POP), через которую проходят все запросы от edge-серверов перед тем, как им разрешат обращаться к origin-источнику оператора. Кэш в этом узле – обычный HTTP-кэш; роль shield играет правило маршрутизации: «ни один edge-сервер не должен напрямую общаться с origin». Только shield взаимодействует с origin, и то лишь в случае, если его собственный кэш не содержит нужных данных.

Второй термин из той же статьи: tiered caching – более широкая модель, при которой между edge и origin размещается более одного кэша. Origin shield – это конкретное название самого глубокого слоя, ближайшего к origin. Промежуточные слои, если они есть, называют региональными кэшами, mid-tier-кэшами, а в терминологии Akamai – parent tier. Таким образом, origin shield – частный случай tiered caching: ситуация, когда один из уровней выступает в роли последних ворот перед origin и единственный имеет право пройти через них.

Нетехническому читателю аналогия из предыдущей статьи Блока 6 – цепь угловых магазинов, региональный распределительный центр и единственный склад – по-прежнему работает. Региональный распределительный центр – это shield. Без него каждый угловой магазин вынужден звонить на склад за каждым товаром, которого у него нет на полке; с ним магазин звонит в центр, а центр обращается на склад только тогда, когда ни у него, ни у его «сестёр» товара не оказалось. Замените полки на кэши, а грузовики на HTTP-запросы – и картина станет точной.

Техническое определение, которое публикует Amazon Web Services (сокращённо AWS) для CloudFront, согласуется с этой моделью. В developer guide прямо сказано: CloudFront Origin Shield – «дополнительный слой в инфраструктуре кэширования CloudFront, помогающий минимизировать нагрузку на origin, повысить его доступность и снизить операционные затраты». Он действует как «централизованный слой кэша между региональными edge-кэшами и вашим origin», «схлопывая дублирующиеся запросы» до того, как они дойдут до сервера оператора.

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

Почему стриминговая нагрузка нуждается в этом больше, чем статический сайт

Статический сайт с глобальной аудиторией спокойно работает с одним-двумя уровнями кэша. Стриминг – нет, и причина здесь в временном паттерне запросов, а не в их объёме. Каждый зритель одного и того же прямого эфира запрашивает один и тот же сегмент практически одновременно – каждые 2–6 секунд на протяжении всего эфира. Арифметика в начале популярного стрима жестока: 100 000 одновременных зрителей одновременно просят сегмент 4172 в течение 200 миллисекунд – с точки зрения origin это выглядит как единичный всплеск нагрузки на один файл в 100 000 раз, затем такой же – на следующий файл через две секунды и так далее.

Возникают два режима отказа. Первый – thundering herd (отраслевой термин для всплеска дублирующих запросов, когда множество edge-узлов одновременно запрашивают один и тот же некэшированный объект при публикации популярного live-сегмента). Без коалесинга и shield каждый edge POP, не успевший закэшировать сегмент 4172, отправляет отдельный upstream-запрос. Пятьсот edge-узлов по всему CDN оператора – это пятьсот запросов к origin на один и тот же файл в одну и ту же миллисекунду; меньше, чем 100 000 зрительских запросов, но больше, чем предусмотрено в модели нагрузки origin. Второй режим – bandwidth: даже если лимит запросов в секунду к origin не превышен, передаваемые байты – это те самые байты, за которые вы платите облачному провайдеру по тарифу на исходящий трафик в публичный интернет. Пятьсот edge-узлов, скачивающих один и тот же сегмент объёмом 4 МБ, – это 2 ГБ исходящего трафика на сегмент в секунду, каждую секунду эфира. По стандартному тарифу AWS $0,09/ГБ из EC2 в публичный интернет это примерно $5,18 в секунду, $310 в минуту, почти $19 000 в час – на одном стриме.

Shield решает обе проблемы одновременно. Пятьсот edge-запросов становятся пятьюстами shield-запросами, но кэш Shield заполняется первым из них и отдаёт остальные за микросекунды; origin видит только один upstream-запрос. «Громовая толпа» (thundering herd) сжимается Shield, а трафик, уходящий с origin, сокращается на величину коэффициента попадания в кэш Shield – обычно 90–99% для популярного live-контента, то есть в 10–100 раз меньше исходящего трафика. Shield не устраняет стоимость передачи данных; он переносит её с строки исходящего трафика оператора на строки «по запросу» и «за гигабайт» в CDN, где цены на порядок ниже, а маршрутизацией занимается CDN.

Инженеры Cloudflare поделились похожей идеей в блоге о concurrent streaming acceleration: даже один только request coalescing – без использования shield – сокращает запросы к origin более чем на 90% во время stampede. Добавьте к коалесингу tiered-кэш shield – и оставшиеся 10% тоже значительно сократятся. Эти две техники дополняют, а не дублируют друг друга; почти каждый современный CDN использует обе, и задача инженера – убедиться, что для стриминговой нагрузки они обе включены.

Как работает tiered caching, слой за слоем

Каноническая иерархия кэшей стриминга состоит из пяти именованных уровней. От зрителя (снизу) к origin (сверху):

Плеер – это кэш на устройстве зрителя. Современные плееры, такие как hls.js, Shaka Player, dash.js и нативный плеер iOS, буферизуют 2–4 сегмента вперёд. Этот буфер представляет собой локальный кэш плеера и является первым местом, где хранятся сегменты.

Edge POP, или нижний ярус кэша, – ближайший к зрителю сервер CDN. У Akamai к Q2 2026 более 4,200 таких POP; Cloudflare публикует охват в 330+ городов; у Fastly 100+ POP с высокой пропускной способностью на каждый. Edge обслуживает основной трафик – 95–99% зрительских запросов, если конфигурация здоровая.

Региональный кэш, mid-tier-кэш или верхний ярус кэша расположен за группой edge-узлов, обычно по одному на географический регион, и хранит «длинный хвост» менее популярного контента, который отдельные edge-узлы нецелесообразно хранить. В Cloudflare этот слой реализован как Generic или Smart Tiered Cache. Akamai на этом уровне использует Tiered Distribution. У Fastly двух-POP-шилдинг позволяет одному выбранному POP одновременно выполнять функции регионального кэша и шилда в зависимости от конфигурации.

Origin shield – это один выбранный регион или POP, через который любой промах кэша с любого edge-сервера и любого региона проходит через единый финальный кэш перед тем, как запрос будет направлен на origin. Документация Cloudflare прямо указывает: «только верхние уровни могут запрашивать контент у вашего origin»; документация CloudFront описывает Origin Shield как «централизованную точку», через которую маршрутизируются запросы; у Fastly это называется «shield POP». Разные вендоры – одна и та же идея.

Origin – собственный сервер оператора: упаковщик, слой хранилища, just-in-time упаковка. Это единственное место, где хранится каноническая копия каждого сегмента. При нормальной стриминговой нагрузке origin должен обрабатывать менее половины процента запросов от зрителей. При аномальной нагрузке – в двадцать раз больше.

Возникают два вопроса. Первый: сколько уровней кэширования использовать? Минимум – два: edge не может напрямую обращаться к origin, между ними обязательно должен быть промежуточный узел. Три уровня – комфортное решение для большинства стриминговых нагрузок: edge, регион, shield. Это стандартная конфигурация, которую по умолчанию предлагает любой крупный коммерческий CDN. Четыре и более – для масштабнейших развёртываний, где иерархия строится физически, а не логически: встроенные ISP-устройства на краю сети пользователей, затем региональный кэш CDN, далее shield-уровень оператора, и, наконец, origin.

Второй вопрос: какой регион выбрать для размещения shield? Правило одно: близко к origin, но не к аудитории. Shield в us-east-1 для origin в us-east-1 обеспечивает задержку между shield и origin в несколько миллисекунд; shield в Сиднее при origin в Вирджинии увеличивает эту задержку до 150 миллисекунд и добавляет трансокеанский round-trip к каждому промаху кэша. Shield обслуживает глобальную аудиторию, поскольку региональные кэши работают с edge-узлами. Поэтому shield должен быть расположен близко только к одному – к origin.

Request collapsing, coalescing и приём из двух слов

Origin shield работает, потому что кэш общий. Request collapsing – он же coalescing или collapse forwarding – работает, потому что общим становится промах. Это независимые идеи, выполняющие схожую задачу; почти каждый CDN с поддержкой shielding использует обе.

Механика коалесинга умещается в один абзац. Когда десять тысяч зрителей просят у edge POP сегмент 4172 в одну миллисекунду и edge его ещё не закэшировал, у edge есть выбор. Наивный – отправить десять тысяч upstream-фетчей. Коалесинг – отправить один upstream-фетч и припарковать остальные девять тысяч девятьсот девяносто девять в очередь, выпустив их всех сразу, как только придёт ответ. Cloudflare, AWS CloudFront, Akamai, Fastly и кастомные Varnish-шилды реализуют коалесинг на каждом слое кэша. В инженерном посте Cloudflare сокращение origin-запросов от коалесинга – более 90% во время stampede. Varnish Software говорит то же самое чуть другими словами: «Varnish identifies requests to the same uncached resource, queues them on a waiting list, and only sends a single request to the origin».

Почему эти две техники – не одно и то же – стоит отдельного абзаца. Shield – это попадание в кэш: контент уже есть в shield, edge-сервер не ждёт origin. Coalesced-запрос – это промах: контента в кэше нет, но кэш один раз запросил его для нескольких клиентов. Shield уменьшает трафик, идущий на origin; coalescing снижает нагрузку на origin по количеству запросов в секунду. Вместе они устраняют и то, и другое: большинство сегментов – это попадания в shield и не доходят до origin; те немногие, что не попадают в shield, объединяются в один запрос к upstream.

Правило конфигурации: «обе включены, на каждом ярусе». Origin shield без коалесинга всё равно генерирует всплески дублирующихся промахов с каждого edge, не успевшего прогреть кэш на сегменте; коалесинг без shield всё равно отправляет по одному origin-запросу с каждого edge, который промахнулся. Каждая техника ловит сбой, который пропускает другая. Реальные CDN по умолчанию включают и то, и другое для property, помеченных как streaming; задача инженера – проверить, а не предполагать.

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

Математика: покажите расчёт

Возьмём пример из реальных проектов. Спортивный стриминг с 50 000 одновременных зрителей, средний битрейт – 3 мегабита в секунду (Mbps), один четырёхсекундный HLS-сегмент на секунду трансляции. Каждый зритель раз в четыре секунды запрашивает сегмент; система обрабатывает 12 500 запросов на получение сегментов в секунду.

Запуск без shield. Edge POP размещаются непосредственно перед origin. Edge cache hit ratio составляет 88%. Это типичный показатель для live-трансляций: сегменты обновляются каждые несколько секунд, и edge-узлам приходится почти на каждом сегментном бордере прогревать кэш с нуля. Оставшиеся 12% запросов идут напрямую с edge:

edge misses per second = 12,500 × (1 − 0,88) = 1,500 fetches/sec

Каждый промах тянет 4-секундный сегмент размером в среднем 1,5 мегабайта при скорости 3 Mbps (3 Mbps × 4 с ÷ 8 = 1,5 МБ). Значит, origin должен выдавать 1500 × 1,5 = 2,25 ГБ в секунду в CDN. За 30 дней непрерывной трансляции в таком режиме счёт составит:

egress per month = 2,25 ГБ/с × 86,400 с/день × 30 дней ≈ 5,83 ПБ/мес
стоимость при $0,09/ГБ     ≈ $524,000/мес

Реальный live не идёт непрерывно; пример выше – потолочный счёт на пиковой скорости в стационарном режиме. Замените 30 дней пика на эквивалент 4 часов пика в сутки – счёт составит около 1/6 от стационара, ≈ $87 000 в месяц, что ближе к реальным цифрам спортивного стриминга.

Теперь включим shield. Назначим один регион – скажем, eu-west-1 – origin shield и направим через него все edge-промахи. Cache hit ratio самого shield на этой нагрузке составляет около 92%, потому что он видит объединённый поток промахов со всех edge-серверов по всему миру для одного и того же небольшого набора сегментов и почти всегда уже имеет нужный сегмент, когда его запрашивает второй edge. Арифметика:

shield misses per second = 1,500 × (1 − 0,92) = 120 fetches/sec
egress per second        = 120 × 1,5 МБ      = 180 МБ/с
egress per month         = 180 МБ/с × 86,400 × 30 ≈ 467 ТБ/мес
стоимость при $0,09/ГБ   ≈ $42,000/мес (стационарный потолок)
или 4 ч/сутки пика       ≈ $7,000/мес

Egress с origin падает в 12,5 раза – точное отношение 0,12 / 0,0096, остаточная доля промахов после edge и shield. Счёт со стороны CDN остаётся примерно на том же уровне – байты всё ещё уходят от CDN к зрителю; меняется только цена за байт этого перегруза, который оплачивает оператор, поскольку перегон shield→origin – единственный, оплачиваемый по тарифу public-egress. Чистая экономия в этом примере: более $80 000 в месяц на типичном ритме спортивного стриминга – за полдня настройки.

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

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

Имена у каждого вендора – полевой справочник

Та же идея у каждого CDN реализуется под своим названием. Ниже приведённая таблица сопоставляет маркетинговые термины с архитектурными понятиями – чтобы быстро найти нужную панель.

Несколько замечаний. Во-первых, принцип «default on» имеет значение: Akamai AMD включает Tiered Distribution для кэшируемого стримингового контента «из коробки», и команда, перешедшая на AMD, получает tiered-топологию бесплатно. Origin CloudFront в обычной distribution такой функции не имеет – инженер должен вручную включить Origin Shield для каждого origin. Во-вторых, регион shield – «ближайший к origin»: документация всех вендоров говорит об этом одинаково, и неправильный выбор (когда shield находится далеко от origin) сводит экономию на нет, поскольку каждый промах приводит к длинному round-trip по дорогому каналу оператора. В-третьих, стоимость самого shield реальная, но небольшая: AWS берёт около $0,0035 за 10 000 shield-запросов в 2026 году (зависит от региона), и большинство команд обнаруживают, что экономия на egress-трафике с origin многократно превышает затраты на запросы – в среднем в десять раз.

Распространённые ошибки, тихо съедающие экономию

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

Ошибка первая: cache key содержит per-viewer query-параметр. Edge и shield ищут кэшированные ответы по cache key – кортежу из хостнейма, пути и выбранных query-параметров и заголовков. Cache key с ?token=abc123 или ?sessionId=xyz789 даёт уникальный ключ для каждого зрителя, разбивая то, что должно быть одной общей записью кэша, на 100 000 отдельных копий – ни одна из которых не может быть использована следующим зрителем. Edge CHR падает; shield CHR падает; origin получает запрос от каждого зрителя. Лечение: проверять подпись signed URL на edge как отдельный шаг авторизации и исключить токен из cache key. Документация каждого CDN объясняет, как это сделать. Cloudflare, CloudFront и Fastly по умолчанию игнорируют query string в cache key, пока оператор явно не включит обратное – проверьте конфигурацию cache key property и убедитесь, что это не было сделано.

Ошибка вторая: per-viewer-кастомный манифест. Server-side ad insertion (сокращённо SSAI) переписывает HLS- или DASH-манифест под каждого зрителя, чтобы вставить персональные рекламные сегменты. Наивная реализация делает URL манифеста per-viewer (разный query string или разный путь), и shield не может делить манифесты между зрителями. Сегменты остаются кэшируемыми, манифест – нет; вы по-прежнему платите за манифестный egress и за rate. Фикс 2026: server-guided ad insertion (сокращённо SGAI), при котором манифест общий, а персонализация рекламы идёт на стороне плеера через DASH event streams или HLS interstitials; форма кэша сохраняется. Подробности в статье 9.6 Блока 9.

Ошибка третья: короткие или отсутствующие TTL на VOD. Cache-Control: max-age=60 на фильме, который не менялся три года, – это расточительство: edge-подсистемы перепроверяют ассет раз в минуту, shield – тоже раз в минуту, а origin постоянно получает условные запросы GET от каждой ноды, которая его раздаёт. Лечение: устанавливать max-age в днях или неделях для VOD; оператор всё ещё может принудительно очищать кэш, используя версионированное имя файла при повторной кодировке – и это, к тому же, более чистый подход. Обратная крайность – тоже ошибка: слишком длинный max-age на live-сегменте, который уже устарел. Однако live-сегменты естественным образом выходят за пределы окна DVR за считанные минуты, и в большинстве случаев это не критично.

Ошибка четвёртая: shield в неправильном регионе. Как уже говорилось, единственная задача shield – находиться близко к origin, а не к аудитории. Команда, разместившая shield «в Европе, потому что там больше всего трафика», при этом разместила origin в us-east-1, тем самым добавила трансатлантический маршрут к каждому промаху в кэш, который она пыталась сократить. Диагностика проста: открыть дашборд и посмотреть на RTT shield→origin. Если он превышает 50 миллисекунд для обычного облачного региона – shield стоит не там, где нужно.

Ошибка пятая: предположить, что дефолт разумный. Несколько крупных CDN по умолчанию создают новые distribution с защитой отключённой. AWS CloudFront по умолчанию включает Origin Shield в режиме Off и требует ручного включения для каждого origin. Smart Tiered Cache у Cloudflare включён по умолчанию на одних тарифах и отключён – на других. Команда, перенаправившая DNS на CDN и ушедшая, может месяцами работать на дефолтных настройках без защиты, даже не замечая этого. Диагностика: сравните дашборд исходящего трафика origin с дашбордом edge egress CDN; если соотношение близко к 1:1, значит, защита не включена, и оператор платит за трафик, который должен был поглощать shield.

Где multi-CDN меняет картину

Когда оператор использует более одного CDN (тема статьи 6.4), вопрос с shield получает второй ответ. У каждого CDN – свой shield, и каждый из них видит только промахи на своих edge-серверах. Два CDN перед одним origin – и origin по-прежнему получает два отдельных потока промахов, по одному от каждого CDN, без какой-либо координации. Стандартное решение – общий origin shield: один shield, размещённый перед origin и за обоими CDN, чтобы потоки промахов от обоих CDN проходили через единый кэш перед тем, как дойти до origin. Varnish, Akamai Cloud Wrapper, кастомные кластеры на nginx, Squid или Apache Traffic Server – типичные реализации этого паттерна; AWS публикует reference-архитектуру, в которой один CloudFront Origin Shield в одном регионе выступает в роли общего shield для multi-CDN-развёртываний, где CloudFront является одним из CDN.

Компромисс – операционный. Общий shield – это единственная точка, через которую проходят все промахи CDN, а значит, именно её нужно правильно масштабировать, мониторить и обеспечивать высокой доступностью. Обычно общий shield разворачивают сразу в нескольких зонах доступности (AZ): AWS утверждает, что «все регионы Origin Shield построены по архитектуре с высокой доступностью, охватывающей несколько зон доступности, и включают автоматический переход на резервные регионы Origin Shield». Однако оператор всё равно обязан проверить работу failover под реальной нагрузкой до первого крупного события.

Cloud Wrapper, коммерческая реализация Akamai, прямо называет компромисс: он «поддерживает общую кэшируемость между CDN» и «централизованно кэширует данные по всем CDN, повышая количество попаданий в кэш и объединяя запросы с нескольких CDN перед отправкой к источнику» – тот же трюк, но на более высоком уровне. Подробности – в статье 6.4.

Три продакшен-архитектуры

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

Single-CDN с shield, один origin. Минимальная разумная архитектура для продакшена при live-нагрузке. Один CDN (AWS CloudFront, Cloudflare, Fastly или Akamai), включён Origin Shield в регионе, ближайшем к origin, и один origin за единым балансировщиком. На такой схеме работают 80% средних стриминговых сервисов – этого вполне достаточно для аудитории в десятки тысяч одновременных зрителей. Настройка занимает один инженерный день с подключением дашборда; по сравнению с базовым вариантом без shield – экономия на egress составляет 10–30 раз, как показано в примере.

Multi-CDN с общим shield перед одним origin. Стандартная архитектура для продуктов с сотнями тысяч и до нескольких миллионов одновременных зрителей. Два или три CDN (часто Akamai + CloudFront или Fastly + Cloudflare + региональный CDN) подключены к общему shield, развёрнутому на Varnish или CloudFront в роли shield. Сам shield обращается к одному origin. Слой steering – content steering для HLS и DASH (спецификация описана в статье 6.5) или сторонний DNS-роутер – определяет, какой CDN обслуживает каждого зрителя. Общий shield гарантирует, что origin видит единый поток промахов, а не несколько. Операционная сложность возрастает: появляется необходимость в настройке steering, расчёте мощности shield и отладке трёх-четырёх уровней кэширования.

Multi-CDN со встроенными ISP-аппаратами. Архитектура крупнейших стриминговых платформ – таких как Netflix Open Connect и YouTube Edge Cache – предполагает размещение специализированных устройств непосредственно в сетях интернет-провайдеров (ISP). Эти аппараты физически находятся внутри ISP-инфраструктуры, распространяют только контент конкретного оператора и для финального этапа доставки полностью обходят публичный интернет.

Сами устройства выступают в роли кэша перед edge CDN; edge CDN – перед региональным shield’ом оператора; а региональный shield – перед origin-сервером. Таким образом, формируется четыре физических уровня доставки.

Согласно опубликованной инженерной документации Netflix, аппараты Open Connect Appliances «обладают теми же возможностями, что и OCAs, используемые в наших более чем 60 глобальных дата-центрах», и обеспечивают коэффициент попадания в кэш (cache hit ratio) на уровне 99%+ для популярных контента.

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

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

Фора Софт строит видеоинфраструктуру с 2005 года, и иерархия кэшей – это слой, с которым мы работаем на каждом проекте: live и VOD для OTT и Internet TV, low-latency-трансляции для спорта и эспорта, видеоконференции, телемедицина – даже при небольшой аудитории shield на записывающем плече даёт выгоду, e-learning с комбинацией VOD-лекций и live-воркшопов, surveillance и AR/VR с жёсткими требованиями к задержкам. Мы проектируем многоуровневые топологии на AWS CloudFront, Cloudflare, Fastly, Akamai, Bunny и Google Media CDN, собираем общие shield на базе Varnish для клиентов, использующих несколько CDN, и настраиваем отслеживание коэффициента попадания в кэш по уровням, чтобы CFO оператора видел экономию уже на следующий день после включения shield.

Ключевые выводы

• Origin shield – это один выбранный кэш, расположенный глубоко в CDN, через который все промахи направляются к origin.
• Tiered caching – общая модель; shield является её самым глубоким уровнем. Три слоя – edge, регион, shield – образуют удобную конфигурацию по умолчанию.
• Shield снижает исходящий трафик с origin на порядок и более в режиме live; в нашем примере – в 12,5 раза.
• Request coalescing работает на уровне потока промахов, а shield – на уровне байтов. Оба механизма должны быть включены на каждом уровне.
• Региональный shield расположен близко к origin, но далеко от аудитории; конечные пользователи обслуживаются региональными кэшами.
• Пять типичных ошибок – ключ кэша на уровне пользователя, манифест на уровне пользователя, слишком короткий TTL для VOD, неправильный регион, отключённая по умолчанию защита – легко обнаруживаются и исправляются.

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

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

CTA

• Обсудите с инженером по стримингу вашу конфигурацию Shield и tiered cache: связаться.
• Ознакомьтесь с нашими кейсами в видеостриминге, OTT и live.
• Скачайте чек-лист настройки Origin Shield: PDF.