Учебный день конференции HighLoad++ 2013

Разработка и проектирование

высоконагруженных систем

Олег Бунинoleg.bunin@ontico.ru

Структура лекцииПервый блок:

• Знакомство;• Цель обучения;• Принципы масштабируемости;• Архитектурные решения;• Виды масштабирования;• Трёхзвенная структура.

Второй блок:• Архитектурные паттерны;• Алгоритм проектирования высоконагруженных систем.

Третий блок:• Примеры: профили на сайте знакомств, новостной сайт, френдлента;

Если успеем:• Ошибки в разработке высоконагруженных систем;• Хаки;• Эксплуатация.

ЗнакомствоДавайте познакомимся!

Олег Бунин

• Председатель Программного комитета конференции разработчиков высоконагруженных систем HighLoad++ вот уже семь лет;

Олег Бунин

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

Олег Бунин

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

• Руководитель отдела веб-разработки компании Рамблер (ещё тогда, когда Рамблер был номером один);

Кто вы?

• У кого пользователей больше 10 тысяч в сутки?

Кто вы?

• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки?

Кто вы?

• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки?

Кто вы?

• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки? миллион в сутки?

Кто вы?

• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки? миллион в сутки? 10 миллионов в сутки?

Кто вы?

• У кого есть в управлении сайты, расположенные на выделенном сервере?

Кто вы?

• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?

Кто вы?

• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?более, чем на пяти выделенных серверах?

Кто вы?

• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?более, чем на пяти выделенных серверах?более, чем на двадцати выделенных серверах?

Цель нашей встречи

• Состоит в том, чтобы вы глубоко начали понимать смысл происходящего в вашим программным кодом;

• Знание нескольких принципов заменяет знание множества фактов;

Репликация полезна?

В чём суть репликации?

Мастер Слейв

Слейв

Запись

Репликация

Чтение

• В чём суть репликации?• Что происходит на серверах физически?

• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?

• Записей больше, чем чтения;

• Записей больше, чем чтения;• Отсутствие консистентности данных;

• Записей больше, чем чтения;• Отсутствие консистентности данных;• Слишком много слейвов;

• Записей больше, чем чтения;• Отсутствие консистентности данных;• Слишком много слейвов;• Слишком много данных;

Кеширование полезно?

Кеширование

• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;

• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;

• Если количество промахов составляет:• 10% -> кеш ускоряет выполнение приложения в 3.3 раза;• 40% -> кеш ускоряет выполнение приложения в 1.7 раз;• 80% -> кеш не приносит пользы;• 90% -> кеш замедляет выполнение приложения.

• Вы знаете своё соотношение hit/miss?

Индексы полезны?

• Индекс – это возможность по значению столбца или группы столбцов быстро найти весь кортеж, всю строку в базе данных;

• Каждый индекс:• замедляет выполнение операции вставки строки;• увеличивает количество требуемой оперативной памяти;• усложняет работу планировщика запросов.

• Нужно учитывать селективность индекса;• Индексы с низкой селективностью, не просто бесполезны, они

вредны;

Принципы построения высоконагруженных

систем

Основная логика масштабируемости• Рано или поздно в процессе оптимизации мы упираемся в

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

одновременно на нескольких машинах;• Это легко сделать в парадигме запрос-ответ, в которой работает

веб;

Как нужно учитывать будущее масштабирование?

Принципы построения высоконагруженных систем

• Максимальная независимость компонент• Отсутствие единой точки отказа:

• По функциональности;• По данным;

Выбор архитектурного решения

Сервисно-ориентированная архитектура

Сервис-ориентированная архитектураКаждый сервис решает строго определенную задачу. Основной минус этого подхода заключается в наличии оверхеда на интеркоммуникацию сервисов между собой и на обработку API взаимодействия между слоями.

Монолитное приложение

Приложение представляет из себя монолитный программный код.

Плюсы:• Отсутствие какого-либо оверхеда на интеркоммуникацию сервисов;

Минусы:• Высокая сложность разработки;• В случае проблемы встает все;• Невозможность вести распределенную разработку.

Ремесленный подход

Ремесленный подходБизнес-логика проекта и инструменты для масштабирования разрабатываются одновременно, учитывая особенности бизнес-логики именно этого проекта.

Приложение Приложение Приложение

Система хранения

Кеш

Видео хранилище СУБД

Масштабируемая архитектура

Ремесленный подход• Быстрая разработка любых новых решений;

• Высокие требования к квалификации разработчиков – низкая масштабируемость разработки;

• Максимально эффективное использование технологий и аппаратного обеспечения;

