Escalando StarRocks no Amazon EKS com KEDA e Karpenter para cargas OLAP corporativas

O que a Amazon FinTech construiu não é só mais um cluster EKS com StarRocks, é uma aplicação concreta da arquitetura de separação de compute e storage que só se tornou madura no StarRocks a partir da versão 3.0 (novembro/2023). Os nós Compute Nodes (CN) rodam como pods stateless, escalando via KEDA com base em métricas Prometheus do próprio StarRocks (como query queue depth e CPU avg), enquanto o Karpenter provisiona instâncias EC2 Spot ou On-Demand sob demanda, ajustando tipo e quantidade conforme a carga real, sem grupos de autoescalonamento pré-definidos. Isso permite que o sistema atinja 1.000 usuários simultâneos com latência sub-5s mesmo em consultas hierárquicas complexas, algo que benchmarks independentes confirmam: o StarRocks supera o ClickHouse em joins multi-tabelas em 3, 36x, graças ao seu planejador MPP otimizado para dados financeiros com dimensões aninhadas.

A escolha pelo StarRocks não foi apenas técnica: ela se alinha com o movimento mais amplo na infraestrutura de dados observado nas coberturas CEVIU anteriores, como o OpenSearch Serverless refeito para escalar até zero e o Crossplane usada para provisionar bancos SQL declarativamente. Aqui, o padrão é o mesmo: desacoplamento radical (compute/storage), controle declarativo (KEDA + Karpenter), e operação orientada a custo-performance, não só a performance bruta, o que faz sentido agora que o CostBench, lançado pela ClickHouse em 1º de junho, está virando referência para decisões de stack em nuvem.

Em maio de 2026, o StarRocks ainda era citado em cenários de POCs com Kubernetes, mas sem integração produtiva com autoscaling nativo. Agora, em 5 de junho, a Amazon FinTech entrega a primeira implantação pública em escala corporativa combinando três camadas críticas: (1) StarRocks com shared-data em S3 (não mais local), (2) KEDA escalando CNs por métricas reais de fila de queries, e (3) Karpenter provisionando nós EC2 com política de consolidation ativa, reduzindo tempo de spin-up para menos de 90 segundos e eliminando overprovisioning. É a primeira vez que a combinação dessas três ferramentas aparece em produção com SLA definido para OLAP financeiro.

Essa arquitetura corta o trade-off tradicional entre performance e custo em análise de dados. Em vez de manter clusters EKS sempre ligados para garantir latência, os CNs sobem e descem com a demanda, e os nós físicos são criados e destruídos em segundos, o que, somado ao uso estratégico de instâncias Spot, reduz custos operacionais em até 62% frente a uma implantação estática equivalente, segundo dados internos da equipe da Amazon FinTech. Para equipes de DevOps e plataformas, isso significa que o modelo de 'infraestrutura sob demanda' deixou de ser viável só para cargas event-driven (como APIs ou workers) e agora se aplica diretamente ao coração das análises corporativas: o data warehouse OLAP.