Load balancer - co to jest i jak działa równoważenie ruchu?

Load balancer to warstwa pośrednia między klientem a grupą serwerów. Przyjmuje ruch, wybiera backend, kontroluje stan instancji i nie wysyła żądań do serwerów, które nie powinny obsługiwać ruchu. Może działać w warstwie 4, gdzie rozdziela połączenia TCP lub UDP, albo w warstwie 7, gdzie analizuje HTTP, nagłówki, ścieżki URL, hosty, cookies i reguły routingu.

Użytkownik nie łączy się wtedy bezpośrednio z konkretnym serwerem aplikacji. Łączy się z adresem load balancera, a dopiero on decyduje, która instancja obsłuży połączenie lub żądanie. Dzięki temu aplikacja może działać na wielu backendach, a awaria jednej instancji nie musi zatrzymać całej usługi.

Co to jest load balancer?

Load balancer, czyli równoważnik obciążenia, jest punktem wejścia do usługi działającej na wielu serwerach, kontenerach albo instancjach aplikacji. Nie chodzi tylko o równy podział ruchu. Dobry load balancer bierze pod uwagę stan backendów, algorytm wyboru, liczbę połączeń, reguły routingu, stan sesji użytkownika, protokół oraz ustawienia bezpieczeństwa.

Podstawowy układ składa się z listenera, puli backendów i mechanizmu health check. Listener odbiera ruch na konkretnym porcie i protokole. Pula backendów zawiera serwery aplikacji. Health check sprawdza, które instancje mogą zostać w rotacji.

Równoważnik obciążenia nie eliminuje wewnętrznych problemów z kodem, ale izoluje infrastrukturę przed skutkami awarii pojedynczych serwerów. To odróżnia go od prostego DNS round robin, który zwykle nie zna realnego stanu aplikacji w chwili żądania.

Jak działa load balancer?

Z zewnątrz wygląda to jak zwykłe przekazanie ruchu dalej. W środku load balancer wykonuje kilka kroków. Odbiera połączenie lub żądanie, sprawdza reguły routingu, wybiera pulę backendów, odrzuca instancje uznane za niezdrowe i przekazuje ruch do konkretnego serwera.

Etap	Co się dzieje	Znaczenie
Połączenie klienta	DNS wskazuje adres load balancera, a nie pojedynczego backendu.	Backendy nie muszą być wystawione bezpośrednio do internetu.
Listener	Load balancer odbiera ruch na porcie i protokole, na przykład HTTP, HTTPS, TCP albo UDP.	To punkt wejścia do usługi.
Reguły routingu	Ruch może zostać skierowany według hosta, ścieżki URL, nagłówka, portu albo protokołu.	Różne części aplikacji mogą trafiać do różnych grup serwerów.
Wybór backendu	Algorytm wskazuje konkretną instancję z puli na podstawie wybranych kryteriów.	Od tej decyzji zależy rozkład ruchu i ryzyko przeciążenia poszczególnych serwerów.
Health check	Instancje uznane za niezdrowe są usuwane z rotacji.	Ruch nie powinien trafiać do serwera, który nie obsłuży żądania.
Przekazanie ruchu	Load balancer działa jako proxy L7 albo przekazuje połączenie w modelu L4.	Od warstwy działania zależy widoczność żądania, wydajność i możliwości routingu.

Load balancer jest blisko spokrewniony z proxy, ale nie każde proxy jest równoważnikiem obciążenia. Proxy pośredniczy w komunikacji, a load balancer dodatkowo wybiera backend z puli i reaguje na jego stan. Ten kontekst dobrze uzupełnia tekst o tym, co to jest proxy.

L4 i L7 w load balancerze

Najważniejszy podział techniczny dotyczy warstwy, w której load balancer podejmuje decyzję. Load balancer L4 pracuje na poziomie transportowym. Load balancer L7 działa na poziomie aplikacyjnym i rozumie treść żądania HTTP.

