Redundância de roteamento global para aplicativos Web críticos

Importante

A projeção de implementações de redundância que lidem com interrupções globais de plataforma para uma arquitetura crítica pode ser complexa e cara. Devido aos possíveis problemas que podem surgir com esse design, considere cuidadosamente as desvantagens.

Na maioria das situações, você não precisará da arquitetura descrita neste artigo.

Os sistemas críticos empenham-se em minimizar os pontos únicos de falha, criando redundância e recursos de autorrecuperação na solução, tanto quanto possível. Qualquer ponto de entrada unificado do sistema pode ser considerado um ponto de falha. Se esse componente sofrer uma interrupção, todo o sistema ficará offline para o usuário. Ao escolher um serviço de roteamento, é importante considerar a confiabilidade do serviço em si.

Na arquitetura de linha de base para um aplicativo crítico, o Azure Front Door foi escolhido em razão de seus SLAs (contratos de nível de serviço) de alto tempo de atividade e um rico conjunto de recursos:

• Roteamento de tráfego para várias regiões em um modelo ativo-ativo
• Failover transparente usando anycast TCP
• Entrega de conteúdo estático de nós de borda usando CDNs (redes de distribuição de conteúdo) integradas
• Bloqueio de acesso não autorizado com o firewall do aplicativo Web integrado

O Front Door foi projetado para fornecer máxima resiliência e disponibilidade não apenas para nossos clientes externos, mas também para várias propriedades da Microsoft. Para obter mais informações sobre os recursos do Front Door, confira Acelerar e proteger seu aplicativo Web com o Azure Front Door.

Os recursos do Front Door são mais do que suficientes para atender à maioria dos requisitos de negócios, no entanto, com qualquer sistema distribuído, espere por falhas. Se os requisitos de negócios exigirem um SLO composto mais alto ou tempo de inatividade zero no caso de uma interrupção, você precisará contar com um caminho alternativo de entrada de tráfego. No entanto, a busca por um SLO mais alto traz custos significativos, sobrecarga operacional e pode reduzir sua confiabilidade geral. Considere cuidadosamente as desvantagens e os possíveis problemas que o caminho alternativo pode introduzir em outros componentes que estão no caminho crítico. Mesmo quando o impacto da indisponibilidade é significativo, a complexidade pode superar o benefício.

Uma abordagem é definir um caminho secundário, com serviços alternativos, que se torna ativo somente quando o Azure Front Door não está disponível. A paridade de recursos com o Front Door não deve ser tratada como um requisito difícil. Priorize os recursos que são imprescindíveis para os fins de continuidade de negócios, mesmo que sejam possivelmente executados em uma capacidade limitada.

Outra abordagem é o uso de tecnologia de terceiros para roteamento global. Essa abordagem exigirá uma implantação ativa-ativa multinuvem com carimbos hospedados em dois ou mais provedores de nuvem. Embora o Azure possa ser efetivamente integrado a outras plataformas de nuvem, essa abordagem não é recomendada devido à complexidade operacional nas diferentes plataformas de nuvem.

Este artigo descreve algumas estratégias para roteamento global usando o Gerenciador de Tráfego do Azure como o roteador alternativo em situações em que o Azure Front Door não está disponível.

Abordagem

Este diagrama de arquitetura mostra uma abordagem geral com vários caminhos de tráfego redundantes.

Com essa abordagem, vamos apresentar vários componentes e fornecer diretrizes que farão alterações significativas associadas à entrega dos aplicativos Web:

1. O Gerenciador de Tráfego do Azure direciona o tráfego para o Azure Front Door ou para o serviço alternativo selecionado.

   O Gerenciador de Tráfego do Azure é um balanceador de carga global baseado em DNS. O registro CNAME do seu domínio aponta para o Gerenciador de Tráfego, que determina o destino com base em como você configura seu método de roteamento. O uso do roteamento prioritário fará com que o tráfego flua pelo Azure Front Door por padrão. O Gerenciador de Tráfego pode alternar automaticamente o tráfego para seu caminho alternativo se o Azure Front Door não estiver disponível.

   Importante

   Essa solução reduz os riscos associados às interrupções do Azure Front Door, mas é suscetível a interrupções do Gerenciador de Tráfego do Azure como um ponto de falha global.

   Você também pode considerar o uso de um sistema de roteamento de tráfego global diferente, como um balanceador de carga global. No entanto, o Gerenciador de Tráfego funciona bem para muitas situações.

