Kubernetes para escalonamento de comércio eletrônico: dos picos de tráfego à expansão global

Os picos de tráfego da Black Friday podem aumentar a carga do comércio eletrônico em 10 a 50 vezes em minutos. A infraestrutura de servidor tradicional não consegue responder com rapidez suficiente. O Kubernetes fornece os recursos de escalonamento automático, autocorreção e gerenciamento de tráfego que as plataformas modernas de comércio eletrônico precisam para lidar com a demanda imprevisível sem provisionamento excessivo durante períodos de silêncio.

Este guia aborda a arquitetura Kubernetes especificamente para cargas de trabalho de comércio eletrônico, desde o gerenciamento de vendas flash até a construção de vitrines multirregionais que atendem aos clientes em menos de 200 ms, independentemente da localização.

Principais conclusões

• O Horizontal Pod Autoscaler (HPA) pode dimensionar serviços de comércio eletrônico de 2 a 200 pods em menos de 90 segundos
• Os controladores de entrada com limitação de taxa protegem os serviços de back-end durante picos de tráfego
• Cargas de trabalho com estado (bancos de dados, índices de pesquisa) exigem estratégias de escalabilidade diferentes das dos serviços sem estado
• As implantações multirregionais do Kubernetes reduzem a latência em 60-80% para bases de clientes globais

---

Quando o Kubernetes faz sentido para o comércio eletrônico

Kubernetes nem sempre é a resposta certa. Acrescenta complexidade operacional que deve ser justificada pelos requisitos de escala.

Matriz de Decisão

Se o seu negócio se enquadra na coluna Docker Compose, consulte nosso Guia de implantação de produção do Docker.

---

Arquitetura Kubernetes para comércio eletrônico

Layout do cluster

Um cluster Kubernetes de comércio eletrônico normalmente contém estes namespaces:

• storefront: pods de aplicativos front-end
• api: serviços de API de back-end
• workers: Processadores de trabalhos em segundo plano (processamento de pedidos, envio de e-mail, sincronização de inventário)
• data: bancos de dados, caches e mecanismos de pesquisa (ou serviços externos gerenciados)
• ingress: controladores de entrada e balanceadores de carga
• monitoring: Prometheus, Grafana, alertando

Configuração de implantação

# storefront-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
  namespace: storefront
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
        - name: storefront
          image: registry.example.com/storefront:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: API_URL
              value: "http://api-service.api.svc.cluster.local:3001"
            - name: NODE_ENV
              value: "production"

---

Configuração de escalonamento automático

Escalonador automático de pod horizontal

# storefront-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: storefront-hpa
  namespace: storefront
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: storefront
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

A política scaleUp permite duplicar pods a cada 60 segundos – essencial para lidar com picos repentinos de tráfego. A política scaleDown é conservadora (10% por minuto) para evitar thrashing.

Escalonador automático de cluster

O HPA dimensiona os pods, mas os pods precisam de nós. O Cluster Autoscaler adiciona e remove nós com base nas demandas pendentes do pod:

# cluster-autoscaler configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  balance-similar-node-groups: "true"
  skip-nodes-with-local-storage: "false"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"
  max-node-provision-time: "5m"

Para AWS EKS, configure grupos de nós com tamanhos mínimo/máximo:

eksctl create nodegroup \
  --cluster ecommerce-prod \
  --name workers \
  --node-type t3.large \
  --nodes-min 3 \
  --nodes-max 20 \
  --node-volume-size 50 \
  --managed

---

Entrada e gerenciamento de tráfego

Controlador de entrada Nginx

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
    - hosts:
        - store.example.com
      secretName: store-tls
  rules:
    - host: store.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 3001
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-service
                port:
                  number: 3000

Lidando com vendas flash

As vendas flash exigem pré-escalonamento. Não confie apenas no escalonamento automático para eventos conhecidos de alto tráfego:

# Pre-scale 2 hours before a flash sale
kubectl scale deployment storefront --replicas=20 -n storefront
kubectl scale deployment api --replicas=15 -n api
kubectl scale deployment order-worker --replicas=10 -n workers

# After the sale, let HPA scale down naturally

---

Dimensionamento de banco de dados no Kubernetes

Bancos de dados gerenciados versus bancos de dados auto-hospedados

Recomendação: Use bancos de dados gerenciados para comércio eletrônico de produção. A sobrecarga operacional da execução do PostgreSQL no Kubernetes não se justifica para a maioria das empresas.

Pool de conexões

# pgbouncer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: data
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: pgbouncer
          image: edoburu/pgbouncer:1.21.0
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: MAX_CLIENT_CONN
              value: "1000"
            - name: DEFAULT_POOL_SIZE
              value: "25"
            - name: POOL_MODE
              value: "transaction"

O PgBouncer no modo de pool de transações permite que centenas de pods de aplicativos compartilhem um pool limitado de conexões de banco de dados. Sem o pool de conexões, o dimensionamento para 50 pods de API exigiria 50 x 20 = 1.000 conexões de banco de dados, sobrecarregando a maioria das instâncias do PostgreSQL.

Para obter mais estratégias de escalonamento de banco de dados, consulte nosso guia de escalonamento de banco de dados.

---

Implantação multirregional

Arquitetura

Uma implantação multirregional de comércio eletrônico do Kubernetes usa:

1. Clusters regionais: clusters Kubernetes independentes em cada região
2. Balanceador de carga global: roteia usuários para a região mais próxima (AWS Global Accelerator, Cloudflare)
3. Replicação de banco de dados: principal em uma região, lê réplicas em outras
4. CDN: ativos estáticos servidos a partir de pontos de presença em todo o mundo

Impacto na latência

A implantação multirregional reduz a latência para clientes internacionais em 60-90%, melhorando diretamente as taxas de conversão. Estudos mostram que cada 100 ms de redução de latência aumenta a conversão de comércio eletrônico em 1,1%.

---

Monitorando o comércio eletrônico do Kubernetes

Painéis essenciais

1. Métricas de negócios: pedidos por minuto, taxa de conversão do carrinho, receita por hora
2. Métricas de aplicação: latência de solicitação (P50, P95, P99), taxa de erros, sessões ativas
3. Métricas de infraestrutura: CPU/memória do pod, utilização de nós, atividade HPA
4. Métricas de banco de dados: contagem de conexões, latência de consulta, atraso de replicação

# prometheus-servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

---

Perguntas frequentes

Quanto custa o Kubernetes em comparação com a hospedagem tradicional?

A infraestrutura do Kubernetes custa de 20 a 40% mais do que instâncias equivalentes de bare metal ou de nuvem simples devido aos custos do plano de controle, às taxas do balanceador de carga e à sobrecarga do nó. No entanto, o escalonamento automático normalmente reduz o gasto total em 30-50% porque você não está pagando pela capacidade de pico fora dos horários de pico. O efeito líquido para a maioria das empresas de comércio eletrônico com tráfego variável é uma redução de custos de 10 a 25%.

Podemos executar o Odoo no Kubernetes?

Sim, mas com ressalvas. O armazenamento de arquivos do Odoo requer armazenamento persistente compartilhado (EFS, NFS) ao executar múltiplas réplicas. A afinidade de sessão é necessária, a menos que você externalize sessões para o Redis. As conexões de banco de dados devem ser agrupadas via PgBouncer. Para a maioria das implantações Odoo, Docker Compose ou ECS é mais simples e suficiente. O Kubernetes faz sentido para grandes implantações do Odoo com mais de 200 usuários simultâneos.

Como lidamos com atualizações do Kubernetes sem tempo de inatividade?

Use um serviço gerenciado do Kubernetes (EKS, GKE, AKS) que lida com atualizações do plano de controle. Para atualizações de nós, use uma estratégia contínua: isolar um nó, drenar seus pods (eles reagendam para outros nós), atualizar o nó, descordá-lo. Com orçamentos adequados para interrupção de pods, isso é totalmente automatizado e sem tempo de inatividade.

Qual é o tamanho mínimo do cluster para comércio eletrônico de produção?

Um cluster de produção mínimo para uma plataforma de comércio eletrônico de médio porte: 3 nós (t3.large ou equivalente) para cargas de trabalho de aplicativos, além de uma instância de banco de dados gerenciada. Isso lida com aproximadamente 500 usuários simultâneos com espaço para escalonamento automático durante picos. Custo total de infraestrutura: aproximadamente US$ 500-800 por mês.

---

O que vem a seguir

O Kubernetes fornece a base de escalonamento, mas é apenas uma peça do quebra-cabeça da infraestrutura. Combine-o com práticas recomendadas de CI/CD, otimização de CDN e teste de carga para obter uma plataforma completa de operações de comércio eletrônico.

Entre em contato com a ECOSIRE para consultoria em Kubernetes e estratégia de expansão de comércio eletrônico ou explore nossos serviços de integração do Shopify para comércio gerenciado sem cabeça no Kubernetes.

---

Publicado pela ECOSIRE – ajudando as empresas a dimensionar a infraestrutura de comércio eletrônico globalmente.