Стриминговый сервис для видео

Мы создали стриминговый сервис для видео, работающий по принципу сервисов коротких роликов (YouTube Shorts). В отличие от стандартного воспроизведения в браузере, где при перемотке нужно дать видеофайлу прогрузиться до нужного момента, ролики передаются чанками — небольшими последовательными блоками данных. Мы реализовали конвертацию видео в формат HTTP-стриминга, благодаря чему просмотр начинается с любой точки ролика, а качество видео подстраивается под скорость соединения пользователя. Такой подход ускоряет доступ к контенту

Изначально рассматривался вариант использования стандартного VK-плеера, но он не обеспечивал полный контроль над видео: пользователи могли удалять или блокировать ролики, что создавало риски для конкурса. Сейчас все видео полностью управляются на стороне платформы, что гарантирует стабильность работы стримингового сервиса и безопасное участие в конкурсе.

Проект рассчитан на высокую нагрузку, поэтому для обеспечения скорости и масштабируемости команда использовала аппаратное ускорение видеокарт. Конвертация выполняется на видеокарте благодаря отдельным аппаратным блокам NVENC и NVDEC, где тысячи ядер позволяют распараллелить обработку видеороликов. По это причине разгружается процессор, который занимается обработкой HTTP-запросов, работой с базой данных (Postgres, Redis), фоновых задач (Celery). Пользователи получают быстрый отклик системы и возможность загружать видео без задержек, а платформа сохраняет стабильность при большой активности.

Оптимизация архитектуры бэкенда

Бэкенд мини-приложения построен на Django Ninja — лёгком и быстром фреймворке для создания API на Python. Основная база данных — PostgreSQL, а Redis используется как кэш и брокер сообщений для Celery. Через Celery запускаются асинхронные задачи — например, конвертация видео. Это позволяет разгрузить сервер: когда пользователь загружает ролик, система не ждёт окончания обработки, а передаёт задачу отдельному воркеру.

Видео автоматически преобразуются в три варианта с разным разрешением — 480p, 720p и 1080p. Для каждого варианта настроены собственные параметры аудио- и видеобитрейта, чтобы оптимизировать размер и скорость загрузки чанков. Такой подход обеспечивает стабильное воспроизведение видео и экономное использование ресурсов.

Кроме конвертации, через Celery выполняются и фоновые процессы — например, запуск и завершение розыгрышей и конкурсов, обновление рейтинга.

Кэширование

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

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

2. Кэширование на уровне фронтенда.
Некоторые данные сохраняются в браузере пользователя, что позволяет повторно использовать результаты предыдущих запросов. Например, список призов кэшируется на несколько часов — при повторном открытии страницы данные подгружаются локально, без обращения к серверу.
Для рейтинга участников используется другой подход: результаты хранятся в materialized view в PostgreSQL, которая обновляется каждые пять минут. Браузер знает, когда произойдёт следующее обновление, и использует кэш до этого момента. Такой способ подходит для данных с известным временем актуальности.

3. Условные HTTP-запросы.
Если данные на сервере не изменились, приложение получает ответ без тела запроса — только подтверждение, что актуальная версия уже есть в браузере. Это сокращает объём передаваемых данных и ускоряет загрузку страниц.

Дополнительно в проекте реализовано сжатие статики в формате gzip. При сборке фронтенда HTML-, CSS- и JS-файлы автоматически архивируются и отдаются пользователю в сжатом виде. Благодаря этому уменьшается трафик и ускоряется загрузка интерфейса.

Мониторинг

Чтобы контролировать стабильность системы и вовремя реагировать на любые сбои, в проекте настроен мониторинг на базе стандартного стека: Prometheus, Grafana и Alertmanager.

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

Grafana визуализирует метрики в виде удобных дашбордов — команда может в реальном времени видеть состояние системы и производительность отдельных компонентов.

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

Дополнительно реализовано централизованное логирование — все сервисы передают логи в общее хранилище. Это позволяет быстро находить и анализировать ошибки.

Интеграция в VK

В отличие от Telegram Mini Apps, где приложения можно запускать без каких-либо предварительных согласований, во «ВКонтакте» предусмотрен обязательный процесс модерации. Он проходит в два этапа.

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

В качестве запасного плана рассматривался вариант перехода на Telegram Mini App. Бэкенд-сервисы уже были готовы к этому — достаточно было бы изменить схему авторизации. На фронтенде же пришлось бы существенно переработать код: SDK Telegram и VK Mini Apps различаются по структуре и набору функций. К счастью, этот сценарий не понадобился — приложение успешно прошло модерацию и было опубликовано в каталоге VK Mini Apps.