Insight IT

Как проект Ravelry дорос до 10 миллионов запросов с помощью Rails

Иван Блинков — Thu, 24 Sep 2009 11:31:00 +0400

Данная статься основана на замечательном интервью, взятом Tim Bray у Casey Forbes, создателя Ravelry, сайта на Ruby on Rails, поддерживаемое сообществом вязальщиц и специалистов по вышивке крючком численностью более 400000 человек.

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

Десять лет назад сайт масштаба Ravelry потребовал бы далеко не один миллион долларов для поддержания своего функционирования. Сегодня же Casey является единственным разработчиком Ravelry, а поддержанием работоспособности системы занимается всего несколько человек. Изначальный процесс разработки занял у Casey 4 месяца работы по ночам и выходным. Если Вы взглянете на список технологий, используемых в Ravelry, Вам станет видно, что проект построен практически полностью на свободном и бесплатном программном обеспечении, которые просто было собрано вместе в единую полноценную систему. В сегодняшней экосистеме существует множество возможностей для того чтобы делать новые вещи просто комбинируя существующие качественные приложения, языки программирования, системы хранения, а также услуги по размещению и предоставлению доступа к веб-приложениям и данным.

Сейчас Casey и еще несколько сотрудников живут за счет Ravelry. Не это ли является мечтой любого предприятия малого бизнеса? Хотите узнать как и Вы могли бы достичь подобных успехов? Данный текст является переводом статьи How Ravelry Scales to 10 Million Requests Using Rails, автор оригинала - Todd Hoff.

Статистика

10 миллионов запросов ежедневно обрабатывается Rails (AJAX + RSS + API)
3.6 миллиона просмотров страниц ежедневно
430,000 зарегистрированных пользователей. 70,000 активно пользуются сайтом ежедневно. 900 новых пользователей регистрируется ежедневно.
2.3 миллиона проектов по вязанию, 50000 новых сообщений на форуме ежедневно, всего 19 миллионов сообщений на форуме, 13 миллионов сообщений, 8 миллионов фотографий (большая часть размещена на Flickr).
Проект начинался на небольшом VPS, но потребности в ресурсах очень быстро вышли за его возможности.
Монетизация: рекламодатели + магазин соответствующей продукции + продажа узоров

Platform

Ruby on Rails (1.8.6, Ruby GC патчи)
Percona сборка MySQL
Gentoo Linux
Servers: Silicon Mechanics (не арендуемые, в их собственности)
Хостинг: Colocation от Hosted Solutions
Интернет-канал: Cogent (очень дешево)
Capistrano для развертывания
Nginx существенно более быстрый и менее требовательный к оперативной памяти по сравнению с Apache
Xen для виртуализации
HAproxy для балансировки нагрузки
Munin для мониторинга
Tokyo Cabinet / Tokyo Tyrant для кеширования больших объектов
Nagios для предупреждений
HopToad для уведомлений об исключительных ситуациях.
NewRelic для тонкой настройки
Syslog-ng для агрегации логов
S3 для хранения данных
Cloudfront в роли CDN
Sphinx для текстового поиска
Memcached для кеширования маленьких объектов

Архитектура

7 серверов (Gentoo Linux). Средствами виртуализации (Xen) создано 13 виртуальных серверов:
- Для обработки пользовательских запросов используются Nginx и Haproxy. Запросы проходят следущую цепочку: nginx -> haproxy -> apache + mod_passenger.
- Один небольшой сервер для резервного копирования данных.
- Один небольшой вспомогательный сервер для некритичных процессов и тестирования новых версий.
- 2 сервера с 32 GB оперативной памяти для master+slave баз данных, а также поисковой системы Sphinx.
- 3 сервера приложений, состоящих из 6 Apache Passenger и запущенных экземпляров Ruby, каждый ограничен 20-ю потоками. Суммарно 6 четырехядерных процессоров и 40 GB оперативной памяти. Часть оперативной памяти большую часть времени простаивает.
5 терабайт данных располагается в Amazon S3. Cloudfront используется как CDN.
Tokyo Cabinet/Tyrant используется вместо memcached в некоторых местах для кеширования более крупных объектов, в частности уже размеченного текста в HTML.
HAproxy и Capistrano используются для вывода новых версий сайта без негативного влияния на производительность и работу пользователей.

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

