Çözümünüzdeki kiracılarla çalışmayı göz önünde bulundurmanın birçok yolu vardır. Yaklaşım seçiminiz önemli ölçüde kaynakları kiracılarınız arasında paylaşıp paylaşmadığınıza ve nasıl paylaştığınıza bağlıdır. Sezgisel olarak, herhangi bir kaynağı paylaşmaktan kaçınmak isteyebilirsiniz, ancak işletmeniz ölçeklendikçe ve daha fazla kiracı eklediğinizde bu yaklaşım hızla pahalıya dönüşür.
Çok kiracılı çeşitli modelleri göz önünde bulundurduğunda, önce kuruluşunuz için kiracıları nasıl tanımladığınız, iş etmenlerinizin ne olduğu ve çözümünüzü ölçeklendirmeyi nasıl planladığınızı hesaba katmak yararlı olur. Bu makale, teknik karar alıcıların kiracı modellerini ve dezavantajlarını değerlendirmesine yardımcı olmak için rehberlik sağlar.
Kiracı tanımlama
İlk olarak, kuruluşunuz için bir kiracı tanımlamanız gerekir. Müşterinizin kim olduğunu düşünün. Başka bir deyişle, hizmetlerinizi kime sağlıyorsunuz? İki yaygın model vardır:
- İşletmeden işletmeye (B2B). Müşterileriniz başka kuruluşlarsa, kiracılarınızı bu müşterilerle eşleme olasılığınız yüksektir. Ancak müşterilerinizin bölümlere (ekipler veya departmanlar) sahip olup olmadığını ve birden çok ülkede/bölgede varlık gösterilip bulunmadığını göz önünde bulundurun. Bu alt gruplar için farklı gereksinimler varsa tek bir müşteriyi birden çok kiracıyla eşlemeniz gerekebilir. Benzer şekilde, bir müşteri geliştirme ve üretim ortamlarını birbirinden ayrı tutabilmek için hizmetinizin iki örneğini tutmak isteyebilir. Genel olarak, tek bir kiracının birden çok kullanıcısı vardır. Örneğin, müşterinin tüm çalışanları tek bir kiracıdaki kullanıcılardır.
- İşletmeden müşteriye (B2C). Müşterileriniz tüketiciyse, müşterileri, kiracıları ve kullanıcıları ilişkilendirmek genellikle daha karmaşıktır. Bazı senaryolarda her tüketici ayrı bir kiracı olabilir. Ancak, çözümünüzün aileler, arkadaş grupları, kulüpler, dernekler veya verilerine birlikte erişmesi ve bunları yönetmesi gerekebilecek diğer gruplar tarafından kullanılıp kullanılmayacağını göz önünde bulundurun. Örneğin, bir müzik akışı hizmeti hem tek tek kullanıcıları hem de aileleri destekleyebileceğinden, bu hesap türlerini kiracılara ayırdığında bu hesap türlerinin her birini farklı şekilde ele alabilir.
Kiracı tanımınız, çözümünüzün mimarisini oluştururken göz önünde bulundurmanız veya vurgu yapmanız gereken bazı şeyleri etkiler. Örneğin, şu kiracı türlerini göz önünde bulundurun:
- Kiracılarınız bireysel kişiler veya ailelerse, kişisel verileri nasıl işlediğiniz ve hizmet ettiğiniz her bir yargı alanı içindeki veri hakimiyeti yasaları hakkında özellikle endişelenmeniz gerekebilir.
- Kiracılarınız işletmeyse, müşterilerinizin mevzuat uyumluluğu, verilerinin yalıtımı ve çalışma süresi veya hizmet kullanılabilirliği gibi belirli bir hizmet düzeyi hedefini (SLO) karşıladığınızdan emin olma gereksinimleri konusunda dikkatli olmanız gerekebilir.
Hangi modeli kullanacağınıza nasıl karar verirsiniz?
Kiracı modeli seçmek yalnızca teknik bir karar değildir. Bu aynı zamanda ticari bir karar. Aşağıdaki gibi soruları göz önünde bulundurmanız gerekir:
- İş hedefleriniz nelerdir?
- Müşterileriniz her türlü çok kiracılılığı kabul edecek mi? Her çok kiracılı model uyumluluk gereksinimlerinizi veya müşterilerinizin uyumluluk gereksinimlerini nasıl etkiler?
- Tek kiracılı bir çözüm gelecekteki büyüme hedeflerinize göre ölçeklendirilecek mi?
- Operasyon ekibiniz ne kadar büyük ve altyapı yönetiminizin ne kadarını otomatikleştirebilirsiniz?
- Müşterileriniz hizmet düzeyi sözleşmelerini (SLA) karşılamanızı mı bekliyor yoksa hedeflediğiniz SLO'larınız mı var?
İşletmenizin çok sayıda müşteriye ölçeklendirilmesini bekliyorsanız, paylaşılan altyapıyı dağıtmak önemlidir. Aksi takdirde, büyük ve büyüyen bir kaynak örneği filosunu korumanız gerekir. Her kiracı için ayrılmış bir abonelik sağlamadığınız ve kullanmadığınız sürece, her müşteri için tek tek Azure kaynaklarını dağıtma işlemi sürdürülemez. Aynı Azure aboneliğini birden çok kiracıda paylaştığınızda, Azure kaynak kotaları ve sınırları uygulanmaya başlayabilir ve bu kaynakları dağıtma ve yeniden yapılandırma işlem maliyetleri her yeni müşteride artar.
Buna karşılık, işletmenizin yalnızca birkaç müşterisi olmasını bekliyorsanız, her müşteriye ayrılmış tek kiracılı kaynakları kullanmayı düşünebilirsiniz. Ayrıca, müşterilerinizin yalıtım gereksinimleri yüksekse, tek kiracılı bir altyapı yaklaşımı daha maliyetli olsa bile uygun olabilir.
Kiracılar ve dağıtımlar
Ardından, belirli çözümünüz için kiracının ne anlama geldiğini ve mantıksal kiracılarla dağıtımları ayırt etmeniz gerekip gerekmediğini belirlemeniz gerekir.
Örneğin, bir müzik akışı hizmeti düşünün. Başlangıçta binlerce kullanıcıyı (hatta on binlerceyi) kolayca işleyebilen bir çözüm oluşturabilirsiniz. Ancak büyümeye devam ettikçe, yeni müşteri talebine göre ölçeklendirmek için çözümünüzü veya bazı bileşenlerini yinelemeniz gerektiğini fark edebilirsiniz. Bu, çözümünüzün belirli örneklerine belirli müşterileri nasıl atayabileceğinizi belirlemeniz gerektiği anlamına gelir. Müşterileri rastgele veya coğrafi olarak ya da tek bir örneği doldurup başka bir örnek başlatarak (kutu paketleme) atayabilirsiniz. Ancak, büyük olasılıkla müşterilerinizin kaydını ve verilerinin ve uygulamalarının hangi altyapıda kullanılabildiğini tutmanız gerekir; böylece trafiği doğru altyapıya yönlendirebilirsiniz. Bu örnekte, her müşteriyi ayrı bir kiracı olarak temsil edebilir ve ardından kullanıcıları verilerini içeren dağıtımla eşleyebilirsiniz. Kiracılar ve dağıtımlar arasında bire çok eşlemeniz vardır ve kiracıları kendi takdirinize bağlı olarak dağıtımlar arasında taşıyabilirsiniz.
Buna karşılık, hukuk firmaları için bulut yazılımı oluşturan bir şirket düşünün. Müşterileriniz uyumluluk standartlarını korumak için kendi ayrılmış altyapılarına sahip olmakta ısrar edebilir. Bu nedenle, başlangıçtan itibaren çözümünüzün birçok farklı örneğini dağıtmaya ve yönetmeye hazırlıklı olmanız gerekir. Bu örnekte, bir dağıtım her zaman tek bir kiracı içerir ve bir kiracı kendi ayrılmış dağıtımıyla eşlenir.
Kiracılar ve dağıtımlar arasındaki önemli bir fark, yalıtımın nasıl zorlanmış olduğudur. Birden çok kiracı tek bir dağıtımı (bir altyapı kümesi) paylaştığında, her kiracının verilerini ayrı tutmak için genellikle uygulama kodunuz ve veritabanındaki bir kiracı tanımlayıcısına güvenirsiniz. Kendi ayrılmış dağıtımlarına sahip kiracılarınız olduğunda, bunların kendi altyapıları vardır, bu nedenle kodunuzun çok kiracılı bir ortamda çalıştığını fark etmeniz daha az önemli olabilir.
Dağıtımlar bazen üst öğeler veya damgalar olarak adlandırılır.
Belirli bir kiracı için bir istek aldığınızda, burada gösterildiği gibi bu kiracının verilerini barındıran dağıtımla eşlemeniz gerekir:
Daha fazla bilgi edinmek için bkz . İstekleri kiracılarla eşleme.
Kiracı yalıtımı
Çok kiracılı mimarinin tasarımında dikkat edilmesi gereken en büyük noktalardan biri, her kiracının ihtiyaç duyduğu yalıtım düzeyidir. Yalıtım farklı anlamlara gelebilir:
- Uygulamanızın ayrı örnekleri ve her kiracı için ayrı veritabanları ile tek bir paylaşılan altyapıya sahip olma.
- Bazı yaygın kaynakları paylaşma, ancak diğer kaynakları her kiracı için ayrı tutma.
- Verileri ayrı bir fiziksel altyapıda tutma. Bulutta, bu yapılandırma her kiracı için ayrı Azure kaynakları gerektirebilir. Aşırı durumlarda, ayrılmış konaklar kullanarak ayrı bir fiziksel altyapı dağıtma anlamına bile gelebilir.
Yalıtımı ayrık bir özellik olarak düşünmek yerine, bunu bir devamlılık üzerinde olmak olarak düşünmelisiniz. Mimarinizin gereksinimlerinize bağlı olarak, aynı mimarideki diğer bileşenlerden daha fazla veya daha az yalıtılmış bileşenleri dağıtabilirsiniz. Aşağıdaki diyagramda yalıtım devamlılığı gösterilmektedir:
Yalıtım düzeyi, aşağıdakiler de dahil olmak üzere mimarinizin birçok yönünü etkiler:
- Güvenlik. Altyapıyı birden çok kiracı arasında paylaşıyorsanız, yanıtları başka bir kiracıya döndürerek bir kiracıdan verilere erişmemeye dikkat etmeniz gerekir. Kimlik stratejiniz için güçlü bir temele ihtiyacınız vardır ve yetkilendirme işleminizde 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 daha ucuzdur.
- Performans. Altyapıyı paylaşırsanız, kaynaklar daha hızlı tüketilebileceği için daha fazla müşteri kullandığından sisteminizin performansı olumsuz etkilenebilir. Performans sorunları, olağan dışı kullanım desenlerine sahip kiracılar tarafından daha da kötüleştirilebilir.
- Güvenilirlik. Tek bir paylaşılan altyapı kümesi kullanıyorsanız, bir bileşenle ilgili bir sorun tüm kiracılarınızda kesintiye neden olabilir.
- Tek tek kiracı gereksinimlerine yanıt verme. Tek bir kiracıya ayrılmış altyapıyı dağıttığınızda, kaynakların yapılandırmasını ilgili kiracının gereksinimlerine uyarlayabilirsiniz. Hatta bu özelliği fiyatlandırma modelinizde göz önünde bulundurarak müşterilerin yalıtılmış dağıtımlar için daha fazla ödeme gerçekleştirmesine olanak tanıyabilirsiniz.
Çözüm mimariniz, yalıtım için kullanılabilir seçeneklerinizi etkileyebilir. Örneğin, üç katmanlı bir çözüm mimarisini göz önünde bulundurun:
- Kullanıcı arabirimi katmanınız, tüm kiracılarınızın tek bir ana bilgisayar adına eriştiği paylaşılan bir çok kiracılı web uygulaması olabilir.
- Orta katmanınız, paylaşılan ileti kuyruklarıyla 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üzeyleri kullanmayı düşünebilirsiniz. Azure kotalarına ve sınırlarına ulaşmadan önce maliyet, karmaşıklık, müşterilerinizin gereksinimleri ve dağıtabileceğiniz kaynak sayısı dahil olmak üzere, paylaşılanlar ve yalıtılmış noktalar hakkındaki kararlarınızı temel almalısınız.
Ortak kiracı modelleri
Gereksinimlerinizi oluşturduktan sonra, bunları bazı ortak kiracı modellerine ve karşılık gelen dağıtım desenlerine göre değerlendirin.
Otomatik tek kiracılı dağıtımlar
Otomatik tek kiracılı dağıtım modelinde, bu örnekte gösterildiği gibi her kiracı için ayrılmış bir altyapı kümesi dağıtırsınız:
Uygulamanız, her kiracının kaynaklarının dağıtımını başlatma ve koordine etme sorumluluğundadır. Genellikle, bu modeli kullanan çözümler kod olarak altyapı (IaC) veya Azure Resource Manager API'lerini kapsamlı olarak kullanır. Her bir müşteriniz 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ı desenini kullanmayı göz önünde bulundurun.
Avantajlar: Bu yaklaşımın temel avantajlarından biri, her kiracı için verilerin yalıtılmış olması ve bu sayede yanlışlıkla sızıntı riskini azaltmasıdır. Bu koruma, yüksek mevzuat uyumluluğu ek yükü olan bazı müşteriler için önemli olabilir. Buna ek olarak, kiracıların birbirlerinin sistem performansını etkileme olasılığı düşüktür. Bu sorun bazen gürültülü komşu sorunu olarak adlandırılır. Güncelleştirmeler ve değişiklikler kiracılar arasında aşamalı olarak dağıtılabilir ve bu da sistem genelinde kesinti olasılığını azaltır.
Riskler: Bu yaklaşımı kullanırsanız, kiracılarınız arasında altyapı paylaşmadığınızdan maliyet verimliliği düşüktür. Tek bir kiracı belirli bir altyapı maliyeti gerektiriyorsa, 100 kiracı büyük olasılıkla bu maliyetin 100 katı gerektirir. Ayrıca, devam eden bakım (yeni yapılandırma veya yazılım güncelleştirmeleri uygulama gibi) büyük olasılıkla zaman alır. İşletimsel süreçlerinizi otomatikleştirmeyi ve değişiklikleri ortamlarınız aracılığıyla aşamalı olarak uygulamayı göz önünde bulundurun. Tüm filonuzda raporlama ve analiz gibi diğer dağıtımlar arası işlemleri de göz önünde bulundurmanız gerekir. Benzer şekilde, birden çok dağıtımda verileri nasıl sorgulayabileceğinizi ve işleyebileceğinizi de planladığınızdan emin olun.
Tamamen çok kiracılı dağıtımlar
Tam tersi bir durumda, tüm bileşenlerin paylaşıldığı tamamen çok kiracılı bir dağıtımı göz önünde bulundurabilirsiniz. Aşağıdaki diyagramda gösterildiği gibi dağıtmak ve bakımını yapmak için yalnızca bir altyapı kümeniz vardır ve tüm kiracılar bunu kullanır:
Avantajlar: Paylaşılan bileşenlere sahip bir çözümün çalıştırılması, her kiracı için tek tek kaynakları kullanmaktan daha ucuz olduğundan bu model caziptir. Artan yükü hesaba katmak için daha yüksek katman veya SKU'lar dağıtmanız gerekse bile, genel dağıtım maliyeti genellikle tek kiracılı kaynaklar kümesinin maliyetinden daha düşüktür. Ayrıca, bir kullanıcının veya kiracının verilerini başka bir kiracıya taşıması gerekiyorsa, kiracı tanımlayıcılarını ve anahtarlarını güncelleştirebilir ve verileri iki ayrı dağıtım arasında geçirmeniz gerekmeyebilir.
Risk:
Her kiracı için verileri ayırıp kiracılar arasında veri sızdırmayın. Parçalama verilerini yönetmeniz gerekebilir. Ayrıca, tek tek kiracıların genel sistem üzerindeki etkileri hakkında endişelenmeniz gerekebilir. Örneğin, büyük bir kiracı ağır bir sorgu veya işlem gerçekleştirmeye çalışırsa, diğer kiracıları etkileyebilir.
Bunu yapmak sizin için önemliyse Azure maliyetlerinizi izlemeyi ve kiracılarla ilişkilendirmeyi belirleyin.
Tek bir dağıtımda bakım daha kolay olabilir çünkü yalnızca bir kaynak kümesini güncelleştirmeniz gerekir. Ancak değişiklikler müşteri tabanınızın tamamını etkileyebileceğinden bu durum genellikle daha risklidir.
Ölçeklendirmeyi de göz önünde bulundurmanız gerekebilir. Paylaşılan bir altyapı kümeniz olduğunda Azure kaynak ölçek sınırlarına ulaşma olasılığınız daha yüksektir. Örneğin, çözümünüzün bir parçası olarak bir depolama hesabı kullanırsanız, ölçeğiniz arttıkça bu depolama hesabına yönelik istek sayısı depolama hesabının işleyebileceği sınıra ulaşabilir. Kaynak kotası sınırına ulaşmamak için kaynaklarınızın birden çok örneğinden oluşan bir havuz (örneğin, birden çok AKS kümesi veya depolama hesabı) dağıtmayı düşünebilirsiniz. Kiracılarınızı birden çok Azure aboneliğine dağıttığınız kaynaklar arasında dağıtmayı da düşünebilirsiniz.
Büyük olasılıkla tek bir dağıtımı ne kadar ölçeklendirebileceğinize ilişkin bir sınır vardır ve bunu yapmanın maliyetleri doğrusal olmayan bir şekilde artabilir. Örneğin, tek bir paylaşılan veritabanınız varsa, çok yüksek ölçekte çalıştırdığınızda aktarım hızını tüketebilir ve talebinize ayak uydurmak için artan aktarım hızı için giderek daha fazla ödeme yapmanız gerekebilir.
Dikey bölümlenmiş dağıtımlar
Bu ölçeklerin uçlarından birini seçmeniz gerekmez. Bunun yerine, şu yaklaşımı benimseyerek kiracılarınızı dikey olarak bölümleyebilirsiniz:
- Tek kiracılı ve çok kiracılı dağıtımların birleşimini kullanın. Örneğin, müşterilerinizin veri ve uygulama katmanlarının çoğu çok kiracılı altyapılarda olabilir, 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ıyı belirli bir dağıtımla eşleyin. Bu yaklaşım özellikle farklı coğrafyalarda kiracılarınız olduğunda etkilidir.
Bazı kiracılar için paylaşılan dağıtımı ve başka bir kiracı için tek kiracılı dağıtımı gösteren bir örnek aşağıda verilmiştir:
Avantajlar: Altyapınızın bir bölümünü paylaşmaya devam ettiğiniz için, paylaşılan çok kiracılı dağıtımları kullanmanın maliyet avantajlarından bazılarını kazanabilirsiniz. Hizmetinizi deneme sürümüyle değerlendiren müşteriler gibi belirli müşteriler için daha ucuz paylaşılan kaynaklar dağıtabilirsiniz. Tek kiracılı dağıtım kullanmak için müşterilere daha yüksek bir ücret bile faturalayabilirsiniz. Bu da maliyetlerinizin bir kısmını kurtarmanıza yardımcı olur.
Riskler: Kod tabanınızın hem çok kiracılı hem de tek kiracılı dağıtımları destekleyecek şekilde tasarlanması gerekir. Dağıtımlar 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ımlarına geçirmeyi göz önünde bulundurmanız gerekir. Ayrıca, sistem sorunları veya yükseltmeleri hakkındaki bilgileri ilgili müşterilere iletebilmeniz için her dağıtımda hangi kiracılarınızın olduğunu bilmeniz gerekir.
Yatay olarak bölümlenmiş dağıtımlar
Ayrıca dağıtımlarınızı yatay olarak bölümleyebilirsiniz. Yatay dağıtımda, bazı paylaşılan bileşenleriniz vardır ancak tek kiracılı dağıtımlarla diğer bileşenleri korursunuz. Örneğin, bu diyagramda gösterildiği gibi tek bir uygulama katmanı oluşturabilir ve sonra her kiracı için ayrı veritabanları dağıtabilirsiniz:
Avantajlar: Yatay olarak bölümlenmiş dağıtımlar gürültülü bir komşu sorununu azaltmanıza yardımcı olabilir: Sisteminizdeki yükün çoğunun belirli bileşenlerden kaynaklandığını belirlerseniz, her kiracı için ayrı bileşenler dağıtabilirsiniz. Örneğin, sorgu yükü yüksek olduğundan veritabanlarınız sisteminizin yükünün çoğunu alabilir. Tek bir kiracı çözümünüze çok sayıda istek gönderirse, veritabanının performansı olumsuz etkilenebilir, ancak diğer kiracıların veritabanları (ve uygulama katmanı gibi paylaşılan bileşenler) etkilenmeden kalır.
Riskler: Yatay olarak bölümlenmiş bir dağıtımda, bileşenlerinizin, özellikle de tek bir kiracı tarafından kullanılan bileşenlerin otomatik dağıtımını ve yönetimini göz önünde bulundurmanız gerekir.
Yalıtım modelinizi test etme
Hangi yalıtım modelini seçerseniz seçin, bir kiracının verilerinin yanlışlıkla başka bir kiracıya sızdırılmadığını ve gürültülü komşu etkilerinin kabul edilebilir olduğunu doğrulamak için çözümünüzü test etmeyi unutmayın. Azure Chaos Studio'yu kullanarak gerçek dünyadaki kesintilerin benzetimini yaparak hataları kasıtlı olarak tanıtmayı ve bileşenler düzgün çalışmadığında bile çözümünüzün dayanıklılığını doğrulamayı göz önünde bulundurun.
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 | Baş Yazılım Mühendisi
Diğer katkıda bulunanlar:
- Chad Kittel | Baş Yazılım Mühendisi
- 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.