Çok kiracılı bir çözüm için göz önünde bulundurulması gereken kiracı modelleri

Çok kiracılı bir çözüm tasarlayabilmeniz için kullanabileceğiniz birçok farklı yol vardır. Genellikle bu kararların, kiracılar arasında kaynakları nasıl paylaştığından ve bu kararı veriyorlar. Intuıcanlı, herhangi bir kaynağın paylaşılmasını önlemek isteyebilirsiniz, ancak işiniz ölçeklendirilirken ve daha fazla kiracı yerleştirirken bu hızlı bir şekilde pahalıdır.

Çok kiracılı farklı modeller hakkında düşünmek yararlı olur. ilk olarak, belirli bir kuruluşunuz için kiracılar nasıl tanımladığınızı, sahip olduğunuz iş sürücülerini ve çözümünüzü ölçeklendirmeyi nasıl planlayacağınızı anlayacaksınız. Bu sayfada, göz önünde bulundurabileceğiz kiracı modelleriyle ilgili teknik karar verme mekanizmaları ve bunların avantajları sunuyoruz.

Kiracı tanımlama

İlk olarak, kuruluşunuz için bir kiracı tanımlamanız gerekir. Müşterinizin kim olduğunu düşünün. Diğer bir deyişle, hizmetlerinizi hizmetine kim sağlıyor? İki ortak model vardır:

• İşletmeden işletmeye (B2B). Müşterilerinizin diğer kuruluşları varsa, Kiracılarınızı bu müşteriler olarak kabul etmeniz olasıdır. Ancak, müşterilerinizin bölümlere (takımlar veya departmanlar) sahip olup olmadığını veya birden çok ülkede varolup olmadığını göz önünde bulundurun. Bu alt gruplar için farklı gereksinimler varsa, birden fazla kiracıya tek bir müşteri Haritası bulundurmaktan düşünmeniz gerekebilir. Benzer şekilde, bir müşteri, her birinin geliştirme ve üretim ortamlarını birbirinden ayrı tutabilmeleri için hizmetinizin iki örneğini sürdürmek isteyebilir. Genellikle, tek bir kiracının birden çok kullanıcısı olur. Örneğin, tüm müşterinizin çalışanları aynı kiracı dahilinde kullanıcılar olacaktır.
• Işletmeden müşteriye (B2C). Müşterileriniz Tüketicileriniz ise müşterileri, kiracılar ve kullanıcıları ilişkilendirmek genellikle daha karmaşıktır. Bazı senaryolarda, her tüketici kendi kiracısıdır. Bununla birlikte, çözümünüzün aileleri, arkadaşların, sinek, ilişkilerin veya verileri birlikte erişmesi ve yönetmesi gerekebilecek diğer gruplandırmaları tarafından kullanılıp kullanılamayacağını göz önünde bulundurun. Örneğin, bir müzik akış hizmeti hem bireysel kullanıcıları hem de ailelerini destekleyebilir ve bu hesap türlerinin her birini kiracılara ayırmak için olduğunda farklı şekilde ele alabilir.

Kiracınız , çözümünüzü mimarınızda göz önüne almanız veya vurgulamanıza gerek duyduğunuz bazı şeyleri etkileyecektir. Örneğin, bu farklı kiracı türlerini göz önünde bulundurun:

• Kiracılarınız bireysel kişiler veya aileler ise, kişisel verileri nasıl işleyeceğinizi ve sunduğunuz her bir yasaların içindeki verileri egemenlik yasaları konusunda özellikle ilgilenmiş olmanız gerekebilir.
• Kiracılarınız işletmeler ise, uygun bir hizmet düzeyi hedefini (SLO) (örneğin, çalışma süresi veya hizmet kullanılabilirliği gibi) karşılamanız için müşterilerinizin gereksinimlerinin en az olması gerekebilir.

Hangi modeli kullanacağınıza nasıl karar verirsiniz?

