Migrar séries temporais para Timestream for InfluxDB

Em muitos ambientes, InfluxDB começou pequeno: alguns Telegraf agents, dashboards de infraestrutura e alertas quase em tempo real. Depois vieram tags por cliente, por região, por device, por versão de aplicação, por mesa de operação e por canal digital. O que era um banco de métricas virou dependência de incident response, capacity planning, análise de fraude operacional e reconciliação de eventos. Nesse estágio, o problema raramente é a API do InfluxDB; o problema é a operação ao redor dela.

Eu vejo três sintomas antes de recomendar migração. O primeiro é o time tratando upgrade, backup, disco, compactação e tuning como trabalho recorrente de SRE, não como exceção. O segundo é o custo escondido: nós grandes reservados para picos de ingestão, storage superprovisionado, snapshots sem política clara e dashboards que competem com writes. O terceiro é governança regional. Se a telemetria de uma subsidiária precisa permanecer em uma região específica, operar um cluster centralizado em outra geografia deixa de ser apenas uma decisão técnica e passa a ser uma decisão de risco.

A expansão regional reduz essa fricção. Ela permite desenhar células locais de séries temporais com APIs conhecidas, dentro do plano de controles AWS, sem forçar uma reescrita imediata dos produtores e consumidores.

Eu separaria a análise em duas trilhas. A primeira é compatibilidade funcional: line protocol, clientes existentes, queries, buckets, organizações, dashboards e integrações de coleta. A documentação de Timestream for InfluxDB preserva o acesso por APIs e ferramentas do ecossistema InfluxDB, mas isso não elimina testes de comportamento. Funções Flux, retenção, tokens, precisão temporal e cardinalidade precisam passar por uma suíte de regressão de consultas, especialmente quando dashboards executivos e alertas de NOC usam janelas diferentes.

A segunda trilha é modelo operacional. Em InfluxDB autogerenciado, eu controlo o host, o sistema operacional, o filesystem, o processo e o agendamento de manutenção. Em Timestream for InfluxDB, eu abro mão desse controle direto e recebo provisioning gerenciado, backups, patching e integração com métricas AWS. Essa troca é saudável quando a organização mede disponibilidade pela experiência do serviço, não pela liberdade de ajustar sysctl em produção.

A escolha fica mais forte para cargas em que o valor está nos dados e nas consultas, não na administração do cluster. Para equipes financeiras, isso costuma aparecer em telemetry stores de canais digitais, monitoramento de baixa latência, observabilidade de processamento batch/streaming e métricas de risco operacional. Eu manteria autogerenciado apenas quando houver extensão, plugin, acesso de host ou controle de engine que seja indispensável e comprovado.

Meu desenho alvo para uma instituição regulada é uma célula regional por domínio crítico, não um cluster mundial compartilhado. Cada célula recebe telemetria local por VPC, mantém tokens e segredos no mesmo perímetro de conta, publica métricas operacionais em CloudWatch e exporta agregados ou dados frios para a plataforma analítica quando necessário. Isso reduz latência, simplifica residência de dados e limita blast radius.

Para ambientes de produção, eu começaria avaliando Multi-AZ ou read replica cluster, conforme o padrão de leitura. A documentação confirma que read replica cluster usa replicação assíncrona, com writer e reader em Availability Zones diferentes dentro da mesma Região. Isso melhora capacidade de leitura e disponibilidade, mas introduz uma decisão explícita: em falha irrecuperável do writer, dados ainda não replicados podem ser perdidos. Em sistemas financeiros, eu não aceitaria essa semântica sem classificar o dado. Métricas de infraestrutura podem tolerar perda mínima na ponta; eventos usados para auditoria, cobrança ou reconciliação não deveriam depender apenas desse caminho.

Se o workload evolui para InfluxDB 3 Enterprise, o caminho de escala muda de vertical para composição de nós. A AWS documenta clusters de até 15 nós, com até 4 writer/reader nodes, até 13 reader-only nodes e compactor dedicado em clusters com 3 ou mais nós. Eu usaria essa flexibilidade para isolar leitura pesada, mas manteria a arquitetura honesta: todos os nós de um cluster usam a mesma classe de instância, então escala horizontal não substitui modelagem de cardinalidade.

Em séries temporais, eu não aceito sizing baseado apenas em CPU média. O risco real está na combinação de cardinalidade, concorrência de escrita, tamanho de batch e consultas que fazem varreduras amplas. A documentação de Timestream for InfluxDB lista classes db.influx de 1 vCPU e 8 GiB até 96 vCPU e 768 GiB, com largura de rede documentada de 10 Gbps nas menores classes até 40 Gbps na db.influx.24xlarge. Isso dá espaço de crescimento, mas não corrige um modelo de tags mal desenhado.

Meu processo é medir séries ativas por bucket e por hora, identificar tags que carregam userId, sessionId, requestId ou valores quase únicos, e bloquear novas tags de alta cardinalidade por contrato de schema. Para produtores críticos, eu padronizaria batch de escrita próximo da orientação documentada de 5.000 linhas quando a latência permitir, tags ordenadas lexicograficamente e precisão temporal tão grosseira quanto o caso de uso aceite. Escrever em nanossegundos quando o sensor produz dados a cada 10 segundos só aumenta ruído.

Também separo SLO de ingestão e SLO de query. Um dashboard que varre semanas com regex pode parecer inocente, mas disputar cache e CPU com ingestão de incidentes. Em produção, consultas caras precisam de owner, limite, janela padrão e, quando possível, endpoint de leitura isolado.

A migração só é completa quando o modelo de acesso muda junto. Em InfluxDB autogerenciado, é comum encontrar tokens compartilhados por squads, dashboards com permissões amplas e rotação manual adiada porque ninguém quer quebrar coleta. Ao trazer a carga para AWS, eu usaria a mudança como marco de saneamento: um token por produtor ou classe de produtor, segredo armazenado em Secrets Manager, rotação testada em ambiente não produtivo e trilha de auditoria para quem alterou secrets e security groups.

No perímetro de rede, eu privilegiaria subnets privadas, security groups explícitos e nenhuma exposição pública para workloads internos. A documentação indica que Timestream for InfluxDB não permite acesso direto ao host; isso é bom para reduzir superfície operacional, mas exige que runbooks sejam adaptados. O time não vai entrar na máquina para investigar processo; vai depender de métricas, logs, eventos, AWS API e suporte.

Em IAM, eu separaria papéis de provisionamento, leitura operacional e automação. Políticas deveriam usar condições por tag quando possível, por exemplo ambiente e domínio, para impedir que um pipeline de desenvolvimento modifique a célula de produção. Para instituições reguladas, eu também registraria uma decisão ADR: quais dados de telemetria podem conter identificadores sensíveis, quais tags são proibidas e qual retenção atende segurança, auditoria e privacidade.

O corte que eu considero saudável começa com leitura espelhada, não com escrita definitiva. Primeiro, eu colocaria os dashboards não críticos lendo do Timestream for InfluxDB, comparando resultados com o cluster atual em janelas de 5 minutos, 1 hora e 24 horas. Diferenças precisam ser classificadas: atraso esperado, divergência de schema, função de query incompatível, precisão temporal diferente ou perda real de ponto.

Depois, eu moveria alertas de baixa criticidade e manteria os alertas de incidente mais severos no caminho antigo até que a equipe tenha pelo menos um ciclo operacional completo: pico diário, janela batch, manutenção e incidente simulado. Em ambientes financeiros, eu gosto de um período de dual-write que atravesse fechamento contábil ou ciclo de liquidação relevante, porque é nesse momento que consultas ad hoc e cargas incomuns aparecem.

O corte de escrita primária deve ter congelamento curto de mudanças de schema, rollback testado e dono claro de decisão. Se o p99 de query subir, isso não significa automaticamente voltar; pode significar mover dashboards para endpoint read-only, reduzir janela padrão ou corrigir cardinalidade. Se houver divergência de contagem em dado regulado, eu paro. Migração bem conduzida não é a que nunca encontra problema; é a que sabe quais problemas são aceitáveis antes de começar.