Geograficky distribuované škálování v prostředí App Service Environments

Přehled

Scénáře aplikací, které vyžadují velmi vysoké škálování, můžou překročit kapacitu výpočetních prostředků dostupnou pro jedno nasazení aplikace. Hlasovací aplikace, sportovní akce a televizní zábavní akce jsou příklady scénářů, které vyžadují extrémně vysoký rozsah. Vysoké požadavky na škálování je možné splnit horizontálním horizontálním navýšením kapacity aplikací. Pro zvládnutí extrémních požadavků na zatížení je možné provést mnoho nasazení aplikací v rámci jedné oblasti a napříč oblastmi.

App Service Prostředí jsou ideální platformou pro horizontální škálování na více instancí. Po výběru konfigurace App Service Environment, která podporuje známou rychlost požadavků, můžou vývojáři nasadit další prostředí App Service způsobem řezačky souborů cookie, aby dosáhli požadované kapacity zatížení ve špičce.

Předpokládejme například, že aplikace spuštěná v konfiguraci App Service Environment byla testována pro zpracování 20 tisíc požadavků za sekundu (RPS). Pokud je požadovaná kapacita zatížení ve špičce 100 tisíc RPS, je možné vytvořit a nakonfigurovat pět (5) App Service prostředí, aby se zajistilo, že aplikace zvládne maximální předpokládané zatížení.

Vzhledem k tomu, že zákazníci obvykle přistupují k aplikacím pomocí vlastní (nebo ješitné) domény, potřebují vývojáři způsob, jak distribuovat žádosti o aplikace napříč všemi App Service Environment instancemi. Skvělým způsobem, jak tohoto cíle dosáhnout, je přeložit vlastní doménu pomocí profilu Azure Traffic Manageru. Profil Traffic Manageru je možné nakonfigurovat tak, aby ukazoval na všechna jednotlivá App Service prostředí. Traffic Manager bude automaticky zpracovávat distribuci zákazníků do všech App Service prostředí na základě nastavení vyrovnávání zatížení v profilu Traffic Manageru. Tento přístup funguje bez ohledu na to, jestli jsou všechna prostředí App Service nasazená v jedné oblasti Azure nebo nasazená po celém světě napříč několika oblastmi Azure.

Navíc vzhledem k tomu, že zákazníci přistupují k aplikacím prostřednictvím domény ješitnosti, zákazníci si nejsou vědomi počtu prostředí App Service, na kterých běží aplikace. V důsledku toho můžou vývojáři rychle a snadno přidávat a odebírat App Service prostředí na základě zjištěného zatížení provozu.

Následující koncepční diagram znázorňuje aplikaci horizontálně škálovanou napříč třemi App Service prostředími v rámci jedné oblasti.

Zbývající část tohoto tématu vás provede postupem nastavení distribuované topologie pro ukázkovou aplikaci pomocí více prostředí App Service.

Plánování topologie

Než vytvoříte distribuovanou aplikaci, pomůže vám mít předem několik informací.

• Vlastní doména aplikace: Jaký je vlastní název domény, který budou zákazníci používat pro přístup k aplikaci? Pro ukázkovou aplikaci je www.asabuludemo.comvlastní název domény .
• Doména Traffic Manageru: Při vytváření profilu Azure Traffic Manageru zvolte název domény. Tento název se zkombinuje s příponou trafficmanager.net , aby se zaregistrovala položka domény spravovaná službou Traffic Manager. Pro ukázkovou aplikaci je zvolený název scalable-ase-demo. V důsledku toho se scalable-ase-demo.trafficmanager.net úplný název domény spravovaný službou Traffic Manager.
• Strategie škálování využití aplikace: Budou se nároky na aplikaci distribuovat do několika App Service prostředí v jedné oblasti? Více oblastí? Kombinace obou přístupů? Založte rozhodnutí na očekávání, odkud bude provoz zákazníků pocházet a jak dobře se zbytek podpůrné back-endové infrastruktury aplikace může škálovat. Například se 100% bezstavovou aplikací je možné aplikaci masivně škálovat pomocí kombinace mnoha App Service prostředí v každé oblasti Azure vynásobené App Service Prostředími nasazenými v mnoha oblastech Azure. S více než 15 globálními oblastmi Azure, ze kterých si mohou vybírat, můžou zákazníci skutečně vytvářet celosvětové využití aplikací v hyperškálovém měřítku. Pro ukázkovou aplikaci, která se používá v tomto článku, se v jedné oblasti Azure (USA – středojiž) vytvořila tři prostředí App Service.
• Zásady vytváření názvů pro prostředí App Service: Každý App Service Environment vyžaduje jedinečný název. Kromě jednoho nebo dvou App Service prostředí je užitečné mít zásady vytváření názvů, které vám pomůžou identifikovat jednotlivé App Service Environment. Pro ukázkovou aplikaci se použila jednoduchá konvence vytváření názvů. Názvy tří prostředí App Service jsou fe1ase, fe2ase a fe3ase.
• Zásady vytváření názvů aplikací: Vzhledem k tomu, že se nasadí více instancí aplikace, je pro každou instanci nasazené aplikace potřeba název. Jednou z málo známých, ale pohodlných funkcí prostředí App Service je, že stejný název aplikace je možné použít ve více prostředích App Service. Vzhledem k tomu, že každý App Service Environment má jedinečnou příponu domény, můžou se vývojáři rozhodnout, že budou v každém prostředí opakovaně používat stejný název aplikace. Vývojář může mít například aplikace pojmenované takto: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net atd. Pro ukázkovou aplikaci má ale každá instance aplikace také jedinečný název. Použité názvy instancí aplikace jsou webfrontend1, webfrontend2 a webfrontend3.

Nastavení profilu Traffic Manageru

Po nasazení více instancí aplikace ve více prostředích App Service je možné jednotlivé instance aplikací zaregistrovat ve službě Traffic Manager. Pro ukázkovou aplikaci je potřeba profil Traffic Manageru pro scalable-ase-demo.trafficmanager.net , který může směrovat zákazníky na některou z následujících nasazených instancí aplikací:

• webfrontend1.fe1ase.p.azurewebsites.net: Instance ukázkové aplikace nasazené na první App Service Environment.
• webfrontend2.fe2ase.p.azurewebsites.net: Instance ukázkové aplikace nasazené na druhé App Service Environment.
• webfrontend3.fe3ase.p.azurewebsites.net: Instance ukázkové aplikace nasazené na třetí App Service Environment.

Nejjednodušší způsob registrace více koncových bodů Azure App Service, které jsou spuštěné ve stejné oblasti Azure, je podpora Azure Resource Manager Traffic Manageru v PowerShellu.

Prvním krokem je vytvoření profilu Azure Traffic Manageru. Následující kód ukazuje, jak se profil pro ukázkovou aplikaci vytvořil:

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

Všimněte si, že byl parametr RelativeDnsName nastavený na scalable-ase-demo. Tento parametr způsobí, že se vytvoří název domény scalable-ase-demo.trafficmanager.net a přidružuje se k profilu Traffic Manageru.

Parametr TrafficRoutingMethod definuje zásadu vyrovnávání zatížení, pomocí které Traffic Manager určí, jak rozložit zatížení zákazníka na všechny dostupné koncové body. V tomto příkladu byla zvolena metoda Weighted . Z důvodu této volby se žádosti zákazníků rozdělí do všech registrovaných koncových bodů aplikace na základě relativních vah přidružených k jednotlivým koncovým bodům.

Po vytvoření profilu se každá instance aplikace přidá do profilu jako nativní koncový bod Azure. Následující kód načte odkaz na každou front-endovou webovou aplikaci. Každou aplikaci pak přidá jako koncový bod Traffic Manageru prostřednictvím parametru 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

Všimněte si, že pro každou instanci aplikace existuje jedno volání Add-AzureTrafficManagerEndpointConfig . Parametr TargetResourceId v každém příkazu PowerShellu odkazuje na jednu ze tří nasazených instancí aplikace. Profil Traffic Manageru rozloží zatížení mezi všechny tři koncové body zaregistrované v profilu.

Všechny tři koncové body používají pro parametr Weight stejnou hodnotu (10). Tato situace má za následek poměrně rovnoměrné rozložení požadavků zákazníků mezi všechny tři instance aplikací.

Nasměrování Custom Domain aplikace na doménu Traffic Manageru

Posledním nezbytným krokem je nasměrovat vlastní doménu aplikace na doménu Traffic Manageru. U ukázkové aplikace přejděte www.asabuludemo.com na scalable-ase-demo.trafficmanager.net. Tento krok dokončete u doménového registrátora, který spravuje vlastní doménu.

Pomocí nástrojů pro správu domén vašeho registrátora je potřeba vytvořit záznam CNAME, který nasměruje vlastní doménu na doménu Traffic Manageru. Následující obrázek ukazuje příklad toho, jak tato konfigurace CNAME vypadá:

I když se toto téma nezabývá, mějte na paměti, že každá jednotlivá instance aplikace musí mít také zaregistrovanou vlastní doménu. V opačném případě, pokud se požadavek dostane do instance aplikace a aplikace nemá zaregistrovanou vlastní doménu v aplikaci, požadavek selže.

V tomto příkladu je www.asabuludemo.comvlastní doména a každá instance aplikace má přidruženou vlastní doménu.

Rekapitulace registrace vlastní domény v aplikacích Azure App Service najdete v tématu registrace vlastních domén.

Vyzkoušení distribuované topologie

Konečným výsledkem konfigurace služby Traffic Manager a DNS je, že požadavky na www.asabuludemo.com budou procházet následující sekvencí:

1. Prohlížeč nebo zařízení provede vyhledávání DNS pro www.asabuludemo.com
2. Položka CNAME u doménového registrátora způsobí přesměrování vyhledávání DNS do Azure Traffic Manageru.
3. Vyhledávání DNS je vytvořené pro scalable-ase-demo.trafficmanager.net na jednom ze serverů DNS Azure Traffic Manageru.
4. Na základě zásad vyrovnávání zatížení zadaných dříve v parametru TrafficRoutingMethod vybere Traffic Manager jeden z nakonfigurovaných koncových bodů. Pak vrátí plně kvalifikovaný název domény tohoto koncového bodu do prohlížeče nebo zařízení.
5. Vzhledem k tomu, že plně kvalifikovaný název domény koncového bodu je adresa URL instance aplikace, která běží na App Service Environment, prohlížeč nebo zařízení požádá server DNS Microsoft Azure o překlad plně kvalifikovaného názvu domény na IP adresu.
6. Prohlížeč nebo zařízení odešle požadavek HTTP/S na IP adresu.
7. Požadavek přijde do jedné z instancí aplikace spuštěných v jednom z App Service prostředí.

Následující obrázek konzoly ukazuje vyhledávání DNS pro vlastní doménu ukázkové aplikace. Úspěšně se přeloží na instanci aplikace, která běží v jednom ze tří ukázkových prostředí App Service (v tomto případě druhé ze tří prostředí App Service):

Další odkazy a informace

Dokumentace k podpoře Azure Resource Manager Traffic Manageru v PowerShellu.