Entrada HTTP global crítica para a missão

As aplicações fundamentais para a missão têm de manter um elevado nível de tempo de atividade, mesmo quando os componentes de rede estão indisponíveis ou degradados. Ao conceber a entrada, o encaminhamento e a segurança do tráfego web, pode considerar combinar vários serviços do Azure para alcançar um nível de disponibilidade mais elevado e evitar ter um único ponto de falha.

Se decidir adotar esta abordagem, terá de implementar um caminho de rede separado para os servidores de aplicações e cada caminho tem de ser configurado e testado separadamente. Tem de considerar cuidadosamente todas as implicações desta abordagem.

Este artigo descreve uma abordagem para suportar a entrada de tráfego HTTP global através do Azure Front Door e Gateway de Aplicação do Azure. Esta abordagem poderá adequar-se às suas necessidades se a sua solução precisar:

• Azure Front Door para encaminhamento de tráfego global. Isto pode significar que tem várias instâncias da sua aplicação em regiões separadas do Azure ou que serve todos os utilizadores globais de uma única região.
• Firewall de aplicações Web (WAF) para proteger a sua aplicação, independentemente do caminho que o tráfego segue para chegar aos servidores de origem.

A colocação em cache no limite da rede não é uma parte crítica da entrega da aplicação. Se a colocação em cache for importante, veja Entrega de conteúdos globais fundamentais para uma abordagem alternativa.

Nota

Este caso de utilização faz parte de uma estratégia de design geral que abrange uma abordagem alternativa quando o Azure Front Door está indisponível. Para obter informações sobre o contexto e as considerações, veja Aplicações Web globais fundamentais para a missão.

Abordagem

Esta solução de balanceamento de carga baseada em DNS utiliza vários perfis do Gestor de Tráfego do Azure para monitorizar o Azure Front Door. No caso improvável de um problema de disponibilidade, o Gestor de Tráfego redireciona o tráfego através de Gateway de Aplicação.

A solução inclui os seguintes componentes:

• O Gestor de Tráfego que utiliza o modo de encaminhamento prioritário tem dois pontos finais. Por predefinição, o Gestor de Tráfego envia pedidos através do Azure Front Door. Se o Azure Front Door não estiver disponível, um segundo perfil do Gestor de Tráfego determina onde direcionar o pedido. O segundo perfil é descrito abaixo.

• O Azure Front Door processa e encaminha a maior parte do tráfego da aplicação. O Azure Front Door encaminha o tráfego para o servidor de aplicação de origem adequado e fornece o caminho principal para a sua aplicação. A WAF do Azure Front Door protege a sua aplicação contra ameaças de segurança comuns. Se o Azure Front Door não estiver disponível, o tráfego é redirecionado automaticamente através do caminho secundário.

• O Gestor de Tráfego que utiliza o modo de encaminhamento de desempenho tem um ponto final para cada instância Gateway de Aplicação. Este Gestor de Tráfego envia pedidos para a instância Gateway de Aplicação com o melhor desempenho da localização do cliente.

• Gateway de Aplicação é implementado em cada região e envia tráfego para os servidores de origem nessa região. A WAF do Gateway de Aplicação protege qualquer tráfego que flua através do caminho secundário.

• Os servidores de aplicações de origem têm de estar prontos para aceitar o tráfego do Azure Front Door e do Gateway de Aplicação do Azure, em qualquer altura.

Considerações

As secções seguintes descrevem algumas considerações importantes para este tipo de arquitetura. Também deve rever aplicações Web globais fundamentais para a missão para outras considerações e desvantagens importantes quando utiliza o Azure Front Door numa solução crítica para a missão.

Configuração do Gestor de Tráfego

Esta abordagem utiliza perfis aninhados do Gestor de Tráfego para alcançar o encaminhamento baseado em prioridade e baseado no desempenho em conjunto para o caminho de tráfego alternativo da sua aplicação. Num cenário simples com uma origem numa única região, poderá precisar apenas de um único perfil do Gestor de Tráfego configurado para utilizar o encaminhamento baseado na prioridade.

Distribuição regional

O Azure Front Door é um serviço global, enquanto Gateway de Aplicação é um serviço regional.

Os pontos de presença do Azure Front Door são implementados globalmente e as ligações TCP e TLS terminam no ponto de presença mais próximo do cliente. Este comportamento melhora o desempenho da sua aplicação. Por outro lado, quando os clientes se ligam a Gateway de Aplicação, as respetivas ligações TCP e TLS terminam no Gateway de Aplicação que recebe o pedido, independentemente da origem do tráfego.

Ligações de clientes

Enquanto serviço multi-inquilino global, o Azure Front Door fornece proteção inerente contra uma variedade de ameaças. O Azure Front Door só aceita tráfego HTTP e HTTPS válido e não aceita tráfego noutros protocolos. A Microsoft gere os endereços IP públicos que o Azure Front Door utiliza para as respetivas ligações de entrada. Devido a estas características, o Azure Front Door pode ajudar a proteger a sua origem contra vários tipos de ataques e as suas origens podem ser configuradas para utilizar Private Link conectividade.

Por outro lado, Gateway de Aplicação é um serviço com acesso à Internet com um endereço IP público dedicado. Tem de proteger a rede e os servidores de origem contra vários tipos de ataques. Para obter mais informações, veja Origin security (Segurança da origem).

Private Link ligações a servidores de origem

O Azure Front Door Premium fornece conectividade Private Link às suas origens, o que reduz a área de superfície pública voltada para a Internet da sua solução.

