Insight IT

Архитектура Tumblr

Иван Блинков — Tue, 21 Feb 2012 16:29:00 +0400

Tumblr - одна из самых популярных в мире платформ для блоггинга, которая делает ставку на привлекательный внешний вид, юзабилити и дружелюбное сообщество. Хоть проект и не особо на слуху в России, цифры говорят сами за себя: 24й по посещаемости сайт в США с 15 миллиардами просмотров страниц в месяц. Хотите познакомиться с историей этого проекта, выросшего из простого стартапа?

Введение

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

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

Платформа

CentOS на серверах, Mac OS X для разработки
Apache - основной веб-сервер
PHP, Scala, Ruby - языки программирования
Finagle - асинхронный RPC сервер и клиент
MySQL, HBase - СУБД
memcached, Redis - кэширование
Varnish, nginx - отдача статики
HAProxy - балансировка нагрузки
kestrel, gearman - очередь задач
Thrift - сериализация
Kafka - распределенная шина сообщений
Hadoop - обработка статистики
ZooKeeper - хранение конфигурации и состояний системы
git - система контроля версий
Jenkins - непрерывное тестирование

Статистика

Около 500 миллионов просмотров страниц в день
Более 15 миллиардов просмотров страниц в месяц
Посещаемость растет примерно на 30% в месяц
Пиковые нагрузки порядка 40 тысяч запросов в секунду
Около 20 технических специалистов в команде
Каждый день создается около 50Гб новых постов и 2.7Тб обновлений списков последователей
Более 1Тб статистики обрабатывается в Hadoop ежедневно
Используется порядка 1000 серверов:
- 500 веб-серверов c Apache и PHP-приложением
- 200 серверов баз данных (существенная их часть - резервные)
  - 47 пулов
  - 30 партиций (шардов)
- 30 серверов memcached
- 25 серверов Redis
- 15 серверов Varnish
- 25 серверов HAProxy
- 8 серверов nginx
- 14 серверов для очередей задач

Типичное использование

Tumblr используется несколько по-другому, чем другие социальные сети:
- При более чем 50 миллионах постов в день, каждый из них попадает в среднем к нескольким сотням читателей. Это и не несколько пользователей с миллионами читателей (например, популярные личности в Twitter) и не миллиарды личных сообщений.
- Ориентированность на длинные публичные сообщения, полные интересной информацией и картинками/видео, заставляет пользователей проводить долгие часы каждый день за чтением Tumblr.
- Большинство активных пользователей подписывается на сотни других блоггеров, что практически гарантирует много страниц нового контента при каждом заходе на сайт. В других социальных сетях поток новых сообщений переполнен ненужным контентом и толком не читается.
- Как следствие, при сложившемся количестве пользователей, средней аудиторией каждого и высокой активностью написания постов, системе приходится обрабатывать и доставлять огромное количество информации.
Публичные блоги называют Tumblelog'ами, они не так динамичны и легко кэшируются.
Сложнее всего масштабировать Dashboard, страницу, где пользователи в реальном времени читают что нового у блоггеров, на которых они подписаны:
- Кэширование практически бесполезно, так как для активных пользователей запросы редко повторяются.
- Информация должна отображаться в реальном времени, быть целостной и не "задерживаться".
- Около 70% просмотров страниц приходится именно на Dashboard, почти все пользователи им пользуются.

Старая архитектура

Когда проект только начинался, Tumblr размещался в Rackspace и последние выдавали каждому блогу с собственным доменом A-запись. Когда они переросли Rackspace, они не смогли полноценно мигрировать в новый датацентр, в том числе из-за количества пользователей. Это было в 2007 году, но у них по-прежнему часть доменов ведут на Rackspace и перенаправляются в новый датацентр с помощью HAProxy и Varnish. Подобных "унаследованных" проблем у проекта очень много.
С технической точки зрения проект прошел по пути типичной эволюции LAMP:
- Исторически разработан на PHP, все началось с веб-сервера, сервера баз данных и начало потихоньку развиваться.
- Чтобы справляться с нагрузкой они начали использовать memcache, затем добавили кэширование целых страниц и статических файлов, потом поставили HAProxy перед кэшами, после чего сделали партиционирование на уровне MySQL, что сильно облегчило им жизнь.
- Они делали все, чтобы выжать максимум из каждого сервера.
- Было разработано два сервиса на C: генератор уникальных идентификаторов на основе HTTP и libevent, а также Staircar, использующий Redis для обеспечения уведомлений в реальном времени на Dashboard.
Dashboard использует подход "разбрасывать-собирать", так как из-за отсортировонности данных по времени традиционные схемы партиционирования работали не очень хорошо. По их прогнозам текущая реализация позволит им рости еще в течении полугода.

Новая архитектура

Приоритетным направлением стали технологии, основанные на JVM, по причине более быстрой разработки и доступности квалифицированных кадров. Мотивация несколько спорная, особенно если учесть, что речь идет в первую очередь о Scala, а не о Java.
Основная цель - вынести все из PHP приложения в отдельные сервисы, что сделает его лишь тонким клиентом к внутреннему API.
Почему выбор пал именно на Scala и Finagle?
- Многие разработчики имели опыт с Ruby и PHP, так что Scala был привлекательным (цитата, логики мало)
- Finagle был одним из основных факторов в пользу JVM: это библиотека, разработанная в Twitter, которая решает большинство распределенных задач вроде маршрутизации запросов и обнаружение/регистрацию сервисов - не пришлось реализовывать это все с нуля.
- В Scala не принято использовать общие состояния, что избавляет разработчиков от забот с потоками выполнения и блокировками.
- Им очень нравится Thrift в роли программного интерфейса из-за его высокой производительности (он кроссплатформенный и к JVM никак не относится)
- Нравится Netty, но не хочется связываться с Java, еще один аргумент в пользу Scala.
- Рассматривали Node.js, но отказались так как под JVM проще найти разработчиков, а также из-за отсутствия стандартов, "лучших практик" и большого количества качественно протестированного кода.
Старые внутренние сервисы также переписываются с C + libevent на Scala + Fingle.
Был создан общий каркас для построения внутренних сервисов:
- Много усилий было приложено для автоматизации управления распределенной системой.
- Создан аналог скаффолдинга - используется некий шаблон для создания каждого нового сервиса.
- Все сервисы выглядят одинаково с точки зрения системного администратора: получение статистики, мониторинг, запуск и остановка реализованы одинаково для всех сервисов.
- Созданы простые инструменты для сборки сервисов без вникания в детали используемых стандартных решений.
Используется 6 внутренних сервисов, над которыми работает отдельная команд. На запуск сервиса с нуля уходит около 2-3 недель.
Новые, нереляционные СУБД, такие как HBase и Redis, вводятся в эксплуатацию, но основным хранилищем по-прежнему остается сильно партиционированный MySQL.
HBase используется для сервиса сокращенных ссылок для постов, а также всех исторических данных и аналитики. HBase хорошо справляется с ситуациями, где необходимы миллионы операций записи в секунду, но он не достаточно стабилен, чтобы полностью заменить проверенное временем решение на MySQL в критичных для бизнеса задачах.
Партиционированный MySQL плохо справляется с отсортированными по времени данными, так как один из серверов всегда оказывается существенно более "горячим", чем остальными. Также сталкивались с значительными задержками в репликации из-за большого количества параллельных операций добавления данных.
Используется 25 серверов Redis с 8-32 процессами на каждом, что означает порядка 300-400 экземпляров Redis в сумме.
- Используется для уведомлений в реальном времени на Dashboard (о событиях вроде "кому-то понравился Ваш пост").
- Высокое соотношений операций записи к операциям чтения сделало MySQL не очень подходящим кандидатом.
- Уведомления не так критичны, их потеря допустима, что позволило отключить персистентность Redis.
- Был создан интерфейс между Redis и отложенными задачами в Finagle.
- Сервис коротких ссылок также использует Redis как кэш, а HBase для постоянного хранения.
- Вторичный индекс Dashboard также построен вокруг Redis.
- Redis также используется для хранения задач Gearman, для чего был написан memcache proxy на основе Finale.
- Постепенно отказываются от memcached в пользу Redis в роли основного кэша. Производительность у них сопоставима.
Внутренним сервисам необходим доступ к потоку всех событий в системе (создание, редактирование и удаление постов, нравится или не нравится и т.п.), для чего была созданна внутренняя шина сообщений (англ. firehose, пожарный шланг):
- Пробовали использовать в этой роли Scribe, но так как оно по сути свелось к пропусканию логов через grep в реальном времени - нагрузки оно не выдержало.
- Текущая реализация основана на Kafka, решению аналогичной задачи от LinkedIn на Scala.
- MySQL также не рассматривался из-за большой доли операций записи.
- Внутри сервисы используют HTTP потоки для чтения данных, хотя Thrift интерфейс также используется.
- Поток сообщений хранит события за последнюю неделю с возможностью указать момент времени с которого считывать данные при открытии соединения.
- Поддерживается абстракция "группы потребителей", которая позволяет группе клиентов вместе обрабатывать один поток данных вместе и независимо, то есть одно и то же сообщение не попадет дважды к клиентам из одной группы.
- ZooKeeper используется для периодического сохранения текущей позиции каждого клиента в потоке.
Новая архитектура Dashboard основана на принципе ячеек или ящиков входящих сообщений:
- Каждая "ячейка" отвечает за группу пользователей и читает новые события с шины сообщений, если один из её пользователей-подопечных подписан на автора только что опубликованного поста, то пост добавляется в "почтовый ящик" подписанного пользователя.
- Когда пользователь заходит в Dashboard его запрос попадает в его ячейку, которая возвращает ему нужную часть непрочитанных постов.
- Каждая ячейка состоит из трех групп серверов:
  - HBase для постоянного хранения копий постов и почтовых ящиков;
  - Redis для кэширование свежих данных;
  - Сервис, читающий данные из шины и предоставляющий доступ к ящикам посредством Thrift.
