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

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

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

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

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

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

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

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

МАСШТАБИРОВАНИЕ АРХИТЕКТУРНОГО РЕШЕНИЯ

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

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

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

ТРЕХЗВЕННАЯ СТРУКТУРА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репликация

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

НАДЕЖНОСТЬ

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

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

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

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

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

facebook.com/oleg.bunin