Geodistribuerad skalning med App Service Environment

  • Artikel

Översikt

Programscenarier som kräver mycket hög skala kan överskrida den beräkningsresurskapacitet som är tillgänglig för en enda distribution av en app. Röstningsprogram, sportevenemang och tv-sända underhållningsevenemang är exempel på scenarier som kräver extremt hög skala. Höga skalningskrav kan uppfyllas genom horisontell skalning av appar. 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 valt 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 på "cookie cutter"-sätt för att uppnå önskad toppbelastningskapacitet.

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 belastningstopparna ä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 planerade belastningen.

Eftersom kunder vanligtvis har åtkomst till appar med hjälp av en anpassad (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 av en Azure Traffic Manager-profil. Traffic Manager-profilen kan konfigureras så att den pekar på alla enskilda App Service miljöer. Traffic Manager hanterar automatiskt distribution av kunder i alla App Service-miljöer, baserat på belastningsutjämningsinställningarna 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 har åtkomst till appar via den anpassade domänen känner kunderna dessutom inte till antalet 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 som skalas ut vågrätt över tre App Service miljöer i en enda region.

Konceptuellt arkitekturdiagram över geo-distribuerad apptjänst med Traffic Manager.

Resten av det här avsnittet beskriver steg för steg hur du konfigurerar en distribuerad topologi för exempelappen med hjälp av 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 kommer att använda för att få åtkomst till appen? För exempelappen är www.asabuludemo.comdet anpassade domännamnet .
  • 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. Därför är det fullständiga domännamnet som hanteras av Traffic Manager scalable-ase-demo.trafficmanager.net.
  • Strategi för skalning av appens fotavtryck: Kommer programmets fotavtryck att distribueras över flera App Service miljöer i en enda region? Flera regioner? En blandning och matchning av båda metoderna? Basera beslutet på förväntningarna om var kundtrafiken kommer att komma och hur väl resten av en apps stödjande backend-infrastruktur kan skalas. Med ett tillståndslöst program på 100 % kan en app till exempel skalas massivt med hjälp av en kombination av många App Service miljöer i varje Azure-region multiplicerat med App Service miljöer som distribueras i många Azure-regioner. Med över 15 globala Azure-regioner att välja mellan kan kunderna verkligen skapa ett globalt fotavtryck för program i hyperskala. För exempelappen som används för den här artikeln skapades tre App Service-miljöer 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 behövs ett namn för varje instans av den distribuerade appen. En föga 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 behövs en Traffic Manager-profil för scalable-ase-demo.trafficmanager.net som kan dirigera kunder till någon av följande distribuerade appinstanser:

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

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

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 ställts in på scalable-ase-demo. Den här parametern gör att domännamnet scalable-ase-demo.trafficmanager.net skapas och associeras med en Traffic Manager-profil.

Parametern TrafficRoutingMethod definierar den belastningsutjämningsprincip som Traffic Manager använder för att fastställa hur kundbelastningen ska spridas över alla tillgängliga slutpunkter. I det här exemplet valdes metoden Weighted (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 klientwebbapp. Sedan läggs varje app till som en 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. Traffic Manager-profilen sprider belastningen över alla tre slutpunkter som är registrerade i profilen.

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

Peka appens Custom Domain på Traffic Manager-domänen

Det sista steget som krävs är att peka appens anpassade domän på 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 domänregistratorn 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 i Traffic Manager-domänen. Bilden nedan visar ett exempel på hur den här CNAME-konfigurationen ser ut:

Skärmbild av konfiguration av CNAME-post i DNS.

Även om det inte beskrivs i det här avsnittet, så kom ihåg att varje enskild appinstans också måste ha den anpassade domänen registrerad med den. Om en begäran skickar den till en appinstans och programmet inte har registrerat den anpassade domänen med appen misslyckas begäran.

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

Skärmbild av inställningen App Service anpassad domän.

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 Traffic Manager- och DNS-konfigurationen ä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 efter www.asabuludemo.com
  2. CNAME-posten hos domänregistratorn gör att DNS-sökningen omdirigeras till Azure Traffic Manager.
  3. En DNS-sökning görs för scalable-ase-demo.trafficmanager.net mot en av Azure Traffic Manager DNS-servrarna.
  4. Baserat på den belastningsutjämningsprincip som angavs tidigare i parametern TrafficRoutingMethod väljer Traffic Manager en av de konfigurerade slutpunkterna. Det returnerar sedan FQDN för den slutpunkten till webbläsaren eller enheten.
  5. Eftersom FQDN för slutpunkten är URL:en för 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 kommer till en av appinstanserna som körs i någon av App Service-miljöerna.

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

Skärmbild av DNS-sökningsresultat.

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

Anteckning

Om du vill komma igång med Azure Apptjänst innan du registrerar dig för ett Azure-konto kan du gå till Prova Apptjänst. Där kan du direkt skapa en tillfällig startwebbapp i Apptjänst. Inget kreditkort krävs, och du gör inga åtaganden.