Como enviar um banco de dados para produção todos os dias

A turbopuffer opera mais de 100 clusters de banco de dados, o dobro de seis meses antes, em três modelos de implantação: SaaS público, SaaS single-tenant e BYOC, em que o cluster roda na conta de nuvem do próprio cliente. A empresa afirma implantar dezenas de atualizações por dia, muitas no mesmo dia em que o PR é aberto, e descreve como sustentar esse ritmo sem acesso direto aos ambientes dos clientes.

O problema do BYOC

Clusters BYOC ficam dentro das contas dos clientes, e a turbopuffer não possui credenciais por padrão, sem acesso via SSH ou kubectl. A alternativa comum seria pedir ao cliente uma conta de nuvem dedicada com credenciais administrativas permanentes, mas isso gera custos de monitoramento de segurança, conformidade e faturamento que a empresa prefere evitar. Para não manter planos de controle diferentes entre BYOC e SaaS, o sistema precisa operar todos os clusters sem intervenção direta.

Estado local e operações como recursos do Kubernetes

A solução é um agente local em cada cluster, baseado em uma máquina de estados simples. Uma única CRD do Kubernetes, TurbopufferOperation, expressa todos os tipos de operação, de upgrade a limpeza. Um controller reconcilia cada recurso até um estado terminal, mesmo se a conexão com o plano de controle central cair. Estados como exigência de aprovação ou espera por janela de manutenção ficam registrados na própria CRD, e clientes BYOC podem controlar quando as operações avançam. O estado é persistido no etcd do cluster, permitindo retomar o trabalho após falhas do agente.

Por que não Terraform ou GitOps

A empresa usa Terraform e Helm para provisionar infraestrutura, mas os considera inadequados como plano de controle para uma frota de bancos de dados. Não há função dedicada de DevOps; engenheiros de banco de dados implantam o próprio código, e colocá-los no caminho de ferramentas de infraestrutura como código não faria sentido. No BYOC, executar terraform apply a partir da infraestrutura da turbopuffer contra o ambiente do cliente não é possível. Um fluxo GitOps poderia funcionar para upgrades, mas deixaria sem solução clara a propriedade do repositório e os portões de aprovação. Além disso, operações como reindexação de namespace, compactação de WAL e coleta de lixo no LSM têm formato de tarefa, não de estado declarativo, e exigiriam commits sucessivos para criar e limpar jobs.

Plano de controle próprio com MySQL na PlanetScale

Para distribuir trabalho e receber status, a turbopuffer construiu um plano de controle central com servidor de API apoiado em um banco MySQL na PlanetScale. Cada agente de cluster usa uma chave própria e busca operações pendentes por polling autenticado. As operações são salvas como custom resources nomeados pelo ID da operação, o que torna o processo idempotente: se uma operação for retornada novamente, o agente retoma o estado existente no etcd em vez de criar duplicata. Transições de status são enviadas ao servidor e gravadas como log append-only; se um POST falhar, o agente tenta de novo. Duplicatas não importam, porque o estado atual é a última transição.

Interface orientada a teclado e alertas no Slack

A interface é um dashboard em Remix/React, inspirado no Linear, operável por atalhos de teclado. Para upgrades, o painel mostra o commit SHA implantado em cada cluster e o distanciamento do último SHA aprovado, com metadados do GitHub como mensagem, número do PR e data. É possível selecionar vários clusters e atualizar todos para um SHA alvo. Como a equipe não deve permanecer no dashboard, as transições de status são transmitidas em threads dedicadas no Slack, falhas aparecem de forma visível no canal e aprovações de clientes BYOC também passam pelo canal de suporte no Slack. O painel oferece atalhos para logs, traces e métricas no Datadog e perfis de CPU e memória na Polar Signals.

Operações de frota

Com o crescimento da frota, a empresa automatizou rollouts amplos. Qualquer operação pode virar uma operação de frota, distribuída em ondas de um ou mais clusters. Entre ondas, um portão verifica se todos os clusters da onda foram atualizados com sucesso e se os monitores estão silenciosos. Se um monitor disparar ou um cluster falhar, o fleet controller pausa o rollout e notifica no Slack. Nada muda para o agente local, que continua consumindo a mesma CRD e reportando status ao MySQL. A turbopuffer relata que essa simplicidade permitiu escalar o plano de controle de poucas regiões públicas para mais de 100 clusters em dezenas de regiões.