Azure Resiliency Evrimi: Şehir Gibi Düşünen Bulut Mimarisi
Bulutta dayanıklılık deyince çoğu kişinin aklına aynı şeyler geliyor: SLA yüzdeleri, kaç replika var, failover kaç dakikada dönüyor… İşin aslı biraz başka. Saha artık bu klişeleri geçti. Hele bir de de de regüle sektörlerde çalışanlar, egemenlik gereksinimi olanlar ya da jeopolitik olarak hassas bölgelerde iş yapanlar için “resiliency” dediğimiz şey, baya farklı bir yere kaydı.
Bu, tek başına bir sistem meselesi değil. Bir şehir meselesi.
Size bir şey söyleyeyim, Modern bir şehri düşünün. Tek bir enerji hattına, tek bir yola, tek bir kontrol merkezine bağlı kalmıyor. Deprem oluyor, sel geliyor, altyapı çöküyor — şehir yine de ayakta kalabiliyorsa; bunun sebebi sadece yedeklilik değil (evet, doğru duydunuz). Yönetim var, kontrol var, kurtarma mekanizmaları var. Ve en önemlisi: bunların hepsi yerel gerçeklere göre tasarlanmış.
Azure’un son yıllardaki resiliency yaklaşımı da tam buraya kaydı. Microsoft geçen sene üç sütunlu bir çerçeveden söz etmişti: altyapı dayanıklılığı, veri dayanıklılığı ve siber kurtarma. Bu yıl işe işin operasyon tarafı öne çıktı —. “tasarladım, kurdum, bitti” kafasından çıkıp, “sürekli test ediyorum, sürekli iyileştiriyorum” tarafına geçiş var.
Ben bu yazıda hem Microsoft’un anlattığı çerçeveyi kendi bakışımla toparlayacağım, hem de Türkiye’deki kurumsal müşteri profili için pratik bir yol haritası çıkaracağım. Çünkü Amerika’daki bir SaaS şirketinin resiliency anlayışıyla İstanbul’daki bir bankanın ya da Ankara’daki bir kamu kurumunun bakışı aynı olamaz. Olmamalı da.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Paylaşılan Sorumluluk: “Microsoft yapar, ben rahat ederim” devri kapandı mı?
Bakın, Azure’un resiliency yaklaşımındaki en hayatı nüans şu: Microsoft dayanıklılığı size sunmuyor, sizinle birlikte kuruyor (yanlış duymadınız). Marketing cümlesi gibi dürüyor, evet; ama pratikte karşılığı çok net.
Aslında — hayır dur, daha doğrusu, Sahada sık gördüğüm bir hata var: Ekipler uygulamayı Azure’a taşıyor, sonra “tamam biz dayanıklıyız çünkü Microsoft’un %99.99 SLA’i var” diyor. Ardından her şeyi tek Availability Zone’a deploy ediyorlar; tek region, tek disk tipi… Sonra bir gün zone kesilince ortalık karışıyor. “Ya Microsoft nasıl olur?” diye soran da çıkıyor. Olur tabiî. Çünkü SLA ancak doğru mimariyi kurduğunuzda anlam kazanıyor.
O yüzden paylaşılan sorumluluk modeli aslında işi bir devretme hikâyesi olmaktan çıkarıp ortaklık hâline getiriyor. Platform tarafı temel altyapıyı, yedekliliği ve güvenlik primitiflerini veriyor. Ama Well-Architected Framework‘e uygun mimarı kurmak, kaos testleri yapmak, DR planını hazırlamak — bunlar sizin işiniz.
“Azure resilient bir platform” cümlesi doğru. Ama “Azure’da olduğum için ben resilient’ım” cümlesi… maalesef değil. İkisi arasındaki farkı anlamak, iyi mimarla vasat mimarı ayıran şey.
Peki fiziksel katman? Zonlar, bölgeler ve egemenlik işi nereye gidiyor?
Azure’un fiziksel katmanı yıllar içinde epey toparlandı. Availability Zone’lar, Region’lar, Region Pair’lar, Edge Zone’lar… Kağıt üzerinde zengin görünüyor. Ama Türkiye tarafında küçük ama can sıkıcı bir gerçek var: Yerel bir Azure bölgemiz yok. Haritada Azure Türkiye Central diye bir kayıt (belki yanılıyorum ama) bulunmuyor şu an. En yakın seçenekler Almanya (Frankfurt), Hollanda (Amsterdam), İtalya ve İsviçre.
Bu ne demek? Kuzey Avrupa tarafında latency genelde 30-50ms bandında dolaşıyor. Veri egemenliği isteyen kamu kurumları — kendi adıma konuşayım — ya da BDDK regülasyonuna tabi bankalar için tablo biraz zorlaşıyor (ki bu çoğu kişinin gözünden kaçıyor). Yanı “Azure’un zone yeteneklerini kullanabiliyorum ama veri ülke dışına çıkıyor” gerçeğiyle yüzleşmek gerekiyor.
Peki neden?
Sovereignty (Egemenlik) — Yeni hayatı eksen bu mu?
Microsoft son iki yıldır bu konuya baya yatırım yapıyor. Microsoft Cloud for Sovereignty, confidential computing yetenekleri, customer-managed keys, HSM entegrasyonları… Hepsi aynı yöne dönük adımlar. Ama Türkiye özelinde egemenlik dediğimizde iki katmanı ayırmak lazım:
- Veri egemenliği: Verinin fiziksel olarak nerede durduğu. Bu kısmı çoğu zaman region seçimiyle çözersiniz.
- Operasyonel egemenlik: Veriye kimin erişebildiği, hangi jurisdiction’ın yasalarına tabi olduğu. Bu daha karışık; Microsoft personelinin desteğe erişimi, log verilerinin nereye gittiği, şifreleme anahtarlarının kimde olduğu gibi katmanları var.
Bunu çözmek için
Siber kurtarma dediğimiz şey sistemi daha temiz, daha güvenilir bir noktadan yeniden ayağa kaldırabilme yeteneği. Bunun için air-gapped backup’lar lazım oluyor; immutable (söylemesi ayıp) vaults lazım oluyor; forensic-ready loglar lazım oluyor. Microsoft bu tarafta son dönemde Azure Brain: Bulutun Sağlığını İzleyen AI Beyni yazımda değindiğim gibi AI destekli anomali tespiti tarafına da el atıyor.
Niyetten uygulamaya geçince işler neden değişiyor? Chaos Engineering ve doğrulama meselesi
İtiraf edeyim, Burası işin en eğlenceli kısmı aslında. Tasarım güzel olabilir, dokümantasyon da güzel olabilir — ama gerçek dünyada test etmediyseniz DR planınız çoğu zaman süslü bir PDF’den ibaret kalıyor. Amazon’un Netflix’in Google’ın yıllardır yaptığı chaos engineering pratikleri şimdi kurumsal tarafa da yayılıyor.
Kısa bir not düşeyim buraya.
Eh, Cotchaos Studio>
Sıkça Sorulan Sorular
Azure resiliency ile high availability aynı şey mi?
Hayır, ikisi farklı şeyler. High availability, sistemin ne kadar süre ayakta kaldığıyla (uptime) ilgili. Resiliency işe aslında çok daha geniş bir kavram — felaketten kurtarma, siber saldırıdan toparlanma, veri bütünlüğü, operasyonel süreklilik gibi katmanları da kapsıyor. Yanı bence HA’yı resiliency’nın sadece bir parçası olarak düşünmek daha doğru.
Availability Zone yeterli mi, yoksa multi-region şart mı?
Çoğu durumda Availability Zone yeterli oluyor aslında — hani aynı bölge içinde farklı fiziksel veri merkezleri kullanılıyor zaten. Ama tüm bölgeyi vuran bir olay söz konusuysa (nadir de olsa oluyor), ya da regülatif bir zorunluluk varsa, multi-region kaçınılmaz (ben de ilk duyduğumda şaşırmıştım). Mesela bankacılık, sağlık, kritik altyapı gibi alanlarda multi-region genellikle tartışmasız bir gereklilik oluyor.
Azure Chaos Studio production ortamında güvenli mi?
Doğru kurgulandığında evet. Chaos Studio, deneylerin kapsamını oldukça sıkı tutmanıza izin veriyor — hangi kaynakları, ne kadar süreyle ve hangi saatlerde etkileyeceğini kendiniz belirliyorsunuz. Ama açıkçası, önce test/staging ortamında iyice deneyimlemeden production’a geçmemek gerekiyor. Tecrübeme göre bu adımı atlayan ekipler pişman oluyor. Netflix bile Chaos Monkey’e “önce staging” prensibiyle başlamıştı.
Türkiye’de veri egemenliği gerektiren bir kurum Azure kullanabilir mi?
Eh, Duruma göre değişiyor. Kişisel verilerin yurt dışına çıkmasına izin vermeyen katı regülasyonlar varsa, Azure’un mevcut bölgeleri (Almanya, İtalya vb.) yetmeyebilir. Bu noktada hibrit senaryolar devreye girebiliyor — yanı Azure Stack HCI ya da Azure Local gibi çözümler. Ama bence şunu da söylemek lazım: KVKK ve BDDK bazlı senaryoların büyük çoğunluğunda, Microsoft’un sovereignty kontrolleriyle uyumlu bir yapı kurulabiliyor.
Resiliency’ye ne kadar bütçe ayırmak mantıklı?
Şöyle bir yol var: önce iş yükünüzün downtime’ının size dakika ya da saat başına ne kadara mal olduğunu hesaplayın. Kritik uygulamalar için ana workload maliyetinin %30-50’si civarında bir resiliency yatırımı sağlıklı. Non-critical iş yüklerinde bu oran %10-15’e kadar düşebilir. Yanı aslında “herkese uyan tek bir formül” diye bir şey yok — iş etkisine göre tier’lamak gerekiyor bence.
Kaynaklar ve İleri Okuma
Built to bounce back: How Azure resiliency evolved (Orijinal Microsoft Azure Blog)
Bunu yaşayan biri olarak söyleyeyim, Azure Well-Architected Framework — Reliability Pillar
Azure Chaos Studio Resmî Dokümantasyonu
Azure Reliability Hub — Bölge, Zone ve Servis Detayları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments