Cloud & IT Cert Prep · Oppitunti

Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot

Oppitunti 2/413 vaihetta

Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot on ilmainen Cloud & IT Cert Prep-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Cloud & IT Cert Prep-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.

Skenaario 1: Multi-AZ-verkkosovellus

Skenaario: Yritys käyttää kaksitasoista verkkosovellusta (ALB → EC2 → RDS) ja haluaa poistaa kaikki yksittäiset vikapisteet AWS-alueen sisältä. Ratkaisu: Ota EC2-instanssit käyttöön Auto Scaling Groupissa, joka kattaa vähintään 2 Availability Zonea ALB:n takana (ALB on luonnostaan usean AZ:n kattava). Ota RDS Multi-AZ käyttöön synkroniseen valmiustilareplikointiin. Määritä ALB:n kuntotarkistukset ohjaamaan liikenne automaattisesti pois viallisilta instansseilta. Tällä arkkitehtuurilla minkä tahansa yksittäisen AZ:n menetys käynnistää automaattisen failoverin kaikilla tasoilla.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Skenaario 2: RDS:n lukuskaalaus kuormituksessa

Skenaario: Verkkokauppasovelluksen RDS-instanssi saavuttaa suorittimen rajat ruuhka-aikoina, koska business intelligence -tiimin analytiikkakyselyt painottuvat lukemiseen. Ratkaisu: Luo RDS Read Replicas ja ohjaa BI-kyselyt replikan endpointiin. Read Replicas käyttää asynkronista replikointia — pieni viive on analytiikassa hyväksyttävä. Tämä siirtää lukuliikenteen pois ensisijaiselta RDS-instanssilta, joka jää kirjoitusoperaatioiden ja sovelluksen lukujen käyttöön. Jos työkuorma on erittäin lukupainotteinen, lisää RDS:n eteen ElastiCache-taso usein käytetyille tiedoille.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Skenaario 3: Auto Scaling suorittimen kuormituspiikin aikana

Skenaario: Tilaton API toimii EC2-instansseissa ALB:n takana. Suorittimen käyttöaste nousee työaikana 90 prosenttiin ja laskee yöllä lähes nollaan. Yritys haluaa skaalata instanssijoukon automaattisesti. Ratkaisu: Määritä Auto Scaling Group, jossa on Target Tracking -skaalauskäytäntö ja jonka tavoitteena on 60 prosentin keskimääräinen suorittimen käyttöaste. ASG lisää instansseja automaattisesti, kun suorittimen käyttöaste ylittää 60 prosenttia, ja poistaa niitä, kun käyttöaste laskee tavoitteen alle. Lisää ajastettu skaalaustoiminto lämmittämään vähimmäiskapasiteetti etukäteen ennen työajan alkua, jotta aamuisen liikennepiikin aikana ei esiinny viivettä.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Skenaario 4: Route 53:n failover DR-sivustolle

Skenaario: Yrityksen ensisijainen verkkosovellus toimii alueella us-east-1, ja yritys haluaa siirtyä alueella us-west-2 sijaitsevalle staattiselle, S3:n isännöimälle huoltosivulle, jos ensisijainen sovellus muuttuu toimimattomaksi. Ratkaisu: Luo Route 53 -kuntotarkistus valvomaan ensisijaisen ALB:n endpointia. Luo kaksi Route 53 -tietuetta, joissa on failover-reitityskäytäntö: ensisijainen tietue osoittaa ALB:hen ja on yhdistetty kuntotarkistukseen, ja toissijainen tietue osoittaa S3:n staattiseen sivustoon. Jos kuntotarkistus epäonnistuu, Route 53 palauttaa DNS-vastauksena automaattisesti toissijaisen tietueen.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Skenaario 5: Resilienssin lisääminen SQS:n avulla

Skenaario: Tilausten käsittelyn taustajärjestelmä kirjoittaa tietokantaan, mutta tietokanta ei toisinaan ole käytettävissä huoltoikkunoiden aikana, jolloin tilauksia menetetään. Ratkaisu: Sijoita SQS-jono käyttöliittymän, joka vastaanottaa tilaukset, ja niitä käsittelevän taustajärjestelmän väliin. Tilaukset asetetaan jonoon heti, jolloin asiakas saa välittömän kuittauksen. Taustatyöntekijät noutavat tilaukset jonosta ja käsittelevät ne, kun tietokanta on käytettävissä. Huollon aikana tilaukset kertyvät jonoon sen sijaan, että ne hylättäisiin — näin asynkroninen irtikytkentä parantaa vikasietoisuutta.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Skenaario 6: Pilot Light -palautusratkaisu

Skenaario: Yritys tarvitsee kohtuuhintaisen katastrofipalautusratkaisun, jonka RPO on 1 tunti ja RTO 4 tuntia. Ratkaisu: Toteuta Pilot Light -palautusstrategia. Pidä ydintietokanta replikoituna DR-alueelle käyttämällä RDS Cross-Region Read Replica -toimintoa. Sovelluspalvelimet eivät ole normaalin toiminnan aikana käynnissä DR-alueella — vain vähimmäisydin eli tietokanta pidetään valmiina. Katastrofin sattuessa ylennä Read Replica itsenäiseksi tietokannaksi ja käynnistä sovelluspalvelimet ennalta luoduista AMI-kuvista CloudFormationin avulla. RTO on tunteja eikä minuutteja, koska palvelimet on käynnistettävä.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Skenaario 7: SQS:n dead-letter-jonot epäonnistuneille viesteille

Skenaario: SQS-jonon viestien käsittely epäonnistuu toistuvasti kuluttaja-Lambdan virheen vuoksi. Viestit ilmestyvät jatkuvasti uudelleen ja tukkivat jonon. Ratkaisu: Määritä pääjonolle Dead-Letter Queue (DLQ). Kun viestin käsittely epäonnistuu määritettävän määrän kertoja (maxReceiveCount), SQS siirtää viestin automaattisesti DLQ:hun sen sijaan, että toimittaisi sitä uudelleen loputtomasti. Tämä vapauttaa pääjonon toimiville viesteille. Määritä DLQ:n ApproximateNumberOfMessagesVisible-metriikalle CloudWatch-hälytys, joka ilmoittaa tekniselle tiimille, kun viestejä kertyy DLQ:hun.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Skenaario 8: Aurora Global Database

Skenaario: Yritys toimii Yhdysvalloissa ja Euroopassa. Euroopassa olevat käyttäjät kokevat suurta tietokannan lukuviivettä, koska RDS sijaitsee alueella us-east-1. Ratkaisu: Käytä Amazon Aurora Global Database -ratkaisua. Ensisijainen klusteri sijaitsee alueella us-east-1, ja alueelle eu-west-1 lisätään toissijainen vain luku -klusteri. Aurora replikoituu toissijaiselle alueelle tyypillisesti alle sekunnin viiveellä tallennustason replikoinnin avulla. Eurooppalaiset käyttäjät lukevat tiedot eu-west-1:n toissijaisesta klusterista. Alueellisen katastrofin sattuessa toissijainen klusteri voidaan ylentää ensisijaiseksi alle minuutissa (paras RTO kaikista AWS:n usean alueen tietokantavaihtoehdoista).

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Skenaario 9: ECS-palvelu ALB:n ja Auto Scalingin kanssa

Skenaario: ECS Fargatessa toimivan kontitetun API-palvelun on skaalattava suorittimen käyttöasteen perusteella ja kestettävä AZ-häiriöt. Ratkaisu: Rekisteröi ECS-palvelu Application Load Balancer -kohderyhmään, jotta liikenne jakautuu käynnissä oleville tehtäville. Sijoita tehtävät useisiin AZ:ihin määrittämällä palvelun asetuksissa useita aliverkkoja. Määritä ECS Service Auto Scaling käyttämään ECS-palvelun suorittimen käyttöasteeseen perustuvaa tavoiteseurantakäytäntöä, jotta tehtävien määrää skaalataan automaattisesti ylös ja alas. Jos AZ vikaantuu, ECS käynnistää vikaantuneet tehtävät uudelleen toimivissa AZ:issa.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Skenaario 10: Kuntotarkistukseen perustuva failover Route 53:n avulla

