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.

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

Иван Блинков — Tue, 15 Feb 2011 19:19:00 +0300

Mollom - это прибыльный SaaS сервис по фильтрации различных форм спама из контента, сгенерированного пользователями: комментариев, постов на форумах и блогах, опросов, контактных и регистрационных форм. Определение спама основано не только на контенте, но и репутации и прошлой активности разместившего его пользователя. Алгоритм машинного обучения Mollom выполняет роль цифрового модератора 24х7 для более 40 тысяч сайтов, в том числе и очень крупных компаний.

С того момента, как Mollom запустили систему анализа цифрового контента, они выявили более 373 миллионов спам сообщений, обнаружив в процессе что впечатляющие 90% всех прошедших через них сообщений оказались спамом. Весь этот поток спама в 100 сообщений в секунду обрабатывается всего двумя географически распределенными серверами. На каждом из них работает сервер Java-приложений и Cassandra. Так мало ресурсов требуется лишь из-за того, что они создали очень эффективную систему машинного обучения. Разве не круто? Так как же они это делают?

Статистика

Обслуживаются 40000 активных веб-сайтов, многие их которых принадлежат крупным клиентам, таким как Adobe, Sony BMG, Warner Brothers, Fox News и The Economist. Много крупных брендов, с крупными сайтами, масса комментариев.
Обнаруживают пол-миллиона спам-сообщений ежедневно.
Обрабатывается около 100 запросов к API в секунду.
Проверка сообщения на спам занимает очень мало времени, обычно около 30-50 миллисекунд, 95% запросов укладывается в 250 миллисекунд, когда самые медленные обрабатываются пол секунды.
Эффективность определения спама составляет 99.95%. Это означает, что из 10000 спам-сообщений Mollom пропустит только 5.
Netlog, европейская социальная сеть, имеет отдельный Mollom-сервер в своем датацентре. Netlog проверяют на спам около 4 миллионов сообщений каждый день на классификаторах, специально натренированных на их данных.

Платформа

Java - исторически сложилось, что Mollom был с самого начала был разработан на Java.
Два сервера обслуживают основную часть клиентов:
- Один сервер на восточном побережье США, другой - на западном
- В случае сбоя один сервер может полностью подменить другой
- Конфигурация обоих: Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 диска по 300 GB, RAID 10.
SoftLayer - хостинг-провайдер.
Cassandra - NoSQL база данных, выбранная из-за высокой производительности на запись и способности работать на серверах, располагающихся в разных датацентрах (была разработана в Facebook, но там практически не используется).
MySQL - Java Persistence API используется для обычных наборов данных, когда Cassandra используется для больших объемов данных.
Glassfish - open source сервер приложений для платформы Java EE. Они выбрали именно Glassfish за его возможности корпоративного уровня, такие как репликация и обработка сбоев.
Hudson - предоставляет непрерывное тестирование и развертывание кода серверной части на всех используемых машинах.
Munin - измерение и построение графиков, касающихся здоровья серверов.
Pingdom - внешний мониторинг.
Zendesk - используется для оказания поддержки клиентам.
Drupal - используется для основного сайта со специализированным модулем интернет-магазина.
Unfuddle - хостинг Subversion для взаимодействия удаленной команды разработчиков.

Как это работает?

Процесс выглядит следующим образом:

Когда пользователь отправляет комментарий на сайт, происходит запрос к API Mollom.
Контент анализируется, если он оказывается спамом, то сайту сообщается, что необходимо его заблокировать, если же алгоритм не уверен на 100% - сайту советуют показать CAPTCHA, которую сервис также предоставляет.
После того, как CAPTCHA будет успешно заполнена, контент принимается. В большинстве случаев пользователи не будут ее видеть и контент будет приниматься сразу же.

Обнаружение спама является сложным балансом между отказом нормальному контенту и принятию спама.

Бизнес-модель

Основным залогом популярности Mollom является бесплатная возможность попробовать сервис, ограничение составляет 100 нормальных (не спам) сообщений в день. Небольшие сайты могут никогда и не достичь этого ограничения.
Далее есть два тарифа: 1 евро в день и 3600 евро с возможностями вполне соответствующими этим суммам
Сайты, использующие бесплатный тариф, вовсе не зря тратят ресурсы системы, как кажется на первый взгляд, а являются жизненно-важным источником данных для тренировки системы. Без этих данных алгоритмы были бы существенно менее точны.

Архитектура

Разработчики Mollom уделяют максимум внимания времени отклика, эффективности кода и использования серверных ресурсов.
Физически каждый сервер может справиться со всеми запросами, два сервера нужны для избежания перерывов в работе системы. Когда оба сервера в строю - работа распределяется между ними, когда один падает - второй перехватывает его запросы.
Mollom прошел через несколько этапов развития:
1. Изначально маленькая команда из двух человек работала вечерами над основными алгоритмами, классификаторами и реальными бизнес-задачами, которые они пытались решить. Для построения инфраструктуры серверной части они использовали свои реализации базовых механизмов по управлению ресурсами, соединениями и потоками. В итоге они обнаружили, что тратят слишком много времени на эти вещи. После этого они переключились на Glassfish, что позволило им намного меньше беспокоится об управлении памятью, REST-запросах, парсинге XML и поддержании пула соединений с базой данных.
2. В прошлом основной проблемой была пропускная способность дисковой подсистемы. Они должны хранить информацию о репутации всех IP-адресов и URL по всему Интернету, что привело к массивному набору данных с большим количеством случайных обращений.
3. Поначалу они использовали MySQL на недорогой виртуальной машине, что в итоге не смогло масштабироваться.
4. Они перенесли данные на твердотельные жесткие диски (SSD) и стали все хранить в файлах. Этот шаг решил проблемы с записью, но возникли новые проблемы:
  1. Это правда дорого.
  2. Очень чувствительно к типу используемой файловой системы
  3. Запись стала происходить быстрой, но итерация по большим наборам данным (что они делали довольно часто для очистки данных и обучения классификаторов) по-прежнему была очень медленным процессом.
