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

Veriler, sizin ve müşterilerinizin değerli iş bilgilerini temsil ettiği için genellikle çözümün en değerli parçası olarak kabul edilir. Verilerinizi dikkatli bir şekilde yönetmek önemlidir. Çok kiracılı bir sistem için depolama veya veri bileşenleri planlarken kiracılarınızın verilerini paylaşma veya yalıtma yaklaşımına karar vermeniz gerekir.

Bu makalede, çok kiracılı bir sistemde veri depolamaya yönelik bir yaklaşıma karar veren çözüm mimarları için önemli noktalar ve gereksinimler hakkında rehberlik sağlanır. Bu makalede ayrıca depolama ve veri hizmetlerine çok kiracılı uygulamayla ilgili bazı yaygın desenler ve kaçınılması gereken bazı kötü amaçlı modeller açıklanmaktadır. Ayrıca bazı belirli senaryolar için hedefli rehberlik sağlar.

Önemli noktalar ve gereksinimler

Depolama ve veri hizmetleri için kullandığınız yaklaşımları , Azure Well-Architected Framework'ün temelleri de dahil olmak üzere çeşitli perspektiflerden ele almak önemlidir.

Ölçek

Verilerinizi depolayan hizmetlerle çalışırken sahip olduğunuz kiracı sayısını ve depoladığınız veri hacmini dikkate almanız gerekir. Beş veya daha az kiracı gibi az kiracınız varsa ve her kiracı için az miktarda veri depolarsanız, büyük olasılıkla yüksek oranda ölçeklenebilir bir veri depolama yaklaşımı planlamanız veya veri kaynaklarınızı yönetmek için tam otomatik bir yaklaşım oluşturmanız gerekmez.

Ancak büyüdükçe, verilerinizi ve depolama kaynaklarınızı ölçeklendirmek ve bunların yönetimini otomatikleştirmek için net bir stratejiye sahip olma avantajından giderek daha fazla yararlanabilirsiniz. 50 veya daha fazla kiracınız varsa veya bu ölçek düzeyine ulaşmayı planlıyorsanız, önemli bir nokta olarak verilerinizi ve depolama yaklaşımınızı ölçekle tasarlamanız özellikle önemlidir.

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

Performans öngörülebilirliği

Çok kiracılı veri ve depolama hizmetleri gürültülü komşu sorununa açıktır. Kiracılarınızın birbirlerinin performansını etkileyip etkilemeyebileceğini göz önünde bulundurmanız önemlidir. Örneğin, kiracılarınızın zaman içinde kullanım düzenlerinde çakışan zirvelere sahip olup olmadığını göz önünde bulundurun. Ayrıca tüm müşterilerinizin çözümünüzü her gün aynı anda kullanıp kullanmadığını ve isteklerin eşit olarak dağıtılıp dağıtılmadığını da göz önünde bulundurun. Bu faktörler, tasarlamanız gereken yalıtım düzeyini, sağlamanız gereken kaynak miktarını ve kiracıların kaynakları ne derece paylaşabileceğini etkiler.

Bu kararın bir parçası olarak Azure kaynağının ve istek kotalarının dikkate alınması önemlidir. Örneğin, kiracılarınızın tüm verilerini içerecek tek bir depolama hesabı dağıttığınızı varsayalım. Saniye başına belirli bir depolama işlemi sayısını aşarsanız, Azure Depolama uygulamanızın isteklerini reddeder ve bu da tüm kiracılarınızı etkiler. Bu davranışa azaltma denir. Kısıtlanmış istekleri izlemeniz oldukça önemlidir.

Veri yalıtımı

Çoğul kiracılı veri hizmetleri içeren bir çözüm tasarlarken, kendine özgü avantajları ve ödünleri olan farklı veri yalıtımı seçenekleri ve düzeyleri vardır. Aşağıdaki örnekleri göz önünde bulundurun:

• Azure Cosmos DB'yi kullandığınızda, her kiracı için ayrı kapsayıcılar dağıtabilir ve veritabanlarını ve hesapları birden çok kiracı arasında paylaşabilirsiniz. Alternatif olarak, ihtiyacınız olan yalıtım düzeyine bağlı olarak her kiracı için farklı veritabanları ve hatta hesaplar dağıtmayı düşünebilirsiniz.

• Blob verileri için Depolama'yı kullandığınızda, 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, kaynakları tek bir paylaşılan Azure aboneliği içinde dağıtmayı göz önünde bulundurabilir veya her kiracı için birden çok Azure aboneliği ve hatta bir abonelik kullanabilirsiniz.

Her senaryo için çalışan tek bir çözüm yoktur. Seçtiğiniz seçenek çeşitli faktörlere ve kiracılarınızın gereksinimlerine bağlıdır. Örneğin, işletmeden müşteriye (B2C) bir çözüm tasarlarsanız, tüm verileriniz için tek bir veri deposuna sahip olmak mantıklı olabilir. Ancak kiracılarınızın belirli uyumluluk veya mevzuat standartlarını 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 sorununu önlemek için yalıtımı zorunlu kılmanız gerekebilir. Aşağıdaki koşullardan herhangi biri geçerliyse, kiracıları diğerlerinden yalıtmanız veya benzer ilkelere sahip kiracılarla gruplandırmanız gerekebilir:

• Kiracıların kendi şifreleme anahtarlarını kullanması gerekir
• Kiracıların tek tek yedekleme ve geri yükleme ilkeleri vardır
• Kiracıların verilerinin farklı coğrafi konumlarda depolanması gerekir

Uygulamanın karmaşıklığı

Uygulamanızın karmaşıklığını göz önünde bulundurmanız önemlidir. Mimarinizi mümkün olduğunca basit tutmak ve gereksinimlerinizi karşılamaya devam etmek iyi bir uygulamadır. Ölçeklendirdikçe giderek daha karmaşık hale gelecek bir mimariye veya geliştirme ve bakım için kaynaklara veya uzmanlığa sahip olmadığınız bir mimariye bağlanmaktan kaçının.

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

Çok kiracılı veri çözümleri için özel bir endişe, desteklediğiniz özelleştirme düzeyidir. Örneğin, bir kiracının veri modelinizi genişletmesine veya özel veri kuralları uygulamasına izin vekleyebilirsiniz. Bu gereksinim için en önde tasarım yaptığınızdan emin olun. Her kiracı için fork oluşturma veya özelleştirilmiş altyapı sağlamaktan kaçının. Özelleştirilmiş altyapı ölçeklendirme, çözümünüzü test etme ve güncelleştirmeleri dağıtma yeteneğinizi engeller. Bunun yerine özellik bayraklarını ve diğer kiracı yapılandırması biçimlerini kullanmayı göz önünde bulundurun.

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

Çözümünüzü nasıl çalıştırmayı planladığınızı ve çok kiracılı yaklaşımınızın operasyonlarınızı ve süreçlerinizi nasıl etkilediğini düşünün.

• Yönetim: Düzenli bakım etkinlikleri gibi yönetim işlemlerini göz önünde bulundurun. Birden çok sunucu, dosya deposu veya veritabanı kullanıyorsanız, her kiracının kaynakları için bakım işlemlerinin nasıl başlatılıp izleneceğini planlayın.

• İzleme ve ölçüm: Kiracılarınızı izler veya ölçerseniz, çözümünüzün ölçümleri nasıl bildirdiğini ve ölçümleri isteği tetikleyen kiracıya kolayca bağlayıp bağlayamayacağını göz önünde bulundurun.

• Raporlama: Birden çok yalıtılmış kiracıdan toplanan verileri raporlamanız gerekip gerekmediğini göz önünde bulundurun. Çözümünüz ölçeklendikçe, her veritabanında ayrı ayrı sorgu çalıştırmak ve sonuçları toplamak zahmetli hale gelir. Farklı bir yaklaşım, her kiracının uygulamalarının verileri merkezi bir veri ambarına yayımlamasını sağlamaktır.

• Şema güncelleştirmeleri: Şemayı zorlayan bir veritabanı kullanıyorsanız, şema güncelleştirmelerini varlığınız arasında nasıl dağıtabileceğinizi planlayın. Uygulamanızın belirli bir kiracının veritabanı sorguları için hangi şema sürümünü kullanacağınızı nasıl bildiğini düşünün.

• Gereksinim -leri: Kiracılarınızın çalışma süresi hizmet düzeyi sözleşmeleri (SLA' lar) gibi yüksek kullanılabilirlik gereksinimlerini ve kurtarma süresi hedefleri (GPO'lar) ve kurtarma noktası hedefleri (RPO'lar) gibi olağanüstü durum kurtarma gereksinimlerini göz önünde bulundurun. Kiracıların farklı beklentileri varsa, her kiracının gereksinimlerini karşılayabildiğinizi doğrulayın.

• Göç: Kiracıların farklı bir hizmet türüne, farklı bir dağıtıma veya başka bir bölgeye taşınmasını sağlamak isteyip istemediğinizi düşünün. Bu özelliği sunmayı planlıyorsanız, tekrarlanabilir ve güvenli bir işlem olduğundan emin olmak için süreçler ve araçlar oluşturun.

Maliyet

Genellikle, kiracıların dağıtım altyapınızdaki yoğunluğu ne kadar yüksek olursa, bu altyapıyı sağlama maliyeti de o kadar düşük olur. Ancak, paylaşılan altyapı gürültülü komşu sorunu gibi sorunların olasılığını artırır, bu nedenle dengeleri dikkatli bir şekilde değerlendirin.

Dikkate alınacak yaklaşımlar ve desenler

Azure Mimari Merkezi'nden alınan çeşitli tasarım desenleri, çok kiracılı depolama ve veri hizmetleriyle ilgilidir. Tek bir deseni tutarlı bir şekilde izlemeyi seçebilirsiniz. İsterseniz, desenleri karıştırmayı ve eşleştirmeyi de düşünebilirsiniz. Örneğin, kiracılarınızın çoğu için çok kiracılı bir veritabanı kullanabilirsiniz, ancak daha fazla ödeme yapan veya olağan dışı gereksinimleri olan kiracılar için tek kiracılı damga damgaları dağıtabilirsiniz.

Dağıtım Damgaları Şablonu

Çok kullanıcılı bir çözümü desteklemek için Dağıtım Damgaları deseni kullanma hakkında daha fazla bilgi için bkz. Genel Bakış.

Tavsiye

Çok kiracılı çözümlerde dağıtım damgaları oluşturmak iyi bir uygulamadır. Bu öneri, çok kiracılı bir veritabanı veya bir damga içinde parçalanmış veritabanları kullandığınızda bile geçerlidir. Çözümünüzü damga olarak modelleyerek, yeni iş fırsatları ortaya çıktıktan sonra kolayca yeniden dağıtabilirsiniz.

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

Paylaşılan bir çok kiracılı veritabanı, depolama hesabı veya dosya paylaşımı dağıtmayı ve tüm kiracılarınızda paylaşmayı düşünebilirsiniz.

Diyagram üç mavi kutudan ve bir gri kutudan oluşur. İlk mavi kutu Kiracı A olarak etiketlenmiştir. İkinci mavi kutu, Kiracı B olarak etiketlenmiştir. Üçüncü mavi kutu Kiracı C olarak etiketlenmiştir. Mavi kutulardan gri kutuya kadar olan ok noktaları Paylaşılan kaynaklar olarak etiketlenir. Paylaşılan kaynaklar kutusu, bir web sunucusunu temsil eden bir simge ve A, B ve C kiracılarını temsil eden bir simge içerir.

Bu yaklaşım, altyapıya en yüksek kiracı yoğunluğu sağlar, bu nedenle herhangi bir yaklaşımın en düşük finansal maliyetine sahip olma eğilimindedir. Ayrıca yönetilmesi, yedeklenmesi ve güvenliğinin sağlanıp sağlanmadığı tek bir veritabanı veya kaynak olduğundan genellikle yönetim ek yükünü azaltır.

Ancak, paylaşılan altyapıyla çalışırken aşağıdaki dezavantajları göz önünde bulundurun:

• Ölçek sınırları: Tek bir kaynağa bağlı olduğunuzda, bu kaynağın desteklenen ölçeğini ve sınırlarını göz önünde bulundurun. Örneğin, mimariniz tek bir paylaşılan veritabanına, bir veritabanı veya dosya deposunun maksimum boyutuna veya en yüksek aktarım hızı sınırlarına bağlıysa, sonunda katı bir engelleyici haline gelir. Bu düzeni seçmeden önce, elde etmeniz gereken maksimum ölçeği dikkatle göz önünde bulundurun ve geçerli ve gelecekteki sınırlarınızla karşılaştırın.

• Gürültülü komşular: Gürültülü komşu sorunu , özellikle meşgul olan veya diğerlerinden daha yüksek iş yükleri oluşturan kiracılarınız varsa bir faktör haline gelebilir. Bu etkileri azaltmak için Azaltma desenini veya Hız Sınırlama desenini uygulamayı göz önünde bulundurun.

• Kiracıların tüketimini ölçme: Her kiracının tüketimini ölçmeniz gerekip gerekmediğini göz önünde bulundurun. Azure Cosmos DB gibi bazı veri hizmetleri, her işlem için kaynak kullanımıyla ilgili raporlama sağlar. Bu bilgileri izleyebilir ve her kiracının tüketimini ölçmek için toplayabilirsiniz. Diğer hizmetler aynı ayrıntı düzeyini sağlamaz. Örneğin, Premium dosya paylaşımlarıyla Azure Dosyalar'ı kullandığınızda, her dosya paylaşımı boyutu için dosya kapasitesi ölçümlerine erişebilirsiniz. Standart katman ölçümleri yalnızca depolama hesabı düzeyinde sağlar.

• Kiracı gereksinimleri: Kiracıların güvenlik, yedekleme, kullanılabilirlik veya depolama konumu için farklı gereksinimleri olabilir. Bu gereksinimler tek kaynağınızın yapılandırmasıyla eşleşmiyorsa bunları karşılayamayabilirsiniz.

• Şema özelleştirmesi: İlişkisel bir veritabanıyla veya verilerin şemasının önemli olduğu başka bir senaryoyla çalıştığınızda, kiracı düzeyinde şema özelleştirmesi zordur.

Parçalama düzeni

Parçalama düzeni, her biri bir veya daha fazla kiracının verilerini içeren parçalar olarak adlandırılan birden çok ayrı veritabanının dağıtılmasını içerir. Dağıtım damgalarından farklı olarak parçalar, altyapının tamamının çoğaltıldığı anlamına gelmez. Ayrıca çözümünüzdeki diğer altyapıyı çoğaltmadan veya parçalamadan veritabanlarını parçalayabilirsiniz.

Diyagram üç mavi kutudan ve bir gri kutudan oluşur. İlk mavi kutu Kiracı A olarak etiketlenmiştir. İkinci mavi kutu, Kiracı B olarak etiketlenmiştir. Üçüncü mavi kutu Kiracı C olarak etiketlenmiştir. Mavi kiracı kutularından gri kutuya ok işareti. Gri kutu, Web sunucusu (Paylaşılan) etiketli daha küçük bir kutu içerir. Gri kutu ayrıca parçalar için üç simge içerir. Bir simge Bölüm haritası olarak etiketlenmiş. İkinci simge Parça 1, üçüncü simge ise Parça 2 olarak etiketlenmiştir. A ve B kiracıları parça 1'i paylaşır ve C kiracısı parça 2'yi kullanır.

Sharding, bölümlendirme ile yakından ilişkilidir ve terimler genellikle birbirinin yerine kullanılır. Yatay, dikey ve işlevsel veri bölümleme kılavuzunu göz önünde bulundurun.

Parçalama düzeni çok sayıda kiracıya ölçeklendirilebilir. İş yükünüze bağlı olarak, parçalar için yüksek kiracı yoğunluğu elde edebilirsiniz ve bu da maliyetleri düşürebilir. Azure aboneliğini ve hizmet kotalarını, sınırlarını ve kısıtlamalarını ele almak için Parçalama desenini kullanabilirsiniz.

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, parçalama altyapısı oluşturmak ve istekleri belirli bir kiracı için doğru parçaya yönlendirmek daha karmaşık olabilir.

Parçalama, kiracı düzeyinde yapılandırma farklılıklarını desteklemeyi ve müşterilerin kendi şifreleme anahtarlarını sağlamasını da zorlaştırır.

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

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

Diyagram üç mavi kutudan ve bir gri kutudan oluşur. İlk mavi kutu Kiracı A olarak etiketlenmiştir. İkinci mavi kutu, Kiracı B olarak etiketlenmiştir. Üçüncü mavi kutu Kiracı C olarak etiketlenmiştir. Mavi kutulardan gri kutuya ok noktaları. Gri kutu, Web sunucusu (Paylaşılan) etiketli daha küçük bir kutu içerir. Ayrıca Kiracı A, Kiracı B ve Kiracı C etiketli üç simge içerir.

Bu modelde, her kiracının verileri diğerlerinin verilerinden yalıtılır ve her kiracı için bir miktar özelleştirmeyi destekleyebilirsiniz.

Her kiracı için ayrılmış veri kaynakları sağladığınız için 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 bulundurabileceğiniz çeşitli seçenekler sunar. Örneğin, Azure SQL Veritabanı ile çalışırken elastik havuzları göz önünde bulundurabilirsiniz. Azure Cosmos DB için bir veritabanı için aktarım hızı sağlayabilirsiniz ve aktarım hızı bu 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, çözümünüzdeki diğer bileşenler için yüksek yoğunluk elde edebilir ve bu bileşenlerin maliyetini düşürebilirsiniz.

Uyarı

Her kiracı için veritabanları sağlarken otomatik dağıtım yaklaşımlarını kullanmak önemlidir. Aksi takdirde, veritabanlarını el ile dağıtma ve yönetme karmaşıklığı zorlaşır.

Jeot deseni

Geode deseni, çok kiracı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 dayanıklılık düzeylerini destekler. Coğrafi bölge desenini uygularsanız, veri katmanınızın verileri coğrafi bölgeler arasında çoğaltabilmesi ve birden çok coğrafi yazma işlemini desteklemesi gerekir.

Diyagram üç mavi kutu ve dört gri kutudan oluşur. İlk mavi kutu Kiracı A olarak etiketlenmiştir. İkinci mavi kutu, Kiracı B olarak etiketlenmiştir. Üçüncü mavi kutu Kiracı C olarak etiketlenmiştir. Mavi kutulardan ok noktalarına Genel Yük Dengeleyici etiketli gri bir kutuya işaret eder. Kiracı A'dan gelen ok, genel yük dengeleyici üzerinden Bölge 1 isimli gri bir kutuya doğru devam eder. Bir web sunucusu ve veritabanı içerir. Kiracı B'den çıkan ok, küresel yük dengeleyici üzerinden Bölge 2 etiketli gri bir kutuya kadar devam eder. Bir web sunucusu ve veritabanı içerir. C kiracısından gelen ok, global yük dengeleyiciden Bölge 3 olarak etiketlenmiş gri bir kutuya uzanmaya devam eder. Bir web sunucusu ve veritabanı içerir. İki taraflı oklar, bölge kutularının her birinde veritabanından veritabanına işaret eder.

Azure Cosmos DB, bu düzeni desteklemek için birden çok bölge yazma işlemi sağlar ve Apache Cassandra için Azure Yönetilen Örneği birden çok bölgeli kümeleri destekler. Diğer veri hizmetleri genellikle önemli özelleştirmeler olmadan bu düzeni destekleyemez.

Kaçınılması gereken antipatternler

Çok kiracılı veri hizmetleri oluşturduğunuzda, ölçeklendirme yeteneğinizi engelleyen durumlardan kaçınmak önemlidir.

İlişkisel veritabanları için bu kötü amaçlı değişkenler şunlardır:

• Tablo tabanlı yalıtım. Tek bir veritabanında çalışırken, her kiracı için ayrı tablolar oluşturmaktan kaçının. Bu yaklaşımı kullandığınızda tek bir veritabanı çok sayıda kiracıyı destekleyemez ve verileri sorgulamak, yönetmek ve güncelleştirmek giderek zorlaşır. Bunun yerine, kiracı tanımlayıcı sütununa sahip tek bir çok kiracılı tablo kümesi kullanmayı göz önünde bulundurun. Alternatif olarak, her kiracı için ayrı veritabanları dağıtmak için önerilen bir desen kullanabilirsiniz.

• Sütun düzeyinde kiracı özelleştirmesi. Yalnızca tek bir kiracı için geçerli olan şema güncelleştirmelerinden kaçının. Örneğin, tek bir çok kiracılı veritabanınız olduğunu varsayalım. Belirli bir kiracının gereksinimlerini karşılamak için yeni sütun eklemekten kaçının. Birkaç özelleştirme için kabul edilebilir olabilir, ancak dikkate almanız gereken birçok özelleştirme olduğunda bu yöntem hızla yönetilemez hale gelir. Bunun yerine, ayrılmış bir tablodaki her kiracı için özel verileri izlemek üzere veri modelinizi gözden geçirmeyi göz önünde bulundurun.

• El ile şema değişiklikleri. Tek bir paylaşılan veritabanınız olsa bile veritabanı şemanızı el ile güncelleştirmekten kaçının. Uyguladığınız güncellemelerin izini kaybetmek kolaydır ve daha fazla veritabanına yayılmanız gerektiğinde, uygulanacak doğru şemayı belirlemek zordur. Bunun yerine, şema değişikliklerinizi dağıtmak için araçlar veya otomatik bir işlem hattı oluşturun ve bunu tutarlı bir şekilde kullanın. Ayrılmış bir veritabanında veya arama tablosundaki her kiracı için kullandığınız şema sürümünü izleyin.

• Sürüm bağımlılıkları. Uygulamanızın veritabanı şemanızın tek bir sürümüne bağımlılık almasını önlemek. Ölçeklendikçe, farklı kiracılar için şema güncelleştirmelerini farklı zamanlarda uygulamanız gerekebilir. Bunun yerine, uygulama sürümünüzün en az bir önceki şema sürümüyle geriye dönük uyumlu olduğundan emin olun ve geri almayı desteklemek için birden çok sürümde yıkıcı şema değişikliklerini sıralayın.

Veritabanları

Çok kiracılı kullanım için yararlı olabilecek bazı özellikler vardır. Ancak bu özellikler tüm veritabanı hizmetlerinde kullanılamaz. Senaryonuz için kullanılacak hizmete karar verince aşağıdaki özelliklere ihtiyacınız olup olmadığını göz önünde bulundurun:

• Satır düzeyi güvenlik , paylaşılan çok kiracılı veritabanında belirli kiracıların verileri için güvenlik yalıtımı sağlayabilir. Bu özellik SQL Veritabanı ve PostgreSQL için Azure Veri Tabanı gibi bazı veritabanlarında kullanılabilir.

  Satır düzeyi güvenlik kullandığınızda, kullanıcının kimliğinin ve kiracı kimliğinin uygulama aracılığıyla ve her sorguyla veri deposuna yayıldığından emin olmanız gerekir. Bu yaklaşım tasarım, uygulama, test ve bakım açısından karmaşık olabilir. Birçok çok kiracılı çözüm, bu karmaşıklıklar nedeniyle satır düzeyi güvenlik kullanmaz.

• Verileri için kendi şifreleme anahtarlarını sağlayan kiracıları desteklemek için kiracı düzeyinde şifreleme gerekebilir. Bu özellik , Always Encrypted'ın bir parçası olarak SQL Server ve Azure SQL'de kullanılabilir. Azure Cosmos DB, hesap düzeyinde müşteri tarafından yönetilen anahtarlar sağlar ve Always Encrypted'ı da destekler.

• Kaynak havuzu, kaynakları ve bunların maliyetlerini birden çok veritabanı veya kapsayıcı arasında paylaşmanızı sağlar. Bu özellik SQL Veritabanı elastik havuzlarında, Azure SQL Yönetilen Örneği'nde ve Azure Cosmos DB veritabanı aktarım hızında kullanılabilir.

• Parçalama ve bölümleme , bazı hizmetlerde diğerlerine göre daha güçlü yerel desteğe sahiptir. Bu özellik Azure Cosmos DB'de mantıksal ve fiziksel bölümleme kullanılarak kullanılabilir. SQL Veritabanı parçalama işlemini yerel olarak desteklemese de, bu tür mimariyi desteklemek için parçalama araçları sağlar.

Ayrıca, ilişkisel veritabanlarından veya diğer şema tabanlı veritabanlarından oluşan bir filo tutarken, şema yükseltme işleminin nerede tetiklenmesi gerektiğini göz önünde bulundurun. Küçük bir veritabanı varlığında, şema değişikliklerini dağıtmak için bir dağıtım işlem hattı kullanmayı düşünebilirsiniz. Veritabanı sayısı arttıkça, uygulama katmanınızın belirli bir veritabanının şema sürümünü algılaması ve yükseltme işlemini başlatması daha iyi olabilir.

Dosya ve blob depolama

Depolama hesabındaki verileri yalıtmak için kullandığınız yaklaşımı göz önünde bulundurun. Örneğin, her kiracı için ayrı depolama hesapları dağıtabilir 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 blob yolunu kullanarak her kiracı için verileri ayırabilirsiniz. Azure abonelik sınırlarını ve kotalarını göz önünde bulundurun ve Azure kaynaklarınızın gelecekteki gereksinimlerinizi destekleyecek şekilde ölçeklendirildiğinden emin olmak için büyümenizi dikkatlice planlayın.

Paylaşılan kapsayıcılar kullanıyorsanız, kiracıların birbirlerinin verilerine erişememelerini sağlamak için kimlik doğrulama ve yetkilendirme stratejinizi dikkatlice planlayın. İstemcilere Depolama kaynaklarına erişim sağlarken Vale Anahtarı düzenini göz önünde bulundurun.

Maliyet tahsisatı

Paylaşılan veri hizmetlerinin kullanımı için tüketimi nasıl ölçtütebileceğinizi ve kiracılara maliyetleri nasıl ayırabileceğinizi düşünün. Mümkün olduğunda, kendi ölçümünüzü hesaplamak yerine yerleşik ölçümleri kullanmayı hedefleyin. Ancak paylaşılan altyapıda, tek tek kiracılar için telemetriyi bölmek zorlaşır ve uygulama düzeyinde özel ölçüm yapmayı göz önünde bulundurmanız gerekebilir.

Genel olarak, Azure Cosmos DB ve Azure Blob Depolama gibi bulutta yerel 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.

Katkıda Bulunanlar

Microsoft bu makaleyi korur. Bu makaleyi aşağıdaki katkıda bulunanlar yazdı.

Asıl yazar:

• John Downs | Baş Yazılım Mühendisi, Azure Desenleri ve Uygulamaları

Diğer katkıda bulunanlar:

• Paul Burpo | Baş Müşteri Mühendisi, Azure için FastTrack
• Daniel Scott-Raynsford | İş Ortağı Teknoloji Stratejisti
• Arsen Vladimirskiy | Azure için FastTrack’te Baş Müşteri Mühendisi

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

İlgili kaynaklar

Azure'daki çok kiracılı hizmetler ve belirli hizmetler hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

• Çok Kiracılı Sistemler ve Depolama
• Çok Kiracılı ve SQL Veritabanı
• Çok Kiracılı ve Azure Cosmos DB
• Çok Kiracılı ve PostgreSQL için Azure Veritabanı