Промышленный подход

Промышленный подходРазработка инструментов для масштабирования происходит отдельно от разработки бизнес-логики прикладных проектов.

Страница Страница Приложение Мобильная версия

API для обмена данными

Хранилище Хранилище Хранилище Хранилище

Слой веб-сервисов

Промышленный подход• Очень долгая разработка общих инструментов;

• Очень быстрая разработка приложений – происходит сборка страниц как в конструкторе Lego;

• Возможность использовать для разработки приложений программистов средней и низкой квалификации – высокая масштабируемость разработки;

• Повышенные требования к аппаратному обеспечению;

Что такое масштабирование?

Вертикальное масштабирование

Вертикальное масштабированиеУвеличение производительности системы за счет увеличения мощности сервера.

В какой-то момент мы все равно достигнем предела по процессору, памяти или жесткому диску.

Горизонтальное масштабирование

Увеличение производительности системы за счет подключения дополнительных cерверов

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

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

Различные данные имеют различные требования к обновлению. Это позволяет нам отложить часть обработки данных до более удобного случая.

Трёхзвенная структура

Трехзвенная структура

Фронтенды Бекенды Хранение данных

Быстрая обработка легких данных Вычисление Хранение данных

Для чего нужен фронтенд?

Фронтенд

• Отдача статического контента;• Буферизация запросов;• Масштабирование бекендов;• Обслуживание медленных клиентов.

Балансировка фронтендов

ПользователиПользователи

DNS-балансировкаDNS-балансировка

Round-Robin

IP1 IP1 IP2 IP2

Heart Beat Или CARP. Идея в том, что одна машинка не работает и наблюдает за другой. Если первая ломается, то она включается. У обеих машин один IP-адрес на двоих.

Балансировка бекендов

DNS-балансировкаDNS-балансировка

Round-Robin

IP1 IP1 IP2 IP2

Бекенд Бекенд Бекенд Бекенд

Дублирование фронтендов

Основной сервер

Вспомогательный сервер

Поток запросов

КофебрейкПаттерны масштабирования сразу после перерыва в 30 минут

Паттерны масштабированияВспомним инструменты, которые мы будем использовать

Инструмент #1

Сервисно-ориентированная архитектура

Вертикальное масштабирование

Горизонтальное масштабирование:• Не храним состояние;• Отсутствие общих узлов;

Отложенные вычисления

Асинхронная обработка

Очереди

Структура данных с дисциплиной доступа к элементам FIFO (First In First Out).

Применения:1. Отложенная обработка (рассылки, обновления лент новостей);2. Межсервисная коммуникация;

Очереди: модерация

Исходящий Rabbit MQ

Приложение, обновляющее SQL и считающая кучу

статистики

Erang-фронтенд Erlang-фронтенд Erlang-фроненд

БД БД БД

Копии всех обновлений

Этот сервер очередей должен стоять на стороне кластера фронтендов для того, чтобы в случае пропадания связи с резервным ДЦ информация никуда не потерялась.

Резервный датацентр

Входящий Rabbit MQ

Удаление сообщений

Очередь на удаление отмодерированных комментариев

Фронтенд для модератора

Заявки на удалениесообщений

Интеркоммуникация сервисов

Задача: необходимо уведомлять одни части системы о событиях, которые происходят в других частях:• размещение информации в пользовательских лентах (feeds) о

событиях, произошедних в сообществах;• лайки;• комментарии;• рассылка писем;

Интеркоммуникация: решение с очередью

Постинг поста

Сервис постов Очередь

Репликация очереди

Разборщик очереди

Постоянная база данных

Синхронная запись в базу данных

Синхронная постановка в

очередь

Репликация или Heart beat

Всегда быть готовым к дублированию задач в очереди

Если очередь сломалась –

переставляем задачи по

постоянной базе

сообщений

Интеркоммуникация: решение с очередью

Сервис A

Внутренняя очередь

сервиса А

Раздающий демон сервиса А

Входящие Http-сервера сервиса Б

Это могут быть те же сервера, что и обрабатывают запросы от фронтендами

Внутренняя очередь

сервиса Б

Сервис Б

Прием задач для сервиса Б

Обработка задач сервиса Б

Push сообщений из сервиса А во все

остальные сервисы

Обработка задач сервиса А

Забираем задачи

Использование толстого клиента

АнтишквалРяд серверов-бекендов, выполняющих однотипные задачи. Запрос приходит на первый бекенд, начинает выполняться, но не успевает за время таймаута. Фронтенд или толстый клиент перебрасывает запрос на новый бекенд, тот тоже не успевает. Таким образом очень быстро вся сеть бекендов будет положена.

