Все, що потрібно вміти і знати з AWS Elastic LoadBalancer. Детальний гайд

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Ігор і я обіймаю посаду DevOps-інженера в компанії TechMagic з квітня минулого року. Тут і почався мій професійний шлях на цій позиції, хоча до того я займав позицію системного адміністратора та керівника відділу IT Support протягом декількох років, а отже моє знайомство з сервісами AWS, а зокрема з Elastic Load Balancer-ом, відбулось набагато раніше.

Спочатку це були базові задачі з уможливлення функціонування внутрішніх продуктів компанії, які вже згодом, з розширенням інфраструктури, переросли у вузькоспеціалізованіші завдання, включно з налаштуванням Load Balancer.

Сьогодні, я можу широко застосовувати набутий досвід користування, налаштування, коригування роботи ELB вже на клієнтських проєктах, тому в статті поділюсь з вами тими тонкощами роботи ELB, з якими я стикнувся за час своєї роботи і більше.

Вступ

Надіюсь, цей гайд підійде як і початківцям, так і допоможе освіжити в пам’яті інформацію тим інженерам, які вже давно працюють з AWS. Я намагатимусь не використовувати в статті cупернакручених «IT-шних» словечок, щоб матеріал був доступний усім. Тому тут буде всього потрошки: і теорії, і практики, діаграм, прикладів. Тож:

AWS ELB (Elastic Load Balancer) — це сервіс, який регулює трафік та навантаження за запитами, що надходять до ваших AWS серверів та AWS контейнерів. Під капотом Load Balancers — це такі ж самі сервери, ПЗ яких виконують роль регулювальників.

Звісно, можна було б створити окремий сервер з (на Linux чи Ubuntu, whatever), інсталювати на нього море софту для такого регулювання, подбати про безпеку такого сервера, виділити для нього публічну адресу і достатньо хардверних ресурсів (CPU, RAM і Storage), до того ж постійно контролювати чи ці ресурси не простоюють, або ж навпаки, чи їх не замало для об’єму трафіку, що необхідно обробити і регулювати.

Тож, якщо ви не готові цим заморочитись, AWS Elastic Load Balancer вже вміє це робити. Розгортання такого «серверу» ELB займає декілька кліків і 5-10 хв вашого часу.

Особисто я завжди асоціював ці «чудо-сервери» з готельними консьєржами. Ваш ELB — це цифровий віртуальний консьєрж, який проінструктований про правила розподілу гостей, служб, персоналу тощо. Він точно знає, куди відправити відвідувача, щоб ресурси готелю були оптимально використаними. Він знає, про те, в яке крило, корпус, будівлю готелю треба відправити відвідувача, чітко розуміючи яка кімната вільна, її місткість, вигоди, поверх та ін.

Аналогічно до прикладу з консьєржем, і наш ELB знає, як реагувати на запит і куди це відправити.

Наша роль, інженерів, в цьому процесі — правильно «проінструктувати» LoadBalancer з вказівками, який трафік і куди направляти в різних ситуаціях. Чим точніші інструкції, тим якісніше буде розподілятись навантаження.

Трішки історії

Загалом, камінь з плечей інженерів та розробників щодо самостійного налаштування балансування трафіку було частково знято у 2009 році. Тоді компанія AWS представила перше покоління ELB, відомого як «Classic Load Balancer».

Можливості такого балансера поширювались на EC2 інстанси в межах однієї зони доступності (Availability Zone (AZ)). ELB міг виявляти нефункціонуючі (нездорові) екземпляри та перенаправляти трафік на інші. Робота балансера відбувалась на рівні 4 (TCP) та рівні 7 (HTTP/HTTPS).

У 2012 році було введено друге покоління ELB — «Application Load Balancer» (ALB). ALB додав нові можливості, такі як підтримка балансування навантаження на рівні маршруту (routing) і на рівні прослуховування (listener), можливість встановлювати правила перенаправлення на основі URL-адреси, підтримка WebSockets, інтеграція з сервісами AWS, такими як Amazon ECS, Amazon RDS і Amazon SNS, а також розширена можливість моніторингу і агрегації логів.

