Azure Fundamentals · Ders

Durum Yoklamaları ve Zarif Kötüleşme

Durum Yoklamaları ve Zarif Kötüleşme, CoddyKit'te ücretsiz bir Azure Fundamentals 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, Azure Fundamentals öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Azure Fundamentals kursu toplamda 4 dersten oluşur.

Sağlık Yoklamaları Neden Önemlidir

Sağlık yoklamaları, yük dengeleyicilerin ve trafik yöneticilerinin bir arka uç örneğinin isteklere hizmet verip veremediğini algılamasını sağlayan mekanizmadır. Sağlık yoklamaları olmadan yük dengeleyici, arızalanmış veya yanıt vermeyen bir sunucuya trafik göndermeyi sürdürebilir ve kullanıcıların karşılaştığı hatalara yol açabilir. Doğru yapılandırılmış sağlık yoklamaları, arızadan sonraki saniyeler içinde trafiğin sağlıksız örneklerden otomatik olarak yeniden yönlendirilmesini sağlar.

Azure Load Balancer Sağlık Yoklamaları

Azure Load Balancer iki tür sağlık yoklamasını destekler:

TCP yoklaması — arka ucun belirtilen bağlantı noktasında bir TCP bağlantısını kabul edip edemediğini denetler. Basittir, ancak uygulama mantığını doğrulamaz.
HTTP/HTTPS yoklaması — belirtilen yola bir GET isteği gönderir ve 200 OK yanıtı bekler. Uygulama uç noktasını doğrudan sınadığı için daha doğrudur.

Yoklama, yapılandırılabilir sayıda ardışık denemede başarısız olursa arka uç sağlıksız olarak işaretlenir.

# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
  --resource-group myRG \
  --lb-name myLoadBalancer \
  --name httpHealthProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 15 \
  --threshold 2

Güvenilir Bir Sağlık Uç Noktası Tasarlama

İyi tasarlanmış bir sağlık uç noktası (/health), yalnızca 200 OK döndürmekten fazlasını yapar; uygulamanın kritik bağımlılıklarına erişilebildiğini doğrular. Kapsamlı bir sağlık denetimi, veritabanına, önbelleğe ve alt akıştaki API'lere bağlantıyı sınayabilir. Herhangi bir bağımlılık kullanılamıyorsa uç nokta bir 5xx durum kodu döndürür ve yük dengeleyiciye bu örneği dönüşümlü hizmet listesinden çıkarması gerektiğini bildirir.

# Example health endpoint response (JSON):
# GET /health
# {
#   'status': 'healthy',
#   'checks': {
#     'database': 'ok',
#     'cache': 'ok',
#     'externalApi': 'ok'
#   }
# }
# If database check fails, return HTTP 503 instead of 200

Traffic Manager Sağlık Yoklamaları

Azure Traffic Manager sağlık yoklamalarını bölgesel düzeyde de kullanır. Her bölgedeki yapılandırılmış uç nokta URL'sine düzenli HTTP veya HTTPS GET istekleri gönderir. Bir uç nokta, belirli sayıda ardışık aralık boyunca zaman aşımı penceresi içinde yanıt veremezse Traffic Manager bu uç noktayı performansı düşmüş olarak işaretler, DNS sorgularını bu uç noktaya yönlendirmeyi durdurur ve kullanıcıları sağlıklı bir bölgeye yönlendirir.

# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
  --resource-group myRG \
  --name myTMProfile \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /health \
  --monitor-interval 30 \
  --monitor-timeout 10 \
  --monitor-tolerated-failures 3

Application Gateway Sağlık Yoklamaları

Azure Application Gateway, Standard Load Balancer'dan daha gelişmiş sağlık yoklaması özelliklerine sahiptir. Ana bilgisayar üst bilgisini, beklenen durum kodu aralığını (ör. 200-399) ve gövde eşleşme dizesini belirten özel yoklamaları destekler. Application Gateway ayrıca yol başına yönlendirmeyi destekler; böylece farklı arka uç havuzları, farklı URL yolları için farklı sağlık yoklaması yapılandırmalarına sahip olabilir.

# Create a custom probe for Application Gateway:
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myRG \
  --name customProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /api/health \
  --interval 20 \
  --timeout 10 \
  --threshold 3

Kontrollü İşlev Azaltma Nedir

Kontrollü işlev azaltma, bir veya daha fazla bağımlılığı başarısız olduğunda uygulamanın kısmi işlevsellik sunmaya devam edebilmesidir. Uygulama tamamen çökmek yerine kritik olmayan bir hizmetin kullanılamadığını algılar ve işlevleri azaltılmış, ancak yine de yararlı bir duruma geçer. Örneğin bir öneri hizmeti başarısız olursa e-ticaret sitesi ürün sayfasının tamamını çökertmek yerine genel öneriler gösterebilir.

Devre Kesici Deseni

devre kesici deseni, bir uygulamanın başarısız olan alt hizmeti tekrar tekrar çağırmasını önler. Bir hizmet başarısız olmaya başladığında devre kesici açılır ve ağ çağrısı yapmadan hemen bir hata veya geri dönüş yanıtı verir. Bekleme süresinin ardından yarı açık duruma geçer ve deneme amaçlı bir isteğe izin verir. İstek başarılı olursa devre kapanır ve normal işlem devam eder.

# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN:   service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
#           success -> CLOSED
#           failure -> OPEN (reset timer)

# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)

Üstel Geri Çekilmeyle Yeniden Deneme

geçici hatalar (kısa süreli ağ kesintileri, geçici hizmet aşırı yükü) için Exponential geri çekilmeyle yeniden deneme stratejisi uygundur. Uygulama, başarısız çağrıyı bir gecikmenin ardından yeniden dener ve her denemede gecikmeyi bir üst sınıra kadar iki katına çıkarır. Gecikmeye jitter (random değişkenlik) eklemek, tüm yeniden deneme girişimlerinin eşzamanlanarak toparlanmakta olan hizmeti aşırı yüklemesini önler.

# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s  + random(0-500ms)
# attempt 2: wait 2s  + random(0-500ms)
# attempt 3: wait 4s  + random(0-500ms)
# attempt 4: wait 8s  + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to caller

Bölme Duvarı Deseni

bölme duvarı deseni, bir uygulamanın farklı bölümlerini kaynak havuzlarına ayırır. Böylece bir alandaki hata tüm kaynakları tüketip sistemin tamamını devre dışı bırakamaz. Bu ad, bir bölmesi su alan geminin tamamının batmasını önleyen gemi bölme duvarlarından gelir. Azure'da bu, hataları sınırlamak için farklı hizmetlerde ayrı iş parçacığı havuzları veya ayrı App Service planları kullanmak anlamına gelebilir.

Geri Dönüş Yanıtları ve Önbelleğe Alınmış Veriler

Denetimli bir performans düşüşü sağlamak için kullanılan yaygın tekniklerden biri, canlı veri kaynağı kullanılamadığında önbelleğe alınmış veya güncelliğini yitirmiş verileri sunmaktır. Örneğin, veritabanına geçici olarak erişilemediğinde bir ürün kataloğu sayfası hata göstermek yerine Azure Cache for Redis üzerinden dünkü önbelleğe alınmış fiyatları sunabilir. Kullanıcılar tamamen başarısız olan bir deneyim yerine küçük bir sorunla (biraz güncelliğini yitirmiş fiyatlarla) karşılaşır.

Performans Düşüşünü İzleme ve Uyarı Oluşturma

Denetimli performans düşüşü görünür olmalı ve ölçülmelidir. Devre kesicilerin açılma oranlarını, geri dönüş yanıtlarını ve yeniden deneme girişimlerini özel ölçümler olarak izlemek için Application Insights kullanın. Bu ölçümler eşikleri aştığında uyarılar oluşturun; böylece kullanıcıya sunulan deneyim kabul edilebilir görünse bile uygulamanın düşük performanslı bir durumda çalıştığı nöbetçi ekibe bildirilir.

Hızlı Kontrol

Bu derste işlenen Microsoft Azure Fundamentals (AZ-900) kavramlarını anlayıp anlamadığınızı sınayın.

Ders Özeti

Bu derste şunları öğrendiniz: sağlık yoklamaları, yük dengeleyicilerin başarısız arka uçları algılamasına ve trafiği otomatik olarak yeniden yönlendirmesine olanak tanır; denetimli performans düşüşü, bağımlılıklar başarısız olduğunda uygulamaların kısmen çalışır durumda kalmasını sağlar; devre kesici, geri çekilmeyle yeniden deneme ve bölme duvarı gibi desenler uygulama düzeyinde dayanıklılık sağlar. Sırada RTO, RPO ve kurtarma katmanlarını tanımlayacağımız olağanüstü durum kurtarma kavramlarını inceleyeceğiz.

Sıkça Sorulan Sorular

“Durum Yoklamaları ve Zarif Kötüleşme” dersi ücretsiz mi?

Evet — “Durum Yoklamaları ve Zarif Kötüleşme” 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 Azure Fundamentals kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Azure Fundamentals kursu toplamda 4 dersten oluşur.

“Durum Yoklamaları ve Zarif Kötüleşme” dersinde ne öğreneceğim?

Arızaları hızlıca algılamak için yük dengeleyici ve Traffic Manager durum yoklamalarını yapılandırın; uygulama katmanınız için devre kesici ve zarif kötüleşme kalıpları tasarlayın. Azure Fundamentals 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.

Azure Fundamentals öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Azure Fundamentals, 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 Yoklamaları ve Zarif Kötüleşme” 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 Azure Fundamentals dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Azure Fundamentals 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

Azure SLA’ları ve Birleşik SLA’lar
Kullanılabilirlik Kümeleri ve Kullanılabilirlik Alanları
Çok Bölgeli Aktif-Aktif Mimari
Durum Yoklamaları ve Zarif Kötüleşme

← Azure Fundamentals Sayfasına Dön