Erişilebilirlik Alanlarının kullanıldığı statik kararlılık

Amazon olarak, oluşturduğumuz hizmetler son derece yüksek erişilebilirlik hedeflerini karşılamalıdır. Bu nedenle, sistemlerimizin barındırdığı bağımlılıklar hakkında dikkatlice düşünmemiz gereklidir. Sistemlerimizi bu bağımlılıklarda sorun yaşansa bile dayanıklı olacak şekilde tasarlarız. Bu makalede, belirtilen dayanıklılık düzeyine ulaşmak için kullandığımız ve statik kararlılık denilen bir modeli tanımlayacağız. Bu kavramı, AWS'de altyapının temel bir yapı taşı olan ve dolayısıyla oluşturduğumuz tüm hizmetlerin ana bağımlılık işlevini gören Erişilebilirlik Alanlarına nasıl uyguladığımızı göstereceğiz.

Statik olarak kararlı bir tasarımda, bir bağımlılıkta sorun yaşansa bile genel olarak sistem çalışmaya devam eder. Sistem, bağımlılığının sağlaması gereken güncellenmiş bilgileri (yenilikler, silinenler veya değiştirilenler gibi) muhtemelen görmez. Ancak, bağımlılıkta sorun yaşanmadan önce yapmakta olduğu her şey, sorunun yaşandığı bağımlılığa rağmen çalışmaya devam eder. Amazon Elastic Compute Cloud (EC2) hizmetini nasıl statik olarak kararlı olacak şekilde oluşturduğumuzu açıklayacağız. Ardından, Erişilebilirlik Alanlarını temel alan yüksek oranda erişilebilir bölgesel sistemler oluşturmaya yardımcı olduğunu düşündüğümüz statik olarak kararlı iki örnek mimari sunacağız.

Son olarak, nasıl yazılım düzeyinde Erişilebilirlik Alanı bağımsızlığı sunacak şekilde tasarlandığı dahil olmak üzere Amazon EC2'nin arkasındaki tasarım felsefesinin bir bölümünü daha kapsamlı bir şekilde inceleyeceğiz. Ayrıca, bu mimari seçimiyle hizmet oluşturmanın getirdiği bazı ödünleri ele alacağız.

Bu bölümde, statik kararlılıktan faydalanarak sistemleri yüksek erişilebilirlik düzeyine ulaşacak şekilde tasarlamak için AWS'de kullandığımız iki üst düzey modeli tanıtacağız. Her bir modelin uygulanacağı farklı durumlar bulunur ancak her ikisi de Erişilebilirlik Alanı soyutlamasından yararlanır.

Bir Erişilebilirlik Alanında sorun yaşanması durumunda, önceki diyagramda gösterilen mimaride hiçbir eylem gerekmez. Sorunlu Erişilebilirlik Alanındaki EC2 bulut sunucuları, durum denetimlerinde hata vermeye başlayacak ve Application Load Balancer hizmeti, trafiği başka yerlere kaydıracaktır. Elastic Load Balancing hizmeti, aslında bu ilkeye göre tasarlanmıştır. Ölçeği artırmaya gerek kalmadan bir Erişilebilirlik Alanı sorununa dayanacak kadar yük dengeleme kapasitesi tedarik etmiştir.

Bu modeli ayrıca yük dengeleyici veya HTTPS hizmeti olmadığında da kullanırız. Örneğin, Amazon Simple Queue Service (SQS) kuyruğundaki mesajları işleyen bir EC2 bulut sunucusu filosu da bu modeli uygulayabilir. Bulut sunucuları, birden fazla Erişilebilirlik Alanındaki bir Otomatik Ölçeklendirme grubunda dağıtılır ve kapasite uygun şekilde fazladan tedarik edilir. Bir Erişilebilirlik Alanında sorun yaşanması durumunda hizmet hiçbir işlem yapmaz. Sorunlu bulut sunucuları iş yapmayı bırakır ve diğerleri ise boşluğu doldurur.

Durum bilgisi olmayan ve etkin-etkin örnekte görüldüğü üzere, birincil düğümün Erişilebilirlik Alanında sorun oluştuğunda durum bilgisi olan hizmet, altyapıyla ilgili bir işlem yapmaz. Amazon RDS kullanan hizmetler için RDS, yük devretme işlemini yönetecek ve DNS adını çalışan Erişilebilirlik Alanındaki yeni birincil düğüme yönlendirecektir. Bu model, ilişkisel veritabanı kullanmasalar bile diğer etkin-yedek kurulumlar için de geçerlidir. Bunu özellikle lider düğüme sahip küme mimarisi olan sistemlere uyguluyoruz. Bu kümeleri Erişilebilirlik Alanlarına dağıtıyor ve yeni lider düğümü "tam zamanında" bir başkasıyla değiştirmek yerine yedek adaylar arasından seçiyoruz.

