Amazon SOA-C02: Moc obliczeniowa i Auto Scaling — Przewodnik do nauki

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Część AWS SysOps Administrator Associate SOA-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Rozmieszczenie instancji, planowanie pojemności i metryki skalowania

Decyzje o rozmieszczeniu wpływają na opóźnienia i domeny awarii: grupy rozmieszczenia (placement groups) oferują strategie cluster (sieć o niskim opóźnieniu), spread (jedna instancja na szafę rack dla krytycznych instancji) oraz partition (izolowane od awarii partycje). ASG domyślnie równoważą instancje pomiędzy Strefami Dostępności (AZ); preferuj planowanie pojemności z uwzględnieniem AZ, aby unikać hotspotów w pojedynczej strefie. Dla CLI:

undefined

Planowanie pojemności uwzględnia typy instancji, opcje zakupu i metryki:

Typy instancji: wybieraj rodziny zoptymalizowane pod kątem CPU/pamięci/sieci (M/C/R/T/D/I) na podstawie obciążenia roboczego; mierz wydajność za pomocą reprezentatywnych testów obciążeniowych.
Opcje zakupu: On-Demand dla przewidywalności, Reserved lub Savings Plans dla redukcji kosztów przy stałym obciążeniu, Spot dla efektywności kosztowej przy obciążeniach przejściowych; użyj MixedInstancesPolicy do łączenia typów instancji i opcji zakupu.
Metryki skalowania: domyślne metryki ASG używają średniego zużycia CPU w całej grupie; preferuj metryki na poziomie aplikacji, takie jak ALB RequestCountPerTarget lub niestandardowe metryki CloudWatch (np. głębokość kolejki) do śledzenia celu (target tracking). Typowe wzorce:
Używaj target tracking z ALB/request-count-per-target, gdy potrzebujesz stałej liczby żądań na instancję.
Używaj skalowania krokowego (step scaling) do obsługi nagłych, dużych skoków ruchu z zdefiniowanymi krokami powrotu.
Rozważ Predictive Scaling dla obciążeń o cyklicznym, dobowym charakterze.

Odzyskiwanie instancji, zachowanie przy zakończeniu i konserwacja

Planuj na wypadek awarii instancji i konserwacji, włączając automatyczne odzyskiwanie po problemach sprzętowych (alarm CloudWatch z akcją EC2 Recover) i obsługując zaplanowane zdarzenia (describe-instance-status). Skonfiguruj flagi instance-initiated-shutdown-behavior i DeleteOnTermination dla EBS, aby kontrolować cykl życia woluminów; użyj

undefined

, aby je dostosować.

Zachowanie przy zakończeniu w ASG: Polityki kończenia (termination policies) w ASG decydują, która instancja zostanie zakończona jako pierwsza (Domyślnie: najstarsza konfiguracja uruchomieniowa lub heurystyki oparte na stanie instancji i równoważeniu AZ). Ważne szczegóły operacyjne:

Stan lokalny jest efemeryczny: woluminy instance-store i pamięć podręczna w pamięci RAM są tracone po zakończeniu instancji. Nie zakładaj, że instancja zastępcza zachowa stan lokalny; utrwalaj krytyczne dane na EBS (z odpowiednimi snapshotami/kopiami zapasowymi), S3 lub w zewnętrznej pamięci podręcznej (ElastiCache).
Używaj haków cyklu życia (lifecycle hooks) do odsączania ruchu (draining) i przenoszenia stanu przed zakończeniem instancji.
Używaj odświeżania instancji (instance refresh) lub wdrożeń blue/green do bezpiecznej wymiany instancji podczas konserwacji;

undefined

Częste pułapki i kryteria decyzyjne

