Yüksek oranda kullanılabilir, çok bölgeli web uygulaması

Bu örnek mimari, Temel web uygulaması örnek mimarisini temel alır ve aşağıdakileri gösterecek şekilde genişletir:

• Azure Uygulaması Service web uygulamasında ölçeklenebilirliği ve performansı geliştirmeye yönelik kanıtlanmış uygulamalar
• Yüksek kullanılabilirlik elde etmek için bir Azure Uygulaması Hizmeti uygulamasını birden çok bölgede çalıştırma

Mimari

Bu mimarinin bir Visio dosyasını indirin.

İş Akışı

Bu iş akışı, mimarinin çok bölgeli yönlerini ele alır ve Temel web uygulamasını temel alır.

• Birincil ve ikincil bölgeler. Bu mimari yüksek kullanılabilirlik elde etmek için iki bölge kullanır. Uygulama her bir bölgeye dağıtılır. Normal işlemler sırasında ağ trafiği birincil bölgeye yönlendirilir. Birincil bölge kullanılamaz duruma gelirse trafik, ikincil bölgeye yönlendirilir.
• Front Door'a. Azure Front Door, çok bölgeli uygulamalar için önerilen yük dengeleyicidir. Yaygın açıklardan yararlanmalara karşı koruma sağlamak için web uygulaması güvenlik duvarı (WAF) ile tümleşir ve Front Door'un yerel içerik önbelleğe alma işlevini kullanır. Bu mimaride Front Door, tüm trafiği kullanılamaz duruma gelmediği sürece birincil bölgeye gönderen öncelikli yönlendirme için yapılandırılır. Birincil bölge kullanılamaz duruma gelirse, Front Door tüm trafiği ikincil bölgeye yönlendirir.
• Depolama Hesaplarının, SQL Veritabanı ve/veya Azure Cosmos DB'nin coğrafi çoğaltması.

Bileşenler

Bu mimariyi uygulamak için kullanılan temel teknolojiler:

• Microsoft Entra Id , çalışanların kuruluşunuz için geliştirilen bulut uygulamalarına erişmesini sağlayan bulut tabanlı bir kimlik ve erişim yönetimi hizmetidir.
• Azure DNS, DNS etki alanları için Microsoft Azure altyapısı kullanılarak ad çözümlemesi olanağı sağlayan bir hizmettir. Etki alanlarınızı Azure'da barındırarak DNS kayıtlarınızı diğer Azure hizmetlerinde kullandığınız kimlik bilgileri, API’ler, araçlar ve faturalarla yönetebilirsiniz. Özel etki alanı adı (gibi) kullanmak için contoso.com, özel etki alanı adını IP adresiyle eşleyen DNS kayıtları oluşturun. Daha fazla bilgi için bkz. Azure App Service’te özel bir etki alanı adı yapılandırma.
• Azure Content Delivery Network , dünyanın her yerinde stratejik olarak yerleştirilmiş fiziksel düğümlerde önbelleğe alarak yüksek bant genişliğine sahip içerik sunmaya yönelik genel bir çözümdür.
• Azure Front Door , katman 7 yük dengeleyicidir. Bu mimaride HTTP isteklerini web ön ucuna yönlendirir. Front Door ayrıca uygulamayı yaygın açıklardan ve güvenlik açıklarından koruyan bir web uygulaması güvenlik duvarı (WAF) sağlar. Front Door, bu tasarımda bir Content Delivery Network (CDN) çözümü için de kullanılır.
• Azure Uygulaması Service, bulut uygulamaları oluşturmak ve dağıtmak için tam olarak yönetilen bir platformdur. Bir web uygulamasının çalıştırılacağı, dağıtılacağı ve dağıtım yuvalarının yapılandırılacağı bir dizi işlem kaynağı tanımlamanıza olanak tanır.
• Azure İşlev Uygulamaları arka plan görevlerini çalıştırmak için kullanılabilir. İşlevler, zamanlayıcı olayı veya kuyruğa alınan ileti gibi bir tetikleyici tarafından çağrılır. Uzun süre çalışan durum bilgisi olan görevler için Dayanıklı İşlevler kullanın.
• Azure Depolama, buluttaki çeşitli veri nesneleri için yüksek oranda kullanılabilir, yüksek oranda ölçeklenebilir, dayanıklı ve güvenli depolama sunan modern veri depolama senaryoları için bir bulut depolama çözümüdür.
• Azure Redis Cache , açık kaynak uygulama Redis önbelleğini temel alarak verilerin daha hızlı alınması için bellek içi veri deposu sağlayan yüksek performanslı bir önbelleğe alma hizmetidir.
• Azure SQL Veritabanı, bulutta hizmet olarak ilişkisel bir veritabanıdır. SQL Veritabanı, Microsoft SQL Server veritabanı altyapısı ile aynı kod tabanını kullanır.
• Azure Cosmos DB , büyük ölçekte verileri yönetmek için genel olarak dağıtılmış, tam olarak yönetilen, düşük gecikme süreli, çok modelli, çok sorgu api'li bir veritabanıdır.
• Azure Bilişsel Arama arama önerileri, belirsiz arama ve dile özgü arama gibi arama işlevleri eklemek için kullanılabilir. Azure Search özellikle birincil veri deposunun katı tutarlılık gerektirdiği durumlarda genellikle başka bir veri deposu ile birlikte kullanılır. Bu yaklaşımda, yetkili verileri diğer veri deposunda ve arama dizinini Azure Search’te depolayın. Azure Search ayrıca birden fazla veri deposundan tek bir arama dizinini birleştirmek için de kullanılabilir.

Senaryo ayrıntıları

Bölgeler arasında yüksek kullanılabilirlik elde etmek için çeşitli genel yaklaşımlar vardır:

• Etkin/Pasif ve etkin bekleme: trafik bir bölgeye, diğer bölge ise etkin beklemede bekler. Etkin bekleme , ikincil bölgedeki App Service'in ayrıldığı ve her zaman çalıştığı anlamına gelir.

• Etkin/Pasif ve soğuk bekleme: trafik bir bölgeye, diğer bölge ise soğuk beklemede bekler. Soğuk bekleme, ikincil bölgedeki App Service'in yük devretme için gerekene kadar ayrılmamış olduğu anlamına gelir. Bu yaklaşımı çalıştırmak daha düşük maliyetlidir ancak bir hata sırasında tekrar çevrimiçi olması genellikle daha uzun sürer.

• Etkin/Etkin: her iki bölge de etkindir ve istekler bunlar arasında yük dengelidir. Bir bölge kullanılamaz duruma gelirse, rotasyondan çıkar.

Bu başvuru, etkin bekleme ile etkin/pasife odaklanır.

Olası kullanım örnekleri

Bu kullanım örnekleri çok bölgeli dağıtımdan yararlanabilir:

• LoB uygulamaları için bir iş sürekliliği ve olağanüstü durum kurtarma planı tasarlayın.

• Windows veya Linux üzerinde çalışan görev açısından kritik uygulamaları dağıtın.

• Uygulamaları kullanılabilir durumda tutarak kullanıcı deneyimini geliştirin.

Öneriler

Gereksinimleriniz, burada açıklanan mimariden farklı olabilir. Bu bölümdeki önerileri bir başlangıç noktası olarak kullanın.

Bölgesel eşleştirme

Her Azure bölgesi aynı coğrafyadaki başka bir bölgeyle eşleştirilir. Genel olarak, bölgeler için aynı bölge çiftinden (örneğin, Doğu ABD 2 ve Orta ABD) seçim yapın. Bunu yapmanın avantajları şunları içerir:

• Geniş çaplı bir kesinti varsa, her çiftten en az bir bölgenin kurtarılması önceliklendirilir.
• Olası kapalı kalma süresini en aza indirmek için, planlı Azure sistem güncelleştirmeleri bölge çiftlerine tek tek uygulanır.
• Çoğu durumda, veri yerleşikliğinin karşılanması için çiftler aynı coğrafyada yer alır.

Ancak uygulamanız için gereken tüm Azure hizmetlerinin her iki bölge tarafından da desteklendiğinden emin olun. Bkz. Bölgelere göre hizmetler. Bölgesel çiftler hakkında daha fazla bilgi için bkz. İş sürekliliği ve olağanüstü durum kurtarma (BCDR): Eşleştirilmiş Azure Bölgeleri.

Kaynak grupları

Birincil bölgeyi, ikincil bölgeyi ve Front Door'ı ayrı kaynak gruplarına yerleştirmeyi göz önünde bulundurun. Bu ayırma, her bölgeye dağıtılan kaynakları tek bir koleksiyon olarak yönetmenize olanak tanır.

App Service uygulamaları

Web uygulamasını ve web API’sini ayrı App Service uygulamaları olarak oluşturmanızı öneririz. Bu tasarım bağımsız olarak genişletilebilmeleri için ayrı App Service planlarında çalıştırmanıza olanak sağlar. Başlangıçta bu ölçeklenebilirlik düzeyine ihtiyacınız yoksa, uygulamaları aynı plana dağıtabilir ve sonra gerekirse ayrı planlara taşıyabilirsiniz.

Front Door yapılandırması

