Insight IT

Информационные технологии

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

Опубликовано 8 января 2010, автор: Иван Блинков

Stack Overflow

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 OverflowServer 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 продуктов, возможно это сильно ударит по Вашему финансовому состоянию. Это справедливо, что в этой заметке речь идет не совсем об архитектуре проекта. Мы знаем об их серверах, об используемом наборе инструментов, об их двухуровневой схеме, где база данных используется напрямую из кода веб-серверов. Но мы не знаем практически ничего о самой реализации, например таких мелочей как теги. Если Вам интересен этот вопрос, возможно Вам удастся получить интересующую Вас информацию из описания их схемы базы данных.
  • 12 комментариев на запись “Архитектура Stack Overflow”

    Jeje8 января 2010 в 1:18

    >У Dell, например, переход от 4GB памяти до 128GB стоит всего 4378$.

    Без комментариев :D

    леха8 января 2010 в 11:45

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

    Alexey8 января 2010 в 15:29

    если бы ребята использовали не Microsoft решения то могли бы хвастаться что не в 10 а в 40 раз )))

    build_your_web8 января 2010 в 18:03

    2леха, ты прежде чем словами бросаться в тему бы вник, у знающих людей поспрашивал, а не у фанатиков «анти-Microsoft».

    Марк8 января 2010 в 23:01

    «6 миллионов посещений в месяц» — это же мелочь, 200 тыс. визитов в день. Вместо 3-навороченных серверов при должном подходе можно было обойтись одним сервером 5 летней давности выпуска.

    upeco9 января 2010 в 19:00

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

    Сделайте что-нибудь аналогичное на PHP, а потом посмотрим, сколько серверов у вас уйдет.

    антилеха9 января 2010 в 19:33

    леха, никогда не покупайте мерседес е класса или bmw 5, если будут деньги, купите камри, а че ничо так машина!

    Успешные компании зарабатывают деньги, потратить каких-то 11 тысяч долларов (цена Лады приоры) на софт для них ничто. Можно конечно взять PHP и MySQL (конечно купить энтерпрайз версию) и возиться в 3 раза дольше и иметь штат программистов в 3 раза больше, во время разработки написать очередной фреймворк... Хотя ничего против этого не имею. ASP.NET дается не всем...

    korchasa1 февраля 2010 в 14:42

    Хотя в целом со статьей согласен — горизонтальное масштабирование нужно совсем не всем и не всегда.

    Филипп26 июня 2010 в 15:24

    Хм, то ли цифры не соответствуют действительности, то ли все действительно плохо.

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

    Жора26 июня 2010 в 22:32

    Филлип,ты бы думал прежде чем говорить, да, 2 раза причем

    Филипп2 июля 2010 в 12:01

    Хм, Жора, я то знаю, о чем говорю. А вот ты, похоже, нет. Я решения с такой нагрузкой (и гораздо более сложной логикой) делал и неоднократно — и да, одного ноутбука хватает с запасом. Ну, или как правильно сказали, сервера 5 летней давности.

    Оставить комментарий