Поделиться через

Географически распределенное масштабирование с использованием Среды службы приложений

  • Статья

Обзор

В некоторых сценариях для корректной работы приложения требуется значительно больше вычислительных ресурсов, чем может обеспечить один развернутый экземпляр. Как следствие, необходимо обеспечить высокий уровень масштабируемости. К примерам таких сценариев относятся проведение голосования, организация спортивных событий и телевизионных трансляций. Высокий уровень масштабируемости можно обеспечить за счет горизонтального масштабирования приложений. При очень высоких требованиях к обслуживанию нагрузки несколько приложений развертываются в одном или нескольких регионах.

Идеальной платформой для горизонтального увеличения масштаба являются среды службы приложений. После того как будет выбрана основная конфигурация сред службы приложений, поддерживающая определенную частоту запросов, разработчики могут при необходимости развернуть дополнительные среды службы приложений, чтобы обеспечить эффективную работу при пиковых нагрузках.

Предположим, что для приложения используется конфигурация среды службы приложений, протестированная для обработки 20 тысяч запросов в секунду. Если при пиковой нагрузке приложение должно обрабатывать 100 тысяч запросов в секунду, можно создать и настроить 5 (пять) сред службы приложений, чтобы обеспечить эффективную работу при прогнозируемой максимальной нагрузке.

Поскольку клиенты обычно обращаются к приложениям, используя именной (личный) домен, разработчикам необходим способ распределения запросов к приложению между всеми экземплярами среды службы приложений. Идеальным решением этой задачи является разрешение личного домена с помощью профиля Диспетчера трафика Azure. Можно настроить профиль диспетчера трафика таким образом, чтобы он указывал на все отдельные среды службы приложений. Диспетчер трафика будет автоматически распределять клиентов между средами службы приложений на основе параметров балансировки нагрузки, заданных в профиле диспетчера трафика. Этот подход работает независимо от того, развернуты среды службы приложений в одном регионе Azure или в нескольких.

Кроме того, поскольку клиенты обращаются к приложениям через именной домен, они не знают, в скольких средах службы приложений выполняется приложение. Поэтому разработчики могут быстро добавлять и удалять среды службы приложений в зависимости от ожидаемого трафика.

На следующей схеме представлено приложение, выполняющееся в трех средах службы приложений в одном регионе.

Схема концептуальной архитектуры геораспределённой службы приложений с диспетчером трафика.

Далее мы рассмотрим действия, связанные с настройкой распределенной топологии приложения. В нашем примере оно будет развернуто в нескольких средах службы приложений.

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

Прежде чем построить распределенную топологию приложения, необходимо собрать некоторые сведения.

  • Именной домен приложения. Какое имя домена клиенты будут использовать для доступа к приложению? В нашем примере используется имя личного домена www.asabuludemo.com.
  • Домен диспетчера трафика. При создании профиля диспетчера трафика Azure нужно выбрать доменное имя. При регистрации записи домена, используемой диспетчером трафика, к этому имени будет добавлен суффикс trafficmanager.net. В нашем примере приложения используется имя scalable-ase-demo, поэтому полное имя домена, управляемое диспетчером трафика, — scalable-ase-demo.trafficmanager.net.
  • Стратегия масштабирования приложения. Как будет распределяться нагрузка между несколькими средами службы приложений? Они будут размещаться в одном регионе, в нескольких регионах, или вы будете применять гибридный подход? Решение должно учитывать предполагаемые источники клиентского трафика, а также масштабируемость серверной инфраструктуры приложения. Например, приложение, работающее без отслеживания состояния, можно масштабировать, развернув конфигурацию из нескольких сред Службы приложений в одном регионе, а также в нескольких регионах Azure. Сейчас доступно более 15 глобальных регионов Azure. Поэтому клиенты могут создать по-настоящему глобальное гипермасштабируемое приложение. Для приложения, рассматриваемого в этой статье, создано три среды службы приложений в одном регионе Azure (центрально-южная часть США).
  • Соглашение об именовании для сред Службы приложений. Для каждой такой среды требуется уникальное имя. Если используется больше двух сред Службы приложений, для их идентификации желательно использовать определенное соглашение об именовании. В нашем примере используется простое соглашение об именовании. Среды службы приложений называются fe1ase, fe2ase и fe3ase.
  • Соглашение об именовании приложений. Так как предполагается развертывание нескольких экземпляров приложения, каждому из них необходимо присвоить уникальное имя. В разных средах службы приложений можно использовать одни и те же имена. Это малоизвестная, но полезная особенность сред службы приложений. Так как у каждой среды Службы приложений есть уникальный доменный суффикс, разработчики могут использовать одно и то же имя приложения во всех средах. Например, разработчик может назвать приложения так: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net и т. п. В приложении, рассматриваемом в этой статье, каждому экземпляру приложения также присвоено уникальное имя. webfrontend1, webfrontend2 и webfrontend3.

Настройка профиля диспетчера трафика

После развертывания нескольких экземпляров приложения в нескольких средах службы приложений отдельные экземпляры приложения можно зарегистрировать в диспетчере трафика. В приложении, рассматриваемом в этой статье, профиль диспетчера трафика используется для перенаправления трафика с scalable-ase-demo.trafficmanager.net на следующие развернутые экземпляры:

  • webfrontend1.fe1ase.p.azurewebsites.net: экземпляр приложения, развернутый в первой среде службы приложений;
  • webfrontend2.fe2ase.p.azurewebsites.net: экземпляр приложения, развернутый во второй среде службы приложений;
  • webfrontend3.fe3ase.p.azurewebsites.net: экземпляр приложения, развернутый в третьей среде службы приложений.

Самый простой способ зарегистрировать несколько конечных точек Службы приложений Azure, работающих в одном и том же регионе Azure, — использовать PowerShell для включения поддержки Диспетчера трафика в Azure Resource Manager.

Прежде всего необходимо создать профиль диспетчера трафика Azure. Ниже приведен код, создающий профиль для нашего примера приложения.

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

Обратите внимание, что для параметра relativeDnsName задано значение scalable-ase-demo. С помощью этого параметра создается имя домена scalable-ase-demo.trafficmanager.net, которое связывается с профилем диспетчера трафика.

Параметр TrafficRoutingMethod определяет политику балансировки нагрузки, которую диспетчер трафика будет использовать для распределения клиентской нагрузки между всеми доступными конечными точками. В этом примере выбран метод Weighted. При использовании этого метода клиентские запросы распределяются по всем зарегистрированным конечным точкам приложения на основе веса, связанного с каждой из них.

После создания профиля каждый экземпляр приложения добавляется в профиль как собственная конечная точка Azure. Приведенный ниже код извлекает ссылку на каждое веб-приложение внешнего интерфейса. Затем каждое приложение добавляется в качестве конечной точки диспетчера трафика с помощью параметра 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

Обратите внимание, что для каждого экземпляра приложения используется один вызов Add-AzureTrafficManagerEndpointConfig . Параметр TargetResourceId в каждой команде PowerShell ссылается на один из трех экземпляров развернутого приложения. Профиль диспетчера трафика будет распределять нагрузку на все три конечные точки, зарегистрированные в профиле.

Для всех трех конечных точек используется одно и то же значение параметра Weight (10), поэтому диспетчер трафика распределяет клиентские запросы между всеми тремя экземплярами приложения относительно равномерно.

Перенаправление трафика с именного домена приложения на домен диспетчера трафика

В заключение необходимо настроить разрешение именного домена приложения в домен диспетчера трафика. В нашем примере приложения перенаправим www.asabuludemo.com на scalable-ase-demo.trafficmanager.net. На этом шаге используется регистратор, управляющий личным доменом.

Используя средства управления доменом, предоставленными регистратором, необходимо создать записи CNAME, которые будут разрешать именной домен в домен диспетчера трафика. На рисунке ниже показан пример конфигурации CNAME:

Снимок экрана: настройка записи CNAME в DNS.

Хотя в этой статье мы не рассматриваем регистрацию доменов, помните, что для каждого отдельного экземпляра приложения необходимо также зарегистрировать именной домен. Запросы к экземпляру приложения, для которого не зарегистрирован личный домен, будут завершаться ошибкой.

В этом примере используется личный домен www.asabuludemo.com, и у каждого экземпляра приложения есть связанный с ним личный домен.

Снимок экрана: Служба приложений параметр личного домена.

См. краткие сведения о регистрации личного домена в приложениях Службы приложений Azure.

Тестирование распределенной топологии

Целью настройки Диспетчера трафика и DNS является перенаправление запросов, отправленных на www.asabuludemo.com, по следующему маршруту:

  1. Браузер или устройство выполняет поиск DNS по www.asabuludemo.com.
  2. Запись CNAME у регистратора домена перенаправляет запрос на диспетчер трафика Azure.
  3. Поиск scalable-ase-demo.trafficmanager.net выполняется на одном из DNS-серверов диспетчера трафика Azure.
  4. В зависимости от политики балансировки нагрузки, указанной ранее в параметре TrafficRoutingMethod, диспетчер трафика выбирает одну из настроенных конечных точек. Затем он возвращает полное доменное имя этой конечной точки браузеру или устройству.
  5. Так как полное доменное имя конечной точки является URL-адресом экземпляра приложения, выполняющегося в среде службы приложений, браузер или устройство отправляет DNS-серверу Microsoft Azure запрос на разрешение полного доменного имени в IP-адрес.
  6. Браузер или устройство отправляет HTTP- или HTTPS-запрос на этот IP-адрес.
  7. Запрос поступает на один из экземпляров приложения, выполняющийся в одной из сред службы приложений.

На изображении консоли ниже показан поиск в DNS для личного домена примера приложения. При этом выполняется разрешение на экземпляр приложения, запущенного в одной из трех сред службы приложений (в данном случае второй из трех сред службы приложений).

Снимок экрана: результат поиска DNS.

См. документацию PowerShell по включению поддержки Диспетчера трафика в Azure Resource Manager.

Примечание

Чтобы приступить к работе со службой приложений Azure до создания учетной записи Azure, перейдите к разделу Пробное использование службы приложений, где вы можете быстро создать кратковременное веб-приложение начального уровня в службе приложений. Никаких кредитных карт и обязательств.