Tek hata noktasını ortadan kaldırmak: AWS'de Multi-AZ mimari adımları

Availability Zone nedir ve neyi korur?

AWS altyapısı bölgelere (Region) ayrılır; her bölge, birbirinden yalıtılmış birden çok erişilebilirlik bölgesinden (Availability Zone, AZ) oluşur. AZ'yi, bölge içinde ayrı olarak çalışan bir ya da birkaç veri merkezi grubu olarak düşünebilirsiniz. Amaç, bir veri merkezini etkileyen elektrik, soğutma ya da ağ arızasının diğer AZ'lere taşmamasıdır.

Bu yüzden Multi-AZ tasarımı, tek bir veri merkezinin kaybına karşı yüksek erişilebilirlik sağlar. Bölgenin tamamını etkileyen bir felaket için ise farklı bir yaklaşım, yani çok bölgeli felaket kurtarma gerekir. İkisini karıştırmamak önemlidir: Multi-AZ her gün işleyen ve çoğu zaman otomatik çalışan dayanıklılık düzenidir, çok bölgeli kurtarma ise nadir görülen büyük olaylar içindir.

AWS'nin felaket kurtarma belgesi de aynı ayrımı yapar: iyi tasarlanmış yüksek erişilebilir bir iş yükünde tek bir fiziksel veri merkezinin kaybı, çoğu zaman yedekten geri yükleme ile karşılanabilecek bir olaydır. Yani önce AZ düzeyinde dayanıklılık kurulur, sonra gerekiyorsa bölgeler arası strateji eklenir.

Katman katman Multi-AZ: neyin otomatik, neyin sizin işiniz olduğu

Her AWS hizmeti AZ konusunda aynı davranmaz. Önce hangisinin kendiliğinden dayanıklı, hangisinin sizin yapılandırmanıza bağlı olduğunu ayırmak gerekir.

• Yük dengeleyici: Elastic Load Balancing, bir ya da birden çok AZ'deki hedeflere dağıtım yapar. Dayanıklılık için yük dengeleyiciyi birden çok AZ'deki alt ağlara yerleştirirsiniz.
• Hesaplama (EC2): Bir EC2 instance'ı tek bir AZ'de çalışır. Dayanıklılık, instance'ı çoğaltarak ve Auto Scaling grubunu birden çok AZ'ye yayarak sağlanır. Auto Scaling, instance'ları seçilen AZ'ler arasında dengeli tutar.
• Veritabanı (RDS): Multi-AZ seçeneği, başka bir AZ'de yedek instance tutar ve birincil sorun yaşarsa yük devri yapar. Aurora'da küme diski birden çok AZ'ye yayılır ve okuyucu instance'lar farklı AZ'lere konabilir.
• Blok depolama (EBS): Bir EBS diski tek bir AZ'ye bağlıdır. AZ kaybına karşı anlık görüntüler ve veri çoğaltma gerekir.
• Nesne depolama (S3): Bölge düzeyinde çalışır ve verinin birden çok AZ'ye dağıtılmasını hizmet üstlenir; bu nedenle sizin ayrıca AZ ayarı yapmanız gerekmez.
• Ağ çıkışı (NAT gateway): Bir AZ'ye yerleştirilir. AZ kaybında diğer AZ'lerin internet çıkışı kesilmesin diye her AZ'de ayrı NAT gateway kurmak yaygın bir önlemdir.

Bu liste şunu gösterir: Multi-AZ tek bir ayar değildir, her katmanda ayrı bir karardır. Bir katman atlanırsa zincir yine tek bir noktaya bağımlı kalır.

Adım adım: web uygulamasını Multi-AZ yapmak

Örneğin bir web uygulaması ve ilişkisel veritabanı düşünelim. Dayanıklı kurulumun sırası şudur:

• Ağ: VPC içinde her AZ için en az bir genel ve bir özel alt ağ oluşturun. Alt ağlar tek bir AZ'ye aittir; AZ dağılımını bu aşamada belirlersiniz.
• Yük dengeleyici: Application Load Balancer'ı genel alt ağların tümüne yerleştirin. Hedef grubuna uygulama sunucularını kaydedin ve sağlık kontrolünü tanımlayın.
• Uygulama sunucuları: Launch template'ten Auto Scaling grubu oluşturun, özel alt ağların hepsini seçin. En düşük kapasiteyi AZ sayısına uygun belirleyin ki bir AZ kaybında diğerlerinde en azından asgari hizmet sürsün.
• Veritabanı: RDS için Multi-AZ'yi etkinleştirin ya da Aurora'da okuyucuyu farklı AZ'de oluşturun. Uygulama veritabanına her zaman uç nokta adıyla bağlansın.
• Paylaşılan durum: Oturum bilgisini ve yüklenen dosyaları sunucu yerel diskinden çıkarın; paylaşılan bir depoya (önbellek, nesne depolama, paylaşılan dosya sistemi) taşıyın.
• Dışa çıkış: Her özel alt ağ kendi AZ'sindeki NAT gateway üzerinden çıkış yapsın.

Bu kurulumun mantığı basittir: her katmanın birden çok AZ'de karşılığı vardır ve hiçbir parça tek bir AZ'ye hapsolmamıştır. Kurulumu elle yapmak yerine CloudFormation ya da Terraform ile tanımlayın; aksi halde AZ'ler arasındaki farklar zamanla sapar.

Kapasite hesabı: bir AZ kaybolursa geriye ne kalır?

Multi-AZ'nin sık atlanan yönü kapasitedir. Uygulama sunucuları AZ'lere eşit dağılmışsa bir AZ düştüğünde toplam kapasitenin o payı kaybolur. Kalan sunucular tüm trafiği karşılamak zorundadır. Bu durum hesaplanmazsa, mimari AZ kaybında ayakta görünür ama yük altında çöker.

Pratik yaklaşım, kayıp senaryosunu baştan hesaba katmaktır:

• Normal zamandaki kullanımı değil, bir AZ kaybından sonraki kullanımı hedefleyin; her AZ'de belirli bir miktar boşluk bırakın.
• Auto Scaling grubunun en düşük kapasitesini bu boşluğa göre yükseltin ve en yüksek kapasitenin kota sınırlarını kontrol edin.
• Ölçeklenme tetiği hızlı çalışacak şekilde ayarlansın; yeni instance'ların ısınma süresini hesaba katın.
• Veritabanı yük devrinden sonra yeni birincil üzerinde bağlantı sayısı ve bellek yeterli mi, kontrol edin.

Maliyet tarafı da gerçektir. AZ'ler arasında taşınan veri için ücret oluşabilir, ek instance'lar ve ek veritabanı kopyası maliyet getirir. Güncel fiyatlar AWS fiyatlandırma sayfalarında yayımlanır. Önemli olan her uygulamaya aynı dayanıklılığı sunmak değil, iş etkisine göre karar vermektir; geliştirme ortamı tek AZ'de çalışabilir, ödeme akışı çalışmamalıdır.

Dayanıklılığı sınamak: kesintiyi önceden yaşamak

Multi-AZ yapılandırması kâğıt üstünde doğru olabilir ama gerçekten çalıştığını yalnızca deneyerek görürsünüz. Basit bir deneme planı:

• Test ortamında bir uygulama instance'ını sonlandırın. Auto Scaling'in yenisini açıp yük dengeleyiciye kaydettiğini doğrulayın.
• Bir AZ'deki tüm hedefleri geçici olarak sağlıksız hale getirin ya da bir AZ'nin alt ağını yük dengeleyiciden çıkarın. Uygulamanın kalan AZ'lerden istek almaya devam ettiğini gözleyin.
• RDS'te kontrollü yük devri başlatın. Uygulamanın bağlantıyı yeniden kurma süresini ve kayıp isteğin olup olmadığını ölçün.
• Sonuçları kaydedin: ne kadar sürdü, hangi alarm çaldı, hangi insan müdahalesi gerekti.

Üretimde aynı denemeleri yapmadan önce yetkili onay ve geri dönüş planı gerekir. AWS Fault Injection Service gibi araçlar bu tür deneyleri kontrollü yürütmeye yardım eder; ilk denemeleri her zaman test ortamında yapın.

Uygulama tarafında sağlam yük devri davranışı da gerekir: bağlantı kopunca yeniden deneme, istekler için zaman aşımı, tekrar çalıştırılabilir (idempotent) işlemler. Altyapı dayanıklı olsa da kodu dayanıklı değilse kullanıcı hata görür.

Sık yapılan hatalar

• Yük dengeleyiciyi tek bir AZ'ye yerleştirmek, Auto Scaling grubunu ise birden çok AZ'ye yaymak ya da tersi. Zincir en zayıf halka kadar dayanıklıdır.
• Veritabanını Multi-AZ yapıp uygulamayı doğrudan birincil instance'ın adıyla bağlamak. Uç nokta adı kullanılmalıdır.
• Tek NAT gateway kullanıp o AZ'yi kaybedince tüm özel alt ağların çıkışını kaybetmek.
• EBS diskine bağımlı durum tutan tek sunucuyu "Multi-AZ" saymak. Disk bir AZ'ye bağlıdır.
• Sağlık kontrolünü yalnızca makinenin ayakta olduğunu değil, uygulamanın çalıştığını ölçecek şekilde kurmamak.
• Kapasite boşluğunu hesaplamamak ve AZ kaybında kalan sunucuların boğulmasına izin vermek.
• Yük devrini hiç denememek.

Kısacası Multi-AZ, bir ayar değil, bir tasarım disiplinidir. Her bileşen için "bu hangi AZ'de, o AZ kaybolursa ne olur" sorusunu sormak, tasarım incelemelerinin en verimli sorularından biridir.

Mindset programlarında bu beceri nerede çalışılır?

AWS Solutions Architect Associate Hazırlık programının Yüksek Erişilebilirlik ve Felaket Kurtarma modülü, bu sayfadaki katmanlı düşünmeyi sınav senaryolarıyla çalıştırır; Hesaplama Mimarisi ve Ölçeklendirme ile Veritabanı ve Önbellekleme Mimarisi modülleri ise uygulama ve veri katmanının tarafını destekler. Mimari tasarım inceleme toplantılarına katılan altyapı, yazılım ve DevOps rolleri için uygun bir çerçevedir. Ekip içinde ortak "hata alanı" diliyle çalışmayı kolaylaştırır.