Çok kiracılı çözümlerin dağıtımı ve yapılandırması için mimari yaklaşımlar

Mimarinize ve bunu uygulamak için kullandığınız bileşenlere bakılmaksızın, çözümünüzün bileşenlerini dağıtmanız ve yapılandırmanız gerekir. Çok kiracılı bir ortamda, özellikle her kiracı için ayrılmış kaynakları dağıtırken veya kaynakları sisteminizdeki kiracı sayısına göre yeniden yapılandırırken Azure kaynaklarınızı nasıl dağıttığınızı göz önünde bulundurmak önemlidir. Bu sayfada, çözüm mimarlarına çok kiracılı çözümleri dağıtma hakkında rehberlik sağlarız ve dağıtım stratejinizi planlarken dikkate alınması gereken bazı yaklaşımları gösteririz.

Önemli noktalar ve gereksinimler

Dağıtım stratejinizi planlamadan önce gereksinimlerinizi net bir şekilde bilmeniz önemlidir. Dikkat edilmesi gerekenler şunlardır:

• Beklenen ölçek: Az sayıda kiracıyı (örneğin, beş veya daha az) desteklemeyi mi bekliyorsunuz yoksa çok sayıda kiracıya mı büyüyebilirsiniz?
• Otomatik veya desteklenen ekleme: Kiracı eklemeye hazır olduğunda, otomatik bir yordamı izleyerek işlemi kendileri tamamlayabilecek mi? Yoksa yeni kiracılar bir istek başlatır ve siz isteği aldıktan sonra bunları el ile mi eklirsiniz? Hizmetinizin kötüye kullanılmasını önlemek için ekibinizden el ile onay adımları gerekiyor mu?
• Sağlama süresi: Kiracı eklemeye hazır olduğunda, ekleme işleminin ne kadar hızlı tamamlanması gerekir? Net bir yanıtınız yoksa bunun saniye, dakika, saat veya gün cinsinden ölçülüp ölçülmeyeceğini göz önünde bulundurun.
• Azure Market: Dağıtımı başlatmak için Azure Market kullanmayı planlıyor musunuz? Bunu yaparsanız, yeni kiracılar eklemek için karşılamanız gereken gereksinimler vardır.

Ayrıca ekleme ve sağlama adımlarını, otomasyonu ve kaynak yönetimi sorumluluğunu da göz önünde bulundurmalısınız.

Ekleme ve sağlama adımları

Bir kiracı eklerken yapmanız gereken her şeyi göz önünde bulundurun ve el ile gerçekleştirilse bile bu listeyi ve iş akışını belgeleyin. Ekleme iş akışı genellikle aşağıdakileri içerir:

• Ticari sözleşmelerin kabulü.
• Sisteminizi yeni kiracı için yapılandırmak için ihtiyacınız olan bilgilerin toplanması.
• Örneğin, hizmetinizin sahtekarlık veya kötüye kullanılmasını önlemek için el ile onay adımları.
• Azure'da kaynakların sağlanması.
• Etki alanı adlarını oluşturma veya yapılandırma.
• Kiracı için ilk kullanıcı hesabını oluşturma ve kimlik bilgilerini kiracıya güvenli bir şekilde iletme gibi dağıtım sonrası yapılandırma görevlerini gerçekleştirin.
• DNS kaydı değişiklikleri gibi el ile yapılandırma değişiklikleri.

Yeni bir kiracı eklemek için gereken iş akışını açıkça belgele.

Ayrıca, kiracı için sağlamanız gereken belirli Azure kaynaklarını da göz önünde bulundurun. Her kiracı için ayrılmış kaynaklar sağlamasanız bile, yeni bir kiracı eklendiğinde bazen kaynakları dağıtmanız gerekip gerekmediğini göz önünde bulundurun. Bu durum, kiracı verilerinin belirli bir bölgede depolanmasını gerektirdiğinde veya çözümünüzdeki bir damga veya bileşenin sınırlarına yaklaştığınızda ve bir sonraki kiracı grubu için başka bir örnek oluşturmanız gerektiğinde ortaya çıkabilir.

Ekleme işleminin, özellikle de aynı altyapıyı paylaşan diğer kiracılar için kesintiye neden olup olmayacağını düşünün. Örneğin, paylaşılan veritabanlarını değiştirmeniz gerekiyorsa bu işlem diğer kiracıların fark edebileceği bir performans etkisine neden olabilir mi? Bu etkilerden kaçınıp kaçınamayacağınızı veya normal çalışma saatleri dışında ekleme işlemini gerçekleştirerek bunları azaltıp azaltamayacağınızı düşünün.

Otomasyon

Bulutta barındırılan çözümler için otomatik dağıtımlar her zaman önerilir. Çok kiracılı çözümlerle çalışırken, dağıtım otomasyonu aşağıdaki nedenlerle daha da önemli hale gelir:

• Ölçek: Kiracı popülasyonunuz arttıkça el ile dağıtım işlemleri giderek daha karmaşık hale gelir ve zaman alır. Kiracı sayısı arttıkça otomatik dağıtım yaklaşımının ölçeklendirilmesi daha kolaydır.
• Tekrarlanabilir: Çok kiracılı bir ortamda, tüm kiracılar genelinde dağıtımlar için tutarlı bir işlem kullanın. El ile gerçekleştirilen işlemler hata olasılığına veya bazı kiracılar için gerçekleştirilmekte olan adımlara neden olur ve diğerleri için uygulanmaz. Bu el ile gerçekleştirilen işlemler ortamınızı tutarsız bir durumda bırakır ve bu da ekibinizin çözümü yönetmesini zorlaştırır.
• Kesintilerin etkisi: El ile dağıtımlar, otomatik dağıtımlara göre önemli ölçüde daha risklidir ve kesintilere açıktır. Çok kiracılı bir ortamda, sistem genelinde kesintinin (dağıtım hatası nedeniyle) etkisi yüksek olabilir çünkü her kiracı etkilenebilir.

Çok kiracılı bir ortama dağıtım yaparken dağıtım işlem hatlarını ve Bicep, JSON ARM şablonları, Terraform veya Azure SDK'ları gibi kod olarak altyapı (IaC) teknolojilerini kullanmanız gerekir.

Çözümünüzü Azure Market aracılığıyla sunmayı planlıyorsanız, yeni kiracılar için tam otomatik bir ekleme işlemi sağlamanız gerekir. Bu işlem SaaS gerçekleştirme API'leri belgelerinde açıklanmıştır.

En fazla kaynak kapasitesi

Kiracı kaynaklarını paylaşılan kaynaklara program aracılığıyla dağıttığınızda, her kaynağın kapasite sınırını göz önünde bulundurun. Bu sınıra yaklaştığınızda, daha fazla ölçeklendirmeyi desteklemek için kaynağın başka bir örneğini oluşturmanız gerekebilir. Dağıttığınız her kaynağın sınırlarını ve başka bir örneği dağıtmanızı tetikleyecek koşulları göz önünde bulundurun.

Örneğin, çözümünüzün bir Azure SQL mantıksal sunucu içerdiğini ve çözümünüzün her kiracı için bu sunucuda ayrılmış bir veritabanı sağladığını varsayalım. Tek bir mantıksal sunucunun sınırları vardır ve bu sınır, mantıksal sunucunun desteklediği en fazla veritabanı sayısını içerir. Bu sınırlara yaklaştıkça kiracı eklemeye devam edebilmeniz için yeni sunucular sağlamanız gerekebilir. Bu işlemi otomatikleştirmeyi veya büyümeyi el ile izlemeyi göz önünde bulundurun.

Kaynak yönetimi sorumluluğu

Çok kiracılı bazı çözümlerde, her kiracı için ayrılmış Azure kaynakları dağıtırsınız( örneğin, her kiracı için bir veritabanı). Alternatif olarak, bir kaynağın tek bir örneğinde barındırılacak belirli sayıda kiracıya karar vekleyebilirsiniz. Bu nedenle sahip olduğunuz kiracı sayısı, Azure'a dağıttığınız kaynak kümesini belirler. Diğer çözümlerde, tek bir paylaşılan kaynak kümesi dağıtırsınız ve sonra yeni kiracıları eklerken kaynakları yeniden yapılandırırsınız.

Bu modellerin her biri, kaynakları farklı şekillerde dağıtmanızı ve yönetmenizi gerektirir ve sağladığınız kaynakların yaşam döngüsünü nasıl dağıtıp yöneteceğini göz önünde bulundurmanız gerekir. İki yaygın yaklaşım şunlardır:

• Kiracıları dağıttığınız kaynakların yapılandırması olarak ele almak ve bu kaynakları dağıtmak ve yapılandırmak için dağıtım işlem hatlarınızı kullanmak.
• Kiracıları veri olarak ele almak ve bir denetim düzlemi sağlamak ve kiracılarınız için altyapıyı yapılandırmak için.

Bu yaklaşımlar hakkında daha fazla bilgi aşağıda verilmiştir.

Test Etme