5. В итоге они отказались от твердотельных накопителей и стали использовать Cassandra.
Cassandra сейчас используется для обработки интенсивного потока запросов на запись и в роли кэша:
- Работает на RAID10, что хорошо подходит для высоких смешанных нагрузок на запись/чтение.
- Cassandra оптимизирована для записи, а в Mollom запись как раз происходит намного чаще, чем чтение.
- Разработана для распределенной работы как внутри датацентра, так и между датацентрами.
- Обратной стороной медали является отсутствие стандартного NoSQL интерфейса, что усложняет реализацию приложений.
- Механизм кэширования строк в Cassandra позволяет им не использовать отдельную систему для кэширования, что существенно упростило код приложения.
- Cassandra имеет функцию удаления устаревшей информации после определенного периода времени. В Европе существуют строгие законы о приватности личных данных, согласно которым они должны храниться не более определенного срока (штаб-квартира Mollom находится в Бельгии). В этом плане эта функция очень удобна. Эта функция опять же избавляет от необходимости реализовывать данный функционал вручную.
Типичный путь одного комментария внутри системы:
- Балансировка нагрузки между серверами лежит на клиентской библиотеке, в роли типичного клиента может выступать сайт на Drupal, осуществляющий запрос к API через XML-RPC или REST.
- Запросы обрабатываются сервером приложений Glassfish и проходят стандартный процесс обработки с помощью сервлетов и специфичных классов.
- Платящие клиенты обслуживаются в первую очередь, что приводит к тому, что клиенты на бесплатном тарифе могут ожидать результата несколько дольше.
- Запрос анализируется и оценка вероятности спама возвращается пользователю. Помимо этого отдельная часть кода Mollom отвечает за генерацию, выдачу и проверку CAPTCHA.
- Классификаторы полностью располагаются в оперативной памяти. Небольшой кусок контента разбивается на тысячи и тысячи крошечных частей, которые могут быть идентифицированы как спам. Такие классификаторы хранят в памяти до нескольких миллионов признаков, характерных для спама. Анализ должен выполняться очень быстро, так что никаких других вариантов кроме расположения всех требуемых данных в оперативной памяти просто не было.
- В Cassandra хранятся очки репутации, частоты, URL и IP-адреса.
- Струтуры данных в памяти не реплицируются напрямую. Они записываются в Cassandra, которая и передает их на второй сервер. Промежуток времени, когда данные не консистентны, очень невелик, так что это не сказывается негативно на алгоритмах.
Балансировка нагрузки с помощью клиента:
- Mollom использует такой подход к балансировке, так как стартап не может себе позволить дорогой железный балансировщик нагрузки. Если учесть, что им нужна балансировка между датацентрами, решение от любого из вендоров было бы комплексным и дорогим.
- У каждого клиента есть индивидуальный список серверов, которыми он может воспользоваться. Этот список изменяется через API.
- Каждый клиент может использовать разный список, платящим клиентам могут предоставлять отдельные сервера для уменьшения задержек.
- Если сервер упал - клиент пытается подключиться к следующему серверу в списке.
- С другой стороны такой подход усложняет разработку неофициальных клиентов: авторам проекта приходится тесно работать с разработчиками сторонних клиентов для обеспечения правильной реализации в них балансировки нагрузки.
Машинное обучение:
- Mollom - это набор самообучающихся систем. Отдельные CAPTCHA-решения, не учитывают ни пользовательское поведение, ни источник контента, заставляя каждого пользователя вводить проверочный код при каждом сообщении. В случае с Mollom это происходит только когда система анализа контента не уверена в конкретном решении.
- Средняя длина сообщения - 500 символов, обычно оно разбивается на 3000 характеристик. Принадлежность контента к спаму определяется путем оценки репутации IP адреса или Open ID, пользовательского идентификатора, эмоциональной окраски, языка, профанации, проверки на наличие специфичных слов и фраз, также учитывается качество написания текста и многие другие факторы. Все эти данные основываются на классификаторах. Некоторые из них статистические по природе, так что обучение происходит автоматически. Другие же основываются на правилах для того, чтобы быть уверенными, что они никогда не могут быть настроены неверно. Комбинация результатов всех тестов после нормализации и образует финальный рейтинг принадлежности к спаму каждого конкретного сообщения.
- Классификаторы и внутренние метрики обучаются с каждым новым сообщением и обновляются в реальном времени.
Glassfish берет на себя планировку нагрузки, учитывая многоядерность системы:
- Ключ к дизайну системы в многопроцессорном окружении заключается в максимальном параллелизации работы при минимальном простое из-за блокировок.
- Они используют 16 thread'ов на сервер.
- Большинство запросов обрабатываются сессионными объектами (Java Bean), не имеющими состояний. Они хорошо подходят для управления параллельными запросами.
- Они держат пул из нескольких сессионных объектов, но определение их количества делегируется Glassfish. В пиковую нагрузку это число увеличивается для более эффективной обработки запросов, порой оно достигает 32.
- Все классификаторы реализованы как раз как такие объекты, повторно использующиеся различными thread'ами.
- У каждого объекта есть свое клиентское соединение с Cassandra, чтобы гарантировать отсутствие блокировок.
- Когда пользователь не отвечает на CAPTCHA сессия очищается и Mollom узнает что это скорее всего был спам.
- На каждом сервере запущено по одной копии каждого классификатора.
- В момент очистки сессии происходит небольшая блокировка, когда происходит обновление классификаторов.
- Обновленные классификаторы записываются в Cassandra каждые пол часа.
Интеграция приложений:
- Mollom использует открытый API, который может быть интегрирован в любую систему.
- Библиотеки: Java, PHP, Ruby и другие.
- Готовые модули: Drupal, Joomla, Wordpress и прочие системы управления контентом.
- Решения от сторонних разработчиков, основанные на примерах кода от Mollom.
Для мониторинга здоровья серверов они используют Munin:
- Каков размер heap памяти после сбора мусора?
- Каково количество доступных соединений?
- Каково количество thread'ов в пуле?
- Оценка времени блокировок в каждом thread'е.
Если взглянуть в целом на архитектуру Mollom, можно увидеть, что они стараются построить систему, способную прозрачно работать в нескольких датацентрах, чтобы позволить горизонтально расширить систему, когда они перерастут текущую двухсерверную конфигурацию:
- Балансировка нагрузки на клиенте позволяет выбирать оптимальный сервер и справляться со сбоями одного из них.
- Кластеризация Glassfish облегчает добавление/удаление новых машин и позволяет перехватывать запросы, когда один из серверов выходит из строя.
- Cassandra используется для управления данными между серверами в нескольких датацентрах.
Инсталляция Mollom в Netlog обладает некоторыми интересными характеристиками. Она обрабатывает больше сообщений, чем основные сервера Mollom, но распределение спама в ней совершенно другое, так как люди в ней общаются в рамках социальной сети. Внутри Netlog лишь 10% сообщений является спамом, когда в суровом мире информационных порталов распределение обратно. Интересным следствием является тот факт, что обработка нормальных сообщений требует меньше вычислительных ресурсов, так что на аналогичном оборудовании удается обрабатывать больший поток сообщений.
Изначально они думали о виртуализированных серверах, в частности об Amazon EC2, но в итоге обнаружилось, что наиболее узким местом являются операции ввода-вывода - низкая производительность дисковой подсистемы в виртуальных машинах создавали реальные проблемы, так что они решили воспользоваться вертикальным масштабированием и переехали на более дорогие физические машины с большим объемом дискового пространства:
- На удивление они не упираются в вычислительные ресурсы: лишь два ядра из 8 занимаются вычислениями, когда остальные же работают над операциями ввода-вывода.
- Трафик Mollom практически постоянен, так что физические сервера более эффективны с финансовой точки зрения. Они рассматривают Amazon лишь как запасной вариант для обработки непредвиденных пиков нагрузки.
Процесс разработки:
- Команда распределена: трое в Бельгии, остальные в Техасе, Бостоне и Германии.
- Scrum используется в процессе разработки и они довольны этой методологией. Scrum-собрание проходит через Skype в два часа дня по Бельгии.
- Разработчики работают локально и отправляют код на Unfuddle.
- Hudson используется для непрерывного интеграционного тестирования. Hudson позволил облегчить миграцию, так как перед развертыванием все тесты должны быть пройдены. Они не теряли лишнего времени на проблемах, обнаруженных уже в развернутом приложении.
- Они активно используют автоматическое тестирование: юнит-тесты, системные тесты, тесты Drupal.
- Развертывание по-прежнему делается вручную для минимизации риска простоя (что правда спорный момент).
- Для обнаружения утечек памяти они используют анализ дампов оперативной памяти. Анализ дампа сервера с 16Гб памяти - дело непростое, практически невозможное на обычном компьютере, так что они арендуют большую виртуальную машину на Amazon для проведения анализа. Весь процесс занимает всего около 2 часов. Они сравнивают два дампа: через 10 и 20 часов после запуска сервера. Если обнаруживаются значительные отличия, то скорее всего дело в утечке памяти.

