Durum Bilgili Hizmetler için Çoklu AZ Örüntüleri

Durum bilgili hizmetler — veritabanları, önbellekler ve dosya sistemleri — arızalardan sonra korunması gereken verileri tuttukları için yüksek kullanılabilirliğe sahip hâle getirilmesi en zor bileşenlerdir. Tek bir AZ'deki veritabanı arızalanırsa uygulamanız veri deposunun tamamını kaybeder. AWS'nin çözümü, birincil bileşen arızalandığında hızla devreye girebilen ikinci bir Kullanılabilirlik Alanında eş zamanlı veya eş zamana yakın bir çoğaltmayı hizmetin koruduğu Multi-AZ dağıtımlarıdır.

RDS Multi-AZ, farklı bir AZ'de eş zamanlı bir bekleme çoğaltması tutar. Birincil bileşene yapılan her yazma işlemi, başarı onaylanmadan önce eş zamanlı olarak çoğaltılır; bu, sıfır veri kaybı (RPO=0) anlamına gelir ancak yazma gecikmesini biraz artırır. Birincil bileşen arızalandığında RDS, 60-120 saniye içinde DNS uç noktasını bekleme örneğini gösterecek şekilde otomatik olarak günceller. Uygulamanızın yalnızca aynı uç noktaya yeniden bağlanması gerekir; kod değişikliği gerekmez.

Amazon Aurora, verileri üç AZ arasında altı kopya olarak otomatik şekilde çoğaltan paylaşımlı dağıtılmış depolama katmanı sayesinde Multi-AZ yaklaşımını daha ileri taşır. Aurora örnekleri durum bilgisi tutmaz; bu paylaşımlı depolamaya okuma ve yazma işlemleri gerçekleştirir. PRIMARY Aurora Writer başarısız olduğunda, başka bir AZ'deki Read Replica 30 saniyeden kısa sürede Writer olarak yükseltilir. Bu işlem, RDS Multi-AZ Failover işleminden daha hızlıdır ve açık bir Standby Replication yapılandırmasına gerek kalmadan veriler AZ'ler arasında her zaman tutarlı kalır.

ElastiCache for Redis, Replication grupları aracılığıyla Multi-AZ desteği sunar. Bir Primary düğümü yazma işlemlerini kabul eder ve verileri diğer AZ'lerdeki Read Replicas düğümlerine Asynchronous olarak çoğaltır. Primary başarısız olduğunda ElastiCache, bir Replica'yı otomatik olarak Primary konumuna yükseltir. Redis için küme modu etkin olduğunda veriler, her birinin AZ'ler arasında kendi Primary ve Replicas düğümleri bulunan birden çok düğüm grubuna bölünür; bu yapı hem HA hem de yatay ölçeklendirme sağlar.

Amazon Elastic File System (EFS) doğası gereği Multi-AZ'dir; bir bölge içinde birden çok AZ'ye verileri yedekli olarak depolayan bölgesel bir hizmettir. Her AZ'nin alt ağı içinde Mount hedefleri oluşturursunuz ve herhangi bir AZ'deki EC2 örnekleri, yerel Mount hedefleri üzerinden dosya sistemini bağlayabilir. Herhangi bir manuel Multi-AZ yapılandırması gerekmez. EFS, AZ'ler arasındaki birden çok örneğin eşzamanlı olarak erişebildiği paylaşımlı POSIX dosya depolaması sağlar.

Elastic yük dengeleyicileri de kendi başlarına Multi-AZ'dir; ALB ve NLB, belirttiğiniz her AZ'de yük dengeleyici düğümleri dağıtır. Bölgeler arası yük dengeleme etkin olduğunda (ALB için varsayılan ayar), her yük dengeleyici düğümü trafiği yalnızca kendi AZ'sindeki değil, tüm AZ'lerdeki kayıtlı hedefler arasında eşit şekilde dağıtır. Böylece bir AZ'deki tüm örnekler başarısız olsa bile yük dengeleyici, kalan AZ'lerdeki örnekler üzerinden trafik sunmaya devam eder.

