🥇Балансировка на натоварването с AWS ELB

Здравейте на всички! Днес стартира курсът «AWS за разработчици», поради което проведохме съответния тематичен уебинар, посветен на прегледа на ELB. Разгледахме видовете балансировачи и създадохме няколко инстанса EC2 с балансировач. Освен това изучихме и други примери за използване.

След като прослушате уебинара, вие ще:

разбирате какво е AWS Load Balancing;
знаете типовете Elastic Load Balancer и неговите компоненти;
използвате AWS ELB в практиката си.

Защо да умеете това изобщо:

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

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

Въведение

Какво е Elastic Load Balancer можете да видите на диаграмата по-долу, където е представен най-простият пример:

Балансировачът приема заявки и ги разпределя между инстансите. Имаме един отделен инстанс, имаме Lambda функции и имаме автоскейлинг група (група сървъри).

Типове 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 (присъщи на всички балансировачи):

Политика за достъп до журнали

— вашите журнали за достъп до ELB. За да извършите настройките, можете да преминете в описанието и да изберете бутона „Редактиране на атрибути“:

След това посочваме S3Bucket — обектно хранилище на Amazon:

Схема

— вътрешен или външен балансировач. Идеята е, дали вашият LoadBalancer трябва да получава външни адреси, за да бъде достъпен отвън, или това може да бъде вашият вътрешен балансировач;

Групи за сигурност

— контрол на достъпа до балансировача. По същество това е висококачествена защитна стена.

Подмрежи

— подмрежи в рамките на вашия VPC (съответно и зони на достъпност). Подмрежите се задават при създаването. Ако VPC е ограничен до региона, подмрежите са ограничени по зони на достъпност. Когато създавате Load Balancer, е най-добре да го създадете поне в две подмрежи (помага, ако възникнат проблеми с една зона на достъпност);

Чувствителности

— вашите протоколи на балансировача. Както беше споменато по-рано, за 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)

Сега ще разгледаме по-подробно балансировачите от второ поколение 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 правила (правила за маршрутизиране). Това касае само Application Load Balancer. Докато в Network Load Balancer просто създавате Listener и той пренасочва трафика към конкретна Target група, в Application Load Balancer всичко е по-забавно и удобно.

Сега да споменем малко за следващия компонент — Elastic IP (статични адреси за NLB). Ако правилата за маршрутизиране на Listener касаят само 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 можете да прикачите IP адреса и да го посочите в вашите правила, политики и т.н.

Нека направим изводи

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

Основни предимства:

висока наличност. В споразумението за обслужване се подразбира 99,99 % наличност за балансировача на натоварване. Например, множество зони на наличност гарантират, че трафикът ще бъде обработван само от работещи обекти. Всъщност, може да се балансира натоварването и в цялата област, пренасочвайки трафика към работещи целеви обекти в различни зони на наличност;
безопасността. ELB работи с Amazon VPC, предоставяйки различни възможности за осигуряване на сигурност - интегрирано управление на сертификати, автентикация на потребители и декрипция на SSL/TLS. Всичко това осигурява централизирано и гъвкаво управление на настройките за TLS;
еластичност. ELB може да обработва внезапни промени в мрежовия трафик. Дълбоката интеграция с Auto Scaling осигурява на приложението достатъчно ресурси, ако натоварването се променя, без необходимост от ръчна намеса;
гъвкавост. Можете да използвате IP адреси за маршрутизиране на заявки към целевите обекти на вашите приложения. Това гарантира гъвкавост при виртуализирането на целевите приложения, позволявайки разполагането на множество приложения на един инстанс. Тъй като приложенията могат да използват един и същи мрежов порт и имат отделни групи сигурности, взаимодействието между приложенията се опростява, когато имаме архитектура, основана, да речем, на микросервизи;
мониторинг и одит. Можете да следите приложенията в реално време, използвайки функциите на Amazon CloudWatch. Става въпрос за метрики, дневници, проследяване на заявки. Казано просто, ще можете да выявите проблеми и доста точно да определите тесните места в производителността;
хибридно балансиране на натоварване. Възможността за балансиране на натоварването между локални ресурси и AWS с един и същ балансировач опростява миграцията или разширяването на локални приложения в облака. Също така, обработката на откази в облака става по-лесна.

Ако ви интересуват подробности, ето още няколко полезни линка от официалния сайт на Amazon:

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