Skenaario: Yrityksellä on kaksi eri AZ:issa sijaitsevaa EC2-instanssia, jotka palvelevat samaa verkkotunnusta. Yritys haluaa Route 53:n lopettavan liikenteen lähettämisen automaattisesti toimimattomalle instanssille. Ratkaisu: Käytä Route 53 Weighted Routing -reititystä yhtä suurilla painoilla (50/50) ja yhdistä kumpaankin tietueeseen endpoint-kuntotarkistus. Kun Route 53 havaitsee endpointin toimimattomaksi, se poistaa tietueen DNS-vastauksista ja ohjaa 100 prosenttia liikenteestä toimivalle endpointille. Kun instanssi palautuu ja kuntotarkistukset onnistuvat jälleen, Route 53 tasaa liikenteen automaattisesti uudelleen — manuaalisia DNS-muutoksia ei tarvita.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Skenaario 11: DynamoDB Global Tables usean alueen HA:ta varten

Skenaario: Mobiilipelisovelluksen pelaajatietojen on oltava luettavissa ja kirjoitettavissa pienellä viiveellä sekä alueella us-east-1 että alueella ap-southeast-1. Yhdellä alueella sijaitseva DynamoDB-taulu aiheuttaa suuren viiveen aasialaisille käyttäjille. Ratkaisu: Ota DynamoDB Global Tables käyttöön. Global Tables replikoivat tiedot automaattisesti määritettyjen alueiden välillä multi-master-replikoinnin avulla — mikä tahansa alue voi vastaanottaa kirjoituksia. Aasialaiset käyttäjät kirjoittavat tietoja ap-southeast-1:n replikaaan ja lukevat niitä siitä paikallisella viiveellä (noin 5 ms). Global Tables ratkaisee ristiriidat aikaleimoihin perustuvalla last-writer-wins-strategialla. Täydellisen alueellisen vikaantumisen RTO on lähes nolla — liikenne ohjataan yksinkertaisesti jäljellä olevalle alueelle.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Pikatarkistus

Testaa, kuinka hyvin ymmärrät tämän oppitunnin AWS Solutions Architect (SAA-C03) -käsitteet.

Vastaa interaktiivisessa oppitunnissa

Oppitunnin yhteenveto

Tässä oppitunnissa käsittelit seuraavia skenaarioita: Multi-AZ ASG ja RDS alueensisäistä HA:ta varten, Route 53:n failover-reititys alueiden väliseen DR:ään, SQS DLQ epäonnistuneiden viestien eristämiseen ilman jonojen tukkimista sekä Aurora Global Database alueiden väliseen lukuskaalaukseen ja alle minuutin RTO:n failoveriin. Seuraavaksi käsittelemme suorituskykyisiä ja kustannustehokkaiksi optimoituja arkkitehtuuriskenaarioita.

Aloita maksutta

Opi Cloud & IT Cert Prep tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit: 150
Oppitunnit: 600

Aloita opiskelu maksutta Näytä koko kurssi

Usein kysytyt kysymykset

Onko oppitunti ”Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot” ilmainen?

Kyllä – oppitunnin ”Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Cloud & IT Cert Prep-kurssin, päivitä CoddyKit PROhon. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot”?

Ratkaise monen AZ:n tietokannan vikasietoisen vaihdon, purskeliikenteen aikaisen automaattisen skaalauksen ja Route 53:n kuntotarkistukseen perustuvan vikasiedon skenaarioita vahvistaaksesi luotettav… Harjoittelet Cloud & IT Cert Prep-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Cloud & IT Cert Prep-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Cloud & IT Cert Prep-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.

Kuinka kauan ”Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Cloud & IT Cert Prep-oppitunnilla?

Kyllä. Jokainen Cloud & IT Cert Prep-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

Suojattujen arkkitehtuurien skenaariot
Vikasietoisten ja erittäin käytettävien arkkitehtuurien skenaariot
Tehokkaiden ja kustannusoptimoitujen arkkitehtuurien skenaariot
Kaikki aihealueet kattava minikoe

← Takaisin: Cloud & IT Cert Prep