У 2015 році було введено третє покоління ELB — «Network Load Balancer» (NLB). NLB був спроєктований для розподілу трафіку на рівні 4 на основі IP-адреси, порта і протоколу, що дозволило обробляти мільйони запитів в секунду з мінімальною затримкою. NLB також надавав можливість використовувати статичні IP-адреси.

У грудні 2020 року — анонсовано новий тип Load Balancer-а, який ми знаємо як «Gateway Load Balancer» (GWLB), що допомагає легко розгортати, масштабувати та керувати віртуальними пристроями сторонніх розробників.

Він дає вам один шлюз для розподілу трафіку між декількома віртуальними пристроями, одночасно збільшуючи або зменшуючи їх масштаб залежно від попиту. Це зменшує потенційні точки збою у вашій мережі та підвищує доступність.

Як, ви вже змогли зрозуміти, далі ми будемо говорити саме про ці 4 типи балансувальників:

• Classic Load Balancer.
• Application Load Balancer.
• Network Load Balancer.
• Gateway Load Balancer.

Core concepts

Поглянемо на базові поняття про ELB, призначення і випадки, коли варто застосовувати балансувальники та їх можливості:

Нагадаю, ELB дозволяє регулювати та перенаправляти трафік до ваших серверів чи контейнерів, в залежності від запиту чи навантаженості сервера, на який надсилається запит.

Вище наведений найпростіший варіант роботи ELB. Ми маємо три EC2-сервери, що знаходяться «за» LoadBalancer-ом. Ці сервери ідентичні, та мають точну копію одного і того ж інстальованого на них сервісу (сайту чи вебаплікації).

На іншій стороні ми маємо трьох користувачів, що намагаються комунікувати з бажаним сервісом. Дякуючи ELB, в цьому «ланцюжку» обміну запитами та інформацією відбувається вже анонсоване балансування. Перший запит і трафік, пов’язаний з першим користувачем отримає інформацію з першого сервера, другий користувач отримає необхідні дані з другого серверу, третій — відповідно, з третього.

Усі наступні користувачі, яким буде необхідно також скористатись результатом роботи сервісу, що встановлено на одному з трьох серверів, отримає результат з найменш навантаженого серверу. Користувачі не мають думати і знати про те, з яким сервером необхідно з’єднатись. Все, що вони мають знати, — треба з’єднатись з ELB.

Чому і де варто використовувати LoadBalancer

1. Коли необхідно рівномірно розподілити навантаження між серверами (контейнерами), що функціонують у вашій інфраструктурі.
2. Коли вашим користувачам необхідно забезпечити єдину точку входу до даних та інформації, яку надає ваш вебсервіс (DNS single point of access).
3. Плавно і «безшумно» справлятись з відмовами та помилками, що стаються на ваших сервісах/ серверах. LoadBalancers мають розроблений та імплементований механізм перевірки справності ваших серверів/ сервісів («перевірок здоров’я» або ж «health checks»).
4. Ви можете виконувати регулярні перевірки стану функціонування вашої інфраструктури/ сервісу.
5. Ви можете використовувати шифровану комунікацію з вашими сервісами, використовуючи SSL-сертифікати, додаючи такі сертифікати до ваших ALB «Listeners».
6. LoadBalancer дозволяє використання Stickiness (sticky sessions). Це дозволяє «прив’язати» сеанс користувача до певного сервера/ сервісу.
7. Забезпечує високу доступність (high-availability). Ми можемо розгорнути наші ресурси у різних зонах доступності в межах AWS регіону.
8. Ви можете відсепаровувати приватний (внутрішній) трафік від зовнішнього (публічного) трафіку.

Варто зазначити, що Elastic Load Balancer-ри — це AWS managed балансувальники, тобто за доступність, оновлення та підтримку цього сервісу відповідає саме AWS. Також ELB забезпечує інтеграцію з багатьма іншими сервісами, що забезпечують можливість гнучкої конфігурації балансувальника. Це:

• сервіси обчислення і масштабування, як EC2, EC2 AutoScaling, ECS;
• сервіси захисту та логування трафіку — ACM (SSL certificates manager), AWS CloudWatch, AWS WAF;
• DNS-сервіси та сервіси забезпечення високої продуктивності — AWS Route53 та AWS Global Accelerator;

