Entrada HTTP global crítica

Os aplicativos críticos precisam manter um alto nível de tempo de atividade, mesmo quando os componentes de rede estão indisponíveis ou prejudicados. Ao projetar a entrada, o roteamento e a segurança do tráfego da Web, você pode considerar a combinação de vários serviços do Azure para obter um nível mais alto de disponibilidade e evitar ter um único ponto de falha.

Caso opte por adotar essa abordagem, você precisará implementar um caminho de rede separado para seus servidores de aplicativos, e cada caminho precisará ser configurado e testado separadamente. É preciso considerar cuidadosamente todas as implicações dessa abordagem.

Este artigo descreve uma abordagem para dar suporte à entrada de tráfego HTTP global por meio do Azure Front Door e do Gateway de Aplicativo do Azure. Essa abordagem pode atender às suas necessidades se a solução precisar do:

• Azure Front Door para roteamento de tráfego global. Isso pode significar que você tem várias instâncias do seu aplicativo em regiões separadas do Azure ou que atende a todos os usuários globais em uma única região.
• WAF (Firewall de Aplicativo Web) para proteger seu aplicativo, independentemente do caminho que seu tráfego segue para chegar aos servidores de origem.

O armazenamento em cache na borda da rede não é parte crítica da entrega do aplicativo. Se o cache for importante, confira Entrega de conteúdo global crítico, para ver uma abordagem alternativa.

Abordagem

Essa solução de balanceamento de carga baseada em DNS usa vários perfis do Gerenciador de Tráfego do Azure para monitorar o Azure Front Door. No caso improvável de um problema de disponibilidade, o Gerenciador de Tráfego redireciona o tráfego por meio do Gateway de Aplicativo.

A solução inclui os seguintes componentes:

• O Gerenciador de Tráfego que usa o modo de roteamento prioritário tem dois pontos de extremidade. Por padrão, o Gerenciador de Tráfego envia solicitações por meio do Azure Front Door. Se o Azure Front Door não estiver disponível, um segundo perfil do Gerenciador de Tráfego determinará para onde direcionar a solicitação. O segundo perfil é descrito a seguir.

• O Azure Front Door processa e roteia a maior parte do tráfego do seu aplicativo. O Azure Front Door roteia o tráfego para o servidor de aplicativos de origem apropriado e fornece o caminho principal para seu aplicativo. O WAF do Azure Front Door protege seu aplicativo contra ameaças comuns de segurança. Se o Azure Front Door não estiver disponível, o tráfego será redirecionado automaticamente pelo caminho secundário.

• O Gerenciador de Tráfego usando o modo de roteamento de desempenho tem um ponto de extremidade para cada instância do Gateway de Aplicativo. Esse Gerenciador de Tráfego envia solicitações para a instância do Gateway de Aplicativo com o melhor desempenho do local do cliente.

• O Gateway de Aplicativo é implantado em cada região e envia tráfego para os servidores de origem dentro dessa região. O WAF do Gateway de Aplicativo protege qualquer tráfego que flua pelo caminho secundário.

• Seus servidores de aplicativos de origem precisam estar prontos para aceitar o tráfego do Azure Front Door e do Gateway de Aplicativo do Azure, a qualquer momento.

Considerações

As seções a seguir descrevem algumas considerações importantes para esse tipo de arquitetura. Você também deve examinar Aplicativos Web globais críticos para ver outras considerações e compensações importantes ao usar o Azure Front Door em uma solução crítica.

Configuração do Gerenciador de Tráfego

Essa abordagem usa perfis aninhados do Gerenciador de Tráfego para obter roteamento baseado em prioridade e em desempenho juntos para o caminho de tráfego alternativo do seu aplicativo. Em um cenário simples com uma origem em uma única região, talvez você precise apenas de um único perfil do Gerenciador de Tráfego configurado para usar o roteamento baseado em prioridade.

Distribuição regional

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

Os pontos de presença do Azure Front Door são implantados globalmente, e as conexões TCP e TLS terminam no ponto de presença mais próximo do cliente. Esse comportamento melhora o desempenho do aplicativo. Por outro lado, quando os clientes se conectam ao Gateway de Aplicativo, suas conexões TCP e TLS terminam no Gateway de Aplicativo que recebe a solicitação, independentemente de onde o tráfego se originou.

Conexões de clientes

Como um serviço multilocatário global, o Azure Front Door fornece proteção inerente contra várias ameaças. O Azure Front Door só aceita tráfego HTTP e HTTPS válido e não aceita tráfego em outros protocolos. A Microsoft gerencia os endereços IP públicos que o Azure Front Door usa para suas conexões de entrada. Devido a essas características, o Azure Front Door pode ajudar a proteger sua origem contra vários tipos de ataque, e suas origens podem ser configuradas para usar a conectividade de Link Privado.

Por outro lado, o Gateway de Aplicativo é um serviço voltado para a Internet com um endereço IP público dedicado. Você deve proteger sua rede e os servidores de origem contra uma variedade de tipos de ataque. Para obter mais informações, confira Segurança da origem.

Conexão de Link Privado com servidores de origem

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

Se você usar o Link Privado para se conectar às suas origens, considere implantar um ponto de extremidade privado em sua rede virtual e configure o Gateway de Aplicativo para usar o ponto de extremidade privado como o back-end do seu aplicativo.

Scaling

Ao implantar o Gateway de Aplicativo, você implanta recursos de computação dedicados para sua solução. Se grandes quantidades de tráfego chegarem ao seu Gateway de Aplicativo inesperadamente, você poderá observar problemas de desempenho ou confiabilidade.

Para reduzir esse risco, considere como dimensionar sua instância do Gateway de Aplicativo. Use o dimensionamento automático ou certifique-se de dimensioná-lo manualmente para lidar com a quantidade de tráfego que você pode receber após o failover.

Cache

Se você usa os recursos de cache do Azure Front Door, é importante estar ciente de que, depois que o tráfego muda para o caminho alternativo e usa o Gateway de Aplicativo, o conteúdo não é mais servido a partir dos caches do Azure Front Door.

Se você depende do cache para sua solução, confira Entrega de conteúdo global crítico para ver uma abordagem alternativa que use uma CDN de parceiro como fallback para o Azure Front Door.

Como alternativa, se você usa o cache, mas ele não é uma parte essencial da sua estratégia de entrega de aplicativos, verifique se é possível expandir vertical ou horizontalmente suas origens para lidar com o aumento da carga causado pelo maior número de perda de cache durante um failover.

Compensações

Esse tipo de arquitetura será mais útil caso queira que seu caminho de tráfego alternativo use recursos como regras de processamento de solicitação, um WAF e descarregamento de TLS. O Azure Front Door e o Gateway de Aplicativo fornecem funcionalidades semelhantes.

No entanto, há desvantagens:

• Complexidade operacional. Ao usar qualquer um desses recursos, você precisa configurá-los no Azure Front Door e no Gateway de Aplicativo. Por exemplo, se você fizer uma alteração de configuração no WAF do Azure Front Door, também precisará aplicar a mesma alteração de configuração ao WAF do Gateway de Aplicativo. Sua complexidade operacional se torna muito maior quando você precisa reconfigurar e testar dois sistemas separados.

• Paridade de recursos. Embora haja semelhanças entre os recursos que o Azure Front Door e o Gateway de Aplicativo oferecem, muitos recursos não têm paridade exata. Esteja atento a essas diferenças, pois elas podem afetar a forma como o aplicativo é entregue com base no caminho de tráfego que ele segue.

  O Gateway de Aplicativo não fornece cache. Para obter mais informações sobre essa diferença, confira Cache.

  O Azure Front Door e o Gateway de Aplicativo são produtos distintos e têm casos de uso diferentes. Particularmente, os dois produtos são diferentes na forma como são implantados nas regiões do Azure. Certifique-se de entender os detalhes de cada produto e como você os usa.

• Custo. Normalmente, é preciso implantar uma instância do Gateway de Aplicativo em cada região onde você tem uma origem. Como cada instância do Gateway de Aplicativo é cobrada separadamente, o custo pode se tornar alto quando você tem origens implantadas em várias regiões.

  Se o custo for um fator significativo para sua solução, confira Entrega de conteúdo global crítico para ver uma abordagem alternativa que use uma CDN (rede de distribuição de conteúdo) de parceiro como fallback para o Azure Front Door. Algumas CDNs cobram pelo tráfego com base no consumo. Portanto, essa abordagem pode ser mais econômica. No entanto, você pode perder algumas das outras vantagens de usar o Gateway de Aplicativo para sua solução.

  Como alternativa, você pode considerar a implantação de uma arquitetura alternativa em que o Gerenciador de Tráfego possa rotear o tráfego diretamente para serviços de aplicativos PaaS (plataforma como serviço), evitando a necessidade do Gateway de Aplicativo e reduzindo seus custos. Essa abordagem poderá ser considerada se você usar um serviço como o Serviço de Aplicativo do Azure ou os Aplicativos de Contêiner do Azure para sua solução. No entanto, seguindo essa abordagem, é preciso considerar várias desvantagens importantes:

  • WAF: o Azure Front Door e o Gateway de Aplicativo fornecem funcionalidades de WAF. Se você expuser seus serviços de aplicativo diretamente à Internet, talvez não seja possível proteger seu aplicativo com um WAF.
  • Descarregamento de TLS: o Azure Front Door e o Gateway de Aplicativo encerram conexões TLS. Os serviços de aplicativos precisam ser configurados para encerrar conexões TLS.
  • Roteamento: tanto o Azure Front Door quanto o Gateway de Aplicativo executam o roteamento em várias origens ou back-ends, incluindo roteamento baseado em caminho, e dão suporte a regras de roteamento complexas. Se os serviços do aplicativo estiverem expostos diretamente à Internet, você não poderá executar o roteamento de tráfego.

Próximas etapas

Analisar o cenário de entrega de conteúdo global para entender se ele se aplica à sua solução.