load balancer

Load balancer to element infrastruktury rozdzielający ruch między kilka serwerów w celu równomiernego obciążenia.

Rola load balancera w architekturze usług

Load balancer, czyli równoważnik obciążenia, jest elementem infrastruktury sieciowej, który przyjmuje połączenia lub żądania od klientów i przekazuje je do jednej z kilku instancji usługi. Instancjami mogą być serwery fizyczne, maszyny wirtualne albo inne punkty końcowe dostępne pod adresami IP i portami. Dzięki temu użytkownik korzysta z jednego adresu usługi, podczas gdy ruch jest rozdzielany pomiędzy zaplecze. Celem nie jest wyłącznie równomierne wykorzystanie procesorów. Load balancer może również zwiększać dostępność usługi, ponieważ po wykryciu niedostępności jednego punktu kieruje nowe połączenia do pozostałych.

Urządzenie lub oprogramowanie tego typu nie naprawia błędów aplikacji i nie zwiększa automatycznie wydajności każdego systemu. Skuteczność zależy od sposobu obsługi sesji, parametrów zaplecza, opóźnień sieciowych oraz poprawnie zdefiniowanych testów zdrowia. Jeżeli wszystkie serwery wykonują tę samą operację równie wolno, samo rozdzielenie ruchu nie usunie wąskiego gardła. Load balancer może natomiast ograniczyć przeciążenie pojedynczego serwera i ułatwić prowadzenie prac serwisowych przez czasowe wyłączenie wybranej instancji z puli.

Równoważenie na warstwie transportowej i aplikacyjnej

Load balancer działający na warstwie transportowej, określany często jako L4, podejmuje decyzję na podstawie parametrów połączenia, takich jak adres IP, port oraz protokół TCP lub UDP. Nie musi analizować treści żądania HTTP. Taki model pozwala przekazywać różne protokoły i ogranicza narzut związany z analizą danych aplikacyjnych, ale nie umożliwia wyboru serwera na podstawie ścieżki URL, nagłówka HTTP czy nazwy hosta zapisanej w żądaniu.

Równoważenie na warstwie aplikacyjnej, nazywane L7, rozumie wybrane elementy protokołu, na przykład metodę HTTP, ścieżkę, nagłówki i kod odpowiedzi. Może dzięki temu kierować żądania /api i /grafika do różnych pul serwerów albo stosować odrębne reguły dla wielu nazw domenowych. Analiza aplikacyjna wymaga większej ilości zasobów i poprawnej obsługi protokołu. W przypadku HTTPS load balancer może przekazywać zaszyfrowany ruch bez wglądu w treść albo zakończyć połączenie TLS na własnej stronie, odszyfrować żądanie i utworzyć połączenie do serwera zaplecza.

Algorytmy wyboru serwera i kontrola dostępności

Najprostszym algorytmem jest round robin, w którym kolejne żądania trafiają do następnych serwerów zgodnie z ustaloną kolejnością. Wariant ważony przekazuje większą część ruchu wydajniejszym instancjom. Algorytm least connections wybiera punkt mający najmniej aktywnych połączeń, co może być korzystne wtedy, gdy czas obsługi żądań jest nierówny. Spotyka się także wybór oparty na hashach, na przykład z wykorzystaniem adresu klienta, identyfikatora sesji albo innych danych. Hash może zapewnić powtarzalne przypisanie klienta do tej samej instancji, lecz zmiana składu puli może zmienić takie przypisania.

Przed wysłaniem ruchu load balancer może wykonywać health check, czyli okresowy test dostępności. Test TCP potwierdza możliwość nawiązania połączenia z określonym portem, natomiast test HTTP może wymagać konkretnej ścieżki i oczekiwać prawidłowego kodu odpowiedzi, na przykład z zakresu 2xx. Sam fakt otwarcia portu nie dowodzi, że aplikacja działa poprawnie, dlatego punkt kontrolny powinien sprawdzać istotny dla usługi etap działania, ale nie wykonywać operacji powodujących zmianę danych. Po przekroczeniu ustalonej liczby nieudanych prób instancja może zostać oznaczona jako niedostępna, a po serii udanych testów ponownie dołączona do puli.

Sesje, awarie i diagnostyka przepływu ruchu

Najłatwiejszy do skalowania jest model bezstanowy, w którym każde żądanie może trafić do dowolnego serwera, ponieważ stan użytkownika jest przechowywany poza konkretną instancją albo przekazywany w żądaniu. Jeżeli aplikacja przechowuje sesję wyłącznie lokalnie, konieczne może być zastosowanie tak zwanej trwałości sesji, czyli kierowania kolejnych żądań tego samego klienta do wybranego serwera. Przypisanie może być oparte na ciasteczku, adresie klienta lub identyfikatorze połączenia. Mechanizm ten nie zastępuje poprawnej obsługi awarii: gdy przypisana instancja przestanie działać, użytkownik może utracić sesję albo wymagać ponownego uwierzytelnienia.

Diagnostyka load balancera obejmuje sprawdzenie kolejnych odcinków przepływu: rozwiązywania nazwy, osiągalności adresu, nasłuchiwania portu, reguł przekazywania, wyniku health checków oraz odpowiedzi serwera zaplecza. Należy rozróżnić połączenie od żądania aplikacyjnego, ponieważ udane zestawienie TCP nie oznacza poprawnej odpowiedzi HTTP. Przy problemach trzeba również sprawdzić nagłówki przekazywane do aplikacji, terminację TLS, limity czasu, maksymalną liczbę połączeń i sposób zapisu adresu klienta. W przypadku laptopa lub komputera PC analiza może dotyczyć klienta, który nie dociera do usługi, błędnej konfiguracji sieciowej albo lokalnego oprogramowania filtrującego ruch, natomiast sama konfiguracja serwerowej puli wymaga dostępu do odpowiedniej infrastruktury.