Типи ELB(Classic, Network, Application, Gateway LoadBalancers)

Як ми вже згадували вище, AWS ELB забезпечує використання трьох типів LoadBalancer-ів. Звичайно, ми згадали 4 типи балансувальників, але сьогодні Classic Load Balancer вважається застарілим. Тому ми все ще можемо зустріти цей тип лоадбалансера в консолі AWS, але все ж зупинимось детальніше на можливостях трьох інших типів балансувальників:

• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer

Application Load Balancer (ALB)

Цей тип ELB підтримує HTTP, HTTPS і WebSocket типи протоколів, відповідно функціонує на 7-му рівні моделі TCP/IP. Балансувальник широко застосовується в роботі з HTTP-сервісами та аплікаціями.

Простими словами — це найкращий варіант при побудові мікросервісів чи базованих на контейнерних технологіях сервісів, з високодоступною, стійкою до відмов та високоефективною інфраструктурою.

Водночас такий цей тип ELB дозволяє балансування трафіку до сервісів, що функціонують в межах однієї машини, до прикладу, контейнерів на ній.

Також ALB підтримує HTTP/2 та WebSocket протоколи.

ALB HTTPS redirects

Дивіться також DevOps Podcast 👇Однією з базових функцій, яку зокрема і ми застосовуємо у своїй роботі, є перенаправлення (redirect) нешифрованого трафіку в зашифрований, іншими словами, HTTP-трафік в HTTPS. Цю можливість ми вже частково зачепили в минулих розділах, а саме в можливості інтеграції ELB з AWS Certificate Manager сервісом.

Саме там ми можемо генерувати безкоштовні SSL сертифікати або ж імпортувати кастомні (придбані або згенеровані на інших провайдерах Secure Sockets Layer сертифікати). Про те, як реалізувати таку функцію, поговоримо згодом.

ALB Target groups routes

Розглянемо базовий варіант розвитку подій, коли нам треба отримати результат роботи вебсервісу, що функціонує на базі EC2 сервера і наочно спробуємо зрозуміти послідовність кроків між надсиланням запиту користувачем і отриманням запиту вебсервісом:

1. Користувач звертається на адресу вебресурсу. Відповідно формується HTTP-запит на порт 80 (стандартний для HTTP трафіку). Запит скеровується на DNS сервер, в якому має міститись інформація, де ж саме знаходиться потрібний нам ресурс. У AWS, за такі доменні записи відповідає сервіс під назвою AWS Route 53.

2. В записах відповідної Hosted-зони запит знаходить потрібний нам рекорд.

3. У вищезгаданому рекорді вказана інформація, що ресурси для такої адреси знаходяться «за» публічним DNS-імʼям Application Load Balancer-а. Ми вже згадували про такий «DNS single point of access» для ALB раніше.

4. Наступним кроком запит спрямовується безпосередньо до балансувальника і проходить перевірку на відповідність правилам Security-групи (налаштування безпеки трафіку). Якщо правила дозволяють трафік з IP-адреси, з якої прийшов запит, та порт, на який надходить запит — потрапляємо на ALB.

5. Якщо ALB має Listener, який «слухає» (очікує) запит на порт 80, (а ми надіслали запит саме на цей порт), то виконує інструкції, вказані в правилах (Rules) для цього Listener-a. Про види таких правил і їхню конфігурацію ми ще невдовзі поговоримо.

6. У нашому випадку ми вказали в правилі для listener-а на порті 80, що всі запити, які потрапляють на порт 80, переспрямовувати (редіректити) на Listener, що «слухає» на порті 443. А це, як нам вже відомо, — порт для HTTPS-трафіку, тобто шифрованого. Надалі цей listener вже віддаватиме результат за запитом в зашифрованому вигляді, і зашифрує всі дані прикріпленим до listener-а на 443 порту ключем SSL-сертифікату.