Çözümünüzü her dağıtım sırasında ve sonrasında kapsamlı bir şekilde test etmek için planlayın. Çözümünüzün işlevsel ve işlevsel olmayan davranışını doğrulamak için otomatik testi kullanabilirsiniz. Kiracı yalıtım modelinizi test ettiğinizden emin olun ve Azure Chaos Studio gibi araçları kullanarak gerçek dünyadaki kesintilerin benzetimini kasıtlı olarak gerçekleştirin ve bir bileşen kullanılamadığında veya arızalandığında bile çözümünüzün çalıştığını doğrulayın.

Dikkate alınacak yaklaşımlar ve desenler

Azure Mimari Merkezi'nden ve daha geniş bir topluluktan gelen çeşitli tasarım desenleri, çok kiracılı çözümlerin dağıtımı ve yapılandırmasıyla ilgilidir.

Dağıtım Damgaları düzeni

Dağıtım DamgaLarı düzeni, bir kiracı veya kiracı grubu için ayrılmış altyapı dağıtmayı içerir. Tek bir damga birden çok kiracı içerebilir veya tek bir kiracıya ayrılmış olabilir. Tek bir damga pulu dağıtmayı seçebilir veya dağıtımı birden çok damga pulu arasında koordine edebilirsiniz. Her kiracı için ayrılmış damga damgaları dağıtırsanız, tüm damga damgalarını program aracılığıyla dağıtmayı da göz önünde bulundurabilirsiniz.

Dağıtım halkaları

Dağıtım halkaları , güncelleştirmeleri farklı altyapı gruplarına farklı zamanlarda dağıtmanızı sağlar. Bu yaklaşım genellikle Dağıtım Damga Damgaları düzeninde kullanılır ve damga grupları kiracı tercihlerine, iş yükü türlerine ve diğer önemli noktalara göre ayrı halkalara atanabilir. Daha fazla bilgi için bkz . Dağıtım halkaları.

Özellik bayrakları

Özellik bayrakları , tek bir kod tabanını korurken çözümünüzün yeni özelliklerini veya sürümlerini aşamalı olarak farklı kiracılara sunmanızı sağlar. Özellik bayraklarınızı yönetmek için Azure Uygulama Yapılandırması kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Özellik bayrakları.

Bazen belirli müşteriler için belirli özellikleri seçmeli olarak etkinleştirmeniz gerekir. Örneğin, belirli özelliklere erişime izin veren farklı fiyatlandırma katmanlarınız olabilir. Özellik bayrakları genellikle bu senaryolar için doğru seçenek değildir. Bunun yerine, her müşterinin sahip olduğu lisans yetkilendirmelerini izlemek ve uygulamak için bir süreç oluşturmayı göz önünde bulundurun.

Kaçınılması gereken kötü model

Çok kiracılı çözümleri dağıtıp yapılandırırken, ölçeklendirme yeteneğinizi engelleyen durumlardan kaçınmak önemlidir. Bunlar aşağıdakileri içerir:

• El ile dağıtım ve test. Yukarıda açıklandığı gibi, el ile dağıtım işlemleri risk oluşturur ve dağıtım becerinizi yavaşlatabilir. Otomatik dağıtımlar için işlem hatlarını kullanmayı, çözümünüzün kodundan program aracılığıyla kaynak oluşturmayı veya her ikisinin bir bileşimini kullanmayı göz önünde bulundurun.
• Kiracılar için özelleştirilmiş özelleştirmeler. Yalnızca tek bir kiracı için geçerli olan özellikleri veya yapılandırmayı dağıtmaktan kaçının. Bu yaklaşım, dağıtımlarınıza ve test süreçlerinize karmaşıklık katar. Bunun yerine, her kiracı için aynı kaynak türlerini ve kod tabanını kullanın ve geçici değişiklikler veya aşamalı olarak dağıtılan özellikler için özellik bayrakları gibi stratejiler kullanın ya da bunları gerektiren kiracılar için özellikleri seçmeli olarak etkinleştirmek için lisans yetkilendirmelerine sahip farklı fiyatlandırma katmanları kullanın. Yalıtılmış veya ayrılmış kaynakları olan kiracılar için bile tutarlı ve otomatik dağıtım işlemi kullanın.

Yapılandırma veya veri olarak kiracı listeleri

Kaynakları çok kiracılı bir çözümde dağıtırken aşağıdaki iki yaklaşımı göz önünde bulundurabilirsiniz:

• Her kaynağı dağıtmak için otomatik dağıtım işlem hattı kullanın. Yeni kiracılar eklendikçe, her kiracı için kaynakları sağlamak üzere işlem hattınızı yeniden yapılandırın.
• Kiracı sayısına bağlı olmayan paylaşılan kaynakları dağıtmak için otomatik dağıtım işlem hattı kullanın. Her kiracı için dağıtılan kaynaklar için bunları uygulamanız içinde oluşturun.

İki yaklaşımı göz önünde bulundurarak kiracı listenizi yapılandırma veya veri olarak kabul etme arasında ayrım yapmalısınız. Bu ayrım, sisteminiz için bir kontrol düzlemi oluşturmayı düşündüğünüzde de önemlidir.

Yapılandırma olarak kiracı listesi

Kiracı listenizi yapılandırma olarak değerlendirdiğinizde, tüm kaynaklarınızı merkezi bir dağıtım işlem hattından dağıtırsınız. Yeni kiracılar eklendiğinde işlem hattını veya parametrelerini yeniden yapılandırabilirsiniz. Yeniden yapılandırma genellikle aşağıdaki diyagramda gösterildiği gibi el ile yapılan değişikliklerle gerçekleşir.

Yeni bir kiracı ekleme işlemi aşağıdakine benzer olabilir:

1. Kiracı listesini güncelleştirin. Bu genellikle işlem hattının kendisini yapılandırarak veya işlem hattının yapılandırmasına dahil edilen bir parametre dosyasını değiştirerek el ile gerçekleşir.
2. İşlem hattının çalıştırılmasını tetikleme.
3. İşlem hattı, kiracıya özgü yeni kaynaklar da dahil olmak üzere tüm Azure kaynakları kümenizi yeniden dağıtır.

Bu yaklaşım, az sayıda kiracı ve tüm kaynakların paylaşıldığı mimariler için iyi çalışma eğilimindedir. Bu basit bir yaklaşımdır çünkü tüm Azure kaynaklarınız tek bir işlem kullanılarak dağıtılabilir ve yapılandırılabilir.

Ancak, 5 ile 10 veya daha fazla kiracı gibi daha fazla sayıda kiracıya yaklaştığınızda, kiracı eklediğinizde işlem hattını yeniden yapılandırmak zahmetli hale gelir. Dağıtım işlem hattını çalıştırmak için gereken süre genellikle önemli ölçüde artar. Bu yaklaşım self servis kiracı oluşturmayı da kolayca desteklemez ve işlem hattınızı çalıştırmak için tetiklemeniz gerektiğinden kiracı eklemeden önceki sağlama süresi daha uzun olabilir.

Veri olarak kiracı listesi

Kiracı listenizi veri olarak ele aldığınızda, paylaşılan bileşenlerinizi yine de işlem hattı kullanarak dağıtırsınız. Ancak, her kiracı için dağıtılması gereken kaynaklar ve yapılandırma ayarları için, kaynaklarınızı zorunlu olarak dağıtır veya yapılandırırsınız. Örneğin, denetim düzleminiz belirli bir kaynak oluşturmak veya parametreli bir şablonun dağıtımını başlatmak için Azure SDK'larını kullanabilir.

Yeni bir kiracı ekleme işlemi aşağıdakine benzer olabilir ve zaman uyumsuz olarak gerçekleşebilir:

1. Sisteminizin denetim düzlemine API isteği başlatarak kiracının eklenmesini isteyin.
2. bir iş akışı bileşeni oluşturma isteğini alır ve kalan adımları düzenler.
3. İş akışı, kiracıya özgü kaynakların Azure'a dağıtımını başlatır. Bu, Örneğin Azure SDK'larını kullanarak veya bicep veya Terraform şablonunun dağıtımını kesin olarak tetikleyerek kesinlik temelli bir programlama modeli kullanılarak gerçekleştirilebilir.
4. Dağıtım tamamlandığında, iş akışı yeni kiracının ayrıntılarını merkezi kiracı kataloğuna kaydeder. Her kiracı için depolanan veriler, iş akışının oluşturduğu kiracıya özgü tüm kaynakların kiracı kimliğini ve kaynak kimliklerini içerebilir.

Bunu yaparak, çözümünüzün tamamını yeniden dağıtmadan yeni kiracılar için kaynak sağlayabilirsiniz. Yalnızca bu kaynakların dağıtılması gerektiğinden, her kiracı için yeni kaynakların sağlanmasıyla ilgili süre muhtemelen daha kısa olacaktır.

Ancak bu yaklaşım genellikle oluşturmak için çok daha fazla zaman alır ve harcadığınız çabanın kiracı sayısı veya karşılamanız gereken sağlama zaman çerçeveleri tarafından gerekçelendirilmesi gerekir.

