Çok kiracılı çözümlerde Azure kaynak kuruluşu

Azure
Azure Resource Manager
Microsoft Entra ID

Azure, kaynaklarınızı düzenlemek için birçok seçenek sunar. Çok kiracılı bir çözümde, kaynak kuruluş stratejinizi planlarken göz önünde bulundurmanız gereken belirli dengeler vardır. Bu makalede, Azure kaynaklarınızı düzenlemenin iki temel öğesini gözden geçireceğiz: kiracı yalıtımı ve birden çok kaynak arasında ölçeği genişletme. Farklı kiracı yalıtım modellerini destekleyebilecek bazı yaygın dağıtım yaklaşımlarını açıklıyoruz. Ayrıca Azure'ın kaynak sınırları ve kotalarıyla çalışmayı ve çözümünüzü bu sınırların ötesinde ölçeklendirmeyi de açıklıyoruz.

Önemli noktalar ve gereksinimler

Kiracı yalıtım gereksinimleri

Azure'da çok kiracılı bir çözüm dağıttığınızda, kaynakları her kiracıya mı ayırdığınıza yoksa kaynakları birden çok kiracı arasında mı paylaştığınıza karar vermeniz gerekir. Bu serinin çok kiracılı yaklaşımları ve hizmete özgü rehberlik bölümleri boyunca, birçok kaynak kategorisi için seçenekleri ve dengeleri açıklıyoruz. Genel olarak, kiracı yalıtımı için bir dizi seçenek vardır. Yalıtım modelinize karar verme hakkında daha fazla rehberlik için Çok kiracılı bir çözüm için dikkate alınacak Kiracı modellerini gözden geçirin.

Ölçek

Azure kaynaklarının yanı sıra kaynak grupları ve aboneliklerin çoğu, ölçeklendirme yeteneğinizi etkileyebilecek sınırlar uygular. Planlanan kiracı sayısını veya planlı sistem yükünüzü karşılamak için ölçeği genişletmeyi veya paketlemeyi göz önünde bulundurmanız gerekebilir.

Çok fazla sayıda kiracıya veya yüksek yüke çıkmayabileceğinizi kesin olarak biliyorsanız, ölçeği genişletme planınızı aşmayın. Ancak çözümünüzün büyümesini planlıyorsanız ölçeği genişletme planınızı dikkatlice göz önünde bulundurun. Bu makaledeki yönergeleri izleyerek ölçek için mimari oluşturduğunuzdan emin olun.

Otomatik dağıtım işleminiz varsa ve kaynaklar arasında ölçeklendirmeniz gerekiyorsa, kiracıları birden çok kaynak örneğine nasıl dağıtıp atayabileceğinizi belirleyin. Örneğin, belirli bir kaynağa atanabilecek kiracı sayısına yaklaştığınızı nasıl algılayacaksınız? Yeni kaynakları ihtiyacınız olduğunda tam zamanında dağıtmayı planlıyor musunuz? Alternatif olarak, ihtiyaç duyduğunuzda kullanmaya hazır olmaları için önceden bir kaynak havuzu mu dağıtacaksınız?

İpucu

Tasarım ve geliştirmenin ilk aşamalarında otomatik ölçek genişletme işlemlerini uygulamayı seçmeyebilirsiniz. Büyüdükçe ölçeklendirmek için gereken işlemleri göz önünde bulundurmanız ve net bir şekilde belgelemeniz gerekir. İşlemleri belgeleyerek, gelecekte ihtiyaç duyulacaksa bunları otomatikleştirmeyi kendiniz daha kolay hale getirirsiniz.

Ayrıca, kodunuzun ve yapılandırmanızın genelinde ölçeklendirme yeteneğinizi sınırlayan varsayımlarda bulunmamak da önemlidir. Örneğin, gelecekte birden çok depolama hesabının ölçeğini genişletmeniz gerekebilir, bu nedenle uygulama katmanınızı oluştururken etkin kiracıya göre bağlandığı depolama hesabını dinamik olarak değiştirebileceğinden emin olun.

Dikkate alınacak yaklaşımlar ve desenler

Kiracı yalıtımı

Azure kaynakları bir hiyerarşi aracılığıyla dağıtılır ve yönetilir. Kaynakların çoğu aboneliklerde yer alan kaynak gruplarına dağıtılır. Yönetim, abonelikleri mantıksal olarak gruplar. Bu hiyerarşik katmanların tümü bir Microsoft Entra kiracısıyla ilişkilendirilir.

Her kiracı için kaynakları dağıtmayı saptadığınızda, hiyerarşideki farklı düzeylerde yalıtabilirsiniz. Her seçenek, belirli çok müşterili çözümler için geçerlidir ve avantajları ve dezavantajları vardır. Ayrıca, bir çözümün farklı bileşenleri için farklı yalıtım modellerini kullanarak yaklaşımları birleştirmek de yaygındır.

Paylaşılan kaynak içinde yalıtım

Bir Azure kaynağını birden çok kiracı arasında paylaşmayı ve tüm iş yüklerini tek bir örnekte çalıştırmayı seçebilirsiniz. Önemli olabilecek belirli noktaları veya seçenekleri anlamak için kullandığınız Azure hizmetlerine yönelik hizmete özgü kılavuzu gözden geçirin.

Bir kaynağın tek bir örneğini çalıştırdığınızda, ölçeklendirildikçe ulaşabileceğiniz hizmet sınırlarını, abonelik sınırlarını veya kotaları göz önünde bulundurmanız gerekir. Örneğin, Azure Kubernetes Service (AKS) kümesi tarafından desteklenen en fazla düğüm sayısı ve bir depolama hesabı tarafından desteklenen saniye başına işlem sayısı üst sınırı vardır. Bu sınırlara yaklaşırken birden çok paylaşılan kaynağa nasıl ölçeklendirilebileceğinizi düşünün.

Ayrıca uygulama kodunuzun çok kiracılılığı tam olarak anladığınızdan ve belirli bir kiracının verilerine erişimi kısıtladığından emin olmanız gerekir.

Paylaşılan kaynak yaklaşımının bir çizimi olarak Contoso'nun web uygulaması, veritabanı ve depolama hesabı içeren çok kiracılı bir SaaS uygulaması oluşturduğunu varsayalım. Tüm müşterilerine hizmet vermek için paylaşılan kaynakları dağıtmaya karar verebilirler. Aşağıdaki diyagramda tek bir kaynak kümesi tüm müşteriler tarafından paylaşılır.

Tüm müşteriler tarafından paylaşılan tek bir kaynak kümesini gösteren diyagram.

Kaynak grubundaki kaynakları ayırma

Ayrıca her kiracı için ayrılmış kaynaklar dağıtabilirsiniz. Çözümünüzün tüm kopyasını tek bir kiracı için dağıtabilirsiniz. Alternatif olarak, bazı bileşenler belirli bir kiracıya ayrılmışken bazı bileşenleri kiracılar arasında paylaşabilirsiniz. Bu yaklaşım yatay bölümleme olarak bilinir.

Aynı yaşam döngüsüne sahip kaynakları yönetmek için kaynak gruplarını kullanmanızı öneririz. Bazı çok kiracılı sistemlerde, birden çok kiracı için kaynakları tek bir kaynak grubuna veya bir kaynak grubu kümesine dağıtmak mantıklıdır.

Kiracıya özgü kaynakların dağıtımının dağıtım işlem hattınız veya uygulamanız tarafından başlatılıp başlatılmadığı da dahil olmak üzere bu kaynakları nasıl dağıttığınızı ve yönettiğinizi göz önünde bulundurmanız önemlidir. Ayrıca, belirli kaynakların belirli kiracılarla ilişkili olduğunu nasıl net bir şekilde tanımlayabileceğinizi de belirlemeniz gerekir. Net bir adlandırma kuralı stratejisi, kaynak etiketleri veya kiracı kataloğu veritabanı kullanmayı göz önünde bulundurun.

Birden çok kiracı arasında paylaştığınız kaynaklar ve tek tek kiracılar için dağıttığınız kaynaklar için ayrı kaynak grupları kullanmak iyi bir uygulamadır. Ancak bazı kaynaklar için Azure, bir kaynak grubuna dağıtılabilen tek bir türdeki kaynak sayısını sınırlar. Bu sınır, büyüdükçe birden çok kaynak grubu arasında ölçeklendirme yapmanız gerekebileceği anlamına gelir.

Contoso'nun üç müşterisi (kiracı) olduğunu varsayalım: Adventure Works, Fabrikam ve Tailwind. Web uygulamasını ve depolama hesabını üç kiracı arasında paylaşmayı ve ardından her kiracı için ayrı veritabanları dağıtmayı seçebilirler. Aşağıdaki diyagramda paylaşılan kaynakları içeren bir kaynak grubu ve her kiracının veritabanını içeren bir kaynak grubu gösterilmektedir.

Paylaşılan kaynakları içeren bir kaynak grubunu ve her müşteri için veritabanı içeren başka bir kaynak grubunu gösteren diyagram.

Abonelikteki kaynak gruplarını ayırma

Her kiracı için bir kaynak kümesi dağıttığınızda, kiracıya özgü ayrılmış kaynak gruplarını kullanmayı göz önünde bulundurun. Örneğin, Dağıtım Damga DamgaLarı desenini uyguladığınızda, her damga kendi kaynak grubuna dağıtılmalıdır. İlkeleri ve erişim denetimi kurallarını kolayca yapılandırmanıza olanak tanıyan, kiracıya özgü birden çok kaynak grubunu paylaşılan bir Azure aboneliğine dağıtmayı düşünebilirsiniz.

Her kiracı için bir kaynak grubu kümesi ve paylaşılan kaynaklar için de paylaşılan kaynak grupları oluşturmayı seçebilirsiniz.

Kiracıya özgü kaynak gruplarını paylaşılan aboneliklere dağıttığınızda, her abonelikteki en fazla kaynak grubu sayısına ve dağıttığınız kaynaklara uygulanan diğer abonelik düzeyi sınırlarına dikkat edin. Bu sınırlara yaklaştıkça birden çok abonelik arasında ölçeklendirme yapmanız gerekebilir.

Örneğimizde Contoso, müşterilerinin her biri için bir damga pulu dağıtmayı ve damgaları tek bir abonelik içindeki ayrılmış kaynak gruplarına yerleştirmeyi seçebilir. Aşağıdaki diyagramda, her müşteri için üç kaynak grubu içeren bir abonelik oluşturulur.

Her biri belirli bir müşteri için eksiksiz bir kaynak kümesi olan üç kaynak grubu içeren bir aboneliği gösteren diyagram.

Abonelikleri ayırma

Kiracıya özgü abonelikleri dağıtarak kiracıya özgü kaynakları tamamen yalıtabilirsiniz. Ayrıca, çoğu kota ve sınır bir abonelik içinde geçerli olduğundan, kiracı başına ayrı bir abonelik kullanmak, her kiracının geçerli kotaları tam olarak kullanmasını sağlar. Bazı Azure ödeme hesabı türleri için program aracılığıyla abonelik oluşturabilirsiniz. Abonelikler arasında işlem için Azure rezervasyonlarını ve Azure tasarruf planını da kullanabilirsiniz.

Oluşturabileceğiniz abonelik sayısını bilmenize olanak sağlar. Microsoft veya bir Microsoft iş ortağıyla ticari ilişkinize bağlı olarak, kurumsal anlaşmanız olması gibi aboneliklerin maksimum sayısı farklılık gösterebilir.

Ancak, çok sayıda abonelikte çalışırken kota artışı istemek daha zor olabilir. Kota API'si bazı kaynak türleri için programlı bir arabirim sağlar. Ancak birçok kaynak türü için bir destek olayı başlatılarak kota artışı istenmelidir. Ayrıca, birçok abonelikle çalışırken Azure desteği sözleşmeleri ve destek örnekleriyle çalışmak da zor olabilir.

Erişim denetimi kurallarının ve ilkelerinin kolay yönetilmesini sağlamak için kiracıya özgü aboneliklerinizi bir yönetim grubu hiyerarşisinde gruplandırmayı göz önünde bulundurun.

Örneğin Contoso'nun aşağıdaki diyagramda gösterildiği gibi üç müşterisinin her biri için ayrı Azure abonelikleri oluşturmaya karar verdiklerini varsayalım. Her abonelik, bu müşteri için eksiksiz kaynak kümesini içeren bir kaynak grubu içerir.

Müşteriye özgü üç aboneliği gösteren diyagram. Her abonelik, bu müşteri için eksiksiz kaynak kümesini içeren bir kaynak grubu içerir.

Her abonelik, bu müşteri için eksiksiz kaynak kümesini içeren bir kaynak grubu içerir.

Aboneliklerinin yönetimini basitleştirmek için bir yönetim grubu kullanırlar. Üretim'i yönetim grubunun adına ekleyerek, herhangi bir üretim kiracısını üretim dışı kiracılardan veya test kiracılarından açıkça ayırt edebilir. Üretim dışı kiracılarda farklı Azure erişim denetimi kuralları ve ilkeleri uygulanır.

Tüm abonelikleri tek bir Microsoft Entra kiracısıyla ilişkilendirilir. Tek bir Microsoft Entra kiracısı kullanmak, Contoso ekibinin kullanıcılar ve hizmet sorumluları dahil olmak üzere kimliklerinin azure varlıklarının tamamında kullanılabilmesi anlamına gelir.

Abonelikleri ayrı Microsoft Entra kiracılarında ayırma

Ayrıca her kiracınız için tek tek Microsoft Entra kiracıları oluşturabilir veya kaynaklarınızı müşterilerinizin Microsoft Entra kiracıları içindeki aboneliklere dağıtabilirsiniz. Ancak, birden çok Microsoft Entra kiracısıyla çalışmak kimlik doğrulamayı, rol atamalarını yönetmeyi, genel ilkeleri uygulamayı ve diğer birçok yönetim işlemini gerçekleştirmeyi daha zor hale getirir.

Uyarı

Çoğu çok kiracılı çözüm için birden çok Microsoft Entra kiracısı oluşturmamanızı öneririz. Microsoft Entra kiracılarında çalışmak ek karmaşıklık sağlar ve kaynaklarınızı ölçeklendirme ve yönetme becerinizi azaltır. Bu yaklaşım genellikle yalnızca müşterileri adına Azure ortamlarını çalıştıran yönetilen hizmet sağlayıcıları (MSP) tarafından kullanılır.

Birden çok Microsoft Entra kiracısı dağıtmak için çaba harcamadan önce, bunun yerine tek bir kiracıdaki yönetim gruplarını veya abonelikleri kullanarak gereksinimlerinizi karşılayıp sağlayamayacağınızı göz önünde bulundurun.

Birden çok Microsoft Entra kiracısına bağlı aboneliklerde Azure kaynaklarını yönetmeniz gereken durumlarda, Microsoft Entra kiracılarınızda kaynaklarınızı yönetmenize yardımcı olması için Azure Lighthouse'u kullanmayı göz önünde bulundurun.

Örneğin Contoso, aşağıdaki diyagramda gösterildiği gibi müşterilerinden her biri için ayrı Microsoft Entra kiracıları ve ayrı Azure abonelikleri oluşturabilir.

Contoso kiracılarının her biri için bir Abonelik ve gerekli kaynakları içeren bir Microsoft Entra kiracısını gösteren diyagram. Azure Lighthouse, her Microsoft Entra kiracısına bağlıdır.

Contoso kiracılarının her biri için bir Microsoft Entra kiracısı yapılandırılır ve bu kiracı bir abonelik ve gerekli kaynakları içerir. Azure Lighthouse, her Microsoft Entra kiracısına bağlıdır.

Bölme paketleme

Kaynak yalıtım modelinizden bağımsız olarak, çözümünüzün birden çok kaynakta ölçeğinin ne zaman ve nasıl genişletileceğini göz önünde bulundurmanız önemlidir. Sisteminizdeki yük arttıkça veya kiracı sayısı arttıkça kaynaklarınızı ölçeklendirmeniz gerekebilir. Gereksinimleriniz için en uygun sayıda kaynak dağıtmak için bölme paketlemeyi göz önünde bulundurun.

İpucu

Birçok çözümde kaynakları tek tek ölçeklendirmek yerine tüm kaynak kümenizi birlikte ölçeklendirmek daha kolaydır. Dağıtım DamgaLarı desenini takip etmeyi göz önünde bulundurun.

Kaynak sınırları

Azure kaynaklarının, çözüm planlamanızda dikkate alınması gereken sınırları ve kotaları vardır. Örneğin, kaynaklar en fazla sayıda eşzamanlı isteği veya kiracıya özgü yapılandırma ayarlarını destekleyebileceğinden.

Her kaynağı yapılandırma ve kullanma şekliniz, bu kaynağın ölçeklenebilirliğini de etkiler. Örneğin, belirli miktarda işlem kaynağı göz önünde bulundurulduğunda uygulamanızın saniyede tanımlı sayıda işleme başarılı bir şekilde yanıt verebileceğini varsayalım. Bu noktadan sonra ölçeği genişletmeniz gerekebilir. Performans testi, kaynaklarınızın artık gereksinimlerinizi karşılamadığı noktayı belirlemenize yardımcı olur.

Not

Birden çok kaynağı ölçeklendirme ilkesi, birden çok örneği destekleyen hizmetlerle çalışırken bile geçerlidir.

