Система видео-хостинга
Описание проекта
Для отслеживания эффективности видео-роликов ведется статистика по просмотрам. Имеется также система модерации видео и комментариев.
Мы унаследовали систему от предыдущих разработчиков в плачевном состоянии. За короткое время мы ее документировали, вычистили, привели в стабильное состояние, оптимизировали использование базы данных, добавили memcached. В настоящее время мы разрабатываем новые компоненты на гораздо более прочном фундаменте.
Нетривиальные моменты
- Полнотекстовый поиск на японском языке
- Обмен данными с сайтами-партнерами
- Распределенное хранилище видео-файлов
- Интеграция с CDN
- Биллинг с использованием кредитных карт
- Фотоальбомы
Сводная статистика
- Более 11 млн. показов страниц в сутки
- Более 250.000 видео-показов в сутки
- Более 200 тыс. зарегистрированных пользователей
- Более 600 тыс. посетителей в день
- Более 2.5 Тб хранимых видеоданных
- Более 50 Терабайт ежедневного трафика
Технологии
- PHP
- Python
- Linux
- PostgreSQL
- memcached
- PgQ
Case study
Вступление
Сопровождение и аудит существующих систем — задача не менее важная (а зачастую гораздо более сложная), чем разработка новых. Мы начали работу с заказчиком (японской компанией Sairis) в непростой ситуации: заказчик уже сменил несколько команд разработчиков, поэтому от нас ожидали ощутимых результатов уже через один-два месяца работы.
Мы унаследовали систему от предыдущих разработчиков в плачевном состоянии. Нужно было любыми средствами ее стабилизировать, при этом весьма экономно расходуя серверные ресурсы (которые у заказчика далеко не безграничны).
Описание системы
Проект представляет собой одну из крупнейших в Японии систем видео-хостинга (фактически, японский аналог YouTube). Сервис предоставляет пользователям возможность бесплатно загружать и просматривать видеоролики, комментировать и голосовать за них. Существует развернутая система рейтингов и рекомендаций. Помимо этого, заказчик планировал организовать платный доступ, предоставляющий дополнительные возможности (например, возможность скачивать видео в формате DivX).
Для отслеживания эффективности видео-роликов ведется статистика по просмотрам. Имеется также система модерации видео и комментариев.
Концептуально система представлена на диаграмме ниже:
Проблемы, проблемы, проблемы
В процессе роста посещаемости сервис столкнулся с типичными проблемами масштабируемости и сопровождаемости.
— Отсутствие полноценной тестовой среды. К сожалению, сопровождавшие сервис аутсорсинговые команды не акцентировали внимание заказчика на этом чрезвычайно важном моменте и не сочли нужным потратить на это время.
— Отсутствие исходного кода некоторых компонентов системы (в частности, видео-плейера).
— Отсутствие мониторинга — определить, что происходит с production-системой, практически невозможно.
— Классическая проблема «энтропии» исходного кода — при отсутствии процедуры постоянного улучшения и «очистки» кода он постепенно переходит в хаотическое состояние, блокируя развитие и наращивание функционала сервиса. Все это ухудшается последовательной сменой нескольких команд разработчиков и полным отсутствием документации.
Задачи
Для бесплатного сервиса такого масштаба очень важно поддерживать высокую посещаемость и минимизировать расходы на сопровождение. В середине 2009 года это «магическое» соотношение стремительно ухудшалось: падал уровень доступности сервиса (а следовательно и число посещений), при этом система удерживалась на плаву поистине титаническими усилиями.
Что делать?
— Привести сервис в состояние, из которого его можно развивать и монетизировать.
— Минимизировать поддержку — все должно «работать само». Понятно, что идеал недостижим, однако очень хочется к нему приблизиться.
Как делать?
Для начала мы отклонили типовые студенческие решения вроде «все выкинуть и переписать». Это решение наиболее популярное и одновременно в большинстве случаев провальное (вспомним хотя бы грустную судьбу браузера Netscape).
Мы условно поделили план развития системы на три параллельных процесса:
— Production-мониторинг
— Рефакторинг и новый функционал
— Оптимизация производительности
Мониторинг
Для мониторинга использовался open-source продукт Zenoss Core. Мы добавили в Zenoss большое число различных параметров, выход которых за допустимые пределы означает что-то плохое. Например, это CPU consumption ключевых страниц, длина входящей видео-очереди и т.п.
Помимо Zenoss, мы использовали Tenshi для анализа лог-файлов, а также набор самодельных скриптов для замера тех параметров, которые сам Zenoss измеряет не очень хорошо (это, например, CPU).
Поскольку система в целом не находится под надзором 24 часа в сутки, мы постарались максимально автоматизировать восстановление в результате разного рода мелких сбоев.
Рефакторинг и новый функционал
Рефакторинг в нашем случае был сильно усложнен отсутствием документации и хаотическим способом написания кода. Поэтому в первую очередь нам пришлось с нуля создать в Москве свою собственную тестовую среду. При этом пришлось срочно адаптировать практически весь код системы к работе в разных средах. В дальнейшем мы создали еще одну отдельную тестовую среду в Японии.
Большую проблему представлял собой сервис кодирования видео. Написанный на PHP, он отличался особой нечитабельностью кода, нестабильной работой и полным отсутствием нормальной обработки ошибок. Это был как раз тот случай, когда проще «выкинуть все». Однако избавлялись от старого сервиса очень осторожно:
— Сначала по ключевым сценариям был написан набор unit-тестов на Python.
— Полностью (в некоторых случаях буквально построчно) воспроизведена ключевая функциональность PHP-скрипта на языке Python.
— Добавлен логгинг, обработка ошибок, работа с FTP и кодировщиком видео (Flix Engine).
Потратив на разработку три недели, мы получили ощутимый результат — новый Python-скрипт в течение многих месяцев работал стабильно, без ошибок, позволял легко распараллеливать нагрузку, спокойно переносил любые проблемы с БД и ошибки Flix Engine. Для сравнения — старый скрипт приводил к полной остановке очереди видео-кодирования и зависанию Flix Engine до 2-3 раз в неделю.
Оптимизация производительности
Проблемы с производительностью наблюдались в двух направлениях:
— База данных. Суммарный объем данных в БД был не так уже велик (порядка 8-10 Гб включая индексы), поэтому причина «проседания» БД заключалась скорее в плохо написанных SQL-запросах. Мы провели несколько циклов оптимизации, выяснив, что основной проблемой является использование рекурсивных функций и избыточные JOIN-ы. В итоге 80% запросов в системе были постепенно переписаны, что совместно с тюнингом PostgreSQL и дисковой подсистемы сервера дало хороший результат: сервер успешно работал в пиковые часы, причем его резервы по нагрузке позволяли БД в ближайшем будущем вырасти еще вдвое без ощутимых проблем.
— PHP страницы. Обычно для замеров производительности используется «тестовый стенд», однако его создание в нашем случае было довольно дорогостоящим, поэтому мы старались проводить как можно больше замеров в production-системе (что следовало делать чрезвычайно аккуратно). Для определения узких мест мы использовали сервис статистики Pinba, который потом был подключен к нашему централизованному мониторингу на базе Zenoss. Статистика от Pinba хороша тем, что позволяет достаточно точно определить наиболее удобное место «вмешательства» в PHP-код, при этом она практически не нагружает production-систему. Затем (в тестовой среде) с помощью профилировщика xhprof мы анализировали код уже на уровне отдельных вызовов и проводили точечную оптимизацию. Результат был довольно впечатляющий: переписыванием всего каких-то 50 строчек мы добились уменьшения загрузки CPU на 30-40%. При этом production-сервер получил хороший резерв для роста посещаемости, что дало заказчику еще минимум полгода до покупки новых серверов.
Результат
Каков итог нашей работы и как это отразилось на бизнесе заказчика?
Эффект можно отметить, например, по статистике роста посещаемости. По данным 2009 года, число посетителей стабильно сокращалось (в лучшем случае, посещаемость оставалась на прежнем уровне). Уже через два месяца после начала нашей работы посещаемость начала расти. За полгода сайт показал более чем 50% рост посещаемости; для бесплатного сервиса, зарабатывающего на рекламе, это весьма и весьма существенно.
В результате переделки системы заказчик получил возможность расширять и наращивать ее функционал. В частности, на базе новой видео-платформы были успешно реализованы: сервис фото-хостинга, поддержка видео на iPhone и мобильных телефонах, интеграция с CDN (что дало существенную экономию по стоимости трафика).
Интервью
Оптимизация доставки видео на десктопные и мобильные устройства
Анатолий Филин: Сегодня мы собрались здесь для того, чтобы обсудить одну техническую проблему, которая возникла на проекте видеохостинга и с которой пришлось довольно прилично повозиться. Она вызвала много обсуждения, и в результате была частично решена. Но главный результат все – таки в том, что мы поняли довольно детально как устроена доставка видео-контента в браузер.
Теперь я попрошу Сашу Кистанова рассказать про саму проблему, а потом мы обсудим, как она решалась.
Александр Кистанов: Начнем с того, что у нас на проекте используется обычный http-хостинг видеофайлов, и файлы отдаются с серверов с помощью http в разных форматах. Для десктопных компьютеров они отдаются в формате flv, для мобильных устройств – в mp4, что связано с тем, что мобильные устройства не поддерживают flash и не могут проигрывать flv. У нас системы работают в разных дата-хостингах. И, когда дата-хостинг располагался достаточно близко к потребителям контента, никаких особых проблем со скоростью проигрывания видео мы не наблюдали. В том числе еще и потому что мы в основном проигрывали достаточно небольшого размера видео, по длительности они были от 5 до 10 минут.
Система видео-хостинга
Анатолий: То есть — видео у нас было порядка 5-10 минут, клиент-потребитель контента был в Японии, и сервер – тоже. И все было нормально?
Александр: Также видео невысокого качества было. В новой же системе была сделана ставка на более качественный контент, видео по длительности превышали и час, и два, и качество было существенно лучше. Размер видео-файлов вырос очень сильно. Плюс – использовался другой дата-центр, который располагался далеко от потребителей контента, на другом континенте. И появилась проблема. Несмотря на то, что flv-файлы проигрывались отлично, mp4-файлы, которые понадобилось проигрывать и на мобильных устройствах и на десктоп-компьютерах, проигрывались с существенными задержками. Между тем как пользователь нажимал на кнопочку просмотра видео и тем моментом, когда видео реально начинало проигрываться, могло пройти несколько десятков секунд. И так было на любых устройствах.
Анатолий: То есть, все зависело от формата, с задержками проигрывалось именно mp4?
Александр: Именно. И даже более того скажу – изначально на этом проекте мы и вовсе не использовали flv.
Анатолий: А с чем был связан выбор формата mp4 для видео?
Александр: Мы выбрали его в новой системе как более универсальный формат, и вместе с тем — сразу выяснилось, что есть определенная проблема.
Анатолий: Понятно. Вы столкнулись с проблемой, начали копать дальше, и что стало выясняться в итоге?
Александр: Когда мы начали проблему «раскапывать», мы попытались понять – а в чем разница между системами? В итоге мы поняли что разница была в местоположении дата-центра, размере видео и формате, в котором оно находилось. Довольно быстро выяснилось что видео в формате flv, даже высокого качества, большого размера, и из удаленных дата-центров, проигрывается практически без задержек, в отличие от видео, закодированного в формате mp4. Причем, в данном случае речь идет именно о контейнере видео. Кодек везде использовался h264 — и в flv и в mp4, а контейнер был разный.
Анатолий: Понятно. Но все же — правильно ли я понимаю что формат flv проигрывается только во flash-плеере, создавая таким образом некоторое ограничение, и поэтому многие движутся в сторону mp4?
Александр: Да, только во Flash проигрывается. И при этом сейчас практически все отказываются от Flash. И производители мобильных устройств-то точно. В частности, Android не так давно отказался от поддержки Flash. А iOS никогда не поддерживал Flash.
Анатолий: Понятно.
Александр: Но все же как показала практика, flv-формат все-таки обладает определенными преимуществами перед mp4 при проигрывании через web. Скорее всего это связано, как мы потом выяснили, с особенностями этого контейнера, а именно — с тем способом, каким он хранит метаинформацию на видео.
Анатолий: Понятно. Чтобы еще раз уточнить возникшую перед вами проблему, получается, что, все-таки, она состояла только в задержке. То есть, после того как видео начинает проигрываться, оно проигрывается уже одинаково, независимо ни от чего – ни от контейнера, ни от удаленности?
Андрей Лебедев: В общем — так как Саша ушел в отпуск, а был июль жаркий, проблема легла на меня (всеобщий смех). Начал я выяснять причину проблемы, и понял, что контейнер mp4 также как и контейнер 3gp, родственный ему, имеет такую особенность, что метаданные распределены по файлу. Есть такая утилита -называется MP4Box, плюс — сейчас FFmpeg последней версии имеет подобную опцию, — они собирают всю метаинформацию файла и переносят ее в начало файла. Таким образом, загрузив начало файла, можно иметь всю информацию о всех кадрах, цепочках, о том, как устроен файл, для того, чтобы можно было его перемотать. Подобные манипуляции с файлом необходимы, если мы хотим проигрывать видео в браузере.
Анатолий: Значит, изначально в самом файле метаинформация «размазана»?
Андрей: Да.
Анатолий: А в какой момент ее собирают, и зачем, и кто собирает вообще?
Денис Елданди: Ее собирают после энкодинга утилитой MP4Box, но как я ранее сказал, последняя версия FFmpeg также умеет это делать.
Анатолий: То есть сбор информации происходит перед отдачей файла?
Денис: Нет, не перед отдачей файла, а к моменту энкодинга. Когда пользователь заливает видео, мы его перекодируем в h264, в контейнер mp4, это делает FFmpeg, к примеру. А потом, другой утилитой, MP4Box, все эти метаданные мы перетряхиваем и засовываем в самое начало файла.
Александр: То есть это пост-обработка файла после кодировки.
Анатолий: А зачем это делается? Объясните поподробнее.
Денис: Это делается для того, чтобы плеер смог скачать начало и файла и чтобы у него была вся карта — с какого байта начинается какая минута или секунда видео.
Александр: Проще говоря, это делается для того, чтобы можно было прокручивать видео.
Анатолий: Ага, то есть это делается для произвольной прокрутки видео.
Андрей: Если не перенести метаинформацию в начало видео файла, то пользователю нужно будет скачать весь файл для того, чтобы знать с какого байта начинается какой кадр. То есть я должен скачать все видео, и только после этого начнется воспроизведение и я смогу сделать skip-ahead. Чтобы этого не происходило, чтобы в интернете видео проигрывалось без проблем, берут всю метаинформацию и переносят ее в начало файла. И так делают без преувеличения все, это стандартная процедура, с mp4 для веба по-другому — никак.
В том нашем проекте, в котором контент был легче и находился ближе к потребителю, не было вышеупомянутой проблемы совершенно. Однако, на новом проекте мы столкнулись с ситуацией, что видеоконтент далеко, и он достаточно «тяжелый», то есть размер файла около 300 мегабайт. Для этого файла метаинформация составляет порядка 1-2% от целого, т.е., порядка 3-6 мегабайт. Со скоростью передачи 100-200 килобайт в секунду (а такая скорость особенно актуальна для мобильных юзеров), 4 мегабайта качаются долго, порядка нескольких десятков секунд. Проблема эта касается, повторюсь, и контейнера mp4, и контейнера 3gp – то есть переход на 3gp никак бы не помог нам.
Мы начали разбираться — почему метаинформация составляет собственно – 1-2 % файла, а не меньше. Изучив достаточно глубоко структуру самого формата mp4, который описан на сайте Apple, в частности, и скачав соответствующие программы, которые позволяют проанализировать метаинформацию, я обратил внимание, что метаинформация у видео в формате mp4 делится по дорожкам. И, самое интересное, размер метаинформации видеодорожки меньше, чем размер метаинформации аудиодорожки.
Дальнейшее исследование показало, что, оказывается, по упущению, мы на наших видео, имеем аудиодорожку очень высокого качества — 44 килогерца, что соответствует качеству CD-записи по чистоте дискретизации. В данном случае, на проекте, где видео смотрят на мобильных устройствах, такое качество звука совершенно избыточно. Поэтому мы провели множество экспериментов по переконвертации файлов, уменьшению видео- и аудио-качества и битрейта, и изменению других параметров аудио. Однако на уменьшение размера метаданных существенно влияет лишь уменьшение дискретизации аудио-дорожки. Например, если битрейт аудио был 44 килогерца, и размер метаданных составлял при этом 4 мегабайта, то когда мы уменьшили битрейт до 11 килогерц, то соответственно и размер метаданных стал равняться 900-м килобайтам, и соответственно видео стало грузиться за 10 секунд. Однако, для заказчика оптимальным было значение 22 килогерца дискретизации аудио-дорожки, т.е. это — порядка 1,5 мегабайта метаинформации на двухчасовой фильм, который начинает стартовать через 15 секунд после начала загрузки видео.
И, конечно, «разбивание» самих файлов на файлы меньшего размера тоже приносит ощутимый результат, метаниформация будет уменьшатся пропорционально размеру видео файла. Изучив в целом проблему – а почему же вообще так происходит, я понял что это особенность программы FFmpeg, которая делает очень короткие цепочки при кодировании и видео и аудио, это и приводит к тому, что метаинформации так много. И изменить этот параметр невозможно. Это особенность FFmpeg. Возможно, в будущем разработчики придумают что-нибудь, чтобы увеличить длину цепочек.
Анатолий: Для уточнения – FFmpeg это что?
Андрей: Это собственно энкодер.
Анатолий: А почему мы используем именно его, а не какие-то другие энкодеры?
Александр: Это самый нормальный open source энкодер, который доступен на данный момент. Индустриальный стандарт, так сказать.
Андрей: Этот энкодер обладает множеством параметров и настроек. Но при этом все же и у него есть свои, вышеупомянутые, недостатки. И с этим многие сталкивались до нас.
Анатолий: Но вообще это в целом понятно или нет – нужна ли содержательно вся эта метаинформация?
Андрей: Скорее всего, можно ее уменьшить. В коротких цепочках присутствуют очень частые описания кадров, а ведь можно описывать цепочки большего размера.
Денис: При этом, конечно, skipahead будет менее чувствительным. Но на мобильном устройстве это не сильно важно.
Анатолий: И вот это настроить нельзя сейчас?
Андрей: Нет, нельзя. То есть mp4box может кейфреймы менять, но на самом деле это никак не влияет на метаданные.
Анатолий: Понятно.
Андрей: В общем, проблема как бы остается. В «мировом масштабе» мы ее не решили, но частично наше решение все-таки отчасти состоит в том, чтобы не делать большие mp4-файлы, если мы их хотим передавать по медленным каналам. Далее – следить за качеством звука, и дробить файлы на меньшие части, если видео долго стартует.
Анатолий: Я бы хотел дальше выяснить следующую вещь. Наша цель перехода на mp4 была в унификации, то есть чтобы показывать видео везде одинаково. Мой вопрос таков: сейчас у нас, таким образом, один файл для всех устройств, или мы готовим для мобильных устройств – один, для ПК, к примеру – другой?
Александр: Мы сейчас используем два вида файлов — flv и mp4. Мы ввели flv, потому что на десктоп-устройствах он сразу начинает проигрывать видео, на flash он сразу начинает проигрываться, там по-другому воспринимается метаинформация, и в результате видео начинает проигрываться практически без задержек, и перемотка видео осуществляется практически без задержек. С mp4 таких результатов добиться не удалось. Но mp4, вместе с тем, поддерживается как IOs, так и Android, соответственно интересно один файл mp4 использовать на двух системах.
Изменение битрейта аудио в видеофайле
Анатолий: То есть получается, что у нас сейчас на декстоп идет flv, а на мобильные устройства — mp4?
Денис: Да.
Александр: Для мобильных устройств особых альтернатив нету. Для них используется HTML5 video тэг, поддержанный браузерами мобильных устройств. Единственный формат, который на данный момент, извиняюсь за тавтологию, поддерживается более-менее всеми мобильными устройствами — это mp4. Есть некоторые другие решения, но они выдают гораздо худшую совместимость.
Андрей: Нет, почему же, есть продуктивное решение, связанное со стримингом, но оно просто существенно дороже.
Александр: Да, есть решение, которое позволяет проигрывать, например, h.264 поток с помощью стриминг-сервера. Но оно требует серьезной поддержки на серверной части, то есть — требуется разрабатывать стриминг-сервер, или покупать его, что выходит за рамки нашего проекта.
Еще одно решение – это http-стриминг, которое заключается в том, что mp4-файл на серверной части делится на множество маленьких кусочков. Каждый маленький кусочек обладает существенно меньшим размером и размером метаинформации соответственно. Когда браузер проигрывает видео, он сперва запрашивает метафайл с перечислением этих кусочков, и он знает, какой кусочек относится — к какому времени. Таким образом, когда браузер показывает видео, либо проматывает его, он адресуется не к одному большому файлу, а конкретно к тому кусочку, который ему требуется. При этом, задержки перед началом проигрывания становятся существенно меньше, ведь метаинформация этих маленьких кусочков существенно меньше, чем таковая у целого файла. Но тут все же есть небольшая проблема: это решение работает хорошо на iOS, но поддерживается лишь самими современными версиями Android.
Анатолий: А как обстоит дело с http-стримингом на декстопе?
Александр: На десктопе не все браузеры поддерживают video тэг. Можно использовать работу с HTTP Live Streaming на десктопе, но для этого придется дополнительно имплементировать его поддержку во flash, который используется для проигрывания видео.
Анатолий: Ну то есть даже в Японии мы пока не можем перейти на video тэг, вместо flash?
Александр: Cтереотип о том что японский пользователь использует более современный софт не соответствует действительности. И пока отказываться от flash там нереально. Даже в целях унификации и перехода на HTML5.
Анатолий: То есть, это означает, что нам сейчас приходится поддерживать две версии сайтов – для мобильных устройств и для десктопных?
Денис: Получается, да. Но это частое явление, это происходит везде, не только на указанном проекте.
Анатолий: Но все же — сейчас все сводится к тому, что для десктопных браузеров идет целиком flash, а для мобильных – целиком mp4, или короткие mp4 используются и для того и для того? Как в результате?
Андрей: На десктоп у нас идет flv а для мобильных устройств – mp4.
Александр: По-хорошему – не имеет смысла поддерживать и разрешать, даже пользователям десктопа, просмотр mp4-файлов. Ведь задержки при проигрывании сразу делают неудобным использование этой системы. Единственный вариант – размещать mp4-файлы ближе к пользователям. Тогда при достаточном трафике задержки будут незаметными.
Анатолий:То есть, при достаточной ширине канала?
Александр: Да.
Александр: Я считаю что не ширина канала даже влияет скорее, а задержки.
Андрей: Да, если мобильный пользователь находится в каком-то удаленном районе, у него в любом случае будут проблемы, в связи с задержками. Конечно, у большинства пользователей проблемы уменьшатся но все же по сравнению с flv работать будет медленнее.
Анатолий: Итак, в результате сейчас у нас каждое входящее видео конвертируется в два формата, или это, может быть, большее число форматов?
Александр: Мы конвертируем видео в зависимости от задач, но как минимум – это 2 формата – да. На самом деле мы поддерживаем несколько большее число опций, в частности, это — видео более низкого и более высокого качеств в формате flv.
Анатолий: А приходится ли делать разное разрешение видео, например, для таких устройств как планшет и смартфон?
Александр: Все это зависит от бизнес-задач. В одном случае — мы поддерживаем, например, два вида формата высокого и низкого разрешений для десктопа, один формат для мобильных устройств, но все уже определяется не техническими, а бизнес-задачами. Мы можем поддерживать и 2, и более формата видео для мобильных устройств.
Андрей: Главный конкурент всех видео-хостингов – YouTube – использует стриминг как решение проблемы с задержками при проигрывании видео.
Александр: Насколько я помню для небольших mp4-файлов YouTube использует точно такой же формат, как и мы, а большие он — действительно стримит. Собственно, всегда более-менее крупный хостинг использует близкие к пользователю сервера, или CDN.
Анатолий: Это отдельный вопрос. Как я понимаю, для нас задача была хотя бы частичного перехода видео-хостинга на стриминг тоже стоит.
Александр: Пока — не стоит. Поскольку у нас не такой крупный проект как YouTube, любое сложное техническое решение — всегда компромисс между стоимостью и эффективностью.
Анатолий: Хорошо. Закончим на этой бизнес-ноте.
Спасибо большое всем!