Poleganie na domyślnych okresach cooldown i metrykach opartych tylko na CPU: wybieraj metryki dopasowane do zachowania aplikacji (ALB RequestCountPerTarget, głębokość kolejki); ustawiaj okresy cooldown, aby uwzględnić czas uruchomienia, oraz HealthCheckGracePeriod, aby uniknąć oscylacji.
Nieużywanie haków cyklu życia do łagodnego kończenia (graceful termination): bez haków, żądania w trakcie przetwarzania i lokalne pamięci podręczne są tracone; zaimplementuj haki z SNS/SQS/Lambda, aby odsączyć ruch i utrwalić stan.
Zakładanie, że instancja zastępcza zachowuje stan lokalny: lokalne woluminy instance-store i pamięci podręczne w RAM są efemeryczne; projektuj instancje jako bezstanowe lub replikuj stan do trwałych magazynów danych.
Nadużywanie sesji przylepnych (stickiness): sesje przylepne zwiększają nierównomierne rozłożenie obciążenia i komplikują skalowanie oraz aktualizacje; preferuj zewnętrzne magazyny sesji (ElastiCache, DynamoDB) dla skalowania w poziomie (scale-out).
Ignorowanie równoważenia między AZ i grup rozmieszczenia: umieszczanie zbyt wielu instancji w jednej AZ lub grupie typu cluster może tworzyć pojedyncze punkty awarii; używaj dystrybucji multi-AZ w ASG i odpowiednich strategii grup rozmieszczenia.
Błędna konfiguracja integracji kontroli stanu (health checks): typ kontroli stanu ASG (health-check-type) musi być zgodny z kontrolami stanu ELB/grupy docelowej, a HealthCheckGracePeriod musi być wystarczająco długi, aby aplikacja zdążyła się zainicjować, w przeciwnym razie zdrowe instancje będą kończone.

Problem praktyczny: Scenariusz użycia

Firma StreamingCo obsługuje API do generowania miniatur wideo, które doświadcza codziennych skoków ruchu i używa lokalnych pamięci podręcznych na dyskach instancji EC2; ostatnio skalowanie w górę jest powolne, a kończone instancje tracą pamięć podręczną, co prowadzi do słabych czasów odpowiedzi.

Zmigruj konfigurację uruchomieniową (launch configuration) do szablonu uruchomieniowego (Launch Template) i przygotuj (bake) lekki obraz AMI z zależnościami środowiska uruchomieniowego; użyj

undefined

i wersjonowania dla niezmiennych wdrożeń (immutable deploys). 2. Skonfiguruj ASG z MixedInstancesPolicy, która zawiera listę kilku typów instancji oraz alokację Spot + On-Demand w celu zrównoważenia kosztów i pojemności. 3. Podłącz ALB i użyj skalowania TargetTrackingScaling opartego na metryce ALB RequestCountPerTarget, z HealthCheckGracePeriod ustawionym na czas startu aplikacji. 4. Zaimplementuj haki cyklu życia (lifecycle hooks) przy kończeniu instancji w ASG, aby odsączyć połączenia i uruchomić przepływ Lambda/SNS w celu utrwalenia niezbędnych kluczy pamięci podręcznej w ElastiCache lub S3 przed zakończeniem instancji. 5. Przenieś stan sesji i pamięci podręcznej na zewnątrz, do ElastiCache lub S3, i użyj grup rozmieszczenia/dystrybucji między AZ, aby spełnić wymagania dotyczące opóźnień i domen awarii.

Uzasadnienie: Użycie szablonów uruchomieniowych i niezmiennych wdrożeń zmniejsza zmienność czasu uruchamiania; target tracking powiązany z ALB uzależnia skalowanie od obciążenia żądaniami, a nie od CPU; haki cyklu życia zapobiegają utracie danych przy kończeniu instancji; przeniesienie pamięci podręcznej na zewnątrz eliminuje zależność od efemerycznego stanu lokalnego, umożliwiając szybkie, bezpieczne skalowanie i niższe koszty dzięki strategiom mieszanych typów instancji i opcji zakupu.

← Pamięć masowa i zarządzanie danymi · Wszystkie domeny · Bazy danych i buforowanie →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →