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

Mimarinizden ve bunu uygulamak için kullandığınız bileşenlerden bağımsız olarak çö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 bulundurmanız ö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 gereksinimleriniz hakkında net bir fikir sahibi olmanız önemlidir. Dikkat edilmesi gereken belirli noktalar ş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? Ya da 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, bir kiracı için sağlamanız gereken belirli Azure kaynaklarını 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ı hafifletip 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.
• Yinelenebilir: Çok kiracılı bir ortamda, tüm kiracılardaki dağıtımlar için tutarlı bir işlem kullanın. El ile gerçekleştirilen işlemler hata olasılığını veya bazı kiracılar için gerçekleştirilmekte olan adımların bazılarını değil, diğer kiracıları gösterir. 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 yapılan dağıtımlar, otomatik dağıtımlara göre önemli ölçüde daha risklidir ve kesintilere açıktır. Çok kiracılı bir ortamda, her kiracı etkilenebileceği için sistem genelinde kesintinin (dağıtım hatası nedeniyle) etkisi yüksek olabilir.

Ç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 sunucusu içerdiğini ve çözümünüzün bu sunucuda her kiracı için ayrılmış bir veritabanı sağladığını varsayalım. Tek bir mantıksal sunucunun, mantıksal sunucunun desteklediği en fazla veritabanı sayısını içeren sınırları vardır. Bu sınırlara yaklaşırken kiracı eklemeye devam edebilmeniz için yeni sunucular sağlamanız gerekebilir. Bu işlemi otomatikleştirip otomatikleştiremeyeceğinizi veya büyümeyi el ile izlediğinizi düşünün.

Kaynak yönetimi sorumluluğu

Çok kiracılı bazı çözümlerde, her kiracı için ayrılmış Azure kaynakları (her kiracı için veritabanı gibi) dağıtırsınız. Alternatif olarak, kaynağın tek bir örneğinde barındırılacak belirli sayıda kiracıyı da belirleyebilirsiniz. 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 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 düşünmeniz gerekir. İki yaygın yaklaşım şunlardır:

• Kiracıları dağıttığınız kaynakların yapılandırması olarak ele almak ve dağıtım işlem hatlarınızı kullanarak bu kaynakları dağıtmak ve yapılandırmak için kullanın.
• 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 simülasyonunu yapmayı ve bir bileşen kullanılamadığında veya arızalı olduğunda 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 ç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 birden çok damga pulu arasında bir dağıtımı koordine edebilirsiniz. Her kiracı için ayrılmış damga damgaları dağıtırsanız, damgaların tamamını program aracılığıyla dağıtmayı da düşünebilirsiniz.

Dağıtım halkaları

Dağıtım halkaları , güncelleştirmeleri farklı altyapı gruplarına farklı zamanlarda dağıtmanıza olanak tanır. 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ı tutarken çözümünüzün yeni özelliklerini veya sürümlerini aşamalı olarak farklı kiracılarda kullanıma sunmanızı sağlar. Özellik bayraklarınızı yönetmek için Azure Uygulaması 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ü amaçlı değişkenler

Ç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 yeteneğinizi 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 ekler. 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 yetkilendirmeleriyle farklı fiyatlandırma katmanlarını kullanın. Yalıtılmış veya ayrılmış kaynakları olan kiracılar için bile tutarlı ve otomatik bir 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 bir 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ı göz önünde bulundurduğunda da önemlidir.

Yapılandırma olarak kiracı listesi

Kiracı listenizi yapılandırma olarak ele aldığınızda, 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 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 olan 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 kaynak 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. 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ıya yaklaştığınızda, kiracı eklerken 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 önce 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 bir 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ırabilirsiniz. Ö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 kiracı ekleme işlemi aşağıdakine benzer olabilir ve zaman uyumsuz olarak gerçekleşebilir:

1. Sisteminizin denetim düzlemine BIR API isteği başlatarak bir 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 derlemek 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ıları var ve önümüzdeki 18 ay içinde 300 kiracıya kadar 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 kümesi 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, dağıtım işlem hattı kullanarak tüm kaynaklarını dağıtmayı düşünebilir. İşlem hattı, 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 bir 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 hatları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 bir şekilde yüksek oranda büyürler ve tek bir Azure SQL mantıksal sunucusunda 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ı düşünebilir.

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ışı, aşağıdaki yaklaşımlardan biri tarafından gerçekleştirilebilecek yeni bir Azure SQL veritabanının dağıtımını başlatır:

• 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'yı 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 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:

• 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.