Aracılığıyla paylaş

Çok kiracılı çözümlerde işlem için mimari yaklaşımlar

  • Makale

Bulut tabanlı çözümlerin çoğu web ve uygulama katmanları, toplu işlemciler, zamanlanmış işler ve hatta GPU'lar ve yüksek performanslı işlem (HPC) gibi özel kaynaklar gibi bir tür işlem kaynağından oluşur. Çok kiracılı çözümler genellikle paylaşılan işlem kaynaklarından yararlanır, çünkü kiracıların altyapıya olan yoğunluğu operasyonel maliyeti ve yönetimi azaltır. Yalıtım gereksinimlerini ve paylaşılan altyapının etkilerini dikkate almanız gerekir.

Bu makalede, çözüm mimarlarının çok kiracılı bir işlem katmanı planlarken dikkate almaları gereken önemli noktalar ve gereksinimler hakkında rehberlik sağlanmaktadır. Bu, işlem hizmetlerine çok kiracılılık uygulamak için bazı yaygın desenlerin yanı sıra kaçınılması gereken bazı kötü modelleri içerir.

Önemli noktalar ve gereksinimler

Çok kiracılılık ve seçtiğiniz yalıtım modeli, işlem kaynaklarınızın ölçeklendirmesini, performansını, durum yönetimini ve güvenliğini etkiler. Bu bölümde, çok kiracılı bir işlem çözümü planlarken yapmanız gereken bazı önemli kararları gözden geçireceğiz.

Ölçek

Sistemlerin değişen talep altında yeterli performans göstermeleri gerekir. Kiracı sayısı ve trafik miktarı arttıkça, artan kiracı sayısına ayak uydurmak ve kabul edilebilir bir performans oranını korumak için kaynaklarınızın kapasitesini artırmanız gerekebilir. Benzer şekilde, etkin kullanıcı sayısı veya trafik miktarı azaldığında maliyetleri azaltmak için işlem kapasitesini otomatik olarak azaltmanız gerekir, ancak kullanıcıları en az etkile kapasiteyi azaltmanız gerekir.

Her kiracı için ayrılmış kaynaklar dağıtırsanız, her kiracının kaynaklarını bağımsız olarak ölçeklendirme esnekliğine sahip olursunuz. İşlem kaynaklarının birden çok kiracı arasında paylaşıldığı bir çözümde, bu kaynakları ölçeklendirirseniz, bu kiracıların tümü yeni ölçeği kullanabilir. Ancak, ölçek genel yüklerini işlemek için yetersiz olduğunda da hepsi zarar görür. Daha fazla bilgi için bkz . Gürültülü Komşu sorunu.

Bulut çözümleri oluştururken, yatay veya dikey olarak ölçeklendirmeyi seçebilirsiniz. Kiracı sayısı artan çok kiracılı bir çözümde, yatay ölçeklendirme genellikle size daha fazla esneklik ve daha yüksek bir genel ölçek tavanı sağlar.

Performans sorunları genellikle bir uygulama yük altında kalana kadar algılanmadan kalır. Uygulamanızın stres altında nasıl davrandığını öğrenmek için Azure Yük Testi gibi tam olarak yönetilen bir hizmet kullanabilirsiniz.

Ölçek tetikleyicileri

Ölçeklendirmek için hangi yaklaşımı kullanırsanız kullanın, genellikle bileşenlerinizin ölçeklendirilmesine neden olan tetikleyicileri planlamanız gerekir. Paylaşılan bileşenleriniz olduğunda, sağlanan kapasitenizin toplam gerekli kapasiteyi karşılayabilmesini sağlamak ve bir kiracının Gürültülü Komşu sorununu yaşama olasılığını en aza indirmek için kaynakları kullanan her kiracının iş yükü desenlerini göz önünde bulundurun. Ayrıca kiracı sayısını göz önünde bulundurarak ölçeklendirme kapasitenizi de planlayabilirsiniz. Örneğin, 100 kiracıya hizmet vermek için kullandığınız kaynakları ölçerseniz, daha fazla kiracı ekledikçe, her ek 100 kiracı için kaynaklarınızın iki katı olacak şekilde ölçeklendirmeyi planlayabilirsiniz.

Durum

İşlem kaynakları durum bilgisi olmayan veya durum bilgisi olan kaynaklar olabilir. Durum bilgisi olmayan bileşenler istekler arasında veri tutmaz. Ölçeklenebilirlik açısından bakıldığında durum bilgisi olmayan bileşenlerin ölçeği genellikle kolayca genişletilebilir çünkü yeni çalışanları, örnekleri veya düğümleri hızla ekleyebilir ve istekleri işlemeye hemen başlayabilirler. Mimariniz buna izin veriyorsa, bir kiracıya atanan örnekleri de yeniden kullanabilir ve bunları başka bir kiracıya ayırabilirsiniz.

Durum bilgisi olan kaynaklar, korudukları durum türüne göre daha fazla alt bölümlere bölünebilir. Kalıcı durum , kalıcı olarak depolanması gereken verilerdir. Bulut çözümlerinde işlem katmanınızda kalıcı bir durum depolamaktan kaçınmanız gerekir. Bunun yerine veritabanları veya depolama hesapları gibi depolama hizmetlerini kullanın. Geçici durum , geçici olarak depolanan verilerdir ve salt okunur bellek içi önbellekleri ve geçici dosyaların yerel disklerde depolanmasını içerir.

Geçici durum genellikle arka uç depolama hizmetlerine yönelik istek sayısını azaltarak uygulama katmanınızın performansını geliştirmek için yararlıdır. Örneğin, bellek içi önbellek kullandığınızda, bir veritabanına bağlanmadan ve başka bir istekte bulunurken son zamanlarda gerçekleştirdiğiniz yoğun bir sorguyu gerçekleştirmeden okuma isteklerine hizmet edebilirsiniz.

Gecikme süresine duyarlı uygulamalarda önbellek hidrasyonunun maliyeti önemli hale gelebilir. Her kiracı farklı verilerin önbelleğe alınmasını gerektiriyorsa, çok kiracılı bir çözüm bu sorunu daha da büyütebilir. Bu sorunu azaltmak için bazı çözümler, belirli bir kullanıcı veya kiracıya yönelik tüm isteklerin aynı işlem çalışanı düğümü tarafından işlenmesini sağlamak için oturum benzini kullanır. Oturum benzitesi, uygulama katmanının önbelleğini etkili bir şekilde kullanabilme becerisini geliştirse de, çalışanlar arasında trafik yükünü ölçeklendirmeyi ve dengelemeyi de zorlaştırır. Bu dengenin dikkatli bir şekilde düşünülmesi gerekiyor. Birçok uygulama için oturum benzitesi gerekli değildir.

Verileri Redis için Azure Cache gibi dış önbelleklerde depolamak da mümkündür. Dış önbellekler düşük gecikme süreli veri alma için iyileştirilirken, durumu işlem kaynaklarından yalıtılmış durumda tutarak ölçeklendirilebilir ve ayrı ayrı yönetilebilir. Birçok çözümde dış önbellekler, işlem katmanını durum bilgisi olmayan tutarken uygulama performansını geliştirmenize olanak tanır.

Önemli

Bellek içi önbellekleri veya durumu koruyan diğer bileşenleri her kullandığınızda kiracılar arasında veri sızıntısından kaçının. Örneğin, her kiracı için verilerin ayrıldığından emin olmak için kiracı tanımlayıcısını tüm önbellek anahtarlarına önceden bağlamayı göz önünde bulundurun.

Yalıtım

Çok kiracılı bir işlem katmanı tasarlarken, paylaşılan işlem kaynaklarını dağıtma, tüm kiracılar tarafından kullanılacak paylaşılan işlem kaynakları, her kiracı için ayrılmış işlem kaynakları veya bu uç değerler arasında bir şey dahil olmak üzere kiracılar arasındaki yalıtım düzeyi için dikkate almanız gereken birçok seçenek vardır. Her seçenek, avantajlı olarak gelir. Çözümünüz için en uygun seçeneği belirlemenize yardımcı olmak için yalıtım gereksinimlerinizi göz önünde bulundurun.

Kiracıların mantıksal yalıtımı ve her kiracıya uygulanan yönetim sorumluluklarının veya ilkelerinin nasıl ayrılacağı konusunda endişeniz olabilir. Alternatif olarak, belirli kiracılar için belirli bir sanal makine SKU'su bir kiracının iş yüküne uyacak şekilde dağıtma gibi farklı kaynak yapılandırmaları dağıtmanız gerekebilir.

Hangi yalıtım modelini seçerseniz seçin, bileşenler kullanılamadığında veya arızalı olduğunda bile kiracı verilerinizin uygun şekilde yalıtılmış durumda kaldığından emin olun. Azure Chaos Studio'yu normal otomatik test sürecinizin bir parçası olarak kullanarak gerçek dünyadaki kesintilerin benzetimini yaparak hatalara neden olabilir ve çözümünüzün kiracılar arasında veri sızdırmadığını ve baskı altında bile düzgün çalıştığını doğrulayabilirsiniz.

Dikkate alınacak yaklaşımlar ve desenler

Otomatik Ölçeklendirme

Azure işlem hizmetleri, iş yüklerinizi ölçeklendirmek için farklı özellikler sağlar. Birçok işlem hizmeti otomatik ölçeklendirmeyi destekler. Bu, ne zaman ölçeklendirmeniz gerektiğini ve en düşük ve en yüksek ölçek düzeylerinizi göz önünde bulundurmanızı gerektirir. Ölçeklendirme için kullanılabilen belirli seçenekler, kullandığınız işlem hizmetlerine bağlıdır. Aşağıdaki örnek hizmetlere bakın:

Dağıtım DamgaLarı düzeni

Dağıtım DamgaLarı düzeninin çok kiracılı bir çözümü desteklemek için nasıl kullanılabileceğini öğrenmek için bkz. Genel Bakış.

İşlem Kaynağı Birleştirme düzeni

İşlem Kaynağı Birleştirme düzeni, temel alınan işlem kaynaklarını paylaşarak işlem altyapısında daha yüksek bir kiracı yoğunluğu elde etmeye yardımcı olur. İşlem kaynaklarını paylaşarak genellikle bu kaynakların doğrudan maliyetini azaltabilirsiniz. Ayrıca, yönetecek daha az bileşen olduğundan yönetim maliyetleriniz genellikle daha düşüktür.

Ancak işlem kaynağı birleştirme, Gürültülü Komşu sorununun olasılığını artırır. Herhangi bir kiracının iş yükü, kullanılabilir işlem kapasitesinin orantısız bir miktarını tüketebilir. Genellikle çözümünüzü uygun şekilde ölçeklendirerek ve kotalar ve API sınırları gibi denetimler uygulayarak, kiracıların kapasiteden eşit paylarından daha fazlasını tüketmesini önleyerek bu riski azaltabilirsiniz.

Bu desen, kullandığınız işlem hizmetine bağlı olarak farklı şekillerde elde edilir. Aşağıdaki örnek hizmetlere bakın:

  • Azure Uygulaması Hizmeti ve Azure İşlevleri: Barındırma sunucusu altyapısını temsil eden paylaşılan App Service planlarını dağıtın.
  • Azure Container Apps: Paylaşılan ortamları dağıtma.
  • Azure Kubernetes Service (AKS):Çok kiracılı bir uygulamayla paylaşılan podları dağıtın.
  • Sanal makineler: Tüm kiracıların kullanması için tek bir sanal makine kümesi dağıtın.

Kiracı başına ayrılmış işlem kaynakları

Ayrıca her kiracı için ayrılmış işlem kaynakları dağıtabilirsiniz. Ayrılmış kaynaklar, her kiracı için işlem kaynaklarının diğerlerinden yalıtıldığından emin olarak Gürültülü Komşu sorununun riskini azaltır. Ayrıca, her kiracının kaynakları için kendi gereksinimlerine göre ayrı bir yapılandırma dağıtmanıza da olanak tanır. Ancak, kiracıların kaynaklara olan yoğunluğu daha düşük olduğundan ayrılmış kaynaklar genellikle daha yüksek maliyetle gelir.

