Azure'da SaaS iş yükleri için veriler
Verileri çözümünüzün en değerli varlığı olarak değerlendirin. Bağımsız bir yazılım satıcısı (ISV) olarak müşterilerinizin verilerini yönetmek sizin sorumluluğunuzdadır. Veri tasarım stratejiniz ve veri deposu seçiminiz müşterilerinizi önemli ölçüde etkileyebilir.
Bu makale, iş performansı gereksinimlerini karşılarken müşterileriniz için veri bütünlüğünü ve gizliliğini sağlama konusunda rehberlik sağlar. Bu hedeflere etkili bir şekilde ulaşmanıza yardımcı olacak önemli noktaları vurgular.
Veri deposu seçme
Hizmet olarak yazılım (SaaS) çözümündeki veri deposu mimarisini, performansını, güvenilirliğini ve işlem karmaşıklığını etkiler. Azure yönetilen hizmetlerinin özelliklerini Benzer Microsoft dışı tekliflerle karşılaştırın. Bazı durumlarda, sanal makinelerde açık kaynak ürünleri çalıştırmayı da düşünebilirsiniz.
Tasarımla ilgili dikkat edilecek noktalar
İşlemsel ve analitik işlemlerinizi birbirinden ayırt edin. İşlemsel veri depoları uygulamalarınızı destekleyecek şekilde tasarlanmıştır ve analiz veri depoları raporlama ve makine öğrenmesi gibi görevler için kullanılır. Bu depolar özel ürünlerle oluşturulmuş olup performans, erişim desenleri, şemalar ve kullanım örnekleri için benzersiz gereksinimlere sahiptir.
Bu kılavuzda işlemsel veri depolarına odaklanılmaktadır.
Veri gereksinimlerinizi anlama. Hacmi, değiştirebileceği sıklığı ve depolamanız gereken veri türünü tahmin edin.
Verilerin zaman içinde önemli ölçüde büyümesini bekleyebilirsiniz. SaaS çözümleri için büyüme birden çok boyutta gerçekleşir. Müşteri sayısı arttıkça veri hacminde ve türlerinde artış olacağını tahmin edin. Bu büyümeyi planladığınızı ve destekleyebilecek teknolojilere yatırım yaptığınızdan emin olun.
Verilerinizin niteliğine göre ilişkisel veya ilişkisel olmayan bir veri platformu arasında karar verin. birçok işlem iş yükü için ilişkisel veritabanı, uygulama varlıklarını ayrık tablolar olarak modellemek için iyi bir seçenektir. Bu yaklaşım sorguların ilişkisel veri modelinde çalışmasına olanak tanır. Alternatif olarak, verileriniz doğal olarak bir belge modeline uyuyorsa veya graf yapısına uyuyorsa, ilişkisel olmayan bir yaklaşım daha uygun olabilir.
Daha fazla bilgi için bkz . SQL ve NoSQL veri platformları.
Veri deposu türlerini en aza indirin. Farklı veri türlerini birden çok farklı veri deposunda depolamak, çeşitli veri platformlarında uzmanlığa sahip olgun kuruluşlar için yararlı olabilir. Ancak bu yaklaşım genellikle startup'lar ve daha küçük kuruluşlar için gereksiz karmaşıklıklara neden olur. Bir veya daha az sayıda veri deposuna odaklanmak daha etkilidir.
Birden çok veri deposu kullanmak için iş gerekçeniz yoksa, çabalarınızı bir veya az sayıda veri deposuna odaklayın.
Bildiklerinizi kullanın ve buna yatırım yapın. Ekibinizin belirli bir veri deposuyla zaten uzmanlığı varsa, yeni beceriler öğrenmeye yatırım yapmak yerine bu veri depolarını kullanmak genellikle daha iyidir. Veri depoları ve platformlar karmaşıktır ve tasarım kararlarını tersine çevirmek zor olabilir.
Ancak, potansiyel büyümeyi göz önünde bulundurun. Geçerli veri deponuz artık gereksinimlerinizi karşılamıyorsa çözümünüzün performansını, dayanıklılığını, güvenliğini ve operasyonel verimliliğini artırabilecek bir veri deposu seçin. Ayrıca ekibinizin uzmanlığını derinleştirmesine de yardımcı olmalıdır.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Günlük işlemler için işlemsel veri depolarını analiz ve raporlama veri depolarından ayırın. | Veri depolarınızın amacını karıştırmak gereksiz karmaşıklığa yol açabilir. Veri segmentasyonu, operasyonel verimliliği artırır ve her veri deposunun kullanımını en üst düzeye çıkarır. |
| Gereksinimlerinize göre ilişkisel veya ilişkisel olmayan veri yapısı arasında seçim yapın. Bir veya az sayıda veri deposuyla başlayın. Yönetilen veri depolarının önceliklerini belirleme. Yaygın seçenekler arasında Azure Cosmos DB, Azure SQL, MySQL, MongoDB ve PostgreSQL bulunur. |
Bu yaklaşım karmaşıklığı en aza indirmeye yardımcı olur ve verimliliği en üst düzeye çıkarmak için doğru ürünü kullanmanızı sağlar. Yönetilen veri depoları, kaynakları ve maliyetleri esnek bir şekilde yönetme ve gereksinimlerinize göre ölçeklendirme esnekliği sağlar. Yönetilen veri depolarını kullanmak, kendi veri deponuzu kendi altyapınıza dağıtmaktan daha az yönetim yükü oluşturur. |
| Seçtiğiniz teknolojiyi öğrenmeye yatırım yapın. Yüksek ölçeklendirme gereksinimlerini ve SaaS çözümlerinin diğer karmaşıklıklarını yönetmek için ekibinizi donatın. | Ölçeklendikçe veri platformunuzu etkili bir şekilde kullanabilmek için kullandığınız araçlar ve bunların daha geniş ekosistemi hakkında bilgi edinin. |
| Veri tasarımınızda esnekliği benimseyin. | SaaS çözümünüz büyüdükçe veya gereksinimleriniz değiştikçe veri depoları ekleyerek veya değiştirerek uyum sağlayabilirsiniz. Bu esneklik, tek bir veri deposuyla başlamanızı ve zaman içinde ihtiyaçlarınızı karşılayacak şekilde gelişmenizi sağlar. |
Kiracı modeli ve veritabanı stratejisi
Veri tasarımının önemli bir yönü, kaynakları müşterileriniz adına barındırma veya kaynakları kendi ortamlarında barındırma kararıdır. Çoğu SaaS sağlayıcısı, tüm müşteriler için kaynak barındırarak veritabanı yönetiminde esneklik sağlar. Kaynakları müşterinin ortamında barındırıyorsanız, bu kaynaklara nasıl erişip yönetileceğini göz önünde bulundurun.
Tasarımla ilgili dikkat edilecek noktalar
Veritabanı segmentasyonunuzu planlayın. İşletmeler arası (B2B) SaaS çözümlerinde, her müşteri için ayrılmış veritabanları oluşturmanızı öneririz. Bu yaklaşım, müşteriler arasında sıkı yalıtım sağlayarak veri güvenliğini artırır ve bu da veri karıştırma riskini azaltır ve müşteri tarafından yönetilen şifreleme anahtarlarını destekler. Ayrıca bazı müşteriler için mevzuat uyumluluğu gereksinimlerini karşılamanıza da yardımcı olur.
Müşteri verilerini tek tek veritabanlarına ayırmak, gürültülü komşu sorunlarını en aza indirerek performansı artırabilir. Bazı yönetilen veri depoları, bu sorunları azaltmak, maliyet verimlilikleri sağlamak ve büyük ölçekte birden çok veritabanını yönetmek için araçlar eklemek için kaynak ayırma denetimlerini içerir.
Bazı durumlarda, birden çok müşterinin verilerini tek bir veri deposunda depolamak uygundur. Örneğin, işletmeden tüketiciye (B2C) çözümlerinde, müşteri kimliğine göre mantıksal bölümleme ile verileri tek bir depoya kaydedebilirsiniz. Bileşenleri paylaşan B2B çözümlerinde, olay deposu gibi belirli parçalar için tek bir veri deposu kullanabilir ve her olaya müşteri kimlikleri eklediğinizden emin olabilirsiniz.
Veri depolarını uygulama bileşenleriyle birlikte dağıtma. Kaynakları müşteri adına barındırıyorsanız çıkış bant genişliği ücretlerinden ve gecikme süresinden kaçınmak için aynı Azure bölgesine dağıtın. Uygulamaları ve veri depolarını bir müşterinin ortamında barındırdığınızda, ortamlar arası karmaşıklıkları önlemek için bunları aynı ortamda birlikte dağıtın.
Veri deposu yönetimini pratik olduğu kadar standartlaştır. Tekdüzenlik, müşteriler arasında veri yönetiminin anahtarıdır. İşletmeniz büyüdükçe müşteriler arasındaki farklar riski ve karmaşıklığı artırır. Bu farklılıklar, üretim kesintilerinin daha olası olmasını ve sorun gidermenin daha zor olmasını da sağlayabilir.
Tek tek müşterileri desteklemek için yönetiminizdeki tek seferlik değişikliklerden kaçının. Örneğin, müşteri tarafından yönetilen meta verileri desteklemek için veritabanınıza ek sütunlar eklemek gibi şema değişikliklerinden kaçının. Bunun yerine, müşterilerin kendi meta verilerini eklemesi için işlevsellik oluşturun. Benzer şekilde, farklı müşteriler için farklı düzeylerde veritabanı performansı sağlamanız gerekiyorsa, farklı müşteri katmanlarına farklı yapılandırmalar uygulamak için kullanabileceğiniz tek bir işlem oluşturun.
Kiracı modelinizin veri stratejinizi nasıl etkilediği hakkında daha fazla bilgi için bkz.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Veritabanlarının birden çok müşteri arasında paylaşılıp paylaşılmayacağını veya paylaşılan bir veri platformu sağlanıp sağlanmayacağını değerlendirin. Uygun yerlerde her müşterinin verileri için tek bir veritabanı dağıtın. B2C çözümleri gibi katı yalıtım gerekli değilse bu stratejiyi gevşetin. |
Bu yaklaşım gürültülü komşu sorunlarını en aza indirir ve bazı müşteriler için uyumluluk gereksinimlerini destekleyebilir. |
| Uygulamaları ve veritabanlarını aynı bölgeye dağıtın. | Bu yaklaşım, bölgeler arası veritabanı erişimi tarafından tahakkuk eden bant genişliği maliyetini ve gecikme süresini iyileştirir. |
| Müşteri tanımlı verileri veya meta verileri depolamak için standartlaştırılmış bir yaklaşım tasarlama. Şemayı tek tek müşteriler için değiştirmekten veya müşteri ortamlarının farklı olmasını sağlamaktan kaçının. | Bu yaklaşım, her müşteri için veritabanları arasındaki tutarsızlıkları yönetmenin operasyonel yükünü önlemenize yardımcı olur. |
| Müşteri tarafından dağıtılan ortamda rutin bakım işlemlerini planlayın. Güncelleştirmeler, şema değişiklikleri, bakım ve diğer işlemler için veritabanına nasıl erişilmeyi planlayın. |
Bu proaktif yaklaşım, bakım eksikliğinden kaynaklanan sorunları en aza indirir ve kapalı kalma süresi ve performans sorunları riskini azaltır. |
Kapasiteyi planlama
Kapasite planlaması, cpu, bellek, depolama ve saniye başına giriş ve çıkış işlemleri (IOPS) gibi disk işlemlerine odaklanarak kaynak kullanımının yönetimini ifade eder. Bazı veri depoları, bu kaynakları Azure SQL'deki veritabanı aktarım hızı birimi (DTU) veya Azure Cosmos DB'deki istek birimi (RU) gibi basit, yapay bir kaynak tüketimi ölçümünde birleştirir. Yönetilen veri depoları kaynak yönetiminde esneklik sağlayarak zaman içinde değişikliklere olanak tanır. İlk planı oluşturmak ve gereksinimleriniz geliştikçe yinelemek çok önemlidir.
Tasarımla ilgili dikkat edilecek noktalar
Kaynak ayırma gereksinimlerinizi anlayın. SaaS çözümlerindeki farklı müşterilerin farklı kaynak gereksinimleri olabilir. Daha küçük müşteriler çok az kaynak gerektirebilir ve daha büyük müşterilerin daha fazlasına ihtiyacı olabilir. Daha büyük müşteriler genellikle daha fazla ödeme ve bu da daha yüksek kaynak ayırmayı haklı gösterir. Her müşteri için ayrı veritabanları kullanarak, kaynak ayırmayı boyutlarına ve ihtiyaçlarına göre ayarlayabilirsiniz.
Veri platformlarının sunduğu farklı kapasite modellerini anlayın. Bulut tabanlı veri platformları genellikle birden çok kaynak modeli sağlar. Örneğin, Azure Cosmos DB gibi bazı Azure hizmetleri sağlanan, aktarım hızı tabanlı modeller ve sunucusuz modeller sağlar. Azure SQL Veritabanı elastik havuzlar da sağlar.
Sağlanan aktarım hızı, tek bir veritabanından veya bir veritabanı grubundan önceden belirlenmiş kaynak ayırmayı gerektirir. Elastik havuzlar birden çok veritabanı arasında kaynak paylaşımına izin verir. Elastik havuzlar SaaS çözümlerinde yaygın olarak kullanılır.
Sağlanan aktarım hızı, kaynakları önceden ayırmanızı gerektirse de Azure Cosmos DB gibi hizmetler otomatik ölçeklendirme aktarım hızı sağlar. Belirtilen tetikleyicilere göre kaynakları dinamik olarak eklemek veya kaldırmak için kurallar ayarlayabilirsiniz.
Sunucusuz kaynak modelleri isteğe bağlı olarak otomatik olarak ölçeklendirilir. Kapasite gereksinimlerinizi önceden tahmin edemiyorsanız bu özellik onları iyi bir başlangıç noktası yapar. Ancak, bunlar daha az özelliği destekleyip siz büyüdükçe maliyet verimsiz hale gelebilir. Sunucusuz modeller Azure SQL Veritabanı ve Azure Cosmos DB'de kullanılabilir.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Her müşteri için veritabanı gereksinimlerinizi modelleyin. Çok sayıda küçük veritabanınız mı yoksa daha az büyük veritabanınız mı yoksa ikisinin karışımı mı olması gerektiğini belirleyin. Müşterileri küçük, orta ve büyük demetler halinde kategorilere ayırmak için tişört boyutlandırma alıştırması kullanın. |
Bu yaklaşım, müşteri başına gereken kaynakların kabaca tahminini sağlar ve müşterileri faturalama modelinizle eşlemenize yardımcı olur. |
| Kaynak havuzlarını kullanan müşteri veritabanlarının boyutuna göre segmentlere ayırma. Sağlanan kapasiteyi kendi yararınıza kullanın. Örneğin, daha küçük müşteriler için paylaşılan bir SQL elastik havuzu, orta ölçekli müşteriler için ayrı bir havuz ve büyük müşteriler için ayrılmış kaynaklar oluşturabilirsiniz. |
Kaynak havuzlarını müşterilerinizin veritabanı boyutuna göre segmentlere ayırırsanız kaynak ayırmayı ve maliyet verimliliğini iyileştirebilirsiniz. |
| Yönetilen hizmetlerin sağladığı yerleşik ölçeklendirme özelliklerinden yararlanın. | Ölçeklendirme sorumluluklarını platforma devredebilirsiniz. Elastik havuzlar ve otomatik ölçeklendirme gibi özellikler kaynak kullanımını iyileştirmeye yardımcı olabilir. |
| Gereksinimlerinizi karşılamaya devam ettiğinden emin olmak için sunucusuz veri depolarını düzenli olarak gözden geçirin. | Veri deposunun gelişen gereksinimlerinizle etkin kalmasını sağlayabilirsiniz. Gereksinimleriniz değiştikçe performansı ve maliyet verimliliğini iyileştirin. |
Yüksek kullanılabilirlik ve olağanüstü durum kurtarma
SaaS çözümlerinin müşterileri genellikle yüksek kullanılabilirlik (HA) ve olağanüstü durum kurtarma (DR) beklentilerine sahiptir. Müşterileriniz düzenlemeye tabi sektörlerde faaliyet gösteriyorsa veya günlük operasyonlar için çözümünüzden yararlanıyorsa gereksinimleri daha da katı olabilir.
HA ve DR her boyuta uygun çözümler değildir ve çeşitli faktörlere bağlıdır. Farklı riskleri azaltma hakkında bilinçli kararlar almak için hem sizin hem de müşterilerinizin gereksinimlerine uygun olan mevcut seçenekleri net bir şekilde anlayın.
Denge: Güvenilirlik, maliyet ve performans: Veri hizmetleri için dayanıklılık, riskleri azaltmak için genellikle verilerinizin çoğaltmalarını veya kopyalarını daha geniş bir coğrafi alana dağıtmayı gerektirir. Ancak, bazı dezavantajlar vardır. Verilerin ne kadar uzun sürmesi gerekirse, yerelleştirilmiş hatalara karşı o kadar fazla korumanız olur. Ancak, verileri daha uzun mesafeler arasında kopyalamak gecikme süresini artırır ve genellikle maliyeti daha yüksektir. Birçok yönetilen veri deposu otomatik veri çoğaltması sağlar, ancak performansı korumak için farklı mesafelerde gerçekleştirebileceğiniz çoğaltma türlerine sınırlar uygulayabilir.
Tasarımla ilgili dikkat edilecek noktalar
Dayanıklılığı ölçme. Çalışma süresi, kurtarma süresi ve kurtarma noktası gibi ölçümleri içeren hizmet düzeyi hedeflerini (SLO) kullanarak dayanıklılık gereksinimlerini ölçün. Bu ölçümler hem iş gereksinimlerinize hem de farklı gereksinimleri olabilecek müşterilerinize göre oluşturulur. Müşterileriniz adına büyük miktarda veri depolarsanız, HA ve DR çözümünüzün katı gereksinimleri karşılamak için daha karmaşık olması gerekebilir.
Dayanıklılık ölçümleri hakkında daha fazla bilgi için bkz . GÜVENILIRLIK hedeflerini tanımlamak için RE:04 Önerileri.
Platform özelliklerini kullanın. Azure, kullanılabilirlik alanlarını kullanarak bir veri merkezi içinde, bir bölgede ve birden çok bölge kullanarak daha geniş bir coğrafi alanda dayanıklılık özellikleri sağlar. Çözümünüz için doğru dayanıklılık düzeyini elde etmek için kullanılabilirlik alanları, bölgeler arası yedekleme ve çok bölgeli dağıtımlar gibi stratejileri birleştirin. Yüksek dayanıklılık gereksinimleri için bölgeler arasında zaman uyumsuz veri çoğaltması içeren çok bölgeli, etkin-pasif bir mimariyi göz önünde bulundurun. Bu yaklaşım, olağanüstü bir kesinti sırasında veri kaybına neden olabilir.
Denge: Çoğaltma ile çok bölgeli, etkin-etkin tasarımlar en dayanıklı olanlardır, ancak derleme ve test etme açısından karmaşıktır. Etkin-etkin çözümlerin çoğunda, veri eşitlemesindeki gecikmeleri hesaplayan bir çakışma çözümü yaklaşımı tasarlamanız gerekir. Çoğu çözümün bu düzeyde dayanıklılığa ihtiyacı yoktur.Kullanılabilirlik alanlarını ve bölgelerini kullanmak için RE:05 Önerileri'ne bakın.
Bileşenlerin patlama yarıçapını yalıtmak için dağıtım damgalarını kullanın. Dağıtım, yönetim, performans ve dayanıklılık açısından avantajlar sağladığından, dağıtım damgaları deseni SaaS çözümlerinde yaygın olarak kullanılır. Örneğin, Birleşik Devletler bir damga pulu ve Avrupa'da başka bir damga pulu dağıtmak, bir bölgedeki müşterilerin diğer bölgedeki kesintilerden yalıtılmasını ve bağımsız olarak çalışabilmesini sağlar.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Hem sizin hem de müşterilerinizin genel veri gereksinimlerini düşünürken dayanıklılık gereksinimlerine odaklanın. | Tasarım kararlarınızı bu gereksinimlere temel alarak, uygun dengeleri sağladığınızdan emin olabilir ve ihtiyaçlarınıza göre düşük veya fazla mühendislikten kaçınabilirsiniz. |
| Faturalama modelinizdeki çeşitli dayanıklılık düzeylerini yansıtır. Müşterilerinizle beklentilerinizi belirleyin. Yıkıcı kesintiler sırasında sıfır veri kaybı veya %100 çalışma süresi gerçekçi olmayabilir. |
Faturalama modelleri, müşterilerinizin ne kadar garantili dayanıklılık için kaydoldıklarını anlamasına yardımcı olabilir. Örneğin, daha düşük bir katmanda müşteriler minimum garantiler alır. Daha yüksek bir katmanda müşteriler daha fazla dayanıklılık elde edebilir çünkü kaynaklarını birden çok bölgede çoğaltmayı göze alabilirsiniz. |
| Üretim çözümleri için Azure kullanılabilirlik alanlarını kullanın. Mümkün olduğunda, alanlar arası yedekli veri depoları kullanın. | Kullanılabilirlik alanları, çözümünüzün maliyetini, gecikme süresini veya karmaşıklığını önemli ölçüde artırmadan veri merkezi kesintilerine karşı dayanıklılık sağlar. |
| Kullanılabilir yerlerde bölgeler arası çoğaltmayı kullanarak veri depolarınızın yedeklerini genel olarak yedekli bir biçimde tutun. | Verilerin bölgeler arası yedekleri ek bir dayanıklılık düzeyi ekler. |
| Coğrafi olarak dağıtılmış konumlarda çözümünüzün ayrı örneklerini oluşturmak için dağıtım damgalarını kullanın. | Coğrafi olarak dağıtılmış konumlarda çözümünüzün ayrı örneklerini oluşturmak için dağıtım damgalarını kullanarak dayanıklılığı artırabilir ve daha kolay operasyon yönetimi gibi daha fazla avantaj sağlayabilirsiniz. |
| Birden çok bölge dağıtımına ihtiyacınız olup olmadığını ve gereksinimleri karşılamak için etkin-etkin bir tasarıma ihtiyacınız olup olmadığını değerlendirin. Dahil olan dengeleri göz önünde bulundurun. Durum bilgisi olmayan bileşenlerin çoğaltılması, veri deposu gibi durum bilgisi olan bileşenlere göre daha kolaydır. |
Çözümünüzü veya damgalarınızı bölgelere yaymak, verileri bölgeler arasında çoğaltarak daha yüksek düzeyde dayanıklılık sağlar. |
Güvenlik ve uyumluluk
Müşterilerinizin verilerinin gizliliğini ve bütünlüğünü sağlamak sizin sorumluluğunuzdadır. Güvenlik temeli oluştururken güvenlik gereksinimlerinizi ve vaatlerinizi göz önünde bulundurun. Veri saklama dahil olmak üzere müşterilerinizin uyumluluk gereksinimlerini karşılamayı planlayın.
Tasarımla ilgili dikkat edilecek noktalar
Ağ: Veri deponuza kimlerin erişeceğini göz önünde bulundurun. Genellikle yalnızca uygulamanızın doğrudan iletişime ihtiyacı vardır, bu nedenle yalnızca özel ağ için yapılandırın.
Kimlik: Veri depolarınıza nasıl erişileceğini göz önünde bulundurun. Birçok SaaS çözümü, tüm veri depoları için tek bir uygulama kimliği kullanır ve uygulama katmanı yalıtım ve yetkilendirmeyi zorunlu kılmış olur. Satır düzeyi güvenlik veya veritabanı düzeyinde yetkilendirme için, kullanıcının kimliğini çok kiracılı bir ortamda karmaşık olan veri deposuna yaymanız gerekebilir.
Veri saklama: Veri saklama ilkelerinizi önceden planlayın. Daha fazla verinin korunması depolama maliyetlerini ve yönetim karmaşıklığını artırır. Örneğin, işlem veritabanındaki büyük miktarda veri, işlemleri sorgulamayı ve kesmeyi karmaşıklaştırabilir.
Uyumluluk veya gelecekteki analizler gibi uzun süreli veri saklama için, verileri uzun süreli saklama için uygun bir depoya yeniden konumlandırmayı göz önünde bulundurun.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Veri depolarınızı özel uç noktaları kullanacak şekilde yapılandırın ve genel uç noktaları devre dışı bırakın. | Bu yaklaşım, iç ağınıza erişimi kısıtlayarak güvenliği artırır. Erişimi kısıtlayarak yetkisiz erişim riskini ve olası veri ihlallerini azaltabilirsiniz. |
| Kimlik doğrulaması için yönetilen kimlikleri ve Microsoft Entra Id'yi kullanın. Veritabanı anahtarlarının veya kimlik bilgilerinin kullanımından kaçının. | Yönetilen kimlikler, veritabanı anahtarları veya kimlik bilgileri gereksinimini ortadan kaldırır ve bu da kimlik bilgisi hırsızlığı riskini azaltır ve erişim yönetimini basitleştirir. |
Paylaşılan veri depolarıyla çalışırken, uygulamanın kiracı tanımlayıcısını WHERE yan tümcelere ekleyerek tek bir kiracıya yönelik tüm isteklerin kapsamını oluşturduğundan emin olun. |
Bu işlem, kiracılar arası veri sızıntısı veya kimliğe bürünme riskini azaltmaya yardımcı olur. |
| Uyumluluk ve iş gereksinimlerine göre veri saklama stratejinizi planlayın. Gereksiz geçmiş verileri saklamaktan kaçının. Uzun süreli saklama için verileri birincil depolardan arşiv depolama alanına taşıyın. | Gereksiz saklamayı önleyerek daha küçük bir yüzey alanı tutarsınız. |
| Veri yaşam döngüsü gereksinimlerinizi desteklemek için veri deposu özelliklerini kullanın. Azure Cosmos DB'de belgeler üzerinde yaşam süresini ayarlayın. Azure SQL'de, arşivleme işleminin veritabanı üzerindeki etkisini en aza indirmek için tablo bölümlemeyi kullanarak kayan pencere stratejisi uygulayın. |
Bu yaklaşımlar verimli veri yaşam döngüsü yönetimi sağlar, eski verileri arşivleyerek veya silerek depolamayı iyileştirir ve mümkün olduğunda el ile müdahaleyi azaltır. |
Operations
SaaS çözümleri genellikle çok sayıda veritabanı veya başka mağaza içerir. Filonuzda rutin bakım planlamanız ve bu görevleri verimli bir şekilde yönetmek için otomasyon seçeneklerini keşfetmeniz önemlidir.
Tasarımla ilgili dikkat edilecek noktalar
Ekibinizin özelliklerini anlayın. Tek tek müşterilerin veritabanlarında ayrıntılı analizler yapabilen büyük veritabanı yöneticileri takımınız yoksa, büyük ölçekte işlemler gerçekleştirmeyi ve mümkün olduğunda platform araçlarını kullanmayı planlayın.
Düzenli bakım yordamlarınızı planlayın. Gereken düzenli bakım işlemlerini ve sıklıklarını listeleyin. Belirli işlemler, kullandığınız veri deposunun türüne göre değişir. Örneğin:
- Önemli tablolar gibi belirli varlıklarda bulunan toplam veri ve veri miktarını izleyin.
- Dizinleri yeniden oluşturun.
- Değişen sorgu desenlerini temel alarak dizinler oluşturun veya kaldırın.
- Bölümleri yeniden dengele.
Düzenli bakım yapmanıza ve yeni sorunları proaktif olarak aramanıza yardımcı olabilecek platform özelliklerini keşfedin. Örneğin, Azure SQL Veritabanı'da SQL Veritabanı Danışmanı sorunları izler.
Otomasyon tasarımı. SaaS çözümünün etkili bir şekilde ölçeklendirilmesi için otomatik operasyonlar gereklidir. Düzenli ve zaman zaman görevleri belirleyin ve bunlar için playbook'lar veya otomasyon betikleri oluşturun. Hemen otomatikleştirememenize neden olan görevler için tutarlılık ve netlik sağlamak için işlemleri ayrıntılı bir şekilde belgeleyebilirsiniz.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Mümkün olduğunda müşterilerin veri depoları arasında tutarlılık sağlamak için çabalayın. Bir müşteri özel konaklama birimlerine ihtiyaç duyuyorsa, bu müşterinin yapılandırmasını özelleştirmek yerine bunları genel bir süreçle tümleştirin. Örneğin, her veritabanı için aynı şemayı kullanın ve kaynaklarınızı dağıtmak ve yönetmek için aynı işlemleri kullanın. |
Tutarlılık, büyük ölçekte değişiklik yapmayı kolaylaştırır ve dağıtımlar veya bakım yordamları sırasında yanlışlıkla oluşan sorun riskini en aza indirir. |
| Sınırlı kaynakları dikkatli bir şekilde dağıtın ve işlemleri kolaylaştırmak için fırsatlar arayın. | Küçük verimliliklerden kaçınabilir, daha iyi kaynak kullanımına ve genel performansa sahip olabilirsiniz. |
| Yinelenen görevler için otomasyon oluşturma. Özel bir çözüm oluşturmak yerine otomatik araçlar satın almayı seçin. Platformun ve Microsoft dışı satıcıların sağladığı seçenekleri keşfedin. |
Kalite otomasyonuna yatırım yaparak bu varlıkları tekrar tekrar kullanabilir ve genellikle hatalara eğilimli el ile gerçekleştirilen görevleri azaltabilirsiniz. Kullandığınız veri deposunda uzman değilseniz veya gerekli bakım görevlerinde emin değilseniz otomatik araçlar değerlidir. |
| Ekibinizin veritabanı yönetim kapasitesini dikkatli bir şekilde dağıtın. Büyük müşterilerle ilgilenme veya birçok müşteri arasında ölçeklendirilebilen otomasyon oluşturma gibi en etkili etkinlikler için insan veritabanı yöneticilerini ayırın. | Değerli işlevlere öncelik vererek verimliliği en üst düzeye çıkarabilirsiniz. |
Verilere müşteri erişimi
Müşterilerinizin bazıları özel raporlama veya analiz için verilerine doğrudan erişim isteyebilir. Müşterilerin çözümünüzdeki verilere nasıl erişebileceğini ve bu istekleri verme veya ihtiyaçlarını karşılamak için alternatif yöntemler sağlama konusunda dikkatli bir şekilde düşünün.
Tasarımla ilgili dikkat edilecek noktalar
Doğrudan erişim nedenlerini iki yana yaslama. Müşterilerin iş sorunları hakkında bilgi alarak ham verilere neden erişmesi gerektiğini anlayın. Platformunuza risk eklemeden ihtiyaçlarını karşılayan bir çözüm bulmak için işbirliği yapın.
Doğrudan erişim vermek yerine gereksinimleri karşılamanın alternatif yollarını bulun. Raporlama amacıyla erişim gerekiyorsa, uygulama katmanı yaklaşımları tercih edilir. Örneğin, Microsoft Power BI kullanarak bunlar için raporlar oluşturabilir veya verilerinizin bir alt kümesini onlara sağladığınız bir dosyaya aktarabilirsiniz. Ayrıca, verilerinize erişmek için kullanabilecekleri API'ler de oluşturabilirsiniz.
Güvenlik ve yalıtım etkilerini değerlendirin. Veri deposuna doğrudan erişim sağlamak önemli güvenlik riskleri oluşturur. Müşteriler de dahil olmak üzere iç kaynakları dış taraflara ifşa etmekten kaçının. Bir çözümü paylaşan çok sayıda müşterinin olduğu bir SaaS ortamında, diğer müşterilerin verilerine erişmek için ortamdan yararlanılabildiği için riskler daha da yüksektir.
Müşterilerin verilerine, üretim sisteminizi etkilemeyen ve müşterilerin sorgularını bozmadan iç veritabanı tasarım değişiklikleri yapmanıza olanak tanıyan güvenli, yalıtılmış bir şekilde erişmesini sağlamayı göz önünde bulundurun.
Performans üzerindeki etkisini göz önünde bulundurun. İşlemsel veri deponuza doğrudan erişime izin vermek, ana uygulamanız için performans sorunlarına yol açabilir. Örneğin, bir müşteri uygulamanın işlevselliğini bozan yoğun kaynak kullanan bir sorgu çalıştırabilir.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Veri depolarınıza doğrudan erişim vermekten kaçının. Doğrudan erişim vermeniz gerekiyorsa, veri platformu destekliyorsa salt okunur bir çoğaltmaya erişim sağlayın. |
Uygulama katmanı yaklaşımları, müşterilerin verilerinizi nasıl kullandığını denetlemenizi sağlar. Uygulama katmanı yapıları oluşturmak mümkün değilse, salt okunur çoğaltmalar aracılığıyla erişim, müşterinin işlemlerinizdeki sorgularının zorluğunu azaltır. |
| İç uygulama ayrıntılarını ortaya çıkarmaktan kaçının. | Veri yapılarınıza erişimi denetleyerek müşterilerin veritabanı şemanızın işlevselliği hakkında varsayımlarda bulunmalarını engellersiniz. Bu esneklik, müşteri tarafından oluşturulan araçların veya yanlış varsayımların kısıtlamaları olmadan zaman içinde veritabanı yapınızı geliştirmenize ve iyileştirmenize olanak tanır. |
Ek kaynaklar
Çok kiracılılık, SaaS iş yüklerini tasarlamaya yönelik temel bir iş metodolojisidir. Bu makaleler, veri tasarımıyla ilgili dikkat edilmesi gerekenler hakkında daha fazla bilgi sağlar:
- Çok kiracılı bir çözüm için mimari yaklaşımlar
- Çok kiracılı çözümlerde depolama ve veri için mimari yaklaşımlar
- Kiracı tümleştirmesi ve veri erişimi için mimari yaklaşımlar
- Kiracı modelleri
Sonraki adım
Verimli müşteri yaşam döngüsü yönetimi ve güvenli dağıtım uygulamaları da dahil olmak üzere SaaS iş yükleri için DevOps ile ilgili dikkat edilmesi gerekenler hakkında bilgi edinin.