Örneğin Azure Uygulaması Hizmeti, planınızın örnek sayısının ölçeğini genişletmeyi destekler, ancak tek bir planı ne kadar ölçeklendirebileceğinize ilişkin sınırlar vardır. Yüksek ölçekli çok kiracılı bir uygulamada bu sınırları aşabilir ve büyümenize uygun daha fazla App Service planı dağıtmanız gerekebilir.

Bazı kaynaklarınızı kiracılar arasında paylaştığınızda, önce kaynağın gereksinimlerinize göre yapılandırıldığında desteklediği kiracı sayısını belirlemeniz gerekir. Ardından, toplam kiracı sayısına hizmet vermek için gereken kadar kaynak dağıtın.

Örneğin, Azure Uygulaması lication Gateway'i çok kiracılı bir SaaS çözümünün parçası olarak dağıttığınızı varsayalım. Uygulama tasarımınızı gözden geçirir, yük altında uygulama ağ geçidinin performansını test eder ve yapılandırmasını gözden geçirirsiniz. Ardından, tek bir uygulama ağ geçidi kaynağının 100 müşteri arasında paylaşılabildiğini belirlersiniz. Kuruluşunuzun büyüme planına göre, ilk yılınızda 150 müşteri eklemeyi bekliyorsunuz, bu nedenle beklenen yüke hizmet vermek için birden çok uygulama ağ geçidi dağıtmayı planlamanız gerekiyor.

İki uygulama ağ geçidini gösteren diyagram. İlk ağ geçidi 1 ile 100 arasında müşterilere, ikincisi ise 101 ile 200 arasında müşterilere ayrılmıştır.

Önceki diyagramda iki uygulama ağ geçidi vardır. İlk ağ geçidi 1 ile 100 arasında müşterilere, ikincisi ise 101 ile 200 arasında müşterilere ayrılmıştır.

Kaynak grubu ve abonelik sınırları

İster paylaşılan ister ayrılmış kaynaklarla çalışın, sınırları dikkate almak önemlidir. Azure, bir kaynak grubuna ve azure aboneliğine dağıtılacak kaynak sayısını sınırlar. Bu sınırlara yaklaşırken birden çok kaynak grubu veya abonelik arasında ölçeklendirmeyi planlamanız gerekir.

Örneğin, müşterilerinizin her biri için paylaşılan bir kaynak grubuna ayrılmış bir uygulama ağ geçidi dağıttığınızı varsayalım. Bazı kaynaklar için Azure desteği aynı türdeki en fazla 800 kaynağı tek bir kaynak grubuna dağıtır. Bu nedenle, bu sınıra ulaştığınızda, yeni uygulama ağ geçitlerini başka bir kaynak grubuna dağıtmanız gerekir. Aşağıdaki diyagramda iki kaynak grubu vardır. Her kaynak grubu 800 uygulama ağ geçidi içerir.

İki kaynak grubunu gösteren diyagram. Her kaynak grubu 800 uygulama ağ geçidi içerir.

Kaynak grupları ve abonelikler arasında gruplama paketi kiracıları

Ayrıca, depo gözü paketleme kavramını kaynaklara, kaynak gruplarına ve aboneliklere de uygulayabilirsiniz. Örneğin, az sayıda kiracınız olduğunda tek bir kaynak dağıtabilir ve tüm kiracılarınız arasında paylaşabilirsiniz. Aşağıdaki diyagramda, tek bir kaynakta kutu paketleme gösterilmektedir.

Tek bir kaynakta kutu paketlemeyi gösteren diyagram.

Büyüdükçe, tek bir kaynağın kapasite sınırına yaklaşabilir ve ölçeği birden çok (R) kaynağa genişletebilirsiniz. Aşağıdaki diyagramda, birden çok kaynak arasında kutu paketleme gösterilmektedir.

Birden çok kaynak arasında bölme paketlemeyi gösteren diyagram.

Zaman içinde, tek bir kaynak grubundaki kaynak sayısı sınırına ulaşabilir ve birden çok (R) kaynağı birden çok (G) kaynak grubuna dağıtabilirsiniz. Aşağıdaki diyagramda, birden çok kaynak grubundaki birden çok kaynakta bölme paketleme gösterilmektedir.

Birden çok kaynak grubunda depo gözü paketlemeyi gösteren diyagram.

Daha da büyüdükçe, her biri birden çok (R) kaynağı olan birden çok (G) kaynak grubu içeren birden çok (S) aboneliğe dağıtabilirsiniz. Aşağıdaki diyagramda, birden çok kaynak grubunda ve abonelikte birden çok kaynak arasında kutu paketleme gösterilmektedir.

