Exercise - Autoscale and monitor a web app
Autoscaling is a key part of ensuring that a system remains available and responsive.
You want to implement autoscaling for the hotel reservation system web app, based on the CPU usage of the host. When the CPU utilization rises over a specific threshold, the web app will scale out. If the CPU usage drops, the web app will scale back in again.
In this unit, you'll set up the web app and run a test client app that imposes a load on the web app. You'll see the types of errors that can occur when the web host becomes overloaded. Next, you'll configure autoscaling for the web app and run the test client again. You'll monitor the autoscale events that occur, and examine how the system responds to the workload.
Setup
The web app for the hotel reservation system implements a web API. The web API exposes HTTP POST and GET operations that create and retrieve customer's bookings. In this exercise, the bookings aren't saved, and the GET operation simply retrieves dummy data.
The exercise also runs a client app that simulates a number of users issuing POST and GET operations simultaneously. This app provides the workload for testing how the web app autoscales.
Important
You need your own Azure subscription to run this exercise, and you might incur charges. If you don't already have an Azure subscription, create a free account before you begin.
Sign in to the Azure portal.
From the Azure portal menu, select Create a resource.
In the left menu pane, select Web, and then search for and select Web App. The Web App panel appears.
Select Create. The Create Web App panel appears.
On the Basics tab, enter the following values for each setting.
Note
The web app must have a unique name. We suggest using something like <your name or initials>hotelsystem. Use this name wherever you see <your-webapp-name> in this exercise.
Setting Value Project Details Subscription Select the Azure subscription you'd like to use for this exercise Resource Group Select the Create new link, and in the Name dialog, enter mslearn-autoscale Instance Details Name <your-webapp-name> Publish Code Runtime stack .NET Core 3.1 (LTS) Operating System Windows Region Select a region close to you Select Review + create, and then select Create.
In the top right menu bar of the Azure portal, open the Cloud Shell (first icon in row of menu choices).
To download the source code for the hotel reservation system, run the following command.
git clone https://github.com/MicrosoftDocs/mslearn-hotel-reservation-system.git
Move to the
mslearn-hotel-reservation-system/src
folder.cd mslearn-hotel-reservation-system/src
Build the apps for the hotel system. There are two apps - a web app that implements the web API for the system, and a client app that you'll use for load testing the web app.
dotnet build
Prepare the HotelReservationSystem web app for publishing.
cd HotelReservationSystem dotnet publish -o website
Go to the website folder containing the published files, zip them up, and deploy them to the web app you created in the previous task. Replace
<your-webapp-name>
with the name of your web app.cd website zip website.zip * az webapp deployment source config-zip --src website.zip --name <your-webapp-name> --resource-group mslearn-autoscale
Test the web app before configuring autoscaling
Using a web browser, go to
https://<your-webapp-name>.azurewebsites.net/api/reservations/1
. Visiting this URL sends a GET request to the web API to retrieve the details of reservation number 1. You should see a result similar to the one that follows. The response contains a JSON document with the details of the booking. Remember that this is dummy data.Return to the Cloud Shell, and move to the ~/mslearn-hotel-reservation-system/src/HotelReservationSystemTestClient folder.
cd ~/mslearn-hotel-reservation-system/src/HotelReservationSystemTestClient
In the Cloud Shell, select the code editor (icon with curly brackets), and edit the App.config file in this folder.
code App.config
Uncomment the line that specifies the ReservationsServiceURI, and replace the value with the URL of your web app. The file should look like the example that follows.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key="NumClients" value="100" /> <add key="ReservationsServiceURI" value="https://<your-webapp-name>.azurewebsites.net/"/> <add key="ReservationsServiceCollection" value="api/reservations"/> </appSettings> </configuration>
The NumClients setting in this file specifies the number of simultaneous clients that will attempt to connect to the web app and perform work. The work consists of creating a reservation, and then running a query to fetch the details of a reservation – all of the data used is fake and is not actually persisted anywhere. Leave this value set to 100.
Save the file by selecting the ellipsis in the upper right hand corner of the editor.
In the Cloud Shell, edit the HotelReservationSystemTestClient.csproj file in this folder.
code HotelReservationSystemTestClient.csproj
Edit the line that specifies the TargetFramework, so that it matches the Runtime stack that you selected for your web app. Change the TargetFramework value to
netcoreapp3.1
. The file should look like this example.<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.1</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Newtonsoft.Json" Version="12.0.1" /> <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.5.0" /> </ItemGroup> <ItemGroup> <ProjectReference Include="..\HotelReservationSystemTypes\HotelReservationSystemTypes.csproj" /> </ItemGroup> </Project>
Save the file by selecting the ellipsis in the upper right hand corner of the editor, and then close the code editor.
Rebuild the test client app with the new configuration.
dotnet build
Run the client app. You'll see a number of messages appear as the clients start running, make reservations, and run queries. Allow the system to run for a couple of minutes. The responses will be slow, and soon the client requests will start to fail with HTTP 408 (Timeout) errors.
dotnet run
To stop the client app, press Enter.
Enable autoscaling and create a scale condition
In the Azure portal, return to your web app.
Under Settings, select Scale out (App Service plan), and then select Custom autoscale.
In the Default autoscale rule, verify that the scale mode is set to Scale based on a metric, and then select Add a rule.
Add a rule that increases the instance count by one if the average CPU utilization across all instances in the web site exceeds 50 percent in the preceding five minutes. This is a scale-out rule.
Select Add a rule again. Add a rule that reduces the instance count by one if the average CPU utilization across all instances in the web site drops below 30 percent in the preceding five minutes. This is a scale-in rule. Remember that it's good practice to define scale rules in pairs.
In the Default auto scale condition window, in the Instance limits section, set the Maximum instance count to five. Name the Autoscale setting ScaleOnCPU, and then select Save.
Monitor autoscale events
Return to the Cloud Shell, go to the ~/hotelsystem/HotelReservationSystemTestClient folder, and run the test client again.
cd ~/hotelsystem/HotelReservationSystemTestClient dotnet run
While the client app is running, switch back to the Azure portal showing the autoscale settings for the web app, and select Run history. Under show data for last, select 1 hour. Initially, the chart will be empty as it will take several minutes for autoscaling to kick in.
While you're waiting for autoscaling events to occur, go to the pane for your web service (not the service plan), and under Monitoring, select Metrics.
Add the following metrics to the chart, set the time range to Last 30 minutes, and then pin the chart to the current dashboard:
- CPU Time. Select the Sum aggregation
- Http Server Errors. Select the Sum aggregation.
- Http 4.xx. Select the Sum aggregation.
- Average Response Time. Select the Avg aggregation.
Allow the system to stabilize, and note the CPU Time, the number of HTTP 4.xx errors, and the average response time. Before the system autoscales, you should see a significant number of HTTP 4.xx errors (these are HTTP 408 Timeout errors), and that the average response time is several seconds. There may be the occasional HTTP Server Error, depending on how the web server is coping with the burden.
After 10 minutes or so, you should see the following trends in this chart:
- CPU Time jumps up.
- Number of HTTP 4.xx errors diminishes.
- Average response time drops.
Each major spike in the CPU Time indicates that more CPU processing power has become available. This is a result of autoscaling.
For the web app and examine the charts, return to the Overview page. These charts should indicate the following trends:
- Data In, Data Out, and Requests metrics have increased.
- Average Response Time has dropped.
Select Scale out (App Service plan), and then select Run history. Select 1 hour. The graph should now indicate that autoscaling has occurred. The number of instances will have increased (it may have reached five, depending on how long the client app has been running), and you should see a number of autoscale events reported.
Note
The autoscale events are reported in pairs. The first event occurs when autoscaling has triggered an increase in the number of instances. The second event occurs when autoscaling has completed.
Return to the Cloud Shell. You should see that the app is running more quickly, and far fewer requests are failing.
To stop the app, press Enter.
After several minutes, if you examine the run history of the App Service Plan, you'll see the number of instances drop. This is the result of the scale-in rule releasing these resources.
You configured autoscaling for the hotel reservation system. The system scaled out when the total CPU usage across all instances hosting the web site exceeded 50 percent in a five-minute period. The system scaled back in when the total CPU utilization dropped below 30 percent, again for a five-minute period. You subjected the hotel reservation system to a test load, and monitored when autoscaling occurred.
Need help? See our troubleshooting guide or provide specific feedback by reporting an issue.