Разработка проектов с высокой посещаемостью

Алексей Рыбак badoo.com

В этом докладе

1. Основные проблемы2. Масштабирование веб-серверов3. Масштабирование БД (Sharding)4. Очереди

Более глубокий/широкий обзор на мастер-классе

1. Основные проблемы

Большие проекты• Миллионы пользователей• 24x7• «Много» серверов• Многозвенная архитектура• Мегабайты кода• Зоопарк!• Быстрый или мертвый

Широкий спектр задач

• Технический менеджмент• Системное администрирование• Поддержка• Разработка

Некоторые ловушки• Высокая степень связанности (данных,

процедур, компонент) – плохое масштабирование

• Полу-решения (накапливание рисков)• Плохо управляемые инструменты • Горе от ума (решения с позиций

«теоретиков», вредные с инженерной точки зрения). Классический пример - ORM

Как не попасть в ловушки?• Многоуровневый анализ и проектирование• Логический: модель данных• Software: ОС, ФС, веб-сервера, базы данных

и другие базовые компоненты – у всех компонент есть свои важные особенности

• Hardware: диски, память, сеть, CPU• Прагматизм и умеренный консерватизм

Стартапы: уровни зрелости• Один сервер• Несколько серверов (скажем, десять)• Много серверов (сотни, тысячи… много ДЦ) • И ещё чтобы не очень падало и удобно

поддерживалось• Переход между уровнями обычно сопровождается

«кризисом»• Ключевое значение играет масштабируемая

архитектура

Масштабируемая архитектура• Независимые или слабо-связанные

веб-сервера

• Горизонтальное разделение данных

• RPC (сервисы, очереди)

• Обслуживание без вмешательства в код

2. Масштабирование веб-серверов

Масштабирование

зара

бот

али

потратили

линейное

эфф

ективность

Двухуровневая схема • Что делает сервер?

– Выполняет код– Обслуживает клиента

• Разве повар вместо официанта принимает заказ?• Принципиально разные задачи, лучше их разделить• Двухуровневая схема (обратное проксирование, frontend/backend)• Колоссальный выигрыш в производительности отдельной

компоненты – лучше «качество» масштабирования всей системы• Топология nginx(n)+apache(k*n), (apache+nginx)(M)

Линейное масштабирование• Независимость компонент• Минимум общих ресурсов (share-nothing => share

accurately)• Некоторые распространённые ловушки:

– общие данные на nfs (сессии, код) => локальные копии кода, сессии например в memcached

– локальный кеш => общий кеш– что-то пишем в базу realtime => сделать тяжелые операции

асинхронными

3. Sharding

Масштабирование• Scale up vs Scale out • Репликация (очень нелинейное)• Вертикальное: по задачам (по

таблицам)• Горизонтальное: по «основным»

сущностям – пользователям, документам и т.д. – sharding

Репликация «на пальцах»• Был один сервер w/r << 1• Добавили ещё один, 100% рост• Но w/r на мастере растёт – w не

масштабируются• Чем больше серверов – тем хуже• Социальные сервисы – много операций записи

Проблемы репликации• Линейна только при очень малом числе

серверов (writes не масштабируются)• Неэффективная утилизация ресурсов

(копии данных на диске и в кеше)• Особенности реализации (раздача лога,

один тред и т.д. – и порождённые извращения)

Масштабирование

зара

бот

али

потратили

линейное

эфф

ективность

Sharding: разделение данных• Статическое (детерминированное), num_key%n_serv,

crc32(md5(str_key))%n_serv, «первая буква логина» и т.д.• Это практически неуправляемо• Математические трюки: «магические 12, 24…»; 4*4 : root = key

%4 ; leaf = (key/4)%4 – всё равно плохо• «Динамическое»: добавление новых машин, замена, перенос,

балансировка – без изменения кода,• Минус динамического: часть приложения, которая отвечает за

адресацию – SPOF, м.б. высокая нагрузка

Sharding: прозрачность• Минимум головной боли при поддержке• Управление разделением данных без вмешательства в

код• «Проксирование»• Координирующий сервис (отвечает на вопрос “где?”)• Динамическая координация менее прозрачна, но

архитектурно более правильна• «Виртуализация» физических координат {server, db_suffix, table_suffix} => storage_id

4. Очереди

RPC• RPC = Remote procedure calls• Синхронно: удаленные сервисы• Асинхронно: очереди• Вариации: логически синхронно,

физически асинхронно• Проблема транзакционной целостности

Универсальная очередь• {event_class, event_data}• Внутри базы – нет проблем с транзакциями• Publisher/Subscriber• Диспетчеризация событий• Топология: (де)централизованная доставка и

обработка

Слайд от Postgresmen

• Утверждается, что в PostgreSQL всё уже есть

• Очереди - PgQ • Sharding - PL/Proxy • Посетите выступление Аско Оя, Skype

Конец

• Спасибо! Вопросы?

• alexey.rybak@gmail.com

• raa @ LJ