Как Yandex Cloud CDN и Yandex Object Storage разгружают высоконагруженную инфраструктуру

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

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

Универсальное масштабируемое S3-хранилище Yandex Object Storage берёт на себя хранение и приём большого объёма данных, а сервис Yandex Cloud CDN ускоряет доставку контента пользователям и снижает количество обращений к источнику.

Типовая архитектура высоконагруженного приложения

Обычно архитектура приложения для обработки клиентских запросов состоит из нескольких основных компонентов:

В Yandex Cloud для этих компонентов можно использовать разные сервисы. Например, для балансировки доступны Yandex Application Load Balancer на уровне L7 и Yandex Network Load Balancer на уровне L4. Бэкенд можно строить на виртуальных машинах Yandex Compute Cloud, физических серверах Yandex BareMetal или в контейнерной инфраструктуре Yandex Managed Service for Kubernetes^®.

Для хранения данных доступны управляемые базы данных, локальные диски разной производительности и объектное хранилище. Дополнительно можно использовать сервисы безопасности, например Yandex Audit Trails и Yandex Smart Web Security.

Но даже при такой архитектуре остаётся вопрос: нужно ли пропускать весь тяжёлый поток данных через бэкенд? В большинстве сценариев — нет.

Сценарий 1. Загрузка контента через бэкенд

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

Типовая архитектура такого решения выглядит так:

1. Пользователь открывает приложение.
2. Приложение отправляет фотографию на бэкенд.
3. Бэкенд аутентифицирует и авторизует пользователя.
4. Бэкенд принимает файл.
5. Бэкенд передаёт файл в Yandex Object Storage.
6. Через очередь сообщений задача отправляется в ML-компонент для обработки изображения.

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

Если множество пользователей одновременно загружает фотографии по мобильному интернету, принимающей стороне нужно:

• буферизовать данные;
• дожидаться полной загрузки файлов;
• обрабатывать повторные попытки загрузки;
• расходовать CPU и RAM;
• удерживать соединения;
• при необходимости использовать локальные диски для временной буферизации;
• затем всё равно сохранять данные в Yandex Object Storage.

Получается, что бэкенд выполняет промежуточную работу, хотя конечное место хранения контента — объектное хранилище.

Оптимизированный сценарий: прямая загрузка в Yandex Object Storage

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

Схема меняется так:

1. Пользователь обращается к приложению.
2. Бэкенд аутентифицирует и авторизует пользователя.
3. Бэкенд выдаёт клиенту подписанную ссылку или STS-токен.
4. Клиентское приложение напрямую загружает файл в Yandex Object Storage.
5. Бэкенд передаёт задачу дальнейшим обработчикам, которые забирают данные из хранилища.

В этом сценарии бэкенд остаётся управляющим компонентом, но перестаёт быть транзитным каналом для тяжёлого контента.

Control Plane и Data Plane: зачем их разделять

Ключевая идея оптимизированной архитектуры — разделить Control Plane и Data Plane.

Такое разделение разгружает бэкенд по трафику и ресурсам. Бэкенд больше не должен принимать и буферизовать тяжёлые файлы, а Yandex Object Storage принимает данные напрямую.

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

Почему Yandex Object Storage подходит для таких сценариев

Yandex Object Storage хорошо подходит для хранения медиафайлов, изображений, видео, логов и другого контента, который нужно масштабируемо принимать и отдавать.

У Yandex Object Storage в этом сценарии есть несколько важных преимуществ:

При этом Yandex Object Storage не заменяет базы данных. Транзакционные данные, счётчики, текстовые переменные и другие структурированные данные по-прежнему логичнее хранить в базах данных. Они будут проходить через бэкенд, но объём такого трафика обычно значительно меньше, чем поток тяжёлого медиаконтента.

Сценарий 2. Доставка контента пользователям

Второй сценарий — получение контента конечными пользователями. По сути это обратный поток: клиент запрашивает данные, они берутся из Yandex Object Storage или другого источника и возвращаются пользователю.

Самый простой вариант — после аутентификации и авторизации бэкенд выдаёт пользователю подписанную ссылку или STS-токен, а пользователь получает файл напрямую из Yandex Object Storage.

Но для массовой раздачи контента более эффективно добавить Yandex Cloud CDN между источником данных и конечными пользователями.

Как Yandex Cloud CDN разгружает источник данных

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

Схема выглядит так:

1. Пользователь запрашивает контент.
2. Запрос приходит на ближайшую точку присутствия CDN.
3. Если контент уже есть в кеше, CDN отдаёт его сразу.
4. Если контента в кеше нет, CDN обращается к источнику данных.
5. Полученный контент кешируется и дальше отдаётся другим пользователям из кеша.