Фронтенд

Сервис Сервис

Первый запрос

Первый бекенд не ответил, переходим ко второму

Антишквал: умные запросыУмные запросы от фронтенда:

• Первый запрос к первому бекенду идет с таймаутом 1 секунду. Второй запрос идет с таймаутом 2 секунды, третий - 3 секунды, а четвертого уже нет. То есть ограничиваем количество запросов;

• Бекенд может принимать решение о том, что он перегружен (раз в секунду спрашивать LA и кэшировать его). При начале обработке запроса происходит проверка и если LA слишком высокий - отдаем фронту Gone Away (штатная ситуация - перейди к другому бекенду).

Фронтенд Фронтенд Фронтенд Фронтенд

Сервис Сервис Сервис Сервис

Первый запрос, Timeout = 1с

Второй запрос,Timeout = 2с

Третий запрос,Timeout = 3с Четвертого запроса

просто нет.

• Кеширование в браузере;• Кеширование HTML-блоков;• Кеширование данных;• Кеширование HTML-страниц.

Кеширование на бекенде;

• Единый кеш для всех бекендов;• Проблема инвалидации кеша;• Проблема старта с непрогретым кешем;• Целесообразность применения кеша;

Бекенд

Кеш

Проблема инвалидации кеша

• Обновление по запросу (проблема race condition для нагруженных страниц);

• Фоновое обновление;

Update(Обновление

элемента кеша)

Select(Запрос

элемента кеша)

Кеш Memcached

Есть значениев кеше?

База данных

Очередь

Класс для вычисления

элемента кеша

Маленький демон

Пишем задачу в очередь

Нет

Возвращаем результат и пишем в кеш

Используем одни модули дляонлайна и оффлайна

Читаем и обнуляемочередь

Пишем в кеш

Программный код

Функциональное разделение

Шардинг

ШардингБазовый принцип: те данные, которые в дальнейшем потребуются вместе, так же должны храниться вместе.

Примеры:1. Пользователи;2. Посты в сообществах;3. Блоги;

Принципы разбиения данных на шарды:4. Центральный диспетчер, знающий, что где лежит;5. Хэш-функция, по ключу вычисляющая шард;6. Хэш-функция, по ключу вычисляющая виртуальный шард + таблица соответствий

виртуальных шардов реальным.

Виртуальные шарды

Виртуальные шардыШард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8

Шард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8

Сервер 1

Сервер 1 Сервер 2

Сервер 1 Сервер 3 Сервер 2 Сервер 4

Сервер 1 Сервер 3 Сервер 2 Сервер 4Сервер 5 Сервер 6 Сервер 7 Сервер 8

Центральный диспетчер

Бекенд

Лог обновлений MongoDB

Обновления слушаются содной из реплик

Мастер MongoDB

Запись поста в блог

Базы данных MongoDB

Реплики MongoDB

Push-сервер

Бекенд

Читаем с реплики

Публикация поста

Чтение блога

AJAX-Соообщение об обновлении

Партиционирование

• Разбиение больших таблиц на логические части по выбранным критериям;

Функциональное разделение базы данныхРазные данные хранятся в разных таблицахили

Разные данные хранятся в разных СУБДили

Разные данные хранятся в разных типах СУБД

Денормализация

Денормализация данных

Денормализация — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.

Введение избыточности

Параллельное выполнение

Алгоритм проектирования высоконагруженной системы

Алгоритм, ШАГ ПЕРВЫЙОпишем бизнес-логику будущей системы, включая потенциальные пути развития системы

Алгоритм, ШАГ ВТОРОЙПосчитаем объёмы хранимых данных и скорость их приращения. Выбираем критический путь – хранение, запись или чтение данных?

Алгоритм, ШАГ ТРЕТИЙОпределить допустимую деградацию функций системы

Алгоритм, ШАГ ЧЕТВЕРТЫЙПостроим схему движения данных и примем решение, какие из особенностей проектируемой системы мы будем использовать

Алгоритм, ШАГ ПЯТЫЙПроектируем схему хранения данных

АЛГОРИТМ, ШАГ ШЕСТОЙЛомаем систему и смотрим, что у нас получится

Не пора ли кофебрейк?Алгоритм проектирования сразу после перерыва в 30 минут

Примеры

ПРОФИЛИ НА САЙТЕ ЗНАКОМСТВСпроектируем систему хранения пользователей на сайте знакомств

Сайт знакомств, профили / #1

