Origin Shield и Tiered Caching

TL;DR

Origin shield – это один выбранный кэш в глубине CDN, через который обязан пройти каждый запрос с каждого edge, прежде чем сеть получит право обратиться к origin оператора; tiered caching – это более широкая модель, при которой между edge и origin размещается несколько таких кэшей, и почти ни один live-сегмент не доходит до origin дважды. Смысл обоих приёмов одинаков: схлопнуть тысячи дублирующихся фетчей, которые рождаются на популярном стриме, в один upstream-запрос, а остальных зрителей обслужить из кэша. На продакшене включение shield снижает egress c origin на live-стриме в десятки раз и больше: в разобранном ниже примере 4,5 Gbps трафика с origin падают до 360 Mbps на той же аудитории, а вся настройка занимает у инженера полдня. Эта статья объясняет архитектуру, арифметику, имена и ручки у каждого вендора, а также четыре ошибки конфигурации, которые тихо съедают экономию, ради которой 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), через который проходят все upstream-запросы со всех edge, прежде чем им разрешат добраться до origin оператора. Кэш, который там стоит, – это обычный HTTP-кэш; shield его делает правило маршрутизации: «ни один edge не разговаривает с origin напрямую». Только shield общается с 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», «схлопывая дублирующиеся запросы» до того, как они дойдут до сервера оператора.

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

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

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

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

Shield решает оба сразу. Пятьсот edge-фетчей становятся пятьюстами shield-фетчами, но кэш shield наполняется первым из них и отдаёт остальные за микросекунды; origin видит один upstream-фетч. Thundering herd «схлопывается» shield, а bandwidth, уходящий с origin, сокращается на величину cache hit ratio shield – обычно 90–99% для популярного live, то есть в 10–100× меньше egress. Shield не убирает стоимость перемещения байтов; он переносит её со строки egress оператора на per-request и per-GB строку 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. Two-POP-шилдинг у Fastly использует один выбранный POP одновременно как региональный кэш и shield в зависимости от конфигурации.

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

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

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

Механика коалесинга умещается в один абзац. Когда десять тысяч зрителей просят у 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 по дефолту включают и то и другое для streaming-помеченных property; задача инженера – проверить, а не предположить.

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

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

Возьмём пример из реальных проектов. Спортивный стриминг с 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 обязан выгружать 1,500 × 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-промахи через shield. Cache hit ratio самого shield на этой нагрузке – около 92%, потому что shield видит объединённый поток промахов всех 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 c origin падает в 12,5× – точное отношение 0,12 / 0,0096, остаточная доля промахов после edge и shield. Счёт CDN-стороны остаётся приблизительно тем же – байты всё ещё уходят с CDN зрителю; меняется per-byte цена того перегона, который оплачивает оператор, потому что shield→origin – единственный перегон, который оператор оплачивает по тарифу public-egress. Чистая экономия в этом примере: более $80,000/мес на типичном ритме спортивного стриминга – за полдня настройки.

Та же арифметика работает в других масштабах для любой live-нагрузки. Прогоняйте её на своих числах до разговора с sales engineer 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 (зависит от региона), и большинство команд обнаруживают, что request-сторона возвращается экономией 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 видит постоянный ручеёк conditional GET от каждой ноды, которая сейчас его раздаёт. Лечение: max-age в днях или неделях для VOD; оператор всё ещё может пуржить версионированным именем файла, когда происходит ре-энкод, и это в любом случае более чистый паттерн. Обратная крайность – тоже ошибка: длинный max-age на live-сегменте, который уже устарел, – но live-сегменты естественно вываливаются из DVR-окна за минуты, и обычно это не критично.

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

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

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

Когда оператор использует более одного CDN (тема статьи 6.4), вопрос про shield получает второй ответ. У каждого CDN свой shield, и каждый shield видит только промахи своих edge. Два CDN перед одним origin – и origin по-прежнему получает два upstream-потока промахов, по одному на 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 пишет: «all Origin Shield regions are built using a highly-available architecture that spans several Availability Zones and includes automatic failover to secondary Origin Shield regions» – но оператор всё равно обязан подтвердить failover под нагрузкой до дня первого крупного события.

Cloud Wrapper, коммерческая реализация Akamai, прямо называет компромисс: он «maintains shared cacheability across CDNs» и «centrally caches across CDNs, improving cache hits and collapsing requests from multiple CDNs before going forward to origin» – тот же трюк на более высоком ярусе. Подробности – в статье 6.4.

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

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

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

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-сетей, раздают только контент оператора и для последнего перегона полностью обходят публичный интернет. Сами аппараты – это ярус кэша перед edge CDN; edge CDN – перед регионным shield оператора; регионный shield – перед origin. Четыре физических яруса. Опубликованная инженерная позиция Netflix: Open Connect Appliances «have the same capabilities as the OCAs that we use in our 60+ global data centres», и модель даёт 99%+ cache hit ratio на популярных тайтлах. Это золотой стандарт по производительности и цене, реально доступный только операторам, достаточно большим, чтобы ISP принимали их кастомный аппарат.

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

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

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

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

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

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

CTA

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