Bir kiracı modelinin seçilmesi yalnızca teknik bir karardır; Ayrıca, yapmanız gereken ticari bir karardır. Aşağıdaki gibi soruları göz önünde bulundurmanız gerekir:

• İş hedefleriniz nelerdir?
• Müşterileriniz, çok kiracılı tüm formları kabul ediyor mu? Her bir çoklu kiracı modeli, uyumluluk gereksinimlerinizi veya müşterinizin uyumluluk gereksinimlerini nasıl etkiler?
• Tek kiracılı bir çözüm, gelecekteki büyüme ASP 'ler için ölçeklendirilmesine mi?
• İşletim ekibiniz ne kadar büyükse ve altyapı yönetimızın ne kadarını otomatikleştirebiliyor musunuz?
• Müşterileriniz, hizmet düzeyi sözleşmeleri (SLA) karşılamanız beklesin veya sizin için uygun olan Slotlarınız var mı?

İşletmenizin çok sayıda müşteriye ölçeklendirebilmesini düşünüyorsanız, paylaşılan altyapıyı dağıtmak çok önemli olacaktır. Aksi takdirde, büyük ve sürekli büyüyen örnek örnekleri korumanız gerekir. Her müşteri için ayrı ayrı Azure kaynakları dağıtmak, kiracı başına adanmış bir abonelik sağlamadığınız ve kullanmadığınız durumlar nedeniyle sürdürülebilir olma olasılığı yüksektir. Aynı Azure aboneliğini birden çok kiracı genelinde paylaşırken, Azure kaynak kotaları ve limitleri uygulanabilir ve bu kaynakları dağıtmak ve yeniden yapılandırmak için, her yeni müşteriyle birlikte işlem maliyetleri daha yüksektir.

Buna karşılık, işletmenizin yalnızca birkaç müşterisi olduğunu düşünüyorsanız, her müşteriye ayrılmış tek kiracılı kaynaklara sahip olmak isteyebilirsiniz. Benzer şekilde, müşterilerinizin yalıtım gereksinimleri yüksekse, tek kiracılı bir altyapı uygun olabilir.

Mantıksal ve fiziksel kiracılar

Daha sonra, bir kiracının belirli çözümünüz için ne anlama geldiğini ve mantıksal ve fiziksel kiracılar arasında ayırt edilip edilmeyeceğini belirlemeniz gerekir.

Örneğin, bir müzik akışı hizmeti düşünün. Başlangıçta, binlerce (veya hatta binlerce binlerce) kullanıcıyla kolayca işlem yapan bir çözüm derleyebilirsiniz. Ancak büyümeye devam ederken, yeni müşteri talepinizi ölçeklendirmek için çözümünüzü veya bazı bileşenlerini çoğaltmaya ihtiyacınız olduğunu fark edebilirsiniz. Bu, belirli müşterileri çözümünüzün belirli örneklerine atamaya çalışmanız gerektiği anlamına gelir. Bunu rastgele veya coğrafi olarak ya da tek bir örnek doldurup başka bir örneğe taşıyarak yapabilirsiniz. Ancak, muhtemelen sahip olduğunuz müşterilere ve bunların veri ve uygulamalarının üzerinde kullanılabildiği bir kayıt uygulamanız gerekir, böylece trafiği doğru altyapıya yönlendirebilirsiniz. Bu örnekte, her bir kullanıcıyı ayrı bir mantıksal kiracı olarak temsil edebilir ve ardından kullanıcıları dağıttığınız farklı örnekleri temsil eden fiziksel kiracılar ile eşleyebilirsiniz. Mantıksal ve fiziksel kiracılar arasında bire çok eşlemeye sahipsiniz ve mantıksal kiracılar arasında fiziksel kiracılar arasında geçiş yapabilirsiniz.

