Görev açısından kritik web uygulamaları için genel yönlendirme yedekliliği

Önemli

Görev açısından kritik bir mimari için küresel platform kesintileriyle ilgilenen yedeklilik uygulamalarının tasarlanması karmaşık ve maliyetli olabilir. Bu tasarımda ortaya çıkabilecek olası sorunlar nedeniyle, dengeleri dikkatlice göz önünde bulundurun.

Çoğu durumda, bu makalede açıklanan mimariye ihtiyacınız olmaz.

Görev açısından kritik sistemler, çözümde mümkün olduğunca yedeklilik ve kendi kendini iyileştirme özellikleri oluşturarak tek hata noktalarını en aza indirmeye çalışır. Sistemin herhangi bir birleşik giriş noktası hata noktası olarak kabul edilebilir. Bu bileşende bir kesinti yaşanırsa sistemin tamamı kullanıcıya çevrimdışı olur. Yönlendirme hizmeti seçerken hizmetin güvenilirliğini göz önünde bulundurmak önemlidir.

Görev açısından kritik bir uygulamanın temel mimarisinde Azure Front Door, yüksek çalışma süresi Hizmet düzeyi sözleşmeleri (SLA) ve zengin özellik kümesi nedeniyle seçildi:

• Etkin-etkin modelde trafiği birden çok bölgeye yönlendirme
• TCP anycast kullanarak saydam yük devretme
• Tümleşik içerik teslim ağlarını (CDN) kullanarak uç düğümlerden statik içerik sunma
• Tümleşik web uygulaması güvenlik duvarı ile yetkisiz erişimi engelleme

Front Door, yalnızca dış müşterilerimiz için değil, aynı zamanda Microsoft genelindeki birden çok özellik için de en yüksek dayanıklılık ve kullanılabilirliği sağlamak üzere tasarlanmıştır. Front Door'un özellikleri hakkında daha fazla bilgi için bkz . Azure Front Door ile web uygulamanızı hızlandırma ve güvenliğini sağlama.

Front Door özellikleri çoğu iş gereksinimlerini karşılamak için fazlasıyla yeterlidir, ancak dağıtılmış sistemlerde hata beklenir. İş gereksinimlerinde kesinti olması durumunda daha yüksek bileşik SLO veya sıfır azaltma süresi gerekiyorsa alternatif bir trafik giriş yoluna güvenmeniz gerekir. Ancak, daha yüksek bir SLO arayışı önemli maliyetler, operasyonel ek yük ile birlikte gelir ve genel güvenilirliğinizi düşürebilir. Alternatif yolun kritik yolda bulunan diğer bileşenlerde ortaya çıkabilecek dezavantajları ve olası sorunları dikkatle göz önünde bulundurun. Kullanılabilir olmamanın etkisi önemli olsa bile, karmaşıklık avantajdan daha ağır basabilir.

Bir yaklaşım, alternatif hizmetler içeren ve yalnızca Azure Front Door kullanılamadığında etkin hale gelen ikincil bir yol tanımlamaktır. Front Door ile özellik eşliği zor bir gereksinim olarak değerlendirilmemelidir. Sınırlı bir kapasitede çalışma olasılığına rağmen iş sürekliliği açısından kesinlikle ihtiyacınız olan özelliklerin önceliklerini belirleyin.

Bir diğer yaklaşım da küresel yönlendirme için üçüncü taraf teknolojisi kullanmaktır. Bu yaklaşım, iki veya daha fazla bulut sağlayıcısında barındırılan damgalarla çok bulutlu etkin-etkin dağıtım gerektirir. Azure, diğer bulut platformlarıyla etkili bir şekilde tümleştirilebilir olsa da, farklı bulut platformlarının operasyonel karmaşıklığı nedeniyle bu yaklaşım önerilmez.

Bu makalede, Azure Front Door'un kullanılamadığı durumlarda alternatif yönlendirici olarak Azure Traffic Manager'ı kullanarak genel yönlendirmeye yönelik bazı stratejiler açıklanmaktadır.

Yaklaşım

Bu mimari diyagramında birden çok yedekli trafik yolu içeren genel bir yaklaşım gösterilmektedir.

Bu yaklaşımla, çeşitli bileşenleri tanıtacak ve web uygulamalarınızın teslimiyle ilgili önemli değişiklikler yapacak rehberlik sağlayacağız:

