Опыт роста Твиттера на ранней стандии довольно интересен, т.к. проект стартовал с простого прототипа и очень быстро столкнулся с большими трудностями при масштабировании.
Статистика
- 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’ах и т.п.
- Кэшируйте данные
- Как только Вы понимаете, что сайт стал медленным, включайте систему статистики/отчетов/графиков для выяснения причин, не угадывайте.
- Тестируйте все.
- Используйте уведомления об ошибках и исключениях, чтобы вовремя на них реагировать.
- Не делайте глупостей. Загрузка трех тысяч друзей в память может убить сервер, хотя с тремя все работает отлично.
- Большинство проблем с производительностью связано не с языком, а с архитектурой.