Так CDN решает сразу несколько задач:

На вебинаре мы отмечали, что у Yandex Cloud CDN — более 60 точек присутствия по миру и более 7 Тбит свободной ёмкости. Сеть активно развивается: мы добавляем примерно одну точку присутствия в неделю.

Yandex Object Storage и Yandex Cloud CDN вместе: что получается

Yandex Object Storage и Yandex Cloud CDN можно использовать независимо, но максимальный эффект возникает, когда они работают вместе.

Yandex Object Storage принимает и хранит тяжёлый контент, а Yandex Cloud CDN раздаёт его конечным пользователям из кеша. Бэкенд при этом занимается управляющей логикой: авторизацией, выдачей токенов, созданием заданий на обработку, работой с базами данных и бизнес-процессами.

Упрощённо роли можно разделить так:

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

Экранирование: дополнительный слой кеширования перед источником

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

Если точек присутствия больше 60, в худшем случае источник может получить десятки запросов к одному и тому же объекту. Для Yandex Object Storage это важно ещё и потому, что в S3-хранилище есть плата за операции, а постоянная работа с одним и тем же ключом может быть не самым эффективным сценарием.

Для оптимизации используется экранирование — дополнительный слой кеширования между точками присутствия CDN и источником данных.

Экранирование работает так:

1. Точки присутствия CDN обращаются не напрямую к источнику, а к shield-слою.
2. Он обращается к источнику данных.
3. Полученный контент распространяется на точки присутствия CDN.
4. Источник получает меньше повторяющихся запросов.

Это ещё сильнее разгружает бэкенд или Yandex Object Storage и помогает лучше выдерживать высокие нагрузки на контент.

Защищённый доступ к контенту через CDN

Если контент нельзя отдавать всем пользователям, можно использовать механизм защищённого доступа.

Бэкенд выписывает специальный токен с ограниченным сроком действия. Этот токен позволяет конкретному клиенту получить доступ к определённому контенту через CDN. По смыслу это похоже на подписанные ссылки в S3-хранилище, но применяется на стороне CDN.

Проверка токена выполняется на точках присутствия. После этого CDN обращается к источнику или shield-слою, кеширует данные и отдаёт их пользователю.

Так можно совместить две задачи:

• ограничить доступ к контенту только для авторизованных пользователей;
• не возвращать весь поток скачивания обратно на бэкенд.

Выделенная IP-адресация в Yandex Cloud CDN

Иногда нужно, чтобы контент раздавался только с определённых IP-адресов. Например, эти адреса могут потребоваться для добавления в группы безопасности, «белые списки» IP-адресов или другие контуры доступа.

Для этого в Yandex Cloud CDN есть выделенная IP-адресация. Она позволяет назначить CDN-ресурсу выделенный IP-адрес, закреплённый только за ресурсами конкретного клиента.

Важны несколько деталей:

• выделенный IP-адрес резервируется за клиентом;
• с этого IP-адреса не будет раздаваться чужой контент;
• IP-адрес можно подать в «белые списки» Минцифры России;
• при этом адрес работает через Anycast-балансировку;
• все точки присутствия CDN продолжают обслуживать трафик к ресурсу.

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

Возможности Yandex Cloud CDN

Отдельно в вебинаре мы перечислили возможности Yandex Cloud CDN для настройки доставки контента. Условно их можно разделить на несколько групп:

CDN может использовать источники как внутри Yandex Cloud, так и за его пределами. Источником может быть Yandex Object Storage, балансировщик, виртуальная машина, сервер, собственная инфраструктура или ресурс у другого провайдера.

Локационные правила и разные источники под одним доменом

Одна из продвинутых возможностей Yandex Cloud CDN — правила на основе регулярных выражений. Они позволяют по-разному обрабатывать разные типы контента.

Например:

• файлы конфигурации можно кешировать на короткое время;
• статические изображения и видео — на более длительное;
• запросы с префиксом /static отправлять к источнику со статическим контентом;
• запросы с префиксом /api отправлять на бэкенд с динамическим контентом;
• для файлов с расширением JPG задать отдельное время кеширования.

Так под одним доменом можно объединить несколько источников и настроить разные правила доставки для разных частей приложения.

Настройка CDN-ресурса: что показали в демо

В демонстрации на вебинаре мы использовали источник контента в регионе Казахстан и CDN-ресурс в российском облаке. Источником был бакет Yandex Object Storage, в котором находились два файла: изображение размером 10 МБ и index.html для тестирования производительности.