Yönlendirme. Front Door çeşitli yönlendirme mekanizmalarını destekler. Bu makalede açıklanan senaryo için öncelik yönlendirmeyi kullanın. Bu ayarda, o bölgenin uç noktası ulaşılamaz duruma gelmediği sürece Front Door tüm istekleri birincil bölgeye gönderir. Bu noktada, otomatik olarak ikinci bölgeye yük devredilir. Kaynak havuzu etkin bölge için 1 ve bekleme veya pasif bölge için 2 veya daha yüksek farklı öncelik değerleriyle ayarlayın.

Sistem durumu araştırma. Front Door, her arka ucun kullanılabilirliğini izlemek için bir HTTPS araştırması kullanır. Yoklama Front Door'a ikincil bölgeye yük devretme için bir geçiş/yük devretme testi verir. Belirtilen URL yoluna bir istek göndererek çalışır. Bir zaman aşımı dönemi içinde 200 olmayan bir yanıt alırsa araştırma başarısız olur. Sistem durumu yoklama sıklığını, değerlendirme için gereken örnek sayısını ve kaynağın iyi durumda olarak işaretlenmesi için gereken başarılı örneklerin sayısını yapılandırabilirsiniz. Front Door kaynağı düşürülmüş olarak işaretlerse, diğer çıkış noktası üzerinden yük devreder. Ayrıntılar için bkz . Sistem Durumu Yoklamaları.

En iyi uygulama olarak, uygulama kaynağınızda uygulamanın genel durumunu bildiren bir sistem durumu yoklama yolu oluşturun. Bu durum yoklaması App Service uygulamaları, depolama kuyruğu ve SQL Veritabanı gibi kritik bağımlılıkları denetlemelidir. Aksi takdirde, uygulamanın kritik bölümleri gerçekten başarısız olduğunda yoklama iyi durumda bir çıkış noktası bildirebilir. Diğer taraftan, sistem durumu araştırmasını düşük öncelikli hizmetleri kontrol etmek için kullanmayın. Örneğin, bir e-posta hizmeti devre dışı kalırsa uygulama ikinci bir sağlayıcıya geçebilir veya e-postaları daha sonradan gönderebilir. Bu tasarım deseni hakkında daha fazla bilgi için bkz . Sistem Durumu Uç Noktası İzleme Düzeni.

İnternet'ten çıkış noktalarının güvenliğini sağlamak, genel olarak erişilebilir bir uygulama uygulamanın kritik bir parçasıdır. Microsoft'un uygulamanızın Front Door ile giriş iletişimlerini güvenli hale getirmek için önerdiği tasarım ve uygulama desenleri hakkında bilgi edinmek için Ağ güvenli giriş uygulamasına bakın.

CDN. Statik içeriği önbelleğe almak için Front Door'un yerel CDN işlevini kullanın. İçerik kullanıcıya coğrafi olarak yakın bir uç sunucuda önbelleğe alındığından, CDN’nin ana avantajı kullanıcılar için gecikme süresini azaltmaktır. Trafik uygulama tarafından işlenmediğinden, CDN ayrıca uygulama üzerindeki yükü de azaltabilir. Front Door ayrıca web uygulamanız için yalnızca statik içerik önbelleğe alma özelliğinden daha iyi bir genel kullanıcı deneyimi sunmanızı sağlayan dinamik site hızlandırma özelliği sunar.

SQL Veritabanı

Veritabanlarınızı dayanıklı hale getirmek için Etkin coğrafi çoğaltma ve otomatik yük devretme gruplarını kullanın. Etkin coğrafi çoğaltma, veritabanlarınızı birincil bölgeden bir veya daha fazla (en fazla dört) bölgeye çoğaltmanıza olanak tanır. Otomatik yük devretme grupları, uygulamalarınızda kod değişikliği yapmadan ikincil bir veritabanına yük devretmenizi sağlayarak etkin coğrafi çoğaltmanın üzerine oluşturulur. Yük devretme işlemleri, oluşturduğunuz ilke tanımlarına göre el ile veya otomatik olarak gerçekleştirilebilir. Otomatik yük devretme gruplarını kullanmak için, bağlantı dizelerinizi tek tek veritabanlarının bağlantı dizesi yerine yük devretme grubu için otomatik olarak oluşturulan yük devretme bağlantı dizesi yapılandırmanız gerekir.

Azure Cosmos DB

Azure Cosmos DB, birden çok yazma bölgesine sahip etkin-etkin desenli bölgeler arasında coğrafi çoğaltmayı destekler. Alternatif olarak, bir bölgeyi yazılabilir bölge, diğerlerini salt okunur çoğaltma olarak belirleyebilirsiniz. Bölgesel bir kesinti varsa, yazma bölgesi olarak başka bir bölge seçerek yük devretme gerçekleştirebilirsiniz. İstemci SDK’sı yazma isteklerini otomatik olarak geçerli yazma bölgesine gönderir, bu nedenle bir yük devretmeden sonra istemci yapılandırmasını güncelleştirmeniz gerekmez. Daha fazla bilgi için bkz . Azure Cosmos DB ile genel veri dağıtımı.

