Архитектура YouTube 2012

Выбирайте самое простое решение с наиболее общими гарантиями, которые практически полезны.
— Дао YouTube

 

YouTube практически на протяжении всех 7 лет своего существования является мировым лидером в сфере интернет-видео. С точки зрения технической реализации проект оказался достаточно консервативным — команда придерживается того же курса и стека технологий, с которых все начиналось еще до приобретения проекта Google. Но с 2008 года, когда я написал первый обзор архитектуры YouTube, все же произошли интересные изменения, о которых я и хотел бы сегодня вкратце рассказать.

 Статистика

  • 4 млрд. просмотров страниц в день
  • 60 часов видео загружается каждую минуту
  • 350 миллионов устройств подключено к YouTube
  • На февраль 2012 года в США по данным comScore:
    • 147,4 млн. уникальных зрителей
    • 16,7 млрд. просмотров видео (в октябре 2011 было больше 20 млрд.)
    • Каждый зритель посмотрел в среднем 7 часов видео за месяц
    • 1.1 млрд. просмотров видео рекламы, суммарной длительностью в 10.8 млн. часов

Технологии

  • Linux — операционная система
  • Apache — основной HTTP-сервер
  • lighttpd — отдача видео из YouTube CDN
  • Zookeeper — распределенные блокировки, хранение конфигураций
  • Python:
    • wiseguy — FastCGI-прослойка между Apache и Python
    • pycurl — лучшая доступная реализация HTTP-клиента, но в итоге все равно заменили на самописное низкоуровневое решение, выиграв 8% в потреблении вычислительных ресурсов.
    • spitfire — высокопроизводительный шаблонизатор на основе абстрактного синтаксического дерева с регулируемым уровнем оптимизации (как в gcc)
    • bson в качестве формата сериализации
  • BigTable — хранение изображений
  • MySQL — используется просто как хранилище данных, версия 5.1.52 с InnoDB
  • Vitess — система для масштабирования MySQL-кластера

Vitess

  • Основная цель проекта — предоставление всех необходимых инструментов и серверов для горизонтального масштабирования баз данных на основе MySQL, с учетом потребностей современных интернет-проектов.
  • Реализован на Go — все еще экзотическом языке программирования, также родившемся в стенах Google. Сравним по производительности с C++ и Java, но несколько более «выразителен».
  • Опубликован в opensource 24 февраля 2012 года, совсем недавно, так что YouTube — по-прежнему единственный пример его использования на практике в крупном проекте.
  • Готовые клиентские библиотеки пока только для Python и Go, что не удивительно, но есть и универсальные интерфейсы на основе HTTP и просто TCP-сокетов.
  • Основной формат данных — bson, как и в MongoDB, но по словам разработчиков Vitess их реализация выполняет (де)сериализацию в 10-15 раз быстрее.
  • Ядром проекта выступает Vtocc,  SQL-прокси с RPC интерфейсом, позволяющий перераспределять запросы от большого количества (более 10 тыс.) одновременно подключенных клиентов в сравнительно небольшое количество соединений с базами данных. Пропускная способность порядка 10 тыс. запросов в секунду.
  • Встроенные возможности Vtocc:
    • парсер и анализатор SQL-запросов для оптимизации их выполнения;
    • заполнение типичных запросов переменными с поддержкой кэширования результатов;
    • управление транзакциями и сроками их выполнения («убивает» затянувшиеся);
    • для каждого пространства ключей (логической таблицы) можно указать фактор репликации, что создаст необходимое количество второстепенных баз данных в дополнение к мастеру;
    • можно явно указать, что чтение необходимо произвести с мастера (важно когда пользователь только что выполнил какое-то действие и должен сразу же увидеть его результат);
    • отдельные пулы соединений для выполнения операций чтения и записи;
    • исключение «зависших» соединений из пулов;
    • перезапуск без простоя системы;
    • поддержка DML.
  • Партиционирование:
    • Во всех таблицах должна быть колонка с уникальным ключем, на основе которого данные будут распределяться по кластеру.
    • Партиционирование основано на диапазонах ключей, что позволяет держать «карту» партиций в памяти и очень быстро определять где располагаются те или иные данные, но обратной стороной медали является вероятное возникновение «горячих» узлов в кластере, особенно при монотонно увеличивающихся значениях ключей (рекомендуется использовать случайные).
    • Поддерживаются ключи в виде натуральных чисел или произвольных бинарных данных.
    • При высокой нагрузке на одну партицию она может быть распределена на две путем фильтрованной репликации; в дальнейшем планируется реализовать и обратный процесс.
    • Еще в планах:
      • Поэтапное внесение изменений в схему данных без видимого простоя системы;
      • Поддержка работы в нескольких датацентрах с концентрацией мастер-серверов в одном датацентре и использования остальных в режиме только для чтения.

Подводим итоги

 

  • YouTube — еще один проект мирового масштаба, который с самого начала использовал MySQL и оказался не в силах от него отказаться, не смотря на трудности с горизонтальным масштабированием.
  • По аналогичному пути пошли и другие проекты, схожие с Vitess надстройки над MySQL используются в Facebook и Twitter:
    • В Facebook она дополнена сильной интеграцией с memcached и сильно ограниченным интерфейсом, не имеющим практически ничего общего с SQL. Планы о публикации в opensource, кажется, были, но я не слышал чтобы они воплотились в жизнь. // Уже почти дописав статью случайно заметил в коде, а потом и мелким шрифтом в документации, что в Vitess тоже используется memcached для кэширования из-за проблем со сборщиком мусора Go.
    • Twitter по-прежнему использует свою связку FlockDB + Gizzard на Scala, которые уже пару лет публично доступны. В отличии от Vitess она заточена на хранение информации о социальных графах, по-этому сфера её применения как в Twitter, так и за его пределами ограничена.
  • Vitess — пожалуй первая относительно успешная попытка построить распределенную горизонтально масштабируемую СУБД на основе реляционной базы данных, сохранив при этом SQL-интерфейс, пускай и с некоторыми ограничениями.
  • Выбирайте подходящее хранилище для каждого типа данных в системе — если Vitess стал подходящим решением для структурированных данных вроде информации о пользователях, метаданных видео и комментариев, это не значит, что он хорошо (или плохо) справится, например, с медиа-файлами вроде изображений и видео (для них в YouTube по-прежнему используют стек технологий Google, подробности не публикуются).
  • Python — вполне пригодный инструмент для реализации бизнес-логики интернет-проектов, свет клином на PHP не сошелся. Python предлагает широкий ассортимент инструментов для решения любых типичных для интернет-проектов задач, хотя субъективно выбор некоторых из них разработчиками YouTube мне кажется странным.

Источники информации

www.insight-it.ru/masshtabiruemost/arkhitektura-youtube-2012/

 

Вверх