AWS'de felaket kurtarma stratejisi nasıl seçilir: dört modelin karar rehberi

Strateji seçmeden önce: felaket neyi ifade ediyor?

Felaket kurtarma planının ilk sorusu hangi felaketten korunduğunuzdur. AWS'nin felaket kurtarma teknik belgesi bu ayrımı net yapar: iyi tasarlanmış, yüksek erişilebilir bir iş yükünde tek bir fiziksel veri merkezinin kaybı için çoğu zaman yedekten geri yükleme yaklaşımı yeterli olabilir. Felaket tanımınız bir bölgenin (Region) tamamının kesilmesini kapsıyorsa ya da mevzuat bunu gerektiriyorsa pilot light, warm standby veya multi-site active/active gibi daha güçlü modeller gündeme gelir.

İkinci soru, iş tarafının tolerans sınırlarıdır. RTO (kurtarma süresi hedefi) hizmetin ne kadar süreyle kapalı kalabileceğini, RPO (kurtarma noktası hedefi) ne kadar veri kaybının kabul edilebileceğini ifade eder. Bu hedefler teknik ekibin değil, iş sahibinin kararıdır; teknik ekip ise hangi mimarinin hangi hedefi karşıladığını ve maliyetini gösterir. Hedefler belirlenmeden strateji seçmek, "en pahalı olan en güvenlidir" yanılgısına düşmeyi kolaylaştırır.

Üçüncü olarak veri felaketini ayırmak gerekir. Sürekli çoğaltma, silinen ya da bozulan verinin de karşı bölgeye hızla taşınmasına yol açabilir. Bu yüzden hangi strateji seçilirse seçilsin, belirli ana dönebilen yedekler (point-in-time) ayrıca tutulmalıdır.

Dört modelin karşılaştırması

AWS'nin sınıflandırması dört yaklaşımı düşük maliyet ve düşük karmaşıklıktan, çok bölgeli aktif yapılara doğru sıralar. Ölçüt bazında özetleyelim.

Backup and restore: Veriyi düzenli olarak (ve gerekirse başka bir bölgeye) yedeklersiniz; felaket anında altyapıyı, yapılandırmayı ve uygulama kodunu hedef bölgede yeniden kurup veriyi geri yüklersiniz. Maliyeti en düşük, kurtarma süresi en uzun seçenektir. Altyapıyı kodla tanımlamak (örneğin CloudFormation ya da CDK) bu yaklaşımın kritik ön koşuludur; aksi halde yeniden kurulum yavaşlar ve RTO aşılabilir.

Pilot light: Veri başka bölgeye sürekli çoğaltılır ve çekirdek altyapı hazır tutulur. Veritabanı ve nesne depolama gibi parçalar sürekli açıktır, uygulama sunucuları ise kodla yüklenmiş ama kapalı durumdadır. Felaket anında sunucular açılır ve ölçeklenir. Adını, gaz sobasında yanık tutulan küçük alevden alır.

Warm standby: Üretim ortamının küçültülmüş ama tam işlevsel bir kopyası diğer bölgede sürekli çalışır. Kapasite artırmak dışında yapılacak iş yoktur, bu yüzden kurtarma pilot light'tan hızlıdır ve sürekli test etmek kolaydır.

Multi-site active/active: İş yükü birden çok bölgede aynı anda çalışır ve trafik hepsinden karşılanır. Bölge kaybında yük devri kavramı kalmaz, kurtarma süresi çoğu felaket için sıfıra yakındır. En karmaşık ve en pahalı seçenektir. Veri bozulması gibi durumlarda ise yine yedeklere dönmek gerekebilir.

Pilot light ile warm standby arasındaki asıl fark

İkisi karıştırılır çünkü her ikisinde de hedef bölgede kopya varlıklar bulunur. AWS belgesindeki ayrım şudur: pilot light ek bir işlem yapılmadan istek karşılayamaz; sunucuların açılması, gerekirse çekirdek olmayan altyapının kurulması ve ölçeklenmesi gerekir. Warm standby ise azaltılmış kapasiteyle de olsa anında trafik alabilir; yalnızca ölçeği büyütmek yeter.

Bu fark seçime şöyle yansır:

• RTO sıkıysa ve bütçe izin veriyorsa warm standby, çünkü ortam zaten çalışıyor ve düzenli olarak gerçek trafikle denenebiliyor.
• Maliyet öncelikliyse ve bir miktar daha uzun kurtarma kabul edilebiliyorsa pilot light.
• Her ikisinde de veri çoğaltması aynı hassasiyetle işletilmelidir; RPO kopyanın ne kadar geriden geldiğine bağlıdır.

Örneğin bir sipariş yönetimi uygulamasında veritabanı karşı bölgede sürekli çoğaltılıyor, uygulama sunucuları ise kapalıysa bu pilot light'tır. Aynı uygulamanın karşı bölgede birkaç küçük sunucuyla sürekli çalışıp felaket anında Auto Scaling grubunun istenen kapasitesinin yükseltilmesi ise warm standby'dır. AWS ayrıca tüm kapasiteyi sürekli hazır tutan ama trafiği tek bölgeden alan yapıyı hot standby olarak adlandırır.

Veri katmanı ve trafik yönlendirme nasıl kurulur?

Veri çoğaltma seçenekleri servise göre değişir. Amazon S3 için bölgeler arası çoğaltma, Aurora için global database, DynamoDB için global tables, RDS için bölgeler arası okuma kopyaları kullanılabilir. AWS belgesine göre Aurora global database, ikincil bölgeyi kesinti halinde yazma yetkisiyle terfi ettirmeyi ve çoğaltma gecikmesini RPO hedefine göre izlemeyi sağlar. Nesne sürümleme ve AWS Backup ile bölgeler ve hesaplar arası yedek kopyaları da ayrıca korumayı güçlendirir.

Trafik yönlendirmede başlıca araçlar şunlardır. Amazon Route 53, sağlık kontrollerine dayalı otomatik DNS yük devri sunar. Elle başlatılan yük devri için Application Recovery Controller (ARC), bir anahtar gibi çalışan sağlık kontrolleriyle yedek bölgeye geçişi betikle tetiklemeyi mümkün kılar. AWS Global Accelerator ise sabit IP adresleriyle birden çok bölgedeki uç noktalara yönlendirme yapar ve DNS önbelleği sorunlarından etkilenmez.

Önemli bir tasarım ilkesi, felaket anında denetim düzlemine (control plane) değil, veri düzlemine (data plane) güvenmektir. AWS'ye göre veri düzlemleri daha yüksek erişilebilirlik hedefiyle tasarlanır. Örneğin ağırlıklı yönlendirmeyi elle değiştirmek denetim düzlemi işlemidir ve bu yüzden daha az dayanıklıdır. Otomatik yük devri yanlış alarmda gereksiz kesinti yaratabilir; bu nedenle birçok ekip yük devrini otomatikleştirip başlatmayı elle yapar.

Karar ölçütleri: pratik bir eleme sırası

Stratejiyi seçerken şu sırayı izleyin:

• İş etki analizinden her sistem için RTO ve RPO değerlerini alın. Değer yoksa önce o çalışmayı yapın.
• Sistemleri kritikliğine göre sınıflayın. Her sistem için aynı stratejiyi seçmek hem pahalı hem gereksizdir. Dahili raporlama aracı için yedekten geri yükleme yetebilir, ödeme akışı için warm standby düşünülebilir.
• Bağımlılıkları çıkarın. Uygulama güvendiği başka hizmet geri gelmeden açılamaz; kimlik doğrulama, DNS ve ortak veritabanları zincirin zayıf halkasıdır.
• Maliyeti hesaplayın: sürekli çalışan kaynaklar, veri aktarımı ve çoğaltma, birden çok ortamın bakımı. Güncel fiyatlar için AWS fiyatlandırma sayfalarına bakın.
• Operasyonel yükü değerlendirin: birden çok bölgeye aynı değişikliği dağıtmak, sürüm uyumunu korumak ve yetkileri ayrı hesaplarla yönetmek ekip yetkinliği ister. AWS, en yüksek yalıtım için bölge başına ayrı hesap kullanmayı önerir.
• Bir strateji seçtiğinizde test planını da tanımlayın.

Planlanmamış stratejiler kâğıt üstünde kalır. Düzenli tatbikat, yük devri adımlarının otomasyon kalitesini ve sürenin hedefi karşılayıp karşılamadığını gösterir. AWS Resilience Hub gibi araçlar, iş yükünün hedeflere uygunluğunu sürekli doğrulamaya yardımcı olabilir.

Sık yapılan hatalar

• Yedek almak ama geri yüklemeyi denememek. Geri yükleme bir denetim düzlemi işlemidir; düzenli otomatik geri yüklemeyle çalışır durumda bir veri deposu tutmak güvenlik sağlar.
• Hedef bölgede hizmet kotalarını yükseltmemek. Ölçeklenmek istediğiniz anda kota sınırına çarparsınız.
• Altyapıyı elle kurmak. Kodla tanımlanmamış ortam, bölgeler arasında sapar.
• Yalnızca sunucuyu düşünüp bağımlılıkları (DNS kayıtları, sertifikalar, gizli bilgiler, IAM rolleri) unutmak.
• Sürekli çoğaltmanın bozuk veriyi de taşıdığını unutmak.
• Felaket kurtarmayı yalnızca teknik bir iş sanmak. İletişim planı, karar yetkisi ve kimin yük devrini onaylayacağı da planın parçasıdır.

Bu başlıklar süreklilik planı çalışmalarında BCP ve DR disipliniyle birleşir. Mindset'in BCP / DR Planlama programı İş Etki Analizi ve RTO/RPO Tanımlama, Tatbikat Tasarımı ve Test Süreçleri, Kriz İletişimi ve Olay Komuta Yapısı gibi modüllerle bu çerçeveyi sağlar; AWS Solutions Architect Associate Hazırlık programının Yüksek Erişilebilirlik ve Felaket Kurtarma modülü ise aynı konunun AWS mimarisi tarafını ele alır.