Insight IT

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

Иван Блинков — Fri, 13 Apr 2012 20:11:00 +0400

Instagram - всего лишь iOS, а теперь и Android, приложение для обмена фотографиями с друзьями. Последнее время находится на слуху благодаря новости о покупке проекта Facebook'ом за кругленькую сумму. Недавно один из основателей проекта, Mike Krieger, выступил на конференции с докладом о техническом аспекте проекта, который я и хотел бы вкратце пересказать.

Статистика

Начало:

1 сервер слабее Macbook Pro
25к регистраций в первый день
2 разработчика

Сегодня:

40+ миллионов пользователей
100+ виртуальных серверов в EC2, в том числе:
Проект куплен Facebook за 1 млрд. долл
1 миллион регистраций за 12 часов после запуска Android-версии
5 разработчиков

Технологии

Ubuntu Linux 11.04 - основная операционная система
Python - основной язык программирования серверной части
Django - фреймворк
Amazon:
- EC2 - хостинг
- ELB - балансировка входящих HTTP-запросов
- Route53 - DNS
- S3 - хранение фотографий
- CloudFront - CDN
nginx - второй уровень балансировки входящихHTTP-запросов
gunicorn - WSGI-сервер
HAProxy - балансировка нагрузки внутри системы
PostgreSQL - основное хранилище данных
postgis - поддержка гео-запросов
pgfouine - отчеты на основе логов
pgbouncer - создание пула соединений
Redis - дополнительное хранилище данных
Memcached - кэширование
Gearman - очередь задач
Solr - гео-поиск
munin, statsd, pingdom - мониторинг
Fabric - управление кластером
xfs - файловая система

Философия

Простота
Минимизация операционных издержек
Использование подходящих инструментов

История

Забыли сделать favicon.ico до запуска - в первый же день логи пестрили ошибками 404
Для хранения данных использовали просто Django ORM и PostgreSQL (из-за postgis)
Начали с одного слабого сервера, после успешного запуска решили переехать на EC2
Довольно быстро пришлось вынести СУБД на отдельный сервер (виртуальный, естественно)
Количество фотографий продолжало расти и расти, даже самый большой инстанс EC2 не справлялся
Решили вертикально разделить данные на несколько баз, с использованием механизма routers из ORM, параллельно избавившись от внешних ключей
Через несколько месяцев суммарный размер базы данных перевалил за 60Гб и перестало справляться и это решение
Следующим шагом стало горизонтальное разбиение данных (sharding):
Создали несколько тысяч логических баз данных.
Распределили их по существенно меньшему количеству физических серверов (читай: виртуальных машин).
Написали свой механизм определения где искать какую базу данных, с поддержкой миграции (вероятно тоже на основе routers).
По последним данным под PostgreSQL используется 12+12 виртуальных машин с максимальной оперативной памятью (68.4Гб), а также сетевые диски EBS, объединенные в программный RAID посредством mdadm. Это необходимо, чтобы весь массив данных помещался в памяти, EBS не в состоянии обеспечить достаточную производительность.
С некоторыми задачами лучше справляется Redis:
Для каждого пользователя в Redis есть список идентификаторов новых фотографий от других пользователей, на которых он подписан.
При отображении потока новых для пользователя фотографий делается выборка части такого списка, после чего посредством multiget достается подробная о них информация из memcached.
Пробовали возложить на него задачу хранения списков подписчиков, но в итоге вернулись к решению на PostgreSQL с небольшим кэшированием.
В Redis также хранится информация о сессиях.
Несколько фактов о Redis:
- Так как все находится в памяти - очень быстрые операции записи и работы с множествами.
- Является не заменой, а дополнением к основному хранилищу данных.
- Redis хорош для структур данных, которые относительно ограничены.
- Отлично подходит для кэширования комплексных структур данных, где нужно большее, чем просто получить значение по ключу (например - счетчики, подмножества, проверка вхождения в множества).
- Механизм репликации (посредством slaveof) позволяет легко масштабировать операции чтения.
Пользователи синхронно загружают фотографии на медиа-сервер с (опциональными) заголовком и месте на карте, все остальное происходит асинхронно посредством очередей, например:
- Сохраняются гео-метки, обновляется Solr (который впоследствии заменил postgis).
- Идентификатор нового фото добавляется в обсуждавшиеся выше списки для всех подписчиков автора.
Поначалу использовали Apache + mod_wsgi для запуска Django, впоследствии перешли к gunicorn из-за меньшего потребления ресурсов и простоты настройки.
С недавних пор начали использовать Amazon ELB вместо DNS round-robin для первичной балансировки входяших HTTP-запросов, что позволило:
избежать необходимости дешифровки SSL посредством nginx;
ускорить исключение из балансировки проблемных серверов.
Благодаря использованию xfs есть возможность "замораживать" и "размораживать" дисковые массивы при резервном копировании.

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