Bu iki modelin ortak yanı, her ikisinin de gerçek bir sorun oluşmadan çok önce Erişilebilirlik Alanında bir sorun oluşması halinde ihtiyaç duyacakları kapasiteyi halihazırda tedarik etmiş olmalarıdır. Bu durumların hiçbirinde hizmet, Erişilebilirlik Alanında sorun oluşmasına müdahale olarak yeni altyapı tedarik etme veya değişiklikler yapma gibi denetim düzlemi bağımlılıklarını planlı olarak kullanmaz.

Makalenin bu son bölümünde, Amazon EC2'deki Erişilebilirlik Alanı bağımsızlık ilkesini uygulama yöntemlerimizden bazılarını kapsayan dayanıklı Erişilebilirlik Alanı mimarilerine bir derece daha yakından bakacağız. Bu kavramların bazılarını anlamak, yalnızca kendisinin yüksek erişilebilirliğe sahip olması değil, aynı zamanda başkalarının da yüksek erişilebilirliğe sahip olabileceği bir altyapı sağlaması gereken bir hizmet oluştururken yararlı olacaktır. Düşük düzeyli AWS altyapısı sağlayıcısı olarak Amazon EC2, uygulamaların yüksek oranda erişilebilir olmak için kullanabileceği altyapıdır. Diğer sistemlerin de bu stratejiyi uygulamak isteyebilecekleri durumlar bulunur.

Dağıtım uygulamalarımızda Amazon EC2'deki Erişilebilirlik Alanı bağımsızlık ilkesini uyguluyoruz. Amazon EC2'de yazılımlar; EC2 bulut sunucularını barındıran fiziksel sunuculara, uç cihazlarına, DNS çözümleyicilerine, EC2 bulut sunucusu başlatma yolundaki denetim düzlemi bileşenlerine ve EC2 bulut sunucularının bağlı olduğu diğer birçok bileşene dağıtılır. Bu dağıtımlar, alansal dağıtım takvimine göre yapılır. Bu; aynı Bölgedeki iki Erişilebilirlik Alanının, belirli bir dağıtımı farklı günlerde alacağı anlamına gelir. AWS genelinde, dağıtımlar aşamalı bir şekilde yapılır. Örneğin, başlangıçta yerleşik olarak ve ardından sunucuların 1/N'i oranına dağıtılması şeklindeki en iyi uygulamayı (hangi hizmet türüne dağıttığımızdan bağımsız olarak) takip ederiz. Ancak, Amazon EC2'deki hizmetler gibi belirli bir hizmet durumunda dağıtımlarımız, bir adım daha ileri gidip planlı bir şekilde Erişilebilirlik Alanı sınırına göre ayarlanır. Bu sayede sorunlu bir dağıtım, bir Erişilebilirlik Alanını etkiler ve geri alınıp düzeltilir. Diğer Erişilebilirlik Alanlarını etkilemez ve bunlar normal çalışmaya devam eder.

Amazon EC2'de hizmet oluştururken bağımsız Erişilebilirlik Alanları ilkesini kullandığımız bir başka yol, tüm paket akışlarını Erişilebilirlik Alanı içinde kalacak ve sınırların dışına çıkmayacak şekilde tasarlamaktır. Ağ trafiğinin Erişilebilirlik Alanında yerel olarak tutulmasıyla ilgili bu ikinci nokta, daha ayrıntılı incelemeye değerdir. Bu, diğer kişilerin yüksek erişilebilirlik için ürün oluşturmalarını sağlayacak Erişilebilirlik Alanından bağımsız altyapı sağladığımız durumun aksine, bağımsız Erişilebilirlik Alanları tüketicisi olan (yani yüksek erişilebilirliğe sahip bir hizmet oluşturmak için temel olarak Erişilebilirlik Alanı bağımsızlığının garantilerini kullanan) bölgesel ve yüksek oranda erişilebilir bir sistem oluştururken nasıl farklı düşündüğümüzün ilginç bir örneğidir.

Aşağıdaki diyagramda, yeşil renkteki dahili başka bir hizmete bağlı olan turuncu renkteki yüksek oranda erişilebilir harici bir hizmet gösterilmektedir. Basit bir tasarım, bu iki hizmeti de bağımsız EC2 Erişilebilirlik Alanları tüketicisi olarak görür. Turuncu ve yeşil renkteki hizmetlerin her biri, Application Load Balancer arkasında yer alır ve her hizmet, üç Erişilebilirlik Alanına yayılan ve kapasite tedariği iyi yapılmış arka uç ana bilgisayar filosuna sahiptir. Yüksek oranda erişilebilir bir bölgesel hizmet, yüksek oranda erişilebilir başka bir hizmeti arar. Bu tasarım sadedir ve geliştirdiğimiz hizmetlerin çoğu için iyi bir tasarımdır.

Ancak, yeşil renkteki hizmetin temel bir hizmet olduğunu varsayalım. Diğer bir ifadeyle, yalnızca yüksek oranda erişilebilir olması için değil, aynı zamanda Erişilebilirlik Alanı bağımsızlığı sağlamak üzere bir yapı taşı görevi görmek için amaçlandığını varsayalım. Bu durumda, Erişilebilirlik Alanı duyarlı dağıtım uygulamalarını izlediğimiz alana özel bir hizmetin üç bulut sunucusu olarak tasarlayabiliriz. Aşağıdaki diyagramda, yüksek oranda erişilebilir bölgesel bir hizmetin yüksek oranda erişilebilir bir alansal hizmeti aradığı tasarım gösterilmektedir.

Yapı taşı olan hizmetlerimizi Erişilebilirlik Alanından bağımsız olacak şekilde tasarlamamızın nedenleri, temel aritmetiğe dayanır. Bir Erişilebilirlik Alanında sorun oluştuğunu varsayalım. Application Load Balancer, nedenleri kesin olan hatalarda etkilenen düğümlerin yüklerini otomatik olarak başka düğümlere devredecektir. Ancak, tüm hataların nedeni bu kadar açık değildir. Yazılımdaki hatalar gibi yük dengeleyicinin durum denetiminde göremeyeceği ve uygun şekilde düzeltemeyeceği gri hatalar olabilir.

Yüksek oranda erişilebilir bölgesel bir hizmetin yüksek oranda erişilebilir başka bir bölgesel hizmeti aradığı önceki örnekte, sistemden bir istek gönderilirse, isteğin sorunlu Erişilebilirlik Alanından kaçınma olasılığı bazı basitleştirici varsayımlarla 2/3 * 2/3 = 4/9 şeklindedir. Yani, isteğin olaydan kaçınma olasılığı yarıdan azdır. Buna karşın, mevcut örnekte olduğu gibi yeşil renkteki hizmeti alansal bir hizmet olarak oluşturursak, o zaman turuncu renkteki hizmette bulunan ana bilgisayarlar aynı Erişilebilirlik Alanında bulunan yeşil renkteki uç noktayı arayabilir. Bu mimari sayesinde sorunlu Erişilebilirlik Alanından kaçınma olasılığı 2/3 olur. N hizmet bu arama yolunun bir parçasıysa bu sayılar, N bölgesel hizmet için (2/3)^N'ye tekabül ederken N alansal hizmet için 2/3'te sabit kalır.

Bu nedenle, Amazon EC2 NAT ağ geçidini alansal bir hizmet olarak oluşturduk. NAT ağ geçidi, özel bir alt ağ kaynaklı giden internet trafiğine olanak sağlayan ve bölgesel, VPC çapında bir ağ geçidi olarak değil, müşterilerin aşağıdaki diyagramda gösterildiği gibi Erişilebilirlik Alanı başına ayrı olarak başlattığı alansal bir kaynak olarak görünen bir Amazon EC2 özelliğidir. NAT ağ geçidi, VPC internet bağlantısı yolunda bulunur ve bu nedenle, bu VPC içindeki her EC2 bulut sunucusu veri düzleminin bir parçasıdır. Bir Erişilebilirlik Alanında bağlantı sorunu varsa, bu sorunu diğer bölgelere yaymadan bu Erişilebilirlik Alanıyla sınırlamak isteriz. Sonuç olarak, bu makalenin önceki bölümlerinde belirtilene benzer mimariyi (yani, üç Erişilebilirlik Alanında bir filo tedarik edip iki Erişilebilirlik Alanının tüm yükü taşıyabileceği kadar kapasite ayırma) oluşturan bir müşterinin, sorunlu Erişilebilirlik Alanında meydana gelenlerden diğer Erişilebilirlik Alanlarının hiçbir şekilde etkilenmeyeceğini bilmesini isteriz. Bunu yapmamızın tek yolu, NAT ağ geçidi gibi tüm temel bileşenlerin gerçekten Erişilebilirlik Alanı içinde kalmasını sağlamaktır.