1. Пользователь заполняет анкету;2. Получает логин пароль для доступа к своему личному кабинету;3. Пользователи могут смотреть профили друг друга;

1. Пользователей 200 миллионов;2. Каждая анкета занимает 10 килобайт, то есть всего 2 000

гигабайт;3. Хитов в день 5 миллиардов;

1. Деградация недопустима;

1. Данные часто читаются, но редко меняются;2. Все анкеты примерно одного размера;3. У анкеты есть уникальный идентификатор;4. Нет ярко выраженных лидеров;

Проектируем схему хранения данных

Репликация?Вообще 140к чтений в секунду

Шардирование?По какому ключу? Диспетчер?

Виртуальные шарды

Сгорает диск?

Сайт знакомств, пользователи / #6

Сайт знакомств, профили / результат• Разбиваем весь массив пользователей на виртуальные шарды;

• Маппим виртуальные шарды на реальные шарды;

• Внутри каждого шарда реплицируем информацию для отказоустойчивости

Стажировка!oleg.bunin@ontico.ru

Задания на стажировку

• В двух абзацах и одной схеме описать различия в СУБД MySQL и PostgreSQL;

• Предположить, какие особенности в оптимизации и архитектуре накладывают из-за этого различия возникают;

• Результаты прислать на oleg.bunin@ontico.ru

НОВОСТНОЙ САЙТБольшая и длинная лента новостей крупного СМИ

Новости / #1

• Пользователь читает свежие новости;• Пользователь читает архивные новости;• Редактор публикует новости;

Новости / #2

• Каждая новость примерно 10 килобайт;• Мы вечно храним архив с даты основания СМИ – 2000 год;• В день публикуется около 10 тысяч различных региональных и

федеральных новостей;• Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за

20 лет – 700 гигабайт; • Это крупнейшее СМИ, посещаемость – 10 миллионов человек в

сутки;

Новости / #3

• Деградация недопустима;

Новости / #4

• Количество чтений на несколько порядков превышает количество записей;

• 99% запросов касаются последнего дня;• 99,99% запросов касаются последней недели.

Новости / #5

ПартиционированиеПо какому принципу?

Новости / #5

Как переносить данные из горячей БД в архив?

Новости / #5

Не надо ничего переносить! Вводим избыточность!

Новости / #5

Очень много запросов к горячим новостям!

Что делать?

Новости / #5

Кеширование!

Новости / результат

• Кеширование для горячих новостей;• Партиционирование новостей по дате – последние новости в

быстрой таблице;• Избыточное хранение новостей – новость пишется сразу и в

горячую таблицу и в архивную, горячая раз в какое-то время чистится;

ПРОСМОТР ФРЕНДЛЕНТЫПросмотр френдлента в блогах

Просмотр френдленты / #1

• У пользователя может быть сколько угодно друзей;• Френдленту храним бесконечно долго;

• В среднем у пользователя 100 друзей;• Каждый пользователь в среднем пишет 3 поста в день;• Каждый пост занимаем около 1 килобайта;• Пользователей – 10 миллионов в сутки, но каждый пользователь

делает 100 хитов. Итого – миллиард запросов к френдленте в сутки;

• В сутки генерируется 30 миллионов постов, 10 миллиардов записей в год;

• Допустимо, что пользователь увидит запись своего друга не моментально, а с небольшой задержкой;

• Допустимо, что порядок записей не будет строго совпадать с хронологическим;

• 99% запросов приходятся на голову френдленты;• У нас есть пользователи, которые в друзьях у миллионов

пользователей;

Избыточность?Каждому пользователю свой список записей в его френдленте? Это

же очень много – один триллион записей за год!

Храним для каждого пользователя ленту идентификаторов постов!

Шардирование?Чего? По какому принципу?

Пользователь и его посты лежат рядом

Сделайте составной идентификатор поста, пусть в него входит идентификатор пользователя

Достали список идентификаторов постов

Как собрать ленту?

Толстый клиент!

Если вы круты, то можете попробовать

Параллельные вычисления

Просмотр френдленты / результаты• Пользователи шардируются, рядом с пользователями лежат его

посты и его френдлента;

• В френдленте пользователя уже записаны идентификаторы постов его друзей в порядке, близком к хронологическому;

• В идентификатор поста зашит ID пользователя, по которому мы быстро определяем шард и забираем с него текст поста;

• За текстом поста у нас будет ходить JS-машина, работающая на клиенте.

Запись френдленты / #5

А как посты попадают в френдленту?

У нас ведь есть пользователи, которые в друзьях у миллионов?

Запись френдленты / #5

Используем очереди!

