AWS’te Felaket Kurtarma (DR) Mimarisi, Bölüm I: Bulutta Kurtarma Stratejileri

Orijinal makale: Link (Seth Eliot)

AWS Well-Architected Dayanıklılık dikeyi üzerine calışan bir çözüm mimarı olarak, müşterilerin AWS’te sağlam iş yükleri oluşturmalarına yardımcı oluyorum. Bu sayede, karşılaşabilecekleri en büyük zorluklardan biri olan afet benzeri olaylara hazırlıklı olmalarına yardım ediyorum. Bu tür olaylar arasında deprem veya sel gibi doğal afetleri, güç veya ağ kaybı gibi teknik arızalar, ve yanlışlıkla veya yetkisiz değişiklikler gibi insan eylemleri gibi durumlar sayılabilir. Nihayetinde, bir iş yükünün veya sistemin bulunduğu ana konumda işini yerine getirilmesini engelleyen herhangi bir olay bir felaket olarak sınıflandırılmaktadır. Bu blog yazısı, bir felakete hazırlanma ve bir felaketten kurtulma süreci olan Felaket Kurtarma (Disaster Recovery – DR) için nasıl bir mimari oluşturabileceğinden bahsedecek. DR, İş Sürekliliği Planınızın çok önemli bir parçasıdır.

DR hedefleri

Bir felaket olayı iş yükünüzü potansiyel olarak durdurabileceğinden dolayı, DR’da hedefiniz iş yükünüzü tekrar çalışır duruma getirmek ya da kesintiden tümüyle kaçınmak olmalıdır. Aşağıdaki hedef tanımlarını kullanıyoruz:

• Kurtarma süresi hedefi (Recovery Time objective – RTO): Servisin kesintiye uğraması ile servisin yeniden çalışır duruma gelmesi arasında geçen kabul edilebilir maksimum gecikme zamanı. Servis kesintisi ile ilgili, kabul edilebilir olan süreyi tanımlar.
• Kurtarma noktası hedefi (Recovery Point Objective – RPO): Son veri kurtarma noktasından bu yana kabul edilebilir maksimum süre. Bu süre, neyin kabul edilebilir bir veri kaybı olarak kabul edildiğini tanımlar.

RTO ve RPO için, daha düşük değerler daha az kesinti ve veri kaybını temsil eder. Bununla birlikte, daha düşük RTO ve RPO, kaynak kullanımı ve operasyonel karmaşıklık açısından daha pahalıya mal olur. Bu nedenle, iş yükünüz için en uygun değeri sağlayan RTO ve RPO hedeflerini belirlemelisiniz.

Bir felaket olayındaki etkinin kapsamı

Çoklu-AZ stratejisi

Her AWS Bölgesi birden çok Erişilebilirlik Alanından (Availability Zone – AZ) oluşur. Her AZ, ayrı ve farklı bir coğrafi konumda bulunan bir veya daha fazla veri merkezinden oluşur. Bu yapı, birden fazla AZ’yi etkileyen tekil olaylar haricindeki olaylardaki etki riskini önemli ölçüde azaltır. Bu nedenle, elektrik kesintileri, sel baskınları ve diğer yerel kesintiler gibi olaylara dayanacak bir DR stratejisi tasarlıyorsanız, bir AWS Bölgesi’nde Multi-AZ DR stratejisi kullanmak ihtiyacınız olan korumayı sağlayabilir.

Çok Bölgeli strateji

AWS, iş yükünüz için Çok Bölgeli bir yaklaşımı oluşturmak için bir çok kaynak sağlar. Bu yapı da, ayrı ve farklı konumlarda birden fazla veri merkezini etkileyebilecek kapsamdaki olaylara karşı güvence sağlar. Bu blog yazısındaki verdiğimiz bir çok örnekte, DR stratejilerini göstermek için Çok Bölgeli bir yaklaşım kullanıyoruz. Yine de bu örnekleri, Multi-AZ stratejileri veya hibrit (şirket içi iş yükü / bulut kurtarma) stratejileri için de kullanabilirsiniz.

DR stratejileri

AWS, iş gereksinimlerinizi karşılayan bir DR stratejisi oluşturmak için çeşitli kaynaklar ve servisler sunar.

Şekil 2, DR teknik raporunda vurgulanan, DR için dört stratejiyi göstermektedir. Soldan sağa, grafik, DR stratejilerinin nasıl farklı RTO ve RPO değerlerine ulaşabileceğini gösteriyor.

