[Хд] logo

Опыт Твиттера

Опыт роста Твиттера на ранней стандии довольно интересен, т.к. проект стартовал с простого прототипа и очень быстро столкнулся с большими трудностями при масштабировании.

Статистика

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

Подписывайтесь на отборные материалы по продвинутой разработке

Google Email

Esc, чтобы подписаться позже