Se utilizar Private Link para ligar às suas origens, considere implementar um ponto final privado na sua rede virtual e configure Gateway de Aplicação para utilizar o ponto final privado como o back-end da sua aplicação.

Dimensionamento

Quando implementa Gateway de Aplicação, implementa recursos de computação dedicados para a sua solução. Se grandes quantidades de tráfego chegarem ao seu Gateway de Aplicação inesperadamente, poderá observar problemas de desempenho ou fiabilidade.

Para mitigar este risco, considere a forma como dimensiona a instância Gateway de Aplicação. Utilize o dimensionamento automático ou certifique-se de que o dimensionou manualmente para processar a quantidade de tráfego que poderá receber depois de efetuar a ativação pós-falha.

Colocação em cache

Se utilizar as funcionalidades de colocação em cache do Azure Front Door, é importante ter em atenção que, após o tráfego mudar para o caminho alternativo e utilizar Gateway de Aplicação, o conteúdo deixa de ser servido a partir das caches do Azure Front Door.

Se depender da colocação em cache da sua solução, veja Entrega de conteúdos globais fundamentais para uma abordagem alternativa que utiliza uma CDN de parceiro como contingência para o Azure Front Door.

Em alternativa, se utilizar a colocação em cache, mas não for uma parte essencial da estratégia de entrega de aplicações, considere se pode aumentar horizontalmente ou aumentar verticalmente as suas origens para fazer face ao aumento da carga causada pelo maior número de falhas de cache durante uma ativação pós-falha.

Vantagens e desvantagens

Este tipo de arquitetura é mais útil se quiser que o seu caminho de tráfego alternativo utilize funcionalidades como regras de processamento de pedidos, waf e descarga de TLS. Tanto o Azure Front Door como o Gateway de Aplicação fornecem capacidades semelhantes.

No entanto, existem desvantagens:

• Complexidade operacional. Quando utiliza qualquer uma destas funcionalidades, tem de as configurar no Azure Front Door e no Gateway de Aplicação. Por exemplo, se fizer uma alteração de configuração à WAF do Azure Front Door, também terá de aplicar a mesma alteração de configuração ao Gateway de Aplicação WAF. A sua complexidade operacional torna-se muito maior quando precisa de reconfigurar e testar dois sistemas separados.

• Paridade de funcionalidades. Embora existam semelhanças entre as funcionalidades que o Azure Front Door e Gateway de Aplicação oferecem, muitas funcionalidades não têm paridade exata. Tenha em atenção estas diferenças, uma vez que podem afetar a forma como a aplicação é fornecida com base no caminho de tráfego que segue.

  Gateway de Aplicação não fornece colocação em cache. Para obter mais informações sobre esta diferença, consulte Colocação em cache.

  O Azure Front Door e Gateway de Aplicação são produtos distintos e têm casos de utilização diferentes. Em particular, os dois produtos são diferentes na forma como são implementados nas regiões do Azure. Certifique-se de que compreende os detalhes de cada produto e como os utiliza.

• Custo. Normalmente, tem de implementar uma instância Gateway de Aplicação em cada região onde tem uma origem. Uma vez que cada Gateway de Aplicação instância é faturada separadamente, o custo pode tornar-se elevado quando tiver origens implementadas em várias regiões.

  Se o custo for um fator significativo para a sua solução, veja Entrega de conteúdos globais fundamentais para a missão para uma abordagem alternativa que utiliza uma rede de entrega de conteúdos (CDN) de parceiro como contingência para o Azure Front Door. Algumas CDNs faturam o tráfego numa base de consumo, pelo que esta abordagem pode ser mais económica. No entanto, poderá perder algumas das outras vantagens de utilizar Gateway de Aplicação para a sua solução.

  Em alternativa, pode considerar implementar uma arquitetura alternativa em que o Gestor de Tráfego pode encaminhar o tráfego diretamente para serviços de aplicações paaS (plataforma como serviço), evitando a necessidade de Gateway de Aplicação e reduzindo os custos. Pode considerar esta abordagem se utilizar um serviço como o Serviço de Aplicações do Azure ou o Azure Container Apps para a sua solução. No entanto, se seguir esta abordagem, existem várias desvantagens importantes a considerar:

  • WAF: O Azure Front Door e Gateway de Aplicação ambos fornecem capacidades waf. Se expor os seus serviços de aplicação diretamente na Internet, poderá não conseguir proteger a sua aplicação com uma WAF.
  • Descarga de TLS: O Azure Front Door e Gateway de Aplicação ambas as ligações TLS terminam. Os serviços da aplicação têm de ser configurados para terminar as ligações TLS.
  • Encaminhamento: Tanto o Azure Front Door como o Gateway de Aplicação efetuam o encaminhamento em várias origens ou back-ends, incluindo o encaminhamento baseado no caminho, e suportam regras de encaminhamento complexas. Se os serviços da aplicação forem expostos diretamente à Internet, não poderá efetuar o encaminhamento de tráfego.

Aviso

Se considerar expor a sua aplicação diretamente na Internet, crie um modelo de ameaças completo e certifique-se de que a arquitetura cumpre os seus requisitos de segurança, desempenho e resiliência.

Se utilizar máquinas virtuais para alojar a sua solução, não deve expor as máquinas virtuais à Internet.

Passos seguintes

Reveja o cenário global de entrega de conteúdos para compreender se se aplica à sua solução.