Coğrafi olarak dağıtılmış bir mimari tasarlama
Azure, küresel bir sistemdir. Birden fazla Azure bölgesini kapsayan bir mimari tasarlayarak bölge genelindeki olağanüstü durumlara dahi dayanıklı bir uygulama derleyebilirsiniz.
Gönderi takip portalınız, ölçeklenebilir Azure kaynakları kullanılarak derlendiğinden ölçeklenebilir niteliktedir. Bileşenleri birden çok örneğe sahip olabileceğinden birçok hataya da dayanıklıdır. Ancak yönetim kurulunuz, portalın tamamı Doğu ABD Azure bölgesinde yer aldığı için büyük ölçekli bir olağanüstü durumun kesintiye neden olabileceği konusunda kaygılandı. Doğu ABD bölgesinin başarısız olması durumunda ikinci bir bölgeye yük devretme gerçekleştirebilecek yeni bir mimari sunmak istiyorsunuz.
Burada, coğrafi olarak dağıtılmış bir uygulamayı desteklemek için uygulamamızın mimarisini ayarlamayı öğreneceksiniz. Bu mimarinin iş açısından kritik uygulamalar için neden avantajlı olduğunu da görüyoruz.
Özgün web uygulaması mimarisi
Şimdi izleme portalının mimari tasarımına ve çözümde kullanılan bileşenlere göz atalım. Tüm parçaları nasıl kullandığımızı anladıktan sonra, coğrafi olarak yedeklilik senaryolarında bu bileşenlerin her birini nasıl destekleyebileceğinizi araştırabiliriz.
İzleme portalının tasarımı, aşağıdaki diyagramda gösterilen başvuru mimarisini temel alır.
Gördüğünüz gibi uygulamanız tek bir Azure kaynak grubunu kullanıyor. Bu kaynak grubu, tüm kaynaklarımızı mantıksal olarak gruplandırmamıza ve yönetmemize olanak tanır ve yönetimi basitleştirir. Bu kaynak grubunun Doğu ABD bölgesine dağıtılmış olduğuna dikkat edin. Kaynak grubu, tüm kaynaklar için aynı Azure bölgesinin kullanılmasını zorunlu kılmasa da uygulamada dağıtılan tüm kaynaklar için Doğu ABD bölgesi kullanıldı.
Uygulamada kullanılan Azure kaynakları üç kategoriye ayrılabilir. Şimdi her kategoriye göz atalım ve hangi kaynakların kullanımda olduğunu görelim.
Ağ bileşenleri
İzleme portalı aşağıdaki ağ hizmetlerini kullanır.
| Hizmet | Açıklama |
|---|---|
| Azure DNS | Azure DNS hizmetini, DNS kayıtlarımızı Azure'da barındırmak için yapılandırdık. Azure DNS, Azure portalındaki Azure kimlik bilgilerimizi kullanarak DNS kayıtlarımızı yönetmemizi sağlar. |
| Application Gateway | Application Gateway yük dengeleyici yapılandırarak trafiğin birden fazla web ön ucu örneği arasında dengelenmesini sağladık. Bu hizmet, tek bir Azure bölgesine özgüdür. |
| Azure CDN | Azure CDN hizmetini, web sitemizin içeriğindeki grafikler gibi güvenlik gereksinimi olmayan statik içeriği en iyi şekilde teslim edebilmek için yapılandırdık. Bu genel hizmet, statik içeriği dünyanın her yerindeki varlık noktalarında önbelleğe alır. |
Uygulama bileşenleri
Takip portalı kod, önbellek ve ara depolama alanı gereksinimleri için aşağıdaki hizmetleri kullanıyor.
| Hizmet | Açıklama |
|---|---|
| Microsoft Entra ID | Kullanıcılar, Microsoft Entra hesaplarını kullanarak izleme portalına erişer. Dizin ve hesaba otomatik olarak genel çoğaltma uygulanıyor. |
| Azure App Service | Takip portalında iki Azure App Service kullanılıyor. İlki bir dizi dinamik web sayfası, ikincisi ise bir web API'sini çalıştırır. |
| Azure İşlev Uygulamaları | İzleme portalı, tüm arka plan görevlerini çalıştırmak için Azure İşlev Uygulamaları'nı kullanıyor. Bu görevlerden bazıları düzenli bir plan dahilinde çalışırken diğerleri kuyruktaki iletilere göre çalışıyor. |
| Azure Depolama Kuyrukları | İzleme portalı, Azure İşlev Uygulamaları ile Azure Depolama Kuyruklarını kullanır. Takip portalı, oluşturulan iletileri kuyruğa eklerken İşlev Uygulamaları bu iletileri işleme alıyor. |
| Redis Cache | Takip portalı, sorgu performansını en üst düzeye çıkarmak için ön uç uygulama hizmeti ile veri depolama alanı sistemleri arasında bir Redis Cache kullanıyor. |
| Azure Blob Depolama | Grafik ve video dosyaları gibi statik içerik, Bir Azure Depolama hesabında İkili Büyük Nesneler (Bloblar) olarak tutulur ve Azure CDN aracılığıyla teslim edilir. |
| Azure Search | Takip portalında Azure Search hizmetini etkinleştirdik. Azure Search, tüm içeriği aranabilir hale getirmemizi ve kullanıcılarımıza arama önerileri ve belirsiz arama sonuçları sağlamamızı sağlar. |
Veri depolama bileşenleri
İzleme portalı aşağıdaki kalıcı depolama hizmetlerini kullanır.
| Hizmet | Açıklama |
|---|---|
| Azure SQL Veritabanı | Sipariş ve müşteri bilgileri gibi ilişkisel verileri Azure SQL Veritabanı'nda depoluyoruz. |
| Cosmos DB | Ürün kataloğumuz dahil olmak üzere yarı yapılandırılmış verileri Cosmos DB'de depoluyoruz. |
Özgün mimariyle ilgili sorunlar
İzleme portalının mevcut mimarisi, ölçeklenebilirlik ve kullanılabilirlik sağlamak için tasarlanmış durumda.
Örneğin, talep yüksekse ve kullanıcı web isteklerine yanıtlar yavaşsa, App Service'te ön uç web uygulamasının daha fazla örneğini ekleyebilirsiniz. Burada Application Gateway, istekleri bu yeni oluşturulan örneklere yönlendirebilir.
Ancak mimari tasarımımızın üstesinden gelinmesi ve hatta başarısız olması gibi zorluklarla karşı karşıya olduğu senaryolar vardır. Takip portalı üzerindeki etkilerini daha iyi anlamak için bu senaryolara göz atalım.
Bölgesel sorunlar
Bir Azure bölgesinin tamamının kesinti yaşamasına neden olabilecek olaylar söz konusu olabilir. Azure veri merkezleri son derece dayanıklı olacak şekilde tasarlanmıştır, ancak kasırga veya sel gibi büyük bir hava olayı bölgeden gelen hizmeti kesintiye uğratabilir.
Bu olaylar olağanüstü durumlardır ve çoğu şirket bu riski alabileceğini düşünür. Ancak takip portalını devre dışı bırakacak düzeyde bir bölgesel hatanın sonuçları çok ciddi olduğundan şirketin yönetim ekibi, riski ortadan kaldırmaya karar verdi.
Servis Seviyesi Sözleşmeleri
Çoğu Azure hizmeti bir Hizmet Düzeyi Sözleşmesi (SLA) veya çalışma süresi garantisi sunmaktadır. Birden fazla Azure hizmetini kapsayan bir uygulama mimarisi oluştururken uygulamanın genel SLA değeri, diğer hizmetlerin SLA'larını dikkate alarak bileşik değer olarak hesaplanır.
Bu SLA'yı hesaplamak için bileşen hizmetlerinin SLA'larını çarpmanız gerekir. Örneğin, uygulamamızın Azure Uygulaması Hizmeti (%99,95 SLA) ve Microsoft Entra Id (%99,9 SLA) olduğunu varsayalım. Hesaplanan son SLA %99,85 olur.
Bu çalışma süresi yüzdesi uygulamanız için yeterli değilse uygulamayı başka bir bölgeye yük devretme gerçekleştirecek şekilde ayarlayabilirsiniz.
Küresel, bölgesel ve yapılandırılabilir bileşenler
Tasarımımızda bazı bileşenler varsayılan olarak küreseldir ve bölgesel hatalardan etkilenmez.
Bazı bileşenler (Application Gateway gibi) tek bir bölgede bulunur. Bu tür bileşenler için alternatif bir hizmet seçmeliyiz.
Bazı bileşenler, birden fazla bölgeyi destekleyecek şekilde yapılandırılabilir. Örneğin Azure Depolama hesabı ile sunulan ve statik içeriği depolayan Coğrafi Olarak Yedekli Depolama (GRS) seçeneğini kullanabilirsiniz. GRS, blobları başka bir bölgede çoğaltır.
Aşağıdaki tabloda hangi bileşenlerin genel, bölgesel ve yapılandırılabilir olduğu gösterilmektedir.
| Bileşen | Birden çok bölge desteği | Yorumlar |
|---|---|---|
| Azure DNS | Genel | Değişiklik yapılmasına gerek yoktur. |
| Application Gateway | Bölgesel | Her Application Gateway örneği tek bir bölgede yer alır. |
| Azure CDN | Genel | Değişiklik gerekmez, içerik varsayılan olarak genel olarak önbelleğe alınır. |
| Microsoft Entra ID | Genel | Değişiklik yapılmasına gerek yoktur. |
| Azure App Service | Bölgesel | Uygulamanın her örneği tek bir bölgede yer alır. |
| Azure İşlev Uygulamaları | Bölgesel | İşlev uygulamasının her örneği tek bir bölgede yer alır. |
| Azure Depolama Kuyrukları | Konfigüre edilebilir | Azure Depolama hesabını birden çok bölgeye çoğaltmayı seçebilirsiniz. |
| Azure Redis Cache | Bölgesel | Önbelleğin her örneği tek bir bölgede yer alır. |
| Azure Blob Storage | Konfigüre edilebilir | Azure Depolama hesabını birden çok bölgeye çoğaltmayı seçebilirsiniz. |
| Azure Search | Bölgesel | Arama hizmetinin her örneği tek bir bölgede yer alır. |
| Azure SQL Veritabanı | Konfigüre edilebilir | Verileri birden çok bölgeye eşitlemek için coğrafi çoğaltmayı kullanabilirsiniz. |
| Azure Cosmos DB | Konfigüre edilebilir | Verileri birden çok bölgeye eşitlemek için coğrafi çoğaltmayı kullanabilirsiniz. |
Önerilen dağıtılmış mimari
Biraz araştırmadan sonra aşağıdaki diyagramda gösterildiği gibi mimariyi önerirsiniz.
Bu tasarımda bir etkin (Doğu ABD), biri de bekleme durumunda (Batı ABD) olan iki bölge yer alıyor. Normal koşullarda bileşenler tarafından iletilen tüm istekleri Doğu ABD bölgesi işliyor. Bölgesel hataya neden olabilecek bir olağanüstü durum oluşması halinde uygulama, Batı ABD bölgesine yük devretme gerçekleştiriyor.
Şimdi özgün mimaride ne tür değişiklikler yaptığınıza bakalım. Bu değişiklikleri sonraki ünitelerde daha ayrıntılı olarak inceleyeceğiz.
Ağ
Azure DNS ve Azure CDN, varsayılan olarak küresel olan sistemlerdir ve bölgesel hatalara karşı dayanıklıdır. Onları yerinde bırakırız.
Azure Application Gateway oluştururken hizmeti tek bir bölgeye atamanız gerekir. Bu hizmeti Azure Front Door ile değiştirerek bu güvenlik açığını ortadan kaldırırız. Front Door birden çok App Services'ı yoklayabilir ve App Service yük devretme işlemini Doğu ABD bölgesinden Batı ABD bölgesine işleyebilir.
Uygulama hizmetleri
Microsoft Entra ID genel bir sistemdir ve hiçbir değişiklik gerektirmez.
Azure Depolama hesapları, içeriği birden fazla bölgede çoğaltacak şekilde yapılandırılabilir. Yapılandırmamızı değiştirmek için coğrafi olarak yedekli depolama seçeneklerinden birini kullanırız.
Bunların dışındaki App Service, İşlev Uygulamaları, Redis Cache ve Azure Search bileşenleri, bölgesel hizmetler. Yeni mimari tasarımımızda Batı ABD bölgesinde bu bileşenlerin yinelenen örneklerini oluşturuyoruz. Bu tasarımda yük devretme gerçekleştiğinde yeni bölge hizmetleri sürdürebilir olacak.
Veri depolama
Azure SQL Veritabanı ve Azure Cosmos DB hizmetleri, verilerin farklı bölgelere coğrafi olarak çoğaltılmasını destekler. Bu hizmetleri Doğu ABD verilerini Batı ABD'deki eşdeğer hizmetlere çoğaltacak şekilde yapılandırıyoruz.
Bölgesel çiftler
Azure bölgesi, tek bir coğrafi alanda bulunan ve bir veya daha fazla Azure veri merkezini kapsayan bir alandır. Tüm bölgeler, aynı coğrafyadaki diğer bölgelerle eşleştirilir. Güncelleştirmeler ve planlı bakım çalışmaları, eşleştirilen bölgelerin ikisinde farklı zamanlarda gerçekleştirilir. Birden fazla bölgeyi etkileyen bir hata olması durumunda her çiftteki bölgelerden en az bir tanesi hızlı kurtarma için önceliklendirilir.
En iyi yöntem, uygulamanız için bir bölge çiftindeki iki bölgeyi temel alan iki bölgeli mimari oluşturmaktır. Buna örnek olarak Doğu ABD ile Batı ABD çiftini düşünebilirsiniz. Önerilen tasarımımızda etkin bölgesi için Doğu ABD, bekleme bölgesi için Batı ABD kullanılmıştır.