Geografisch gedistribueerde schaal met App Service-omgevingen

Overzicht

Toepassingsscenario's die een zeer grote schaal vereisen, kunnen de rekenresourcecapaciteit overschrijden die beschikbaar is voor één implementatie van een app. Stemtoepassingen, sportevenementen en entertainment op tv zijn allemaal voorbeelden van scenario's die een extreem hoge schaal vereisen. Aan hoge schaalvereisten kan worden voldaan door apps horizontaal uit te schalen. Voor het afhandelen van vereisten voor extreme belasting kunnen veel app-implementaties worden uitgevoerd binnen één regio en tussen regio's.

App Service omgevingen zijn een ideaal platform voor horizontaal uitschalen. Na het selecteren van een App Service Environment-configuratie die een bekende aanvraagsnelheid kan ondersteunen, kunnen ontwikkelaars extra App Service-omgevingen implementeren op de manier van 'cookie cutter' om een gewenste piekbelastingscapaciteit te bereiken.

Stel dat een app die wordt uitgevoerd op een App Service Environment-configuratie is getest om 20.000 aanvragen per seconde (RPS) af te handelen. Als de gewenste piekbelastingscapaciteit 100.000 RPS is, kunnen vijf (5) App Service omgevingen worden gemaakt en geconfigureerd om ervoor te zorgen dat de toepassing de maximale verwachte belasting kan verwerken.

Omdat klanten doorgaans toegang krijgen tot apps via een aangepast (of vanity)domein, hebben ontwikkelaars een manier nodig om app-aanvragen te distribueren naar alle App Service Environment exemplaren. Een uitstekende manier om dit doel te bereiken, is door het aangepaste domein op te lossen met behulp van een Azure Traffic Manager-profiel. Het Traffic Manager-profiel kan worden geconfigureerd om te verwijzen naar alle afzonderlijke App Service omgevingen. Traffic Manager verwerkt automatisch de distributie van klanten over alle App Service omgevingen, op basis van de taakverdelingsinstellingen in het Traffic Manager-profiel. Deze aanpak werkt ongeacht of alle App Service-omgevingen in één Azure-regio of wereldwijd worden geïmplementeerd in meerdere Azure-regio's.

Bovendien, omdat klanten toegang hebben tot apps via het vanity-domein, zijn klanten zich niet bewust van het aantal App Service-omgevingen waarop een app wordt uitgevoerd. Hierdoor kunnen ontwikkelaars snel en eenvoudig App Service-omgevingen toevoegen en verwijderen op basis van de waargenomen verkeersbelasting.

In het onderstaande conceptuele diagram ziet u een app die horizontaal is uitgeschaald over drie App Service omgevingen binnen één regio.

In de rest van dit onderwerp worden de stappen beschreven voor het instellen van een gedistribueerde topologie voor de voorbeeld-app met behulp van meerdere App Service-omgevingen.

De topologie plannen

Voordat u een gedistribueerde app-footprint opbouwt, is het handig om van tevoren een paar stukjes informatie te hebben.