Многие проблемы с масштабируемостью - результат банальных человеческих ошибок.
Масштабирование = замена всех деталей в машине на скорости 150 км/ч.
Заранее сложно узнать как в основном будут обращаться к данным, без реального использования.
В первую очередь попытайтесь адаптировать известные Вам технологии и инструменты для создания простого и понятного решения, прежде чем бросаться на поиски чего-то нетривиального.
Дополните свое основное хранилище более гибким компонентом, вроде Redis.
Постарайтесь не использовать два инструмента для решения одной и той же задачи.
Оставайтесь гибкими и ловкими = напоминайте себе о том, что на самом деле имеет значение.
Разрабатывайте решения, к которым не придется постоянно возвращаться из-за их сбоев.
Активное юнит- и функциональное тестирование стоят потраченного на них времени.
DRY: не делайте одну и ту же работу несколько раз.
Слабая связанность посредством уведомлений или сигналов позволяет легко менять структуру проекта.
Дисковый ввод-вывод часто оказывается узким местом, особенно на EC2.
Спускаться до C нужно только при необходимости, большую часть работы лучше делать в Python.
Короткий цикл разработки - залог быстрого развития.
Частые совместные рассмотрения кода нужны, чтобы все были в курсе происходящего.
Не изобретайте велосипед.
Окружите себя с толковыми консультантами.
Культура открытости вокруг разработки.
Делитесь с opensource сообществом.
Фокусируйтесь на том, что вы делаете лучше всего.
Вашим пользователям абсолютно без разницы, написали ли Вы собственную СУБД или нет.
Не переоптимизируйте и не предполагайте заранее как сайт будет расти.
Не рассчитывайте, что "кто-то еще присоединится к команде и разберется с этим".
Для социальных стартапов очень мало, или даже совсем нет, нерешимых вопросов, связанных с масштабируемостью.

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

Упоминавшаяся во вступлении неприлично длинная презентация из 185 слайдов:

На видео, к сожалению, это выступление не записывалось.

Часть информации взята из технического блога Instagram.

Аналитика в реальном времени от Facebook

Иван Блинков — Thu, 24 Mar 2011 19:14:00 +0300

HBase в Facebook завоевывает все более и более крепкие позиции, в прошлый раз я рассказывал о применении HBase в роли системы хранения данных для их новой системы обмена сообщений. Вторым продуктом, который теперь полноценно использует данную технологию, является система сбора и обработки статистики в реальном времени под названием Insights. Социальные кнопки (см. слева от поста) стали одним из основных источников трафика для многих сайтов, новая система аналитики позволит владельцам сайтов и страниц лучше понимать как пользователи взаимодействуют и оптимизировать свои интернет-ресурсы, основываясь на данных в реальном времени. Итак, 20 миллиардов событий в день (200 тысяч в секунду) с задержкой не более 30 секунд, как же можно этого достичь?

Цели сервиса

Дать пользователям надежные счетчики в реальном времени по ряду метрик
Предоставлять анонимные данных - нельзя узнать кто конкретно были эти люди
Продемонстрировать ценность социальных плагинов и виджетов. Что они дают сайту или бизнесу?
Концепция воронки: сколько людей увидело плагин, сколько совершило действие, сколько было привлечено пользователей обратно на интернет-ресурс
Сделать данные более оперативными: сокращение частоты обновлений с 48 часов до 30 секунд

Задачи

Множество типов метрик, более 100: показы, лайки, просмотры и клики в новостной ленте, демография и.т.д.
Большой поток данных: 20 миллиардов событий в день
Неравномерное распределение данных: за большинство контента практически не голосуют, но некоторые материалы набирают просто невероятное количество лайков

Неудавшиеся попытки

MySQL

В каждой строке идентификатор и значение счетчика
Привело к очень высокой активности в СУБД
Статистика считается за каждые сутки, создание новых счетчиков в полночь приводило к большому скачку операций записи
Пришлось пробовать искать способы решать проблему распределения счетчиков, пробовали учитывать временные зоны пользователей
Пики операций записи неминуемо вели к блокировкам
Решение оказалось не очень хорошо подходящим для данной конкретной задачи

