Como dimensionar infraestrutura para picos de tráfego

1. Fundamentos do dimensionamento para picos

1.1. Conceitos de escalabilidade vertical vs. horizontal

Dimensionar infraestrutura para picos de tráfego exige compreender as duas abordagens fundamentais de escalabilidade. A escalabilidade vertical (scale up) consiste em adicionar mais recursos a uma única máquina — mais CPU, RAM ou armazenamento. Já a escalabilidade horizontal (scale out) distribui a carga entre múltiplas instâncias menores.

Para picos de tráfego, a escalabilidade horizontal é geralmente preferível por oferecer resiliência e elasticidade. Exemplo de configuração de instância para escala vertical:

# Exemplo: Configuração de instância EC2 para escala vertical
tipo_instancia: r5.8xlarge
vCPU: 32
RAM: 256 GB
Armazenamento: 4 TB SSD
Custo/hora: $2.016

Já para escala horizontal:

# Exemplo: Configuração de grupo de instâncias para escala horizontal
tipo_instancia: t3.medium
vCPU: 2
RAM: 4 GB
Quantidade mínima: 3
Quantidade máxima: 20
Custo/hora por instância: $0.0416

1.2. Identificação de padrões de tráfego

Picos de tráfego podem ser classificados em três categorias principais:

  • Sazonal: Ocorrem em períodos previsíveis (Black Friday, Natal)
  • Viral: Resultam de eventos imprevistos (menção em rede social)
  • Previsível: Baseiam-se em horários de pico (horário comercial, início de semana)

Exemplo de análise de padrão sazonal:

# Análise de tráfego sazonal (requisições por minuto)
Horário normal: 1.200 req/min
Black Friday (10h-14h): 45.000 req/min
Pico absoluto (Black Friday 11h30): 78.000 req/min
Fator de crescimento: 65x

1.3. Métricas-chave

Três métricas são essenciais para dimensionamento:

  • Throughput: Quantidade de requisições processadas por segundo
  • Latência: Tempo de resposta médio (alvo: <200ms)
  • Capacidade de reserva: Percentual de capacidade ociosa para absorver picos
# Métricas de capacidade para pico
Throughput normal: 5.000 req/s
Throughput em pico: 50.000 req/s
Latência aceitável: 150ms
Capacidade de reserva recomendada: 30%
Instâncias necessárias no pico: 50.000 / 1.000 (por instância) = 50
Instâncias com reserva: 50 * 1.3 = 65

2. Estratégias de escalonamento automático (Auto Scaling)

2.1. Configuração de grupos de auto scaling

No AWS Auto Scaling, a configuração típica para picos inclui:

# Configuração de Auto Scaling Group (ASG)
Nome: asg-producao-pico
Tipo de instância: t3.large
Mínimo: 3
Máximo: 30
Capacidade desejada: 5
Zonas de disponibilidade: us-east-1a, us-east-1b, us-east-1c

2.2. Políticas baseadas em métricas

Políticas de escalonamento devem considerar múltiplas métricas:

# Política de escalonamento por CPU
Nome: scale-out-cpu-alto
Métrica: CPUUtilization
Limiar: 70%
Período de avaliação: 5 minutos
Cooldown: 300 segundos
Adicionar instâncias: 3

# Política de escalonamento por fila de requisições
Nome: scale-out-fila
Métrica: ApproximateNumberOfMessagesVisible (SQS)
Limiar: 1000 mensagens
Período de avaliação: 2 minutos
Adicionar instâncias: 5

2.3. Escalonamento preditivo com machine learning

Para picos conhecidos, o escalonamento preditivo pode antecipar a demanda:

# Configuração de escalonamento preditivo
Modo: FORECAST_ONLY
Intervalo de previsão: 2 horas
Frequência de atualização: 30 minutos
Dados históricos: 14 dias
Modelo: ARIMA sazonal
Capacidade máxima prevista: 25 instâncias

3. Arquitetura de balanceamento de carga e distribuição

3.1. Balanceadores de carga

O balanceamento adequado distribui o tráfego uniformemente:

# Configuração do Nginx como balanceador
upstream backend_pico {
    least_conn;
    server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.3:8080 backup;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_pico;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

3.2. Estratégias de roteamento

# Estratégias de balanceamento
Round-robin: Distribuição igual entre servidores
Least connections: Envia para servidor com menos conexões ativas
Sticky sessions: Mantém usuário no mesmo servidor (usar com cautela em picos)

3.3. CDN e DNS anycast

Para picos globais, CDN e anycast são essenciais:

# Configuração de CDN para pico
Provedor: CloudFront
Origem: ALB
Comportamento de cache: 300 segundos
Método de cache: GET, HEAD
Comportamento de pico: Aumentar TTL para 600 segundos
Qualidade de compressão: Brotli

4. Gerenciamento de capacidade de banco de dados

4.1. Replicação de leitura e caching

# Configuração de replicação de leitura
Banco: PostgreSQL 15
Instância primária: db.r5.xlarge (4 vCPU, 32 GB)
Réplicas de leitura: 3 instâncias db.r5.large
Cache Redis: 2 nós cache.r5.large (13 GB cada)
Hit rate do cache: 85%

4.2. Sharding e particionamento

# Estratégia de sharding para pico
Chave de shard: user_id % 8
Nós de shard: 8 (expansível para 16)
Balanceamento: Hash consistente
Capacidade por shard: 10.000 writes/s
Capacidade total: 80.000 writes/s

4.3. Bancos NoSQL para elasticidade

# Configuração DynamoDB para pico
Tabela: pedidos_pico
Capacidade de leitura: 5.000 unidades
Capacidade de escrita: 10.000 unidades
Auto scaling: Ativado
Capacidade máxima de leitura: 50.000
Capacidade máxima de escrita: 100.000

5. Otimização de camada de aplicação e cache

5.1. Cache de borda

# Configuração Varnish para pico
vcl 4.0;
backend default {
    .host = "app_server";
    .port = "8080";
}
sub vcl_recv {
    if (req.url ~ "^/api/produtos") {
        return (hash);
    }
}
sub vcl_backend_response {
    set beresp.ttl = 3600s;
}

5.2. Compressão e lazy loading

# Configuração de compressão
Algoritmo: Brotli (nível 6)
Tipos de conteúdo: text/html, application/json, text/css
Redução de payload: 60-70%
Lazy loading: Imagens abaixo da dobra
Threshold: 100KB

5.3. Filas de mensagens

# Configuração SQS para pico
Fila: processamento_pedidos_pico
Tipo: FIFO
Visibilidade: 30 segundos
Retenção: 4 dias
Dead letter queue: 3 tentativas
Mensagens por segundo: 5.000

6. Testes de estresse e simulação de picos

6.1. Ferramentas de carga

# Script Locust para simulação de pico
from locust import HttpUser, task, between

class PicoUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def buscar_produto(self):
        self.client.get("/api/produto/123")

    @task(1)
    def finalizar_compra(self):
        self.client.post("/api/pedido", json={"produto": 123})

    def on_start(self):
        # Simular ramp-up de 1000 usuários em 5 minutos
        pass

6.2. Cenários realistas

# Cenário de pico Black Friday
Duração: 4 horas
Usuários simultâneos: 50.000
Ramp-up: 10 minutos
Taxa de requisição inicial: 100 req/s
Taxa de requisição no pico: 5.000 req/s
Dados de entrada: Catálogo real com 10.000 produtos

6.3. Análise de resultados

# Resultados do teste de estresse
Throughput máximo: 4.200 req/s
Latência média: 180ms
Latência P99: 450ms
Erros (5xx): 0.2%
Instâncias escaladas: 12 -> 28
Tempo de escalonamento: 3 minutos

7. Monitoramento e resposta a incidentes em tempo real

7.1. Dashboards com Prometheus e Grafana

# Métricas monitoradas em tempo real
- Taxa de requisições (req/s)
- Latência média e P99
- Utilização de CPU (média por instância)
- Filas de mensagens (tamanho)
- Erros HTTP (4xx, 5xx)
- Capacidade de auto scaling (instâncias ativas)

7.2. Alertas proativos

# Regras de alerta para pico
Alerta: latencia_p99_alta
Expressão: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5
Severidade: critical
Ação: Escalar +5 instâncias

Alerta: fila_crescente
Expressão: aws_sqs_queue_size > 5000
Severidade: warning
Ação: Notificar equipe de plantão

7.3. Playbooks de resposta

# Playbook de resposta a pico inesperado
1. Verificar dashboards (Prometheus + Grafana)
2. Identificar gargalo (CPU, banco, fila)
3. Escalar manualmente se auto scaling não responder
4. Ativar circuit breakers para serviços não críticos
5. Reduzir TTL de cache para aliviar banco
6. Notificar stakeholders
7. Documentar incidente

8. Custos e governança no dimensionamento

8.1. Capacidade reservada vs. sob demanda

# Comparação de custos para pico
Capacidade base (50 instâncias):
- Reservada 1 ano: $0.028/hora * 50 = $1.40/hora
- Sob demanda: $0.0416/hora * 50 = $2.08/hora
Economia: 32.7%

Capacidade de pico (30 instâncias adicionais):
- Spot: $0.0125/hora * 30 = $0.375/hora
- Sob demanda: $0.0416/hora * 30 = $1.248/hora
Economia no pico: 69.9%

8.2. Instâncias spot e preemptíveis

# Configuração de instâncias spot para pico
Tipo: t3.large
Preço máximo: $0.03/hora (50% do sob demanda)
Pool de instâncias: 3 zonas de disponibilidade
Diversidade: 3 tipos de instância
Interrupção: Tolerar até 20%

8.3. Políticas de orçamento

# Política de orçamento para pico
Orçamento mensal: $50.000
Orçamento para pico: $15.000 (30%)
Alertas:
- 80% do orçamento: Notificar equipe financeira
- 100% do orçamento: Desativar instâncias não críticas
Tags obrigatórias:
- Environment: production
- CostCenter: infra-pico
- Project: black-friday-2024

Referências

  • AWS Auto Scaling Documentation — Guia oficial para configuração de grupos de auto scaling, políticas baseadas em métricas e escalonamento preditivo.
  • Nginx Load Balancing Documentation — Documentação completa sobre estratégias de balanceamento de carga com Nginx, incluindo round-robin e least connections.
  • Redis Caching Best Practices — Guia oficial de caching com Redis, incluindo configuração para alta disponibilidade e estratégias de cache.
  • Locust Documentation — Documentação da ferramenta de teste de carga Locust, com exemplos de simulação de picos de tráfego.
  • Prometheus Monitoring Guide — Guia oficial do Prometheus para monitoramento de métricas e configuração de alertas proativos.
  • AWS DynamoDB Auto Scaling — Documentação sobre escalonamento automático de capacidade para bancos NoSQL em picos de tráfego.
  • CloudFront CDN Optimization — Guia de otimização de CDN para absorção de picos globais de tráfego.