• Aangepast domein voor de app: Wat is de aangepaste domeinnaam die klanten gebruiken om toegang te krijgen tot de app? Voor de voorbeeld-app is www.asabuludemo.comde aangepaste domeinnaam .
• Traffic Manager-domein: Kies een domeinnaam bij het maken van een Azure Traffic Manager-profiel. Deze naam wordt gecombineerd met het achtervoegsel trafficmanager.net om een domeinvermelding te registreren die wordt beheerd door Traffic Manager. Voor de voorbeeld-app is de gekozen naam scalable-ase-demo. Als gevolg hiervan wordt de volledige domeinnaam die wordt beheerd door Traffic Manager scalable-ase-demo.trafficmanager.net.
• Strategie voor het schalen van de footprint van de app: Wordt de footprint van de toepassing verdeeld over meerdere App Service omgevingen in één regio? Meerdere regio's? Een combinatie van beide benaderingen? Baseer de beslissing op verwachtingen van waar klantverkeer vandaan komt en hoe goed de rest van de ondersteunende back-endinfrastructuur van een app kan worden geschaald. Met een 100% stateless toepassing kan een app bijvoorbeeld massaal worden geschaald met behulp van een combinatie van veel App Service omgevingen in elke Azure-regio, vermenigvuldigd met App Service omgevingen die in veel Azure-regio's zijn geïmplementeerd. Met meer dan 15 wereldwijde Azure-regio's waaruit kan worden gekozen, kunnen klanten echt een wereldwijde, hyperschaaltoepassingsvoetafdruk bouwen. Voor de voorbeeld-app die voor dit artikel wordt gebruikt, zijn drie App Service omgevingen gemaakt in één Azure-regio (VS - zuid-centraal).
• Naamconventie voor de App Service-omgevingen: voor elke App Service Environment is een unieke naam vereist. Naast een of twee App Service-omgevingen is het handig om een naamconventie te hebben om elke App Service Environment te identificeren. Voor de voorbeeld-app is een eenvoudige naamconventie gebruikt. De namen van de drie App Service omgevingen zijn fe1ase, fe2ase en fe3ase.
• Naamconventie voor de apps: Omdat er meerdere exemplaren van de app worden geïmplementeerd, is een naam nodig voor elk exemplaar van de geïmplementeerde app. Een weinig bekende maar handige functie van App Service-omgevingen is dat dezelfde app-naam kan worden gebruikt in meerdere App Service omgevingen. Omdat elke App Service Environment een uniek domeinachtervoegsel heeft, kunnen ontwikkelaars ervoor kiezen om exact dezelfde app-naam in elke omgeving opnieuw te gebruiken. Een ontwikkelaar kan bijvoorbeeld apps met de volgende naam hebben: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net, enzovoort. Voor de voorbeeld-app heeft elk app-exemplaar echter ook een unieke naam. De namen van de app-exemplaren zijn webfrontend1, webfrontend2 en webfrontend3.

Het Traffic Manager-profiel instellen

Zodra meerdere exemplaren van een app zijn geïmplementeerd op meerdere App Service-omgevingen, kunnen de afzonderlijke app-exemplaren worden geregistreerd bij Traffic Manager. Voor de voorbeeld-app is een Traffic Manager-profiel nodig voor scalable-ase-demo.trafficmanager.net waarmee klanten kunnen worden gerouteerd naar een van de volgende geïmplementeerde app-exemplaren:

• webfrontend1.fe1ase.p.azurewebsites.net: Een exemplaar van de voorbeeld-app die is geïmplementeerd op de eerste App Service Environment.
• webfrontend2.fe2ase.p.azurewebsites.net: Een exemplaar van de voorbeeld-app die is geïmplementeerd op de tweede App Service Environment.
• webfrontend3.fe3ase.p.azurewebsites.net: Een exemplaar van de voorbeeld-app die is geïmplementeerd op de derde App Service Environment.

De eenvoudigste manier om meerdere Azure App Service eindpunten te registreren, die allemaal in dezelfde Azure-regio worden uitgevoerd, is met de Ondersteuning voor PowerShell Azure Resource Manager Traffic Manager.

De eerste stap bestaat uit het maken van een Azure Traffic Manager-profiel. De onderstaande code laat zien hoe het profiel is gemaakt voor de voorbeeld-app:

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

U ziet hoe de parameter RelativeDnsName is ingesteld op scalable-ase-demo. Deze parameter zorgt ervoor dat de domeinnaam scalable-ase-demo.trafficmanager.net wordt gemaakt en gekoppeld aan een Traffic Manager-profiel.

De parameter TrafficRoutingMethod definieert het taakverdelingsbeleid dat Traffic Manager gebruikt om te bepalen hoe de klantbelasting moet worden verdeeld over alle beschikbare eindpunten. In dit voorbeeld is de methode Gewogen gekozen. Vanwege deze keuze worden aanvragen van klanten verdeeld over alle geregistreerde toepassingseindpunten op basis van de relatieve gewichten die aan elk eindpunt zijn gekoppeld.

Wanneer het profiel is gemaakt, wordt elk app-exemplaar aan het profiel toegevoegd als een systeemeigen Azure-eindpunt. Met de volgende code wordt een verwijzing naar elke front-end-web-app opgehaald. Vervolgens wordt elke app toegevoegd als een Traffic Manager-eindpunt via de parameter 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

