AWS üzerinde hataya dayanıklı ve dirençli uygulamalar tasarlamak

AWS üzerinde Uygulama Geliştirme

Ricardo Sueiras

Principal Technologist

Dayanıklılık için geliştirme

Geçici hatalar

 

• Yaygın hata türlerini anla:
• Geçici hatalar kendiliğinden kaybolur, genelde yeniden denemek güvenlidir.

Zaman aşımları

 

• Yaygın hata türlerini anla:
• Geçici hatalar kendiliğinden kaybolur, genelde yeniden denemek güvenlidir.
• Zaman aşımı: dış servis yanıt vermekte çok gecikiyor.

Kalıcı hatalar

 

• Yaygın hata türlerini anla:
• Geçici hatalar kendiliğinden kaybolur, genelde yeniden denemek güvenlidir.
• Zaman aşımı: dış servis yanıt vermekte çok gecikiyor.
• Kalıcı hatalar: istek temelde hatalı, yeniden denemek işe yaramaz.

API limitleri

 

• Yaygın hata türlerini anla:
• Geçici hatalar kendiliğinden kaybolur, genelde yeniden denemek güvenlidir.
• Zaman aşımı: dış servis yanıt vermekte çok gecikiyor.
• Kalıcı hatalar: istek temelde hatalı, yeniden denemek işe yaramaz.
• API hız limitleri: çok fazla istek, HTTP 429 Too Many Requests beklenir.

Yeniden deneme stratejileri

• Dağıtık sistemlerde hatalar çoğunlukla geçicidir.
• Yeniden denenen bir istek sık sık başarılı olur.
• Retry mantığını dikkatle ekle; körüne denemeler durumu kötüleştirebilir.
• Üssel geri çekilme: denemeler arasındaki gecikmeyi artır.
• Jitter: yeniden deneme yığılmalarını önlemek için rastgelelik ekle.
• Retry sınırları: sonsuz döngüleri engelle.

 

AWS SDK yerel yetenekleri

• AWS SDK'lar retry mantığını otomatik yönetir.
• Dahili retry; üssel geri çekilme ve jitter içerir.
• Başarısız veya kısıtlanan istekler artan gecikmeyle yeniden denenir.
• Yazman gereken hata yönetimi kodunu azaltır.

 

Retry mantığını yönetmek

 

• Retry mantığı her zaman çözüm değildir.
• HTTP 4xx hataları: sunucu isteğini anladı ve reddetti.
• İdempotent olmayan istekler: yeniden denemek yinelenen veya tutarsız işlemlere yol açabilir.

Zaman aşımlarını yönetmek

 

• Sınırsız yeniden deneme, yük altında sorunları büyütebilir.
• Yeniden denemeleri zaman aşımlarıyla birleştir.
• Zaman aşımı, bir yanıt için bekleyeceğin en uzun süreyi belirler.
• Her dış servis çağrısında bir zaman aşımı olmalı.

Circuit breakerlar

• Bir servis sürekli hata veriyorsa, sadece yeniden denemek yetmez.
• İstek göndermeye devam etmek hatalı servisi aşırı yükleyebilir.
• Circuit breaker deseni, sağlıksız bağımlılığa geçici olarak istekleri durdurur.
• Kapalı durum: istekler normal akar.

 

Circuit breakerlar

• Hatalar eşik değeri aşınca devre açılır.
• Sonraki istekler engellenir.

 

Circuit breakerlar

• Soğuma süresinden sonra, toparlanmayı test etmek için devre yarı açık duruma geçer.
• Servis başarılı yanıt verirse: normal işleyişe dönülür.
• Hâlâ hatalıysa: devre açık kalır.
• Circuit breakerları uygulama katmanında uygula.

 

Dead letter queue'lar

 

• Sürekli başarısız olan iletiler sistemi tıkayabilir.
• Onları ana işlem akışından çıkar.
• Başarısız iletiler Dead Letter Queue'ya düşer.
• Dayanıklı uygulamalar kurmanın kilit parçasıdır.
• Ancak, ödünleşimleri anla

AWS API limitleri

 

• AWS servisleriyle API'ler üzerinden etkileşirsin.
• Her servis kendi API hız limitlerini tanımlar.
• Limitleri aşmak kısıtlama tetikler (HTTP 429 Too Many Requests).
• Uygulamanı kısıtlamayı zarifçe ele alacak şekilde tasarla.

Üçüncü taraf servislerle entegrasyon

• Üçüncü taraf servisler belirsizlik getirir.
• Performansları veya kullanılabilirlikleri üzerinde kontrolün yok.
• Uzun beklemeleri önlemek için zaman aşımı ayarla.
• Geçici sorunlar için geri çekilmeli yeniden deneme kullan.
• Etki alanını sınırlamak için bağımlılıkları yalıt.

 

Üçüncü taraflarla entegrasyon

• Senkron haberleşmeden asenkrona geçmeyi düşün.
• Dış servis gecikse bile sistemin işlemeye devam eder.

 

Hadi pratik yapalım!

AWS üzerinde Uygulama Geliştirme