This post is also available in: Английский

Современные системы доставки видеоконтента в большинстве случаев строятся на основе технологии HTTP Streaming. В рамках данной технологии видео доставляется пользователю в виде серии кусочков (чанков) контента по несколько секунд каждый. Наиболее популярными форматами доставки видео являются Apple HTTP Live Streaming и Adobe HTTP Dynamic Streaming. В скором времени, наверное, станет популярен MPEG DASH. Преимуществами данной технологии являются более стабильная работа видеоплатформы при доставке контента через неоднородную публичную сеть Интернет и возможность использования существующих механизмов традиционных CDN сетей (кеширование HTTP чанков). Но часто традиционных средств недостаточно, в крупных онлайн видеосервисах, как правило, требуется более гибкое управление доставкой видеоконтента. В своих проектах мы используем наш Video Load Balancer. В этой статье мы расскажем об основных принципах его работы. Мы надеемся, что они могут принести пользу вашим проектам, независимо от технологии, которая будет использоваться для распределения нагрузки.

В популярных видео сервисах рост нагрузки, как правило, происходит лавинообразно в так называемый Prime Time. Это вечернее время, когда люди приходят с работы и проводят время за просмотром любимых фильмов, программ, сериалов, шоу и спортивных событий. Этот эффект существенно усиливается в периоды трансляции популярных спортивных событий или премьер нового контента. Чтобы обеспечить эффективное распределение нагрузки и быстродействие в таких случаях, мы написали на C++ собственный сервер. Типичная для Prime Time ситуация — когда за короткий промежуток времени к сервису обращается несколько десятков тысяч пользователей. Поэтому сервер распределения нагрузки должен уметь обрабатывать несколько тысяч запросов в секунду. Учитывая, что сервер балансировки нагрузки определяет, кто и каким образом будет доставлять видео конкретному пользователю, время ответа (скорость обработки) также является предельно критичной: по сути это прямая задержка на старте видео. В данной ситуации оптимальной является автономная работа балансировщика: учитывая всю информацию с узлов доставки видеоконтента он будет принимать решение о маршрутизации пользователя на определенный узел на основе лишь тех данных, которые были предварительно подготовлены в памяти процесса.

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

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

• модуль статистики должен собирать данные о присутствии в кеше разных единиц контента разного типа: VoD, Live, DVR;
• разные типы устройств могут потреблять разные форматы единиц контента (HTTP LS / DS / PD);
• кеш может быть неограниченно большим, и нужно уметь оперативно следить за ним: объем дисков растет, и на серверах доставки нередко оказываются терабайты и десятки терабайтов видео;
• разные серверы доставки имеют разную пропускную способность, причем для каждого типа контента она может отличаться — например, для HD видео;
• определение наличия контента в кеше по определенному количеству чанков — далеко не всегда сервер доставки контента содержит абсолютно все чанки.

При создании модуля балансировки нагрузки важно учитывать следующие функции:

• сбор и агрегация статистики с серверов доставки видео в фоновом режиме;
• поддержка площадок с серверами доставки — они могут быть в разных ДЦ, в разных городах и странах;
• возможность выводить из использования серверы доставки контента и включать их обратно в работу — например, для проведения профилактических работ или анализа ошибки на конкретном сервере;
• форсированный сбор статистики с Edge-серверов при пиковых нагрузках — это очень важно, когда ситуация очень быстро меняется и сервер может оказаться перегруженным за несколько десятков секунд;
• сброс трафика в сторонние CDN при пиках нагрузки или высокой загруженности всех собственных серверов: это может помочь вам существенно экономить на CDN услугах;
• балансировка нагрузки с учетом полученного от пользователя сообщения о недоступности серверов доставки — какие-то серверы могут быть недоступны пользователю, он должен иметь возможность сообщить о невозможности работы с ними и получить альтернативные адреса;
• контроль доступа к API.

Кроме того, мы встретились с необходимостью наличия удобного API-интерфейса, который бы в режиме реального времени позволял снимать информацию о статистике подключений, балансировке и изменять конфигурацию балансировщика прямо на лету. Так появилось небольшое AIR приложение CDN Admin.

Желаем большой нагрузки Вашим видеосервисам и отличного качества доставки контента пользователям!

P.S.
Если Вам интересно увидеть, как наш балансировщик справится с видеонагрузкой в ваших проектах на базе HTTP Streaming, то мы с удовольствием настроим его для Вас. Особенно если нагрузка очень большая 🙂