Créer Zilliz Cloud en 18 mois : leçons apprises lors de la création d’un service de recherche vectorielle évolutif sur le cloud public
Préface
Les bases de données vectorielles se sont imposées comme une tendance majeure dans le secteur des bases de données en 2023. Cet article détaille la création de Zilliz Cloud, un service entièrement géré propulsé par Milvus, la base de données vectorielle open source la plus adoptée, développée de A à Z sur dix-huit mois. Tout au long de cette période, nous avons développé un service cloud complet à partir de rien et fait face à une multiplication par dix du trafic, portée par l’expansion rapide des grands modèles de langage (LLM). Cette rétrospective vise à partager les choix de conception essentiels et les enseignements précieux acquis au cours de notre parcours.
Zilliz Cloud Dedicated Cluster - Le voyage commence
Revenons en mai 2022 : la base de données vectorielle open source Milvus 2.0 commençait enfin à se stabiliser après plusieurs itérations majeures. À travers nos échanges avec les utilisateurs, le besoin d’une version stable, hébergée commercialement, est apparu comme une demande récurrente. Pour Zilliz, l’entreprise commerciale derrière Milvus, le moment semblait idéal pour se lancer dans la commercialisation : nous disposions d’une équipe d’ingénieurs expérimentée, d’un produit en cours de maturation et d’une base d’utilisateurs engagés ayant des besoins urgents. Dans cette optique, nous nous sommes fixé un objectif ambitieux : lancer notre produit en six mois.
Au lancement du projet, nous avons évalué nos capacités et objectifs actuels :
- Notre technologie de base, une base de données vectorielle open source cloud-native conçue avec une désagrégation stockage-calcul et une architecture de microservices, est pensée pour une intégration fluide dans un cluster Kubernetes (K8s). Cette architecture cloud-native nous permet de nous adapter rapidement aux environnements de production cloud.
Figure 1 : Architecture de Milvus
Comme nous utilisions Kubernetes Operator, nous étions en mesure de déployer rapidement des services sur les principales plateformes de cloud public telles qu’AWS et GCP ; cela a été confirmé par plusieurs utilisateurs qui ont mis en œuvre avec succès leurs services de production sur le cloud public.
Notre plateforme comprenait des fonctionnalités d’observabilité de base, telles que la surveillance et la journalisation, mais elle avait besoin de fonctions d’alerte cruciales pour la production.
En plus des éléments mentionnés précédemment, en tant que service, il nous manquait plusieurs composants critiques, notamment, sans s’y limiter, l’authentification de connexion utilisateur, la mesure et la facturation, les mécanismes de paiement, la mise en réseau, la sécurité, une console Web, la prise en charge d’OpenAPI, la planification des ressources et la gestion des workflows.
Déterminer quels modules essentiels construire en six mois représentait une tâche redoutable. En réponse, nous avons entrepris une auto-évaluation critique : comment pouvions-nous exploiter les ressources disponibles le plus efficacement possible ? Pouvions-nous simplifier notre approche afin de créer une version allégée mais pleinement fonctionnelle ? Ces questions décisives ont guidé notre réflexion et ont finalement façonné un ensemble de principes de conception fondamentaux :
Maximiser l’utilisation de produits tiers matures pour éviter de réinventer la roue :
En mettant l’accent sur une mise sur le marché rapide, nous nous sommes stratégiquement appuyés sur des services cloud et tiers établis. Nous avons exploité les services essentiels d’AWS, tels qu’EKS, EC2, S3, EBS et ALB, ainsi que Kafka et RDS gérés par AWS comme socle de notre infrastructure. Cette approche a non seulement répondu à nos besoins immédiats, mais a également révélé que ces composants offrent une voie rentable pour une adaptation future à un environnement multi-cloud, accélérant ainsi notre rythme d’innovation. Confrontés à des problèmes de compatibilité entre les files de messages GCP/Azure et les services Kafka gérés, nous avons développé notre système de journal distribué, ancré sur Apache Bookkeeper. Le manque de solutions de journalisation distribuée fiables, open source ou cloud-native a motivé cette initiative. Encouragés par cette lacune, nous envisageons d’ouvrir notre solution en open source, dans l’espoir qu’elle aidera d’autres personnes à construire des services cloud.
Les fournisseurs SaaS tiers ont joué un rôle déterminant dans l’accélération du développement de notre plateforme. Par exemple, nous avons adopté Stripe pour gérer notre traitement des paiements, en répondant à des exigences complexes de mesure et de fiscalité. Pour faciliter les connexions avec les marketplaces multi-cloud, nous avons intégré Sugar.io. De plus, nous avons évalué des plateformes de services de facturation telles qu’Orb et Metronome afin d’améliorer nos opérations de facturation. Auth0 était notre produit de choix pour la gestion des comptes et la fonctionnalité de connexion ; nous avons en outre étendu notre fonctionnalité d’authentification et de connexion afin d’inclure la prise en charge de la connexion Google. Nous avons établi notre système d’alertes opérationnelles sur PagerDuty, choisi pour son intégration rapide avec nos outils de surveillance existants et sa polyvalence dans la personnalisation des règles de notification.
Les entités ne doivent pas être multipliées inutilement
Guidés par la philosophie du rasoir d’Occam, nous avons adopté une approche de conception minimaliste qui s’est manifestée dans divers aspects du produit :
Simplicité de l’architecture : Initialement, notre conception comprenait plus de 60 microservices, ce qui posait d’importants défis en matière de coordination du développement et des tests. Pour simplifier notre architecture, nous avons ramené ce nombre à moins de dix microservices principaux, notamment user, billing, CloudService, resources, metadata et scheduling. Cette réduction a clarifié les dépendances et allégé la charge de test.
Simplicité fonctionnelle : Dans sa première itération, l’accent de Zilliz Cloud a été mis sur les fonctionnalités utilisateur essentielles telles que l’inscription, le déploiement de clusters et la facturation, tandis que nous avons délibérément reporté des fonctionnalités moins urgentes comme la mise à l’échelle et les sauvegardes afin d’alléger la charge de travail. Il convient de souligner notre engagement à établir une boucle de rétroaction robuste, en facilitant d’abord les retours par e-mail, puis en les complétant par une intégration Zendesk afin de garantir que des retours rapides et de haute qualité puissent nous guider dans de nouvelles améliorations.
Simplicité de conception : La conception de notre service cloud privilégiait une communication efficace et le potentiel d’engagement des utilisateurs, nécessitant une approche disciplinée et ciblée. L’exploitation de tests A/B rapides nous a permis de valider rapidement les fonctionnalités et de nous adapter en fonction des indicateurs d’engagement des utilisateurs.
Anticiper les défis du Jour 2 dès le Jour 1 :
Dans le paysage dynamique des services cloud, la capacité à évoluer rapidement sans sacrifier la fiabilité des interfaces utilisateur et des services est primordiale. Cette manœuvre complexe ressemble à « remplacer les réacteurs d’un avion en plein vol ». Pour l’observateur externe, le service fonctionne parfaitement tandis qu’un cycle vigoureux d’innovation et d’amélioration est en cours en interne. Il est crucial d’adopter une approche de développement axée sur l’objectif final.
Prise en charge multi-cloud : Initialement axée sur AWS, notre approche a toujours privilégié l’indépendance vis-à-vis du cloud. Nous avons évalué en profondeur des fournisseurs comme GCP et Alibaba Cloud afin de garantir la compatibilité entre clouds publics. Grâce à des personnalisations du projet open-source Crossplane, nous avons développé une couche « cloud adapter », réduisant les coûts associés à la prise en charge multi-cloud. Cette conception a facilité une intégration rapide avec GCP en seulement un mois et a rationalisé l’intégration avec d’autres fournisseurs de cloud public.
Sécurité : Bien que les développeurs d’applications AIGC puissent accorder la priorité à autre chose qu’à la sécurité, Zilliz Cloud Services accorde une importance capitale à la sécurité des données. En adhérant strictement aux normes cloud IAM, nous contrôlons méticuleusement les autorisations d’accès aux données et employons le chiffrement pour toutes les données, tant en transit qu’au repos. En mettant l’accent sur l’isolation réseau pour des performances optimales, nous avons sélectionné les add-ons réseau EKS d’AWS pour leur efficacité et leur convivialité. La délimitation des frontières d’interaction entre les couches de données et de contrôle a permis de réaliser d’importantes économies lors du déploiement de notre produit BYOC.
Mutualisation des ressources : Zilliz Cloud Services adopte la « loi de commutativité du cloud », en donnant la priorité à l’évolutivité élastique grâce à la mutualisation des ressources. En séparant le stockage et le calcul et en employant un équilibrage de charge dynamique, nous garantissons une utilisation efficace des ressources cloud. Cette approche nous permet de réserver des ressources uniquement lorsque cela est nécessaire, améliorant considérablement l’utilisation des Spot Instances et des fonctions Lambda tout en réduisant les coûts.
Adapté aux opérations : Zilliz Cloud est conçu en pensant aux développeurs et au personnel opérationnel, contrairement à d’autres bases de données vectorielles. Dotée d’une interface graphique complète et de capacités de surveillance sophistiquées, la plateforme offre une reprise après sinistre sur trois AZ et respecte des SLA stricts, garantissant stabilité et fiabilité pour les environnements de production.
Guidés par nos philosophies de conception fondamentales, nous avons atteint le jalon du lancement de notre produit commercial de recherche vectorielle en seulement six mois, tout en sécurisant notre premier groupe de clients d’amorçage. Vous trouverez ci-dessous le diagramme d’architecture de notre première version.
Figure 2- Architecture de Zilliz Cloud
Serverless : De $300 à $5 de coût d’acquisition d’un nouvel utilisateur
La croissance survient souvent à des moments inattendus. Après trois mois de croissance régulière de nos services SaaS, la croissance de Zilliz Cloud, alimentée par la popularité explosive d’AutoGPT, a atteint un sommet. L’idée de considérer les bases de données vectorielles comme une mémoire à long terme pour les grands modèles de langage a progressivement été acceptée, entraînant une augmentation rapide de la base d’utilisateurs de Zilliz, le nombre de nouveaux clusters ajoutés quotidiennement atteignant rapidement plusieurs centaines.
Cependant, cette croissance a apporté deux défis majeurs à Zilliz : la stabilité et le coût. Bien que nous nous soyons toujours concentrés sur l’évolutivité, les pics soudains de trafic élevé ont presque paralysé tous nos services, seule la base de données principale en sortant indemne. Les API fournies par les fournisseurs de services cloud ont été limitées, et notre système de stockage de journaux, Loki, a été saturé deux fois en seulement quelques jours, forçant l’interruption de nombreux services en raison d’un manque de ressources.
De plus, la stratégie initiale d’essai gratuit adoptée par Zilliz Cloud, qui offrait $300 de crédits aux nouveaux utilisateurs pour découvrir toutes les fonctionnalités, a entraîné une forte augmentation des coûts à mesure que le nombre d’utilisateurs explosait (la plupart essayant simplement le service), nous obligeant à repenser notre modèle économique. Ces points de douleur nous ont incités à lancer Zilliz Cloud Serverless, un produit plus flexible, avec une barrière à l’entrée plus faible, et plus adapté aux utilisateurs d’AIGC qui débutent leur parcours avec les bases de données vectorielles.
Le Saint Graal reste à trouver : maîtriser l’évolutivité, le coût et la latence pour le développement d’applications RAG
Pour le cas d’utilisation Retrieval-Augmented Generation (RAG) , la solution de niveau gratuit idéale doit prendre en compte les éléments suivants :
Figure 3 : Maîtriser l’évolutivité, le coût et la latence dans une application RAG
Évolutivité — Cela englobe deux aspects clés :
Au niveau du locataire individuel, le système doit évoluer dynamiquement pour traiter efficacement les données. Cette mise à l’échelle dynamique exige que la base de données vectorielle soit suffisamment polyvalente pour s’adapter aux volumes de données fluctuants de différents locataires, qu’ils traitent de petits ou de grands ensembles de données. Des temps de réponse aux requêtes constamment stables doivent être maintenus, quelle que soit la taille des données traitées.
Dans la gestion d’un grand nombre de locataires, le système doit prendre en charge efficacement l’évolutivité jusqu’à des millions de locataires. Plus précisément, il doit différencier et prendre en charge intelligemment les modèles d’utilisation « chauds » (très actifs) et « froids » (moins actifs), garantissant une allocation optimale des ressources et une constance des performances sur l’ensemble.
Coût — Le contrôle des coûts pour le niveau gratuit est crucial. Idéalement, le coût devrait être maintenu en dessous de $1 tout en fournissant suffisamment de ressources pour prendre en charge 1 million de vecteurs à 768 dimensions. Cependant, lorsqu’on s’appuie sur l’indexation vectorielle en mémoire, le prix pour gérer 1 million de vecteurs à 768 dimensions peut facilement dépasser $10. Bien que ce coût puisse être acceptable pour les entreprises SaaS ciblant des services aux entreprises, il est excessif pour les applications ToC destinées aux consommateurs.
Faible latence — Bien que les cas d’utilisation RAG ne soient peut-être pas aussi sensibles à la latence que les domaines de la recherche et de la recommandation, les performances de la récupération vectorielle ont un impact significatif sur le « Time-to-first-token ». Par conséquent, maintenir une faible latence est crucial pour améliorer l’expérience utilisateur et la réactivité du système.
L’offre initiale de Zilliz Cloud a démontré une évolutivité exceptionnelle pour gérer de grands volumes de données et atteindre une faible latence, dépassant les attentes des utilisateurs. Même avec la gestion de nombreux locataires et le contrôle des coûts, la solution de cluster dédié n’a pas pleinement satisfait les demandes des utilisateurs. Pour y remédier, nous avons développé le « Zilliz Serverless Tier », un modèle de service spécialement conçu pour réduire la barrière d’entrée pour les utilisateurs individuels d’AIGC. Ce niveau offre les solutions de stockage les plus rentables et une évolutivité permettant de relever efficacement les défis mentionnés ci-dessus.
L’architecture Serverless de Zilliz Cloud
Figure 4- The Zilliz Cloud Serverless Architecture
Zilliz Cloud Serverless introduit le concept de clusters logiques, où chaque cluster logique correspond à une base de données dans un cluster physique. Nous assurons l’isolation logique de tous les locataires au sein d’un seul cluster physique grâce à des mécanismes d’authentification basés sur les bases de données et les clés API. Lors des requêtes, le système achemine les demandes en fonction des clés API afin de déterminer les données auxquelles les utilisateurs doivent accéder, en utilisant des nœuds proxy pour le routage.
Les opérations d’écriture de données sont d’abord envoyées à un pool de nœuds de journalisation, qui écrivent ensuite les données dans un service Write-Ahead Logging (WAL), réorganisant périodiquement les données et les vidant dans le stockage objet. Le CompactionService est un service mutualisé chargé de consolider les segments de données plus petits en segments plus grands et de purger les entrées supprimées, optimisant ainsi l’espace de stockage et la vitesse d’accès. L’Index Service est responsable de la création des index sur les données brutes, qui sont ensuite chargés par les nœuds de requête afin d’assurer l’efficacité des requêtes.
Lors des opérations de requête, notre stratégie consiste à mettre en cache toutes les données sur les disques locaux des Query Nodes et à exécuter localement l’échange mémoire-disque. Cette méthodologie réduit considérablement les coûts de stockage pour les utilisateurs Serverless, de plus de dix fois par rapport à l’indexation basée sur la mémoire. Cependant, un défi majeur consiste à gérer efficacement les ressources afin d’éviter la surcharge des nœuds de requête causée par les problèmes de points chauds des locataires et les voisins bruyants. Ceci est particulièrement crucial, car chaque Query Node doit gérer le chargement de données provenant de plusieurs locataires.
Pour renforcer la stabilité du système, nous avons introduit les trois mécanismes importants suivants :
Quota distribué : Ce mécanisme, basé sur un service de quota centralisé, alloue dynamiquement des quotas de ressources et les ajuste en fonction de la charge des nœuds de requête. Cette allocation dynamique contribue à garantir une consommation équitable des ressources pour chaque locataire.
Quota distribué : Ce mécanisme, basé sur un service de quota centralisé, alloue dynamiquement des quotas de ressources et les ajuste en fonction de la charge des nœuds de requête. Cela contribue à garantir une consommation équitable des ressources pour chaque locataire.
Mise à l’échelle dynamique des ressources basée sur les métriques : Nous avons intégré un module Cloud Resource Scheduler, qui gère de manière globale la mémoire, le disque, les charges CPU et la mise en file d’attente des requêtes. Il permet une mise à l’échelle dynamique des ressources physiques afin de répondre aux demandes variables en ressources dans différents scénarios.
Planification multiniveau : Nous avons établi un cadre de planification des ressources qui fonctionne à différents niveaux, englobant l’isolation physique par le regroupement des ressources, l’équilibrage de charge au sein de ces groupes de ressources, ainsi que la gestion des files d’attente de requêtes et de la planification du cache au niveau des nœuds. Cette approche garantit une allocation équitable des ressources entre plusieurs locataires tout en atténuant le risque qu’un seul locataire monopolise les ressources.
Grâce à notre service Serverless, nous avons réussi à réduire le coût d’essai pour les utilisateurs individuels à 5 $, en soutenant des dizaines de milliers de développeurs AIGC. Dans la prochaine version de Zilliz Cloud, nous améliorons encore notre solution Serverless pour la rendre encore plus économique et élastique. Dans cette nouvelle version, chaque utilisateur Serverless pourra traiter les données de millions de locataires dans une seule collection, assurant l’isolation des données tout en réduisant considérablement les coûts de stockage d’un facteur dix par rapport à la solution actuelle. Nous continuerons à approfondir les détails techniques de Zilliz Cloud Serverless dans de futurs articles.
Six leçons que nous avons tirées de la création d’un service cloud à partir d’une VectorDB open source
Reconnaître les limites du cloud : Même avec des systèmes cloud-native comme Milvus, la transition vers un SaaS cloud pose des défis considérables. Elle va au-delà d’un simple déploiement sur EC2 et EBS. Dans le domaine des bases de données open source, les utilisateurs doivent posséder une compréhension approfondie des subtilités du produit pour parvenir à une mise à l’échelle horizontale, une reprise après panne et une optimisation des performances grâce à un réglage minutieux des paramètres. Le véritable défi des services cloud réside dans la rationalisation des opérations tout en maintenant une fiabilité et une élasticité élevées. Il est essentiel de traiter les contraintes spécifiques de l’environnement cloud, telles que les limites de débit de S3 et les limitations de fréquence des appels OpenAPI, pour tirer pleinement parti du potentiel d’élasticité et de scalabilité du cloud computing.
Déploiement prudent des fonctionnalités : Bien que l’ajout continu de nouvelles fonctionnalités aux premiers stades du produit puisse sembler séduisant pour attirer des clients, il faut donner la priorité à la résolution des véritables points de douleur des utilisateurs. Maintenir un délai d’avance d’environ six mois pour les fonctionnalités du produit open source par rapport à la version SaaS constitue un bon compromis. Ce délai garantit que ces fonctionnalités font l’objet de tests et d’améliorations approfondis avant d’être déployées pour la fourniture du service.
Fixer des limites appropriées : Aucun produit n’est parfait. Prenons S3, par exemple. Malgré son interface élégante et son raffinement poussé, les développeurs ne peuvent en maximiser la valeur que dans certaines situations. Contrairement à la liberté dont bénéficient les produits open source, les produits SaaS nécessitent des contraintes plus strictes pour se protéger. Ces contraintes font partie intégrante du produit et servent de guide et d’éducation pour les utilisateurs. Des limitations raisonnables peuvent orienter les utilisateurs vers une utilisation plus intelligente du produit, améliorant ainsi la valeur globale et l’expérience utilisateur.
Opter pour des services de dépendance cloud-agnostic : Envisager l’adoption de services de dépendance cloud-agnostic comme S3, EC2 et les services managés K8s, qui sont largement disponibles sur les principales plateformes cloud, peut offrir des avantages substantiels en matière de réduction des coûts et de simplification des complexités liées à l’adoption du multi-cloud. À défaut, opter pour des services SaaS qui prennent intrinsèquement en charge l’utilisation multi-cloud peut rationaliser le processus. Malgré d’éventuelles variations de mise en œuvre entre les différents fournisseurs de services cloud, l’établissement précoce d’une couche d’adaptation multi-cloud peut minimiser efficacement les efforts de développement redondants et améliorer l’efficacité globale.
Se concentrer sur le Cloud FinOps : Dans le cloud public, des ressources apparemment abordables peuvent entraîner de manière inattendue des coûts élevés. Par exemple, avant de réaliser une analyse de facturation, nous n’avions pas encore anticipé que les coûts de bande passante réseau ALB pourraient représenter une part significative des dépenses globales. Pour optimiser les coûts et maximiser les optimisations de performance, il est essentiel de comprendre en profondeur les performances des différents types d’instances et services. Par exemple, chaque disque cloud GP3 offre 3000 IOPS ; regrouper plusieurs disques sur une seule machine et configurer RAID permet d’augmenter considérablement le débit des disques, évitant ainsi de lourdes factures pour des IOPS supplémentaires.
Reconnaître l’importance d’Open API : Avec l’adoption croissante des Agents, le rôle d’Open API et de la documentation associée devient de plus en plus important. Les services cloud traditionnels s’appuient sur des consoles web et des interfaces graphiques pour fournir leurs fonctionnalités, mais l’interaction et l’intégration futures des services cloud dépendront de plus en plus d’OpenAPI. Le niveau d’automatisation des services, la compatibilité avec les Agents et l’observabilité sont devenus des critères d’évaluation essentiels pour les futurs services cloud.
Épilogue
En repensant aux 18 derniers mois, nous nous sommes lancés dans un parcours exceptionnellement passionnant et exigeant, où le temps semblait passer trois fois plus vite. Ces progrès rapides peuvent être attribués à plusieurs facteurs clés : premièrement, l’avènement des LLMs a considérablement amélioré notre efficacité de codage. Deuxièmement, la reconnaissance rapide et unanime par les utilisateurs de la valeur des cas d’usage RAG est devenue le principal cas d’usage de la recherche vectorielle pour acquérir de nouveaux utilisateurs. Enfin, nous devons remercier tous les fournisseurs open-source, SaaS et de services cloud dont nous dépendons ; leurs services exceptionnels ont contribué à accélérer ce parcours.
Nous devons une gratitude particulière aux utilisateurs fidèles de Zilliz Cloud et de Milvus. Vos retours méticuleux et patients nous ont fourni des conseils et des orientations inestimables. Que ce soit dans les domaines du SaaS ou du Serverless, nous croyons fermement que tout ce que nous avons accompli n’est que le début. La quête du rapport coût-efficacité, de la performance, de la scalabilité et de la convivialité ne connaît aucune limite.
Remerciements
Je tiens à adresser un sincère merci à nos utilisateurs dévoués, dont le soutien a été déterminant dans le développement de Zilliz Cloud. Vos encouragements ont été essentiels pour partager notre parcours de construction de Zilliz Cloud, en offrant des enseignements susceptibles de bénéficier à d’autres personnes souhaitant développer leur service cloud. Une reconnaissance particulière va aux plus de 300 contributeurs de la communauté Milvus pour leur travail acharné, ainsi qu’à notre CEO, Charles, pour son soutien indéfectible à nos initiatives techniques innovantes.
Si vous souhaitez découvrir les services de recherche vectorielle, nous vous invitons à vous inscrire à Zilliz Cloud. Les nouveaux inscrits recevront $100 de crédits gratuits pour commencer.
Continuer à lire
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.