Yaygın bir hata, bir AZ'de tek bir NAT Gateway dağıtıp diğer AZ'lerdeki özel alt ağların bu ağ geçidi üzerinden yönlendirilmesidir. Bu AZ başarısız olursa tüm özel örnekler internet erişimini kaybeder. Doğru Multi-AZ modeli, her AZ için bir NAT Gateway dağıtmak ve her AZ'nin özel yönlendirme tablosunu 0.0.0.0/0 trafiğini kendi NAT Gateway'i üzerinden yönlendirecek şekilde yapılandırmaktır. Bu yaklaşım, NAT Gateway'in AZ'ler arası bir SPOF olmasını önler ve AZ'ler arası veri aktarımı maliyetlerini azaltır.

DynamoDB, bir bölge içindeki üç AZ arasında verileri otomatik olarak çoğaltan, tamamen yönetilen bir hizmettir; Multi-AZ'yi manuel olarak yapılandırmazsınız. Başarılı yanıt döndürülmeden önce her yazma işlemi üç AZ'nin tamamında kalıcı olarak depolanır. DynamoDB, AZ düzeyindeki hatalara karşı kullanıma hazır şekilde etkin bir hata toleransına sahiptir. Sınav sorusu, düşük operasyonel yükle yüksek kullanılabilirliği vurguladığında DynamoDB'nin genellikle önerilen veritabanı seçimi olmasının nedeni budur.

Bir RDS Multi-AZ Failover işlemi sırasında kalıcı veritabanı bağlantılarını koruyan uygulamalar, Endpoint değiştiği için hatalarla karşılaşabilir. RDS Proxy, uygulamanız ile RDS arasında konumlanır ve veritabanına ait bir bağlantı havuzunu yönetir. Failover sırasında RDS Proxy, bağlantıları otomatik olarak yeni Primary'ye yönlendirir; böylece Proxy Endpoint'ini kullanan uygulamalarda Failover etkisi 60-120 saniyeden 30 saniyenin altına iner. RDS Proxy, çok sayıda kısa ömürlü bağlantı oluşturan Lambda işlevlerine de yardımcı olur.

Çoğaltma modlarını anlamak, Multi-AZ modellerini seçmek için kritik öneme sahiptir. Synchronous çoğaltma (RDS Multi-AZ, EFS), her yazma işleminin başarı onayından önce her iki AZ'de de doğrulanmasını sağlayarak RPO=0 sunar. Bunun karşılığında yazma gecikmesi biraz artar. Asynchronous çoğaltma (ElastiCache Redis Replicas, RDS Read Replicas) daha düşük yazma gecikmesi sağlar; ancak küçük bir çoğaltma gecikmesini kabul eder. Bu, çoğaltma tamamlanmadan önce Primary başarısız olursa bazı verilerin kaybolabileceği anlamına gelir.

RTO varsayımlarınızı doğrulamak için Multi-AZ Failover işlemini düzenli olarak test etmelisiniz. RDS için konsolun Failover ile yeniden başlat seçeneğini veya CLI'yi kullanarak bir Failover işlemi tetikleyebilirsiniz. FailedSQLServerAgentJobsCount metriği için CloudWatch'ı izleyin ve yeniden başarılı şekilde bağlandığını doğrulamak üzere uygulama günlüklerinizi kontrol edin. Gerçek Failover süresini belgeleyin; bu süre, örnek sınıfınıza ve iş yükünüze bağlı olarak AWS belgelerinde belirtilenden farklı olabilir.

Bu dersteki AWS Çözüm Mimarı (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Bu derste şunları öğrendiniz: RDS Multi-AZ, otomatik DNS Failover ile Synchronous çoğaltma kullanır, Aurora daha hızlı Failover için üç AZ arasında paylaşımlı bir depolama katmanı kullanır ve EFS ile DynamoDB, manuel yapılandırma olmadan doğası gereği Multi-AZ'dir. AZ'ler arası SPOF'ları önlemek için her AZ'ye bir NAT Gateway dağıtın. Sırada multi-region active-active ve active-passive modellerini inceleyeceğiz.