Comment déployer la base de données vectorielle Open-Source Milvus sur Amazon EKS

Ce billet a été publié à l'origine sur le site web d'AWS et est traduit, édité et rediffusé ici avec l'autorisation de l'auteur.

Vue d'ensemble des embarquements vectoriels et des bases de données vectorielles

L'essor de l'IA générative (GenAI), en particulier des grands modèles de langage(LLM), a considérablement stimulé l'intérêt pour les bases de données vectorielles, les établissant comme un composant essentiel au sein de l'écosystème GenAI. En conséquence, les bases de données vectorielles sont de plus en plus utilisées.

Un rapport IDC prévoit que d'ici 2025, plus de 80 % des données commerciales seront non structurées et existeront dans des formats tels que le texte, les images, le son et les vidéos. La compréhension, le traitement, le stockage et l'interrogation de cette vaste quantité de données non structurées à grande échelle représentent un défi de taille. La pratique courante en GenAI et en apprentissage profond consiste à transformer les données non structurées en encastrements vectoriels, à les stocker et à les indexer dans une base de données vectorielle comme Milvus ou Zilliz Cloud (Milvus entièrement géré) pour les recherches de similarité vectorielle ou de similarité sémantique.

Mais que sont exactement les embeddings vectoriels? En termes simples, il s'agit de représentations numériques de nombres à virgule flottante dans un espace à haute dimension. La distance entre deux vecteurs indique leur pertinence : plus ils sont proches, plus ils sont pertinents l'un par rapport à l'autre, et vice versa. Cela signifie que des vecteurs similaires correspondent à des données originales similaires, ce qui diffère des recherches traditionnelles par mots clés ou exactes.

Comment effectuer une recherche de similarité vectorielle

Figure 1 : Comment effectuer une recherche de similarité vectorielle ?

La capacité de stocker, d'indexer et de rechercher des vecteurs intégrés est la fonctionnalité principale des bases de données vectorielles. Actuellement, les bases de données vectorielles courantes se répartissent en deux catégories. La première catégorie étend les produits de bases de données relationnelles existants, comme Amazon OpenSearch Service avec le plugin KNN et Amazon RDS pour PostgreSQL avec l'extension pgvector. La deuxième catégorie comprend des produits de bases de données vectorielles spécialisées, y compris des exemples bien connus comme Milvus, Zilliz Cloud (Milvus entièrement géré), Pinecone, Weaviate, Qdrant et Chroma.

Les techniques d'intégration et les bases de données vectorielles ont de vastes applications dans divers cas d'utilisation axés sur l'IA, notamment la recherche de similitudes d'images, la déduplication et l'analyse de vidéos, le traitement du langage naturel, les systèmes de recommandation, la publicité ciblée, la recherche personnalisée, le service client intelligent et la détection des fraudes.

Milvus est l'une des options open-source les plus populaires parmi les nombreuses bases de données vectorielles. Ce billet présente Milvus et explore la pratique du déploiement de Milvus sur AWS EKS.

Qu'est-ce que Milvus ?

Milvus est une base de données vectorielles open-source extrêmement flexible, fiable et rapide. Elle alimente la recherche de similarités vectorielles et les applications d'IA et s'efforce de rendre les bases de données vectorielles accessibles à toutes les organisations. Milvus peut stocker, indexer et gérer plus d'un milliard d'encastrements vectoriels générés par des réseaux neuronaux profonds et d'autres modèles d'apprentissage automatique.

Milvus a été publié sous la licence open-source Apache License 2.0 en octobre 2019. Il s'agit actuellement d'un projet diplômé de la LF AI & Data Foundation. Au moment de la rédaction de ce blog, Milvus avait atteint plus de 50 millions de téléchargements Docker pull et était utilisé par de nombreux clients, tels que NVIDIA, AT&T, IBM, eBay, Shopee et Walmart.

Principales caractéristiques de Milvus

En tant que base de données vectorielles native dans le nuage, Milvus présente les caractéristiques clés suivantes :

• Haute performance et recherche à la milliseconde sur des ensembles de données vectorielles à l'échelle du milliard.

• Prise en charge et chaîne d'outils multilingues.

• Évolutivité horizontale et grande fiabilité, même en cas d'interruption.

• Recherche hybride, obtenue en associant le filtrage scalaire à la recherche de similarité vectorielle.

Architecture de Milvus

Milvus suit le principe de la séparation du flux de données et du flux de contrôle. Le système se décompose en quatre niveaux, comme le montre le diagramme :

Architecture Milvus

Figure 2 Architecture Milvus

• Couche d'accès : La couche d'accès est composée d'un groupe de mandataires sans état et sert de couche frontale du système et de point final pour les utilisateurs.

• Service de coordination : Le service de coordination attribue des tâches aux nœuds de travail.

• Nœuds de travail : Les nœuds de travail sont des exécutants idiots qui suivent les instructions du service de coordination et exécutent les commandes DML/DDL déclenchées par l'utilisateur.

• Stockage : Le stockage est responsable de la persistance des données. Il comprend un méta stockage, un courtier de journaux et un stockage d'objets.

Options de déploiement de Milvus

Milvus prend en charge trois modes d'exécution : Milvus Lite, Standalone et Distributed.

• Milvus Lite est une bibliothèque Python qui peut être importée dans des applications locales. En tant que version légère de Milvus, elle est idéale pour le prototypage rapide dans les blocs-notes Jupyter ou l'exécution sur des appareils intelligents avec des ressources limitées.

• Milvus Standalone estun déploiement de serveur sur une seule machine. Si vous avez une charge de travail de production mais préférez ne pas utiliser Kubernetes, l'exécution de Milvus Standalone sur une seule machine avec suffisamment de mémoire est une bonne option.

• Milvus Distributed peut être déployé sur des clusters Kubernetes. Il prend en charge des ensembles de données plus importants, une plus grande disponibilité et une meilleure évolutivité, et convient mieux aux environnements de production.

Milvus est conçu dès le départ pour prendre en charge Kubernetes et peut être facilement déployé sur AWS. Nous pouvons utiliser Amazon Elastic Kubernetes Service (Amazon EKS) comme Kubernetes géré, Amazon S3 comme stockage d'objets, Amazon Managed Streaming for Apache Kafka (Amazon MSK) comme stockage de messages et Amazon Elastic Load Balancing (Amazon ELB) comme équilibreur de charge pour construire un cluster de base de données Milvus fiable et élastique.

Ensuite, nous fournirons des conseils étape par étape sur le déploiement d'un cluster Milvus à l'aide d'EKS et d'autres services.

Déploiement de Milvus sur AWS EKS

Conditions préalables

Nous utiliserons AWS CLI pour créer un cluster EKS et déployer une base de données Milvus. Les conditions suivantes sont requises :

• Un PC/Mac ou une instance Amazon EC2 avec AWS CLI installé et configuré avec les autorisations appropriées. Les outils AWS CLI sont installés par défaut si vous utilisez Amazon Linux 2 ou Amazon Linux 2023.

• Lesoutils EKS sont installés, y compris Helm, Kubectl, eksctl, etc.

• Un panier Amazon S3.

• Une instance Amazon MSK.

Éléments à prendre en compte lors de la création de MSK

• La dernière version stable de Milvus (v2.3.13) dépend de la fonctionnalité autoCreateTopics de Kafka. Ainsi, lors de la création de MSK, nous devons utiliser une configuration personnalisée et modifier la propriété auto.create.topics.enable de la valeur par défaut false à true. En outre, pour augmenter le débit de messages de MSK, il est recommandé d'augmenter les valeurs de message.max.bytes et replica.fetch.max.bytes. Voir Configurations MSK personnalisées pour plus de détails.

auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760

• Milvus ne prend pas en charge l'authentification IAM basée sur les rôles de MSK. Ainsi, lors de la création de MSK, activer l'option SASL/SCRAM authentication dans la configuration de sécurité et configurer username et password dans AWS Secrets Manager. Voir l'authentification des identifiants de connexion avec AWS Secrets Manager pour plus de détails.

Figure 3 : Paramètres de sécurité : activer l'authentification SASL SCRAM.png

Figure 3 : Paramètres de sécurité : activer l'authentification SASL/SCRAM

• Nous devons activer l'accès au groupe de sécurité MSK à partir du groupe de sécurité ou de la plage d'adresses IP du cluster EKS.

Création d'un cluster EKS

Il existe de nombreuses façons de créer un cluster EKS, notamment via la console, CloudFormation, eksctl, etc. Ce billet montrera comment créer un cluster EKS à l'aide d'eksctl.

eksctl eksctl est un outil de ligne de commande simple pour créer et gérer des clusters Kubernetes sur Amazon EKS. Il fournit le moyen le plus rapide et le plus facile de créer un nouveau cluster avec des nœuds pour Amazon EKS. Voir le site web d'eksctl pour plus d'informations.

1. Tout d'abord, créez un fichier eks_cluster.yaml avec l'extrait de code suivant. Remplacez cluster-name par le nom de votre cluster, region-code par la région AWS où vous souhaitez créer le cluster et private-subnet-idx par vos sous-réseaux privés. Remarque : ce fichier de configuration crée un cluster EKS dans un VPC existant en spécifiant des sous-réseaux privés. Si vous souhaitez créer un nouveau VPC, supprimez la configuration du VPC et des sous-réseaux, et le site eksctl en créera automatiquement un nouveau.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
 name: <cluster-name>
 region: <region-code>
 version: "1.26"

iam:
 withOIDC: true

 serviceAccounts:
 - metadata:
     name: aws-load-balancer-controller
     namespace: kube-system
   wellKnownPolicies:
     awsLoadBalancerController: true
 - metadata:
     name: milvus-s3-access-sa
     # if no namespace is set, "default" will be used;
     # the namespace will be created if it doesn't exist already
     namespace: milvus
     labels: {aws-usage: "milvus"}
   attachPolicyARNs:
   - "arn:aws:iam::aws:policy/AmazonS3FullAccess"

# Use existed VPC to create EKS.
# If you don't config vpc subnets, eksctl will automatically create a brand new VPC
vpc:
 subnets:
   private:
     us-west-2a: { id: <private-subnet-id1> }
     us-west-2b: { id: <private-subnet-id2> }
     us-west-2c: { id: <private-subnet-id3> }

managedNodeGroups:
 - name: ng-1-milvus
   labels: { role: milvus }
   instanceType: m6i.2xlarge
   desiredCapacity: 3
   privateNetworking: true
  
addons:
- name: vpc-cni # no version is specified so it deploys the default version
 attachPolicyARNs:
   - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
- name: coredns
 version: latest # auto discovers the latest available
- name: kube-proxy
 version: latest
- name: aws-ebs-csi-driver
 wellKnownPolicies:      # add IAM and service account
   ebsCSIController: true

2. Ensuite, exécutez la commande eksctl pour créer le cluster EKS.

eksctl create cluster -f eks_cluster.yaml

Cette commande créera les ressources suivantes :

• Un cluster EKS avec la version spécifiée.

• Un groupe de nœuds gérés avec trois instances EC2 m6i.2xlarge.

• Un fournisseur d'identité IAM OIDC et un ServiceAccount appelé aws-load-balancer-controller, que nous utiliserons plus tard lors de l'installation du contrôleur AWS Load Balancer.

• Un espace de noms milvus et un ServiceAccount milvus-s3-access-sa dans cet espace de noms. Cet espace de noms sera utilisé ultérieurement lors de la configuration de S3 en tant que stockage d'objets pour Milvus.

  Remarque : pour des raisons de simplicité, le site milvus-s3-access-sa bénéficie ici de toutes les autorisations d'accès à S3. Dans les déploiements en production, il est recommandé de suivre le principe du moindre privilège et de n'accorder l'accès qu'au seau S3 spécifique utilisé pour Milvus.