Счетчики в памяти

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

MapReduce

Предыдущий вариант реализации был создан с помощью Hadoop + Hive
Подход гибкий, легко справляется с большим входящим потоком информации и объемами данным
Основной минус: даже близко не в реальном времени, слишком комплексная система

Cassandra

Вариант с Cassandra рассматривался, но так и не был реализован
Причины были опубликованы достаточно сомнительные: высокие требования к доступности данных и производительности записи
По всем данным у Cassandra нет абсолютно никаких проблем ни с одним, ни с другим

Победитель: HBase + Scribe + Ptail + Puma

В целом система, на которой остановился выбор, выглядит следующим образом:

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

Как обрабатывается один запрос:

Пользователь жмет на кнопку Like
Браузер инициирует AJAX запрос к серверу Facebook
Запрос записывается в лог в HDFS с помощью Scribe
Ptail - внутренний инструмент для чтения данных из нескольких Scribe-логов, на выходе данные разделяются на три потока, которые отправляются в разные кластеры в разных датацентрах:
- Просмотры плагинов и виджетов
- Просмотры в новостной ленте
- Действия (плагины + новостная лента)
Puma - механизм для пакетной записи данных в HBase для снижения влияния "горячих" материалов:
- HBase может справиться с очень большим потоком операций записи, но популярные материалы могут заставить упереться во ввод-вывод даже её
- В среднем пакет запросов собирается в течении 1.5 секунд, хотелось бы больше - но из-за огромного количества URL очень быстро заканчивается оперативная память
Отображение данных пользователю:
- Сам код для отображения написан на PHP
- Работа с HBase осуществляется из Java
- Для взаимодействия по традиции используется Thrift
Система кэширования используется для ускорения отображения страниц:
- Чем более старые данные запрашиваются, тем реже они пересчитываются
- Многое зависит от типа запрашиваемой статистики
MapReduce:
- Данные передаются для дальнейшего анализа с помощью Hive
- Сами логи удаляются через какой-то период времени
- Помимо этого старая система анализа статистики все еще в действии, она используется для регулярных проверок результатов новой системы, а также в роли запасного плана, если что-то пойдет не так

О проекте

Продолжительность 5 месяцев
2 с половиной разработчика самой системы
2 разработчика пользовательского интерфейса
Всего было задействовано около 14 человек, включая менеджмент, дизайнера и системных администраторов

Направления развития

Списки популярных материалов: при текущем подходе их составление является сложной задачей
Отдельные пользовательские счетчики
Обобщение приложения для использования с другими сервисами, а не только с социальными плагинами
Распределение системы на несколько датацентров

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

У новых систем аналитики и сообщений много общего: большой поток входящих данных для записи, HBase и требование работы в реальном времени. Facebook делает ставку на HBase, Hadoop и HDFS, не смотря на громоздкость системы, когда другие предпочитают Cassandra из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным - покажет время.

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

HBase в Facebook: 135 миллиардов сообщений в месяц

Иван Блинков — Thu, 10 Mar 2011 20:49:00 +0300

С тех пор, как я написал пост про Архитектуру Facebook, я как-то перестал активно следить за развитием событий и, как оказалось, зря. В Facebook ввели новый функционал "социального почтового ящика", агрегирующий входящие сообщения из электронной почты, мессенджеров, SMS и сообщений на сайте Facebook. Изначально они разрабатывали Cassandra именно для использования в этом проекте, но в итоге этот пост заняла достаточно противоречивая технология: HBase. HBase одержала вверх над Cassandra, MySQL и многими другими решениями. Как так получилось?

Используемая в Cassandra логика целостности данных оказалась не достаточно строгой для использования в этом продукте. В Facebook широко используется MySQL, но производительность существенно снижается с ростом массива данных и увеличением размеров индексов. Возможно они взялись бы за разработку нового решения для этой задачи, но их выбор пал на HBase.

HBase представляет собой горизонтально масштабируемую систему хранения таблиц, поддерживающую высокую частоту обновления строк в массивных наборах данных. Звучит как то что надо, для построения новой системы сообщений в Facebook. В основе модели данных HBase лежит концепция BigTable от Google, которая хорошо подходит для поиска строк по идентификаторам, фильтрации и сканированию наборов строк. Из слабых сторон можно назвать отсутствию поддержки сложных запросов, но этот факт компенсируется широким спектром инструментов по аналитике, в том числе и Hive, разработанном в самом Facebook для работы с их многопетабайтным хранилищем данных. Помимо прочего HBase основана на Apache Hadoop и HDFS, с которыми Facebook и так активно работает для анализа данных.