Buna karşılık, yasal şirketler için bulut yazılımı oluşturan bir şirketi göz önünde bulundurun. Müşterileriniz, uyumluluk standartlarını sürdürmek için kendi özel altyapısına insist edebilir. Bu nedenle, çözümünüzün hemen başından itibaren birçok farklı örneğini dağıtıp yönetmeye hazır olmanız gerekir. Bu örnekte, mantıksal ve fiziksel bir kiracı aynı şeydir.

Mantıksal ve fiziksel kiracılar arasındaki önemli bir fark, yalıtımın nasıl zorlanır. Birden çok mantıksal kiracı tek bir altyapı kümesini paylaşıyorsa, her kiracının verisini ayrı tutmak için genellikle uygulama kodunuza ve bir veritabanındaki kiracı tanımlayıcısından yararlanmalısınız. Fiziksel kiracılarınız varsa, kendi altyapıları vardır ve bu sayede kodunuzun çok kiracılı bir ortamda çalıştığını bilmesi daha az önemli olabilir.

Bazen dağıtım, süper kiracıveya Damgaolarak adlandırılan fiziksel kiracılar görürsünüz. Bu belgenin geri kalanında, mantıksal ve fiziksel kiracılar arasında karışıklık oluşmasını önlemek için terimler dağıtımlarını ve fiziksel dağıtımlarıkullanırız.

Belirli bir mantıksal kiracı için bir istek aldığınızda, aşağıda gösterildiği gibi, bu kiracının verilerini tutan fiziksel dağıtıma eşlemeniz gerekir:

Kiracı yalıtımı

Çok kiracılı bir mimari tasarlarken dikkat etmeniz gereken en büyük noktalar, her kiracının ihtiyacı olan yalıtımın bir düzeyidir. Yalıtım farklı şeyler anlamına gelebilir:

• Tek bir paylaşılan altyapı kümesine sahip olmak, uygulamanızın ayrı örnekleri ve her kiracı için ayrı veritabanları.
• Diğer kaynakları her kiracı için ayrı tutarken, bazı ortak kaynakları paylaşma.
• Verileri ayrı bir fiziksel altyapıda tutma. Bulutta, bu her kiracı için ayrı Azure kaynakları gerektirebilir veya adanmış Konaklarıkullanarak ayrı bir fiziksel altyapıyı de tam olarak dağıtmaktan kaynaklanabilir.

Ayrık bir özellik olduğu için yalıtımı düşünmek yerine, bir Continuum olarak yalıtımın olduğunu düşünmelisiniz. Mimarinizin, gereksinimlerinize bağlı olarak, aynı mimarideki diğer bileşenlerden daha fazla veya daha az yalıtılmış olan bileşenlerini dağıtabilirsiniz. Aşağıdaki diyagramda bir yalıtımın sürekliliği gösterilmektedir:

Yalıtım düzeyi, mimarinizin birçok yönlerini etkiler ve aşağıdakiler de dahildir:

• Güvenlik'i seçin. Altyapıyı birden çok kiracı arasında paylaşırsanız, yanıtları başka bir kiracıya geri döndürürken, özellikle bir kiracıdan veriye erişememeye dikkat etmeniz gerekir. Kimlik stratejiniz için güçlü bir temel gerekir ve yetkilendirme sürecinizin içinde hem kiracı hem de Kullanıcı kimliğini göz önünde bulundurmanız gerekir.
• Maliyet. Paylaşılan altyapı birden çok kiracı tarafından kullanılabilir; Bu nedenle, bu da bir kişi olabilir.
• Performans. Altyapıyı paylaşıyorsanız, kaynakların daha hızlı tüketilebilmesi için sisteminizin performansı daha fazla müşteri tarafından kullanılıyorsa, bu da daha fazla müşterinin performansını etkilemeyebilir.
• Artırır. Tek bir paylaşılan altyapı kümesi kullanıyorsanız, bir kiracının bileşenleriyle ilgili bir sorun herkese karşı bir kesinti oluşmasına neden olabilir.
• Ayrı kiracıların ihtiyaçlarına yanıt verme. Tek bir kiracıya adanmış altyapıyı dağıttığınızda, söz konusu kiracının gereksinimlerine ait kaynakların yapılandırmasını ayarlayabilirsiniz. Bu işlem, müşterilerin yalıtılmış dağıtımlar için daha fazla ödeme yapma olanağı sağlayan fiyatlandırma modelinize da göz önünde bulundurmanız gerekir.

