Видеоплатформа для трёх миллионов видео в сутки

Продолжаем серию расшифровки выступлений спикеров на VK Tech Talks | Backend. На этот раз разберем доклад тимлида бэкенд-инфраструктуры Александра Светкина про видеоплатформу ВКонтакте.

Видео ВКонтакте сегодня — это более трёх миллионов видеофайлов и 125 ТБ данных ежедневно. С прошлого года эти значения увеличились примерно в 1,5 раза.

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

  1. Создаём несколько разрешений в адекватном битрейте;
  2. Выравниваем ключевые кадры для всех разрешений;
  3. Поворачиваем видео;
  4. Нормируем частоту кадров;
  5. Используем кодеки H264 (видео), AAC (аудио);
  6. Создаём обложки и скриншоты.

Обработка видео осуществляется просто: когда пользователь хочет загрузить его, он получает через API ссылку на конкретный кодировщик из пула машин. Он загружает видео методом POST, видео начинается обрабатываться, а кодировщик создаёт несколько копий в уменьшенном битрейте и отправляет их в хранилище.

Видеоплатформа для трёх миллионов видео в сутки, image #1

Что «под капотом» этой системы?

Видеоплатформа для трёх миллионов видео в сутки, image #2

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

Видеоплатформа для трёх миллионов видео в сутки, image #3

Что в этой системе нас не устраивало? Что «болело»:

  1. Долгая обработка длинных видеозаписей;
  2. Скопление файлов на отдельных кодировщиках;
  3. Лишняя нагрузка на CPU, о который мы не знали;
  4. Слишком много кодировщиков в работе.

Повышение параметра -threads у ffmpeg, чтобы кодировать в очень много потоков, было хоть и простым решение, но нерабочим. На деле увеличение количества потоков с 6 до 24 не даст прирост в 4 раза. Решением этой проблемы стало сегментированное кодирование: каждое поступающее длинное видео разрезается на 4 части и каждая часть кодируется независимо и параллельно, после чего все части склеиваются. Такой подход дал нужный прирост в 4 раза.

Видеоплатформа для трёх миллионов видео в сутки, image #4

Пришло время второй проблемы. Смотрим, что происходит в системе балансировки, почему на некоторых кодировщиках скапливаются очереди.

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

Поэтому нужно было направлять пользователя на наименее загруженный сервер. Но возник ряд вопросов:

  1. Какие метрики собирать?
  2. Как часто?
  3. Как выбрать сервер?
Видеоплатформа для трёх миллионов видео в сутки, image #5

Подводные камни, возникшие на пути:

  1. Неизбежное отставание метрик от реальной нагрузки;
  2. Интервал снятия значений метрик;
  3. Неопределённое поведение при максимальной нагрузке на все кодировщики.

Для этих проблем существует не такое уж и сложное решение:

  1. Длина очереди как метрика;
  2. Отсечение 25 % наихудших кодировщиков.

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

Видеоплатформа для трёх миллионов видео в сутки, image #6

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

Видеоплатформа для трёх миллионов видео в сутки, image #7
Видеоплатформа для трёх миллионов видео в сутки, image #8
1 of 2

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

  1. Необходимо посмотреть, есть ли на кодировщике свободные ресурсы (CPU, GPU, память);
  2. Выбрать задачу из очереди с наивысшим приоритетом;
  3. Сделать оценку «трудоёмкости» конвертации и точно оценить ресурсы;
  4. Обновить информацию о текущей нагрузке и начать обработку.

Но в чём заключалась проблема, о которой мы не сразу начали подозревать:

Видеоплатформа для трёх миллионов видео в сутки, image #9

В целом все вышеописанные оптимизации давали прирост в производительности в несколько процентов, но хотелось уменьшить количество кодировщиков в разы. Оказалось, что для кодирования видео можно использовать видеокарты:

Видеоплатформа для трёх миллионов видео в сутки, image #10

Что получилось в итоге:

Видеоплатформа для трёх миллионов видео в сутки, image #11

А на этом всё! Полную версию выступления можно посмотреть ниже:

Видеоплатформа для трёх миллионов видео в сутки, image #12
The Brown Room — независимое интернет-издание
о социальных сетях и технологиях

Автор: Сергей Котов
Корректоры: Арсений Метелёв, Анастасия Литвиненко
Изображения: Александр Светкин / ВКонтакте

155 views·3 shares