Материалы:
Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?
Платформа:
. 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();
}
Этот цикл проходит далеко не одну итерацию ежедневно.
Базы данных
Раньше: — MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее.?— Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков;?— Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день.?— Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре.
Сейчас:
— Используются распределенные базы данных;
— Сегментированная система (прим.: по аналогии с Flickr);
— Распределенные чтение и запись;
— Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;
— Такая архитектура привела к 30%-й экономии на оборудовании;
— Задержки в реплицировании сведены к нулю;
— Размеры базы данных могут расти практически неограниченно
Стратегия размещения в датацентрах
Поначалу использовались хостинг-провайдеры, предоставляющие услуги colocation. Подобный подход нельзя было избежать на начальном этапе, несмотря на всю его неэкономичность.
Хостинг-провайдеры не могут поспеть за темпами роста подобного проекта. Поскольку не всегда получается своевременно получить контроль над необходимым оборудованием или сделать необходимые дополнительные соглашения о предоставлению сетевых услуг – данный вариант размещения не подходит.
Решением этой проблемы для YouTube стало создание собственной базы для размещения оборудования. С внедрением этого подхода появилась возможность настраивать абсолютно все необходимое в кратчайшие сроки и подписывать уже собственные контракты такого рода.
Было использовано 5 или 6 разных датацентров в дополнение к CDN. Их параллельное взаимоувязанное использование дало возможность ресурсу прогрессировать.
В настоящее время процесс осуществляется следующим образом: Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным — он перемещается в CDN.
Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
Что касается изображений – для них более актуальны задержки, особенно если на одной странице должно быть размещено около 60 изображений. Репликация изображений производится средствами BigTable. В этом случае используются различные способы для определения ближайшего места, откуда можно получить необходимые данные.