Filary niezawodności i efektywności wydajnościowej
Projektować rozwiązania z automatycznym odtwarzaniem, skalowaniem horyzontalnym i zarządzaniem pojemnością; dobierać właściwe typy zasobów i monitorować je, aby utrzymywać wydajność w czasie.
Filary niezawodności i efektywności wydajnościowej to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Omówienie filaru niezawodności
Filar niezawodności Well-Architected Framework zapewnia, że obciążenie wykonuje swoją zamierzoną funkcję poprawnie i spójnie, gdy jest to wymagane. Niezawodność obejmuje trzy obszary: podstawy (limity usług, topologia sieci), architekturę obciążenia (systemy rozproszone, unikanie pojedynczych punktów awarii) oraz zarządzanie zmianami i awariami (monitorowanie, skalowanie, odzyskiwanie po awarii). Celem jest budowanie systemów, które automatycznie odzyskują sprawność po zakłóceniach infrastruktury lub usług.
# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)
# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS BackupLimity usług i przydziały
AWS nakłada przydziały usług (wcześniej nazywane limitami) na zasoby, aby chronić wszystkich klientów. Przykładami są domyślne limity instancji EC2 w regionie, limity VPC oraz liczba równoczesnych wykonań Lambda. Jeśli obciążenie niespodziewanie osiągnie przydział, żądania będą ograniczane lub odrzucane, co spowoduje problemy z niezawodnością. Należy używać konsoli Service Quotas lub interfejsu CLI, aby wyświetlać bieżące limity i żądać ich zwiększenia, zanim będzie to potrzebne. Należy monitorować metryki użycia, aby wykryć zbliżanie się do limitów, zanim wpłyną one na dostępność.
# List service quotas for EC2
aws service-quotas list-service-quotas \
--service-code ec2 \
--query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'
# Request quota increase
aws service-quotas request-service-quota-increase \
--service-code ec2 \
--quota-code L-1216C47A \
--desired-value 500Automatyczne odzyskiwanie po awarii
Filar niezawodności kładzie nacisk na automatyczne odzyskiwanie bez udziału człowieka. AWS udostępnia wiele mechanizmów samonaprawiania: EC2 Auto Recovery automatycznie przywraca instancję na tym samym sprzęcie lub przenosi ją na sprawny sprzęt, gdy nie przejdzie ona testów bazowych. Testy kondycji ASG kończą działanie niesprawnych instancji i uruchamiają ich zamienniki. RDS Multi-AZ automatycznie przełącza działanie na instancję zapasową. Architekturę należy projektować tak, aby większość scenariuszy awarii uruchamiała automatyczne działania naprawcze rejestrowane w alarmach CloudWatch.
# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
--alarm-name EC2-auto-recover \
--metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
--comparison-operator GreaterThanThreshold \
--threshold 0 \
--evaluation-periods 2 \
--alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'Skalowanie horyzontalne na rzecz niezawodności
Filar niezawodności zaleca skalowanie horyzontalne (dodawanie większej liczby mniejszych instancji) zamiast skalowania wertykalnego (zwiększania rozmiaru instancji), aby poprawić niezawodność. Pojedyncza duża instancja jest pojedynczym punktem awarii. Wiele mniejszych instancji za modułem równoważenia obciążenia oznacza, że awaria dowolnej z nich ma minimalny wpływ na system. AWS Auto Scaling automatycznie dostosowuje rozmiar floty do zapotrzebowania, zapewniając zarówno wystarczającą pojemność, jak i brak opłat za bezczynne zasoby w okresach małego obciążenia.
# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
# - Failure of 1 = loss of 10% capacity
# - ASG launches replacement automatically
# - 9 instances absorb load during replacement
# 1 r5.4xlarge:
# - Failure = 100% downtime until instance recovered
# - Much higher RTO (new instance launch: 1-3 min)
# Prefer horizontal scaling for stateless tiersTestowanie niezawodności
Filar niezawodności wymaga testowania procedur odzyskiwania, a nie zakładania, że działają. Należy używać AWS Fault Injection Simulator (FIS) do kontrolowanego wprowadzania awarii do systemu: losowego kończenia instancji EC2, ograniczania liczby wywołań API i wprowadzania opóźnień sieciowych. Eksperymenty te należy przeprowadzać na produkcji (z zastosowaniem zabezpieczeń), aby sprawdzić, czy monitorowanie wykrywa awarie, automatyczne skalowanie reaguje, a odzyskiwanie kończy się w ramach RTO. Niesprawdzone procedury odzyskiwania często zawodzą pod presją rzeczywistego incydentu.
# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
--description 'Chaos: terminate 1 of 5 instances' \
--targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
--actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
--stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'Omówienie filaru efektywności wydajnościowej
Filar efektywności wydajnościowej koncentruje się na efektywnym wykorzystywaniu zasobów obliczeniowych w celu spełnienia wymagań systemu oraz utrzymywaniu tej efektywności wraz ze zmianami zapotrzebowania i rozwojem technologii. Kluczowe zasady projektowania: udostępnianie zaawansowanych technologii — używanie usług zarządzanych (RDS, SageMaker) zamiast tworzenia wszystkiego od podstaw. Globalny zasięg w kilka minut — wdrażanie w wielu regionach za pomocą CloudFormation. Używanie architektur serverless — wyeliminowanie zarządzania infrastrukturą. Częstsze eksperymentowanie — testowanie różnych typów instancji i konfiguracji.
# Performance Efficiency areas:
# Selection: Right compute, storage, database, network
# Review: Continuously evaluate new services
# Monitoring: CloudWatch metrics guide decisions
# Trade-offs: Consistency vs performance, latency vs cost
# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scaleWybór odpowiednich zasobów obliczeniowych
Efektywność wydajnościowa zaczyna się od wyboru odpowiedniego typu zasobów obliczeniowych dla obciążenia. EC2 oferuje dziesiątki rodzin instancji zoptymalizowanych pod kątem różnych zastosowań: seria c do zadań intensywnie wykorzystujących procesor (kodowanie wideo, przetwarzanie wsadowe), seria r do zadań intensywnie wykorzystujących pamięć (bazy danych działające w pamięci, buforowanie), seria i do zadań intensywnie wykorzystujących pamięć masową (NoSQL, hurtownie danych), serie p/g do obciążeń GPU (trenowanie modeli ML). Użycie niewłaściwego typu instancji oznacza płacenie za niewykorzystywaną pojemność lub obniżenie wydajności.
# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345
# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing
# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisationBuforowanie na rzecz efektywności wydajnościowej
Buforowanie jest podstawową techniką poprawy efektywności wydajnościowej, która zmniejsza opóźnienia i obciążenie bazy danych. ElastiCache (Redis/Memcached) buforuje wyniki zapytań do bazy danych w pamięci, zapewniając dostęp w milisekundach. CloudFront buforuje odpowiedzi HTTP w lokalizacjach brzegowych znajdujących się blisko użytkowników. Buforowanie API Gateway zmniejsza liczbę wywołań Lambda przez buforowanie odpowiedzi API. DAX (DynamoDB Accelerator) dodaje mikrosekundową pamięć podręczną działającą w pamięci przed DynamoDB. Należy wybrać odpowiednią warstwę buforowania w zależności od miejsca występowania wąskiego gardła — w bazie danych, API lub dostarczaniu brzegowym.
# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
--cluster-name my-dax \
--node-type dax.r6g.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123:role/DAXRole \
--subnet-group my-dax-subnet-group
# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches resultOdpowiednia pamięć masowa dla wydajności
Wybór pamięci masowej ma ogromny wpływ na wydajność. io2 Block Express EBS zapewnia do 256 000 IOPS dla wysokowydajnych baz danych. gp3 jest domyślnym wyborem dla większości obciążeń i charakteryzuje się niższym kosztem. Instance store zapewnia najwyższą liczbę IOPS (NVMe) dla danych tymczasowych. S3 skaluje się do tysięcy żądań na sekundę w przypadku magazynowania obiektów. EFS zapewnia współdzielony dostęp do plików POSIX. Pamięć masową należy dopasować do wzorca operacji wejścia-wyjścia: odczyty sekwencyjne korzystają z st1 (dysk HDD zoptymalizowany pod kątem przepustowości), natomiast losowe operacje wejścia-wyjścia wymagają woluminów SSD.
# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)
# Create high-performance io2 volume
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type io2 \
--size 500 \
--iops 50000Monitorowanie wydajności i ciągłe doskonalenie
Efektywność wydajnościowa nie jest decyzją podejmowaną tylko raz — należy stale monitorować metryki wydajności i ponownie oceniać wybory wraz z udostępnianiem przez AWS nowych usług. Należy używać pulpitów nawigacyjnych CloudWatch do śledzenia percentyli opóźnień p50, p90 i p99 (a nie tylko średnich, które ukrywają opóźnienia skrajne). Należy używać śladów X-Ray do identyfikowania najwolniejszych elementów łańcucha żądania. Należy skonfigurować wykrywanie anomalii CloudWatch, aby automatycznie wyznaczać wartości bazowe i alarmować o nietypowych odchyleniach wydajności. Należy regularnie przeglądać komunikaty AWS — nowsze typy instancji często zapewniają lepszą wydajność przy niższym koszcie.
# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
--alarm-name 'API-P99-Latency' \
--metric-name TargetResponseTime \
--namespace AWS/ApplicationELB \
--extended-statistic p99 \
--dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
--period 60 \
--evaluation-periods 5 \
--threshold 2.0 \
--comparison-operator GreaterThanThresholdKompromisy w zakresie efektywności wydajnościowej
Efektywność wydajnościowa czasami wymaga kompromisów z innymi filarami. Dodanie pamięci podręcznej (ElastiCache) poprawia wydajność, ale zwiększa złożoność operacyjną (kompromis względem doskonałości operacyjnej) i koszty (kompromis względem optymalizacji kosztów). Użycie DynamoDB zamiast RDS poprawia wydajność na dużą skalę, ale wymaga przeprojektowania modelu danych (wysiłek związany z doskonałością operacyjną). Well-Architected Framework uwzględnia te kompromisy i wymaga podejmowania ich w sposób świadomy oraz dokumentowania uzasadnienia. W pytaniach egzaminacyjnych należy szukać opcji, która osiąga cele wydajnościowe przy najmniejszym narzucie operacyjnym.
# Common performance vs cost trade-offs:
# Cache: +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD: +IOPS, +Cost
# Multi-region: -Latency for users, +Cost, +Complexity
# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lagSzybkie sprawdzenie
Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo następujące zagadnienia: niezawodność wymaga automatycznego odzyskiwania, skalowania horyzontalnego i regularnego testowania awarii, efektywność wydajnościowa wymaga wyboru odpowiedniego typu zasobów obliczeniowych, pamięci masowej i bazy danych dla każdego obciążenia, a buforowanie na wielu warstwach zmniejsza opóźnienia i obciążenie bazy danych. Oba filary wymagają ciągłego monitorowania i gotowości do ponownego analizowania decyzji architektonicznych. Następnie omówimy filary optymalizacji kosztów i zrównoważonego rozwoju.
Często zadawane pytania
Czy lekcja „Filary niezawodności i efektywności wydajnościowej” jest bezpłatna?
Tak — pełny tekst „Filary niezawodności i efektywności wydajnościowej” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Co nauczysz się w „Filary niezawodności i efektywności wydajnościowej”?
Projektować rozwiązania z automatycznym odtwarzaniem, skalowaniem horyzontalnym i zarządzaniem pojemnością; dobierać właściwe typy zasobów i monitorować je, aby utrzymywać wydajność w czasie. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?
Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.
Ile czasu zajmuje lekcja „Filary niezawodności i efektywności wydajnościowej”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?
Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Filary doskonałości operacyjnej i bezpieczeństwa
- Filary niezawodności i efektywności wydajnościowej
- Filary optymalizacji kosztów i zrównoważonego rozwoju
- AWS Well-Architected Tool i proces przeglądu