2. Você tem dois caminhos de entrada:

   • O Azure Front Door fornece o caminho principal, processa e roteia todo o tráfego do aplicativo.

   • Outro roteador é usado como backup para o Azure Front Door. O tráfego fluirá por esse caminho secundário somente se o Front Door não estiver disponível.

   O serviço específico selecionado para o roteador secundário depende de muitos fatores. Você pode optar por usar serviços nativos do Azure ou serviços de terceiros. Nestes artigos, fornecemos opções nativas do Azure para evitar adição de complexidade operacional extra à solução. Caso opte por serviços de terceiros, você precisará usar vários planos de controle para gerenciar sua solução.

3. Os servidores de aplicativos de origem precisam estar prontos para aceitar o tráfego de qualquer serviço. Considere como você protege o tráfego para sua origem e quais responsabilidades o Front Door e outros serviços upstream apresentam. Certifique-se de que seu aplicativo possa lidar com o tráfego, seja qual for o caminho que ele faça.

Compensações

Embora essa estratégia de mitigação possa tornar o aplicativo disponível durante interrupções da plataforma, há algumas desvantagens significativas. Você deve avaliar os possíveis benefícios em relação aos custos conhecidos e tomar uma decisão informada, pesando se os benefícios valem o que custam.

• Custo financeiro: ao implantar vários caminhos redundantes para seu aplicativo, você precisa considerar o custo de implantação e execução dos recursos. Fornecemos dois cenários de exemplo para casos de uso diferentes, cada um com um perfil de custo diferente.

• Complexidade operacional: sempre que você adiciona componentes extras a sua solução, aumenta a sua sobrecarga de gerenciamento. Qualquer alteração em um componente pode afetar outros componentes.

  Suponha que você decida usar os novos recursos do Azure Front Door. É preciso verificar se o caminho de tráfego alternativo também fornece um recurso equivalente. Em caso negativo, você precisará decidir como lidar com a diferença de comportamento entre os dois caminhos de tráfego. Em aplicativos reais, essas complexidades podem ter um alto custo e representar um grande risco para a estabilidade do sistema.

• Desempenho: esse design requer pesquisas CNAME adicionais durante a resolução de nomes. Na maioria dos aplicativos, essa não é uma preocupação significativa, mas você deve avaliar se o desempenho do aplicativo é afetado pela introdução de camadas adicionais no caminho de entrada.

• Custo de oportunidade: projetar e implementar caminhos de entrada redundantes requer um investimento significativo em engenharia, o que, em última análise, tem um custo de oportunidade para o desenvolvimento de recursos e outras melhorias na plataforma.

Aviso

Se não houver cuidado no design e na implementação de uma solução complexa de alta disponibilidade, você poderá realmente piorar sua disponibilidade. O aumento do número de componentes em sua arquitetura aumenta o número de pontos de falha. Isso também significa que você tem um nível mais alto de complexidade operacional. Quando você adiciona componentes extras, cada alteração feita precisa ser cuidadosamente revisada para entender como ela afeta a solução geral.

Disponibilidade do Gerenciador de Tráfego do Azure

O Gerenciador de Tráfego do Azure é um serviço confiável, mas o contrato de nível de serviço não garante 100% de disponibilidade. Se o Gerenciador de Tráfego não estiver disponível, talvez os usuários não consigam acessar seu aplicativo, mesmo que o Azure Front Door e o serviço alternativo estejam disponíveis. É importante planejar como a solução continuará funcionando nessas circunstâncias.

O Gerenciador de Tráfego retorna respostas de DNS em cache. Se a TTL (vida útil) em seus registros DNS permitir o armazenamento em cache, as interrupções curtas do Gerenciador de Tráfego talvez não sejam motivo de preocupação. Isso ocorre porque os resolvedores DNS downstream podem ter armazenado em cache uma resposta anterior. Você deve se planejar para interrupções prolongadas. Você pode optar por reconfigurar manualmente os servidores DNS para direcionar os usuários para o Azure Front Door se o Gerenciador de Tráfego não estiver disponível.