Cecha	L4 load balancer	L7 load balancer
Podstawa decyzji	IP, port, protokół, połączenie i flow.	HTTP, host, path, header, cookie, metoda i query string.
Typowy ruch	TCP, UDP i TLS passthrough.	HTTP, HTTPS, API i WebSocket.
Największa zaleta	Szybkość, prostota i niskie opóźnienia.	Inteligentny routing aplikacyjny.
Największe ograniczenie	Brak wiedzy o treści żądania HTTP.	Większy narzut i częste TLS termination.
Przykład	NLB, HAProxy TCP i load balancing połączeń.	ALB, NGINX HTTP i reverse proxy.

W warstwie 4 load balancer wybiera instancję docelową dla połączenia lub przepływu. Nie musi znać adresu URL ani nagłówków HTTP. W warstwie 7 może kierować ruch według treści żądania. Ścieżka /api może trafić do jednej puli backendów, panel administracyjny do drugiej, a inna domena do osobnej aplikacji.

Przy L4 ważne stają się adresy IP, porty, pakiety, sesje TCP i zachowanie adresu źródłowego klienta. Load balancer może zachować adres klienta, nadpisać go albo przekazać w nagłówkach typu X-Forwarded-For. Dobrym uzupełnieniem jest poradnik o tym, jak sprawdzić adres IP.

Algorytmy load balancingu

Algorytm decyduje, który backend dostanie nowe połączenie albo żądanie. Krótkie żądania statyczne, długie połączenia WebSocket i ciężkie requesty API nie obciążają systemu w ten sam sposób, dlatego wybór algorytmu ma realne znaczenie.

Algorytm	Sposób działania	Dobre zastosowanie	Ryzyko
Round robin	Ruch trafia kolejno do następnych backendów.	Podobne serwery oraz krótkie i przewidywalne requesty.	Algorytm nie widzi realnego obciążenia.
Weighted round robin	Backendy mają przypisane wagi.	Serwery o różnej mocy albo stopniowe wdrożenia.	Źle dobrane wagi tworzą hot spoty.
Least connections	Nowy ruch trafia do backendu z najmniejszą liczbą aktywnych połączeń.	Długie i nierówne połączenia.	Liczba połączeń nie zawsze odpowiada zużyciu CPU lub pamięci.
Least time	Decyzja uwzględnia czas odpowiedzi backendu.	Systemy, w których kluczowa jest latencja.	Potrzebne są wiarygodne metryki.
IP hash / source hash	Klient jest mapowany na backend według adresu lub hasha.	Prosta session affinity.	NAT może skleić wielu użytkowników pod jednym adresem.
Random / power of two choices	Load balancer losuje instancję albo porównuje losowo wybrane backendy.	Duże pule instancji.	Debugowanie jest mniej intuicyjne niż przy prostym round robin.

Równoważenie ruchu nie musi oznaczać identycznej liczby żądań na każdym serwerze. Czasem ważniejsza jest liczba aktywnych połączeń, czas odpowiedzi, stabilność sesji albo omijanie backendu, który formalnie działa, ale zaczyna odpowiadać wolniej.

Health checks i stan backendów

Health check sprawdza, czy backend powinien zostać w rotacji. Bez tego mechanizmu load balancer może wysyłać ruch do instancji, która nadal przyjmuje połączenie TCP, ale nie jest w stanie obsłużyć realnego żądania aplikacji.

Najprostszy test TCP potwierdza tylko, że port odpowiada. W wielu aplikacjach to za mało. Lepszy health check HTTP sprawdza dedykowany endpoint, na przykład /health, /ready albo /status. Taki endpoint powinien być szybki, tani i na tyle reprezentatywny, żeby wykrywać istotne awarie.

Zbyt płytki health check może ukryć problem. Aplikacja może odpowiadać statusem 200 OK, mimo że logowanie, checkout albo API zależne od bazy danych zwracają błędy. Zbyt ciężki health check też jest zły, bo cykliczne sprawdzanie bazy, cache, kolejek i usług zewnętrznych może samo generować obciążenie.

Typ sprawdzenia	Co wykrywa	Co może pominąć
TCP health check	Port jest otwarty i można zestawić połączenie.	Aplikacja może zwracać błędy 500 albo mieć problem z bazą.
HTTP health check	Endpoint aplikacji odpowiesz poprawnym statusem.	Endpoint może nie sprawdzać zależności krytycznych.
Deep health check	Wybrane zależności aplikacji działają.	Test może być zbyt ciężki, jeśli sprawdza za dużo przy każdym przebiegu.
Global health check	Usługa jest dostępna z różnych regionów lub sieci.	Wynik może pokazywać problem trasy sieciowej, a nie samego serwera.

