Insight IT

Как дела у Plenty of Fish

Иван Блинков — Sun, 12 Feb 2012 18:04:00 +0400

Напомню, что Plenty of Fish - один из самых популярных в мире сайтов знакомств, созданный одним человеком и работающий на всего нескольких серверах и коммерческих технологиях. На Insight IT два года назад уже была подробная статья о технической реализации проекта, сегодня же я хочу поделиться свежей информацией о том, как проект развивается.

О проекте

Долгое время, около 7 лет, проект полностью разрабатывался и поддерживался исключительно Маркусом, его создателем
Первый архитектор баз данных был нанят в июле 2011 года
На сегодняшний день команда составляет около 5 сотрудников
Используется стек технологий от Microsoft, а также Akamai в роли CDN
Расходы на техническое обеспечение проекта составляют порядка 70 тысяч долларов в месяц
Ежегодные доходы от рекламы измеряются миллионами долларов

Статистика на ноябрь 2011

6 миллиардов просмотров страниц
32 миллиарда просмотров изображений, пики до 22 тыс. в секунду, по ночам около 7 тыс.
30 миллиардов обращений к серверам мгновенного обмена сообщениями
Более 6 миллионов пользователей заходят на сайт каждое воскресенье
Количество веб-серверов увеличилось с 2 до 11, что обеспечивает практически двухкратный запас по используемым ресурсам

Выводы

Чтобы проект был очень прибыльным для своих создателей, не всегда стоит торопиться стать большой компанией. Быть маленьким тоже выгодно:

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

Является ли использование продукции Microsoft причиной провала MySpace?

Иван Блинков — Wed, 20 Apr 2011 12:37:00 +0400

Как известно, MySpace появилась на рынке даже несколько раньше, чем Facebook, с практически аналогичным продуктом. Но при этом на сегодняшний день Facebook - общепризнанный лидер рынка социальных сетей, а MySpace даже далеко не все слышали название. С технической точки зрения у проектов совершенно разные подходы: Facebook построен на opensource технологиях, типичный LAMP, MySpace же полностью использует стек от Microsoft. Некоторое время назад в зарубежной блогосфере зародилась оживленная дискуссия на тему: а не выбор ли закрытых технологий стал основной причиной проигранной MySpace "гонки" социальных сетей?

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

Некоторые ключевые точки зрения:

Все интернет-компании в первую очередь технологические. Даже если основной тематикой является развлечение, всё равно оно предоставляются посредством технологий.
Все неудачи в бизнесе не связаны с технологиями. Если менеджмент не понимает ценность каждого разработчика и не может делегировать полномочия и ответственность - проект не станет успешным. С другой стороны если разработчики не знают какие вещи являются важными для бизнеса, так как их просто не держат в курсе - это так же ничем хорошим не заканчивается.
Нельзя мотивировать разрушение инновации. В MySpace основным источником дохода являлась рекламе Google, доход с которой напрямую зависел от количества просмотров страниц и кликов, что в результате подтолкнуло MySpace добавить дополнительные не нужные страницы ко всем действиям пользователей, что абсолютно уничтожило все юзабилити.
Корпоративная разработка и веб-разработка - совершенно разные вещи. Не смотря на тот факт, что большинство сошлось во мнении, что ни продукция Microsoft, ни разработчики MySpace не виноваты в провале проекта, тот факт, что между инструментами, подходами и технологиями для разработки масштабируемых интернет-проектов и корпоративных приложений имеется очень большой разрыв, очевиден. Технологии, разработанные для корпоративного рынка, не могут быть без серьезной настройки и доработки использованы в мире крупных интернет-проектов.
Нельзя позволять обратной совместимости останавливать развитие. В MySpace этот вопрос касается в большей степени пользовательского интерфейса: пользователи сами могут его настраивать. В итоге при введении каждой новой кнопочки или технологии типа AJAX им приходилось задумываться: "а не сломает ли это страницу при настройках какого-нибудь пользователя?"
Успех не вечен. Изменения нужно вводить в эксплуатацию без страха ошибиться.
Не полагайтесь на единственного клиента. Нужно иметь набор различных источников дохода, чтобы быть от них независимыми и продолжать развиваться даже если один из них иссяк.
Определитесь кем вы являетесь. Когда битва проиграна, можно переключить фокус на другую нишу, где меньше конкуренции - так новый генеральный директор MySpace переориентировал проект с социальной сети на сервис по открытию для себя новой музыки. Такие решения могут сработать, а могут и нет - но в любом случае это лучше, чем просто закрыть проект.

