Kontrole stanu i przełączanie awaryjne DNS

Testy kondycji Route 53 stale monitorują kondycję punktów końcowych — serwerów internetowych, load balancerów oraz dowolnych punktów końcowych HTTP/HTTPS/TCP dostępnych w internecie. Na podstawie wyników testów kondycji Route 53 może automatycznie aktualizować routing DNS, aby nie kierować ruchu do niezdrowych zasobów.

Opłaty za testy kondycji są naliczane za każdy test miesięcznie. Globalne moduły sprawdzające kondycję Route 53 (znajdujące się w wielu regionach) jednocześnie sondują punkt końcowy, zapewniając nadmiarowość również w samym procesie sprawdzania kondycji. Punkt końcowy jest uznawany za niezdrowy dopiero wtedy, gdy uzgodni to określona liczba modułów sprawdzających.

Testy kondycji punktu końcowego monitorują konkretny adres IP lub nazwę domenową przy użyciu wybranego protokołu (HTTP, HTTPS lub TCP), portu oraz opcjonalnej ścieżki. W przypadku testów HTTP/HTTPS Route 53 sprawdza, czy punkt końcowy zwróci kod stanu HTTP 2xx lub 3xx w wyznaczonym czasie oczekiwania. W przypadku testów HTTPS opcjonalnie weryfikuje certyfikat TLS.

Najważniejsze opcje konfiguracji to: interwał żądań (10 lub 30 sekund — 10 sekund oznacza szybsze wykrywanie, ale wyższy koszt), próg niepowodzeń (od 1 do 10 kolejnych niepowodzeń przed oznaczeniem punktu jako niezdrowego) oraz dopasowywanie ciągu znaków (opcjonalna weryfikacja, czy treść odpowiedzi zawiera określony ciąg znaków).

Obliczane testy kondycji łączą wyniki wielu podrzędnych testów kondycji za pomocą logiki boolowskiej (AND, OR, NOT). Umożliwiają definiowanie kondycji aplikacji na podstawie wielu sygnałów bez tworzenia złożonych łańcuchów routingu.

Przykład: aplikacja internetowa jest zdrowa tylko wtedy, gdy pomyślnie przejdą zarówno test serwera API, jak i test bazy danych. Należy utworzyć obliczany test kondycji typu AND, który odwołuje się do obu testów punktów końcowych. Jeśli którykolwiek z nich zakończy się niepowodzeniem, obliczany test kondycji również zakończy się niepowodzeniem, a Route 53 usunie powiązany rekord DNS z odpowiedzi.

Testy kondycji na podstawie alarmów CloudWatch łączą test kondycji Route 53 ze stanem alarmu CloudWatch. Jeśli alarm znajduje się w stanie ALARM, test kondycji jest oznaczany jako niezdrowy; jeśli znajduje się w stanie OK lub INSUFFICIENT_DATA, jest oznaczany jako zdrowy.

Ten wzorzec jest szczególnie przydatny w przypadku punktów końcowych znajdujących się wewnątrz VPC (do których nie mogą dotrzeć zewnętrzne moduły sprawdzające Route 53). Zamiast sondować prywatny punkt końcowy, należy utworzyć dla niego metryki i alarmy CloudWatch, a następnie oprzeć test kondycji Route 53 na stanie alarmu. Umożliwia to również sprawdzanie kondycji na podstawie metryk biznesowych, takich jak współczynnik błędów lub głębokość kolejki.

Moduły sprawdzające kondycję Route 53 to zarządzane przez AWS serwery znajdujące się poza VPC, które łączą się z punktami końcowymi za pośrednictwem publicznego internetu. Zasoby w prywatnych podsieciach są niedostępne dla standardowych testów kondycji punktów końcowych. W przypadku prywatnych punktów końcowych należy zastosować jedno z poniższych rozwiązań:

• Publikować niestandardową metrykę CloudWatch z wnętrza VPC (np. sygnał powodzenia/niepowodzenia z aplikacji), utworzyć alarm i użyć testu kondycji na podstawie alarmu CloudWatch
• Użyć złożonego alarmu CloudWatch agregującego metryki ELB, RDS lub aplikacji znajdujących się wewnątrz VPC

Ten wzorzec ma kluczowe znaczenie w przypadku baz danych w prywatnych podsieciach, wewnętrznych load balancerów i usług backendowych.

Stan testu kondycji można wyświetlić w konsoli Route 53 w sekcji Health Checks lub pobrać za pośrednictwem API. Route 53 publikuje metryki testów kondycji w CloudWatch w przestrzeni nazw AWS/Route53, w tym HealthCheckStatus (1 = zdrowy, 0 = niezdrowy) oraz HealthCheckPercentageHealthy (odsetek modułów sprawdzających Route 53, które zgłaszają, że punkt końcowy jest zdrowy).

Należy skonfigurować alarmy CloudWatch dla HealthCheckStatus, aby otrzymywać powiadomienia SNS, gdy punkt końcowy stanie się niezdrowy. Zapewni to widoczność problemu, zanim zespół dyżurny zauważy, że przełączenie DNS nastąpiło już wcześniej.

