Share via

Çok kiracılı çözümlerde ağ iletişimi için mimari yaklaşımlar

  • Makale

Azure'a dağıtılan tüm çözümler için bir tür ağ iletişimi gerekir. Çözüm tasarımınıza ve iş yüküne bağlı olarak, Azure'ın ağ hizmetleriyle etkileşim kurma yöntemleriniz farklı olabilir. Bu makalede, Azure'da çok kiracılı çözümlerin ağ özelliklerine ilişkin önemli noktalar ve yönergeler sağlıyoruz. Sanal ağlar gibi alt düzey ağ bileşenleriyle ilgili bilgileri daha üst düzeye ve uygulama katmanı yaklaşımlarına dahil ediyoruz.

Not

Azure'ın kendisi çok kiracılı bir ortamdır ve Azure'ın ağ bileşenleri çok kiracılı kullanım için tasarlanmıştır. Kendi çözümünüzü tasarlamak için ayrıntıları anlamanız gerekmese de Azure'ın sanal ağ trafiğinizi diğer müşterilerin trafiğinden nasıl yalıtdığı hakkında daha fazla bilgi edinebilirsiniz.

Önemli noktalar ve gereksinimler

Altyapı ve platform hizmetleri

Ağ bileşenlerinizle ilgili endişeleriniz, kullandığınız hizmetlerin kategorisine bağlı olarak farklılık gösterir.

Altyapı hizmetleri

Sanal makineler veya Azure Kubernetes Service gibi altyapı hizmetlerini her kullandığınızda, hizmetlerinizin bağlantısını destekleyen sanal ağları veya sanal ağları göz önünde bulundurmanız ve tasarlamanız gerekir. Ayrıca tasarımınıza dahil etmeniz gereken diğer güvenlik ve yalıtım katmanlarını da göz önünde bulundurmanız gerekir. Yalnızca ağ katmanı denetimlerine güvenmekten kaçının.

Platform hizmetleri

Azure'ın App Service, Azure Cosmos DB veya Azure SQL Veritabanı gibi platform hizmetlerini kullanıyorsanız, ihtiyacınız olan ağ hizmetlerini kullandığınız mimari belirler.

Platform hizmetlerinizi İnternet'ten yalıtmanız gerekiyorsa bir sanal ağ kullanmanız gerekir. Kullandığınız belirli hizmetlere bağlı olarak, özel uç noktalarla veya Application Gateway gibi sanal ağ ile tümleşik kaynaklarla çalışabilirsiniz. Ancak, platform hizmetlerinizi genel IP adresleri aracılığıyla kullanılabilir hale getirmeyi ve hizmetlerin güvenlik duvarları ve kimlik denetimleri gibi kendi korumalarını kullanmayı da seçebilirsiniz. Bu gibi durumlarda sanal ağa ihtiyacınız olmayabilir.

Platform hizmetleri için sanal ağların kullanılıp kullanılmaymayacağına ilişkin karar, aşağıdaki faktörler de dahil olmak üzere birçok gereksinimi temel alır:

  • Uyumluluk gereksinimleri: Belirli bir uyumluluk standardına uymanız gerekebilir. Bazı standartlar, Azure ortamınızın belirli şekillerde yapılandırılmasını gerektirir.
  • Kiracılarınızın gereksinimleri: Kendi kuruluşunuzun ağ katmanı yalıtımı veya denetimleri için belirli gereksinimleri olmasa bile kiracılarınız bunu yapabilir. Kiracılarınızın çözümünüze nasıl erişeceğini ve ağ tasarımıyla ilgili varsayımları olup olmadığını net bir şekilde anladığınızdan emin olun.
  • Karmaşıklık: Sanal ağları anlamak ve bunlarla çalışmak daha karmaşık olabilir. Ekibinizin ilgili ilkeleri net bir şekilde anladığınızdan veya güvenli olmayan bir ortam dağıtma olasılığınız olduğundan emin olun.

Özel ağ kullanmanın etkilerini anladığınızdan emin olun.

Alt ağları boyutlandırma

