1 of 32

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

Проектирование и разработка распределенных программных систем, лекция 6

2 of 32

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

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

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

3 of 32

Плюсы вертикального масштабирования

Вертикальное масштабирование очень простое (нажать пару кнопок в панели управления облаком и перезагрузить узел).

4 of 32

Плюсы горизонтального масштабирования

  1. Больше не упираемся в ограничения по возможностям железа
  2. Повышается отказоустойчивость (поломка одного узла не ломает всю систему)
  3. Появляется возможность географического распределения
  4. Появляется возможность динамического масштабирования (добавить серверов на время «черной пятницы»)

5 of 32

Минусы горизонтального масштабирования

  1. Логика работы узлов должна позволять распределенную работу
  2. Требуется усложнять архитектуру системы
  3. Добавляется оверхед к скорости работы системы

6 of 32

Плюсы и минусы

Горизонтальное масштабирование — это сложно и дорого, поэтому в первую очередь производительность повышают за счет железа и оптимизаций.

Но с какого-то этапа развития большого проекта плюсы начинают перевешивать минусы.

7 of 32

Логика масштабирования бэкендов

8 of 32

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

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

Например, можно отделить от основного сервиса:

  • Биллинг
  • Форум со службой поддержки
  • Посадочные промо-страницы

9 of 32

Зачем нужно функциональное разделение

  • Увеличение надежности
  • Простое разделение нагрузки
  • Возможность использовать разные технологии и настройки для разных компонентов
  • Раздельное масштабирование (масштабируем только узкие места)

10 of 32

Shared Nothing

В подходе Shared Nothing каждый узел системы самодостаточен и способен самостоятельно обработать запрос пользователя. Поэтому у системы нет единой точки отказа.

11 of 32

Shared Nothing

Не всегда рационально полностью следовать подходу Shared Nothing. Например, можно использовать общую БД. Но всегда нужно понимать, какие есть общие ресурсы у нод одного вида.

12 of 32

Stateless

Stateless означает, что в памяти бэкенда не хранится никакого состояния между запросами. Бэкенд забывает о пользователе сразу же после ответа на запрос.

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

13 of 32

Применимость stateless

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

  • Массовые онлайн-игры
  • Чат-комнаты
  • Сознательный отказ от stateless ради повышения производительности

14 of 32

Архитектура

15 of 32

16 of 32

Балансировщик нагрузки (фронтенд)

Узел, который принимает все входящие запросы и распределяет их между бэкендами.

Чем равномернее распределение, тем меньше нужно бэкендов.

17 of 32

Балансировка нагрузки через DNS

DNS сервер — это первый узел, который принимает запрос от посетителя и возвращает IP-адрес приложения.

В настройках DNS можно указать несколько записей с разными IP-адресами.

18 of 32

Балансировка нагрузки через DNS

example.com IN A 216.40.104.1

example.com IN A 216.40.104.2

example.com IN A 216.40.104.3

example.com IN A 216.40.104.4

19 of 32

Round-robin DNS

Меняем порядок записей после каждого запроса.

Клиент обычно выбирает первый IP-адрес из списка.

20 of 32

GeoDNS

Можно настроить DNS-сервер, чтобы он отдавал разные IP-адреса в зависимости от местоположения пользователя. Тогда каждый пользователь сможет получать IP-адрес ближайшего к нему сервера.

21 of 32

Плюсы балансировки через DNS

  • Не требуется дополнительная инфраструктура

22 of 32

Минусы балансировки через DNS

  • Нет стандарта, по которому клиент будет выбирать IP-адрес из списка, поэтому запросы будут распределяться неравномерно
  • Ответы кешируются на локальных DNS-серверах, поэтому нельзя быстро убрать упавший бэкенд из списка

23 of 32

Балансировщики нагрузки

  • HAProxy
  • nginx
  • squid

24 of 32

Алгоритмы балансировки нагрузки

  • Случайный
  • Round-robin
  • Least connections
  • Использование весов

25 of 32

Умная балансировка нагрузки

  • Layer 4 load balancing: решение принимается на основе данных транспортного уровня (source IP, destination IP, порт)
  • Layer 7 load balancing: решение принимается на основе данных прикладного уровня (URL, параметры запроса)

26 of 32

Health checks

Чтобы не перенаправлять запросы на недоступные сервера, балансировщик нагрузки должен следить за их доступностью.

27 of 32

Активные и пассивные хелсчеки

Active health check — балансировщик периодически отправляет запросы к бэкенду и проверяет, что он отдает корректный ответ.

Passive health check — балансировщик проверяет ответы бэкенда на запросы пользователя, и если приходит некорректный ответ, то бэкенд временно помечается как недоступный.

28 of 32

Кластеры балансировщиков

Чтобы балансировщик нагрузки не был единой точкой отказа, можно ставить несколько балансировщиков нагрузки в кластере.

29 of 32

Режимы работы кластера

active-passive: активный балансировщик обслуживает запросы, а пассивный следит за его состоянием и встает на его место в случае падения

active-active: оба балансировщика обслуживают запросы и готовы подменить друг друга, если один из них упадет

30 of 32

Балансировка балансировщиков

Переключение между балансировщиками происходит с помощью VRRP (Virtual Router Redundancy Protocol) / CARP (Common Address Redundancy Protocol) и плавающих IP-адресов.

31 of 32

Ссылки

32 of 32

Ссылки

  1. Общая логика масштабирования http://highload.guide/blog/scaling-logic.html
  2. Масштабирование бэкенда https://xakep.ru/2012/11/30/backend-zoom/
  3. Горизонтальное масштабирование. Что, зачем, когда и как http://highload.guide/blog/scaling-what-why-when-and-how.html
  4. Как мы сделали ровную балансировку нагрузки на фронтенд-кластере http://highload.guide/blog/load-balancing-frontend-cluster.html