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