Всім привіт! Вже сьогодні стартує курс
- розуміти, що таке 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:
- Схема
- Внутрішній або зовнішній балансувальник. Сенс у тому, чи повинен ваш LoadBalancer отримати зовнішні адреси, щоб бути доступним зовні, чи це може бути ваш внутрішній балансувальник;
- Групи безпеки
- Контроль доступу до балансувальника. По суті, це високорівневий файрвол.
- Підмережі
- Підмережі всередині вашої VPC (відповідно, і зони доступності). Subnets вказується під час створення. Якщо VPC обмежені регіоном, Subnets обмежений по зонах доступності. Коли створюєте 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)
Тепер докладніше розглянемо балансувальники 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 все
Тепер скажемо пару слів про наступний компонент. Еластичний 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 змінився.
Ось
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