Insight IT

Архитектура Twitter

Иван Блинков — Sat, 10 May 2008 12:36:00 +0400

Twitter стартовал как побочный подпроект, но не смотря на это темпы его роста были впечатляющими: путь от 0 до миллионов просмотров страниц занял всего несколько коротких месяцев. Ранние решения о проектировании системы неплохо справлялись с небольшими нагрузками, но они быстро таяли под напором огромного количества пользователей, желающих разослать весточки всем своим друзьям с ответом на простой вопрос: а чем ты занимаешься?

Поначалу все винили Ruby on Rails во всех проблемах с масштабированием, но Blaine Cook, главный архитектор Twitter, встал на его защиту:

Основной для нас на самом деле является проблема горизонтального масштабирования, с этой точки зрения Ruby on Rails ничем не хуже других языков программирования или framework'ов: переход на "более быстрый" язык программирования дал бы нам 10-20% прирост производительности, в то время архитектурные преобразования, легко реализованные средствами Ruby on Rails, сделали Twitter быстрее на 10000%.

Даже если Ruby on Rails оказался невиновен, как же тогда Twitter научился с его помощью рости до все больших и больших высот?

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

Этот текст является продолжением серии переводов, автор оригинала - Todd Hoff. На этот раз написать что-либо своими силами у меня не сложилось, все мысли ушли на другой пост, который я скоро опубликую, а перевод этот получился несколько менее строгим, чем обычно, но я думаю ничего страшного.

Scaling Twitter Video от Blaine Cook.
Scaling Twitter Slides
Good News блог пост от Rick Denatale
Scaling Twitter блог пост от Patrick Joyce
Twitter API Traffic is 10x Twitter’s Site
A Small Talk on Getting Big. Scaling a Rails App & all that Jazz

Платформа

Статистика

Более 350000 пользователей. Точная цифра, как обычно, держится в секрете.
Около 600 запросов в секунду.
В среднем система поддерживает 200-300 соединений в секунду. Максимум обычно достигается при значении 800.
MySQL обрабатывает примерно 2400 запросов в секунду.
180 экземпляров приложений на Rails, использующих Mongrel как веб-сервер.
1 MySQL сервер (одна большая машина с 8 ядрами) и 1 slave, используемый лишь для статистики и отчетов.
30+ процессов для выполнения произвольных работ.
8 Sun X4100
Обработка запроса обычно занимает у Rails 200 миллисекунд.
В среднем ответ на запрос к базе данных занимает 50-100 миллисекунд.
Более 16 GB выделено под memcached.

Архитектура

