Geograficznie rozproszona skala za pomocą App Service Environments

Przegląd

Scenariusze aplikacji, które wymagają bardzo dużej skali, mogą przekraczać pojemność zasobów obliczeniowych dostępną dla pojedynczego wdrożenia aplikacji. Aplikacje do głosowania, wydarzenia sportowe i telewizyjne wydarzenia rozrywkowe to przykłady scenariuszy wymagających bardzo dużej skali. Wymagania dotyczące dużej skali można spełnić, skalując aplikacje poziomo. 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.

Środowiska App Service Environment to idealna platforma do skalowania w poziomie. Po wybraniu konfiguracji środowiska App Service Environment, która może obsługiwać znaną częstotliwość żądań, deweloperzy mogą wdrażać dodatkowe środowiska App Service Environment w sposób "wycinania plików cookie", aby uzyskać żądaną szczytową pojemność obciążenia.

Załóżmy na przykład, że aplikacja uruchomiona w konfiguracji środowiska App Service Environment została przetestowana pod kątem obsługi 20 000 żądań na sekundę (RPS). Jeśli wymagana szczytowa pojemność obciążenia wynosi 100 000 RPS, można utworzyć pięć (5) środowisk App Service Environment 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 tzw. 'vanity'), deweloperzy potrzebują sposobu dystrybucji żą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 Environment. Usługa Traffic Manager automatycznie będzie obsługiwać dystrybucję klientów we wszystkich środowiskach App Service Environment 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 Environment 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 vanity domain, 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 Environment w oparciu o zaobserwowane obciążenie ruchem.

Poniższy diagram koncepcyjny przedstawia aplikację rozproszoną w poziomie w trzech Środowiskach Usług Aplikacji 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 Environment.

Planowanie topologii

Przed budowaniem rozproszonego śladu aplikacji warto z wyprzedzeniem zdobyć kilka istotnych informacji.

• Domena niestandardowa dla 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 to skalowalne-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? Mieszanka i dopasowanie obu podejść? Decyzja powinna opierać się na oczekiwaniach co do źródła ruchu klientów oraz na tym, jak dobrze reszta infrastruktury zaplecza technicznego potrafi się skalować. Na przykład przy użyciu 100% bezstanowej aplikacji można skalować aplikację masowo przy użyciu kombinacji wielu środowisk App Service Environment w każdym regionie świadczenia usługi Azure, mnożonych przez środowiska App Service Environment 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 w skali hiperskalowej na całym świecie. W przypadku przykładowej aplikacji używanej w tym artykule trzy środowiska App Service Environment zostały utworzone w jednym regionie świadczenia usługi Azure (Południowo-środkowe stany USA).
• Konwencja nazewnictwa środowisk App Service Environment: Każde środowisko App Service Environment wymaga unikatowej nazwy. Poza jednym lub dwoma środowiskami App Service Environment warto mieć konwencję nazewnictwa, aby ułatwić identyfikację każdego środowiska App Service Environment. W przypadku przykładowej aplikacji użyto prostej konwencji nazewnictwa. Nazwy trzech środowisk App Service Environment są fe1ase, fe2ase i fe3ase.
• Konwencja nazewnictwa aplikacji: Ponieważ zostanie wdrożonych wiele wystąpień aplikacji, dla każdego wystąpienia wdrożonej aplikacji jest wymagana nazwa. Jedną z mało znanych, ale wygodnych funkcji środowisk App Service Environment jest to, że ta sama nazwa aplikacji może być używana w wielu środowiskach App Service Environment. Ponieważ każde środowisko App Service Environment ma unikatowy sufiks domeny, deweloperzy mogą ponownie używać 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 Environment 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: Instancja przykładowej aplikacji wdrożonej na pierwszym środowisku App Service.
• webfrontend2.fe2ase.p.azurewebsites.net: Wystąpienie przykładowej aplikacji wdrożonej w drugim środowisku usług aplikacji.
• webfrontend3.fe3ase.p.azurewebsites.net: Wystąpienie przykładowej aplikacji wdrożonej w trzecim środowisku App Service Environment.

Najprostszym sposobem zarejestrowania wielu punktów końcowych usługi Azure App Service, uruchomionych w tym samym regionie świadczenia usługi Azure, jest obsługa usługi Azure Resource Manager Traffic Manager w programie 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ę, że parametr RelativeDnsName został ustawiony na Scalable-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 wybrano metodę 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 front-endowej aplikacji internetowej. 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 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 rozdzieli obciążenie wszystkich trzech punktów końcowych zarejestrowanych w profilu.

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

Wskazywanie domeny niestandardowej aplikacji na domenę Traffic Managera

Ostatnim krokiem jest skierowanie domeny niestandardowej aplikacji na domenę usługi Traffic Manager. Wskieruj www.asabuludemo.com na scalable-ase-demo.trafficmanager.net w przypadku przykładowej aplikacji. Wykonaj ten krok u rejestratora domen, który zarządza domeną niestandardową.

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

Chociaż temat ten nie obejmuje tego szczegółowo, warto pamiętać, że każda instancja aplikacji wymaga również zarejestrowania domeny niestandardowej. W przeciwnym razie, jeśli żądanie wysyła je do wystąpienia aplikacji, a aplikacja nie zarejestrowała domeny niestandardowej w aplikacji, żądanie zakończy się niepowodzeniem.

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

Aby zapoznać się z podsumowaniem rejestrowania domeny niestandardowej w aplikacjach usługi Azure App Service, zobacz Rejestrowanie domen niestandardowych.

Wypróbowywanie topologii rozproszonej

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

1. Przeglądarka lub urządzenie utworzy wyszukiwanie DNS www.asabuludemo.com
2. Wpis CNAME u rejestratora domen powoduje przekierowanie wyszukiwania DNS do usługi Azure Traffic Manager.
3. Wykonywane jest wyszukiwanie DNS 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 w App Service Environment, przeglądarka lub urządzenie poprosi serwer DNS Microsoft Azure o rozwiązanie nazwy FQDN na adres 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 środowisk App Service Environment.

Na poniższym obrazku z 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 Environment (w tym przypadku drugim z trzech środowisk App Service Environment):

Dodatkowe linki i informacje

Dokumentacja dotycząca obsługi menedżera ruchu Azure Resource Manager w programie PowerShell.

Uwaga

Jeśli chcesz rozpocząć pracę z usługą Azure App Service przed zarejestrowaniem się na koncie platformy Azure, przejdź do strony Wypróbuj usługę App Service, gdzie możesz natychmiast utworzyć początkową aplikację internetową o krótkim okresie życia w usłudze App Service. Nie są wymagane żadne karty kredytowe; brak zobowiązań.