Birden çok kaynak grubu ve abonelikte birden çok kaynak arasında bölme paketlemeyi gösteren diyagram.

Ölçeği genişletme stratejinizi planlayarak çok fazla sayıda kiracıya ölçeklendirebilir ve yüksek yük düzeyini sürdürebilirsiniz.

Etiketler

Kaynak etiketleri, Azure kaynaklarınıza özel meta veriler eklemenize olanak tanır. Bu, yönetim ve izleme maliyetleri için yararlı olabilir. Diğer ayrıntılar için bkz . Kaynak etiketlerini kullanarak maliyetleri ayırma.

Dağıtım yığınları

Dağıtım yığınları, birden çok kaynak grubuna veya aboneliğe yayılmış olsalar bile kaynakları ortak bir yaşam süresine göre gruplandırmanıza olanak tanır. Dağıtım yığınları, kiracıya özgü kaynakları dağıtırken, özellikle de ölçek veya uyumluluk endişeleri nedeniyle farklı kaynak türlerini farklı yerlere dağıtmayı gerektiren bir dağıtım yaklaşımınız varsa kullanışlıdır. Dağıtım yığınları, tek bir kiracıyla ilgili tüm kaynakları tek bir işlemde (bu kiracı kapalıysa) kolayca kaldırmanıza da olanak tanır. Daha fazla bilgi için bkz . Dağıtım yığınları.

Kaçınılması gereken kötü amaçlı değişkenler

  • Ölçek planlanmaması. Dağıtacağınız kaynakların sınırlarını ve yükünüz veya kiracı sayısı arttıkça hangi sınırların önemli hale gelebileceğini net bir şekilde anladığınızdan emin olun. Ölçeklendikçe ek kaynakları nasıl dağıtabileceğinizi planlayın ve planı test edin.
  • Paketlemeyi planlamayın. Hemen büyümeniz gerekmeyecek olsa bile Azure kaynaklarınızı zaman içinde birden çok kaynak, kaynak grubu ve abonelik arasında ölçeklendirmeyi planlayın. Gelecekte birden çok kaynağa ölçeklendirmeniz gerekebilecek tek bir kaynak gibi uygulama kodunuzda varsayımlarda bulunmaktan kaçının.
  • Birçok ayrı kaynağı ölçeklendirme. Karmaşık bir kaynak topolojiniz varsa, her bileşeni ayrı ayrı ölçeklendirmek zor olabilir. Dağıtım DamgaLarı desenini izleyerek çözümünüzü bir birim olarak ölçeklendirmek genellikle daha kolaydır.
  • Gerekli olmadığında her kiracı için yalıtılmış kaynaklar dağıtma. Birçok çözümde, birden çok kiracı için paylaşılan kaynakları dağıtmak daha uygun maliyetli ve verimlidir.
  • Kiracıya özgü kaynaklar izlenememesi. Kiracıya özgü kaynakları dağıtırsanız, hangi kaynakların hangi kiracılara ayrıldığını anladığınızdan emin olun. Bu bilgiler uyumluluk amacıyla, maliyetleri izlemek için ve kiracı kullanımdan kaldırılmışsa kaynakların sağlamasını kaldırma için önemlidir. Kaynaklardaki kiracı bilgilerini izlemek için kaynak etiketlerini kullanmayı ve kiracıya özgü kaynakları içinde bulundukları kaynak grubuna veya aboneliğe bakılmaksızın mantıksal bir birimde gruplandırmak için dağıtım yığınlarını kullanmayı göz önünde bulundurun.
  • Ayrı Microsoft Entra kiracıları kullanma. Genel olarak, birden çok Microsoft Entra kiracısı sağlanması öngörülemez. Microsoft Entra kiracılarında kaynakları yönetmek karmaşıktır. Tek bir Microsoft Entra kiracısına bağlı abonelikler arasında ölçeklendirme yapmak daha kolaydır.
  • Ölçeklendirmeniz gerekmeyen durumlarda aşırı mimari oluşturma. Bazı çözümlerde, hiçbir zaman belirli bir ölçek düzeyinin ötesine geçmeyeceğini kesin olarak bilirsiniz. Bu senaryolarda karmaşık ölçeklendirme mantığı oluşturmaya gerek yoktur. Ancak, kuruluşunuz büyümeyi planlıyorsa, kısa sürede ölçeklendirmeye hazır olmanız gerekir.

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:

Diğer katkıda bulunanlar:

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

Sonraki adımlar

Maliyet yönetimi ve ayırma yaklaşımlarını gözden geçirin.