Geo-distributed horizontal scale with App Service Environment

Application scenarios that require high scale can exceed the compute resource capacity available to a single deployment of an app. Voting applications, sporting events, and televised entertainment events are examples of scenarios that require high scale. You can support high scale requirements by horizontally scaling out apps. To handle extreme load requirements, many app deployments can be made within a single region and across regions.

This article provides an overview for creating a distributed topology with a sample app and multiple App Service Environments. The horizontal scaling is accomplished by using Azure Traffic Manager.

Overview of horizontal scaling process

App Service Environments are an ideal platform for horizontal scale-out. After selecting an App Service Environment configuration that can support a known request rate, developers can deploy more App Service Environments in "cookie cutter" fashion to attain a desired peak load capacity.

Suppose an app running on an App Service Environment configuration is tested to handle 20-K requests per second (RPS). If the desired peak load capacity is 100 K RPS, five App Service Environments can be created and configured to ensure the application can handle the maximum projected load.

Because customers typically access apps by using a custom (or vanity) domain, developers need a way to distribute app requests across all of the App Service Environment instances. A great way to accomplish this goal is to resolve the custom domain by using a Traffic Manager profile. The profile can be configured to point to all of the individual App Service Environments. Traffic Manager automatically handles the distribution of customers across all of the App Service Environments, based on the load-balancing settings in the profile. This approach works regardless of whether all the App Service Environments are deployed in a single Azure region, or deployed worldwide across multiple Azure regions.

In this scenario, customers often access apps through the vanity domain. They're unaware of the number of App Service Environments running an app. Developers can quickly and easily add and remove App Service Environments based on observed traffic load.

The following diagram shows an app horizontally scaled across three App Service Environments within a single region:

Topology requirements

To build the distributed app, you need the following information:

• Custom domain for the app: Determine the custom or vanity domain name customers use to access your app. For the sample app in this article, the custom domain name is www.asabuludemo.com.

• Traffic Manager domain: Choose a domain name when you create the Traffic Manager profile. The name is combined with the trafficmanager.net suffix, which indicates Traffic Manager maintains registration and management for the domain entry. For the sample app, the domain name is scalable-ase-demo. The full domain name managed by Traffic Manager is scalable-ase-demo.trafficmanager.net.

• Strategy for scaling the app footprint: Determine how the app is distributed across the multiple App Service Environments: a single region, multiple regions, or a combination. Consider where customer traffic originates, and how well the rest of an app's supporting back-end infrastructure can scale.

  Consider a 100% stateless application that can be massively scaled. You can use a combination of many App Service Environments in each Azure region multiplied by App Service Environments deployed across many Azure regions. Microsoft Azure is available in a multitude of global regions, which supports a world-wide hyper-scale app footprint. The sample app uses three App Service Environments in a single Azure region (South Central US).

• Naming convention for the App Service Environments: Define the convention for naming your App Service Environments. Each App Service Environment requires a unique name. If you have more than just one or two App Service Environments, it's helpful to have a naming convention that can identify each App Service Environment. The sample app implements a simple naming convention. The names of the three App Service Environments are fe1ase, fe2ase, and fe3ase.

• Naming convention for the apps: Define the convention for naming your apps. Because multiple instances of the app are deployed, you need a name for each instance of the deployed app. App Service Environments allow you to use the same app name across multiple App Service Environments. Because each App Service Environment has a unique domain suffix, developers can reuse the same app name in each environment. For example, you might have multiple apps named myapp.env1.p.azurewebsites.net, myapp.env2.p.azurewebsites.net, myapp.env3.p.azurewebsites.net, and so on. For the sample app, each app instance has a unique name: webfrontend1, webfrontend2, and webfrontend3.

Traffic Manager profile

After you deploy multiple instances of an app across multiple App Service Environments, you can register the app instances with Traffic Manager. The sample app requires a Traffic Manager profile for the scalable-ase-demo.trafficmanager.net address. When customers access this location, the profile configuration routes them to the deployed app instances:

