Архитектура высоконагруженного мультимедиапортала

Рассмотрим архитектуру высоконагруженного мультимедиапортала на примере портала YouTube.

Подходящими для использования в данном случае являются следующие платформы:

  • • 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();

sleepO;

notice_new_bottleneck();

}

Этот цикл проходит далеко не одну итерацию ежедневно.

Относительно веб-серверов известно следующее.

NetScalar используется для балансировки нагрузки и кэширования статического контента.

Apache работает с включенным mod_fast_cgi.

Запросы отправляются на обработку с помощью серверного приложения на Python.

Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.

Масштабирование обычно происходит просто добавлением дополнительных компьютеров.

Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.

Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.

На формирование страницы обычно уходит не более 100 мс.

Psyco, динамический компилятор Python —» С, использует ЛТ подход к компилированию для оптимизации внутренних циклов

Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на языке С.

Часть ранее сгенерированного HTML-кода хранится в кэше.

Кэширование данных в СУБД призводится на уровне строк.

Кэшируются полностью сформированные объекты Python.

Некие данные вычисляются и отправляются каждому серверу для кэширования в локальной оперативной памяти.

Приведенная стратегия может использоваться далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

В части управления видео отметим следующее.

Издержки включают затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.

Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.

Использование кластеров влечет за собой:

  • • увеличение производительности пропорционально количеству дисков, на которых расположен контент;
  • • возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров;
  • • возможность организации создания резервных копий онлайн.

В роли HTTP-сервера для работы с видео используется lighttpd. Он имеет преимущества перед Apache в плане производительности предоставления статического контента. Для работы с событиями ввода/вывода используется epoll. Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно.

Самая популярная часть контента размещается в CDN:

  • • CDN реплицирует весь контент в разных частях системы;
  • • компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.

Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах согласно услуге colocation. У этого подхода следующие особенности:

  • • несмотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках;
  • • в такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств;
  • • более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может весьма положительно повлиять на производительность;
  • • выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Отметим ключевые моменты в создании архитектуры.

Максимальное упрощение. Необходимо минимизировать количество устройств (маршрутизаторов, коммутаторов и т.п.) между контентом и пользователями: так как неизвестно, все ли они будут способны выдерживать интенсивную нагрузку.

Использование самого обычного оборудования. Hi-end-обору- дование, как правило, обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождения решения той или иной проблемы с оборудованием в Сети.

Использование самых распространенных утилит. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе.

Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.

Управление миниатюрами видео — на удивление сложно решаемая задача, особенно если необходима эффективность:

  • • для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
  • • миниатюры хранятся всего на нескольких компьютерах.

При этом в связи с работой большого количества маленьких

объектов существует ряд затруднений:

  • • проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode'oB файловой системы;
  • • ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе — не оптимальное решение;
  • • большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов;
  • • в условиях таких нагрузок Apache показывает плохую производительность;
  • • эксперименты с использованием squid (обратной proxy) между Apache и посетителями показали, что с ростом нагрузки производительность падает — с 300 до 20 обработанных запросов в секунду;
  • • попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность;
  • • с таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов;
  • • перезагрузка занимала 6—10 часов, так как кэш должен был «разогреться» прежде чем перестать использовать данные с жестких дисков.

Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google:

  • • устраняются проблемы, связанные с большим количеством файлов, так как объединяются маленькие файлы;
  • • система работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети;
  • • уменьшаются задержки, так как используется распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Обратимся теперь к особенностям работы баз данных.

До применения предложенного решения ситуация складывалась следующим образом.

MySQL использовалась для хранения данных: пользователей, тэгов, описаний и т.д.

Данные хранились на монолитном массиве RAID 10, состоящем из 10 жестких дисков.

Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости при- менния нового оборудования на оформление заказа и доставку требовался не один день.

Долгий эволюционный путь развития: вначале использовался один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, далее база данных была разбита на части, и наконец, создана полноценная распределенная архитектура.

Поначалу система страдала от задержек, связанных с репли- цированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные серверы, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них.

Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло серверы читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации.

Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации.

Основным кардинальным архитектурным решением стало отделение обеспечения процесса просмотра видео от основного кластера. Главной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.

В настоящее время ситуация складывается следующим образом. Используются:

  • • распределенные базы данных;
  • • сегментированная система (по аналогии с Flickr);
  • • распределенные чтение и запись;
  • • более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;

Такая архитектура привела к 30 %-ной экономии на оборудовании; задержки в реплицировании сведены к нулю; размеры базы данных могут расти практически неограниченно.

Стратегия размещения в датацентрах. Ранее использовались хостинг-провайдеры, предоставляющие услуги colocation — не самый экономичный подход, но другого выхода не было. При этом хостинг-провайдеры не успевают обеспечивать соответствующие темпы роста проекта; не всегда имеют контроль над соответствующим оборудованием или соответствующие соглашения о предоставлению сетевых услуг.

Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все оборудование и подписывать свои собственные контракты. В дополнение к CDN было использовано 5 или 6 разных датацентров.

В частности, поступившее из случайного датацентра видео не подвергается никаким специальным проверкам, но если ролик становится достаточно популярным — он перемещается в CDN.

Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.

Для изображений более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.

Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

Резюмируем вышесказанное.

  • 1. Обоснованность. Креативные и рискованные трюки помогут справиться с задачей на короткое время, но со временем понадобятся более продуманные решения.
  • 2. Расстановка приоритетов. Определите, какие части вашего сервиса важнее всего и стройте систему обеспечения ресурсами именно в соответствии с поставленными приоритетами.
  • 3. Ноу-хау. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком дорого и потребовало бы слишком много времени. Возможно у вас появятся подобные возможности в отношении системы.
  • 4. Простота. Оперативное изменение архитектуры позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает, что значит просто, но если вы не боитесь перемен, то это знак что вашей системе свойственна та самая простота.
  • 5. Сегментирование. Позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод/вывод. Выполняется не только для повышения производительности операций записи.
  • 6. Постоянная работа над поиском и устранением узких мест в системе:
    • • на программном уровне это чаще всего кэширование и работа с СУБД;
    • • на уровне операционной системы — операции ввода/вы- вода;
    • • на уровне оборудования — оперативная память и RAID массивы.
  • 7. Командная работа. Хорошая команда разного рода специалистов понимает общий принцип работы системы и при этом каждый делает свое дело.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >