Rozproszona geograficznie skala przy użyciu środowisk usługi App Service

Omówienie

Scenariusze aplikacji wymagające bardzo dużej skali mogą przekraczać pojemność zasobów obliczeniowych dostępnych dla pojedynczego wdrożenia aplikacji. Aplikacje do głosowania, wydarzenia sportowe i wydarzenia telewizyjne są przykładami scenariuszy wymagających bardzo dużej skali. Wymagania dotyczące dużej skali można spełnić, skalując aplikacje w poziomie. Aby obsłużyć ekstremalne wymagania dotyczące obciążenia, wiele wdrożeń aplikacji można wykonać w jednym regionie i w różnych regionach.

App Service Environments to idealna platforma do skalowania w poziomie. Po wybraniu konfiguracji App Service Environment, która może obsługiwać znaną szybkość żądań, deweloperzy mogą wdrożyć dodatkowe środowiska App Service w sposób "wycinarki plików cookie", aby uzyskać żądaną pojemność szczytowego obciążenia.

Załóżmy na przykład, że aplikacja działająca w konfiguracji App Service Environment została przetestowana pod kątem obsługi żądań 20K na sekundę (RPS). Jeśli wymagana maksymalna pojemność obciążenia wynosi 100 tys. rpS, można utworzyć pięć (5) App Service Środowiska i skonfigurować je w celu zapewnienia, że aplikacja może obsłużyć maksymalne przewidywane obciążenie.

Ponieważ klienci zazwyczaj uzyskują dostęp do aplikacji przy użyciu domeny niestandardowej (lub vanity), deweloperzy potrzebują sposobu dystrybuowania żądań aplikacji we wszystkich wystąpieniach App Service Environment. Doskonałym sposobem na osiągnięcie tego celu jest rozwiązanie problemu z domeną niestandardową przy użyciu profilu usługi Azure Traffic Manager. Profil usługi Traffic Manager można skonfigurować tak, aby wskazywał wszystkie poszczególne środowiska App Service. Usługa Traffic Manager automatycznie będzie obsługiwać dystrybucję klientów we wszystkich środowiskach App Service na podstawie ustawień równoważenia obciążenia w profilu usługi Traffic Manager. Takie podejście działa niezależnie od tego, czy wszystkie środowiska App Service są wdrażane w jednym regionie świadczenia usługi Azure, czy wdrażane na całym świecie w wielu regionach świadczenia usługi Azure.

Ponadto, ponieważ klienci uzyskują dostęp do aplikacji za pośrednictwem domeny vanity, klienci nie wiedzą o liczbie środowisk App Service z uruchomioną aplikacją. Dzięki temu deweloperzy mogą szybko i łatwo dodawać i usuwać środowiska App Service na podstawie obserwowanego obciążenia ruchu.

Poniższy diagram koncepcyjny przedstawia aplikację skalowaną w poziomie w poziomie w trzech środowiskach App Service w jednym regionie.

W pozostałej części tego tematu przedstawiono kroki związane z konfigurowaniem topologii rozproszonej dla przykładowej aplikacji przy użyciu wielu środowisk App Service.

Planowanie topologii

Przed utworzeniem rozproszonego śladu aplikacji pomaga ona mieć kilka informacji przed upływem czasu.

• Domena niestandardowa aplikacji: Jaka jest niestandardowa nazwa domeny, której klienci będą używać do uzyskiwania dostępu do aplikacji? W przypadku przykładowej aplikacji niestandardowa nazwa domeny to www.asabuludemo.com.
• Domena usługi Traffic Manager: Wybierz nazwę domeny podczas tworzenia profilu usługi Azure Traffic Manager. Ta nazwa zostanie połączona z sufiksem trafficmanager.net w celu zarejestrowania wpisu domeny zarządzanego przez usługę Traffic Manager. W przypadku przykładowej aplikacji wybrana nazwa jest skalowalna-ase-demo. W związku z tym pełna nazwa domeny zarządzana przez usługę Traffic Manager jest scalable-ase-demo.trafficmanager.net.
• Strategia skalowania śladu aplikacji: Czy ślad aplikacji będzie dystrybuowany w wielu środowiskach App Service w jednym regionie? Wiele regionów? Połączenie obu podejść? Należy podjąć decyzję o oczekiwaniach dotyczących tego, skąd będzie pochodzić ruch klientów i jak dobrze będzie można skalować resztę infrastruktury zaplecza obsługującej aplikację. Na przykład w przypadku aplikacji bezstanowej 100% aplikacja może być skalowana masowo przy użyciu kombinacji wielu środowisk App Service w każdym regionie świadczenia usługi Azure pomnożonego przez środowiska App Service wdrożone w wielu regionach świadczenia usługi Azure. Dzięki 15+ globalnym regionom platformy Azure dostępnym do wyboru klienci mogą naprawdę utworzyć zasięg aplikacji na całym świecie w skali hiperskalowej. W przypadku przykładowej aplikacji używanej w tym artykule trzy środowiska App Service zostały utworzone w jednym regionie świadczenia usługi Azure (Południowo-środkowe stany USA).
• Konwencja nazewnictwa środowisk App Service: każda App Service Environment wymaga unikatowej nazwy. Poza jednym lub dwoma środowiskami App Service warto mieć konwencję nazewnictwa, aby ułatwić identyfikację każdego App Service Environment. W przypadku przykładowej aplikacji użyto prostej konwencji nazewnictwa. Nazwy trzech środowisk App Service to fe1ase, fe2ase i fe3ase.
• Konwencja nazewnictwa aplikacji: Ponieważ zostanie wdrożonych wiele wystąpień aplikacji, nazwa jest potrzebna dla każdego wystąpienia wdrożonej aplikacji. Jedną mało znaną, ale wygodną funkcją środowisk App Service jest to, że ta sama nazwa aplikacji może być używana w wielu środowiskach App Service. Ponieważ każdy App Service Environment ma unikatowy sufiks domeny, deweloperzy mogą użyć dokładnie tej samej nazwy aplikacji w każdym środowisku. Na przykład deweloper może mieć aplikacje o nazwie w następujący sposób: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net itp. Jednak w przypadku przykładowej aplikacji każde wystąpienie aplikacji ma również unikatową nazwę. Używane nazwy wystąpień aplikacji to webfrontend1, webfrontend2 i webfrontend3.

Konfigurowanie profilu usługi Traffic Manager

Po wdrożeniu wielu wystąpień aplikacji w wielu środowiskach App Service poszczególne wystąpienia aplikacji można zarejestrować w usłudze Traffic Manager. W przypadku przykładowej aplikacji wymagany jest profil usługi Traffic Manager dla scalable-ase-demo.trafficmanager.net , który może kierować klientów do dowolnego z następujących wdrożonych wystąpień aplikacji:

• webfrontend1.fe1ase.p.azurewebsites.net: Wystąpienie przykładowej aplikacji wdrożonej w pierwszej App Service Environment.
• webfrontend2.fe2ase.p.azurewebsites.net: Wystąpienie przykładowej aplikacji wdrożonej na drugim App Service Environment.
• webfrontend3.fe3ase.p.azurewebsites.net: Wystąpienie przykładowej aplikacji wdrożonej na trzecim App Service Environment.

Najprostszym sposobem rejestrowania wielu punktów końcowych Azure App Service, które działają w tym samym regionie świadczenia usługi Azure, jest obsługa usługi Azure Resource Manager Traffic Manager programu PowerShell.

Pierwszym krokiem jest utworzenie profilu usługi Azure Traffic Manager. Poniższy kod pokazuje, jak profil został utworzony dla przykładowej aplikacji:

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

Zwróć uwagę, jak parametr RelativeDnsName został ustawiony na skalowalny-ase-demo. Ten parametr powoduje utworzenie i skojarzenie nazwy domeny scalable-ase-demo.trafficmanager.net z profilem usługi Traffic Manager.

Parametr TrafficRoutingMethod definiuje zasady równoważenia obciążenia usługi Traffic Manager, aby określić, jak rozłożyć obciążenie klienta na wszystkie dostępne punkty końcowe. W tym przykładzie została wybrana metoda Ważona . W związku z tym żądania klientów będą rozłożone na wszystkie zarejestrowane punkty końcowe aplikacji na podstawie względnych wag skojarzonych z każdym punktem końcowym.

Po utworzeniu profilu każde wystąpienie aplikacji jest dodawane do profilu jako natywny punkt końcowy platformy Azure. Poniższy kod pobiera odwołanie do każdej aplikacji internetowej frontonu. Następnie dodaje każdą aplikację jako punkt końcowy usługi Traffic Manager za pomocą 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

Zwróć uwagę, że istnieje jedno wywołanie polecenia Add-AzureTrafficManagerEndpointConfig dla każdego pojedynczego wystąpienia aplikacji. Parametr TargetResourceId w każdym poleceniu programu PowerShell odwołuje się do jednego z trzech wdrożonych wystąpień aplikacji. Profil usługi Traffic Manager rozłoży obciążenie we wszystkich trzech punktach końcowych zarejestrowanych w profilu.

Wszystkie trzy punkty końcowe używają tej samej wartości (10) dla parametru Waga . Taka sytuacja powoduje równomierne rozłożenie żądań klientów przez usługę Traffic Manager we wszystkich trzech wystąpieniach aplikacji.

Wskazywanie Custom Domain aplikacji w domenie usługi Traffic Manager

Ostatnim krokiem jest wskazanie domeny niestandardowej aplikacji w domenie usługi Traffic Manager. W przypadku przykładowej aplikacji wskaż www.asabuludemo.com wartość .scalable-ase-demo.trafficmanager.net Wykonaj ten krok z rejestratorem domen, który zarządza domeną niestandardową.

Za pomocą narzędzi do zarządzania domenami rejestratora należy utworzyć rekordy CNAME, które wskazuje domenę niestandardową w domenie usługi Traffic Manager. Na poniższym obrazie przedstawiono przykładowa konfiguracja CNAME:

Chociaż nie opisano w tym temacie, należy pamiętać, że każde pojedyncze wystąpienie aplikacji musi mieć również zarejestrowaną domenę niestandardową. W przeciwnym razie, jeśli żądanie wysyła je do wystąpienia aplikacji, a aplikacja nie zarejestrowała domeny niestandardowej z aplikacją, żądanie zakończy się niepowodzeniem.

W tym przykładzie domena niestandardowa to www.asabuludemo.com, a każde wystąpienie aplikacji ma skojarzona z nią domenę niestandardową.

Aby uzyskać podsumowanie rejestrowania domeny niestandardowej za pomocą aplikacji Azure App Service, zobacz Rejestrowanie domen niestandardowych.

Wypróbowanie topologii rozproszonej

Wynikiem końcowym konfiguracji usługi Traffic Manager i DNS jest to, że żądania dla www.asabuludemo.com usługi będą przepływać przez następującą sekwencję:

1. Przeglądarka lub urządzenie utworzy wyszukiwanie DNS dla www.asabuludemo.com
2. Wpis CNAME u rejestratora domen powoduje przekierowanie wyszukiwania DNS do usługi Azure Traffic Manager.
3. Wyszukiwanie DNS jest tworzone dla scalable-ase-demo.trafficmanager.net względem jednego z serwerów DNS usługi Azure Traffic Manager.
4. Na podstawie zasad równoważenia obciążenia określonych wcześniej w parametrze TrafficRoutingMethod usługa Traffic Manager wybiera jeden ze skonfigurowanych punktów końcowych. Następnie zwraca nazwę FQDN tego punktu końcowego do przeglądarki lub urządzenia.
5. Ponieważ nazwa FQDN punktu końcowego jest adresem URL wystąpienia aplikacji uruchomionego na App Service Environment, przeglądarka lub urządzenie poprosi serwer DNS platformy Microsoft Azure o rozwiązanie nazwy FQDN do adresu IP.
6. Przeglądarka lub urządzenie wyśle żądanie HTTP/S do adresu IP.
7. Żądanie zostanie dostarczone do jednego z wystąpień aplikacji uruchomionych w jednym z App Service Environments.

Na poniższej ilustracji konsoli przedstawiono wyszukiwanie DNS dla domeny niestandardowej przykładowej aplikacji. Pomyślnie rozpoznano wystąpienie aplikacji uruchomione w jednym z trzech przykładowych środowisk App Service (w tym przypadku drugim z trzech środowisk App Service):

Dodatkowe linki i informacje

Dokumentacja dotycząca obsługi usługi Azure Resource Manager Traffic Manager programu PowerShell.

Uwaga

Jeśli chcesz zacząć korzystać z usługi Azure App Service przed utworzeniem konta platformy Azure, przejdź do artykułu Try App Service (Wypróbuj usługę App Service), w którym wyjaśniono, jak od razu utworzyć początkową aplikację internetową o krótkim okresie istnienia w usłudze App Service. Bez kart kredytowych i bez zobowiązań.