1. Azure Traffic Manager , trafiği Azure Front Door'a veya seçtiğiniz alternatif hizmete yönlendirir.

   Azure Traffic Manager, DNS tabanlı bir genel yük dengeleyicidir. Etki alanınızın CNAME kaydı Traffic Manager'ı işaret eder ve bu, yönlendirme yöntemini nasıl yapılandırdığınıza göre hedefi belirler. Öncelik yönlendirmenin kullanılması, trafiğin varsayılan olarak Azure Front Door üzerinden akmasını sağlar. Azure Front Door kullanılamıyorsa Traffic Manager trafiği otomatik olarak alternatif yolunuzla değiştirebilir.

   Önemli

   Bu çözüm, Azure Front Door kesintileriyle ilişkili riskleri azaltır, ancak genel bir hata noktası olarak Azure Traffic Manager kesintilerine açıktır.

   Genel yük dengeleyici gibi farklı bir genel trafik yönlendirme sistemi de kullanabilirsiniz. Ancak Traffic Manager birçok durumda iyi çalışır.

2. İki giriş yolunuz vardır:

   • Azure Front Door birincil yolu sağlar ve tüm uygulama trafiğinizi işler ve yönlendirir.

   • Azure Front Door için yedek olarak başka bir yönlendirici kullanılır. Trafik yalnızca Front Door kullanılamıyorsa bu ikincil yoldan akar.

   İkincil yönlendirici için seçtiğiniz hizmet birçok faktöre bağlıdır. Azure yerel hizmetlerini veya üçüncü taraf hizmetleri kullanmayı seçebilirsiniz. Bu makalelerde çözüme daha fazla işlem karmaşıklığı eklemekten kaçınmak için Azure'a özel seçenekler sunuyoruz. Üçüncü taraf hizmetleri kullanıyorsanız çözümünüzü yönetmek için birden çok kontrol düzlemi kullanmanız gerekir.

3. Kaynak uygulama sunucularınızın her iki hizmetten gelen trafiği kabul etmeye hazır olması gerekir. Kaynağınıza gelen trafiğin güvenliğini nasıl sağladığınızı ve Front Door ve diğer yukarı akış hizmetlerinin sağladığı sorumlulukları göz önünde bulundurun. Uygulamanızın trafiğinizin aktığı yoldan gelen trafiği işleyebileceğinden emin olun.

Avantajlar ve Dezavantajlar

Bu azaltma stratejisi, uygulamanın platform kesintileri sırasında kullanılabilir olmasını sağlasa da, bazı önemli dengeler vardır. Olası avantajları bilinen maliyetlere göre değerlendirmeli ve avantajların bu maliyetlere değip değmediği konusunda bilinçli bir karar vermelisiniz.

• Finansal maliyet: Uygulamanıza birden fazla yedekli yol dağıttığınızda, kaynakları dağıtma ve çalıştırma maliyetini göz önünde bulundurmanız gerekir. Her biri farklı bir maliyet profiline sahip olan farklı kullanım örnekleri için iki örnek senaryo sunuyoruz.

• operasyonel karmaşıklık: Çözümünüz için her ek bileşen eklediğinizde yönetim ek yükünüzü artırırsınız. Bir bileşende yapılan herhangi bir değişiklik diğer bileşenleri etkileyebilir.

  Azure Front Door'un yeni özelliklerini kullanmaya karar ettiğinizi varsayalım. Alternatif trafik yolunuzun da eşdeğer bir özellik sağlayıp sağlamadığını denetlemeniz ve sağlanmadıysa, iki trafik yolu arasındaki davranış farkının nasıl işleneceğini belirlemeniz gerekir. Gerçek dünyadaki uygulamalarda bu karmaşıklıklar yüksek maliyete sahip olabilir ve sisteminizin kararlılığı için önemli bir risk oluşturabilir.

• Performans: Bu tasarım, ad çözümlemesi sırasında ek CNAME aramaları gerektirir. Çoğu uygulamada bu önemli bir sorun değildir, ancak giriş yolunuz için ek katmanlar ekleyerek uygulama performansınızın etkilenip etkilenmediğini değerlendirmeniz gerekir.

• Fırsat maliyeti: Yedekli giriş yollarının tasarlanması ve uygulanması için önemli bir mühendislik yatırımı gerekir ve bu da geliştirmeyi ve diğer platform geliştirmelerini öne çıkarma fırsatına neden olur.

Uyarı

