'

Учебник по построению высоконагруженных систем

Понравилась презентация – покажи это...





Слайд 0

Учебник по построению высоконагруженных систем Олег Бунин


Слайд 1

Цель доклада Представить набор инструментов, используемых в разработке архитектур высоконагруженных систем. Инструменты разные, правильные, не правильные, используйте на свой вкус ?


Слайд 2

Монолитное приложение Приложение представляет из себя монолитный программный код. Плюсы: Отсутствие какого-либо оверхеда на интеркоммуникацию сервисов; Минусы: Высокая сложность разработки; В случае проблемы встает все; Невозможность вести распределенную разработку.


Слайд 3

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


Слайд 4

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


Слайд 5

Ремесленный подход Быстрая разработка любых новых решений; Высокие требования к квалификации разработчиков – низкая масштабируемость разработки; Максимально эффективное использование технологий и аппаратного обеспечения;


Слайд 6

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


Слайд 7

Промышленный подход Очень долгая разработка общих инструментов; Очень быстрая разработка приложений – происходит сборка страниц как в конструкторе Lego; Возможность использовать для разработки приложений программистов средней и низкой квалификации – высокая масштабируемость разработки; Повышенные требования к аппаратному обеспечению;


Слайд 8

Масштабирование архитектурного решения


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

МАСШТАБИРОВАНИЕ ФРОНТЕНДА


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

Классическое горизонтальное масштабирование Низкая степень связности кода; Share-nothing для горизонтального масштабирования; Слоистость кода; Минимизация использования сложных запросов сразу к нескольким таблицам;


Слайд 22

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


Слайд 23

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


Слайд 24

МАСШТАБИРОВАНИЕ “ВО ВРЕМЕНИ”


Слайд 25

Очереди Структура данных с дисциплиной доступа к элементам FIFO (First In First Out). Применения: Отложенная обработка (рассылки, обновления лент новостей); Межсервисная коммуникация;


Слайд 26

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


Слайд 27

ИНТЕРКОММУНИКАЦИЯ


Слайд 28

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


Слайд 29

Антишквал: решение с очередью Промежуточное звено с очередью, бекенды сами забирают из него задачи. Проблемы этого варианта: Смешение подходов - синхронную задачу решают асинхронными методами; Не решает проблему с тем, если фронт отключился, то запрос остался; Те задачи, которые попали на тормозящий бекенд - пропадают. Это решается перестартом очереди.


Слайд 30

Антишквал: умные запросы Умные запросы от фронтенда: Первый запрос к первому бекенду идет с таймаутом 1 секунду. Второй запрос идет с таймаутом 2 секунды, третий - 3 секунды, а четвертого уже нет. То есть ограничиваем количество запросов; Бекенд может принимать решение о том, что он перегружен (раз в секунду спрашивать LA и кэшировать его). При начале обработке запроса происходит проверка и если LA слишком высокий - отдаем фронту Gone Away (штатная ситуация - перейди к другому бекенду).


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34

МАСШТАБИРОВАНИЕ БАЗ ДАННЫХ


Слайд 35

Типы баз данных Реляционная модель: данные в базе данных представляют собой набор отношений; Иерархическая модель: база данных состоит из объектов с указанием отношений родитель ? ребенок; Сетевая модель: база данных со структурой в виде графа; Объектно-ориентированная модель: база данных, в которой данные представлены в виде моделей объектов.


Слайд 36

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


Слайд 37

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


Слайд 38

Партиционирование Функциональное разделение базы данных. Разные данные хранятся в разных таблицах. или Разные данные хранятся в разных СУБД. или Разные данные хранятся в разных типах СУБД.


Слайд 39

Кластеризация


Слайд 40

Репликация


Слайд 41

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


Слайд 42

НАДЕЖНОСТЬ


Слайд 43

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


Слайд 44

ЭКСПЛУАТАЦИЯ


Слайд 45

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


Слайд 46

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


Слайд 47

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


Слайд 48

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


Слайд 49

oleg.bunin@ontico.ru facebook.com/oleg.bunin


×

HTML:





Ссылка: