Insight IT

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

Иван Блинков — Fri, 13 Apr 2012 20:11:00 +0400

Instagram - всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

Начало:

1 сервер слабее Macbook Pro
25к регистраций в первый день
2 разработчика

Сегодня:

40+ миллионов пользователей
100+ виртуальных серверов в EC2, в том числе:
Проект куплен Facebook за 1 млрд. долл
1 миллион регистраций за 12 часов после запуска Android-версии
5 разработчиков

Технологии

Ubuntu Linux 11.04 - основная операционная система
Python - основной язык программирования серверной части
Django - фреймворк
Amazon:
- EC2 - хостинг
- ELB - балансировка входящих HTTP-запросов
- Route53 - DNS
- S3 - хранение фотографий
- CloudFront - CDN
nginx - второй уровень балансировки входящихHTTP-запросов
gunicorn - WSGI-сервер
HAProxy - балансировка нагрузки внутри системы
PostgreSQL - основное хранилище данных
postgis - поддержка гео-запросов
pgfouine - отчеты на основе логов
pgbouncer - создание пула соединений
Redis - дополнительное хранилище данных
Memcached - кэширование
Gearman - очередь задач
Solr - гео-поиск
munin, statsd, pingdom - мониторинг
Fabric - управление кластером
xfs - файловая система

Философия

Простота
Минимизация операционных издержек
Использование подходящих инструментов

История

Забыли сделать favicon.ico до запуска - в первый же день логи пестрили ошибками 404
Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
Следующим шагом стало горизонтальное разбиение данных (sharding):
Создали несколько тысяч логических баз данных.
Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
С некоторыми задачами лучше справляется Redis:
Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
В Redis также хранится информация о сессиях.
Несколько фактов о Redis:
- Так как все находится в памяти - очень быстрые операции записи и работы с множествами.
- Является не заменой, а дополнением к основному хранилищу данных.
- Redis хорош для структур данных, которые относительно ограничены.
- Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например - счетчики, подмножества, проверка вхождения в множества).
- Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
- Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
- Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
избежать необходимости дешифровки SSL посредством nginx;
ускорить исключение из балансировки проблемных серверов.
Благодаря использованию xfs есть возможность "замораживать" и "размораживать" дисковые массивы при резервном копировании.

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

Многие проблемы с масштабируемостью - результат банальных человеческих ошибок.
Масштабирование = замена всех деталей в машине на скорости 150 км/ч.
Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
Дополните свое основное хранилище более гибким компонентом, вроде Redis.
Постарайтесь не использовать два инструмента для решения одной и той же задачи.
Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
Активное юнит- и функциональное тестирование стоят потраченного на них времени.
DRY: не делайте одну и ту же работу несколько раз.
Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
Короткий цикл разработки - залог быстрого развития.
Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
Не изобретайте велосипед.
Окружите себя с толковыми консультантами.
Культура открытости вокруг разработки.
Делитесь с opensource сообществом.
Фокусируйтесь на том, что вы делаете лучше всего.
Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
Не рассчитывайте, что "кто-то еще присоединится к команде и разберется с этим".
Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

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

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.

Архитектура 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.

Архитектура 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-сервера, стало недостаточная расширяемость и масштабируемость существующих решений. Была необходимость в реализации многих нестандартных функций, вроде индивидуальных обработчиков пользовательских изображений и личных данных, обычно в других решениях было доступно только изменение методов аутентификации.

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

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