Depolama

Azure Depolama için, okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) kullanın. RA-GRS depolaması ile, veriler ikincil bir bölgeye çoğaltılır. İkincil bölgedeki verilere ayrı bir uç nokta üzerinden salt okunur erişiminiz vardır. Coğrafi olarak çoğaltılan depolama hesapları için ikincil bölgeye kullanıcı tarafından başlatılan yük devretme desteklenir. Depolama hesabı yük devretmesi başlatma, dns kayıtlarını otomatik olarak güncelleştirerek ikincil depolama hesabını yeni birincil depolama hesabı yapar. Yük devretme işlemleri yalnızca gerekli olduğunu kabul ettiğinizde yapılmalıdır. Bu gereksinim, kuruluşunuzun olağanüstü durum kurtarma planı tarafından tanımlanır ve aşağıdaki Önemli Noktalar bölümünde açıklandığı gibi etkilerini dikkate almanız gerekir.

Bölgesel bir kesinti veya olağanüstü durum varsa, Azure Depolama ekibi ikincil bölgeye coğrafi yük devretme gerçekleştirmeye karar verebilir. Bu yük devretme türleri için müşteri eylemi gerekmez. Birincil bölgeye yeniden çalışma, bu durumlarda Azure depolama ekibi tarafından da yönetilir.

Bazı durumlarda blok blobları için nesne çoğaltma iş yükünüz için yeterli bir çoğaltma çözümü olacaktır. Bu çoğaltma özelliği, birincil depolama hesabından tek tek blok bloblarını ikincil bölgenizdeki bir depolama hesabına kopyalamanıza olanak tanır. Bu yaklaşımın avantajları, çoğaltılmakta olan veriler üzerinde ayrıntılı bir denetimdir. Çoğaltılan blok blobu türlerinin daha ayrıntılı denetimi için bir çoğaltma ilkesi tanımlayabilirsiniz. İlke tanımlarına örnek olarak şunlar verilebilir ancak bunlarla sınırlı değildir:

• Yalnızca ilkenin oluşturulmasından sonra eklenen blok blobları çoğaltılır
• Yalnızca belirli bir tarih ve saatten sonra eklenen blok blobları çoğaltılır
• Yalnızca belirli bir ön ekle eşleşen blok blobları çoğaltılır.

Kuyruk depolama, bu senaryo için Azure Service Bus'a alternatif bir mesajlaşma seçeneği olarak başvurulur. Ancak, mesajlaşma çözümünüz için kuyruk depolama kullanıyorsanız, kuyruk depolama alanı depolama hesaplarında bulunduğundan coğrafi çoğaltmaya göre yukarıda sağlanan yönergeler burada geçerlidir. Ancak iletilerin ikincil bölgeye çoğaltılmadığını ve durumlarının bölgeden ayrılmaz olduğunu anlamak önemlidir.

Azure Service Bus

Azure Service Bus için sunulan en yüksek dayanıklılıktan yararlanmak için ad alanlarınız için premium katmanı kullanın. Premium katman kullanılabilirlik alanlarını kullanır ve bu da ad alanlarınızın veri merkezi kesintilerine dayanıklı olmasını sağlar. Birden çok veri merkezini etkileyen yaygın bir olağanüstü durum varsa, premium katmana dahil edilen Coğrafi olağanüstü durum kurtarma özelliği kurtarmanıza yardımcı olabilir. Coğrafi Olağanüstü Durum kurtarma özelliği, bir ad alanının (kuyruklar, konular, abonelikler ve filtreler) tüm yapılandırmasının eşlendiğinde birincil ad alanından ikincil ad alanına sürekli olarak çoğaltılmasını sağlar. İstediğiniz zaman birincilden ikincile yalnızca bir kez yük devretme taşıması başlatmanızı sağlar. Yük devretme taşıma işlemi, ad alanı için seçilen diğer adı ikincil ad alanına yeniden atar ve eşleştirmeyi bozar. Yük devretme işlemi başlatıldıktan hemen sonra gerçekleşir.

Azure Bilişsel Arama

Bilişsel Arama'da kullanılabilirlik birden çok çoğaltma aracılığıyla elde edilirken, iş sürekliliği ve olağanüstü durum kurtarma (BCDR) birden çok arama hizmeti aracılığıyla elde edilir.

Bilişsel Arama'da çoğaltmalar dizininizin kopyalarıdır. Birden çok çoğaltmaya sahip olmak, Azure Bilişsel Arama bir çoğaltmada makine yeniden başlatmaları ve bakım gerçekleştirmesine olanak sağlarken, sorgu yürütme diğer çoğaltmalarda devam eder. Çoğaltma ekleme hakkında daha fazla bilgi için bkz . Çoğaltmaları ve bölümleri ekleme veya azaltma.

