Insight IT

Кардинальный переворот в архитектуре поиска Twitter

Иван Блинков — Fri, 15 Apr 2011 23:03:00 +0400

Не успел я опубликовать обновление об архитектуре Twitter, как они снова перекроили половину проекта =) На этот раз к паре Ruby+Scala активно вплелись технологии из мира Java. Наибольшим изменениям подверглась подсистема поиска твитов , о которой сегодня и пойдет речь.

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

Backend

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

Так как поиск в Twitter является одной из самых часто используемых поисковых систем в мире (более миллиарда поисковых запросов в день), то требования к новой системе поиска были сопоставимо строгими: - Обработка более 12000 запросов в секунду - Индексация потока в 1000 новых твитов в секунду - Задержка между написанием твита и его появлением в индексе должна быть менее 10 секунд

Lucene была взята за основу, так как на сегодняшний день это одно из лучших решений для реализации поиска в мире opensource. Но в текущей ее реализации она не была приспособлена к поиску в реальном времени. Команде Twitter пришлось переписать существенную часть основных структур в памяти, особенно списки записей. При этом внешний API Lucene остался неизменным, что позволило использовать поисковые алгоритмы в практически неизменном виде. Среди основных изменений в Lucene можно выделить:

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

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

После внедрения этой системы поиск стал потреблять лишь 5% доступных ему ресурсов, что оставило приличный запас для роста даже по меркам невероятно быстро развивающегося Twitter. Новая подсистема индексации способна обрабатывать в 50 раз больше твитов в секунду, чем они получали на момент запуска, что также является очень позитивным показателем. Помимо улучшения производительности, Lucene повысила и качество поиска, а также открыла простор для новых улучшений в этом направлении.

Frontend

Кардинальный переворот в этой части системы можно описать одной фразой: Ruby on Rails заменен на Java-сервер, который они назвали Blender.

За неделю до развертывания Blender, количество поисков по твитам существенно возросло из-за #tsunami в Японии. Среднее время поиска достигало 800-900мс.

После введения Blender в эксплуатацию среднее время отклика 95% запросов упало втрое: до 250мс, при этом уровень использования вычислительных ресурсов на frontend серверах упал вдвое. Тот же поток запросов стало возможным обрабатывать меньшим количеством серверов.

Чтобы понять, откуда взялся такой прирост производительности, необходимо показать в чем были слабые стороны старого поиска на Ruby on Rails. На каждом frontend сервере было запущено фиксированное количество однопоточных Rails процессов, каждый из которых занимался следующим:

обработкой поисковых запросов
синхронным обращением к серверам с индексами
агрегацией и составлением результатов

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

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

Что же, собственно, представляет собой Blender?

Это HTTP и Thrift сервер, разработанный на основе Netty, масштабируемой неблокирующей клиент-серверной библиотеки на Java, позволяющей легко и быстро разрабатывать клиенты и серверы для различных протоколов. Выбор пал именно на неё, а не на аналоги (например Jetty или Mina) из-за более чистого API, детальной документации и, что более важно, так как некоторые другие сервисы в Twitter уже используют её. Интеграции с Thrift у нее не было, но этот вопрос решился написанием простого кодека, обрабатывающего сообщения на низком уровне.

Обработка поисковых запросов представляет собой цепочку запросов к внутренним сервисами, обработку ответов и генерацию результата. Внутренние сервисы имеют зависимости, которые можно представить в виде ацикличного направленного графа. После топологической сортировки графа Blender получает последовательность выполнения запросов, которые назначаются к выполнению в поток Netty, что в совокупности с обработчиками событий и образует workflow обработки поисковых запросов.

Заключение

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

На моей памяти эти нововведения в Twitter - практически единственный случай, когда крупный успешный проект настолько кардинально поменял основную часть стека используемых технологий. Да, они получили существенный выигрыш в производительности не в ущерб масштабируемости, но не поменяли же они большую часть команды разработчиков с Ruby-программистов на Java-программистов... Понятно, что это лишь инструменты, но довольно приличная часть людей, особенно те, кто в возрасте, не способны резко переключиться с привычных технологий на что-то совершенно новое. Хотя, скорее всего, в команде Twitter особо не было разработчиков "за 40", так что для них это не было особой проблемой.

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

Twitter Search 3x Faster (cпасибо Сергею Гуляеву за предоставленную ссылку)
Twitter's New Search Architecture

Архитектура Stack Exchange Network