Karmaşık bir yüksek kullanılabilirlik çözümünü tasarlama ve uygulama konusunda dikkatli değilseniz, kullanılabilirliğinizi daha da kötü hale getirebilirsiniz. Mimarinizdeki bileşen sayısını artırmak hata noktası sayısını artırır. Bu aynı zamanda daha yüksek bir operasyonel karmaşıklık düzeyine sahip olduğunuz anlamına gelir. Ek bileşenler eklediğinizde, yaptığınız her değişikliğin genel çözümünüzü nasıl etkilediğini anlamak için dikkatle gözden geçirilmesi gerekir.

Azure Traffic Manager kullanılabilirliği

Azure Traffic Manager güvenilir bir hizmettir, ancak hizmet düzeyi sözleşmesi %100 kullanılabilirlik garantisi vermez. Traffic Manager kullanılamıyorsa, Azure Front Door ve alternatif hizmetiniz kullanılabilir durumda olsa bile kullanıcılarınız uygulamanıza erişemeyebilir. Çözümünüzün bu koşullar altında nasıl çalışmaya devam edeceğinizi planlamak önemlidir.

Traffic Manager önbelleğe alınabilen DNS yanıtları döndürür. DNS kayıtlarınızda yaşam süresi (TTL) önbelleğe almaya izin veriyorsa Traffic Manager'da kısa süreli kesintiler sorun oluşturmayabilir. Bunun nedeni aşağı akış DNS çözümleyicilerinin önceki bir yanıtı önbelleğe almış olmasıdır. Uzun süreli kesintiler planlamanız gerekir. Traffic Manager kullanılamıyorsa kullanıcıları Azure Front Door'a yönlendirmek için DNS sunucularınızı el ile yeniden yapılandırmayı seçebilirsiniz.

Trafik yönlendirme tutarlılığı

Kullandığınız ve kullandığınız Azure Front Door özelliklerini ve özelliklerini anlamak önemlidir. Alternatif hizmeti seçtiğinizde, ihtiyacınız olan en düşük özelliklere karar verin ve çözümünüz düzeyi düşürülmüş moddayken diğer özellikleri atlayın.

Alternatif bir trafik yolu planlarken göz önünde bulundurmanız gereken bazı önemli sorular şunlardır:

• Azure Front Door'un önbelleğe alma özelliklerini kullanıyor musunuz? Önbelleğe alma kullanılamıyorsa kaynak sunucularınız trafiğinize ayak uydurabilir mi?
• Özel yönlendirme mantığı gerçekleştirmek veya istekleri yeniden yazmak için Azure Front Door kural altyapısını kullanıyor musunuz?
• Uygulamalarınızın güvenliğini sağlamak için Azure Front Door web uygulaması güvenlik duvarını (WAF) kullanıyor musunuz?
• Trafiği IP adresine veya coğrafyaya göre kısıtlar mısınız?
• TLS sertifikalarınızı kim sorunları ve yönetti?
• Azure Front Door üzerinden geldiğinden emin olmak için kaynak uygulama sunucularınıza erişimi nasıl kısıtlarsınız? Özel Bağlantı mi kullanıyorsunuz yoksa hizmet etiketleri ve tanımlayıcı üst bilgileri olan genel IP adreslerine mi güveniyorsunuz?
• Uygulama sunucularınız Azure Front Door dışında herhangi bir yerden gelen trafiği kabul etti mi? Kabul ederlerse hangi protokolleri kabul ederler?
• İstemcileriniz Azure Front Door'un HTTP/2 desteğini kullanıyor mu?

Web uygulaması güvenlik duvarı (WAF)

Uygulamanızı korumak için Azure Front Door'un WAF'sini kullanıyorsanız trafik Azure Front Door'a geçmezse ne olacağını göz önünde bulundurun.

Alternatif yolunuz bir WAF de sağlıyorsa aşağıdaki soruları göz önünde bulundurun:

• Azure Front Door WAF'nizle aynı şekilde yapılandırılabilir mi?
• Hatalı pozitif algılama olasılığını azaltmak için bağımsız olarak ayarlanması ve test edilmesi gerekiyor mu?

Uyarı

Alternatif giriş yolunuz için WAF kullanmamayı seçebilirsiniz. Bu yaklaşım, uygulamanın güvenilirlik hedefini desteklemek için düşünülebilir. Ancak, bu iyi bir uygulama değildir ve bunu önermiyoruz.

