Географически распределенное масштабирование с использованием сред службы приложенийGeo Distributed Scale with App Service Environments

Краткое описаниеOverview

Примечание

Эта статья была изменена и теперь содержит сведения о новом модуле Az для Azure PowerShell.This article has been updated to use the new Azure PowerShell Az module. Вы по-прежнему можете использовать модуль AzureRM, исправления ошибок для которого будут продолжать выпускаться как минимум до декабря 2020 г.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Дополнительные сведения о совместимости модуля Az с AzureRM см. в статье Introducing the new Azure PowerShell Az module (Знакомство с новым модулем Az для Azure PowerShell).To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Инструкции по установке модуля Az см. в статье об установке Azure PowerShell.For Az module installation instructions, see Install Azure PowerShell.

В некоторых сценариях для корректной работы приложения требуется значительно больше вычислительных ресурсов, чем может обеспечить один развернутый экземпляр. Как следствие, необходимо обеспечить высокий уровень масштабируемости.Application scenarios which require very 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 all examples of scenarios that require extremely high scale. Высокого уровня масштабируемости можно добиться за счет горизонтального масштабирования, при котором несколько приложений развертываются в одном или нескольких регионах.High scale requirements can be met by horizontally scaling out apps, with multiple app deployments being made within a single region, as well as across regions, to handle extreme load requirements.

Среды службы приложений — это идеальная платформа для горизонтального масштабирования. После выбора конфигурации Среда службы приложений, которая может поддерживать известную частоту запросов, разработчики могут развернуть дополнительные среды службы приложений в "резчике файлов cookie", чтобы достичь желаемой емкости пиковой нагрузки.App Service Environments are an ideal platform for horizontal scale out. Once an App Service Environment configuration has been selected that can support a known request rate, developers can deploy additional App Service Environments in "cookie cutter" fashion to attain a desired peak load capacity.

Предположим, что для приложения используется конфигурация среды службы приложений, протестированная для обработки 20 тысяч запросов в секунду.For example suppose an app running on an App Service Environment configuration has been tested to handle 20K requests per second (RPS). Если при пиковой нагрузке приложение должно обрабатывать 100 тысяч запросов в секунду, можно создать и настроить пять (5) сред службы приложений, чтобы обеспечить эффективную работу при прогнозируемой максимальной нагрузке.If the desired peak load capacity is 100K RPS, then five (5) App Service Environments can be created and configured to ensure the application can handle the maximum projected load.

Поскольку клиенты обычно обращаются к приложениям, используя именной (личный) домен, разработчикам необходим способ распределения запросов к приложению между всеми экземплярами среды службы приложений.Since customers typically access apps using a custom (or vanity) domain, developers need a way to distribute app requests across all of the App Service Environment instances. Отличный способ сделать это — разрешить личный домен с помощью профиля диспетчера трафика Azure.A great way to accomplish this is to resolve the custom domain using an Azure Traffic Manager profile. Можно настроить профиль диспетчера трафика таким образом, чтобы он указывал на все отдельные среды службы приложений.The Traffic Manager profile can be configured to point at all of the individual App Service Environments. Диспетчер трафика будет автоматически распределять клиентов между средами службы приложений на основе параметров балансировки нагрузки, заданных в профиле диспетчера трафика.Traffic Manager will automatically handle distributing customers across all of the App Service Environments based on the load balancing settings in the Traffic Manager profile. Этот подход работает независимо от того, развернуты среды службы приложений в одном регионе Azure или в нескольких.This approach works regardless of whether all of the App Service Environments are deployed in a single Azure region, or deployed worldwide across multiple Azure regions.

Кроме того, поскольку клиенты обращаются к приложениям через именной домен, они не знают, в скольких средах службы приложений выполняется приложение.Furthermore, since customers access apps through the vanity domain, customers are unaware of the number of App Service Environments running an app. Поэтому разработчики могут быстро добавлять и удалять среды службы приложений в зависимости от ожидаемого трафика.As a result developers can quickly and easily add, and remove, App Service Environments based on observed traffic load.

На следующей схеме представлено приложение, выполняющееся в трех средах службы приложений в одном регионе.The conceptual diagram below depicts an app horizontally scaled out across three App Service Environments within a single region.

Концепция архитектуры

Далее мы рассмотрим действия, связанные с настройкой распределенной топологии приложения. В нашем примере оно будет развернуто в нескольких средах службы приложений.The remainder of this topic walks through the steps involved with setting up a distributed topology for the sample app using multiple App Service Environments.

Планирование топологииPlanning the Topology

Прежде чем построить распределенную топологию приложения, необходимо собрать некоторые сведения.Before building out a distributed app footprint, it helps to have a few pieces information ahead of time.

  • Именной домен приложения. Какое имя домена клиенты будут использовать для доступа к приложению?Custom domain for the app: What is the custom domain name that customers will use to access the app? Для примера приложения имя пользовательского домена — www.scalableasedemo.comFor the sample app the custom domain name is www.scalableasedemo.com
  • Домен диспетчера трафика: При создании профиля диспетчера трафика Azureнеобходимо выбрать доменное имя.Traffic Manager domain: A domain name needs to be chosen when creating an Azure Traffic Manager profile. При регистрации записи домена, используемой диспетчером трафика, к этому имени будет добавлен суффикс trafficmanager.net.This name will be combined with the trafficmanager.net suffix to register a domain entry that is managed by Traffic Manager. В нашем примере приложения используется имя scalable-ase-demo,For the sample app, the name chosen is scalable-ase-demo. поэтому полное имя домена, управляемое диспетчером трафика, — scalable-ase-demo.trafficmanager.net.As a result the full domain name that is managed by Traffic Manager is scalable-ase-demo.trafficmanager.net.
  • Стратегия масштабирования приложения. Как будет распределяться нагрузка между несколькими средами службы приложений? Они будут размещаться в одном регионе,Strategy for scaling the app footprint: Will the application footprint be distributed across multiple App Service Environments in a single region? в нескольких регионах,Multiple regions? или вы будете применять гибридный подход?A mix-and-match of both approaches? Решение должно основываться на предполагаемых источниках клиентского трафика, а также на характеристиках масштабируемости серверной инфраструктуры приложения.The decision should be based on expectations of where customer traffic will originate, as well as how well the rest of an app's supporting back-end infrastructure can scale. Например, приложение, не хранящее сведения о состоянии, можно масштабировать, развернув конфигурацию из нескольких сред службы приложений в одном регионе, а также в нескольких регионах Azure.For example, with a 100% stateless application, an app can be massively scaled using a combination of multiple App Service Environments per Azure region, multiplied by App Service Environments deployed across multiple Azure regions. В настоящее время доступно более 15 открытых регионов Azure, поэтому клиенты могут создать по-настоящему глобальное гипермасштабируемое приложение.With 15+ public Azure regions available to choose from, customers can truly build a world-wide hyper-scale application footprint. Для приложения, рассматриваемого в этой статье, создано три среды службы приложений в одном регионе Azure (центрально-южная часть США).For the sample app used for this article, three App Service Environments were created in a single Azure region (South Central US).
  • Соглашение об именовании для сред службы приложений. Для каждой такой среды требуется уникальное имя.Naming convention for the App Service Environments: Each App Service Environment requires a unique name. Если используется больше двух сред службы приложений, рекомендуется присваивать каждой из них имя на основе соглашения об именовании.Beyond one or two App Service Environments it is helpful to have a naming convention to help identify each App Service Environment. В нашем примере используется простое соглашение об именовании:For the sample app a simple naming convention was used. Среды службы приложений называются fe1ase, fe2ase и fe3ase.The names of the three App Service Environments are fe1ase, fe2ase, and fe3ase.
  • Соглашение об именовании приложений. Так как предполагается развертывание нескольких экземпляров приложения, каждому из них необходимо присвоить уникальное имя.Naming convention for the apps: Since multiple instances of the app will be deployed, a name is needed for each instance of the deployed app. В разных средах службы приложений можно использовать одни и те же имена. Это малоизвестная, но очень полезная особенность сред службы приложений.One little-known but very convenient feature of App Service Environments is that the same app name can be used across multiple App Service Environments. Так как у каждой среды службы приложений есть уникальный доменный суффикс, разработчики могут использовать одно и то же имя приложения во всех средах.Since each App Service Environment has a unique domain suffix, developers can choose to re-use the exact same app name in each environment. Например, разработчик может иметь приложения, названные следующим образом: MyApp.Foo1.p.azurewebsites.NET, MyApp.Foo2.p.azurewebsites.NET, MyApp.foo3.p.azurewebsites.NETи т. д. Для примера приложения каждый экземпляр приложения также имеет уникальное имя.For example a developer could have apps named as follows: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net, etc. For the sample app though each app instance also has a unique name. webfrontend1, webfrontend2 и webfrontend3.The app instance names used are webfrontend1, webfrontend2, and webfrontend3.

Настройка профиля диспетчера трафикаSetting up the Traffic Manager Profile

