Архитектура YouTube
Архитектура YouTube
Иван Блинков
Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?
Источники информации
В отличии от остальных, этот перевод статьи от Todd Hoff‘а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:
* Google Video
Платформа
* Apache
* Python
* Linux (SuSe)
* MySQL
* psyco, динамический компилятор Python → C
* lighttpd для видео
Что внутри?
Статистика
* Поддержка обработки более 100 миллионов видеороликов в сутки
* Сервис был запущен в феврале 2005 года
* В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
* К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
* Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных
Рецепт управления огромными темпами роста
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}
Этот цикл проходит далеко не одну итерацию ежедневно.
Веб-серверы
* NetScalar используется для балансировки нагрузки и кэширования статического контента.
* Apache работает с включенным mod_fast_cgi
* Запросы отправляются на обработку с помощью серверного приложения на Python.
* Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
* Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
* Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
* Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
* На формирование страницы обычно уходит не более 100 миллисекунд.
* psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
* Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
* Какая-то часть заранее сгенерированного HTML хранится в кэше.
* Кэширование данных в СУБД на уровне строк.
* Кэшируются полностью сформированные объекты Python.
* Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.
Управление видео
* Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
* Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
* Использование кластеров влечет за собой:
– увеличение производительности пропорционально количеству дисков, на которых расположен контент;
– возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров;
– возможность организации создания резервных копий online.
* В роли HTTP-сервера для работы с видео используется lighttpd:
– Он способен дать фору Apache в плане производительности предоставления статического контента;
– Для работы с событиями ввода-вывода используется epoll;
– Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
* Самая популярная часть контента размещается в CDN
– CDN реплицирует весь контент в разных частях системы;
– Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
* Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation:
– Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках;
– В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств;
– Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность;
– Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.
Ключевые моменты
* Чем проще - тем лучше;
* Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
* Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
* Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
* Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.
Управление миниатюрами видео
* На удивление сложно решаемая задача, особенно если необходима эффективность;
* Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
* Миниатюры хранятся всего на нескольких компьютерах;
* Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов:
– Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode‘ов файловой системы;
– Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея;
– Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов;
– В условиях таких нагрузок Apache показывает плохую производительность;
– Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20;
– Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность;
– С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов;
– Перезагрузка занимала 6-10 часов, так как кэш должен был “разогреться” прежде чем перестать использовать данные с жестких дисков.
* Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google:
– Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе.
– Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети.
– Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.
Базы данных
* Раньше:
– MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее.
– Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков;
– Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день.
– Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре.
– Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них.
– Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации.
– Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации.
– Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
* Сейчас:
– Используются распределенные базы данных;
– Сегментированная система (прим.: по аналогии с Flickr);
– Распределенные чтение и запись;
– Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;
– Такая архитектура привела к 30%-й экономии на оборудовании;
– Задержки в реплицировании сведены к нулю;
– Размеры базы данных могут расти практически неограниченно
Стратегия размещения в датацентрах
* Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
* Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
* Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
* Было использовано 5 или 6 разных датацентров в дополнение к CDN.
* Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
* Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
* Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
* Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.
Подводим итоги
* Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
* Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
* Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
* Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
* Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
* Постоянная работа над поиском и устранением узких мест в системе:
– на программном уровне это чаще всего бывает кэширование и работа с СУБД;
– на уровне операционной системы - операции ввода-вывода;
– на уровне оборудования - оперативная память и RAID массивы.
* Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.
Взято тут
http://www.insight-it.ru/net/scalability/arkhitektura-youtube/
-~{}~ 25.08.08 17:14:
================================================
От Anton.Shevchuk
MyPHPTube.com (клонируем YouTube)
С возросшей популярностью сервиса YouTube.com многим захотелось организовать подобный сервис, но как это сделать? Приведу небольшой рецепт организации такого сервиса.
Функциональность
Для начала опишем основной функционал сайта (сразу определимся и с ролями пользователей):
1. Гость
* просмотр видеофайлов на сайте
2. Пользователь
* аплоад видеофайлов
3. Администратор
* управление пользователями
* управление файлами
WEB 2.0 фичи
А теперь расширем наш базовый функционал, чтобы привлечь аудиторию:
1. Гость
* просмотр комментариев к видеофайлам
* поиск файлов (по категории, по тегам)
2. Пользователь
* возможность оставлять комментарии к видеофайлам
* возможность записывать видеофайлы с web-камеры
* возможность связывать видеоролик с категорией
* возможность связывать видеоролик с несоклькими тегами (tags)
* выставление рейтинга видеофайла
* организация списка друзей
* внутренняя mail система
* закладки
3. Администратор
* управление комментариями
* управление категориями
Это конечно не весь функционал YouTube, но ведь нужно с чего-то начинать
Конфигурация сервера
Наша система будет базироваться на LAMP:
* Linux
* Apache (версия 2.2 и выше)
* MySQL (версия 5.0 и выше)
* PHP (версия 5.2 и выше)
Возможные проблемы
А теперь расскажем о проблемах с которыми Вам предстоит столкнуться
Конвертирование Видео
Если позволить каждому из посетителей сайта заливать на сервер видеоролики в произвольном формате, то для того, чтобы просмотреть их все, Вам прийдется устанавливать на свой компьютер очень много кодеков, а если требовать определенный формат от пользователя - то, с очень большой вероятностью, это отпугнет от вашего сайта поситителей. И что же делать? Правильно, конвертировать все видеофайлы в один формат, и будем конфертировать в формат FLV (flash video - можно просматривать в большинстве операционных систем, поскольку он использует широко распространённый Adobe Flash Player и плагины к большинству браузеров, а также поддерживается многими программами для воспроизведения видео, например, MPlayer, VLC media player и другими программами, работающими с помощью DirectShow).
Нам понадобятся следующие програмные средства (всё opensource):
1. mencoder или FFmpeg
2. flvtool2 (требует наличия Ruby)
3. PHP Program Package (’example.php’ пример конвертации с использованием mencoder’a) или ffmpeg class (’ffmpeg.example1.php’ пример конвертации с использованием ffmpeg)
Дополнительно можно еще использовать mplayer для получения информации о оригинальном видеоролике.
Замечательно, если мы всё установили и правильно собрали, то мы теперь можем конвертировать…
Статус загрузки
Еще такой момент - пользователям не нравиться сидеть и ждать пока файл загрузится на сервер, пользователь он же любознательный, ему хотя бы вывести progress bar надо:
* http://www.emllabs.com/article.php?articleId=121/ (используя Flash8 и PHP)
* http://tomas.epineer.se/tesupload/
* http://www.raditha.com/megaupload/
* http://www.obokaman.com/p/descripcion-y-fuentes-del-upload-php-ajax-con-barra-de-progreso-1596
* http://labs.beffa.org/w2box/demo/
* http://trydobe.com/?page_id=3
* http://ecosmear.com/relay/ (прикольный примерчик, используется perl)
Все ссылки нарыл на форуме xajax’a http://community.xajaxproject.org/viewtopic.php?pid=10100
Ресурсы
Так, на сервер мы залили видеофайл, показали как он быстро к нам заливался, но вот беда, если мы будем на нашем web-сервере конвертировать видео ролики - то сайт у нас будет скорее мёртв, чем жив. Для этой цели нам надо будет использовать еще один (как минимум) сервер, который будет забирать неотконвертированный файлы с web-сервера и отправлять назад отконвертированные ролики. Т.е. для решение данной проблемы нам понадобиться еще железо…
Распределение нагрузки
Конвертирование это ресурсоемко, а отдавать видеоролики всем желающим?… Это конечно не будет так нагружать процессор, но вот канал точно умрет… как выход у нас появляются еще сервера, которые и хранят у себя видеофайлы:
* http://mirror1.myphptube.com
* http://mirror2.myphptube.com
* и т.д.
Как распределять нагрузку - это уже решать Вам. Но прежде, чем городить огород Вы должны определить какой приблизительно объем данных Вам прийдеться хранить, и далее уже решать какая схема больше подойдет, ориентируемся, что 1 пользователь заливает на сервер 20mb в месяц (234Gb на 1000 пользователей в год), не популярные ролики не сохраняются более года):
* Объём данных ~ 0.3Tb - 1.5Tb:
на каждом зеркале у нас хранятся все видеоролики
у нас есть mirror1 - сервер на котором всегда первым появляется переконвертированный видеоролик, остальные с ним синхронизируются
* Объём данных ~ 1.5Tb - 3 Tb:
все видеоролики храняться только на одном главном сервере, если у видеоролика растет популярность, он заливается и на другие зеркала
* Объём данных > 3Tb:
видеролик заливается на ближайшее зеркало (подразумеваем, что ролик залитый китайцем будут смотреть в основном китайцы, следовательно заливаем его на зеркало в Китае)
по мере роста популярности ролика зеркалим его на сервер ближайший к эпицетру популярности (пример: китаец живет в США, его ролик залит на зеркало расположенное в США, смотрят его в основном в Китае, видя это ролик будет отзеркален на Китайский сервер)
Числа взяты с потолка, против китайцев ничего не имею (просто взяты для примера), пишите свои варианты…
База данных
Далее я опишу простенькую архитектуру БД:
users
id autoincrement field
login unique login
password encrypt password
email user email
actcode activation code
role ENUM(guest/user/admin)
status not active / active / disable
date_create
date_update date of last change profile
date_login date of last login
… another fields e.g. first name, last name
friends
id autoincrement field
user_id1 user ID
user_id2 user ID
status request / ok / cancel
date_create date of send request
date_update date of accept or denied request
files
id autoincrement field
title title of video file
file name of file on file system
status not convert / in process / ok
access public / members only / friends only / private
author_id ID of owner (users)
category_id ID of category (categories)
date_create
date_update date of last changes
… another fields e.g. length, description
mirrors
id autoincrement field
url mirror url
date_create
date_update date of last changes
mirrors_link
file_id ID of file (files)
mirror_id ID of mirror (mirrors)
status current file status downloading / ok
date_create
date_update date of last changes
categories
id autoincrement field
pid parent category ID
name name of category
… another fields e.g. metadescription, metakeywords
tags
id autoincrement field
word tag word
tags_link
id autoincrement field
tag_id tag ID (tags)
file_id file ID (files)
comments
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
message text of message
date_create
rate
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
rate integer value, e.g. for 0 to 10
date_create
messages
id autoincrement field
author_id ID of owner (users)
user_id ID of recipient (users)
type e.g. friend request-response / admin message
author_folder outbox/draft/delete
user_folder inbox/delete
user_status read or not
date_create
bookmarks
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
title title of link
description some description
date_create
Небольшое примечание:
* для полей ввида date_create и date_update используем функцию gmdate(’Y-m-d H:i:s’) - время по Гринвичу, это облегчит в дальнейшем жизнь при отображении времени на сайте.
Команда
Какую лучше всего собрать команду для разработки такого проекта? Я предлагаю следующий вариант:
* 2 PHP-разработчика
* Flash разработчик / дизайнер
* 1 администратор
* 1 тестировщик
* 1 менеджер
Оценка
Гость
Статические странички такие как “Contact Us”, “Terms of Use” etc. 1h/page
Поиск простенький поиск по нескольким параметрам 6h
Облако тэгов 8h
Просмотр видео FLV video player 16h
Просмотр комментариев 6h
Регистрация включая валидацию e-mail 12h
Напоминалка пароля 2h
Пользователь
Login/Logout 2h
Upload file 14h
Запись видео Необходим один из следующих серверов:
FMS, Wowza (from Feb 2007) or Red5 (opensource) 16h
Progress bar 16h
Добавление комментария 4h
Система рейтингов 2h
Закладки create/edit/delete 8h
Администратор
Управление пользователями Список пользователей, просмотр и редактирование профайлов 16h
Управление категориями 16h
Остальное
Дизайн 32h
Разработка БД 16h
Разработка архитектуры 32h
Хранилище файлов от 8h до 96h 8h
Конвертирование видеофайлов 20h
Итого
Настройка серверов web-server, convert-server, mirrors 40h
Разработка 256h
Тестирование 30%-50% от разработки 85h
Менеджмент 10% минимум 40h
Итого: 421h
Да уж, не мало - 421 часа, т.е. примерно 2,5 месяца разработки… и это еще очень оптимистическая оценка, с учётом, что разработчики используют свои наработки или какую-либо CMF систему аналогичную Zend Framework или phpXCore, а так же организовываем простейшее хранилище файлов. Если же разработка будет вестись с нуля - то можно смело умножать данную оценку на 2.
Итого, такой проект будет стоить не менее $10 000…
P.S.
Основная проблема не в реализации системы, а в привличениии аудитории, кто будет пользоваться вашим сервисом если есть YouTube (и даже PornoTube)? Чем завлечь? Если есть идеи - пишите каменты…
На момент написания статьи домен MyPHPTube.com не был зарегистрирован, если вы его таки зарегистрировали, вышлете пива на мой домашний адрес…
Есть несколько причин побудивших написать данную статью:
1. хотелось написать умную статью для своего блога (или претендующую на “умную”)
2. хотелось показать, что Package Program таки может пригодиться
3. продемонстрировать, что OpenSource и LAMP тоже рулит
Архитектура YouTube
Иван Блинков
Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?
Источники информации
В отличии от остальных, этот перевод статьи от Todd Hoff‘а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:
* Google Video
Платформа
* Apache
* Python
* Linux (SuSe)
* MySQL
* psyco, динамический компилятор Python → C
* lighttpd для видео
Что внутри?
Статистика
* Поддержка обработки более 100 миллионов видеороликов в сутки
* Сервис был запущен в феврале 2005 года
* В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
* К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
* Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных
Рецепт управления огромными темпами роста
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}
Этот цикл проходит далеко не одну итерацию ежедневно.
Веб-серверы
* NetScalar используется для балансировки нагрузки и кэширования статического контента.
* Apache работает с включенным mod_fast_cgi
* Запросы отправляются на обработку с помощью серверного приложения на Python.
* Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
* Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
* Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
* Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
* На формирование страницы обычно уходит не более 100 миллисекунд.
* psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
* Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
* Какая-то часть заранее сгенерированного HTML хранится в кэше.
* Кэширование данных в СУБД на уровне строк.
* Кэшируются полностью сформированные объекты Python.
* Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.
Управление видео
* Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
* Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
* Использование кластеров влечет за собой:
– увеличение производительности пропорционально количеству дисков, на которых расположен контент;
– возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров;
– возможность организации создания резервных копий online.
* В роли HTTP-сервера для работы с видео используется lighttpd:
– Он способен дать фору Apache в плане производительности предоставления статического контента;
– Для работы с событиями ввода-вывода используется epoll;
– Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
* Самая популярная часть контента размещается в CDN
– CDN реплицирует весь контент в разных частях системы;
– Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
* Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation:
– Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках;
– В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств;
– Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность;
– Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.
Ключевые моменты
* Чем проще - тем лучше;
* Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
* Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
* Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
* Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.
Управление миниатюрами видео
* На удивление сложно решаемая задача, особенно если необходима эффективность;
* Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
* Миниатюры хранятся всего на нескольких компьютерах;
* Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов:
– Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode‘ов файловой системы;
– Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея;
– Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов;
– В условиях таких нагрузок Apache показывает плохую производительность;
– Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20;
– Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность;
– С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов;
– Перезагрузка занимала 6-10 часов, так как кэш должен был “разогреться” прежде чем перестать использовать данные с жестких дисков.
* Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google:
– Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе.
– Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети.
– Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.
Базы данных
* Раньше:
– MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее.
– Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков;
– Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день.
– Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре.
– Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них.
– Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации.
– Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации.
– Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
* Сейчас:
– Используются распределенные базы данных;
– Сегментированная система (прим.: по аналогии с Flickr);
– Распределенные чтение и запись;
– Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;
– Такая архитектура привела к 30%-й экономии на оборудовании;
– Задержки в реплицировании сведены к нулю;
– Размеры базы данных могут расти практически неограниченно
Стратегия размещения в датацентрах
* Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
* Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
* Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
* Было использовано 5 или 6 разных датацентров в дополнение к CDN.
* Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
* Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
* Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
* Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.
Подводим итоги
* Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
* Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
* Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
* Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
* Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
* Постоянная работа над поиском и устранением узких мест в системе:
– на программном уровне это чаще всего бывает кэширование и работа с СУБД;
– на уровне операционной системы - операции ввода-вывода;
– на уровне оборудования - оперативная память и RAID массивы.
* Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.
Взято тут
http://www.insight-it.ru/net/scalability/arkhitektura-youtube/
-~{}~ 25.08.08 17:14:
================================================
От Anton.Shevchuk
MyPHPTube.com (клонируем YouTube)
С возросшей популярностью сервиса YouTube.com многим захотелось организовать подобный сервис, но как это сделать? Приведу небольшой рецепт организации такого сервиса.
Функциональность
Для начала опишем основной функционал сайта (сразу определимся и с ролями пользователей):
1. Гость
* просмотр видеофайлов на сайте
2. Пользователь
* аплоад видеофайлов
3. Администратор
* управление пользователями
* управление файлами
WEB 2.0 фичи
А теперь расширем наш базовый функционал, чтобы привлечь аудиторию:
1. Гость
* просмотр комментариев к видеофайлам
* поиск файлов (по категории, по тегам)
2. Пользователь
* возможность оставлять комментарии к видеофайлам
* возможность записывать видеофайлы с web-камеры
* возможность связывать видеоролик с категорией
* возможность связывать видеоролик с несоклькими тегами (tags)
* выставление рейтинга видеофайла
* организация списка друзей
* внутренняя mail система
* закладки
3. Администратор
* управление комментариями
* управление категориями
Это конечно не весь функционал YouTube, но ведь нужно с чего-то начинать
Конфигурация сервера
Наша система будет базироваться на LAMP:
* Linux
* Apache (версия 2.2 и выше)
* MySQL (версия 5.0 и выше)
* PHP (версия 5.2 и выше)
Возможные проблемы
А теперь расскажем о проблемах с которыми Вам предстоит столкнуться
Конвертирование Видео
Если позволить каждому из посетителей сайта заливать на сервер видеоролики в произвольном формате, то для того, чтобы просмотреть их все, Вам прийдется устанавливать на свой компьютер очень много кодеков, а если требовать определенный формат от пользователя - то, с очень большой вероятностью, это отпугнет от вашего сайта поситителей. И что же делать? Правильно, конвертировать все видеофайлы в один формат, и будем конфертировать в формат FLV (flash video - можно просматривать в большинстве операционных систем, поскольку он использует широко распространённый Adobe Flash Player и плагины к большинству браузеров, а также поддерживается многими программами для воспроизведения видео, например, MPlayer, VLC media player и другими программами, работающими с помощью DirectShow).
Нам понадобятся следующие програмные средства (всё opensource):
1. mencoder или FFmpeg
2. flvtool2 (требует наличия Ruby)
3. PHP Program Package (’example.php’ пример конвертации с использованием mencoder’a) или ffmpeg class (’ffmpeg.example1.php’ пример конвертации с использованием ffmpeg)
Дополнительно можно еще использовать mplayer для получения информации о оригинальном видеоролике.
Замечательно, если мы всё установили и правильно собрали, то мы теперь можем конвертировать…
Статус загрузки
Еще такой момент - пользователям не нравиться сидеть и ждать пока файл загрузится на сервер, пользователь он же любознательный, ему хотя бы вывести progress bar надо:
* http://www.emllabs.com/article.php?articleId=121/ (используя Flash8 и PHP)
* http://tomas.epineer.se/tesupload/
* http://www.raditha.com/megaupload/
* http://www.obokaman.com/p/descripcion-y-fuentes-del-upload-php-ajax-con-barra-de-progreso-1596
* http://labs.beffa.org/w2box/demo/
* http://trydobe.com/?page_id=3
* http://ecosmear.com/relay/ (прикольный примерчик, используется perl)
Все ссылки нарыл на форуме xajax’a http://community.xajaxproject.org/viewtopic.php?pid=10100
Ресурсы
Так, на сервер мы залили видеофайл, показали как он быстро к нам заливался, но вот беда, если мы будем на нашем web-сервере конвертировать видео ролики - то сайт у нас будет скорее мёртв, чем жив. Для этой цели нам надо будет использовать еще один (как минимум) сервер, который будет забирать неотконвертированный файлы с web-сервера и отправлять назад отконвертированные ролики. Т.е. для решение данной проблемы нам понадобиться еще железо…
Распределение нагрузки
Конвертирование это ресурсоемко, а отдавать видеоролики всем желающим?… Это конечно не будет так нагружать процессор, но вот канал точно умрет… как выход у нас появляются еще сервера, которые и хранят у себя видеофайлы:
* http://mirror1.myphptube.com
* http://mirror2.myphptube.com
* и т.д.
Как распределять нагрузку - это уже решать Вам. Но прежде, чем городить огород Вы должны определить какой приблизительно объем данных Вам прийдеться хранить, и далее уже решать какая схема больше подойдет, ориентируемся, что 1 пользователь заливает на сервер 20mb в месяц (234Gb на 1000 пользователей в год), не популярные ролики не сохраняются более года):
* Объём данных ~ 0.3Tb - 1.5Tb:
на каждом зеркале у нас хранятся все видеоролики
у нас есть mirror1 - сервер на котором всегда первым появляется переконвертированный видеоролик, остальные с ним синхронизируются
* Объём данных ~ 1.5Tb - 3 Tb:
все видеоролики храняться только на одном главном сервере, если у видеоролика растет популярность, он заливается и на другие зеркала
* Объём данных > 3Tb:
видеролик заливается на ближайшее зеркало (подразумеваем, что ролик залитый китайцем будут смотреть в основном китайцы, следовательно заливаем его на зеркало в Китае)
по мере роста популярности ролика зеркалим его на сервер ближайший к эпицетру популярности (пример: китаец живет в США, его ролик залит на зеркало расположенное в США, смотрят его в основном в Китае, видя это ролик будет отзеркален на Китайский сервер)
Числа взяты с потолка, против китайцев ничего не имею (просто взяты для примера), пишите свои варианты…
База данных
Далее я опишу простенькую архитектуру БД:
users
id autoincrement field
login unique login
password encrypt password
email user email
actcode activation code
role ENUM(guest/user/admin)
status not active / active / disable
date_create
date_update date of last change profile
date_login date of last login
… another fields e.g. first name, last name
friends
id autoincrement field
user_id1 user ID
user_id2 user ID
status request / ok / cancel
date_create date of send request
date_update date of accept or denied request
files
id autoincrement field
title title of video file
file name of file on file system
status not convert / in process / ok
access public / members only / friends only / private
author_id ID of owner (users)
category_id ID of category (categories)
date_create
date_update date of last changes
… another fields e.g. length, description
mirrors
id autoincrement field
url mirror url
date_create
date_update date of last changes
mirrors_link
file_id ID of file (files)
mirror_id ID of mirror (mirrors)
status current file status downloading / ok
date_create
date_update date of last changes
categories
id autoincrement field
pid parent category ID
name name of category
… another fields e.g. metadescription, metakeywords
tags
id autoincrement field
word tag word
tags_link
id autoincrement field
tag_id tag ID (tags)
file_id file ID (files)
comments
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
message text of message
date_create
rate
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
rate integer value, e.g. for 0 to 10
date_create
messages
id autoincrement field
author_id ID of owner (users)
user_id ID of recipient (users)
type e.g. friend request-response / admin message
author_folder outbox/draft/delete
user_folder inbox/delete
user_status read or not
date_create
bookmarks
id autoincrement field
author_id ID of owner (users)
file_id file ID (files)
title title of link
description some description
date_create
Небольшое примечание:
* для полей ввида date_create и date_update используем функцию gmdate(’Y-m-d H:i:s’) - время по Гринвичу, это облегчит в дальнейшем жизнь при отображении времени на сайте.
Команда
Какую лучше всего собрать команду для разработки такого проекта? Я предлагаю следующий вариант:
* 2 PHP-разработчика
* Flash разработчик / дизайнер
* 1 администратор
* 1 тестировщик
* 1 менеджер
Оценка
Гость
Статические странички такие как “Contact Us”, “Terms of Use” etc. 1h/page
Поиск простенький поиск по нескольким параметрам 6h
Облако тэгов 8h
Просмотр видео FLV video player 16h
Просмотр комментариев 6h
Регистрация включая валидацию e-mail 12h
Напоминалка пароля 2h
Пользователь
Login/Logout 2h
Upload file 14h
Запись видео Необходим один из следующих серверов:
FMS, Wowza (from Feb 2007) or Red5 (opensource) 16h
Progress bar 16h
Добавление комментария 4h
Система рейтингов 2h
Закладки create/edit/delete 8h
Администратор
Управление пользователями Список пользователей, просмотр и редактирование профайлов 16h
Управление категориями 16h
Остальное
Дизайн 32h
Разработка БД 16h
Разработка архитектуры 32h
Хранилище файлов от 8h до 96h 8h
Конвертирование видеофайлов 20h
Итого
Настройка серверов web-server, convert-server, mirrors 40h
Разработка 256h
Тестирование 30%-50% от разработки 85h
Менеджмент 10% минимум 40h
Итого: 421h
Да уж, не мало - 421 часа, т.е. примерно 2,5 месяца разработки… и это еще очень оптимистическая оценка, с учётом, что разработчики используют свои наработки или какую-либо CMF систему аналогичную Zend Framework или phpXCore, а так же организовываем простейшее хранилище файлов. Если же разработка будет вестись с нуля - то можно смело умножать данную оценку на 2.
Итого, такой проект будет стоить не менее $10 000…
P.S.
Основная проблема не в реализации системы, а в привличениии аудитории, кто будет пользоваться вашим сервисом если есть YouTube (и даже PornoTube)? Чем завлечь? Если есть идеи - пишите каменты…
На момент написания статьи домен MyPHPTube.com не был зарегистрирован, если вы его таки зарегистрировали, вышлете пива на мой домашний адрес…
Есть несколько причин побудивших написать данную статью:
1. хотелось написать умную статью для своего блога (или претендующую на “умную”)
2. хотелось показать, что Package Program таки может пригодиться
3. продемонстрировать, что OpenSource и LAMP тоже рулит
