Discord reduz tempo de provisionamento de cluster shadow em 94% com SCP

Discord's Persistence Infrastructure team manages 20-plus ScyllaDB clusters across roughly 500 nodes, storing messages, channels, and server data for hundreds of millions of users. A equipe anterior operava esse footprint usando scripts Python e shell que exigiam conhecimento institucional profundo e supervisão constante. Scylla Control Plane (SCP), um framework de orquestração interno, substitui scripts ad hoc por workflows declarativos e resumíveis. Provisionamento de shadow cluster — uma réplica de produção completa usada para validar upgrades de ScyllaDB antes do deployment — caiu de um dia e meio de atenção ativa de engenheiro para menos de duas horas sem supervisão. Isso representa uma redução de 94% nessa operação — um cálculo editorial baseado em referências informais de tempo do Discord, não um número publicado pelo Discord.

SCP é construído em torno de três primitivas: tasks (operações idempotentes), workflows (sequências definidas em YAML) e jobs (contextos de execução resumíveis com estado persistido em SQLite). Ele aborda três modos de falha da abordagem anterior: ordenação insegura de execução, incapacidade de retomar após interrupções e fragilidade ao estender automação para novos cenários. Cada task define pré-condições explícitas. Antes de drenar um node, a CLI scyllactl verifica segurança de quórum e saúde do cluster — verificações embutidas na definição de task que rodam toda vez.

Clusters distribuídos multi-AZ exigem mais que guards em nível de task. SCP força controles de concorrência configuráveis em nível de workflow. Engenheiros podem expressar regras como "nunca reiniciar nodes em múltiplas zonas de disponibilidade simultaneamente" diretamente em YAML. Batching com consciência de zona, gates de pré-condição por step, alerting dirigido por webhook e retries automáticos com classificação de erro estão embutidos no framework em vez de deixados para runbooks individuais.

Uma operação de shadow cluster mostra a melhoria. Anteriormente, provisionar dezenas de nodes, juntá-los um de cada vez, validar replicação, configurar pipelines dual-write e supervisionar cada step manualmente levava mais de um dia de tempo de engenheiro. Erros no step 9 significavam recomeçar do zero. Com SCP, a mesma sequência roda sem supervisão em menos de duas horas.

O framework agora automatiza rolling OS upgrades em centenas de nodes, expansão de cluster, recuperação de node, binary cycling, mudanças de scylla.yaml, sinais SIGHUP e limpeza de repair. Garantias de idempotência significam que jobs interrompidos podem ser retentados com segurança sem corromper estado de cluster ou duplicar ações — impossível com a abordagem anterior dirigida por scripts.

Nenhuma métrica de latência, custo-por-operação ou throughput para SCP foi divulgada. O time enquadrou o benefício primariamente como redução de carga cognitiva: engenheiros não mais supervisionam procedimentos de manutenção de execução longa step a step. Além de provisionamento de shadow cluster, nenhuma métrica operacional de overhead mais ampla (melhoria percentual em todas as operações, horas de engenheiro agregadas economizadas ou taxa de redução de incidentes) foi publicada.

SCP ainda não está finalizado. Gestão de ciclo de vida de shadow cluster totalmente automatizada e estratégias de expansão mais inteligentes estão listadas como próximos investimentos. Algumas operações multi-phase ainda exigem checkpoints humanos.

O padrão transferível: codificar regras de segurança operacional — verificações de quórum, restrições de isolamento de AZ, requisitos de idempotência — diretamente em definições de workflow em vez de confiar em disciplina de runbook. SQLite para persistência local de job-state fornece resumibilidade sem adicionar uma dependência de coordenação.