Costruire Zilliz Cloud in 18 mesi: lezioni apprese durante la creazione di un servizio di ricerca vettoriale scalabile sul cloud pubblico
Prefazione
I database vettoriali sono emersi come una delle principali tendenze nel settore dei database nel 2023. Questo post descrive in dettaglio la creazione di Zilliz Cloud, un servizio completamente gestito basato su Milvus, il database vettoriale open-source più adottato, sviluppato da zero nell’arco di diciotto mesi. Durante questo periodo, abbiamo sviluppato da zero un servizio cloud completo e affrontato un aumento del traffico di dieci volte, trainato dalla rapida espansione dei Large Language Models (LLM). Questa retrospettiva si concentra sulla condivisione delle scelte di progettazione critiche e delle preziose intuizioni acquisite durante il nostro percorso.
Zilliz Cloud Dedicated Cluster - Il viaggio inizia
Tornando indietro a maggio 2022, il database vettoriale open-source Milvus 2.0 ha finalmente iniziato a stabilizzarsi dopo diverse importanti iterazioni. Attraverso le conversazioni con i nostri utenti, la necessità di una versione stabile e ospitata commercialmente è emersa come una richiesta ricorrente. Per Zilliz, la società commerciale dietro Milvus, il momento sembrava perfetto per intraprendere la commercializzazione: avevamo un team di ingegneri esperto, un prodotto in fase di maturazione e una base di utenti dedicata con esigenze urgenti. Con questo in mente, abbiamo fissato un obiettivo ambizioso: lanciare il nostro prodotto entro sei mesi.
Quando abbiamo avviato il progetto, abbiamo valutato le nostre capacità e i nostri obiettivi attuali:
- La nostra tecnologia principale, un database vettoriale open-source cloud-native progettato con disaggregazione tra storage e computing e un framework a microservizi, è progettata per integrarsi senza soluzione di continuità in un cluster Kubernetes (K8s). Questo framework cloud-native ci consente di adattarci rapidamente agli ambienti di produzione cloud.
Figure 1: Milvus Architecture
Poiché abbiamo utilizzato il Kubernetes Operator, eravamo in grado di distribuire rapidamente servizi sulle principali piattaforme cloud pubbliche come AWS e GCP; ciò è stato confermato da diversi utenti che hanno implementato con successo i loro servizi di produzione sul cloud pubblico.
La nostra piattaforma includeva funzionalità di osservabilità di base come monitoraggio e logging, ma necessitava di funzioni di alerting cruciali per la produzione.
Oltre agli elementi menzionati in precedenza, come servizio, ci mancavano diversi componenti critici, tra cui, a titolo esemplificativo ma non esaustivo, autenticazione per il login degli utenti, misurazione e fatturazione, meccanismi di pagamento, networking, sicurezza, una console Web, supporto OpenAPI, scheduling delle risorse e gestione dei workflow.
Restringere il campo dei moduli essenziali da costruire entro sei mesi rappresentava un compito formidabile. In risposta, ci siamo impegnati in una critica autovalutazione: come potevamo sfruttare le risorse disponibili nel modo più efficiente? Potevamo distillare il nostro approccio per creare una versione snella ma pienamente funzionale? Queste domande cruciali hanno guidato la nostra riflessione e alla fine hanno plasmato una serie di principi di progettazione fondamentali:
Massimizzare l’uso di prodotti di terze parti maturi per evitare di reinventare la ruota:
Ponendo l’accento su una rapida preparazione al mercato, ci siamo appoggiati strategicamente a servizi cloud e di terze parti consolidati. Abbiamo sfruttato i servizi core di AWS, come EKS, EC2, S3, EBS e ALB, insieme a Kafka e RDS gestiti da AWS come spina dorsale della nostra infrastruttura. Questo approccio non solo ha soddisfatto le nostre esigenze immediate, ma ha anche rivelato che tali componenti offrono un percorso conveniente per un futuro adattamento a un ambiente multi-cloud, accelerando così il nostro ritmo di innovazione. Di fronte a problemi di compatibilità tra le code di messaggistica GCP/Azure e i servizi Kafka gestiti, abbiamo sviluppato il nostro sistema di log distribuito, basato su Apache Bookkeeper. La mancanza di soluzioni di logging distribuito affidabili, open-source o cloud-native ha guidato questo sforzo. Motivati da questa lacuna, stiamo valutando di rendere open-source la nostra soluzione, sperando che aiuti altri nella creazione di servizi cloud.
I fornitori SaaS di terze parti sono stati fondamentali per accelerare lo sviluppo della nostra piattaforma. Ad esempio, abbiamo adottato Stripe per gestire l'elaborazione dei pagamenti, affrontando complessi requisiti di misurazione e tassazione. Per facilitare le connessioni con i marketplace multi-cloud, abbiamo integrato Sugar.io. Inoltre, abbiamo valutato piattaforme di servizi di fatturazione come Orb e Metronome per migliorare le nostre operazioni di fatturazione. Auth0 è stato il nostro prodotto di scelta per la gestione degli account e la funzionalità di login; abbiamo ulteriormente ampliato la nostra funzionalità di autenticazione e login per includere il supporto al login con Google. Abbiamo stabilito il nostro sistema di avvisi operativi su PagerDuty, scelto per la sua rapida integrazione con i nostri strumenti di monitoraggio esistenti e la sua versatilità nella personalizzazione delle regole di notifica.
Le entità non devono essere moltiplicate inutilmente
Guidati dalla filosofia del Rasoio di Occam, abbiamo adottato un approccio di design minimalista che si è manifestato in vari aspetti del prodotto:
Semplicità dell'architettura: Inizialmente, il nostro design includeva oltre 60 microservizi, il che poneva sfide significative nella coordinazione dello sviluppo e dei test. Per semplificare la nostra architettura, abbiamo ridotto il numero a meno di dieci microservizi principali, inclusi user, billing, CloudService, resources, metadata e scheduling. Questa riduzione ha chiarito le dipendenze e ridotto il carico di test.
Semplicità funzionale: Nella sua iterazione iniziale, l'enfasi di Zilliz Cloud è stata posta sulle funzionalità utente principali come registrazione, distribuzione di cluster e fatturazione, mentre abbiamo deliberatamente rimandato funzionalità meno urgenti come scalabilità e backup per alleviare il carico di lavoro. Degno di nota è stato il nostro impegno nello stabilire un solido ciclo di feedback, facilitando inizialmente il feedback via email e successivamente potenziandolo con l'integrazione di Zendesk per garantire che un feedback tempestivo e di alta qualità potesse guidarci in ulteriori miglioramenti.
Semplicità del design: Il design del nostro servizio cloud ha dato priorità a una comunicazione efficiente e al potenziale di coinvolgimento degli utenti, richiedendo un approccio disciplinato e focalizzato. Sfruttare rapidi test A/B ci ha permesso di convalidare le funzionalità rapidamente e di adattarci in base alle metriche di coinvolgimento degli utenti.
Anticipare le sfide del Giorno 2 fin dal Giorno 1:
Nel panorama dinamico dei servizi cloud, la capacità di evolversi rapidamente senza sacrificare l'affidabilità delle interfacce utente e dei servizi è fondamentale. Questa manovra intricata assomiglia a "sostituire i motori a reazione in volo." All'osservatore esterno, il servizio funziona perfettamente mentre internamente è in corso un vigoroso ciclo di innovazione e miglioramento. Adottare un approccio di sviluppo orientato al risultato finale è cruciale.
Supporto multi-cloud: Inizialmente focalizzato su AWS, il nostro approccio ha sempre dato priorità all'agnosticismo rispetto al cloud. Abbiamo valutato ampiamente provider come GCP e Alibaba Cloud per garantire la compatibilità tra cloud pubblici. Attraverso personalizzazioni del progetto open-source Crossplane, abbiamo sviluppato un livello di 'cloud adapter', riducendo i costi associati al supporto multi-cloud. Questo design ha facilitato la rapida integrazione con GCP in appena un mese e semplificato l'integrazione con altri provider di cloud pubblico.
Sicurezza: Mentre gli sviluppatori di applicazioni AIGC potrebbero dare priorità a qualcosa di diverso dalla sicurezza, Zilliz Cloud Services attribuisce la massima importanza alla sicurezza dei dati. Aderendo rigorosamente agli standard IAM del cloud, controlliamo meticolosamente le autorizzazioni di accesso ai dati e utilizziamo la crittografia per tutti i dati, sia in transito sia a riposo. Enfatizzando l'isolamento della rete per prestazioni ottimali, abbiamo scelto gli add-on di rete EKS di AWS per la loro efficienza e facilità d'uso. Delineare i confini di interazione tra i livelli dati e controllo ha comportato significativi risparmi sui costi durante il rollout del nostro prodotto BYOC.
Pooling delle risorse: Zilliz Cloud Services adotta la "legge della commutatività del cloud", dando priorità alla scalabilità elastica tramite il pooling delle risorse. Separando storage e calcolo e impiegando il bilanciamento dinamico del carico, garantiamo un utilizzo efficiente delle risorse cloud. Questo approccio ci consente di riservare risorse solo quando necessario, migliorando significativamente l'utilizzo di Spot Instances e funzioni Lambda e riducendo al contempo i costi.
Orientato alle operazioni: Zilliz Cloud è progettato pensando agli sviluppatori e al personale operativo, a differenza di altri database vettoriali. Dotata di una GUI completa e di sofisticate capacità di monitoraggio, la piattaforma offre disaster recovery su tripla AZ e rispetta SLA rigorosi, garantendo stabilità e affidabilità per gli ambienti di produzione.
Guidati dalle nostre filosofie di progettazione fondamentali, abbiamo raggiunto il traguardo del lancio del nostro prodotto commerciale di ricerca vettoriale in soli sei mesi, assicurandoci nel processo il nostro gruppo iniziale di clienti seed. Di seguito, troverai il diagramma architetturale della nostra release inaugurale.
Figura 2- Architettura di Zilliz Cloud
Serverless: da $300 a $5 di costo di acquisizione di nuovi utenti
La crescita spesso avviene in momenti inaspettati. Dopo aver registrato una crescita costante nei nostri servizi SaaS per tre mesi, la crescita di Zilliz Cloud, alimentata dall'esplosiva popolarità di AutoGPT, ha raggiunto un picco. La visione dei database vettoriali come memoria a lungo termine per i Large Language models ha gradualmente ottenuto consenso, portando a un rapido aumento della base utenti di Zilliz, con il numero di nuovi cluster aggiunti quotidianamente che ha rapidamente raggiunto le centinaia.
Tuttavia, questa crescita ha portato due sfide principali a Zilliz: stabilità e costi. Sebbene ci fossimo sempre concentrati sulla scalabilità, gli improvvisi picchi di traffico elevato hanno quasi paralizzato tutti i nostri servizi, con solo il database principale che ne è uscito indenne. Le API fornite dai cloud service provider sono state soggette a throttling e il nostro sistema di archiviazione dei log, Loki, si è riempito due volte in pochi giorni, costringendo molti servizi a essere interrotti a causa della mancanza di risorse.
Inoltre, la strategia iniziale di prova gratuita adottata da Zilliz Cloud, che offriva $300 Credits ai nuovi utenti per provare tutte le funzionalità, ha portato a un forte aumento dei costi con l'impennata del numero di utenti (la maggior parte dei quali stava provando il servizio), costringendoci a ripensare il nostro modello di business. Questi punti critici ci hanno spinto a lanciare Zilliz Cloud Serverless, un prodotto più flessibile, con una barriera d'ingresso più bassa e più adatto agli utenti AIGC che stanno appena iniziando il loro percorso con i database vettoriali.
Il Santo Graal è ancora là fuori: domare scalabilità, costi e latenza per lo sviluppo di applicazioni RAG
Per il caso d'uso Retrieval-Augmented Generation (RAG) , la soluzione ideale di livello gratuito deve considerare quanto segue:
Figura 3: Domare scalabilità, costi e latenza nell'applicazione RAG
Scalabilità — Questo comprende due aspetti chiave:
A livello di singolo tenant, il sistema deve scalare dinamicamente per elaborare i dati in modo efficace. Questa scalabilità dinamica richiede che il database vettoriale sia abbastanza versatile da adattarsi ai volumi di dati fluttuanti dei diversi tenant, sia che elaborino dataset piccoli o grandi. Devono essere mantenuti tempi di risposta alle query costantemente stabili, indipendentemente dalla dimensione dei dati gestiti.
Nella gestione di molti tenant, il sistema deve supportare in modo efficiente la scalabilità fino a milioni di tenant. In particolare, dovrebbe differenziare e accomodare in modo intelligente i modelli di utilizzo 'hot' (altamente attivi) e 'cold' (meno attivi), garantendo un'allocazione ottimale delle risorse e una coerenza delle prestazioni su tutta la linea.
Costo — Il controllo dei costi per il piano gratuito è cruciale. Idealmente, il costo dovrebbe essere mantenuto sotto $1, fornendo al contempo risorse sufficienti per supportare 1 milione di vettori a 768 dimensioni. Tuttavia, quando si fa affidamento sull’indicizzazione vettoriale in memoria, il prezzo per gestire 1 milione di vettori a 768 dimensioni può facilmente superare $10. Sebbene questo costo possa essere accettabile per le aziende SaaS che puntano a servizi enterprise, è eccessivo per le applicazioni ToC rivolte ai consumatori.
Bassa latenza — Sebbene i casi d’uso RAG possano non essere sensibili alla latenza quanto i domini di ricerca e raccomandazione, le prestazioni del recupero vettoriale incidono in modo significativo sul "Time-to-first-token." Pertanto, mantenere una bassa latenza è cruciale per migliorare l’esperienza utente e la reattività del sistema.
L’offerta iniziale di Zilliz Cloud ha dimostrato una scalabilità eccezionale nella gestione di grandi volumi di dati e nel raggiungimento di una bassa latenza, superando le aspettative degli utenti. Anche con la gestione di numerosi tenant e il controllo dei costi, la soluzione con cluster dedicato non è riuscita a soddisfare pienamente le esigenze degli utenti. Per porvi rimedio, abbiamo sviluppato il 'Zilliz Serverless Tier,' un modello di servizio progettato specificamente per ridurre la barriera d’ingresso per i singoli utenti AIGC. Questo livello offre le soluzioni di archiviazione più convenienti e la scalabilità necessaria per affrontare efficacemente le sfide menzionate sopra.
L’architettura Serverless di Zilliz Cloud
Figura 4- L’architettura Serverless di Zilliz Cloud
Zilliz Cloud Serverless introduce il concetto di cluster logici, in cui ogni cluster logico corrisponde a un database in un cluster fisico. Otteniamo l’isolamento logico per tutti i tenant all’interno di un singolo cluster fisico tramite meccanismi di autenticazione basati su database e API key. Durante le query, il sistema instrada le richieste in base alle API key per determinare i dati a cui gli utenti devono accedere, utilizzando nodi proxy per il routing.
Le operazioni di scrittura dei dati vengono inizialmente inviate a un pool di nodi di log, che quindi scrivono i dati in un servizio di Write-Ahead Logging (WAL), riorganizzando periodicamente i dati e scaricandoli nell’object storage. Il CompactionService è un servizio di pooling responsabile del consolidamento dei segmenti di dati più piccoli in segmenti più grandi e dell’eliminazione delle voci cancellate, ottimizzando lo spazio di archiviazione e la velocità di accesso. L’Index Service è responsabile della costruzione degli indici sui dati grezzi, che vengono poi caricati dai nodi di query per garantire l’efficienza delle query.
Durante le operazioni di query, la nostra strategia prevede la memorizzazione nella cache di tutti i dati sui dischi locali dei Query Nodes e l’esecuzione locale dello swapping da memoria a disco. Questa metodologia riduce in modo significativo i costi di archiviazione per gli utenti Serverless di oltre dieci volte rispetto all’indicizzazione basata sulla memoria. Tuttavia, una sfida primaria consiste nel gestire efficacemente le risorse per prevenire il sovraccarico dei nodi di query causato da problemi di hotspot dei tenant e da noisy neighbors. Questo è particolarmente cruciale poiché ogni Query Node deve gestire il caricamento dei dati da più tenant.
Per migliorare la stabilità del sistema, abbiamo introdotto i seguenti tre importanti meccanismi:
Quota distribuita: Questo meccanismo, basato su un servizio di quota centralizzato, alloca dinamicamente le quote di risorse e le regola in base al carico dei nodi di query. Questa allocazione dinamica aiuta a garantire un consumo equo delle risorse per ciascun tenant.
Quota distribuita: Questo meccanismo, basato su un servizio di quota centralizzato, alloca dinamicamente le quote di risorse e le regola in base al carico dei nodi di query. Questo aiuta a garantire un consumo equo delle risorse per ciascun tenant.
Scalabilità dinamica delle risorse basata su metriche: Abbiamo incorporato un modulo Cloud Resource Scheduler, che gestisce in modo completo memoria, disco, carichi CPU e accodamento delle richieste. Consente la scalabilità dinamica delle risorse fisiche per soddisfare le diverse esigenze di risorse in scenari differenti.
Pianificazione multilivello: Abbiamo stabilito un framework di pianificazione delle risorse che opera su vari livelli, comprendendo l'isolamento fisico tramite il raggruppamento delle risorse, il bilanciamento del carico all'interno di questi gruppi di risorse e la gestione delle code di query e della pianificazione della cache a livello di nodo. Questo approccio garantisce un'allocazione equa delle risorse tra più tenant, mitigando al contempo il rischio che un singolo tenant monopolizzi le risorse.
Attraverso il nostro servizio Serverless, abbiamo ridotto con successo il costo di prova per i singoli utenti a 5 $, supportando decine di migliaia di sviluppatori AIGC. Nella prossima release di Zilliz Cloud, stiamo migliorando ulteriormente la nostra soluzione Serverless affinché sia ancora più conveniente ed elastica. In questa nuova versione, ogni utente Serverless sarà in grado di gestire dati provenienti da milioni di tenant in una singola collection, ottenendo l'isolamento dei dati e riducendo significativamente i costi di storage di un fattore dieci rispetto alla soluzione attuale. Continueremo ad approfondire i dettagli tecnici di Zilliz Cloud Serverless in articoli futuri.
Sei lezioni che abbiamo imparato costruendo un servizio cloud da un VectorDB open-source
Riconoscere i limiti del cloud: Anche con sistemi cloud-native come Milvus, la transizione al SaaS cloud presenta sfide significative. Va oltre un semplice deployment su EC2 ed EBS. Nel dominio dei database open-source, gli utenti devono possedere una profonda comprensione delle complessità del prodotto per ottenere scalabilità orizzontale, ripristino dai guasti e ottimizzazione delle prestazioni attraverso una meticolosa regolazione dei knob. La vera sfida con i servizi cloud risiede nello snellire le operazioni mantenendo al contempo elevata affidabilità ed elasticità. Affrontare vincoli specifici dell'ambiente cloud, come i limiti di frequenza di S3 e le limitazioni sulla frequenza delle chiamate OpenAPI, è cruciale per sfruttare appieno il potenziale di elasticità e scalabilità del cloud computing.
Rilascio prudente delle funzionalità: Sebbene aggiungere continuamente nuove funzionalità nelle fasi iniziali del prodotto possa sembrare allettante per attrarre clienti, è necessario dare priorità ai reali punti dolenti degli utenti. Mantenere un lead time di circa sei mesi per le funzionalità del prodotto open-source rispetto alla versione SaaS è un buon compromesso. Questo lead time assicura che tali funzionalità vengano sottoposte a test e miglioramenti approfonditi prima di essere rilasciate per la fornitura del servizio.
Impostare limiti appropriati: Nessun prodotto è impeccabile. Prendiamo S3, ad esempio. Nonostante la sua interfaccia elegante e l'ampio perfezionamento, gli sviluppatori possono massimizzarne il valore solo in determinate situazioni. A differenza della libertà di cui possono godere i prodotti open-source, i prodotti SaaS richiedono vincoli più rigorosi per salvaguardarsi. Questi vincoli costituiscono parte integrante del prodotto e fungono da guida ed educazione per gli utenti. Limitazioni ragionevoli possono orientare gli utenti verso un uso più intelligente del prodotto, migliorando il valore complessivo e l'esperienza utente.
Optare per servizi di dipendenza cloud-agnostic: Considerare l'adozione di servizi di dipendenza cloud-agnostic come S3, EC2 e servizi gestiti K8s, ampiamente disponibili sulle principali piattaforme cloud, può offrire vantaggi sostanziali in termini di riduzione dei costi e semplificazione delle complessità legate all'adozione multi-cloud. In alternativa, optare per servizi SaaS che supportano intrinsecamente l'uso multi-cloud può snellire il processo. Nonostante potenziali variazioni nell'implementazione tra diversi provider di servizi cloud, l'istituzione precoce di un layer di adattamento multi-cloud può minimizzare efficacemente gli sforzi di sviluppo ridondanti e migliorare l'efficienza complessiva.
Concentrarsi sul Cloud FinOps: Nel cloud pubblico, risorse apparentemente convenienti possono inaspettatamente tradursi in costi elevati. Ad esempio, prima di condurre un'analisi della fattura, non avevamo ancora previsto che i costi della larghezza di banda di rete degli ALB potessero rappresentare una parte significativa delle spese complessive. Per ottimizzare i costi e massimizzare le ottimizzazioni delle prestazioni, è essenziale comprendere a fondo le prestazioni dei diversi tipi di istanze e servizi. Ad esempio, ogni disco cloud GP3 offre 3000 IOPS; raggruppare più dischi su una singola macchina e configurare RAID consente di aumentare sostanzialmente il throughput del disco, evitando così fatture salate per IOPS aggiuntivi.
Riconoscere l'importanza di Open API: Con la crescente adozione degli Agent, il ruolo di Open API e della relativa documentazione diventa sempre più importante. I servizi cloud tradizionali si affidano a console web e interfacce grafiche per offrire funzionalità, ma l'interazione e l'integrazione future dei servizi cloud dipenderanno sempre più da OpenAPI. Il livello di automazione del servizio, la compatibilità con gli Agent e l'osservabilità sono diventati criteri di valutazione fondamentali per i servizi cloud futuri.
Epilogo
Ripensando agli ultimi 18 mesi, abbiamo intrapreso un viaggio eccezionalmente entusiasmante e impegnativo, in cui il tempo sembrava passare a velocità tripla. Questo rapido progresso può essere attribuito a diversi fattori chiave: in primo luogo, l'avvento degli LLM ha migliorato drasticamente la nostra efficienza nella scrittura del codice. In secondo luogo, il riconoscimento rapido e unanime da parte degli utenti del valore dei casi d'uso RAG è diventato il caso d'uso principale per la ricerca vettoriale nell'acquisizione di nuovi utenti. Infine, dobbiamo ringraziare tutti i fornitori open-source, SaaS e di servizi cloud da cui dipendiamo; i loro servizi eccezionali hanno contribuito ad accelerare questo percorso.
Dobbiamo una gratitudine speciale agli utenti fedeli di Zilliz Cloud e Milvus. Il vostro feedback meticoloso e paziente ci ha fornito consigli e indicazioni inestimabili. Sia nell'ambito del SaaS sia in quello Serverless, crediamo fermamente che tutto ciò che abbiamo fatto sia solo l'inizio. La ricerca di convenienza, prestazioni, scalabilità e facilità d'uso non conosce limiti.
Ringraziamenti
Desidero esprimere un sentito ringraziamento ai nostri utenti dedicati, il cui supporto è stato determinante nello sviluppo di Zilliz Cloud. Il vostro incoraggiamento è stato fondamentale nel condividere il nostro percorso per costruire Zilliz Cloud, offrendo spunti che potrebbero essere utili ad altri che desiderano sviluppare il proprio servizio cloud. Un riconoscimento speciale va agli oltre 300 contributori della community Milvus per il loro instancabile lavoro e al nostro CEO, Charles, per il suo incrollabile sostegno ai nostri innovativi sforzi tecnici.
Se siete interessati a esplorare i servizi di ricerca vettoriale, vi invitiamo a registrarvi a Zilliz Cloud. I nuovi registrati riceveranno $100 in crediti gratuiti per iniziare.
Continua a leggere
Zilliz Skills Breakdown: How AI Agents Master Vector Databases
Zilliz's Milvus Skill (pymilvus, 7 files) and Zilliz Cloud Skill (zilliz-cli, 14 modules) bring vector-DB dev and ops into one Claude Code session.
Smarter Autoscaling in Zilliz Cloud: Always Optimized for Every Workload
With the latest upgrade, Zilliz Cloud introduces smarter autoscaling—a fully automated, more streamlined, elastic resource management system.
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.