Пути развития

Mollom API основано на XML-RPC, REST-интерфейс находится на стадии тестирования для облегчения интеграции других сервисов.
Они мигрировали на Cassandra, чтобы облегчить процесс горизонтального масштабирования, когда нагрузка достигнет соответствующего уровня.
Скоро будут выпущены корпоративные возможности, которые позволят работать с сотнями сайтов как с единым целым. Появится возможность легко модерировать несколько сайтов одновременно по эмоциональной окраске сообщений, рейтингу спама или удалить все сообщения с определенного IP-адреса.
Они думали над участием в бизнесе потоковых данных вроде Twitter, но они сильно ограничены европейскими более строгими требованиями по приватности.
Планируются эксперименты по использованию Glassfish для балансировки нагрузки в рамках каждого датацентра.
Если нагрузка увеличится десятикратно им придется добавить больше серверов в Cassandra. Дисковый ввод-вывод является узким местом. Дополнительные сервера приложения понадобятся только если нагрузка вырастет более, чем на порядок.

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

Mollom очень серьезно относится к разработке высокопроизводительной системы. Они гордятся тем, что Mollom очень эффективно использует вычислительные и финансовые ресурсы. Множество запросов может обрабатываться одним сервером с низкой задержкой, что очень радует как клиентов, так и владельцев проекта, так как издержки очень низки. Этот вопрос был выбран приоритетным с самого начала и они выбрали подходящие технологии для реализации своих целей. Это позволило им вкладывать средства в маркетинг, построить базу клиентов и создавать новые продукты на основе Mollom.
Машинное обучение требует много исходных данных для успешного обнаружение спама. Для сбора этих данных предлагает бесплатные услуги. Крупные клиенты обеспечивают доход и получают выгоду от данных, полученных от более мелких клиентов. Эта модель очень хорошо себя проявила в машинном обучении, за которым как известно будущее.
Старайтесь избавиться от проблем, не связанных напрямую с продуктом. Большие системы требуют серьезных усилий на разработку инфраструктуры. Можно убить все время на построение инфраструктуры, вместо создания по-настоящему ценного продукта (классификаторов, системы репутации, клиентских библиотек). Mollom постоянно пытались максимально избавляться от лишних проблем, именно по-этому они выбрали Cassandra и Glassfish.
Будьте осторожны с клиентским кодом. Выполнение кода на клиентской части привлекательно тем, что он тратит чужие ресурсы, а не серверные. Проблемы начинаются когда сторонние библиотеки разрабатываются некачественно, что заставляет систему в целом работать плохо. Плотно работайте с разработчиками клиентских библиотек для повышения качества их продукции.
Отдавайте приоритет платящим клиентам. Платящие клиенты получают более высокое качество услуг, обрабатываются вне очереди, получают меньше задержек и получают доступ к запасному серверу когда основной дал сбой. Этого вполне достаточно, чтобы подтолкнуть клиентов платить.
Уменьшайте объем кода, позволяя используемым сторонним продуктам брать на себя грязную работу. Поначалу код Mollom был существенно большим по объему, чем сейчас. Использование Cassandra и Glassfish позволило убрать массу кода, связанного с кэшированием, кластеризацией, репликацией и обработкой сбоев. Упрощайте систему со временем.
Минимизируйте блокировки. Mollom потратили много времени на устранение блокировок внутри Glassfish, так как это начинало становиться узким местом. Минимизируйте простой от блокировок для достижения полного параллелизма.

Источники информации и дополнительные материалы

Mollom Architecture - Killing Over 373 Million Spams At 100 Request Per Second (основной источник информации)
Mollom Technical Whitepaper
Episode #072 - Mollom.com's GlassFish backend with Dries and Johan
Mollom gets a new backend
Fighting spam with Mollom on Glassfish
Mollom API

Если Вам понравилась данная статья, можете ознакомиться с другими материалами по архитектуре высоконагруженных систем и подписаться на RSS.

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

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

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

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

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

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

Статистика

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

Platform

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

Архитектура

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

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

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

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

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