AWS Elastic Load Balancing — co to jest i jak działa?

Czym jest Elastic Load Balancing?

Elastic Load Balancing (ELB) to zarządzana usługa Amazon Web Services, która przyjmuje przychodzący ruch od klientów i rozdziela go między zarejestrowane cele — instancje EC2, kontenery, funkcje Lambda i adresy IP — w jednej lub kilku Availability Zones.

Zgodnie z dokumentacją AWS usługa monitoruje kondycję celów i kieruje ruch wyłącznie do tych zdrowych, a swoją pojemność skaluje sama, w reakcji na zmiany natężenia ruchu.

Ważne, czym ELB nie jest: to nie serwer aplikacyjny i nie uruchamia Twojej logiki biznesowej. To zarządzana warstwa dystrybucji ruchu, umieszczona pomiędzy klientami a zasobami, które faktycznie obsługują aplikację.

Klient łączy się z jednym punktem wejścia. To, ile maszyn stoi za tym punktem i które z nich aktualnie żyją, pozostaje dla niego niewidoczne.

ELB to zarazem nazwa całej rodziny usług, a nie pojedynczego produktu — o czym za chwilę. Pierwotny load balancer (dziś Classic Load Balancer) pojawił się w 2009 roku, a kolejne, wyspecjalizowane typy dochodziły z czasem. Historia jest tu jednak drugorzędna — liczy się to, jak dobrać właściwy typ do zadania.

Po co nam load balancer?

Pojedynczy serwer ma dwie fundamentalne słabości: skończoną pojemność i status pojedynczego punktu awarii. Gdy pada, pada cała aplikacja.

Load balancer rozwiązuje oba problemy naraz — rozkłada obciążenie na wiele zasobów i, dzięki health checkom, automatycznie omija te, które przestały odpowiadać.

W architekturze AWS load balancer jest zwykle bramą między publicznym internetem a Twoją flotą serwerów. Pozwala trzymać maszyny w prywatnych podsieciach, dodawać je i usuwać bez przerywania obsługi żądań, a także przejąć na siebie kosztowną terminację TLS^?terminację TLS: rozszyfrowanie ruchu HTTPS na load balancerze — serwery aplikacji odbierają już odszyfrowany ruch HTTP i nie muszą zajmować się kryptografią. To niewidzialna warstwa, od której zależy, czy serwis w ogóle działa pod obciążeniem.

Rodzina ELB: ALB, NLB, GWLB i Classic

To najważniejsze rozróżnienie w całym temacie: Elastic Load Balancing to nazwa usługi/rodziny, w ramach której masz cztery typy load balancerów, różniące się głównie warstwą modelu OSI, na której działają. Zgodnie z zestawieniem funkcji AWS:

Różnica między ALB a NLB to nie niuans, tylko odmienny model działania.

ALB rozumie treść żądania HTTP i wybiera cel algorytmem round robin^?round robin: rozdziela żądania kolejno, po równo między dostępne cele (domyślnie) lub least outstanding requests^?least outstanding requests: kieruje nowe żądanie do celu z najmniejszą liczbą trwających żądań.

NLB działa na warstwie 4: dla każdego połączenia wybiera cel algorytmem flow hash^?flow hash: wybiera cel na podstawie stałych cech połączenia, tak że całe połączenie trafia zawsze do tego samego celu (na podstawie protokołu, adresów i portów źródła i celu oraz numeru sekwencyjnego TCP) i trzyma to połączenie na jednym celu przez cały jego czas życia.

GWLB nie terminuje ruchu — przepuszcza go do urządzeń bezpieczeństwa innych producentów, używając enkapsulacji GENEVE^?GENEVE: protokół tunelujący pakiety do urządzeń bezpieczeństwa bez ich modyfikacji na porcie 6081.

Ponieważ ALB jest najczęstszym wyborem dla aplikacji HTTP/HTTPS, na jego przykładzie wyjaśnimy dalej pojęcia listenera, reguł i grup docelowych.

Jak działa ALB: od listenera do celu

To najważniejszy model mentalny dla ALB. Ruch przechodzi przez łańcuch elementów:

Listener nasłuchuje połączeń na wskazanym protokole i porcie. Do listenera przypisujesz reguły, z których każda ma priorytet, warunek i akcję; każdy listener musi mieć regułę domyślną.

Grupa docelowa kieruje żądania do zarejestrowanych celów i to na jej poziomie konfiguruje się health checki. Po odebraniu żądania ALB ocenia reguły w kolejności priorytetów i wybiera cel z odpowiedniej grupy.

Routing w ALB: host, ścieżka, nagłówek, parametr

Właśnie routing oparty na treści żądania czyni z ALB usługę warstwy 7 i naturalny front-end mikroserwisów. Jeden load balancer może kierować różne ścieżki do różnych grup:

Reguły dopasowują żądania po:

• ścieżce URL
• nagłówku Host (wiele domen za jednym balancerem)
• nagłówkach HTTP
• metodzie
• parametrach zapytania
• źródłowym adresie IP

Sama ALB potrafi ponadto:

• przekierowywać ruch
• zwracać stałe odpowiedzi
• uwierzytelniać użytkowników
• współpracować z AWS WAF

Health checks — ELB wykrywa, nie naprawia

Health check to okresowa sonda na poziomie grupy docelowej, sprawdzająca, czy cel odpowiada poprawnie. Zgodnie z dokumentacją: gdy load balancer wykryje niezdrowy cel, przestaje kierować do niego ruch, a wznawia dopiero, gdy cel wraca do zdrowia.

To mechanizm, który odróżnia load balancer od prostego rozdzielacza — decyzje o kierowaniu są ciągle korygowane realnym stanem maszyn.

Kluczowe rozróżnienie: ELB niczego nie naprawia. Wykrywa problem i omija cel, ale to Auto Scaling Group^?Auto Scaling Group: usługa AWS utrzymująca zadaną liczbę instancji EC2 — sama dodaje i usuwa maszyny może wymienić uszkodzoną instancję.

Availability Zones i cross-zone load balancing

Gdy włączasz Availability Zone, ELB tworzy w niej węzeł load balancera. Wysoką dostępność buduje się, rozpinając balancer na wielu Availability Zones — ale wymagania różnią się per typ. ALB wymaga co najmniej dwóch Availability Zones. NLB może działać nawet w jednej, choć dla odporności zaleca się wiele.

Cross-zone load balancing decyduje, czy węzeł z jednej Availability Zone może kierować ruch do celów w innych Availability Zones. Bez niego węzeł obsługuje tylko cele w swojej Availability Zone — co przy nierównej liczbie maszyn prowadzi do nierównego rozłożenia ruchu.

Internet-facing vs internal

Przy tworzeniu load balancera wybierasz jeden z dwóch schematów:

• Internet-facing — węzły mają publiczne adresy IP i przyjmują ruch z internetu; nazwa DNS rozwiązuje się na adresy publiczne.
• Internal — ma tylko adresy prywatne i obsługuje wyłącznie klientów z dostępem do VPC^?VPC: Virtual Private Cloud — izolowana, prywatna sieć wirtualna użytkownika w AWS.

Istotny szczegół: oba schematy kierują ruch do celów po prywatnych adresach IP, więc Twoje serwery nie potrzebują publicznych IP. Typowa architektura wielowarstwowa łączy oba: internet-facing ALB z serwerami webowymi z przodu, a za nimi internal ALB z serwerami aplikacyjnymi.

Security Groups — backend nie musi być publiczny

Security group działa jak firewall load balancera. Kanoniczny, bezpieczny wzorzec wygląda tak:

Terminacja TLS

Dla listenera HTTPS load balancer terminuje szyfrowanie, używając certyfikatu z AWS Certificate Manager. Deszyfracja odbywa się na brzegu, co odciąża serwery aplikacyjne.

Konsekwencja, o której trzeba pamiętać: ALB działa jako proxy, więc aplikacja nie widzi bezpośrednio adresu klienta — źródłowe IP odczytuje się z nagłówka X-Forwarded-For^?X-Forwarded-For: nagłówek HTTP, w którym proxy zapisuje oryginalny adres IP klienta, który ALB dodaje automatycznie.

ELB + Auto Scaling

To jedno z najważniejszych połączeń w AWS. Load balancer i Auto Scaling Group razem dają samoobsługującą się, elastyczną flotę:

ELB odpowiada za rozdział ruchu i wykrywanie awarii, ASG — za utrzymanie właściwej liczby instancji. Nowe instancje są automatycznie rejestrowane w grupie docelowej, a usuwane — wyrejestrowywane, z zachowaniem czasu na dokończenie trwających połączeń.

ELB + API Gateway

Amazon API Gateway to zarządzana brama API, a nie load balancer — i to jest sedno różnicy. Działa warstwę wyżej niż ELB: uwierzytelnia żądania, ogranicza ich tempo (throttling), waliduje wejście, obsługuje klucze API oraz wersjonowanie. ELB rozkłada ruch na flotę maszyn; API Gateway zarządza samym interfejsem API. W praktyce często stoją razem.

Gdy backend działa w prywatnym VPC — bez publicznego adresu IP — API Gateway nie połączy się z nim wprost przez internet. Pośredniczy wtedy VPC Link: API Gateway zakłada w Twoim VPC elastyczne interfejsy sieciowe^?elastyczne interfejsy sieciowe: ENI — wirtualne karty sieciowe w VPC, przez które zasoby łączą się z resztą sieci i sam nimi zarządza, tworząc prywatną ścieżkę z bramy do wnętrza sieci — ruch nie wychodzi na zewnątrz. Sama integracja jest typu HTTP proxy: wskazuje na ARN listenera load balancera (ALB lub NLB), a brama przekazuje do niego żądania bez zmian. Domyślnie ruch płynie po HTTP — HTTPS wymaga skonfigurowania TLS na listenerze.

To, z jakim load balancerem połączy się VPC Link, zależy od rodzaju API:

Który load balancer podłączysz do API, zależy od wersji VPC Link. Starsza wersja była wąska — REST API mogło stać tylko przed NLB. Nowsza (V2) obsługuje już ALB i NLB (a dla HTTP API także usługi w AWS Cloud Map), więc dziś typ load balancera praktycznie nie ogranicza architektury.

Nie musisz wybierać jednego zamiast drugiego. API Gateway daje kontrolę nad samym API — limity, autoryzację, klucze — a ELB skalowalną dystrybucję ruchu na flotę. Razem tworzą typowy wzorzec: publiczne API z prywatnym, skalowalnym backendem.

DNS i adresacja IP

Czy load balancer ma adres IP? Nie stały — dostaje nazwę DNS w rodzaju my-lb-1234567890.elb.eu-central-1.amazonaws.com. Klient rozwiązuje tę nazwę, a AWS może aktualizować stojące za nią adresy IP przy skalowaniu balancera.

Stąd praktyczna zasada: do ALB odwołuj się przez nazwę DNS, bo jego adresy IP mogą się zmieniać. NLB jest inny — tworzy jeden interfejs sieciowy na Availability Zone i daje z niego jeden statyczny adres IP na Availability Zone, a dla wariantu internet-facing^?internet-facing: load balancer z publicznymi adresami IP, osiągalny z internetu (przeciwieństwo internal, dostępnego tylko wewnątrz VPC) można przypisać własny Elastic IP^?Elastic IP: statyczny publiczny adres IP AWS, który można trwale przypisać do zasobu.

Sticky sessions i deregistration delay

Sticky sessions (przypięcie sesji) sprawiają, że kolejne żądania tego samego klienta trafiają do tego samego celu. W ALB realizuje to ciasteczko generowane przez load balancer (lub ciasteczko aplikacji) — przydatne dla aplikacji trzymających stan sesji lokalnie, choć lepszym wzorcem są serwery bezstanowe.

Deregistration delay (znane też jako connection draining) to czas, jaki load balancer daje trwającym połączeniom na dokończenie, zanim wyrejestrowany cel zostanie odłączony. Dzięki temu wyłączanie instancji przy scale-in nie zrywa obsługiwanych właśnie żądań.

Kiedy wybrać ALB, NLB czy GWLB

Reguła kciuka^?Reguła kciuka: praktyczna, uproszczona zasada oparta na doświadczeniu — nie sztywny wzór; daje dobry wybór w większości przypadków, ale dopuszcza wyjątki. — dobierz typ do zadania:

• ALB — aplikacje HTTP/HTTPS i routing po treści (ścieżka, host, nagłówki).
• NLB — skrajna przepustowość, niskie opóźnienia, protokoły TCP/UDP albo stałe adresy IP.
• GWLB — wpięcie w ścieżkę ruchu urządzeń bezpieczeństwa innych firm (firewall, IDS/IPS).

Przy NLB myśl w kategoriach połączeń i przepływów o bardzo wysokiej wydajności i niskim opóźnieniu, a nie samych żądań HTTP — hasło „miliony żądań na sekundę" bywa mylące.

Typowe scenariusze egzaminacyjne (SAA)

Najważniejsze do zapamiętania

ELB to warstwa dystrybucji ruchu, nie serwer aplikacyjny — siedzi na styku internetu i Twojej floty i jako pierwsza przyjmuje każdy skok ruchu oraz każdą awarię pojedynczej maszyny.

Trzy rzeczy warto utrwalić ponad resztę:

• ELB to rodzina (ALB/NLB/GWLB/CLB), a wybór typu to jedna z pierwszych i trudno odwracalnych decyzji architektonicznych.
• Cross-zone i minimalna liczba Availability Zones różnią się między ALB a NLB.
• ELB tylko wykrywa awarie i omija cele, a wymianą instancji zajmuje się Auto Scaling.

Ten sam wzorzec — bezstanowe serwery za load balancerem, health checki jako źródło prawdy o kondycji floty, Auto Scaling reagujący na metryki, TLS terminowany na brzegu — powtarza się w Google Cloud, Azure i Kubernetes. Opanowanie go na AWS przenosi się więc niemal wprost na inne platformy. To nie jest technologia efektowna, lecz fundamentalna: różnica bywa taka, jak między instalacją elektryczną a żyrandolem.

Źródła

• AWS — How Elastic Load Balancing works (dokumentacja) — link
• AWS — Elastic Load Balancing features — link
• AWS — What is an Application Load Balancer? (dokumentacja) — link
• AWS — Network Load Balancers (dokumentacja) — link
• AWS — Application Load Balancers (dokumentacja) — link
• AWS — Elastic Load Balancing pricing — link
• AWS — API Gateway: private integrations for HTTP APIs (dokumentacja) — link
• AWS — API Gateway: set up VPC links V2 (dokumentacja) — link