Балансировка нагрузки с помощью AWS ELB

Всем привет! Уже сегодня стартует курс «AWS для разработчиков», в связи с чем мы провели соответствующий тематический вебинар, посвященный обзору ELB. Мы рассмотрели виды балансировщиков и создали несколько инстансов EC2 с балансировщиком. А также изучили другие примеры использования.

Прослушав вебинар, вы будете:

• понимать, что такое AWS Load Balancing;
• знать типы Elastic Load Balancer и его компоненты;
• использовать AWS ELB в вашей практике.

Зачем вообще это уметь:

• полезно, если планируете сдавать экзамены сертификации AWS;
• это простой способ распределения нагрузки между серверами;
• это простой способ добавления Lambda в ваш сервис (ALB).

Открытый урок провёл Ришат Терегулов, системный инженер в маркетинговой компании по разработке и поддержке сайтов.

Введение

Что такое Elastic Load Balancer, можно увидеть на диаграмме ниже, где представлен простейший пример:

Load Balancer принимает реквесты и распределяет их по инстансам. У нас есть один отдельный инстанс, есть Lambda-функции и есть AutoScaling-группа (группа серверов).

Типы AWS ELB

1. Рассмотрим основные типы:

Classic Load Balancer. Самый первый балансировщик от AWS, работает как на 4-м, так и на 7-м уровне OSI, поддерживаются HTTP, HTTPS, TCP и SSL. Он обеспечивает базовую балансировку нагрузки между несколькими инстансами Amazon EC2 и работает как на уровне запросов, так и на уровне соединения. Давайте его откроем (выделен серым):

Этот балансер считается устаревшим, поэтому рекомендуется к использованию лишь в отдельных случаях. Например, для приложений, которые были построены в сети EC2‑Classic. В принципе, нам никто не мешает его создать:

2. Network Load Balancer. Подходит для высокой нагрузки, работает на 4-м уровне OSI (можно использовать в EKS и ECS), поддерживаются TCP, UDP и TLS.

Network Load Balancer направляет трафик на целевые объекты в Amazon VPC и способен обрабатывать миллионы запросов в секунду при сверхнизких задержках. Кроме того, он оптимизирован для обработки моделей трафика с внезапной и изменяющейся нагрузкой.

3. Application Load Balancer. Работает на 7-м уровне, имеет поддержку Lambda, поддерживает правила на уровне заголовков и путей, поддерживаются HTTP и HTTPS.
Обеспечивает расширенную маршрутизацию запросов, ориентированную на доставку приложений, построенных на базе современных архитектур, в том числе микросервисы и контейнеры. Направляет трафик на целевые объекты в Amazon VPC, опираясь на содержимое запроса.

Для многих пользователей, Application Load Balancer первым делом заменил Classic Load Balancer, ведь TCP не так распространен в отличие от HTTP.

Создадим его тоже, в результате чего у нас уже будут два балансировщика нагрузки:

Компоненты Load Balance

Общие компоненты Load Balance (присущи всем балансировщикам):

• Access Logging Policy

— ваши журналы доступа к ELB. Чтобы выполнить настройки, можно перейти в Description и выбрать кнопку «Edit attributes»:

Потом указываем S3Bucket — объектное хранилище Amazon:

• Scheme

— внутренний или внешний балансировщик. Смысл в том, должен ли ваш LoadBalancer получить внешние адреса, чтобы быть доступным снаружи, или это может быть ваш внутренний балансировщик;

• Security Groups

— контроль доступа к балансировщику. По сути это высокоуровневый файрвол.

• Subnets

— подсети внутри вашей VPC (соответственно, и зоны доступности). Subnets указывается при создании. Если VPC ограничены регионом, то Subnets ограничен по зонам доступности. Когда создаете Load Balancer, лучше создавать его по крайней мере в двух подсетях (помогает, если с одной зоной доступности возникнут проблемы);

• Listeners

— ваши протоколы балансировщика. Как уже было сказано ранее, для Classic Load Balancer это может быть HTTP, HTTPS, TCP и SSL, для Network Load Balancer — TCP, UDP и TLS, для Application Load Balancer — HTTP и HTTPS.

Пример для Classic Load Balancer:

А вот в Application Load Balancer мы видим и немного другой интерфейс, и в целом другую логику:

Компоненты Load Balancer v2 (ALB и NLB)

Теперь подробнее рассмотрим балансировщики 2-й версии Application Load Balancer и Network Load Balancer. У этих балансировщиков есть свои компонентные особенности. Например, появилось такое понятие, как Target Groups — инстансы (и функции). Благодаря этому компоненту, у нас появилась возможность указывать, на какой из Target Groups мы хотим направлять трафик.

