Как создать архитектуру YouTube с Kafka, S3 и адаптивным стримингом

Эта статья основана на курсе Кирти Пурвани (Keerti Purwani), опубликованном на канале freeCodeCamp.org. В ней подробно разбирается процесс создания архитектуры видеоплатформы уровня YouTube с нуля, включая вопросы загрузки, транскодирования и адаптивного стриминга.

📺 Эволюция пет-проектов: почему обычные клоны больше не работают 0:00

Современный рынок разработки ПО стал чрезвычайно конкурентным. По мнению автора курса Кирти Пурвани, создание простых веб-приложений или визуальных клонов известных сервисов больше не впечатляет работодателей . Сегодня от инженера ожидают понимания принципов системного проектирования (High-Level Design, HLD). Данный проект — это не просто интерфейс YouTube, а полноценная распределенная система, включающая:

Три независимых микросервиса: Upload Service, Watch Service и Transcoder Service .
Инфраструктуру обмена сообщениями на базе Apache Kafka .
Реляционную базу данных PostgreSQL для метаданных .
Облачное хранилище S3 и сложные алгоритмы обработки видео .

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

🏗️ Первый этап: ядро системы и клиентская часть 4:38

Проектирование начинается не с архитектуры, а с реализации базовых функций. Кирти рекомендует начинающим разработчикам сначала сфокусироваться на трех столпах: загрузке (upload), просмотре (watch) и преобразовании (transcode) .

Для реализации видеоплеера на стороне клиента (Next.js) используется библиотека react-player . На первом этапе система учится трем вещам:

Воспроизведению любого внешнего URL с YouTube .
Стримингу собственного видео и аудио пользователя (аналог функционала Zoom) .
Воспроизведению файлов напрямую из публичного бакета S3 .

Затем создается Upload Service на Node.js . Изначально это простейший API, который принимает файл и отправляет его в облако S3. Автор подчеркивает важность поэтапного усложнения: сначала загружается обычная PNG-картинка, затем маленькое видео, и только потом система переходит к обработке тяжелого контента .

🔐 Аутентификация и безопасность 13:00

Безопасность системы реализована через протокол OAuth с использованием библиотеки NextAuth.js . Выбор пал на авторизацию через Google, так как это стандарт для современных платформ.

Ключевые технические детали:

Логика аутентификации выполняется на серверной стороне Next.js .
Для настройки требуется конфигурация в Google Cloud Console .
Только авторизованные пользователи получают доступ к функционалу загрузки видео .

📨 Внедрение Apache Kafka и принципов HLD 15:11

Когда базовый поток «клиент — сервер — S3» отлажен, Кирти вводит концепции High-Level Design. Прямая загрузка видео неэффективна, так как после получения файла система должна выполнить множество ресурсозатратных задач: фильтрацию контента на запрещенные материалы, проверку авторских прав и, самое главное, транскодирование в разные разрешения (1080p, 720p и т.д.) .

Для решения этой задачи используется паттерн Pub-Sub (Publisher-Subscriber) на базе Kafka :

Upload Service выступает в роли продюсера (Producer): после завершения загрузки он отправляет сообщение в топик transcode .
Transcoder Service выступает в роли потребителя (Consumer): он «слушает» топик и начинает обработку видео, как только появляется новое задание .

Автор использовала облачное решение Aiven для развертывания Kafka и PostgreSQL, отмечая его удобство для обучения .

📦 Чанкинг и Multipart Upload в S3 20:15

Загрузка 10-гигабайтного файла одним куском практически невозможна из-за ограничений сети и высокого риска сбоев. Решением является чанкинг — разделение видео на мелкие части (чанки) .

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

Для сборки видео на стороне S3 используется механизм Multipart Upload, состоящий из трех этапов :

Initiation: Запрос на начало загрузки, получение uploadID .
Parts Upload: Параллельная отправка кусков. За каждую часть S3 возвращает eTag (уникальный идентификатор части) .
Completion: Отправка массива всех eTag и partNumber. После этого S3 автоматически «склеивает» видео в один файл .

📈 Балансировка и параллелизм 37:17

Для оптимизации загрузки Кирти использует массив промисов в JavaScript. Вместо того чтобы ждать завершения загрузки каждого чанка по очереди (await внутри цикла), клиент отправляет все части сразу, а затем ожидает их завершения через Promise.all . Это создает нагрузку на бэкенд, но при наличии балансировщика нагрузки (Load Balancer) позволяет достичь максимальной пропускной способности канала .

🗄️ Watch Service и работа с метаданными 39:15

Когда видео оказывается в S3, данные о нем должны быть доступны для поиска и отображения. Для этого создается Watch Service и база данных PostgreSQL.

В качестве ORM используется Prisma . Процесс выглядит так:

После того как S3 подтвердил сборку файла, Upload Service получает финальный URL.
Метаданные (название, описание, автор, ссылка на S3) записываются в БД через Prisma .
Watch Service предоставляет API для получения списка всех видео (findMany) .

Кирти упоминает технологию Vitess, которую YouTube использует для горизонтального масштабирования MySQL, но в рамках учебного проекта ограничивается классической PostgreSQL .

🔄 Адаптивный стриминг (HLS) и транскодирование 59:00

Самая сложная часть проекта — реализация Adaptive Bitrate Streaming. Это технология, позволяющая видеоплееру автоматически менять качество видео (например, с 1080p на 480p) при ухудшении интернет-соединения .

Для реализации используется протокол HLS (HTTP Live Streaming) от Apple . Суть процесса:

FFMPEG: Программное обеспечение, которое перекодирует исходное видео в несколько разрешений (320p, 480p, 720p) одновременно .
Сегментация: Каждое видео режется на 10-секундные кусочки с расширением .ts .
Манифест (.m3u8): Текстовый файл-плейлист, который содержит ссылки на все сегменты. Создается «мастер-плейлист», который указывает плееру, какие файлы соответствуют какому разрешению .

🛠️ Модель «S3 to S3» 1:17:46

Финальная схема работы Transcoder Service выглядит так:

Сервис скачивает оригинал видео из S3 во временную локальную папку .
Запускает процесс транскодирования через бинарные файлы ffmpep-static .
Создает структуру папок с манифестами и сегментами.
Загружает всю структуру обратно в S3 и удаляет локальные временные копии .

🏁 Резюме архитектуры (HLD Diagram) 1:21:43

В завершение Кирти сводит все компоненты в единую диаграмму:

Клиент (Next.js) инициирует загрузку чанками.
Upload Service управляет Multipart Upload в S3, пишет метаданные в PostgreSQL и кидает задачу в Kafka.
Transcoder Service забирает задачу, скачивает видео, дробит его на сегменты для разных разрешений через FFMPEG и возвращает результат в S3.
Watch Service отдает клиенту ссылки на HLS-манифесты из базы данных.

По словам автора, реализация такой системы дает инженеру «не просто проект для портфолио, а глубокое понимание того, как работают высоконагруженные платформы в реальности» .