(продолжение предыдущего поста)
Балансировщик нагрузки - один из неотъемлимых компонентов высоконагруженного приложения. Он обеспечивает:
* Распределение нагрузки между серверами для предотвращения перегрузки.
* Высокую доступность за счёт исключения неработающих серверов из обработки запросов.
* Гибкость в маршрутизации запросов (разные пути направляются к разным группам серверов).
* Улучшение пользовательского опыта за счёт быстрого и надёжного обслуживания запросов.
Рассмотрим, как работает балансировщик нагрузки
1. Приём запросов от клиентов (Listener)
Процесс начинается с того, что клиенты (устройства, подключённые к интернету) отправляют запросы на балансировщик нагрузки. Запросы поступают на Listener (прослушиватель), который настроен на определённый порт и протокол (например, HTTP:80). Listener служит «точкой входа» для входящих запросов.
2. Маршрутизация запросов (Routing Rules & Policies)
После приёма запроса балансировщик определяет, куда его направить, используя правила маршрутизации (Routing Rules). Эти правила основаны на различных параметрах:
* путь (Path) в URL (например,
/api/* или /images/*);* хост (Host);
* заголовки (Header) HTTP-запроса.
На изображении показаны два основных правила:
* Rule 1: /api/\*** — направляет запросы, начинающиеся с `/api/`, в **Target Group 1 (API Servers).
* Rule 2: /images/\*** — направляет запросы, начинающиеся с `/images/`, в **Target Group 2 (Image Servers).
3. Распределение нагрузки по целевым группам (Target Groups)
Целевые группы (Target Groups) — это наборы серверов или ресурсов, которые обрабатывают запросы. На изображении есть две целевые группы:
* Target Group 1: API Servers — включает EC2 Instance A, EC2 Instance B и Container C. Обрабатывает API-запросы.
* Target Group 2: Image Servers — включает S3 Bucket и EC2 Instance D. Обрабатывает запросы к изображениям.
Когда запрос соответствует определённому правилу маршрутизации, он перенаправляется в соответствующую целевую группу.
4. Выбор конкретного сервера (алгоритмы балансировки)
Внутри целевой группы балансировщик выбирает конкретный сервер для обработки запроса, используя алгоритмы балансировки нагрузки. Пример алгоритма — Round Robin (циклическое распределение запросов между серверами).
Например, если клиент отправил запрос
GET /api/users, процесс будет следующим:1. Listener принимает запрос на порту 80.
2. Routing Rule определяет, что путь
/api/users соответствует правилу /api/*.3. Запрос перенаправляется в Target Group 1 (API Servers).
4. Балансировщик выбирает, например, EC2 Instance A для обработки запроса (на основе алгоритма Round Robin).
5. EC2 Instance A обрабатывает запрос и возвращает ответ клиенту.
5. Политики (Policies) для повышения надёжности и удобства
Для эффективной работы балансировщика используются политики (Policies):
* Health Checks (проверки работоспособности) — балансировщик регулярно проверяет состояние серверов в целевых группах (например, каждые 30 секунд, Threshold: 2). Если сервер не проходит проверку, он временно исключается из обработки запросов.
* Sticky Sessions (прилипающие сессии) — политика, которая привязывает клиента к одному серверу на время сессии. Это полезно для приложений, где важна непрерывность взаимодействия (например, корзины покупок). На изображении эта политика включена для Target Group 2.
6. Обработка различных типов ресурсов
Балансировщик нагрузки может работать не только с EC2-инстансами, но и с другими ресурсами:
* EC2 Instance — виртуальные машины в облаке.
* Container — контейнеры (например, Docker), которые могут быстро масштабироваться.
* S3 Bucket — хранилище объектов (например, для статических файлов, изображений).
