Insight IT

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

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

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

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

Архитектура Stack Overflow

Иван Блинков — Fri, 08 Jan 2010 00:31:00 +0300

Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel'а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.

Одним из ключевых моментов в истории Stack Overflow является использование вертикального масштабирования, как достаточно работоспособного решения достаточного большого класса проблем. Не смотря на то, что публика на сегодняшний день больше склоняется к подходу с использованием горизонтальным масштабирования и не-SQL баз данных.

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

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

Перевод статьи, автор оригинала - Todd Hoff. Возможно будет еще один пост с менее формальной информацией на ту же тему.

Статистика

16 миллионов просмотров страниц в месяц
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
6 миллионов посещений в месяц
86% трафика приходит с Google
9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Более дешевые лицензии были получены через программу Microsoft BizSpark. Скорее всего они заплатили около 11000\$ за лицензии на ОС и MSSQL.

Стратегия монетизации: ненавязчивая реклама, вакансии, конференции DevDays, достижения других смежных ниш (Server Fault, Super User), разработка StackExchange и возможно каких-то других систем рейтингов для программистов.

Платформа

Microsoft ASP.NET MVC
SQL Server 2008
C#
Visual Studio 2008 Team Suite
jQuery
LINQ to SQL
Subversion
Beyond Compare 3
VisualSVN 1.5
Веб уровень:
- 2 x Lenovo ThinkServer RS110 1U
- 4 ядра, 2.83 Ghz, 12 MB L2 cache
- 500 GB жесткие диски, зеркалирование RAID1
- 8 GB RAM
Уровень базы данных:
- 1 x Lenovo ThinkServer RD120 2U
- 8 ядер, 2.5 Ghz, 24 MB L2 cache
- 48 GB RAM
Четвертый сервер был добавлен для запуска superuser.com. Все сервера вместе обеспечивают работу Stack Overflow, Server Fault, и Super User.
QNAP TS-409U NAS для резервного копирования данных. Было принято решение не использовать "облачные" решения, так как вызванные ими дополнительные 5GB трафика ежедневно были бы накладными.
Сервера располагаются у Peak Internet. В основном из-за впечатляющей детализации технических ответов и разумных расценок.
Полнотекстный поиск в SQL Server активно используется для реализации поиска по сайту и выявления повторных вопросов. Lucene .NET рассматривается как достаточно заманчивая альтернатива.

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

Данный список является сборником уроков от Jeff и Joel, а также из комментариев к их записям:

