Grupy docelowe i kontrole stanu

Grupa docelowa to logiczny zbiór celów, do których moduł równoważenia obciążenia kieruje żądania. Każda grupa docelowa ma typ celu, protokół/port oraz konfigurację kontroli kondycji. Moduł równoważenia obciążenia rozdziela żądania między zarejestrowane cele w grupie docelowej, które przechodzą kontrole kondycji.

Grupy docelowe są powiązane ze słuchaczami modułu równoważenia obciążenia za pomocą reguł słuchacza. Jeden słuchacz może kierować ruch do wielu grup docelowych na podstawie atrybutów żądania. Jest to podstawowy mechanizm routingu na podstawie ścieżki i hosta w ALB.

Grupy docelowe obsługują trzy typy celów:

• instance: kieruje ruch do instancji EC2 na podstawie identyfikatora instancji; moduł równoważenia obciążenia przesyła ruch do głównego interfejsu sieciowego instancji na określonym porcie
• ip: kieruje ruch do prywatnych adresów IP — jest to przydatne w przypadku celów znajdujących się w kontenerach (ECS/EKS), serwerów lokalnych dostępnych przez VPN/Direct Connect lub dodatkowych adresów IP instancji EC2
• lambda: kieruje ruch do pojedynczej funkcji Lambda (tylko ALB); ALB konwertuje żądanie HTTP na zdarzenie JSON i synchronicznie wywołuje funkcję

Typ celu IP jest wymagany w przypadku zadań ECS z trybem sieci awsvpc (każde zadanie otrzymuje własny adres IP), podów EKS oraz architektur hybrydowych z celami lokalnymi.

Cele można rejestrować w grupie docelowej ręcznie (w konsoli lub za pomocą interfejsu CLI) albo automatycznie (poprzez dołączenie Auto Scaling Group lub konfigurację usługi ECS). Cele zarejestrowane ręcznie pozostają w grupie do momentu ich jawnego wyrejestrowania.

W przypadku ASG należy dołączyć ASG do grupy docelowej. ASG automatycznie rejestruje nowo uruchomione instancje i wyrejestrowuje te zakończone. Ta ścisła integracja z ASG to standardowy wzorzec dla elastycznych warstw obliczeniowych — nowe instancje są uruchamiane i zaczynają odbierać ruch zaraz po pomyślnym przejściu kontroli stanu.

Każda grupa docelowa ma powiązaną kontrolę stanu, której moduł równoważenia obciążenia używa do określenia, czy cel działa prawidłowo i może odbierać ruch. Kontrola stanu wysyła okresowe żądania do każdego celu i ocenia odpowiedź:

• Protokół: HTTP, HTTPS lub TCP (w przypadku NLB)
• Ścieżka: ścieżka URL, do której należy wysłać żądanie (np. /health lub /ping)
• Port: port, który należy sprawdzić (domyślnie port grupy docelowej)
• Próg stanu prawidłowego: liczba kolejnych pomyślnych kontroli przed oznaczeniem celu jako działającego prawidłowo
• Próg stanu nieprawidłowego: liczba kolejnych nieudanych kontroli przed oznaczeniem celu jako niedziałającego prawidłowo
• Interwał: liczba sekund między kontrolami stanu (5–300)
• Limit czasu: liczba sekund oczekiwania na odpowiedź

W przypadku kontroli stanu HTTP/HTTPS należy określić, które kody odpowiedzi HTTP oznaczają, że cel działa prawidłowo. Wartością domyślną jest 200, ale można skonfigurować zakresy, takie jak 200-299, lub wartości rozdzielane przecinkami, takie jak 200,301,302.

Najlepsza praktyka: należy utworzyć w aplikacji dedykowany punkt końcowy /health, który zwraca kod 200 tylko wtedy, gdy wszystkie krytyczne zależności są dostępne (połączenie z bazą danych, pamięć podręczna, usługa podrzędna). Nie należy używać głównego adresu URL (/) jako ścieżki kontroli stanu, jeśli wykonuje on kosztowne operacje lub wymaga uwierzytelnienia.

Po zarejestrowaniu cel przechodzi przez następujące stany:

• initial: ELB wykonuje pierwsze kontrole stanu
• healthy: cel pomyślnie przeszedł wymaganą liczbę kolejnych kontroli stanu; odbiera ruch
• unhealthy: cel nie przeszedł wymaganej liczby kolejnych kontroli stanu; zostaje usunięty z rotacji
• draining: trwa wyrejestrowywanie; istniejące połączenia mogą zostać zakończone, ale nowe połączenia nie są wysyłane
• unused: cel jest zarejestrowany w grupie, ale żadna reguła odbiornika nie kieruje obecnie ruchu do tej grupy

