Всем привет! Уже сегодня стартует курс «AWS для разработчиков», в связи с чем мы провели соответствующий тематический вебинар, посвященный обзору ELB. Мы рассмотрели виды балансировщиков и создали несколько инстансов EC2 с балансировщиком. А также изучили другие примеры использования.
Прослушав вебинар, вы будете:
Зачем вообще это уметь:
Открытый урок провёл Ришат Терегулов, системный инженер в маркетинговой компании по разработке и поддержке сайтов.
Что такое Elastic Load Balancer, можно увидеть на диаграмме ниже, где представлен простейший пример:
Load Balancer принимает реквесты и распределяет их по инстансам. У нас есть один отдельный инстанс, есть Lambda-функции и есть AutoScaling-группа (группа серверов).
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 (присущи всем балансировщикам):
Потом указываем S3Bucket — объектное хранилище Amazon:
Пример для Classic Load Balancer:
А вот в Application Load Balancer мы видим и немного другой интерфейс, и в целом другую логику:
Теперь подробнее рассмотрим балансировщики 2-й версии Application Load Balancer и Network Load Balancer. У этих балансировщиков есть свои компонентные особенности. Например, появилось такое понятие, как Target Groups — инстансы (и функции). Благодаря этому компоненту, у нас появилась возможность указывать, на какой из Target Groups мы хотим направлять трафик.
Говоря простым языком, в Target Groups мы указываем инстансы, куда будет приходить трафик. Если в том же Classic Load Balancer вы просто сразу подключаете интенсы к балансировщику, то в Application Load Balancer вы сначала:
Такая логика работы может показаться сложнее, но на самом деле она удобнее.
Следующий компонент — 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 способен распределять трафик с меняющейся нагрузкой как в одной зоне доступности, так и между несколькими зонами доступности. Пользователь может выбрать из трёх типов балансировщиков, обеспечивающих и высокую доступность, и автомасштабирование, и неплохую защиту. Всё это важно для обеспечения отказоустойчивости ваших приложений.
Основные плюсы:
Если интересуют подробности, вот еще пару полезных ссылок с официального сайта Amazon:
Прослушав вебинар, вы будете:
- понимать, что такое 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
Потом указываем S3Bucket — объектное хранилище Amazon:
- Scheme
- Security Groups
- Subnets
- Listeners
Пример для 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:
