Dağıtım DamgaLarı düzeni

Dağıtım damgası düzeni, birden çok iş yükünü veya kiracıyı barındırmak ve çalıştırmak için heterojen bir kaynak grubunun sağlanmasını, yönetilmesini ve izlenmesini içerir. Her bir kopya damga veya bazen hizmet birimi, ölçek birimi veya hücre olarak adlandırılır. Çok kiracılı bir ortamda, her damga veya ölçek birimi önceden tanımlanmış sayıda kiracıya hizmet verebilir. Çözümü neredeyse doğrusal olarak ölçeklendirmek ve artan sayıda kiracıya hizmet vermek için birden çok damga dağıtılabilir. Bu yaklaşım çözümünüzün ölçeklenebilirliğini artırabilir, örnekleri birden çok bölgeye dağıtmanıza ve müşteri verilerinizi ayırmanıza olanak tanır.

Bağlam ve sorun

Bir uygulamayı bulutta barındırırken uygulamanızın performansını ve güvenilirliğini göz önünde bulundurmanız önemlidir. Çözümünüzün tek bir örneğini barındırıyorsanız aşağıdaki sınırlamalara tabi olabilirsiniz:

• Ölçek sınırları. Uygulamanızın tek bir örneğini dağıtmak doğal ölçeklendirme sınırlarına neden olabilir. Örneğin, gelen bağlantı sayısı, ana bilgisayar adları, TCP yuvaları veya diğer kaynakların sayısıyla ilgili sınırları olan hizmetleri kullanabilirsiniz.
• Doğrusal olmayan ölçeklendirme veya maliyet. Çözümünüzün bazı bileşenleri, istek sayısı veya veri miktarıyla doğrusal olarak ölçeklendirilmeyebilir. Bunun yerine, eşik karşılandıktan sonra performansta ani bir düşüş veya maliyet artışı olabilir. Örneğin, bir veritabanı kullanabilir ve daha fazla kapasite eklemenin (ölçeği artırma) marjinal maliyetinin engelleyici hale geldiğini ve ölçeği genişletmenin daha uygun maliyetli bir strateji olduğunu keşfedebilirsiniz.
• Müşteri ayrımı. Belirli müşterilerin verilerini diğer müşterilerin verilerinden yalıtılmış tutmanız gerekebilir. Benzer şekilde, hizmet vermek için diğerlerinden daha fazla sistem kaynağı gerektiren bazı müşterileriniz olabilir ve bunları farklı altyapı kümelerinde gruplandırmayı düşünebilirsiniz.
• Tek ve çok kiracılı örnekleri işleme. Çözümünüzün kendi bağımsız örneklerine ihtiyaç duyan bazı büyük müşterileriniz olabilir. Ayrıca, çok kiracılı bir dağıtımı paylaşabilen daha küçük bir müşteri havuzunuz da olabilir.
• Karmaşık dağıtım gereksinimleri. Güncelleştirmeleri hizmetinize denetimli bir şekilde dağıtmanız ve farklı zamanlarda müşteri tabanınızın farklı alt kümelerine dağıtmanız gerekebilir.
• Güncelleştirme sıklığı. Sisteminizde sık sık güncelleştirmeler yapma konusunda toleranslı olan bazı müşterileriniz olabilirken, bazıları risk almayabilir ve isteklerine hizmet veren sistemde seyrek güncelleştirmeler yapmak isteyebilir. Bu müşterilerin yalıtılmış ortamlara dağıtılmış olması mantıklı olabilir.
• Coğrafi veya jeopolitik kısıtlamalar. Düşük gecikme süresi için mimari yapmak veya veri hakimiyeti gereksinimlerine uymak için bazı müşterilerinizi belirli bölgelere dağıtabilirsiniz.

Bu sınırlamalar genellikle çok kiracılı olacak şekilde tasarlanmış hizmet olarak yazılım (SaaS) oluşturan bağımsız yazılım satıcıları (ISV) için geçerlidir. Ancak, aynı sınırlamalar diğer senaryolar için de geçerli olabilir.

Çözüm

Bu sorunlardan kaçınmak için kaynakları ölçek birimlerinde gruplandırmayı ve damgalarınızın birden çok kopyasını sağlamayı göz önünde bulundurun. Her ölçek birimi kiracılarınızın bir alt kümesini barındırır ve hizmet eder. Damga pulları birbirinden bağımsız olarak çalışır ve bağımsız olarak dağıtılabilir ve güncelleştirilebilir. Tek bir coğrafi bölge tek bir damga içerebilir veya bölge içinde yatay ölçeği genişletmeye olanak sağlayan birden çok damga içerebilir. Damga pulları müşterilerinizin bir alt kümesini içerir.

