https://www.insight-it.ru/Wed, 02 Mar 2011 03:37:00 +0300https://www.insight-it.ru//highload/2011/arkhitektura-disqus/<p><img alt="DISQUS" class="left" src="https://www.insight-it.ru/images/disqus.jpg" title="DISQUS"/> <a href="https://www.insight-it.ru/goto/a754581e/" rel="nofollow" target="_blank" title="https://disqus.com">DISQUS</a> - самая популярная система комментирования и одновременно самое большое в мире Django-приложение. Она установлена более чем на полумиллионе сайтов и блогов, в том числе и очень крупных, таких как Engadget, CNN, MTV, IGN. Основной особенностью в её реализации является тот факт, что DISQUS не является тем сайтом, который хотят увидеть пользователи, он лишь предоставляет механизмы комментирования, авторизации и интеграции с социальными сетями. Пики нагрузки возникают одновременно c появлением какой-то шумихи в Интернете, что достаточно непредсказуемо. Как же им удается справляться с этой ситуацией?<!--more--></p> <h2 id="platforma">Платформа</h2> <ul> <li><a href="/tag/linux/">Linux</a> - операционная система</li> <li><a href="/tag/python/">Python</a> - язык программирования</li> <li><a href="/tag/django/">Django</a> - основной framework</li> <li><a href="/tag/apache/">Apache 2.2</a> +&nbsp;<a href="/tag/wsgi/">mod_wsgi</a> - веб-сервер</li> <li><a href="/tag/postgresql/">PostgreSQL</a> - СУБД</li> <li><a href="/tag/memcached/">memcached</a> - кэширование</li> <li><a href="/tag/haproxy/">HAProxy</a> - балансировка нагрузки</li> <li><a href="/tag/slony/">Slony</a> - репликация данных</li> <li><a href="/tag/heartbeat/">heartbeat</a> - обеспечение доступности</li> </ul> <h2 id="statistika">Статистика</h2> <ul> <li>До 17 тысяч запросов в секунду</li> <li>500 000 сайтов</li> <li>15 миллионов зарегистрированных пользователей</li> <li>75 миллионов комментариев</li> <li>250 миллионов посетителей (на август 2010г.)</li> </ul> <h2 id="osnovnye-trudnosti">Основные трудности</h2> <ul> <li>Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)</li> <li>Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)</li> <li>Нельзя угадать на каком сайте из тысяч возникнет пик трафика</li> <li>Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования</li> <li>Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)</li> </ul> <h2 id="arkhitektura">Архитектура</h2> <p><img alt="Архитектура DISQUS" class="responsive-img" src="https://www.insight-it.ru/images/disqus_architecture.jpeg" title="Архитектура DISQUS"/></p> <ul> <li><strong>Оборудование</strong>, в сумме около 100 серверов:<ul> <li>30% веб-серверов (Apache + <code>mod_wsgi</code>)</li> <li>10% серверов баз данных (PostgreSQL)</li> <li>25% кэш-серверов (memcached)</li> <li>20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)</li> <li>15% прочие сервера (Python скрипты)</li> </ul> </li> <li><strong>Балансировка нагрузки</strong>:<ul> <li>HAProxy:<ul> <li>Высокая производительность</li> <li>Интеллектуальная проверка доступности</li> <li>Неплохая статистика</li> </ul> </li> </ul> </li> <li><strong>Репликация</strong>:<ul> <li>Используется Slony-I</li> <li>Основана на триггерах</li> <li>Master/Slave для обеспечения большего объема операций чтения</li> </ul> </li> <li><strong>Высокая доступность</strong>:<ul> <li>heartbeat</li> <li>Пассивная копия мастер баз данных на случай сбоя основной</li> </ul> </li> <li><strong>Партиционирование</strong>:<ul> <li>Реализовано на уровне кода</li> <li>Простая реализация, быстрые положительные результаты</li> <li>Два метода разделения данных:<ul> <li><em>Вертикальное:</em><ul> <li>Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)</li> <li>Позволяет разделять базы данных</li> <li>Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)</li> <li>Бартер производительности на масштабируемость</li> <li>Более эффективное кэшировние</li> <li>Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал</li> </ul> </li> <li><em>Горизонтальное:</em><ul> <li>Некоторые сайты имеют очень большие массивы данных</li> <li>Партнеры требуют повышенного уровня доступности</li> <li>Помогает снижать загрузку по записи на мастер базе данных</li> <li>В основном используется все же вертикальное партиционирование</li> </ul> </li> </ul> </li> </ul> </li> <li><strong>Производительность базы данных</strong>:<ul> <li>Особое внимание уделяется тому, чтобы индексы помещались в оперативную память</li> <li>Логирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)</li> <li>Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)</li> <li>Оптимизация QuerySet'ов:<ul> <li>Не используется чистый SQL</li> <li>Встроенный кэш позволяет выделять части выборки</li> <li>Но это не всегда нужно, они убрали этот кэш</li> </ul> </li> <li>Атомарные операции:<ul> <li>Поддерживают консистентность данных</li> <li>Использование update(), так как save() не является thread-safe</li> <li>Отлично работают для таких вещей, как счетчики</li> </ul> </li> <li>Транзакции:<ul> <li>TransactionMiddleware поначалу использовалось, но со временем стало обузой</li> <li>В <code>postgrrsql_psycopg2</code> есть опция autocommit:<ul> <li>Это означает что каждый запрос выполняется в отдельной транзакции</li> <li>Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию</li> <li>Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в случае ошибки)</li> <li>В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости переключаются в транзакционный режим</li> </ul> </li> </ul> </li> </ul> </li> <li><strong>Отложенные сигналы</strong>:<ul> <li>Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)</li> <li>Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)</li> <li>Модели отправляются в очередь в сериализованном виде</li> </ul> </li> <li><strong>Кэширование</strong>:<ul> <li>Используется memcached</li> <li>Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)</li> <li>Настраиваемые алгоритмы поведения клиента</li> <li>Используется <code>_auto_reject_hosts</code> и <code>_retry_timeout</code> для предотвращения повторных подключений к вышедшим из строя кэш-серверам</li> <li>Алгоритм размещения ключей: консистентное хэширование на основе libketama</li> <li>Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:<ul> <li>Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно</li> <li>В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш</li> <li>django-newcache и MintCache умеют это делать</li> <li>Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы</li> </ul> </li> </ul> </li> <li><strong>Мониторинг</strong>:<ul> <li>Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware</li> <li>Сбор и отображение с помощью Ganglia</li> </ul> </li> <li><strong>Отключение функционала</strong>:<ul> <li>Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось</li> <li>Система должна срабатывать мгновенно, по всем серверам, без записи на диск</li> <li>Позволяет запускать новые возможности постепенно, лишь для части аудитории</li> <li>Позволяет постоянно использовать основную ветку кода</li> <li>Аналогичная система используется и в <a href="/tag/facebook/">Facebook</a></li> </ul> </li> <li><strong>Масштабирование команды разработчиков</strong>:<ul> <li>Небольшая команда</li> <li>Месячная аудитория / количество разработчиков = 40 миллионов</li> <li>Это означает:<ul> <li>Автоматическое тестирование</li> <li>И максимально простой процесс разработки</li> </ul> </li> <li>Новый сотрудник может начать работать уже через несколько минут, нужно лишь:<ul> <li>Установить и настроить PostgreSQL</li> <li>Скачать исходный код из <a href="/tag/git/">git</a></li> <li>С помощью pip и virtualenv установить зависимости</li> <li>Изменить настройки в settings.py</li> <li>Выполнить автоматическое создание структуры данных средствами Django</li> </ul> </li> </ul> </li> <li><strong>Непрерывное тестирование</strong>:<ul> <li>Ежедневное развертывание с помощью <a href="/tag/fabric/">Fabric</a></li> <li><a href="/tag/hudson/">Hudson</a> обеспечивает регулярно осуществляет и тестирует сборки</li> <li>Интегрирован <a href="/tag/selenium/">Selenium</a></li> <li>Быстрое тестирование с помощью <a href="/tag/pyflakes/">Pyflakes</a> и post-commit hooks</li> <li>70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут</li> <li>Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью</li> </ul> </li> <li><strong>Отслеживание проблем и задач</strong>:<ul> <li>Переключились с Trac на Redmine (из-за поддержки под-задач)</li> <li>Отправка исключений на e-mail - плохая идея</li> <li>Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием <a href="https://www.insight-it.ru/goto/2e33ac0/" rel="nofollow" target="_blank" title="https://github.com/dcramer/django-sentry">Sentry</a></li> </ul> </li> </ul> <h2 id="delaem-vyvody">Делаем выводы</h2> <ul> <li>Язык программирования, каким бы он ни был, не является проблемой</li> <li>Django в целом очень хорош (но приходится все же использовать набор собственных патчей)</li> <li>Даже при использовании низкопроизводительного framework можно построить масштабируемую систему</li> <li>Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости</li> <li>Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования</li> <li>Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои</li> </ul> <h2 id="istochnik-informatsii">Источник информации</h2> <p>Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:</p> <div class="video-container no-controls"> <iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/key/21F2PzBmYATx2Y" width="425"> </iframe> </div> <p><em>Другие статьи по масштабируемости высоконагруженных систем можно почитать <a href="https://www.insight-it.ru/highload/">в соответствующем разделе</a>, а вовремя узнавать о новых - <a href="/feed/">подписавшись на RSS</a>. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать :)</em></p>Иван БлинковWed, 02 Mar 2011 03:37:00 +0300tag:www.insight-it.ru,2011-03-02:highload/2011/arkhitektura-disqus/ApacheDISQUSdjangoFabricGangliaGitHAProxyheartbeatHudsonLinuxMemcachedpgbouncerpgFouinePostgreSQLPyflakesPythonSeleniumSlonysyslog-ngWSGIАрхитектура DISQUSМасштабируемостьhttps://www.insight-it.ru//highload/2011/arkhitektura-mollom/<p><img alt="Mollom" class="right" src="https://www.insight-it.ru/images/mollom-logo.jpg" title="Mollom"/> <a href="https://www.insight-it.ru/goto/aa3c2fd2/" rel="nofollow" target="_blank" title="http://mollom.com/">Mollom</a> - это прибыльный SaaS сервис по фильтрации различных форм спама из контента, сгенерированного пользователями: комментариев, постов на форумах и блогах, опросов, контактных и регистрационных форм. Определение спама основано не только на контенте, но и репутации и прошлой активности разместившего его пользователя. Алгоритм машинного обучения Mollom выполняет роль цифрового модератора 24х7 для более 40 тысяч сайтов, в том числе и очень крупных компаний.</p> <p>С того момента, как Mollom запустили систему анализа цифрового контента, они выявили более 373 миллионов спам сообщений, обнаружив в процессе что впечатляющие 90% всех прошедших через них сообщений оказались спамом. Весь этот поток спама в 100 сообщений в секунду обрабатывается всего двумя географически распределенными серверами. На каждом из них работает сервер Java-приложений и Cassandra. Так мало ресурсов требуется лишь из-за того, что они создали очень эффективную систему машинного обучения. Разве не круто? Так как же они это делают?<!--more--></p> <h2 id="statistika">Статистика</h2> <ul> <li>Обслуживаются 40000 активных веб-сайтов, многие их которых принадлежат крупным клиентам, таким как Adobe, Sony BMG, Warner Brothers, Fox News и The Economist. Много крупных брендов, с крупными сайтами, масса комментариев.</li> <li>Обнаруживают пол-миллиона спам-сообщений ежедневно.</li> <li>Обрабатывается около 100 запросов к API в секунду.</li> <li>Проверка сообщения на спам занимает очень мало времени, обычно около 30-50 миллисекунд, 95% запросов укладывается в 250 миллисекунд, когда самые медленные обрабатываются пол секунды.</li> <li>Эффективность определения спама составляет 99.95%. Это означает, что из 10000 спам-сообщений Mollom пропустит только 5.</li> <li><a href="https://www.insight-it.ru/goto/82e0a09b/" rel="nofollow" target="_blank" title="http://mollom.com/blog/netlog-using-mollom">Netlog</a>, европейская социальная сеть, имеет отдельный Mollom-сервер в своем датацентре. Netlog проверяют на спам около 4 миллионов сообщений каждый день на классификаторах, специально натренированных на их данных.</li> </ul> <h2 id="platforma">Платформа</h2> <ul> <li><a href="/tag/java/">Java</a> - исторически сложилось, что Mollom был с самого начала был разработан на Java.</li> <li>Два сервера обслуживают основную часть клиентов:<ul> <li>Один сервер на восточном побережье США, другой - на западном</li> <li>В случае сбоя один сервер может полностью подменить другой</li> <li>Конфигурация обоих: Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 диска по 300 GB, RAID 10.</li> </ul> </li> <li><a href="https://www.insight-it.ru/goto/ad66f2bf/" rel="nofollow" target="_blank" title="http://www.softlayer.com/">SoftLayer</a> - хостинг-провайдер.</li> <li><a href="https://www.insight-it.ru/goto/baf11ec8/" rel="nofollow" target="_blank" title="http://cassandra.apache.org/">Cassandra</a> - NoSQL база данных, выбранная из-за высокой производительности на запись и способности работать на серверах, располагающихся в разных датацентрах (была разработана в&nbsp;<a href="https://www.insight-it.ru/highload/2010/arkhitektura-facebook/">Facebook</a>, но там практически не используется).</li> <li><a href="https://www.insight-it.ru/goto/dce103e6/" rel="nofollow" target="_blank" title="http://www.mysql.com/">MySQL</a> - Java Persistence API используется для обычных наборов данных, когда Cassandra используется для больших объемов данных.</li> <li><a href="https://www.insight-it.ru/goto/2b056aff/" rel="nofollow" target="_blank" title="http://en.wikipedia.org/wiki/GlassFish">Glassfish</a> - open source сервер приложений для платформы Java EE. Они выбрали именно Glassfish за его возможности корпоративного уровня, такие как репликация и обработка сбоев.</li> <li><a href="https://www.insight-it.ru/goto/cc84f430/" rel="nofollow" target="_blank" title="http://hudson-ci.org/">Hudson</a> - предоставляет непрерывное тестирование и развертывание кода серверной части на всех используемых машинах.</li> <li><a href="https://www.insight-it.ru/goto/f94e85c8/" rel="nofollow" target="_blank" title="http://munin-monitoring.org/">Munin</a> - измерение и построение графиков, касающихся здоровья серверов.</li> <li><a href="https://www.insight-it.ru/goto/cfd5a6c7/" rel="nofollow" target="_blank" title="http://www.pingdom.com/">Pingdom</a> - внешний мониторинг.</li> <li><a href="https://www.insight-it.ru/goto/acf8f59d/" rel="nofollow" target="_blank" title="http://www.zendesk.com/">Zendesk</a> - используется для оказания поддержки клиентам.</li> <li><a href="https://www.insight-it.ru/goto/17f204ac/" rel="nofollow" target="_blank" title="http://drupal.org/">Drupal</a> - используется для основного сайта со специализированным модулем интернет-магазина.</li> <li><a href="https://www.insight-it.ru/goto/a81d9bb9/" rel="nofollow" target="_blank" title="http://unfuddle.com/">Unfuddle</a> - хостинг Subversion для взаимодействия удаленной команды разработчиков.</li> </ul> <h2 id="kak-eto-rabotaet">Как это работает?</h2> <p>Процесс выглядит следующим образом:</p> <ul> <li>Когда пользователь отправляет комментарий на сайт, происходит запрос к API Mollom.</li> <li>Контент анализируется, если он оказывается спамом, то сайту сообщается, что необходимо его заблокировать, если же алгоритм не уверен на 100% - сайту советуют показать CAPTCHA, которую сервис также предоставляет.</li> <li>После того, как CAPTCHA будет успешно заполнена, контент принимается. В большинстве случаев пользователи не будут ее видеть и контент будет приниматься сразу же.</li> </ul> <p>Обнаружение спама является сложным балансом между отказом нормальному контенту и принятию спама.</p> <h2 id="biznes-model">Бизнес-модель</h2> <ul> <li>Основным залогом популярности Mollom является бесплатная возможность попробовать сервис, ограничение составляет 100 нормальных (не спам) сообщений в день. Небольшие сайты могут никогда и не достичь этого ограничения.</li> <li>Далее есть два тарифа: 1 евро в день и 3600 евро с возможностями вполне соответствующими этим суммам</li> <li>Сайты, использующие бесплатный тариф, вовсе не зря тратят ресурсы системы, как кажется на первый взгляд, а являются жизненно-важным источником данных для тренировки системы. Без этих данных алгоритмы были бы существенно менее точны.</li> </ul> <h2 id="arkhitektura">Архитектура</h2> <ul> <li>Разработчики Mollom уделяют максимум внимания времени отклика, эффективности кода и использования серверных ресурсов.</li> <li>Физически каждый сервер может справиться со всеми запросами, два сервера нужны для избежания перерывов в работе системы. Когда оба сервера в строю - работа распределяется между ними, когда один падает - второй перехватывает его запросы.</li> <li> <p>Mollom прошел через несколько этапов развития:</p> <ol> <li>Изначально маленькая команда из двух человек работала вечерами над основными алгоритмами, классификаторами и реальными бизнес-задачами, которые они пытались решить. Для построения инфраструктуры серверной части они использовали свои реализации базовых механизмов по управлению ресурсами, соединениями и потоками. В итоге они обнаружили, что тратят слишком много времени на эти вещи. После этого они переключились на Glassfish, что позволило им намного меньше беспокоится об управлении памятью, REST-запросах, парсинге XML и поддержании пула соединений с базой данных.</li> <li>В прошлом основной проблемой была пропускная способность дисковой подсистемы. Они должны хранить информацию о репутации всех IP-адресов и URL по всему Интернету, что привело к массивному набору данных с большим количеством случайных обращений.</li> <li>Поначалу они использовали MySQL на недорогой виртуальной машине, что в итоге не смогло масштабироваться.</li> <li>Они перенесли данные на твердотельные жесткие диски (SSD) и стали все хранить в файлах. Этот шаг решил проблемы с записью, но возникли новые проблемы:<ol> <li>Это правда дорого.</li> <li>Очень чувствительно к типу используемой файловой системы</li> <li>Запись стала происходить быстрой, но итерация по большим наборам данным (что они делали довольно часто для очистки данных и обучения классификаторов) по-прежнему была очень медленным процессом.</li> </ol> </li> <li>В итоге они отказались от твердотельных накопителей и стали использовать Cassandra.</li> </ol> </li> <li> <p>Cassandra сейчас используется для обработки интенсивного потока запросов на запись и в роли кэша:</p> <ul> <li>Работает на RAID10, что хорошо подходит для высоких смешанных нагрузок на запись/чтение.</li> <li>Cassandra оптимизирована для записи, а в Mollom запись как раз происходит намного чаще, чем чтение.</li> <li>Разработана для распределенной работы как внутри датацентра, так и между датацентрами.</li> <li>Обратной стороной медали является отсутствие стандартного NoSQL интерфейса, что усложняет реализацию приложений.</li> <li>Механизм кэширования строк в Cassandra позволяет им не использовать отдельную систему для кэширования, что существенно упростило код приложения.</li> <li>Cassandra имеет функцию удаления устаревшей информации после определенного периода времени. В Европе существуют строгие законы о приватности личных данных, согласно которым они должны храниться не более определенного срока (штаб-квартира Mollom находится в Бельгии). В этом плане эта функция очень удобна. Эта функция опять же избавляет от необходимости реализовывать данный функционал вручную.</li> </ul> </li> <li>Типичный путь одного комментария внутри системы:<ul> <li>Балансировка нагрузки между серверами лежит на клиентской библиотеке, в роли типичного клиента может выступать сайт на Drupal, осуществляющий запрос к API через XML-RPC или REST.</li> <li>Запросы обрабатываются сервером приложений Glassfish и проходят стандартный процесс обработки с помощью сервлетов и специфичных классов.</li> <li>Платящие клиенты обслуживаются в первую очередь, что приводит к тому, что клиенты на бесплатном тарифе могут ожидать результата несколько дольше.</li> <li>Запрос анализируется и оценка вероятности спама возвращается пользователю. Помимо этого отдельная часть кода Mollom отвечает за генерацию, выдачу и проверку CAPTCHA.</li> <li>Классификаторы полностью располагаются в оперативной памяти. Небольшой кусок контента разбивается на тысячи и тысячи крошечных частей, которые могут быть идентифицированы как спам. Такие классификаторы хранят в памяти до нескольких миллионов признаков, характерных для спама. Анализ должен выполняться очень быстро, так что никаких других вариантов кроме расположения всех требуемых данных в оперативной памяти просто не было.</li> <li>В Cassandra хранятся очки репутации, частоты, URL и IP-адреса.</li> <li>Струтуры данных в памяти не реплицируются напрямую. Они записываются в Cassandra, которая и передает их на второй сервер. Промежуток времени, когда данные не консистентны, очень невелик, так что это не сказывается негативно на алгоритмах.</li> </ul> </li> <li>Балансировка нагрузки с помощью клиента:<ul> <li>Mollom использует такой подход к балансировке, так как стартап не может себе позволить дорогой железный балансировщик нагрузки. Если учесть, что им нужна балансировка между датацентрами, решение от любого из вендоров было бы комплексным и дорогим.</li> <li>У каждого клиента есть индивидуальный список серверов, которыми он может воспользоваться. Этот список изменяется через API.</li> <li>Каждый клиент может использовать разный список, платящим клиентам могут предоставлять отдельные сервера для уменьшения задержек.</li> <li>Если сервер упал - клиент пытается подключиться к следующему серверу в списке.</li> <li>С другой стороны такой подход усложняет разработку неофициальных клиентов: авторам проекта приходится тесно работать с разработчиками сторонних клиентов для обеспечения правильной реализации в них балансировки нагрузки.</li> </ul> </li> <li>Машинное обучение:<ul> <li>Mollom - это набор самообучающихся систем. Отдельные CAPTCHA-решения, не учитывают ни пользовательское поведение, ни источник контента, заставляя каждого пользователя вводить проверочный код при каждом сообщении. В случае с Mollom это происходит только когда система анализа контента не уверена в конкретном решении.</li> <li>Средняя длина сообщения - 500 символов, обычно оно разбивается на 3000 характеристик. Принадлежность контента к спаму определяется путем оценки репутации IP адреса или Open ID, пользовательского идентификатора, эмоциональной окраски, языка, профанации, проверки на наличие специфичных слов и фраз, также учитывается качество написания текста и многие другие факторы. Все эти данные основываются на классификаторах. Некоторые из них статистические по природе, так что обучение происходит автоматически. Другие же основываются на правилах для того, чтобы быть уверенными, что они никогда не могут быть настроены неверно. Комбинация результатов всех тестов после нормализации и образует финальный рейтинг принадлежности к спаму каждого конкретного сообщения.</li> <li>Классификаторы и внутренние метрики обучаются с каждым новым сообщением и обновляются в реальном времени.</li> </ul> </li> <li>Glassfish берет на себя планировку нагрузки, учитывая многоядерность системы:<ul> <li>Ключ к дизайну системы в многопроцессорном окружении заключается в максимальном параллелизации работы при минимальном простое из-за блокировок.</li> <li>Они используют 16 thread'ов на сервер.</li> <li>Большинство запросов обрабатываются сессионными объектами (Java Bean), не имеющими состояний. Они хорошо подходят для управления параллельными запросами.</li> <li>Они держат пул из нескольких сессионных объектов, но определение их количества делегируется Glassfish. В пиковую нагрузку это число увеличивается для более эффективной обработки запросов, порой оно достигает 32.</li> <li>Все классификаторы реализованы как раз как такие объекты, повторно использующиеся различными thread'ами.</li> <li>У каждого объекта есть свое клиентское соединение с Cassandra, чтобы гарантировать отсутствие блокировок.</li> <li>Когда пользователь не отвечает на CAPTCHA сессия очищается и Mollom узнает что это скорее всего был спам.</li> <li>На каждом сервере запущено по одной копии каждого классификатора.</li> <li>В момент очистки сессии происходит небольшая блокировка, когда происходит обновление классификаторов.</li> <li>Обновленные классификаторы записываются в Cassandra каждые пол часа.</li> </ul> </li> <li>Интеграция приложений:<ul> <li>Mollom использует открытый API, который может быть интегрирован в любую систему.</li> <li>Библиотеки: Java, PHP, Ruby и другие.</li> <li>Готовые модули: Drupal, Joomla, Wordpress и прочие системы управления контентом.</li> <li>Решения от сторонних разработчиков, основанные на примерах кода от &nbsp;Mollom.</li> </ul> </li> <li>Для мониторинга здоровья серверов они используют Munin:<ul> <li>Каков размер heap памяти после сбора мусора?</li> <li>Каково количество доступных соединений?</li> <li>Каково количество thread'ов в пуле?</li> <li>Оценка времени блокировок в каждом thread'е.</li> </ul> </li> <li>Если взглянуть в целом на архитектуру Mollom, можно увидеть, что они стараются построить систему, способную прозрачно работать в нескольких датацентрах, чтобы позволить горизонтально расширить систему, когда они перерастут текущую двухсерверную конфигурацию:<ul> <li>Балансировка нагрузки на клиенте позволяет выбирать оптимальный сервер и справляться со сбоями одного из них.</li> <li>Кластеризация Glassfish облегчает добавление/удаление новых машин и позволяет перехватывать запросы, когда один из серверов выходит из строя.</li> <li>Cassandra используется для управления данными между серверами в нескольких датацентрах.</li> </ul> </li> <li>Инсталляция Mollom в Netlog обладает некоторыми интересными характеристиками. Она обрабатывает больше сообщений, чем основные сервера Mollom, но распределение спама в ней совершенно другое, так как люди в ней общаются в рамках социальной сети. Внутри Netlog лишь 10% сообщений является спамом, когда в суровом мире информационных порталов распределение обратно. Интересным следствием является тот факт, что обработка нормальных сообщений требует меньше вычислительных ресурсов, так что на аналогичном оборудовании удается обрабатывать больший поток сообщений.</li> <li>Изначально они думали о виртуализированных серверах, в частности об Amazon EC2, но в итоге обнаружилось, что наиболее узким местом являются операции ввода-вывода - низкая производительность дисковой подсистемы в виртуальных машинах создавали реальные проблемы, так что они решили воспользоваться вертикальным масштабированием и переехали на более дорогие физические машины с большим объемом дискового пространства:<ul> <li>На удивление они не упираются в вычислительные ресурсы: лишь два ядра из 8 занимаются вычислениями, когда остальные же работают над операциями ввода-вывода.</li> <li>Трафик Mollom практически постоянен, так что физические сервера более эффективны с финансовой точки зрения. Они рассматривают Amazon лишь как запасной вариант для обработки непредвиденных пиков нагрузки.</li> </ul> </li> <li>Процесс разработки:<ul> <li>Команда распределена: трое в Бельгии, остальные в Техасе, Бостоне и Германии.</li> <li>Scrum используется в процессе разработки и они довольны этой методологией. Scrum-собрание проходит через Skype в два часа дня по Бельгии.</li> <li>Разработчики работают локально и отправляют код на Unfuddle.</li> <li>Hudson используется для непрерывного интеграционного тестирования.&nbsp;Hudson позволил облегчить миграцию, так как перед развертыванием все тесты должны быть пройдены. Они не теряли лишнего времени на проблемах, обнаруженных уже в развернутом приложении.</li> <li>Они активно используют автоматическое тестирование: юнит-тесты, системные тесты, тесты Drupal.</li> <li>Развертывание по-прежнему делается вручную для минимизации риска простоя (что правда спорный момент).</li> <li>Для обнаружения утечек памяти они используют анализ дампов оперативной памяти. Анализ дампа сервера с 16Гб памяти - дело непростое, практически невозможное на обычном компьютере, так что они арендуют большую виртуальную машину на Amazon для проведения анализа. Весь процесс занимает всего около 2 часов. Они сравнивают два дампа: через 10 и 20 часов после запуска сервера. Если обнаруживаются значительные отличия, то скорее всего дело в утечке памяти.</li> </ul> </li> </ul> <h2 id="puti-razvitiia">Пути развития</h2> <ul> <li>Mollom API основано на XML-RPC, REST-интерфейс находится на стадии тестирования для облегчения интеграции других сервисов.</li> <li>Они мигрировали на Cassandra, чтобы облегчить процесс горизонтального масштабирования, когда нагрузка достигнет соответствующего уровня.</li> <li>Скоро будут выпущены корпоративные возможности, которые позволят работать с сотнями сайтов как с единым целым. Появится возможность легко модерировать несколько сайтов одновременно по эмоциональной окраске сообщений, рейтингу спама или удалить все сообщения с определенного IP-адреса.</li> <li>Они думали над участием в бизнесе потоковых данных вроде Twitter, но они сильно ограничены европейскими более строгими требованиями по приватности.</li> <li>Планируются эксперименты по использованию Glassfish для балансировки нагрузки в рамках каждого датацентра.</li> <li>Если нагрузка увеличится десятикратно им придется добавить больше серверов в Cassandra. Дисковый ввод-вывод является узким местом. Дополнительные сервера приложения понадобятся только если нагрузка вырастет более, чем на порядок.</li> </ul> <h2 id="podvodim-itogi">Подводим итоги</h2> <ul> <li><strong>Mollom очень серьезно относится к разработке&nbsp;высокопроизводительной системы.</strong> Они гордятся тем, что Mollom очень эффективно использует вычислительные и финансовые ресурсы. Множество запросов может обрабатываться одним сервером с низкой задержкой, что очень радует как клиентов, так и владельцев проекта, так как издержки очень низки. Этот вопрос был выбран приоритетным с самого начала и они выбрали подходящие технологии для реализации своих целей. Это позволило им вкладывать средства в маркетинг, построить базу клиентов и создавать новые продукты на основе Mollom.</li> <li><strong>Машинное обучение требует много исходных данных&nbsp;для успешного обнаружение спама.</strong> Для сбора этих данных предлагает бесплатные услуги. Крупные клиенты обеспечивают доход и получают выгоду от данных, полученных от более мелких клиентов. Эта модель очень хорошо себя проявила в машинном обучении, за которым как известно будущее.</li> <li><strong>Старайтесь избавиться от проблем, не связанных напрямую с продуктом.</strong> Большие системы требуют серьезных усилий на разработку инфраструктуры. Можно убить все время на построение&nbsp;инфраструктуры, вместо создания по-настоящему ценного продукта (классификаторов, системы репутации, клиентских библиотек). Mollom постоянно пытались максимально избавляться от лишних проблем, именно по-этому они выбрали Cassandra и Glassfish.</li> <li><strong>Будьте осторожны с клиентским кодом.</strong> Выполнение кода на клиентской части привлекательно тем, что он тратит чужие ресурсы, а не серверные. Проблемы начинаются когда сторонние библиотеки разрабатываются некачественно, что заставляет систему в целом работать плохо. Плотно работайте с разработчиками клиентских библиотек для повышения качества их продукции.</li> <li><strong>Отдавайте приоритет платящим клиентам.</strong> Платящие клиенты получают более высокое качество услуг, обрабатываются вне очереди, получают меньше задержек и получают доступ к запасному серверу когда основной дал сбой. Этого вполне достаточно, чтобы подтолкнуть клиентов платить.</li> <li><strong>Уменьшайте объем кода, позволяя используемым сторонним продуктам брать на себя грязную работу</strong>.&nbsp;Поначалу код Mollom был существенно большим по объему, чем сейчас. Использование Cassandra и Glassfish позволило убрать массу кода, связанного с кэшированием, кластеризацией, репликацией и обработкой сбоев. Упрощайте систему со временем.</li> <li><strong>Минимизируйте блокировки.</strong> Mollom потратили много времени на устранение блокировок внутри Glassfish, так как это начинало становиться узким местом. Минимизируйте простой от блокировок для достижения полного параллелизма.</li> </ul> <h2 id="istochniki-informatsii-i-dopolnitelnye-materialy">Источники информации и дополнительные материалы</h2> <ul> <li><a href="https://www.insight-it.ru/goto/796d6b53/" rel="nofollow" target="_blank" title="http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html">Mollom Architecture - Killing Over 373 Million Spams At 100 Request Per Second</a> (основной источник информации)</li> <li><a href="https://www.insight-it.ru/goto/a695ef0e/" rel="nofollow" target="_blank" title="http://mollom.com/files/mollom-technical-whitepaper.pdf">Mollom Technical Whitepaper</a></li> <li><a href="https://www.insight-it.ru/goto/23d06e29/" rel="nofollow" target="_blank" title="http://blogs.sun.com/glassfishpodcast/entry/episode_072_mollom_com_s">Episode #072 - Mollom.com's GlassFish backend with Dries and Johan</a></li> <li><a href="https://www.insight-it.ru/goto/c1eeadac/" rel="nofollow" target="_blank" title="http://buytaert.net/mollom-gets-a-new-backend">Mollom gets a new backend</a></li> <li><a href="https://www.insight-it.ru/goto/fd87538b/" rel="nofollow" target="_blank" title="http://blogs.lodgon.com/johan/">Fighting spam with Mollom on Glassfish</a></li> <li><a href="https://www.insight-it.ru/goto/9c3dc3c9/" rel="nofollow" target="_blank" title="http://mollom.com/api">Mollom API</a></li> </ul> <p><strong><em>Если Вам понравилась данная статья, можете ознакомиться с другими <a href="https://www.insight-it.ru/highload/">материалами по архитектуре высоконагруженных систем</a> и <a href="/feed/">подписаться на RSS</a>.</em></strong></p>Иван БлинковTue, 15 Feb 2011 19:19:00 +0300tag:www.insight-it.ru,2011-02-15:highload/2011/arkhitektura-mollom/CassandraDrupalGlassfishHudsonIntelJavaMollomMuninMySQLPingdomsaasSoftLayerUnfuddleXeonZendeskАрхитектура Mollom