İnternet'ten gelen trafiğin herhangi bir denetim olmadan kabul edilmesindeki dengeyi göz önünde bulundurun. Bir saldırgan uygulamanızın korumasız bir ikincil trafik yolunu bulursa, birincil yol waf içerdiğinde bile ikincil yolunuz üzerinden kötü amaçlı trafik gönderebilir.

Uygulama sunucularınıza giden tüm yolların güvenliğini sağlamak en iyisidir.

Etki alanı adları ve DNS

Görev açısından kritik uygulamanız özel bir etki alanı adı kullanmalıdır. Trafiğin uygulamanıza nasıl aktığını denetleyeceksiniz ve tek bir sağlayıcıdaki bağımlılıkları azaltacaksınız.

Azure DNS gibi etki alanı adınız için yüksek kaliteli ve dayanıklı bir DNS hizmeti kullanmak da iyi bir uygulamadır. Etki alanı adınızın DNS sunucuları kullanılamıyorsa, kullanıcılar hizmetinize erişemez.

Genel dayanıklılığı daha da artırmak için birden çok DNS çözümleyicisi kullanmanız önerilir.

CNAME zincirleme

Traffic Manager, Azure Front Door ve diğer hizmetleri birleştiren çözümler, CNAME zincirleme olarak da adlandırılan çok katmanlı bir DNS CNAME çözümleme işlemi kullanır. Örneğin, kendi özel etki alanınızı çözümlediğinizde, bir IP adresi döndürülmeden önce beş veya daha fazla CNAME kaydı görebilirsiniz.

CNAME zincirine ek bağlantılar eklemek DNS ad çözümleme performansını etkileyebilir. Ancak, DNS yanıtları genellikle önbelleğe alınır ve bu da performans etkisini azaltır.

TLS sertifikaları

Görev açısından kritik bir uygulama için Azure Front Door tarafından sağlanan yönetilen sertifikalar yerine kendi TLS sertifikalarınızı sağlamanız ve kullanmanız önerilir. Bu karmaşık mimariyle ilgili olası sorunların sayısını azaltacaksınız.

Bazı avantajlar şunlardır:

• Yönetilen TLS sertifikalarını vermek ve yenilemek için Azure Front Door etki alanı sahipliğini doğrular. Etki alanı doğrulama işlemi, etki alanınızın CNAME kayıtlarının doğrudan Azure Front Door'a işaret ettiğini varsayar. Ancak bu varsayım genellikle doğru değildir. Azure Front Door'da yönetilen TLS sertifikalarını verme ve yenileme sorunsuz çalışmayabilir ve TLS sertifika sorunları nedeniyle kesinti riskini artırabilirsiniz.

• Diğer hizmetleriniz yönetilen TLS sertifikaları sağlasa bile etki alanı sahipliğini doğrulayamayabilir.

• Her hizmet kendi yönetilen TLS sertifikalarını bağımsız olarak alırsa, sorunlar olabilir. Örneğin, kullanıcılar farklı yetkililer tarafından verilen farklı TLS sertifikalarını veya farklı bitiş tarihleri veya parmak izleriyle görmeyi beklemeyebilir.

Ancak, sertifikalarınızın süresi dolmadan önce sertifikalarınızı yenileme ve güncelleştirmeyle ilgili ek işlemler olacaktır.

Kaynak güvenliği

Kaynağınızı yalnızca Azure Front Door üzerinden trafiği kabul etmek üzere yapılandırdığınızda katman 3 ve katman 4 DDoS saldırılarına karşı koruma elde edebilirsiniz. Azure Front Door yalnızca geçerli HTTP trafiğine yanıt verdiği için, birçok protokol tabanlı tehditlere maruz kalmanızı azaltmaya da yardımcı olur. Mimarinizi alternatif giriş yollarına izin verecek şekilde değiştirirseniz, kaynağınızın tehditlere maruz kalmasını yanlışlıkla artırıp artırmadığınıza karar vermeniz gerekir.

Azure Front Door'dan kaynak sunucunuza bağlanmak için Özel Bağlantı kullanıyorsanız trafik alternatif yolunuz üzerinden nasıl akar? Çıkış noktalarınıza erişmek için özel IP adresleri kullanabilir misiniz yoksa genel IP adresleri mi kullanmanız gerekir?

Kaynağınız, trafiğin Azure Front Door'a aktığını doğrulamak için Azure Front Door hizmet etiketini ve X-Azure-FDID üst bilgisini kullanıyorsa trafiğin geçerli yollarınızdan herhangi birinden aktığını doğrulamak için kaynaklarınızın nasıl yeniden yapılandırılabildiğini göz önünde bulundurun. Diğer müşterilerin Azure Front Door profillerinden gelenler de dahil olmak üzere diğer yollardan gelen trafiğe çıkış noktasınızı yanlışlıkla açmadığınızdan emin olmanız gerekir.

Kaynak güvenliğinizi planlarken, alternatif trafik yolunun ayrılmış genel IP adresleri sağlamaya bağlı olup olmadığını denetleyin. Yedekleme yolunu çevrimiçi yapmak için el ile tetiklenen bir işlem gerekebilir.

Ayrılmış genel IP adresleri varsa, kaynaklarınıza yönelik hizmet reddi saldırıları riskini azaltmak için Azure DDoS Koruması uygulamanız gerekip gerekmediğini göz önünde bulundurun. Ayrıca, Azure Güvenlik Duvarı veya sizi çeşitli ağ tehditlerine karşı koruyabilen başka bir güvenlik duvarı uygulamanız gerekip gerekmediğini de göz önünde bulundurun. Ayrıca daha fazla izinsiz giriş algılama stratejisine de ihtiyacınız olabilir. Bu denetimler daha karmaşık bir çok mimaride önemli öğeler olabilir.

Sistem durumu modelleme

Görev açısından kritik tasarım metodolojisi, çözümü ve bileşenlerini genel olarak gözlemlemenizi sağlayan bir sistem durumu modeli gerektirir. Birden çok trafik giriş yolu kullandığınızda, her yolun sistem durumunu izlemeniz gerekir. Trafiğiniz ikincil giriş yoluna yeniden yönlendiriliyorsa sistem durumu modeliniz sistemin hala çalışır durumda olduğu ancak düzeyi düşürülmüş durumda olduğu gerçeğini yansıtmalıdır.

Sistem durumu modeli tasarımınıza şu soruları ekleyin:

• Çözümünüzün farklı bileşenleri aşağı akış bileşenlerinin durumunu nasıl izler?
• Sistem durumu izleyicileri aşağı akış bileşenlerinin ne zaman iyi durumda olmadığını dikkate almalıdır?
• Kesintinin algılanması ne kadar sürer?
• Bir kesinti algılandıktan sonra trafiğin alternatif bir yoldan yönlendirilmesi ne kadar sürer?

Azure Front Door'un durumunu izlemenizi ve bir kesinti oluşursa yedekleme platformuna otomatik yük devretme tetiklemenizi sağlayan birden çok genel yük dengeleme çözümü vardır. Azure Traffic Manager çoğu durumda uygundur. Traffic Manager ile, hangi URL'nin denetleneceğini, bu URL'nin ne sıklıkta denetleneceğini ve yoklama yanıtlarına göre aşağı akış hizmetinin ne zaman iyi durumda olmadığını belirleyerek aşağı akış hizmetlerini izlemek için uç nokta izlemeyi yapılandırırsınız. Genel olarak, denetimler arasındaki aralık ne kadar kısa olursa Traffic Manager'ın trafiği kaynak sunucunuza ulaşmak için alternatif bir yol üzerinden yönlendirmesi o kadar kısa sürer.

Front Door kullanılamıyorsa, kesintinin trafiğinizi etkilediği süreyi birden çok faktör etkiler, örneğin:

• DNS kayıtlarınızda yaşam süresi (TTL).
• Traffic Manager'ın sistem durumu denetimlerini çalıştırma sıklığı.
• Traffic Manager'ın trafiği yeniden yönlendirmeden önce görecek şekilde yapılandırıldığı başarısız yoklama sayısı.
• İstemcilerin ve yukarı akış DNS sunucularının Traffic Manager'ın DNS yanıtlarını önbelleğe alma süresi.

Ayrıca bu faktörlerden hangilerinin denetiminizde olduğunu ve denetiminizin dışındaki yukarı akış hizmetlerinin kullanıcı deneyimini etkileyip etkilemeyebileceğini belirlemeniz gerekir. Örneğin, DNS kayıtlarınızda düşük TTL kullansanız bile, yukarı akış DNS önbellekleri gerekenden daha uzun süre eski yanıtlara hizmet edebilir. Bu davranış, Traffic Manager alternatif trafik yoluna istek göndermeye geçiş yapmış olsa bile kesintinin etkilerini daha da büyütebilir veya uygulamanız kullanılamıyor gibi görünebilir.

İpucu

