Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi
Tangani senario peralihan pangkalan data Multi-AZ, penskalaan automatik ketika trafik memuncak dan peralihan pemeriksaan kesihatan Route 53 untuk memantapkan konsep kebolehpercayaan.
Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi ialah pelajaran Cloud & IT Cert Prep percuma di CoddyKit. Ini ialah pelajaran 2 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Cloud & IT Cert Prep, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Cloud & IT Cert Prep merangkumi sejumlah 4 pelajaran.
Senario 1: Aplikasi Web Multi-AZ
Senario: Sebuah syarikat menjalankan aplikasi web dua peringkat (ALB → EC2 → RDS) dan mahu menghapuskan sebarang titik kegagalan tunggal dalam AWS Region. Penyelesaian: Letakkan Instance EC2 dalam Kumpulan Penskalaan Automatik yang merentasi sekurang-kurangnya 2 Availability Zones di belakang ALB (yang sememangnya bersifat multi-AZ). Dayakan RDS Multi-AZ untuk replikasi standby segerak. Konfigurasikan semakan kesihatan pada ALB untuk menghalakan trafik secara automatik daripada Instance yang tidak sihat. Dengan seni bina ini, kehilangan mana-mana satu AZ akan menyebabkan failover automatik pada setiap peringkat.
# 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/abcSenario 2: Penskalaan Bacaan RDS Semasa Beban Tinggi
Senario: Instance RDS sebuah aplikasi e-dagang mencapai had CPU pada waktu puncak kerana pertanyaan analitis yang banyak membaca daripada pasukan risikan perniagaan. Penyelesaian: Cipta RDS Read Replica dan halakan pertanyaan BI ke endpoint replika tersebut. Read Replica menggunakan replikasi tak segerak — sedikit kelewatan boleh diterima untuk analitis. Ini memindahkan trafik bacaan daripada Instance RDS Primary, yang dikhaskan untuk operasi Write dan bacaan aplikasi. Untuk beban kerja yang sangat banyak membaca, tambahkan lapisan ElastiCache di hadapan RDS bagi data yang kerap diakses.
# 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)Senario 3: Penskalaan Automatik Semasa Lonjakan CPU
Senario: API tanpa keadaan berjalan pada EC2 di belakang ALB. Penggunaan CPU melonjak kepada 90% pada waktu bekerja dan turun hampir sifar pada waktu malam. Syarikat tersebut mahu fleet diskalakan secara automatik. Penyelesaian: Konfigurasikan Kumpulan Penskalaan Automatik dengan dasar penskalaan Penjejakan Target yang menyasarkan purata penggunaan CPU sebanyak 60%. ASG akan menambah Instance secara automatik apabila CPU melebihi 60% dan mengalih keluar Instance apabila penggunaan turun di bawah sasaran. Tambahkan tindakan penskalaan berjadual untuk menyediakan kapasiti minimum lebih awal sebelum waktu bekerja bermula, sekali gus mengelakkan kelewatan ketika lonjakan trafik pagi.
# 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 5Senario 4: Failover Route 53 ke Tapak DR
Senario: Sebuah syarikat menjalankan aplikasi web Primary di us-east-1 dan mahu beralih secara automatik ke halaman penyelenggaraan statik yang dihoskan pada S3 di us-west-2 jika aplikasi Primary menjadi tidak sihat. Penyelesaian: Cipta semakan kesihatan Route 53 yang memantau endpoint ALB Primary. Cipta dua rekod Route 53 dengan dasar penghalaan failover: rekod Primary yang menunjuk kepada ALB (dikaitkan dengan semakan kesihatan), dan rekod Secondary yang menunjuk kepada tapak statik S3. Jika semakan kesihatan gagal, Route 53 akan menyampaikan respons DNS rekod Secondary secara automatik.
# 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 failsSenario 5: Penyahgandingan dengan SQS untuk Ketahanan
Senario: Backend pemprosesan pesanan menulis ke Database, tetapi Database kadangkala tidak tersedia semasa tempoh penyelenggaraan, menyebabkan pesanan hilang. Penyelesaian: Letakkan baris gilir SQS antara Frontend (yang menerima pesanan) dengan Backend (yang memprosesnya). Pesanan dimasukkan ke dalam baris gilir serta-merta supaya pelanggan menerima pengesahan serta-merta. Pekerja latar belakang mengambil pesanan daripada baris gilir dan memprosesnya apabila Database tersedia. Semasa penyelenggaraan, pesanan beratur dan bukannya dibuang — sekali gus memberikan ketahanan melalui penyahgandingan tak segerak.
# 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)Senario 6: Pilot Light DR
Senario: Sebuah syarikat memerlukan penyelesaian pemulihan bencana dengan RPO selama 1 jam dan RTO selama 4 jam, menggunakan belanjawan sederhana. Penyelesaian: Laksanakan strategi DR Pilot Light. Pastikan Database teras direplikasi ke DR Region menggunakan RDS Cross-Region Read Replica. Pelayan aplikasi tidak berjalan di DR Region semasa operasi biasa — hanya 'teras' minimum (Database) dikekalkan dalam keadaan sedia. Semasa bencana, naik taraf Read Replica kepada kendiri dan lancarkan pelayan aplikasi daripada AMIs yang telah dicipta terlebih dahulu menggunakan CloudFormation. RTO mengambil masa beberapa jam, bukannya beberapa minit, kerana pelayan perlu dilancarkan.
# 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-2Senario 7: SQS Dead-Letter Queue untuk Mesej yang Gagal
Senario: Mesej dalam baris gilir SQS gagal diproses berulang kali kerana pepijat dalam Lambda pengguna. Mesej tersebut terus muncul semula dan menyekat baris gilir. Penyelesaian: Konfigurasikan Dead-Letter Queue (DLQ) pada baris gilir utama. Selepas mesej gagal diproses beberapa kali yang boleh dikonfigurasikan (maxReceiveCount), SQS akan memindahkannya ke DLQ secara automatik dan bukannya menghantarnya semula tanpa henti. Ini membebaskan baris gilir utama untuk mesej yang sihat. Tetapkan penggera CloudWatch pada metrik ApproximateNumberOfMessagesVisible DLQ untuk memberi amaran kepada pasukan kejuruteraan apabila mesej terkumpul dalam DLQ.
# 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 SumSenario 8: Aurora Global Database
Senario: Sebuah syarikat beroperasi di US dan Eropah. Pengguna di Eropah mengalami kelewatan bacaan Database yang tinggi kerana RDS berada di us-east-1. Penyelesaian: Gunakan Amazon Aurora Global Database. Kluster Primary berada di us-east-1; kluster bacaan sahaja Secondary ditambahkan di eu-west-1. Aurora mereplikasi data ke Region Secondary dengan kelewatan lazim di bawah 1 saat menggunakan replikasi pada peringkat storan. Pengguna Eropah membaca daripada kluster Secondary di eu-west-1. Jika berlaku bencana serantau, Secondary boleh dinaik taraf menjadi Primary dalam masa kurang daripada 1 minit (RTO terbaik antara mana-mana pilihan DB berbilang Region AWS).
# 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-1Senario 9: Perkhidmatan ECS dengan ALB dan Penskalaan Automatik
Senario: Perkhidmatan API berbekas yang berjalan pada ECS Fargate perlu diskalakan berdasarkan penggunaan CPU dan terus beroperasi apabila berlaku kegagalan AZ. Penyelesaian: Daftarkan perkhidmatan ECS dengan kumpulan target Application Load Balancer supaya trafik diagihkan merentasi tugasan yang sedang berjalan. Letakkan tugasan merentasi beberapa AZ dengan menetapkan beberapa subnet dalam konfigurasi perkhidmatan. Konfigurasikan Penskalaan Automatik Perkhidmatan ECS dengan dasar Penjejakan Target pada penggunaan CPU perkhidmatan ECS untuk menambah atau mengurangkan bilangan tugasan secara automatik. Jika AZ gagal, ECS akan memulakan semula tugasan yang gagal dalam AZ yang sihat.
# 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
}]'Senario 10: Failover Semakan Kesihatan dengan Route 53
Senario: Sebuah syarikat menjalankan dua Instance EC2 dalam AZ yang berbeza untuk menyampaikan domain yang sama. Mereka mahu Route 53 berhenti menghantar trafik ke Instance yang tidak sihat secara automatik. Penyelesaian: Gunakan Weighted Routing Route 53 dengan Weight yang sama (50/50) dan kaitkan semakan kesihatan endpoint dengan setiap rekod. Apabila Route 53 mengesan endpoint yang tidak sihat, ia mengalih keluar rekod tersebut daripada respons DNS dan menghantar 100% trafik ke endpoint yang sihat. Apabila Instance pulih dan semakan kesihatan lulus semula, Route 53 akan mengimbangi semula trafik secara automatik — tiada perubahan DNS manual diperlukan.
# 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"}]
}
}]
}'Senario 11: DynamoDB Global Tables untuk HA Berbilang Region
Senario: Sebuah aplikasi permainan mudah alih memerlukan data pemainnya boleh dibaca dan ditulis dengan kelewatan rendah dari us-east-1 dan ap-southeast-1. Satu Table DynamoDB dalam satu Region menyebabkan kelewatan tinggi bagi pengguna Asia. Penyelesaian: Dayakan DynamoDB Global Tables. Global Tables mereplikasi data secara automatik merentasi Region yang ditetapkan menggunakan replikasi multi-master — mana-mana Region boleh menerima operasi Write. Pengguna Asia menulis dan membaca daripada replika ap-southeast-1 dengan kelewatan setempat (~5ms). Global Tables mengendalikan penyelesaian konflik menggunakan strategi 'penulis terakhir menang' berdasarkan cap masa. RTO bagi kegagalan serantau penuh hampir sifar — trafik hanya dihalakan ke Region yang masih beroperasi.
# 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"}}]'Pemeriksaan Ringkas
Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) daripada pelajaran ini.
Rumusan Pelajaran
Dalam pelajaran ini, Anda telah meneliti senario yang merangkumi: ASG Multi-AZ dan RDS untuk HA dalam Region, penghalaan failover Route 53 untuk DR merentas Region, SQS DLQ untuk mengasingkan mesej yang gagal tanpa menyekat baris gilir, dan Aurora Global Database untuk penskalaan bacaan merentas Region serta failover RTO bawah seminit. Seterusnya, kita akan membincangkan senario seni bina berprestasi tinggi dan dioptimumkan kos.
Pelajari Cloud & IT Cert Prep dengan tutor kecerdasan buatan — percuma
Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.
- Kursus
- 150
- Pelajaran
- 600
Soalan Lazim
Adakah pelajaran “Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi” percuma?
Ya — teks penuh “Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus Cloud & IT Cert Prep, tingkat taraf kepada CoddyKit PRO. Kursus Cloud & IT Cert Prep merangkumi sejumlah 4 pelajaran.
Apakah yang akan saya pelajari dalam “Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi”?
Tangani senario peralihan pangkalan data Multi-AZ, penskalaan automatik ketika trafik memuncak dan peralihan pemeriksaan kesihatan Route 53 untuk memantapkan konsep kebolehpercayaan. Anda berlatih Cloud & IT Cert Prep menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.
Adakah saya memerlukan pengalaman untuk memulakan Cloud & IT Cert Prep?
Tiada pengalaman terdahulu diperlukan. Pembelajaran Cloud & IT Cert Prep di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 2 daripada 4.
Berapa lamakah pelajaran “Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi” diambil?
Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.
Bolehkah saya menulis dan menjalankan kod dalam pelajaran Cloud & IT Cert Prep ini?
Ya. Setiap pelajaran Cloud & IT Cert Prep menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.
Semua pelajaran dalam kursus ini
- Senario Seni Bina Selamat
- Senario Seni Bina Berdaya Tahan dan Berketersediaan Tinggi
- Senario Prestasi Tinggi dan Dioptimumkan Kos
- Peperiksaan Mini Penuh Domain Campuran