Позвольте своим пользователям работать над Вашим сайтом за Вас. Проводите итерации и развивайтесь. Начните с чего-то, что просто работает, и позвольте людям начать пользоваться продуктом, развивать проект совместно с пользователями намного проще. Не торопясь развивайте бета-версию своего проекта. Также медленно приглашайте новых людей. Старайтесь ежедневно обсуждать с пользователями что бы они хотели увидеть нового в проекте. Разрешите им оказывать помощь в развитии проекта и результат станет существенно более обнадеживающим, утешительным, интуитивно-понятным и эффективным.
Позвольте пользователям спонсировать Ваш проект. Ravelry частично был создан за счет его пользователей, которые пожертвовали в пользу проекта более 71 тысячи долларов. Эти средства были переданы проекту просто как дар, а не в обмен на акции. Не недооценивайте значимость капитала компании. Ravelry потребовалось 6 месяцев непрерывной работы и экономии на издержках, связанных с серверным оборудованием и каналами связи, чтобы наконец-то начать получать прибыль, и полученные от пользователей средства оказались основным фактором, позволившим проекту пережить этот тяжелый период. Залогом их успеха является поддержание интереса и искры в глазах своих пользователей, подталкивание пользователей к оказанию помощи и поддержки проекту. Для этого требуется любовь к своему делу и самоотдача.
Станьте центром выбранной ниши. Найдите нишу на рынке с недостаточным предложением. Не стремитесь к массовым рынкам. Совсем не обязательно делать что-то для многих миллионов людей. Миллионы скорее всего просто зевнут от скуки и в скором времени о Вас забудут. Лучше создайте что-нибудь очень полезное для небольшой заинтересованной группы лиц и их страсть к их интересам перейдет и к Вам.
Успех не обязательно должен быть связан с масштабностью проекта, намного большее значение имеет стабильная и качественная реализация © Jeff Putz.
Основная проблема в базе данных. Практически вся работа, относящаяся к масштабируемости/настройке/производительности, так или иначе связана с базой данных. Например, изменение схемы данных для больших таблиц в MySQL всегда связано с рядом проблем, особенно если простой сервиса неприемлем. Еще один аргумент в пользу баз данных, не имеющих схем данных.
Продолжайте получать удовольствие. Casey перешел на Ruby on Rails так как ему хотелось снова заняться программированием с энтузиазмом. Этот факт стал одним из основных факторов, которые помогли сделать проект успешным.
Придумывайте новые вещи, которые будут приводить в восторг Ваших пользователей. Воспользуйтесь магией, людям это нравится. Это тоже один из принципов данного проекта. Например по этой ссылке, можно почитать об использовании очень инновационных подходов к управлению форумами.
Ruby — это круто. Он представляет собой интересный язык программирования, позволивший Ravelry быстро пройти стадию изначальной разработки и выпускать новые версии дважды в день в период бета-тестирования.
Получайте большую прибыль за счет минимизации издержек. У Ravelry есть свой магазин с соответствующей тематике продукцией, оптовые счета, принтеры и реализующая компания. Это позволяет им поддерживать издержки на низком уровне, таким образом их прибыль не уходит сторонним компаниям вроде CafePress.
Наиболее сложный переход заключается в переходе от одного сервера к нескольким. В этом процессе все меняется и становится более сложным и комплексным. Всегда имейте этот переход ввиду, когда планируете архитектуру веб-приложения.
В сегодняшней экосистеме имеется возможность делать массу различных вещей даже обладая минимумом ресурсов. Для создания комплексного сайта вроде Ravelry больше не нужно много людей или финансов. Взгляните на список различных программ, используемых в Ravelry, а также на небольшое количество людей, работающих над поддержанием работы проекта.

Некоторые люди могут жаловаться, что здесь нет практически никаких подробностей о том, как же все таки работает Ravelry. Сайты таких размеров не должны иметь развернутого описания мистического процесса его масштабирования, такие проекты могут быть построены просто из составных частей, с умом собранных вместе. И это очень здорово.

Архитектура Friends for Sale

Иван Блинков — Mon, 17 Mar 2008 21:44:00 +0300

За три коротких месяца Friend for Sale (рейтинговая система в условиях рыночной экономики) попала в десятку лучших приложений Facebook, непринужденно обрабатывая 200 запросов в секунду и демонстрируя шокирующее количество просмотров страниц, за месяц достигающее 300 миллионов просмотров. Все это дело рук двух разработчиков, работающих не полный рабочий день, которые смогли создать успешное веб-приложение, имея в своем распоряжении лишь кластер из дюжины серверов и Ruby on Rails.

