Load Balancing i Auto Scaling - skalowalność na autopilocie

Jeden serwer to za mało. Co gdy Twoja aplikacja ma tysiące użytkowników? Co gdy serwer padnie? Potrzebujesz dwóch rzeczy: rozdzielania ruchu (Load Balancing) i automatycznego skalowania (Auto Scaling). Razem tworzą fundament skalowalnych architektur w AWS.

Elastic Load Balancing (ELB)

ELB to zarządzany serwis, który automatycznie rozdziela ruch przychodzący między wiele instancji EC2 (lub kontenerów, Lambda). Sam jest wysoko dostępny i skaluje się automatycznie.

💡 Analogia
Load balancer to jak hostessa w restauracji. Zamiast wszyscy goście szli do jednego stolika, hostessa kieruje ich do różnych kelnerów. Jeśli kelner „padnie" (np. poszedł na przerwę), hostessa przestaje wysyłać do niego gości. Nikt nie czeka, restauracja działa bez zakłóceń.

Typy Load Balancerów

Application Load Balancer (ALB)

Działa na warstwie 7 (HTTP/HTTPS). Najczęściej używany i najbardziej elastyczny:

  • Routing na podstawie URL path (/api/* → serwery API, /images/* → serwery statyczne)
  • Routing na podstawie hostname (api.example.com vs www.example.com)
  • Routing na podstawie query string i headers
  • Natywne wsparcie dla WebSocket
  • Integracja z ECS, EKS, Lambda

Network Load Balancer (NLB)

Działa na warstwie 4 (TCP/UDP). Ekstremalnie szybki:

  • Miliony requestów na sekundę przy ultra-niskiej latencji
  • Statyczny IP na load balancerze (Elastic IP)
  • Idealny do: gier online, IoT, VoIP, protokołów non-HTTP

Gateway Load Balancer (GWLB)

Warstwa 3 (IP). Specjalistyczny, do ruchu przez firewalle i urządzenia sieciowe third-party. Rzadko spotykany na egzaminie CLF-C02.

ALB (Application)
  • Warstwa 7 (HTTP/HTTPS)
  • Zaawansowany routing (path, host, header)
  • Idealny dla aplikacji webowych i API
  • Wolniejszy niż NLB, ale inteligentniejszy
NLB (Network)
  • Warstwa 4 (TCP/UDP)
  • Ultra-niska latencja, miliony req/s
  • Statyczny IP (Elastic IP)
  • Idealny dla gier, IoT, non-HTTP

Health Checks

Load balancer regularnie sprawdza, czy instancje są zdrowe. Wysyła requesty (np. GET /health) i sprawdza odpowiedź. Jeśli instancja nie odpowie poprawnie kilka razy z rzędu, zostaje oznaczona jako unhealthy i load balancer przestaje wysyłać do niej ruch.

Auto Scaling Group (ASG)

Auto Scaling Group automatycznie dostosowuje liczbę instancji EC2 do aktualnego obciążenia. Więcej ruchu? Więcej instancji. Mniej ruchu? Mniej instancji. Płacisz tylko za to, czego potrzebujesz.

Konfiguracja ASG wymaga trzech kluczowych parametrów:

  • Minimum - minimalna liczba instancji (np. 2, dla High Availability)
  • Desired - pożądana liczba (od niej ASG startuje)
  • Maximum - limit górny (zabezpieczenie przed niespodziewanym wzrostem kosztów)

Polityki skalowania

  • Target Tracking - „Utrzymuj CPU na 50%". ASG sam dodaje/usuwa instancje → najprostsza i najczęstsza
  • Step Scaling - „Gdy CPU > 70% dodaj 2. Gdy CPU > 90% dodaj 4" → precyzyjna kontrola
  • Simple Scaling - „Gdy alarm się włączy, dodaj 1 instancję" → przestarzała, nie polecana
  • Scheduled Scaling - „Codziennie o 8:00 ustaw minimum na 10" → przewidywalne wzorce
  • Predictive Scaling - ML analizuje historyczne wzorce i skaluje z wyprzedzeniem
🏢 Scenariusz: E-commerce w Black Friday

Sklep internetowy normalnie obsługuje 1000 użytkowników na minutę (3 instancje m5.large za ALB). W Black Friday ruch rośnie 20x.

Konfiguracja: ASG min=3, desired=3, max=30. Target Tracking na 60% CPU. Scheduled Scaling: w piątek o 6:00 ustaw desired=15 (na zapas).

Efekt: o 6:00 ASG skaluje do 15 instancji. Gdy ruch rośnie powyżej progu, Target Tracking dodaje kolejne. Maksymalnie 30. Po Black Friday ruch spada i ASG automatycznie redukuje do 3. Zero interwencji manualnej.

📝 Na egzaminie
Na CLF-C02 musisz wiedzieć: ALB = warstwa 7 (HTTP), NLB = warstwa 4 (TCP). Auto Scaling = automatyczne dostosowanie liczby instancji. Health checks wykrywają niezdrave instancje. Skalowanie horyzontalne (więcej instancji) vs wertykalne (większa instancja). Przygotuj się solidnie z testami w Akademii CloudManiak!

ASG musi wiedzieć, jakie instancje uruchamiać. Do tego służy:

  • Launch Configuration - starsza metoda, nie wspiera wersjonowania, AWS ją wycofuje
  • Launch Template - nowsza, wspiera wersjonowanie, mieszane typy instancji, Spot + On-Demand. Zawsze używaj Launch Template!

Launch Template definiuje: AMI, typ instancji, Key Pair, Security Groups, User Data, EBS volumes i inne parametry.

🧠 Podsumowanie
  • ELB rozdziela ruch między instancje - ALB (HTTP), NLB (TCP), GWLB (IP)
  • Health checks wykrywają niezdrave instancje i przekierowują ruch
  • Auto Scaling Group (ASG) automatycznie skaluje liczbę instancji
  • ASG: Minimum, Desired, Maximum capacity
  • Polityki: Target Tracking, Step, Scheduled, Predictive
  • ELB + ASG = fundament skalowalnej i odpornej architektury
🧪 Sprawdź się

Twoja aplikacja webowa potrzebuje routingu na podstawie URL path (np. /api vs /web). Który load balancer wybierzesz?

A Application Load Balancer (ALB)
B Network Load Balancer (NLB)
C Gateway Load Balancer (GWLB)
ALB działa na warstwie 7 (HTTP/HTTPS) i obsługuje routing na podstawie URL path, hostname, headers i query string. NLB działa na warstwie 4 i nie widzi URL paths.

Auto Scaling Group ma ustawienie: min=2, desired=2, max=10. CPU wzrasta do 90%. Co się stanie?

A Nic, bo desired=2 jest zablokowane
B ASG uruchomi dodatkowe instancje (do max 10)
C ASG zmieni typ instancji na większy
Gdy polityka skalowania (np. Target Tracking) wykryje wysokie CPU, ASG uruchamia dodatkowe instancje aż do max=10. To skalowanie horyzontalne (dodawanie instancji), nie wertykalne (zmiana rozmiaru).