Escala distribuída geograficamente com ambientes de Serviço de Aplicativo

  • Artigo

Visão geral

Cenários de aplicativos que exigem escala muito alta podem exceder a capacidade de recursos de computação disponíveis para uma implantação de um aplicativo. Aplicativos de votação, eventos esportivos e de entretenimento televisionados são exemplos de cenários que exigem escala extremamente alta. Os requisitos de alta escala podem ser atendidos por meio da expansão horizontal de aplicativos. Para lidar com requisitos de carga extrema, muitas implantações de aplicativo podem ser feitas em uma região e entre regiões.

Os Ambientes do Serviço de Aplicativo são uma plataforma ideal para expansão horizontal. Ao selecionar uma configuração de Ambiente do Serviço de Aplicativo compatível com uma taxa de solicitação conhecida, os desenvolvedores poderão implantar Ambientes do Serviço de Aplicativo adicionais em massa para obter uma capacidade de carga de pico desejada.

Por exemplo, suponha que um aplicativo em execução em uma configuração de Ambiente do Serviço de Aplicativo foi testado para manipular 20 mil RPS (solicitações por segundo). Se a capacidade de carga de pico desejada é de cem mil RPS, cinco (5) Ambientes do Serviço de Aplicativo podem ser criados e configurados para garantir que o aplicativo possa lidar com a carga máxima prevista.

Já que os clientes normalmente acessam aplicativos usando um domínio personalizado, os desenvolvedores precisam ter uma maneira de distribuir solicitações de aplicativo entre todas as instâncias do Ambiente de Serviço de Aplicativo. Uma ótima maneira de alcançar essa meta é resolver o domínio personalizado usando um perfil do Gerenciador de Tráfego do Azure. O perfil do Gerenciador de Tráfego pode ser configurado para apontar para todos os Ambientes de Serviço de Aplicativo individuais. O Gerenciador de Tráfego manipulará automaticamente a distribuição de clientes em todos os Ambientes do Serviço de Aplicativo baseado nas configurações de balanceamento de carga no perfil do Gerenciador de Tráfego. Essa abordagem funciona independentemente de todos os Ambientes de Serviço de Aplicativo serem implantados em uma única região do Azure ou distribuídos pelo mundo todo em várias regiões do Azure.

Além disso, uma vez que os clientes acessam aplicativos usando o domínio personalizado, eles não estão cientes do número de Ambientes de Serviço de Aplicativo que estão executando um aplicativo. Sendo assim, os desenvolvedores podem adicionar e remover Ambientes de Serviço de Aplicativo rápida e facilmente baseados na carga de tráfego observada.

O diagrama conceitual abaixo mostra um aplicativo escalado horizontalmente em três Ambientes de Serviço de Aplicativo dentro de uma única região.

Conceptual architecture diagram of geo-distributed app service with Traffic Manager.

O restante deste tópico explica as etapas envolvidas na configuração de uma topologia distribuída para o aplicativo de exemplo usando vários Ambientes de Serviço de Aplicativo.

Planejando a topologia

Antes de criar uma superfície de aplicativo distribuído, é bom ter algumas informações prévias.

  • Domínio personalizado para o aplicativo: qual é o nome de domínio personalizado que os clientes usarão para acessar o aplicativo? Para o aplicativo de exemplo, o nome de domínio personalizado é www.asabuludemo.com.
  • Domínio do Gerenciador de Tráfego: escolha um nome de domínio ao criar um perfil do Gerenciador de Tráfego do Azure. Esse nome será combinado com o sufixo trafficmanager.net para registrar uma entrada de domínio gerenciada pelo Gerenciador de Tráfego. Para o aplicativo de exemplo, o nome escolhido é scalable-ase-demo. Assim, o nome de domínio completo gerenciado pelo Gerenciador de Tráfego é scalable-ase-demo.trafficmanager.net.
  • Estratégia para escalonar a superfície do aplicativo: a superfície do aplicativo será distribuída em vários Ambientes de Serviço de Aplicativo em uma única região? Várias regiões? Uma combinação de ambas as abordagens? A decisão deve se basear nas expectativas da origem de tráfego do cliente e em quão bem o restante da infraestrutura de back-end de suporte de um aplicativo poderá ser escalonada. Por exemplo, com um aplicativo 100% sem estado, ele pode ser massivamente escalonado usando uma combinação de muitos Ambientes do Serviço de Aplicativo em cada região do Azure, multiplicado por Ambientes do Serviço de Aplicativo implantados em muitas regiões do Azure. Com mais de 15 regiões globais do Azure disponíveis para escolha, os clientes podem realmente criar uma superfície de aplicativo de hiperescala mundial. Para o aplicativo de exemplo usado neste artigo, três Ambientes do Serviço de Aplicativo foram criados em uma região do Azure (Centro-Sul dos EUA).
  • Convenção de nomenclatura para os Ambientes de Serviço de Aplicativo: cada Ambiente de Serviço de Aplicativo requer um nome exclusivo. Além de um ou dois Ambientes do Serviço de Aplicativo, é útil ter uma convenção de nomenclatura para ajudar a identificar cada Ambiente. Para o aplicativo de exemplo, foi usada uma convenção de nomenclatura simples. Os nomes dos três Ambientes de Serviço de Aplicativo são fe1ase, fe2ase e fe3ase.
  • Convenção de nomenclatura para os aplicativos: como várias instâncias do aplicativo serão implantadas, é necessário um nome para cada instância do aplicativo implantado. Um recurso pouco conhecido, mas conveniente dos Ambientes do Serviço de Aplicativo é que o mesmo nome de aplicativo pode ser usado em vários Ambientes do Serviço de Aplicativo. Como cada Ambiente do Serviço de Aplicativo tem um sufixo de domínio exclusivo, os desenvolvedores podem optar por reutilizar o mesmo nome de aplicativo em cada ambiente. Por exemplo um desenvolvedor poderia ter aplicativos nomeados da seguinte forma: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net etc. No entanto, no caso do aplicativo de exemplo, cada instância de aplicativo também tem um nome exclusivo. Os nomes de instância de aplicativo usados são webfrontend1, webfrontend2 e webfrontend3.

Configurando o perfil do Gerenciador de Tráfego

Quando várias instâncias de um aplicativo são implantadas em vários Ambientes de Serviço de Aplicativo, as instâncias de aplicativos individuais podem ser registradas com o Gerenciador de Tráfego. Para o aplicativo de exemplo, um perfil do Gerenciador de Tráfego é necessário para scalable-ase-demo.trafficmanager.net que seja capaz de rotear os clientes para uma das seguintes instâncias de aplicativo implantadas:

  • webfrontend1.fe1ase.p.azurewebsites.net: uma instância do aplicativo de exemplo implantada no primeiro Ambiente de Serviço de Aplicativo.
  • webfrontend2.fe2ase.p.azurewebsites.net: uma instância do aplicativo de exemplo implantada no segundo Ambiente de Serviço de Aplicativo.
  • webfrontend3.fe3ase.p.azurewebsites.net: uma instância do aplicativo de exemplo implantada no terceiro Ambiente de Serviço de Aplicativo.

A maneira mais fácil de registrar vários pontos de extremidade do Serviço de Aplicativo do Azure, todos executados na mesma região do Azure, é com o suporte do Gerenciador de Tráfego ao Azure Resource Manager do PowerShell.

A primeira etapa é a criação de um perfil do Gerenciador de Tráfego do Azure. O código abaixo mostra como o perfil foi criado para o aplicativo de exemplo:

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

Observe como o parâmetro RelativeDnsName foi definido como scalable-ase-demo. Esse parâmetro faz com que o nome de domínio scalable-ase-demo.trafficmanager.net seja criado e associado a um perfil do Gerenciador de Tráfego.

O parâmetro TrafficRoutingMethod define a política de balanceamento de carga que o Gerenciador de Tráfego usará para determinar como distribuir a carga do cliente entre todos os pontos de extremidade disponíveis. Neste exemplo, o método Weighted foi o escolhido. Devido a essa opção, as solicitações do cliente serão distribuídas por todos os pontos de extremidade do aplicativo registrados com base nos pesos relativos associados a cada ponto de extremidade.

Com o perfil criado, cada instância do aplicativo é adicionada ao perfil como um ponto de extremidade do Azure nativo. O código a seguir busca uma referência para cada aplicativo Web de front-end. Em seguida, ele adiciona cada aplicativo como um ponto de extremidade do Gerenciador de Tráfego por meio do parâmetro 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