Progi healthy i unhealthy chronią przed flappingiem, czyli ciągłym dodawaniem i usuwaniem backendu z rotacji. W systemach globalnych testy mogą być wykonywane z wielu regionów. Backend może być zdrowy lokalnie, ale niedostępny z części internetu przez problem trasy, DNS albo operatora.

Sticky sessions i architektura bezstanowa

Sticky session sprawia, że kolejne żądania tego samego klienta trafiają do tego samego backendu. Load balancer może uzyskać taki efekt przez cookie, hash adresu IP, nagłówek albo inny identyfikator.

Ten mechanizm bywa używany w starszych aplikacjach, które trzymają stan sesji lokalnie na konkretnym serwerze. To działa, ale jest słabym fundamentem pod skalowanie. Backend przestaje być wtedy wymienną instancją, bo niesie lokalny stan użytkownika.

Nowocześniejsza architektura dąży do modelu stateless. Backend obsługuje żądanie, ale nie przechowuje krytycznego stanu sesji wyłącznie u siebie. Sesje, koszyki, tokeny odświeżania albo dane użytkownika trafiają do zewnętrznego magazynu, na przykład klastra Redis, bazy danych albo osobnej usługi sesyjnej. Wtedy dowolna zdrowa instancja może obsłużyć kolejne żądanie, a sticky sessions przestają być warunkiem działania aplikacji.

Przyklejenie użytkownika do backendu nie gwarantuje utrzymania sesji po awarii. Jeżeli aplikacja trzyma stan lokalnie, a backend padnie, load balancer może prносить użytkownika na inny serwer, ale lokalna sesja i tak zniknie.

TLS termination, passthrough i re-encryption

Load balancer często obsługuje HTTPS. Może kończyć TLS na sobie, przekazywać zaszyfrowany ruch dalej albo odszyfrować i ponownie zaszyfrować połączenie do backendu.

Model	Działanie	Zaleta	Ograniczenie
TLS termination	Load balancer kończy HTTPS na sobie.	Certyfikaty, routing L7 i inspekcja HTTP są w jednym miejscu.	Ruch do backendu wymaga osobnej decyzji o zabezpieczeniu.
TLS passthrough	Load balancer przekazuje zaszyfrowane połączenie TCP.	Backend kontroluje TLS.	Load balancer nie widzi ścieżki URL ani nagłówków HTTP.
Re-encryption	Osobny TLS działa między klientem i LB oraz między LB i backendem.	Bezpieczniejszy model między warstwami.	Konfiguracja certyfikatów jest bardziej złożona.
mTLS	Obie strony połączenia potwierdzają tożsamość certyfikatem.	Silna kontrola tożsamości usług.	Większa złożoność operacyjna.

Wybór modelu TLS wpływa na możliwości routingu. Przy TLS passthrough load balancer zachowuje się bliżej warstwy 4, bo nie zna treści HTTP. Przy TLS termination może działać jako L7 i kierować ruch według hosta, ścieżki URL, nagłówków albo cookies.

Load balancer, reverse proxy, CDN i DNS round robin

Load balancer często działa razem z reverse proxy, CDN, DNS i firewallem, ale każdy z tych elementów ma inną rolę. Pomieszanie tych warstw prowadzi do złych założeń projektowych.

Element	Główna rola	Ograniczenie
Load balancer	Wybiera backend z puli i wycofuje niedziałające instancje.	Nie zastępuje logiki aplikacji ani trwałego magazynu danych.
Reverse proxy	Pośredniczy w HTTP, może routować, cache’ować i kończyć TLS.	Nie zawsze zapewnia wysoką dostępność wielu backendów.
CDN	Przybliża treści do użytkownika i może cache’ować statyczne zasoby.	Nie zastępuje logiki backendu.
DNS round robin	Zwraca różne adresy IP dla tej samej nazwy.	Nie zna realnego stanu aplikacji w chwili żądania.
Firewall / WAF	Filtruje ruch według reguł bezpieczeństwa.	Nie rozwiązuje sam problemu wydajności backendów.
API gateway	Obsługuje polityki API, autoryzację, rate limit i routing usług.	Nie zawsze zastępuje warstwę load balancera infrastrukturalnego.