Как Friends for Sale масштабируется для того, чтобы обеспечить торговлю всеми этими красивыми людьми? Как Вы думаете, сколько стоят Ваши друзья на открытом рынке?

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

Традиционная пара фраз, чтобы отдать должное оригиналу и его автору. Продолжаем:

Ответы на стандартный набор вопросов от Siqi Chen и Alexander Le, создателей Friends for Sale;
Virality on Facebook.

Платформа

Ruby on Rails
CentOS (64 bit)
Capistrano - для обновлений и перезапусков серверов
Memcached
MySQL
nginx
Starling - распределенный сервер очередей
Softlayer - хостинг
Pingdom - мониторинг
LVM - Magic Multi-Connections Gem - разделение операций чтения и записи между серверами

Статистика

Это Facebook приложение находится в десятке наиболее популярных;
Около 600 тысяч активных пользователей;
Полмиллиона уникальных посетителей ежедневно, и эта цифра неуклонно растет;
Темпы роста проекта достигают 300% в месяц;
200 запросов в секунду;
5 TB трафика в месяц;
Над проектом работают 2 разработчика и 1 админимтратор баз данных.
4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки:
- Каждый из серверов приложений содержит 4 ядра и 8 GB оперативной памяти.
- На каждом из них работает 16 сервисов mongrel (в сумме - 96).
- 4 GB оперативной памяти на каждом из них отведено под memcached.
- Сервера баз данных имеют более серьезное оборудование: при тех же 4-х ядрах, они имеют 32 GB оперативной памяти и RAID 10 массив из четырех 15000rpm SCSI дисков, работающих в режиме "master/slave".

Давайте знакомиться

Для чего нужна ваша система?

Наша система разработана в качестве платформы для нашего Facebook приложения, Friends for Sale. В целом оно представляет собой аналог рейтинговой системы Hot-or-Not с некоторым добавлением рыночной экономики. В момент проведения интервью это приложение было на 10-м месте по популярности среди приложений Facebook.

Описание этого приложения на самом Facebook гласит:

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

Почему вы решили построить эту систему?

Мы разработали ее скорее как эксперимент для того, чтобы проверить удалось ли нам понять концепции и измерения вирусного эффекта в рамках Facebook. Мне кажется нам это удалось. :)

С какими конкретными сложными задачами, связанными с дизайном, архитектурой или реализацией системы, вам пришлось столкнуться при построении системы?

Как и в любом Facebook приложении, каждый запрос является динамическим, так что кэширование страниц невозможно. Так как приложение является интерактивным, со множеством операций записи, определенные трудности вызвало масштабирование базы данных.

Каковы были ваши

действия, направленные для решения этих задач?

С самого начала мы активно использовали memcached - для перезагрузки страницы совсем не требуется выполнение SQL запросов. В основном мы использовали кэширование фрагментов Rails с индивидуальной логикой актуальности.

Как вы оцениваете размеры вашей системы?

Вчера статистика показала более полумиллиона уникальных посетителей, и эта цифра неуклонно растет. За этот месяц было зарегистрировано более 300 миллионов просмотров страниц.

Каковы показатели использования пропускной способности интернет-канала?

В прошлом месяце было потрачено 3 терабайта трафика, но в этом месяце ожидается цифра не меньше 5 терабайт. Эти цифры состоят по большей части из XHTML / CSS и нескольких небольших иконок.

Как много документов используется в системе? Сколько изображений? Какой объем данных?

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

Как вы оцениваете темпы роста вашей системы?

Месяц назад за сутки просматривалось около трех миллионов страниц, на данный момент эта цифра достигла 10 миллионов в сутки. Из чего можно сделать вывод, что ориентировочные темпы роста проекта составляют 300% в месяц. Если говорить о ежесекундной нагрузке, то на данный момент она составляет около 200 запросов в секунду.

Какая часть посетителей платит вам за участие в вашем проекте?

Он абсолютно бесплатен для пользователей.

Каковы показатели "текучести" пользователей?

В среднем около 1% в сутки, с ежедневным ростом в 3% от этой цифры, если говорить в терминах новых установок .

Как много учетных записей активно принимали участие в проекте за последний месяц?

По данным Google за последний месяц проект посетил 2.1 миллион уникальных пользоывтелей.

Какова архитектура вашей системы?