U ziet hoe er één aanroep naar Add-AzureTrafficManagerEndpointConfig is voor elk afzonderlijk app-exemplaar. De parameter TargetResourceId in elke PowerShell-opdracht verwijst naar een van de drie geïmplementeerde app-exemplaren. Het Traffic Manager-profiel verspreidt de belasting over alle drie de eindpunten die in het profiel zijn geregistreerd.

Alle drie de eindpunten gebruiken dezelfde waarde (10) voor de parameter Gewicht . Deze situatie heeft tot gevolg dat Traffic Manager aanvragen van klanten relatief gelijkmatig verspreidt over alle drie de app-exemplaren.

De Custom Domain van de app naar het Traffic Manager-domein wijzen

De laatste stap die nodig is, is het verwijzen van het aangepaste domein van de app naar het Traffic Manager-domein. Wijs voor de voorbeeld-app www.asabuludemo.com naar scalable-ase-demo.trafficmanager.net. Voer deze stap uit met de domeinregistrar die het aangepaste domein beheert.

Met behulp van de domeinbeheerhulpprogramma's van uw registrar moet een CNAME-record worden gemaakt die het aangepaste domein naar het Traffic Manager-domein verwijst. In de onderstaande afbeelding ziet u een voorbeeld van hoe deze CNAME-configuratie eruitziet:

Hoewel dit niet in dit onderwerp wordt behandeld, moet voor elk afzonderlijk app-exemplaar het aangepaste domein ook worden geregistreerd. Als een aanvraag anders naar een app-exemplaar wordt verzonden en de toepassing het aangepaste domein niet heeft geregistreerd bij de app, mislukt de aanvraag.

In dit voorbeeld is www.asabuludemo.comhet aangepaste domein , en aan elk exemplaar van de toepassing is het aangepaste domein gekoppeld.

Zie Aangepaste domeinen registreren voor een samenvatting van het registreren van een aangepast domein met Azure App Service-apps.

De gedistribueerde topologie uitproberen

Het eindresultaat van de Traffic Manager- en DNS-configuratie is dat aanvragen voor www.asabuludemo.com de volgende volgorde worden doorlopen:

1. Een browser of apparaat maakt een DNS-zoekactie voor www.asabuludemo.com
2. De CNAME-vermelding bij de domeinregistrar zorgt ervoor dat de DNS-zoekopdracht wordt omgeleid naar Azure Traffic Manager.
3. Er wordt een DNS-zoekactie gemaakt voor scalable-ase-demo.trafficmanager.net op een van de DNS-servers van Azure Traffic Manager.
4. Op basis van het taakverdelingsbeleid dat eerder is opgegeven in de parameter TrafficRoutingMethod , selecteert Traffic Manager een van de geconfigureerde eindpunten. Vervolgens wordt de FQDN van dat eindpunt geretourneerd naar de browser of het apparaat.
5. Omdat de FQDN van het eindpunt de URL is van een app-exemplaar dat wordt uitgevoerd op een App Service Environment, vraagt de browser of het apparaat een Microsoft Azure DNS-server om de FQDN om te lossen naar een IP-adres.
6. De browser of het apparaat verzendt de HTTP/S-aanvraag naar het IP-adres.
7. De aanvraag komt binnen bij een van de app-exemplaren die worden uitgevoerd op een van de App Service-omgevingen.

In de onderstaande consoleafbeelding ziet u een DNS-zoekopdracht voor het aangepaste domein van de voorbeeld-app. Het wordt omgezet in een app-exemplaar dat wordt uitgevoerd op een van de drie voorbeeldomgevingen App Service omgevingen (in dit geval de tweede van de drie App Service-omgevingen):

Aanvullende koppelingen en informatie

Documentatie over de ondersteuning voor PowerShell Azure Resource Manager Traffic Manager.

Notitie

Als u aan de slag wilt met Azure App Service voordat u zich aanmeldt voor een Azure-account, gaat u naar App Service uitproberen. Hier kunt u direct een tijdelijke web-app maken in App Service. U hebt geen creditcard nodig en u doet geen toezeggingen.