Geodistribuerad skalning med App Service Environment

Översikt

Programscenarier som kräver mycket hög skala kan överskrida beräkningsresurskapaciteten som är tillgänglig för en enskild distribution av en app. Röstningsprogram, sportevenemang och tv-evenemang är exempel på scenarier som kräver mycket hög skala. Krav på hög skalning kan uppfyllas genom att skala ut appar horisontellt. För att hantera extrema belastningskrav kan många appdistributioner göras inom en enda region och mellan regioner.

App Service miljöer är en perfekt plattform för horisontell utskalning. När utvecklare har App Service-miljön en App Service-miljön-konfiguration som har stöd för en känd begärandefrekvens kan de distribuera ytterligare App Service-miljöer med "cookie-skärning" för att uppnå önskad kapacitet för hög belastning.

Anta till exempel att en app som körs på en App Service-miljön-konfiguration har testats för att hantera 20 000 begäranden per sekund (RPS). Om den önskade högsta belastningskapaciteten är 100 000 RPS kan fem (5) App Service-miljöer skapas och konfigureras för att säkerställa att programmet kan hantera den maximala projicerade belastningen.

Eftersom kunder vanligtvis kommer åt appar med hjälp av en anpassad domän (eller anpassad domän) behöver utvecklare ett sätt att distribuera appbegäranden över alla App Service-miljön instanser. Ett bra sätt att uppnå det här målet är att lösa den anpassade domänen med hjälp Azure Traffic Manager profil. Profilen Traffic Manager kan konfigureras så att den pekar på alla enskilda App Service miljöer. Traffic Manager hanterar automatiskt distributionen av kunder över alla App Service-miljöer, baserat på inställningarna för belastningsutjämning i Traffic Manager profilen. Den här metoden fungerar oavsett om alla App Service-miljöer distribueras i en enda Azure-region eller distribueras över hela världen över flera Azure-regioner.

Eftersom kunderna dessutom har åtkomst till appar via domänen är kunderna inte medvetna om hur många App Service miljöer som kör en app. Därför kan utvecklare snabbt och enkelt lägga till och ta bort App Service miljöer baserat på observerad trafikbelastning.

Det konceptuella diagrammet nedan visar en app vågrätt utskalade över tre App Service miljöer inom en enda region.

Resten av det här avsnittet går igenom stegen för att konfigurera en distribuerad topologi för exempelappen med flera App Service miljöer.

Planera topologin

Innan du skapar ett distribuerat appfotavtryck hjälper det att ha lite information i förväg.

• Anpassad domän för appen: Vilket är det anpassade domännamn som kunder använder för att få åtkomst till appen? För exempelappen är det anpassade domännamnet www.asabuludemo.com .
• Traffic Manager domän: Välj ett domännamn när du skapar en Azure Traffic Manager profil. Det här namnet kombineras med suffixet trafficmanager.net för att registrera en domänpost som hanteras av Traffic Manager. För exempelappen är det valda namnet scalable-ase-demo. Det innebär att det fullständiga domännamnet som hanteras av Traffic Manager är scalable-ase-demo.trafficmanager.net.
• Strategi för att skala appens fotavtryck: Kommer programmets fotavtryck att distribueras över App Service miljöer i en enda region? Flera regioner? En blandning av båda metoderna? Basera beslutet på förväntningar på var kundtrafiken kommer ifrån och hur väl resten av en app stöder backend-infrastrukturen kan skalas. Med ett tillståndslöst program på 100 % kan en app till exempel skalas massivt med en kombination av många App Service-miljöer i varje Azure-region, multiplicerat med App Service-miljöer som distribuerats i många Azure-regioner. Med över 15 globala Azure-regioner tillgängliga att välja mellan kan kunderna skapa ett världsomfattande programfotavtryck i hyperskala. För exempelappen som används för den här artikeln skapades tre App Service i en enda Azure-region (USA, södra centrala).
• Namngivningskonvention för App Service miljöer: Varje App Service-miljön kräver ett unikt namn. Utöver en eller två App Service miljöer är det bra att ha en namngivningskonvention som hjälper dig att identifiera varje App Service-miljön. För exempelappen användes en enkel namngivningskonvention. Namnen på de tre App Service miljöerna är fe1ase, fe2ase och fe3ase.
• Namngivningskonvention för apparna: Eftersom flera instanser av appen kommer att distribueras krävs ett namn för varje instans av den distribuerade appen. En lite känd men praktisk funktion i App Service miljöer är att samma appnamn kan användas i flera App Service miljöer. Eftersom varje App Service-miljön har ett unikt domänsuffix kan utvecklare välja att återanvända exakt samma appnamn i varje miljö. En utvecklare kan till exempel ha appar med följande namn: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net osv. För exempelappen har dock varje appinstans också ett unikt namn. Appinstansnamnen som används är webfrontend1, webfrontend2 och webfrontend3.

Konfigurera Traffic Manager profilen

När flera instanser av en app har distribuerats i flera App Service-miljöer kan de enskilda appinstanserna registreras med Traffic Manager. För exempelappen krävs en Traffic Manager profil för scalable-ase-demo.trafficmanager.net kan dirigera kunder till någon av följande distribuerade appinstanser:

• webfrontend1.fe1ase.p.azurewebsites.net: En instans av exempelappen som distribuerats på den första App Service-miljön.
• webfrontend2.fe2ase.p.azurewebsites.net: En instans av exempelappen som distribuerats på den andra App Service-miljön.
• webfrontend3.fe3ase.p.azurewebsites.net: En instans av exempelappen som distribuerats på den tredje App Service-miljön.

Det enklaste sättet att registrera Azure App Service slutpunkter, som körs i samma Azure-region, är med PowerShell-Azure Resource Manager Traffic Manager stöd för.

Det första steget är att skapa en Azure Traffic Manager profil. Koden nedan visar hur profilen skapades för exempelappen:

$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

Observera hur parametern RelativeDnsName har angetts till scalable-ase-demo. Den här parametern gör att scalable-ase-demo.trafficmanager.net skapas och associeras med en Traffic Manager profil.

Parametern TrafficRoutingMethod definierar belastningsutjämningsprincipen som Traffic Manager för att fastställa hur kundernas belastning ska spridas över alla tillgängliga slutpunkter. I det här exemplet valdes metoden Viktad. På grund av det här valet sprids kundbegäranden över alla registrerade programslutpunkter baserat på de relativa vikter som är associerade med varje slutpunkt.

När profilen har skapats läggs varje appinstans till i profilen som en intern Azure-slutpunkt. Följande kod hämtar en referens till varje frontend-webbapp. Den lägger sedan till varje app som Traffic Manager slutpunkt via parametern TargetResourceId.

$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10

$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10

$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10

Set-AzTrafficManagerProfile –TrafficManagerProfile $profile

Observera att det finns ett anrop till Add-AzureTrafficManagerEndpointConfig för varje enskild appinstans. Parametern TargetResourceId i varje PowerShell-kommando refererar till en av de tre distribuerade appinstanserna. Den Traffic Manager profilen sprider belastningen över alla tre slutpunkter som registrerats i profilen.

Alla tre slutpunkterna använder samma värde (10) för parametern Vikt. Den här situationen leder Traffic Manager att kundförfrågningar sprids över alla tre appinstanserna relativt jämnt.

Peka appens Custom Domain på Traffic Manager domänen

Det sista steget är att peka appens anpassade domän på den Traffic Manager domänen. För exempelappen pekar du www.asabuludemo.com på scalable-ase-demo.trafficmanager.net . Slutför det här steget med den domänregistrator som hanterar den anpassade domänen.

Med hjälp av registratorns domänhanteringsverktyg måste en CNAME-post skapas som pekar den anpassade domänen Traffic Manager domänen. Bilden nedan visar ett exempel på hur den här CNAME-konfigurationen ser ut:

Även om det inte tas upp i det här avsnittet bör du komma ihåg att varje enskild appinstans måste ha den anpassade domänen registrerad med den också. Annars misslyckas begäran om en begäran kommer till en appinstans och programmet inte har registrerat den anpassade domänen med appen.

I det här exemplet är den anpassade domänen www.asabuludemo.com , och varje programinstans har den anpassade domän som är associerad med den.

En sammanfattning av hur du registrerar en anpassad domän med Azure App Service-appar finns i Registrera anpassade domäner.

Testa den distribuerade topologin

Slutresultatet av konfigurationen Traffic Manager DNS är att begäranden för www.asabuludemo.com flödar genom följande sekvens:

1. En webbläsare eller enhet gör en DNS-sökning för www.asabuludemo.com
2. CNAME-posten hos domänregistratorn gör att DNS-sökning omdirigeras till Azure Traffic Manager.
3. En DNS-sökning görs för att scalable-ase-demo.trafficmanager.net mot en av de Azure Traffic Manager DNS-servrarna.
4. Baserat på belastningsutjämningsprincipen som angavs tidigare i parametern TrafficRoutingMethod väljer Traffic Manager en av de konfigurerade slutpunkterna. Det returnerar sedan FQDN för slutpunkten till webbläsaren eller enheten.
5. Eftersom FQDN för slutpunkten är webbadressen till en appinstans som körs på en App Service-miljön, kommer webbläsaren eller enheten att be en Microsoft Azure DNS-server att matcha FQDN till en IP-adress.
6. Webbläsaren eller enheten skickar HTTP/S-begäran till IP-adressen.
7. Begäran tas emot vid en av de appinstanser som körs på en av App Service miljöerna.

Konsolbilden nedan visar en DNS-sökning för exempelappens anpassade domän. Den matchas med en appinstans som körs på någon av de tre App Service-miljöerna (i det här fallet den andra av de tre App Service miljöerna):

Ytterligare länkar och information

Dokumentation om PowerShell-Azure Resource Manager Traffic Manager stöd för.