• Multiple add-ons, où vpc-cni, coredns, kube-proxy sont des add-ons de base requis par EKS. aws-ebs-csi-driver est le pilote AWS EBS CSI qui permet aux clusters EKS de gérer le cycle de vie des volumes Amazon EBS.

Il ne nous reste plus qu'à attendre la fin de la création du cluster.

Attendez la fin de la création du cluster. Au cours du processus de création du cluster, le fichier kubeconfig sera automatiquement créé ou mis à jour. Vous pouvez également le mettre à jour manuellement en exécutant la commande suivante. Veillez à remplacer region-code par la région AWS dans laquelle votre cluster est créé et cluster-name par le nom de votre cluster.

aws eks update-kubeconfig --region <region-code> --name <cluster-name>

Une fois le cluster créé, vous pouvez afficher les nœuds en exécutant la commande suivante :

kubectl get nodes -A -o wide

3. Créez une StorageClass ebs-sc configurée avec GP3 comme type de stockage et définissez-la comme StorageClass par défaut. Milvus utilise etcd comme méta stockage et a besoin de cette StorageClass pour créer et gérer les PVC.

cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ebs-sc
 annotations:
   storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
 type: gp3
EOF

Ensuite, définissez la StorageClass d'origine gp2 comme n'étant pas une classe par défaut :

kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

4. Installer le contrôleur AWS Load Balancer. Nous utiliserons ce contrôleur plus tard pour le service Milvus et Attu Ingress, donc installons-le au préalable.

• Tout d'abord, ajoutez le repo eks-charts et mettez-le à jour.

helm repo add eks https://aws.github.io/eks-charts
helm repo update

• Ensuite, installez le contrôleur AWS Load Balancer. Remplacez cluster-name par le nom de votre cluster. Le ServiceAccount nommé aws-load-balancer-controller a déjà été créé lorsque nous avons créé le cluster EKS dans les étapes précédentes.

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
 -n kube-system \
 --set clusterName=<cluster-name> \
 --set serviceAccount.create=false \
 --set serviceAccount.name=aws-load-balancer-controller

• Vérifiez que le contrôleur a été installé avec succès.

kubectl get deployment -n kube-system aws-load-balancer-controller

• La sortie doit ressembler à ceci :

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   2/2     2            2           12m

Déploiement d'un cluster Milvus

Milvus prend en charge plusieurs méthodes de déploiement, telles que Operator et Helm. Operator est plus simple, mais Helm est plus direct et plus flexible. Dans cet exemple, nous utiliserons Helm pour déployer Milvus.

Lors du déploiement de Milvus avec Helm, vous pouvez personnaliser la configuration via le fichier values.yaml. Cliquez sur values.yaml pour afficher toutes les options. Par défaut, Milvus crée dans le cluster minio et pulsar en tant que stockage d'objets et stockage de messages, respectivement. Nous allons apporter quelques modifications à la configuration pour la rendre plus adaptée à la production.

1. Tout d'abord, ajoutez le repo Milvus Helm et mettez-le à jour.

helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update

2. Créez un fichier milvus_cluster.yaml avec l'extrait de code suivant. Cet extrait de code personnalise la configuration de Milvus, par exemple en configurant Amazon S3 comme stockage d'objets et Amazon MSK comme file d'attente de messages. Nous fournirons des explications détaillées et des conseils de configuration ultérieurement.

#####################################
# Section 1
#
# Configure S3 as the Object Storage
#####################################

# Service account
# - this service account are used by External S3 access
serviceAccount:
  create: false
  name: milvus-s3-access-sa

# Close in-cluster minio
minio:
  enabled: false

# External S3
# - these configs are only used when `externalS3.enabled` is true
externalS3:
  enabled: true
  host: "s3.<region-code>.amazonaws.com"
  port: "443"
  useSSL: true
  bucketName: "<bucket-name>"
  rootPath: "<root-path>"
  useIAM: true
  cloudProvider: "aws"
  iamEndpoint: ""

#####################################
# Section 2
#
# Configure MSK as the Message Storage
#####################################

# Close in-cluster pulsar
pulsar:
  enabled: false