7. У правилах для listener-a на порту 443 сказано, що всі запити, які надійдуть на такий порт з хостовою частиною, яка відповідає нашому доменному імені, — переправляти (форвадити) на таргет-групу (target group). Target Group — це набір потрібних нам ресурсів, об’єднаних в одну групу. У нашому випадку це Target group з EC2-інстансами. На одному з них наш запит знайде потрібний сервіс. На якому саме, запитаєте ви? Так, саме на найменш навантаженому, адже в цьому і полягає суть балансування навантаження і ELB володіє рядом інструментів, щоб оцінити таке навантаження, а також ряд перевірок на функціональність (health-checks).

Після усіх вищезгаданих кроків, за умови успішних перевірок трафіку на безпеку потрібного listener-а, правил, ресурсів, користувач отримає дані у відповідь.

Надалі ми ускладнюватимемо наші задачі, щоб наочно і практично ознайомитись з усіма можливостями, що нам пропонує ALB.

Уявімо, що з часом наша інфраструктура обростає новими і новими сервісами і нам якимось чином треба віддавати результат роботи цих сервісів, але володіємо ми лиш одним доменом, для прикладу назвемо наш домен blablabla.com.

Логічно, що основним доменним ім’ям ми вже не можемо скористатись, оскільки за ним знаходиться наш основний вебресурс.

Тому нам доведеться використати інші типи адрес, як-от:

• нові саб-домени для інших сервісів (наприклад one.blablabla.com);
• доступ до сервісу за новими шляхами (path) в URL-адресі (наприклад blablabla.com/two);
• отримувати відповіді від сервісів за Query Strings (blablabla.com/user?id=....).

Також ми можемо налаштувати роутинг трафіку за походженням, наприклад за IP-адресою, з якої прийшов запит, HTTP-header-ом, HTTP-request методом.

Для прикладу, розглянемо декілька типів умов у правилах (Rules) ALB listener-ів.

Умова хостової частини (host part) в URL-адресі

Для відображення сутності цього типу правила я продемонструю налаштування для нього в реальних умовах:

Конфігурація даного правила listener-a, для трафіку, який потрапляє на port 443 з хостовою частиною one.blablabla.com перенаправить трафік, що надійшов на target group з назвою bla-target group в якій, до прикладу, можуть знаходитись потрібні нам сервери чи контейнери.

Умова збігу шляхової частини (path part) в URL-адресі

Для цього правила ми змінимо завдання, для кращого розуміння, які дії ми можемо застосувати, якщо умова в правилі для вхідного трафіку справджується. Наприклад, ми хочемо отримувати фіксовану відповідь для усіх запитів, що звертаються на адресу blablabla.com/error.

Текст відповіді при зверненні на таку сторінку має бути «Not found», а код помилки — 404. Нижче наглядно продемонстровано, як виглядає конфігурація правила Listener-a для такого типу правила та поведінки:

Якщо ж нам треба все ж перенаправляти такий запит на сервіс чи статичну сторінку, ми можемо редагувати правило та вибрати потрібний для нас тип дії при справджуванні умови правила. Для цього достатньо видалити поточний Action і додати новий, з типом дії Forward, Redirect чи ін.

Умова правила, базованого на IP-адресі, з якої походить трафік

З конфігурації цього правила можемо здогадатись, що для трафіку, який походить з <Source IP> треба виконати автентифікацію за допомогою Amazon Cognito сервісу.

Обмеження для правил Listener-ів ALB

Усього можливо застосувати 100 правил для балансування навантаження, при цьому кожне правило може мати максимально 5 умов, 5 wildcards (*) на кожне правило, а також 5 target groups, що можуть бути прикріплені до одного правила.

Network Load Balancer

Для цього типу балансувальників підтримуваними протоколами є TCP, TLS (secure TCP), UDP, тож відповідно функціонує на 4-му рівні TCP/IP мережевої моделі.

Якщо вам необхідно забезпечити високу ефективність балансування і розподілу трафіку, цей тип є найкращим рішенням. Затримка обробки і доставки трафіку при використанні NLB складає приблизно 100 ms, (для ALB — це приблизно 400 ms).

NLB забезпечує виділення однієї статичної IP-адреси для кожної Availability Zone, а також пропонує опцію використання ElasticIP (виділеної IP-адреси).

Часто Network Load Balancer застосовують у зв’язці з Application Load Balancer. Інфраструктурний ланцюжок для такої співпраці виглядає так: NLB — ALB — Target Groups — Services. Коли ми ставимо NLB перед ALB — це дозволяє нам користуватись Static IP чи Elastic IP. Отже, дякуючи NLB, ми отримуємо можливість звертатись до ALB за IP адресою.

Однак ALB може володіти статичною IP-адресою і без застосування NLB, оскільки все ще зберігається опція застосування інтеграції з AWS Global Accelerator, але таке рішення є дещо дорожчим.

Для такої зв’язки необідно створити нову Target групу з типом target-у «Application Load Balancer». ALB обовʼязково має мати listener на порту 80.

Gateway Load Balancer

Цей тип ELB функціонує на 3 рівні TCP/IP моделі, тобто використовує IP-протокол. Це найновіший тип Load Balancer-ів і використовується для розгортання і керування 3-rd party віртуальними мережевими сервісами, такими як Firewall-забезпечення, аналізатори пакетів даних, системи виявлень та запобігання вторгненням в інфраструктуру та сервіси тощо.

GWLB дозволяє «прогнати» ваш трафік і запити через сторонні сервіси захисту інформації, а також проаналізувати трафік на наявність зловмисного вмісту, перед тим як він опиниться у ваших сервісах.

Наголошу, що робота балансувальника такого типу відбувається на 3-му , мережевому рівні моделі tcp/ip, а отже аналіз даних відбувається також на цьому рівні, тобто відбувається обробка IP-пакетів даних.

Детальніше процедура такого аналізу трафіку зображена на базовій діаграмі вище. Тут ми вказали правило в VPC Subnet Route Table, що весь трафік, який надійде з усього Інтернету, слід направити на Gateway Load Balancer Endpoint. З ендпоінту трафік буде перенаправлено в Gateway-балансувальник, який своєю чергою розподілить трафік у таргет групу з серверами (контейнерами), на яких проінстальовано пакетні аналізатори.

GWLB також може використовувати можливості AWS Autoscaling Group. Це означає, що ми можемо легко масштабувати наші 3-rd party appliances в залежності від потреб та необхідної кількості трафіку, що потрібно проаналізувати.

При створенні Target group-и з такими аналізаторами слід вибирати Geneve протокол, що працює на порті 6081. Типами таргетів в target group можуть бути EC2 інстанси чи IP-адреси.

Sticky sessions (Sessions affinity)

Stickiness — це опція ELB, яка дозволяє «утримувати» (зберігати сесію) з’єднання клієнта з однією і тією ж машиною (сервером). Застосувати це можна, використовуючи Application Load Balancer та Network Load balancer у випадках, коли ми не хочемо, щоб дані, що використовуються в поточному з’єднанні (сесії) були втрачені.

Щоб реалізувати це, «під капотом» використовуються «cookies» (це невеликі текстові файли, які зберігаються на вебпереглядачі комп’ютера користувача, коли він відвідує сайти), час життя яких ми можемо регулювати в налаштуваннях Sticky Sessions. ELB cookies поділяються на 2 типи:

• Application-based cookies — бувають Custom-типу (згенеровані сервісом) і Application-типу (згенеровані балансувальником);
• Duration-based cookies — згенеровані LoadBalancer-ом і базовані на показнику продовжуваності життя (expiration time) такого cookie.

Та все ж варто бути обережними з активуванням цієї опції, оскільки це може призвести до перенавантаження однієї з «машин» в таргет-групі.

Щоб активувати таку опцію, слід перейти на рівень Target Group сервісу EC2 і поредагувати Target Group attributes:

Кросзональне балансування (Cross-zone load balancing)

Уявімо нашу інфраструктуру, кінцеві «машини» в якій знаходяться в Target group-ах в різних зонах доступності (availability zones (AZs)). ELB дозволяє балансування трафіку не тільки між машинами, а ще й між AZ.

Щоб розглянути відмінності принципів роботи з увімкненим кросзональним балансуванням і вимкнутим, погляньмо на high-level діаграму нижче:

• Для активованого Cross-az балансування, розподіл навантаження відбувається більш рівномірно, тобто загальне навантаження серверів (контейнерів) рівномірно розподіляється на всі «машини», що доступні для нас в різних зонах. В нашому випадку на кожну з 10 робочих машин припаде 10% від загального трафіку/ навантаження.
• Для НЕ активованого Cross-az балансування, розподіл навантаження відбувається за принципом початкового поділу навантаження між серверами ELB в різних AZ. Тобто, в цьому випадку трафік поділиться не між машинами, як в минулому варіанті, а спочатку між «нодами» балансувальника в різних AZ, а вже потім навантаження на кожну «ноду» рівномірно розподіляється між машинами в target group. Тож бачимо, що в одній AZ «машини» навантажені більше, а в іншій — менше.

Варто зазначити, що для ALB, кросзональне балансування увімкнуте за замовчанням, оскільки за балансування трафіку між AZ не стягується плата. Для NLB і GWLB — балансування вимкнуте в налаштуваннях за замовчанням. Якщо ви все ж увімкнете цю опцію, оплата для таких типів ELB стягуватиметься за дані, що трансферуються між зонами доступності.

Змінити дане налаштування можна в меню Attributes в консолі управління та налаштування ELB для Network Load Balancer i Gateway Load Balancer. Для Application Load Balancer-а значення за замовчуванням можна вимкнути на рівні Target Group, змінивши Target Group attributes опцію кросзонального балансування з успадковування налаштувань з LoadBalancer на потрібну вам опцію.

SSL-сертифікати та ELB

SSL-сертифікати (Secure Socket Layer) є цифровими сертифікатами, які забезпечують захищене з’єднання між веббраузером користувача та вебсервером. У нашому ж випадку SSL-сертифікати дозволяють встановлювати захищене з’єднання між користувачем та ELB.

ALB і NLB дозволяють використання такого сертифікату. Найпростішим рішенням для реалізації захищеного з’єднання є використання згенерованих в ACM (AWS Certificates Manager) SSL-сертифікатів або ж додавати до ACM сертифікат, виданий зовнішнім реєстратором SSL-сертифікатів (Comodo, GoDaddy, Letsencrypt та ін.)

Приємно те, що ACM сертифікати — безкоштовні, не потребують періодичного оновлення, AWS забезпечує автоматичне оновлення таких сертифікатів. Інша сторона медалі для таких сертифікатів — ви не зможете їх експортувати, а лише прикріпляти до таких сервісів як: Elastic Load Balancer, CloudFront, API Gateway.

Налаштування і генерація такого сертифікату займає декілька хвилин, включно з DNS-верифікацією факту власності домену, для якого видається сертифікат.

Для додавання сертифіката до нашого балансувальника достатньо створити лістенер на порту 443 (протокол TLS or HTTPS) і вказати, який саме сертифікат ви хочете використовувати для запитів, які надходять на такий «прослуховувач» (listener).

Базове налаштування шифрованого трафіку виглядатиме так: створюється listener на 80-му порті, де ми налаштовуємо правило, що весь трафік, який потрапить на даний лісенер, перенаправляти на порт 443 (до якого ми вже прикріпили сертифікат).

Як результат, кінцевий користувач, що звертається, до прикладу, на адресу blablabla.com (а насправді повна адреса такого запиту blablabla.com, наголошую, відбувається саме HTTP-запит) відправляє запит до 80-го порту ELB. Там, як ми вже знаємо, є правило вищезгаданого перенаправлення усього трафіку на порт 443.

В результаті користувач зможе побачити, що адреса в адресному рядку браузера змінилась з blablabla.com на httpS://blablabla.com, a поруч з’явився заповітний green-bar з іконкою замочка.

Під капотом браузер користувача отримає екземпляр SSL- сертифікату, проведе перевірку, чи такий сертифікат зареєстровано, чи його термін придатності не вийшов і чи тіло сертифіката коректне. Якщо такі перевірки пройдуть успішно — це означатиме, що наш трафік тепер безпечний та зашифрований.

SSL-SNI (Server Name Identifiator)

Опція SNI дозволяє нам використовувати декілька SSL-сертифікатів в одному і тому ж ELB. Цей протокол відповідає за визначення клієнтом хостового імені (доменного імені) цільового сервера при ініціюванні безпечного зʼєднання.