Çözüm mimariniz, yalıtımda size sunulan seçenekleri etkileyebilir. Örneğin, örnek üç katmanlı çözüm mimarisi hakkında bilgi verelim:

• Kullanıcı arabirimi katmanınız paylaşılan bir çok kiracılı web uygulaması olabilir ve Kiracılarınızın hepsi tek bir ana bilgisayar adına erişir.
• Orta katmanınız Paylaşılan ileti kuyrukları ile paylaşılan bir uygulama katmanı olabilir.
• Veri katmanınız yalıtılmış veritabanları, tablolar veya blob kapsayıcıları olabilir.

Her katmanda farklı yalıtım düzeylerini karıştırmaya ve eşleştirmeye göz önüne alabilirsiniz. Nelerin paylaşılacağını ve yalıtılmış olduğunu gösteren kararınız, maliyet, karmaşıklık, müşterilerinizin gereksinimleri ve Azure kotaları ve sınırlarına ulaşmadan önce dağıtabileceğiniz kaynak sayısı dahil olmak üzere birçok önemli noktalara dayandırılır.

Ortak kiracı modelleri

Gereksinimlerinizi kurduktan sonra, bunları bazı ortak Kiracı modelleriyle ve desenlerine karşı değerlendirin.

Otomatik tek kiracılı dağıtımlar

Otomatik tek kiracılı bir dağıtım modelinde, bu örnekte gösterildiği gibi her kiracı için adanmış bir altyapı kümesi dağıtırsınız:

Uygulamanız, her bir kiracının kaynaklarının dağıtımını başlatmaktan ve koordine maktan sorumludur. Genellikle, bu model kullanılarak oluşturulan çözümler altyapıyı kod olarak altyapı (IAC) veya Azure Resource Manager API 'Leri olarak kullanır. Müşterilerinizin her biri için tamamen ayrı altyapılar sağlamanız gerektiğinde bu yaklaşımı kullanabilirsiniz. Dağıtımınızı planlarken dağıtım damgalar modelini göz önünde bulundurun.

Avantajlar: Bu yaklaşımın önemli bir avantajı, her kiracının verilerinin yalıtılması ve yanlışlıkla sızıntı riskini azaltır. Bu, yüksek düzeyde yasal uyumluluk yükü olan bazı müşteriler için önemli olabilir. Ayrıca, kiracılar bazen gürültülü komşu sorun olarak da adlandırılan her bir sistem performansını etkilemeyebilir. Güncelleştirmeler ve değişiklikler kiracılar arasında aşamalı olarak alınabilir ve bu da sistem genelinde kesinti olasılığını azaltır.

Riskler: Kiracılar arasında altyapı paylaşmadığından, maliyet etkinliğinizi azalmıştır. Tek bir kiracı altyapıda belirli bir miktar harcamayı gerektiriyorsa, 100 kiracıların ücretlendiri100 lecektir. Ayrıca, devam eden bakımın (yeni yapılandırma veya yazılım güncelleştirmeleri uygulamak gibi) zaman alıcı olma olasılığı yüksektir. İşletimsel işlemlerinizi otomatik hale getirme ve ortamlarınızı kullanarak değişiklikleri aşamalı olarak uygulamayı düşünün. Ayrıca, tüm emlak konusunda raporlama ve analiz gibi diğer çapraz dağıtım işlemlerini de göz önünde bulundurmanız gerekir. Benzer şekilde, birden fazla dağıtımda verileri nasıl sorgulayabilir ve işleyebileceğiniz konusunda plan olduğunuzdan emin olun.

Tam çok kiracılı dağıtımlar

Ters Extreme 'de, tüm bileşenlerin paylaşıldığı tam çok kiracılı bir dağıtımı göz önünde bulundurmanız gerekir. Dağıtım ve bakım için yalnızca bir altyapı kümesine sahipsiniz ve tüm kiracılar bunu aşağıdaki diyagramda gösterildiği gibi kullanır:

Avantajlar: Bu model, paylaşılan bileşenlerle bir çözüm çalıştırmanın daha düşük maliyetli olmasından dolayı etkileyici bir işlem yapar. Daha yüksek katman veya kaynak SKU 'Ları dağıtmanız gerekebilse de, genel dağıtım maliyetinin tek bir kiracı kaynakları kümesinden daha düşük olması gerekir. Ayrıca, bir kullanıcının veya kiracının verilerini başka bir mantıksal kiracıya taşıması gerekiyorsa, verileri iki ayrı dağıtım arasında geçirmeniz gerekmez.

Göz

• Her kiracı için verileri ayırmanızı ve kiracılar arasında veri sızıntısını aldığınızdan emin olun. Verilerinizi kendiniz de yönetmeniz gerekebilir. Ayrıca, tek tek kiracıların genel sistem üzerinde sahip olabileceği etkileri konusunda endişe duymalıdır. Örneğin, tek bir büyük kiracı ağır bir sorgu veya işlem gerçekleştirmeye çalışırsa, diğer kiracıların da etkilenmesine izin veriyor mu?

• Sizin için önemli olan Azure maliyetlerinizi kiracılar ile nasıl izleyip ilişkilendirdiğinizdenöğrenin. Yalnızca bir kaynak kümesini güncelleştirmeniz gerektiğinden, bakım tek bir dağıtımla daha kolay olabilir. Bununla birlikte, tüm değişiklikler müşteri tabanınızı etkileyebileceğinden, bu da çoğu zaman Risker.

• Ölçeklendirmenin yanı sıra göz önünde bulundurulması gereken bir faktör olabilir. Paylaşılan bir altyapı kümesine sahip olduğunuzda Azure Kaynak ölçek sınırlarına ulaşabilmeniz daha olasıdır. Örneğin, çözümünüzün bir parçası olarak bir depolama hesabı kullanırsanız, ölçeklendirmeniz arttıkça, bu depolama hesabına yönelik isteklerin sayısı depolama hesabının işleyebileceği sınıra ulaşabilirler. Kaynak kotası sınırına ulaşmaktan kaçınmak için, kaynaklarınızın birden çok örneğini (örneğin, birden çok AKS kümesi veya depolama hesabı) dağıtmayı düşünebilirsiniz ya da Kiracılarınızı birden çok Azure aboneliğine dağıttığınız kaynaklar arasında dağıtmayı düşünebilirsiniz.

• Tek bir dağıtımı ne kadar ölçeklendirebileceğiniz için bir sınır olması olasıdır ve bu işlemin maliyetleri, bir süre önce artabilir. Örneğin, tek bir paylaşılan veritabanınız varsa, çok yüksek ölçekli bir şekilde çalıştırdığınız zaman verimini tüketebilir ve daha fazla verimlilik için daha fazla ücret ödemenize olanak sağlayabilir.

Dikey olarak bölümlenmiş dağıtımlar

Bu ölçeklerinin aşırı uç birine oturmeniz gerekmez. Bunun yerine, aşağıdaki adımlarla Kiracılarınızı dikey olarak bölümlemeyi göz önünde bulundurmanız gerekir:

• Tek kiracılı ve çok kiracılı dağıtımların birleşimini kullanın. Örneğin, çok kiracılı altyapılarda müşterilerinizin veri ve uygulama katmanlarınızın çoğuna sahip olabilirsiniz, ancak daha yüksek performans veya veri yalıtımı gerektiren müşteriler için tek kiracılı altyapıları dağıtabilirsiniz.
• Çözümünüzün birden çok örneğini coğrafi olarak dağıtın ve her kiracının belirli bir dağıtıma sabitlenmiş olmasını sağlayabilirsiniz. Bu, özellikle farklı coğrafi bölgelerde kiracılar varsa etkilidir.