- В HBase используется две таблицы:
  - Отсортированный список идентификаторов постов для каждого пользователя в ячейке, именно в том виде, как они будут отображены в итоге.
  - Копии всех постов по идентификаторам, что позволяет выдать все данные для отрисовки Dashboard без обращений к серверам вне одной ячейки.
- Ячейки представляют собой независимые единицы, что позволяет легко масштабировать систему при росте числа пользователей.
- Платой за относительно безболезненность масштабирования является чрезвычайная избыточность данных: при том что ежедневно создается лишь 50Гб постов, суммарный объем данных в ячейках растет на 2.7Тб в день.
- Альтернативой было бы использование общего кластера со всеми постами, но тогда он бы стал единственной точкой отказа и потребовалось бы делать дополнительные удаленные запросы. Помимо этого выигрыш по объему был бы не велик - списки идентификаторов занимают значительно больше места, чем сами посты.
- Пользователи, которые подписаны или на которых подписаны миллионы других пользователей, обрабатываются отдельно - страницы с их постами генерируются не заранее (как описывалось выше), а при поступлении запроса - это позволяет не тратить впустую много ресурсов (этот подход называется выборочная материализация).
- Количество пользователей в одной ячейке позволяет управлять балансом между уровнем надежности и стоимостью содержания этой подсистемы.
- Параллельное чтение их шины сообщений оказывает серьезную нагрузку на сеть, в дальнейшем из ячеек можно будет составить иерархию: только часть будет читать напрямую из шины сообщений, а остальным сообщения будут ретранслироваться.
Tumblr географически по-прежнему находится в одном датацентре (если не считать незначительное присутствие в Rackspace), распределение по нескольким лишь в планах.

Развертывание

Начиналось как несколько rsync-скриптов для распространения PHP-приложения. Как только машин стало больше 200 такой подход стал занимать слишком много времени.
Следующий вариант был основан на Capistrano: были созданы три стадии процесса развертывания (разработка, тестирование, боевой). Неплохо справлялся с десятками серверов, но на сотнях также был слишком медленным, так как основывался на SSH.
Итоговый вариант основан на Func, решении от RedHat, позволившим заменить SSH на более легковесный протокол.

Разработка

Поначалу философия была такова, что каждый мог использовать любые технологии, которые считал уместным. Но довольно скоро пришлось стандартизировать стек технологий, чтобы было легче нанимать и вводить в работу новых сотрудников, а также для более оперативного решения технических проблем.
Каждый разработчик имеет одинаковую заранее настроенную рабочую станцию, которая обновляется посредством Puppet:
- Настроена публикация изменений, тестирование и развертывание новых версий.
- Разработчики используют vim и Textmate.
Новый PHP код систематически инспектируется другими разработчиками.
Внутренние сервисы подвергаются непрерывному тестированию посредством Jenkins.

Структура команд

Проект разбит на 6 команд:

Инфраструктура: все, что ниже 5 уровня по модели OSI - маршрутизация, TCP/IP, DNS, оборудование и.т.п.
Платформа: разработка основного приложения, партиционирование SQL, взаимодействие сервисов.
Надежность (SRE): сфокусирована на текущие потребности с точки зрения надежности и масштабируемости.
Сервисы: занимается более стратегической разработкой того, что понадобится через один-два месяца.
Эксплуатация: отвечает за обнаружение и реагирование на проблемы, плюс тонкая настройка.

Найм

На интервью они обычно избегают математики и головоломок, основной упор идет в основном именно на те вещи, которым придется заниматься кандидату.
Основной вопрос: будет ли он успешно решать поставленные задачи? Цель в том, чтобы найти отличных людей, а не в том, чтобы никого не брать.
Разработчиков обязательно просят привести пример своего кода, даже во время телефонных интервью.
Во время интервью кандидатов не ограничивают в наборе инструментов, можно даже гуглить.
Поиск людей с опытом в крупных проектах достаточно сложен, так как всего нескольких компаниях по всему миру решают подобные проблемы.

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

Автоматизация - ключ к успеху крупного проекта.
При партиционировании MySQL может масштабироваться, но лишь при преобладании операций чтения.
Redis с отключенной персистентностью легко может заменить memcached.
Scala достойно себя проявляет в роли языка программирования для внутренних сервисов, во многом благодаря обширной Java-экосистеме.
Внедряйте новые технологии постепенно, поначалу работать с HBase и Redis было очень болезненно, они были включены в основной стек технологий только после испытаний в некритичных сервисах и подпроектах, где цена ошибки не так велика.
Проект должен строиться вокруг навыков его команды, а не наоборот.
Нужно нанимать людей только если они вписываются в команду и в состоянии довести работу до результата.
При выборе технологического стека одну из ключевых ролей играет доступность соответствующих специалистов на кадровом рынке.
Читайте публикации и статьи в блогах. Ключевые аспекты архитектуры, включая "ячейки" и частичную материализацию были позаимствованы из внешних источников.
Поспрашивайте своих коллег, кто-то из них мог общаться с специалистами из Facebook, Twitter, Google или LinkedIn - если нет прямого доступа, всегда можно получить нужную информацию через одно-два "рукопожатия".

Статья написана на основе интервью Blake Matheny, директора по разработке платформы Tumblr.

Архитектура Twitter. Два года спустя.

Иван Блинков — Sat, 05 Mar 2011 20:47:00 +0300

В далеком 2008м я уже публиковал статью про архитектуру Twitter, но время летит стремительно и она уже абсолютно устарела. За это время аудитория Twitter росла просто фантастическими темпами и многое поменялось и с технической точки зрения. Интересно что новенького у одного из самых популярных социальных интернет-проектов?

Статистика

3 год, 2 месяца и 1 день потребовалось Twitter, чтобы набрать 1 миллиард твитов
На сегодняшний день, чтобы отправить миллиард твитов пользователям нужна всего одна неделя
752% рост аудитории за 2008 год
1358% рост аудитории за 2009 год (без учета API, по данным comScore)
175 миллионов зарегистрированных пользователей на сентябрь 2010 года
460 тысяч регистраций пользователей в день
9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
50 миллионов твитов в день год назад, 140 миллионов твитов в день месяц назад, 177 миллионов твитов в день на 11 марта 2011г.
Рекорд по количеству твитов за секунду 6939, установлен через минуту после того, как Новый Год 2011 наступил в Японии
600 миллионов поисков в день
Лишь 25% трафика приходится на веб сайт, остальное идет через API
Росто числа мобильных пользователей за последний год 182%
6 миллиардов запросов к API в день, около 70 тысяч в секунду
8, 29, 130, 350, 400 - это количество сотрудников Twitter на январь 2008, январь 2009, январь 2010, январь и март 2011, соответственно