Bir sanal ağ dağıtmanız gerektiğinde, tüm sanal ağın ve sanal ağın içindeki alt ağların boyutlandırma ve adres alanını dikkatle göz önünde bulundurmanız önemlidir.

Azure kaynaklarınızı sanal ağlara nasıl dağıtacağınız ve her kaynağın tükettiği IP adresi sayısını net bir şekilde anladığınızdan emin olun. Kiracıya özgü işlem düğümlerini, veritabanı sunucularını veya diğer kaynakları dağıtırsanız, beklenen kiracı büyümeniz ve kaynakların yatay otomatik ölçeklendirmesi için yeterince büyük alt ağlar oluşturduğunuzdan emin olun.

Benzer şekilde, yönetilen hizmetlerle çalışırken IP adreslerinin nasıl tüketildiğini anlamanız önemlidir. Örneğin, Azure Kubernetes Service'i Azure Container Networking Interface (Azure CNI) ile kullandığınızda, alt ağdan tüketilen IP adreslerinin sayısı düğüm sayısı, yatay olarak ölçeklendirme şekliniz ve kullandığınız hizmet dağıtım süreci gibi faktörlere dayalı olacaktır. Azure Uygulaması Hizmeti'ni kullandığınızda ve sanal ağ tümleştirmesiyle Azure İşlevleri kullandığınızda, kullanılan IP adresi sayısı plan örneklerinin sayısına bağlıdır.

Alt ağlarınızı planlarken alt ağ segmentasyonu kılavuzunu gözden geçirin.

Genel veya özel erişim

Kiracılarınızın hizmetlerinize İnternet üzerinden mi yoksa özel IP adresleri üzerinden mi erişeceğini düşünün.

İnternet tabanlı (genel) erişim için, hizmetinizin güvenliğini sağlamak için güvenlik duvarı kurallarını, IP adresi izin verilenler listesi ve reddetme listesini, paylaşılan gizli dizileri ve anahtarları ve kimlik tabanlı denetimleri kullanabilirsiniz.

Özel IP adresleri kullanarak hizmetinize bağlantıyı etkinleştirmeniz gerekiyorsa, Azure Özel Bağlantı Hizmeti veya kiracılar arası sanal ağ eşlemesi kullanmayı göz önünde bulundurun. Bazı sınırlı senaryolarda, çözümünüzde özel erişim sağlamak için Azure ExpressRoute veya Azure VPN Gateway kullanmayı da düşünebilirsiniz. Bu yaklaşımı yalnızca az sayıda kiracınız olduğunda kullanmanızı ve her kiracı için ayrılmış sanal ağlar dağıtmanızı öneririz.

Kiracıların uç noktalarına erişim

Azure içinde veya dışında kiracı ağlarının içindeki uç noktalara veri göndermeniz gerekip gerekmediğini göz önünde bulundurun. Örneğin, müşteri tarafından sağlanan bir web kancasını çağırmanız mı yoksa bir kiracıya gerçek zamanlı iletiler göndermeniz mi gerekiyor?

Kiracıların uç noktalarına veri göndermeniz gerekiyorsa aşağıdaki yaygın yaklaşımları göz önünde bulundurun:

  • Çözümünüzden kiracıların uç noktalarına İnternet üzerinden bağlantı başlatın. Bağlantıların statik BIR IP adresinden kaynaklanıp kaynaklandığını düşünün. Kullandığınız Azure hizmetlerine bağlı olarak NAT Ağ Geçidi, güvenlik duvarı veya yük dengeleyici dağıtmanız gerekebilir.
  • Azure'da barındırılan hizmetlerinizle müşterilerinizin ağları arasında nerede bulunduklarına bakılmaksızın bağlantıyı etkinleştirmek için bir aracı dağıtın.
  • Tek yönlü mesajlaşma için Azure Event Grid gibi bir hizmeti olay etki alanlarıyla veya olay etki alanları olmadan kullanmayı göz önünde bulundurun.

Dikkate alınacak yaklaşımlar ve desenler

Bu bölümde, çok kiracılı bir çözümde göz önünde bulundurabileceğiniz bazı önemli ağ yaklaşımlarını açıklayacağız. İlk olarak temel ağ bileşenlerine yönelik alt düzey yaklaşımları açıklıyoruz ve ardından HTTP ve diğer uygulama katmanı endişeleri için göz önünde bulundurabileceğiniz yaklaşımları takip ediyoruz.

Hizmet sağlayıcısı tarafından seçilen IP adresleriyle kiracıya özgü sanal ağlar

Bazı durumlarda Azure'da kiracı adına ayrılmış sanal ağa bağlı kaynaklar çalıştırmanız gerekir. Örneğin, her kiracı için bir sanal makine çalıştırabilir veya kiracıya özgü veritabanlarına erişmek için özel uç noktaları kullanmanız gerekebilir.

Denetlediğiniz bir IP adresi alanı kullanarak her kiracı için bir sanal ağ dağıtmayı göz önünde bulundurun. Bu yaklaşım, trafik giriş ve çıkışını merkezi olarak denetlemek için bir merkez-uç topolojisi oluşturmanız gerektiği gibi, sanal ağları kendi amaçlarınız doğrultusunda eşlemenize olanak tanır.

Ancak kiracıların sanal ağ eşlemesi kullanarak doğrudan oluşturduğunuz sanal ağa bağlanması gerekiyorsa hizmet sağlayıcısı tarafından seçilen IP adresleri uygun değildir. Seçtiğiniz adres alanının kendi adres alanlarıyla uyumsuz olması olasıdır.

Kiracı tarafından seçilen IP adreslerine sahip kiracıya özgü sanal ağlar

Kiracıların kendi sanal ağlarını kendi adına yönettiğiniz sanal ağlarla eşlemesi gerekiyorsa kiracıya özgü sanal ağları kiracının seçtiği bir IP adresi alanıyla dağıtmayı göz önünde bulundurun. Bu sistem, her kiracının sisteminizin sanal ağındaki IP adresi aralıklarının kendi sanal ağlarıyla çakışmadığından emin olmasını sağlar. Çakışmayan IP adresi aralıklarını kullanarak ağlarının eşleme için uyumlu olduğundan emin olabilirler.

Ancak bu yaklaşım, kiracılarınızın sanal ağlarını eşleyebileceğiniz veya farklı kiracıların sanal ağları arasında çakışan IP adresi aralıkları olabileceğinden bir merkez-uç topolojisi benimseme olasılığınız düşük olduğu anlamına gelir.

Merkez-uç topolojisi

Merkez-uç sanal ağ topolojisi, birden çok uç sanal ağı olan merkezi bir merkez sanal asını eşlemenizi sağlar. Sanal ağlarınızın trafik giriş ve çıkışını merkezi olarak denetleyebilir ve her bir uçtaki sanal ağ içindeki kaynakların birbiriyle iletişim kurup kuramayacağını denetleyebilirsiniz. Her uç sanal ağı Azure Güvenlik Duvarı gibi paylaşılan bileşenlere de erişebilir ve Azure DDoS Koruması gibi hizmetleri kullanabilir.

Merkez-uç topolojisi kullandığınızda, eşlenen sanal ağ sayısı üst sınırı gibi sınırların etrafında planlama yaptığınızdan emin olun ve her kiracının sanal ağı için çakışan adres alanları kullanmadığınızdan emin olun.

Hub ve uç topolojisi, seçtiğiniz IP adresleriyle kiracıya özgü sanal ağları dağıttığınızda yararlı olabilir. Her kiracının sanal ağı bir uç haline gelir ve merkez sanal ağındaki ortak kaynaklarınızı paylaşabilir. Ayrıca, paylaşılan kaynakları ölçeklendirme amacıyla birden çok sanal ağ arasında ölçeklendirirken veya Dağıtım Damgaları desenini kullandığınızda merkez-uç topolojisini de kullanabilirsiniz.

İpucu

Çözümünüz birden çok coğrafi bölgede çalışıyorsa, her bölgeye ayrı hub'lar ve hub kaynakları dağıtmak genellikle iyi bir uygulamadır. Bu uygulama daha yüksek bir kaynak maliyetine neden olsa da, birden çok Azure bölgesinden gereksiz yere giden trafiği önler ve bu da isteklerin gecikme süresini artırabilir ve genel eşleme ücretlerine neden olabilir.

Statik IP adresleri

Kiracılarınızın gelen trafik, giden trafik veya her ikisi için statik genel IP adreslerini kullanmak için hizmetinize ihtiyacı olup olmadığını göz önünde bulundurun. Farklı Azure hizmetleri, statik IP adreslerini farklı şekillerde etkinleştirir.

Sanal makinelerle ve diğer altyapı bileşenleriyle çalışırken, hem gelen hem de giden statik IP adresleme için yük dengeleyici veya güvenlik duvarı kullanmayı göz önünde bulundurun. Giden trafiğin IP adresini denetlemek için NAT Gateway kullanmayı göz önünde bulundurun. Nat Gateway'i çok kiracılı bir çözümde kullanma hakkında daha fazla bilgi için bkz . Çok kiracılılık için Azure NAT Gateway ile ilgili dikkat edilmesi gerekenler.

Platform hizmetleriyle çalışırken, kullandığınız belirli hizmet IP adreslerini denetleyip denetleyemeyeceğinizi ve nasıl denetleyebileceğinizi belirler. Kaynağı, örneğin bir sanal ağa dağıtarak ve NAT Ağ Geçidi veya güvenlik duvarı kullanarak belirli bir şekilde yapılandırmanız gerekebilir. Alternatif olarak, hizmetin giden trafik için kullandığı geçerli IP adresi kümesini de isteyebilirsiniz. Örneğin App Service, uygulamanız için geçerli giden IP adreslerini almak için bir API ve web arabirimi sağlar.

Aracılar

Kiracılarınızın çözümünüz tarafından başlatılan iletileri almasını etkinleştirmeniz gerekiyorsa veya kiracıların kendi ağlarında bulunan verilere erişmeniz gerekiyorsa, ağlarında dağıtabilecekleri bir aracı (bazen şirket içi ağ geçidi olarak da adlandırılır) sağlamayı göz önünde bulundurun. Bu yaklaşım, kiracılarınızın ağlarının Azure'da, başka bir bulut sağlayıcısında veya şirket içinde olmasına bakılmaksızın çalışabilir.

Aracı, belirttiğiniz ve denetlediğiniz bir uç noktaya giden bağlantı başlatır ve uzun süre çalışan bağlantıları etkin tutar veya aralıklı olarak yoklar. Aracınızdan hizmetinize bağlantı kurmak ve yönetmek için Azure Relay'i kullanmayı göz önünde bulundurun. Aracı bağlantıyı kurduğunda, kimliğini doğrular ve hizmetinizin bağlantıyı doğru kiracıyla eşleyebilmesi için kiracı tanımlayıcısı hakkında bazı bilgiler içerir.

Aracılar genellikle kiracılarınız için güvenlik yapılandırmasını basitleştirir. Özellikle şirket içi ortamda gelen bağlantı noktalarını açmak karmaşık ve riskli olabilir. Bir aracı, kiracıların bu riski alması gereğini önler.

Kiracıların ağlarına bağlantı için aracı sağlayan Microsoft hizmetleri örnekleri şunlardır:

Azure Özel Bağlantı hizmeti, kiracının Azure ortamından çözümünüzle özel bağlantı sağlar. Kiracılar, hizmetinize şirket içi ortamdan erişmek için Özel Bağlantı hizmetini kendi sanal ağlarıyla da kullanabilir. Azure, özel IP adreslerini kullanarak trafiği hizmete güvenli bir şekilde yönlendirir.

Özel Bağlantı ve çok kiracılılık hakkında daha fazla bilgi için bkz. Çok kiracılılık ve Azure Özel Bağlantı.

Etki alanı adları, alt etki alanları ve TLS

Çok kiracılı bir çözümde etki alanı adları ve aktarım katmanı güvenliği (TLS) ile çalışırken dikkat edilmesi gereken bazı noktalar vardır. Çok kiracılı ve etki alanı adları için dikkat edilmesi gerekenleri gözden geçirin.