Dağıtım damgaları, çözümünüzün hizmet olarak altyapı (IaaS) veya hizmet olarak platform (PaaS) bileşenlerini veya her ikisinin bir karışımını kullanması fark eder. Genellikle IaaS iş yüklerinin ölçeklendirilmesi için daha fazla müdahale gerekir, bu nedenle desen IaaS yoğun iş yüklerinde ölçeği genişletmeye olanak sağlamak için yararlı olabilir.

Damgalar dağıtım halkalarını uygulamak için kullanılabilir. Farklı müşteriler farklı sıklıklarda hizmet güncelleştirmeleri almak isterse, farklı damga pulları halinde gruplandırılabilir ve her damga damgasının güncelleştirmeleri farklı tempolarda dağıtılabilir.

Damgalar birbirinden bağımsız olarak çalıştığından, veriler örtük olarak parçalanır. Ayrıca, tek bir damga pulu, damga pulu içinde ölçeklenebilirlik ve esneklik sağlamak için dahili olarak daha fazla parçalama kullanabilir.

Dağıtım damgası deseni App Service, Azure Stack ve Azure Depolama dahil olmak üzere birçok Azure hizmeti tarafından dahili olarak kullanılır.

Dağıtım damgaları coğrafi bölgelerle ilişkilidir ancak coğrafi bölgelerden farklıdır. Dağıtım damgası mimarisinde, sisteminizin birden çok bağımsız örneği dağıtılır ve müşterilerinizin ve kullanıcılarınızın bir alt kümesini içerir. Coğrafi bölgelerde, tüm örnekler herhangi bir kullanıcıdan gelen isteklere hizmet edebilir, ancak bu mimarinin tasarlanıp oluşturulması genellikle daha karmaşıktır. İki deseni tek bir çözüm içinde karıştırmayı da düşünebilirsiniz; bu makalenin devamında açıklanan trafik yönlendirme yaklaşımı , bu tür bir karma senaryoya örnektir.

Dağıtım

Aynı bileşenlerin özdeş kopyalarının dağıtılmasındaki karmaşıklık nedeniyle, iyi DevOps uygulamaları bu deseni uygularken başarılı olmak için kritik öneme sahiptir. Bicep, JSON Azure Resource Manager şablonları (ARM şablonları), Terraform ve betikler gibi altyapınızı kod olarak açıklayın. Bu yaklaşımla, her damga pulu dağıtımının öngörülebilir ve tekrarlanabilir olduğundan emin olabilirsiniz. Ayrıca damga pulları arasındaki yapılandırmada yanlışlıkla uyuşmazlıklar gibi insan hataları olasılığını azaltır.

Güncelleştirmeleri tüm damgalara paralel olarak otomatik olarak dağıtabilirsiniz. Bu durumda altyapınızın ve uygulamalarınızın dağıtımını koordine etmek için Bicep veya Resource Manager şablonları gibi teknolojileri göz önünde bulundurabilirsiniz. Alternatif olarak, güncelleştirmeleri önce aşamalı olarak bazı damga pullarına, sonra da aşamalı olarak başkalarına dağıtabilirsiniz. Her damgaya dağıtımları düzenleme amacıyla Azure Pipelines veya GitHub Actions gibi bir yayın yönetimi aracı kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz.

• Bicep'i Azure Pipelines ile tümleştirme
• JSON ARM şablonlarını Azure Pipelines ile tümleştirme

Dağıtımlarınız için Azure aboneliklerinin ve kaynak gruplarının topolojisini dikkatle göz önünde bulundurun:

• Genellikle bir abonelik tek bir çözüm için tüm kaynakları içerir, bu nedenle genel olarak tüm damgalar için tek bir abonelik kullanmayı göz önünde bulundurun. Bununla birlikte, bazı Azure hizmetleri abonelik genelinde kotalar uygular, bu nedenle bu düzeni yüksek düzeyde ölçeği genişletmeye izin vermek için kullanıyorsanız, farklı abonelikler arasında damgaları dağıtmayı düşünebilirsiniz.
• Kaynak grupları genellikle aynı yaşam döngüsüne sahip bileşenleri dağıtmak için kullanılır. Güncelleştirmeleri tüm damgalarınıza aynı anda dağıtmayı planlıyorsanız, tüm damgalarınızın bileşenlerini içeren tek bir kaynak grubu kullanmayı ve her damgaya ait bileşenleri tanımlamak için kaynak adlandırma kurallarını ve etiketlerini kullanmayı göz önünde bulundurun. Alternatif olarak, güncelleştirmeleri her damgaya bağımsız olarak dağıtmayı planlıyorsanız, her damgayı kendi kaynak grubuna dağıtmayı göz önünde bulundurun.

Kapasite planlaması

Belirli bir damganın barındırabileceği yaklaşık yükü belirlemek için yük ve performans testini kullanın. Yük ölçümleri, tek bir damganın barındırabileceği müşteri/kiracı sayısına veya damga içindeki bileşenlerin yaydığı hizmetlerden alınan ölçümlere bağlı olabilir. Belirli bir damga damgasının kapasitesine yaklaştığını ölçmek için yeterli ölçümlere sahip olduğunuzdan ve talebe yanıt vermek için hızlı bir şekilde yeni damga pulları dağıtabileceğinizden emin olun.

Trafik yönlendirme

Her damga bağımsız olarak ele alındıysa Dağıtım Damgası düzeni düzgün çalışır. Örneğin Contoso aynı API uygulamasını birden çok damgaya dağıtırsa, trafiği ilgili damgaya yönlendirmek için DNS kullanmayı göz önünde bulundurabilir:

• unit1.aus.myapi.contoso.com trafiği Avustralya bölgesinde damgalama unit1 olarak yönlendirir.
• unit2.aus.myapi.contoso.com trafiği Avustralya bölgesinde damgalama unit2 olarak yönlendirir.
• unit1.eu.myapi.contoso.com trafiği Avrupa bölgesi içinde damgalama unit1 olarak yönlendirir.

İstemciler daha sonra doğru damgaya bağlanmakla sorumludur.

Tüm trafik için tek bir giriş noktası gerekiyorsa, belirli bir istek, müşteri veya kiracının damgasını çözümlemek için bir trafik yönlendirme hizmeti kullanılabilir. Trafik yönlendirme hizmeti, istemciyi damga pulu için ilgili URL'ye yönlendirir (örneğin, http 302 yanıt durum kodu kullanarak) veya ters proxy görevi görür ve istemci farkında olmadan trafiği ilgili damgaya iletir.

Merkezi bir trafik yönlendirme hizmeti, özellikle de bir çözüm birden çok bölgede çalıştığında tasarlanması gereken karmaşık bir bileşen olabilir. Trafik yönlendirme hizmetini birden çok bölgeye (damgaların dağıtıldığı her bölge dahil) dağıtmayı ve ardından veri deposunun (kiracıları damgalarla eşleme) eşitlendiğinden emin olun. Trafik yönlendirme bileşeni, coğrafi düzenin bir örneği olabilir.

Örneğin Azure API Management, trafik yönlendirme hizmeti rolünde işlem yapmak için dağıtılabilir. Kiracılar ve damgalar arasındaki eşlemeyi depoladığı bir Azure Cosmos DB koleksiyonundaki verileri arayarak istek için uygun damgayı belirleyebilir. ARDıNDAN API Management, arka uç URL'sini ilgili damganın API hizmetine dinamik olarak ayarlayabilir.

İsteklerin coğrafi olarak dağıtılmasını ve trafik yönlendirme hizmetinin coğrafi olarak yedekliliğini etkinleştirmek için API Management birden çok bölgeye dağıtılabilir veya Azure Front Door trafiği en yakın örneğe yönlendirmek için kullanılabilir. Front Door arka uç havuzuyla yapılandırılabilir ve isteklerin kullanılabilir en yakın API Management örneğine yönlendirilmesini sağlar. Uygulamanız HTTP/S aracılığıyla kullanıma sunulmazsa, gelen çağrıları bölgesel Azure Load Balancer'lara dağıtmak için bölgeler arası Bir Azure Load Balancer kullanabilirsiniz. Azure Cosmos DB'nin genel dağıtım özelliği, eşleme bilgilerini her bölgede güncel tutmak için kullanılabilir.

Çözümünüzde bir trafik yönlendirme hizmeti varsa, bunun bir ağ geçidi görevi yapıp yapmadığını ve bu nedenle belirteç doğrulama, azaltma ve yetkilendirme gibi diğer hizmetler için ağ geçidi boşaltması gerçekleştirip gerçekleştiremeyeceğini göz önünde bulundurun.

Örnek trafik yönlendirme mimarisi

Genel trafik yönlendirmesi için Azure Front Door, Azure API Management ve Azure Cosmos DB kullanan aşağıdaki örnek trafik yönlendirme mimarisini ve ardından bölgeye özgü bir dizi damgayı göz önünde bulundurun:

Bir kullanıcının normalde New York'ta olduğunu varsayalım. Verileri Doğu ABD bölgesindeki 3. damgada depolanır.

Kullanıcı California'ya seyahat eder ve sonra sisteme erişirse, bu istekte bulunduğunda coğrafi olarak en yakın olduğu yer olduğundan, bağlantıları büyük olasılıkla Batı ABD 2 bölgesi üzerinden yönlendirilir. Ancak, verilerin depolandığı yer burası olduğundan, isteğe nihai olarak 3. damga ile hizmet verilmelidir. Trafik yönlendirme sistemi, isteğin doğru damgaya yönlendirilmesini sağlar.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacağınıza karar verirken aşağıdaki noktaları dikkate almalısınız:

• Dağıtım işlemi. Birden çok damga dağıtırken otomatik ve tam olarak tekrarlanabilir dağıtım işlemlerinin olması kesinlikle önerilir. Damgalarınızı bildirimli olarak tanımlamak ve tanımları tutarlı tutmak için Bicep, JSON ARM şablonları veya Terraform modüllerini kullanmayı göz önünde bulundurun.
• Çapraz damga işlemleri. Çözümünüz birden çok damga pulu arasında bağımsız olarak dağıtıldığında, "Tüm pullarımızda kaç müşterimiz var?" gibi soruları yanıtlamak daha karmaşık hale gelebilir. Sorguların her damgada yürütülmesi ve sonuçların toplanması gerekebilir. Alternatif olarak, tüm damgaların verileri birleştirilmiş raporlama için merkezi bir veri ambarına yayımlamasını da göz önünde bulundurun.
• Ölçeği genişletme ilkelerini belirleme. Damga damgaları, damga puluna dağıtılabilir kiracı sayısı gibi bir ara sunucu ölçümü kullanılarak tanımlanabilir sınırlı bir kapasiteye sahiptir. Her damga için kullanılabilir kapasiteyi ve kullanılan kapasiteyi izlemek ve yeni kiracıların kendilerine yönlendirilmesine olanak sağlamak için ek damgaları proaktif olarak dağıtmak önemlidir.
• En az damga sayısı. Dağıtım Damgası desenini kullandığınızda, çözümünüzün en az iki damgasını dağıtmanız önerilir. Yalnızca tek bir damga dağıtıyorsanız, ölçeği genişlettiğinizde uygulanmayacak varsayımları kodunuz veya yapılandırmanıza yanlışlıkla sabit kodla eklemek kolaydır.
• Maliyet. Dağıtım Damgası düzeni, altyapı bileşeninizin birden çok kopyasını dağıtmayı içerir ve bu da büyük olasılıkla çözümünüzü çalıştırma maliyetinde önemli bir artış içerir.
• Pullar arasında hareket ediyor. Her damga bağımsız olarak dağıtılır ve çalıştırılır, bu nedenle kiracıları damga pulları arasında taşımak zor olabilir. Uygulamanızın belirli bir müşteri hakkındaki bilgileri farklı bir damgaya iletmek ve ardından kiracının bilgilerini özgün damgadan kaldırmak için özel mantığa ihtiyacı olacaktır. Bu işlem, damga pulları arasındaki iletişim için bir arka plan gerektirebilir ve genel çözümün karmaşıklığını daha da artırır.
• Trafik yönlendirme. Bu makalenin önceki bölümlerinde açıklandığı gibi, trafiği belirli bir istek için doğru damgaya yönlendirmek, kiracıları damgalara çözümlemek için ek bir bileşen gerektirebilir. Bu bileşenin de yüksek oranda kullanılabilir hale getirilmesi gerekebilir.
• Paylaşılan bileşenler. Damga pulları arasında paylaşılabilen bazı bileşenleriniz olabilir. Örneğin, tüm kiracılar için paylaşılan tek sayfalı bir uygulamanız varsa, bunu tek bir bölgeye dağıtmayı ve genel olarak çoğaltmak için Azure CDN'yi kullanmayı göz önünde bulundurun.

Bu düzenin kullanılacağı durumlar

Bu desen aşağıdaki durumlarda kullanışlıdır:

• Ölçeklenebilirlik için doğal sınırlar. Örneğin, bazı bileşenler belirli sayıda müşteri veya isteğin ölçeğini genişletemiyorsa veya ölçeklendirmemesi gerekiyorsa, damgaları kullanarak ölçeği genişletmeyi göz önünde bulundurun.
• Belirli kiracıları diğerlerinden ayırma gereksinimi. Güvenlik endişeleri nedeniyle diğer müşterilerle birlikte çok kiracılı bir damga puluna dağıtılamayan müşterileriniz varsa, bunlar kendi yalıtılmış damga damgalarına dağıtılabilir.
• Çözümünüzün farklı sürümlerinde aynı anda bazı kiracılara sahip olmanız gerekir.
• Her kiracının verilerinin ve trafiğinin belirli bir bölgeye yönlendirilmesi gereken çok bölgeli uygulamalar.
• Kesintiler sırasında dayanıklılık elde etme isteği. Damga pulları birbirinden bağımsız olduğundan, bir kesinti tek bir damgayı etkilerse, diğer damga damgalarına dağıtılan kiracılar etkilenmemelidir. Bu yalıtım, bir olayın veya kesintinin 'patlama yarıçapını' kapsamaya yardımcı olur.

