Одна CDN — хорошо, а две — лучше? Как Multi-CDN помогает экономить на ИТ-инфраструктуре

Основные принципы, которые позволят вам использовать несколько сетей доставки контента не только эффективно, но и выгодно.

Multi-CDN может быть эффективна по многим параметрам. Вы не зависите от одного провайдера, нет единой точки отказа, географическое покрытие шире, скорость доставки контента выше.

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

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

Краткий ликбез: какие задачи решает Multi-CDN

Multi-CDN — архитектура, в которой трафик распределяется между несколькими независимыми CDN-провайдерами.

Для чего это нужно:

  • Дополнительное покрытие

  • Требование резервирования

  • Балансировка цены за CDN (несколько провайдеров становятся конкурентами)

С первыми двумя пунктами, в целом, всё понятно. Вы подключаете больше CDN, получаете больше точек присутствия, лучшую связность и возможность резервирования. А вот третий пункт — далеко не самый очевидный. Тем не менее Multi-CDN действительно помогает снизить затраты:

  • Minute Media, одна из крупнейших международных медиакомпаний, сократила расходы на доставку контента на 30% с помощью грамотной Multi-CDN-стратегии.

  • RGE Media Group, крупное медиа с несколькими ТВ-каналами и цифровой платформой, внедрила Multi-CDN с балансировкой трафика по регионам. В результате расходы на CDN сократились на 30%.

  • StreamFlow, платформа для ретрансляции прямых эфиров, внедрила Multi-CDN, и это помогло сократить расходы на стриминг на 23%.

В Российских реалиях чаще работает логика конкуренции между основными игроками рынка.

Статистика для грамотной маршрутизации

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

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

Что советуем обязательно сделать:

1. Запрашивать у провайдеров CDN сырые логи. Они дадут более детальное представление о работе сетей. Здесь лучше всего реализовать собственную единую аналитическую систему, куда будут собираться все логи из всех сетей. Сделать это можно, например, через Kafka или Vector в базы данных ClickHouse или VictoriaMetrics. Это даст вам полную картину работы Multi-CDN.

2. Запрашивать статистику в одно и то же время, за одинаковые временные промежутки. Так будет проще свести данные в единое целое.

3. Указать одинаковые HTTP-заголовки, которые CDN-серверы будут добавлять в запросы и ответы. Так вам будет проще анализировать информацию.

4. Собирать RUM-метрики: TTFB, Core Web Vitals, буферизация и т.д. Это покажет вам, как ваши веб-ресурсы реально работают у ваших пользователей.

Классические схемы оптимального распределения трафика

Итак, мы настроили статистику, которая даёт нам понять, как именно работает каждая сеть. Дальше маршрутизацию мы настраиваем, исходя из этих данных. 

Как именно всё будет настроено у вас — зависит от особенностей вашего проекта. Здесь я приведу несколько самых распространённых вариантов балансировки для примера.

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

Если у вас через CDN идёт стабильный поток трафика, но при этом периодически бывают скачки нагрузки (например, во время распродаж или важных релизов), выгодно будет совместить пакетное решение с PAYG (Pay-As-You-Go, оплата за фактически потраченные ресурсы). И тогда ваша постоянная нагрузка ложится на сеть с дешёвым пакетным тарифом, а пиковые скачки направляются на CDN с более выгодным PAYG.

Допустим, компания нашла выгодный пакет на 1 ПБ трафика в месяц за 700 000 ₽. Но превышение трафика на тарифе стоит 2 ₽. А у компании временами случаются скачки трафика во время крупных событий и больших онлайн-трансляций. Из-за них пакет перерасходуется на 100 ТБ в месяц.

Но есть ещё одна CDN, у которой нет таких выгодных пакетных предложений, но трафик стоит 1 ₽/ГБ.

Если направлять весь трафик через CDN с выгодным пакетом, то в месяцы пиковых скачков общие расходы на CDN-трафик будут 700 000 + (100 000 ГБ х 2) = 900 000 ₽.

А если дополнительную нагрузку направить по второй CDN с выгодным PAYG, то получится: 700 000 + (100 000 ГБ х 1) = 800 000 ₽.

Общая экономия: 11%.

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

Но чем более продвинутая CDN, тем выше бывает ценник на её услуги. При этом для доставки обычных картинок и CSS многие передовые фичи бывают просто не нужны.

Если в вашем проекте много и статики, и динамики, можно их разделить. Для статики выбрать более дешёвую сеть с простым тарифом. А динамику раздавать через более дорогую CDN, которая умеет её ускорять.

Допустим, 5 ТБ трафика в месяц у компании — статика, при этом около 50 ГБ в месяц приходится на динамику. CDN с тарифом 1 ₽ за гигабайт трафика отлично справляется со статикой, но никак не ускоряет динамический контент. Другая более навороченная CDN умеет ускорять динамику, но тариф у неё уже 2 ₽ за гигабайт.

Если использовать навороченную CDN, расходы в месяц на весь контент будут: (5 000 ГБ + 50 ГБ) х 2 = 10 100 ₽

А если направить статику через более дешёвую сеть, а динамику через более дорогую, получится: (5 000 ГБ х 1 ₽) + (50 ГБ х 2 ₽) = 5 100 ₽.

Экономия: 49%.

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

