Инфраструктура прямых трансляций

Продолжаем серию расшифровки докладов с VK Tech Talks | Backend. На этот раз в своём выступлении Михаил Райченко рассказал про эволюцию прямых трансляций «ВКонтакте». Публикуем расшифровку.

У нас появилось желание сделать прямые трансляции. В идеале, конечно, хочется полноценную систему, но вначале — как можно быстрее.

Что такое полноценная система? Это приём сигнала с мобильных или десктопных устройств или со сторонних партнёрских серверов.

Первая версия. Что нам нужно?

1. Нужно принять и отдать сигнал (RTMP);
2. Для инфраструктуры прототип = MVP;
3. Пробуем различные варианты медиасерверов, выбрали стороннее решение (транскодер) и nginx-rtmp модуль.

Вот так может выглядеть первая версия любого сервиса прямых трансляций:

Самая первая версия примерно такой и была. Теперь же необходимо масштабироваться. Логично масштабироваться сначала на зрителей. То есть необходимо больше разрекламировать прямые трансляции, показать интересный контент для того, чтобы понять, как будет вести себя аудитория в случае, если контент хороший. Для этого необходимо добавить уровень кэширования, потому что на большом количестве зрителей медиасервер перестаёт справляться с нагрузкой.

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

Ниже представлен работающий вариант масштабирования:

Что осталось «за кадром» масштабирования:

1. Защита от кражи трафика;
2. Приватность;
3. Балансировка;
4. Борьба с транскодерами и доработки nginx-rtmp;
5. Статистика, отладка;
6. Куча интеграционного PHP-кода.

На определённом этапе приходит осознание, что поддержка занимает очень много времени, и что иногда ты не можешь ответить на вопросы команды эксплуатации и помочь им с чем-то.

Естественное решение этой проблемы — всё переписать.

Плюсы и минусы этой идеи:

Выбор пал на язык Go. Но почему не С++? Было понимание, что задача транскодирования стрима, то есть преобразование его в более низкие разрешения, тратит большее количество ресурсов.

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

Из клиентских вещей, которые мы получили:

1. Существенное улучшение приёма потока: видео перестали «биться»;
2. Экономия на SSD;
3. Отладка и статистика стали в разы проще;
4. Легко добавляется функциональность.

Но не бывает всё так гладко, чтобы всё и сразу заработало. Поэтому, на картинке ниже любому человеку, даже далекому от работы с инфраструктурой, понятно, что что-то не так.

Это график CPU. Что мы видим? Иногда CPU «улетает» в 100 % на пару минут. При этом происходит интенсивная запись на диск. Из этого следует, что система не диагностируемая. Мы не можем, посмотрев на наш текущий график, сказать, что вот здесь проблема. Это нужно исправлять.

Как мы пытались это исправить:

1. В диагностике проблем с дисками не обнаружили.
2. Улучшили кеширование.
3. Максимально разгрузили диски.
4. Везде прописываем лимиты. Лимиты, лимиты, лимиты…

Что изменилось? Ничего. Единственное, это стало происходить реже, что косвенно нам подтвердило, что проблема всё-таки в дисках.

На самом деле, это решалось достаточно просто, но проблема не с тем, что происходило, а с тем, почему мы этого не видели. В Linux-подсистеме есть такое понятие как Dirty pages — страницы памяти, которые ожидают записи на диск. У этой настройки есть два значения: абсолютное и относительное.

В итоге система стала диагностируемой. Но появился представленный ниже график. На нём мы видим 100 % дисковую утилизацию при том, что диск почти ничем не занят.

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

Можно считать это счастливым концом этой истории.

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

Автор: Сергей Котов
Корректоры: Арсений Метелёв, Анастасия Литвиненко
Слайды и статистика: Михаил Райченко / ВКонтакте