Métodos de roteamento de tráfego para a origem

Aplica-se a: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (clássico)

Importante

O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante que você migre seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Desativação do Azure Front Door (clássico).

O Azure Front Door é compatível com quatro métodos de roteamento de tráfego para gerenciar como o tráfego HTTP/HTTPS é distribuído entre diferentes origens. Quando as solicitações do usuário chegam aos locais de borda do Front Door, o método de roteamento configurado garante que elas sejam encaminhadas para o melhor recurso de back-end.

Observação

Neste artigo, uma Origem refere-se ao backend e um grupo de origem refere-se ao conjunto de backends na configuração do Azure Front Door (versão clássica).

Os quatro métodos de roteamento de tráfego são:

• Latência: encaminha as solicitações para origens com a menor latência em uma faixa de sensibilidade aceitável, o que garante que as solicitações sejam enviadas para as origens mais próximas em termos de latência de rede.

• Prioridade: permite a definição de uma prioridade para as origens por meio da designação de uma origem primária para lidar com todo o tráfego e de uma secundária para atuar como backup em caso de indisponibilidade na primária.

• Ponderado: atribui um peso a cada origem para distribuir o tráfego uniformemente ou de acordo com coeficientes de peso especificados. O tráfego será distribuído com base em valores de peso se as latências das origens estiverem na faixa de sensibilidade aceitável.

• Afinidade de sessão: garante que as solicitações do mesmo usuário final sejam enviadas à mesma origem por meio da configuração da afinidade de sessão para domínios ou hosts de front-end.

Observação

Nas camadas Standard e Premium do Azure Front Door, o nome do ponto de extremidade é denominado host de front-end no Azure Front Door (clássico).

Todas as configurações do Front Door incluem monitoramento de integridade de back-end e failover global automatizado. Para obter mais informações, saiba mais em Monitoramento de back-end do Front Door. O Azure Front Door pode usar um único método de roteamento ou combinar diversos para criar uma topologia de roteamento ideal com base nas necessidades do aplicativo.

Observação

Usando o mecanismo de regras Front Door, você pode configurar regras para substituir as configurações de rota nas camadas Azure Front Door Standard e Premium ou substituir o pool de back-end no Azure Front Door (clássico) para uma solicitação. O grupo de origem ou pool de back-end definido pelo mecanismo de regras substitui o processo de roteamento descrito neste artigo.

Fluxo de decisão geral

Este diagrama mostra o fluxo de decisão geral:

As etapas de decisão são:

1. Origens disponíveis: selecione todas as origens habilitadas e consideradas íntegras (200 OK) com base na investigação de integridade.
   • Exemplo: Se houver seis origens A, B, C, D, E e F, e C estiver com problemas e E estiver desabilitada, as origens disponíveis são A, B, D e F.
2. Prioridade: selecione as origens de maior prioridade entre as disponíveis.
   • Exemplo: se as origens A, B e D tiverem prioridade 1 e a origem F tiver prioridade 2, as origens selecionadas serão A, B e D.
3. Sinal de latência (com base na investigação de integridade): selecione origens dentro do intervalo de latência permitido no ambiente do Front Door na qual a solicitação chegou. Esse intervalo baseia-se na configuração de sensibilidade de latência do grupo de origem e na latência das origens mais próximas.
   • Exemplo: se a latência para a origem A for 15 ms, para B for 30 ms e para D for 60 ms, e a sensibilidade de latência for definida como 30 ms, as origens selecionadas serão A e B porque D excede o intervalo de 30 ms.
4. Pesos: Distribuir o tráfego entre as origens finais selecionadas com base nas especificadas proporções de peso.
   • Exemplo: se a origem A tiver um peso de 3 e a origem B tiver um peso de 7, o tráfego será distribuído como 3/10 para A e como 7/10 para B.

Se você habilitar a afinidade de sessão, a primeira solicitação em uma sessão seguirá o fluxo explicado anteriormente. As solicitações subsequentes vão para a origem selecionada na primeira solicitação.

Roteamento de tráfego baseado em latências mais baixas

Implantar origens em vários locais globais pode aprimorar a capacidade de resposta do aplicativo roteando o tráfego para a origem "mais próxima" dos usuários finais. O método de roteamento baseado em latência é o padrão para as configurações do Azure Front Door. Esse método direciona as solicitações do usuário para a origem com a menor latência de rede, em vez do local geográfico mais próximo, garantindo desempenho ideal.

A arquitetura anycast do Azure Front Door, combinada com o método de roteamento de latência, garante que cada usuário tenha o melhor desempenho com base no local. Cada ambiente do Front Door mede de maneira independente a latência para as origens, o que significa que usuários em diferentes locais são roteados para a origem que oferece o melhor desempenho para o ambiente específico.

Observação

Por padrão, a propriedade de sensibilidade de latência é definida como 0 ms. Com essa configuração, as solicitações são sempre encaminhadas para as origens mais rápidas disponíveis. Os pesos nas origens só entrarão em vigor se duas origens tiverem a mesma latência de rede.

Para saber mais, confira Arquitetura de roteamento do Azure Front Door.