Например, 3 ПБ востребованного и важного контента вы направляете через крутую сеть и платите за них 6 млн ₽. А ещё 1 ПБ менее важного и востребованного контента идёт через более дешёвую сеть, и на него вы тратите 1 млн ₽ вместо 2 млн ₽ (сколько бы он стоил в дорогой сети). Общая экономия получается около 12%.

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

Шилдинг: экономим не только на CDN-трафике, но и на трафике облака

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

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

Разбираемся на примере. Компания «Крутое медиа» в среднем отдаёт пользователям около 10 ПБ трафика в месяц. При этом у них часто выходят новости, обновления, и в кеш Multi-CDN в среднем попадает около 80% всего трафика. За остальными 20% CDN обращается к источнику.

Шилдинг источников у разных CDN стоит по-разному, но в среднем цена колеблется около 4 000 ₽/мес. за ресурс. Давайте считать.

Процент попадания в кеш

Объём трафика от источника к CDN

Расходы на трафик

Расходы на шилдинг

Общие расходы

Без шилдинга

80%

2 ПБ

1,4 млн ₽

(2 млн ГБ х 0,7 ₽ = 1,4 млн ₽)

0 ₽

1,4 млн ₽ 

С шилдингом

95%

0,5 ПБ
или 500 000 ГБ

350 000 ₽

(500 000 ГБ х 0,7 ₽ = 350 000 ₽)

20 000 ₽

370 000 ₽

Экономия при таком раскладе — 73%.

По нашему опыту, подключение шилдинга сокращает расходы на трафик в облаке в среднем на 50-80%. Но здесь, конечно, всё индивидуально и зависит от специфики вашего проекта.

Дополнительные опции: выбираем самые выгодные

Функции многих современных CDN не ограничены простой доставкой контента. К примеру, EdgeCDN умеет:

  • сжимать контент на лету;

  • изменять изображения;

  • защищать контент от несанкционированного доступа с помощью Secure token (безопасных ссылок с ограниченным сроком действия) и заголовков CORS;

  • ограничивать скорость загрузки контента.

И это далеко не полный список.

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

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

Типичные ошибки при настройке Multi-CDN, которые увеличивают чек

Несинхронизированные политики кеширования. Из-за разных настроек TTL или заголовков процент попадания в кеш на разных CDN может сильно отличаться. Может возникнуть ситуация, когда одна CDN кеширует контент на 95%, а вторая — на 60%. Это приводит к лишним запросам к источнику и, соответственно, к перерасходу трафика в облаке.

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

Использование только внутренней статистики CDN-провайдеров. Так как она у всех разная, свести разрозненные данные в единую картинку очень сложно.

Собирайте сырые логи в единую аналитическую систему. Так данные будет проще анализировать.

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

Если одна сеть упала, переводите трафик на другую постепенно: например, сначала 10%, потом 20%, потом 50% и так далее. Сильно затягивать тоже не стоит, чтобы ваши ресурсы остались доступны. Идея в том, чтобы не переключаться слишком резко, чтобы не перегрузить и резервную сеть, и сервер-источник, и не сделать недоступным вообще всё.

Балансировка трафика с помощью DNS

Распределять нагрузку между разными CDN можно разными способами. Иногда для этого советуют продвинутые балансировщики. Однако, если мы говорим про экономию, наверное, самый дешёвый способ — балансировка с помощью DNS. Да, этот метод имеет свои ограничения. Но нужно понимать, что в основе даже самых продвинутых балансировщиков часто прячется обычный DNS с добавленными к нему скриптами.

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

По географическому принципу трафик можно распределять по таким параметрам:

  • ASN

  • Континент

  • Страна

  • Координаты (широта и долгота)

  • Регионы России

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

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

Напоследок: когда Multi-CDN вообще не нужна

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

Тут, опять же, нужно всё считать индивидуально. Приведём несколько классический примеров, когда Multi-CDN-стратегия точно не помогает:

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

  • Достаточно однородный контент. Например, в основном статика и мало динамики. Невозможно разделить его так, чтобы можно было пользоваться преимуществами разных CDN. В этом случае проще раздавать всё через одну сеть.

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

  • Много динамики. Приложениям, в которых большая часть контента — динамика, использование даже одной CDN вообще может быть неоправданно. Какими бы навороченными не были современные сети, с раздачей статики они справляются сильно лучше.

Подведём итоги

Сколько будет стоить Multi-CDN, во многом зависит от настроек балансировки.

Базовые стратегии собрали для вас в наглядную таблицу. Дополнительно отметим, что данные по экономическому эффекту — примерные и не означают, что у вас будет именно такая экономия. Размер сокращения затрат во многом зависит от специфики проекта.

Стратегия

Кому подходит

Примерный экономический эффект

Разделение на постоянный и пиковый трафик

Онлайн-ритейл, геймдев, видеотрансляции и другие проекты, где часто случаются внезапные крупные скачки трафика

10-15%

Разделение статики и динамики

Маркетплейсы, социальные сети, мессенджеры и другие платформы, где много и динамического, и статического контента.

35-50%

Разделение контента по востребованности

Онлайн-ритейл, медиаплатформы, где много контента с разной частотой запросов.

10-15%

Шилдинг источника

Live-стримы, медиа, проекты с тяжёлым контентом, источник которого размещён в публичном облаке.

50-80%

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

Источник: habr.com

0 0 голоса
Рейтинг новости
1
0
Подписаться
Уведомить о
0 комментариев