Если Вы комфортно себя чувствуете в деле управления серверами - не бойтесь покупать их. Две основных проблемы с издержками аренды оборудования:
1. невероятные цены на дополнительную оперативную память и жесткие диски;
2. хостинг-провайдеры на самом деле не могут управлять чем-либо за Вас.
Делайте одноразовые более крупные инвестиции в оборудование, чтобы избежать быстро растущих ежемесячных издержек по аренде, которые окажутся более высокими в долгосрочном периоде.
Обновляйте сетевые драйвера. Производительность запросто может удвоиться.
Использование 48GB RAM требует обновления до MS Enterprise edition.
Оперативная память невероятно дешевая. Используйте возможности по её расширению по максимуму для получения практически бесплатной производительности. У Dell, например, переход от 4GB памяти до 128GB стоит всего 4378\$.
Stack Overflow скопировали ключевую часть структуры базы данных у Wikipedia. Это обернулось огромной ошибкой, для исправления которой потребуется большой и болезненный рефакторинг базы данных. Основным направлением изменений будет избавление от излишних операций по объединению данных в большом количестве ключевых запросов. Это ключевой урок, который стоит усвоить у гигантских много-терабайтных схем (вроде Google BigTable), которые полностью избавлены от операций объединения данных. Этот вопрос был достаточно важен для Stack Overflow, так как их база данных практически полностью располагается в оперативной памяти и операции join по прежнему требуют относительно много вычислительных ресурсов.
Производительность CPU оказывается на удивление важным фактором для серверов баз данных. Переход от 1.86 GHz, к 2.5 GHz, и к 3.5 GHz процессорам дает практически линейный прирост к времени выполнения типичных запросов. Исключение: запросы, которые затрагивают не только оперативную память.
Когда оборудование арендуется, обычно никто не платит за дополнительную оперативную память, если только вы не на помесячном контракте.
В 90% случаев наиболее узким местом является база данных.
При небольшом количестве серверов, ключевым компонентом издержек становится не место в стойках, электроэнергия, интернет-канал, сервера или программное обеспечение, а СЕТЕВОЕ ОБОРУДОВАНИЕ. Вам потребуется как минимум гигабитное соединение между уровнями веб-серверов и баз данных. Между интернетом и веб-серверами потребуется firewall, маршрутизатор и VPN. К моменту добавления второго веб-сервера понадобится решение для балансировки нагрузки. Суммарная стоимость такого оборудования может запросто вдвое превосходить стоимость пяти серверов.
EC2 предназначен для горизонтального масштабирования, для того чтобы нагрузка могла быть распределена между большим количеством машин (достаточно хорошая идея, если Вы планируете расширяться). Еще больше смысла в таком подходе появляется, если вы планируете масштабироваться по необходимости (то есть добавлять и убирать машины в зависимости от уровня нагрузки).
Горизонтальное масштабирование может проходить относительно безболезненно только при использовании open source программного обеспечения. В противном случае вертикальное масштабирование значит сокращение издержек, связанных с лицензиями, в ущерб стоимости оборудования, а горизонтальное масштабирование - наоборот: экономия на оборудовании, но требуется существенно больше лицензий на программное обеспечение.
RAID-10 отлично работает для баз данных с высокой нагрузкой операций чтения и записи.
Разделяйте работу приложений и баз данных таким образом, чтобы они могли масштабироваться независимо друг от друга. Например, базы данных могут масштабироваться вертикально, а сервера приложений - горизонтально.
Приложения должны хранить все информацию о своем состоянии в базе данных для обеспечения возможности роста путем простого добавления серверов приложений в кластер.
Одна из основных проблем со стратегией вертикального масштабирования - недостаток избыточности. Кластеризация добавляет надежности, но когда стоимость каждого сервера высока - это не так просто реализовать.
Некоторые приложения могут масштабироваться линейно относительно числа процессоров. Но зачастую будут использоваться механизмы блокировки, что приведет к сериализации вычислений и в итоге к существенному уменьшению эффективности приложения.
С более крупными серверами, занимающими от 7U в стойке, электроэнергия и охлаждение становятся критичными вопросами. Возможно использование чего-то среднего между 1U и 7U может облегчить Ваши взаимоотношения с датацентром.
С добавлением все новых и новых серверов баз данных издержки на лицензии SQL Server могут стать очень существенными. Если Вы начнете с вертикального масштабирования и постепенно начнете переходить к горизонтальному с использованием не open source продуктов, возможно это сильно ударит по Вашему финансовому состоянию. Это справедливо, что в этой заметке речь идет не совсем об архитектуре проекта. Мы знаем об их серверах, об используемом наборе инструментов, об их двухуровневой схеме, где база данных используется напрямую из кода веб-серверов. Но мы не знаем практически ничего о самой реализации, например таких мелочей как теги. Если Вам интересен этот вопрос, возможно Вам удастся получить интересующую Вас информацию из описания их схемы базы данных.

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

Иван Блинков — Mon, 21 Dec 2009 16:15:00 +0300

MySpace.com является одним из наиболее быстро набирающих популярность сайтов в Интернете с 65 миллионами пользователей и 260000 регистрациями в день. Этот сайт часто подвергается критике из-за не достаточной производительности, хотя на самом деле MySpace удалось избежать ряда проблем с масштабируемостью, с которыми большинство других сайтов неизбежно сталкивались. Как же им это удалось?

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

Данная статья является переводом статьи MySpace Architecture, автором которой является Todd Hoff. Когда-то давно один из читателей этого блога просил меня осветить и эту тему, тогда я так и не решился из-за отсутствия моего личного интереса, но сейчас снова случайно наткнулся на эту статью и подумал: а почему бы и нет?

Платформа

ASP .NET 2.0
Windows
IIS
MSSQL Server

Что внутри?

300 миллионов пользователей.
Отдает 100Gbps в Интернет. 10Gbps из них является HTML контентом.
4,500+ веб серверов со связкой: Windows 2003 / IIS 6.0 / ASP .NET.
1,200+ кэширующих серверов, работающих на 64-bit Windows 2003. На каждом 16GB объектов находятся в кэше в оперативной памяти.
500+ серверов баз данных, работающих на 64-bit Windows и SQL Server 2005.
MySpace обрабатывает 1.5 миллиарда просмотров страниц в день, а также 2.3 миллионов одновременно работающих пользователей в течении дня.
Вехи по количеству пользователей:
- 500 тысяч пользователей: простая архитектура перестает справляться
- 1 миллион пользователей: вертикальное партиционирование временно спасает от основных болезненных вопросов с масштабированием
- 3 миллиона пользователей: горизонтальное масштабирование побеждает над вертикальным
- 9 миллионов пользователей: сайт мигрирует на ASP.NET, создается виртуализированная система хранения данных (SAN)
- 26 миллионов пользователей: MySpace переходит на 64-битную технологию.
500 тысяч учетных записей было многовато для двух веб-серверов и одного сервера баз данных.
На 1-2 миллионах учетных записей:
- Они использовали архитектуру базы данных, построенную на концепции вертикального партиционирования, с отдельными базами данных для разных частей сайта, которые использовались для выполнения различных функций, таких как экран авторизации, профили пользователей и блоги.
- Схема с вертикальным партиционированием помогала разделить нагрузку как для операций чтения, так и для операций записи, а если пользователям в друг оказывалась нужна новая функциональная возможность - достаточно было просто добавить еще один сервер баз данных для её обслуживания.
- MySpace переходит от использования систем хранения, подключенных к серверам баз данных напрямую, к сетям хранения данных (SAN), при таком подходе целый массив систем хранения объединяется вместе специализированной сетью с высокой пропускной способностью, и сервера баз данных также получают доступ к хранилищам через эту сеть. Переход к SAN оказал положительное влияние как на производительность, так и на доступность и надежность системы.
На 3 миллионах учетных записей:
- Решение с вертикальным партиционированием не протянуло долго, так как им приходилось реплицировать какую-то часть информации (например информацию об учетных записях) по всем вертикальным частям базы данных. С таким большим количеством операций репликации данных один узел даже при незначительном сбое мог существенно замедлить обновление информации во всей системе.
- Индивидуальные приложения вроде блогов на под-секциях сайта достаточно быстро стали слишком большими для нормальной работы с единственным сервером базы данных
- Произведена реорганизация всех ключевых данных для более логичной организации в единственную базу данных
- Пользователи были разбиты на группы по миллиону в каждой и каждая такая группа была перемещена на отдельный SQL Server
9–17 миллионов учетных записей:
- Переход на ASP .NET, который требовал меньше ресурсов по сравнению с их предыдущим вариантом архитектуры. 150 серверов, использовавших новый код могли обработать нагрузку, для которой раньше требовалось 246 серверов.
- Снова пришлось столкнуться с узким местом в системе хранения данных. Реализация SAN решило какую-то часть старых проблем с производительностью, но на тот момент потребности сайта начали периодически превосходить возможности SAN по пропускной способности операций ввода-вывода - той скорости, с которой она может читать и писать данные на дисковые массивы.
- Столкнулись с лимитом производительности при размещении миллиона учетных записей на одном сервере, ресурсы некоторых серверов начали исчерпываться.
- Переход к виртуальному хранилищу, где весь SAN рассматривается как одно большое общее место для хранения данных, без необходимости назначать конкретные диски для хранения данных определенной части приложения. MySpace на данный момент работает со стандартизированным оборудованием от достаточно нового вендора SAN - 3PARdata
Был добавлен кэширующий уровень — прослойка из специализированных серверов, расположенных между веб-серверами и серверами данных, чья единственная задача была захватывать копии часто запрашиваемых объектов с данными в памяти и отдавать их веб-серверам для минимизации количества поиска данных в СУБД.
26 миллионов учетных записей:
- Переход на 64-битные сервера с SQL Server на правах решения проблемы с недостатком оперативной памяти. С тех пор их стандартный сервер баз данных оснащен 64 GB RAM.
Горизонтальная федерация баз данных. Базы данных партиционируются в зависимости от своего назначения. У них есть базы данных с профилями, электронными сообщениями и так далее. Каждая партиция основана на диапазоне пользователей. По миллиону в каждой базе данных. Таким образом, у них есть Profile1, Profile2 и все остальные базы данных вплоть до Profile300, если считать, что у них на данный момент зарегистрировано 300 миллионов учетных записей.
Кэш ASP не используется, так как он не обеспечивает достаточного процента попаданий на веб серверах. Кэш, организованный как промежуточный слой, имеет существенно более высокое значение данного показателя.
Изоляция сбоев. Внутри веб-сервера запросы сегментируются по базам данным. Разрешено использование только 7 потоков для работы с каждой базой данных. Таким образом, если база данных по каким-то причинам начинает работать медленно, только эти потоки замедлятся, в то время как остальные потоки будут успешно продолжать обрабатывать поток трафика.

Работа сайта

Коллектор данных о производительности. Централизованная система сбора информации о производительности через UDP. Такой подход более надежен, чем стандартный механизм Windows, а также позволяет любому клиенту подключиться и увидеть статистику.
Веб-система по просмотру дампов стеков процессов. Можно просто сделать клик правой кнопкой мыши на проблемном сервере и увидеть дамп стека процессов, управляемых .NET. И это после привычки каждой раз удаленно подключаться к серверу, включать дебаггер и через полчаса получать свой ответ о том что же все таки происходит. Медленно, немасштабируемо и утомительно. Эта же система позволяет увидеть не просто стек процесса, но и предоставляет большое количество информации о контексте, в котором он работает. Обнаружение проблем намного проще при таком подходе, например можно легко увидеть, что база не отвечает, так как 90 ее потоков заблокировано.
Веб-система создания дампа heap-памяти. Создает дамп всей выделенной памяти. Очень удобно и полезно для разработчиков. Сэкономьте часы на выполнение этой работы вручную.
Профайлер. Прослеживает запрос от начала до конца и выводит подробный отчет. В нем можно увидеть URL, методы, статус, а также все, что поможет идентифицировать медленный запрос и его причины. Обнаруживает проблемы с блокировкой потоков, непредвиденными исключениями, другими словами все, что может оказаться интересным. В то же время остается очень легковесным решением. Работает на одной машине из каждой VIP (группа из 100 серверов) в production-среде. Опрашивает 1 поток каждые 10 секунд. Постоянно следит за системой в фоновом режиме.
Powershell. Новая программная оболочка от Microsoft, которая работает в процессе и передаем объекты между командами вместо работы с текстовыми данными. MySpace разрабатывает множество так называемых commandlets'ов для поддержки различных операций.
Разработана собственная технология асинхронной коммуникации для того, чтобы обойти проблемы с сетевыми проблемами Windows и работать с серверами как с группой. Например, она позволяет доставить файл .cs, скомпилировать его, запустить, и доставить результат обратно.
Развертывание. Обновление кодовой базы происходит с помощью упомянутой выше собственной технологии. Ранее происходило до 5 таких обновлений в день, сейчас же они происходят лишь раз в неделю.

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

С помощью стека Microsoft тоже можно делать большие веб-сайты.
Стоит использовать кэширование с самого начала.
Кэш является более подходящим местом для хранения временных данных, не требующих персистентности, например информации о пользовательских сессиях.
Встроенные в операционные систему возможности, например по обнаружению DDoS-атака, могут приводить к необъяснимым сбоям.
Храните свои данные в географически удаленных датацентрах для минимизации проблем, связанных со сбоями в электросети.
Рассматривайте возможности использования виртуализированных систем хранения данных или кластерных файловых систем с самого начала. Это позволит существенно параллелизировать операции ввода-вывода, а также увеличивать дисковое пространство без необходимости какой-либо реорганизации.
Разрабатывайте утилиты для работы с production окружением. Невозможно смоделировать все ситуации в тестовой среде. Масштабируемость и все различные варианты использования API не могут быть симулированы в процессе тестирования качества программного обеспечения. Обычные пользователи и хакеры обязательно найдут такие способы использования вашего продукта, о которых вы даже никогда и не подумаете в процессе тестирования, хотя конечно большая часть все же обнаружима в процессе QA тестирования.
Когда это возможно - лучше просто использовать дополнительное оборудование для решения проблем. Это намного проще, чем изменять поведение программного обеспечения для того чтобы решать задачи как-то по-другому. Примером может служить добавление нового сервера на каждый миллион пользователей. Возможно было бы более эффективным изменить подход к самой работе с СУБД, но на практике все же проще и дешевле добавлять все новые и новые сервера. По крайней мере на данный момент.