Görev açısından kritik çözümler, mümkün olan her yerde otomatik yük devretme yaklaşımları gerektirir. Uygulamanın yanıt vermeye devam edebilmesi için el ile yük devretme işlemleri yavaş kabul edilir.

Bkz. Görev açısından kritik tasarım alanı: Sistem durumu modelleme

Sıfır kapalı kalma süresi dağıtımı

Bir çözümün yedekli giriş yolu ile nasıl çalıştırılacağı planlandığında, hizmetlerinizin düzeyi düşürülmüş olduğunda nasıl dağıtılacağı veya yapılandırılacağı da planlanmalıdır. Çoğu Azure hizmeti için SLA'lar, yönetim işlemlerine veya dağıtımlarına değil hizmetin çalışma süresine uygulanır. Dağıtım ve yapılandırma işlemlerinizin hizmet kesintilerine dayanıklı hale getirilip getirilmeyeceğini göz önünde bulundurun.

Çözümünüzü yönetmek için etkileşim kurmanız gereken bağımsız kontrol düzlemlerinin sayısını da göz önünde bulundurmalısınız. Azure hizmetlerini kullandığınızda, Azure Resource Manager birleşik ve tutarlı bir denetim düzlemi sağlar. Ancak trafiği yönlendirmek için üçüncü taraf bir hizmet kullanıyorsanız, hizmeti yapılandırmak için ayrı bir denetim düzlemi kullanmanız gerekebilir ve bu da daha fazla işlem karmaşıklığı getirir.

Uyarı

Birden çok kontrol düzleminin kullanılması, çözümünüz için karmaşıklık ve risk oluşturur. Her fark noktası, birinin bir yapılandırma ayarını yanlışlıkla kaçırma veya yedekli bileşenlere farklı yapılandırmalar uygulama olasılığını artırır. operasyonel yordamlarınızın bu riski azaltmasını sağlayın.

Bkz. Görev açısından kritik tasarım alanı: Sıfır kapalı kalma süresi dağıtımı

Sürekli doğrulama

Görev açısından kritik bir çözüm için test uygulamalarınız, uygulama trafiğinizin geçtiği yoldan bağımsız olarak çözümünüzün gereksinimlerinizi karşıladığını doğrulamalıdır. Çözümün her bölümünü ve her kesinti türü için nasıl test ettiğinizi düşünün.

Test süreçlerinizin şu öğeleri içerdiğine emin olun:

• Birincil yol kullanılamadığında trafiğin alternatif yol üzerinden doğru yönlendirildiğini doğrulayabilir misiniz?
• Her iki yol da almayı beklediğiniz üretim trafiği düzeyini destekleyebilir mi?
• Düzeyi düşürülmüş durumdayken güvenlik açıklarının açılmasını veya açığa çıkarılmasını önlemek için her iki yol da yeterince güvenli mi?

Bkz. Görev açısından kritik tasarım alanı: Sürekli doğrulama

Genel senaryolar

Bu tasarımın kullanabildiği yaygın senaryolar şunlardır:

• Genel içerik teslimi genellikle statik içerik teslimi, medya ve yüksek ölçekli e-ticaret uygulamaları için geçerlidir. Bu senaryoda önbelleğe alma, çözüm mimarisinin kritik bir parçasıdır ve önbelleğe alma hataları performansın veya güvenilirliğin önemli ölçüde düşmesine neden olabilir.

• Genel HTTP girişi genellikle görev açısından kritik dinamik uygulamalar ve API'ler için geçerlidir. Bu senaryoda temel gereksinim, trafiği kaynak sunucuya güvenilir ve verimli bir şekilde yönlendirmektir. WaF genellikle bu çözümlerde kullanılan önemli bir güvenlik denetimidir.

Uyarı

Karmaşık bir çoklu giriş çözümünü tasarlama ve uygulama konusunda dikkatli değilseniz, kullanılabilirliğinizi daha da kötü hale getirebilirsiniz. Mimarinizdeki bileşen sayısını artırmak hata noktası sayısını artırır. Bu aynı zamanda daha yüksek bir operasyonel karmaşıklık düzeyine sahip olduğunuz anlamına gelir. Ek bileşenler eklediğinizde, yaptığınız her değişikliğin genel çözümünüzü nasıl etkilediğini anlamak için dikkatle gözden geçirilmesi gerekir.

Sonraki adımlar

Çözümünüz için geçerli olup olmadığını anlamak için genel HTTP girişi ve genel içerik teslim senaryolarını gözden geçirin.