Проект столкнулся с массой проблем, связанных с масштабируемостью. Маленькая птичка частенько давала сбои.
Изначально не было реализовано никаких форм мониторинга, графиков или статистики, это очень затрудняло обнаружение м решение возникающих проблем. Впоследствии были внедрены Munin и Nagios. Разработчики столкнулись с некоторыми трудностями при использовании этих продуктов в Solaris. Помимо этого был использован сервис Google Analytics, но от него обычно мало толку, особенно когда страницы даже не загружаются.
Активное использование кэширования средствами memcached:
- Например, если подсчет количества чего-либо выполняется медленно, намного эффективнее один раз запомнить результат в memcached, чем каждый раз считать его заново.
- Получение информации о статусе своих друзей - непростая задача. Вместо использования запросов информация о статусе друзей обновляется в кэше. База данных совсем не используется. Такой подход позволяет получить предсказуемое время отклика (ограниченное сверху примерно 20 миллисекундами).
- Объекты ActiveRecord настолько велики, что кэширование их нецелесообразно. Критичные атрибуты хранятся в хэше, а остальная их часть подвергается "ленивой загрузке" в момент запроса на доступ.
- 90% запросов являются запросами к API. Таким образом кэширование страниц или их фрагментов становится бессмысленным, зато никто не мешает им кэшировать сами API запросы.
Внутренняя организация работы с сообщениями:
- Сообщения очень активно используются: производители генерируют сообщения, они образуются в очереди, а затем распространяются по потребителем.
- Основная функция Twitter заключается в реализации своеобразного моста между различными форматами электронных сообщений (SMS, электронная почта, сервисы мгновенного обмена сообщениями и так далее).
- Чтобы инвалидировать в кэше информацию можно просто отправить внутреннее сообщение, зачем выполнять все действия синхронно?
- Изначально этот механизм основывался на DRb (distributed Ruby) - библиотека, позволяющая отправлять и принимать сообщения сообщения между удаленными Ruby-объектами по TCP/IP. Но она была несколько странноватой, да и являлось потенциально слабым местом с точки зрения стабильности.
- Со временем сервис перевели на Rinda, представляющую собой набор общих для всей системы очередей. Но и у нее были недостатки: все очереди были постоянными, а данные терялись при сбоях.
- Следующей попыткой был Erlang. Но однажды возникла проблема: каким образом сломавшийся сервер может продолжать работать, но при этом в очереди откуда-то возникли целых 20000 ожидающих пользователей? Разработчики не знали. На лицо явный недостаток документации...
- В конце концов решение было разработано своими силами: Twitter выпустил Starling, распределенный легковесный сервер очередей, написанный на Ruby и поддерживающий протокол memcache. Сейчас серверная часть Twitter управляется именно им.
- Распределенные очереди позволяют переживать сбои путем записи их на диск в критических ситуациях. Другие крупные интернет-проекты также часто пользуются таким подходом.
Работа с SMS осуществляется с помощью сторонних сервисов и предоставляемых ими шлюзов. Достаточно дорогое удовольствие.
Развертывание:
- Просто запускаются дополнительные сервера с mongrel, более элегантного решения пока нет.
- Все внутренние ошибки выдаются пользователям, если обслуживающий их mongrel сервер на данный момент заменяется.
- Все сервера останавливаются одновременно. Отключение их по одному по определенным причинам не используется.
Неправильное использование сервиса:
- Много времени сервис был не доступен, так как люди проходились специальными программами по сайту с целью добавить всех кто попадался под руку в друзья. 9000 друзей за 24 часа. Это просто-напросто останавливало работу сайта.
- Были разработаны средства для своевременного обнаружения таких ситуаций.
- Будте беспощадными, таких пользователей нужно просто удалять.
Сегментирование:
- Пока оно только в планах, сейчас оно не используется.
- В будущем оно будет основываться на времени, а не на пользователях, так как запросы обычно очень локальны по времени.
- Сегментирование будет не так просто реализовать благодаря автоматическому запоминанию результатов выполнения функций для последующего повторного их использования. Никто не даст гарантии, что операции "только для чтения" на самом деле будут таковыми являться. Запись в slave, работающий в режиме read-only, - не самая лучшая идея.
API Twitter генерирует в 10 раз больше трафика, чем сам сайт.
- Их API - самая важная вещь из всех, что они разработали.
- Простота сервиса позволила разработчикам строить свои приложения поверх инфраструктуры Twitter, привнося все новые и новые идеи. Например, Twitterrific - красивый способ использовать Twitter в небольшой команде.
Мониторинг используется для остановки слишком больших процессов.

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

Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) - они сыграют свою роль и спасут работоспособность системы.
Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
Оптимизируйте базу данных:
- Индексируйте все таблицы, Rails не будет делать это за Вас.
- Используйте "explain" для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.
- Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.
- Избегайте комплексного объединения данных из нескольких таблиц.
- Избегайте сканирования больших наборов данных.
Кэшируйте все, что только можно.
Тестируйте все максимально тщательно:
- Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.
- Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.
Длительно функционирующие процессы стоит оформить в виде daemon'ов.
Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
Не делайте глупостей!
- Масштаб проект несколько меняет понятие "глупость".
- Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 - этот механизм прекрасно работал.
Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!

Архитектура 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!