İşte, bazı kiracılar için paylaşılan bir dağıtımı ve diğeri için tek kiracılı bir dağıtımı gösteren bir örnek:

Avantajlar: Altyapıyı hala paylaşmakta olduğunuza göre, paylaşılan çok kiracılı dağıtımlar olmanın bazı maliyet avantajlarına sahip olmaya devam edebilirsiniz. Hizmetinizi bir deneme sürümü ile deneenlere benzer şekilde, belirli müşteriler için paylaşılan kaynaklar da dağıtabilirsiniz. Hatta müşterilerin tek kiracılı bir dağıtımda daha yüksek bir ücret üzerinden faturalandırılmalarını sağlayabilirsiniz. böylece bazı maliyetlerinizden bazılarını izleyebilirsiniz.

Riskler: Kod tabanınızın, büyük olasılıkla hem çok kiracılı hem de tek kiracılı dağıtımları destekleyecek şekilde tasarlanması gerekir. Altyapılar arasında geçişe izin vermeyi planlıyorsanız, müşterileri çok kiracılı bir dağıtımdan kendi tek kiracılı dağıtımına nasıl geçireceğinizi göz önünde bulundurmanız gerekir. Ayrıca, sistem sorunları veya ilgili müşterilere yükseltmeler hakkında bilgi edinmek için mantıksal Kiracılarınızın hangi fiziksel altyapı kümelerinde olduğunu net bir şekilde anlayabilmeniz gerekir.

Yatay bölümlenmiş dağıtımlar

Ayrıca, dağıtımlarınızı yatay olarak bölümlemeyi de göz önünde bulundurun. Bu, bazı paylaşılan bileşenleriniz olduğu ve tek kiracılı dağıtımlarla diğer bileşenleri sürdürirken olduğu anlamına gelir. Örneğin, tek bir uygulama katmanı oluşturabilir ve ardından her kiracı için ayrı veritabanlarını Bu çizimde gösterildiği gibi dağıtabilirsiniz:

Avantajlar: Yatay olarak bölümlenmiş dağıtımlar, sisteminizdeki yükün çoğunun her kiracı için ayrı olarak dağıtabileceğiniz belirli bileşenlere neden olduğunu belirlediyseniz, gürültülü komşu bir sorunu azaltmanıza yardımcı olabilir. Örneğin, veritabanınız büyük bir olasılıkla, sorgu yükü yüksek olduğu için sisteminizin yükünün çoğunu artışlarını devralarak edebilir. Tek bir kiracı çözümünüze çok sayıda istek gönderirse, bir veritabanının performansı olumsuz etkilenebilir, ancak diğer kiracı ' veritabanları (ve uygulama katmanı gibi paylaşılan bileşenler) etkilenmez durumda kalır.

Riskler: Yatay olarak bölümlenmiş bir dağıtımla, bileşenlerinizin otomatik dağıtımını ve yönetimini, özellikle de tek bir kiracı tarafından kullanılan bileşenleri göz önünde bulundurmanız gerekir.

Yalıtım modelinizi test etme

Hangi yalıtım modelini seçtiğinizde, bir kiracının verilerinin yanlışlıkla bir başkasına sızdırılmadığından ve gürültülü komşu etkilerin kabul edilebilir olduğundan emin olmak için çözümünüzü test edin. Gerçek dünyada kesintiler benzetimi yapan hataları kasıtlı olarak tanıtmak ve bileşenler arızalı olduğunda bile çözümünüzün dayanıklılığını doğrulamak için Azure Chaos Studio 'yu kullanmayı göz önünde bulundurun.

Sonraki adımlar

Kiracılarınızın yaşam döngüsünügöz önünde bulundurun.