AWS Solutions Architect · leksjon

Søyler for pålitelighet og ytelseseffektivitet

Utform løsninger for automatisk gjenoppretting, horisontal skalering og kapasitetsstyring; velg riktige ressurstyper og overvåk dem for å opprettholde ytelsen over tid

Leksjon 2 av 413 trinn

Søyler for pålitelighet og ytelseseffektivitet er en gratis leksjon i AWS Solutions Architect på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i AWS Solutions Architect, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i AWS Solutions Architect inneholder totalt 4 leksjoner.

Oversikt over pålitelighetssøylen

Pålitelighetssøylen i Well-Architected Framework sørger for at en arbeidsbelastning utfører den tiltenkte funksjonen korrekt og konsekvent når det forventes. Pålitelighet omfatter tre områder: grunnlag (tjenestegrenser, nettverkstopologi), arbeidsbelastningsarkitektur (distribuerte systemer, unngåelse av SPOF-er) og endrings- og feilhåndtering (overvåking, skalering og gjenoppretting etter feil). Målet er å bygge systemer som gjenopprettes automatisk etter avbrudd i infrastruktur eller tjenester.

# 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 Backup

Tjenestegrenser og kvoter

AWS håndhever tjenestekvoter (tidligere kalt grenser) for ressurser for å beskytte alle kunder. Eksempler er standardgrenser for EC2-instanser per region, VPC-grenser og samtidige Lambda-kjøringer. Hvis arbeidsbelastningen uventet når en kvote, blir forespørsler begrenset eller avvist, noe som fører til pålitelighetsfeil. Bruk Service Quotas-konsollen eller CLI til å se gjeldende grenser og be om økninger før De trenger dem. Overvåk bruksmetrikk for å oppdage når De nærmer Dem grensene, før de påvirker tilgjengeligheten.

# 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 500

Automatisk gjenoppretting etter feil

Pålitelighetssøylen legger vekt på automatisk gjenoppretting uten menneskelig inngripen. AWS tilbyr flere mekanismer for selvreparasjon: EC2 Auto Recovery gjenoppretter automatisk en instans på samme maskinvare eller flytter den til frisk maskinvare når den ikke består underliggende kontroller. ASG-helsesjekker avslutter ufriske instanser og starter erstatninger. RDS Multi-AZ utfører automatisk failover til standby-instansen. Utform arkitekturen slik at de fleste feilscenarier utløser automatiske gjenopprettingshandlinger som fanges opp av CloudWatch-alarmer.

# 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'

Horisontal skalering for pålitelighet

Pålitelighetssøylen anbefaler å skalere horisontalt (legge til flere mindre instanser) i stedet for vertikalt (skalere opp til større instanser) for bedre pålitelighet. Én stor instans er et enkelt feilpunkt. Mange mindre instanser bak en lastbalanserer betyr at en feil i én enkelt instans får minimal innvirkning. AWS Auto Scaling justerer automatisk størrelsen på instansgruppen etter behov, slik at De både har tilstrekkelig kapasitet og unngår å betale for uvirksomme ressurser i rolige perioder.

# 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 tiers

Testing for pålitelighet

Pålitelighetssøylen krever at De tester gjenopprettingsprosedyrer i stedet for å anta at de fungerer. Bruk AWS Fault Injection Simulator (FIS) til å sette inn feil i systemet på en kontrollert måte: avslutt tilfeldige EC2-instanser, begrens API-kall eller sett inn nettverksforsinkelse. Kjør disse eksperimentene i produksjon (med sikkerhetstiltak) for å kontrollere at overvåkingen oppdager feil, at autoskalering reagerer, og at gjenopprettingen fullføres innenfor Deres RTO. Utestede gjenopprettingsprosedyrer svikter ofte under belastningen fra en reell hendelse.

# 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"}]'

Oversikt over søylen for ytelseseffektivitet

Ytelseseffektivitetssøylen fokuserer på å bruke databehandlingsressurser effektivt for å oppfylle systemkravene og opprettholde denne effektiviteten når etterspørselen endres og teknologien utvikler seg. Viktige designprinsipper: Demokratiser avansert teknologi — bruk administrerte tjenester (RDS, SageMaker) i stedet for å bygge fra grunnen av. Gå globalt på minutter — distribuer til flere regioner med CloudFormation. Bruk serverløse arkitekturer — eliminer administrasjon av infrastruktur. Eksperimenter oftere — test ulike instanstyper og konfigurasjoner.

# 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, scale

Velge riktig databehandling

Ytelseseffektivitet starter med å velge riktig type databehandling for arbeidsbelastningen. EC2 har dusinvis av instansfamilier som er optimalisert for ulike bruksområder: c-serien for databehandlingsintensive oppgaver (videokoding, satsvis behandling), r-serien for minneintensive oppgaver (databaser i minnet, hurtigbufring), i-serien for lagringsintensive oppgaver (NoSQL, datavarehus), p/g-serien for GPU-arbeidsbelastninger (ML-trening). Hvis De bruker feil instanstype, betaler De for kapasitet De ikke kan utnytte, eller ytelsen blir dårligere.

# 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 optimisation

Hurtigbufring for ytelseseffektivitet

Hurtigbufring er en grunnleggende teknikk for ytelseseffektivitet som reduserer ventetid og belastning på databasen. ElastiCache (Redis/Memcached) lagrer resultater fra databaseforespørsler i minnet, slik at de kan hentes på millisekunder. CloudFront mellomlagrer HTTP-svar på kantlokasjoner nær brukerne. API Gateway-hurtigbufring reduserer antallet Lambda-kjøringer ved å mellomlagre API-svar. DAX (DynamoDB Accelerator) legger til en hurtigbuffer i minnet foran DynamoDB, med tilgang på mikrosekundnivå. Velg riktig hurtigbufferlag basert på hvor flaskehalsen ligger — database, API eller levering fra kanten.

# 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 result

Riktig lagring for ytelse

Valg av lagring har stor innvirkning på ytelsen. io2 Block Express EBS tilbyr opptil 256 000 IOPS for høytytende databaser. gp3 er standardvalget for de fleste arbeidsbelastninger til lavere kostnad. Instance store tilbyr de høyeste IOPS-verdiene (NVMe) for midlertidige data. S3 skalerer til tusenvis av forespørsler per sekund for objektlagring. EFS tilbyr delt POSIX-filtilgang. Tilpass lagringen til I/O-mønsteret: sekvensielle lesinger har fordel av st1 (Throughput Optimised HDD), mens tilfeldig I/O krever SSD-volumer.

# 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 50000

Ytelsesovervåking og kontinuerlig forbedring

Ytelseseffektivitet er ikke en engangsbeslutning — De må kontinuerlig overvåke ytelsesmetrikker og vurdere valgene Deres på nytt etter hvert som AWS lanserer nye tjenester. Bruk CloudWatch-dashbord til å følge p50-, p90- og p99-persentilene for ventetid (ikke bare gjennomsnittet, som skjuler ventetid i halen). Bruk X-Ray-spor til å identifisere de tregeste delene av en forespørselskjede. Konfigurer CloudWatch-anomalideteksjon til automatisk å etablere en normalverdi og varsle om unormale ytelsesavvik. Følg jevnlig med på AWS-kunngjøringer — nyere instanstyper gir ofte bedre ytelse til lavere kostnad.

# 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 GreaterThanThreshold

Avveininger i ytelseseffektivitet

Ytelseseffektivitet krever noen ganger avveininger mot andre søyler. En hurtigbuffer (ElastiCache) forbedrer ytelsen, men tilfører driftsmessig kompleksitet (en avveining mot operasjonell fremragende praksis) og kostnader (en avveining mot kostnadsoptimalisering). Bruk av DynamoDB i stedet for RDS forbedrer ytelsen i stor skala, men krever at datamodellen utformes på nytt (innsats innen operasjonell fremragende praksis). Well-Architected Framework anerkjenner disse avveiningene og ber Dem gjøre dem bevisst og dokumentere begrunnelsen. I eksamensoppgaver bør De se etter alternativet som oppnår ytelsesmålene med minst mulig driftsmessig merarbeid.

# 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 lag

Kort kontroll

Test forståelsen Deres av AWS Solutions Architect-konsepter (SAA-C03) fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen lærte De: Pålitelighet krever automatisk gjenoppretting, horisontal skalering og regelmessig testing av feil, ytelseseffektivitet krever at De velger riktig type databehandling, lagring og database for hver arbeidsbelastning, og hurtigbufring på flere lag reduserer ventetid og belastning på databasen. Begge søylene krever kontinuerlig overvåking og vilje til å vurdere arkitekturbeslutninger på nytt. Deretter utforsker vi søylene for kostnadsoptimalisering og bærekraft.

Gratis å komme i gang

Lær deg AWS Solutions Architect med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 30
Leksjoner: 120

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Søyler for pålitelighet og ytelseseffektivitet» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien AWS Solutions Architect, inkludert «Søyler for pålitelighet og ytelseseffektivitet», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i AWS Solutions Architect inneholder totalt 4 leksjoner.

Hva lærer jeg i «Søyler for pålitelighet og ytelseseffektivitet»?

Utform løsninger for automatisk gjenoppretting, horisontal skalering og kapasitetsstyring; velg riktige ressurstyper og overvåk dem for å opprettholde ytelsen over tid Du øver på AWS Solutions Architect med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med AWS Solutions Architect?

Ingen tidligere erfaring er nødvendig. AWS Solutions Architect på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Søyler for pålitelighet og ytelseseffektivitet»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne AWS Solutions Architect-leksjonen?

Ja. Alle AWS Solutions Architect-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Søyler for fremragende drift og sikkerhet
Søyler for pålitelighet og ytelseseffektivitet
Søyler for kostnadsoptimalisering og bærekraft
Well-Architected Tool og gjennomgangsprosessen

← Tilbake til AWS Solutions Architect