Serverless e Autoscaling

Observe um dia de tráfego da BoxOffice. Da meia-noite às 09:45, a API atende algumas centenas de requisições por segundo. Às 10:00, quando a turnê de um show em estádio abre as vendas, o tráfego salta para dezenas de milhares — em segundos. Às 10:30 já voltou ao normal. O mesmo formato se repete algumas vezes por semana, em horários anunciados com antecedência, além das surpresas (um artista posta o link nas redes sociais às 23:00).

Há duas opções ruins: dimensionar a frota para o pico e pagar por máquinas ociosas 99% do tempo, ou dimensioná-la para a média e cair às 10:00. Esta página cobre as duas famílias de ferramentas que evitam ambas — as plataformas serverless, que escalam por requisição e cobram por uso, e o autoscaling, que aumenta e diminui uma frota de réplicas com base em métricas ou agendas — e a verdade incômoda que elas compartilham: escalar leva tempo, e uma flash sale não espera.

Serverless

Serverless significa que você faz o deploy do código e a plataforma provisiona, escala e cobra pelas máquinas por baixo, inclusive escalando até zero quando não há tráfego. Dois formatos dominam:

• Functions as a Service (FaaS) — AWS Lambda, Google Cloud Run functions, Azure Functions: você faz o deploy de uma função, e a plataforma a chama uma vez por evento (uma requisição HTTP, uma mensagem de fila, o upload de um arquivo, um agendamento).
• Containers serverless — Google Cloud Run, AWS Fargate (com ECS), Azure Container Apps: você faz o deploy de uma imagem de container que atende HTTP; a plataforma executa quantas instâncias o tráfego exigir, até zero.

A ideia já foi descrita como "programação em nuvem simplificada"¹: nenhum servidor para atualizar, nenhuma capacidade para planejar, pague apenas pelo que executa. As restrições são o preço.

Como uma função executa

sequenceDiagram
    participant E as Fonte de eventos
    participant P as Plataforma
    participant X as Ambiente de execução
    E->>P: invoca (requisição 1)
    P->>X: nenhum ambiente quente → cria sandbox
    Note over X: INIT: baixa o código, inicia o runtime, roda o código de init (cold start)
    X-->>P: pronto
    P->>X: atende a requisição 1
    X-->>E: resposta
    E->>P: invoca (requisição 2)
    P->>X: reutiliza o ambiente quente
    X-->>E: resposta (sem cold start)
    Note over X: ocioso por um tempo → congelado, depois destruído

Cada ambiente de execução (uma VM leve ou sandbox) atende uma requisição por vez no Lambda; uma rajada de 300 requisições simultâneas precisa de 300 ambientes. Os ambientes são reutilizados enquanto o tráfego continua e destruídos depois de algum tempo ociosos². Tudo decorre desse modelo:

• Cold start: a primeira requisição em um ambiente novo paga pela sua criação. Para uma função pequena em Python ou Node.js, isso costuma levar algumas centenas de milissegundos; para uma aplicação Spring Boot em uma JVM comum, pode levar vários segundos (faixas ilustrativas — meça as suas).
• Concorrência = taxa × duração (a lei de Little de novo): 2.000 requisições/s × 0,2 s = 400 ambientes concorrentes. Reduzir a duração pela metade reduz a concorrência pela metade — e a conta também.
• O estado morre com o ambiente: qualquer coisa mantida em memória ou no disco local pode sumir entre requisições; é a regra do stateless da visão geral, imposta pela plataforma.

Cold starts e como reduzi-los

Cold starts importam em caminhos sensíveis à latência e voltados ao usuário, com tráfego em picos. Não importam para um consumidor de fila que gera PDFs de ingressos, onde um segundo a mais é invisível.

Limites de concorrência protegem — e estrangulam

Serverless escala rápido, mas não infinitamente:

• Limites de conta e de função: o AWS Lambda tem uma cota padrão de 1.000 execuções concorrentes por Região, compartilhada por todas as funções da conta (pode ser aumentada), e cada função escala no máximo 1.000 ambientes a cada 10 segundos². Além do limite, as invocações sofrem throttling (429), e os eventos assíncronos são reprocessados depois.
• Reserved concurrency limita uma função para que ela não deixe as outras sem recursos — e limita também a carga que ela pode colocar sobre um serviço downstream.
• Concorrência por instância: containers serverless como o Cloud Run deixam uma instância atender várias requisições ao mesmo tempo (80 por padrão)³, o que significa muito menos instâncias — e menos cold starts — para serviços limitados por I/O.

Custo: por uso vs sempre ligado

FaaS cobra por invocação mais GB-segundos (memória × duração). Containers cobram pela capacidade provisionada, usada ou não. Qual sai mais barato depende de quão ocupado o serviço é. O gráfico usa preços de tabela ilustrativos (AWS Lambda x86 em us-east-1 no momento em que este texto foi escrito: US$ 0,20 por milhão de requisições e US$ 0,0000166667 por GB-segundo; uma réplica de container a um custo assumido de US$ 60/mês, cada uma atendendo até 300 requisições/s, no mínimo duas para disponibilidade) — confira os preços atuais antes de usá-los em uma decisão real.

Com essas premissas, cada invocação custa cerca de US$ 1 por milhão; assim, funções são muito mais baratas abaixo de aproximadamente cem milhões de requisições por mês (algumas dezenas de requisições por segundo, em média), e containers vencem para serviços estáveis e ocupados. Cargas com picos e majoritariamente ociosas favorecem o serverless; cargas estáveis e de alto volume favorecem a capacidade provisionada. O FinOps (cloud-native) parte desse cálculo.

O panorama

Experimente no playground

Abra o cenário serverless-burst: uma função serverless atrás de uma API recebe uma rajada.

1. Rode o perfil spike e observe o p99 nos primeiros segundos: a penalidade do cold start.
2. Reduza o limite de concorrência da função até aparecerem requisições estranguladas (erros); depois aumente-o e veja o que acontece com o banco de dados por trás.
3. Compare o custo ao vivo com a mesma carga em uma camada de containers (troque o nó por um App Server com autoscaling).

Abrir o simulador completo

Autoscaling

O autoscaling ajusta a capacidade automaticamente. Ele opera em três níveis, que precisam funcionar juntos:

O HPA adiciona pods, mas, se nenhum nó tiver espaço, os pods ficam Pending até o cluster autoscaler adicionar um nó — o que demora bem mais. Os dois laços importam para o tempo de resposta.

Políticas

O HPA do Kubernetes

A cada 15 segundos (por padrão), o HPA calcula⁴:

Seis réplicas do catalog a 90% de CPU com alvo de 60%: ⌈6 × 90 / 60⌉ = 9 réplicas. Ele ignora variações dentro de uma tolerância de 10% e usa janelas de estabilização para não oscilar (a redução espera 5 minutos por padrão).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: catalog
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog
  minReplicas: 4                 # never below N+1 across zones
  maxReplicas: 40                # bounded by what the database can take
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60   # % of the CPU *request* of each pod
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100               # at most double every 15 s
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 20                # remove at most 20% per minute
          periodSeconds: 60

A utilização de CPU é medida em relação ao request de CPU do pod; portanto, o HPA só funciona se os requests estiverem definidos (e forem realistas). O Hands-on 10 executa uma versão deste HPA do tamanho de um notebook, sob uma carga do k6 (quadro abaixo).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: catalog
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60     # % of the CPU *request* (250m): scale when pods average > 150m
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0  # react at once to load
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100                 # at most double...
          periodSeconds: 15
        - type: Pods
          value: 2                   # ...or +2 pods, whichever is more, every 15 s
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 120  # wait 2 min of lower load before removing pods
      policies:
        - type: Pods
          value: 1
          periodSeconds: 30

Escolhendo a métrica

Escalando workers pela profundidade da fila

O KEDA (Kubernetes Event-Driven Autoscaling) alimenta o HPA com métricas de fontes de eventos — lag do Kafka, profundidade do SQS, tamanho de fila do RabbitMQ, consultas ao Prometheus, cron — e consegue escalar um Deployment até zero quando não há nada a fazer⁵:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ticket-worker
spec:
  scaleTargetRef:
    name: ticket-worker            # the Deployment
  minReplicaCount: 1
  maxReplicaCount: 24              # = partitions of order.confirmed.v1
  cooldownPeriod: 120
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: ticket-worker
        topic: order.confirmed.v1
        lagThreshold: "200"        # target lag per replica

Com um lag de 4.800 mensagens e um limiar de 200, o KEDA pede 24 réplicas — o teto, porque um consumer group do Kafka não consegue usar mais consumidores do que o tópico tem partições (mensageria).

