Escala Distribuída Geograficamente com Ambientes de Serviço de Aplicações

  • Artigo

Descrição Geral

Os cenários de aplicação que requerem um dimensionamento muito elevado podem exceder a capacidade de recursos de computação disponível para uma única implementação de uma aplicação. As aplicações de voto, eventos desportivos e eventos de entretenimento televisivo são todos exemplos de cenários que requerem uma escala extremamente elevada. Os requisitos de alta escala podem ser cumpridos ao aumentar horizontalmente as aplicações. Para lidar com requisitos de carga extremos, muitas implementações de aplicações podem ser efetuadas numa única região e em várias regiões.

Serviço de Aplicações Ambientes são uma plataforma ideal para aumentar horizontalmente. Depois de selecionar uma configuração Ambiente do Serviço de Aplicações que possa suportar uma taxa de pedidos conhecida, os programadores podem implementar ambientes de Serviço de Aplicações adicionais de forma "corta-cookies" para alcançar uma capacidade de carga de pico pretendida.

Por exemplo, suponha que uma aplicação em execução numa configuração de Ambiente do Serviço de Aplicações foi testada para processar pedidos de 20 mil por segundo (RPS). Se a capacidade de carga máxima pretendida for de 100 K RPS, podem ser criados e configurados cinco (5) Serviço de Aplicações Ambientes para garantir que a aplicação consegue lidar com a carga máxima projetada.

Uma vez que os clientes normalmente acedem a aplicações através de um domínio personalizado (ou de vaidade), os programadores precisam de uma forma de distribuir pedidos de aplicações por todas as instâncias Ambiente do Serviço de Aplicações. Uma excelente forma de alcançar este objetivo é resolver o domínio personalizado com um perfil do Gestor de Tráfego do Azure. O perfil do Gestor de Tráfego pode ser configurado para apontar para todos os Ambientes de Serviço de Aplicações individuais. O Gestor de Tráfego processará automaticamente a distribuição de clientes em todos os Ambientes de Serviço de Aplicações, com base nas definições de balanceamento de carga no perfil do Gestor de Tráfego. Esta abordagem funciona independentemente de todos os Ambientes de Serviço de Aplicações serem implementados numa única região do Azure ou implementados em todo o mundo em várias regiões do Azure.

Além disso, uma vez que os clientes acedem a aplicações através do domínio de vaidade, os clientes desconhecem o número de ambientes de Serviço de Aplicações que executam uma aplicação. Como resultado, os programadores podem adicionar e remover de forma rápida e fácil Serviço de Aplicações Ambientes com base na carga de tráfego observada.

O diagrama conceptual abaixo ilustra uma aplicação horizontalmente reduzida horizontalmente em três ambientes Serviço de Aplicações numa única região.

Diagrama de arquitetura conceptual do serviço de aplicações geograficamente distribuído com o Gestor de Tráfego.

O resto deste tópico explica os passos envolvidos na configuração de uma topologia distribuída para a aplicação de exemplo com vários ambientes de Serviço de Aplicações.

Planear a Topologia

