Chaos Engineering: Üretim Ortamında Kesintisiz Hizmetin Mimarı
Modern dağıtık sistem mimarileri, özellikle mikroservisler ve bulut altyapıları, doğaları gereği karmaşıklığı beraberinde getirir. Bu karmaşıklık, beklenmedik arızaların potansiyelini artırırken, sistemlerin üretim ortamında ne kadar dayanıklı olduğunu anlamak kritik hale gelmiştir. Geleneksel test yaklaşımları genellikle bilinen senaryoları kapsar; ancak asıl sorun, bilinmeyenin, öngörülemeyen arızaların nasıl yönetileceğidir. İşte bu noktada Chaos Engineering devreye girer.
Chaos Engineering Nedir?
Chaos Engineering, bir sistemin üretim ortamında veya üretime yakın ortamlarda arızalara ne kadar dayanıklı olduğunu proaktif olarak test etme disiplinidir. Amacı, sistemin zayıf noktalarını pasif gözlemle değil, aktif deneylerle ortaya çıkarmaktır. Bu, rastgele çökmeler yaratmak anlamına gelmez; aksine, bilimsel bir yaklaşımla, hipotezlere dayalı, kontrollü deneyler tasarlayarak ve uygulayarak sistemin gerçek davranışını anlamayı hedefler.
Bir Chaos Engineering deneyi, şu adımları takip eder:
- Normal Durum Tanımlama (Steady-State Definition): Sistem metrikleri (latency, error rate, throughput) üzerinden belirlenen, beklenen ve sağlıklı davranış kalıpları.
- Hipotez Oluşturma: "Eğer X servisi Y kadar gecikirse, sistemin Z metriği değişmeyecektir" gibi bir hipotez öne sürmek.
- Deney Çalıştırma: Kontrollü bir şekilde arıza enjekte etmek (servis durdurma, ağ gecikmesi, kaynak tüketimi).
- Sonuçları Gözlemleme ve Doğrulama: Hipotezin doğru olup olmadığını, sistemin normal durumdan sapıp sapmadığını izlemek.
Neden Chaos Engineering? Gerçek Dünya Senaryoları
Senaryo 1: Mikroservis Bağımlılık Arızaları
Büyük bir e-ticaret platformunun mikroservis mimarisine sahip olduğunu düşünelim. ödeme-servisi, stok-servisi ve kargo-servisi gibi kritik bağımlılıkları olan bir sipariş-işleme-servisi mevcuttur. Geleneksel testlerde bu servislerin tekil arızaları belki ele alınır, ancak stok-servisi'nin aniden yavaşlaması veya tamamen erişilemez hale gelmesi durumunda sipariş-işleme-servisi nasıl tepki verir? Bu durumun genel kullanıcı deneyimine etkisi ne olur?
Chaos Deneyi: stok-servisi'ne giden veya gelen ağ trafiğini belirli bir süre için engelleme veya gecikme enjekte etme.
Araçlar: Kubernetes ortamında Chaos Mesh veya LitmusChaos, bağımlı pod'lar arasında ağ gecikmesi veya bağlantı kesintisi enjekte etmek için kullanılabilir. Alternatif olarak, AWS üzerinde çalışan bir sistem için AWS Fault Injection Simulator (FIS) ile belirli bir EC2 instance'ının Security Group kurallarını değiştirerek veya ağ ACL'lerini manipüle ederek trafiği kesmek mümkün olabilir.
# Chaos Mesh ile bir pod'a ağ gecikmesi enjekte etme örneği
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: stock-service-latency
namespace: default
spec:
action: delay
mode: one
selector:
labelSelectors:
app: stock-service
delay:
latency: "5000ms"
duration: "60s" # 60 saniye boyunca gecikme
direction: both
target:
selector:
labelSelectors:
app: order-processing-service
mode: all
Bu deneyle, sipariş-işleme-servisi'nin stok-servisi'ne olan bağımlılığına karşı devre kesici (circuit breaker) mekanizmalarının doğru çalışıp çalışmadığı, zaman aşımlarının (timeout) beklendiği gibi davranıp davranmadığı ve son kullanıcıya makul bir hata mesajı sunulup sunulmadığı test edilir. Beklentimiz, sipariş-işleme-servisi'nin stok-servisi'nin yavaşlaması durumunda siparişleri kabul etmeye devam etmesi (belki stok kontrolü olmadan veya varsayılan bir stokla) veya zarif bir şekilde hata vermesidir.
Senaryo 2: Veritabanı Gecikmesi ve Erişilemezliği
Bir uygulamanın ana veritabanı (örneğin, AWS RDS üzerindeki bir PostgreSQL kümesi) aniden yüksek gecikme yaşamaya başlarsa veya erişilemez hale gelirse ne olur? Birçok uygulama, veritabanı bağlantı havuzu tükenmesi veya uzun süreli kilitlenmeler nedeniyle tamamen yanıt vermeyi durdurabilir.
Chaos Deneyi: Belirli bir RDS instance'ına yoğun yük bindirme veya ağ gecikmesi enjekte etme.
Araçlar: AWS Fault Injection Simulator (FIS) bu senaryo için idealdir. FIS ile bir RDS instance'ını belirli bir süre için yeniden başlatabilir, bir Availability Zone'u (AZ) izole edebilir veya CPU/I/O stres testi uygulayabiliriz.
# AWS FIS ile RDS instance'ına gecikme enjekte etme (pseudo-code)
# Gerçek FIS şablonları daha karmaşıktır ve hedef kaynakları, aksiyonları ve durdurma koşullarını içerir.
{
"description": "RDS Instance Latency Injection",
"targets": {
"MyRdsInstance": {
"resourceType": "aws:rds:db-instance",
"selectionMode": "ALL",
"parameters": {
"DBInstanceIdentifiers": ["my-prod-database-instance"]
}
}
},
"actions": {
"InjectNetworkLatency": {
"actionId": "aws:network:inject-latency",
"parameters": {
"delay": "100ms",
"duration": "5m"
},
"targets": {
"resourceType": "aws:rds:db-instance",
"targetName": "MyRdsInstance"
}
}
},
"stopConditions": [
{
"source": "cloudwatch",
"value": "MyRDSConnectionErrors > 50" # Bağlantı hataları belli bir eşiği aşarsa durdur.
}
]
}
Bu deney sırasında, uygulamanın veritabanı bağlantı havuzu yönetimi, retry mekanizmaları, önbellekleme stratejileri ve veritabanı başarısız olduğunda kullanıcıya sunulan geri bildirim incelenir. Amaç, ana veritabanı sorunları yaşarken bile uygulamanın tamamen çökmemesi, mümkünse sınırlı işlevsellikle çalışmaya devam etmesi veya zarif bir şekilde hata vermesidir.
Senaryo 3: Bölgesel Erişilebilirlik Sorunları (Availability Zone Failure)
Bulut tabanlı mimarilerde, birden fazla Availability Zone (AZ) kullanarak yüksek erişilebilirlik sağlamak standart bir yaklaşımdır. Ancak, bir AZ'nin tamamen veya kısmen erişilemez hale gelmesi durumunda sistemimiz gerçekten sorunsuz bir şekilde diğer AZ'lere failover yapabiliyor mu?
Chaos Deneyi: Bir AWS bölgesindeki belirli bir AZ'deki tüm EC2 instance'larını sonlandırma veya ağ erişimini kesme.
Araçlar: AWS FIS, belirli bir AZ içindeki kaynakları hedefleyebilir. Örneğin, bir grup EC2 instance'ını veya RDS instance'ını hedef alarak bunları durdurabilir veya yeniden başlatabilir. Bu, Load Balancer'ların (ALB/NLB) trafik yönlendirmesini, Auto Scaling gruplarının yeni instance'lar başlatmasını ve veritabanı replikasyonlarının sorunsuz bir şekilde primary role'ü üstlenmesini test etmemizi sağlar.
# AWS FIS ile bir Availability Zone'daki EC2 instance'larını sonlandırma (pseudo-code)
{
"description": "Terminate EC2 Instances in a specific AZ",
"targets": {
"Ec2InstancesInAZ1": {
"resourceType": "aws:ec2:instance",
"selectionMode": "ALL",
"parameters": {
"Filters": [
{
"Path": "Placement.AvailabilityZone",
"Values": ["us-east-1a"] # Hedef AZ
}
]
}
}
},
"actions": {
"TerminateInstances": {
"actionId": "aws:ec2:terminate-instances",
"targets": {
"resourceType": "aws:ec2:instance",
"targetName": "Ec2InstancesInAZ1"
}
}
},
"stopConditions": [
{
"source": "cloudwatch",
"value": "ApplicationErrorRate > 10" # Uygulama hata oranı belirli bir eşiği aşarsa durdur.
}
]
}
Bu deneyin amacı, sistemin otomatik ölçeklendirme, yük dengeleme ve veri replikasyonu mekanizmalarının AZ arızalarına karşı ne kadar etkili olduğunu ortaya koymaktır. Beklentimiz, kullanıcıya kesinti yaşatmadan veya minimum kesintiyle sistemin diğer AZ'lerde çalışmaya devam etmesidir.
Sonuç
Chaos Engineering, üretim ortamındaki kırılganlıkları proaktif bir şekilde ortaya çıkararak sistem güvenilirliğini artıran vazgeçilmez bir disiplindir. Bu disiplin, sadece arızaları bulmakla kalmaz, aynı zamanda ekiplerin arıza durumlarında nasıl tepki vereceğini ve sistemlerini nasıl daha dirençli hale getireceğini öğrenmelerini sağlar. AWS Fault Injection Simulator, Chaos Mesh gibi araçlar, bu tür deneyleri güvenli ve kontrollü bir şekilde yürütmek için güçlü yetenekler sunar. Kesintisiz ve dayanıklı hizmet sunma hedefi olan her organizasyon için Chaos Engineering, DevOps ve SRE pratiklerinin ayrılmaz bir parçası olmalıdır.