Она представляет собой относительно стандартный Rails кластер. В качестве интерфейса между запросами пользователей и серверами приложений используется proxy балансировщик нагрузки, который перенаправляет запросы напрямую шести четырехядерным серверам приложений. На каждом сервере приложений запущено 16 mongrel'ов, что в сумме дает 96. Балансировщик нагрузки перенаправляет запросы напрямую на порты серверов mongrel. В дополнение к этому на каждом сервере приложений выделено 4 GB оперативной памяти под memcached, а также работает локальный сервер распределенного менеджера очередей Starling и несколько менее важных фоновых процессов.

СУБД работает на двух серверах (четыре ядра, 32 GB оперативной памяти, четыре 15000rpm SCSI диска в RAID 10) в режиме "master/slave". Для организации распределения операций чтения и записи между серверами используется Magic Multi-Connections Gem от Dr Nic.

На данный момент ведется работа над добавлением дополнительных серверов, работающих в роли "slave", для обеспечения более эффективного распределения нагрузки, избыточности и политик хранения запасных копий данных. Помимо этого нам помогают Percona (ребята из mysqlperformanceblog) с удаленной работой над архитектурой базы данных.

Нашим хостинг-провайдером является Softlayer - он просто фантастический. Основной проблемой был тот факт, что их балансировщик нагрузки не справлялся со своей задачей ... поначалу у нас возникала масса проблем, связанных с задержками и повисшими соединениями. Переход на отдельный сервер с запущенным только nginx в режиме proxy балансировщика нагрузки позволила решить все проблемы.

Каким образом планируется масштабировать архитектуру вашего проекта?

Каких-то конкретных планов нет. На уровне приложения система не использует какие-либо общие ресурсы, так что все достаточно тривиально. На уровне баз данных на данный момент все еще используется один сервер в роли "master", но мы стараемся отложить неизбежный переход к сегментированной базе данных на как можно более длительный срок. На данный момент базы данных масштабируются вертикально, но со временем, надеюсь, мы сможем от этого избавиться.

Назовите самые интересные уникальные факты о вашем проекте?

Я могу назвать:

Ни один из двух разработчиков ранее не имел опыта в крупномасштабных разработках на основе Rails.
Наша траектория роста проекта достаточно редка в истории разработок с использованием Rails.
У нас практически не было возможностей для кэширования статических страниц - каждый запрос страницы приходилось обрабатывать Rails.

Чему вам удалось научиться? Каков залог вашего успеха? Чего бы вам хотелось сделать по-другому в прошлом, если бы была такая возможность? Что бы вы оставили как есть?

Отличные хостинг, оборудование и архитектура БД являются очень важными факторами. Мы привыкли пользоваться услугами хостинга Railsmachine, который честно говоря является отличным провайдером shared хостинга, но со временем они потеряли возможность выдерживать необходимую нагрузку. В итоге почти месяц мы были едва способны отвечать на запросы браузеров из-за проблем с оборудованием, хотя последующий переход на Softlayer занял всего два часа. Стоит заранее выбирать качественный хостинг, если планируется масштабирование проекта, смена хостинг-провайдера - не очень веселое занятие.

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

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

Мы определенно не сменим наш framework - Rails был незаменим при быстрой разработке приложения, нам удалось доказать, что для масштабирования проекта на RoR достаточно двух парней, абсолютно не имеющих опыта в этом.

Кто входит в состав вашей команды?

У нас есть два разработчика, включая меня. Помимо этого недавно мы начали пользоваться услугами помощи с DBA, о которой уже упоминалось.

Сколько всего людей участвует в проекте?

В технической части - два разработчика и один администратор баз данных, работающий на контрактной основе.

Где они расположены с географической точки зрения?

Все участники проекта живут в районе SOMA, San Francisco.

Каковы обязанности каждого из участников проекта?

Оба разработчика проекта по совместительству являются и его создателями. Поначалу я (Siqi) был ответственным за дизайн и разработку пользовательского интерфейса, но так как у меня был некоторый опыт с развертыванием систем я взял на себя и разработку управления сетевыми операциями и развертывания. Мой коллега Alex был ответственным за большую часть Rails кода, вся логика приложения - его рук дело.

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

У вас есть какая-то определенная философия менеджмента?

Да - найти самых умелых и сообразительных людей, сделать им наилучшее возможное предложение и убраться с их пути. Самые лучшие менеджеры должны уметь НЕ МЕШАТЬ работникам, так что я стараюсь максимально этому следовать при работе с другими участниками проекта. Но, к сожалению, мне удается это далеко не всегда.

Если ваша команда работает раздельно, как вам удается координировать свою работу?