С моей точки зрения основной минус закрытых технологий - отсутствие полного контроля над всем кодом проекта, если проблемы начинаются в "закрытых" компонентах, то их исправление занимает нереальное количество времени, так как требует взаимодействия со сторонней компанией, которая? скорее всего? не будет торопиться решать каждую конкретную проблему и в лучшем случае её исправление будет доступно лишь в следующем релизе используемого продукта. Помимо этого, при использовании проприетарных технологий у разработчиков меньше понимания того, как работают внутри используемые технологии - никакая документация не заменит возможность "залезть под капот". В случае же с Microsoft проект совсем связывает себя по рукам и ногам, так как воспользовавшись монолитным стеком чаще всего нельзя постепенно перейти на другую технологическую базу, так как это по сути сводится к полному переписыванию кода проекта, что на подобном уровне очень затруднительно. Эти и подобные вещи замедляют процесс разработки, а значит и развитие проекта - этот фактор очень важен в современном интернет-сообществе, так как, если не двигаться вперед, конкуренты догонят и перегонят очень стремительно, как в целом и случилось с MySpace.

А какова твоя точка зрения на данную ситуацию? Может ли неудачное технологическое решение столь кардинально повлиять на успех бизнеса?

Архитектура Plenty of Fish

Иван Блинков — Mon, 18 Jan 2010 16:43:00 +0300

Plenty of Fish представляет собой очень популярный сервис онлайн знакомств, насчитывающий более 45 миллионов посетителей в месяц и 30+ миллионов просмотров страниц в сутки (что составляет около 500-600 страниц в секунду). Но это не самая интересная часть истории... Все это управляется единственным человеком при использовании нескольких серверов, при этом он тратит на работу всего пару часов в день и зарабатывает 6 миллионов долларов на рекламе от Google. Завидуете? Я тоже :) Как же ему удалось соединить столько влюбленных пар, используя так мало ресурсов?

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

Данный пост является переводом англоязычной статьи, автор оригинала: Todd Hoff.

Платформа

Microsoft Windows
ASP.NET
IIS
Akamai CDN
Foundry ServerIron Load Balancer

Статистика

PlentyOfFish (POF) имеет 1.2 миллиарда просмотров страниц в месяц, в среднем 500 тысяч уникальных авторизованных пользователей в день. Пиковый сезон приходится на январь каждого года, когда эти цифры возрастают на 30%.
POF имеет единственного сотрудника: создатель и генеральный директор Markus Frind.
Зарабатывает до 10 миллионов долларов в год на рекламе от Google, работает при этом только около двух часов в день.
30+ миллионов просмотров страниц в день (500 - 600 страниц в секунду).
1.2 миллиарда просмотров страниц и 45 миллионов посетителей в месяц.
Имеет CTR в 5-10 раз выше, чем Facebook.
Находится в top 30 сайтов США по данным Competes Attention, top 10 в Канаде и top 30 в Великобритании.
Нагрузка балансируется между двумя веб-серверами с 2 Quad Core Intel Xeon X5355 @ 2.66Ghz, 8GB RAM (используется около 800 MB), 2 жесткими дисками, работают под управлением Windows x64 Server 2003.
3 сервера баз данных. Информация об их конфигурации не предоставляется.
Приближается к 64000 одновременных соединений и 2 миллионам просмотрам страниц в час.
Интернет-канал в 1Gbps, из которых используется только 200Mbps.
1 TB трафика от отдачи 171 миллионов изображений через Akamai.
6TB система хранения данных для обработки миллионов полноразмерных изображений, которые загружаются на сайт каждый месяц.

Что внутри?

