Разработка проектов с высокой посещаемостью
Алексей Рыбак 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