Это решение было принято не на пустом месте, а так как они отслеживали как используется данный функционал и пришли к выводу, что это то, что им нужно. Им нужна была система, справляющаяся с двумя типичными ситуациями:

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

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

HBase:

имеет более подходящую модель консистентности, чем Cassandra;
отлично масштабируется и показывает неплохую производительность при паттернах использования в FB;
имеет ряд преимуществ благодаря использованию HDFS для хранения данных: репликация, проверка целостности, автоматическая перебалансировка;
легко поддерживать в Facebook, так как их системные администраторы уже имеют большой опыт со смежными проектами - Hadoop и HDFS.

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

Для сбора сообщений из различных источников используется собственный сервер приложений.

Поиск новых пользователей основан на ZooKeeper.

Продукт тесно с другими сервисами Facebook для:

Проверка адресов электронной почты
Определения отношений дружбы
Настроек приватности
Решений о транспорте для отправки сообщения (e-mail, SMS, внутреннее сообщение)

Использование смежных проектов Hadoop и Hive стало одним из ключевых факторов, повлиявших на то, что эта технология прижилась как часть экосистемы в таком крупном проекте, как Facebook. Это идеальный сценарий для практически любого продукта: стать партнером успешного популярного продукта в надежде на то, что пользователь воспользуется обоими за компанию - именно по такому пути развивается HBase.

Хочется добавить пару слов от себя: я имел довольно приличный опыт работы с HBase в (уже) далеком 2008 году, на тот момент HBase был самым нестабильным из всех проектов, составляющих экосистему Hadoop. На бумаге HBase и правда выглядит идеальным решением для многих задач, но малейший сбой в метаданных делал всю базу данных неработоспособной, а таковое случалось достаточно часто, обычно по вине HDFS. В том проекте было убито массу времени на попытки "нормализовать" работу связки Hadoop+HBase, но в итоге от последней пришлось отказаться. Очень рад, что этот проект развивается такими семимильными шагами, задумка у проекта изначально была и правда очень стоящая. HBase буквально за пару лет стал пригоден для production использования, да еще и на таком масштабе. Пройдет еще год-другой, кардинально изменится архитектура Hadoop в лучшую сторону, и HBase наверняка станет лучшей из распределенных систем хранения структурированных данных, доступных на рынке. Если, конечно, Google к тому времени не успеет опубликовать в opensource её прародителя, BigTable :)

А Вы как относитесь к HBase? Использовали ли на практике? Какие впечатления?

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

Facebook за 20 минут

Иван Блинков — Sun, 20 Feb 2011 07:37:00 +0300

Facebook поделились новыми цифрами в конце прошлого года.

Что обычно происходит за 20 минут на Facebook?

Люди делятся миллионом ссылок
Отмечают друзей на 1323 тысячах фотографий
Приглашают 1 484 000 знакомых на мероприятиях
Отправляют 1 587 000 сообщений на стену
Пишут 1 851 000 новых статусов
2 миллиона пар людей становятся друзьями
Загружается 2.7 миллиона фотографий
Появляется 10.2 миллиона комментариев 10,208,000
Отправляется 4 632 000 личных сообщения

За 2010 год:

43 869 800 изменили свой статус на "не женат / не замужем"
3 025 791 изменили свой статус на "все сложно"
28 460 516 изменили свой статус на "есть парень / девушка"
5 974 574 изменили свой статус на "помолвлен"
36 774 801 изменили свой статус на "женат /замужем"

Хочется узнать больше? Прочитайте статью про архитектуру Facebook.

Социальная сеть

Иван Блинков — Wed, 27 Oct 2010 01:25:00 +0400

Как известно сегодня закончился второй день конференции HighLoad++, но речь сейчас пойдет не о ней. После мероприятия я почти совершенно случайно попал в кинотеатр на фильм "Социальная сеть" про создание Facebook, о котором как раз ходили какие-то непонятные слухи не то на хабре, не то еще где. Не знаю можно ли его сейчас посмотреть в свободном доступе, но в целом мне очень даже понравилось. Вообще из меня совсем никакой кинокритик, так что просто поделюсь чуть-чуть впечатлениями.