Kullandığınız Azure işlem hizmetlerine bağlı olarak, aşağıdaki gibi farklı ayrılmış kaynaklar dağıtmanız gerekir:

  • Azure Uygulaması Hizmeti ve Azure İşlevleri: Her kiracı için ayrı App Service planları dağıtın.
  • Azure Container Apps: Her kiracı için ayrı ortamlar dağıtın.
  • Azure Kubernetes Service (AKS):Her kiracı için ayrılmış kümeler dağıtın.
  • Sanal makineler: Her kiracı için ayrılmış sanal makineler dağıtın.

Yarı yalıtılmış işlem kaynakları

Yarı yalıtılmış yaklaşımlar, diğer bileşenleri paylaşırken çözümün özelliklerini yalıtılmış bir yapılandırmada dağıtmanızı gerektirir.

App Service ve Azure İşlevleri ile çalışırken, her kiracı için ayrı uygulamalar dağıtabilir ve uygulamaları paylaşılan App Service planlarında barındırabilirsiniz. App Service planları faturalama birimini temsil ettiğinden bu yaklaşım işlem katmanınızın maliyetini azaltır. Ayrıca her uygulamaya ayrı yapılandırma ve ilkeler uygulamanıza olanak tanır. Ancak, bu yaklaşım Gürültülü Komşu sorununun riskini ortaya taşır.

Azure Container Apps, paylaşılan bir ortama birden çok uygulama dağıtmanıza ve sonra da her uygulamayı ayrı ayrı yapılandırmak için Dapr ve diğer araçları kullanmanıza olanak tanır.

Azure Kubernetes Service (AKS) ve Kubernetes daha geniş kapsamlı bir şekilde çok kiracılılık için aşağıdakiler de dahil olmak üzere çeşitli seçenekler sağlar:

  • Paylaşılan kümelere ve düğüm havuzlarına dağıtılan kiracıya özgü kaynakların mantıksal yalıtımı için kiracıya özgü ad alanları.
  • Paylaşılan kümedeki kiracıya özgü düğümler veya düğüm havuzları.
  • Aynı düğüm havuzunu kullanabilen kiracıya özgü podlar.

AKS ayrıca Gürültülü Komşu sorununu azaltmak için pod düzeyinde idare uygulamanızı sağlar. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) kaynakları yönetmek için uygulama geliştiricilerine yönelik en iyi yöntemler.

Bir Kubernetes kümesindeki paylaşılan bileşenleri ve bu bileşenlerin çok kiracılı durumdan nasıl etkilenebileceğini bilmeniz de önemlidir. Örneğin Kubernetes API sunucusu, kümenin tamamında kullanılan paylaşılan bir hizmettir. Kiracıların uygulama iş yüklerini yalıtmak için kiracıya özgü düğüm havuzları sağlasanız bile, API sunucusu kiracılar genelinde çok sayıda istekten kaynaklanan çekişmelerle karşılaşabilir.

Kaçınılması gereken kötü amaçlı değişkenler

Gürültülü Komşu kötü modeli

Kiracılar arasında paylaşılan bileşenleri her dağıttığınızda, Gürültülü Komşu sorunu olası bir risktir. Bir kiracının işlem iş yükünün diğer kiracıların etkinliğinden etkilenme riskini azaltmak için kaynak idaresi ve izleme dahil olduğunuzdan emin olun.

Kiracılar arası veri sızıntısı

İşlem katmanları düzgün işlenmediyse kiracılar arası veri sızıntısına maruz kalabiliyor. Bu genellikle Azure'da çok kiracılı bir hizmet kullanırken göz önünde bulundurmanız gereken bir şey değildir çünkü Microsoft platform katmanında koruma sağlar. Ancak, kendi çok kiracılı uygulamanızı geliştirirken, paylaşılan kaynakların (yerel disk önbellekleri, RAM ve dış önbellekler gibi) başka bir kiracının yanlışlıkla görüntüleyebileceği veya değiştirebileceği veriler içerip içermeyebileceğini göz önünde bulundurun.