Самая свежая статистика про Twitter.

Платформа

Сравните с аналогичным разделом предыдущей статьи о Twitter - увидите много новых лиц, подробнее ниже.

Оборудование

Сервера расположены в NTT America
Никаких облаков и виртуализации, существующие решения страдают слишком высокими задержками
Более тысячи серверов
Планируется переезд в собственный датацентр

Что такое твит?

Сообщение длиной до 140 символов + метаданные
Типичные запросы:
- по идентификатору
- по автору
- по @упоминаниям пользователей

Архитектура

Unicorn

Сервер приложений для Rails:

Развертывание новых версий кода без простоя
На 30% меньше расход вычислительных ресурсов и оперативной памяти, по сравнению с другими решениями
Перешли с mod_proxy_balancer на mod_proxy_pass

Rails

Используется в основном для генерации страниц, работа за сценой реализована на чистом Ruby или Scala.

Столкнулись со следующими проблемами:

Проблемы с кэшированием, особенно по части инвалидации
ActiveRecord генерирует не самые удачные SQL-запросы, что замедляло время отклика
Высокие задержки в очереди и при репликации

memcached

memcached не идеален. Twitter начал сталкиваться с Segmentation Fault в нем очень рано.
Большинство стратегий кэширования основываются на длинных TTL (более минуты).
Вытеснение данных делает его непригодным для важных конфигурационных данных (например флагов "темного режима", о котором пойдет речь ниже).
Разбивается на несколько пулов для улучшения производительности и снижения риска вытеснения.
Оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached + FNV hash, вместо чистого Ruby и md5.
Twitter является одним их наиболее активных проектов, участвующих в разработке libmemcached.

MySQL

Разбиение больших объемов данных является тяжелой задачей.
Задержки в репликации и вытеснение данных из кэша является причиной нарушения целостности данных с точки зрения конечного пользователя.
Блокировки создают борьбу за ресурсы для популярных данных.
Репликация однопоточна и происходит недостаточно быстро.
Данные социальных сетей плохо подходят для реляционных СУБД:
- NxN отношения, социальный граф и обход деревьев - не самые подходящие задачи для таких баз данных
- Проблемы с дисковой подсистемой (выбор файловой системы, noatime, алгоритм планирования)
- ACID практически не требуется
- Для очередей также практически непригодны
Twitter сталкивался с большими проблемами касательно таблиц пользователей и их статусов
Читать данные с мастера при Master/Slave репликации = медленная смерть

FlockDB

Масштабируемое хранилище для данных социального графа:

Разбиение данных через Gizzard
Множество серверов MySQL в качестве низлежащей системы хранения
В Twitter содержит 13 миллиардов ребер графа и обеспечивает 20 тысяч операций записи и 100 тысяч операций чтения в секунду
Грани хранятся и индексируются в обоих направлениях
Поддерживает распределенный подсчет количества строк
Open source!

Среднее время на выполнение операций:

Подсчет количества строк: 1мс
Временные запросы: 2мс
Запись: 1мс для журнала, 16мс для надежной записи
Обход дерева: 100 граней/мс

Подробнее про эволюцию систем хранения данных в Twitter в презентации Nick Kallen.

Cassandra

Распределенная система хранения данных, ориентированная на работу в реальном времени:

Изначально разработана в Facebook
Очень высокая производительность на запись
Из слабых сторон: высокая задержка при случайном доступе
Децентрализованная, способна переносить сбои оборудования
Гибкая схема данных
~~Планируется полный переход на нее по следующему алгоритму:~~
- ~~Все твиты пишутся и в Cassandra и в MySQL~~
- ~~Динамически часть операций чтения переводится на Cassandra~~
- ~~Анализируется реакция системы, что сломалось~~
- ~~Полностью отключаем чтение из Cassandra, чиним неисправности~~
- ~~Начинаем сначала~~
Обновление: стратегия по поводу использования Cassandra изменилась, попытки использовать её в роли основного хранилища для твитов прекратились, но она продолжает использоваться для аналитики и географической информации.

Подробнее почему Twitter пришел к решению использовать Cassandra можно прочитать в отдельной презентации.

Помимо всего прочего Cassandra ~~планируется использовать~~ используется для аналитики в реальном времени.

Scribe

Пользователи Twitter генерируют огромное количество данных, около 15-25 Гб в минуту, более 12 Тб в день, и эта цифра удваивается несколько раз в год.

Изначально для сбора логов использовали syslog-ng, но он очень быстро перестал справляться с нагрузкой.

Решение нашлось очень просто: Facebook столкнулся с аналогичной проблемой и разработал проект Scribe, который был опубликован в opensource.

По сути это фреймворк для сбора и агрегации логов, основанный на Thrift. Вы пишете текст для логов и указываете категорию, остальное он берет на себя.

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

Поддерживаются различные системы для записи в данным, в том числе обычные файлы и HDFS (о ней ниже).

Этот продукт полностью решил проблему Twitter со сбором логов, используется около 30 различных категорий. В процессе использования была создана и опубликована масса доработок. Активно сотрудничают с командой Facebook в развитии проекта.

Hadoop

Как Вы обычно сохраняете 12Тб новых данных, поступающих каждый день?

Если считать, что средняя скорость записи современного жесткого диска составляет 80Мбайт в секунду, запись 12Тб данных заняла бы почти 48 часов.

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

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

Hadoop Distributed File System (HDFS) предоставляет возможность автоматической репликации и помогает справляться со сбоями оборудования.

MapReduce framework позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение.

Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter:

Вычисление связей дружбы в социальном графе (grep и awk не справились бы, self join в MySQL на таблицах с миллиардами строк - тоже)
Подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 миллиардах записей)
Подсчет PageRank между пользователями для вычисления репутации.

В твиттер используется бесплатный дистрибутив от Cloudera, версия Hadoop 0.20.1, данные храняться в сжатом по алгоритму LZO виде, библиотеки для работы с данными опубликованы под названием elephant-bird.

Pig

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

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

Немного напоминает SQL, но намного проще. Это позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce работ. Большая часть работы по анализу данных в Twitter осуществляется с помощью Pig.

Данные

Полу-структурированные данные:

логи Apache, RoR, MySQL, A/B тестирования, процесса регистрации
поисковые запросы

Структурированные данные:

Твиты
Пользователи
Блок-листы
Номера телефонов
Любимые твиты
Сохраненные поиски
Ретвиты
Авторизации
Подписки
Сторонние клиенты
География

Запутанные данные:

Социальный граф

Что же они делают с этим всем?

Подсчет математического ожидания, минимума, максимума и дисперсии следующих показателей:
- Количество запросов за сутки
- Средняя задержка, 95% задержка
- Распределение кодов HTTP-ответов (по часам)
- Количество поисков осуществляется каждый день
- Количество уникальных запросов и пользователей
- Географическое распределение запросов и пользователей
Подсчет вероятности, ковариации, влияния:
- Как отличается использование через мобильные устройства?
- Как влияет использование клиентов сторонних разработчиков?
- Когортный анализ
- Проблемы с сайтом (киты и роботы, подробнее ниже)
- Какие функциональные возможности цепляют пользователей?
- Какие функциональные возможности чаще используются популярными пользователями?
- Корректировка и предложение поисковых запросов
- A/B тестирование
Предсказания, анализ графов, естественные языки:
- Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
- Какая структура графа ведет к успешным популярным сетям
- Пользовательская репутация
- Анализ эмоциональной окраски
- Какие особенности заставляют людей ретвитнуть твит?
- Что влияет на глубину дерева ретвитов ?
- Долгосрочное обнаружение дубликатов
- Машинное обучение
- Обнаружения языка

Подробнее про обработку данных в презентации Kevin Weil.

HBase

Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:

HBase используется как изменяемая прослойка над HDFS
Данные экспортируются из HBase c помощью периодической MapReduce работы:
- На этапе Map используются также данные из FlockDB и нескольких внутренних сервисов
- Собственная схема разбиения данных
- Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala (подробнее о построении распределенных сервисов на Scala)

На основе HBase разрабатываются и другие продукты внутри Twitter.

Основными её достоинствами являются гибкость и легкая интеграция с Hadoop и Pig.

По сравнению с Cassandra:

"Их происхождение объясняет их сильные и слабые стороны"
HBase построен на основе системы по пакетной обработке данных, высокие задержки, работает далеко не в реальном времени
Cassandra построена с нуля для работы с низкими задержками
HBase легко использовать при анализе данных как источник или место сохранения результатов, Cassandra для этого подходит меньше, но они работают над этим
HBase на данный момент единственную точку отказа в виде мастер-узла
В твиттере HBase используется для аналитики, анализа и создания наборов данных, а Cassandra - для онлайн систем

Loony

Централизованная система управления оборудованием.

Реализована с использованием:

Python
Django
MySQL
Paraminko (реализация протокола SSH на Python, разработана и опубликована в opensource в Twitter)

Интегрирована с LDAP, анализирует входящую почту от датацентра и автоматически вносит изменения в базу.

Murder

Система развертывания кода и ПО, основанная на протоколе BitTorrent.

Благодаря своей P2P природе позволяет обновить более тысячи серверов за 30-60 секунд.

Kestrel

Распределенная очередь, работающая по протоколу memcache:

set - поставить в очередь
get - взять из очереди

Особенности:

Отсутствие строгого порядка выполнения заданий
Отсутствие общего состояния между серверами
Разработана на Scala

Daemon'ы

Каждый твит обрабатывается с помощью daemon'ов.

В unicorn обрабатываются только HTTP запросы, вся работа за сценой реализована в виде отдельных daemon'ов.

Раньше использовалось много разных демонов, по одному на каждую задачу (Rails), но перешли к меньшему их количеству, способному решать несколько задач одновременно.

Как они справляются с такими темпами роста?

Рецепт прост, но эффективен, подходит практически для любого интернет-проекта:

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

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

Автоматический сбор метрик (причем в агрегированном виде)
Построение графиков (RRD, Ganglia)
Сбор и анализ логов
Все данные должны получаться с минимальной задержкой, как можно более близко к реальному времени
Анализ:
- Из данных необходимо получать информацию
- Следить за динамикой показателей: стало лучше или хуже?
- Особенно при развертывании новых версий кода
- Планирование использования ресурсов намного проще, чем решение экстренных ситуаций, когда они на исходу

Примерами агрегированных метрик в Twitter являются "киты" и "роботы", вернее их количество в единицу времени.

Что такое "робот"?

Ошибка внутри Rails (HTTP 500)
Непойманное исключение
Проблема в коде или нулевой результат

Что такое "кит"?

HTTP ошибка 502 или 503
В твиттер используется фиксированный таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах)
Убитый слишком длинный запрос к базе данных (mkill)

Значительное превышение нормального количества китов или роботов в минуту является поводом для беспокойством.

Реализован этот механизм простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения. Подробнее про работу команды оперативного реагирования в презентации John Adams.

"Темный режим"

Для экстренных ситуаций в Twitter предусмотрен так называемый "темный режим", который представляет собой набор механизмов для отключения тяжелых по вычислительным ресурсам или вводу-выводу функциональных частей сайта. Что-то вроде стоп-крана для сайта.

Имеется около 60 выключателей, в том числе и полный режим "только для чтения".

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

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

Не бросайте систему на самотек, начинайте собирать метрики и их визуализировать как можно раньше
Заранее планируйте рост требуемых ресурсов и свои действия в случае экстренных ситуаций
Кэшируйте по максимуму все, что возможно
Все инженерные решения не вечны, ни одно из решений не идеально, но многие будут нормально работать в течение какого-то периода времени
Заранее начинайте задумываться о плане масштабирования
Не полагайтесь полностью на memcached и базу данных - они могут Вас подвести в самый неподходящий момент
Все данные для запросов в реальном времени должны находиться в памяти, диски в основном для записи
Убивайте медленные запросы (mkill) прежде, чем они убьют всю систему
Некоторые задачи могут решаться путем предварительного подсчета и анализа, но далеко не все
Приближайте вычисления к данным по возможности
Используйте не mongrel, а unicorn для RoR

Спасибо за внимание, жду Вас снова! Буду рад, если Вы подпишитесь на меня в Twitter, с удовольствием пообщаюсь со всеми читателями :)

Архитектура DISQUS

Иван Блинков — Wed, 02 Mar 2011 03:37:00 +0300

DISQUS - самая популярная система комментирования и одновременно самое большое в мире Django-приложение. Она установлена более чем на полумиллионе сайтов и блогов, в том числе и очень крупных, таких как Engadget, CNN, MTV, IGN. Основной особенностью в её реализации является тот факт, что DISQUS не является тем сайтом, который хотят увидеть пользователи, он лишь предоставляет механизмы комментирования, авторизации и интеграции с социальными сетями. Пики нагрузки возникают одновременно c появлением какой-то шумихи в Интернете, что достаточно непредсказуемо. Как же им удается справляться с этой ситуацией?

Платформа

Linux - операционная система
Python - язык программирования
Django - основной framework
Apache 2.2 + mod_wsgi - веб-сервер
PostgreSQL - СУБД
memcached - кэширование
HAProxy - балансировка нагрузки
Slony - репликация данных
heartbeat - обеспечение доступности

Статистика

До 17 тысяч запросов в секунду
500 000 сайтов
15 миллионов зарегистрированных пользователей
75 миллионов комментариев
250 миллионов посетителей (на август 2010г.)

Основные трудности

Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)
Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)
Нельзя угадать на каком сайте из тысяч возникнет пик трафика
Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования
Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)

Архитектура

Оборудование, в сумме около 100 серверов:
- 30% веб-серверов (Apache + mod_wsgi)
- 10% серверов баз данных (PostgreSQL)
- 25% кэш-серверов (memcached)
- 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
- 15% прочие сервера (Python скрипты)
Балансировка нагрузки:
- HAProxy:
  - Высокая производительность
  - Интеллектуальная проверка доступности
  - Неплохая статистика
Репликация:
- Используется Slony-I
- Основана на триггерах
- Master/Slave для обеспечения большего объема операций чтения
Высокая доступность:
- heartbeat
- Пассивная копия мастер баз данных на случай сбоя основной
Партиционирование:
- Реализовано на уровне кода
- Простая реализация, быстрые положительные результаты
- Два метода разделения данных:
  - Вертикальное:
    - Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
    - Позволяет разделять базы данных
    - Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
    - Бартер производительности на масштабируемость
    - Более эффективное кэшировние
    - Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
  - Горизонтальное:
    - Некоторые сайты имеют очень большие массивы данных
    - Партнеры требуют повышенного уровня доступности
    - Помогает снижать загрузку по записи на мастер базе данных
    - В основном используется все же вертикальное партиционирование
Производительность базы данных:
- Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
- Логирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
- Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
- Оптимизация QuerySet'ов:
  - Не используется чистый SQL
  - Встроенный кэш позволяет выделять части выборки
  - Но это не всегда нужно, они убрали этот кэш
- Атомарные операции:
  - Поддерживают консистентность данных
  - Использование update(), так как save() не является thread-safe
  - Отлично работают для таких вещей, как счетчики
- Транзакции:
  - TransactionMiddleware поначалу использовалось, но со временем стало обузой
  - В postgrrsql_psycopg2 есть опция autocommit:
    - Это означает что каждый запрос выполняется в отдельной транзакции
    - Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
    - Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в случае ошибки)
    - В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости переключаются в транзакционный режим
Отложенные сигналы:
- Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
- Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
- Модели отправляются в очередь в сериализованном виде
Кэширование:
- Используется memcached
- Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
- Настраиваемые алгоритмы поведения клиента
- Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
- Алгоритм размещения ключей: консистентное хэширование на основе libketama
- Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
  - Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
  - В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
  - django-newcache и MintCache умеют это делать
  - Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
Мониторинг:
- Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
- Сбор и отображение с помощью Ganglia
Отключение функционала:
- Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
- Система должна срабатывать мгновенно, по всем серверам, без записи на диск
- Позволяет запускать новые возможности постепенно, лишь для части аудитории
- Позволяет постоянно использовать основную ветку кода
- Аналогичная система используется и в Facebook
Масштабирование команды разработчиков:
- Небольшая команда
- Месячная аудитория / количество разработчиков = 40 миллионов
- Это означает:
  - Автоматическое тестирование
  - И максимально простой процесс разработки
- Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
  - Установить и настроить PostgreSQL
  - Скачать исходный код из git
  - С помощью pip и virtualenv установить зависимости
  - Изменить настройки в settings.py
  - Выполнить автоматическое создание структуры данных средствами Django
Непрерывное тестирование:
- Ежедневное развертывание с помощью Fabric
- Hudson обеспечивает регулярно осуществляет и тестирует сборки
- Интегрирован Selenium
- Быстрое тестирование с помощью Pyflakes и post-commit hooks
- 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
- Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
Отслеживание проблем и задач:
- Переключились с Trac на Redmine (из-за поддержки под-задач)
- Отправка исключений на e-mail - плохая идея
- Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

Язык программирования, каким бы он ни был, не является проблемой
Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

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

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

Другие статьи по масштабируемости высоконагруженных систем можно почитать в соответствующем разделе, а вовремя узнавать о новых - подписавшись на RSS. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать :)

Новое поколение MapReduce в Apache Hadoop

Иван Блинков — Sat, 19 Feb 2011 21:23:00 +0300

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce, в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предистория

Текущая реализация Hadoop MapReduce устаревает на глазах. Основываясь на текущих тенденциях в размерах кластеров и нагрузок на них, JobTracker требует кардинальных доработок, чтобы исправить его дефекты в области масштабируемости, потребления памяти, многопоточности, надежности и производительности. С точки зрения работы с Hadoop при каждом обновлении кластера (даже если это просто багфикс), абсолютно все компоненты кластера, так и приложений, которые на нем работают, должны быть обновлены одновременно. Это так же очень неудобно, так как каждый раз необходимо тестировать все приложения на совместимость с новой версией.

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

Надежность
Доступность
Масштабируемость - кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
Обратная и прямая совместимость - возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
Контроль над обновлениями
Предсказуемые задержки
Эффективное использование ресурсов

Среди менее значительных требований:

Поддержка альтернативных парадигм разработки (помимо MapReduce)
Поддержка сервисов с коротким жизненным циклом

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

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker'а на два отдельных части:

управление ресурсами;
планирования и мониторинга задач.

В итоге появляется несколько новых ролей:

ResourceManager управляет глобальным распределением вычислительных ресурсов между приложениями;
ApplicationMaster управляет планированием и координацией внутри приложения;
NodeManager управляет процессами в рамках одной машины.

ApplicationMaster представляет собой библиотеку, с помощью которой можно получить у ResourceManager квоту на вычислительные ресурсы и работать с NodeManager(ами) для выполнения и мониторинга задач.

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

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

По одному ApplicationMaster запускается для каждого приложения, они ответственны за запрос необходимых ресурсов у планировщика, запуск задач, отслеживание статусов, мониторинг прогресса и обработку сбоев.

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

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

Масштабируемость особенно важна в свете текущих трендов в оборудовании - на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

ResourceManager использует Apache ZooKeeper для обработки сбоев. Когда ResourceManager перестает работать, аналогичный процесс может быстро запуститься на другой машине благодаря тому, что состояние кластера было сохранено в ZooKeeper. При таком сценарии все запланированные и выполняющиеся приложения максимум лишь перезапустятся.
ApplicationMaster - поддерживается создание точек восстановления на уровне приложений. ApplicationMaster может восстановить работу из состояния, сохраненного в HDFS, в случае сбоя.

Совместимость протокола

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

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

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

Эффективность использования вычислительных ресурсов

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

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

Apache Hadoop, и в частности Hadoop MapReduce - очень успешный opensource проект по обработке больших объемов данных. Предложенный Yahoo путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

Осталось дело за малым - собственно реализовать задуманное! :)

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

Подписаться на RSS можно здесь.

Архитектура Вконтакте

Иван Блинков — Thu, 28 Oct 2010 21:12:00 +0400

Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте, в том числе и техническим. Спешу поделиться своим взглядом на архитектуру проекта по результатам данного выступления.

Платформа

Debian Linux - основная операционная система
nginx - балансировка нагрузки
PHP + XCache
Apache + mod_php
memcached
MySQL
Собственная СУБД на C, созданная "лучшими умами" России
node.js - прослойка для реализации XMPP, живет за HAProxy
Изображения отдаются просто с файловой системы xfs
ffmpeg - конвертирование видео

Статистика

95 миллионов учетных записей
40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
11 миллиардов запросов в день
200 миллионов личных сообщений в день
Видеопоток достигает 160Гбит/с
Более 10 тысяч серверов, из которых только 32 - фронтенды на nginx (количество серверов с Apache неизвестно)
30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
Каждый день выходит из строя около 10 жестких дисков

Архитектура

Общие принципы

Cервера многофункциональны и используются одновременно в нескольких ролях:
- Перебрасывание полуавтоматическое
- Требуется перезапускать daemon'ы
Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие - использование собственной СУБД вместо MySQL
При балансировке нагрузки используются:
- Взвешенный round robin внутри системы
- Разные сервера для разных типов запросов
- Балансировка на уровне ДНС на 32 IP-адреса
Большая часть внутреннего софта написано самостоятельно, в том числе:
- Собственная СУБД (см. ниже)
- Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс :) )
- Автоматическая система тестирования кода
- Анализаторы статистики и логов
Мощные сервера:
- 8-ядерные процессоры Intel (по два на сервер, видимо)
- 64Гб оперативной памяти
- 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
- RAID не используется
- Не брендированные
Вычислительные мощности серверов используются менее, чем на 20%
Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
- Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
- В Московских датацентрах только аудио и видео
- В планах сделать репликацию базы данных в другой датацентр в ленинградской области
CDN на данный момент не используется, но в планах есть
Резервное копирование данных происходит ежедневно и инкрементально

Волшебная база данных на C

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

Разработана "лучшими умами" России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих "героев" Вконтакте (писал на слух и возможно не всех успел, так что извиняйте):
- Андрей Лопатин
- Николай Дуров
- Арсений Смирнов
- Алексей Левин
Используется в огромном количестве сервисов:
- Личные сообщения
- Сообщения на стенах
- Статусы
- Поиск
- Приватность
- Списки друзей
Нереляционная модель данных
Большинство операций осуществляется в оперативной памяти
Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
Кластеризация осуществляется легко
Есть репликация
Если честно, я так и не понял зачем им MySQL с такой штукой - возможно просто как legacy живет со старых времен

Аудио и видео

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

1000-1500 серверов используется для перекодирования видео, на них же оно и хранится.

XMPP

Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.

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

Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
Работа с большими контакт-листами - у многих пользователей количество друзей на Вконтакте измеряется сотнями и тысячами
Высокая активность смены статусов - люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
Аватарки передаются в base64
Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
60-80 тысяч человек онлайн, в пике - 150 тысяч
HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
Данные хранятся в MySQL (думали о MongoDB, но передумали)
Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код наnode.js (по 4 процесса на сервер), а на трех самых мощных - еще и MySQL
В node.js большие проблемы с использованием OpenSSL, а также течет память
Группы друзей в XMPP не связаны с группами друзей на сайте - сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся

Интеграция со внешними ресурсами

Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:

Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
Кнопка "поделиться с друзьями", поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

Интересные факты не по теме

Процесс разработки близок к Agile, с недельными итерациями
Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian
Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
Есть много доработок над memcached, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия
Фотографии не удаляются для минимизации фрагментации
Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на них и на реализовавшем его разработчике
Павел Дуров откладывал деньги на хостинг с 1 курса :)

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

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, например, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

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

Если хотите быть в курсе новых веяний в сфере масштабируемости высоконагруженных интернет-проектов - по традиции рекомендую подписаться на RSS.

Hadoop возвращается

Иван Блинков — Sun, 17 Aug 2008 23:15:00 +0400

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

Что нового?

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

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

Повторно повторяться смысла не вижу, все уже давно разложено по полочкам. Так что сразу перейдем к глобальным изменениям в проекте, произошедшим с написания вышеупомянутого поста, то есть с февраля. Сразу хочу сказать, что подробно пересказывать release notes у меня нет никакого желания, если Вам интересны все подробности о каждом bugfix'е или изменении в API, то имеет смысл почитать их в оригинале.

Наиболее значительным событием в развитии Apache Hadoop было, пожалуй, отделение HBase в отдельный проект. Какие же это повлекло последствия? С точки зрения простого смертного наиболее заметен тот факт, что HBase пропал из основного архива или репозитория Hadoop и его теперь нужно качать отдельно :) На самом же деле такое обособление лишь ускорило ее развитие, совсем недавно HBase отпраздновала свой релиз версии 0.2.0, включающий в себя массу нововведений и исправленных проблем, например язык запросов HQL был полностью заменен на jirb/jython shell, а также было добавлено кэширование данных в памяти. Помимо этого сильно изменилось API, очень рекомендую заглянуть в javadoc проекта, если Вас это интересует.

На уровне файловой системы наиболее значительным изменением стало добавление еще одного типа узлов - Secondary NameNode. Это нововведение является первым шагом на пути к устранению узких мест в системе (так называемых single points of failure). Название этого типа узлов говорит само за себя: они подстраховывают основной NameNode на случай непредвиденных сбоев. Они создают резервную копию образа метаданных файловой системы и лога транзакций (то есть всех операций с файлами и директориями в HDFS) и периодически ее обновляют. Полноценного автоматического восстановления системы они в случае сбоя на сервере с NameNode они на данный момент не обеспечивают, но сохранность данных на случай, скажем, разрушившегося RAID обеспечить могут.

MapReduce framework тоже несомненно развивается и дорабатывается, но каких-либо особо выдающихся изменений в нем не произошло: появляются дополнительные возможности, исправляются ошибки, снимаются те или иные ограничения. В общем все идет своим чередом.

Поднимаем кластер

ВНИМАНИЕ!

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

Для начала нам понадобится некоторое количество компьютеров (хотя если у Вас серьезные намерения, то лучше все же гордо называть их серверами, а для "побаловаться" сойдут и обычные рабочие станции с Linux). Конкретное количество на самом деле роли не играет, продолжать можно как с 2 серверами, так и с 20 тысячами (по крайней мере теоретически). Хотя пару рекомендаций все же могу дать: при использовании в "боевых" условиях стоит стараться избегать физического совмещения мастер-узлов компонентов системы (NameNode, JobTracker, HMaster) с "рядовыми" серверами, таким образом желательно начинать с, как минимум, 5-7 серверов.

Удостоверившись, что на всем оборудовании установлен какой-нибудь дистрибутив Linux или Unix (любители особо поизвращаться могут попытать счастья с "окнами" в совокупности с Cygwin) и 5 или 6 версия JRE/JDK (желательно от Sun), можно приступать к настройке каждого узла по тому же принципу, что и для псевдо-кластера (да-да, предупреждение в начале раздела было написано не для мебели). Кстати не забудьте, что HBasе теперь нужно скачивать отдельно. О небольших присутствующих особенностях я расскажу чуть позже, а пока дам маленький совет, который позволит несколько облегчить это непростое дело.

Вручную выполнять одни и те же операции на паре десятков/сотен/тысяч серверов мало того что долго, но и чрезвычайно утомительно. Уже на втором-третьем сервере начнет появляться желание каким-либо образом автоматизировать процесс установки. Конечно же можно воспользоваться специализированным программным обеспечением, скажем gexec, но есть и более простой способ: существенно упростить жизнь может простой скрипт на bash в 5 строчек:

#!/bin/bash
for x in `cat ~/nodes`
do
ssh hadoop@$x $1
done

В файле ~/nodes должен располагаться список IP-адресов всех серверов, тогда получив первым параметром произвольную консольную команду скрипт выполнит ее на каждом сервере. С его помощью можно существенно сократить время, требуемое на выполнение всех необходимых действий для запуска кластера.

После небольшого лирического отступления вернемся собственно к Hadoop. Как Вы уже, надеюсь, знаете, система использует ssh для управления всеми компонентами системы, причем очень желателен беспарольный доступ между всеми узлами. Для этого необходимо собрать в один файл все публичные ключи ~/.ssh/id_rsa.pub на каждом из узлов (по одному на строчку) и разместить его под именем ~/.ssh/authorized_keys тоже на каждом из узлов. Кстати для упоминавшегося выше скрипта беспарольный доступ тоже очень желателен.

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

hadoop-site.xml

<property>
  <name>fs.default.name</name>
  <value>hdfs://namenode:54310</value>
  <description>
    The name of the default file system.  A URI whose
    scheme and authority determine the FileSystem implementation.  The
    uri's scheme determines the config property (fs.SCHEME.impl) naming
    the FileSystem implementation class.  The uri's authority is used to
    determine the host, port, etc. for a filesystem.
  </description>
</property>
<property>
  <name>mapred.job.tracker</name>
  <value>jobtracker:54311</value>
  <description>
    The host and port that the MapReduce job tracker runs
    at.  If "local", then jobs are run in-process as a single map
    and reduce task.
  </description>
</property>

Каждый сервер должен знать где расположен NameNode, по-этому он явно указывается в полном пути к файловой системе, практически аналогичная ситуация и с JobTracker. Вместо namenode и jobtracker необходимо указать их IP-адреса или доменные имена (или в крайнем случае - имя в /etc/hosts)

masters

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

slaves

Список всех рядовых серверов, по одному на строку (опять же: IP или доменное имя). На них будут запущенны DataNode и TaskTracker.

hbase-site.xml

<property>
  <name>hbase.master</name>
  <value>localhost:60000</value>
  <description>
    the host and port that the HBase master runs at
  </description>
</property>

Первое изменение достаточно очевидно: HRegionServer должны знать где находится HMaster, о чем им и сообщает первое свойство (заменяем hmaster на соответствующий адрес). А вот второе свойство является следствием "обособления" HBase от Hadoop, о котором шла речь ранее. Теперь имеется возможность использовать их отдельно (с локальной файловой системой вместо HDFS), а так как появился выбор файловой системы - ее адрес необходимо указывать полностью. В данном случае указан адрес HDFS (такой же как в hadoop-site.xml).

regionservers

Вполне очевидный конфигурационный файл, по аналогии со slaves, заполняется списком адресов для запуска HRegionServer. Часто совпадает с упомянутым slaves, обычно достаточно просто скопировать.

Запуск

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

#!/bin/bash
ssh hadoop@namenode ~/hadoop/bin/start-dfs.sh
ssh hadoop@jobtracker ~/hadoop/bin/start-mapred.sh
ssh hadoop@hmaster ~/hbase/bin/start-hbase.sh

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

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

$ ~/hadoop/bin/hadoop jar hadoop-*-examples.jar pi 4 10000

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

Заключение

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

Если Вы еще не успели подписаться на RSS - сейчас самое время!

Архитектура LiveJournal

Иван Блинков — Thu, 10 Apr 2008 00:24:00 +0400

LiveJournal был одним из первых сервисов, бесплатно предоставляющих всем желающим личный блог. Практически с самого начала своего существования в далеком 1999 году проект столкнулся с непрерывно растущим потоком желающих воспользоваться услугами сервиса. Как же проекту удалось справиться с предоставлением маленького кусочка интернета каждому желающему, обойдя при этом всех конкурентов?

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

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

Linux (Debian Sarge)
Perl
Apache
MySQL 4.0/4.1 в основном с InnoDB
Perlbal, веб-сервер и балансировщик нагрузки
memcached для распределенного кэширования
MogileFS, распределенная файловая система
Gearman
TheShwartz
djabberd