Иван Блинков — Thu, 31 Mar 2011 16:05:00 +0400

Stack Exchange Network представляет собой сеть из 46 сайтов вопросов-ответов на совершенно разные темы от программирования до кулинарии. Проект вырос из известной в узких кругах тусовки программистов Stack Overflow, об архитектуре которой я уже рассказывал чуть больше года назад. Проект активно развивается и уже появилось приличное количество новой информации, которой я и спешу с Вами поделиться.

Статистика

95 миллионов просмотров страниц в месяц
800 HTTP запросов в секунду
180 DNS запросов в секунду
Загруженность интернет-канала в 55 Мбит/с
16 миллионов уникальных пользователей в месяц

Технологии

Разработка

C# - основной язык программирования
Visual Studio 2010 Team Suite - IDE
Microsoft ASP.NET 4.0 - framework
ASP.NET MVC 3 - web Framework
Razor - генератор шаблонов
jQuery 1.4.2 - JavaScript framework
LINQ to SQL и немного чистого SQL - доступ к данным
Mercurial и Kiln - контроль версий исходного кода
Beyond Compare 3 - инструмент для сравнения

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

WISC стек получен условно-бесплатно с помощью BizSpark
Windows Server 2008 R2 x64 - основная операционная система
MS SQL Server 2008 R2 на Windows Server 2008 Enterprise Edition x64 - база данных
Ubuntu Server
CentOS
IIS 7.0 - веб-сервер
HAProxy - балансировка нагрузки
Redis - используется как распределенная система кэширования
CruiseControl.NET - сборки и автоматическая система развертывания кода
Lucene.NET - полнотекстовый поиск
Bacula - резервное копирование
Nagios (с плагинами n2rrd и drraw) для мониторинга
Splunk - сбор и агрегация логов
SQL Monitor от Red Gate - мониторинг SQL Server
Bind - DNS
DotNetOpenId - реализация OpenID на .NET
WMD - текстовый редактор
Prettify - подсветка синтаксиса
MarkdownSharp - обработчик разметки Markdown на C#
Flot - построение графиков на JavaScript

Внешние сервисы

reCAPTCHA - защита от спама
Google Analytics - веб-аналитика
Kiln - Mercurial хостинг
Pingdom - внешний мониторинг и уведомления
CDN не используется, его роль выполняет sstatic.net, отдельный домен для статичных файлов SEN без cookie

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

Датацентры

1 стойка в Peak Internet, штат Орегон (чат и обнаружение данных)
2 стойки в Peer 1, Нью-Йорк (остальная часть SEN)

Серверы

10 веб-серверов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- Windows Server 2008 R2
- IIS
2 сервера баз данных:
- Dell R710
- 2x Intel Xeon Processor X5680 @ 3.33 GHz
- 64 GB RAM
- 8 жестких дисков
- MS SQL Server 2008 R2
2 виртуальных сервера для балансировки нагрузки:
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 4 GB RAM
- Ubuntu Server
- HAProxy
2 сервера для кэша:
- Dell R610
- 2x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- CentOS
- Redis
1 сервер для резервного копирования:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Bacula
1 сервер для мониторинга, управления и сбора логов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Nagios
2 сервера для виртуализации:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- VMWare ESXi

Сетевое оборудование

2 маршрутизатора на Linux
5 свитчей Dell PowerConnect

Прочее

Rovio - маленький робот, позволяющий удаленным разработчиком посетить офис "виртуально"

Команда

14 разработчиков
2 системных администратора

Что нового?

