AWS Cloud ile BT Dayanıklılığı, Bölüm II: Mimari ve Şablonlar

Orijinal makale: Link (Randy DeFauw, Amine Chigani ve Nigel Harris)

İki bölümden oluşan yazının 1. bölümünde hibrit “şirket içi veri merkezleri (on-premises) / bulut” ortamlarında dayanıklı uygulamalar oluştururken dikkate alınacak en iyi pratikleri özetledik. Ayrıca düşünce yapılarını ve organizasyonel kültürü nasıl uyarlayacağınızı da aktarmaya çalıştık. Bölüm 2’de ise AWS Cloud’da dayanıklılık için mimari ve şablonlar ile ilgili teknik konulardan bahsedeceğiz.

Mimari ve şablonlar ile ilgili hususlar

AWS Well-Architected Framework dayanıklılığı, “yük (servise gelen istek sayısında artış), saldırılar (yanlışlıkla yapılan bir hata sebebiyle veya kasıtlı olarak yapılan) ve iş yükü bileşenlerindeki herhangi bir bileşenin arızası ile kırılganlığa sebep olan bir durumla karşılaştığında iyileşme yeteneğine sahip olmak” olarak tarifler. Dayanıklılık, diğer mimari özelliklere oldukça bağlı olan kapsamlı bir mimari özelliktir. Yönetici geliştiricilerin dayanıklılık stratejilerini kullanılabilirlik, performans ve felaket kurtarma konularının merkezine almaları özellikle önerilir. Şimdi bu yetkinliği sağlayan mimari şablonları inceleyelim.

1. Esneklik mimarinizi yeniden uyarlayın

Şirket içi veri merkezlerinde dayanıklılık için yapılan planlama, sunucu (compute) kaynaklarının fiziksel konumuna sıkı bir şekilde bağlıdır. Şirket içi veri merkezlerinde sağlanan dayanıklılık genellikle iki farklı veri merkezi kullanılarak elde edilir (Şekil 1).

Şekil 1. Şirket içi veri merkezi dayanıklılık stratejileri için iki ayrı veri merkezi modeli

Yönetici geliştiricilerin endişelerine dayanarak ortamlarının dayanıklılığını iyileştirmek için ele almaya çalıştıkları Şekil 1’deki modeli inceleyelim:

Performans: Ağır yük altında gecikme ve/veya performans sorunlarını çözmek için duyulan endişeler.
Kullanılabilirlik: Yüksek kullanılabilirlik (High Availability – HA) ve Felaket Kurtarma (Disaster Recovery – DR) sorunlarını çözmek için duyulan endişeler.

Şimdi bu endişeleri AWS Cloud’da nasıl ele alabileceğimizi aktarmaya başlayalım. İlk olarak AWS Well-Architected Framework, kullanılabilirlik ve performans konusunda size yardımcı olan önemli mimari prensiplerini ve ilgili servisleri kapsar. İkinci olarak çeşitli dağıtım (deployment) modelleri sayesinde dayanıklılığınızı artırmak için AWS global altyapısını kullanabilirsiniz.

AWS altyapısı dayanıklılığı sağlar

AWS dünya çapında her biri birden çok Erişilebilirlik Alanı‘ndan (Availability Zone – AZ) oluşan 25 Bölge’de (Region) hizmet verir. Her AZ’nin fazladan (redundant) kaynakları vardır ve her bir AZ, diğer AZ’lerden izole olacak şekilde anlamlı bir mesafede bulunan ayrı fiziksel tesisler kullanır. AWS ayrıca AWS Local Zones, AWS Wavelength Zones, AWS Outposts ve 275’ten fazla varlık noktası (Points of Presence – PoP) dahil olmak üzere kaynakları son kullanıcılara yaklaştırmak için farklı mekanizmalar sunar. AWS Direct Connect ve yönetilen VPN hizmetleri, AWS ağı ile şirketlerin kendi ağları arasında bağlantılar sağlar (Şekil 2).

Şekil 2: AWS Global Altyapısı

AWS servisleri ile performans

Gecikmeyi azaltmak için en sık kullanılan AWS servisleri Amazon CloudFront ve Amazon API Gateway‘dir. Bu servisler, varlık noktalarında (PoP’lerde) statik ve dinamik içeriği ve API cevaplarını önbelleğe (cache) alır.

Kullanılabilirlik ve felaket kurtarma

Kullanılabilirlik, hedef ve beklentilerinizi değerlendirmeyi ve ayrıca olasılık, etki ve maliyeti düşürme gibi konularda bir risk analizi yapmayı gerektirir (Şekil 3). Bir DR hedefini şirket içi veri merkezi yapılarında olduğu gibi birebir olarak “iki AWS bölgesine dağıtma (deployment)” olarak düşünmeyin. Örneğin DR’yi “fiziksel bir tesisin kaybına dayanabilecek” olarak tanımlarsanız, tek bir AWS Bölgesi’nde birden fazla AZ kullanarak bu hedefi karşılayabilirsiniz. Amazon Simple Storage Service (Amazon S3) gibi bölgesel servislerin yanı sıra Multi-AZ dağıtımları, iki veri merkezinin sunduğundan daha fazla kullanılabilirlik sağlar.

Şekil 3. Altyapı dayanıklılığı için risk sınıflandırma matrisi

2. İş yüklerini kullanılabilirlik katmanlarına göre sınıflandırın

Şirket içi veri merkezini buluta taşıdığınızda, buluttaki BT varlıkları için tek bir Kurtarma Süresi Hedefi (Recovery Time Objective – RTO) ve Kurtarma Noktası Hedefi (Recovery Point Objective – RPO) uygulamayın. Bunun yerine Şekil 4’teki dört katmanlı sınıflandırma modelini kullanarak iş yüklerinizi sınıflandırın ve iş kritikliği için gerekli RTO / RPO ihtiyaçlarını kullanarak strateji geliştirin.

Şekil 4: Dayanıklılık Sınıflandırma Matrisi

3. Çok Bölgeli (Multi-Region) felaket kurtarma şablonları 
İş yüklerinizi sınıflandırdıktan sonra çok bölgeli bir yapıya ihtiyacınız varsa uygun bir DR şablonu seçin. Veritabanı ve Amazon S3 replikasyonu gibi yedekleme çözümleri en fazla birkaç dakikalık RPO sağlayabilir, ancak RTO önemli ölçüde değişecektir. Aşağıdaki bölümlerde gösterildiği gibi sık kullanılan 4 farklı çok bölgeli DR şablonu vardır.

Yedekleme ve geri yükleme (Seviye 4)

Kritik verileri başka bir AWS bölgesinde yedekleyin. DR senaryosunda, yedeklediğiniz verileri geri yükleyin ve uygulamalarınızı bu AWS bölgesinde ayağa kaldırın. Bu seçenek en düşük maliyetli yöntem olacaktır, ancak tam anlamıyla sistemlerin çalışır hale gelmesi birkaç saat sürebilir. Bu şablon yedekleme zamanlamalarına bağlı olarak daha fazla veri kaybına neden olabilir.

Pilot light (Seviye 2)

Veritabanı gibi temel bileşenleri Amazon S3 üzerinde replike ederek saklayın. Ölçekleri azaltılan uygulama sunucularını diğer AWS bölgesinde çalışır vaziyette tutun ve DR senaryosunda da bellek içi önbellek (in-memory cache) gibi diğer bileşenleri yükleyin. RTO yaklaşık olarak bir saat sürebilir; operasyon ekiplerinin problemi bulması ve çözmesi ile yeni altyapının tam anlamıyla çalışır hale gelmesi için zaman gerekecektir.

Warm standby (Seviye 3)

İkinci bir AWS bölgesinde uygulamaları (uygulama sunucuları, veritabanı gibi bileşenleriyle) küçültülmüş sistem konfigürasyonları ile çalıştırın. Felaket durumunda DR’ın bulunduğu AWS bölgesindeki kaynakları büyütün ve AWS bölgesine giden trafiği artırın. RTO yaklaşık olarak bir saat sürer; operasyon ekiplerinin problemi bulması ve çözmesi ile yeni altyapının tam anlamıyla çalışır hale gelmesi için zaman gerekecektir. Bu model hızlı yanıt vermesi gereken ancak hemen tam kapasiteye ihtiyaç duymayan uygulamalar için uygun bir şablondur.

Aktif – Aktif (Seviye 1)

Bu şablonda birden fazla AWS bölgesinde aktif olarak çalışan uygulamanızı gerçek boyutlarında ve konfigürasyonlarında çalıştırın. Uygulamaya gelen trafiği birden fazla AWS bölgesine yönlendirebilmek için DNS (Amazon Route 53) veya AWS Global Accelerator servislerini kullanabilirsiniz. Bu seçenek hatayı tespit etme ve DNS’i güncelleyerek trafiği yeniden yönlendirme süresine bağlı olarak muhtemelen saniyeler içinde en iyi RTO’yu sunacaktır. Maliyet diğer şablonlara göre daha yüksektir. Hazır bekleme yaklaşımında olduğu gibi minimum kapasitede çalıştırmanın maliyetinin yanı sıra, bu şablonda her AWS bölgesini ekstra kapasiteye sahip olacak şekilde ölçeklendirmek durumundasınızdır ki istenilen RTO değerlerine ulaşabilin.

4. Hepsini bir araya getirdiğimizde

Performans ve kullanılabilirlik için belirlediğiniz iş gereksinimlerinizi şirket içi veri merkezlerindeki eski altyapının kullandığı yöntemlerden farklılaştırdınız. Bir sonraki adım olarak son kullanıcılar için düşük gecikmeli erişim sağlayan Amazon CloudFront’u kullanmayı tercih edebilirsiniz. Bu yaklaşım kullanılabilirlik için “yedekleme ve geri yükleme” stratejisine sahip bir Multi-AZ mimarisini de içerebilir (Şekil 5).