Основным сюжетом фильма является история о рождении находящегося у всех на слуху интернет-гиганта и сопутствующих этому конфликтов, соответственно тривиальности в нем мало, пересказывать естественно не буду. Честно говоря, я не сильно был знаком с этой истории до этого, так что не могу судить о правдивости, но даже если сюжет даже частично документален - уже здорово. В отличии от большинства американских комедий, юмор в фильме не тупой и правда улыбает довольно часто :) Качество съемки и игры актеров также на очень хорошем уровне, из минусов могу назвать разве что ахинею с технической точки зрения, которую иногда проскальзывала из уст Марка и иногда других персонажей. Помимо всего прочего фильм очень воодушевителен и поучителен для тех, кто планирует начать или только начал свой собственный интернет-проект: подталкивает к действию как-будто все возможно, но при этом показывает что легко не бывает и без конфликтов, ссор и переворотов с ног на голову бывает очень редко. В общем фильм определенно хорош и стоит того, чтобы хотябы разок посмотреть, рекомендую.

В целом я остался доволен, как предпремьерным показом, так и конференцией, особенно если учесть, что благодаря добрым людям попал и туда и туда бесплатно. Как многие уже наверное слышали, сегодня на HighLoad++ пожаловал Павел Дуров, что вызвало небольшой фурор у аудитории, в твиттере вроде даже писали, что это чуть ли не первое публичное выступление о том, как работает эта популярная социальная сеть. Не смотря на то, что технической информации он выдал не так много, как хотелось бы, я постараюсь в ближайшие несколько дней написать не только отчет по HighLoad++, но и пост под условным заголовком "Архитектура Вконтакте" - в комментариях к моим предыдущим постам читатели не раз интересовались именно этим интернет-проектом. Выступление снималось на видео, возможно скоро будет доступно в сети, хотя существенная часть инфы осталась за кадром "в кулуарах". До скорых встреч!

Facebook: how we scaled to 500 000 000 users by Robert Johnson

Иван Блинков — Sat, 23 Oct 2010 01:23:00 +0400

Буквально только что вернулся после насыщенного дня, большую часть которого я провел на RIW2010 (о котором я надеюсь успеть полноценно написать в воскресенье), а вечером я очень рад что собрался таки съездить на выступления Robert Johnson под названием "Facebook: how we scaled to 500 000 000 users" в ГУ-ВШЭ (где я собственно на данный момент и учусь в магистратуре). Сейчас же я хотел бы сосредоточиться именно на последнем мероприятии, благо оно мало того что было существенно более качественным, чем остальные выступления, на которых я был последнее время, так еще и очень сильно коррелирует как в целом с общей нитью данного блога, так и с последним постом в частности.

Прежде чем читать дальше, настоятельно рекомендую ознакомиться с архитектурой Facebook (которую я обновил немного), здесь я постараюсь особо не повторяться и рассказать лишь об общих впечатлениях и новых фактах, которые мне удалось услышать и выяснить.\

Само выступление длилось всего пол часа, было абсолютно без технических подробностей - немного понтов о своих достижениях в плане аудитории и нагрузки (собственно говоря первым слайдом был график роста аудитории по годам), а затем базовые вещи оb построении высоконагруженных систем в духе мол, что масштабироваться надо горизонтально, внимательно следить за SPOF, быстро двигаться вперед с использованием небольших итераций в разработке и.т.п. Аудитория слушала с очень напряженными лицами - для многих определенно было много незнакомых слов и вообще довольно суровое скороговорочное американское произношение мало кому давалось легко на слух.

