Grupos de destino e verificações de integridade

Um grupo de destinos é uma coleção lógica de destinos para os quais o balanceador de carga encaminha solicitações. Cada grupo de destinos tem um tipo de destino, um protocolo/porta e uma configuração de verificação de integridade. O balanceador de carga distribui as solicitações entre os destinos registrados no grupo que passam pelas verificações de integridade.

Os grupos de destinos são associados aos listeners do balanceador de carga por meio de regras de listener. Um listener pode encaminhar tráfego para vários grupos de destinos com base nos atributos da solicitação. Esse é o mecanismo central por trás do roteamento baseado em caminho e em host no ALB.

Os grupos de destinos oferecem três tipos de destino:

• instance: encaminha o tráfego para instâncias do EC2 pelo ID da instância; o balanceador de carga envia o tráfego para a interface de rede primária da instância, na porta especificada
• ip: encaminha o tráfego para endereços IP privados—é útil para destinos em contêineres (ECS/EKS), servidores locais acessíveis via VPN/Direct Connect ou IPs secundários de instâncias do EC2
• lambda: encaminha o tráfego para uma única função do Lambda (somente ALB); o ALB converte a solicitação HTTP em um evento JSON e invoca a função de forma síncrona

O tipo de destino IP é obrigatório para tarefas do ECS com o modo de rede awsvpc (cada tarefa recebe seu próprio IP), para pods do EKS e para arquiteturas híbridas com destinos locais.

Registra destinos em um grupo de destinos manualmente (no console ou na CLI) ou automaticamente (por meio da associação a um Grupo de Auto Scaling ou da configuração de um serviço ECS). Os destinos registrados manualmente permanecem no grupo até que sejam explicitamente desregistrados.

Para ASGs, associe o ASG a um grupo de destinos, e o ASG registrará automaticamente as instâncias recém-lançadas e desregistrará as encerradas. Essa integração estreita com o ASG é o padrão para camadas de computação elástica: novas instâncias ficam disponíveis e começam a receber tráfego assim que passam na verificação de integridade.

Cada grupo de destinos tem uma verificação de integridade associada, que o balanceador de carga usa para determinar se um destino está íntegro e apto a receber tráfego. A verificação de integridade envia solicitações periódicas a cada destino e avalia a resposta:

• Protocolo: HTTP, HTTPS ou TCP (para NLB)
• Caminho: o caminho da URL a ser solicitado (por exemplo, /health ou /ping)
• Porta: a porta a ser verificada (por padrão, a porta do grupo de destinos)
• Limite de integridade: sucessos consecutivos antes de marcar o destino como íntegro
• Limite de não integridade: falhas consecutivas antes de marcar o destino como não íntegro
• Intervalo: segundos entre as verificações de integridade (5–300)
• Tempo limite: segundos de espera por uma resposta

Para verificações de integridade HTTP/HTTPS, especifique quais códigos de resposta HTTP indicam que um destino está íntegro. O padrão é 200, mas você pode configurar intervalos como 200-299 ou valores separados por vírgulas, como 200,301,302.

Prática recomendada: crie um endpoint /health dedicado em sua aplicação que retorne 200 somente quando todas as dependências críticas estiverem disponíveis (conectividade com o banco de dados, cache e serviço downstream). Não use a URL raiz (/) como caminho da verificação de integridade se ela executar operações dispendiosas ou exigir autenticação.

Após o registro, um destino passa pelos seguintes estados:

• inicial: o ELB está realizando as primeiras verificações de integridade
• íntegro: passou nas verificações de integridade consecutivas exigidas; recebe tráfego
• não íntegro: falhou nas verificações de integridade consecutivas exigidas; foi removido da rotação
• em drenagem: o desregistro está em andamento; as conexões existentes podem ser concluídas, mas nenhuma conexão nova é enviada
• não utilizado: está registrado no grupo, mas nenhuma regra de listener direciona tráfego atualmente para esse grupo

Monitore as métricas UnHealthyHostCount e HealthyHostCount do CloudWatch para detectar problemas na sua frota de destinos.

O atraso de desregistro (anteriormente chamado de drenagem de conexões) é o tempo que o ELB aguarda a conclusão das conexões existentes antes de finalmente desregistrar um destino. O padrão é de 300 segundos (5 minutos). Durante esse período, nenhuma solicitação nova é enviada ao destino em processo de desregistro, mas as solicitações em andamento podem ser concluídas.

Para implantações rápidas e encerramentos causados pelo escalonamento automático, talvez você queira reduzir esse tempo para 30–60 segundos se sua aplicação processar as solicitações rapidamente. Para operações de longa duração (uploads de arquivos e processamento de vídeo), mantenha um tempo suficiente para que essas operações sejam concluídas sem interrupções.

Os grupos de destinos são compatíveis com diferentes algoritmos de balanceamento de carga:

• Round robin (padrão do ALB): distribui as solicitações uniformemente em rotação; é melhor quando todos os destinos são equivalentes
• Menor número de solicitações pendentes (ALB): envia cada solicitação nova ao destino com o menor número de solicitações em andamento; é melhor para cargas de trabalho de duração variável, nas quais algumas solicitações demoram mais que outras
• Hash de fluxo (NLB): distribui com base no protocolo, no IP de origem/destino, na porta de origem/destino e no número de sequência TCP; garante que todos os pacotes de um fluxo TCP/UDP sejam enviados ao mesmo destino

Para aplicações baseadas em sessão nas quais todas as solicitações de um usuário devem chegar ao mesmo destino, habilite sessões persistentes em vez de depender da distribuição round robin.

Uma única regra de listener do ALB pode distribuir tráfego entre vários grupos de destinos usando grupos de destinos ponderados. Por exemplo, direcione 90% do tráfego para um grupo de destinos estável e 10% para um grupo de destinos canário em implantações azul-verde, sem usar o roteamento ponderado do Route 53.

Os grupos de destinos ponderados são configurados no nível da regra do listener. Os pesos são relativos: 90/10 envia 90% para o primeiro grupo e 10% para o segundo. Isso é diferente do roteamento ponderado entre vários ALBs; aqui, ele ocorre dentro de uma única regra de listener do ALB.

Ao implantar serviços ECS atrás de um ALB, cada tarefa do ECS é registrada no grupo de destinos do ALB usando o tipo de destino IP (para o modo de rede awsvpc). O serviço ECS gerencia automaticamente o registro e o desregistro: novas tarefas são registradas depois de passarem nas verificações de integridade, e a parada de tarefas aciona o atraso de desregistro antes do encerramento.

Cada serviço ECS pode ser registrado com uma substituição de porta específica, permitindo que vários serviços ECS compartilhem um único ALB por meio de regras de listener diferentes (baseadas em caminho ou em host), com grupos de destinos diferentes; esse é um padrão comum de microsserviços.

O comportamento das verificações de integridade do NLB difere do ALB:

• O NLB é compatível com os protocolos de verificação de integridade TCP, HTTP e HTTPS, independentemente do protocolo do listener
• As verificações de integridade do NLB são enviadas a partir dos endereços IP do NLB em cada AZ; certifique-se de que os grupos de segurança permitam tráfego dos IPs de sub-rede do NLB ou use o grupo de segurança do próprio NLB
• Para verificações de integridade TCP, o NLB considera um destino íntegro se ele aceitar uma conexão TCP na porta especificada
• Os destinos do NLB que falham nas verificações de integridade são removidos por AZ; se todos os destinos de uma AZ estiverem não íntegros, o NLB poderá fazer balanceamento de carga entre zonas para destinos íntegros em outras AZs (se o balanceamento de carga entre zonas estiver habilitado)

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: os grupos de destinos contêm destinos registrados e íntegros dos tipos instância, IP ou Lambda; as verificações de integridade sondam periodicamente os destinos para remover os não íntegros da rotação; e o atraso de desregistro garante a drenagem ordenada das solicitações em andamento antes da remoção do destino. A seguir, exploraremos as regras de listener e o roteamento baseado em caminho no ALB.