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

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

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

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

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

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

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

Въведение

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

Политика за достъп до логове

— вашите логове за достъп до ELB. За да настроите, можете да отидете в Description и да изберете бутона «Edit attributes»:

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

Схема

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

Security Groups

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

Подмрежи

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