Bu seçim, ek karmaşıklık maliyetiyle birlikte gelir. Bizim için Amazon EC2'de ek karmaşıklık, bölgesel yerine alansal hizmet ortamlarını yönetme biçiminde gelir. NAT ağ geçidi müşterileri için ek karmaşıklık, VPC'nin farklı Erişilebilirlik Alanlarında kullanılmak üzere birden fazla NAT ağ geçidi ve yol tablosuna sahip olma şeklindedir. NAT ağ geçidinin kendisi, alansal erişilebilirlik garantileri sağlaması gereken Amazon EC2 veri düzleminin bir parçası olan temel bir hizmet olduğu için ek karmaşıklık oluşması normaldir.

Erişilebilirlik Alanından bağımsız hizmetler oluştururken dikkate aldığımız bir nokta daha bulunur ve bu nokta veri dayanıklılığıdır. Daha önce belirtilen alansal mimarilerin her biri, tek bir Erişilebilirlik Alanında bulunan yığının tamamını gösterse de olağanüstü durum kurtarma işlemleri için tüm sabit durumları birden fazla Erişilebilirlik Alanına çoğaltırız. Örneğin, genellikle düzenli aralıklarla veritabanı yedeklerini Amazon S3'e depolar ve Erişilebilirlik Alanı sınırlarında veri depolarımızın okuma replikalarını muhafaza ederiz. Bu replikalar, birincil Erişilebilirlik Alanının çalışması için gerekli değildir. Bunun yerine, müşteri veya iş açısından önemli verileri birden fazla konumda saklamamızı sağlarlar.

AWS'de çalışacak hizmet odaklı bir mimari tasarlarken, bu iki modelden birini veya ikisinin bir birleşimini kullanmayı öğrendik:

• Daha basit model: bölgesel-bölgeseli-arar. Bu genellikle dışa dönük hizmetler için en iyi seçimdir ve çoğu dahili hizmet için de uygundur. Örneğin, AWS'de Amazon API Gateway ve AWS sunucusuz teknolojileri gibi üst düzey uygulama hizmetleri oluştururken, Erişilebilirlik Alanında sorun oluşması durumunda bile yüksek erişilebilirlik sağlamak için bu modeli kullanıyoruz.
• Daha karmaşık model: bölgesel-alansalı-arar veya alansal-bölgeseli-arar. Amazon EC2'de dahili ve bazı durumlarda harici veri düzlemi bileşenleri (doğrudan önemli veri yolunda bulunan ağ gereçleri veya diğer altyapılar) tasarlarken, ağ trafiğinin aynı Erişilebilirlik Alanında kalması için Erişilebilirlik Alanı bağımsızlığı modelini takip ediyor ve Erişilebilirlik Alanlarında yalıtılmış olan bulut sunucularını kullanıyoruz. Bu model, meydana gelen sorunları bir Erişilebilirlik Alanıyla sınırlamakla kalmıyor, aynı zamanda AWS'de avantajlı ağ trafiği maliyeti özelliğine sahip.

Bu makalede, Erişilebilirlik Alanlarında bağımlılıkları başarıyla almak için AWS'de kullandığımız bazı basit stratejileri açıkladık. Sorunlar gerçekleşmeden önce bunları öngörmenin statik kararlılık için son derece önemli olduğunu öğrendik. Bir sistemin yatay olarak ölçeklenebilir etkin-etkin bir filoda çalışması ya da durum bilgisi olan etkin-yedek model olması fark etmeksizin, yüksek erişilebilirlik düzeylerini hedeflemek için Erişilebilirlik Alanlarını kullanabiliriz. Sistemlerimizi, bir sorun oluşması durumunda ihtiyaç duyulacak olan tüm kapasitenin halihazırda tedarik edilmiş ve kullanıma hazır olacak şekilde dağıtıyoruz. Son olarak, Amazon EC2'nin Erişilebilirlik Alanlarının birbirlerinden bağımsız olmalarını sağlamak için statik kararlılık kavramlarını nasıl kullandığını daha kapsamlı bir şekilde inceledik.