Bu düzen aşağıdakiler için uygun değildir:

• Yüksek dereceye ölçeklendirilmesi gerekmeyen basit çözümler.
• Uygulama katmanının boyutunu artırarak veya veritabanları ve depolama katmanı için ayrılmış kapasiteyi artırarak tek bir örnek içinde kolayca ölçeği genişletilebilen veya artırılabilir sistemler.
• Verilerin dağıtılan tüm örneklerde çoğaltılması gereken çözümler. Bu senaryo için coğrafi deseni göz önünde bulundurun.
• Yalnızca bazı bileşenlerin ölçeklendirilmesi gereken, ancak diğerlerinin ölçeklendirilmediği çözümler. Örneğin, çözüm bileşenlerinin tümünün yeni bir kopyasını dağıtmak yerine veri deposu parçalanarak çözümünüzün ölçeklendirilip ölçeklendirilemeyeceğini göz önünde bulundurun.
• Yalnızca ön uç JavaScript uygulaması gibi statik içeriklerden oluşan çözümler. Bu tür içerikleri bir depolama hesabında depolamayı ve Azure CDN'yi kullanmayı göz önünde bulundurun.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için dağıtım damgaları deseninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

Destekleyici teknolojiler

• Kod olarak altyapı. Örneğin, Bicep, Resource Manager şablonları, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, trafiği belirli bir damgaya veya trafik yönlendirme hizmetine yönlendirebilir.

Örnek

Aşağıdaki örnek, basit bir PaaS çözümünün birden çok damgasını bir uygulama hizmeti ve her damga pulunda bir SQL Veritabanı ile dağıtır. Damga damgaları şablonda dağıtılan hizmetleri destekleyen herhangi bir bölgede yapılandırılabilir, ancak çizim amacıyla bu şablon Batı ABD 2 bölgesinde iki damga ve Batı Avrupa bölgesinde bir damga daha dağıtır. Bir damga içinde, uygulama hizmeti kendi genel DNS ana bilgisayar adını alır ve diğer tüm damgalardan bağımsız olarak bağlantılar alabilir.

Çözümü dağıtmak için aşağıdaki bağlantıya tıklayın.

Örnek trafik yönlendirme yaklaşımı

Aşağıdaki örnek, bir varsayımsal API uygulaması için dağıtım damgaları kümesiyle kullanılabilecek bir trafik yönlendirme çözümünün uygulamasını dağıtır. Gelen isteklerin coğrafi olarak dağıtılmasını sağlamak için Front Door, tüketim katmanında API Management'ın birden çok örneğiyle birlikte dağıtılır. Her API Management örneği, istek URL'sinden kiracı kimliğini okur ve ardından coğrafi olarak dağıtılmış bir Azure Cosmos DB veri deposundan istek için ilgili damgayı arar. İstek daha sonra ilgili arka uç damgasına iletilir.

Çözümü dağıtmak için aşağıdaki bağlantıya tıklayın.

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:

• John Downs | Asıl Program Yöneticisi

Diğer katkıda bulunanlar:

• Daniel Larsen | Baş Müşteri Mühendisi, Azure için FastTrack
• Angel Lopez | Kıdemli Yazılım Mühendisi, Azure Desenleri ve Uygulamaları
• Paolo Salvatori | Baş Müşteri Mühendisi, Azure için FastTrack
• Arsen Vladimirskiy | Baş Müşteri Mühendisi, Azure için FastTrack

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

İlgili kaynaklar

• Parçalama, veri katmanınızın ölçeğini genişletmek için başka, daha basit bir yaklaşım olarak kullanılabilir. Damgalar verilerini örtük olarak parçalar, ancak parçalama için Dağıtım Damgası gerekmez. Daha fazla bilgi için bkz. Parçalama düzeni.
• Bir trafik yönlendirme hizmeti dağıtılırsa, bu bileşeni en iyi şekilde kullanmak için Ağ Geçidi Yönlendirme ve Ağ Geçidi Boşaltma düzenleri birlikte kullanılabilir.