Модель монетизации заключалась в использовании рекламы от Google. Match.com, для сравнения, получает 300 миллионов долларов в год, в основном с платных подписок. Источник дохода POF должен измениться, чтобы позволить ему получать больше выручки от имеющихся пользователей. Планируется нанять больше сотрудников, в частности людей, которые будут заниматься продажей рекламы напрямую вместо того, чтобы полностью полагаться на AdSense.
При 30 миллионах просмотрах страниц в день можно зарабатывать неплохие деньги на рекламе, даже если CPM будет всего 5-10 центов.
Akamai используется для отдачи более 100 миллионов изображений в день. Если на странице 8 изображений и каждое загружается за 100 миллисекунд - их загрузка займет почти секунду, так что распределение изображений целесообразно.
Десятки миллионов изображений отдаются с серверов POF, но большинство из них размером меньше 2KB и практически полностью закешированы в оперативной памяти.
Все динамично. Практически никакой статики.
Все исходящие данные сжимаются с использованием Gzip, что обходится всего 30% использованием процессорного времени. Используется много вычислительных ресурсов, но зато существенно сокращается использование пропускной способности интернет-канала.
Кэширование ASP .NET не используется, так как данные теряют свою актуальность практически сразу же.
Встроенные компоненты ASP также не используется. Почти все написано с чистого листа. Ничего не может быть более сложным, чем кучка простых if-then-else и циклов. Все максимально элементарно.
Балансировка нагрузки:
IIS произвольно ограничивает общее количество соединений до 64000, таким образом балансировщик нагрузки был добавлен для обработки большего количества одновременных соединений. Вариант с добавлением второго IP адреса и использованием round robin DNS также рассматривался, но вариант с балансировщиком нагрузки выглядел более избыточным и позволял более легко расширять количество серверов. Помимо этого ServerIron позволял использовать более продвинутую функциональность, вроде блокировки ботов и балансировку запросов по cookies, сессиям или IP-адресам пользователей.
Windows Network Load Balancing (NLB) функция не использовалась, так как не поддерживает привязку сессий к серверам. Обходным путем было бы хранение сессионных данных в базе данных или общей файловой системе.
8-12 NLB серверов могут объединяться в кластер и может использоваться неограниченное количество таких кластеров. Схема DNS round robin может использоваться для распределения запросов между кластерами. Теоретически такая архитектура могла бы позволить 70 веб-серверам обрабатывать более 300 тысяч одновременных соединений.
NLB имеет опцию для отправки каждого пользователя на конкретный сервер, таким образом не используется внешнее хранилище для сессионных данных и если сервер выходит из строя - пользователи просто разлогиниваются из системы. Если это состояние включает в себя например корзину интернет-магазина или какую-то другую важную информацию, то такой подход мог бы показаться неприемлемым, но для сайта знакомств это было бы не так критично.
Было решено, что хранение и получение сессионных данных программными средствами слишком дорого. Аппаратная балансировка нагрузка проще: пользователи просто назначаются конкретным серверам и в случае сбоя сервера назначенным ему пользователям предлагается пройти процесс авторизации еще раз.
Покупка ServerIron была дешевле и проще, чем использование NLB. Многие крупные сайты используют их для создания пулов TCP соединений, автоматическому определению ботов и так далее. ServerIron может делать намного больше, чем просто балансировать нагрузку и такие функции достаточно привлекательные за эту цену.
Была большая проблема с выбором системы размещения рекламы. Многие из них хотели несколько сотен тысяч в год и многолетний контракт.
В процессе избавления от ASP.NET повторителей и использование взамен конкатенации строк или response.write. Если у вас миллионы просмотров страниц в день - просто напишите весь код для отображения на экране пользователя.
Большинство изначальных вложений ушло на построение SAN. Избыточность любой ценой.
Рост был за счет вирусного эффекта. Портал начал набирать популярность в Канаде, затем о нем узнали в Великобритании и Австралии, и только потом в США.
База данных:
Одна база данных является основной.
Две базы данных для поиска. Поисковые запросы распределяются по их типу.
Производительность наблюдается через диспетчер задач. Когда появляются пики - ситуация рассматривается более детально. Проблемы обычно заключались в блокировках на уровне СУБД. Собственно говоря почти всегда это были проблемы с базами данных, очень редко они возникают на уровне .NET. Так как POF не использует библиотеки .NET, отследить проблемы с производительностью оказывается достаточно просто. Если бы использовалось много уровней framework'ов, поиск мест, где скрываются проблемы, был бы трудным и утомляющим.
Если Вы делаете запрос к базе данных 20 раз при отображении одной страницы, Вы проиграли в любом случае, вне зависимости от того, что Вы будете делать.
Разделяйте запросы чтения и записи к базе данных. Если у вас нет избыточного количества оперативной памяти не следование этому правилу может заставить систему зависнуть на несколько секунд.
Постарайтесь делать базы данных только для чтения.
Денормализуйте данные. Если Вам приходится доставать данные из 20 разных таблиц, попробуйте сделать просто одну таблицу, где будут лежать все нужные для чтения данные.
Один день может проработать почти что угодно, но когда Ваша база данных удвоится - использованные подход может внезапно перестать работать.
Если система делает только что-то одно, она будет делать это реально хорошо. Только записывайте данные и все будет нормально. Только читайте данные и все будет нормально. Делайте и то и другое - и все испортится. База данных погрязнет в проблемах с блокировками.
Если Вы полностью используете вычислительные мощности, Вы либо делаете что-то не так, либо Ваша система на самом деле очень оптимизирована. Если вы можете разместить всю базу в оперативной памяти - обязательно делайте это.
Процесс разработки выглядит примерно следующим образом: появляется идея, быстро реализуется и выдается пользователям в пределах 24 часов. Отклик от пользователей получается по слежению за тем, что они делают на сайте: выросло количество сообщений на пользователя? среднее время сессий выросло? Если пользователям новая фишка не пришлась по вкусу - просто уберите её.
При небольшом количестве серверов системные сбои достаточно редки и краткосрочны. Наибольшими сложностями были проблемы с DNS, когда некоторые интернет-провайдеры говорили, что POF больше не существует. Но так как сайт бесплатен, пользователи нормально относятся к небольшим периодам его недоступности. Люди часто не замечают простой сайта, так как думают, что это какая-то проблема у них, с интернет-соединением или еще чем-то.
Переход от миллиона пользователей к 12 миллионам пользователей был большим прыжком. Система может обслуживать и 60 миллионов пользователей с двумя веб-серверами.
Часто смотрите на конкурентов для идей новых функциональных возможностей.
Рассмотрите использование чего-то вроде S3, когда система начнет требовать географической балансировки.

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