Технических вопросов было довольно мало (что впрочем не удивительно, т.к. мероприятие проходило в гуманитарном ВУЗе) - превалировали вопросы в духе "что вы делаете с профилями умерших людей" (есть процедура когда друзья/родственники сообщают и если оказывается правдой то специальным образом перенастраивают аккаунт, чуть ли не несколько миллионов таких случаев было), "как работает фича Х" (из интересных фич - скрытие фоток твоих бывших boy/girl friend'ов через face recognition), "как выглядит типичный день разработчика в Facebook" (2/3 пишут код, остальное - всякие остальные виды деятельности), "какие планы развития в России и мире" или "что думаете о конкурентах" (их позиция - делать лучший продукт на рынке и аудитория сама подтянется), еще спрашивали снимался ли он в фильме, о котором последнее время в рунете слухи ходят. Недавно еще у них открылся небольшой венчурный фонд для инвестиций в социальные проекты. Вообще сессия публичных ответов-вопросов длилась около часа и потом еще где-то с полчаса он активно общался с людьми лично, тоже с ним поговорил немного. Под конец общение почти превратилось в фотосессию, я тоже вот решил за компанию сфотографироваться:

Пожалуй хватит воды, перейдем к делу, собственно что же нового для себя я узнал на мероприятии:

С примерно первой половины года их официальная активная аудитория повысилась с 400 до 500 миллионов человек
Штат инженеров (т.е. по-нашему разработчиков и сис. администраторов) увеличился до \~500 человек, примерно стало понятно как они распределены:
- Основной принцип: много небольших узкоспециализированных команд, которым даны полномочия принимать решения и проводить полностью продукт от стадии идеи до стадии реализации
- Около половины работают в "продуктовых" командах, до 5-10 человек в каждой (фотографии, поиск, личные сообщения, и.т.п.)
- Ряд команд, занимающихся общими вопросами (например 4 человека работают над оптимизацией MySQL, еще есть команды по безопасности, приватности, производительности)
- Нестрогий менеджмент, 2 уровня управления
Используются аппаратные балансировщики нагрузки от F5 + некое опенсорсное решение, сказал что возможно nginx, но он не уверен
Виртуализация совсем не используется - на таком масштабе она не актуальна
MySQL-сервера используют подключенные напрямую массивы дисков (direct attached storage)
По вопросам мониторинга кое-где используются nagios и ganglia, но большая часть данной подсистемы написано самостоятельно
Десятки тысяч серверов и десятки гигабит трафика, более точных цифр, к сожалению, не дали
Коммерческого программное обеспечение практически не используется, по большей части собственные разработки и в ключевых местах opensource
Сам спросил про датацентры:
- Santa Clara, California - master (названия мест плохо расслышал, поправьте если ошибаюсь)
- Ashburn, Virginia - read-only slave
- За пределами США присутствие очень небольшое, по паре стоек в нескольких странах - если я правильно понял, то для кэширования статики, т.е. своя CDN
Помимо этого мне было интересно про репликацию между ними:
- Используется модифицированный механизм встроенной репликации MySQL
- Основные доработки: передача помимо собственно данных списка идентификаторов объектов, которые следует инвалидировать из-за текущего обновления + какая-то хитрая система расстоновки флагов о текущем состоянии процесса репликации
DDoS их особо не волнует - сколько-либо серьезных попыток они не встречали, защита аппаратная на уровне ДЦ, как я понял
Намного больше внимания уделяется модерации контента и борьбе со спамом
Развертывание делается максимально плавно, как в плане обновления софта, так и в плане выкатывания новых версий кода сайта (упоминал в статье про архитектуру)
Их позиция касательно opensource:
- Активно использовать и возвращать взамен с улучшениями
- Facebook выгодно возвращать вносимые изменения в популярные opensource проекты, так как они не считают их конкурентным преимуществом (ну и лицензии никто не отменял)
- Если это не делается, то чаще всего т.к. либо используются "грязные хаки и костыли", которые никому кроме них не нужны, либо так как разработчикам не хватает времени привести патч в удобоваримый вид
- Свои проекта также активно публикуются, так как организации вроде Apache Software Foundation берут на себя многие вопросы по поддержке и развитию кода
Apache Hadoop как уже многие писали используется как хранилище и оффлайновый обработчик данных вроде логов, Hive родился как надстройка для упрощения доступа
Хоть сотрудники Facebook и реализовали проект Cassandra, про который активно спрашивали в комментариях как тут, так и на хабре, но они его практически не используют у себя. Как известно он опубликован в opensource и поддерживается ASF. В Facebook он используется (использовался?) только как хранилище для поиска по внутренним сообщениям, мотивация: очень быстрая запись, недостаточная производительность операций случайного чтения
На вопрос про основной дистрибутив линукс и вендоров оборудования он был не особо уверен, но сказал что скорее всего использутся CentOS и они работают с несколькими основными вендорами серверов (HP, IBM, Dell) - свое оборудование (как Google) они не изобретают, так как не считают целесообразным
Используется довольно сильно модифицированное ядро ОС, особенно по части сетевого стека

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

Иван Блинков — Wed, 20 Oct 2010 13:02:00 +0400

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

Платформа

Linux - операционная система
PHP с HipHop - код на PHP компилируется в C++
memcached - агрессивное кэширование объектов
MySQL - используется как хранилище пар ключ-значение, никаких join'ов
Thrift - интерфейс взаимодействия между сервисами, написанными на разных языках программирования
Scribe - универсальная система сбора и агрегации данных с рабочих серверов

Статистика

Более 500 миллионов активных пользователей (месячная аудитория)
Более миллиарда социальных связей
Более 200 миллиардов просмотров страниц в месяц
Более 4 триллионов действий попадает в новостные ленты каждый день
Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше
Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно
Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду
20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых
О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно
Более миллиарда сообщений в чате каждый день
Более ста миллионов поисковых запросов в день
Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect
Более 400 тысяч разработчиков сторонних приложений
Менее 500 разработчиков и системных администраторов в штате
Более миллиона активных пользователей на одного инженера
Десятки тысяч серверов, десятки гигабит трафика

Архитектура

Общие принципы

Балансировщик нагрузки выбирает веб-сервер для обработки запроса
PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:
- MySQL
- memcached
- Специализированные сервисы
Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
- Вер-приложение
- Распределенный индекс
- Постоянное хранилище
Использование открытых технологий там, где это возможно
Поиск возможностей оптимизации используемых продуктов
Философия Unix:
- Старайтесь делать каждый компонент системы простым и производительным
- Комбинируйте компоненты для решения задач
- Концентрируйте внимание на хорошо обозначенных точках взаимодействия
Все усилия направлены на масштабируемость
Попытки минимизации количества точек отказа
Простота, простота, простота!

PHP

Почему PHP?

Во многом "так исторически сложилось"
Хорошо подходит для веб-разработки
Легок в изучении: небольшой набор выражений и языковых конструкций
Легок в написании: нестрогая типизация и универсальный "массив"
Легок в чтении: синтаксис похож на C++ и Java
Прост в дебаггинге: нет необходимости в перекомпиляции
Большой ассортимент библиотек, актуальных для веб-проектов
Подходит для процесса разработки с короткими итерациями
Активное сообщество разработчиков по всему миру
Динамическая типизация, интерпретируемый язык для скриптов

Как оказалось на самом деле?

Высокий расход оперативной памяти и вычислительных ресурсов
Сложно работать, когда объем исходного кода очень велик: слабая типизация и ограниченные возможности для статичного анализа и оптимизации кода
Не особо оптимизирован для использования в крупных проектах
Линейный рост издержек при подключении файлов с исходным кодом
Механизм разработки расширений не очень удобен

Доработки:

Оптимизация байт-кода
Улучшения в APC (ленивая загрузка, оптимизация блокировок, "подогрев" кэша)
Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)
HipHop - трансформатор исходных кодов:
- Разработчики пишут на PHP, который конвертируется в оптимизированный C++
- Статический анализ, определение типов данных, генерация кода, и.т.д.
- Облегчает разработку расширений
- Существенно сокращает расходы оперативной памяти и вычислительных ресурсов
- У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка
- Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля

MySQL

Как используется MySQL?

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

Как оказалось на самом деле?

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

Доработки:

Практически никаких модификаций исходного кода MySQL
Своя схема партиционирования с глобально-уникальными идентификаторами
Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя
Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша
Библиотеки для доступа к данным на основе графа:
- Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)
- Реплицированные связи (ребра графа)
- Аналоги распределенных внешних ключей (foreign keys)
- Большинство данных распределено случайно

Memcache

Как используется memcached?

Высокопроизводительная распределенная хэш-таблица
Содержит "горячие" данные из MySQL
Снижает нагрузку на уровень баз данных
Основная форма кэширования
Используется более 25TB памяти на нескольких тысячах серверов
Среднее время отклика менее 250 микро-секунд
Кэшируются сериализованные структуры данных PHP
Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL - приходится делать это на уровне программного кода
Множество multi-get запросов для получения данных на другом конце ребер графа
Ограниченная модель данных, неэффективен для маленьких объектов

Доработки:

Порт на 64-битную архитектуру
Более эффективная сериализация
Многопоточность
Улучшенный протокол
Компрессия
Проксирование запросов
Доступ к memcache через UDP:
- уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений
- управление ходом исполнения приложение (оптимизация для multi-get)
Статистика о работе потоков по запросу - уменьшает блокировки
Ряд изменений в ядре Linux для оптимизации работы memcache:
- распределение управления сетевыми прерывания по всем ядрам
- оппортунистический опрос сетевых интерфейсов
После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений

Thrift

Что это?

Легкий механизм построения приложений с использованием нескольких языков программирования
Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.
Предоставляет язык описания интерфейсов, статический генератор кода
Поддерживаемые языки: C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell и многие другие
Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)
Протоколы: стандарты сериализации (бинарный, JSON)
Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные

Почему именно Thrift?

Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers - но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию
Он быстрый, очень быстрый
Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы
Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями
Общий инструментарий, знакомый всем разработчикам

Scribe

Что это?

Масштабированный распределенный механизм ведения логов
Перемещает данные с серверов в центральный репозиторий
Широкая сфера применения:
- Логи поисковых запросов
- Публикации в новостных лентах
- Данные по A/B тестированиям
Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных
Простая модель данных
Построен на основе Thrift

Хранение фотографий

Сначала сделали это просто:

Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
Загрузка с сервера: изображения отдаются из NFS через HTTP
NFS построена на коммерческих продуктах
Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
На самом деле оказалось, что:
- Файловые системы непригодны для работы с большим количеством небольших файлов
- Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
- Ограничивающим фактором является ввод-вывод, а не плотность хранения

Потом начали оптимизировать:

Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
Распределение их по CDN для уменьшения сетевых задержек
Возможно сделать еще лучше:
- Хранение изображений в больших бинарных файлах (blob)
- Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
- Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее "простого" подхода и в 3 раза эффективнее "оптимизированного"

Другие сервисы

SMC: консоль управления сервисами - централизованная конфигурация, определение на какой физической машине работает логический сервис
ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
И еще около 50 других сервисов...

Как это работает все вместе?

Новые альбомы друзей

Получаем профиль по идентификатору пользователя (скорее всего из кэша, но потенциально возможно обращение к базе данных)
Получаем список друзей (опять же на основе идентификатора пользователя из кэша или из базы данных в случае промаха)
Параллельно запрашиваем идентификаторы последних 10 альбомов для каждого из друзей (multi-get, каждый промах мимо кэша индивидуально вытаскивается из MySQL)
Параллельно получаем данные о всех альбомах (на основе идентификаторов альбомов из предыдущего шага)
Все данные получены, выполняем логику отрисовки конкретной страницы на PHP
Отправляем HTML в браузер, пользователь счастлив :)

Новостная лента

Поиск

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

LAMP не идеален

PHP+MySQL+Memcache решает большинство задач, но не может решить совсем все:
- PHP не может хранить состояния
- PHP не самый производительный язык
- Все данные находятся удаленно
Facebook разрабатывает собственные внутренние сервисы, чтобы:
- Располагать исполняемый код ближе к данным
- Скомпилированное окружение более эффективно
- Некоторая функциональность присутствует только в других языках программирования
Философия сервисов:
- Создание сервисов только при необходимости (минимизация издержек по развертке, поддержке и ведению отдельной кодовой базы; потенциальная дополнительная точка сбоя)
- Создание общего набора инструментов для создания сервисов (Thrift, Scribe, ODS, средства мониторинга и уведомлений)
- Использование правильных языка программирования, библиотек и инструментов для решения задачи
Возвращение инноваций общественности - важный аспект разработки в Facebook:
- Опубликованные свои проекты:
  - Thrift
  - Scribe
  - Tornado
  - Cassandra
  - Varnish
  - Hive
  - xhprof
- Доработки популярных решений:
  - PHP
  - MySQL
  - memcached
- Информация о взаимодействии Facebook с opensource-сообществом, этих и других проектах расположена на странице, посвященной opensource.
Ключевые моменты культуры разработки в Facebook:
- Двигайся быстро и не бойся ломать некоторые вещи
- Большое влияние маленьких команд
- Будь откровенным и инновационным

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

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

Очень рекомендую посмотреть материалы в оригинале, так как естественно я осветил в статье далеко не все, да и неточности какие-либо неисключены. Помимо этого возможно многим будет интересно мероприятие "Facebook: how we scaled to 500 000 000 users ", где Robert Johnson выступает 22 октября в Москве. Еще он числится в списке докладчиков Highload++ с аналогичным выступлением. Дополнительную информацию можно почерпнуть в блоге инженеров Facebook.

UPD: Обновил некоторые моменты после посещения вышеупомянутого выступления Роберта.

И по традиции напоминаю, что так как я пишу довольно редко - читать мой блог намного удобнее по RSS. Спасибо за внимание :)

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