И далее по аналогииАлгоритм универсален!

Блок “Если успеем”На этот раз уже без перерыва!

Надежность высоконагруженной веб-системы

Принципы надежности

• Взаимозаменяемость серверов;• Избыточность данных, дублирование узлов:

• Фронтенд: DNS-балансировка, CARP, heartbeat;• Бекенд: гомогенные взаимозаменяемые бекенды;• База данных: дублирование данных, репликации, кластера;

Мониторинг

Вы должны с абсолютной точностью знать, что происходит в системе.

• Мониторинг серверов;• Мониторинг приложений;• Мониторинг элементов приложений;• Мониторинг показателей базы данных;

Мониторинг: pinba

Деплоймент

Регулярный быстрый автоматический деплоймент с возможностью сплит-тестирования и возможностью быстрого отката.

Лайфхаки

Различное строение СУБД

Буферизация в операционной системе

Электрический сигнал Сетевая карта

Операционная система, Сетевая подсистема

apache PHP

Операционная система, дисковая подсистема

Диск

ПамятьБаза данных

Синхронная обработка, синхронные запросы

Бездумное использование ORM

Стажировка!oleg.bunin@ontico.ru

Задания на стажировку

• В двух абзацах и одной схеме описать различия в СУБД MySQL и PostgreSQL;

• Предположить, какие особенности в оптимизации и архитектуре накладывают из-за этого различия возникают;

• Результаты прислать на oleg.bunin@ontico.ru

Вопросы?oleg.bunin@ontico.ru

Дополнительные примеры

Event-driven чат

Основной сервер (PHP-бекенд)

Основная базаMySQL

Быстрая база MongoDB

Быстрый серверNode.JS или phpDaemon

Клиенты

AJAX Long polling

POST-запрос с сообщением

Пишем постоянную версию

Поток репликации

Лента новостейПользователь А

публикует запись

Сохраняем запись в статичном постоянном

хранилище

Удачны обе операции?

Ставим в очередь З задачу обновить ленты

подписчиков пользователя А

Например, RabbitMQ

Публикация произошла успешно

Удачно?

Удаляем (или не коммитим) запись в

статичное хранилище.

Сервер очередей

Пул процессов, обслуживающих

очередь

Обновляем соответствующие

списки идентификаторов

Постоянное хранилище

Пользователь B, подписанный на

пользователя А, читает свою ленту

Запрашиваем список идентификаторов

записей из ленты B

Обрабатываем идентификаторы и для

каждого из них запрашиваем данные из постоянного хранилища

Этот процесс тоже можно оптимизировать, группировать.

Сначала можно запросить подробности по двум записям,

потом по четырем, потом по всем оставшимся.

Запись не сохранилась

Нет

Нет Да

Хранилище лент, каждая лента =

список идентификаторов

записей

Страница построена

Хранение бинарных данных

Frontend / 1

Design images

memcached

Frontend / 2

Design images

nginx memcached

Пользователи

DNS-БалансингDNS-Балансинг

Image Server / 1

User images

Image Server / 3

User images

Image Server / 2

User images

Backend / 1

PHP + Limb

Backend / 2

PHP + Limb

Backend / 3

PHP + Limb

Демоны

Database / 1

Закачивание фотографии

После того, как nginx полностью принялфотографию, он отправляет ее в

php-бекенд

Пишем в базуданных метаинформацию

о фотографии

По scp заливаем фотку (все варианты)на один из серверов

Отдачафотографии напрямую

с хоста

Учебный день конференции HighLoad++ 2013

Documents

20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Когда стоит написать свою БД", Олег Краснов

Highload: специализированные высокопроизводительные индексы

Hl++2012 lyamin qrator ddos highload 2012

HighLoad++ 2013 Iosif Itkin Anton Sitnikov

Cборка мусора в Java без пауз (HighLoad++ 2013)

IATE Lecture 3: Quality Assurance for Highload Systems

Алексей Рыстенко: Highload и микросервисы

HighLoad++ 2009 In-Memory Data Grids

Highload 2014. PostgreSQL: ups, DevOps

Разработка SPA на мультисайтовом highload-проекте

HighLoad Junior - Как выбирать и как выбрать ДЦ

Git in Sky presentation @ HighLoad++ 2013

Highload не кусается.антон шевчук

HighLoad весна 2014 лекция 1

HighLoad весна 2014 лекция 3

Highload осень 2012 лекция 7

Клиентские приложения под нагрузкой (HighLoad 2014)

Highload осень 2012 лекция 10

Highload sites, master-class, OK-2009

Highload осень 2012 лекция 5