Roteamento de tráfego baseado em prioridade

Para garantir a alta disponibilidade, implante os serviços de backup para assumir se o serviço primário falhar. Essa configuração é conhecida como implantação Ativa/Espera ou Ativa/Passiva. O método de roteamento de tráfego Priority em Azure Front Door ajuda você a implementar esse padrão de failover.

Por padrão, o Azure Front Door roteia o tráfego para as origens com a maior prioridade (menor valor de prioridade). Quando essas origens primárias ficam indisponíveis, ele roteia o tráfego para as origens secundárias (próximo valor de prioridade mais baixo). Esse processo continuará com origens terciárias se as origens primária e secundária não estiverem disponíveis. As sondas de integridade monitoram a disponibilidade das origens com base no status e na integridade configurados.

Configuração de prioridade para origens

Cada origem em seu grupo de origem Azure Front Door tem uma propriedade Priority, que você pode definir como um valor entre 1 e 5. Valores mais baixos indicam prioridade mais alta. Diversas origens podem compartilhar o mesmo valor de prioridade.

Método de roteamento de tráfego ponderado

Observação

Para clientes com RPS muito baixo (solicitações por segundo), devido à natureza de distribuição dos POPs e máquinas AFD, Azure Front Door não pode garantir que os pesos configurados sejam estritamente seguidos e o balanceamento de carga pode parecer desequilibrado.

O método de roteamento de tráfego ponderado distribui o tráfego com base em pesos predefinidos.

Nesse método, você atribui um peso a cada origem no grupo de origem do Azure Front Door. O peso é um inteiro entre 1 e 1.000, com um valor padrão de 50.

O tráfego é distribuído entre as origens disponíveis usando um mecanismo round-robin com base nas taxas de peso especificadas, desde que as origens atendam aos critérios aceitáveis de sensibilidade à latência. Se você definir a sensibilidade de latência como 0 milissegundos, os pesos só entrarão em vigor se duas origens tiverem a mesma latência de rede.

O método ponderado é compatível com diversos cenários:

• Upgrade gradual do aplicativo: roteie uma porcentagem do tráfego para uma nova origem e aumente essa porcentagem gradualmente ao longo do tempo.
• Migração de Aplicativo para Azure: crie um grupo de origens com origens externas e do Azure. Ajuste os pesos para dar preferência a novas origens, aumentando gradualmente a participação no tráfego até que elas gerenciem a maior parte do tráfego e, em seguida, desabilite e remova as origens menos preferidas.
• Explosão de nuvem para capacidade adicional: expanda implantações locais na nuvem adicionando ou habilitando mais origens e especificando a distribuição de tráfego.

Afinidade de sessão

Por padrão, o Azure Front Door encaminha solicitações do mesmo cliente para origens diferentes. No entanto, a afinidade de sessão é útil para aplicativos com estado ou cenários em que solicitações subsequentes do mesmo usuário precisam ser processadas pela mesma origem. Esse recurso garante que a mesma origem gerencie a sessão de um usuário, o que é benéfico para cenários como autenticação de usuário.

O Azure Front Door usa a afinidade de sessão baseada em cookie, em que cookies gerenciados com SHA256 da URL de origem são usados como identificador. Esse método direciona o tráfego subsequente de uma sessão de usuário para a mesma origem.

Você pode habilitar a afinidade de sessão no nível do grupo de origem em camadas Azure Front Door Standard e Premium e no nível do host de front-end em Azure Front Door (clássico) para cada domínio ou subdomínio configurado. Quando você habilita esse recurso, Azure Front Door adiciona cookies chamados ASLBSA e ASLBSACORS à sessão do usuário. Esses cookies ajudam a identificar usuários diferentes mesmo que compartilhem o mesmo endereço IP, o que permite uma distribuição mais uniforme do tráfego entre as origens.

O tempo de vida do cookie corresponde à sessão do usuário, porque o Front Door só aceita cookies de sessão no momento.

Observação

O cookie de sessão do navegador mantém a afinidade de sessão no nível do domínio. Subdomínios no mesmo domínio curinga podem compartilhar afinidade de sessão, desde que o navegador do usuário envie solicitações ao recurso de mesma origem.

Proxies públicos podem interferir na afinidade de sessão porque estabelecer uma sessão exige que o Front Door adicione um cookie de afinidade de sessão à resposta. Essa ação não poderá ser feita se a resposta for em cache, pois interromperia cookies para outros clientes que solicitam o mesmo recurso. Para evitar esse problema, a afinidade de sessão não será estabelecida se a origem enviar uma resposta em cache. Se a sessão já estiver estabelecida, a capacidade de cache da resposta não importará.

A afinidade de sessão é estabelecida nas seguintes circunstâncias além dos cenários padrão que não podem ser armazenados em cache:

• A resposta inclui o cabeçalho Cache-Control com no-store.
• A resposta contém um cabeçalho Authorization válido.
• A resposta é um código de status HTTP 302.

Próximas etapas

• Saiba como criar um Azure Front Door.
• Saiba como o Azure Front Door funciona.