# External kafka
# - these configs are only used when `externalKafka.enabled` is true
externalKafka:
  enabled: true
  brokerList: "<broker-list>"
  securityProtocol: SASL_SSL
  sasl:
    mechanisms: SCRAM-SHA-512
    username: "<username>"
    password: "<password>"
    
#####################################
# Section 3
#
# Expose the Milvus service to be accessed from outside the cluster (LoadBalancer service).
# or access it from within the cluster (ClusterIP service). Set the service type and the port to serve it.
#####################################
service:
  type: LoadBalancer
  port: 19530
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external #AWS Load Balancer Controller fulfills services that has this annotation
    service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #User defined name given to AWS Network Load Balancer
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal # internal or internet-facing, later allowing for public access via internet
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #The Pod IPs should be used as the target IPs (rather than the node IPs)
    
#####################################
# Section 4
#
# Installing Attu the Milvus management GUI
#####################################
attu:
  enabled: true
  name: attu
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: alb # Annotation: set ALB ingress type
      alb.ingress.kubernetes.io/scheme: internet-facing #Places the load balancer on public subnets
      alb.ingress.kubernetes.io/target-type: ip #The Pod IPs should be used as the target IPs (rather than the node IPs)
      alb.ingress.kubernetes.io/group.name: attu # Groups multiple Ingress resources
    hosts:
      -
      
#####################################
# Section 5
#
# HA deployment of Milvus Core Components
#####################################
rootCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Enable active-standby when you set multiple replicas for root coordinator
  resources:
    limits:
      cpu: 1
      memory: 2Gi
indexCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Enable active-standby when you set multiple replicas for index coordinator
  resources:
    limits:
      cpu: "0.5"
      memory: 0.5Gi
queryCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Enable active-standby when you set multiple replicas for query coordinator
  resources:
    limits:
      cpu: "0.5"
      memory: 0.5Gi
dataCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Enable active-standby when you set multiple replicas for data coordinator
  resources:
    limits:
      cpu: "0.5"
      memory: 0.5Gi
proxy:
  replicas: 2
  resources:
    limits:
      cpu: 1
      memory: 4Gi

#####################################
# Section 6
#
# Milvus Resource Allocation
#####################################
queryNode:
  replicas: 1
  resources:
    limits:
      cpu: 2
      memory: 8Gi
dataNode:
  replicas: 1
  resources:
    limits:
      cpu: 1
      memory: 4Gi
indexNode:
  replicas: 1
  resources:
    limits:
      cpu: 4
      memory: 8Gi

Le code contient six sections. Suivez les instructions suivantes pour modifier les configurations correspondantes.

Section 1: Configurer S3 comme stockage d'objets. Le serviceAccount accorde à Milvus l'accès à S3 (dans ce cas, il s'agit de milvus-s3-access-sa, qui a été créé lorsque nous avons créé le cluster EKS). Veillez à remplacer <region-code> par la région AWS où se trouve votre cluster. Remplacez <bucket-name> par le nom de votre seau S3 et <root-path> par le préfixe du seau S3 (ce champ peut être laissé vide).

Section 2: Configurer MSK comme stockage de messages. Remplacez <broker-list> par les adresses des points d'extrémité correspondant au type d'authentification SASL/SCRAM de MSK. Remplacez <username> et <password> par le nom d'utilisateur et le mot de passe du compte MSK. Vous pouvez obtenir l'adresse <broker-list> à partir des informations du client MSK, comme le montre l'image ci-dessous.

Figure 4 : Configurer MSK en tant que stockage de messages de Milvus.png

Figure 4 : Configurer MSK en tant que stockage de messages de Milvus

Section 3 : Exposer le service Milvus et permettre l'accès depuis l'extérieur du cluster. Le point d'extrémité Milvus utilise par défaut un service de type ClusterIP, qui n'est accessible qu'à l'intérieur du cluster EKS. Si nécessaire, vous pouvez le changer pour un service de type LoadBalancer afin de permettre l'accès depuis l'extérieur du cluster EKS. Le service de type LoadBalancer utilise Amazon NLB comme équilibreur de charge. Conformément aux meilleures pratiques en matière de sécurité, aws-load-balancer-scheme est configuré par défaut en mode interne, ce qui signifie que seul l'accès intranet à Milvus est autorisé. Cliquez pour voir les instructions de configuration NLB.

Section 4 : Installer et configurer Attu, un outil d'administration milvus open-source. Il dispose d'une interface graphique intuitive qui vous permet d'interagir facilement avec Milvus. Nous activons Attu, configurons l'entrée à l'aide d'AWS ALB et la définissons sur le type internet-facing afin qu'Attu soit accessible via Internet. Cliquez sur ce document pour obtenir le guide de la configuration ALB.

Section 5 : activer le déploiement HA des composants principaux de Milvus. Milvus contient plusieurs composants indépendants et découplés. Par exemple, le service de coordination agit en tant que couche de contrôle, gérant la coordination des composants Racine, Requête, Données et Index. Le proxy de la couche d'accès sert de point d'accès à la base de données. Par défaut, ces composants ne comportent qu'une seule réplique de pod. Le déploiement de plusieurs répliques de ces composants de service est particulièrement nécessaire pour améliorer la disponibilité de Milvus.

Remarque : le déploiement multiréplique des composants Root, Query, Data et Index coordinator nécessite l'activation de l'option activeStandby.

Section 6 : Ajustez l'allocation des ressources pour les composants Milvus afin de répondre aux exigences de vos charges de travail. Le site Web de Milvus propose également un outil de dimensionnement qui génère des suggestions de configuration en fonction du volume de données, des dimensions des vecteurs, des types d'index, etc. Il peut également générer un fichier de configuration Helm en un seul clic. La configuration suivante est la suggestion donnée par l'outil pour 1 million de vecteurs de 1024 dimensions et un type d'index HNSW.

1. Utilisez Helm pour créer Milvus (déployé dans l'espace de noms milvus). Remarque : vous pouvez remplacer <demo> par un nom personnalisé.

helm install <demo> milvus/milvus -n milvus -f milvus_cluster.yaml

2. Exécutez la commande suivante pour vérifier l'état du déploiement.

kubectl get deployment -n milvus

La sortie suivante montre que les composants Milvus sont tous DISPONIBLES et que les composants de coordination ont plusieurs répliques activées.

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
demo-milvus-attu         1/1     1            1           5m27s
demo-milvus-datacoord    2/2     2            2           5m27s
demo-milvus-datanode     1/1     1            1           5m27s
demo-milvus-indexcoord   2/2     2            2           5m27s
demo-milvus-indexnode    1/1     1            1           5m27s
demo-milvus-proxy        2/2     2            2           5m27s
demo-milvus-querycoord   2/2     2            2           5m27s
demo-milvus-querynode    1/1     1            1           5m27s
demo-milvus-rootcoord    2/2     2            2           5m27s

Accès et gestion de Milvus

Jusqu'à présent, nous avons déployé avec succès la base de données vectorielle Milvus. Nous pouvons maintenant accéder à Milvus par le biais de points d'extrémité. Milvus expose des points finaux via les services Kubernetes. Attu expose les points d'extrémité via Kubernetes Ingress.

Accès aux points d'extrémité de Milvus

Exécutez la commande suivante pour obtenir les points de terminaison des services :

kubectl get svc -n milvus

Vous pouvez voir plusieurs services. Milvus prend en charge deux ports, le port 19530 et le port 9091:

• Le port 19530 est destiné à gRPC et à l'API RESTful. C'est le port par défaut lorsque vous vous connectez à un serveur Milvus avec différents SDK Milvus ou clients HTTP.
• Le port 9091 est un port de gestion pour la collecte de métriques, le profilage pprof et les sondes de santé dans Kubernetes.

Le service demo-milvus fournit un point d'accès à la base de données, qui est utilisé pour établir une connexion à partir des clients. Il utilise NLB comme équilibreur de charge. Vous pouvez obtenir le point d'extrémité du service à partir de la colonne EXTERNAL-IP.

NAME                     TYPE           CLUSTER-IP       EXTERNAL-IP                                               PORT(S)                          AGE
demo-etcd                ClusterIP      172.20.103.138   <none>                                                    2379/TCP,2380/TCP                62m
demo-etcd-headless       ClusterIP      None             <none>                                                    2379/TCP,2380/TCP                62m
demo-milvus              LoadBalancer   172.20.219.33    milvus-nlb-xxxx.elb.us-west-2.amazonaws.com               19530:31201/TCP,9091:31088/TCP   62m
demo-milvus-datacoord    ClusterIP      172.20.214.106   <none>                                                    13333/TCP,9091/TCP               62m
demo-milvus-datanode     ClusterIP      None             <none>                                                    9091/TCP                         62m
demo-milvus-indexcoord   ClusterIP      172.20.106.51    <none>                                                    31000/TCP,9091/TCP               62m
demo-milvus-indexnode    ClusterIP      None             <none>                                                    9091/TCP                         62m
demo-milvus-querycoord   ClusterIP      172.20.136.213   <none>                                                    19531/TCP,9091/TCP               62m
demo-milvus-querynode    ClusterIP      None             <none>                                                    9091/TCP                         62m
demo-milvus-rootcoord    ClusterIP      172.20.173.98    <none>                                                    53100/TCP,9091/TCP               62m

Gestion de Milvus à l'aide d'Attu

Comme décrit précédemment, nous avons installé Attu pour gérer Milvus. Exécutez la commande suivante pour obtenir le point final :

kubectl get ingress -n milvus

Vous pouvez voir un Ingress appelé demo-milvus-attu, où la colonne ADDRESS est l'URL d'accès.

NAME            CLASS   HOSTS   ADDRESS                                     PORTS   AGE
demo-milvus-attu   <none>   *       k8s-attu-xxxx.us-west-2.elb.amazonaws.com   80      27s

Ouvrez l'adresse Ingress dans un navigateur et voyez la page suivante. Cliquez sur Connecter pour vous connecter.

Figure 5 : Connectez-vous à votre compte Attu.png

Figure 5 : Connexion à votre compte Attu

Après vous être connecté, vous pouvez gérer les bases de données Milvus via Attu.

Figure 6 L'interface Attu.png

Figure 6 : L'interface Attu

Test de la base de données vectorielle Milvus

Nous allons utiliser le code d'exemple Milvus pour tester le bon fonctionnement de la base de données Milvus. Tout d'abord, téléchargez le code d'exemple hello_milvus.py à l'aide de la commande suivante :

wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py

Modifiez l'hôte dans le code d'exemple en point d'extrémité du service Milvus.

print(fmt.format("start connecting to Milvus"))
connections.connect("default", host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", port="19530")

Exécutez le code :

python3 hello_milvus.py

Si le système renvoie le résultat suivant, cela signifie que Milvus fonctionne normalement.

=== start connecting to Milvus     ===
Does collection hello_milvus exist in Milvus: False
=== Create collection `hello_milvus` ===
=== Start inserting entities       ===
Number of entities in Milvus: 3000
=== Start Creating index IVF_FLAT  ===
=== Start loading                  ===

Conclusion

Cet article présente Milvus, l'une des bases de données vectorielles open-source les plus populaires, et fournit un guide sur le déploiement de Milvus sur AWS à l'aide de services gérés tels qu'Amazon EKS, S3, MSK et ELB pour obtenir une plus grande élasticité et une plus grande fiabilité.

En tant que composant central de divers systèmes GenAI, en particulier Retrieval Augmented Generation (RAG), Milvus prend en charge et s'intègre à une variété de modèles et de cadres GenAI courants, notamment Amazon Sagemaker, PyTorch, HuggingFace, LlamaIndex et LangChain. Commencez votre voyage d'innovation GenAI avec Milvus dès aujourd'hui !

Références

• Guide de l'utilisateur d'Amazon EKS
• Site Web officiel de Milvus
• Dépôt GitHub de Milvus
• Site Web officiel d'eksctl