Нам стоило бы задуматься об использования каких-либо эффективных средств общения. Мне кажется, что использование удаленной работа / outsourcing'а является по-настоящему сложной задачей - я предпочитаю обходиться без этого в разработке основы системы. Для системного администрирования или разработки архитектуры БД это было бы более оправданно.

Что вы используете для разработки?

Мы используем Rails с несколькими plug-in'ами, самыми важными являются cache-fu от Cris Wanstrath и magic multi connections от Dr Nic. В качестве текстового редактора я предпочитаю vim с плагином rails.vim.

Какие языки программирования используются?

Ruby on Rails

Сколько используется серверов?

На данный момент используется кластер из 12 серверов.

Как они используются?

4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки.

Кто их предоставляет?

Мы заказываем их у Softlayer - до подключения их к системе проходит порой менее четырех часов, что очень неплохо.

Какая операционная система используется?

CentOS 5 (64 бит)

Какой http сервер используется?

nginx

Какая СУБД используется?

MySQL 5.1

Вы используете обратную proxy?

Мы просто используем встроенный в nginx proxy балансировщик нагрузки.

Как вы развертываете вышу систему в датацентре?

Мы используем хостинг выделенных серверов, Softlayer.

Какова ваша стратегия хранения данных?

Мы используем резервное копирование NAS помимо внутренних SCSI RAID массивов.

Какой объем дискового пространства вам доступен?

На всех серверах в сумме около 5 TB.

Как вы наращиваете объем дискового пространства?

Спонтанно. Мы еще не выполнили каких-либо исследований в планировании дискового пространство, но это было явно зря не сделано.

Вы используйте какой-либо сервис хранения информации?

Нет.

Вы используете виртуализацию хранимых данных?

Нет.

Как организована работа с сессиями?

На данный момент она поручена СУБД, но передача их обслуживания напрямую memcached - достаточно несложная задача.

Как организована архитектура вашей БД?

На данный момент - "master/slave". Мы осуществляем переход к нескольким "slave" с proxy балансировщиком нагрузки для режима "только для чтения".

Как организована балансировка нагрузки?

На программном уровне средствами nginx.

Какой framework / AJAX библиотеку вы используете?

Rails.

Какие средства распределенного управления задачами вы используете?

Starling

Как вы управляете рекламой в проекте?

Мы участвуем в нескольких рекламных сетях. Мы оцениваем эффективность каждой рекламной сети с помощью eCPM на уровне приложения.

Имеете ли вы стандартную API на вашем сайте?

Нет.

Сколько человек в вашей команде?

2 разработчика.

Какими наборами способностей обладают участники вашей команды?

Я: дизайн пользовательского интерфейса, разработка, ограниченные знания в Rails, оптимизация MySQL, развертывание Rails.

Alex: разработка логики приложения, дизайн пользовательского интерфейса, программная инженерия в целом.

Какие средства разработки вы используете?

Alex работает в OS X, а я предпочитаю Ubuntu. Для контроля за версиями используется SVN. В качестве текстового редактора я использую VIM, а Alex - TextMate.

Как проходит процесс разработки?

На логическом уровне все упирается в тесты, мы проводим их достаточно экстенсивно. На уровне приложения все ограничивается быстрыми итерациями и не менее быстры тестированием.

Какова ваша стратегия кэширования объектов и контента?

Мы используем memcached без TTL и просто вручную очищаем кэш при необходимости.

Как происходит кэширование на клиентской стороне?

Никак.

Как вы проверяете глобальную доступность и моделируете производительность для конечных пользователей?

Мы используем Pingdom для внешнего мониторинга за сайтом - они отлично справляются.

Как вы проверяете работоспособность ваших серверов и сетей?

На данный момент мы полагаемся на внешний мониторинг и ping мониторинг от Softlayer. В перспективе мы рассматриваем FiveRuns как возможное решение для мониторинга серверов.

Как вы строите на графиках или диаграммах сетевую и серверную статистику, а также тенденции?

Мы не занимаемся этим.

Как вы тестируете систему?

Сначала мы разворачиваем ее на тестовом сервере и проводим несколько тестов, после чего разворачиваем систему уже на серверах приложений.

Как вы анализируете производительность?

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

Как вы обеспечиваете безопасность?

Тщательно.

Как вы решаете какие возможности добавить или оставить?

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

Как вы реализуете веб-аналитику?

Мы используем собственную систему оценок для оптимизации вирусного эффекта, но помимо этого пользуемся и услугами Google Analytics.