Antes de criar uma pegada de aplicação distribuída, ajuda ter algumas informações antecipadas.

  • Domínio personalizado para a aplicação: Qual é o nome de domínio personalizado que os clientes utilizarão para aceder à aplicação? Para a aplicação de exemplo, o nome de domínio personalizado é www.asabuludemo.com.
  • Domínio do Gestor de Tráfego: Escolha um nome de domínio ao criar um perfil do Gestor de Tráfego do Azure. Este nome será combinado com o sufixo trafficmanager.net para registar uma entrada de domínio gerida pelo Gestor de Tráfego. Para a aplicação de exemplo, o nome escolhido é scalable-ase-demo. Como resultado, o nome de domínio completo gerido pelo Gestor de Tráfego é scalable-ase-demo.trafficmanager.net.
  • Estratégia para dimensionar a pegada da aplicação: A pegada da aplicação será distribuída por vários ambientes de Serviço de Aplicações numa única região? Várias regiões? Uma combinação de ambas as abordagens? Baseie a decisão nas expectativas de onde o tráfego do cliente terá origem e quão bem o resto da infraestrutura de back-end de suporte de uma aplicação pode ser dimensionada. Por exemplo, com uma aplicação sem estado a 100%, uma aplicação pode ser dimensionada em grande escala com uma combinação de muitos ambientes de Serviço de Aplicações em cada região do Azure, multiplicado por ambientes Serviço de Aplicações implementados em muitas regiões do Azure. Com mais de 15 regiões globais do Azure disponíveis para escolher, os clientes podem realmente criar uma pegada de aplicação de hiperescamada em todo o mundo. Para a aplicação de exemplo utilizada para este artigo, foram criados três Serviço de Aplicações Ambientes numa única região do Azure (E.U.A. Centro-Sul).
  • Convenção de nomenclatura para ambientes de Serviço de Aplicações: cada Ambiente do Serviço de Aplicações requer um nome exclusivo. Além de um ou dois ambientes de Serviço de Aplicações, é útil ter uma convenção de nomenclatura para ajudar a identificar cada Ambiente do Serviço de Aplicações. Para a aplicação de exemplo, foi utilizada uma convenção de nomenclatura simples. Os nomes dos três ambientes de Serviço de Aplicações são fe1ase, fe2ase e fe3ase.
  • Convenção de nomenclatura para as aplicações: Uma vez que serão implementadas várias instâncias da aplicação, é necessário um nome para cada instância da aplicação implementada. Uma funcionalidade pouco conhecida, mas conveniente, de ambientes de Serviço de Aplicações é que o mesmo nome da aplicação pode ser utilizado em vários Ambientes Serviço de Aplicações. Uma vez que cada Ambiente do Serviço de Aplicações tem um sufixo de domínio exclusivo, os programadores podem optar por reutilizar exatamente o mesmo nome de aplicação em cada ambiente. Por exemplo, um programador pode ter aplicações com o nome seguinte: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net, etc. No entanto, para a aplicação de exemplo, cada instância de aplicação também tem um nome exclusivo. Os nomes de instâncias de aplicações utilizados são webfrontend1, webfrontend2 e webfrontend3.

Configurar o Perfil do Gestor de Tráfego

Assim que várias instâncias de uma aplicação forem implementadas em vários Ambientes de Serviço de Aplicações, as instâncias de aplicações individuais podem ser registadas no Gestor de Tráfego. Para a aplicação de exemplo, é necessário um perfil do Gestor de Tráfego para scalable-ase-demo.trafficmanager.net que possa encaminhar os clientes para qualquer uma das seguintes instâncias de aplicações implementadas:

  • webfrontend1.fe1ase.p.azurewebsites.net: Uma instância da aplicação de exemplo implementada no primeiro Ambiente do Serviço de Aplicações.
  • webfrontend2.fe2ase.p.azurewebsites.net: Uma instância da aplicação de exemplo implementada no segundo Ambiente do Serviço de Aplicações.
  • webfrontend3.fe3ase.p.azurewebsites.net: Uma instância da aplicação de exemplo implementada no terceiro Ambiente do Serviço de Aplicações.

A forma mais fácil de registar vários pontos finais Serviço de Aplicações do Azure, todos em execução na mesma região do Azure, é com o suporte do Gestor de Tráfego do Azure Resource Manager do PowerShell.

O primeiro passo é criar um perfil do Gestor de Tráfego do Azure. O código abaixo mostra como o perfil foi criado para a aplicação de exemplo:

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

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

O parâmetro TrafficRoutingMethod define a política de balanceamento de carga que o Gestor de Tráfego irá utilizar para determinar como distribuir a carga do cliente em todos os pontos finais disponíveis. Neste exemplo, foi escolhido o método Ponderado . Devido a esta opção, os pedidos do cliente serão distribuídos por todos os pontos finais da aplicação registados com base nos pesos relativos associados a cada ponto final.

Com o perfil criado, cada instância de aplicação é adicionada ao perfil como um ponto final nativo do Azure. O código seguinte obtém uma referência a cada aplicação Web de front-end. Em seguida, adiciona cada aplicação como um ponto final do Gestor de Tráfego através 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