Ağ Geçidi Yönlendirme ve Ağ Geçidi Boşaltma desenleri

Ağ Geçidi Yönlendirme düzeni ve Ağ Geçidi Boşaltma düzeni, katman 7 ters ara sunucu veya ağ geçidi dağıtmayı içerir. Ağ geçitleri, aşağıdaki özellikler de dahil olmak üzere çok kiracılı bir uygulama için temel hizmetler sağlamak için kullanışlıdır:

  • İstekleri kiracıya özgü arka uçlara veya dağıtım damgalarına yönlendirme.
  • Kiracıya özgü etki alanı adlarını ve TLS sertifikalarını işleme.
  • Web uygulaması güvenlik duvarı (WAF) kullanarak güvenlik tehditlerine yönelik istekleri inceleme.
  • Performansı geliştirmek için yanıtları Önbelleğe Alma.

Azure, Azure Front Door, Azure Uygulaması lication Gateway ve Azure API Management gibi bu hedeflerin bazılarını veya tümünü gerçekleştirmek için kullanılabilecek çeşitli hizmetler sunar. Ayrıca NGINX veya HAProxy gibi yazılımları kullanarak kendi özel çözümünüzü dağıtabilirsiniz.

Çözümünüz için bir ağ geçidi dağıtmayı planlıyorsanız, önce ihtiyacınız olan tüm özellikleri içeren eksiksiz bir prototip oluşturmak ve uygulama bileşenlerinizin beklediğiniz gibi çalışmaya devam ettiğini doğrulamak iyi bir uygulamadır. Ayrıca ağ geçidi bileşeninin trafiğinizi ve kiracı büyümenizi destekleyecek şekilde nasıl ölçeklendirileceğini de anlamanız gerekir.

Statik İçerik Barındırma düzeni

Statik İçerik Barındırma düzeni, web içeriğini buluta özel depolama hizmetinden sunma ve içeriği önbelleğe almak için bir içerik teslim ağı (CDN) kullanmayı içerir.

Çözümünüzün tek sayfalı JavaScript uygulamaları gibi statik bileşenleri ve görüntü dosyaları ve belgeler gibi statik içerik için Azure Front Door veya başka bir CDN kullanabilirsiniz.

Çözümünüzün nasıl tasarlandığına bağlı olarak, kiracıya özgü dosyaları veya JSON biçimli API yanıtları gibi cdn içindeki verileri de önbelleğe alabilirsiniz. Bu uygulama çözümünüzün performansını ve ölçeklenebilirliğini artırmanıza yardımcı olabilir, ancak kiracıya özgü verilerin kiracılar arasında veri sızıntısını önlemek için yeterince yalıtılmış olup olmadığını göz önünde bulundurmanız önemlidir. Verilerin güncelleştirilmesi veya yeni bir uygulama sürümünün dağıtılması gibi kiracıya özgü içeriği önbelleğinizden nasıl temizlemeyi planladığınızı düşünün. URL yoluna kiracı tanımlayıcısını ekleyerek, belirli bir dosyayı mı, belirli bir kiracıyla ilişkili tüm dosyaları mı yoksa tüm kiracıların tüm dosyalarını mı temizleyebileceğinizi denetleyebilirsiniz.

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

Sanal ağ bağlantısı planlanamaması

Kaynakları sanal ağlara dağıtarak, trafiğin çözümünüzün bileşenleri üzerinden nasıl aktığı üzerinde çok fazla denetime sahip olursunuz. Ancak sanal ağ tümleştirmesi ayrıca dikkate almanız gereken ek karmaşıklık, maliyet ve diğer faktörleri de ortaya ekler. Bu etki özellikle hizmet olarak platform (PaaS) bileşenlerinde geçerlidir.

Ağ stratejinizi bir üretim ortamında uygulamadan önce ortaya çıkarmanız için test etmek ve planlamak önemlidir.

Sınırlar için planlama yapılmaz

Azure, ağ kaynaklarını etkileyen bir dizi sınır uygular. Bu sınırlar Azure kaynak sınırlarını, temel protokol ve platform sınırlarını içerir. Örneğin, Azure Uygulaması Hizmeti ve Azure İşlevleri gibi platform hizmetlerinde yüksek ölçekli çok kiracılı bir çözüm oluşturduğunuzda, TCP bağlantılarının ve SNAT bağlantı noktalarının sayısını göz önünde bulundurmanız gerekebilir. Sanal makineler ve yük dengeleyicilerle çalışırken, giden kuralları ve SNAT bağlantı noktalarıyla ilgili sınırlamaları da göz önünde bulundurmanız gerekir.

Küçük alt ağlar

Özellikle ölçeklendirdikçe dağıtacağınız kaynak veya kaynak örneklerinin sayısına izin vermek için her alt ağın boyutunu göz önünde bulundurmanız önemlidir. Hizmet olarak platform (PaaS) kaynaklarıyla çalışırken, kaynağınızın yapılandırmasının ve ölçeğinin alt ağından gereken IP adresi sayısını nasıl etkileyeceğini anladığınızdan emin olun.

Yanlış ağ segmentasyonu

Çözümünüz sanal ağlar gerektiriyorsa, gelen ve giden (kuzey-güney) trafik akışlarını ve çözümünüz içindeki akışları (doğu-batı) denetlemenizi sağlamak için ağ segmentasyonunu nasıl yapılandıracağınızı düşünün. Kiracıların kendi sanal ağlarına sahip olup olmadığına veya paylaşılan kaynakları paylaşılan sanal ağlara dağıtıp dağıtmayacağınıza karar verin. Yaklaşımı değiştirmek zor olabilir, bu nedenle tüm gereksinimlerinizi dikkate alıp gelecekteki büyüme hedeflerinize uygun bir yaklaşım seçtiğinizden emin olun.

Yalnızca ağ katmanı güvenlik denetimlerini kullanma

Modern çözümlerde, ağ katmanı güvenliğini diğer güvenlik denetimleriyle birleştirmek önemlidir ve yalnızca güvenlik duvarlarına veya ağ segmentasyonuna güvenmemelisiniz. Buna bazen sıfır güven ağı adı verilir. Çözümünüzün her katmanında istemciyi, çağıranı veya kullanıcıyı doğrulamak için kimlik tabanlı denetimleri kullanın. Ek koruma katmanları eklemenize olanak tanıyan hizmetleri kullanmayı göz önünde bulundurun. Kullanabileceğiniz seçenekler, kullandığınız Azure hizmetlerine bağlıdır. AKS'de karşılıklı TLS kimlik doğrulaması için bir hizmet ağı ve doğu-batı trafiğini denetlemek için ağ ilkeleri kullanmayı göz önünde bulundurun. App Service'te, kimlik doğrulaması, yetkilendirme ve erişim kısıtlamaları için yerleşik desteği kullanmayı göz önünde bulundurun.

Test etmeden ana bilgisayar üst bilgilerini yeniden yazma

Ağ Geçidi Boşaltma düzenini kullandığınızda, HTTP isteklerinin Host üst bilgisini yeniden yazmayı düşünebilirsiniz. Bu uygulama, özel etki alanını ve TLS yönetimini ağ geçidine boşaltarak arka uç web uygulaması hizmetinizin yapılandırmasını basitleştirebilir.

Ancak, Host üst bilgi yeniden yazmaları bazı arka uç hizmetlerinde sorunlara neden olabilir. Uygulamanız HTTP yeniden yönlendirmeleri veya tanımlama bilgileri verirse, konak adlarındaki uyuşmazlık uygulamanın işlevselliğini bozabilir. Bu sorun özellikle Azure Uygulaması Hizmeti, Azure İşlevleri ve Azure Spring Apps gibi çok kiracılı arka uç hizmetlerini kullandığınızda ortaya çıkabilir. Daha fazla bilgi için bkz . Konak adı koruma en iyi uygulaması.

Kullanmayı planladığınız ağ geçidi yapılandırmasıyla uygulamanızın davranışını test ettiğinizden emin olun.

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ş Müşteri Mühendisi, Azure için FastTrack

Diğer katkıda bulunanlar:

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

Sonraki adımlar