Bu yaklaşım hakkında daha fazla bilgi için bkz. Çok kiracılı kontrol düzlemleri için dikkat edilmesi gerekenler.

Örnek

Contoso müşterileri için çok kiracılı bir çözüm çalıştırır. Şu anda altı kiracısı var ve önümüzdeki 18 ay içinde 300 kiracıya büyümeyi bekliyorlar. Contoso , her kiracı yaklaşımı için ayrılmış veritabanlarına sahip Çok Kiracılı uygulamayı izler. Tüm kiracıları arasında paylaşılan tek bir App Service kaynağı ve Azure SQL mantıksal sunucusu dağıttılar ve aşağıdaki diyagramda gösterildiği gibi her kiracı için ayrılmış bir Azure SQL veritabanı dağıttılar.

Contoso, Azure kaynaklarını dağıtmak için Bicep kullanır.

Seçenek 1 - Her şey için dağıtım işlem hatlarını kullanma

Contoso bir dağıtım işlem hattı kullanarak tüm kaynaklarını dağıtmayı düşünebilir. İşlem hatları, her kiracı için Azure SQL veritabanları dahil olmak üzere tüm Azure kaynaklarını içeren bir Bicep dosyası dağıtır. Parametre dosyası kiracı listesini tanımlar ve Bicep dosyası, aşağıdaki diyagramda gösterildiği gibi listelenen kiracıların her biri için veritabanı dağıtmak üzere bir kaynak döngüsü kullanır.

Contoso bu modeli izlerse, yeni bir kiracı ekleme işleminin bir parçası olarak parametre dosyasını güncelleştirmeleri gerekir. Ardından işlem hattını yeniden çalıştırmaları gerekir. Ayrıca, herhangi bir sınıra yaklaşıp yaklaşmadıklarını el ile izlemeleri gerekir, örneğin beklenmedik şekilde yüksek bir hızda büyürlerse ve tek bir Azure SQL mantıksal sunucuda desteklenen en fazla veritabanı sayısına yaklaşırlar.

Seçenek 2 - Dağıtım işlem hatlarının ve kesinlik temelli kaynak oluşturmanın bir bileşimini kullanma

Alternatif olarak Contoso, Azure dağıtımlarının sorumluluğunu ayırmayı da göz önünde bulundurabilir.

Contoso, dağıtılması gereken paylaşılan kaynakları tanımlayan bir Bicep dosyası kullanır. Paylaşılan kaynaklar, aşağıdaki diyagramda gösterildiği gibi tüm kiracılarını destekler ve bir kiracı eşleme veritabanı içerir.

Contoso ekibi daha sonra kiracı ekleme API'sini içeren bir denetim düzlemi oluşturur. Satış ekibi yeni bir müşteriye satışı tamamladığında, Microsoft Dynamics ekleme işlemini başlatmak için API'yi tetikler. Contoso ayrıca müşterilerin kullanması için bir self servis web arabirimi sağlar ve bu da API'yi tetikler.

API, yeni kiracılarını ekleyen bir iş akışını zaman uyumsuz olarak başlatır. İş akışı yeni bir Azure SQL veritabanının dağıtımını başlatır ve bu dağıtım aşağıdaki yaklaşımlardan biri tarafından yapılabilir:

• Azure SQL veritabanını tanımlayan ikinci bir Bicep dosyasının dağıtımını başlatmak için Azure SDK'sını kullanın.
• Yönetim kitaplığını kullanarak kesin olarak bir Azure SQL veritabanı oluşturmak için Azure SDK'sını kullanın.

Veritabanı dağıtıldıktan sonra iş akışı, aşağıdaki diyagramda gösterildiği gibi kiracıyı kiracı listesi veritabanına ekler.

Devam eden veritabanı şeması güncelleştirmeleri, uygulama katmanları tarafından başlatılır.

Katkıda Bulunanlar

Bu makale Microsoft tarafından korunur. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

• John Downs | Baş Müşteri Mühendisi, Azure için FastTrack

Diğer katkıda bulunanlar:

• Bohdan Çerçilik | Kıdemli 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.

Sonraki adımlar

• Çok kiracılı bir çözümü güncelleştirmeyle ilgili dikkat edilmesi gerekenleri gözden geçirin.
• Depolama ve veriler için mimari yaklaşımları göz önünde bulundurun.
• Azure Resource Manager'ı çok kiracılı bir çözümde kullanmayı göz önünde bulundurun.