Хранение и раздача видео и медиаконтента через S3 и CDN: архитектура

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

В этой статье разберём референс-архитектуру медиаплатформы на российском S3: как заливать крупные файлы через multipart, как раскладывать контент по классам хранения, как отдавать его через CDN с экономией трафика, защищать presigned-ссылками и кодировать в Kubernetes. По объёмам и хранению петабайтов с быстрым доступом есть отдельный разбор — «Петабайты данных и быстрый поиск».

Почему для медиа так важно объектное хранилище

Медиаконтент растёт кратно и непредсказуемо, и это первый вызов для хранилища. Блочные диски ВМ нужно заранее провизионить под пиковую ёмкость, а реляционная БД не предназначена для бинарных объектов в десятки гигабайт. Объектное хранилище снимает оба ограничения: плоское пространство имён, доступ по HTTP, метаданные на каждом объекте и горизонтальное масштабирование без потолка.

Видео и фото растут быстрее, чем планируется любая ёмкость, поэтому хранилищу нужны безлимит и дешёвая стоимость гигабайта. Российский рынок СХД, по данным CNews, вырос с ₽50 млрд в 2024 году до прогнозных ₽54 млрд в 2025 году, и объектные хранилища — самый востребованный сегмент. Медиакомпании держат в S3 исходники, дорожки дубляжа, промо-материалы и резервные копии одновременно.

В VK Object Storage объём и число объектов не лимитированы, а суммарная ёмкость платформы — больше 400 ПБ. Durability достигает 99,999999% (восемь девяток): данные реплицируются, и вероятность потери объекта остаётся на уровне статистической погрешности. Это критично для хранения исходников, которые невозможно пересоздать: отснятый материал, мастер-копии, архивы съёмок. Платить при этом приходится только за фактически занятый объём с поминутным биллингом, а входящий трафик при загрузке — бесплатный.

Архитектура хранения данных в объектом хранилище

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

Поток медиаданных

Поток выглядит так: клиент → загрузка (multipart) → бакет VK Object Storage → CDN → зритель:

1. Клиент (мобильное приложение, веб-загрузчик, бэкенд-сервис) заливает файл частями напрямую в бакет, минуя промежуточный сервер приложения.
2. Бакет хранит объект и его версии, отдаёт метаданные и обслуживает lifecycle-политики.
3. CDN кэширует контент на edge-узлах (граничных узлах) ближе к зрителю и снимает основную нагрузку раздачи с хранилища.
4. Зритель получает сегменты с ближайшего узла, а не из дата-центра происхождения.

Ключевое архитектурное решение здесь — разделение записи и чтения. Загрузка идёт в origin-бакет, раздача — через кэширующий слой CDN. Бэкенд приложения не проксирует байты видео: он выдаёт ссылки и управляет правами, а тяжёлый трафик идёт мимо него. Это снимает с прикладного слоя до 85% нагрузки по сравнению с прямой раздачей через бэкенд.

Multipart-загрузка больших файлов

Крупное видео нельзя заливать одним PUT-запросом: при обрыве соединения вся загрузка стартует заново. Multipart-загрузка делит объект на части и грузит их независимо, с повтором только упавших фрагментов. По спецификации S3 API часть весит от 5 МБ до 5 ГБ, частей может быть до 10 000, а сам объект — до 5 ТБ. Multipart рекомендуется включать для файлов от 100 МБ.

Заливка крупного файла через aws-cli с S3-совместимым эндпоинтом VK Cloud выглядит так:

aws s3 cp master_4k.mov s3://media-origin/uploads/master_4k.mov \
  --endpoint-url https://hb.vkcs.cloud \
  --endpoint-url https://hb.vkcs.cloud \
  --expected-size 21474836480

aws-cli сам разбивает файл на части и собирает их на стороне хранилища. Для тонкого контроля размера части и параллелизма используйте низкоуровневый API в boto3:

import boto3
from boto3.s3.transfer import TransferConfig

s3 = boto3.client("s3", endpoint_url="https://hb.vkcs.cloud")

config = TransferConfig(
    multipart_threshold=100 * 1024 * 1024,   # multipart от 100 МБ
    multipart_chunksize=64 * 1024 * 1024,    # части по 64 МБ
    max_concurrency=8,                        # 8 параллельных потоков
)
s3.upload_file("master_4k.mov", "media-origin",
               "uploads/master_4k.mov", Config=config)

Полная совместимость с Amazon S3 API означает, что тот же код работает и с VK Cloud, и с любым другим S3 — без vendor lock-in.

Классы хранения для медиа

Не весь контент нужен одинаково часто, и платить за архив как за горячие данные расточительно. Классы хранения раскладывают объекты по уровням доступа: свежий трендовый ролик и съёмки пятилетней давности живут в одном бакете, но стоят по-разному. Lifecycle-политики переносят объекты между классами автоматически, по возрасту или по дате последнего обращения.

Горячее и холодное медиа

В VK Cloud два класса хранения: Hotbox и Icebox. Распределение по сценариям медиаплатформы:

Lifecycle-правило переносит объект из Hotbox в Icebox через заданное число дней без обращений.Пример политики через aws-cli:

aws s3api put-bucket-lifecycle-configuration \
  --bucket media-origin --endpoint-url https://hb.vkcs.cloud \
  --lifecycle-configuration file://lifecycle.json
{
  "Rules": [{
    "ID": "media-tiering",
    "Status": "Enabled",
    "Filter": {"Prefix": "archive/"},
    "Transitions": [{"Days": 30, "StorageClass": "ST-IA"}]
  }]
}

Та же логика работает для тяжёлых нестандартных форматов: готовые рендеры и проекты держат в Hotbox на время продакшена, сданные сцены уходят в архив. Российские системы для коллективной работы с 3D-данными строятся поверх объектного S3-хранилища.

CDN-раздача и кэш

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

Доставка через CDN

CDN кэширует медиа на edge-узлах и отдаёт его зрителю с ближайшей географической точки. Для VOD-сценария origin offload превышает 95%: больше 19 из 20 запросов обслуживаются с кэша, не доходя до исходного бакета. Нагрузка на бэкенд снижается до 85%, исходящий трафик origin по отраслевым оценкам сокращается до 60%. Дополнительную экономию даёт кодек: H.265 и AV1 урезают вес потока на 20–50% относительно H.264 при сопоставимом качестве.

VK Cloud CDN интегрируется с Object Storage из коробки, время отклика edge-узла — порядка 20 мс. Origin-бакет настраивается как источник, CDN сам подтягивает объекты при первом запросе и держит их в кэше по TTL. HLS/DASH-сегменты и плейлисты раздаются с edge, а origin принимает только «холодные» промахи кэша.

Защита контента и presigned URL

Публичный бакет означает, что любой со ссылкой скачает контент и встроит его к себе через хотлинк. Для платного и приватного медиа бакет держат закрытым, а доступ выдают точечно — временными подписанными ссылками. Presigned URL открывает один объект на ограниченное время и закрывается по истечении срока.

Закрытый доступ к файлам

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

Генерация presigned URL на чтение через boto3:

import boto3

s3 = boto3.client("s3", endpoint_url="https://hb.vkcs.cloud")

url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "media-origin", "Key": "premium/episode_07.mp4"},
    ExpiresIn=3600,   # ссылка живёт 1 час
)
print(url)

Бэкенд проверяет права пользователя, и только после этого выдаёт presigned URL на час. Для стриминга срок жизни ставят коротким и обновляют ссылку на сегменты по ходу сессии. Связка presigned URL с CDN дополнительно прячет origin: зритель получает подписанный путь к edge-узлу, а не прямой адрес бакета.

Кодирование и Kubernetes

Загруженное видео почти всегда нужно перекодировать: привести к нескольким битрейтам для адаптивного стриминга, нарезать на сегменты, сгенерировать превью. Транскодинг — пиковая по ресурсам задача: загрузок то нет, то сразу сотни. Держать под неё постоянный парк мощных серверов дорого, поэтому кодирование выносят в Kubernetes с автоскейлингом.

При HLS/DASH стриминге один исходный файл превращается в 5-6 копий от 360 до 4к + аудиодорожки и субтитры. Таким образом, 1 ТБ исходного видео генерирует 2.5–3 ТБ в S3 для раздачи.

Транскодинг с автоскейлингом

Pod забирает сегмент из VK Object Storage, кодирует его FFmpeg и кладёт результат обратно в бакет. Horizontal Pod Autoscaler (HPA) масштабирует число Pod'ов по загрузке CPU или по кастомным метрикам — например, по длине очереди задач. Cluster Autoscaler добавляет ноды в кластер, когда Pod'ам не хватает ресурсов на текущих узлах. Когда пик проходит, кластер сжимается обратно, и платформа не платит за простаивающие мощности.

Для медиа‑нагрузок автоскейлинг можно сделать событийным: Kubernetes Event‑driven Autoscaling (KEDA) масштабирует Pod'ы по внешним источникам — например, по длине очереди в RabbitMQ или по числу объектов/сообщений в S3‑очереди. Это маркер зрелой архитектуры: система реагирует не только на загрузку CPU, но и на фактический объём входящих задач транскодинга, быстро поднимая нужное количество воркеров ровно на период пика.

Видеоэнкодеры memory-intensive и многопоточны, чувствительны к раскладке памяти по NUMA-узлам. Pod'ам кодирования задают адекватные requests/limits по памяти и CPU, а на крупных нодах учитывают NUMA-привязку, чтобы потоки одного энкодера не разъезжались между узлами памяти. VK Cloud Managed Kubernetes интегрирован с VK Object Storage, поэтому Pod пишет результат прямо в S3-бакет без промежуточного хранилища: данные стримятся и сбрасываются в объектное хранилище через CSI‑драйвер или S3 API. За счёт этого не требуются постоянные сетевые диски большого объёма под временные медиафайлы — транскодинг остаётся лёгким по хранилищу и масштабируется за счёт вычислительных ресурсов.

Упрощённая схема HPA для пула транскодинга:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: transcoder-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ffmpeg-transcoder
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Медиа в VK Cloud

Собранная архитектура — это три компонента в одной платформе: S3-хранилище, CDN и Kubernetes. Они работают как единый конвейер, без интеграционного клея между разными вендорами.

Связка S3 + CDN + K8s

Референс-архитектура медиаплатформы на VK Cloud замыкает весь путь медиафайла. VK Object Storage хранит исходники и результаты транскодинга с durability до 99,999999% и SLA 99,95% с финансовой гарантией. Объём и число объектов не лимитированы, скорость доступа достигает 1 Гбит/с, классы Hotbox/Icebox/Glacier раскладывают контент по стоимости. CDN раздаёт контент с edge-узлов за ~20 мс, Managed Kubernetes кодирует видео с автоскейлингом.

Для российской медиаплатформы поверх технических характеристик лежит регуляторный слой. Дата-центры — Tier III в РФ, платформа аттестована по 152-ФЗ на уровень защищённости УЗ-1. С 1 января 2025 года запрещено использовать иностранное ПО на значимых объектах КИИ, с 1 сентября 2025 года значимые объекты КИИ переходят на софт из российского реестра. Спрос подтверждается цифрами: потребление S3 у одного из российских провайдеров выросло в 7 раз за год.

Полная совместимость с Amazon S3 API снимает vendor lock-in — мигрировать на VK Cloud можно без переписывания кода. Поминутный биллинг и бесплатный входящий трафик делают стоимость предсказуемой: платите за занятый объём и исходящий трафик, заливка ничего не стоит. Хранение 3D-данных и моделей устроено по той же схеме: тяжёлые рендеры и анимация уходят в архивные классы по lifecycle-политике.

Заключение

Облачное хранилище для видео работает на масштабе только как часть конвейера. Связка трёх компонентов закрывает весь путь медиафайла: VK Object Storage принимает крупные файлы через multipart и хранит их по классам Hotbox/Icebox/Glacier, CDN раздаёт контент с edge-узлов и снимает до 95% нагрузки с origin, Kubernetes кодирует видео с автоскейлингом под пики. Presigned URL закрывают приватный контент от хотлинка, lifecycle-политики управляют стоимостью архива. На VK Cloud эта архитектура собирается из S3 API-совместимых сервисов с durability до 99,999999%, аттестацией 152-ФЗ УЗ-1 и Tier III в РФ. Спроектировать хранение и раздачу медиа с контролем стоимости можно на российском S3 без vendor lock-in — отправная точка для расчётов и пилота описана в документации хранилища.