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Масштабируемость