Главная > Опыт > Twitter.com - архитектура и масштабирование

Twitter.com - архитектура и масштабирование

3 Декабрь 2009

В этой статье поговорим об одном из самых шумных и растущих проектов - Twitter.com (далее - Твиттер).

Разработка и развитие этого проекта совпадает с классической схемой удачного стартапа. Стартовал проект с простенького прототипа, написаного на скоркую руку на платформе Ruby-on-Rails. После этого в проекте было сделано огромное количество изменений в архитектурном и техническом плане. Твиттер не раз сталкивался и преодолевал проблемы быстрого роста нагрузки.

Разработчики Твиттера делятся своим опытом.

Статистика

600 запросов в секунду
200-300 соединений в секунду, доходит до 800 в пики
MySQL обрабатывает 2,400 запросов в секунду
180 Rails-инстанций
1 сервер MySQL (8-ядер) с репликацией на 1 слейв. Слейв используется только для статистики и отчетов
30+ процессов для обработки периодичных задач
8 серверов Sun X4100
Rails генерирует страницы за 200 мс
16 GB памяти для Memcached

Платформа и технологии

Ruby on Rails
Erlang
Mongrel
Munin
Nagios
Google Analytics
AWStats
Memcached

Архитектура и решения

Мониторинг

С самого начала на Твиттере небыло никаких инструментов для мониторинга и сбора статистики. При появлении первых проблем с производительностью первое, что они сделали - добавили такие инструменты. В качестве мониторинга был использован Nagios, в качестве инструмента по сбору статистики - Munin. Monit используется для отслеживания и “убивания” слишком “больших” процессов.

Кеширование

Кеширование всего, чего только можно:

Кешировать нужно максимум всего. В абсолютном большинстве случаев отдача из кеша намного быстрее, чем из СУБД.
Подогревание кеша. Например, получение статуса друга скрывает тяжелую логику (приватность, безопасность и другие моменты), что приводит к очень тяжелому запросу для выборки. Поэтому статус друга обновляется напрямую в кеше, практически никогда запрос не доходит до СУБД.
Объекты ActiveRecord очень большие, поэтому они не кешируются. Все данные кешируются в ассоциативном массиве, и достаются по мере надобности
90% всех запросов - запросы к API. Поэтому у них нет кеширования фрагментов страниц на фронтсерверах, но они кешируют API запросы

Системы очередей/сообщений

Использование систем/очередей сообщений повсеместно. Главная функциональная роль твиттера - это быть мостом между разными форматами (SMS, Web, IM и т.п.)
Например, для обновления кеша друга используется сообщение, которое передает эту работу в фон, вместо того, чтобы делать это синхронно.
Перепробовали множество очередей, остановились на Starling (система распределенных очередей на Ruby)

Пользователи

Существуют пользователи, которые ходят по страницам сайта и добавляют всех в друзья. Некоторые добавляют по 9000 друзей за сутки. Убийственно для производительности системы.
Используются инструменты (собственной разработки) для обнаружение таких проблем
Таких пользователей не жалеют - их удаляют

Партиционирование

Планируют партиционироваться, но пока этого не делают
Схему для партиционирования выберут временнУю. Делить по пользователям (точнее по идентификаторам пользователей) не правильно, т.к. многие запросы имеют временный характер

Уроки и выводы

Обращайтесь за помощью к сообществам, не пытайтесь спрятать и решить все проблемы сами. Вам помогут!
План масштабирования следует держать наравне с бизнес планом.
Разрабатывайте инструменты сами. Твиттер перепробовал множество решений, которые “почти работали”, но в итоге для многих вещей разработчикам пришлось делать собственные инструменты.
Встраивайте ограничения для пользователей. Люди будут пытаться (специально или нет) провалить Вашу систему. Делайте инструменты для обнаружения подобных аномалий.
Не делайте сами лишних проблем для СУБД. Не вся логика нуждается в гигантских JOIN’ах и т.п.
Кешируйте данные
Думайте над возможностью партиционирования приложения с самого начала, тогда у Вас будет возможность масштабировать его просто
Как только Вы понимаете, что сайт стал медленным, включайте систему статистики/отчетов/графиков для выяснения причин, не угадывайте
Оптимизируйте БД: индексируйте, пользуйтесь EXPLAIN-ом, денормализируйте, избегайте тяжелых объединений (JOIN-ы), избегайте сканирования больших объемов данных (FULL TABLE SCAN и т.п.)
Тестируйте все
Используйте уведомления об ошибках и исключениях, чтобы вовремя на них реагировать
Не делайте глупостей. Загрузка трех тысяч друзей в память может убить сервер, хотя с четырмя все работает отлично
Большинство проблем с производительностью связано не с языком, а с архитектурой