Rails Scale: 1000 запросов в секунду Макс Лапшин [email protected] http://evilmartians.ru/

Задача:
оптимизация приложения вконтакте

30 тыс пользователей
до 9 секунд на запрос
5 серверов
надо опустить время ответа до 500 мс
Вводные

Более 2-х млн пользователей
25 мс на запрос
14 серверов
40K RPM и 20 млн записей в сутки
Результаты

Ежедневная смена требований
Экспоненциальный рост нагрузки
Поровну записи и чтения
Сделать быстро, дешево и приемлемо
С чем столкнулись

Что оказалось
важным в
нашем случае

Грамотный менеджер
«Щасспрошу» завалит проект
Персонал

Системный администратор.
Получше, чем «aptitude-джан»
Персонал

Наша команда злых марсиан!
http://evilmartians.ru/
Персонал

Волшебных гномиков нет.

Нет их даже в MongoDB и memcached

pgpool — master-master медленный
memcached — нечего кешировать
Сразу выкинули

Ruby on Rails — нужна гибкость
PostgreSQL — часто меняется схема
RabbitMQ — задержка записи
внешний инструментарий
Оставили

Что мы делали

Без него никуда
Догадки не работают
newrelic.com
Фоновые задачи очень важны
Профилирование

Место на дисках
Упавшие серверы
Длины очередей
Ночной дежурный (?)
Мониторинг

Нужны реляционные выборки
Часто меняются критерии
PostgreSQL быстр и удобен
Индексы — основной дисковый IO
SQL база

Много данных рядом — плохо
Нам повезло с логикой выборок
Шардинг: user_id % 100
Надо планировать заранее
Шардинг

Меньше всего проблем
Zero-downtime deploy с unicorn-ом
Плохая поддержка шардинга
Необходимость RabbitMQ
Ruby on Rails

Самая быстрая часть проекта
Оказался индикатором состояния
Мучительное восстановление
RabbitMQ