Говоря простым языком, в Target Groups мы указываем инстансы, куда будет приходить трафик. Если в том же Classic Load Balancer вы просто сразу подключаете интенсы к балансировщику, то в Application Load Balancer вы сначала:

• создаете Load Balancer;
• создаете Target-группу;
• направляете по нужным портам или правилам Load Balancer на нужные Target Groups;
• в Target-группах назначаете инстансы.

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

Следующий компонент — Listener rules (правила для маршрутизации). Это уже касается только Application Load Balancer. Если в Network Load Balancer вы просто создаете Listener, и он шлет трафик на конкретную Target-группу, то в Application Load Balancer всё веселее и удобнее.

Теперь скажем пару слов про следующий компонент — Elastic IP (статические адреса для NLB). Если правила для маршрутизации Listener rules касались только Application Load Balancer, то Elastic IP касается только Network Load Balancer.

Создадим Network Load Balancer:

И как раз в процессе создания мы увидим, что нам дается возможность выбрать Elastic IP:

Elastic IP предоставляет единственный IP-адрес, который можно связать с разными экземплярами EC2 во времени. Если экземпляр EC2 имеет Elastic IP-адрес и этот экземпляр завершен или остановлен, можно немедленно связать новый экземпляр EC2 с адресом Elastic IP. При этом ваше текущее приложение не прекратит работу, так как приложения видят всё тот же IP-адрес, даже если реальный EC2 изменился.

Вот еще один юз-кейс на тему того, зачем нужен Elastic IP. Смотрите, мы видим 3 IP-адреса, но они не навсегда здесь останутся:

Amazon меняет их с течением времени, может делать это каждые 60 секунд (но на практике, конечно, реже). Значит, IP-адреса могут поменяться. А в случае с Network Load Balancer вы как раз можете привязать айпишник и указывать его в ваших правилах, политиках и т. п.

Делаем выводы

ELB обеспечивает автоматическое распределение входящего трафика по нескольким целевым объектам (контейнеры, инстансы Amazon EC2, IP‑адреса и функции Lambda). ELB способен распределять трафик с меняющейся нагрузкой как в одной зоне доступности, так и между несколькими зонами доступности. Пользователь может выбрать из трёх типов балансировщиков, обеспечивающих и высокую доступность, и автомасштабирование, и неплохую защиту. Всё это важно для обеспечения отказоустойчивости ваших приложений.

Основные плюсы:

• высокая доступность. В соглашении об обслуживании подразумевается 99,99 % доступности для балансировщика нагрузки. Например, несколько зон доступности гарантирует, что трафик будет обработан только исправными объектами. Собственно говоря, можно балансировать нагрузку и по всему региону, осуществляя перенаправление трафика на исправные целевые объекты в различных зонах доступности;
• безопасность. ELB работает с Amazon VPC, предоставляя разные возможности по обеспечению безопасности — это и интегрированное управление сертификатами, и аутентификация пользователей, и расшифровка SSL/TLS. Всё вместе обеспечивает централизованное и гибкое управление настройками TLS;
• эластичность. ELB может выполнять обработку внезапных изменений сетевого трафика. А глубокая интеграция с Auto Scaling дает приложению достаточно ресурсов, если меняется нагрузка, причем ручное вмешательство не потребуется;
• гибкость. Можно применять IP‑адреса для маршрутизации запросов к целевым объектам ваших приложений. Это гарантирует гибкость при виртуализации целевых приложений, давая таким образом возможность размещать сразу несколько приложений на одном инстансе. Так как приложения могут использовать один сетевой порт и имеют отдельные группы безопасности, упрощается взаимодействие между приложениями, когда у нас архитектура, допустим, на основе микросервисов;
• мониторинг и аудит. Можно осуществлять мониторинг приложений в реал-тайме, используя функции Amazon CloudWatch. Речь идёт о метриках, журналах, отслеживании запросов. Говоря простым языком, вы сможете выявлять проблемы и довольно точно определять узкие места производительности;
• гибридная балансировка нагрузки. Возможность балансировки нагрузки между локальными ресурсами и AWS с применением одного и того же балансировщика упрощает миграцию либо расширение локальных приложений в облако. Упрощается и обработка отказов с применением облака.

Если интересуют подробности, вот еще пару полезных ссылок с официального сайта Amazon:

1. Elastic Load Balancing.
2. Возможности Elastic Load Balancing.

Источник: habr.com