Földrajzi alapú méretezés App Service-környezetekkel

  • Cikk

Áttekintés

A nagy léptékű alkalmazásforgatókönyvek meghaladhatják az alkalmazások egyetlen üzembe helyezéséhez rendelkezésre álló számítási erőforrás-kapacitást. A szavazóalkalmazások, a sportesemények és a televíziós szórakoztató események mind olyan forgatókönyvek, amelyek rendkívül nagy léptéket igényelnek. A nagy léptékű követelmények az alkalmazások horizontális felskálázásával teljesíthetők. A szélsőséges terhelési követelmények kezeléséhez számos alkalmazástelepítés végezhető egyetlen régión belül és régiók között.

App Service Környezetek ideális platform a horizontális horizontális felskálázáshoz. Miután kiválasztott egy olyan App Service Environment konfigurációt, amely támogatja az ismert kérelmek arányát, a fejlesztők további App Service-környezeteket helyezhetnek üzembe "cookie-vágó" módon a kívánt maximális terhelési kapacitás eléréséhez.

Tegyük fel például, hogy egy App Service Environment konfiguráción futó alkalmazást teszteltek a másodpercenkénti 20 000 kérelem (RPS) kezelésére. Ha a kívánt maximális terhelési kapacitás 100 000 RPS, öt (5) App Service környezet hozható létre és konfigurálható, hogy az alkalmazás képes legyen kezelni a maximálisan tervezett terhelést.

Mivel az ügyfelek általában egyéni (vagy hiúsági) tartomány használatával férnek hozzá az alkalmazásokhoz, a fejlesztőknek módot kell adni az alkalmazáskérések terjesztésére az összes App Service Environment példányban. Ennek a célnak az egyik nagyszerű módja, ha egy Azure Traffic Manager-profillal oldja fel az egyéni tartományt. A Traffic Manager-profil úgy konfigurálható, hogy az egyes App Service környezetekre mutasson. A Traffic Manager automatikusan kezeli az ügyfelek elosztását az összes App Service környezetben a Traffic Manager-profil terheléselosztási beállításai alapján. Ez a megközelítés attól függetlenül működik, hogy az összes App Service környezet egyetlen Azure-régióban van üzembe helyezve, vagy világszerte több Azure-régióban van üzembe helyezve.

Emellett mivel az ügyfelek a hiúság tartományon keresztül férnek hozzá az alkalmazásokhoz, az ügyfelek nem ismerik az alkalmazást futtató App Service környezetek számát. Ennek eredményeképpen a fejlesztők gyorsan és egyszerűen adhatnak hozzá és távolíthatnak el App Service környezeteket a megfigyelt forgalomterhelés alapján.

Az alábbi fogalmi diagram egy alkalmazást ábrázol vízszintesen felskálázva három App Service-környezetre egyetlen régión belül.

A georedundáns alkalmazásszolgáltatás fogalmi architektúradiagramja a Traffic Managerrel.

A témakör hátralévő része végigvezeti a mintaalkalmazás elosztott topológiájának több App Service-környezetek használatával történő beállításának lépésein.

A topológia megtervezése

Az elosztott alkalmazáslábnyom létrehozása előtt segít, hogy néhány részletre vonatkozó információval rendelkezzen az idő előtt.

  • Az alkalmazás egyéni tartománya: Mi az az egyéni tartománynév, amelyet az ügyfelek használni fognak az alkalmazás eléréséhez? A mintaalkalmazás esetében az egyéni tartománynév a következő www.asabuludemo.com: .
  • Traffic Manager-tartomány: Azure Traffic Manager-profil létrehozásakor válasszon tartománynevet. Ez a név az trafficmanager.net utótaggal lesz kombinálva a Traffic Manager által felügyelt tartománybejegyzés regisztrálásához. A mintaalkalmazás esetében a választott név skálázható-ase-demo. Ennek eredményeként a Traffic Manager által felügyelt teljes tartománynév scalable-ase-demo.trafficmanager.net.
  • Az alkalmazás lábnyomának skálázási stratégiája: Az alkalmazás lábnyoma egyetlen régióban több App Service környezet között lesz elosztva? Több régió? A két megközelítés egyezése? A döntés alapja az, hogy honnan indul az ügyfélforgalom, és hogy egy alkalmazás háttérinfrastruktúrájának többi része milyen mértékben méretezhető. Például egy 100%-ban állapot nélküli alkalmazással az alkalmazások nagymértékben skálázhatók az egyes Azure-régiókban található számos App Service-környezet kombinációjával, megszorozva App Service számos Azure-régióban üzembe helyezett környezetekkel. Ha több mint 15 globális Azure-régió közül választhat, az ügyfelek valóban létrehozhatnak egy globális, hiperméretű alkalmazásigényt. A cikkhez használt mintaalkalmazáshoz három App Service környezet jött létre egyetlen Azure-régióban (USA déli középső régiója).
  • A App Service-környezetek elnevezési konvenciói: Minden App Service Environment egyedi nevet igényel. Egy vagy két App Service környezeten kívül hasznos, ha rendelkezik elnevezési konvencióval az egyes App Service Environment azonosításához. A mintaalkalmazáshoz egy egyszerű elnevezési konvenciót használtunk. A három App Service környezet neve fe1ase, fe2ase és fe3ase.
  • Az alkalmazások elnevezési konvenciója: Mivel az alkalmazás több példánya lesz üzembe helyezve, az üzembe helyezett alkalmazás minden példányához szükség van egy névre. A App Service-környezetek egyik kevéssé ismert, de kényelmes funkciója, hogy ugyanazt az alkalmazásnevet több App Service-környezetben is használhatja. Mivel minden App Service Environment egyedi tartományi utótagot használ, a fejlesztők dönthetnek úgy, hogy minden környezetben pontosan ugyanazt az alkalmazásnevet használják fel. Egy fejlesztő például a következő nevű alkalmazásokkal rendelkezhet: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net stb. A mintaalkalmazás esetében azonban minden alkalmazáspéldánynak egyedi neve is van. A használt alkalmazáspéldányok neve a webfrontend1, a webfrontend2 és a webfrontend3.

A Traffic Manager-profil beállítása

Ha egy alkalmazás több példánya több App Service környezetben van üzembe helyezve, az egyes alkalmazáspéldányok regisztrálhatók a Traffic Managerben. A mintaalkalmazáshoz egy Traffic Manager-profilra van szükség az scalable-ase-demo.trafficmanager.net , amely az ügyfeleket az alábbi üzembe helyezett alkalmazáspéldányok bármelyikére irányíthatja:

  • webfrontend1.fe1ase.p.azurewebsites.net: Az első App Service Environment üzembe helyezett mintaalkalmazás egy példánya.
  • webfrontend2.fe2ase.p.azurewebsites.net: A második App Service Environment üzembe helyezett mintaalkalmazás egy példánya.
  • webfrontend3.fe3ase.p.azurewebsites.net: A harmadik App Service Environment üzembe helyezett mintaalkalmazás egy példánya.

Több Azure App Service végpont regisztrálásának legegyszerűbb módja, ha mind ugyanabban az Azure-régióban fut, a PowerShell Azure Resource Manager Traffic Manager-támogatással.

Az első lépés egy Azure Traffic Manager-profil létrehozása. Az alábbi kód bemutatja, hogyan lett létrehozva a profil a mintaalkalmazáshoz:

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

Figyelje meg, hogy a RelativeDnsName paraméter skálázható-ase-demo értékre lett állítva. Ez a paraméter a tartománynevet scalable-ase-demo.trafficmanager.net hozza létre, és egy Traffic Manager-profilhoz társítja.

A TrafficRoutingMethod paraméter határozza meg a Traffic Manager terheléselosztási szabályzatát, amely meghatározza, hogyan oszthatja el az ügyfelek terhelését az összes elérhető végpont között. Ebben a példában a Súlyozott metódust választottuk. Emiatt az ügyfélkérések az egyes végpontokhoz társított relatív súlyok alapján minden regisztrált alkalmazásvégpontra el lesznek osztva.

A profil létrehozásakor minden alkalmazáspéldány natív Azure-végpontként lesz hozzáadva a profilhoz. Az alábbi kód lekéri az egyes előtér-webalkalmazások hivatkozását. Ezután az egyes alkalmazásokat Traffic Manager-végpontként adja hozzá a TargetResourceId paraméterrel.

$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

Figyelje meg, hogy minden egyes alkalmazáspéldányhoz egyetlen hívás tartozik az Add-AzureTrafficManagerEndpointConfig szolgáltatáshoz. Az egyes PowerShell-parancsok TargetResourceId paramétere a három üzembe helyezett alkalmazáspéldány egyikére hivatkozik. A Traffic Manager-profil a profilban regisztrált mindhárom végpontra elosztja a terhelést.

Mindhárom végpont ugyanazt az értéket (10) használja a Súly paraméterhez. Ez a helyzet azt eredményezi, hogy a Traffic Manager viszonylag egyenletesen terjeszti az ügyfélkéréseket mindhárom alkalmazáspéldányban.

Mutasson az alkalmazás Custom Domain a Traffic Manager-tartományra

Az utolsó szükséges lépés az alkalmazás egyéni tartományának a Traffic Manager-tartományra mutatása. A mintaalkalmazás esetében mutasson a következőre www.asabuludemo.com : scalable-ase-demo.trafficmanager.net. Hajtsa végre ezt a lépést az egyéni tartományt kezelő tartományregisztrálóval.

A regisztráló tartománykezelési eszközeivel létre kell hozni egy CNAME rekordot, amely az egyéni tartományra mutat a Traffic Manager-tartományra. Az alábbi képen egy példa látható arra, hogyan néz ki ez a CNAME-konfiguráció:

Képernyőkép a CNAME rekord DNS-en való konfigurálásáról.

Bár ez a témakör nem foglalkozik vele, ne feledje, hogy minden egyes alkalmazáspéldánynak regisztrálnia kell az egyéni tartományt is. Ellenkező esetben, ha egy kérés egy alkalmazáspéldányra küldi, és az alkalmazás nem regisztrálta az egyéni tartományt az alkalmazással, a kérés sikertelen lesz.

Ebben a példában az egyéni tartomány a , www.asabuludemo.comés minden alkalmazáspéldányhoz hozzá van rendelve az egyéni tartomány.

Képernyőkép App Service egyéni tartománybeállításról.

Az egyéni tartományok Azure App Service alkalmazásokban való regisztrálásáról az egyéni tartományok regisztrálása című témakörben olvashat.

Az elosztott topológia kipróbálása

A Traffic Manager és a DNS-konfiguráció végeredménye, hogy a www.asabuludemo.com kérések a következő sorrendben fognak haladni:

  1. Egy böngésző vagy eszköz DNS-keresést fog végezni a következőhöz: www.asabuludemo.com
  2. A tartományregisztráló CNAME bejegyzése miatt a DNS-keresés átirányításra kerül az Azure Traffic Managerbe.
  3. Dns-keresés készül az egyik Azure Traffic Manager DNS-kiszolgálón scalable-ase-demo.trafficmanager.net .
  4. A TrafficRoutingMethod paraméterben korábban megadott terheléselosztási szabályzat alapján a Traffic Manager kiválasztja az egyik konfigurált végpontot. Ezután visszaadja a végpont teljes tartománynevét a böngészőnek vagy az eszköznek.
  5. Mivel a végpont teljes tartományneve egy App Service Environment futó alkalmazáspéldány URL-címe, a böngésző vagy az eszköz megkéri a Microsoft Azure DNS-kiszolgálót, hogy oldja fel az FQDN-t egy IP-címmel.
  6. A böngésző vagy az eszköz elküldi a HTTP/S kérést az IP-címre.
  7. A kérés az egyik App Service-környezetben futó alkalmazáspéldányhoz érkezik.

Az alábbi konzolképen a mintaalkalmazás egyéni tartományának DNS-keresése látható. Sikeresen feloldható egy olyan alkalmazáspéldányra, amely a App Service-környezetek három mintapéldányának egyikén fut (ebben az esetben a három App Service környezet másodikában):

Képernyőkép a DNS-keresés eredményéről.

A PowerShell Azure Resource Manager Traffic Manager-támogatásának dokumentációja.

Megjegyzés

Ha nem szeretne regisztrálni Azure-fiókot az Azure App Service megismerése előtt, lépjen Az App Service kipróbálása oldalra, ahol azonnal létrehozhat egy rövid élettartamú alapszintű webalkalmazást az App Service-ben. Ehhez nincs szükség bankkártyára, és nem jár kötelezettségekkel.