За полгода с июля 2024 года большинство аудиторных и технических показателей RUTUBE выросло в разы: количество ежедневных пользователей выросло почти в 4 раза; количество видео, ежедневно загружаемых на видеохостинг — в 3 раза, с 330 тыс. до 1 млн единиц контента; CDN-трафик — в 4 раза и в пиковые часы превышает 7 Тбит/с. Как архитектура сервиса показала себя в условиях продолжительного «нагрузочного тестирования» и как команда переживала такой рост нагрузки, читайте в этой статье.
Меня зовут Эльдар Ниязов, я директор департамента развития и эксплуатации ИТ-инфраструктуры RUTUBE. В статье разберу верхнеуровневое устройство основных компонентов видеохостинга: раздачу видео и CDN, загрузку на платформу, хранение, воспроизведение и прямые трансляции. А в следующих статьях этого блога мы с коллегами рассмотрим каждый элемент подробнее и копнём вглубь реализации.
RUTUBE сегодня
Пробежимся по продуктовому ландшафту и стеку технологий, чтобы лучше понимать применимость тех или иных технических решений.
Видеохостинг работает на вебе, Android, iOS, Smart TV. Поддерживает просмотр горизонтальных и вертикальных видео, прямые трансляции и вещание ТВ-каналов.
По данным Mediascope за декабрь 2024 г. сервис посетило 78,3 млн человек, а среднее количество ежедневных пользователей составляет 18 млн. RUTUBE смотрят по всей России: из городов миллионников и населённых пунктов поменьше (почти половина зрителей живут в городах с населением менее 100 тыс. чел.).
Объём видеохранилища на сегодня составляет более 250 Пбайт, в нём хранится около 400 млн видео и каждый день их количество увеличивается в среднем на 1 млн — столько новых видео пользователи в среднем загружают на платформу.
Чтобы обеспечить быстрый и надёжный доступ к контенту, наша собственная геораспределенная сеть доставки контента (CDN) состоит из 6 ЦОДов в Москве и одного в Санкт-Петербурге, 4000 серверов (из них 700 серверов для обработки видео), более 200 CDN-серверов, более 25 городов присутствия, страны СНГ и даже США. Ёмкость сети составляет более 10 Тбит/с.
Видеохостинг разрабатывает собственная, полностью in-house команда, которая так же как и ИТ-инфраструктура смогла гибко перестроиться и масштабироваться.
RUTUBE — это более 100 микросервисов. Кодовая база бэкенда написана преимущественно на одном из трёх языков: Python3 — 600 тыс. строк, Node.js — 600 тыс. строк, Golang — 300 тыс. строк. В инфраструктуре у нас высокий уровень автоматизации: IaC (Terraform, Ansible) составляет примерно 200 тыс. строк.
Далее рассмотрим основные блоки видеохостинга.
CDN (раздача)
В век клипового мышления нужно как можно быстрее доставлять контент пользователям. Чтобы минимизировать задержку, мы, во-первых, разнесли контент по CDN в разных городах, чтобы кешировать его ближе к пользователю. Во-вторых, разделили CDN на два уровня: горячий (более x запросов в сутки) и холодный. За видео, которое не было востребовано в течение долгого времени, например, целого месяца, мы обратимся к основному хранилищу.
Такое разделение позволило:
повысить скорость доставки контента до конечного пользователя;
сэкономить на хранилище и оптимизировать использование серверных ресурсов;
снизить затраты на передачу данных по сети.
Подходящий узел CDN мы можем определять по GeoIP (т.е. ближайший) или по ISP (Internet Service Provider). Наши CDN-серверы, естественно, тоже подключены к сети через провайдеров, и в некоторых случаях с точки зрения задержки выгоднее избежать лишних стыков между провайдерами, чем выбрать ближайший, но находящийся в другой сети CDN. В предельном случае грамотное использование CDN позволило нам снизить время доставки с 300 мс до 10 мс.
Стандартный сетап сервера CDN с холодным контентом: 512 Гбайт оперативной памяти, 100 Тбайт дисков под хранение и 2 диска под ОС, 2 сетевые карты — 100 Гбит/с на отдачу, 25 Гбит/с на подгрузку контента из основного хранилища.
Горячий CDN-сервер мощнее и в нём стоят одинаково быстрые сетевые карты на 100 Гбит/с на download и на upload.
Категория комплектующих | CDN 1 уровня с холодным контентом | CDN 2 уровня с горячим контентом | ||
Процессор | AMD EPYC 9004 Series 32 | 1 | AMD EPYC 9004 Series 32 | 2 |
Модуль памяти | Samsung 64GB DDR5 4800MHz | 8 | Samsung 64GB DDR5 4800MHz | 16 |
Сетевая карта | Mellanox 100 gbit dual port | 1 | Mellanox 100 gbit dual port | 2 |
Сетевая карта | Mellanox 25 gbit dual | 2 | — | |
Накопитель SSD 2.5 | Samsung | 2 | Samsung | 2 |
Накопитель SSD SD 2.5 | Intel 7.68TB U2 | 16 | Intel 7.68TB U2 | 16 |
График раздачи в течение типичной недели выглядит примерно так.
Воспроизведение видео
Рассмотрим, что происходит, когда пользователь запускает видео в плеере RUTUBE.
GET-запрос отправляется в балансировщик, который по GeoIP и ISP рассчитывает «расстояние» до CDN-серверов.
Балансировщик видео получает из нашего хранилища FileHeap адрес CDN, на котором есть видео, и адрес самого видео.
Отдает плееру М3U8-манифест c указанием основного и запасного CDN-узла и адрес исходного видео.
Плеер идёт за видеочанками сначала на CDN второго уровня. Если контент не популярный и его нет в горячем кеше, то плеер запрашивает видео с CDN первого уровня, если и там не оказалось — то идет в основное хранилище.
Загрузка видео
В среднем каждый день пользователи RUTUBE загружают на видеохостинг 1 млн новых видео. Загрузка видео — важный и нагруженный сервис и один из самых сложно масштабируемых. Расскажу, что происходит, когда пользователь в личном кабинете нажимает «+», «Загрузить видео».
Балансировщик загрузки отдаёт адрес сервера, на который отправляется загрузка (под загрузку у нас выделено более 800 серверов).
Наш собственный сервис Watchduck, который по нашей традиции назван в честь животного, нарезает видео на разные качества. Watchduck написан на Python3, умеет транскодировать видео и на GPU, и CPU, что нам очень пригодилось в момент бурного роста нагрузки и невозможности быстро увеличить парк видеокарт. Нарезкой разных качеств и обложек занимается ≈ 700 серверов.
После нарезки Watchduck идёт в FileHeap, под который отведено по 10 серверов в основных ЦОДах и который обеспечивает балансировку нагрузки на хранилище. FileHeap получает адрес, куда и в какое именно хранилище положить загрузку.
Естественно вся загрузка и нарезка происходит чанками — по 3–6 Мбайт.
Устройство видеохранилища. Альтернатива S3
Для хранения видео мы используем не стандартный S3, а собственное приложение. Наше решение существует давно, хорошо себя зарекомендовало и в своё время было быстрее, чем альтернативы, например, Ceph.
Главный минус S3 для нас — это необходимость в кеширующих серверах, причем в определённом соотношении с бакетами, чтобы не тормозило. А большое количество дополнительных серверов — это большие затраты на покупку и обслуживание оборудования.
Кроме экономии на оборудовании собственная реализация хранилища даёт следующие плюсы:
возможность глубокого мониторинга на каждом этапе;
гибкая адаптация под свои нужды;
не надо платить за лицензии и поддержку;
скорость и производительность.
Мы используем партнёрские S3 в качестве резерва, арендуем мощности у крупных известных поставщиков. Однако максимальная скорость отдачи, которую нам могут обеспечить сторонние S3, составляет всего 60 Гбит/с. Иначе их сервисы деградируют и страдают другие клиенты.
Видеохранилище RUTUBE состоит по сути из трёх частей:
DS-origin — само хранилище, разнесенное по разным ЦОДам;
FileHeap — балансировщик;
CDN-серверы.
Оно устроено предельно просто, что помогает легко организовать любой мониторинг и при необходимости что-то подтюнить.
Что в результате? Ниже графики нагрузки в обычную неделю без происшествий и пиковой посещаемости, это скорость отдачи контента напрямую с основного хранилища DS-origin (т.е., когда контента не оказалось на CDN первого и второго уровня) и с использованием партнёрских S3.
Прямые трансляции
Когда пользователь хочет провести прямой эфир через RUTUBE и создает трансляцию, под капотом сервиса происходит следующее:
видеопоток от пользователя поступает на RTMP-балансировщик;
RTMP-балансировщик распределяет поток в разные ЦОДы (основной и запасной);
далее поток попадает в сервис live-транскодирования на FFmpeg, где нарезается в разные разрешения — от 144 до 4к;
транскодирование также проходит через балансировщик, выполняется в разных ЦОДах и резервируется по двум ссылкам;
из балансировщика поток попадает на CDN, ближайший к зрителю трансляции.
Наши трансляции минимально отстают от реального времени — на 3–5 секунд.
Схема работы прямых трансляций RUTUBE. Genetta — собственный сервис, агент по управлению ffmpeg на live-транскодерах
Что мы делали при резком росте нагрузки
В августе 2024 года количество пользователей RUTUBE стало расти гораздо быстрее, чем до этого. В один прекрасный день мы поняли, что с таким темпом увеличения нагрузки мы скоро исчерпаем наши ресурсы — надо срочно масштабироваться и расширять инфраструктуру.
Первым делом мы развернулись в облаках. Это дорого и даёт только временную отсрочку, но зато достаточно надёжно и позволяет быстро добавить мощностей.
Где потребовались дополнительные ресурсы при росте нагрузки:
Загрузка и обработка — первое, где требовалось масштабирование. Обработка видео, его нарезка во все качества — ресурсоемкий процесс, а когда авторы резко начинают заливать в видеохостинг все свои ролики, накопленные за годы творчества, это может стать потенциальной проблемой. Мы арендовали 1000 дополнительных серверов у партнёров, а сам процесс не потребовал изменений, просто у балансировщика появился больший пул серверов.
Хранение — новые видео надо где-то хранить. На всякий случай подстраховались арендными S3 и увеличили количество кеш-серверов.
Раздача и трансляции имеют больший запас прочности из-за особенностей архитектуры, поэтому тут удалось подстраховаться тем, что быстро купили несколько серверов в частном порядке и выиграли время на полноценную закупку.
Специфика видеохостинга в том, что нагрузки на запись гораздо меньше, чем нагрузки на чтение. Поэтому мы держим по одному мастеру в каждом ЦОДе и много реплик на чтение.
Итого
Основные элементы архитектуры RUTUBE, заложенные разработчиками сервиса ранее, позволили нам горизонтально масштабироваться при кратном росте нагрузки. Конечно, когда в течение августа 2024 г. трафик увеличился примерно в два раза, нам с командой пришлось попотеть: перераспределять имеющиеся ресурсы, сетапить новые, подключать арендные мощности, готовиться к сценариям плавной деградации и т.д. Для нас главное — команда быстро и чётко прошла критическую фазу масштабирования. Теперь мы можем в чуть более равномерном, но по-прежнему высоком темпе наращивать мощности: и железные, и человеческие. Потому что планы у нас амбициозные ;)
Статья написана по мотивам доклада на HighLoad++, если кому-то удобнее слушать и смотреть — ловите ссылку на видео. Этим и другими материалами о том, как создаются медиасервисы, делимся в телеграм-канале Смотри за IT — присоединяйтесь.