Arama hizmetinize iki veya daha fazla çoğaltma ekleyerek Azure Bilişsel Arama ile Kullanılabilirlik Alanları kullanabilirsiniz. Her çoğaltma, bölge içinde farklı bir Kullanılabilirlik Alanına yerleştirilir.

BCDR ile ilgili dikkat edilmesi gerekenler için Ayrı coğrafi bölgelerde birden çok hizmet belgelerine bakın.

Redis için Azure Önbelleği

tüm Redis için Azure Cache katmanları yüksek kullanılabilirlik için Standart çoğaltma sunarken, Premium veya Enterprise katmanının daha yüksek düzeyde dayanıklılık ve kurtarılabilirlik sağlaması önerilir. Bu katmanlar için dayanıklılık ve kurtarılabilirlik özelliklerinin ve seçeneklerinin tam listesi için Yüksek kullanılabilirlik ve olağanüstü durum kurtarma'yı gözden geçirin. İş gereksinimleriniz, altyapınıza en uygun katmanı belirler.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Güvenilirlik

Güvenilirlik, uygulamanızın müşterilerinize sağladığınız taahhütleri karşılayabilmesini sağlar. Daha fazla bilgi için bkz . Güvenilirlik sütununa genel bakış. Bölgeler arasında yüksek kullanılabilirlik için tasarım yaparken bu noktaları göz önünde bulundurun.

Azure Front Door

Birincil bölge kullanılamaz duruma gelirse Azure Front Door otomatik olarak yük devreder. Front Door yük devredildiğinde, istemcilerin uygulamaya ulaşamaması için bir süre (genellikle yaklaşık 20-60 saniye) vardır. Bu süre aşağıdaki faktörlerden etkilenir:

• Sistem durumu yoklamalarının sıklığı. Sistem durumu yoklamaları ne kadar sık gönderilirse Front Door kapalı kalma süresini veya çıkış noktasının iyi durumda olduğunu o kadar hızlı algılayabilir.
• Örnek boyut yapılandırması. Bu yapılandırma, sistem durumu yoklaması için birincil kaynağın erişilemez hale geldiğini algılamak için kaç örnek gerektiğini denetler. Bu değer çok düşükse, aralıklı sorunlardan hatalı pozitifler alabilirsiniz.

Front Door sistemde olası bir hata noktasıdır. Hizmet başarısız olursa, istemciler kapalı kalma süresi boyunca uygulamanıza erişemez. Front Door hizmet düzeyi sözleşmesini (SLA) gözden geçirin ve yalnızca Front Door kullanımıyla, yüksek kullanılabilirliğe ilişkin iş gereksinimlerinizin karşılanıp karşılanmadığını belirleyin. Aksi durumda, yardımcı çözüm olarak başka bir trafik yönetim çözümü eklemeniz faydalı olabilir. Front Door hizmeti başarısız olursa, DNS’deki kurallı ad (CNAME) kayıtlarınızı diğer trafik yönetimi hizmetini gösterecek şekilde değiştirin. Bu adımın el ile uygulanması gerekir ve uygulamanız DNS değişiklikleri yayılana kadar kullanılamaz.

Azure Front Door Standard ve Premium katmanı, Azure Front Door (klasik), Microsoft'tan Azure CDN Standart (klasik) ve Azure WAF özelliklerini tek bir platformda birleştirir. Azure Front Door Standard veya Premium'un kullanılması hata noktalarını azaltır ve gelişmiş denetim, izleme ve güvenlik sağlar. Daha fazla bilgi için bkz . Azure Front Door katmanına genel bakış.

SQL Veritabanı

SQL Veritabanı için kurtarma noktası hedefi (RPO) ve tahmini kurtarma süresi hedefi (RTO), Azure SQL Veritabanı ile iş sürekliliğine genel bakış bölümünde belgelenmiştir.

Etkin coğrafi çoğaltmanın çoğaltılan her veritabanının maliyetini etkili bir şekilde iki katına çıkardıklarına dikkat edin. Korumalı alan, test ve geliştirme veritabanları genellikle çoğaltma için önerilmez.

Azure Cosmos DB

Azure Cosmos DB için RPO ve kurtarma süresi hedefi (RTO), kullanılabilirlik, veri dayanıklılığı ve aktarım hızı arasında denge sağlayan tutarlılık düzeyleri aracılığıyla yapılandırılabilir. Azure Cosmos DB, çoklu ana bilgisayar ile rahat bir tutarlılık düzeyi için en az 0 RTO veya tek ana şablon ile güçlü tutarlılık için 0 RPO sağlar. Azure Cosmos DB tutarlılık düzeyleri hakkında daha fazla bilgi edinmek için bkz . Azure Cosmos DB'de tutarlılık düzeyleri ve veri dayanıklılığı.

