Sondas de integridade e degradação controlada

As sondas de integridade são o mecanismo pelo qual os balanceadores de carga e os gerenciadores de tráfego detectam se uma instância de back-end é capaz de atender a solicitações. Sem sondas de integridade, um balanceador de carga pode continuar enviando tráfego para um servidor com falha ou sem resposta, causando erros visíveis aos usuários. Sondas de integridade configuradas corretamente permitem o redirecionamento automático do tráfego para longe das instâncias não íntegras poucos segundos após uma falha.

O Azure Load Balancer é compatível com dois tipos de sondas de integridade:

• Sonda TCP — verifica se o back-end pode aceitar uma conexão TCP em uma porta especificada. É simples, mas não verifica a lógica do aplicativo.
• Sonda HTTP/HTTPS — envia uma solicitação GET para um caminho especificado e espera uma resposta 200 OK. É mais precisa porque testa diretamente o ponto de extremidade do aplicativo.

Um back-end é marcado como não íntegro se a sonda falhar durante um número configurável de tentativas consecutivas.

Um ponto de extremidade de integridade bem projetado (/health) faz mais do que retornar 200 OK — ele verifica se as dependências críticas do aplicativo estão acessíveis. Uma verificação de integridade abrangente pode testar a conectividade com o banco de dados, o cache e quaisquer APIs downstream. Se alguma dependência estiver indisponível, o ponto de extremidade retornará um código de status 5xx, sinalizando ao balanceador de carga que deve remover essa instância da rotação.

O Azure Traffic Manager também usa sondas de integridade, mas no nível regional. Ele envia solicitações GET HTTP ou HTTPS periódicas ao URL do ponto de extremidade configurado em cada região. Se um ponto de extremidade não responder dentro da janela de tempo limite durante um número definido de intervalos consecutivos, o Traffic Manager marcará esse ponto de extremidade como degradado e interromperá o encaminhamento de consultas DNS para ele, redirecionando os usuários para uma região íntegra.

O Azure Application Gateway oferece recursos de sondas de integridade mais sofisticados do que o Load Balancer padrão. Ele é compatível com sondas personalizadas que especificam o cabeçalho do host, o intervalo esperado de códigos de status (por exemplo, 200-399) e uma cadeia de caracteres a ser localizada no corpo. O Application Gateway também é compatível com roteamento por caminho, permitindo que diferentes pools de back-end tenham configurações distintas de sondas de integridade para diferentes caminhos de URL.

Degradação controlada é a capacidade de um aplicativo continuar fornecendo funcionalidade parcial quando uma ou mais de suas dependências falham. Em vez de falhar completamente, o aplicativo detecta a indisponibilidade de um serviço não crítico e recorre a um estado degradado, mas ainda útil. Por exemplo, se um serviço de recomendações falhar, um site de comércio eletrônico poderá exibir sugestões genéricas em vez de fazer toda a página do produto falhar.

O padrão circuit breaker impede que uma aplicação chame repetidamente um serviço downstream que está falhando. Quando um serviço começa a falhar, o circuit breaker abre e retorna imediatamente um erro ou uma resposta alternativa, sem realizar a chamada de rede. Após um período de espera, ele entra no estado half-open e permite uma solicitação de teste. Se ela for bem-sucedida, o circuito fecha e a operação normal é retomada.

Para falhas transitórias (breves instabilidades de rede ou sobrecarga temporária do serviço), é apropriada uma estratégia de nova tentativa com recuo Exponential. A aplicação repete a chamada que falhou após um atraso, dobrando esse atraso a cada nova tentativa até atingir um máximo. Adicionar jitter (uma variação aleatória) ao atraso impede que todas as tentativas de nova chamada sejam sincronizadas e sobrecarreguem um serviço em recuperação.

O padrão bulkhead isola diferentes partes de uma aplicação em pools de recursos, para que uma falha em uma área não consuma todos os recursos nem derrube o sistema inteiro. O nome vem das divisórias de navios, que impedem que um compartimento inundado faça toda a embarcação afundar. No Azure, isso pode significar usar pools de threads separados ou planos do App Service separados para diferentes serviços, a fim de conter falhas.

Uma técnica comum de degradação controlada é fornecer dados armazenados em cache ou obsoletos quando uma fonte de dados ativa está indisponível. Por exemplo, uma página de catálogo de produtos pode exibir os preços de ontem armazenados em cache no Azure Cache for Redis, em vez de mostrar um erro se o banco de dados estiver temporariamente inacessível. Os usuários enfrentam um pequeno inconveniente (preços ligeiramente desatualizados), em vez de uma falha completa.

A degradação controlada deve ser visível e mensurada. Use o Application Insights para acompanhar, como métricas personalizadas, a taxa de aberturas do circuit breaker, de respostas fallback e de tentativas de nova chamada. Configure alertas quando essas métricas excederem os limites, para que a equipe de plantão seja notificada de que a aplicação está operando em estado degradado, mesmo que a experiência do usuário pareça aceitável.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que: sondas de integridade permitem que os balanceadores de carga detectem backends com falha e redirecionem o tráfego automaticamente; a degradação controlada mantém as aplicações parcialmente funcionais quando as dependências falham; e padrões como circuit breaker, nova tentativa com recuo e bulkhead implementam resiliência no nível da aplicação. A seguir, exploraremos conceitos de recuperação de desastres — definindo RTO, RPO e níveis de Recovery.