• webfrontend1.fe1ase.p.azurewebsites.net: Sample app instance deployed on first App Service Environment.
• webfrontend2.fe2ase.p.azurewebsites.net: Sample app instance deployed on second App Service Environment.
• webfrontend3.fe3ase.p.azurewebsites.net: Sample app instance deployed on third App Service Environment.

Create the profile

The easiest way to register multiple App Service endpoints that run in the same Azure region is by using Azure PowerShell. The first step is to create the Traffic Manager profile. The following code creates a new profile named scalableasedemo for the sample app.

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

Notice how the -RelativeDnsName parameter is set to scalable-ase-demo. The command uses this parameter to create the domain name scalable-ase-demo.trafficmanager.net and associate it with a Traffic Manager profile.

The -TrafficRoutingMethod parameter defines the load-balancing policy Traffic Manager uses to determine how to distribute customer load across all available endpoints. The sample app uses the Weighted method. Customer requests distribute across all registered application endpoints based on the relative weights associated with each endpoint.

Add app instances to the profile

The next step is to add each app instance to the profile as a native Azure endpoint. The following code fetches a reference to each front-end web app. It then adds each app as a Traffic Manager endpoint through the -TargetResourceId parameter.

$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

Notice the Add-AzureTrafficManagerEndpointConfig command for each individual app instance. The -TargetResourceId parameter in each command references one of the three deployed app instances. The Traffic Manager profile distributes the load across all three endpoints registered in the profile.

All three endpoints use the same value (10) for the -Weight parameter. Traffic Manager distributes the customer requests across all three app instances, as evenly as possible.

For more information, see Use PowerShell to manage Traffic Manager.

Custom domain connection with Traffic Manager

After you configure the profile and add instances, you can point the custom domain of the app at the Traffic Manager domain. The sample app points the www.asabuludemo.com custom domain at the Traffic Manager domain, scalable-ase-demo.trafficmanager.net.

In your configuration, complete this task with the domain registrar that manages your custom domain. By using your registrar's domain management tools, create a CNAME record that points the custom domain at the Traffic Manager domain.

You can view your DNS zone configuration in the Azure portal under DNS zone > DNS Management > Recordsets. The following image shows an example of the CNAME configuration:

Register all app instances

After the connection is made, you need to register the custom domain with each individual app instance. If a request reaches an app instance, and the instance has no custom domain registration, the request fails.

In the sample app scenario, the custom domain is www.asabuludemo.com, and each app instance is associated with the custom domain. The following image shows this configuration:

For more information, see Set up an existing custom domain in Azure App Service.

Traffic distribution topology

When all web app instances can reach the Traffic Manager domain, requests for the www.asabuludemo.com site flow through the following sequence. The sequence uses the configuration names for resources in the sample application.

1. A browser or device makes a DNS lookup for the site, www.asabuludemo.com.

2. The CNAME entry at the domain registrar causes the DNS lookup to redirect to Traffic Manager.

3. A DNS lookup is made for the scalable-ase-demo.trafficmanager.net domain against one of the Traffic Manager DNS servers.

4. Based on the load-balancing policy specified in the -TrafficRoutingMethod parameter, Traffic Manager selects one of the configured endpoints. It then returns the FQDN of that endpoint to the browser or device.

5. Because the FQDN of the endpoint is the URL of an app instance that runs on an App Service Environment, the browser or device requests an Azure DNS server to resolve the FQDN to an IP address.

6. The browser or device sends the HTTP/S request to the IP address.

7. The request arrives at one of the app instances running on one of the App Service Environments.

The following image shows a DNS lookup for the sample app's custom domain. It successfully resolves to an app instance that runs on one of the three sample App Service Environments (in this case, the second of the three App Service Environments, fe2ase).

Related content

• Use PowerShell to manage Azure Traffic Manager