HAProxy стал использоваться вместо Windows NLB так как HAProxy является быстрым, нересурсоемким, бесплатным решением, которое работает. Полностью прозрачен для серверов, легче обслуживать по сравнению со старым решением, располагается на виртуальных машинах.
CDN не используется, так как даже "недорогие" решения обходятся в очень приличную сумму по сравнению с тем трафиком, который входит в тарифный план хостинг-провайдера. Самое дешевой решение CDN от Amazon обошлось бы как минимум на тысячу долларов в месяц дороже при текущем уровне использования трафика.
Резервное копирование на диски для быстрого восстановления и на кассеты для "истории".
Полнотекстный поиск в SQL Server плохо интегрируется, нестабилен и обладает низким качеством результатов, так что они перешли на Lucene.
Все сайты в SEN теперь работают на общей платформе: используется общее оборудование и программное обеспечение.
Проект разделен на разные сайты для разных ниш, чтобы полностью изолировать группы аудитории, специализирующиеся в каждой конкретной области.
Используется агрессивное кэширование, большинство страниц кэшируются в виде HTML для анонимных пользователей средствами IIS.
Используется три уровня кэширования: локальный, относящийся к каждому сайту и глобальный.
Локальный кэш доступен только для каждой пары сайт/сервер:
- Используется для уменьшения сетевых задержек, по сути просто через HttpRuntime.Cache.
- Содержит такие вещи как пользовательские сессии, будущие обновления счетчиков просмотров страниц.
- Располагается полностью в оперативной памяти веб-сервера.
Кэш сайта доступен для каждого сервера, обрабатывающий запрос к конкретному сайту:
- Большинство кэшируемых данных располагаются здесь.
- Располагается в Redis.
- Redis настолько быстр, что большую часть времени доступа к кэшу занимает передача данных по сети.
- Данные сжимаются перед отправкой в Redis, так как большинство данных являются строками и у них есть масса свободных вычислительных ресурсов.
- Использование процессорных ресурсов на серверах с Redis стремится к нулю.
Глобальный кэш является общим для всех серверов и сайтов:
- Личные сообщения, квоты по API и несколько других по-настоящему глобальных вещей располагаются здесь.
- Также используется Redis.
Большинство данных в кэше удаляются через заданный период времени (обычно в районе нескольких минут) и практически никогда явно не удаляются.
Когда требуется инвалидация кэша на уровне готовых страниц, используется система подписки внутри Redis для отправки сообщений в соответствующую часть системы кэширования.
Для системы ввода-вывода они выбрали Intel X25 SSD в RAID10. RAID решил многие вопросы с надежностью, а SSD показывают отличную производительностью по сравнению с FusionIO при существенно более низкой цене.
Стоимость лицензий используемых продуктов Microsoft составила бы 242 тысячи долларов. Но так как они используют программу BizSpark, им не пришлось платить большую часть этой суммы.
Сетевые карты от Broadcom заменяются на сетевые карты от Intel на основных production серверах. Это решило большинство проблем с потерями соединений, пакетов и таблицами ARP.

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

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

Архитектура Одноклассников

Иван Блинков — Tue, 22 Mar 2011 00:17:00 +0300

Сегодня представители Одноклассников рассказали о накопленном за 5 лет опыте по поддержанию высоконагруженного проекта. Была опубликована довольно детальная информация о том, как устроена эта социальная сеть для аудитории "постарше". Далее можно прочитать мою версию материала, либо перейти на оригинал по сссылке.

Платформа

Windows и openSUSE - основные операционные системы
Java - основной язык программирования
С/С++ - для некоторых модулей
GWT - реализация динамического веб-интерфейса
Apache Tomcat - сервера приложений
JBoss 4 - сервера бизнес-логики
LVS и IPVS - балансировка нагрузки
MS SQL 2005 и 2008 - основная СУБД
BerkleyDB - дополнительная СУБД
Apache Lucene - индексация и поиск текстовой информации

Статистика

До 2.8 млн. пользователей онлайн в часы пик
7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
2 400 серверов и систем хранения данных, из которых 150 являются веб-серверами
Сетевой трафик в час пик: 32 Gb/s

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

Сервера используются двухпроцессорные с 4 ядрами, объемом памяти от 4 до 48 Гб. В зависимости от роли сервера данные хранятся либо в памяти, либо на дисках, либо на внешних системах хранения данных.

Все оборудование размещено в 3 датацентрах, объединенных в оптическое кольцо. На данный момент на каждом из маршрутов пропускная способность составляет 30Гбит/с. Каждый из маршрутов состоит из физически независимых друг от друга оптоволоконных пар, которые агрегируются в общую “трубу” на корневых маршрутизаторах.

Сеть физически разделена на внутреннюю и внешнюю, разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети HTTP сервера, общаются с Интернетом, по внутренней сети все сервера общаются между собой. Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches), которые, в свою очередь, подключены как минимум двумя гигабитными линками к aggregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке. Для того, чтобы эта схема работала, используется протокол RSTP. При необходимости, подключения access коммутаторов к agregation стеку осуществляются более чем двумя линками с использованием link aggregation портов. Aggregation коммутаторы подключены 10Гб линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром. Используются коммутаторы и маршрутизаторы от компании Cisco.

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

Архитектура

Архитектура проекта имеет традиционную многоуровневую структуру:

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

