Automatyzacja i elastyczność
Jedną z największych zalet chmury jest to, że infrastruktura może się sama dostosowywać do potrzeb. Nie musisz ręcznie dodawać serwerów o 3 w nocy, gdy Twoja promocja staje się viralem. W tej lekcji zagłębimy się w Auto Scaling, poznamy różne polityki skalowania i nauczymy się budować architektury, które naprawiają się same.
Auto Scaling: deep dive
Znasz już podstawy Auto Scaling z wcześniejszych lekcji. Teraz czas na szczegóły, które mogą pojawić się na egzaminie.
Auto Scaling Group (ASG) to zbiór instancji EC2, którymi zarządza Auto Scaling. Definiujesz:
- Minimum capacity: najmniejsza liczba instancji (np. 2). Nawet przy zerowym ruchu ASG utrzyma tyle instancji
- Desired capacity: docelowa liczba instancji. Auto Scaling stara się utrzymać tę liczbę
- Maximum capacity: górny limit (np. 10). Zabezpieczenie przed niekontrolowanym skalowaniem i kosztami
Scaling Policies
Auto Scaling oferuje kilka strategii skalowania. Każda ma swoje zastosowanie:
1. Target Tracking Scaling
Najprostsza i najczęściej używana. Mówisz: "chcę, żeby średnie CPU było na poziomie 50%". Auto Scaling sam dodaje lub usuwa instancje, żeby utrzymać ten cel.
To jak termostat: ustawiasz temperaturę 21°C, a system sam włącza/wyłącza ogrzewanie. Nie musisz definiować reguł "jeśli powyżej 25°C, wyłącz", bo system sam to ogarnia.
2. Step Scaling
Definiujesz konkretne progi i akcje. Na przykład:
- CPU 60-70%: dodaj 1 instancję
- CPU 70-80%: dodaj 2 instancje
- CPU powyżej 80%: dodaj 3 instancje
Daje większą kontrolę niż Target Tracking, ale wymaga ręcznej konfiguracji progów.
3. Simple Scaling
Najprostsza: jeden alarm, jedna akcja. "Jeśli CPU > 70%, dodaj 1 instancję". Problem: po dodaniu instancji czeka (cooldown period) zanim może dodać kolejną. Przez to reaguje wolno na nagłe skoki.
4. Scheduled Scaling
Skalujesz na podstawie harmonogramu. "W poniedziałek o 8:00 zwiększ do 10 instancji, w piątek o 18:00 zmniejsz do 3". Idealne, gdy znasz wzorce ruchu z góry.
5. Predictive Scaling
AWS używa machine learning do analizy historycznych wzorców ruchu i przewiduje przyszłe zapotrzebowanie. System sam skaluje z wyprzedzeniem, zanim ruch wzrośnie. Łączy się z innymi politykami (np. Target Tracking) dla najlepszych rezultatów.
| Polityka | Kiedy użyć | Złożoność |
|---|---|---|
| Target Tracking | Większość przypadków (domyślny wybór) | Niska |
| Step Scaling | Gdy potrzebujesz różnej reakcji na różne poziomy obciążenia | Średnia |
| Simple Scaling | Proste scenariusze (ma cooldown, reaguje wolniej) | Niska |
| Scheduled Scaling | Przewidywalne wzorce (np. godziny pracy) | Niska |
| Predictive Scaling | Gdy masz historyczne dane i chcesz wyprzedzić ruch | Niska (ML robi robotę) |
Launch Templates
Launch Template to "przepis" na instancję EC2. Definiuje wszystko, czego Auto Scaling potrzebuje, żeby uruchomić nową instancję:
- AMI (obraz systemu)
- Instance type (np. t3.micro)
- Key pair (klucz SSH)
- Security groups
- User data (skrypt startowy)
- Storage (EBS volumes)
- IAM Instance Profile
Launch Templates zastąpiły starsze Launch Configurations. Kluczowa różnica: Launch Templates wspierają wersjonowanie (możesz mieć v1, v2, v3 i przełączać się między nimi) oraz Mixed Instances Policy (różne typy instancji w jednym ASG).
Lifecycle hooks pozwalają wykonać dodatkowe akcje podczas uruchamiania lub wyłączania instancji w ASG:
- Launching hook: zatrzymuje instancję w stanie "Pending:Wait" zanim dołączy do ASG. Czas na instalację dodatkowego oprogramowania, pobranie konfiguracji, rejestrację w systemie monitoringu.
- Terminating hook: zatrzymuje instancję w stanie "Terminating:Wait" zanim zostanie usunięta. Czas na graceful shutdown, zapis logów, wyrejestrowanie z load balancera.
Przykład: masz aplikację, która przy starcie pobiera model ML z S3 (trwa 5 minut). Bez lifecycle hook ASG od razu kierowałby ruch na nową instancję, zanim model jest gotowy. Z hookiem instancja najpierw pobiera model, a dopiero potem dołącza do grupy i zaczyna obsługiwać ruch.
Self-Healing Architectures
W tradycyjnej infrastrukturze, gdy serwer padnie, ktoś musi zauważyć problem, zalogować się, zdiagnozować i naprawić. W chmurze możesz zbudować architekturę, która naprawia się sama.
Jak to działa z Auto Scaling?
- ASG uruchamia instancje w wielu AZ
- ELB wykonuje health checks co kilka sekund
- Jeśli instancja nie odpowiada na health check, ELB przestaje do niej kierować ruch
- ASG wykrywa "unhealthy" instancję i ją terminuje
- ASG uruchamia nową instancję (z Launch Template) w zdrowej AZ
- ELB automatycznie zaczyna kierować ruch na nową instancję
Cały proces dzieje się automatycznie, bez interwencji człowieka.
Firma chce automatycznie reagować na zdarzenia w infrastrukturze. Oto jak to zbudować z EventBridge + Lambda:
- EC2 instance terminates: EventBridge przechwytuje event, Lambda wysyła alert na Slack i tworzy ticket w systemie helpdesk
- S3 object uploaded: EventBridge wykrywa nowy plik, Lambda uruchamia pipeline przetwarzania (np. kompresja obrazu, generowanie miniatur)
- Security Group changed: EventBridge łapie zmianę, Lambda sprawdza, czy zmiana jest zgodna z polityką. Jeśli nie, automatycznie cofa zmianę i powiadamia admina
To jest prawdziwa automatyzacja. Nie musisz monitorować logów i ręcznie reagować. System sam pilnuje się i naprawia.
Elastyczność vs Skalowanie
Dwa pojęcia, które łatwo pomylić:
Scalability (skalowalność) to zdolność systemu do obsługi rosnącego obciążenia. Dwa typy:
- Vertical scaling (scale up/down): zwiększasz moc jednej instancji (np. z t3.micro na t3.large). Ma limit (największa instancja), wymaga restartu.
- Horizontal scaling (scale out/in): dodajesz więcej instancji tego samego typu. Teoretycznie bez limitu, nie wymaga downtime.
Elasticity (elastyczność) to zdolność do automatycznego skalowania w górę i w dół w odpowiedzi na zapotrzebowanie. Elastyczność = skalowalność + automatyzacja. Auto Scaling daje elastyczność.
Automatyzacja z AWS
Oprócz Auto Scaling, AWS oferuje wiele narzędzi do automatyzacji:
- EventBridge: event bus, reaguje na zdarzenia w AWS (i zewnętrzne) i uruchamia akcje
- Lambda: serverless compute, idealne jako "klej" łączący usługi i automatyzujący zadania
- Systems Manager: automatyzacja operacji na EC2 (patching, konfiguracja, Run Command)
- CloudFormation / CDK: Infrastructure as Code, automatyczny provisioning całej infrastruktury
- Step Functions: orkiestracja wielokrokowych workflow (np. pipeline przetwarzania danych)
- Auto Scaling Group (ASG) zarządza instancjami EC2 z minimum, desired i maximum capacity
- Target Tracking to najprostsza i najczęściej używana polityka skalowania (jak termostat)
- Predictive Scaling używa ML do przewidywania ruchu i skalowania z wyprzedzeniem
- Launch Templates to "przepis" na instancję EC2, wspierają wersjonowanie
- Self-healing: ASG + ELB automatycznie zastępują uszkodzone instancje
- Elasticity = automatyczne skalowanie w górę i w dół. Scalability = zdolność do obsługi większego obciążenia
- EventBridge + Lambda = potężna kombinacja do automatyzacji reakcji na zdarzenia
Która polityka Auto Scaling jest najlepsza, gdy chcesz utrzymać średnie wykorzystanie CPU na poziomie 60%?
Czym różni się elasticity od scalability?
Auto Scaling Group ma: minimum = 2, desired = 4, maximum = 6. Jedna instancja pada. Co się stanie?