Архитектура YouTube - Linux - Каталог статей

Рост 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 массивы.
Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.