Consistência do roteamento de tráfego

É importante entender os recursos e funcionalidades do Azure Front Door que você usa e nos quais confia. Ao escolher o serviço alternativo, decida sobre os recursos mínimos necessários e omita outros recursos quando sua solução estiver em um modo degradado.

Ao planejar um caminho de tráfego alternativo, estas perguntas-chave devem ser consideradas:

• Você usa os recursos de cache do Azure Front Door? Se o cache não estiver disponível, seus servidores de origem podem acompanhar o tráfego?
• Você usa o mecanismo de regras do Azure Front Door para executar lógica de roteamento personalizada ou para reescrever solicitações?
• Você usa o WAF (firewall do aplicativo Web) do Azure Front Door para proteger seus aplicativos?
• Você restringe o tráfego com base no endereço IP ou na região geográfica?
• Quem emite e gerencia seus certificados TLS?
• Como você restringe o acesso aos seus servidores de aplicativos de origem para garantir que ele venha pelo Azure Front Door? Você usa o Link Privado ou depende de endereços IP públicos com marcas de serviço e cabeçalhos de identificador?
• Seus servidores de aplicativos aceitam tráfego de qualquer lugar que não seja do Azure Front Door? Se sim, quais protocolos eles aceitam?
• Seus clientes usam o suporte HTTP/2 do Azure Front Door?

WAF (Firewall do aplicativo Web)

Se você usa o WAF do Azure Front Door para proteger seu aplicativo, considere o que acontecerá se o tráfego não passar pelo Azure Front Door.

Se o caminho alternativo também fornecer um WAF, considere as seguintes perguntas:

• Ele pode ser configurado da mesma maneira que o WAF do Azure Front Door?
• Ele precisa ser ajustado e testado de modo independente, para reduzir a probabilidade de detecções de falsos positivos?

Aviso

Você pode optar por não usar o WAF para seu caminho de entrada alternativo. Essa abordagem pode ser considerada para dar suporte ao destino de confiabilidade do aplicativo. No entanto, essa não é uma boa prática e não a recomendamos.

Considere a desvantagem em aceitar tráfego da Internet sem quaisquer verificações. Se um invasor descobrir um caminho de tráfego secundário desprotegido até seu aplicativo, ele poderá enviar tráfego mal-intencionado pelo caminho secundário, mesmo quando o caminho principal incluir um WAF.

É melhor proteger todos os caminhos para seus servidores de aplicativos.

Nomes de domínio e DNS

Seu aplicativo crítico deve usar um nome de domínio personalizado. Você controlará como o tráfego flui para seu aplicativo e reduzirá as dependências a um único provedor.

Também é uma boa prática usar um serviço DNS resiliente e de alta qualidade para seu nome de domínio, como o DNS do Azure. Se os servidores DNS do seu nome de domínio não estiverem disponíveis, os usuários não poderão acessar o serviço.

É recomendável usar vários resolvedores DNS para aumentar ainda mais a resiliência geral.

Encadeamento CNAME

As soluções que combinam o Gerenciador de Tráfego, o Azure Front Door e outros serviços usam um processo de resolução CNAME DNS de várias camadas, também chamado de encadeamento CNAME. Por exemplo, ao resolver seu próprio domínio personalizado, você pode ver cinco ou mais registros CNAME antes que um endereço IP seja retornado.

Adicionar mais links a um encadeamento CNAME pode afetar o desempenho da resolução de nomes DNS. No entanto, as respostas DNS geralmente são armazenadas em cache, o que reduz o impacto no desempenho.

Certificados TLS

Para um aplicativo crítico, é recomendável provisionar e usar seus próprios certificados TLS em vez dos certificados gerenciados fornecidos pelo Azure Front Door. Você reduzirá o número de problemas potenciais com essa arquitetura complexa.

Veja a seguir alguns benefícios:

• Para emitir e renovar certificados TLS gerenciados, o Azure Front Door verifica sua propriedade do domínio. O processo de verificação de domínio pressupõe que os registros CNAME do seu domínio apontam diretamente para o Azure Front Door. Mas, essa suposição muitas vezes não está correta. Emitir e renovar certificados TLS gerenciados no Azure Front Door pode não funcionar tão bem e você aumenta o risco de interrupções devido a problemas de certificado TLS.

