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

MollomMollom - это прибыльный 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, так как это начинало становиться узким местом. Минимизируйте простой от блокировок для достижения полного параллелизма.

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

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