Интересное видео с конференции, где рассмотрены основные вопросы масштабирования, которые встретились команде YouTube и как они были решены в данной статье.

Онлайн видео портал YouTube вырос невероятно быстро, более миллиарда просмотров видео в день, с командой из нескольких экспертов. Как они справились с задачей доставки видео всем пользователям? И как развивалась обстановка после приобретения YouTube компанией Google?
Платформа

• Apache
• Python
• Linux (SuSe)
• MySQL
• psyco, динамический python->C компилятор
• lighttpd для видео вместо Apache

Взгляд изнутри

• Более одного миллиарда просмотров видео в день
• Основан 2/2005
• 3/2006 30 миллионов просмотров в день
• 7/2006 100 миллионов просмотров в день
• 2 системных администратора, 2 архитектора по масштабированию
• 2 разработчика интерфейсов, 2 сетевых инженера, 1 DBA

Рецепт управления ростом

Данный цикл нужно запускать много раз в день.

Веб сервера

• NetScalar используется для балансировки нагрузки и кеширования статичного контента.
• Apache запускается с mod_fast_cgi.
• Запросы маршрутизируются на обработку серверу приложений на Python.
• Сервер приложений общается с различными БД и другими источниками информации, необходимыми.
• Горизонтальное масштабирование простым добавлением машин.
• Код Python обычно не является узким местом, большинство времени он ожидает ответа RPC.
• Python позволяет быструю и гибкую разработку и внедрение новых функций. Это особо критично в свете сложностей, с которым сталкивается проект.
• Обычно менее 100 мс на обработку страницы.
• Использование psyco, динамического python->C компилятора, который при помощи JIT подхода оптимизирует внутренние циклы.
• Для высокозатратных действий для CPU, таких как шифрование, используются С расширения.
• Предвариетльная генерация и кеширование HTML для тяжелых в рендеринге страниц.
• Кеширование на уровне записей в БД.
• Полностью сформированные объекты Питона кешируются.
• Некоторые данные вычисляются и отправляются в приложение, где они кешируются в локальной памяти. Это малоиспользуемая стратегия. Самый быстрый кеш в сервере приложений и это не занимает много времени, разослать предварительно вычисленные данные на все сервера. Нужен только агент, который мониторит изменения, делает предварительные вычисления и отправляет данные.

Доставка видео

• Стоимость доставки включает стоимость канала, оборудования и энергопотребления.
• Каждое видео обслуживается мини кластером. Каждое видео обслуживается более чем одним сервером.
• Использование кластера означает:
  • больше дисков обслуживают контент — больше скорость чтения.
  • централизованное управление — если один сервер выходит из строя, другие берут на себя его функции.
  • онлайн бэкап.
• Сервера используют lighttpd для видео:
  • Apache обладал большим оверхедом.
  • Использует epoll для ожидания множества fds.
  • Переключились с одного процесса на многопроцессную конфигурацию для обслуживания большего количества подключений.
• Наиболее популярный контент передается CDN:
  • CDN реплицирует контент в нескольких местах. Таким образом увеличивается вероятность нахождения контента ближе к пользователю, с меньшим числом hop’ов.
  • CDN сервера выдают контент из памяти, т.к. контент очень популярен, поэтому передвижение контенти из кеша и в кеш случаются редко
• Менее популярный контент (1-20 просмотров в день) использует сервера YouTube с различных площадок.
  • Эффект длинного хвоста. Видео редко смотрят, но такого видео очень много. Необходим доступ к произвольным секторам дисков.
  • Кеширование контента не особо помогает в данном случае, поэтому затраты на кеш скорее всего не дадут результата. Поэтому если Ваш продукт обладает эффектом длинного хвоста, то скорее всего механизмы кеширования Вас не спасут.
• Тюнинг RAID контроллера и других низкоуровневых вещей, которые могут помочь.
• Тюнинг памяти на серверах до оптимального размера.

Обслуживание скриншотов

• Удивительно сложно реализовать эффективно.
• Каждому видео соответствует 4 скриншота, поэтому скриншотов гораздо больше.
• Скриншоты хранятся на 4х машинах.
• Встретили проблемы обработки большого количества мелких объектов:
  • Большое количество seek’ов по диску и проблемы inode кешем и page кешем на уровне ОС.
  • Достигли лимита директорий, в частности Ext3. Перешли на более иерархическую структуру.
  • Последние доработки в 2.6 kernel могут улучшить Ext3 работу с большими директориями в 100 раз, но вообще хранение большого количества файлов в файловой системе не очень хорошая идея.
  • Большое количество запросов в секунду, т.к. одна страница может иметь до 60 скриншотов.
  • Под такой нагрузкой Apache вел себя плохо.
  • Использовалие squid (reverse proxy) перед Apache’м. Некоторое время это спасало, но с ростом нагрузки производительность падала (с 300 запросов в секунду до 20).
  • Попробовали использовать lighttpd но с единым потоком он подвисал. Встретили проблемы многопроцессности, т.к. каждый процесс содержал свой отдельный кеш.
  • С таким количеством изображений установка нового сервера занимала 24 часа.
  • Перезагрузка машини занимала 6-10 часов на прогрев кеша и сокращения количества обращений к жесткому диску.
• Для решения проблем начали использовать Google BigTable, распределенное хранилище данных:
  • Устранение проблемы мелких файлов, т.к. файлы слепляются
  • Быстрый, отказоустойчиывай. Предполагает работу в ненадежной сети.
  • Сниженные задержки, т.к. используется распределенный многоуровневый кеш. Этот кеш работает между множеством разных площадок с оборудованием.

База данных
Ранние годы:

• Используют MySQL для хранения метаданных, таких как пользователи, теги и описания.
• Обслуживали данные монолитными разделами RAID 10 с 10 дисками.
• Прошли стандартные этапы эволюции: один сервер, один мастер с несколькими серверами на чтение, partitioning базы данных, переход к шардам.
• Проблемы с задержками репликации. Мастер многопоточный запускался на мощном сервере, так что он мог обрабатывать много запросов. Сервера на чтение однопоточные и, как правило, запускались на менее производительных машинах. Репликация асинхронная, поэтому сервера на чтение могли существенно отставать от мастера.
• Использование архитектуры с репликацией приводит к существенным затратам на производительность записи реплицируемых данных.
• Одним из решений была приоритезация трафика при помощи разделения его на два кластера — кластер видео доставки и кластер общего назначения. Идея была в том, что просмотр видео является основной функцией, на которую должно выделяться больше ресурсов. Социальные функции менее приоритетны и они могут обрабатываться менее производительным кластером.

Последние годы:

• Перешли на использование partitioning
• Разделили БД на шарды, пользователей распределяют по разным шардам.
• Рспределение чтения и записи.
• Повышенная локальность кеша, приводящая к меньшему количеству IO.
• Привело к 30% снижению количества оборудования.
• Снизили задержку реплицирования до нуля.
• Возможность неограниченного масштабирования БД.

Выводы

Борьба за время. Креативные и рискованные заплатки могут решить проблему в краткосрочной перспективе пока Вы работаете над долгосрочным решением.
Приоритеты. Знайте, что наиболее важно для Вашего сервиса и расставляйте приоритеты Вашему персоналу, концентрируйте усилия на приоритетных направлениях.
Ввязывайтесь лишь в свои битвы. Не бойтесь аутсорсинга некоторых основополагающих сервисов. YouTube использует CDN услуги для доставки наиболее популярного контента. Создание своей собственной сети доставки занимает слишком много времени и стоит слишком дорого. Скорее всего у Вас есть такие же возможности для повышения эффективности Вашего проекта. Обратите взгляд на идеологию Software/Infrastructure as a Service за дополнительными идеями.
Сохраняйте простоту! Простота реализации позволяет Вам изменять архитектуру намного быстрее, тем самым Вы можете решать проблемы существенно быстрее. Правда в том, что никто не знает, что такое простота, но если Вы не боитесь делать изменения — то это хороший знак того, что простота имеет место быть.
Шард (Shard). Механизм шард позволяет изолировать хранение данных, CPU, память и операции IO. Это не только увеличивает производительность записи.
Постоянные итерации по узким местам:
— ПО: БД, кеширование
— ОС: операции I/O
— Оборудование: память, RAID
Команда. Наличие хорошей, разносторонне опытной команды, которая понимает как работает система в целом и что внутри системы. С хорошей командой возможно все.