Balanceamento de carga e health checks
Escolher o load balancer certo pela decisão de roteamento que ele consegue tomar, diagnosticar targets presos em unhealthy e usar health checks do Route 53, failover de DNS e zonal shift para o tráfego se afastar das falhas.
Um load balancer roteia apenas para targets que ele acredita estarem saudáveis, e essa crença vem inteiramente de ajustes de health check que alguém escolheu. Quando esses ajustes dizem a verdade, uma instância quebrada sai de rotação em um minuto. Quando não dizem, o sintoma aparece como carga desigual, erro 502 intermitente ou uma frota inteira servindo respostas ruins com todos os gráficos verdes. Este tópico existe para você saber distinguir esses casos antes de mexer em qualquer coisa.
O que este tópico cobre
- O modelo de nós por Availability Zone, o TTL de 60 segundos do DNS e por que o cliente é quem escolhe o nó
- ALB, NLB e Gateway Load Balancer separados pela camada que cada um inspeciona e pela decisão que aquela camada torna possível
- Listeners, regras de listener, target groups e target types, incluindo por que
instancenão atravessa VPC peering - A aritmética de cross-zone load balancing (25% contra 6,25% contra 10%) e os padrões por tipo de load balancer
- Deregistration delay, algoritmos de roteamento, slow start e stickiness: qual falha cada atributo resolve
- Ajustes de health check com seus padrões, e a assimetria entre um target que chega e um que se recupera
- Estados de saúde e reason codes, mais a lista ordenada de causas por trás de um target unhealthy
- Fail open, thresholds de target group health e a diferença entre HTTP 502, 503, 504 e 460
- Health checks do Route 53: endpoint, calculado e de alarme do CloudWatch, com a regra dos 18%
- Failover ativo-passivo contra ativo-ativo, Evaluate Target Health em registros alias e zonal shift com o ARC
Por que isso importa
A Skill 2.2.1 do guia da SOA-C03 pede configuração e diagnóstico de Elastic Load Balancing e de health checks do Route 53, e as questões quase nunca pedem a definição de um serviço. Elas entregam um sintoma (carga desigual entre instâncias, 502 depois de um deploy, health check que passa no curl e falha no load balancer) e 4 correções plausíveis. Acertar depende de saber qual ajuste produz qual sintoma.
O mesmo raciocínio decide plantões. Um target unused não é um target doente, um alarme em UnHealthyHostCount com a estatística errada não dispara, e um health check desabilitado não drena Região nenhuma. As 3 lições aqui montam a cadeia completa, da requisição que chega no nó até a resposta de DNS que decide para qual Região o cliente vai.