• Mesmo que seus outros serviços forneçam certificados TLS gerenciados, talvez eles não consigam verificar a propriedade do domínio.

• Se cada serviço obtiver seus próprios certificados TLS gerenciados independentemente, poderá haver problemas. Por exemplo, talvez os usuários não esperem ver certificados TLS diferentes emitidos por autoridades diferentes, ou com datas de expiração ou impressões digitais diferentes.

No entanto, haverá operações adicionais relacionadas à renovação e atualização de seus certificados antes que eles expirem.

Segurança da origem

Ao configurar sua origem para aceitar apenas tráfego por meio do Azure Front Door, você ganha proteção contra ataques DDoS de camada 3 e camada 4. Como o Azure Front Door responde apenas ao tráfego HTTP válido, isso também ajuda a reduzir sua exposição a muitas ameaças baseadas em protocolo. Se você alterar sua arquitetura para permitir caminhos de entrada alternativos, será preciso avaliar se não houve aumento acidental da exposição de sua origem a ameaças.

Se você usa o Link Privado para se conectar do Azure Front Door ao seu servidor de origem, como o tráfego fluirá pelo caminho alternativo? Você pode usar endereços IP privados para acessar suas origens ou deve usar endereços IP públicos?

Se sua origem usa a marca de serviço Azure Front Door e o cabeçalho X-Azure-FDID para validar que o tráfego fluiu pelo Azure Front Door, considere como suas origens podem ser reconfiguradas para validar que o tráfego fluiu por qualquer um dos caminhos válidos. Você deve testar se não abriu acidentalmente sua origem para o tráfego por outros caminhos, inclusive dos perfis do Azure Front Door de outros clientes.

Ao planejar sua segurança de origem, verifique se o caminho de tráfego alternativo depende do provisionamento de endereços IP públicos dedicados. Isso pode precisar de um processo disparado manualmente para colocar o caminho de backup online.

Se houver endereços IP públicos dedicados, considere se você deve implementar a Proteção contra DDoS do Azure para reduzir o risco de ataques de negação de serviço contra suas origens. Além disso, considere se é preciso implementar o Firewall do Azure ou outro firewall capaz de proteger você contra várias ameaças de rede. Você também pode precisar de mais estratégias de detecção de intrusão. Esses controles podem ser elementos importantes em uma arquitetura de vários caminhos mais complexa.

Modelagem de integridade

A metodologia de design crítico requer um modelo de integridade do sistema que forneça observabilidade geral da solução e de seus componentes. Ao usar vários caminhos de entrada de tráfego, você precisa monitorar a integridade de cada caminho. Se o tráfego for redirecionado para o caminho de entrada secundário, seu modelo de integridade deverá refletir o fato de que o sistema ainda está funcionando, mas que está sendo executado em um estado degradado.

Inclua estas perguntas no design do seu modelo de integridade:

• Como os diferentes componentes da sua solução monitoram a integridade dos componentes downstream?
• Quando os monitores de integridade devem considerar que os componentes downstream não estão íntegros?
• Quanto tempo demora para que uma interrupção seja detectada?
• Depois que uma interrupção é detectada, quanto tempo leva para o tráfego ser roteado para um caminho alternativo?

Há várias soluções de balanceamento de carga global que permitem monitorar a integridade do Azure Front Door e disparar um failover automático para uma plataforma de backup em caso de interrupção. O Gerenciador de Tráfego do Azure é adequado na maioria dos casos. Com o Gerenciador de Tráfego, você configura o monitoramento do ponto de extremidade para monitorar serviços downstream especificando a URL a ser verificada, com que frequência verificar essa URL e quando considerar o serviço downstream não íntegro com base nas respostas da investigação. Em geral, quanto menor o intervalo entre as verificações, menos tempo leva para o Gerenciador de Tráfego direcionar o tráfego por um caminho alternativo para chegar ao servidor de origem.

Se o Front Door não estiver disponível, vários fatores influenciarão por quanto tempo a interrupção afetará seu tráfego, incluindo:

• A TTL (vida útil) em seus registros DNS.
• Com que frequência o Gerenciador de Tráfego executa suas verificações de integridade.
• Quantas investigações com falha o Gerenciador de Tráfego está configurado para ver antes de redirecionar o tráfego.
• Por quanto tempo os clientes e servidores DNS upstream armazenam em cache as respostas DNS do Gerenciador de Tráfego.

Você também precisa determinar quais desses fatores estão sob seu controle e se os serviços upstream além do seu controle podem afetar a experiência do usuário. Por exemplo, mesmo se você usar TTL baixa em seus registros DNS, os caches DNS upstream ainda poderão apresentar respostas obsoletas por mais tempo do que deveriam. Esse comportamento pode exacerbar os efeitos de uma interrupção ou fazer parecer que seu aplicativo não está disponível, mesmo quando o Gerenciador de Tráfego já foi alternado para enviar solicitações para o caminho de tráfego alternativo.

Dica

As soluções críticas exigem abordagens de failover automatizadas sempre que possível. Os processos de failover manuais são considerados lentos para que o aplicativo permaneça responsivo.

Confira: Área de design crítico: modelagem de integridade

Implantação sem tempo de inatividade

Ao planejar como operar uma solução com caminho de entrada redundante, você também deve planejar como implantar ou configurar seus serviços quando eles estiverem degradados. Para a maioria dos serviços do Azure, os SLAs se aplicam ao tempo de atividade do serviço em si, e não às implantações ou operações de gerenciamento. Considere se seus processos de implantação e configuração precisam ser resilientes às interrupções de serviço.

Você também deve considerar o número de planos de controle independentes com os quais precisa interagir para gerenciar a solução. Quando você usa os serviços do Azure, o Azure Resource Manager fornece um plano de controle unificado e consistente. No entanto, se você usar um serviço de terceiros para rotear o tráfego, talvez seja necessário usar um plano de controle separado para configurar o serviço, o que introduz mais complexidade operacional.

Aviso

O uso de vários planos de controle introduz complexidade e risco à sua solução. Cada ponto de diferença aumenta a probabilidade de alguém perder acidentalmente uma definição de configuração ou aplicar configurações diferentes a componentes redundantes. Garanta que seus procedimentos operacionais mitiguem esse risco.

Confira: Área de design crítico: implantação sem tempo de inatividade

Validação contínua

Em uma solução crítica, suas práticas de teste precisam verificar se a solução atende aos seus requisitos, independentemente do caminho seguido pelo tráfego do aplicativo. Considere cada parte da solução e como testá-la para cada tipo de interrupção.

Certifique-se de que seus processos de teste incluam estes elementos:

• Você pode verificar se o tráfego será redirecionado corretamente pelo caminho alternativo quando o caminho principal não estiver disponível?
• Ambos os caminhos podem dar suporte ao nível de tráfego de produção que você espera receber?
• Ambos os caminhos estão adequadamente protegidos, para evitar abrir ou expor vulnerabilidades quando você está em um estado degradado?

Confira: Área de design crítico: validação contínua

Cenários comuns

Eis alguns cenários comuns em que esse design pode ser usado:

• A entrega de conteúdo global geralmente se aplica à entrega de conteúdo estático, mídia e aplicativos de comércio eletrônico de alta escala. Nesse cenário, o cache é uma parte crítica da arquitetura da solução, e falhas no cache podem resultar em desempenho ou confiabilidade significativamente degradados.

• A entrada HTTP global geralmente se aplica a APIs e aplicativos dinâmicos críticos. Nesse cenário, o principal requisito é rotear o tráfego para o servidor de origem de maneira confiável e eficiente. Frequentemente, um WAF é um importante controle de segurança usado nessas soluções.

Aviso

Se não houver cuidado no design e na implementação de uma solução complexa com várias entradas, você poderá realmente piorar sua disponibilidade. O aumento do número de componentes em sua arquitetura aumenta o número de pontos de falha. Isso também significa que você tem um nível mais alto de complexidade operacional. Quando você adiciona componentes extras, cada alteração feita precisa ser cuidadosamente revisada para entender como ela afeta a solução geral.

Próximas etapas

Analisar os cenários de entrada HTTP global e entrega de conteúdo global para entender se eles se aplicam à sua solução