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

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

18 января 2010 | Иван Блинков | Высокие нагрузки