Load balancer może mieć reguły dostępu, ale nie należy mylić go z firewallem. Do kontroli ruchu, filtrowania i blokowania dostępu służą osobne mechanizmy opisane w tekście co to jest firewall.

Gdzie load balancer może zawieść?

Wprowadzenie równoważenia obciążenia zwiększa odporność na awarie sprzętowe, ale nie zastąpi poprawnie zaprojektowanego kodu ani stabilnej architektury. Może wycofać backend z rotacji, ale nie przywróci bazy danych, nie odtworzy sesji zapisanej lokalnie i nie zastąpi dobrze zaprojektowanego procesu wdrożenia.

Duże znaczenie ma sposób wprowadzania nowej lub odzyskanej instancji do rotacji. Slow start polega na stopniowym wpuszczaniu ruchu na backend, który dopiero wrócił po awarii albo został świeżo uruchomiony. Dzięki temu serwer ma czas na rozgrzanie cache, zestawienie połączeń z bazą, inicjalizację aplikacji i stabilne wejście pod obciążenie.

Connection draining działa w drugą stronę. Gdy instancja ma zostać wyłączona, load balancer przestaje wysyłać do niej nowe żądania, ale pozwala zakończyć istniejące połączenia i requesty. Bez tego mechanizmu deploy, restart albo skalowanie w dół może przerywać użytkownikom aktywne operacje.

Timeouty również potrafią zepsuć stabilną usługę. Zbyt krótki timeout przerywa długie requesty albo WebSockety. Zbyt długi trzyma martwe połączenia i wyczerpuje zasoby. Źle ustawione keep-alive potrafi przeciążyć backend liczbą otwartych połączeń, nawet jeśli liczba aktywnych requestów wygląda niewinnie.

Osobnym ryzykiem jest sam load balancer jako punkt wejścia. Jeżeli nie ma własnej redundancji, może stać się pojedynczym punktem awarii. W praktyce dlatego produkcyjne rozwiązania stosują wiele instancji load balancera, wiele stref dostępności, automatyczny failover i monitoring samej warstwy równoważenia ruchu.

Load balancer w hostingu, chmurze i mikroserwisach

W prostym hostingu load balancer może stać przed kilkoma serwerami WWW. W chmurze często jest usługą zarządzaną, na przykład Application Load Balancer albo Network Load Balancer. W Kubernetesie podobną rolę pełnią Service typu LoadBalancer, Ingress Controller albo Gateway API. W mikroserwisach load balancing może działać także między usługami, często przez Envoy, service mesh albo bardziej zaawansowane mechanizmy blisko warstwy jądra systemu.

Dla zwykłej strony internetowej load balancer zaczyna mieć sens wtedy, gdy jedna instancja przestaje wystarczać albo gdy wymagana jest wyższa dostępność niż pojedynczy serwer. To łączy temat z wyborem infrastruktury i tym, co realnie oznacza hosting strony WWW.

W architekturze cloudowej load balancing nie kończy się na jednym regionie. Globalny load balancer może kierować użytkownika do najbliższego lub najzdrowszego regionu. Wtedy zdrowie systemu zależy nie tylko od backendów, ale też od DNS, tras sieciowych, opóźnień i dostępności centrów danych.

Load balancer — najważniejszy wniosek

Load balancer nie jest zwykłym rozdzielaczem ruchu. To punkt decyzyjny między klientem a backendami, który wybiera instancję docelową, sprawdza jej stan, obsługuje failover, może kończyć TLS, utrzymywać sticky sessions i stosować reguły routingu L4 albo L7. Najważniejsze jest nie to, czy ruch jest rozłożony po równo, ale czy trafia do zdrowej instancji, z poprawnym stanem sesji, właściwym protokołem, sensownymi timeoutami i bez tworzenia nowego pojedynczego punktu awarii.