Çoklu kiracı çözümlerinde depolama ve veri için mimari yaklaşımlar

Çok kiracılı depolama veya veri bileşenleri planlarken, Kiracılarınızın verilerini paylaşma veya yalıtma yaklaşımına karar vermeniz gerekir. Veriler genellikle, müşterilerinizin değerli iş bilgilerini temsil ettiğinden, bir çözümün en değerli bölümü olarak değerlendirilir. Bu nedenle, çok kiracılı bir ortamda verileri yönetmek için kullandığınız yaklaşımı dikkatle planlamanız önemlidir. Bu sayfada, çok kiracılı bir sistemde veri depolama yaklaşımına karar verirken çözüm mimarları için gereken önemli konular ve gereksinimler hakkında rehberlik sağlıyoruz. Daha sonra depolama ve veri hizmetlerine çok kiracılı ve kaçınacak bazı kenar desenlerine yönelik bazı yaygın desenler öneririz. Son olarak, bazı belirli durumlar için hedeflenen rehberlik sağlıyoruz.

Önemli konular ve gereksinimler

Depolama ve veri Hizmetleri için kullandığınız yaklaşımları, Azure Well-Architected çerçevesininparagraf larına yaklaşık olarak uyum sağlayan bir dizi perspektiften göz önünde bulundurmanız önemlidir.

Ölçek

Verilerinizi depolayan hizmetlerle çalışırken, sahip olduğunuz kiracılar sayısını ve depoladığınız veri hacmini göz önünde bulundurmanız gerekir. Az sayıda kiracı (beş veya daha az) varsa ve her kiracı için küçük miktarlarda veri depoluyorsanız, yüksek oranda ölçeklenebilir bir veri depolama yaklaşımını planlamak veya veri kaynaklarınızı yönetmek için tamamen otomatik bir yaklaşım oluşturmak çok çaba duyuyoruz. Büyüdükçe, veri ve depolama kaynaklarınızı ölçeklendirmeye yönelik açık bir stratejiye sahip olmanın yanı sıra kendi yönetimine Otomasyon uygulamanızı de daha fazla avantaj elde edersiniz. 50 kiracılar veya daha fazlasına sahipseniz veya bu ölçek düzeyine erişmeyi planlıyorsanız, önemli bir değerlendirme olarak ölçeklendirerek veri ve depolama yaklaşımınızı tasarlamak özellikle önemlidir.

Ölçeklendirmeyi planladığınız kapsamı göz önünde bulundurun ve bu ölçek düzeyini karşılamak için veri depolama mimari yaklaşımını açık bir şekilde planlayın.

Performans öngörülebilirlik

Çok kiracılı veri ve depolama hizmetleri özellikle gürültülü komşu sorunaaçıktır. Kiracılarınızın birbirlerinin performansını etkileyebileceğini göz önünde bulundurmanız önemlidir. Örneğin, Kiracılarınızın kullanım desenlerinde zaman içinde çakışan üst öğeler mi var? Tüm müşterileriniz, çözümünüzü her gün aynı anda mı kullanıyorsunuz, isterse eşit olarak dağıtılmış mı? Bu faktörler, tasarlamanız gereken yalıtımın düzeyini, sağlamanız gereken kaynak miktarını ve kiracılar arasında kaynakların paylaşılabileceği dereceyi etkiler.

Bu kararın bir parçası olarak Azure 'un kaynağını ve istek kotalarını göz önünde bulundurmanız önemlidir. Örneğin, Kiracılarınızın tüm verilerini içeren tek bir depolama hesabı dağıtdığınızı varsayalım. saniye başına belirli sayıda depolama işlemini aşarsanız Azure Depolama uygulamanızın isteklerini reddeder ve tüm kiracılarınız etkilenecektir. Bu, azaltma davranışı olarak adlandırılır. Kısıtlanmış istekleri izlemeniz önemlidir. Daha fazla bilgi için bkz. Azure hizmetleri Için yeniden deneme Kılavuzu .

Veri yalıtımı

Çok müşterili veri hizmetleri içeren bir çözüm tasarlarken, genellikle her biri kendi avantajları ve avantajları olan veri yalıtımının farklı seçenekleri ve düzeyleri vardır. Örnek:

• Azure Cosmos DB kullanırken, her kiracı için ayrı kapsayıcılar dağıtabilir ve birden çok kiracı arasında veritabanlarını ve hesapları paylaşabilirsiniz. Alternatif olarak, gereken yalıtım düzeyine bağlı olarak, her bir kiracı için farklı veritabanları veya hatta hesaplar dağıtmaya de göz önünde bulundurmanız gerekebilir.
• blob verileri için Azure Depolama kullanırken, her kiracı için ayrı blob kapsayıcıları dağıtabilir veya ayrı depolama hesapları dağıtabilirsiniz.
• Azure SQL kullanırken, paylaşılan veritabanlarında ayrı tablolar kullanabilir veya her kiracı için ayrı veritabanları veya sunucular dağıtabilirsiniz.
• Tüm Azure hizmetlerinde, tek bir paylaşılan Azure aboneliği içinde kaynak dağıtımı yapmayı düşünebilirsiniz veya birden çok Azure aboneliği (Belki de her kiracı için bile) kullanabilirsiniz.

Her durum için çalışacak tek çözüm yoktur. Seçtiğiniz seçenek, Kiracılarınızın bir dizi etkene ve gereksinimlerine bağlıdır. Örneğin, Kiracılarınızın belirli uyumluluk veya yasal standartları karşılaması gerekiyorsa, daha yüksek bir yalıtım düzeyi uygulamanız gerekebilir. Benzer şekilde, müşterilerinizin verilerini fiziksel olarak yalıtmak için ticari gereksinimleriniz olabilir veya gürültülü komşu sorunuönlemek için yalıtımı zorunlu kılabilirsiniz. Ayrıca, kiracıların kendi şifreleme anahtarlarını kullanması gerekiyorsa, bireysel yedekleme ve geri yükleme ilkelerine sahiptirler ya da bunların verilerinin farklı coğrafi konumlarda depolanması gerekir, bunları diğer kiracılardan yalıtmak veya benzer ilkeleri olan kiracılar ile gruplamak gerekebilir.

Uygulamanın karmaşıklığı

Uygulamanızın karmaşıklığını göz önünde bulundurmanız önemlidir. Gereksinimlerinize uygun olmaya devam ederken mimarinizi olabildiğince basit tutmanız iyi bir uygulamadır. Ölçeklendirdikçe giderek daha fazla karmaşık hale gelecek bir mimariye veya geliştirme ve bakım yapmak için kaynak veya uzmanlığı olmayan bir mimariye uygulamadan kaçının.

Benzer şekilde, çözümünüzün çok sayıda kiracıya ölçeklendirilmesi gerekmiyorsa veya performans ya da veri yalıtımına ilişkin endişeleriniz yoksa, çözümünüzü basit tutmanız ve gereksiz karmaşıklık eklemekten kaçınmak daha iyidir.

Çok kiracılı veri çözümleri için belirli bir sorun, destekettiğiniz özelleştirmenin düzeyidir. Örneğin, bir kiracı veri modelinizi genişletebilir veya özel veri kuralları uygulayabilir miyim? Bu ön uç için tasarlamanızı sağlayın. Bu, çözümünüzü test etmek ve güncelleştirmeleri dağıtmak için ölçeklendirme yeteneğinizi ortadan kaldırmak ve tek tek kiracılar için özel altyapı sağlamaktan kaçının. Bunun yerine, özellik bayraklarını ve diğer kiracı yapılandırması biçimlerini kullanmayı düşünün.

Yönetim ve işlemlerin karmaşıklığı

Çözümünüzü nasıl çalıştıracağınızı ve çoklu kiracı yaklaşımınızın işlemlerinizi ve işlemlerinizi nasıl etkilediğini göz önünde bulundurun. Örnek:

• Normal bakım etkinlikleri gibi çapraz kiracı yönetimi işlemlerini göz önünde bulundurun. Birden çok hesap, sunucu veya veritabanı kullanıyorsanız her kiracı için işlemleri nasıl başlatacaksınız ve izlersiniz?
• Kiracılarınızı izleyip ölçerler, çözümünüzün ölçümleri nasıl raporlediğini ve isteği tetikleyen kiracıya kolayca bağlanıp bağlanamayacağını göz önünde bulundurun.
• Yalıtılmış kiracıların içindeki raporlama verileri, her bir Kiracıdaki sorguları tek tek çalıştırmak ve sonra sonuçları toplamak yerine, her kiracının verileri merkezi bir veri ambarına yayımlamasına gerek duyar.
• Şemayı zorlayan bir veritabanı kullanırsanız, şema güncelleştirmelerini kendi koşullarınız genelinde nasıl dağıtacağınızı planlayın. Uygulamanızın belirli bir kiracının veritabanı sorguları için hangi şema sürümünün kullanılacağını öğrenin.
• Kiracılarınızın yüksek kullanılabilirlik gereksinimlerini (örneğin, çalışma süresi hizmet düzeyi sözleşmeleri veya SLA 'Lar) ve olağanüstü durum kurtarma gereksinimlerini (örneğin, kurtarma süresi hedefleri veya RTOs ve kurtarma noktası amaçları veya RPOs) göz önünde bulundurun. Kiracıların farklı beklentileri varsa, kiracının gereksinimlerini karşılayabilirsiniz.
• Kiracılar farklı bir hizmet türüne, farklı bir dağıtıma ya da başka bir bölgeye taşınmaya ihtiyaç duyduklarında nasıl geçiş yapılır?

Maliyet

Genellikle, kiracılar 'ın dağıtım altyapınızın yoğunluğu arttıkça, bu altyapıyı sağlama maliyeti düşüktür. Ancak, paylaşılan altyapı, gürültülü komşu sorunugibi sorunlar olasılığını artırır, bu yüzden avantajları dikkatle değerlendirin.

Göz önünde bulundurulması gereken yaklaşımlar ve desenler

Azure Mimari Merkezi çeşitli tasarım desenleri, Mulitenant depolama ve veri Hizmetleri ile ilgiden oluşur. Bir kalıbı sürekli olarak izlemeyi tercih edebilirsiniz. Ya da, desenleri karıştırmaya ve eşleştirmeye de göz önünde bulundurmanız gerekir. Örneğin, Kiracılarınızın çoğu için çok kiracılı bir veritabanı kullanabilir, ancak daha fazla ödeme yapan veya olağan dışı gereksinimlere sahip kiracılar için tek kiracılı damgalar dağıtabilirsiniz. Benzer şekilde, çok kiracılı bir veritabanı veya bir damga içinde parçalı veritabanları kullandığınızda bile, dağıtım damgaları kullanılarak ölçeklendirmek genellikle iyi bir uygulamadır.

Dağıtım damgaları stili

Dağıtım damgaları deseninin çok kiracılı bir çözümü desteklemek için nasıl kullanılabileceği hakkında daha fazla bilgi için bkz. genel bakış.

Paylaşılan çok kiracılı veritabanları ve dosya depoları

Paylaşılan bir çok kiracılı veritabanı, depolama hesabı veya dosya paylaşımı dağıtmaya ve bu dosyayı Kiracılarınızın tümünde paylaşmaya göz önünde bulundurmanız gerekir.

Bu yaklaşım, altyapıya kiracı için en yüksek yoğunluklu bir yaklaşım sağlar. bu nedenle, herhangi bir yaklaşımın en düşük maliyetine yaklaşmasını sağlar. Ayrıca, yönetilecek, yedeklenecek ve güvenli hale getirilebileceğiniz tek bir veritabanı veya kaynak olduğundan genellikle yönetim yükünü azaltır.

Ancak, paylaşılan altyapıyla çalışırken göz önünde bulundurmanız gereken birkaç uyarılar vardır:

• Tek bir kaynağa dayandığınızda, bu kaynağın desteklenen ölçeğini ve sınırlarını göz önünde bulundurun. Örneğin, bir veritabanının veya dosya deposunun en büyük boyutu veya en fazla aktarım hızı sınırı, mimariniz tek bir veritabanı kullanıyorsa, sonunda son bir engelleyici hale gelir. Bu kalıbı seçmeden önce elde etmeniz gereken maksimum ölçeği dikkatle düşünün ve geçerli ve gelecekteki limitleriyle karşılaştırın.
• Özellikle meşgul olan kiracılar varsa veya diğerlerinden daha yüksek iş yükleri oluşturursanız, gürültülü komşu sorun bir faktör haline gelebilir. Bu etkileri azaltmak için daraltma deseninin veya hız sınırlaması deseninin uygulanması düşünüldüğünde.
• Etkinliği izlemenin ve tek bir kiracının tüketimini ölçmekte güçlük yaşayabilirsiniz. Azure Cosmos DB gibi bazı hizmetler, her bir istek için kaynak kullanımı hakkında raporlama sağlar; bu nedenle, her bir kiracının tüketimini ölçmek üzere bu bilgiler izlenebilir. Diğer hizmetler aynı düzeyde ayrıntı sağlamaz. Örneğin, dosya kapasitesi için Azure dosyaları ölçümleri, yalnızca Premium paylaşımlar kullandığınızda dosya paylaşımı boyutu başına kullanılabilir. Ancak standart katman ölçümleri yalnızca depolama hesabı düzeyinde sağlar.
• Kiracılar güvenlik, yedekleme, kullanılabilirlik veya depolama konumu için farklı gereksinimlere sahip olabilir. Bunlar tek kaynağınızın yapılandırmasıyla eşleşmezse, bunlara uyum sağlayamayabilir.
• İlişkisel bir veritabanı veya veri şemasının önemli olduğu başka bir durumla çalışırken, kiracı düzeyinde şema özelleştirmesi zordur.

Parçalama düzeni

Parçalama düzeninde, bir veya daha fazla kiracının verilerini içeren birden fazla ayrı veritabanının dağıtımı vardır. Dağıtım damgalarından farklı olarak, parçalar bütün altyapının yinelendiği anlamına gelmez. Ayrıca, çözümünüzde diğer altyapıyı çoğaltmadan veya parçalara ayırmaya gerek kalmadan veritabanlarını parçalayabilirsiniz.

Parçalama, bölümlemeile yakından ilgilidir ve şartlar genellikle birbirinin yerine kullanılır. Yatay, dikey ve işlevsel veri bölümleme rehberini göz önünde bulundurabilirsiniz.

Parçalama düzeni çok fazla sayıda kiracıya ölçeklendirebilirsiniz. Buna ek olarak, iş yükünüze bağlı olarak, parçalara yüksek yoğunlukta kiracılar elde etmek mümkün olabilir, böylece maliyet cazip olabilir. Parçalama düzeni, Azure aboneliği ve hizmet kotaları, sınırları ve kısıtlamaları için de kullanılabilir.

Azure Cosmos DB gibi bazı veri depoları parçalama veya bölümleme için yerel destek sağlar. Azure SQL gibi diğer çözümlerle çalışırken, bir parçalama altyapısı oluşturmak ve istekleri bir kiracı için doğru parçaya yönlendirmek daha karmaşık olabilir.

Her kiracı için ayrılmış veritabanlarına sahip çok kiracılı uygulama

Bir diğer yaygın yaklaşım da her kiracı için ayrılmış veritabanlarıyla tek bir çok kiracılı uygulama dağıtmaktır.

Bu modelde, her kiracının verileri diğer kiracılardan yalıtılmış ve her kiracı için bir ölçüde özelleştirmeyi destekleyebilirsiniz.

Her kiracı için ayrılmış veri kaynakları sağlarken, bu yaklaşımın maliyeti paylaşılan barındırma modellerinden daha yüksek olabilir. Ancak Azure, tek tek veri kaynaklarını birden çok kiracıda barındırmanın maliyetini paylaşmak için göz önünde bulundurabilirsiniz çeşitli seçenekler sunar. Örneğin, Azure veritabanı ile SQL elastik havuzları göz önünde bulundurabilirsiniz. Azure Cosmos DB için bir veritabanı için aktarım hızı sabilirsiniz ve aktarım hızı söz konusu veritabanındaki kapsayıcılar arasında paylaşılır, ancak her kapsayıcı için garantili performansa ihtiyacınız olduğunda bu yaklaşım uygun değildir.

Bu yaklaşımda, her kiracı için tek tek yalnızca veri bileşenleri dağıtıldığından, büyük olasılıkla çözümünüzde diğer bileşenler için yüksek yoğunluk elde ediyor ve bu bileşenlerin maliyetini azaltabilirsiniz.

Her kiracı için veritabanları sağlarken otomatik dağıtım yaklaşımlarını kullanmak önemlidir.

Coğrafi bölge düzeni

Coğrafi Bölge düzeni, çok kullanıcılı çözümler de dahil olmak üzere coğrafi olarak dağıtılmış çözümler için özel olarak tasarlanmıştır. Yüksek yük ve yüksek düzeydekileri destekler. Coğrafi Bölge düzeniyle çalışırken, veri katmanı verileri coğrafi bölgeler arasında çoğaltabilecek ve çok coğrafyalı yazmaları desteklemeli.

Azure Cosmos DB, bu düzeni desteklemek için çoklu ana kaynak yazmaları sağlar ve Cassandra çok bölgeli kümeleri destekler. Diğer veri hizmetleri, önemli özelleştirmeler olmadan bu düzeni genel olarak destekleyemmektedir.

Kaçınılması gereken antipatterns

Çok kullanıcılı veri hizmetleriyle çalışırken ölçeklendirme becerinizi engelleyen durumlardan kaçınmak önemlidir.

İlişkisel veritabanları için şunlar dahildir:

• Tablo tabanlı yalıtım. Tek bir veritabanı içinde çalışıyorken, her kiracı için ayrı tablolar oluşturmaktan kaçının. Bu yaklaşımı kullanırken tek bir veritabanı çok fazla sayıda kiracıyı desteklemez ve verileri sorgulamak, yönetmek ve güncelleştirmek giderek daha zor hale gelir. Bunun yerine, kiracı tanımlayıcısı sütunuyla tek bir çok kiracılı tablo kümesi kullanmayı göz önünde bulundurabilirsiniz. Alternatif olarak, her kiracı için ayrı veritabanları dağıtmak üzere yukarıda açıklanan desenlerden birini kullanabilirsiniz.
• Sütun düzeyinde kiracı özelleştirmesi. Yalnızca tek bir kiracı için geçerli olan şema güncelleştirmelerini uygulamaktan kaçının. Örneğin, tek bir çok kullanıcılı veritabanınız olduğunu varsayalım. Belirli bir kiracının gereksinimlerini karşılamak için yeni bir sütun eklemekten kaçının. Bu, az sayıda özelleştirme için kabul edilebilir olabilir, ancak göz önünde bulundurarak çok sayıda özelleştirme olduğunda bu hızla kullanılamaz hale gelir. Bunun yerine, ayrılmış bir tablodaki her kiracıya yönelik özel verileri izlemek için veri modelinizi gözden geçirilmesini göz önünde bulundurabilirsiniz.
• El ile şema değişiklikleri. Yalnızca tek bir paylaşılan veritabanınız olsa bile veritabanı şemanızı el ile güncelleştirmekten kaçının. Uygulamakta olduğu güncelleştirmeleri kolayca izleyebilirsiniz ve ölçeği daha fazla veritabanına ölçeklendirmeniz gerekirse uygulanacak doğru şemayı belirlemek zordur. Bunun yerine, şema değişikliklerinizi dağıtmak için otomatik bir işlem hattı oluşturabilir ve bunu tutarlı bir şekilde kullanabilirsiniz. Ayrılmış bir veritabanında veya arama tablosunda her kiracı için kullanılan şema sürümünü takip edin.
• Sürüm bağımlılıkları. Uygulamanın veritabanı şemanın tek bir sürümüne bağımlılığından kaçının. Ölçeklendirilirken farklı kiracılar için farklı zamanlarda şema güncelleştirmeleri uygulamanız gerekir. Bunun yerine, uygulama sürümünün en az bir şema sürümüyle geriye dönük uyumlu olduğundan emin olun ve yıkıcı şema güncelleştirmelerinden kaçının.

Veritabanları

Çok kullanıcılılık için yararlı olan bazı özellikler vardır. Ancak, bunlar tüm veritabanı hizmetlerde kullanılamaz. Senaryo için kullanmak üzere hizmete karar verdiyken bunlara ihtiyacınız olup olmadığını göz önünde önünde önünden düşünün:

• Satır düzeyi güvenlik, paylaşılan çok kiracılı bir veritabanında belirli kiracıların verileri için güvenlik yalıtımı sağlar. Bu özellik Azure SQL ve Postgres Flex'te kullanılabilir, ancak MySQL veya Azure Cosmos DB gibi diğer veritabanlarında kullanılamaz.
• Kiracı düzeyinde şifreleme, verileri için kendi şifreleme anahtarlarını sağlayan kiracıları desteklemek üzere gerekli olabilir. Bu özellik, azure SQL bir parçası olarak Always Encrypted. Cosmos DB, hesap düzeyinde müşteri tarafından yönetilen anahtarlar sağlar ve aynı zamanda Always Encrypted.
• Kaynak havuzu, kaynakları ve maliyeti birden çok veritabanı veya kapsayıcı arasında paylaşma olanağı sağlar. Bu özellik Azure SQL'nin elastik havuzlarında ve yönetilen örneklerde ve Azure Cosmos DB'nin veritabanı aktarım hızında kullanılabilir, ancak her seçeneğin farkında olması gereken sınırlamaları vardır.
• Parçalama ve bölümleme, bazı hizmetlerde diğerlerine göre daha güçlü yerel destek sunar. Bu özellik Azure Cosmos DB'de, mantıksal ve fiziksel bölümleme kullanılarak vePostgres Hiper Ölçek'te kullanılabilir. Azure SQL parçalamayı yerel olarak desteklemese de, bu tür mimariyi desteklemek için parçalama araçları sağlar.

Buna ek olarak, ilişkisel veritabanları veya diğer şema tabanlı veritabanlarıyla çalışırken, bir veritabanı filosunu bulundurarak şema yükseltme işleminin nerede tetiklenir gerektiğini göz önünde bulundurabilirsiniz. Küçük veritabanlarında, şema değişikliklerini dağıtmak için bir dağıtım işlem hattı kullanmayı düşünebilirsiniz. Büyüdükçe, uygulama katmanınız için belirli bir veritabanının şema sürümünü algılamak ve yükseltme işlemini başlatmak daha iyi olabilir.

Dosya ve blob depolama

Depolama hesabı içindeki verileri yalıtmak için kullanabileceğiniz yaklaşımı göz önünde bulundurabilirsiniz. Örneğin, her kiracı için ayrı depolama hesapları dağıtabilirsiniz veya depolama hesaplarını paylaşabilir ve tek tek kapsayıcıları dağıtabilirsiniz. Alternatif olarak, paylaşılan blob kapsayıcıları oluşturabilir ve ardından her kiracı için verileri ayırmak üzere blob yolunu kullanabilirsiniz. Azure abonelik limitlerini ve kotalarını gözönünde bulundurarak, Azure kaynaklarınızı gelecekteki ihtiyaçları destekleyecek şekilde ölçeklendirilenden emin olmak için büyümenizi dikkatle plan edin.

Paylaşılan kapsayıcıları kullanıyorsanız, kiracıların birbirlerinin verilerine erişenemlerini sağlamak için kimlik doğrulama ve yetkilendirme stratejinizi dikkatli bir şekilde planlamalısınız. İstemcilere Azure anahtar kaynaklarınaerişim sağlarken Vale Anahtarı Depolama düşünün.

Maliyet ayırma

Paylaşılan veri hizmetlerinin kullanımı için tüketimi nasıl ölçtüyebilirsiniz vemaliyetleri kiracılara nasıl ayırabilirsiniz? Mümkün olduğunda, kendi ölçümlerinizi hesaplamak yerine yerleşik ölçümleri kullanmayı hedefle. Ancak paylaşılan altyapıda kiracılar için telemetri verileri bölmek zor hale gelir. Uygulama düzeyinde özel ölçüm dikkate alınmalıdır.

Genel olarak, Azure Cosmos DB ve Azure Blob Depolama gibi buluta özel hizmetler, belirli bir kiracının kullanımını izlemek ve modellemek için daha ayrıntılı ölçümler sağlar. Örneğin, Azure Cosmos DB her istek ve yanıt için tüketilen aktarım hızını sağlar.

Sonraki adımlar

Çok kullanıcılılık ve belirli Azure hizmetleri hakkında daha fazla bilgi için bkz:

• Çok kullanıcılılık ve Azure Depolama
• Çok kullanıcılılık ve Azure SQL Veritabanı
• Çok kullanıcılılık ve Azure Cosmos DB