Get overview of the various ways to scale an Azure web app, such as scaling out and up an App Service app and scaling the associated SQL Database.
- [Instructor] Let's take a few minutes to talk about how we can control our web apps' scale and performance which can be accomplished by scaling our web apps and replicating the associated SQL databases. Let's start off with scaling. When we refer to scaling in Azure web app, we have two work flows to choose from. First, we have the scale out work flow which increases the number of virtual machine instances that the app is running on. And at the premium tier level, we can have up to 20 instances. When we're using the App Service Environment at the premium level, we can have up to 50 instances.
We can also scale up our web apps which increases the amount and number of resources that the app can actually access. These resources could be additional CPU, memory, or staging slots. There are two ways to scale your web app and the choice will depend on the tier that you're working in. If you are using the free or shared tier then scaling is not supported at all. The basic plan will allow you to scale manually. And to do so, you will need to specify the number of instances to scale to and you'll be responsible for manually monitoring and adjusting this as required.
The standard and premium tier support autoscaling. When you autoscale, the number of instances is based on a metric. For example, we can autoscale to increase our instance count by two, when our CPU percentage is greater than 70. But when it drops below 30 we can decrease that instance count by two. We can also set up autoscaling based on a schedule. For example, you may want to reduce the number of instances that are running during the weekends when you know there will be little to no traffic.
We can also scale the associated SQL database by changing the tier of the database between basic, standard, premium, and premium RS. And within each of these tiers, we can then select the number of DTUs and the amount of storage. And finally, we can also replicate our SQL databases and we can have up to four readable secondary databases. These secondary databases are not only used for a web app, but we can also use them for other tasks such as reporting. And keep in mind that active geo-replication must be between databases within the same subscriptions.
So you cannot use different subscriptions in this model. Now that we've talked about scaling and replicating, let's go ahead and do it in Azure. I'm logged into Azure, I'm in our resource group, and I'm going to go ahead and select our web app. You'll find scaling up and out under settings. Let's go ahead and work with the scale up option first. And here, our scaling is just choosing our pricing tier. We can scale up to let's say a P3, or we could scale down as required.
I'm going to leave it as is, going to go ahead and close that blade. Next we have the scale out options. And here, we can go ahead and either manually override our instance count if we wanted to do so. So I can come in and set that to three, or I can go ahead and enable autoscaling. So all I've done is click on enable autoscaling, and the first thing I'm going to do is scale based on a metric. And I'm going to use the same example that I used in the presentation. To do so, click on add a rule.
And now we can go ahead and select the criteria. I'm going to go ahead and use average the CPU percentage. The time grain statistic again will be average, greater than 70. And it must be greater than 70% for 20 minutes in order for this rule to kick in. Once we've been at 70% for longer than 10 minutes, we're going to increase the instance count by two and then we have a cooldown period as well. And as we can see here, the cooldown period is the time that the application will wait before scaling again.
I'm going to leave it at five minutes. Then I'm going to go ahead and click add. Next, we're going to add in another rule. Because now I would like it to scale down. My operator will be less than, threshold will be 30. The duration is 10, we're going to decrease the count by two and again our cooldown period. Click add. That's it. Very simple. Next we can go ahead and create another condition. And in this case, it's going to be scale to a specific instance count during certain times.
Now, before I go and configure all this I'd actually like to change out the name here so I know what this condition is. And then go ahead and remove what's here and then call it scheduled weekends. And the instance count will be one and I can repeat on specific days and let's say Saturdays and Sundays, entering your timezone, and your start and end times. Once you're happy with it, you can go ahead and save. But I've noticed right off the top that I forgot to add in a profile name. So I'm going to go ahead and do that.
I could've also gone in and edited the title on our first condition, but for our demonstration today, we're going to leave it as is. And go ahead and click save, and this will take a few minutes. There we go. Our autoscale settings have now been saved and they will run for us in the background. If you wanted to look at the details you can go ahead, click on the JSON file, and you'll see that all the conditions are set up in your JSON file. If I wanted to delete this, I can go ahead and click delete.
And then go ahead and click back into configure. I can go ahead and disable autoscale as well. Now that we've done our scaling for our web apps, let's go ahead and look at the SQL database and how we can scale that. I'm going to go ahead and close this blade. I'm going to scroll over. Next, I'm going to go ahead and select our database that we created when we created this Azure web app. And you'll notice here that we have a pricing tier so we can scale. Click on your pricing tier.
And as I said, you can go ahead and flip between the different tiers. I'm going to stay in standard, but I'm going to increase my DTUs. I'm going to leave the storage as is, then I'm just going to simply click apply. And that's it. Our database DTUs are now going to scale up. And finally, we can go ahead and set up geo-replication for our SQL databases. To do so, click on geo-replication. As you can see, we're presented with a handy dandy little chart.
We can go ahead and select the highlighted region. Or we can scroll down. That lets us know that geo-replication is not configured. And we can go ahead and select the replication region. So in this case, it was recommended that I choose Canada East because my App Service is staying in Canada Central. Next, I can choose a secondary type, readable or non-readable. I'm going to leave it as readable. Next, we're going to go ahead and configure our new server. Then provide your server admin login and a password.
Click select, and you'll notice here that our pricing tier automatically changed for us because this is replicated. So it'll use the same tier settings. And then click OK. After a few minutes, your database will be seated, and will be online, and then our example here is now readable. By using scaling and SQL replication, you can ensure that your web apps are always highly available and responsive to your users when they need to access that data.
Learn the intermediate-level skills needed to design Azure web and mobile apps for any organization, using the Azure Web Apps and Mobile Apps services. Instructor Sharon Bennett, a Microsoft Certified Solutions Expert, covers securing mobile and web apps with Azure Active Directory, creating WebJobs to script tasks such as queue processing and file maintenance, and extending mobile apps with custom code. Plus, learn how to update, back up, and restore your Azure apps.
As an intermediate-level course, an existing understanding of the Azure platform is required. After completing the training, IT professionals will also be better prepared for Azure certification.
- Create Azure web apps
- Create WebJobs
- Using Traffic Manager
- Adding a CDN to web apps
- Updating, backing up, and restoring Azure Web Apps
- Deploying Azure mobile apps