Bulutta verimli mimari oluşturmak için dayanıklılık modellerini ve ödünleşimleri anlayın

Orijinal makale: Link (Haresh Nandwani, Lewis Taylor ve Bonnie McClure)

Bu gönderi ilk olarak Haziran 2022’de yayınlandı ve şimdi, dayanıklılık modellerini bulutta verimli bir şekilde tasarlama hakkında daha fazla bilgi ile güncellendi.

Bulutta dayanıklılık için iş yükleri tasarlamak için genellikle iş yükleri için en uygun mimariye karar vermeden önce birden çok faktörü değerlendirmek gerekir.

Example Corp, değişen kritikliğe sahip birden çok uygulamaya sahiptir ve uygulamalarının her birinin dayanıklılık, karmaşıklık ve maliyet açısından farklı ihtiyaçları vardır. Dayanıklılık ve maliyet açısından iş yüklerini yapılandırmak için pek çok seçeneğe sahipler, ancak ihtiyaçlarına en uygun seçenek hangisi? Uygulamalarının ihtiyaçlarına en uygun modelleri seçerken nelere dikkat etmelidirler?

Bu soruları yanıtlamaya yardımcı olmak için, Şekil 1’deki beş dayanıklılık modelini ve bunları uygularken göz önünde bulundurulması gereken ödünleşimleri (trade-offs) tartışacağız: 1) tasarım karmaşıklığı, 2) uygulama maliyeti, 3) operasyonel çaba, 4) güvenliği sağlama çabası, ve 5) çevresel etki. Bu, çeşitli düzeylerde dayanıklılık elde etmenize ve ihtiyaçlarınıza en uygun mimari hakkında kararlar almanıza yardımcı olacaktır. Niyetimiz, bu modellerin her biri ile ilişkili ödünleşimler üzerine konuşmaları yapılandırmak için üst düzey bir yaklaşım sağlamaktır. Her kalıba ilişkin daha derin bir inceleme için lütfen bu yazının sonundaki Daha Fazla Okuma bölümüne gidin.

Not: Bu modeller birbirini dışlamaz; daha fazla modelden birinin kombinasyonunu uygulamaya karar verebilirsiniz.

Dayanıklılık nedir? Neden önemlidir?

AWS Well-Architected Framework, dayanıklılığı “yük (servis için daha fazla istek), saldırılar (bir hata nedeniyle kazara veya kasıtlı olarak) ve iş yükünün bileşenlerindeki herhangi bir bileşenin arızası nedeniyle baskılandığında iyileşme yeteneğine sahip olmak” olarak tanımlar.

İşletmenizin dayanıklılık gereksinimlerini karşılamak için iş yüklerinizi tasarlarken aşağıdaki temel faktörleri göz önünde bulundurun:

• Tasarım karmaşıklığı – Sistem karmaşıklığında bir artış tipik olarak o sistemin ortaya çıkan davranışlarını artırır. Her bir iş yükü bileşeninin dayanıklı olması gerekir ve insanlar, süreçler ve teknoloji ögeleri arasındaki tek nokta arızalarını ortadan kaldırmanız gerekir. Müşteriler dayanıklılık gereksinimlerini göz önünde bulundurmalı ve sistem karmaşıklığını artırmanın etkili bir yaklaşım mı yoksa sistemi basit tutmanın ve bir felaket kurtarma (DR) planı kullanmanın mı daha uygun olduğuna karar vermelidir.
• Uygulama maliyeti – Çalıştırılacak yeni yazılım ve altyapı bileşenleri olduğundan, daha yüksek dayanıklılık uyguladığınızda maliyetler genellikle önemli ölçüde artar. Bu tür maliyetlerin gelecekteki kayıpların potansiyel maliyetleriyle dengelenmesi önemlidir.
• Operasyonel çaba– Son derece dayanıklı sistemleri devreye almak ve desteklemek, karmaşık operasyonel süreçler ve gelişmiş teknik beceriler gerektirir. Örneğin, müşterilerin Operasyonel Hazırlık Gözden Geçirme (Operational Readiness Review – ORR) yaklaşımını kullanarak operasyonel süreçlerini iyileştirmeleri gerekebilir. Daha yüksek dayanıklılık uygulamaya karar vermeden önce, gerekli süreç olgunluğu ve beceri setlerine sahip olduğunuzu doğrulamak için operasyonel yetkinliğinizi değerlendirin.
• Güvenliği sağlama çabası – Güvenlik karmaşıklığı, dayanıklılık ile daha az doğrudan ilişkilidir. Bununla birlikte, yüksek oranda dayanıklı sistemler için genellikle güvence altına alınması gereken daha fazla bileşen vardır. Bulut devreye alımları için en iyi güvenlik uygulamalarını kullanmak, daha yüksek bir dağıtım ayak iziyle bile önemli bir karmaşıklık yaratmadan güvenlik hedeflerine ulaşabilir.
• Çevresel etki – Dayanıklı sistemler için artan dağıtım ayak izi, bulut kaynaklarının tüketimini artırabilir. Ancak, kaynak tüketimini azaltmak için yaklaşık bilgi işlem ve kasıtlı olarak daha yavaş yanıt süreleri uygulamak gibi ödünleşimleri kullanabilirsiniz. AWS Well-Architected Sustainability Pillar, bu kalıpları açıklar ve sürdürülebilirlik en iyi uygulamaları hakkında rehberlik sağlar.

Model 1 (M1): Multi-AZ

M1, sisteminizin dayanıklılığını artırmak için mimarinize Erişilebilirlik Alanları (AZ’ler) ekleyen bulut tabanlı bir mimari modelidir (Şekil 2). M1 modeli, uygulamaların tek bir AWS Bölgesi içinde birden fazla AZ’de çalıştığı bir Multi-AZ mimarisi kullanır. Bu, uygulamanızın Erişilebilirlik Alanlarında olan etkilere dayanmasını sağlar.

Şekil 2’de gösterildiği gibi, Example Corp, dahili çalışan uygulamalarını M1 modelini kullanarak dağıtır. Bu uygulamalar düşük iş etkisine sahiptir ve bu nedenle dayanıklılık için daha düşük gereksinimlere sahiptir.

Example Corp, düşük iş etkisine sahip uygulamalarını bir Otomatik Ölçeklendirme grubu (Auto Scaling group) tarafından yönetilen tek bir Amazon Elastic Compute Cloud (Amazon EC2) bulut sunucusu olarak dağıtır. Amazon EC2, hataları otomatik olarak algılamak için durum denetimlerini kullanır. Bir AZ başarısız olursa Amazon EC2, bir Amazon EC2 Auto Scaling grubundan uygulamalarını etkilenmemiş başka bir AZ’de yeniden oluşturmasını ister.

Ödünleşimler

M1, birkaç kategoride düşüktür ve uygulamayı barındıran AZ’deki kesintiyi azaltır, ancak bu, uygulamanın kurtarılması pahasına gelir. Bir AZ kapalıysa, yeni kaynaklar yeni bir AZ’de yeniden sağlanırken son kullanıcıların uygulamaya erişimini kesintiye uğratır. Bu, iki modlu davranış (bi-modal behavior) olarak bilinir.

Model 2 (M2): Statik kararlılığa sahip Multi-AZ

M2, dayanıklılığı artırmak için bir Bölge içindeki birden çok AZ’de birden çok sunucu kullanır. Model, iki modlu davranışı önlemek için statik kararlılık kullanır. Statik olarak kararlı sistemler, çalışma ortamlarındaki değişikliklerden bağımsız olarak kararlı kalır ve tek modda çalışır. AWS’te statik olarak kararlı bir sistemin önemli bir avantajı, önceden tedarik edilmiş kaynak kapasitesi sayesinde bir kesinti sırasında kurtarmanın karmaşıklığını azaltmasıdır. Bir AZ kaynak kaybı gibi bir kesinti sırasında operasyonları sürdürmek için gereken tüm kaynaklar zaten mevcuttur ve kurtarmanın başarılı olması için AWS hizmet kontrol düzlemlerinin kullanılabilir olması gerekmez. Statik kararlılık, veri düzlemleri ve kontrol düzlemleri hakkında daha fazla bilgi edinmek için Amazon Builder’s Library’deki Erişilebilirlik Alanlarının kullanıldığı statik kararlılık adlı makaleyi okuyun.

Şekil 3’te gösterildiği gibi, Example Corp, hizmet dışı kalma süresi için daha düşük toleransa sahip, müşteriye dönük bir web sitesine sahiptir. Web sitesi her kapatıldığında, gelir kaybına neden olabilir. Bu nedenle web sitesi, iki AZ’de sağlanan iki EC2 bulut sunucusu gerektirir. Sağlık kontrollerini kullanarak, AZ hizmet dışı kaldığında, Elastic Load Balancer trafiği etkilenen AZ’den uzaklaştırırken web sitesi çalışmaya devam eder. Durum denetimlerini kullanma hakkında daha fazla bilgi için Amazon Builder’s Library’deki Durum denetimlerini gerçekleştirme makalesine bakın.

Ödünleşimler

M2, uygulama istemcilerine kesinti süresi olmadan AZ kesintisini azaltır, ancak maliyet endişelerine karşı tartılmalıdır. M1, daha az bilgi işlem kapasitesi sağladığından ve bir arıza durumunda yeni bulut sunucularının başlatılmasına dayandığından, altyapı maliyeti açısından daha ucuzdur. Ancak M1’in iki modlu davranışı, büyük ölçekli etkinlikler sırasında müşterilerinizi etkileyebilir.

M2’yi uygulamak, uygulamanızın birden çok sunucuda dağıtılmış işlemi desteklemesini gerektirir. Uygulamanız bu modeli destekliyorsa, iş yükünüzü Bölge genelindeki tüm kullanılabilir AZ’lere (genellikle 3 veya daha fazla) dağıtabilirsiniz. İki AZ’deki %200’e kıyasla (önceki örneğimizde belirtildiği gibi) kapasitenizin yalnızca %150’sini üç AZ’de sağlamanız gerektiğinden, bu, fazla tedarikle ilişkili maliyetleri azaltacaktır.

Model 3 (M3): Uygulama portföyü dağılımı

M3, Şekil 4’te gösterildiği gibi işlevsel dayanıklılığı artırmak için bir Çoklu Bölge modeli kullanır. Farklı kritik uygulamaları birden çok Bölgeye dağıtır.

Example Corp, tüketicilere birden çok dijital kanalda kredi bakiyesi çekleri gibi bankacılık hizmetleri sağlar. Bu hizmetler tüketicilere mobil uygulama, iletişim merkezi ve web tabanlı uygulamalar aracılığıyla sunulmaktadır. Her bir dijital kanal, bölgesel bir hizmet kesintisini azaltan ayrı bir Bölgeye dağıtılır.

Örneğin, müşterilerin mobil uygulamasına sahip bir Bölgede, mobil uygulamanın kullanılamamasına neden olan bir kesinti olabilir, ancak müşteriler alternatif bir Bölgede konuşlandırılan çevrimiçi bankacılık yoluyla bankacılık hizmetlerine erişmeye devam edebilir. Bölgesel hizmet kesintileri nadirdir, ancak bunun gibi bir model uygulamak, kullanıcılarınızın kesintiler sırasında iş açısından kritik hizmetlere erişmeye devam etmelerini sağlar.

Ödünleşimler

M3, aynı anda çok sayıda sistemi etkileyen bölgesel bir hizmet kesintisi olasılığını azaltır. Birden çok Bölgeye yayılan bir uygulama portföyünün çalıştırılması, önemli operasyonel planlama ve yönetim gerektirir. Yalıtılmış işlevsel ögeler, tek bir Bölgede dağıtılan ortak aşağı akış sistemlerine ve veri kaynaklarına bağlı olabilir. Bu nedenle, Bölge çapındaki olaylar yine de aksamaya neden olabilir, ancak etki yüzey alanı azaltılmalıdır.

Model 4 (M4): Multi-AZ dağıtımı (multi-Region DR)

Example Corp, tüketicilerin banka ödemeleri yapabilmesi gibi kesintiye karşı çok düşük bir toleransa sahip olan iş açısından kritik birkaç hizmet yürütür. Example Corp, DR için dört yaygın modeli (AWS’te İş Yüklerinin Felaketten Kurtulması: Bulutta Kurtarma bölümünde tanımlandığı gibi) inceledi ve çok Bölgeli uygulamaları için aşağıdaki alt modelleri kullanmaya karar verdi:

• Pilot Light – Bu model, 10 dakika katları RTO/RPO gerektiren uygulamalar için çalışır. Veriler aktif olarak çoğaltılır ve uygulama altyapısı, DR Bölgesinde önceden sağlanır. Uygulama altyapısı kapalı tutulduğu ve yalnızca geri yükleme olayı sırasında açık tutulduğu için, maliyet optimizasyonu burada önemli bir etkendir.
• Warm Standby – Bu model, uygulamalarınızı DR Bölgesinde ancak azaltılmış bir kapasiteyle çalışır durumda tutarak pilot light’a kıyasla geri yükleme sürelerini önemli ölçüde artırır. Bir DR olayı sırasında uygulama altyapısı ölçeklendirilecektir, ancak bu genellikle minimum manuel çabayla otomatikleştirilebilir. Bu model, doğru bir şekilde uygulanırsa dakika katları RTO/RPO’ya ulaşabilir.

Ödünleşimler

M4, hafifletme maliyetlerini düşürürken bölgesel bir hizmetteki kesintiyi azaltır. Bölgesel DR modelleri, altyapı değişikliklerinin Bölgeler arasında senkronize edilmesi gerektiğinden dağıtım karmaşıklığını artırır. Dayanıklılığın test edilmesi de önemli ölçüde daha karmaşıktır ve bölgesel bozulmaların simülasyonunu içerir. Dağıtımları otomatikleştirmek için Altyapıyı Kod (Infrastructure as Code) olarak kullanmak, bu sorunları hafifletmeye yardımcı olabilir.

Model 5 (P5): Multi-Region active-active

Example Corp’un temel bankacılık ve Müşteri İlişkileri Yönetimi uygulamaları kesintiye karşı sıfır toleransa sahiptir. Gerçek zamanlı bir RTO’ya ve sıfıra yakın veri kaybına sahip bir RPO’ya sahip olduğundan, bu uygulamaları devreye almak için M5 modelini kullanıyorlar. İş yüklerini aynı anda birden fazla Bölgede çalıştırarak, tüm Bölgelerden gelen trafiği aynı anda sunmalarına olanak tanır. Bu model, yalnızca bölgesel kesintileri azaltmakla kalmaz, aynı zamanda sıfır tolerans gereksinimlerini de karşılar (Şekil 5).

Ödünleşimler

P5, bölgesel bir hizmetin kesintiye uğramasını azaltır ve sıfıra yakın bir RTO sunmak için ek maliyetler ve karmaşıklık yatırımı yapar. Gerekli iş hizmetlerini sunmak için işbirliği yapan birden çok uygulama içerdiklerinden, çok etkin konuşlandırmalar genellikle karmaşıktır. Bu kalıbı uygularsanız, Bölgeler genelinde veriler için asenkron çoğaltmayı başlattığınızı ve bunun veri tutarlılığı üzerindeki etkisini göz önünde bulundurmanız gerekir.

Bu modelin çalıştırılması çok yüksek düzeyde bir süreç olgunluğu gerektirir, bu nedenle müşterilerin daha önce açıklanan dağıtım modellerinden başlayarak kademeli olarak bu modele doğru geliştirmelerini öneririz.

Sonuç

Bu blog gönderisinde, bunları uygularken göz önünde bulundurmanız gereken beş dayanıklılık modelini ve ödünleşimleri tanıttık. Kullanım durumunuz için en verimli mimariyi bulmanıza yardımcı olmak amacıyla, Example Corp’un bu seçenekleri nasıl değerlendirdiğini ve bunları iş ihtiyaçlarına nasıl uyguladıklarını gösterdik.

Daha fazla okuma

• AWS Well Architected Framework – Resilience Pillar
• Building Resilient Well-Architected Workloads Using AWS Resilience Hub
• Disaster Recovery of Workloads on AWS: Recovery in the Cloud
• Disaster Recovery (DR) Architecture on AWS, Architecture Blog series
• AWS Multi-Region Fundamentals whitepaper

Daha fazla mimari içerik mi arıyorsunuz?

AWS Mimari Merkezi, referans mimari diyagramları, incelenmiş mimari çözümleri, Well-Architected en iyi uygulamaları, modeller, ikonlar ve daha fazlasını sağlar!