Код проекта в целом написан на Java, но есть исключения в виде модулей для кэширования на C и C++. Java был выбран так как он является удобным языком для разработки, доступно множество наработок в различных сферах, библиотек и opensource проектов.

Презентационный уровень

Используем собственный фреймворк, позволяющий строить композицию страниц на языке Jаvа, с использованием собственные GUI фабрик (для оформления текста, списков, таблиц и портлетов).
Страницы состоят из независимых блоков (обычно портлетов), что позволяет обновлять информацию на них частями с помощью AJAX запросов.
При данном подходе одновременно обеспечивается минимум перезагрузок страниц для пользователей с включенным JavaScript, так и полная работоспособность сайта для пользователей, у которых он отключен.
Google Web Toolkit используется для реализации функциональные компонент, таких как Сообщения, Обсуждения и Оповещения, а также все динамических элементов (меню шорткатов, метки на фотографиях, сортировка фотографий, ротация подарков и.т.д.). В GWT используются UIBinder и HTMLPanel для создания интерфейсов.
Кешируются все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируются и сжимаются (gzip).
Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты.
При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы.
Никаких универсальных CSS селекторов. Стараются не использовать типовые селекторы (по имени тэга), что повышает скорость отрисовки страниц внутри браузера.
Если необходимы CSS expressions, то пишутся «одноразовые». По возможности избегаются фильтры.
Кешируется обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляется DOM дерево в «оффлайне».

Уровень бизнес-логики

На уровне бизнес логики располагаются около 25 типов серверов и компонентов, общающихся между собой через удаленные интерфейсы. Каждую секунду происходит около 3 миллионов удаленных запросов между этими модулями. Сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, то есть любое событие или группу событий можно выделить и направить на обработку на определенную группу серверов. При общении серверов между собой используется свое решение, основанное на JBoss Remoting.

Уровень кэширования

Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кэшируются все данные, к которым происходит частое обращение, например: профили пользователей, списки участников сообществ, информация о самих сообществах, граф связей пользователей и групп, праздники, мета информация о фотографиях и многое другое.Для хранения больших объемов данных в памяти используется память Java off heap memory для снятия ненужной нагрузки с сборщика мусора. Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД. Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу данных по сети. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность.

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

Для примера, один сервер, кэширующий граф связей пользователей, в час пик может обработать около 16 600 запросов в секунду. Процессоры при этом заняты до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа - более 85 миллионов, связей 2.5 миллиарда. В памяти граф занимает 30 GB.

Уровень баз данных

Суммарный объем данных без резервирования составляет 160Тб. Используются два решения для хранения данных: MS SQL и BerkeleyDB. Данные хранятся в нескольких копиях, в зависимости от их типа от двух до четырех. Полное резервное копирование всех данных осуществляется раз в сутки, плюс каждые 15 минут делаются резервные копии новых данных. В результате максимально возможная потеря данных составляет 15 минут.

Сервера с MS SQL объединены в failover кластера, при выходе из строя одного из серверов, находящийся в режиме ожидания сервер берет на себя его функции. Общение с MS SQL происходит посредством JDBC драйверов.

Используются как вертикальное, так и горизонтальное разбиение данных, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — весь процесс реализован на уровне бизнес-логики. Распределенные транзакции не используются — всё только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на один сервер или, если это невозможно, дополнительно разрабатывается логика обеспечения целостности данных. В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов, что позволяет осуществлять JOIN как с данными из баз данных, так и с данными из кэша. При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения потребления вычислительных ресурсов на серверах баз данных. SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция. Данные удаляются чаще всего через маркер: запись сначала отмечается как удаленная, а потом удаляется окончательно с помощью фонового процесса. Широко используются индексы, как обычные, так и кластерные. Последние для оптимизации наиболее высокочастотных запросов в таблицу.

Используется C реализация BerkleyDB версии 4.5. Для работы с BerkleydDB используется своя библиотека, позволяющая организовывать двухнодовые master-slave кластера с использованием родной BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные хранятся в tmpfs, transaction логи сохраняются на дисках. Резервная копия логов делается каждые 15 минут. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии одновременно. Помимо прочего, BerkleyDB используется и в роли очереди заданий.

Внутри системы используется взвешенный round robin, а также вертикальное и горизонтальное разбиение данных как на уровне СУБД, так и на уровне кэширования.

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

Уровень инфраструктуры