Вам не нужны миллионы в финансировании, размашистая инфраструктура и целое здание сотрудников для того, чтобы создать вебсайт мирового уровня, который обслуживает кучу пользователей и приносит неплохие деньги. Все что нужно - всего лишь привлекательная идея, которая понравится большому количеству идей, сайт, который становится популярным благодаря слухам, а также опыт и видение для построения сайта, не наступая на типичные "грабли". Вот и все, что Вам нужно :-)
Необходимость - мать всех изменений.
Когда вы растете быстро, но не слишком быстро, у Вас появляется шанс расти, модифицировать и адаптироваться.
Максимальное использование оперативной памяти решает массу проблем. После этого рост возможен просто за счет использование более мощных серверов.
В начале старайтесь держать все максимально простым. Практически все дают этот же самый совет, а Markus говорит, что все что он делает - всего лишь очевидный здравый смысл. Но то что просто, не всегда означает всего лишь осмысленную вещь. Создание простых вещей является результатом многих лет практического опыта.
Поддерживайте время доступа к базе данных быстрым и у Вас не будет проблем.
Одной из основных причин, по которой POF может работать с таким небольшим количеством сотрудников и оборудования, является использование CDN для отдачи активно используемого контента. Использование CDN может оказаться секретным соусом для многих крупных сайтов. Markus считает, что в top 100 не существует ни одного сайта, не использующего CDN. Без CDN время загрузки страницы в Австралии возросло бы до 3-4 секунд только за счет изображений.
Реклама на Facebook принесла плохие результаты. Из 2000 кликов только 1 человек регистрировался. С CTR равным 0.04% Facebook выдавал 0.4 клика на 1000 показов рекламы (CPM). При 5 центах CPM = 12.5 центов за клик, 50 центах CPM = 1.25\$ за клик. 1 доллар CPM = 2.50\$ за клик. 15\$ CPM = 37.50\$ за клик.
Это просто продавать несколько миллионов просмотров страниц с высоким CPM, но НАМНОГО сложнее продавать миллиарды просмотров с высоким CPM, как это делают Myspace и Facebook.
Модель монетизации, основанная на рекламе, ограничивает Ваши доходы. Вам придется переходить к платной модели чтобы повышать прибыль. Генерировать 100 миллионов долларов в год за счет бесплатного сайта практически невозможно - Вам потребуется слишком большой рынок.
Повышение количества просмотров за счет Facebook не работает для сайтов знакомств. Иметь посетителя на собственном сайте намного более прибыльно. Большинство просмотров страниц на Facebook находятся за пределами США и Вам придется делить 5 центов CPM с Facebook.
Предложение пользователям при регистрации получить информацию об ипотеке или каком-то другом продукте, может стать неплохим источником дополнительной выручки.
Вы не можете постоянно прислушиваться к отзывам пользователей. Кому-то всегда будут нравиться новые функции, а кто-то всегда будет их ненавидеть, но только часть из них сообщит Вам об этом. Вместо этого лучше смотреть как новые функции влияют на то, чем люди на самом деле занимаются, просто смотря на Ваш сайт и статистику его использования.

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