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

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 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 de 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

Ao usar o mecanismo de regras do Front Door, é possível configurar uma regra para substituir as configurações de rota nas camadas Standard e Premium do Azure Front Door ou substituir o pool de back-ends no Azure Front Door (clássico) para uma solicitação. O grupo de origem ou o pool de back-ends 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: imagine que existem seis origens: A, B, C, D, E e F. Dentre elas, C não está íntegra e E está desabilitada.
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 no intervalo de latência permitido do ambiente do Front Door que recebeu a solicitação. Isso se baseia 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: distribua o tráfego entre as origens selecionadas finais com base nas proporções de peso especificadas.
   • 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 a afinidade de sessão estiver habilitada, a primeira solicitação em uma sessão seguirá o fluxo explicado anteriormente. As solicitações subsequentes serão enviadas para a origem selecionada na primeira solicitação.

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

A implantação de origens em diversos locais globais pode melhorar a capacidade de resposta do aplicativo devido ao roteamento do tráfego para a origem "mais próxima" dos usuários finais. O método de roteamento de latência é o padrão para 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 alta disponibilidade, as organizações geralmente implantam serviços de backup que assumem o controle em caso de falha no serviço principal. Essa configuração é conhecida como implantação Ativa/Espera ou Ativa/Passiva. O método de roteamento de tráfego prioritário no Azure Front Door permite a implementação desse padrão de failover de maneira eficaz.

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 no grupo de origem do Azure Front Door tem uma propriedade Prioridade, que pode ser definida 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

O método de roteamento de tráfego ponderado permite distribuir 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 número inteiro entre 1 e 1000, 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 proporções de peso especificadas, desde que as origens atendam à sensibilidade de latência aceitável. Se a sensibilidade de latência for definida 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 o Azure: crie um pool de origens com as 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 lidem com a maior parte do tráfego e, em seguida, desabilite e remova as origens com menor preferência.
• 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 lide com a sessão de um usuário, o que é benéfico para cenários como autenticação de clientes.

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. Isso direciona o tráfego subsequente de uma sessão de usuário para a mesma origem.

A afinidade de sessão pode ser habilitada no nível do grupo de origem nas camadas Standard e Premium do Azure Front Door e no nível do host de front-end no Azure Front Door (clássico) para cada domínio ou subdomínio configurado. Uma vez habilitado, o Azure Front Door adiciona cookies chamados ASLBSA e ASLBSACORS à sessão do usuário. Esses cookies ajudam a identificar diferentes usuários, mesmo que eles compartilhem o mesmo endereço IP, permitindo 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

A afinidade da sessão é mantida por meio do cookie de sessão do navegador 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. Isso não poderá ser feito se a resposta puder ser armazenada em cache, porque isso interromperia os cookies de outros clientes que solicitam o mesmo recurso. Para evitar o problema, a afinidade da 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 armazenamento em cache da resposta não importará.

A afinidade de sessão será 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 e sem armazenamento.
• 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.