Observe como não há uma chamada para Add-AzureTrafficManagerEndpointConfig em cada instância do aplicativo individual. O parâmetro TargetResourceId em cada comando do PowerShell faz referência a uma das três instâncias de aplicativo implantadas. O perfil do Gerenciador de Tráfego distribuirá a carga entre todos os três pontos de extremidade registrados no perfil.

Todos os três pontos de extremidade usam o mesmo valor (10) para o parâmetro Weight . Essa situação faz com que o Gerenciador de Tráfego distribua as solicitações de cliente entre todas as três instâncias de aplicativo de maneira quase uniforme.

Apontando o domínio personalizado do aplicativo no domínio do Gerenciador de Tráfego

A última etapa necessária é apontar o domínio personalizado do aplicativo para o domínio do Gerenciador de Tráfego. Para o aplicativo de exemplo, aponte www.asabuludemo.com para scalable-ase-demo.trafficmanager.net. Conclua essa etapa com o registrador de domínios que gerencia o domínio personalizado.

Usando as ferramentas de gerenciamento de seu registrador domínio, um registro CNAME precisa ser criado apontando para o domínio personalizado no domínio do Gerenciador de Tráfego. A figura a seguir mostra um exemplo da aparência dessa configuração CNAME:

Screenshot of configuring CNAME record on DNS.

Embora não seja abordado neste tópico, lembre-se de que cada instância de aplicativo individual precisa ter também o domínio personalizado registrado nele. Caso contrário, se uma solicitação chegar a uma instância de aplicativo e o aplicativo não tiver registrado o domínio personalizado com o aplicativo, a solicitação falhará.

Neste exemplo, o domínio personalizado é www.asabuludemo.com e cada instância de aplicativo tem o domínio personalizado associado a ela.

Screenshot of App Service custom domain setting.

Para uma recapitulação do registro de um domínio personalizado nos aplicativos do Serviço de Aplicativo do Azure, confira registrar domínios personalizados.

Experimentando a topologia distribuída

O resultado final da configuração do Gerenciador de Tráfego e do DNS é que as solicitações ao www.asabuludemo.com fluirão através da seguinte sequência:

  1. Um navegador ou dispositivo fará uma pesquisa de DNS por www.asabuludemo.com
  2. A entrada CNAME no registrador de domínio faz com que a pesquisa de DNS seja redirecionada para o Gerenciador de Tráfego do Azure.
  3. Uma pesquisa de DNS é feita para scalable-ase-demo.trafficmanager.net em um dos servidores DNS do Gerenciador de Tráfego do Azure.
  4. Com base na política de balanceamento de carga especificada anteriormente no parâmetro TrafficRoutingMethod, o Gerenciador de Tráfego seleciona um dos pontos de extremidade configurados. Em seguida, ele retorna o FQDN desse ponto de extremidade para o navegador ou dispositivo.
  5. Já que o FQDN do ponto de extremidade é a URL de uma instância de aplicativo que é executada em um Ambiente do Serviço de Aplicativo, o navegador ou dispositivo solicitará que um servidor DNS do Microsoft Azure resolva o FQDN para um endereço IP.
  6. O navegador ou dispositivo enviará a solicitação HTTP/S para o endereço IP.
  7. A solicitação chegará em uma das instâncias do aplicativo em execução em um dos Ambientes de Serviço do Aplicativo.

A imagem do console abaixo mostra uma pesquisa de DNS para o domínio personalizado do aplicativo de exemplo. Ela é resolvida com êxito em uma instância de aplicativo executada em um dos três Ambientes do Serviço de Aplicativo de exemplo (neste caso, o segundo dos três Ambientes do Serviço de Aplicativo):

Screenshot of DNS lookup result.

Documentação sobre o suporte do Gerenciador de Tráfego ao Azure Resource Manager do PowerShell.

Observação

Se você deseja começar com o Serviço de Aplicativo do Azure antes de se inscrever em uma conta do Azure, acesse Experimentar o Serviço de Aplicativo, em que você pode criar imediatamente um aplicativo Web inicial de curta duração no Serviço de Aplicativo. Nenhum cartão de crédito é exigido, sem compromissos.