РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2733.html
Для того чтобы подготовить видео к стримингу на большое количество типов устройств, нужно сделать несколько шагов - от подготовки метаданных до упаковки в разные контейнеры (MP4, DASH, HLS) с разным битрейтом.
Мы построили гибкую систему с приоритетами, которая учитывает потребности бизнеса в скорости подготовки видео и умеет работать с пятью DRM-системами. Архитектурное решение основывается на жонглировании Docker-контейнерами и включает в себя как аппаратные средства для кодирования видео, так и софтверные.
2. 2
✓ Показываем легальное видео почти на любом устройстве
(Web, iOS, Android, SmartTV, XBOX и т.д)
✓ Highload проект с многомиллионной аудиторией (33 млн.)
✓ Свой CDN 30 городов РФ. Москва 3 ДЦ с кольцом 150 Гбит
✓ ~ 70 000 запросов в секунду
Немного о ivi
4. 4
✓ Многокилометровые инструкции админам по правильной сборке
(ffmpeg, mp4box и т.д)
✓ Необходимость снизить требования к порогу вхождения для операторов
системы кодирования
✓ Подготовка видео к стримингу состоит из большого числа этапов, на каждом
можно получить ошибку
✓ R&D постоянно придумывает что-то новое и это надо быстро внедрять
✓ Зоопарк контейнеров, кодеков и DRM
✓ 6 DRM систем
✓ 52 конфигурации кодирования
✓ Сохранение истории параметров кодирования
✓ Проблемы с тестированием системы кодирования
✓ Стандартные проблемы системы массового обслуживания
Какие у нас были проблемы
5. 5
Ожидания бизнеса
✓ Дешевый специалист
✓ Все умеет
✓ В восторге от однообразной работы
Кто такой оператор кодирования
Ожидания тех. департамента
✓ ну пожалуйста, пусть, как на картинке
Чего мы старались добиться
✓ Создать систему с низким уровнем вхождения для операторов
✓ Возможность использования дешевых и
низкоквалифицированных сотрудников on demand
✓ Не увеличивать число профи
6. 6
✓ Проверка оригинала
✓ Bitrate
✓ Пропорции
✓ FPS
✓ Звуковые дорожки
✓ и т.д.
✓ Кодирование в нужный bitrate
✓ Упаковка в нужный контейнер (возможно + шифрование)
✓ Отправка на origin сервера
✓ Контроль качества
Этапы подготовки видео
8. 8
✓ API
✓ Админка для разработчиков
✓ Админка для операторов кодирования
✓ Управление контейнерами
✓ Примитивная оркестрация
Общая архитектура системы обработки видео
9. 9
Каждый контейнер последовательно выполняет несколько типов задач
(не обязательно для одного и того же видеопотока)
✓ mp4
✓ HLS
✓ DASH
✓ HDS
Содержимое контейнера
✓ Ubuntu
✓ ffmpeg, ffprobe, mp4box и т.д.
✓ Django
Что внутри контейнера?
11. 11
Сложно построить систему массового обслуживания без
приоритезации заданий и мы добавили приоритеты
✓ обычный
✓ срочный
✓ мега срочный
✓ супер срочный
✓ мне надо вчера
✓ внезапно (с) В. Прохода
Приоритеты
13. 13
✓ Службе эксплуатации пришлось повозиться, чтобы
перестроить мировоззрение
✓ У Docker есть особенности. Некоторые баги ловили по полгода
✓ Эксперименты с Kubernetes убедили нас им не пользоваться
✓ Debug системы кодирования занимает космическое время
Какие проблемы встретили по дороге
14. 14
✓ Простота эксплуатации
✓ Масштабируемость
✓ Подробное логирование всех этапов обработки видео
✓ Возможность подключать любые внешние сервисы
✓ за 2016 год весь каталог ivi был перекодирован несколько раз
(весь каталог ~ 2 Pb)
✓ Счастье QA
Чего удалось добиться
1) непривычно, люди привыкли заходить на машины по ssh, запускать скрипты, смотреть запущенные процессы, читать логи, здесь для всего этого нужно привыкать к новым инструментам
2) многие сервисы пришлось переделывать под докерную философию "один контейнер = один процесс", что не везде удобно
3) когда что-то не работало, сложно было искать причину ошибки (то докер никак не мог тупо скачать образ, а сообщения в логах были неинформативными, то сам кубернетис сыпал логами в громадных объемах и в них ничего нельзя было найти)
4) когда запущенный в докере сервис или скрипт падал, кубернетис бодро его перезапускал, удаляя старый контейнер и оставляя нас без диагностической информации
5) сборка докер-образов идет долго (по сравнению с выкладкой кода rsync), даже если принять во внимание кеширование слоев сборки, которое есть в докере
Часть проблем с тех пор, вероятно, решена свежими версиями докера и кубрнетиса, два года прошло
Ну и еще один из основных плюсов куберетиса (возможность запускать заданное число копий каждого сервиса) для тестовых кластеров малополезен
Еще к пункту 1 или 2 --- у нас много скриптов, которые тестировщики запускают руками из консоли, зайдя куда-либо по ssh, а с кубернетисом некуда заходить по ssh и скрипты приходилось запускать в отдельных контейнерах, для чего пришлось изобрести специальную гуйню
Вот это точно успели пофиксить с тех пор в докере или кубернетисе