A ilusão do serverless
- Serverless se consolidou como uma tendência central da tecnologia de nuvem.
- Esse paradigma permite que desenvolvedores se concentrem apenas na lógica de negócio, sem o peso de gerenciar servidores.
- Modelo de cobrança: paga-se apenas pelo que é usado, e o overhead operacional fica praticamente zero.
- Diversos bancos de dados serverless surgiram no mercado, com líderes estabelecidos como Elastic, Confluent e Pinecone disputando espaço com novos entrantes como Neon, WarpStream, Upstash e Turbopuffer.
Problemas dos bancos de dados serverless atuais
- Muitos bancos de dados serverless não são realmente serverless.
- A maior parte dos serviços se baseia em arquitetura cloud-native, que foi uma inovação pensada para a era de server pools.
- Eles operam clusters de servidores e, por meio de software complexo e intervenção humana, prevêem carga e gerenciam capacidade.
- Essa ilusão gera problemas reais para os usuários.
Impacto da arquitetura ineficiente
- A incompatibilidade de arquitetura não é um simples detalhe técnico; ela causa problemas concretos para os usuários.
- O usuário paga por servidores ociosos, pois os clusters de servidores permanecem ativos continuamente para atender diferentes finalidades.
- Problema de escalabilidade: adicionar novos servidores a um cluster leva alguns minutos, o que impede tratar picos de tráfego de forma imediata.
- Baixa flexibilidade de escolha: como exige gestão de infraestrutura para cada região de nuvem, o usuário tem opções de locais de serviço limitadas.
Um modelo insustentável
- Bancos de dados “serverless” baseados em arquitetura de server pool não são sustentáveis.
- Provedores precisam de investimento significativo para operar clusters de servidores, e isso pode levar à alteração de preços.
- Usuários de baixa carga acabam pagando valores excessivos para sustentar o sistema, enquanto usuários de sucesso se deparam com elevação de preço inesperada.
A necessidade de uma arquitetura serverless nativa
- No início da computação em nuvem, a maioria dos bancos de dados “cloud” era legado.
- A arquitetura serverless nativa transfere toda a gestão da infraestrutura para o provedor de nuvem e, em vez de clusters de servidores, utiliza funções sem estado e serviços serverless.
- Essa abordagem trata a infraestrutura de nuvem como um único supercomputador de grande porte, permitindo escalabilidade instantânea e um verdadeiro modelo de pagamento por requisição.
- Teste de litmus: para validar se um banco de dados é realmente serverless nativo, é necessário verificar se ele pode ser implantado em uma conta de nuvem sem provisionar cluster Kubernetes ou VMs.
Apresentação do LambdaDB
- LambdaDB é um novo mecanismo de busca construído como serverless nativo.
- Esse sistema opera como um conjunto de funções e recursos serverless, separando totalmente a lógica do banco de dados da infraestrutura.
- Requisições de usuários passam por um gateway regional e são roteadas para Control Functions ou Data Functions conforme o tipo de requisição.
- Recursos empresariais: LambdaDB oferece recursos como point-in-time recovery e cloning sem cópia, sem necessidade de gerenciamento de infraestrutura.
Como o LambdaDB funciona
- Arquitetura do LambdaDB: todos os componentes são construídos com serviços cloud serverless.
- O gateway valida a API key das requisições dos usuários e roteia para função de controle ou função de dados.
- Funções de controle tratam operações CRUD e solicitações de gestão de dados, enquanto as funções de dados executam a gravação e leitura reais dos dados.
- Caminho de escrita: a Writer Function registra a requisição, grava no buffer de escrita serverless durável e, em seguida, responde ao cliente.
A contradição da eficiência de custos
- LambdaDB reduz custo de computação em comparação com bancos de dados baseados em server pool.
- O custo por unidade do Lambda é maior que o de uma instância EC2, porém a redução vem da redundância necessária para garantir alta disponibilidade e tolerância a falhas.
- Desperdício de capacidade fixa: a média de uso computacional das empresas é de apenas 10% a 20%, então a computação serverless pode reduzir custos em 50% a 90%.
Desempenho e escalabilidade
- Desempenho e escalabilidade: o LambdaDB comprovou seu desempenho em testes adicionando milhões de vetores de 960 dimensões.
- Latência de escrita: com 10 upserts por segundo, a mediana de latência é de 43 ms, e quando o tráfego aumenta 100 vezes ela permanece semelhante.
- Latência de consulta: a latência de consulta é estável em diferentes cargas, e o percentil 99 fica entre 172 ms e 210 ms.
- Esforço de otimização: há otimização contínua para reduzir a latência das funções de consulta, enquanto a infraestrutura serverless também está sendo aprimorada.
Benefícios para clientes
- Economia de custos: o LambdaDB é mais de 10 vezes mais barato porque não há servidores ociosos.
- Escalabilidade imediata e praticamente ilimitada: o LambdaDB pode escalar para milhares de funções paralelas em milissegundos.
- Início e expansão simples: é possível construir aplicações de IA poderosas e, conforme cresce, a arquitetura permanece simples e econômica.
- Recursos empresariais: oferece recursos como point-in-time recovery e cloning sem cópia, sem acrescentar complexidade ou custo.
Planos futuros e visão
- O LambdaDB já processa milhões de requisições por dia em centenas de milhões de documentos.
- Plano de longo prazo: planeja-se suportar outros modelos de dados (relacional, stream, key-value, grafos etc.).
5 comentários
A ideia é boa, mas para reduzir a latência da consulta, é inevitável precisar de estado. Em comparação com MySQL, PostgreSQL etc., a latência da consulta parece ficar quase 100 vezes maior. Isso parece bastante semelhante a inserir e extrair dados de um sistema de arquivos.
Obrigado pelo ótimo feedback. O ponto que você mencionou, de que é necessário um estado para reduzir a latência, captura perfeitamente um dos trade-offs centrais da nossa arquitetura.
Primeiro, quanto à latência de consulta, em nossos benchmarks o p99 (99º percentil) fica em torno de 130–210 ms. Acho que a observação sobre uma diferença de 100x provavelmente veio da situação limite citada no texto — que o cold start pode levar alguns segundos. Como você destacou, essa parte é claramente uma desvantagem da nossa arquitetura, e como mencionado no texto, ela ocorre em menos de 0,01% do total (P99.99) em ambiente de produção. Fora isso, a maioria das consultas foi projetada para usar o cache da memória local e do disco de cada Lambda, garantindo desempenho estável.
Portanto, como você disse, essa arquitetura pode não ser adequada para sistemas de transação financeira de latência ultrabaixa onde todas as consultas precisariam ficar abaixo de 10 ms. Porém, para a maioria das aplicações de busca e recomendação baseadas em IA, uma latência de 100–200 ms no P99 é um desempenho suficientemente bom, e acredito que o ganho de reduzir em mais de 90% os custos de infraestrutura e a sobrecarga operacional é muito maior.
Agradeço novamente pela sua contribuição aprofundada.
Como você mencionou, parece que, em vez de um banco de dados de uso geral, isso poderá ser uma solução que pode ser usada como "serverless de verdade" em situações específicas.
Não esperava receber uma resposta em coreano! (Acabei escrevendo de forma bem cínica...)
Eu inicialmente pensei que era uma ideia revolucionária. Na verdade, o maior problema dos bancos de dados serverless é que há um servidor real sendo executado em um local em que isso não fica aparente. Então, quando o tráfego aumenta demais, ocorre a situação de indisponibilidade até que aquele servidor seja alocado (cerca de 5 minutos). Por isso, é difícil usar DBs serverless existentes em nuvem (AWS etc.) em nível de produção.
Pensei em testar, mas a razão da preocupação era esta: então teríamos que implementar a lógica binária de indexação, ordenação etc., que já foi feita no MySQL, PostgreSQL, e assim por diante. Pensei em como seria difícil reconstruir sobre o Lambda um projeto de banco de dados open source confiável.
Já que vocês estão criando diretamente o produto, espero que ele evolua bastante~!
Ótima observação, obrigado. Como você mencionou, acredito que não é adequado para casos de uso de RDB e que deve ser entendido como uma posição para mecanismos de busca (Elasticsearch) e DB de vetor (Pinecone). Internamente também utilizamos o Lucene, comprovadamente estável ao longo de muito tempo, para suportar funções como indexação, classificação e agregação. Obrigado :)