Należy monitorować metryki CloudWatch UnHealthyHostCount i HealthyHostCount, aby wykrywać problemy we flocie celów.

Opóźnienie wyrejestrowania (wcześniej nazywane opróżnianiem połączeń) to czas, przez jaki ELB czeka na zakończenie istniejących połączeń przed ostatecznym wyrejestrowaniem celu. Wartość domyślna wynosi 300 sekund (5 minut). W tym czasie do wyrejestrowywanego celu nie są wysyłane nowe żądania, ale żądania będące w toku mogą zostać dokończone.

W przypadku szybkich wdrożeń i kończenia instancji przez automatyczne skalowanie można skrócić ten czas do 30–60 sekund, jeśli aplikacja szybko obsługuje żądania. W przypadku długotrwałych operacji (przesyłanie plików, przetwarzanie wideo) należy ustawić go na tyle długo, aby operacje mogły zakończyć się bez przerwania.

Grupy docelowe obsługują różne algorytmy równoważenia obciążenia:

• Round robin (domyślny dla ALB): żądania są równomiernie rozdzielane cyklicznie — najlepsze rozwiązanie, gdy wszystkie cele są równoważne
• Least outstanding requests (ALB): każde nowe żądanie jest wysyłane do celu z najmniejszą liczbą żądań będących w toku — lepsze rozwiązanie dla obciążeń o zmiennej długości, w których obsługa niektórych żądań trwa dłużej
• Flow hash (NLB): rozdzielanie odbywa się na podstawie protokołu, źródłowego i docelowego adresu IP, źródłowego i docelowego portu oraz numeru sekwencyjnego TCP — zapewnia, że wszystkie pakiety w ramach przepływu TCP/UDP trafią do tego samego celu

W przypadku aplikacji korzystających z sesji, w których wszystkie żądania użytkownika muszą trafiać do tego samego celu, należy włączyć sesje sticky zamiast polegać na rozdzielaniu round-robin.

Pojedyncza reguła odbiornika ALB może rozdzielać ruch między wiele grup docelowych za pomocą ważonych grup docelowych. Można na przykład kierować 90% ruchu do stabilnej grupy docelowej, a 10% do grupy docelowej canary na potrzeby wdrożeń blue-green — bez używania routingu ważonego Route 53.

Ważone grupy docelowe konfiguruje się na poziomie reguły odbiornika. Wagi są względne: proporcja 90/10 kieruje 90% ruchu do pierwszej grupy, a 10% do drugiej. Różni się to od routingu ważonego między wieloma ALB — tutaj routing odbywa się w ramach jednej reguły odbiornika ALB.

Podczas wdrażania usług ECS za ALB każde zadanie ECS jest rejestrowane w grupie docelowej ALB przy użyciu typu celu ip (w przypadku trybu sieci awsvpc). Usługa ECS automatycznie zarządza rejestrowaniem i wyrejestrowywaniem: nowe zadania są rejestrowane po pomyślnym przejściu kontroli stanu, a zatrzymywane zadania przechodzą przez opóźnienie wyrejestrowania przed zakończeniem.

Każda usługa ECS może zostać zarejestrowana z określonym nadpisaniem portu, co pozwala wielu usługom ECS współdzielić jeden ALB za pośrednictwem różnych reguł odbiornika (na podstawie ścieżki lub hosta) i różnych grup docelowych — jest to typowy wzorzec mikrousług.

Zachowanie kontroli stanu NLB różni się od zachowania ALB:

• NLB obsługuje protokoły kontroli stanu TCP, HTTP i HTTPS niezależnie od protokołu odbiornika
• Kontrole stanu NLB są wysyłane z adresów IP NLB w każdej strefie AZ — należy upewnić się, że grupy zabezpieczeń zezwalają na ruch z adresów IP podsieci NLB lub użyć grupy zabezpieczeń samego NLB
• W przypadku kontroli stanu TCP NLB uznaje cel za działający prawidłowo, jeśli akceptuje połączenie TCP na określonym porcie
• Cele NLB, które nie przechodzą kontroli stanu, są usuwane w poszczególnych strefach AZ — jeśli wszystkie cele w danej strefie AZ są niedziałające prawidłowo, NLB może równoważyć obciążenie między strefami i kierować ruch do działających prawidłowo celów w innych strefach AZ (jeśli włączono równoważenie między strefami)

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: grupy docelowe zawierają zdrowe, zarejestrowane cele typu instancja, IP lub Lambda, kontrole stanu okresowo sprawdzają cele, aby usuwać niedziałające prawidłowo cele z rotacji, a opóźnienie wyrejestrowania zapewnia prawidłowe opróżnienie żądań będących w toku przed usunięciem celu. Następnie omówimy reguły odbiornika i routing na podstawie ścieżki w ALB.