Geo-verteilter Maßstab mit App Service Environment

Anwendungsszenarien, die eine sehr hohe Skalierung erfordern, können die für eine einzelne Bereitstellung einer App verfügbare Computeressourcenkapazität überschreiten. Abstimmungsanwendungen, Sportveranstaltungen und Fernsehunterhaltungsveranstaltungen sind beispiele für Szenarien, die eine extrem hohe Skalierung erfordern. Hohe Anforderungen können erfüllt werden, indem Apps horizontal skaliert werden. Um extreme Lastanforderungen zu erfüllen, können viele App-Bereitstellungen innerhalb einer einzelnen Region und in allen Regionen erfolgen.

Überblick

App-Dienstumgebungen sind eine ideale Plattform für horizontales Skalieren. Nachdem Sie eine App Service Environment-Konfiguration ausgewählt haben, die eine bekannte Anforderungsrate unterstützen kann, können Entwickler zusätzliche App-Dienstumgebungen auf "Cookie-Schneidemaschine" bereitstellen, um eine gewünschte Spitzenlastkapazität zu erreichen.

Angenommen, eine App, die in einer App Service Environment-Konfiguration ausgeführt wird, wurde getestet, um 20 K-Anforderungen pro Sekunde (RPS) zu verarbeiten. Wenn die gewünschte Spitzenlastkapazität 100 K RPS beträgt, können fünf (5) App Service-Umgebungen erstellt und konfiguriert werden, um sicherzustellen, dass die Anwendung die maximale projizierte Last verarbeiten kann.

Da Kunden in der Regel mit einer benutzerdefinierten Domäne (oder Vanity)-Domäne auf Apps zugreifen, benötigen Entwickler eine Möglichkeit, App-Anforderungen über alle App Service Environment-Instanzen hinweg zu verteilen. Eine hervorragende Möglichkeit, dieses Ziel zu erreichen, besteht darin, die benutzerdefinierte Domäne mithilfe eines Azure Traffic Manager-Profils aufzulösen. Das Traffic Manager-Profil kann so konfiguriert werden, dass es auf alle einzelnen App Service-Umgebungen verweist. Traffic Manager verarbeitet automatisch die Verteilung von Kunden über alle App-Dienstumgebungen, basierend auf den Einstellungen für den Lastenausgleich im Traffic Manager-Profil. Dieser Ansatz funktioniert unabhängig davon, ob alle App-Dienstumgebungen in einer einzigen Azure-Region bereitgestellt oder weltweit in mehreren Azure-Regionen bereitgestellt werden.

Da Kunden über die Vanity-Domäne auf Apps zugreifen, wissen Kunden nicht, wie viele App-Dienstumgebungen eine App ausführen. Daher können Entwickler app Service-Umgebungen basierend auf beobachteter Datenverkehrslast schnell und einfach hinzufügen und entfernen.

Das nachstehende konzeptionelle Diagramm zeigt eine App horizontal skaliert auf drei App-Dienstumgebungen innerhalb einer region.

Im restlichen Teil dieses Artikels werden die Schritte zum Einrichten einer verteilten Topologie für die Beispiel-App mithilfe mehrerer App-Dienstumgebungen erläutert.

Planen der Topologie

Bevor Sie einen verteilten App-Speicherbedarf erstellen, hilft es, einige Informationen vorab zu erhalten.

• Benutzerdefinierte Domäne für die App: Was ist der benutzerdefinierte Domänenname, den Kunden für den Zugriff auf die App verwenden? Für die Beispiel-App lautet www.asabuludemo.comder benutzerdefinierte Domänenname .
• Traffic Manager-Domäne: Wählen Sie beim Erstellen eines Azure Traffic Manager-Profils einen Domänennamen aus. Dieser Name wird mit dem suffix trafficmanager.net kombiniert, um einen Domäneneintrag zu registrieren, der von Traffic Manager verwaltet wird. Für die Beispiel-App ist der gewählte Name skalierbar-ase-demo. Daher wird der vollständige Domänenname, der von Traffic Manager verwaltet wird , scalable-ase-demo.trafficmanager.net.
• Strategie für die Skalierung des App-Speicherbedarfs: Wird der Anwendungsbedarf in mehreren App-Dienstumgebungen in einer einzelnen Region verteilt? Mehrere Regionen? Eine Mischung aus beiden Ansätzen? Basieren Sie auf den Erwartungen, wo der Kundendatenverkehr entsteht, und wie gut der Rest der unterstützenden Back-End-Infrastruktur einer App skaliert werden kann. Beispielsweise kann eine App mit einer 100% zustandslosen Anwendung massiv skaliert werden, indem sie eine Kombination aus vielen App-Dienstumgebungen in jeder Azure-Region verwendet, multipliziert mit App Service-Umgebungen, die in vielen Azure-Regionen bereitgestellt werden. Mit mehr als 15 globalen Azure-Regionen, aus der Sie wählen können, können Kunden wirklich einen weltweiten, hyperskalen Anwendungsbedarf aufbauen. Für die Beispiel-App, die für diesen Artikel verwendet wird, wurden drei App-Dienstumgebungen in einer einzelnen Azure-Region (South Central US) erstellt.
• Benennungskonvention für die App-Dienstumgebungen: Jede App Service-Umgebung erfordert einen eindeutigen Namen. Über eine oder zwei App-Dienstumgebungen hinaus ist es hilfreich, eine Benennungskonvention zu haben, um jede App Service-Umgebung zu identifizieren. Für die Beispiel-App wurde eine einfache Benennungskonvention verwendet. Die Namen der drei App-Dienstumgebungen sind fe1ase, fe2ase und fe3ase.
• Benennungskonvention für die Apps: Da mehrere Instanzen der App bereitgestellt werden, wird für jede Instanz der bereitgestellten App ein Name benötigt. Ein wenig bekanntes, aber praktisches Feature von App-Dienstumgebungen besteht darin, dass derselbe App-Name in mehreren App-Dienstumgebungen verwendet werden kann. Da jede App Service-Umgebung über ein eindeutiges Domänensuffix verfügt, können Entwickler den exakt gleichen App-Namen in jeder Umgebung wiederverwenden. Beispielsweise könnte ein Entwickler Apps wie folgt benannt haben: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net usw. Für die Beispiel-App hat jede App-Instanz jedoch auch einen eindeutigen Namen. Die verwendeten App-Instanznamen sind webfrontend1, webfrontend2 und webfrontend3.

Einrichten des Traffic Manager-Profils

Sobald mehrere Instanzen einer App in mehreren App-Dienstumgebungen bereitgestellt wurden, können die einzelnen App-Instanzen beim Traffic Manager registriert werden. Für die Beispiel-App wird ein Traffic Manager-Profil für scalable-ase-demo.trafficmanager.net benötigt, das Kunden an eine der folgenden bereitgestellten App-Instanzen weiterleiten kann:

• webfrontend1.fe1ase.p.azurewebsites.net: Eine Instanz der Beispiel-App, die in der ersten App-Dienstumgebung bereitgestellt wird.
• webfrontend2.fe2ase.p.azurewebsites.net: Eine Instanz der Beispiel-App, die in der zweiten App-Dienstumgebung bereitgestellt wird.
• webfrontend3.fe3ase.p.azurewebsites.net: Eine Instanz der Beispiel-App, die in der dritten App-Dienstumgebung bereitgestellt wird.

Die einfachste Möglichkeit zum Registrieren mehrerer Azure App Service-Endpunkte , die alle in derselben Azure-Region ausgeführt werden, ist die Unterstützung von PowerShell Azure Resource Manager Traffic Manager.

Der erste Schritt besteht darin, ein Azure Traffic Manager-Profil zu erstellen. Der folgende Code zeigt, wie das Profil für die Beispiel-App erstellt wurde:

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

Beachten Sie, wie der Parameter "RelativeDnsName " auf "scalable-ase-demo" festgelegt wurde. Dieser Parameter bewirkt, dass der Domänenname scalable-ase-demo.trafficmanager.net erstellt und einem Traffic Manager-Profil zugeordnet wird.

Der Parameter "TrafficRoutingMethod " definiert die Richtlinie "Lastenausgleichsrichtlinie Traffic Manager", um zu bestimmen, wie die Kundenlast über alle verfügbaren Endpunkte verteilt wird. In diesem Beispiel wurde die Weighted-Methode ausgewählt. Aufgrund dieser Wahl werden Kundenanforderungen auf alle registrierten Anwendungsendpunkte verteilt, basierend auf den relativen Gewichtungen, die den einzelnen Endpunkten zugeordnet sind.

Mit dem erstellten Profil wird jede App-Instanz dem Profil als nativer Azure-Endpunkt hinzugefügt. Der folgende Code ruft einen Verweis auf jede Front-End-Web-App ab. Anschließend wird jede App als Traffic Manager-Endpunkt über den Parameter TargetResourceId hinzugefügt.

$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

Beachten Sie, wie es einen Aufruf von Add-AzureTrafficManagerEndpointConfig für jede einzelne App-Instanz gibt. Der Parameter TargetResourceId in jedem PowerShell-Befehl verweist auf eine der drei bereitgestellten App-Instanzen. Das Traffic Manager-Profil verteilt sich über alle drei im Profil registrierten Endpunkte.

Alle drei Endpunkte verwenden denselben Wert (10) für den Weight-Parameter . Dies führt dazu, dass Traffic Manager Kundenanforderungen auf alle drei App-Instanzen relativ gleichmäßig verteilt.

Verweisen auf die benutzerdefinierte Domäne der App auf die Traffic Manager-Domäne

Der letzte Schritt ist erforderlich, um die benutzerdefinierte Domäne der App auf die Traffic Manager-Domäne zu verweisen. Zeigen www.asabuludemo.com Sie für die Beispiel-App auf scalable-ase-demo.trafficmanager.net. Führen Sie diesen Schritt mit der Domänenregistrierungsstelle aus, die die benutzerdefinierte Domäne verwaltet.

Erstellen Sie mithilfe der Domänenverwaltungstools Ihrer Registrierungsstelle einen CNAME-Eintrag, der auf die benutzerdefinierte Domäne in der Traffic Manager-Domäne verweist. Die folgende Abbildung zeigt ein Beispiel dafür, wie diese CNAME-Konfiguration aussieht:

Beachten Sie zwar nicht in diesem Thema, dass jede einzelne App-Instanz auch die benutzerdefinierte Domäne registriert haben muss. Andernfalls schlägt die Anforderung fehl, wenn eine Anforderung an eine App-Instanz sendet und die Anwendung die benutzerdefinierte Domäne nicht bei der App registriert hat.

In diesem Beispiel ist www.asabuludemo.comdie benutzerdefinierte Domäne , und jede Anwendungsinstanz hat die benutzerdefinierte Domäne zugeordnet.

Eine Zusammenfassung der Registrierung einer benutzerdefinierten Domäne bei Azure App Service-Apps finden Sie unter Registrieren benutzerdefinierter Domänen.

Testen der verteilten Topologie

Das Endergebnis der Traffic-Manager- und DNS-Konfiguration besteht darin, dass Anforderungen für www.asabuludemo.com den Datenverkehr über die folgende Sequenz fließen:

1. Ein Browser oder Gerät macht eine DNS-Suche für www.asabuludemo.com
2. Der CNAME-Eintrag bei der Domänenregistrierungsstelle bewirkt, dass der DNS-Nachschlagevorgang an Azure Traffic Manager umgeleitet wird.
3. Für scalable-ase-demo.trafficmanager.net für einen der Azure Traffic Manager-DNS-Server wird eine DNS-Suche durchgeführt.
4. Basierend auf der weiter oben im Parameter "TrafficRoutingMethod " angegebenen Richtlinie wählt Traffic Manager einen der konfigurierten Endpunkte aus. Anschließend wird der FQDN dieses Endpunkts an den Browser oder das Gerät zurückgegeben.
5. Da der FQDN des Endpunkts die URL einer App-Instanz ist, die in einer App-Dienstumgebung ausgeführt wird, fordert der Browser oder das Gerät einen Microsoft Azure DNS-Server auf, den FQDN in eine IP-Adresse aufzulösen.
6. Der Browser oder das Gerät sendet die HTTP/S-Anforderung an die IP-Adresse.
7. Die Anforderung wird bei einer der App-Instanzen eingehen, die in einer der App-Dienstumgebungen ausgeführt werden.

Die nachstehende Konsolengrafik zeigt eine DNS-Suche nach der benutzerdefinierten Domäne der Beispiel-App. Es wird erfolgreich zu einer App-Instanz aufgelöst, die in einer der drei Beispiel-App-Dienstumgebungen ausgeführt wird (in diesem Fall die zweite der drei App-Dienstumgebungen):

Verwandte Inhalte

• PowerShell-Unterstützung für Azure Resource Manager Traffic Manager