Mikroservis Mimarisi & Dayanıklılık Mühendisliği 6 dk okuma 3 okunma

Chaos Engineering: Mikroservislerde Dayanıklılık Testleri

Chaos Engineering, sistemin zayıf noktalarını üretim ortamında kontrollü deneylerle keşfetmeyi amaçlar. Mikroservislerde ağ gecikmesi, servis çökmesi, kaynak tüketimi gibi arızalar simüle edilerek dayanıklılık test edilir. Chaos Monkey, Litmus, Gremlin gibi araçlar ve .NET'te Polly ile uygulama stratejileri ele alınır.

Chaos Engineering: Mikroservislerde Dayanıklılık Testleri

Chaos Engineering: Mikroservislerde Dayanıklılık Testleri

Mikroservis mimarisinde, "her şey yolunda" olduğu bir anda bile bir servis çökebilir, ağ gecikebilir veya bir düğüm arızalanabilir. Geleneksel test yöntemleri (unit, integration, load test) bu tür senaryoları simüle etmekte yetersizdir; çünkü test ortamı, üretim ortamının kaosunu yansıtmaz. İşte Chaos Engineering (Kaos Mühendisliği), sistemin zayıf noktalarını kasıtlı olarak arıza enjekte ederek keşfetmeyi amaçlayan bir disiplindir.

1. Chaos Engineering Nedir?

Chaos Engineering, dağıtık sistemlerde güveni artırmak için kontrollü deneyler yapma disiplinidir. Amaç, sistemin gerçek dünyada karşılaşabileceği arızalara karşı ne kadar dayanıklı olduğunu ölçmek ve zayıf noktaları üretim ortamına zarar vermeden keşfetmektir.

Temel Prensipler (Principles of Chaos):

  1. Bir hipotez kurun: "Bu servis çökerse, sistem çalışmaya devam eder."

  2. Gerçek dünya olaylarını simüle edin: Ağ gecikmesi, sunucu çökmesi, disk dolması.

  3. Üretim ortamında test edin: Test ortamı değil, gerçek trafik.

  4. Sürekli çalıştırın: Otomatik ve sürekli deneyler.

  5. En az etkiyle başlayın: Küçük deneylerle başlayıp kapsamı genişletin.

2. Neden Chaos Engineering?

Mikroservislerde arızalar kaçınılmazdır. Chaos Engineering'in sağladığı faydalar:

Fayda Açıklama
Zayıf Noktaları Keşfetme Sistemin nerede çökeceğini önceden öğrenin.
Dayanıklılık Doğrulama Retry, circuit breaker, bulkhead gibi desenlerin çalıştığını doğrulayın.
MTTR Azaltma Arıza anında müdahale süresini kısaltın.
Kültür Değişimi Arızayı bir hata değil, öğrenme fırsatı olarak görün.
Müşteri Güveni Üretimde çökmeden önce sorunları çözün.

3. Kaos Deneyi Türleri

Chaos Engineering'de en yaygın kaos türleri:

A. Ağ Kaosu (Network Chaos)

  • Latency (Gecikme): Servisler arası çağrılara yapay gecikme ekleme.

  • Packet Loss (Paket Kaybı): Ağ paketlerinin bir kısmını düşürme.

  • Bandwidth Limiting: Bant genişliğini sınırlama.

  • DNS Failure: DNS çözümlemesini bozma.

B. Servis Kaosu (Service Chaos)

  • Pod Kill: Rastgele pod'ları öldürme.

  • Container Kill: Container'ları sonlandırma.

  • Service Unavailable: Bir servisi geçici olarak devre dışı bırakma.

C. Kaynak Kaosu (Resource Chaos)

  • CPU Stress: CPU'yu aşırı yükleme.

  • Memory Stress: Belleği tüketme.

  • Disk Fill: Diski doldurma.

  • I/O Stress: Disk G/Ç'yi yavaşlatma.

D. Uygulama Kaosu (Application Chaos)

  • Exception Injection: Belirli metotlarda exception fırlatma.

  • Response Delay: Belirli endpoint'lerde gecikme.

  • HTTP Error Injection: 5xx hataları döndürme.

E. Durum Kaosu (State Chaos)

  • Time Skew: Saat kayması simülasyonu.

  • Clock Drift: Zamanı ileri/geri alma.

4. Popüler Chaos Engineering Araçları

Araç Platform Özellikler
Chaos Monkey Netflix (AWS) Rastgele instance'ları sonlandırır.
Litmus Kubernetes (CNCF) Kubernetes-native, zengin kaos kütüphanesi.
Chaos Mesh Kubernetes (CNCF) Pod, network, I/O, stress kaosları.
Gremlin Ticari Kullanıcı dostu arayüz, geniş kaos kütüphanesi.
AWS Fault Injection Simulator AWS AWS servislerine özel kaos deneyleri.
Azure Chaos Studio Azure Azure kaynaklarına yönelik kaos deneyleri.
Steadybit Ticari Güvenlik odaklı, otomatik kaos.

5. Kubernetes'te Chaos Mesh ile Deney

Chaos Mesh, Kubernetes ortamında en yaygın kullanılan açık kaynak kaos aracıdır.

A. Pod Kill Deneyi

yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
  namespace: default
spec:
  action: pod-kill
  mode: one
  selector:
    labelSelectors:
      app: order-service
  scheduler:
    cron: '@every 5m'  # Her 5 dakikada bir

B. Network Latency Deneyi

yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-example
spec:
  action: delay
  mode: all
  selector:
    labelSelectors:
      app: payment-service
  delay:
    latency: '500ms'
    correlation: '100'
    jitter: '0ms'
  duration: '5m'

C. CPU Stress Deneyi

yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: cpu-stress-example
spec:
  mode: one
  selector:
    labelSelectors:
      app: inventory-service
  stressors:
    cpu:
      workers: 2
      load: 80  # %80 CPU yükü
  duration: '10m'

6. .NET'te Chaos Engineering: Polly ile Simülasyon

Chaos Engineering'i uygulama seviyesinde test etmek için Polly'nin Simmy (Chaos Monkey for Polly) uzantısı kullanılabilir.

Kurulum:

bash

dotnet add package Polly.Contrib.Simmy

A. Exception Injection (Hata Enjeksiyonu)

csharp

using Polly.Contrib.Simmy;
using Polly.Contrib.Simmy.Behavior;

// %10 olasılıkla exception fırlat
var chaosPolicy = MonkeyPolicy.InjectExceptionAsync(
    with =>
    {
        with.Fault(new InvalidOperationException("Simüle edilmiş hata!"));
        with.InjectionRate(0.1); // %10
        with.Enabled(true);
    });

var pipeline = Policy.WrapAsync(chaosPolicy, retryPolicy, circuitBreakerPolicy);

B. Latency Injection (Gecikme Enjeksiyonu)

csharp

var latencyPolicy = MonkeyPolicy.InjectLatencyAsync(
    with =>
    {
        with.Latency(TimeSpan.FromSeconds(2)); // 2 saniye gecikme
        with.InjectionRate(0.05);              // %5 olasılıkla
        with.Enabled(true);
    });

C. Result Injection (Hatalı Sonuç Enjeksiyonu)

csharp

var resultPolicy = MonkeyPolicy.InjectResultAsync<HttpResponseMessage>(
    with =>
    {
        with.Result(new HttpResponseMessage(HttpStatusCode.InternalServerError));
        with.InjectionRate(0.1);
        with.Enabled(true);
    });

Kullanım:

csharp

var policy = Policy.WrapAsync(
    latencyPolicy,
    exceptionPolicy,
    retryPolicy,
    circuitBreakerPolicy
);

var response = await policy.ExecuteAsync(async () =>
    await _httpClient.GetAsync("https://api.example.com/data"));

7. Chaos Engineering Deney Akışı

Adım 1: Hipotez Kurun

"Ödeme servisi 5 saniye gecikirse, sipariş servisi yine de 10 saniye içinde yanıt döner."

Adım 2: Küçük Başlayın
Test ortamında veya üretimde düşük trafikli saatlerde başlayın.

Adım 3: Deneyi Çalıştırın
Chaos Mesh veya Simmy ile arızayı enjekte edin.

Adım 4: Gözlemleyin
Metrikleri izleyin: hata oranı, yanıt süresi, kaynak tüketimi.

Adım 5: Sonuçları Analiz Edin

  • Hipotez doğrulandı mı?

  • Beklenmedik bir davranış var mı?

  • Hangi servis çöktü?

Adım 6: İyileştirin

  • Retry, circuit breaker, bulkhead ekleyin.

  • Timeout sürelerini optimize edin.

  • Servisleri izole edin.

Adım 7: Tekrarlayın
Chaos Engineering süreklilik gerektirir.

8. Kaos Deneyleri için En İyi Pratikler

Pratik Açıklama
Blast Radius'u Sınırlayın Tüm sistemi değil, önce bir servisi test edin.
Gözlemlenebilirlik Şart Deney öncesi metrik ve log altyapınızın hazır olduğundan emin olun.
Rollback Planı Deney ters giderse anında geri dönebilin.
İş Saatlerinde Test Edin Sabah 3'te değil, ekip hazırken test edin.
Production'da Test Edin En iyi test ortamı, üretimdir (düşük trafikli saatlerde başlayın).
Otomatikleştirin CI/CD pipeline'ına chaos deneylerini ekleyin.
Kültürü Benimseyin Arızayı bir hata değil, öğrenme fırsatı olarak görün.
Gerçekçi Senaryolar Kullanın Gerçek dünyada karşılaşılan arızaları simüle edin.
Ekip Eğitimi Tüm ekip chaos deneylerine katılmalı.
Güvenlik Sınırları Deneylerin veri kaybına yol açmadığından emin olun.

9. Chaos Engineering vs. Diğer Test Türleri

Test Türü Amaç Ne Zaman Kullanılır?
Unit Test Tek bir metot doğru mu? Geliştirme sırasında
Integration Test Servisler birlikte çalışıyor mu? CI/CD pipeline'ında
Load Test Sistem yüksek trafik altında dayanıklı mı? Release öncesi
Chaos Engineering Sistem arıza altında dayanıklı mı? Sürekli, üretimde

Chaos Engineering, diğer test türlerini tamamlar, onların yerini almaz.

10. Gerçek Dünya Senaryosu: E-Ticaret Uygulaması

Senaryo: Bir e-ticaret uygulamasında, ödeme servisi zaman zaman yavaşlıyor. Sistemin bu duruma dayanıklı olup olmadığını test etmek istiyorsunuz.

Deney Tasarımı:

yaml

# Chaos Mesh ile ödeme servisine 2 saniye gecikme enjekte et
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency-test
spec:
  action: delay
  mode: all
  selector:
    labelSelectors:
      app: payment-service
  delay:
    latency: '2000ms'
  duration: '10m'

Beklenen Davranış:

  • Order Service, Payment Service'e istek gönderir.

  • 2 saniyelik gecikme nedeniyle Payment Service yavaş yanıt verir.

  • Order Service'deki timeout (ör. 3 saniye) devreye girer.

  • Retry politikası ile tekrar denenir.

  • Circuit Breaker devreye girer ve Payment Service'e yapılan çağrılar geçici olarak durdurulur.

  • Kullanıcıya anlamlı bir hata mesajı döner.

Sonuç: Sistem, ödeme servisi yavaşladığında bile çökmüyor; kullanıcıya hata mesajı dönüyor.

Sonuç

Chaos Engineering, dağıtık sistemlerin dayanıklılığını gerçek dünya arızalarını simüle ederek test etmenin en etkili yoludur. Kontrollü deneyler, küçük başlangıç, sürekli test ve gözlemlenebilirlik ile sisteminizin zayıf noktalarını üretim ortamına zarar vermeden keşfedebilirsiniz. Kubernetes'te Chaos Mesh ve Litmus, uygulama seviyesinde Polly Simmy ile kaos deneylerini kolayca uygulayabilirsiniz. Unutmayın: Chaos Engineering bir "saldırı" değil, bir "öğrenme" aracıdır. Amaç, sisteminiz çökmeden önce nerede ve nasıl çökeceğini bilmektir. Güvenilir sistemler, arıza olmadığında değil, arıza olduğunda bile çalışmaya devam eden sistemlerdir.

Tüm yazılar Soru ya da yorumun mu var? Yaz