Статистика

на данный момент 15320315 учетных записей; (10.04.08)
из них активно используется 551589;
наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей - девушки и женщины;
более 15 миллионов новых записей в блогах за месяц;
более 50 миллионов просмотров страниц в день, при пиковой нагрузке - несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

Все началось с одного обычного сервера. Он выполнял роль как веб-сервера так и базы данных. Единственный плюс такого подхода к организации работы оборудования - достаточно дешево. Само собой достаточно скоро этот сервер перестал справляться с нагрузкой.
Следующим шагом было разнесение веб-сервера и базы данных на разные серверы, всего их получилось два. По прежнему имелось два узла, сбой в которых означал недоступность сервиса. По прежнему вычислительная мощность такой системы оставалась более чем скромной.
Первым из тех двух серверов, как ни странно, перестал справляться с нагрузкой веб-сервер - докупили еще два. Веб-сервера три, внешний IP - один, теперь приходится как-то распределять нагрузку! А как добавить еще одну базу данных?
Новый сервер баз данных был подключен в роли slave к исходному, данные в нем обновлялись с помощью репликации, а обрабатывал он только операции чтения, оставив все операции записи первому серверу.
Есть предположения о том, к чему привело дальнейшее добавление новых серверов? Правильно - к полнейшему хаосу! Со временем стала возникать проблема масштабируемости баз данных. Операции чтения производились на каком-то одном сервере, но когда приходил запрос на запись данных, так или иначе данные приходилось производить обновление на каждом из slave серверов. В итоге выполнение синхронизации данных стало занимать подавляющее большинство процессорного времени slave серверов, что привело к отсутствию возможности продолжать масштабирование просто добавлением дополнительных серверов.
Пришло время задуматься над архитектурой системы и распределением операций записи. Основной целью стало избавиться от такой серьезной избыточности данных, так как это было практически пустой тратой времени копировать одни и те же данные на десяток машин, да еще и с RAID на каждой из них.

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

Применительно к LiveJournal эту схему лучше всего демонстрирует один из слайдов презентации, указанной в источниках информации:

При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

Программное обеспечение

В ситуации, когда не удавалось найти готового программного решения для какой-то конкретной задачи, они не боялись взяться за написание его самостоятельно, это стало одним из основных компонентов успеха проекта. Существенная часть программной платформы LiveJournal написана специально для этого проекта и выпущено под свободной лицензией с открытым исходным кодом, доступным в официальном SVN репозитории.

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
достигать превосходной производительности при формировании HTML-кода страниц;
в разы снизить нагрузку на базы данных в проекте любого масштаба.

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

Perlbal

При решении вопроса, связанного с балансировкой нагрузки между веб-серверами, пришлось перепробовать далеко не один десяток готовых решений, но, к сожалению, ни один из них не смог удовлетворить все потребности проекта. Не растерявшись, разработчики написали свое решение этой задачи и назвали его Perlbal. Конкурентов у него множество, начиная от решений на уровне оборудования, например от Foundry, заканчивая proxy балансировщиками нагрузки встроенные в более популярные веб-сервера, но, тем не менее, продукт получился достаточно конкурентноспособным. Он удовлетворял всем требованиям, выдвигаемым разработчиками проекта:

быстрый;
небольшой размер;
"сообразительный";
обработка "мертвых" узлов;
может выступать как в роли reverse proxy, так и балансировщика нагрузки;
базовый функционал классического веб-сервера;
реализация внутреннего перенаправления данных;
поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in'ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

Идея распределенных файловых систем далеко не нова, достаточно вспомнить лишь GFS или любой ее opensource аналог. Сам факт создания такой системы был очень легок, изначальная версия была написана за одни выходные, но при доведении ее до требуемого уровня качества пришлось попотеть. Решение о ее создании было развитием идеи распределения операций записи. Общая принцип хранения файлов прост: каждый файл в ФС относится к определенному классу файлов, который определяет все правила работы с файлом, в основном механизм его реплицирования, об остальном заботится сама система.

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных - в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal - сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

Gearman по сути прост до безобразия, но это не мешает ему быть чрезвычайно эффективным. Возможно Вы уже догадались в чем суть этого еще одного продукта, написанного специально для LJ, если уже навели курсор на акроним в начале этого абзаца, если же нет - поясню: он управляет общей работой системы средствами клиент-серверной архитектуры и высокопроизводительного бинарного протокола. С их помощью он способен удаленно вызывать практически любые процедуры на удаленных серверах с минимальными задержками во времени. Казалось бы ничего особенного он сам по себе не делает, но на самом деле он выполняет очень важную функцию: увеличивает степень параллельности выполнения операций, необходимых для полноценного функционирования проекта. Единственное но в работе этого механизма заключается в том, что он не предоставляет никаких гарантий успешности выполнения работ.

В рамках LiveJournal Gearman применяется в основном для:

обработка изображений средствами Image::Magick вне perl-приложений;
создание pool'а DBI соединений (DBD::Gofer + Gearman);
уменьшением нагрузки, создаваемой отдельными компонентами системы;
улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

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

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

Основными сферами применения TheShwartz в LJ являются:

отправка электронной почты (SMTP клиент);
LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
отправка RPC сообщений внешним сервисам;
внедрение Atom потоков;

djabberd

Как всегда следуя принципу "чем проще - тем лучше", разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

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

Если перед Вами появилась нетривиальная задача - не бойтесь написать программное обеспечение для ее решения самостоятельно! Пускай, возможно, это потребует некторых дополнительных усилий, но масса преимуществ, связанных с полным соответствием требованиям конкретного проекта, превосходит все издержки дополнительной разработки.
Невозможно масштабировать проект просто постоянно добавляя новые сервера, рано или поздно все же прийдется задуматься об его архитектуре;
Распределение нагрузок и параллельное операций порой заслуживают того, чтобы разработчики обратили на них внимание;
"Мы ненавидим изобретать колесо! Но тем не менее, если колесо не существует или оно квадратное, то мы не боимся изобретать круглое колесо." (с)

Архитектура Wikimedia

Иван Блинков — Fri, 28 Mar 2008 15:32:00 +0300

Wikimedia является платформой для Wikipedia, Wiktionary и еще семи менее крупных wiki-проектов. Этот документ очень пригодится новичкам, пытающимся довести свои проекты до масштабов гигантских вебсайтов. Здесь можно найти множество интересных деталей и инновационных идей, которые уже успели доказать свою работоспособность на самых посещаемых сайтах всего Интернета.

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

Перевод статьи. Автор - Todd Hoff.

Архитектура Wikimedia
Серверы Wikimedia
scale-out vs scale-up из блога "Oracle to MySQL"

Платформа

Apache
Linux
MySQL
PHP
Squid
LVS
Lucene для поиска
Memcached для распределенного кэширования объектов
lighttpd для работы с изображениями

Статитстика

8 миллионов статей распределены по сотням языковых подпроектов (английские, голландские, ...)
В десятке самых высоконагруженных проектов по данным Alexa
Экспоненциальный рост: в терминах посетителей, трафика и серверов удвоение происходит каждые 4-6 месяцев
30000 HTTP запросов в секунду в периоды пиковой нагрузки
3 GBps трафик данных
3 датацентра: Тампа, Амстердам, Сеул
350 серверов, конфигурации варьируются от однопроцессорных Pentium 4 с 512 MB оперативной памяти до двухпроцессорных Xeon Quad-Core с 16 GB RAM.
Управляется ~6 людьми
Три кластера на трех разных континентах

Архитектура