Repare como existe uma chamada para Add-AzureTrafficManagerEndpointConfig para cada instância de aplicação individual. O parâmetro TargetResourceId em cada comando do PowerShell referencia uma das três instâncias de aplicações implementadas. O perfil do Gestor de Tráfego irá distribuir a carga pelos três pontos finais registados no perfil.

Todos os três pontos finais utilizam o mesmo valor (10) para o parâmetro Peso . Esta situação faz com que o Gestor de Tráfego espalhe pedidos de clientes em todas as três instâncias da aplicação de forma relativamente uniforme.

Apontar o Custom Domain da Aplicação para o Domínio do Gestor de Tráfego

O último passo necessário é apontar o domínio personalizado da aplicação para o domínio do Gestor de Tráfego. Para a aplicação de exemplo, aponte www.asabuludemo.com para scalable-ase-demo.trafficmanager.net. Conclua este passo com a entidade de registo de domínios que gere o domínio personalizado.

Ao utilizar as ferramentas de gestão de domínios da sua entidade de registo, é necessário criar um registo CNAME que aponte o domínio personalizado no domínio do Gestor de Tráfego. A imagem abaixo mostra um exemplo do aspeto desta configuração CNAME:

Captura de ecrã a mostrar a configuração do registo CNAME no DNS.

Apesar de não estar abrangido neste tópico, lembre-se de que cada instância de aplicação individual também precisa de ter o domínio personalizado registado no mesmo. Caso contrário, se um pedido chegar a uma instância de aplicação e a aplicação não tiver registado o domínio personalizado na aplicação, o pedido falhará.

Neste exemplo, o domínio personalizado é www.asabuludemo.com, e cada instância de aplicação tem o domínio personalizado associado ao mesmo.

Captura de ecrã a mostrar Serviço de Aplicações definição de domínio personalizado.

Para obter uma recapitulação do registo de um domínio personalizado com Serviço de Aplicações do Azure aplicações, veja Registar domínios personalizados.

Experimentar a Topologia Distribuída

O resultado final da configuração do Gestor de Tráfego e do DNS é que os pedidos de www.asabuludemo.com irão fluir através da seguinte sequência:

  1. Um browser ou dispositivo fará uma pesquisa de DNS www.asabuludemo.com
  2. A entrada CNAME na entidade de registo de domínios faz com que a pesquisa DNS seja redirecionada para o Gestor de Tráfego do Azure.
  3. É feita uma pesquisa DNS para scalable-ase-demo.trafficmanager.net num dos servidores DNS do Gestor de Tráfego do Azure.
  4. Com base na política de balanceamento de carga especificada anteriormente no parâmetro TrafficRoutingMethod , o Gestor de Tráfego seleciona um dos pontos finais configurados. Em seguida, devolve o FQDN desse ponto final ao browser ou dispositivo.
  5. Uma vez que o FQDN do ponto final é o URL de uma instância de aplicação que é executada num Ambiente do Serviço de Aplicações, o browser ou dispositivo pedirá a um servidor DNS do Microsoft Azure que resolva o FQDN para um endereço IP.
  6. O browser ou dispositivo enviará o pedido HTTP/S para o endereço IP.
  7. O pedido será recebido numa das instâncias da aplicação em execução num dos Ambientes do Serviço de Aplicações.

A imagem da consola abaixo mostra uma pesquisa DNS para o domínio personalizado da aplicação de exemplo. Resolve com êxito para uma instância de aplicação que é executada num dos três ambientes de Serviço de Aplicações de exemplo (neste caso, o segundo dos três Ambientes de Serviço de Aplicações):

Captura de ecrã a mostrar o resultado da pesquisa de DNS.

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

Nota

Se pretender começar a utilizar o App Service do Azure antes de se inscrever numa conta do Azure, aceda a Experimentar o App Service, onde pode criar de imediato uma aplicação Web de arranque de curta duração no App Service. Sem cartões de crédito; sem compromissos.