0Pricing
AWS Solutions Architect · Ders

Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları

Güvenilirlik kavramlarını pekiştirmek için çoklu-AZ veritabanı yük devri, ani trafik altında otomatik ölçeklendirme ve Route 53 durum denetimli yük devri senaryolarını ele alın.

Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları, CoddyKit'te ücretsiz bir AWS Solutions Architect dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, AWS Solutions Architect öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. AWS Solutions Architect kursu toplamda 4 dersten oluşur.

Senaryo 1: Multi-AZ Web Uygulaması

Senaryo: Bir şirket iki katmanlı bir web uygulaması (ALB → EC2 → RDS) çalıştırıyor ve AWS Region içindeki tek hata noktalarını ortadan kaldırmak istiyor. Çözüm: EC2 bulut sunucularını bir ALB'nin arkasında, en az 2 Availability Zone'u kapsayan bir Auto Scaling Group içinde dağıtın (ALB zaten yerleşik olarak Multi-AZ'dir). Eş zamanlı yedek çoğaltma için RDS Multi-AZ'yi etkinleştirin. Sağlıksız bulut sunucularından gelen trafiği otomatik olarak başka yöne yönlendirmek için ALB üzerinde sağlık kontrolleri yapılandırın. Bu mimariyle herhangi bir AZ'nin kaybı, her katmanda otomatik yük devretmeyi tetikler.

# 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

Senaryo 2: Yük Altında RDS Okuma Ölçeklendirmesi

Senaryo: Bir e-ticaret uygulamasının RDS bulut sunucusu, iş zekâsı ekibinin okuma ağırlıklı analiz sorguları nedeniyle yoğun saatlerde CPU sınırlarına ulaşıyor. Çözüm: RDS Read Replica'ları oluşturun ve BI sorgularını replika uç noktasına yönlendirin. Read Replica'lar asenkron çoğaltma kullanır; analiz için küçük bir gecikme kabul edilebilir. Böylece okuma trafiği, yazma işlemleri ve uygulama okumaları için ayrılmış birincil RDS bulut sunucusundan uzaklaştırılır. Son derece okuma ağırlıklı iş yükleri için sık erişilen veriler adına RDS'nin önüne bir ElastiCache katmanı ekleyin.

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

Senaryo 3: CPU Artışında Otomatik Ölçeklendirme

Senaryo: Durum bilgisi tutmayan bir API, ALB'nin arkasında EC2 üzerinde çalışıyor. CPU kullanımı mesai saatlerinde %90'a çıkıyor ve geceleri neredeyse sıfıra düşüyor. Şirket, sunucu filosunun otomatik olarak ölçeklenmesini istiyor. Çözüm: Ortalama CPU kullanımını %60'ı hedefleyecek bir Target Tracking ölçeklendirme ilkesi ile bir Auto Scaling Group yapılandırın. ASG, CPU %60'ı aştığında otomatik olarak bulut sunucuları ekler, hedefin altına düştüğünde ise bulut sunucularını kaldırır. Sabah trafiğindeki ani artışta gecikmeyi önlemek için mesai saatleri başlamadan önce minimum kapasiteyi önceden ısıtacak bir zamanlanmış ölçeklendirme eylemi ekleyin.

# 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

Senaryo 4: Route 53 ile DR Sitesine Yük Devretme

Senaryo: Bir şirket birincil web uygulamasını us-east-1'de çalıştırıyor ve birincil uygulama sağlıksız hâle gelirse us-west-2'deki statik S3 barındırmalı bakım sayfasına yük devretmek istiyor. Çözüm: Birincil ALB uç noktasını izleyen bir Route 53 sağlık kontrolü oluşturun. yük devretme yönlendirme ilkesi ile iki Route 53 kaydı oluşturun: Sağlık kontrolüyle ilişkilendirilmiş ve ALB'yi gösteren Primary kaydı ile S3 statik sitesini gösteren Secondary kaydı. Sağlık kontrolü başarısız olursa Route 53, ikincil kaydın DNS yanıtını otomatik olarak sunar.

# 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

Senaryo 5: Dayanıklılık için SQS ile Ayrıştırma

Senaryo: Sipariş işleme arka ucu bir veritabanına yazıyor, ancak veritabanı bakım zamanlarında bazen kullanılamaz hâle geliyor ve siparişlerin kaybolmasına neden oluyor. Çözüm: Siparişleri kabul eden ön uç ile siparişleri işleyen arka uç arasına bir SQS kuyruğu yerleştirin. Siparişler hemen kuyruğa eklenir ve müşteriye anında onay verilir. Arka plan çalışanları kuyruktan siparişleri alır ve veritabanı kullanılabilir olduğunda işler. Bakım sırasında siparişler silinmek yerine kuyrukta birikir; böylece asenkron ayrıştırma yoluyla dayanıklılık sağlanır.

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

Senaryo 6: Pilot Light DR

Senaryo: Bir şirketin, orta düzey bir bütçeyle RPO'su 1 saat ve RTO'su 4 saat olan bir felaket kurtarma çözümüne ihtiyacı var. Çözüm: Pilot Light DR stratejisi uygulayın. Temel veritabanını RDS Cross-Region Read Replica kullanarak DR Region'a çoğaltılmış durumda tutun. Uygulama sunucuları normal çalışma sırasında DR Region'da çalışmaz; yalnızca minimum “temel” bileşen, yani veritabanı, hazır durumda tutulur. Bir felaket durumunda Read Replica'yı bağımsız bir veritabanına yükseltin ve CloudFormation kullanarak önceden oluşturulmuş AMIs üzerinden uygulama sunucularını başlatın. Sunucuların başlatılması gerektiği için RTO dakikalar değil, saatler düzeyindedir.

# 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

Senaryo 7: Başarısız Mesajlar için SQS Dead-Letter Queue

Senaryo: Bir SQS kuyruğundaki mesajların işlenmesi, tüketici Lambda'daki bir hata nedeniyle tekrar tekrar başarısız oluyor. Mesajlar yeniden görünmeye devam ediyor ve kuyruğu engelliyor. Çözüm: Ana kuyruk üzerinde bir Dead-Letter Queue (DLQ) yapılandırın. Bir mesaj, yapılandırılabilir sayıda kez (maxReceiveCount) işlenemediğinde SQS, mesajı sonsuza kadar yeniden sunmak yerine otomatik olarak DLQ'ya taşır. Bu işlem, ana kuyruğun sağlıklı mesajlar için kullanılmasını sağlar. DLQ'da mesajlar biriktiğinde mühendislik ekibini uyarmak için DLQ'nun ApproximateNumberOfMessagesVisible metriği üzerinde bir CloudWatch alarmı ayarlayın.

# 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

Senaryo 8: Aurora Global Database

Senaryo: Bir şirket US ve Avrupa'da faaliyet gösteriyor. RDS us-east-1'de bulunduğu için Avrupa'daki kullanıcılar yüksek veritabanı okuma gecikmesi yaşıyor. Çözüm: Amazon Aurora Global Database kullanın. Birincil küme us-east-1'de bulunur; eu-west-1'e salt okunur ikincil bir küme eklenir. Aurora, depolama katmanı çoğaltmasını kullanarak verileri genellikle 1 saniyenin altındaki gecikmeyle ikincil Region'a çoğaltır. Avrupa'daki kullanıcılar eu-west-1'deki ikincil kümeden okuma yapar. Bölgesel bir felaket durumunda ikincil küme 1 dakikadan kısa sürede birincil kümeye yükseltilebilir; bu, AWS'nin çok bölgeli DB seçenekleri arasındaki en iyi RTO'dur.

# 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

Senaryo 9: ALB ve Auto Scaling ile ECS Service

Senaryo: ECS Fargate üzerinde çalışan kapsayıcılı bir API hizmetinin CPU kullanımına göre ölçeklenmesi ve AZ arızalarına dayanması gerekiyor. Çözüm: Trafiğin çalışan görevler arasında dağıtılması için ECS hizmetini bir Application Load Balancer hedef grubuna kaydedin. Hizmet yapılandırmasında birden fazla alt ağ belirterek görevleri birden fazla AZ'ye yerleştirin. Görev sayısını otomatik olarak artırıp azaltmak için ECS hizmeti CPU kullanımına dayalı bir hedef izleme ilkesiyle ECS Service Auto Scaling yapılandırın. Bir AZ arızalanırsa ECS, başarısız görevleri sağlıklı AZ'lerde yeniden başlatır.

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

Senaryo 10: Route 53 ile Sağlık Kontrolü ve Yük Devretme

Senaryo: Bir şirket, farklı AZ'lerde aynı etki alanını sunan iki EC2 bulut sunucusu çalıştırıyor. Route 53'ün trafiği sağlıksız bir bulut sunucusuna göndermeyi otomatik olarak durdurmasını istiyorlar. Çözüm: Eşit ağırlıklara (%50/%50) sahip Route 53 Weighted Routing kullanın ve her kayıtla bir uç nokta sağlık kontrolünü ilişkilendirin. Route 53 sağlıksız bir uç nokta algıladığında bu kaydı DNS yanıtlarından çıkarır ve trafiğin %100'ünü sağlıklı uç noktaya gönderir. Bulut sunucusu kurtarılıp sağlık kontrolleri yeniden başarılı olduğunda Route 53 trafiği otomatik olarak yeniden dengeler; manuel DNS değişikliği gerekmez.

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

Senaryo 11: Multi-Region HA için DynamoDB Global Tables

Senaryo: Bir mobil oyun uygulamasının oyuncu verilerinin hem us-east-1 hem de ap-southeast-1'den düşük gecikmeyle okunup yazılabilmesi gerekiyor. Tek Region'lı bir DynamoDB tablosu Asya'daki kullanıcılar için yüksek gecikmeye neden oluyor. Çözüm: DynamoDB Global Tables'ı etkinleştirin. Global Tables, verileri çoklu ana sunucu çoğaltması kullanarak belirtilen Region'lar arasında otomatik olarak çoğaltır; herhangi bir Region yazma işlemlerini kabul edebilir. Asya'daki kullanıcılar yerel gecikmeyle (yaklaşık 5 ms) ap-southeast-1 replikasına yazıp buradan okur. Global Tables, zaman damgalarına dayalı “son yazan kazanır” stratejisiyle çakışma çözümünü yönetir. Tam bir bölgesel arıza için RTO neredeyse sıfırdır; trafik basitçe çalışmaya devam eden Region'a yönlendirilir.

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

Hızlı Kontrol

Bu dersteki AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Ders Özeti

Bu derste şunları kapsayan senaryolar üzerinde çalıştınız: Region içi HA için Multi-AZ ASG ve RDS, Region'lar arası DR için Route 53 yük devretme yönlendirmesi, kuyrukları engellemeden başarısız mesajları ayırmak için SQS DLQ ve Region'lar arası okuma ölçeklendirmesi ve bir dakikadan kısa RTO ile yük devretme için Aurora Global Database. Sırada yüksek performanslı ve maliyet açısından optimize edilmiş mimari senaryolar var.

Sıkça Sorulan Sorular

“Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları” dersi ücretsiz mi?

Evet — “Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve AWS Solutions Architect kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. AWS Solutions Architect kursu toplamda 4 dersten oluşur.

“Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları” dersinde ne öğreneceğim?

Güvenilirlik kavramlarını pekiştirmek için çoklu-AZ veritabanı yük devri, ani trafik altında otomatik ölçeklendirme ve Route 53 durum denetimli yük devri senaryolarını ele alın. AWS Solutions Architect ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

AWS Solutions Architect öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te AWS Solutions Architect, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.

“Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu AWS Solutions Architect dersinde kod yazıp çalıştırabilir miyim?

Evet. Her AWS Solutions Architect dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Güvenli Mimari Senaryoları
  2. Dayanıklı ve Yüksek Kullanılabilirlikli Mimari Senaryoları
  3. Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar
  4. Karma Alanlardan Oluşan Tam Uzunlukta Mini Sınav
← AWS Solutions Architect Sayfasına Dön