Target Group
Grupo de destinos do Application Load Balancer
Um Target Group define para onde o ALB envia o tráfego depois de uma regra de listener. No CRM, o tipo usual é IP (tasks ECS em modo awsvpc): cada task recebe um IP na subnet e o ECS registra esse IP no grupo quando a task fica saudável.
Papel na arquitetura
| Sem Target Group | Com Target Group |
|---|---|
| ALB não sabe quais backends estão válidos | Só IPs/portas healthy recebem requisições |
| Deploy derruba tráfego para instâncias mortas | Health check remove targets ruins automaticamente |
Tipos de target
| Tipo | Uso |
|---|---|
| instance | Targets em instâncias EC2 (modo bridge/host no ECS EC2) |
| ip | Tasks Fargate/ECS awsvpc — mais comum no CRM |
| lambda | Função como backend (menos comum para API principal) |
| alb | Encadeamento de load balancers |
Health check
O ALB consulta periodicamente cada target; parâmetros típicos:
| Parâmetro | Exemplo | Significado |
|---|---|---|
| Protocol | HTTP | HTTPS se o app expõe TLS no container (menos comum atrás de ALB) |
| Path | /health ou /api/health | Endpoint que retorna 200 quando app está pronta |
| Port | traffic port | Mesma porta do registro (ex. 8080) |
| Healthy threshold | 2 | Sucessos seguidos para marcar healthy |
| Unhealthy threshold | 3 | Falhas seguidas para remover do balanceamento |
| Interval | 30 s | Frequência das probes |
| Timeout | 5 s | Tempo máximo de resposta |
| Matcher | 200 | Códigos HTTP aceitos (pode incluir 200-299) |
O health check deve ser leve (sem bater no banco pesado) mas honesto (falha se dependências críticas estiverem indisponíveis, se essa for a política do time). Um check que sempre retorna 200 esconde API quebrada.
Atributos úteis
| Atributo | Efeito |
|---|---|
| Deregistration delay | Tempo que target unhealthy ainda recebe conexões existentes (draining no deploy) |
| Stickiness | Cookie de sessão no ALB — use só se a API exigir estado em memória local |
| Slow start | Ramp-up gradual de peso para targets novos após deploy |
Balanceamento
| Algoritmo | Comportamento |
|---|---|
| Round robin (padrão) | Distribui requisições igualmente entre targets healthy |
| Least outstanding requests | Envia para quem tem menos requisições em flight — bom para latências variáveis |
Deploy e ciclo de vida da task
- ECS sobe nova task → IP novo.
- ECS registra IP no Target Group.
- Health check passa → ALB inclui no roteamento.
- Deploy drena task antiga → deregistration delay → conexões terminam → task para.
Se o health check nunca passa, o deploy trava ou reverte conforme configuração do service.
Múltiplos target groups
Um ALB pode ter vários listeners/rules apontando para TGs diferentes:
| Cenário | Exemplo |
|---|---|
| API vs admin | /api/* → TG crm-api, /admin/* → outro service |
| Blue/green | Dois TGs; rule alterna peso (avançado) |
| gRPC / HTTP2 | Mesmo ALB com regras por host/path |