Szablony uruchamiania i konfiguracja ASG

Launch Template to wersjonowany wzorzec, który informuje grupy Auto Scaling (a także bezpośrednio EC2), jak uruchamiać instancje. Zawiera on identyfikator AMI, typ instancji, parę kluczy, grupy zabezpieczeń oraz opcjonalne dane użytkownika w jednym dokumencie wielokrotnego użytku. W przeciwieństwie do starszej funkcji Launch Configuration, Launch Template obsługuje wiele wersji i można go aktualizować bez zastępowania ASG.

Launch Template można utworzyć za pomocą AWS CLI, używając polecenia create-launch-template. Parametr --launch-template-data przyjmuje obiekt JSON definiujący wszystkie ustawienia instancji. Wersjonowanie umożliwia iteracyjne rozwijanie szablonu bez wpływu na uruchomione instancje, dopóki nie będzie Państwo gotowi do wdrożenia.

Każdy Launch Template rozpoczyna się od wersji 1. Podczas tworzenia nowej wersji można zastąpić tylko zmienione pola — wszystkie pozostałe ustawienia są dziedziczone z wersji źródłowej. ASG można skonfigurować tak, aby używał wersji $Latest (zawsze najnowszej) lub $Default (jawnie wyznaczonej). Użycie $Default zapewnia kontrolowane wdrożenia, natomiast $Latest jest wygodne w środowiskach programistycznych.

Auto Scaling Group (ASG) utrzymuje pulę instancji EC2 w określonych granicach: minimum (dolna granica), maximum (górna granica) oraz desired capacity (docelowa liczba w danym momencie). Gdy instancje nie przejdą kontroli stanu lub zadziała polityka skalowania, ASG automatycznie uruchamia albo kończy instancje, aby utrzymać docelową liczbę instancji między wartościami min i max.

Podczas tworzenia ASG odwołuje się Państwo do Launch Template, a nie bezpośrednio do konkretnego AMI. Należy również określić podsiecі VPC, w których będą uruchamiane instancje. Rozmieszczenie instancji w wielu podsieciach (po jednej na AZ) zapewnia wbudowaną nadmiarowość w wielu AZ — jeśli jedna strefa dostępności ulegnie awarii, ASG automatycznie uruchomi instancje zastępcze w pozostałych strefach.

Domyślnie ASG używa kontroli stanu EC2, które oznaczają instancję jako niesprawną tylko wtedy, gdy jest zatrzymana, zakończona lub hiperwizor zgłosi jej awarię. Po dołączeniu load balancera należy przełączyć się na kontrole stanu ELB, aby ASG zastępowała instancje, które działają, ale zwracają błędy HTTP 5xx. To częste pytanie egzaminacyjne: jeśli w architekturze znajduje się load balancer, zawsze należy wybrać kontrole stanu ELB.

Ustawienie właściwych granic pojemności ma kluczowe znaczenie. Minimum gwarantuje, że aplikacja zawsze będzie mogła obsługiwać ruch (nie spadnie poniżej tej wartości). Maximum zapobiega niekontrolowanemu skalowaniu, które mogłoby wyczerpać limity usług lub budżet. Desired capacity to początkowy cel; polityki skalowania dostosowują go dynamicznie. Jeśli wartości min=max=desired są takie same, ASG działa jako grupa o stałym rozmiarze, co jest przydatne przy wdrożeniach z użyciem Launch Template lub przy utrzymywaniu stałej pojemności.

W przypadku aplikacji warstwy webowej należy dołączyć ASG do grupy docelowej Application Load Balancer. Każda nowa instancja uruchomiona przez ASG jest automatycznie rejestrowana w grupie docelowej, a zakończone instancje są z niej automatycznie wyrejestrowywane. Dzięki temu ruch jest kierowany wyłącznie do sprawnych i działających instancji. Należy również ustawić typ kontroli stanu na ELB, aby ASG uwzględniała awarie wykrywane na poziomie load balancera.

User data to skrypt powłoki (zakodowany w Base64), który jest uruchamiany raz, podczas pierwszego uruchomienia instancji. W Launch Template jest to właściwe miejsce na instalowanie pakietów, konfigurowanie agentów (CloudWatch, SSM) i pobieranie kodu aplikacji. User data powinno być idempotentne — skrypty, które można bezpiecznie uruchamiać wielokrotnie, zapobiegają problemom podczas odświeżania instancji. W przypadku złożonych konfiguracji należy zamiast umieszczania dużych skryptów wywołać AWS Systems Manager lub narzędzie do zarządzania konfiguracją.

Warm Pool wstępnie inicjalizuje zestaw zatrzymanych (lub działających) instancji EC2 w stanie gotowości, poza ASG. Gdy ASG musi skalować się w górę, pobiera instancje z warm pool zamiast uruchamiać je od zera — znacznie skracając czas potrzebny na zwiększenie pojemności. Instancje w warm pool generują koszty stanu zatrzymania (tylko EBS, bez opłat za procesor), dzięki czemu rozwiązanie to jest znacznie tańsze niż utrzymywanie w pełni działających zapasowych instancji.

Gdy ASG skaluje się w dół, musi zdecydować, które instancje zakończyć. Domyślna polityka kończenia najpierw wybiera AZ z największą liczbą instancji (aby przywrócić równowagę), następnie instancje z najstarszym Launch Template, a na końcu instancję najbardziej zbliżoną do rozpoczęcia kolejnej godziny rozliczeniowej. Mogą Państwo dostosować tę kolejność — na przykład wybrać OldestLaunchTemplate, aby najpierw usuwać instancje działające ze starymi konfiguracjami. ASG automatycznie wykonuje również równoważenie AZ po udostępnieniu podsieci lub po ręcznych zmianach.

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

W tej lekcji poznali Państwo następujące zagadnienia: Launch Templates zapewniają wersjonowany i wielokrotnego użytku szablon instancji obsługujący wiele wersji oraz wskaźniki wersji $Latest/$Default, granice pojemności ASG (min/max/desired) określają rozmiar puli i zapewniają automatyczne rozmieszczanie w wielu AZ za pośrednictwem podsieci, a kontrole stanu ELB muszą być włączone, gdy ASG znajduje się za load balancerem, aby awarie na poziomie aplikacji uruchamiały zastępowanie instancji. W następnej części omówimy polityki skalowania, w tym target tracking i step scaling.