Construindo o Zilliz Cloud em 18 meses: lições aprendidas ao criar um serviço de busca vetorial escalável na nuvem pública
Prefácio
Bancos de dados vetoriais surgiram como uma tendência líder no setor de bancos de dados em 2023. Esta publicação detalha a criação do Zilliz Cloud, um serviço totalmente gerenciado impulsionado pelo Milvus, o banco de dados vetorial open-source mais adotado, desenvolvido do zero ao longo de dezoito meses. Durante esse período, desenvolvemos um serviço de nuvem abrangente a partir do zero e navegamos por um aumento de dez vezes no tráfego, impulsionado pela rápida expansão dos Large Language Models (LLM). Esta retrospectiva concentra-se em compartilhar as escolhas críticas de design e os insights inestimáveis obtidos durante nossa jornada.
Cluster Dedicado do Zilliz Cloud - A Jornada Começa
Voltando no tempo para maio de 2022, o banco de dados vetorial open-source Milvus 2.0 finalmente começou a se estabilizar após várias iterações importantes. Por meio de conversas com nossos usuários, a necessidade de uma versão estável, hospedada comercialmente, emergiu como uma solicitação recorrente. Para a Zilliz, a empresa comercial por trás do Milvus, o momento parecia perfeito para embarcar na comercialização — tínhamos uma equipe experiente de engenheiros, um produto em amadurecimento e uma base de usuários dedicada com necessidades urgentes. Com isso em mente, definimos uma meta ambiciosa: lançar nosso produto em seis meses.
Ao iniciarmos o projeto, avaliamos nossas capacidades e objetivos atuais:
- Nossa tecnologia central, um banco de dados vetorial open-source nativo de nuvem, projetado com desagregação de armazenamento e computação e uma estrutura de microsserviços, é desenvolvida para integração perfeita em um cluster Kubernetes (K8s). Essa estrutura nativa de nuvem nos permite adaptar-nos rapidamente a ambientes de produção em nuvem.
Figura 1: Arquitetura do Milvus
Como utilizamos o Kubernetes Operator, estávamos preparados para implantar rapidamente serviços nas principais plataformas de nuvem pública, como AWS e GCP; isso foi confirmado por vários usuários que implementaram com sucesso seus serviços de produção na nuvem pública.
Nossa plataforma incluía recursos básicos de observabilidade, como monitoramento e logs, mas ainda precisava de funções cruciais de alertas para produção.
Além dos elementos mencionados anteriormente, como serviço, faltavam-nos vários componentes críticos, incluindo, mas não se limitando a autenticação de login de usuários, medição e faturamento, mecanismos de pagamento, redes, segurança, um console Web, suporte a OpenAPI, agendamento de recursos e gerenciamento de fluxos de trabalho.
Definir quais módulos essenciais criar em seis meses representou uma tarefa formidável. Em resposta, fizemos uma autoavaliação crítica: Como poderíamos aproveitar os recursos disponíveis da forma mais eficiente? Seria possível sintetizar nossa abordagem para criar uma versão enxuta, mas totalmente funcional? Essas perguntas fundamentais orientaram nossa reflexão e, por fim, moldaram um conjunto de princípios de design fundamentais:
Maximizar o Uso de Produtos Maduros de Terceiros para Evitar Reinventar a Roda:
Enfatizando uma rápida prontidão para o mercado, apoiamo-nos estrategicamente em serviços de nuvem e de terceiros já estabelecidos. Aproveitamos os serviços centrais da AWS, como EKS, EC2, S3, EBS e ALB, juntamente com Kafka e RDS gerenciados pela AWS como a espinha dorsal da nossa infraestrutura. Essa abordagem não apenas facilitou nossas necessidades imediatas, mas também revelou que tais componentes oferecem um caminho econômico para adaptação futura a um ambiente multi-cloud, acelerando assim nosso ritmo de inovação. Diante de problemas de compatibilidade entre filas de mensagens do GCP/Azure e serviços Kafka gerenciados, desenvolvemos nosso sistema de log distribuído, ancorado no Apache Bookkeeper. A falta de soluções de logging distribuído confiáveis, open-source ou nativas de nuvem impulsionou esse esforço. Motivados por essa lacuna, estamos considerando tornar nossa solução open-source, esperançosos de que ela ajude outros a criar serviços de nuvem.
Provedores SaaS de terceiros foram fundamentais para acelerar o desenvolvimento da nossa plataforma. Por exemplo, adotamos o Stripe para gerenciar nosso processamento de pagamentos, atendendo a requisitos complexos de medição e tributação. Para facilitar conexões com marketplaces multicloud, integramos o Sugar.io. Além disso, avaliamos plataformas de serviços de faturamento como Orb e Metronome para aprimorar nossas operações de faturamento. Auth0 foi o produto de nossa escolha para gerenciamento de contas e funcionalidade de login; ampliamos ainda mais nossa funcionalidade de autenticação e login para incluir suporte a login com Google. Estabelecemos nosso sistema operacional de alertas no PagerDuty, selecionado por sua integração ágil com nossas ferramentas de monitoramento existentes e sua versatilidade na personalização de regras de notificação.
As entidades não devem ser multiplicadas desnecessariamente
Guiados pela filosofia da Navalha de Occam, adotamos uma abordagem de design minimalista que se manifestou em vários aspectos do produto:
Simplicidade da Arquitetura: Inicialmente, nosso design incluía mais de 60 microsserviços, o que representava desafios significativos na coordenação de desenvolvimento e testes. Para simplificar nossa arquitetura, reduzimos o número para menos de dez microsserviços principais, incluindo user, billing, CloudService, resources, metadata e scheduling. Essa redução esclareceu as dependências e reduziu a carga de testes.
Simplicidade Funcional: Em sua iteração inicial, a ênfase do Zilliz Cloud foi colocada nas funcionalidades principais do usuário, como registro, implantação de clusters e faturamento, enquanto adiamos deliberadamente recursos menos urgentes, como escalabilidade e backups, para aliviar a carga de trabalho. Notável foi nosso compromisso em estabelecer um ciclo de feedback robusto, inicialmente facilitando feedback por e-mail e posteriormente ampliando-o com integração ao Zendesk para garantir que feedback rápido e de alta qualidade pudesse nos orientar em melhorias adicionais.
Simplicidade de Design: Nosso design de serviço em nuvem priorizou a comunicação eficiente e o potencial de engajamento do usuário, exigindo uma abordagem disciplinada e focada. Aproveitar testes A/B rápidos nos permitiu validar recursos rapidamente e adaptar-nos com base em métricas de engajamento do usuário.
Antecipe os desafios do Dia 2 desde o Dia 1:
No cenário dinâmico dos serviços em nuvem, a capacidade de evoluir rapidamente sem sacrificar a confiabilidade das interfaces e dos serviços do usuário é fundamental. Essa manobra complexa se assemelha a "trocar os motores a jato em pleno ar." Para o observador externo, o serviço opera perfeitamente enquanto um ciclo vigoroso de inovação e melhoria está em andamento internamente. Adotar uma abordagem de desenvolvimento com o objetivo final em mente é crucial.
Suporte Multicloud: Inicialmente focada na AWS, nossa abordagem sempre priorizou a independência em relação a provedores de nuvem. Avaliamos extensivamente provedores como GCP e Alibaba Cloud para garantir compatibilidade entre nuvens públicas. Por meio de personalizações no projeto de código aberto Crossplane, desenvolvemos uma camada de 'adaptador de nuvem', reduzindo os custos associados ao suporte multicloud. Esse design facilitou a integração rápida com o GCP em apenas um mês e simplificou a integração com outros provedores de nuvem pública.
Segurança: Embora desenvolvedores de aplicações AIGC possam priorizar algo que não seja segurança, o Zilliz Cloud Services atribui máxima importância à segurança dos dados. Aderindo estritamente aos padrões de IAM em nuvem, controlamos meticulosamente as permissões de acesso a dados e empregamos criptografia para todos os dados, tanto em trânsito quanto em repouso. Enfatizando o isolamento de rede para desempenho ideal, selecionamos os complementos de rede EKS da AWS por sua eficiência e facilidade de uso. Delimitar as fronteiras de interação entre as camadas de dados e controle resultou em economias de custo significativas durante o lançamento do nosso produto BYOC.
Agrupamento de recursos: O Zilliz Cloud Services adota a "lei da comutatividade da nuvem", priorizando a escalabilidade elástica por meio do agrupamento de recursos. Ao separar armazenamento e computação e empregar balanceamento de carga dinâmico, garantimos a utilização eficiente dos recursos de nuvem. Essa abordagem nos permite reservar recursos apenas quando necessário, melhorando significativamente a utilização de Spot Instances e funções Lambda, ao mesmo tempo que reduz custos.
Amigável para operações: O Zilliz Cloud é projetado tendo em mente desenvolvedores e equipes operacionais, diferentemente de outros bancos de dados vetoriais. Com uma GUI abrangente e recursos sofisticados de monitoramento, a plataforma oferece recuperação de desastres em três AZ e adere a SLAs rigorosos, garantindo estabilidade e confiabilidade para ambientes de produção.
Guiados por nossas filosofias centrais de design, alcançamos o marco de lançar nosso produto comercial de busca vetorial em apenas seis meses, garantindo nosso grupo inicial de clientes seed no processo. Abaixo, você encontrará o diagrama arquitetural de nosso lançamento inaugural.
Figura 2- Arquitetura do Zilliz Cloud
Serverless: De $300 para $5 de custo de aquisição de novos usuários
O crescimento muitas vezes ocorre em momentos inesperados. Após experimentarmos um crescimento constante em nossos serviços SaaS por três meses, o crescimento do Zilliz Cloud, impulsionado pela popularidade explosiva do AutoGPT, atingiu um ponto alto. Ver bancos de dados vetoriais como memória de longo prazo para Grandes Modelos de Linguagem gradualmente ganhou aceitação, levando a um rápido aumento na base de usuários da Zilliz, com o número de novos clusters adicionados diariamente chegando rapidamente às centenas.
No entanto, esse crescimento trouxe dois principais desafios para a Zilliz: estabilidade e custo. Embora sempre tenhamos focado em escalabilidade, os picos repentinos de tráfego intenso quase paralisaram todos os nossos serviços, com apenas o banco de dados central saindo ileso. As APIs fornecidas por provedores de serviços de nuvem foram limitadas, e nosso sistema de armazenamento de logs, Loki, ficou cheio duas vezes em apenas alguns dias, forçando muitos serviços a serem interrompidos devido à falta de recursos.
Além disso, a estratégia inicial de teste gratuito adotada pelo Zilliz Cloud, que oferecia $300 em créditos a novos usuários para experimentar todos os recursos, levou a um aumento acentuado nos custos à medida que o número de usuários disparou (a maioria dos quais estava experimentando o serviço), forçando-nos a repensar nosso modelo de negócios. Esses pontos problemáticos nos levaram a lançar o Zilliz Cloud Serverless, um produto mais flexível, com menor barreira de entrada e mais adequado para usuários de AIGC que estão apenas começando sua jornada com bancos de dados vetoriais.
O Santo Graal ainda está por aí: Domando escalabilidade, custo e latência para o desenvolvimento de aplicações RAG
Para o caso de uso de Geração Aumentada por Recuperação (RAG) , a solução ideal de camada gratuita precisa considerar o seguinte:
Figura 3: Domando escalabilidade, custo e latência em aplicações RAG
Escalabilidade — Isso abrange dois aspectos principais:
No nível do locatário individual, o sistema deve escalar dinamicamente para processar dados de forma eficaz. Essa escalabilidade dinâmica exige que o banco de dados vetorial seja versátil o suficiente para se ajustar aos volumes de dados flutuantes de diferentes locatários, estejam eles processando conjuntos de dados pequenos ou grandes. Tempos de resposta de consulta consistentemente estáveis devem ser mantidos, independentemente do tamanho dos dados sendo manipulados.
Ao gerenciar muitos locatários, o sistema deve oferecer suporte eficiente à escalabilidade de até milhões de locatários. Especificamente, ele deve diferenciar e acomodar de forma inteligente os padrões de uso 'quentes' (altamente ativos) e 'frios' (menos ativos), garantindo alocação ideal de recursos e consistência de desempenho em todos os casos.
Custo — O controle de custos para o nível gratuito é crucial. Idealmente, o custo deve ser mantido abaixo de $1, fornecendo recursos suficientes para suportar 1 milhão de vetores de 768 dimensões. No entanto, ao depender de indexação vetorial em memória, o preço para lidar com 1 milhão de vetores de 768 dimensões pode facilmente exceder $10. Embora esse custo possa ser aceitável para empresas SaaS voltadas a serviços empresariais, ele é excessivo para aplicações ToC voltadas ao consumidor.
Baixa latência — Embora os casos de uso de RAG possam não ser tão sensíveis à latência quanto os domínios de busca e recomendação, o desempenho da recuperação vetorial impacta significativamente o "Tempo até o primeiro token." Portanto, manter baixa latência é crucial para melhorar a experiência do usuário e a responsividade do sistema.
A oferta inicial da Zilliz Cloud demonstrou escalabilidade excepcional para lidar com grandes volumes de dados e alcançar baixa latência, superando as expectativas dos usuários. Mesmo com o gerenciamento de numerosos tenants e o controle de custos, a solução de cluster dedicado ficou aquém de satisfazer plenamente as demandas dos usuários. Para remediar isso, desenvolvemos o 'Zilliz Serverless Tier,' um modelo de serviço especificamente projetado para reduzir a barreira de entrada para usuários individuais de AIGC. Esse nível oferece as soluções de armazenamento mais econômicas e escalabilidade para enfrentar efetivamente os desafios mencionados acima.
A arquitetura serverless da Zilliz Cloud
Figura 4- A arquitetura serverless da Zilliz Cloud
O Zilliz Cloud Serverless introduz o conceito de clusters lógicos, em que cada cluster lógico corresponde a um banco de dados em um cluster físico. Alcançamos isolamento lógico para todos os tenants dentro de um único cluster físico por meio de mecanismos de autenticação baseados em banco de dados e chave de API. Durante as consultas, o sistema roteia solicitações com base nas chaves de API para determinar os dados que os usuários precisam acessar, usando nós proxy para o roteamento.
As operações de escrita de dados são inicialmente enviadas a um pool de nós de log, que então gravam os dados em um serviço de Write-Ahead Logging (WAL), reorganizando periodicamente os dados e fazendo flush para o armazenamento de objetos. O CompactionService é um serviço de pooling responsável por consolidar segmentos de dados menores em segmentos maiores e eliminar entradas excluídas, otimizando o espaço de armazenamento e a velocidade de acesso. O Index Service é responsável por criar índices sobre dados brutos, que então são carregados pelos nós de consulta para garantir a eficiência das consultas.
Durante as operações de consulta, nossa estratégia envolve armazenar todos os dados em cache nos discos locais dos Query Nodes e executar a troca entre memória e disco localmente. Essa metodologia reduz significativamente os custos de armazenamento para usuários Serverless em mais de dez vezes em comparação com a indexação baseada em memória. No entanto, um desafio principal está em gerenciar efetivamente os recursos para evitar sobrecarga dos nós de consulta causada por problemas de hotspot de tenants e vizinhos barulhentos. Isso é particularmente crucial, pois cada Query Node deve lidar com o carregamento de dados de múltiplos tenants.
Para aumentar a estabilidade do sistema, introduzimos os três mecanismos importantes a seguir:
Cota distribuída: Esse mecanismo, baseado em um serviço de cota centralizado, aloca dinamicamente cotas de recursos e as ajusta com base na carga dos nós de consulta. Essa alocação dinâmica ajuda a garantir o consumo justo de recursos para cada tenant.
Cota distribuída: Esse mecanismo, baseado em um serviço de cota centralizado, aloca dinamicamente cotas de recursos e as ajusta com base na carga dos nós de consulta. Isso ajuda a garantir o consumo justo de recursos para cada tenant.
Escalabilidade dinâmica de recursos baseada em métricas: Incorporamos um módulo Cloud Resource Scheduler, que gerencia de forma abrangente cargas de memória, disco, CPU e enfileiramento de solicitações. Ele permite o dimensionamento dinâmico de recursos físicos para atender a demandas variáveis de recursos em diferentes cenários.
Agendamento em múltiplas camadas: Estabelecemos uma estrutura de agendamento de recursos que opera em vários níveis, abrangendo o isolamento físico por meio do agrupamento de recursos, o balanceamento de carga dentro desses grupos de recursos e o gerenciamento de filas de consultas e agendamento de cache no nível do nó. Essa abordagem garante a alocação equitativa de recursos entre múltiplos locatários, ao mesmo tempo em que mitiga o risco de qualquer locatário individual monopolizar recursos.
Por meio do nosso serviço Serverless, reduzimos com sucesso o custo de teste para usuários individuais para US$ 5, dando suporte a dezenas de milhares de desenvolvedores de AIGC. Na próxima versão do Zilliz Cloud, estamos aprimorando ainda mais nossa solução Serverless para que seja ainda mais econômica e elástica. Nesta nova versão, cada usuário Serverless poderá lidar com dados de milhões de locatários em uma única coleção, alcançando isolamento de dados enquanto reduz significativamente os custos de armazenamento por um fator de dez em comparação com a solução atual. Continuaremos a nos aprofundar nos detalhes técnicos do Zilliz Cloud Serverless em artigos futuros.
Seis lições que aprendemos ao criar um serviço em nuvem a partir de um VectorDB de código aberto
Reconhecendo as limitações da nuvem: Mesmo com sistemas cloud-native como o Milvus, a transição para SaaS em nuvem apresenta desafios significativos. Ela vai além de uma simples implantação em EC2 e EBS. No domínio dos bancos de dados de código aberto, os usuários devem ter um entendimento profundo das complexidades do produto para alcançar escalabilidade horizontal, recuperação de falhas e otimização de desempenho por meio de ajuste meticuloso de parâmetros. O verdadeiro desafio com serviços em nuvem está em simplificar as operações enquanto se mantém alta confiabilidade e elasticidade. Abordar restrições específicas do ambiente de nuvem, como limites de taxa do S3 e limitações na frequência de chamadas OpenAPI, é crucial para aproveitar plenamente o potencial de elasticidade e escalabilidade da computação em nuvem.
Lançamento prudente de recursos: Embora adicionar continuamente novos recursos nos estágios iniciais do produto possa parecer atraente para conquistar clientes, atender aos verdadeiros pontos problemáticos dos usuários deve ser priorizado. Manter um lead time de aproximadamente seis meses para recursos do produto de código aberto em relação à versão SaaS é um bom compromisso. Esse lead time garante que esses recursos passem por testes e melhorias minuciosos antes de serem lançados para a prestação do serviço.
Defina limites apropriados: Nenhum produto é perfeito. Veja o S3, por exemplo. Apesar de sua interface elegante e amplo refinamento, os desenvolvedores só conseguem maximizar seu valor em determinadas situações. Diferentemente da liberdade que os produtos de código aberto têm, os produtos SaaS exigem restrições mais rigorosas para se protegerem. Essas restrições formam uma parte integral do produto e servem como orientação e educação para os usuários. Limitações razoáveis podem conduzir os usuários a um uso mais inteligente do produto, aumentando o valor geral e a experiência do usuário.
Optar por serviços de dependência agnósticos em relação à nuvem: Considerar a adoção de serviços de dependência agnósticos em relação à nuvem, como S3, EC2 e serviços gerenciados de K8s, que estão amplamente disponíveis nas principais plataformas de nuvem, pode oferecer benefícios substanciais em termos de redução de custos e simplificação das complexidades da adoção multi-cloud. Alternativamente, optar por serviços SaaS que suportem inerentemente o uso multi-cloud pode simplificar o processo. Apesar de possíveis variações na implementação entre diferentes provedores de serviços em nuvem, o estabelecimento antecipado de uma camada de adaptação multi-cloud pode minimizar efetivamente esforços de desenvolvimento redundantes e aumentar a eficiência geral.
Foco em Cloud FinOps: Na nuvem pública, recursos aparentemente acessíveis podem resultar inesperadamente em custos elevados. Por exemplo, antes de realizar uma análise de fatura, ainda não havíamos previsto que os custos de largura de banda de rede do ALB poderiam compor uma parcela significativa das despesas gerais. Para otimizar custos e maximizar as otimizações de desempenho, é essencial compreender completamente o desempenho de diferentes tipos de instância e serviços. Por exemplo, cada disco em nuvem GP3 oferece 3000 IOPS; agrupar vários discos em uma única máquina e configurar RAID permite que a taxa de transferência do disco seja substancialmente aumentada, evitando assim contas pesadas por IOPS adicionais.
Reconheça a importância da Open API: Com a crescente adoção de Agents, o papel da Open API e da documentação relacionada torna-se cada vez mais importante. Serviços de nuvem tradicionais dependem de consoles web e interfaces gráficas para fornecer funcionalidade, mas a interação e integração futuras dos serviços de nuvem dependerão cada vez mais da OpenAPI. O nível de automação de serviços, compatibilidade com Agents e observabilidade tornou-se critério de avaliação fundamental para futuros serviços de nuvem.
Epílogo
Olhando para os últimos 18 meses, embarcamos em uma jornada excepcionalmente empolgante e desafiadora, na qual o tempo parecia passar três vezes mais rápido. Esse progresso rápido pode ser atribuído a vários fatores-chave: Em primeiro lugar, o advento dos LLMs aumentou drasticamente nossa eficiência de codificação. Em segundo lugar, o reconhecimento rápido e unânime dos usuários em relação ao valor dos casos de uso de RAG tornou-se o principal caso de uso da busca vetorial para adquirir novos usuários. Por fim, devemos agradecer a todos os provedores de código aberto, SaaS e serviços de nuvem dos quais dependemos; seus serviços excepcionais ajudaram a acelerar esta jornada.
Devemos gratidão especial aos usuários fiéis do Zilliz Cloud e do Milvus. Seu feedback meticuloso e paciente nos forneceu conselhos e orientações inestimáveis. Seja nos domínios de SaaS ou Serverless, acreditamos firmemente que tudo o que fizemos é apenas o começo. A busca por custo-benefício, desempenho, escalabilidade e facilidade de uso não tem limites.
Agradecimentos
Quero estender um sincero agradecimento aos nossos usuários dedicados, cujo apoio foi fundamental no desenvolvimento do Zilliz Cloud. Seu incentivo foi crucial para compartilhar nossa jornada de construção do Zilliz Cloud, oferecendo insights que podem beneficiar outras pessoas que desejam desenvolver seu serviço de nuvem. Reconhecimento especial vai para os mais de 300 colaboradores da comunidade Milvus por seu trabalho incansável e ao nosso CEO, Charles, por seu apoio inabalável aos nossos empreendimentos técnicos inovadores.
Se você estiver interessado em explorar serviços de busca vetorial, convidamos você a se cadastrar no Zilliz Cloud. Novos registrantes receberão US$ 100 em créditos gratuitos para começar.
Continue lendo
8 Latest RAG Advancements Every Developer Should Know
Explore eight advanced RAG variants that can solve real problems you might be facing: slow retrieval, poor context understanding, multimodal data handling, and resource optimization.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.