This post is also available in: Английский
Прежде всего обсудим специфику видео проектов — видео платформы.
Просмотр видео на сайте требует хороших серверных мощностей, т.к. каждый пользователь создает приличную нагрузку в несколько мегабит. Один из вариантов решения задачи — доставка контента через CDN провайдеров, хотя часто бывает выгодно доставлять контент самостоятельно или использование CDN услуг не подходит по каким-либо причинам. В этом случае требуется установки платформы доставки видео контента.
Edge серверы выполняют доставку контента конечным пользователям. В последнее время крайне популярны реализации на базе HTTP протокола (HTTP Dynamic Streaming, HTTP Live Streaming, HTTP Progressive Download). В случае HTTP DS/LS Edge сервер выполняет кеширование сегментов (чанков) видео контента и для оптимального использования вычислительных мощностей запросы пользователей должны попадать на тот сервер, где этот контент есть в кеше (content aware load balancing).
Другой важный момент — Edge серверы должны иметь возможность поместить весь контент или хотя бы весь «горячий» контент в свой суммарный кеш (для доставки не из СХД). Поэтому, зная размер библиотеки видео контента, Вы можете рассчитать размер суммарного эффективного дискового пространства на edge серверах, а из требований к пиковому количеству одновременных зрителей Вы можете рассчитать суммарную полосу пропускания от edge серверов до открытого Интернета. Также стоит отметить, что эффективность создания отдельных площадок «поближе» к пользователю не всегда так очевидна как кажется.
Если Вы решите самостоятельно доставлять видео пользователям, то Вам скорее всего пригодится наш балансировщик нагрузки доступный как в виде серверного программного обеспечения для установки на Вашем оборудовании, так и в виде облачного сервиса.
Защита контента
При работе с премиум контентом очень важно обеспечить его защиту. Как правило, это достигается за счет использования DRM решений (например, Adobe Flash Access). Учитывая критичность этого модуля важно размещать его за средствами защиты от DDoS атак (например, IPS). Также важно отметить кеширование лицензий на стороне пользователя. При большом количестве просмотров видео генерируется большое количество запросов к серверу лицензий. Для минимизации нагрузки стоит выставлять допустимый уровень кеширования лицензий (как правило, указывается правообладателями).
При реализации функций сбора статистики в сервере лицензий применимы рекомендации из следующего раздела.
Статистика
Крупные онлайн видео сервисы генерируют колоссальные объемы статистической информации по действиям пользователей необходимые для расчета финансовых результатов работы, реализации удобных функций (например, возврат к просмотру с места последнего прерывания, рекомендации) и др. Для того чтобы Ваш сервис хорошо справлялся с нагрузками и мог быстро расти вместе с аудиторией требуется в самом начале на этапе проектирования заложить правильную архитектуру.
В задаче сбора статистики можно выделить следующие этапы, требующие качественного проектирования:
Сбор сырых данных — информация о просмотрах (в случае HTTP DS — скачивания чанков) видео может быть агрегирована по логам отдающих (edge) серверов. Если Вы планируете использовать услуги CDN провайдера, то Вам следует проверить доступные CDN логи, а также гарантии их точности и полноты. Альтернативный вариант — использование сервиса сборки статистических данных. Один из таких сервисов доступен у нас (Video Analytics) — видео плееры отправляют ему события, а он сохраняет их в удобной форме для возможности быстрого доступа. Следует отметить важность обычных лог файлов, кеш хранилищ и прочих технологий на первом шаге — это позволит собирать колоссальные объемы данных без существенных затрат на аппаратные мощности.
Первичная обработка — в зависимости от того, какие данные нужно получить в итоге, следует производить подготовку предварительных данных. На данном этапе информацию стоит переносить из промежуточных высокоскоростных хранилищ в реляционную БД для удобства ее дальнейшей обработки.
Подготовка агрегированных данных — часто статистика собирается для расчета финансовых параметров (разделение доходов и прочее). В этом случае при подготовке информации участвуют данные за длительные периоды, выборки из огромного числа записей, очень сложные взаимосвязи. Здесь очень важно использование выделенных серверов для просчета статистики, т.к.
Архивирование данных — со временем количество информации может превзойти разумные пределы. Скажем при 10 млн просмотров видео контента в день, за год это уже будет 3,6 млрд просмотров (например, если хранить подробные сведения о истории просмотра). Любой даже очень мощной БД скорее всего станет плохо от выборок по такому количеству записей. Поэтому очень важно на определенном этапе выводить устаревшие и очень редко используемые данные на отдельные серверы. Альтернативный вариант — использование шардирования БД по датам.
Напоследок, полезная презентация коллег из Yahoo! про построение их собственной видео платформы для своих сервисов:
Интересный факт из презентации: Yahoo! использует Rhozet и ffmpeg — не удивительно, т.к. на одном ffmpeg, как правило, далеко не уедешь. Например, В своих проектах мы как правило создаем фермы подготовки (транскодирования) контента на базе Rhozet Carbon.
Другой важной частью видео сервиса является веб платформа. Специфика веб платформы у каждого проекта своя, мы лишь обозначим некоторые ключевые моменты, о которых стоит задуматься на этапе проектирования в случае видео сервисов. Про общие правило разработки высокопроизводительного ПО тоже забывать не стоит. В случае видео сервисов, как правило, на архитектуре больше всего сказываются следующие требования:
- множество интерфейсов и платформ — обслуживание разных устройств при помощи единого ядра и множества специализированных представлений (PC, iPad, iPhone, Android, ТВ)
- высокая степень персонализации — рекомендации, история использования сервиса пользователем, социальный профиль пользователя стремятся к созданию уникального портала и интерфейса под каждого пользователя
- высокая интерактивность — пользователи требовательны к скорости отклика видео сервиса: быстрая смена страниц, быстрая смена видео контента в плеере
Front End
В качестве Front End серверов часто используются легковесные веб серверы типа NGINX и lighttpd. На этапе проектирования важно понять каким образом будет работать кеширование веб страниц. Выбор технологий зависит от множества факторов:
- насколько страницы динамичны — чем больше персонализации тем меньше эффект от кеширования целых страниц, тем сложнее реализация персонализации в дальнейшем (тот же сервис рекомендаций по предпочтениям конкретного пользователя)
- насколько страницы сложны в подготовке (длительность расчета)
- как много информации будет доставляться AJAX’ом
В зависимости от особенностей вашего проекта целесообразно использование разных механизмов кеширования (кеширование полных страниц, блоков или только данных). Здесь приведена информация по тестированию производительности PHP фреймфорков, шаблонизаторов, NoSQL БД.
Средства защиты от компьютерных ботов и спамеров (такие как Captcha) следует выносить на отдельные серверы. Они требуют существенных вычислительных ресурсов и могут повлечь перегрузку и отказ основных сервисов. Хорошая подборка рекомендаций по оптимзиации веб сайтов от Yahoo! здесь.
Cache серверы
В качестве кеш серверов очень часто используют MemCached. Из-за отсутствия встроенной репликации и некоторых других фишечек, многие проекты начинают использовать Redis. Вопрос выбора оптимального решения сводится к анализу полезности расширенных функций Redis. С точки зрения видео сервисов, очень эффективно закидывать предварительную статистику по потреблению видео контента (впрочем и потоки других событий) в списки обработки Redis для их дальнейшей обработки системами статистики, биллинга и т.п.
Базы Данных
Традиционно многие разработчики используют MySQL и PostgreSQL, но высоконагруженные проекты быстро переводят многие критичные ко времени исполнения функции на нереляционные базы данных, такие как MongoDB, Cassandra. Нереляционные БД предлагают потенциально более высокую производительность и множество необходимых для высоконагруженных проектов функций: мастер-мастер репликацию, шардирование и прочее.
В видео сервисах часто требуется агрегация статистических данных за длительные периоды и по большому количеству параметров. Для таких случаев очень важно иметь отдельную БД (как правило, реляционную) для выполнения долгих и сложных расчетов со сложными структурными зависимостями.