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

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

Importante

Azure Front Door (clássico) não oferece suporte à criação de perfis, à integração de novos domínios ou aos certificados gerenciados e será desativado em 31 de março de 2027. Para evitar a interrupção do serviço, igrate para Azure Front Door Standard ou Premium. Para obter mais informações, consulte Azure Front Door (clássico) de aposentadoria.

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 se refere ao back-end, e um grupo de origem se refere ao pool de back-ends na configuração do Azure Front Door (clássico).

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 (clássico), o nome do ponto de extremidade é host de front-end.

Todas as configurações do Front Door incluem monitoramento de integridade do back-end e failover global automatizado. Para obter mais informações, confira 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 do Front Door, você pode configurar regras para substituir configurações de rota nos níveis Standard e Premium do Azure Front Door 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:

Diagrama explicando como as origens são selecionadas com base nas configurações de prioridade, latência e peso no Azure Front Door.

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 sonda de integridade): seleciona origens dentro do intervalo de latência permitido do ambiente Front Door onde 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 investigações 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 (solicitações por segundo) muito baixo, devido à natureza da distribuição dos POPs e máquinas do AFD, o Azure Front Door não pode garantir que os pesos configurados sejam seguidos rigorosamente 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 de rodízio baseado nas proporções de peso especificadas, desde que as origens atendam à sensibilidade de latência aceitável. 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.
  • Expansão para a nuvem para capacidade adicional: expanda as implantações locais para a 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 do 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 a afinidade de sessão, desde que o navegador do usuário envie solicitações ao mesmo recurso de 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 armazenável 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