Географическая балансировка нагрузки, основываясь на IP клиента, перенаправляет их на ближайший кластер. Происходит статическое отображение множества IP адресов на множество стран, а затем и на множество кластеров.
Кэширование с помощью Squid группируется по типу контента: текст для wiki отдельно от изображений и больших статических файлов.
На данный момент функционирует 55 Squid серверов, плюс еще 20 подготавливается к запуску.
1000 HTTP запросов в секунду на каждый сервер, в периоды повышенной нагрузки эта цифра может достигать 2500.
~ 100-250 MBps на сервер.
~ 14000-32000 открытых соединений на каждом сервере.
До 40 GB дискового кэша на каждом Squid сервере.
До 4 дисков в каждом сервере (1U серверы).
8 GB оперативной памяти, половину использует Squid.
PowerDNS предоставляет геораспределение.
В основном и региональных датацентрах текстовые и медиа кластеры построены на LVS, CARP Squid, кэш Squid. В основном датацентре также находится хранилище медиа-данных.
Для того, чтобы обеспечить предоставление только последних версий страниц, всем Squid-серверам отправляются инвалидационные запросы.
Централизованно управляемая и синхронизированная установка программного обеспечения для сотен серверов.
MediaWiki отлично масштабируется с несколькими процессорами, так что закупаются двухпроцессорный четырех ядерные серверы (8 ядер на сервер).
Одно и то же оборудование выполняет как задачи внешнего хранения данных, так и кэширования Memcached.
Memcached используется для кэширования метаданных изображений, данных парсера, различий между ревизиями, пользователей, сессий. Метаданные, такие как история ревизий, отношений статей (ссылки, категории и так далее), учетные записи пользователей хранятся в основных базах данных
Сам текст находится во внешних хранилищах данных.
Статические (загруженные пользователями) файлы, например изображения, хранятся отдельно на сервере изображений, а метаданные (размер, тип и так далее) кэшируются в основной базе данных и объектном кэше.
Отдельная база данных для каждой вики (не отдельный сервер!).
Один master и много реплицированных slave серверов.
Операции чтения равномерно распределяются по slave серверам, операции записи направляются на master.
Иногда master используется и для операция чтения, когда репликация на slave еще не завершена.
Внешнее хранение данных:
- Текст статей хранится на отдельных кластерах, которые представляют собой простой средство хранения данных с возможностью только дописывания новых данных. Такой подход позволяет сохранить дорогостоящее место в высоконагруженных основных базах данных от редко используемой информации.
- Благодаря этому появляются дополнительные неиспользованные ресурсы на серверах приложений (порой 250-500 GB на сервер).
- На данной момент используются реплицируемые кластеры из 3 MySQL серверов, но в будущем это может измениться, так как требуется более удобное управление ими.

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

Сфокусируйтесь на архитектуре, а не на операциях или чем-то другом.
Иногда кэширование обходится дороже, чем повторные вычисление или поиск данных в исходном источнике.
Старайтесь избегать сложных алгоритмов, запросов к базе данных и тому подобного.
Кэшируйте каждый результат, который дорого вам обошелся и является относительно локальным.
Сфокусируйтесь на "горячих точках" в коде.
Масштабируйтесь разделением:
- операций чтения и записи (master/slave);
- сложных операций и более частых и простых (группы запросов);
- больших, популярных вики и более мелких.
Улучшайте кэширование: временная и пространственная локализация данных, а также уменьшение набора данных на каждом сервере.
Выполняйте компрессию текстовых данных, храните только изменения в статьях.
Казалось бы простые вызовы библиотечных функций порой на практике могут занимать слишком много времени.
Скорость поиска данных на диске ограничена, так что чем больше дисков - тем лучше!
Масштабирование с использованием обычного оборудование не означает использование самых дешевых вещей, которые удастся найти. Серверы баз данных Wikipedia сегодня представляют собой 16GB RAM, двух- или четырех-ядерные серверы с 6 15000 rpm SCSI дисками, организованными в RAID 0. Возможно они бы и использовали более дешевые системы, но 16 GB как раз хватает для размещения основного объема данных, а остальное берут на себя жесткие диски, это вполне соответствует потребностям системы, которую они построили. Примерно по таким же причинам их веб-сервера имеют 8 ядер, так как это позволяет достичь неплохой производительности PHP при достаточно простой организации балансировки нагрузки.
Для масштабирования требуется выполнение массы работы, но если заранее этого не предусмотреть - понадобится сделать еще больше. MediaWiki изначально была написана для одного master сервера баз данных. Затем добавилась поддержка slave. Затем добавилось распределение по языкам и проектам. Дизайн системы с тех пор прекрасно выдерживает все нагрузки, но без очистки от новых узких мест системы не обошлось.
Каждый, кто хочет разработать свою базу данных таким образом, чтобы она позволила недорого масштабироваться с уровня одного сервера до уровня десятки лучших сайтов Интернета, должен начать с обработки слегка устаревших данных на реплицированных slave серверах, при этом не забывать балансировать нагрузку операций чтения между slave серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.

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

Иван Блинков — Sat, 01 Mar 2008 16:07:00 +0300

Рост 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();
}

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

Веб-серверы

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

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

В отличии от остальных, этот перевод статьи от Todd Hoff'а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:

Google Video

Архитектура Flickr

Иван Блинков — Fri, 08 Feb 2008 22:41:00 +0300

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

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

Как и предыдущий пост "Архитектура Google", этот тоже является переводом статьи от Todd'а Hoff'а. Возможно читателям Google был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:

Flickr и PHP (ранний документ)
Планирование нагрузок на LAMP
Федерация Flickr: Тур по архитектуре Flickr
Построение масштабируемых веб-сайтов от Call Handerson'а из Flickr
История войн баз данных #3: Tim O'Reilly о Flickr
Cal Henderson's Talks - много полезных презентаций

Платформа

PHP
MySQL
Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")
Memcached для кэширования
Squid в качестве обратной-прокси для html и изображений
Linux (RedHat)
Smarty в роли шаблонизатора
Perl
PEAR для парсинга e-mail и XML
ImageMagick для обработки изображений
Java для узлового сервиса
Apache
SystemImager для развертывания систем
Ganglia для мониторинга распределенных систем
Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
Cvsup для распространения и обновления коллекций файлов по сети

Статистика

Более четырех миллиардов запросов в день
Примерно 35 миллионов фотографий в кэше Squid
Около двух миллионов фотографий в оперативной памяти Squid
Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
38 тысяч запросов к memcached (12 миллионов объектов)
2 петабайта дискового пространства
Более 400000 фотографий добавляются ежедневно

Архитектура

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

Два ServerIron
Squid кэши
Системы хранения NetApp
Серверы PHP приложений
Менеджер хранения данных
Master-master сегменты
Центральная база данных, структурированная по принципу Dual Tree
Memcached кластер
Поисковая система

Хранение данных

Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.
Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.
Использование выделенных серверов для статического контента
Все, за исключением фотографий, хранится в базе данных
Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API
В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".
Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:
- Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.
- Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.
- Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)
Сегменты:
- Срез основной базы данных
- Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре
- Привязывание новых учетных записей к сегментам системы происходит случайным образом
- Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.
Нажатие на Favorite:
- Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)
- Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)
- Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?
Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.
Для избавления от задержек, связанных с репликацией...
- при каждой загрузке страницы, пользователю предоставляется список серверов
- если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.
Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
Каждый сегмент содержит данные о более чем 400 тысячах пользователей.
Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

Поиск

Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!
В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.
Эту систему стоит рассматривать как аналог Lucene.

Оборудование

EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.
6 жестких дисков с 15000rpm, объединены в RAID-10.
Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).
Используются 2U корпуса.

Резервное копирование данных

ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.
Каждую ночь делается снимок со всего кластера баз данных.
Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.
Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.
Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.

Тэги

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

Направления для развития

Ускорение работы с помощью создания организационного плана для непрерывной работы всей системы на уровне нескольких датацентров, таким образом чтобы все датацентры имели возможность получать запросы на общий уровень данных (как сами БД, так и memcache и прочее) все вместе одновременно. Если все части системы постоянно активны - время простоя оборудования будет сведено к минимуму.

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

Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.
Реструктуризация базы данных - не самое лучшее занятие.
Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
Кэширование и оперативная память может стать ответом на все вопросы.
Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
Найдите максимальное значения для всех показателей:
- Какой максимум чего-то, что может выполнять каждый сервер?
- Как близко параметр находится к максимуму и каковы тенденции?
- MySQL (дисковый ввод/вывод?)
- Squid (дисковый ввод/вывод? или процессорное время?)
- Memcached (процессорное время? или пропускная способность?)
Старайтесь учесть особенности использования Вашего приложения.
- Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?
- Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.
- По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.