Для агрегации статистики используется собственная библиотека, основанная на log4j. Сохраняется такая информация, как количество вызовов, среднее, максимальное и минимальное время выполнения, количество ошибок. Данные сохраняются во временные базы, но раз в минуту данные переносятся из них в общий склад данных (data warehouse), а временные базы очищаются. Сам склад реализован на базе решений от Microsoft: MS SQL 2008 и сиситема генерации отчетов Reporting Services. Он расположен на 13 серверах, находящихся в отдельной от production среде. Некоторые из них отвечают за статистику в реальном времени, а некоторые за ведение и предоставление доступа к архиву. Общий объем статистических данных составляет 13Тб. Планируется внедрение многомерного анализа статистики на основе OLAP.

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

Мониторинг логически разделен на две части:

Мониторинг сервисов и компонентов
Мониторинг ресурсов, оборудования и сети

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

Команда

Над проектом работают около 70 технических специалистов:

40 разработчиков;
20 системных администраторов и инженеров;
8 тестеров.

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

Разработка ведется итерациями в несколько недель. Как пример жизненного цикла разработки можно привести 3х недельный цикл:

определение архитектуры;
разработка, тестирование на компьютерах разработчиков;
тестирование на pre-production среде, релиз на production среду.

Практически весь новый функционал делается «отключаемым», типичный процесс запуска новой функциональной возможности:

Функционал разрабатывается и попадает в production релиз;
Через централизованную систему конфигурации функционал включается для небольшой части пользователей;
Анализируется статистика активности пользователей, нагрузка на инфраструктуру;
Если предыдущий этап прошел успешно, функционал включается постепенно для все большей аудитории;
Если в процессе запуска собранная статистика выглядет неудовлетворительно, либо непозволительно вырастает нагрузка на инфраструктуру, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с начала.

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

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

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

Иван Блинков — Thu, 11 Sep 2008 04:00:00 +0400

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

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

22 миллиона пользователей;
4+ миллиона уникальных посетителей в день;
40 миллионов просмотров страниц в день;
2 миллиона поисковых запросов в день;
ежедневно отправляются 250 тысяч приглашений;
1 миллион ответов в день;
2 миллиона электронных сообщений ежедневно.

Платформа

Solaris (как x86, так и SPARC)
Tomcat и Jetty
Oracle и MySQL
Никакого ORM
ActiveMQ для JMS
Lucene в качестве основы для поиска
Spring в роли "клея"

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

2003-2005

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

2006

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

2008

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

Облако

"Облаком" в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
его размеры: 22 миллиона вершин и 120 миллионов ребер;
занимает 12GB оперативной памяти;
одновременно держится в памяти в 40 экземплярах;
построение Облака из данных, в дисковой системе, занимает 8 часов;
обновления происходят в режиме реального времени с помощью Databus;
во время остановки данные записываются на диск;
кэш реализован с помощью C++, а доступ предоставляется по JNI;
они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части - не самая тривиальная задача.

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

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

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

Сервис постоянных сообщений

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

вся система работает асинхронно и активно использует JMS;
клиенты отправляют сообщения так же через JMS;
далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

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

Сервис сетевых обновлений

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

Изначальная архитектура (до 2007 года)

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

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

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

Вторая итерация

стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский "почтовый ящик", в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом "ящике";
такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);
сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
вместо CLOB'ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