Şekil 5: Performans ve dayanıklılık sağlayan AWS altyapısı

Kritik teknoloji alanlarına ilişkin hususlar

AWS, ihtiyacınız olan dayanıklılık düzeyinde bir mimari tasarlamanız için gereken araçları sağlar. Kurumsal mimarlarınız bu araçların nasıl uygulanacağına karar verirken üç kritik teknik alana odaklanmalıdırlar. Bu alanların her birini, medya endüstrisinde iş yapan AWS müşterisinin anekdotları ile aktarmaya çalışacağız.

1. Ağ and ağ trafiği yönetimi

Artık ikinci bir AWS bölgesinde DR yapısı kurduğunuza göre felaket senaryosu durumunda yük aktarımı yapmak için trafiği DR bölgesine nasıl yönlendirirsiniz? DR bölgesi müşterilerinizden uzaktaysa ekstra gecikmeyi nasıl önlersiniz?

AWS, sabit giriş noktaları ve bölgeler arasında trafik yönlendirmesi sağlayarak küresel yük dengeleyici olarak hizmet verebilen Route 53 ve Global Accelerator servislerini sunar.

Son kullanıcılar için gecikmeyi azaltmak için Global Accelerator veya CloudFront servislerini kullanabilirsiniz. Bu servisler müşteri trafiğini mümkün olan en kısa sürede AWS uç ağına taşıyacak ve açık internete kıyasla daha öngörülebilir bir gecikme sağlayacaktır.

Video akışı (video streming) müşterimiz, gelişmiş video akışı performansı ihtiyacını içerik dağıtımı için kullandığı CloudFront servisi ile sağlıyor. Ayrıca iki farklı bölgede çalıştırdığı mikroservislere son kullanıcı trafiğini yönlendirmek için de Global Accelerator servisini kullanıyor.

2. Veri depolama

Üç katmanlı bir web uygulamasında veritabanı katmanı, aktif-aktif bir senaryoda yönetilmesi en zor olan katmandır. İlişkisel veritabanları, fonksiyonel maliyeti de olan işlem tutarlılığını garantiler (yani ACID işlemleri): Bunu sağlamak için de çoğu ilişkisel veritabanı farklı kanallardan gelen yazma isteklerini tek bir yazma noktası aracılığıyla huni yöntemi uygulayarak yazmayı gerçekleştirir.

Tutarlılık gereksinimlerinizi gevşetip gevşetemeyeceğinizi veya veri depolama katmanınızdaki verileri nasıl parçalayabileceğinizi değerlendirmek gerekebilir. Amazon DynamoDB gibi global tablolara sahip NoSQL veritabanları birden çok bölgeye veri yazmanıza imkan sağlar. Bununla birlikte, çoğu NoSQL veritabanında kullanılabilirlik için optimize edebileceğiniz ayarlanabilir tutarlılık modelleri bulunur.

Video akışı müşterimiz, nihai okuma tutarlılığını (eventual read consistency) tolere edebileceklerini fark ettikleri için birden fazla bölgede çalıştırdığı mikroservisleri için DynamoDB global tablolarını kullanıyor.

3. İzleme ve operasyonel müdahale

Müşterilerinizin uygulamanıza erişirken olağandışı hata oranları veya gecikme görüp görmediklerini tespit edebiliyor musunuz? Bunun neden olduğunu ve bir felaket kurtarma senaryosu başlatmanız gerekip gerekmediğini biliyor musunuz?

Amazon CloudWatch ve AWS X-Ray gibi izleme ve gözlenebilirlik servisleri, uygulamanızın sağlık durumunu ve uygulamanıza gelen istek akışını görmenizi sağlar. Otomasyon araçları, müdahale senaryolarınızı (response runbook) otomatikleştirmenize yardımcı olur. Oyun günleri (Gameday) adı verilen, izleme ve müdahale planlarınızı uygulayıp test edebileceğiniz bir nevi tatbikat çalışmaları ile planlarınızın muhtemel sorunlarını ortaya çıkartabilirsiniz.

Video akışı müşterimiz, otomatik altyapı kurulum ve konfigürasyonu için AWS CloudFormation‘a, izleme için CloudWatch’a ve sistem performansının son kullanıcı görünümünü izlemek için CloudWatch Synthetics’e güveniyor.

Sonuç

Yönetici geliştiriciler, esnek bulut ortamlarını uygulamak ve çalıştırmak için ekiplerine nasıl liderlik edecekleri konusunda rehberliğe ihtiyaç duyar. Bu yazıda mimari ve şablonlar ile ilgili konuların yanı sıra odaklanılması gereken teknoloji alanlarının gözden geçirilmesi konusunda bilgi vermeye çalıştık.

İlgili yazı: AWS Cloud ile BT Dayanıklılığı, Bölüm I: Düşünce Yapısı ve Kültür