Meşgul Ön Uç kötü modeli

Meşgul Ön Uç kötü modelinden kaçınmak için, ön uç katmanınızın mimarinizin diğer bileşenleri veya katmanları tarafından işlenebilen birçok iş yapmasını ön uç katmanınızdan kaçının. Bu kötü model, çok kiracılı bir çözüm için paylaşılan ön uçlar oluşturduğunuzda özellikle önemlidir, çünkü yoğun bir ön uç tüm kiracıların deneyimini düşürecektir.

Bunun yerine, kuyrukları veya diğer mesajlaşma hizmetlerini kullanarak zaman uyumsuz işleme kullanmayı göz önünde bulundurun. Bu yaklaşım, farklı kiracılar için kendi gereksinimlerine göre hizmet kalitesi (QoS) denetimleri uygulamanızı da sağlar. Örneğin, tüm kiracılar ortak bir ön uç katmanını paylaşabilir, ancak daha yüksek bir hizmet düzeyi için ödeme yapan kiracıların kuyruk iletilerindeki işleri işlemek için ayrılmış kaynaklar daha yüksek olabilir.

Yetersiz veya yetersiz ölçeklendirme

Çok kiracılı çözümler genellikle çok katmanlı ölçek desenlerine tabidir. Paylaşılan bileşenler bu soruna özellikle duyarlıdır, çünkü seri artış kapsamı daha yüksektir ve farklı kullanım desenlerine sahip daha fazla kiracınız olduğunda etki daha fazla olur.

Bulutun esnekliğini ve ölçeğini iyi kullandığınızdan emin olun. Yatay mı yoksa dikey ölçeklendirme mi kullanacağınızı düşünün ve yükteki ani artışları otomatik olarak işlemek için otomatik ölçeklendirmeyi kullanın. Farklı yük düzeylerinde nasıl davrandığını anlamak için çözümünüzü test edin. Üretimde beklenen yük hacimlerini ve beklenen büyümeyi eklediğinizden emin olun. Uygulamanızın stres altında nasıl davrandığını öğrenmek için Azure Yük Testi gibi tam olarak yönetilen bir hizmet kullanabilirsiniz.

Önbelleksizlik kötü modeli

Uygulama katmanı istekler arasında yeniden kullanılabilecek bilgileri tekrar tekrar istediğinden veya yeniden çözümlediğinden, Önbelleğe Alma Yok kötü modeli çözümünüzün performansından zarar görür. Kiracılar arasında veya tek bir kiracıdaki kullanıcılar arasında paylaşılabilen verileriniz varsa, arka uç/veritabanı katmanınızdaki yükü azaltmak için önbelleğe almaya değer.

Gereksiz durum bilgisi

Önbelleğe Alma Yok kötü modeline giden corollary, işlem katmanınızda gereksiz durum depolamaktan da kaçınmanız gerektiğidir. Durumu nerede ve neden koruyabileceğiniz konusunda açık olun. Durum bilgisi olan ön uç veya uygulama katmanları ölçeklendirme yeteneğinizi azaltabilir. Durum bilgisi olan işlem katmanları genellikle oturum benzine ihtiyaç duyar ve bu da çalışanlar veya düğümler arasında trafiği etkili bir şekilde dengeleme olanağınızı azaltabilir.

İşlem katmanınızda koruduğunuz her durum parçası için dengeleri ve kiracılarınızın iş yükü düzenleri değiştikçe ölçeklendirme veya büyüme becerinizi etkileyip etkilemediğini göz önünde bulundurun. Durumu Redis için Azure Cache gibi bir dış önbellekte de depolayabilirsiniz.

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 yazarlar:

  • Dixit Arora | Kıdemli Müşteri Mühendisi, Azure için FastTrack
  • John Downs | Baş Müşteri Mühendisi, Azure için FastTrack

Diğer katkıda bulunanlar:

Sonraki adımlar

İşlem hizmetleriniz için hizmete özgü yönergeleri gözden geçirin: