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

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

Олег Бунин

[email protected]

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

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

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

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

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

2

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

3

Олег Бунин

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

4

Олег Бунин


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

5

Олег Бунин


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

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

6

7

Кто вы?

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

8

Кто вы?


100 тысяч в сутки?

9

Кто вы?




10

Кто вы?




миллион в сутки?

11

Кто вы?




миллион в сутки?

10 миллионов в сутки?

12

Кто вы?

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

выделенном сервере?

13

Кто вы?



более, чем на двух выделенных серверах?

14

Кто вы?




более, чем на пяти выделенных серверах?

15

Кто вы?




более, чем на пяти выделенных серверах?

более, чем на двадцати выделенных серверах?

16

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

17

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

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

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

18

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

19

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

20

Мастер Слейв

Слейв

Слейв

Запись

Репликация

Чтение


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

• Что происходит на серверах физически?

21




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

22




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

23




• Решает ли репликация любую проблему и всегда ли она полезна?• Записей больше, чем чтения;

24





• Отсутствие консистентности данных;

25






• Слишком много слейвов;

26






• Слишком много слейвов;

• Слишком много данных;

27

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

28

Кеширование

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

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

29




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

30





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

• 40% -> кеш ускоряет выполнение приложения в 1.7 раз;

• 80% -> кеш не приносит пользы;

• 90% -> кеш замедляет выполнение приложения.

31





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

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

32

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

33


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

34


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

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

• увеличивает количество требуемой оперативной памяти;

• усложняет работу планировщика запросов.

35


• Нужно учитывать селективность индекса;

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

36

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

37

Основная логика масштабируемости

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

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

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

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

38

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

• Максимальная независимость компонент

• Отсутствие единой точки отказа:• По функциональности;

• По данным;

39

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

40


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

41

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

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


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

43

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

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

Плюсы:

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

Минусы:

• Высокая сложность разработки;

• В случае проблемы встает все;

• Невозможность вести распределенную разработку.


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

45

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

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

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

Кеш

Видео хранилище

СУБД

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



MySQL

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

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

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

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


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

48

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

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

версия

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

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

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

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

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

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

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

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

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

51


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

52


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

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


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

54

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


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

56

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

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

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

58

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

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

данных

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

Вычисление Хранение данных

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

60

Фронтенд

• Отдача статического контента;

• Буферизация запросов;

• Масштабирование бекендов;

• Обслуживание медленных клиентов.

61

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

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

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

Round-Robin

IP1 IP1 IP2 IP2

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

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

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

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

Round-Robin

IP1 IP1 IP2 IP2

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

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

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

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

CARP

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

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

65

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

66

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

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

67



68


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

• Отсутствие общих узлов;

69


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

70


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

71

Очереди

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

Применения:

1. Отложенная обработка (рассылки, обновления лент новостей);

2. Межсервисная коммуникация;

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

Исходящий Rabbit MQ

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

статистики

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

БД БД БД

SQL

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

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

SQL

SQL

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

Входящий Rabbit MQ

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

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

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

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

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

Задача: необходимо уведомлять одни части системы о событиях, которые происходят в других частях:

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

• лайки;

• комментарии;

• рассылка писем;

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

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

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

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

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

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

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

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

очередь

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

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

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

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

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

сообщений

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

Сервис A

Сервис A

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

сервиса А

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

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



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

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

сервиса Б

Сервис Б

Сервис Б

Сервис Б

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

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

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

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

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

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


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

77

АнтишквалРяд серверов-бекендов, выполняющих однотипные задачи.

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

Фронтенд или толстый клиент перебрасывает запрос на новый бекенд, тот тоже не успевает.

Таким образом очень быстро вся сеть бекендов будет положена.

Фронтенд

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

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

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

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

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

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

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

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

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

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

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

просто нет.



80


• Кеширование в браузере;

• Кеширование HTML-блоков;

• Кеширование данных;

• Кеширование HTML-страниц.

81

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

• Единый кеш для всех бекендов;

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

• Проблема старта с непрогретым кешем;

• Целесообразность применения кеша;

Бекенд

Бекенд

Бекенд

Кеш

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

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

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

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

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

Select(Запрос

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

Кеш Memcached

Да

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

База данных

Очередь

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

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

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

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

Нет

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

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

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

Пишем в кеш

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


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

84


Шардинг

85

Шардинг

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

Примеры:

1. Пользователи;

2. Посты в сообществах;

3. Блоги;

Принципы разбиения данных на шарды:

1. Центральный диспетчер, знающий, что где лежит;

2. Хэш-функция, по ключу вычисляющая шард;

3. Хэш-функция, по ключу вычисляющая виртуальный шард + таблица соответствий виртуальных шардов реальным.


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

87

Виртуальные шардыШард 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


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

89



90


Бекенд

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

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

Мастер MongoDB

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

Базы данных MongoDB

Реплики MongoDB






Push-сервер

Бекенд

Бекенд

Бекенд

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

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

Чтение блога

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


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

92

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

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

93

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

Разные данные хранятся в разных таблицах

или

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

или

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


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

95

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

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


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

97


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

98

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

99

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

100

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

101

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

102

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

103

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

104

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

105

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

106

Примеры

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

108

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

1. Пользователь заполняет анкету;

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

3. Пользователи могут смотреть профили друг друга;

109


1. Пользователей 200 миллионов;

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

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

110


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

111


1. Данные часто читаются, но редко меняются;

2. Все анкеты примерно одного размера;

3. У анкеты есть уникальный идентификатор;

4. Нет ярко выраженных лидеров;

112


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

113


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

114


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

115


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

116


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

117

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


118

Сайт знакомств, профили / результат

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

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

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

отказоустойчивости

119

Стажировка[email protected]

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

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

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

• Результаты прислать на [email protected]

121

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

122

Новости / #1

• Пользователь читает свежие новости;

• Пользователь читает архивные новости;

• Редактор публикует новости;

123

Новости / #2

• Каждая новость примерно 10 килобайт;

• Мы вечно храним архив с даты основания СМИ – 2000 год;

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

• Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за 20 лет – 700 гигабайт;

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

124

Новости / #3

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

125

Новости / #4

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

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

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

126

Новости / #5


127

Новости / #5

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

128

Новости / #5

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

129

Новости / #5

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

130

Новости / #5

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

Что делать?

131

Новости / #5

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

132

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

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

• Партиционирование новостей по дате – последние новости в быстрой таблице;

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

133

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

134

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

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

• Френдленту храним бесконечно долго;

135


• В среднем у пользователя 100 друзей;

• Каждый пользователь в среднем пишет 3 поста в день;

• Каждый пост занимаем около 1 килобайта;

• Пользователей – 10 миллионов в сутки, но каждый пользователь делает 100 хитов. Итого – миллиард запросов к френдленте в сутки;

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

136


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

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

137


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

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

138



139


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

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

140


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

141


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

142


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

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

143


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

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

144


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

145


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

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

146

Просмотр френдленты / результаты

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

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

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

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

147

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

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

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

148

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

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

149

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

150

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

151

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

152

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

• Взаимозаменяемость серверов;

• Избыточность данных, дублирование узлов:• Фронтенд: DNS-балансировка, CARP, heartbeat;

• Бекенд: гомогенные взаимозаменяемые бекенды;

• База данных: дублирование данных, репликации, кластера;

Мониторинг

154

Мониторинг

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

• Мониторинг серверов;

• Мониторинг приложений;

• Мониторинг элементов приложений;

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

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

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

Деплоймент

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

Лайфхаки

159

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

160

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

161

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

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

nginx

apache PHP

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

Диск

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

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

162

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

163

Стажировка[email protected]

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

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

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

• Результаты прислать на [email protected]

165

Вопросы[email protected]

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

167

Event-driven чат

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

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

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

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

Клиенты

AJAX Long polling

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

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

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

Лента новостей

Пользователь А публикует запись

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

хранилище

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

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

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

Например, RabbitMQ

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

Удачно?

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

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

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

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

очередь

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

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

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

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

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

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

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

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

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

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

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

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

Да

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

Нет

Нет Да

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

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

записей

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

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

Frontend / 1

nginx

Design images

memcached

Frontend / 2

Design images

nginx memcached

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

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

Image Server / 1

User images

nginx

Image Server / 3

User images

nginx

Image Server / 2

User images

nginx

Backend / 1

PHP + Limb

Backend / 2

PHP + Limb

Backend / 3

PHP + Limb

Демоны

Database / 1

MySQL

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

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

php-бекенд

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

о фотографии

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

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

с хоста

Documents

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