Балансировка нагрузки с помощью 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.
    OTUS. Онлайн-образование
    Цифровые навыки от ведущих экспертов

    Похожие публикации

    Комментарии 0

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

    Самое читаемое