0Pricing
Cloud & IT Cert Prep · Aula

Verificações de integridade, disjuntores e lógica de repetição

Use verificações de integridade do ELB, verificações de endpoints do Route 53 e disjuntores no nível da aplicação para detectar falhas e redirecionar o tráfego automaticamente.

Verificações de integridade, disjuntores e lógica de repetição é uma aula grátis de Cloud & IT Cert Prep no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Cloud & IT Cert Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.

Por que a detecção automatizada de falhas é importante

Em sistemas distribuídos, os componentes falham continuamente — instâncias travam, ocorrem partições de rede e os serviços downstream ficam sobrecarregados. Sem detecção automatizada de falhas, o tráfego continua sendo direcionado para componentes com falha, causando falhas em cascata. A AWS oferece várias camadas de verificação de integridade: as verificações de integridade do ELB detectam instâncias não saudáveis, as verificações de integridade do Route 53 detectam endpoints não saudáveis e o Auto Scaling substitui instâncias com falha. Padrões no nível da aplicação, como disjuntores de circuito e novas tentativas, completam a estratégia de resiliência.

Verificações de integridade do ELB

As verificações de integridade do Elastic Load Balancer enviam periodicamente solicitações aos destinos registrados para determinar se eles estão íntegros. Você configura o caminho da verificação de integridade (por exemplo, /health), o protocolo, a porta, o intervalo (o padrão é 30 segundos) e o limite de destinos íntegros/não íntegros (o número de sucessos/falhas consecutivos). Quando um destino falha nas verificações de integridade, o ELB deixa de encaminhar tráfego para ele. O destino é reavaliado continuamente e adicionado novamente assim que atinge o limite de integridade.

# Configure ALB target group health check
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
  --health-check-protocol HTTPS \
  --health-check-port 443 \
  --health-check-path /health \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200

Verificações de integridade do Route 53

As verificações de integridade do Route 53 monitoram endpoints de vários locais globalmente e funcionam em conjunto com o roteamento de failover do DNS. Existem três tipos: verificações de endpoint, que consultam diretamente a URL da sua aplicação; verificações calculadas, que combinam várias verificações de integridade secundárias usando a lógica AND/OR (útil para monitoramento complexo); e verificações de alarmes do CloudWatch, que delegam a determinação da integridade ao CloudWatch — úteis quando você não pode expor um endpoint público de integridade ou precisa tomar decisões de integridade com base em métricas.

# Create endpoint health check
aws route53 create-health-check \
  --caller-reference ref-$(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true
  }'

Verificações de integridade do Auto Scaling

Os grupos do Auto Scaling podem usar dois tipos de verificações de integridade: as verificações de integridade do EC2 detectam falhas de instâncias no nível do hipervisor (falha na verificação de status da instância). As verificações de integridade do ELB têm maior conhecimento da aplicação — uma instância pode estar em execução, mas apresentar erros, e as verificações de integridade do ELB detectam isso. Você pode configurar o ASG para usar verificações de integridade do ELB, fazendo com que falhas no nível da aplicação também acionem a substituição da instância, e não apenas falhas subjacentes do EC2.

# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

# Grace period: time after launch before health checks start
# Prevents premature termination during startup

O padrão do disjuntor

Um disjuntor é um padrão no nível da aplicação que evita falhas em cascata monitorando chamadas para um serviço downstream e interrompendo-as temporariamente quando as falhas ultrapassam um limite. O disjuntor tem três estados: Closed (operação normal), Open (as falhas ultrapassaram o limite e as chamadas são bloqueadas imediatamente) e Half-Open (após um tempo limite, um pequeno número de chamadas de teste é permitido para verificar se o serviço se recuperou). O AWS App Mesh e SDKs de aplicações, como o Resilience4j, implementam esse padrão.

# Circuit breaker states
# CLOSED: All calls pass through
#   failureCount < threshold -> stay CLOSED
#   failureCount >= threshold -> open circuit

# OPEN: All calls fail immediately
#   After timeout -> enter HALF-OPEN

# HALF-OPEN: Allow limited test calls
#   Success -> return to CLOSED
#   Failure -> return to OPEN

# Example threshold: 5 failures in 10 seconds -> OPEN

AWS App Mesh para interrupção de circuitos

O AWS App Mesh é uma malha de serviços que implementa interrupção de circuitos, novas tentativas e políticas de tempo limite no nível da infraestrutura, sem alterações no código. Você define políticas de disjuntor na configuração do nó virtual ou roteador virtual. Quando um serviço upstream fica não íntegro, o proxy Envoy do App Mesh abre automaticamente o disjuntor, retornando erros imediatamente em vez de aguardar os tempos limite. Isso é especialmente valioso em arquiteturas de microsserviços executadas no ECS ou EKS.

# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
  'spec': {
    'listeners': [{
      'outlierDetection': {
        'consecutiveErrors': 5,
        'interval': {'unit': 'ms', 'value': 10000},
        'baseEjectionDuration': {'unit': 's', 'value': 30},
        'maxEjectionPercent': 50
      }
    }]
  }
}

Lógica de novas tentativas e espera exponencial

A lógica de novas tentativas repete automaticamente operações que falharam, mas uma lógica ingênua de novas tentativas (repetição imediata em um loop apertado) pode piorar situações de sobrecarga. A espera exponencial aumenta exponencialmente o tempo de espera entre as novas tentativas: 1s, 2s, 4s, 8s... O resultado é uma redução da carga sobre um serviço com dificuldades e mais tempo para que ele se recupere. A variação aleatória (intervalos de novas tentativas aleatórios) evita o problema da debandada, no qual todos os clientes tentam novamente simultaneamente após uma breve interrupção. O SDK da AWS implementa automaticamente a espera exponencial com variação aleatória.

# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds

# Python boto3 custom retry configuration
import boto3
from botocore.config import Config

config = Config(
    retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)

Idempotência para novas tentativas seguras

As novas tentativas só são seguras quando as operações são idempotentes — executar a mesma operação várias vezes produz o mesmo resultado. Por exemplo, criar um objeto do S3 com a mesma chave é idempotente (o resultado é o mesmo). Porém, fazer um pedido duas vezes cria dois pedidos — portanto, não é idempotente. Projete APIs idempotentes usando chaves de idempotência fornecidas pelo cliente: o servidor armazena o resultado da primeira solicitação e retorna o mesmo resultado para solicitações posteriores com a mesma chave. DynamoDB, SQS e API Gateway são compatíveis com padrões de chaves de idempotência.

# SQS message deduplication ID for FIFO queues
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
  --message-body '{"orderId":"ord-123","items":[...]}' \
  --message-group-id 'customer-456' \
  --message-deduplication-id 'ord-123-attempt-1'

# SQS deduplicates messages with same ID for 5 minutes

Configuração de tempos limite

Sem tempos limite explícitos, um serviço downstream lento faz com que os encadeamentos fiquem bloqueados indefinidamente, esgotando o conjunto de conexões e causando falhas em cascata. Defina tempos limite em todas as camadas: tempo limite de conexão (tempo para estabelecer uma conexão TCP), tempo limite de leitura (tempo para receber uma resposta) e tempo limite geral da solicitação. Na AWS, configure o tempo limite de inatividade do ELB (padrão de 60s), o tempo limite de execução do Lambda (máximo de 15 min) e o tempo limite de integração do API Gateway (máximo de 29s). Os tempos limite acionam sua lógica de novas tentativas ou de disjuntor.

# Lambda: set execution timeout
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <ALB-ARN> \
  --attributes Key=idle_timeout.timeout_seconds,Value=60

# API Gateway: integration timeout max 29000ms

Filas de mensagens não entregues para processamento com falha

Quando o processamento de mensagens falha repetidamente, uma fila de mensagens não entregues (DLQ) captura as mensagens que não puderam ser processadas após o número máximo de tentativas de recebimento. Configure DLQs nas filas do SQS e nos mapeamentos de origem de eventos do Lambda para impedir que mensagens inválidas bloqueiem sua fila indefinidamente. As mensagens na DLQ podem ser inspecionadas, reproduzidas após a correção do erro ou arquivadas. As DLQs são um componente essencial de arquiteturas orientadas por eventos e resilientes.

# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
  }'

# After 3 failed processing attempts, message goes to DLQ

Observação de falhas com o CloudWatch

Verificações de integridade e disjuntores eficazes exigem monitoramento para compreender os padrões de falha. O CloudWatch é a camada de observabilidade: crie alarmes para ELB UnHealthyHostCount (instâncias que falham nas verificações de integridade), a taxa de erros do Lambda, SQS NumberOfMessagesSentToDLQ (mensagens enviadas à DLQ) e RequestCountPerTarget do grupo de destinos. Configure notificações do SNS para que sua equipe de plantão seja alertada imediatamente quando as verificações automatizadas de integridade detectarem degradação.

# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
  --alarm-name 'ALB-UnhealthyHosts' \
  --alarm-description 'Alert when targets fail health checks' \
  --metric-name UnHealthyHostCount \
  --namespace AWS/ApplicationELB \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-team

Verificação rápida

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

Recapitulação da lição

Nesta lição, você aprendeu que: as verificações de integridade do ELB e do Route 53 automatizam a detecção de falhas no nível da infraestrutura; os disjuntores evitam falhas em cascata interrompendo chamadas para serviços não íntegros; e a espera exponencial com variação aleatória torna as novas tentativas seguras sob carga. As filas de mensagens não entregues capturam mensagens com falha para inspeção. A seguir, exploraremos RTO, RPO e as camadas de recuperação de desastres.

Perguntas Frequentes

A aula “Verificações de integridade, disjuntores e lógica de repetição” é grátis?

Sim — o texto completo de “Verificações de integridade, disjuntores e lógica de repetição” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Cloud & IT Cert Prep, atualize para CoddyKit PRO. O curso de Cloud & IT Cert Prep inclui 4 aulas no total.

O que vou aprender em “Verificações de integridade, disjuntores e lógica de repetição”?

Use verificações de integridade do ELB, verificações de endpoints do Route 53 e disjuntores no nível da aplicação para detectar falhas e redirecionar o tráfego automaticamente. Você pratica Cloud & IT Cert Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Cloud & IT Cert Prep?

Nenhuma experiência prévia é necessária. Cloud & IT Cert Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.

Quanto tempo leva a aula “Verificações de integridade, disjuntores e lógica de repetição”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Cloud & IT Cert Prep?

Sim. Cada aula de Cloud & IT Cert Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. HA versus tolerância a falhas: definições e diferenças
  2. Padrões Multi-AZ para serviços com estado
  3. Ativo-ativo e ativo-passivo em várias Regiões
  4. Verificações de integridade, disjuntores e lógica de repetição
← Voltar para Cloud & IT Cert Prep