Цель: повысить производительность путем сокращения количества обновлений CLOB'ов, так как они требуют много вычислительных ресурсов.
Был добавлен буфер: колонки в таблицах типа varchar(4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

нельзя бесконечно долго ограничиваться одной базой данных: используйте много баз данных как с вертикальным, так и с горизонтальным сегментированием данных;
забудьте о ссылочной целостности и кросс-серверных JOIN'ах;
забудьте о 100% целостности данных;
при большом масштабе издержки могут стать проблемой: оборудование, базы данных, лицензии, системы хранения данных, электроэнергия и так далее;
как только вы станете достаточно крупны и популярны, спаммеры и прочие злые люди не заставят себя долго ждать;
не забывайте про кэширование!!!
используйте асинхронные потоки данных;
аналитика и построение отчетов может стать непростой задачей, постарайтесь задуматься о них заранее в процессе планирования системы;
имейте всегда ввиду, что Ваша система может упасть в любой момент;
не стоит недооценивать траекторию своего роста.

P.S.

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

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

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

Иван Блинков — Tue, 01 Apr 2008 20:49:00 +0400

Трафик, генерируемый более чем 1.2 миллионами пользователей Digg, знаменитых своей жаждой информации, способен загнать любой невинный сайт за рамки его вычислительных ресурсов и пропускной способности канала. Как же сам Digg справляется с такой нагрузкой?

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

Этот текст - перевод статьи, автор - Todd Hoff.

Платформа

Статистика

Проект стартовал в конце 2004 года на одном сервере под управлением Linux с использованием Apache 1.3, PHP 4 и MySQL 4.0 (со стандартной системой хранения данных - MyISAM).
Более 1.2 миллиона пользователей.
Более 200 миллионов просмотров страниц в месяц.
100 серверов расположены в нескольких датацентрах, из них: – 20 серверов баз данных; – 30 веб-серверов; – несколько поисковых серверов, использующих Lucene; – остальные используются для обеспечения избыточности.
30 GB данных.
Ни одна из проблем, с которыми пришлось столкнуться проекту не была связана с PHP, в основном они касались базы данных.
Легковесная природа PHP позволила переместить вычислительные работы из базы данных в приложение для улучшения производительности.

Что внутри?

Балансировщик нагрузки равномерно распределяет запросы между PHP серверами.
MySQL используется по принципу master-slave: - Сервера, обрабатывающие большое количество транзакций, используют движок InnoDB. - Сервера, выполняющие аналитическую обработку данных в реальном времени, используют MyISAM. - Снижения производительности при переходе с MySQL 4.1 на версию 5 замечено не было.
Для кэширования используется Memcached.
Используется сегментирование баз данных.
Особенности использования Digg существенно облегчают процесс масштабирования. Большинство посетителей просто просматривают главную страницу и уходят. Это приводит к тому, что 98% запросов к базе данных являются операциями чтения. Такое соотношение операций чтения и записи позволяет не беспокоиться о комплексной работе по проектированию операций записи, что позволяет намного проще масштабировать проект.
Возникали проблемы, связанные с системой хранения данных, которые сообщали, что данные уже записаны на диск, когда на самом деле это было не так. Контроллеры делали это для создания впечатления более высокой производительности. Но на практике это приводило лишь к проблемам с целостностью данных. Это достаточно распространенная проблема, которую порой не так уж просто решить, правда все зависит от используемого оборудования.
Для облегчения нагрузки на базы данных используется кэширование и APC PHP Accelerator.
С использованием рабочих потоков Apache2, FastCGI и PHP акселератора возможно избежать необходимости каждый раз заново интерпретировать и компилировать PHP скрипты: скрипт компилируется только при первом обращении, что существенно ускоряет скорость его выполнения при последующих обращениях.

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

Используйте возможность выбора движка для MySQL. Если Вам нужны транзакции - используйте InnoDB, если нет - MyISAM. Например, если на master сервере расположены транзакционные таблицы, то для slave серверов можно использовать и MyISAM.
В определенный момент рост стал невозможен путем добавления дополнительной оперативной памяти, пришлось продолжать рост путем изменения архитектуры.
Люди часто жалуются, что Digg медлителен. Скорее это вызвано их огромными JavaScript библиотеками, чем работой их серверной системы.
Стоит тщательно выбирать какие именно приложения развертывать. Они приложили все усилия, чтобы не использовать приложения, требующие больших вычислительных мощностей. Очевидно, что Digg работает на совершенно стандартной LAMP архитектуре, но тем не менее реализована она достаточно интересно. У инженеров часто возникает желание реализовать какой-либо дополнительный функционал, но всегда стоит иметь ввиду, что они могут разрушить инфраструктуру, если она не сможет расти теми же темпами. Так что с этим стоит повременить до тех пор пока система сможет выдерживать все необходимые нагрузки. Это приводит к планированию ресурсов, особенно большое внимание этому аспекту уделяет Flickr.
Вам остается лишь догадываться, сможет ли Digg удержать свои позиции, если и дальше будет ограничивать добавление новых возможностей, или уступит более активно развивающимся сервисам социальных закладок? Возможно если бы была возможность увеличивать масштабы более простыми методами, более быстрое добавление новых функций и возможностей позволило бы более эффективно конкурировать на этом рынке? С другой стороны, просто добавление новых возможностей может и не поменять ситуацию кардинальным образом.
Основные проблемы с масштабируемостью и производительностью связаны с обработкой данных и в большинстве случаев они не зависят от используемого языка программирования. Вы столкнетесь с ними при работе с Java, PHP, Ruby, или подставьте сюда Ваш любимый язык программирования.

Архитектура 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 серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.