Laboratório de Troubleshooting: Configure traffic acceleration
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que usuários na Europa estão com latência de resposta acima de 800ms ao acessar uma aplicação web hospedada no Azure, mesmo após a implantação do Azure Front Door há três semanas. Usuários na América do Norte relatam latência normal, em torno de 60ms.
O engenheiro responsável verifica o perfil do Front Door e encontra o seguinte estado:
Perfil: fd-app-prod
SKU: Standard
Rota: /api/* -> origem app-service-eastus
Rota: /* -> origem app-service-eastus
Cache: Desabilitado
Health probe: HTTP/80 - intervalo 30s - Status: Healthy
Durante a investigação, o engenheiro também observa que o certificado TLS da aplicação foi renovado na semana anterior e que o App Service está com consumo de CPU em 35%, dentro do normal.
Ao executar uma resolução DNS da URL do Front Door a partir de um cliente europeu, o resultado retorna o seguinte:
nslookup app.contoso.com
Resposta: app.contoso.com -> app-service-eastus.azurewebsites.net
CNAME direto para a origem, sem intermediário do Front Door
Qual é a causa raiz da latência elevada para usuários europeus?
A) O cache está desabilitado no perfil do Front Door, forçando todas as requisições a atingir a origem sem otimização
B) O Front Door não está sendo utilizado no caminho do tráfego; o DNS aponta diretamente para o App Service, contornando o Front Door
C) O certificado TLS foi renovado e o Front Door ainda está usando a versão antiga, causando renegociação excessiva
D) O SKU Standard do Front Door não possui pontos de presença na Europa, obrigando o tráfego a rotear pela América do Norte
Cenário 2 — Decisão de Ação
A causa de um incidente em produção foi identificada: o grupo de origens do Azure Front Door tem a prioridade de duas origens configuradas com o mesmo valor (prioridade 1), quando a intenção era que a segunda origem funcionasse exclusivamente como failover (prioridade 2). Como resultado, o Front Door está distribuindo tráfego entre as duas origens de forma ativa, e a segunda origem, em uma região secundária, não está dimensionada para carga de produção, gerando erros 503 intermitentes para os usuários.
O contexto adicional é:
- O incidente está ativo e afetando 30% das requisições
- A segunda origem está respondendo com latência elevada e erros esporádicos
- Alterar a prioridade no grupo de origens é uma operação de configuração sem downtime declarado pela Microsoft
- A equipe de segurança exige aprovação formal para qualquer alteração em recursos de rede de produção, processo que leva em média 4 horas
- Existe uma opção de desabilitar temporariamente a segunda origem no grupo, ação que não requer aprovação de segurança conforme a política interna
Qual é a ação correta a tomar neste momento?
A) Aguardar a aprovação formal de segurança e somente então corrigir a prioridade da origem, pois qualquer alteração sem aprovação viola a política interna
B) Corrigir imediatamente a prioridade da origem para 2, sem aguardar aprovação, pois é uma alteração de configuração sem downtime
C) Desabilitar temporariamente a segunda origem no grupo de origens para conter o impacto imediato, e então iniciar o processo de aprovação para a correção definitiva de prioridade
D) Remover permanentemente a segunda origem do grupo de origens para eliminar o problema de imediato
Cenário 3 — Causa Raiz
Um desenvolvedor configurou o Azure Front Door para servir uma aplicação de e-commerce. Após alguns dias em produção, o time de QA reporta que usuários autenticados estão ocasionalmente recebendo respostas de outros usuários, como carrinhos de compras incorretos e dados de sessão misturados.
O engenheiro investiga e encontra a seguinte configuração de regra de rota:
Rota: /* -> grupo de origens ecommerce-origins
Cache: Habilitado
Duração do cache: 1 hora
Chave de cache: URL completa (padrão)
Query strings: Ignorar todas
O App Service de origem está saudável. Os logs do Front Door mostram cache HIT para requisições autenticadas. A aplicação usa cookies de sessão para identificar o usuário, e os cabeçalhos de resposta da origem incluem:
Set-Cookie: sessionid=abc123; Path=/; HttpOnly
Vary: Cookie
Qual é a causa raiz do comportamento observado?
A) O App Service está com problema de afinidade de sessão, roteando requisições do mesmo usuário para instâncias diferentes
B) O Front Door está servindo respostas em cache de um usuário para outro, pois a chave de cache não inclui o cookie de sessão, tornando respostas personalizadas indistinguíveis entre usuários
C) O cabeçalho Vary: Cookie está corrompendo o cache do Front Door, causando invalidação prematura e reenvio de respostas antigas
D) A duração de cache de 1 hora é excessiva para dados de sessão; reduzir para 5 minutos resolveria o problema de mistura de dados
Cenário 4 — Sequência de Diagnóstico
Um usuário reporta que ao acessar https://app.contoso.com, recebe o erro HTTP 503 de forma intermitente. O Azure Front Door está configurado como ponto de entrada. A equipe precisa diagnosticar o problema de forma estruturada.
Os seguintes passos de investigação estão disponíveis:
- Verificar o status das origens no grupo de origens do Front Door (health probe results)
- Analisar os logs de diagnóstico do Front Door no Log Analytics para identificar se o 503 é gerado pelo Front Door ou repassado da origem
- Confirmar se o DNS de
app.contoso.comresolve para o endpoint do Front Door e não diretamente para a origem - Verificar a configuração do health probe: protocolo, porta e caminho estão corretos e correspondem ao que a origem efetivamente responde
- Testar a origem diretamente (sem passar pelo Front Door) para determinar se ela responde com sucesso na mesma rota
Qual é a sequência correta de investigação?
A) 3 -> 2 -> 1 -> 4 -> 5
B) 1 -> 4 -> 5 -> 2 -> 3
C) 2 -> 1 -> 3 -> 5 -> 4
D) 3 -> 1 -> 4 -> 5 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista determinante está na saída do nslookup: o DNS de app.contoso.com resolve diretamente para app-service-eastus.azurewebsites.net, sem passar pelo Front Door. Isso significa que o registro DNS foi configurado incorretamente como CNAME apontando para a origem, e não para o endpoint do Front Door. O Front Door simplesmente não está no caminho do tráfego europeu.
Quando o Front Door não está sendo utilizado, todos os benefícios de aceleração desaparecem: sem roteamento pelo backbone da Microsoft, sem PoP intermediário, sem otimização de conexão. O tráfego europeu percorre a internet pública até a origem na região East US, explicando a latência de 800ms.
A informação sobre a renovação do certificado TLS é irrelevante para este diagnóstico. A alternativa C a usa como distrator clássico: conectar um evento recente (renovação) ao sintoma observado (latência), mesmo sem relação causal. A alternativa A é tecnicamente plausível, pois cache desabilitado aumenta carga na origem, mas não explica latência de 800ms para uma região específica. A alternativa D é factualmente falsa: o SKU Standard do Front Door possui PoPs globais, incluindo Europa.
O distrator mais perigoso é a alternativa A: um operador que age com base nela habilitaria o cache sem resolver o problema real, e os usuários europeus continuariam com alta latência.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta duas restrições simultâneas e conflitantes: um incidente ativo afetando usuários (urgência) e uma política de segurança que exige aprovação para alterações em recursos de rede (restrição formal). A ação correta equilibra as duas.
Desabilitar a segunda origem não requer aprovação conforme a política interna descrita, e resolve o impacto imediato ao remover do balanceamento a origem subdimensionada. Em seguida, o processo formal de aprovação pode ser iniciado para a correção definitiva de prioridade, que é a solução estrutural correta.
A alternativa A ignora o impacto ativo: aguardar 4 horas com 30% de erro em produção é inaceitável quando existe uma ação de contenção permitida. A alternativa B viola a política de segurança, mesmo sendo tecnicamente correta em outro contexto. A alternativa D é destrutiva e irreversível: remover permanentemente uma origem de failover válida para resolver um problema de configuração de prioridade é uma sobrerreação que compromete a resiliência da arquitetura.
O raciocínio correto em cenários de decisão com restrições é: conter o impacto dentro dos limites permitidos primeiro, depois corrigir a causa raiz pelo caminho formal.
Gabarito — Cenário 3
Resposta: B
O problema central é a configuração da chave de cache. O Front Door está usando a URL completa como chave de cache padrão e ignorando todas as query strings. Isso significa que duas requisições para GET /cart de usuários diferentes com cookies de sessão distintos geram a mesma chave de cache, e o Front Door serve a resposta armazenada do primeiro usuário para o segundo.
A pista crítica está nos logs: cache HIT para requisições autenticadas. Uma requisição autenticada nunca deveria ser servida do cache sem que o identificador da sessão faça parte da chave de cache, ou que a resposta tenha sido configurada como não cacheável pela origem.
O cabeçalho Vary: Cookie na resposta da origem é um sinal importante que foi ignorado na configuração. Esse cabeçalho instrui intermediários a variar o cache com base no conteúdo do cookie. O Front Door, no entanto, não inclui cookies na chave de cache por padrão, e a configuração do laboratório não substituiu esse comportamento.
A alternativa A (problema no App Service) é um distrator plausível porque mistura de dados de sessão pode ser causada por afinidade de sessão mal configurada, mas os logs de cache HIT descartam essa hipótese: o problema ocorre antes de atingir a origem. A alternativa D descreve uma solução parcialmente razoável, mas reduzir o TTL não resolve a causa: o problema é a ausência de diferenciação por usuário na chave, não a duração.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 3 -> 2 -> 1 -> 4 -> 5
O raciocínio diagnóstico progressivo parte do mais externo para o mais interno:
Passo 3 (DNS): Antes de qualquer análise do Front Door, confirmar que o tráfego realmente passa por ele. Se o DNS não aponta para o Front Door, todos os demais passos são irrelevantes para o diagnóstico do serviço.
Passo 2 (logs): Com o DNS confirmado, analisar os logs do Front Door no Log Analytics permite determinar a origem do erro 503: é gerado pelo próprio Front Door (ex: todas as origens marcadas como unhealthy) ou é uma resposta repassada da origem?
Passo 1 (health probe results): Agora que se sabe que o Front Door está no caminho, verificar o estado das origens revela se o Front Door as considera saudáveis ou não.
Passo 4 (configuração do health probe): Se as origens aparecem como unhealthy, verificar se o probe está configurado corretamente. Um probe com caminho ou porta incorreta marcará uma origem saudável como falha.
Passo 5 (teste direto na origem): Somente após identificar que o probe pode estar incorreto, testar a origem diretamente confirma se ela é de fato capaz de responder, distinguindo entre falha real da origem e falha de configuração do probe.
A sequência B começa pelo estado das origens sem confirmar se o Front Door está no caminho, pulando a etapa de validação mais básica. A sequência C começa pelos logs sem verificar o DNS, introduzindo ambiguidade desnecessária. A sequência D é similar à A até o passo 4 e 5 invertidos, o que faria o engenheiro testar a origem diretamente antes de verificar se o probe está mal configurado, perdendo contexto importante para interpretar o resultado do teste.
Árvore de Troubleshooting: Configure traffic acceleration
Legenda:
- Azul escuro: sintoma inicial que dispara o diagnóstico
- Azul médio: pergunta diagnóstica com resposta verificável na prática
- Vermelho: causa raiz identificada
- Verde: ação recomendada ou resolução
- Laranja: etapa de validação ou verificação após correção
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é diretamente observável: resultado do DNS, logs do Front Door, estado do health probe. Cada resposta elimina um ramo inteiro de hipóteses. Nunca avance para a etapa seguinte sem ter verificado a anterior na prática. A maioria dos problemas de aceleração de tráfego se resolve nos primeiros três níveis da árvore, antes de chegar à investigação da origem em si.