Іншими словами, завдяки SNI-протоколу в ELB, відповідь на клієнтський запит за адресою, наприклад, bird.dev.abrakadabra.com, повернеться саме з сертифікатом для ресурсу з адресою *.dev.abrakadabra.com.

Якщо ж наступного разу клієнт зробить запит на адресу one.blablabla.com, він отримає результат вже з SSL- сертифікатом для доменного імені *.blablabla.com.

Нижче відображено реальну конфігурацію multi-сертифікатного налаштування для Listenera на порті 443 ALB :

ELB connectivity troubleshooting

Не секрет, що інколи може статись неочікувана поведінка ELB, наприклад, клієнти отримують у відповіді на запити невідомі помилки, або у вас є підозра, що на ваші сервіси можуть мати доступ небажані користувачі, або ж ефективність вашого ALB значно погіршилась.

Все це одразу спонукає шукати, де ж знаходяться метрики балансувальника, або куди агрегуються записи журналу (логи).

Звісно, можна одразу передивитись метрики вашого ELB (вкладка Monitoring або перейти в CloudWatch-метрики) і за знайденими метриками звужувати коло пошуку проблеми.

Якщо ж хочете копати глибше — слід проаналізувати логи. Найпростіший варіант — знайти вкладку Description для вашого балансувальника і знайти інформаційне поле під назвою «Access logs». Там буде вказано назву S3 бакета, в який агрегуються записи доступу до вашого ELB.

В цьому S3 бакеті ви знайдете усі необхідні записи, щоб зрозуміти природу проблеми. Але є одне але: такий пошук буде зробити вкрай важко, адже дані в файлах записів мають велику кількість інформації та, часто, невідомі атрибути.

Тут я рекомендую скористатись можливостями сервісу AWS Athena — це сервіс аналітики на основі SQL, який надає можливість виконувати запити до даних, збережених в Amazon S3, без необхідності створювати та керувати базами даних.

За ось цими двома посиланнями [1] і [2], ви швидко дізнаєтесь як створюються Athena-таблиці, і як витягувати необхідні дані із записів доступу до Load Balancer-ів.

Нижче я продемонструю базовий запит, який дозволить нам переглянути останні 10 записів доступу до ALB, код відповіді яких 5ХХ:

В результаті, ми маємо отримати «читабельний» результат, що дозволить нам проаналізувати 5ХХ помилки за атрибутами, такими як: часовий маркер запису, клієнтський порт, цільовий порт IP-адреса походження трафіку та ін.

Загалом, ви можете сформувати запит, користуючись чисельними опціями, що пропонує AWS Athena. Нижче, я наведу декілька додаткових прикладів таких запитів:

• Запит покаже нам, як отримати записи від найбільшої до меншої кількості target_processing_time у часовому діапазоні від 2022-10-10-12:00:00 до 2022-10-11-00:00:00;

• Запит покаже усі request_url, куди кінцеві користувачі надіслали його за допомогою веббраузера Safari;

Вартість рішення

Підсумовуючи, хотілось би додати декілька слів про цінову політику використання AWS EL

B. Одразу скажу, для тих, хто вирішить реалізовувати власні «балансувальні» рішення — зробити дешевше ніж це пропонує AWS ELB навряд чи вдасться. Оскільки користувач ELB не повинен думати про підтримку, оновлення чи оптимізацію ресурсів балансувальника.

Цінова політика AWS ELB базується на використанні. За використання ELB стягується плата, яка залежить від кількості годин, коли ELB використовувався для балансування навантаження. Крім того, за трафік, який проходить через ELB, також стягується плата.

Але, думаю, краще за цінову політику ніж сам AWS ніхто не зможе розказати. Тому рекомендую перейти за посиланням та ознайомитися детальніше.

Тут ви знайдете цінники і умови в залежності від типу балансування навантаження, який використовується (Application Load Balancer, Network Load Balancer або Classic Load Balancer), кількості запущених екземплярів EC2, обсягу трафіку та регіону, в якому використовується ELB. А також на сторінці наведено декілька прикладів розрахунку прайсингу.