После развертывания нескольких экземпляров приложения в нескольких средах службы приложений отдельные экземпляры приложения можно зарегистрировать в диспетчере трафика.Once multiple instances of an app are deployed on multiple App Service Environments, the individual app instances can be registered with Traffic Manager. В приложении, рассматриваемом в этой статье, профиль диспетчера трафика используется для перенаправления трафика с scalable-ase-demo.trafficmanager.net на следующие развернутые экземпляры:For the sample app a Traffic Manager profile is needed for scalable-ase-demo.trafficmanager.net that can route customers to any of the following deployed app instances:

  • webfrontend1.fe1ase.p.azurewebsites.net — экземпляр примера приложения, развернутый в первой среде службы приложений;webfrontend1.fe1ase.p.azurewebsites.net: An instance of the sample app deployed on the first App Service Environment.
  • webfrontend2.fe2ase.p.azurewebsites.net — экземпляр примера приложения, развернутый во второй среде службы приложений;webfrontend2.fe2ase.p.azurewebsites.net: An instance of the sample app deployed on the second App Service Environment.
  • webfrontend3.fe3ase.p.azurewebsites.net:  — экземпляр примера приложения, развернутый в третьей среде службы приложений.webfrontend3.fe3ase.p.azurewebsites.net: An instance of the sample app deployed on the third App Service Environment.

Самый простой способ регистрации нескольких конечных точек службы приложений Azure, работающих в одном регионе Azure, — это Поддержка диспетчера трафика PowerShell Azure Resource Manager.The easiest way to register multiple Azure App Service endpoints, all running in the same Azure region, is with the Powershell Azure Resource Manager Traffic Manager support.

Прежде всего необходимо создать профиль диспетчера трафика Azure.The first step is to create an Azure Traffic Manager profile. Ниже приведен код, создающий профиль для нашего примера приложения.The code below shows how the profile was created for the sample app:

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

Обратите внимание, что для параметра relativeDnsName задано значение scalable-ase-demo.Notice how the RelativeDnsName parameter was set to scalable-ase-demo. С помощью этого параметра создается имя домена scalable-ase-demo.trafficmanager.net , которое связывается с профилем диспетчера трафика.This is how the domain name scalable-ase-demo.trafficmanager.net is created and associated with a Traffic Manager profile.

Параметр TrafficRoutingMethod определяет политику балансировки нагрузки, которую диспетчер трафика будет использовать для распределения клиентской нагрузки между всеми доступными конечными точками.The TrafficRoutingMethod parameter defines the load balancing policy Traffic Manager will use to determine how to spread customer load across all of the available endpoints. В этом примере выбран метод Weighted .In this example the Weighted method was chosen. При использовании этого метода клиентские запросы распределяются по всем зарегистрированным конечным точкам приложения на основе веса, связанного с каждой из них.This will result in customer requests being spread across all of the registered application endpoints based on the relative weights associated with each endpoint.

После создания профиля каждый экземпляр приложения добавляется в профиль как собственная конечная точка Azure.With the profile created, each app instance is added to the profile as a native Azure endpoint. Приведенный ниже код получает ссылку на каждое интерфейсное веб-приложение, а затем добавляет каждое приложение как конечную точку диспетчера трафика с помощью параметра TargetResourceId .The code below fetches a reference to each front end web app, and then adds each app as a Traffic Manager endpoint by way of the TargetResourceId parameter.

$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzureTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10

$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzureTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10

$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzureTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10

Set-AzureTrafficManagerProfile –TrafficManagerProfile $profile

Обратите внимание, что для каждого экземпляра приложения используется один вызов Add-AzureTrafficManagerEndpointConfig .Notice how there is one call to Add-AzureTrafficManagerEndpointConfig for each individual app instance. Параметр TargetResourceId в каждой команде PowerShell ссылается на один из трех экземпляров развернутого приложения.The TargetResourceId parameter in each Powershell command references one of the three deployed app instances. Профиль диспетчера трафика будет распределять нагрузку на все три конечные точки, зарегистрированные в профиле.The Traffic Manager profile will spread load across all three endpoints registered in the profile.

Для всех трех конечных точек используется одно и то же значение параметра Weight (10),All of the three endpoints use the same value (10) for the Weight parameter. поэтому диспетчер трафика распределяет клиентские запросы между всеми тремя экземплярами приложения относительно равномерно.This results in Traffic Manager spreading customer requests across all three app instances relatively evenly.

Перенаправление трафика с именного домена приложения на домен диспетчера трафикаPointing the App's Custom Domain at the Traffic Manager Domain

В заключение необходимо настроить разрешение именного домена приложения в домен диспетчера трафика.The final step necessary is to point the custom domain of the app at the Traffic Manager domain. Для примера приложения это означает указание www.scalableasedemo.com в scalable-ase-demo.trafficmanager.net.For the sample app this means pointing www.scalableasedemo.com at scalable-ase-demo.trafficmanager.net. Этот шаг выполняется в регистраторе доменов, который управляет именным доменом.This step needs to be completed with the domain registrar that manages the custom domain.

Используя средства управления доменом, предоставленными регистратором, необходимо создать записи CNAME, которые будут разрешать именной домен в домен диспетчера трафика.Using your registrar's domain management tools, a CNAME records needs to be created which points the custom domain at the Traffic Manager domain. На рисунке ниже показан пример конфигурации CNAME:The picture below shows an example of what this CNAME configuration looks like:

CNAME для именного домена

Хотя в этой статье мы не рассматриваем регистрацию доменов, помните, что для каждого отдельного экземпляра приложения необходимо также зарегистрировать именной домен.Although not covered in this topic, remember that each individual app instance needs to have the custom domain registered with it as well. Запросы к экземпляру приложения, для которого не зарегистрирован именной домен, будут завершаться ошибкой.Otherwise if a request makes it to an app instance, and the application does not have the custom domain registered with the app, the request will fail.

В этом примере пользовательский домен имеет www.scalableasedemo.com, и каждый экземпляр приложения имеет связанный с ним пользовательский домен.In this example the custom domain is www.scalableasedemo.com, and each application instance has the custom domain associated with it.

Пользовательский домен

Сведения о регистрации пользовательского домена в приложениях службы приложений Azure см. в следующей статье о регистрации пользовательских доменов.For a recap of registering a custom domain with Azure App Service apps, see the following article on registering custom domains.

Тестирование распределенной топологииTrying out the Distributed Topology

Конечным результатом настройки диспетчера трафика и DNS является то, что запросы к www.scalableasedemo.com будут проходить по следующей последовательности:The end result of the Traffic Manager and DNS configuration is that requests for www.scalableasedemo.com will flow through the following sequence:

  1. Браузер или устройство будет выполнять поиск DNS для www.scalableasedemo.comA browser or device will make a DNS lookup for www.scalableasedemo.com
  2. Запись CNAME у регистратора домена перенаправляет запрос на диспетчер трафика Azure.The CNAME entry at the domain registrar causes the DNS lookup to be redirected to Azure Traffic Manager.
  3. Поиск scalable-ase-demo.trafficmanager.net выполняется на одном из DNS-серверов диспетчера трафика Azure.A DNS lookup is made for scalable-ase-demo.trafficmanager.net against one of the Azure Traffic Manager DNS servers.
  4. На основе политики балансировки нагрузки (параметр TrafficRoutingMethod , который использовался при создании профиля диспетчера трафика) диспетчер трафика выбирает одну из настроенных конечных точек и возвращает ее полное доменное имя браузеру или устройству.Based on the load balancing policy (the TrafficRoutingMethod parameter used earlier when creating the Traffic Manager profile), Traffic Manager will select one of the configured endpoints and return the FQDN of that endpoint to the browser or device.
  5. Так как полное доменное имя конечной точки является URL-адресом экземпляра приложения, выполняющегося в среде службы приложений, браузер или устройство отправляет DNS-серверу Microsoft Azure запрос на разрешение полного доменного имени в IP-адрес.Since the FQDN of the endpoint is the Url of an app instance running on an App Service Environment, the browser or device will ask a Microsoft Azure DNS server to resolve the FQDN to an IP address.
  6. Браузер или устройство отправляет HTTP- или HTTPS-запрос на этот IP-адрес.The browser or device will send the HTTP/S request to the IP address.
  7. Запрос поступает на один из экземпляров приложения, выполняющийся в одной из сред службы приложений.The request will arrive at one of the app instances running on one of the App Service Environments.

На изображении окна консоли показано, как в результате поиска именного домена в DNS для нашего примера приложения выполняется разрешение на экземпляр приложения, выполняющийся в одной из трех сред службы приложений (в данном случае второй из трех сред службы приложений).The console picture below shows a DNS lookup for the sample app's custom domain successfully resolving to an app instance running on one of the three sample App Service Environments (in this case the second of the three App Service Environments):

Поиск в DNS

Документация по PowerShell Azure Resource Manager поддержки диспетчера трафика.Documentation on the Powershell Azure Resource Manager Traffic Manager support.

Примечание

Если вы хотите приступить к работе со службой приложений Azure до создания учетной записи Azure, перейдите к разделу Пробное использование службы приложений, где вы можете быстро создать кратковременное веб-приложение начального уровня в службе приложений.If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you can immediately create a short-lived starter web app in App Service. Никаких кредитных карт и обязательств.No credit cards required; no commitments.