Слайд 2Задача:
оптимизация приложения вконтакте
Слайд 330 тыс пользователей
до 9 секунд на запрос
5 серверов
надо опустить время ответа до
Слайд 4Более 2-х млн пользователей
25 мс на запрос
14 серверов
40K RPM и 20 млн
записей в сутки
Результаты
Слайд 5Ежедневная смена требований
Экспоненциальный рост нагрузки
Поровну записи и чтения
Сделать быстро, дешево и приемлемо
С
чем столкнулись
Слайд 6Что оказалось
важным в
нашем случае
Слайд 7Грамотный менеджер
«Щасспрошу» завалит проект
Персонал
Слайд 8Системный администратор.
Получше, чем «aptitude-джан»
Персонал
Слайд 9Наша команда злых марсиан!
http://evilmartians.ru/
Персонал
Слайд 11Нет их даже в MongoDB и memcached
Слайд 12pgpool — master-master медленный
memcached — нечего кешировать
Сразу выкинули
Слайд 13Ruby on Rails — нужна гибкость
PostgreSQL — часто меняется схема
RabbitMQ — задержка записи
внешний инструментарий
Оставили
Слайд 15Без него никуда
Догадки не работают
newrelic.com
Фоновые задачи очень важны
Профилирование
Слайд 16Место на дисках
Упавшие серверы
Длины очередей
Ночной дежурный (?)
Мониторинг
Слайд 17Нужны реляционные выборки
Часто меняются критерии
PostgreSQL быстр и удобен
Индексы — основной дисковый IO
SQL база
Слайд 18Много данных рядом — плохо
Нам повезло с логикой выборок
Шардинг: user_id % 100
Надо планировать
Слайд 19Меньше всего проблем
Zero-downtime deploy с unicorn-ом
Плохая поддержка шардинга
Необходимость RabbitMQ
Ruby on Rails
Слайд 20Самая быстрая часть проекта
Оказался индикатором состояния
Мучительное восстановление
RabbitMQ