Azure Spring Apps'i birden çok bölgeye dağıtma

Bu başvuru mimarisi, birden çok Azure Spring Apps örneğini etkin-etkin bir yapılandırmada bölgeler arasında çalıştırma yaklaşımını açıklar.

Bu tasarım, Azure Spring Apps temel mimarisini temel alır. Temel, bir Java Spring Boot uygulamasını tek bir bölge içindeki birden çok kullanılabilirlik alanına dağıtır. Birden çok bölge, iş yükünün Azure bölgesindeki yerel hataları tolere edebilmesi için uygulama iş yükünü ayrı konumlara yayar.

Ancak, bölgenin tamamında bir kesinti yaşanırsa, taban çizgisi kullanıcı tarafından kullanılamaz duruma gelir. Bu tasarımın amacı, bölgesel bir kesintiye dayanabilecek yüksek kullanılabilirlik oluşturmaktır.

Bu mimari aşağıdaki hedefleri karşılamak için kullanışlıdır:

• Uygulamanın genel dayanıklılığını ve hizmet düzeyi hedefini (SLO) artırın.
• Uygulama için genel erişimi etkinleştirin.
• İş yükünü son kullanıcıya yaklaştırın ve gecikme süresini mümkün olduğunca düşük hale getirin.
• Birincil bölge için yük devretme sitesi olarak ikincil bir bölge kullanın ve etkin-pasif bir tasarım tercih edin.

Uygulama dayanıklılığını ve güvenilirliğini artırmak için uygulamayı birden çok bölgeye dağıtabilirsiniz. Bu tasarım için, farklı bölgelerdeki uygulamalarınıza yönelik isteklerin yükünü dengelemek için genel bir yönlendiriciye ihtiyacınız vardır. Bu mimarideki genel yönlendirici diğer hedefleri de ele alır.

Çok bölgeli bir kurulumun en büyük zorluğu, uygulamanızın verilerini birden çok bölge arasında çoğaltmaktır. Bu sorun, çok bölgeli kurulumla ilgili bir sorun değildir. Azure kullanılabilirlik alanları, 2 ms'den kısa bir gidiş dönüş gecikme süresine sahip yüksek performanslı bir ağ ile bağlanır. Bu gecikme süresi çoğu uygulama için yeterlidir.

Mimari

Aşağıdaki diyagramda bu yaklaşımın mimarisi gösterilmiştir:

Bileşenler

Bu mimarinin bileşenleri temel mimariyle aynıdır. Aşağıdaki listede yalnızca temel mimarideki değişiklikler vurgulanır. Azure hizmetleri hakkındaki ürün belgeleri için İlgili kaynaklar bölümüne bakın.

• Azure Front Door genel yük dengeleyici işlevi görür. Bu hizmet, daha düşük gecikme süresi, daha yüksek ölçek ve uçta önbelleğe alma ile daha yüksek kullanılabilirlik sunma özelliği nedeniyle kullanılır.

İş Akışı

Başvuru mimarisi aşağıdaki iş akışını uygular:

1. Kullanıcı, uygulamanın HTTP ana bilgisayar adına gibi www.contoso.combir istek gönderir. Azure DNS, bu ana bilgisayar adı isteğini Azure Front Door'a çözümler.

2. Azure Front Door, gelen istekleri her bölgedeki Azure Uygulaması lication Gateway'in genel uç noktasına iletmek için çeşitli yük dengeleme yapılandırmalarını kullanır. Application Gateway örnekleri, Azure Front Door ile aynı özel etki alanı adı ve TLS sertifika adıyla yapılandırılır.

3. Tümleşik Azure Web Uygulaması Güvenlik Duvarı ile Application Gateway isteği inceler. Web Uygulaması Güvenlik Duvarı yalnızca belirtilen Azure Front Door profilinden gelen isteklere izin verir.

4. Application Gateway, sağlanan Spring Apps örneğinde izin verilen trafiği yük dengeleyicinin IP adresine iletir.

5. İç yük dengeleyici, trafiği yalnızca Application Gateway'den arka uç hizmetlerine yönlendirir. Bu hizmetler, her bölgedeki bir sanal ağ içinde Spring Apps örneğinde barındırılır.

6. İstek işlemenin bir parçası olarak, uygulama sanal ağ içindeki diğer Azure hizmetleriyle iletişim kurar. Örnekler arasında gizli diziler için Azure Key Vault ile iletişim kuran uygulama ve depolama durumu için veritabanı yer alır.

Genel dağıtım