В настройках CDN-ресурса мы показали:

• группу источников
• основной источник — Yandex Object Storage в Казахстане
• возможность добавить дополнительные primary-источники
• возможность добавить secondary-источник для отказоустойчивости
• настройку доступа к источнику
• подключение SSL-сертификата через Yandex Certificate Manager
• поддержку Let’s Encrypt
• настройки шифров и редиректов
• переход по редиректам при определённых кодах ответа
• кеширование по настройкам источника или вручную
• ручную настройку времени кеширования вплоть до одного года
• HTTP-заголовки
• разрешённые методы
• очистку и предзагрузку контента
• выгрузку логов
• экранирование
• локационные правила

Для теста десятимегабайтный файл был заранее предзагружен на точки доступа CDN, после чего сравнивалась загрузка напрямую из Yandex Object Storage и через CDN.

Результаты демо

В тесте мы сравнили два URL:

• прямой URL на бакет Yandex Object Storage в Казахстане
• домен CDN-ресурса

Тест выполняли из Москвы. Источник контента находился в Казахстане, в Караганде.

После нескольких загрузок на «прогретых» данных средние результаты были такими:

Разница составила около 250 мс. В относительных величинах контент через CDN загружался примерно в 2,5 раза быстрее.

Ускоряет ли CDN динамический контент без кеширования

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

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

В вебинаре мы показывали пример: приложение демонстрирует актуальные валютные котировки, которые обновляются раз в несколько секунд. Если страницу запрашивают 1000 RPS, нет смысла каждый раз отправлять запрос в бэкенд, если данные обновляются не 1000 раз в секунду. Можно закешировать ответ на несколько секунд, и тогда точки присутствия CDN будут отдавать большую часть запросов пользователям, а источник будет получать значительно меньше обращений.

CDN и защита от DDoS-атак

В Yandex Cloud CDN есть встроенная защита от DDoS-атак на уровне точек присутствия. На вебинаре мы отдельно поговорили про L4-атаки, например SYN-флуд. За счёт большого количества точек присутствия, широких каналов и распределения трафика CDN помогает справляться с такими атаками на низком уровне.

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

Для защиты от атак на уровне L7 рекомендуем использовать дополнительную защиту перед источником после CDN — например, с помощью сервиса Yandex Smart Web Security.

Нужно ли выбирать между прямой загрузкой в Yandex Object Storage и CDN

Это не взаимоисключающие подходы. Разделение Control Plane и Data Plane через Yandex Object Storage помогает разгрузить бэкенд при загрузке и получении тяжёлого контента. CDN помогает ускорить доставку этого контента пользователям и снизить нагрузку на источник. Их можно использовать отдельно, вместе или в разных частях одной архитектуры.

Например, приложение может загружать фотографии напрямую в Yandex Object Storage, а затем раздавать обработанные изображения пользователям через Yandex Cloud CDN. Бэкенд при этом остаётся управляющим слоем, но не принимает на себя весь поток файлов.

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

Yandex Object Storage и Yandex Cloud CDN помогают разгрузить высоконагруженную инфраструктуру за счёт правильного разделения ролей между компонентами.

Главные идеи:

• Не весь трафик должен проходить через бэкенд.
  Тяжёлый медиаконтент можно загружать напрямую в Yandex Object Storage по подписанным ссылкам или STS-токенам.
• Control Plane и Data Plane лучше разделять.
  Бэкенд управляет авторизацией и бизнес-логикой, а поток данных идёт напрямую в хранилище или через CDN.
• Yandex Object Storage подходит для масштабируемого хранения контента.
  Он помогает принимать большие объёмы данных, обеспечивает отказоустойчивость и позволяет платить за фактически используемый объём.
• Yandex Cloud CDN ускоряет доставку и снижает нагрузку на источник.
  Контент отдаётся из ближайших точек присутствия, а источник получает меньше повторных запросов.
• Экранирование снижает нагрузку ещё сильнее.
  Дополнительный слой кеширования между CDN и источником помогает избежать множества одинаковых обращений к источнику.
• Для защищённого контента можно использовать токены.
  Бэкенд выдаёт временный токен, а CDN проверяет его на точках присутствия.
• CDN полезен не только для статического, но и для части динамического контента.
  Если данные обновляются раз в несколько секунд, короткое кеширование может значительно снизить нагрузку на бэкенд.
• Для L7-защиты нужен отдельный слой безопасности.
  CDN помогает с низкоуровневыми DDoS-атаками, но для прикладного уровня рекомендуется использовать дополнительные средства, например Yandex Smart Web Security.

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