En iyi stratejiyi belirlemek için, mühendislik/BT ekipleri tarafından verilen bilgileri kullanarak, iş yükünün sahibi ile birlikte, faydaları ve riskleri analiz etmelisiniz. İş yükünüz için hangi RTO ve RPO’ya ihtiyaç duyulduğunu, ve nasıl bir para yatırımı, zaman, ve çaba harcamak istediğinizi belirlemelisiniz.

Aktif/pasif ve aktif/aktif DR stratejileri

Şekil 2’de DR stratejilerini aktif/pasif veya aktif/aktif olarak sınıflandırıyoruz. Şekil 3’te ise, aktif/pasifin nasıl çalıştığını gösteriyoruz. İş yükü tek bir sitede (bu durumda bir AWS Bölgesi) çalışıyor ve tüm talepler aktif olan Bölgeden cevaplanıyor. Bir felaket olayı meydana gelirse ve etkin Bölge iş yükü işlemlerini destekleyemezse, pasif Bölge, kurtarma sitesi (kurtarma Bölgesi) olur. Daha sonra da iş yükümüzün oradan çalışabilmesi için bazı adımlar atıyoruz. Tüm istekler artık “yük devretme” adı verilen bir süreç ile yeni siteye yönlendirilmek üzere değiştirilir. Daha sıkı RTO/RPO hedefleri için de veriler canlı tutulur ve altyapı yük devretmeden önce kurtarma sitesinde tamamen veya kısmen devreye girer. Verilerin yedeklemeden geri yüklenmesi gerekiyorsa, bu durum kurtarma noktasını (ve veri kaybını) artırabilir. Altyapı, canlı trafiği kabul etmeden önce ek işlemler yapılmasını da gerektiriyorsa, yine bu durum kurtarma süresini artırabilir. İş ile ilgili hedeflere ulaşılabildiği sürece, RTO ve RPO’daki bu tür artışlar sorun olmayacaktır.

Şekil 4, iki veya daha fazla Bölgenin aktif olarak istekleri karşıladığı ve Bölgeler arasında verilerin çoklandığı aktif/aktif bir stratejiyi göstermektedir. Bir Bölge bir felaket olayına maruz kaldığında, yük devretme, söz konusu Bölge trafiğinin kalan etkin Bölgeye veya Bölgelere yönlendirildiği anlamına gelir. Veriler Bölgeler arasında çoklanmış olsa da, yine de DR’ın bir parçası olarak verileri yedeklememiz gerekir, çünkü “insan eylemi” ya da teknik yazılım türü felaketlere karşı da önlem almak gerekecektir. Böyle bir felaket silinmiş veya bozulmuş verilerle sonuçlanırsa, yedeklemeden bilinen en son kararlı duruma kadarki zamana döneceğimiz bir kurtarma operasyonunda bu yedeklerin kullanılması gerekir.

DR stratejilerinin mimarisi

Her DR stratejisi gelecekteki blog yazılarımızda daha da detaylandırılacak; yine de aşağıdaki bölümlerde her bir stratejiyi kısaca özetleyelim.

Yedekleme ve geri yükleme

Şekil 5, çeşitli AWS veri kaynaklarının yedeklerini göstermektedir. Yedeklemeler, kaynakla aynı Bölgede oluşturulur ve sonra başka bir Bölgeye kopyalanır. Bu size herhangi bir etki kapsamındaki felaketlerden en etkili korumayı sağlar. Bölge “yük devretme” için, yedeklemeden veri kurtarmaya ek olarak, kurtarma Bölgesi’nde altyapınızı yeniden geri yükleyebilmeniz de gerekir. AWS CloudFormation veya AWS Cloud Development Kit (AWS CDK) gibi Kod ile altyapı oluşturma ortamları, Bölgeler arasında tutarlı bir altyapı oluşturabilmenize olanak tanır.

Yedekleme ve kurtarma stratejisi RTO için en az verimli strateji olarak kabul edilir. Ancak Amazon EventBridge gibi AWS kaynaklarını, sunucusuz otomasyon oluşturmak için kullanabilirsiniz. Bu tarz yaklaşımlar, algılama ve kurtarmayı iyileştirerek RTO’yu azaltacaktır. Bu konu ilerideki diğer bir blog yazımızda daha ayrıntılı olarak ele alınacak.

Pilot light

Pilot light stratejisi ile veriler canlı ve güncel, ancak servisler boşta duruyor. Bu yapı, canlı veriler, veri depoları ve veritabanlarının aktif Bölge’de güncel olduğu anlamına gelir (veya neredeyse güncel) ve okuma işlemleri için hizmete hazır durumdadır. Şekil 6’da, Amazon Aurora global veritabanı, verileri kurtarma Bölgesi’ndeki yerel bir sadece okunabilen veritabanına çoklar. Ancak tüm DR stratejilerinde olduğu gibi, yedeklemeler (Şekil 6’daki Aurora DB anlık görüntüsü gibi) de gerekli. Verilerinizi silen veya bozan felaket olayları durumunda yedeklemeler, bilinen son kararlı duruma “geri sarmanıza” izin verir.

Pilot light stratejisinde, Şekil 6’daki Elastic Load Balancing ve Amazon EC2 Auto Scaling gibi temel altyapı öğeleri mevcuttur. Ancak işlevsel unsurlar (sunucular gibi) “kapalı”dır. Bulutta, bir Amazon EC2 bulut sunucusunu kapatmanın en iyi yolu onu kurulu bırakmak da değildir; Şekil 6, hiçbir bulut sunucusu kurulmadığını gösteriyor. Bu bulut sunucularını “açmak” için önceden oluşturulmuş ve tüm Bölgelere kopyalanmış bir Amazon Machine Image (AMI) kullanıyoruz. Bu AMI, tam olarak ihtiyacımız olan işletim sistemi ve paketlerle Amazon EC2 bulut sunucuları oluşturur. Tetiklenene kadar evinizi ısıtamayan bir fırındaki pilot light gibi, bir pilot light stratejisi, kalan altyapıyı oluşturmak için tetiklenene kadar talepleri işleme alamayacaktır.

Warm standby

Pilot light stratejisi gibi, warm standby stratejisi de periyodik yedeklemelere ek olarak canlı verileri korur. İkisi arasındaki fark altyapı ve üzerinde çalışan koddur. Sıcak olarak bekleme, talepleri karşılayabilecek minimum bir kurulumdur, ancak daha düşük bir kapasitede – canlı sistem düzeyinde trafiği kaldıramaz. Bu yapı, her katmanda kurulu bir Amazon EC2 bulut sunucusu olarak Şekil 7’de görülebilir. Bu durum, warm standby’ı test etmeyi de kolaylaştırır, çünkü pasifteki bağlantı noktasının, siz göndermeden önce herhangi bir test işlemini gerçekleştirmesi için ek bir çalışma gerekmez. “Yük devretme”den önce, altyapının canlı sistem ihtiyaçlarını karşılayacak şekilde ölçeklendirilmesi de gerekir.

Çok siteli aktif/aktif

Çok siteli aktif/aktif mimari, iki veya daha fazla Bölge’den aktif olarak istekleri kabul eder. Yük devretme, isteklerin kendilerine hizmet edemeyen bir Bölgeden diğerine doğru yeniden yönlendirilmesi ile olur. Burada veriler Bölgeler arasında çoğaltılır ve bu Bölgelerde okuma istekleri sunmak için aktif olarak kullanılır. Yazma istekleri için, ana Bölgeye yazma veya yazıları belirli Bölgelere yeniden yönlendirmeyi içeren çeşitli kalıplar da kullanabilirsiniz. Bu konu, yine ilerideki bir blog yazısında ayrıntılı olarak tartışılacaktır. Yine DR için her zaman olduğu gibi, yanlışlıkla silme veya bozulmayı düzeltmek için geri yüklenmesi gerektiği için veriler de ayrıca yedeklenir. Şekil 8, veritabanı katmanı olarak kullanılan Amazon DynamoDB global tablolarını gösteriyor. Bu, çok siteli aktif/aktif için mükemmel bir seçim, çünkü herhangi bir Bölgedeki bir tablo yazılabilir ve veriler genellikle bir saniye içinde diğer tüm Bölgelere yayılır.

Sonuç

Felaket olayları, iş yükünüzün erişilebilirliği için tehdit oluştursa da, AWS Cloud servislerini kullanarak bu tehditleri azaltabilir ya da ortadan kaldırabilirsiniz. Öncelikle iş yükünüz için uygun gereksinimleri anlayarak, uygun bir DR stratejisi seçmelisiniz. Ardından, AWS servislerini kullanarak işletmenizin ihtiyaç duyduğu kurtarma süresi ve kurtarma noktası hedeflerine ulaşan bir mimari tasarlamalısınız.

İlgili bilgiler

• Bulut teknik raporunda felaket kurtarma seçenekleri