Yüksek kullanılabilirlik için tasarlarsanız, bu mimariyi etkin-etkin, etkin-pasif ve etkin bekleme modunda veya etkin-pasif ve soğuk bekleme modunda ayarlayabilirsiniz.

Seçiminiz uygulamanızın kullanılabilirlik gereksinimlerine bağlıdır. Örnek kuruluş yüksek çalışma süresi SLA'sına (Hizmet Düzeyi Sözleşmesi) sahip genel bir varlık sahibi olmak istediği için bu mimari iki bölgede etkin-etkin dağıtım kullanır. Görev açısından kritik uygulamalar çalıştırıyorsanız ve daha yüksek kullanılabilirlik istiyorsanız ikiden fazla bölge kullanmanız gerekir.

Aktif-aktif

Etkin-etkin modda, tüm bölgeler istekleri aynı anda işler. Etkin-etkin modun en büyük zorluğu, bölgeler arasında veri eşitlemesini korumaktır. Neredeyse tüm bileşenler için iki kez ödeme yaptığınız için bu mod maliyetli bir yaklaşımdır.

Etkin bekleme ile aktif-pasif

Etkin-pasif modda etkin bekleme modunda, birincil bölge etkin olduğu sürece ikincil bölge Azure Front Door'dan herhangi bir istek almaz. Uygulama verilerinizi birincil bölgenizden ikincil bölgenize çoğaltdığınızdan emin olun. Birincil bölgenizde bir hata oluşursa arka uç veritabanlarınızın rollerini değiştirmeniz ve Azure Front Door üzerinden tüm trafiği ikincil bölgenize devretmeniz gerekir.

Etkin-pasif modda yük devretmenin biraz zaman alması beklenir ve bu da tüm verilerin eşitlenmiş kalmasını kolaylaştırır. Ancak etkin bekleme modunda etkin-pasif mod, etkin-etkin modla çalışmak kadar maliyetlidir.

Soğuk bekleme ile aktif-pasif

Etkin-pasif modda soğuk bekleme modunda birincil bölge tüm kaynaklara sahiptir ve trafiğe hizmet eder. İkincil bölge daha az bileşene veya daha düşük işlem kaynağına sahip bileşenlere sahip olabilir. Teknoloji seçenekleri, iş gereksinimlerine göre ne kadar kapalı kalma süresinin kabul edilebilir olduğuna bağlıdır. İkincil bölge kurulumunuzun kapsamı maliyetleri de etkiler. en azından uygulama verilerinin ikincil bölgede bulunduğundan emin olun.

Belirtildiği gibi, etkin-pasif mod biraz zaman alan yük devretmeyi içerir, bu nedenle tüm verileri eşitlenmiş halde tutmak daha kolaydır. Tüm kaynakları her iki bölgeye de dağıtmadığınız için en uygun maliyetli yaklaşım, soğuk bekleme ile etkin-pasif moddur.

Çözüm kurulumunuzun tamamında şablonlar kullanılıyorsa, kaynakları gerektiği gibi oluşturarak soğuk bekleme ikincil bölgesini kolayca dağıtabilirsiniz. Terraform, Bicep veya Azure Resource Manager şablonlarını kullanabilir ve sürekli tümleştirme/sürekli dağıtım (CI/CD) işlem hattında altyapı kurulumunu otomatikleştirebilirsiniz. Şablonlarınızın acil bir durumda dağıtılabilir olduğundan emin olmak için ikincil bölgenizi yeniden oluşturarak yapılandırmanızı düzenli olarak test etmelisiniz.

Bir uygulamanın veya bileşenin birden çok bağımsız kopyası tek bir şablondan birden çok bölgeye dağıtılabildiğinden dağıtım damgaları deseni önerilir.

Mod karşılaştırması

Aşağıdaki tablo, her mod için verileri eşitlemek için gereken çabayı özetler ve maliyeti karşılaştırır.

Bölgeler arasında yönlendirme

Bu başvuru mimarisi, herhangi bir bölgenin herhangi bir isteği karşıladığı coğrafi düğümleri (Geodes) kullanır.

Azure Front Door, iki dağıtım bölgesi arasında eşit yönlendirmeyle yapılandırılır. Azure Front Door ayrıca çıkış noktası için başka trafik yönlendirme yöntemleri de sağlar. İstemcileri en yakın kaynaklarına yönlendirmek istiyorsanız gecikme süresi tabanlı yönlendirme en mantıklı yol olur. Etkin-pasif bir çözüm tasarlarsanız, öncelik tabanlı yönlendirme daha uygundur.

Başvuru mimarisi örneği, iki bölge arasında eşit ağırlıkta bir yük dengeleme kuralı kullanır. Azure Front Door şu şekilde yapılandırılır:

• Gibi www.contoso.comuygulama ana bilgisayar adıyla aynı ada sahip bir özel etki alanı ve aktarım katmanı güvenliği (TLS) sertifikası.

• Uygulamanın dağıtıldığı bölge başına bir çıkış noktası, burada her çıkış noktası bir Azure Uygulaması lication Gateway örneğidir.

Kaynak grubu düzeni

Her bölgeye tek bir koleksiyon olarak dağıtılan kaynakları yönetmek için Azure kaynak gruplarını kullanın. Aşağıdaki diyagramda gösterildiği gibi birincil bölgeyi, ikincil bölgeyi ve Azure Front Door'ı ayrı kaynak gruplarına yerleştirmeyi göz önünde bulundurun:

Diyagramda kaynak gruplarının aşağıdaki yapılandırması gösterilmektedir:

• Azure Front Door kaynak grubunda dağıtılır Application-shared .
• Batı Avrupa bölgesinde (weu) barındırılan tüm kaynaklar kaynak grubunda dağıtılır Application-weu .
• Doğu ABD bölgesinde (eus) barındırılan kaynaklar kaynak grubunda barındırılır Application-eus .
• Doğu Japonya bölgesinde (jae) barındırılan kaynaklar kaynak grubunda barındırılır Application-jae .

Aynı kaynak grubundaki kaynaklar aynı yaşam döngüsünü paylaşır ve birlikte kolayca oluşturulup silinebilir. Her bölgenin, bölge adına dayalı bir adlandırma kuralına uygun ayrılmış bir kaynak grubunda kendi kaynak kümesi vardır. Azure Front Door kendi kaynak grubundadır çünkü başka bölgeler eklendiğinde veya kaldırıldığında bile mevcut olması gerekir.

Ters proxy kurulumu

Azure Front Door, bölgeler arasında genel yük dengelemesi yapar. Bu ters ara sunucu, bir iş yükünü birden çok bölgeye dağıtırsanız trafiğin dağıtılmasına yardımcı olur. Alternatif olarak Azure Traffic Manager'ı kullanabilirsiniz. Traffic Manager, yalnızca etki alanı düzeyinde yük dengeleyen DNS tabanlı bir trafik yük dengeleyicidir.

Azure Front Door, Microsoft'un küresel uç ağından içerik teslim eden tümleşik içerik teslim ağlarına (CDN' ler) sahiptir ve dünyanın dört bir yanına dağıtılmış iletişim noktaları (PoP'ler) vardır.

Geçerli çözüm, temel mimariyle tutarlılığı korumak için iki ters proxy kullanır. Azure Front Door genel yönlendiricidir. Application Gateway, bölge başına yük dengeleyici işlevi görür. Çoğu durumda bu kurulum gerekli değildir. Aşağıdaki gereksinimleri karşılıyorsanız Application Gateway'i kaldırabilirsiniz:

• Azure Web Uygulaması Güvenlik Duvarı Application Gateway'e bağlı olduğundan bunun yerine Azure Front Door hizmetine Web Uygulaması Güvenlik Duvarı eklemeniz gerekir.
• Gelen çağrıların yalnızca Azure Front Door örneğinizden kaynaklanmasını sağlamak için bir yönteme ihtiyacınız vardır. Spring Cloud Gateway uygulamasında denetimi ve Azure Front Door IP aralıkları denetimini ekleyebilirsiniz X-Azure-FDID header . Daha fazla bilgi için bkz . Spring Cloud Gateway ile ters ara sunucu olarak Azure Front Door kullanma.

Farklı ters ara sunucu senaryoları, bunların nasıl ayarlanacağı ve güvenlik konuları hakkında bilgi için bkz . Azure Spring Apps'i ters ara sunucu aracılığıyla kullanıma sunma.

Arka uç veritabanı

Çok bölgeli dağıtım için bir veri çoğaltma stratejiniz olması gerekir. Uygulama bölgeler arasında kullanılabilir olduğunda, kullanıcıların eski verileri görmemesi için verilerin eşitlenmesi gerekir.

Geçerli mimaride arka uç veritabanı için bir MySQL veritabanı kullanılır, ancak bu yapılandırma veri eşitlemeyi ele almaz. Bir veritabanı teknolojisi seçtiğinizde, bölgeler arasında verileri en iyi şekilde çoğaltmayı ve eşitlemeyi denetleyin. Bir seçenek, birincil veritabanı için sürekli eşitlenmiş, okunabilir bir ikincil veritabanı sağlayan etkin bir coğrafi çoğaltma özelliğine sahip olan Azure SQL Veritabanı.

Bu özelliği aşağıdaki senaryolarda kullanabilirsiniz:

• İkincil bölgeniz etkin istek almayan soğuk bir bekleme durumundaysa
• Birincil bölgeniz başarısız olursa yük devretme yapmak için
• İki bölge arasındaki sanal ağ eşlemesi aracılığıyla kendi bölgelerine özel bağlantı bağlantıları olan birincil ve ikincil veritabanlarını ayarlamak için.

Bir diğer yaklaşım da Azure Cosmos DB'yi kullanmaktır. Bu hizmet, verileri Azure Cosmos DB hesabınızdaki tüm bölgelere saydam bir şekilde çoğaltarak verileri genel olarak dağıtabilir. Azure Cosmos DB'yi birden çok yazma bölgesiyle de yapılandırabilirsiniz. Daha fazla bilgi için bkz . Coğrafi düzen.

Otomatik dağıtım

Altyapı dağıtımınızı ve uygulama kodu dağıtımlarınızı mümkün olduğunca otomatikleştirin.

Altyapı dağıtımlarının otomatikleştirilmesi, altyapının aynı şekilde yapılandırılmasını garanti eder ve bu da bölgeler arasında olduğu gibi yapılandırma kaymasını önlemeye yardımcı olur. Altyapı otomasyonu yük devretme işlemlerini de test edebilir.

Uygulama dağıtımı için dağıtım sistemlerinizin dağıtılması gereken birden çok bölgeyi hedeflediğinden emin olun. Mavi-yeşil veya kanarya dağıtım stratejisinde birden çok bölge de kullanabilirsiniz. Bu dağıtım stratejileriyle, test için bir bölgeye ve test başarılı olduktan sonra diğer bölgelere uygulamaların yeni sürümlerini dağıtacaksınız.

Performans ve Ölçeklenebilirlik   

Bu mimari, yükü bölgelere yaydığı için uygulama taleplerini karşılamak için temel mimariden daha uygundur. Azure Front Door'ı istekleri gecikme süresine göre yönlendirecek şekilde yapılandırdığınızda, istekler kendilerine en yakın bölgelere yönlendirildiği için kullanıcılar daha iyi yanıt süreleri elde eder.

Veritabanı kurulumunuza bağlı olarak, veriler bölgeler arasında eşitlenmesi gerektiğinde fazladan gecikme süresine neden olabilirsiniz. Daha rahat bir tutarlılık düzeyiyle Azure Cosmos DB kullanarak bu gecikme süresini aşabilirsiniz.

Bu başvuru mimarisinde ölçümlere göre otomatik ölçeklendirme yapabilecek çeşitli bileşenler vardır:

• Azure Front Door isteğe bağlı olarak otomatik ölçeklendirme yapabilir. Varlıkları son kullanıcılarınıza yakınlaştırmak için trafik hızlandırma ve önbelleğe alma özellikleri gibi diğer Azure Front Door özelliklerini kullanabilirsiniz.
• Application Gateway otomatik ölçeklendirmeyi destekler. Daha fazla bilgi için bkz. Application Gateway v2 ve Web Uygulaması Güvenlik Duvarı v2'yi ölçeklendirme.
• Azure Spring Apps otomatik ölçeklendirmeyi de destekler. Daha fazla bilgi için bkz . Uygulamalar için otomatik ölçeklendirmeyi ayarlama.

Maliyetle ilgili konular

Bu çözüm, temel mimarinin maliyet tahminlerini etkili bir şekilde ikiye katlar.

Çok bölgeli çözümle ilişkili maliyetlerin başlıca etmenleri şunlardır:

• Birincil ve ikincil veritabanları aynı hizmet katmanını kullanmalıdır; aksi takdirde, ikincil veritabanı çoğaltma değişikliklerine ayak uyduramayabilir.
• Bölgeler arası önemli trafik maliyetleri artırır. Azure bölgeleri arasındaki ağ trafiği ücrete tabi olur.

Bu maliyetleri yönetmek için uygulamanız için şu önerileri göz önünde bulundurun:

• Bekleme bölgesinde Azure Spring Apps ve Application Gateway gibi kaynakların ölçeği azaltılmış sürümlerini kullanın ve kaynakların ölçeğini yalnızca bekleme etkin olduğunda büyütün.
• İş senaryolarınız izin verirse maliyetlerden tasarruf etmek için etkin-pasif bir kurulum oluşturun.
• Kullanılabilirlik ve dayanıklılık iş gereksinimlerini karşılamak için tek bir bölgede çok bölgeli bir kurulum uygulayın. Çoğu kaynak için yalnızca bir kez ödeme yaptığınız için bu seçenek daha uygun maliyetli olabilir.
• Maliyetlerden tasarruf etmeye yardımcı olmak için yalnızca bir ters ara sunucu kullanan alternatif kurulumu seçin. Bu alternatifin güvenliğini sağlamak için ek yapılandırma uygulamanız gerektiğini unutmayın.

Küçük ölçekli bir uygulama için makul varsayılan değerleri kullanarak Azure fiyatlandırma hesaplayıcısı ile bu mimarideki hizmetlerin maliyetini tahmin ettik. Bu tahmini, uygulamanız için beklenen aktarım hızı değerlerine göre güncelleştirebilirsiniz.

Dikkat edilecek diğer noktalar

Çok bölgeli temel mimarinin tasarım konuları, bu makalede açıklanan çok bölgeli çözüm için de geçerlidir. Çok bölgeli mimari bağlamında aşağıdaki noktaları gözden geçirin:

• Ağ güvenliği. Ağ üzerinden iletişimi denetlemek önemlidir. Bu çözüm, çağrıların her bölgedeki Application Gateway'e yönlendirildiği yalnızca Azure Front Door'dan gelen çağrılara izin verir. Application Gateway'den çağrılar arka uç Azure Spring Apps hizmetine yönlendirilir. Azure Spring Apps'ten Key Vault gibi destekleyici hizmetlere yönelik iletişim de özel uç noktalar kullanılarak denetlenmektedir. Daha fazla bilgi için bkz . Temel mimari: Ağ güvenliği.

• Kimlik ve erişim yönetimi. Farklı bileşenler arasında bağlanmak için yönetilen kimlikleri kullanarak daha güvenli erişim uygulayın. Azure Spring Apps'in Key Vault'a bağlanmak için yönetilen kimliği nasıl kullandığına örnek olarak gösterilebilir. Daha fazla bilgi için bkz . Temel mimari: Kimlik ve erişim yönetimi.

• İzleme. Uygulamadan veri toplamak için izleme ekleyebilir ve dağıtılmış izlemeyi etkinleştirebilirsiniz. Uygulamanızla ilgili uçtan uca içgörüler elde etmek için bu veri kaynağını platform tanılamalarıyla birleştirin. Daha fazla bilgi için bkz . Temel mimari: İzleme.

• Gizli dizi yönetimi. Çok bölgeli çözüm, uygulama gizli dizilerini ve sertifikalarını tek bir anahtar kasasında depolar. Daha fazla bilgi için bkz . Temel mimari: Gizli dizi yönetimi.

Senaryo dağıtımı

Bu başvuru mimarisi için bir dağıtım, GitHub'daki Azure Spring Apps çok bölgeli başvuru mimarisinde kullanılabilir. Dağıtımda Terraform şablonları kullanılır.

Mimariyi dağıtmak için adım adım yönergeleri izleyin.

Katkıda Bulunanlar

Microsoft bu içeriği korur. Aşağıdaki katkıda bulunan özgün içeriği geliştirdi.

Asıl yazar:

• Gitte Vermeiren | Azure Mühendisi için FastTrack

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

Sonraki adımlar

Bu iş yükünü kuruluşunuzdaki merkezi ekipler tarafından yönetilen paylaşılan hizmetlerle tümleştirmek için azure uygulama giriş bölgesine dağıtın.

İlgili kaynaklar

Bu mimaride kullanılan Azure hizmetleri ve özellikleriyle ilgili belgeler için aşağıdaki makalelere bakın:

• Azure Spring Apps
• Azure Front Door
• Azure Uygulaması lication Gateway v2
• MySQL için Azure Veritabanı
• Azure Key Vault
• Azure DNS
• Azure Web Uygulaması Güvenlik Duvarı
• Azure Özel Bağlantı
• Azure kaynakları için Microsoft Entra yönetilen kimlikleri

Bu mimariyle ilgili yapılandırma seçenekleri hakkında daha ayrıntılı bilgi edinmek için aşağıdaki kılavuzları öneririz:

• Ters ara sunucu aracılığıyla Azure Spring Apps'i kullanıma sunma
• Uygulamalar için yüksek kullanılabilirlik mavi/yeşil dağıtım
• Ters proxy ile arka uç web uygulaması arasında özgün HTTP ana bilgisayar adını koruma

Bu mimari, Microsoft Azure İyi Tasarlanmış Çerçeve'nin sütunlarıyla uyumlu olarak tasarlanmıştır. Her sütun için tasarım ilkelerini gözden geçirmenizi öneririz.