Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı
Arızaları algılamak ve trafiği otomatik olarak yeniden yönlendirmek için ELB durum denetimlerini, Route 53 uç nokta denetimlerini ve uygulama düzeyinde devre kesicileri kullanın.
Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı, CoddyKit'te ücretsiz bir AWS Solutions Architect dersidir. Bu, 4 dersinin 4. 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.
Otomatik Hata Algılama Neden Önemlidir?
Dağıtık sistemlerde bileşenler sürekli olarak başarısız olur; örnekler çöker, ağ bölümleri oluşur ve alt hizmetler aşırı yüklenir. Otomatik hata algılama olmadan trafik, başarısız bileşenlere akmaya devam eder ve zincirleme hatalara yol açar. AWS, birden çok Health Check katmanı sunar: ELB Health Check'leri sağlıksız örnekleri, Route 53 Health Check'leri sağlıksız Endpoint'leri algılar ve Auto Scaling başarısız örnekleri değiştirir. Devre kesiciler ve yeniden denemeler gibi uygulama düzeyindeki modeller, dayanıklılık yaklaşımını tamamlar.
ELB Health Kontrolleri
Elastic Load Balancer sağlık kontrolleri, kayıtlı hedeflere düzenli aralıklarla istek göndererek bunların sağlıklı olup olmadığını belirler. sağlık kontrolü yolunu (ör. /health), protokolü, portu, aralığı (varsayılan 30 Seconds) ve sağlıklı/sağlıksız eşiğini (art arda gerçekleşmesi gereken başarı veya başarısızlık sayısı) yapılandırırsınız. Bir hedef sağlık kontrollerinde başarısız olduğunda ELB, trafiği bu hedefe yönlendirmeyi durdurur. Hedef sürekli olarak yeniden değerlendirilir ve sağlıklı eşiğini geçtiğinde yeniden eklenir.
# Configure ALB target group health check
aws elbv2 modify-target-group \
--target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
--health-check-protocol HTTPS \
--health-check-port 443 \
--health-check-path /health \
--health-check-interval-seconds 15 \
--healthy-threshold-count 2 \
--unhealthy-threshold-count 3 \
--matcher HttpCode=200Route 53 Health Kontrolleri
Route 53 sağlık kontrolleri, uç noktaları küresel olarak birden fazla konumdan izler ve DNS failover yönlendirmesiyle birlikte çalışır. Üç tür vardır: Uç nokta kontrolleri, uygulama URL'nizi doğrudan yoklar. Hesaplanmış kontroller, birden fazla alt sağlık kontrolünü AND/OR mantığıyla birleştirir (karmaşık izleme senaryoları için kullanışlıdır). CloudWatch alarm kontrolleri, sağlık durumunun belirlenmesini CloudWatch'a devreder; bu, herkese açık bir sağlık uç noktası sunamadığınızda veya metrik tabanlı sağlık kararlarına ihtiyaç duyduğunuzda kullanışlıdır.
# Create endpoint health check
aws route53 create-health-check \
--caller-reference ref-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true
}'Otomatik Ölçeklendirme Sağlık Kontrolleri
Otomatik Ölçeklendirme Grupları iki tür sağlık kontrolü kullanabilir: EC2 sağlık kontrolleri, hiper yönetici düzeyindeki instance arızalarını (instance durum kontrolü başarısızlığını) algılar. ELB sağlık kontrolleri uygulamanın durumunu daha iyi yansıtır; bir instance çalışıyor olabilir ancak hatalar sunuyor olabilir ve ELB sağlık kontrolleri bunu yakalar. ASG'yi ELB sağlık kontrollerini kullanacak şekilde yapılandırarak yalnızca temel EC2 arızalarının değil, uygulama düzeyindeki arızaların da instance değiştirme işlemini tetiklemesini sağlayabilirsiniz.
# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--health-check-type ELB \
--health-check-grace-period 300
# Grace period: time after launch before health checks start
# Prevents premature termination during startupCircuit Breaker Deseni
Circuit breaker, alt düzey bir hizmete yapılan çağrıları izleyerek ve arızalar bir eşiği aştığında çağrıları geçici olarak durdurarak zincirleme arızaları önleyen uygulama düzeyinde bir desendir. Devrenin üç durumu vardır: Closed (normal çalışma), Open (arızalar eşiği aşmıştır, çağrılar anında engellenir) ve Half-Open (bir timeout sonrasında, hizmetin düzelip düzelmediğini kontrol etmek için az sayıda test çağrısına izin verilir). AWS App Mesh ve Resilience4j gibi uygulama SDK'ları bu deseni uygular.
# Circuit breaker states
# CLOSED: All calls pass through
# failureCount < threshold -> stay CLOSED
# failureCount >= threshold -> open circuit
# OPEN: All calls fail immediately
# After timeout -> enter HALF-OPEN
# HALF-OPEN: Allow limited test calls
# Success -> return to CLOSED
# Failure -> return to OPEN
# Example threshold: 5 failures in 10 seconds -> OPENCircuit Breaking için AWS App Mesh
AWS App Mesh, kod değişikliği gerektirmeden circuit breaking, yeniden deneme ve timeout ilkelerini altyapı düzeyinde uygulayan bir hizmet ağıdır. circuit breaker ilkelerini sanal düğüm veya sanal yönlendirici yapılandırmasında tanımlarsınız. Bir üst hizmet sağlıksız duruma geldiğinde App Mesh'in Envoy proxy'si devreyi otomatik olarak açar ve timeout'ları beklemek yerine hataları hemen döndürür. Bu özellik, ECS veya EKS üzerinde çalışan mikro hizmet mimarilerinde özellikle değerlidir.
# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
'spec': {
'listeners': [{
'outlierDetection': {
'consecutiveErrors': 5,
'interval': {'unit': 'ms', 'value': 10000},
'baseEjectionDuration': {'unit': 's', 'value': 30},
'maxEjectionPercent': 50
}
}]
}
}Yeniden Deneme Mantığı ve Üstel Geri Çekilme
Yeniden deneme mantığı, başarısız işlemleri otomatik olarak tekrarlar; ancak naif yeniden deneme mantığı (sıkı bir döngüde hemen yeniden deneme), aşırı yük durumlarını kötüleştirebilir. Üstel geri çekilme, yeniden denemeler arasındaki bekleme süresini üstel olarak artırır: 1s, 2s, 4s, 8s... Bu, zorlanan bir hizmet üzerindeki yükü azaltır ve hizmete toparlanması için zaman tanır. Jitter (yeniden deneme aralıklarını rastgeleleştirme), kısa bir kesintiden sonra tüm istemcilerin aynı anda yeniden denediği gürültülü kalabalık sorununu önler. AWS SDK, jitter içeren üstel geri çekilmeyi otomatik olarak uygular.
# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds
# Python boto3 custom retry configuration
import boto3
from botocore.config import Config
config = Config(
retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)Güvenli Yeniden Denemeler için İdempotensi
Yeniden denemeler yalnızca işlemler idempotent olduğunda güvenlidir; yani aynı işlemin birden çok kez gerçekleştirilmesi aynı sonucu üretir. Örneğin, aynı anahtarla bir S3 nesnesi oluşturmak idempotent'tir (sonuç aynıdır). Ancak bir siparişi iki kez vermek iki sipariş oluşturur; bu işlem idempotent değildir. istemci tarafından sağlanan idempotensi anahtarlarını kullanarak API'leri idempotent olacak şekilde tasarlayın: sunucu ilk isteğin sonucunu saklar ve aynı anahtarla yapılan sonraki isteklerde aynı sonucu döndürür. DynamoDB, SQS ve API Gateway idempotensi anahtarı desenlerini destekler.
# SQS message deduplication ID for FIFO queues
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
--message-body '{"orderId":"ord-123","items":[...]}' \
--message-group-id 'customer-456' \
--message-deduplication-id 'ord-123-attempt-1'
# SQS deduplicates messages with same ID for 5 minutesTimeout Yapılandırması
Açıkça belirtilmiş timeout'lar olmadığında yavaş bir alt hizmet, iş parçacıklarının süresiz olarak engellenmesine, bağlantı havuzunun tükenmesine ve zincirleme arızalara neden olur. Her katmanda timeout ayarlayın: bağlantı timeout'u (TCP bağlantısını kurma süresi), okuma timeout'u (yanıt alma süresi) ve genel istek timeout'u. AWS'de ELB boşta kalma timeout'unu (varsayılan 60s), Lambda yürütme timeout'unu (en fazla 15 Minutes) ve API Gateway entegrasyon timeout'unu (en fazla 29s) yapılandırın. Timeout'lar, yeniden deneme veya circuit breaker mantığınızı tetikler.
# Lambda: set execution timeout
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30
# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn <ALB-ARN> \
--attributes Key=idle_timeout.timeout_seconds,Value=60
# API Gateway: integration timeout max 29000msBaşarısız İşleme için Dead Letter Kuyrukları
Mesaj işleme tekrar tekrar başarısız olduğunda, bir Dead Letter Queue (DLQ), maksimum alma denemesi sayısından sonra işlenemeyen mesajları yakalar. Hatalı mesajların kuyruğunuzu süresiz olarak engellemesini önlemek için SQS kuyruklarında ve Lambda olay kaynağı eşlemelerinde DLQ'ları yapılandırın. DLQ'daki mesajlar incelenebilir, hata düzeltildikten sonra yeniden oynatılabilir veya arşivlenebilir. DLQ'lar, dayanıklı olay güdümlü mimarilerin kritik bir bileşenidir.
# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
}'
# After 3 failed processing attempts, message goes to DLQCloudWatch ile Arızaları Gözlemleme
Etkili sağlık kontrolleri ve circuit breaker'lar, arıza örüntülerini anlamak için izleme gerektirir. CloudWatch, gözlemlenebilirlik katmanıdır: ELB UnHealthyHostCount (sağlık kontrollerinde başarısız olan instance'lar), Lambda Errors oranı, SQS NumberOfMessagesSentToDLQ (DLQ'ya ulaşan mesajlar) ve hedef grubunun RequestCountPerTarget değeri için alarmlar oluşturun. Otomatik sağlık kontrolleri bozulma algıladığında nöbetçi ekibinizin hemen uyarılması için SNS bildirimleri ayarlayın.
# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
--alarm-name 'ALB-UnhealthyHosts' \
--alarm-description 'Alert when targets fail health checks' \
--metric-name UnHealthyHostCount \
--namespace AWS/ApplicationELB \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-teamHızlı Kontrol
Bu dersteki AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.
Ders Özeti
Bu derste şunları öğrendiniz: ELB ve Route 53 sağlık kontrolleri, altyapı düzeyinde arıza algılamayı otomatikleştirir, circuit breaker'lar sağlıksız hizmetlere yapılan çağrıları durdurarak zincirleme arızaları önler ve jitter içeren üstel geri çekilme, yük altında yeniden denemeleri güvenli hâle getirir. Dead Letter Queue'lar, başarısız mesajları incelenmek üzere yakalar. Sırada RTO, RPO ve felaket kurtarma katmanlarını inceleyeceğiz.
Sıkça Sorulan Sorular
“Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı” dersi ücretsiz mi?
Evet — “Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı” 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.
“Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı” dersinde ne öğreneceğim?
Arızaları algılamak ve trafiği otomatik olarak yeniden yönlendirmek için ELB durum denetimlerini, Route 53 uç nokta denetimlerini ve uygulama düzeyinde devre kesicileri kullanı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 4. dersidir.
“Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı” 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
- HA ve Hata Toleransı: Tanımlar ve Ödünleşimler
- Durum Bilgili Hizmetler için Çoklu AZ Örüntüleri
- Çok Bölgeli Etkin-Etkin ve Etkin-Pasif
- Durum Denetimleri, Devre Kesiciler ve Yeniden Deneme Mantığı