Depolama

RA-GRS depolama dayanıklı depolama sağlar, ancak yük devretme gerçekleştirmeyi düşünürken aşağıdaki faktörleri göz önünde bulundurmak önemlidir:

• Veri kaybını tahmin etme: İkincil bölgeye veri çoğaltma zaman uyumsuz olarak gerçekleştirilir. Bu nedenle, coğrafi yük devretme gerçekleştirilirse, birincil hesapta yapılan değişiklikler ikincil hesapla tam olarak eşitlenmediyse bazı veri kaybı beklenmelidir. Birincil bölgedeki verilerin ikincil bölgeye en son ne zaman başarıyla yazıldığını görmek için ikincil depolama hesabının Son Eşitleme Zamanı özelliğini de kontrol edebilirsiniz.

• Kurtarma süresi hedefinizi (RTO) buna göre planlayın: İkincil bölgeye yük devretme işlemi genellikle yaklaşık bir saat sürer, dolayısıyla DR planınız RTO parametrelerinizi hesaplarken bu bilgileri dikkate almalıdır.

• Yeniden çalışmanızı dikkatle planlayın: Depolama hesabı yük devredildiğinde özgün birincil hesaptaki verilerin kaybolduğunu anlamak önemlidir. Dikkatli bir planlama yapmadan birincil bölgeye yeniden çalışma girişimi risklidir. Yük devretme tamamlandıktan sonra, yeni birincil (yük devretme bölgesindeki) yerel olarak yedekli depolama (LRS) için yapılandırılır. Birincil bölgeye çoğaltmayı başlatmak için coğrafi olarak çoğaltılmış depolama alanı olarak el ile yeniden yapılandırmanız ve ardından hesapların eşitlenmesine izin vermek için yeterli zaman vermeniz gerekir.

• Ağ kesintisi gibi geçici hatalar depolama yük devretmesini tetiklemez. Uygulamanızı geçici hatalara karşı dayanıklı olarak tasarlayın. Azaltma seçenekleri şunlardır:

  • İkinci bölgeden okuyun.
  • Yeni yazma işlemleri (örneğin kuyruk iletilerine) için geçici olarak başka bir depolama hesabına geçin.
  • İkincil bölgeden verileri başka bir depolama hesabına kopyalayın.
  • Sistem yeniden çalışana kadar azaltılmış işlev sağlayın.

Daha fazla bilgi için bkz. Azure Depolama kesintisi oluşursa yapmanız gerekenler.

Blok blobları için nesne çoğaltma kullanılırken dikkat edilmesi gerekenler için nesne çoğaltma belgelerinin önkoşullarına ve uyarılarına bakın.

Azure Service Bus

Premium Azure Service Bus katmanında yer alan Coğrafi olağanüstü durum kurtarma özelliğinin aynı yapılandırmayla işlemlerin anında sürekliliğini sağladığını anlamak önemlidir. Ancak, kuyruklarda, konu aboneliklerinde veya teslim edilemeyen kuyruklarda tutulan iletileri çoğaltmaz. Bu nedenle, ikincil bölgeye sorunsuz bir yük devretme sağlamak için bir azaltma stratejisi gereklidir. Dikkat edilmesi gereken diğer noktaların ve risk azaltma stratejilerinin ayrıntılı açıklaması için dikkate alınacak önemli noktalar ve olağanüstü durum kurtarma konuları belgelerine bakın.

Güvenlik

Güvenlik, kasıtlı saldırılara ve değerli verilerinizin ve sistemlerinizin kötüye kullanılmasına karşı güvence sağlar. Daha fazla bilgi için bkz . Güvenlik sütununa genel bakış.

Gelen trafiği kısıtlama Uygulamayı yalnızca Front Door'dan gelen trafiği kabul etmek üzere yapılandırın. Bu, uygulamaya ulaşmadan önce tüm trafiğin WAF'ye ulaşmasını sağlar. Daha fazla bilgi için bkz. Arka ucuma erişimi yalnızca Azure Front Door'a kilitlemek Nasıl yaparım??

Çıkış Noktaları Arası Kaynak Paylaşımı (CORS) Ayrı uygulamalar olarak bir web sitesi ve web API'si oluşturursanız, CORS'yi etkinleştirmediğiniz sürece web sitesi API'ye istemci tarafı AJAX çağrıları yapamaz.

Uygulama Hizmetleri herhangi bir uygulama kodu yazmaya gerek kalmadan yerleşik CORS desteği sunar. Bkz. CORS kullanarak JavaScript’ten bir API uygulaması kullanma. Web sitesini API için izin verilen çıkış noktaları listesine ekleyin.

şifrelemeyi SQL Veritabanı Veritabanında bekleyen verileri şifrelemeniz gerekiyorsa Saydam Veri Şifrelemesi kullanın. Bu özellik bütün bir veritabanı (yedekler ve işlem günlüğü dosyaları) için gerçek zamanlı şifreleme ve şifre çözme işlemlerini gerçekleştirir ve uygulamada değişiklik yapmayı gerektirmez. Şifreleme biraz gecikme süresi ekler, bu nedenle kendi veritabanında güvenliği sağlanması gereken verileri ayırıp yalnızca bu veritabanı için şifrelemeyi etkinleştirmek iyi bir uygulamadır.

Kimlik Bu mimarideki bileşenler için kimlik tanımlarken, kimlik bilgilerini yönetme gereksiniminizi ve kimlik bilgilerini yönetme risklerini azaltmak için mümkün olduğunda sistem tarafından yönetilen kimlikleri kullanın. Sistem tarafından yönetilen kimlikleri kullanmanın mümkün olmadığı durumlarda, kullanıcı tarafından yönetilen her kimliğin yalnızca bir bölgede olduğundan ve hiçbir zaman bölge sınırları arasında paylaşılmadığından emin olun.

Hizmet güvenlik duvarları Bileşenler için hizmet güvenlik duvarlarını yapılandırırken, hem yalnızca bölge yerel hizmetlerinin hizmetlere erişimi olduğundan hem de hizmetlerin yalnızca çoğaltma ve uygulama işlevselliği için açıkça gerekli olan giden bağlantılara izin ettiğinden emin olun. Daha fazla gelişmiş denetim ve segmentasyon için Azure Özel Bağlantı kullanmayı göz önünde bulundurun. Web uygulamalarının güvenliğini sağlama hakkında daha fazla bilgi için bkz . Temel yüksek oranda kullanılabilir alanlar arası yedekli web uygulaması.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Önbelleğe Alma Sık değişmeyen içeriğe hizmet veren sunuculardaki yükü azaltmak için önbelleğe almayı kullanın. Bir sayfanın her işleme döngüsü işlem, bellek ve bant genişliği tükettiğinden maliyeti etkileyebilir. Bu maliyetler, özellikle JavaScript tek sayfalı uygulamalar ve medya akışı içeriği gibi statik içerik hizmetleri için önbelleğe alma kullanılarak önemli ölçüde azaltılabilir.

Uygulamanızın statik içeriği varsa, ön uç sunuculardaki yükü azaltmak için CDN kullanın. Sık değişmeyen veriler için Redis için Azure Cache kullanın.

Otomatik ölçeklendirme için yapılandırılmış durum bilgisi olmayan uygulamalar, durum bilgisi olan uygulamalardan daha uygun maliyetlidir. Oturum durumunu kullanan bir ASP.NET uygulaması için Redis için Azure Cache ile bellek içinde depolayın. Daha fazla bilgi için bkz. Redis için Azure Cache için oturum durumu sağlayıcısı ASP.NET. Bir diğer seçenek de Azure Cosmos DB'yi bir oturum durumu sağlayıcısı aracılığıyla arka uç durum deposu olarak kullanmaktır. Bkz . Azure Cosmos DB'yi ASP.NET oturum durumu ve önbelleğe alma sağlayıcısı olarak kullanma.

İşlevler Arka plan görevlerinin HTTP isteklerini işleyen aynı örneklerde çalışmaması için bir işlev uygulamasını ayrılmış bir App Service planına yerleştirmeyi göz önünde bulundurun. Arka plan görevleri aralıklı olarak çalıştırılıyorsa, saatlik değil, kullanılan yürütme ve kaynak sayısına göre faturalandırılan bir tüketim planı kullanmayı göz önünde bulundurun.

Daha fazla bilgi için Microsoft Azure İyi Tasarlanmış Çerçeve'nin maliyet bölümüne bakın.

Maliyetleri tahmin etmek için fiyatlandırma hesaplayıcısını kullanın. Bu bölümdeki bu öneriler maliyeti düşürmenize yardımcı olabilir.

Azure Front Door

Azure Front Door faturalaması üç fiyatlandırma katmanına sahiptir: giden veri aktarımları, gelen veri aktarımları ve yönlendirme kuralları. Daha fazla bilgi için bkz. Azure Front Door Fiyatlandırması. Fiyatlandırma grafiği, kaynak hizmetlerden verilere erişme ve Front Door'a aktarma maliyetlerini içermez. Bu maliyetler, Bant Genişliği Fiyatlandırma Ayrıntıları bölümünde açıklanan veri aktarımı ücretlerine göre faturalandırılır.

Azure Cosmos DB

Azure Cosmos DB fiyatlandırması belirleyen iki faktör vardır:

• Sağlanan aktarım hızı veya saniye başına İstek Birimleri (RU/sn).

  Azure Cosmos DB'de standart ve otomatik ölçeklendirme olmak üzere iki tür aktarım hızı sağlanabilir. Standart aktarım hızı, belirttiğiniz RU/sn değerini garanti etmek için gereken kaynakları ayırır. Otomatik ölçeklendirme için maksimum aktarım hızını sağlarsınız ve Azure Cosmos DB yüke bağlı olarak ölçeği anında artırır veya küçültür ve maksimum otomatik ölçeklendirme aktarım hızının en az %10'unu sağlar. Standart aktarım hızı, saatlik sağlanan aktarım hızı için faturalandırılır. Otomatik ölçeklendirme aktarım hızı, saatlik tüketilen maksimum aktarım hızı için faturalandırılır.

• Tüketilen depolama alanı. Veriler için kullanılan toplam depolama alanı (GB) miktarı ve belirli bir saat için dizinler için sabit bir fiyat faturalandırılırsınız.

Daha fazla bilgi için Microsoft Azure İyi Oluşturulmuş Mimari Çerçevesi makalesindeki maliyet bölümüne bakın.

Performans verimliliği

Azure App Service’in önemli bir avantajı uygulamanızı yüküne göre ölçeklendirebilmesidir. Burada, uygulamanızı ölçeklendirmeyi planlarken göz önünde bulundurmanız gereken bazı noktalar verilmiştir.

App Service uygulaması

Çözümünüz birden fazla App Service uygulaması içeriyorsa, bunları ayrı App Service planlarına dağıtmayı göz önünde bulundurun. Ayrı örneklerde çalıştıkları için, bu yaklaşım uygulamaları birbirinden bağımsız olarak ölçeklendirmenizi sağlar.

SQL Veritabanı

SQL veritabanlarını parçalayarak veritabanının ölçeklenebilirliğini artırın. Parçalamak, veritabanını yatay olarak bölümlemek anlamına gelir. Parçalamak, Elastik Veritabanı araçlarını kullanarak veritabanının ölçeğini genişletmenizi sağlar. Parçalamanın olası avantajları şunları içerir:

• Daha iyi işlem aktarım hızı.
• Sorgular verilerin bir alt kümesi üzerinde daha hızlı çalışabilir.

Azure Front Door

Front Door, SSL boşaltma gerçekleştirebilir ve ayrıca arka uç web uygulamasıyla toplam TCP bağlantısı sayısını azaltır. Web uygulaması daha az miktarda SSL el sıkışması ve TCP bağlantısı yönettiğinden bu, ölçeklenebilirliği artırır. Bu performans kazanımları, yüksek bağlantı yeniden kullanımı düzeyi nedeniyle istekleri web uygulamasına HTTPS olarak iletseniz bile geçerlidir.

Azure Search

Azure Search karmaşık veri aramaları gerçekleştirme yükünü birincil veri deposundan kaldırır ve yükü işlemek için ölçeklendirilebilir. Bkz. Azure Search’te iş yüklerini sorgulama ve dizin oluşturma için kaynak düzeylerini ölçeklendirme.

Operasyonel mükemmellik

Operasyonel mükemmellik, bir uygulamayı dağıtan ve üretimde çalışır durumda tutan operasyon süreçlerini ifade eder ve İyi Tasarlanmış Çerçeve Güvenilirliği kılavuzunun bir uzantısıdır. Bu kılavuz, iş yüklerinizin kullanılabilir olduğundan ve herhangi bir ölçekteki hatalardan kurtarıldığından emin olmak için uygulama çerçevenizde dayanıklılık mimarisi oluşturma hakkında ayrıntılı bir genel bakış sağlar. Bu yaklaşımın temellerinden biri, uygulama altyapınızı, bu tasarımda gösterildiği gibi birden çok coğrafi bölgede en uygun şekilde yüksek oranda kullanılabilir olacak şekilde tasarlamaktır.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

• Arvind Boggaram Pandurangaiah Setty | Kıdemli Danışman

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

• Azure Front Door hakkında ayrıntılı bilgi - trafik yönlendirme yöntemleri

• Uç nokta izleme desenlerine göre uygulamanın genel durumunu bildiren sistem durumu yoklamaları oluşturma

• Azure SQL otomatik yük devretme gruplarını etkinleştirme

• Azure Eşleştirilmiş Bölgeleri kullanarak iş sürekliliğini ve olağanüstü durum kurtarmayı sağlama

İlgili kaynaklar

• Çok bölgeli N katmanlı uygulama benzer bir senaryodur. Birden çok Azure bölgesinde çalışan N katmanlı bir uygulamayı gösterir

• Azure uygulamaları için tasarım ilkeleri