Odświeżanie instancji i haki cyklu życia

Po zaktualizowaniu Launch Template (nowy AMI, nowe dane użytkownika lub nowy typ instancji) istniejące instancje działające w ASG nie są automatycznie zastępowane — nadal działają ze starą konfiguracją. Aby propagować zmiany, należy zastąpić instancje. Ręczne kończenie i ponowne uruchamianie instancji jest ryzykowne i podatne na błędy. Instance Refresh automatyzuje ten proces za pomocą konfigurowalnych mechanizmów bezpieczeństwa.

Instance Refresh zastępuje instancje ASG partiami, metodą rolling update. Na każdym etapie kończy działanie partii starych instancji, czeka, aż nowe instancje przejdą testy sprawności, a następnie przechodzi do kolejnej partii. Tempo można kontrolować za pomocą parametru MinHealthyPercentage (minimalny procent pojemności, który musi pozostać sprawny podczas odświeżania) oraz opcjonalnego czasu InstanceWarmup.

MinHealthyPercentage określa minimalny poziom sprawnej pojemności podczas odświeżania. Ustawienie wartości 90% oznacza, że jednocześnie zastępowane jest tylko 10% floty — wolniej, ale bezpieczniej. Wartość 50% oznacza jednoczesne zastąpienie połowy floty — szybciej, ale z mniejszą nadmiarowością. ASG automatycznie oblicza rozmiary partii na podstawie tego procentu i bieżącej pożądanej pojemności. W przypadku obciążeń produkcyjnych należy wybrać wyższą wartość procentową, aby utrzymać dostępność.

Checkpoints umożliwiają wstrzymanie Instance Refresh na wcześniej zdefiniowanych progach procentowych. Można na przykład odświeżyć 20% instancji, wstrzymać proces na 10 minut w celu przeprowadzenia testów dymnych, a następnie go wznowić. Jeśli na dowolnym punkcie kontrolnym zostanie wykryty problem, można anulować odświeżanie — ASG przestanie zastępować kolejne instancje, ale pozostawi już zastąpione instancje działające (korzystają one już z nowego szablonu). Jest to w praktyce wzorzec wdrożenia canary dla EC2.

Trwające Instance Refresh można w dowolnym momencie anulować; zatrzyma to dalsze zastępowanie instancji, ale nie wycofa zakończonych zastąpień. Polecenia describe-instance-refreshes należy używać do sprawdzania stanu, procentowego postępu oraz instancji, których nie udało się uruchomić. Instance Refresh można zintegrować z potokiem CI/CD, aby automatycznie uruchamiać odświeżanie po przesłaniu nowego AMI do Launch Template, uzyskując w pełni zautomatyzowane wdrożenie w stylu blue/green.

Lifecycle Hooks wstrzymują przejścia instancji ASG w kluczowych momentach, aby można było wykonać własną logikę przed aktywowaniem instancji lub przed jej zakończeniem. Dostępne są dwa punkty obsługi: EC2_INSTANCE_LAUNCHING (po uruchomieniu, przed umieszczeniem instancji w stanie InService) oraz EC2_INSTANCE_TERMINATING (po podjęciu decyzji o zakończeniu, przed faktycznym zakończeniem instancji). Podczas działania haka instancja znajduje się w stanie Pending:Wait lub Terminating:Wait.

Hak uruchamiania idealnie nadaje się do zadań, które muszą zostać ukończone, zanim instancja zacznie obsługiwać ruch: instalowania dodatkowego oprogramowania, pobierania konfiguracji z Parameter Store, rejestrowania w rejestrze wykrywania usług lub uruchamiania testów integracyjnych. ASG nie doda instancji do grupy docelowej modułu równoważenia obciążenia, dopóki hak nie zakończy działania (lub nie upłynie limit czasu). Zapobiega to kierowaniu ruchu do niekompletnie skonfigurowanej instancji.

Hak kończenia działa przed faktycznym zakończeniem instancji. Przykładowe zastosowania to: opróżnienie kolejki na poziomie aplikacji z obsługiwanych żądań, zapisanie danych z pamięci podręcznej w trwałym magazynie, wyrejestrowanie z rejestru usług lub skopiowanie plików dzienników do S3. Bez haka kończenia praca wykonywana przez instancję, która ma zostać zakończona, może zostać utracona. Hak zapewnia do 2 godzin (limit czasu heartbeat) na ukończenie zadań związanych z kontrolowanym zamknięciem.

Własna logika uruchomiona na instancji lub przez nią wyzwolona musi poinformować hak o zakończeniu działania. Należy użyć complete-lifecycle-action z wartością CONTINUE (normalna kontynuacja) lub ABANDON (w przypadku haka uruchamiania zakończenie instancji; w przypadku haka kończenia zignorowanie i kontynuowanie). Limit czasu haka można również przedłużać, wysyłając heartbeat w każdym odstępie, aż do osiągnięcia maksymalnego czasu trwania. Jeśli limit czasu haka zostanie przekroczony, zastosowana zostanie wartość DefaultResult.

Najczystszym sposobem reagowania na haki cyklu życia jest użycie Amazon EventBridge. Po uruchomieniu haka cyklu życia ASG wysyła zdarzenie do EventBridge. Reguła EventBridge przekazuje to zdarzenie do funkcji Lambda, która wykonuje wymaganą pracę, a następnie wywołuje complete-lifecycle-action. Ta architektura jest w pełni bezserwerowa, nie wymaga odpytywania i skaluje się automatycznie. Powiadomienia SQS i SNS są starszymi alternatywami, ale w nowych projektach preferowane jest EventBridge.

Gdy Instance Refresh zastępuje instancję, nadal uruchamiane są oba haki cyklu życia: hak kończenia dla starej instancji oraz hak uruchamiania dla nowej. Oznacza to, że logika kontrolowanego zamykania i inicjalizacji jest automatycznie wykonywana podczas aktualizacji metodą rolling update, a nie tylko podczas zwykłych zdarzeń skalowania. Przed wdrożeniem produkcyjnym należy zawsze przetestować logikę haków cyklu życia podczas etapowego Instance Refresh, aby zweryfikować jej prawidłowe działanie.

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

W tej lekcji poznali Państwo: Instance Refresh zastępuje instancje ASG partiami, kontrolowanymi przez MinHealthyPercentage i opcjonalne punkty kontrolne umożliwiające walidację w stylu canary; Lifecycle Hooks wstrzymują przejścia instancji podczas uruchamiania lub kończenia, aby wykonać własną logikę inicjalizacji albo kontrolowanego zamykania; natomiast EventBridge + Lambda to zalecany wzorzec reagowania na zdarzenia haków cyklu życia bez odpytywania. Następnie omówimy funkcje AWS Lambda, środowiska uruchomieniowe, wyzwalacze i handlery.