Колёса: Раньше и сейчас. Как поменять архитектуру высоконагруженного проекта

ПРОПАТЧИЛGLIBC???

CVE-2015-0235

GHOST

КолёсаРаньше и сейчас

2011 — 2015

Кто здесь?

● Максим, администратор серверных систем● Отвечаю за производительность● Состою в скромной команде архитекторов● Холю и лелею инфраструктуруДо Колёс:

● много VoIP’а на цисках и линуксах● линуксы дома, на работе, в отпуске…

2011 год

● 3 разработчика● 0 админов (аутсорс)● ~ 12 серверов-десктопов● 4.5М просмотров● 260k визитов

9 миллионов4 сервера:● 2 процессора● 48 Гб ОЗУХранилка:● 12 дисков● 12 ТБ (RAID10)Адская избыточность, высокая надежность, расширяемость, управляемость, печеньки!

2011 год (уиии, блэйд!)

● 3 разработчика● 0 админов (аутсорс)● 4 блэйд-сервера● 5.6M просмотров● 270к визитов

2012 год, начало

● 3 разработчика● 1 админ (ура!)● 4 блэйд-сервера● ~15 контейнеров OpenVZ● одна плоская сеть /24

Знаменитая трёхзвенная (плюшки)

OpenVZ

Плюсы:● быстрый● дерзкий● как пуля резкий● 1-3% накладных расходов● простой, как палка

OpenVZМинусы:

● одно ядро на всех● «хитрое» управление памятью (MongoDB и JVM передают

привет!)● ФС для контейнеров● видимость ограничена● постоянные танцы с бубном вокруг user_beancounters

KVMПлюсы:

● полная изоляция ВМ друг от друга и от хоста● MongoDB и JVM улыбаются и пляшут● быстрая работа с диском● видимость всех ресурсов ВМ● virtio, vhost_net, KSM

KVM

Минусы:● сложный● теоретически медленнее, чем OpenVZ

(аппаратная виртуализация спасает)● мало опыта администрирования и отладки

OpenVZ, давай, до свидания!● Несколько недель не спим● Переносим контейнеры в ВМ● …● PROFIT!

P.S. До сих пор KVM ни разу не становился настолько узким местом, чтобы хотелось от него отказаться.

Proxmox VE (proxmox.com)

● кластер KVM-серверов● multimaster● CLI● web● HA● API

Немного про overprovisioning

Он же оверселлинг, он же оверсабскрайбинг, он же большая радость хостера и засада клиента:

● позволяет продать больше, чем имеешь● провоцирует «драку» за ресурсы● распределение ресурсов становится

«тяжелой», но приоритетной задачей● совершенно нам не подходит

Блэйд-система в Колёсах

Почему же?

● большая коробка — половину в другой ЦОД не отпилишь

● аренда места в ЦОД стоит космических денег● заполненность на 25% экономически невыгодна● сэкономили на сетевой части● недешевый бренд

Наш выбор — Supermicro Twin²● один такой заменит блэйд● компактный● производительный● в 4 раза меньше● в 2 раза дешевле● недорогой бренд● даже с учётом электричества, аренда обходится

дешевле

GlusterFS

● как NFS, только от Red Hat● плюшки в виде репликации● и распределенности● которые никто не заюзал● ибо хранилище было одно● в самом низу — родная ФС (ext3/4, xfs)

Что лежало на хранилкеОбъявления:

/mnt/data/live/0007/654/321/data.xml

Фотографии:

/mnt/data/live/0007/654/321/photos/1/60x45.jpg

/mnt/data/live/0007/654/321/photos/1/120x90.jpg

/mnt/data/live/0007/654/321/photos/1/400x300.jpg

/mnt/data/live/0007/654/321/photos/1/full.jpg

~ 2 ТБ данных к середине 2012-го

Цифры

● 10M объявлений● ~ 10М файлов data.xml● ~ 40М каталогов для фото● ~ 160M файлов *.jpg

● ~ 200М объектов● ~ 50-60 Гб метаданных

И чо?подумаешь, много файлов…

fsck youвот чо

Проблема

Задержки:● HDD● сетевая ФС● ФС как структура вообще● множественный доступ (кэш не спасёт)● бэкап данных за неделю длится неделю

Решение для объявлений

● Никаких каталогов● Никаких файлов● Вкусный JSON вместо XML● Репликация● Резервное копирование (с бубном)

В итоге

● драматическое падение задержек● катастрофический прирост производительности● ещё два года Колёса живут без шардинга

Решение для фотографий

● храним объекты● намного меньше метаданных● доступ по HTTP● nginx для кэша и HTTPS● распределенная система● избыточно (3 копии данных)● задержки по-прежнему высоковаты :(

Цифры (Swift vs Хранилка)

● стоимость: 30% старой системы● расходы: на 20% выше● тройная избыточность● защита от сбоев● распределенность

Миграция1. поднимаем новую систему2. включаем запись в обе системы3. запускаем перенос данных из старой в новую

систему4. начинаем читать с новой системы5. дожидаемся окончания переноса6. ждём «на всякий случай»7. отключаем старую систему

Фотографии (сейчас)

● 2к запросов/сек● 260 Мбит/сек● 220 ГБ кэш (memcached)● кэш спасает, но продолжаем ускоряться● SSD для метаданных

2013 год● 5-8 разработчиков● 1 админ● 1 тестировщик!● ~ 150 ВМ

Колёса:● 8.2М просмотров● 450k визитов

Крыша:● 1.8М просмотров● 114к визитов

2013 …

● появились мобильные приложения● доросли до конца года до 1.5М просмотров и

120к визитов● масштабируемся каждый день● все хотят в API, а API всех ненавидит● присутствуем в двух ЦОДах

Оптимизация

Постоянные «фоновые» задачи:1. найти узкое место2. всё переделать3. перейти к шагу 1

Немного уже не узких мест● CDN для фотографий и статики

○ два ЦОДа○ балансировка на уровне DNS

● загрузка фото○ кэш для свежезагруженных изображений○ фоновый перенос в Swift

● жесткие диски○ SSD уже не дорого○ и очень быстро

Автоматизация

● серверов всё больше● конфигурации всё изощрённее● зависимость A->B->C->D->A● нужно же что-то делать, Петька!

Chef● сервер управления конфигурацией● для всех *nix● пишем рецепты, а оно их исполняет● только там, где нужно● попутная инвентаризация● только pull● пришлось учить ruby● программисты смеялись :(

Примеры

● добавлять все новые серверы в мониторинг● установить nginx на серверы группы web● найти все серверы, с драйвером e1000 и

наложить патч

Плюшки

● NTP● IPv6● SPDY

2014-2015● 11 разработчиков● 5 тестировщиков● 2 админа (ура! ура!)● ~ 520 ВМ

Сайты:

● 11.5М просмотров● 660к визитов

Мобильные приложения:

● 7.5М просмотров● 250k визитов

Что дальше?

● вчерашние паттерны уже антипаттерны● на горизонте маячит HTTP2● оптимизация под dial-up снова в моде● только теперь 1080p и 4K● зато даже в самолёте

Вопросы?

Максим Кравецадминистратор серверных системТОО «Колёса»[email protected]: zeelax

Спасибо!