Используете ли вы A/B тестирование?

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

Как вы выполняете резервное копирование и восстановление?

Мы используем LVM для создания ежедневных и еженедельных инкрементальных резервных копий.

Как выполняются обновления оборудования и программного обеспечения?

На данный момент мы делаем это вручную, за исключением развертывания Rails приложения. Для обновления и перезапуска серверов приложений мы используем Capistrano.

Как вы выполняете глобальные изменения в структуре базы данных при обновлениях?

Обычно мы начинаем переход с второстепенных серверах баз данных, а затем просто переключаем основные.

Каковы ваши планы насчет защиты от сбоев и развития бизнеса?

Не самым лучшим образом...

Есть ли у вас отдельная операционная команда, работающая над сайтом?

Было бы неплохо, но нет :)

Используете ли вы CDN? Если да, то какую и для каких целей?

Нет.

Как выглядит модель ваших доходов?

CPM: больше просмотров страниц - больше денег. Помимо этого у нас бывают прямые поощрительные предложения через нашу виртуальную валюту.

Как вы продвигаете ваш продукт?

Это же социальная сеть. Мы просто используем вирусный эффект для поддержания роста проекта.

Используете ли вы какие-либо особенно интересные технологии или алгоритмы?

Я думаю Ruby запросто мог бы подойти под это определение, но на самом деле нет - мы не проводим научных исследований, мы просто стараемся быть полезными для посетителей.

Храните ли вы изображения в базе данных?

Нет, это бы была не самая лучшая идея.

Как много работы над организацией взаимодействия с пользователями приходится выполнять?

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

Приходилось ли вам сталкиваться с какими-либо сюрпризами, положительными или отрицательными?

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

С другой стороны, было удивительно насколько далеко смогла наз завести архитектура с одним "master" и несколькими "slave" на самом обыкновенном оборудовании. Я думаю, что даже миллиард просмотров страниц в месяц достижим при таком подходе к базе данных.

Как ваша система эволюционирует для соответствия новым требованиям к масштабируемости?

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

Кем вы восхищаетесь?

Brad Fitzpatrick за изобретение memcache, а также каждым, кому успешно удалось горизонтально масштабировать свой проект.

Каковы ваши планы по изменению архитектуры в будущем?

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

Их мысли о вирусном эффекте Facebook

Facebook моделирует социальную сеть в цифровой форме максимально точно и полно, по крайней мере насколько это возможно.
Построение социальной сети более важно, чем возможности, предоставляемые пользователям.
Facebook позволяет быстро распространять новые приложения через социальную сеть.
Идея вашего приложения должна быть социальной, затягивающей и универсальной.
Социальный аспект является основой вирусного эффекта.
"Затягивание" пользователей позволяет зарабатывать на нем.
Универсальность дает необходимый потенциал.
Friends for Sale - социальный проект, так как предоставляет возможность торговать своей частью социального графа.
Он затягивает, так как в основе лежит в какой-то степени сумасшедшая идея, ненавязчивая, слегка флиртующая, и немного циничная.
Он универсальный, так как все люди в какой-то степени самовлюбленны, знают себе цену, и хотят флиртовать с "горячими" людьми.
Каждая часть приложения является потенциальной для вовлечения новых пользователей.
Каждый пользователь в среднем приводит 1.4 новых, что является залогом экспонентациального роста.
Для каждого нового пользователя отслеживается количество приглашений, нотификаций, записей на "стене", кликов в профиле и других факторов.
Для каждого канала поступления новых пользователей вычисляются проценты нажавших, успешно вовлеченных и выходов из проекта.

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

На Facebook требуется масштабирование с самого начала. Дорога до миллиона просмотров страниц в сутки заняла 4 недели.
Ruby on Rails может масштабироваться.
При правильном подходе к архитектуре может масштабироваться практически все что угодно, сосредоточтесь на этом.
Вам определенно нужна продуманная архитектура базы данных, качественный хостинг, а также правильно настроенное оборудование.
С использованием кэширования и современных серверов, может пройти достаточно длительный период времени до тех пор, пока понадобится использование баз данных с более сложной структурой, такой как сегментирование.
Социальная сеть - это реальность. Количество новых пользователей в хорошо реализованном Facebook приложении на самом деле ошеломляет.
Большая часть проблем с производительностью в итоге сводится к базе данных. Лишний раз обратите внимание на конфигурацию СУБД, запросы и использование индексов.
Люди до сих пор пользуются Vi!