O atraso do autoscaling

O autoscaling reativo tem um atraso embutido: a carga precisa chegar, ser medida, disparar uma decisão, e a nova capacidade precisa subir e aquecer. Cada passo é pequeno; somados, são minutos:

Uma flash sale vai de 1× a 20× em segundos (aqui, de 1.000 a 20.000 req/s em 20 s). A simulação abaixo compara um autoscaler reativo (alvo de 60%, no máximo dobrando a cada 15 s, novas réplicas prontas após 90 s) com o mesmo autoscaler mais um pré-escalonamento agendado às 09:45 para a previsão, 20.000 / (500 × 0,6) ≈ 67 réplicas:

A área vermelha é a demanda acima da capacidade: requisições que ficam na fila, estouram o timeout ou são rejeitadas — nos primeiros minutos da venda, exatamente quando mais importa. O escalonamento reativo acaba alcançando a demanda, mas só depois que os fãs já tiveram uma experiência ruim.

Escalonamento agendado e preditivo

Quando você sabe que o pico vai chegar, não espere pelas métricas:

• Escalonamento agendado: às 09:45, aumente o minReplicas (ou o mínimo do Auto Scaling group) para a previsão das 10:00, e reduza de volta às 10:45. Com o KEDA, um gatilho cron faz exatamente isso.
• Pré-aqueça tudo de que as réplicas precisam: nós (overprovisioning com pods "reserva" de baixa prioridade, que são despejados quando os pods reais precisam do espaço), imagens baixadas, caches preenchidos, pools de conexão com o banco abertos.
• Escalonamento preditivo (p. ex., o predictive scaling da AWS) aprende ciclos diários e semanais a partir do histórico e escala antes deles. Ajuda com o pico regular do fim da tarde, não com uma abertura de vendas pontual.

E quando nem isso basta — dois milhões de fãs para 60 mil lugares —, capacidade não é a resposta: uma sala de espera admite fãs na taxa que o sistema consegue atender, o rate limiting barra os bots, e o load shedding rejeita o excesso cedo e a baixo custo (edge, confiabilidade). O cenário flash-sale do playground combina todos eles.

Reduzindo com segurança

Reduzir a escala também causa incidentes:

• Flapping: reduzir assim que a carga cai e logo aumentar de novo; janelas de estabilização e políticas de redução lentas evitam isso.
• Matar trabalho em andamento: as réplicas precisam drenar ao receber SIGTERM (graceful shutdown, visão geral); os workers precisam parar de pegar jobs e terminar ou liberar o atual.
• Escalar até zero economiza dinheiro, mas traz de volta o cold start para a próxima requisição; mantenha um mínimo nos caminhos voltados ao usuário.

Containers ou serverless?

Como se conecta

flowchart LR
    FAAS["funções por evento"] --> COLD["cold starts,<br/>concorrência provisionada"]
    FAAS --> CONC["concorrência = taxa × duração<br/>cotas, throttling"]
    CONC --> DOWN["o banco não escala junto<br/>→ Bancos de dados"]
    FAAS --> COST["por uso vs sempre ligado<br/>→ FinOps"]
    AS["autoscaling"] --> HPA["HPA, KEDA, VPA, autoscalers de nós<br/>→ Kubernetes"]
    HPA --> MET["métrica: CPU, RPS,<br/>concorrência, atraso da fila"]
    AS --> LAG["minutos de atraso"]
    LAG --> SCHED["escala agendada + pré-aquecimento<br/>para a abertura das 10:00"]
    LAG --> PROT["sala de espera, rate limiting,<br/>descarte de carga → Confiabilidade"]
    HPA --> MAX["maxReplicas a partir do<br/>orçamento do downstream"]
    MAX --> DOWN

Componentes da paleta: serverless (webhooks, redimensionamento de imagens, cola para rajadas) · app (os containers que o HPA escala) · worker (KEDA pelo atraso da fila) · queue (o sinal de atraso) · sql (o orçamento de conexões que limita maxReplicas) · apigw (rate limiting enquanto a capacidade alcança a demanda) · metrics (o que o autoscaler lê). Cenários: serverless-burst, scale-out, async-queue, flash-sale. Continua em: Cloud-native — Kubernetes, Cloud-native — FinOps, Confiabilidade — descarte de carga, Estimativa — filas, Exercício: autoscaling no Kubernetes.

Pontos-chave