Gdy Route 53 wykryje, że test kondycji rekordu Primary zakończył się niepowodzeniem, usuwa Primary z odpowiedzi DNS i zwraca adres Secondary. Nazywa się to DNS failover. Przełączenie następuje w czasie równym okresowi oceny (liczba niepowodzeń modułów sprawdzających × interwał żądań) powiększonemu o TTL rekordu.

Przykład: interwał żądań = 30 s, próg niepowodzeń = 3, TTL = 60 s. Maksymalny czas przełączenia ≈ 3 × 30 + 60 = 150 sekund. Ustawienie krótszego TTL (np. 10 sekund) i szybszego interwału testów kondycji (10 s) może skrócić ten czas do 3 × 10 + 10 = 40 sekund.

Testy kondycji można powiązać również z rekordami Weighted i Latency, a nie tylko z rekordami Failover. Gdy test kondycji rekordu Weighted zakończy się niepowodzeniem, Route 53 proporcjonalnie redystrybuuje wagę ruchu tego rekordu między zdrowe rekordy Weighted. Gdy test kondycji rekordu Latency zakończy się niepowodzeniem, Route 53 kieruje zapytania do kolejnego zdrowego rekordu o najniższym opóźnieniu.

Dzięki temu reguły routingu Weighted i Latency są odporne na awarie punktów końcowych bez konieczności tworzenia jawnych rekordów Failover. Jest to typowy wzorzec SAA-C03: routing Latency między regionami wraz z testami kondycji zapewnia zarówno optymalizację wydajności, jak i automatyczne odzyskiwanie po awarii.

Odporny na awarie wzorzec active-active w wielu regionach z użyciem Route 53:

1. Utworzyć rekordy Latency dla każdego regionu (us-east-1, eu-west-1, ap-southeast-1), każdy z testem kondycji
2. Gdy wszystkie regiony są zdrowe, użytkownicy są kierowani do regionu o najniższym opóźnieniu
3. Jeśli test kondycji jednego z regionów zakończy się niepowodzeniem (aplikacja nie działa lub nie odpowiada), Route 53 automatycznie usuwa ten region z odpowiedzi DNS i kieruje zapytania do kolejnego najlepszego zdrowego regionu
4. Gdy awaria regionu zostanie usunięta, test kondycji kończy się powodzeniem, a Route 53 ponownie włącza ten region do rotacji

Zapewnia to automatyczny globalny failover wraz z optymalizacją wydajności — bez konieczności ręcznej interwencji.

Moduły sprawdzające kondycję Route 53 korzystają z opublikowanego zestawu zakresów adresów IP w sekcji ROUTE53_HEALTHCHECKS pliku JSON z zakresami adresów IP AWS. Jeśli punkt końcowy jest chroniony przez zaporę sieciową lub grupę zabezpieczeń ograniczającą dostęp przychodzący, należy zezwolić na ruch z tych zakresów adresów IP, aby testy kondycji mogły się powieść.

Alternatywnie można użyć publicznie dostępnego punktu końcowego, który przekazuje żądania do prywatnego backendu (na przykład ALB), na potrzeby sprawdzania kondycji. Grupa zabezpieczeń ALB musi zezwalać jedynie na zakresy adresów IP Route 53, natomiast grupa zabezpieczeń backendu — wyłącznie na grupę zabezpieczeń ALB, co pozwala zachować wielowarstwowe podejście do ochrony.

Najlepsze praktyki dotyczące testów kondycji Route 53:

• Utworzyć dedykowany punkt końcowy /health, który sprawdza wszystkie krytyczne zależności (łączność z bazą danych, dostępność pamięci podręcznej) i zwraca kod 200 tylko wtedy, gdy system działa w pełni poprawnie
• W przypadku krytycznych punktów końcowych produkcyjnych używać 10-sekundowego interwału żądań, aby szybciej wykrywać awarie
• Monitorować HealthCheckPercentageHealthy w CloudWatch — częściowa awaria (gdy niektóre, ale nie wszystkie moduły sprawdzające Route 53 zawodzą) może wskazywać na regionalny problem z siecią lub problem występujący sporadycznie
• W przypadku zasobów prywatnych w VPC używać testów kondycji na podstawie alarmów CloudWatch, opartych na metrykach aplikacji
• Testować przełączanie awaryjne w środowiskach innych niż produkcyjne, zanim zacznie się na nim polegać w środowisku produkcyjnym

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: testy kondycji punktów końcowych wykonują sondowanie HTTP/HTTPS/TCP za pośrednictwem zewnętrznych modułów sprawdzających Route 53, testy kondycji na podstawie alarmów CloudWatch umożliwiają monitorowanie prywatnych zasobów VPC, a obliczane testy kondycji łączą wiele sygnałów za pomocą logiki boolowskiej. Szybkość DNS failover zależy od interwału testów kondycji, progu niepowodzeń i TTL. W następnej części omówimy dystrybucje CloudFront i źródła.