オープンソースのMilvusベクターデータベースをAmazon EKSにデプロイする方法
この投稿は元々AWSのウェブサイトに掲載されたもので、許可を得て翻訳・編集し、ここに再掲載している。
ベクトル埋め込みとベクトルデータベースの概要
ジェネレーティブAI(GenAI)、特に大規模言語モデル(LLM)の台頭は、ベクターデータベースへの関心を著しく高め、GenAIのエコシステムにおいて不可欠なコンポーネントとして確立しました。その結果、ベクターデータベースはますます多くのユースケースで採用されるようになっている。
IDCのレポートでは、2025年までにビジネスデータの80%以上が非構造化データになり、テキスト、画像、音声、動画などの形式で存在すると予測しています。この膨大な非構造化データを大規模に理解し、処理し、保存し、照会することは、重要な課題である。GenAIやディープラーニングにおける一般的な手法は、非構造化データをベクトル埋め込みに変換し、Milvusや Zilliz Cloud(フルマネージドMilvus)のようなベクトルデータベースに保存、インデックス化し、ベクトルの類似性や意味的類似性を検索することだ。
しかし、ベクトル埋め込みとは一体何なのだろうか?簡単に言えば、高次元空間における浮動小数点数の数値表現である。2つのベクトル間の距離はその関連性を示し、近ければ近いほど関連性が高く、逆もまた然りです。これは、類似したベクトルは類似した元のデータに対応することを意味し、従来のキーワード検索や完全一致検索とは異なります。
ベクトル類似検索の実行方法
図1:ベクトル類似検索の実行方法
ベクトル埋め込みデータを格納し、インデックスを付け、検索する機能は、ベクトルデータベースの中核をなす機能です。現在、主流のベクトルデータベースは2つのカテゴリに分類されます。最初のカテゴリーは、Amazon OpenSearch ServiceのKNNプラグインやAmazon RDS forPostgreSQLのpgvector拡張など、既存のリレーショナルデータベース製品を拡張したものです。2つ目のカテゴリーは、Milvus、Zilliz Cloud(フルマネージドMilvus)、Pinecone、Weaviate、Qdrant、Chromaのような有名な例を含む、特化したベクトルデータベース製品で構成される。
埋め込み技術とベクトルデータベースは、画像類似検索、ビデオ重複排除と分析、自然言語処理、推薦システム、ターゲット広告、パーソナライズされた検索、インテリジェントな顧客サービス、詐欺検出など、様々なAI主導のユースケースに幅広く応用されています。
Milvusは、数あるベクトルデータベースの中でも最も人気のあるオープンソースの選択肢の1つである。この投稿ではMilvusを紹介し、AWS EKS上でのMilvusのデプロイの実践を探る。
Milvusとは?
Milvusは柔軟性、信頼性が高く、高速なクラウドネイティブのオープンソースベクターデータベースです。ベクトル類似検索とAIアプリケーションを強力にサポートし、あらゆる組織がベクトルデータベースにアクセスできるように努めています。Milvusは、ディープニューラルネットワークやその他の機械学習(ML)モデルによって生成された10億以上のベクトル埋め込みを保存、インデックス付け、管理することができます。
Milvusは2019年10月にオープンソースのApache License 2.0の下でリリースされた。現在、LF AI & Data Foundationの卒業プロジェクトとなっている。このブログを書いている時点で、Milvusは5000万以上のDocker Pullダウンロードに達しており、NVIDIA、AT&T、IBM、eBay、Shopee、Walmartなど多くの顧客に利用されている。
Milvusの主な特徴
クラウドネイティブなベクターデータベースとして、Milvusは以下の主な特徴を誇っている:
億スケールのベクトルデータセットをミリ秒単位で検索する高いパフォーマンス。
多言語サポートとツールチェーン
水平スケーラビリティと障害発生時の高い信頼性
スカラーフィルタリングとベクトル類似検索を組み合わせたハイブリッド検索。
Milvusのアーキテクチャ
Milvusは、データフローと制御フローを分離するという原則に従っている。システムは図のように4つのレベルに分かれている:
Milvusアーキテクチャ
図2 Milvusアーキテクチャ
アクセス層:アクセスレイヤーはステートレスプロキシ群で構成され、システムのフロントレイヤーとして、またユーザーに対するエンドポイントとして機能する。
コーディネータサービス:コーディネータサービスは、ワーカーノードにタスクを割り当てる。
ワーカーノード:ワーカーノードは、コーディネータサービスからの指示に従い、ユーザートリガーのDML/DDLコマンドを実行するダムエグゼキュータです。
ストレージ:ストレージはデータの永続化を担当する。メタストレージ、ログブローカー、オブジェクトストレージから構成される。
Milvusの展開オプション
Milvusは3つの実行モードをサポートしています:Milvus Lite、スタンドアロン、分散です。
Milvus Liteはローカルアプリケーションにインポート可能なPythonライブラリです。Milvusの軽量版として、Jupyter Notebookでの迅速なプロトタイピングや、リソースの限られたスマートデバイスでの実行に最適です。
Milvus Standaloneはシングルマシンサーバーデプロイメントです。実運用ワークロードがあるがKubernetesを使用したくない場合、十分なメモリを持つシングルマシン上でMilvus Standaloneを実行することは良い選択肢です。
Milvus DistributedはKubernetesクラスタ上にデプロイすることができる。より大きなデータセット、より高い可用性、スケーラビリティをサポートし、本番環境により適しています。
Milvusは最初からKubernetesをサポートするように設計されており、AWS上で簡単にデプロイできる。マネージドKubernetesとしてAmazon Elastic Kubernetes Service (Amazon EKS)を、オブジェクトストレージとしてAmazon S3を、メッセージストレージとしてAmazon Managed Streaming for Apache Kafka (Amazon MSK)を、ロードバランサーとしてAmazon Elastic Load Balancing (Amazon ELB)を使用することで、信頼性と弾力性のあるMilvusデータベースクラスタを構築することができます。
次に、EKSやその他のサービスを利用したMilvusクラスタのデプロイについて、ステップバイステップで説明します。
AWS EKS上でのMilvusのデプロイ
前提条件
AWS CLIを使用してEKSクラスタを作成し、Milvusデータベースをデプロイします。以下の前提条件が必要です:
AWS CLIがインストールされ、適切な権限で設定されたPC/MacまたはAmazon EC2インスタンス。Amazon Linux 2またはAmazon Linux 2023を使用している場合、AWS CLIツールはデフォルトでインストールされています。
Helm、Kubectl、eksctlなどのEKSツールがインストールされていること。
Amazon S3バケット。
Amazon MSKインスタンス。
MSKを作成する際の考慮事項
- Milvusの最新安定版(v2.3.13)はKafkaの
autoCreateTopics
機能に依存しています。そのため、MSKを作成する際には、カスタム設定を使用し、auto.create.topics.enable
プロパティをデフォルトのfalse
からtrue
に変更する必要があります。また、MSKのメッセージスループットを向上させるためには、message.max.bytes
とreplica.fetch.max.bytes
の値を大きくすることが推奨されます。詳細については、カスタムMSK設定を参照してください。
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
- milvusはMSKのIAMロールベース認証をサポートしていません。そのため、MSKを作成する際は、セキュリティ設定で
SASL/SCRAM authentication
オプションを有効にし、AWS Secrets Managerでusername
、password
。詳しくは、AWS Secrets Manager によるサインイン認証を参照。
図 3 セキュリティ設定 SASL SCRAM 認証を有効にする.png
図 3: セキュリティ設定: SASL/SCRAM 認証を有効にする
- EKSクラスタのセキュリティグループまたはIPアドレス範囲からMSKセキュリティグループへのアクセスを有効にする必要があります。
EKSクラスタの作成
コンソール、CloudFormation、eksctlなど、EKSクラスタを作成する方法はたくさんあります。この記事では、eksctlを使用してEKSクラスタを作成する方法を紹介します。
eksctl
は、Amazon EKS上でKubernetesクラスタを作成・管理するためのシンプルなコマンドラインツールです。Amazon EKS用のノードを持つ新しいクラスタを作成するための最速かつ最も簡単な方法を提供します。詳細はeksctlのウェブサイトを参照してください。
- まず、以下のコード・スニペットで
eks_cluster.yaml
ファイルを作成します。cluster-name
をクラスタ名に置き換え、region-code
をクラスタを作成する AWS リージョンに置き換え、private-subnet-idx
をプライベートサブネットに置き換えてください。 注:この設定ファイルは、プライベートサブネットを指定して既存の VPC に EKS クラスタを作成します。新しいVPCを作成する場合は、VPCとサブネットの構成を削除すると、eksctl
。
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
- 次に、
eksctl
コマンドを実行して EKS クラスターを作成します。
eksctl create cluster -f eks_cluster.yaml
このコマンドにより、以下のリソースが作成されます:
指定したバージョンのEKSクラスター。
3台のm6i.2xlarge EC2インスタンスを持つ管理ノードグループ。
IAM OIDC IDプロバイダーと、後でAWSロードバランサーコントローラーをインストールするときに使用する
aws-load-balancer-controller
というServiceAccount。名前空間
milvus
と、この名前空間内の ServiceAccountmilvus-s3-access-sa
。この名前空間は、後でMilvusのオブジェクトストレージとしてS3を設定する際に使用します。注意: ここでは簡単のため、
milvus-s3-access-sa
に S3 のフルアクセス権限を付与しています。本番環境では、最小特権の原則に従い、Milvusに使用する特定のS3バケットのみにアクセス権を付与することをお勧めします。vpc-cni
,coredns
,kube-proxy
はEKSに必要なコアアドオンです。aws-ebs-csi-driver
はEKSクラスタがAmazon EBSボリュームのライフサイクルを管理するためのAWS EBS CSIドライバです。
あとは、クラスタの作成が完了するのを待つだけです。
クラスタの作成が完了するまで待ちます。クラスタ作成プロセス中に、kubeconfig
ファイルが自動的に作成または更新されます。以下のコマンドを実行して手動で更新することもできます。region-code
」をクラスタが作成されるAWSリージョンに、「cluster-name
」をクラスタ名に置き換えてください。
aws eks update-kubeconfig --region <region-code> --name <cluster-name>
クラスタが作成されたら、以下のコマンドを実行してノードを表示できます:
kubectl get nodes -A -o wide
- ストレージタイプとしてGP3を設定した
ebs-sc
StorageClassを作成し、デフォルトのStorageClassとして設定します。Milvusはメタストレージとしてetcdを使用し、PVCの作成と管理にこのStorageClassが必要です。
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
その後、元のgp2
StorageClassをnon-defaultに設定する:
kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
- AWS Load Balancer Controllerをインストールする。このコントローラは後でMilvus ServiceとAttu Ingressで使うので、事前にインストールしておこう。
- まず、
eks-charts
のレポを追加し、アップデートする。
helm repo add eks https://aws.github.io/eks-charts
helm repo update
- 次に、AWS Load Balancer Controllerをインストールします。
cluster-name
はクラスタ名に置き換えてください。aws-load-balancer-controller
という名前の ServiceAccount は、前のステップで EKS クラスタを作成したときに既に作成されている。
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
- コントローラーが正常にインストールされたか確認する。
kubectl get deployment -n kube-system aws-load-balancer-controller
- 出力は以下のようになるはずです:
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 12m
Milvusクラスタのデプロイ
MilvusはOperatorやHelmなど複数のデプロイ方法をサポートしています。Operatorはよりシンプルですが、Helmはより直接的で柔軟です。この例ではHelmを使用してMilvusをデプロイします。
Helmを使ってMilvusをデプロイする場合、values.yaml
ファイルを使って設定をカスタマイズすることができます。values.yamlをクリックするとすべてのオプションが表示されます。デフォルトでは、Milvusはクラスタ内のminioとpulsarをそれぞれオブジェクトストレージとメッセージストレージとして作成します。これを本番環境に適したものにするため、いくつかの設定変更を行います。
- まず、Milvus Helmレポを追加し、更新します。
helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
- 以下のコード・スニペットで
milvus_cluster.yaml
。このコードスニペットは、オブジェクトストレージとしてAmazon S3、メッセージキューとしてAmazon MSKを設定するなど、Milvusの設定をカスタマイズします。詳細な説明とコンフィギュレーションガイダンスは後ほど提供します。
#####################################
# 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
このコードには6つのセクションがあります。以下の指示に従って、対応する設定を変更してください。
セクション1:オブジェクトストレージとしてS3を設定する。serviceAccountはMilvusにS3へのアクセスを許可します(この場合、milvus-s3-access-sa
、EKSクラスタ作成時に作成したものです)。<region-code>
はクラスタが配置されている AWS リージョンに置き換えてください。<bucket-name>
をS3バケットの名前に、<root-path>
をS3バケットのプレフィックスに置き換えてください(このフィールドは空のままでも構いません)。
セクション2:MSKをメッセージストレージとして構成する。<broker-list>
を、MSKのSASL/SCRAM認証タイプに対応するエンドポイントアドレスに置き換える。<username>
と<password>
を MSK アカウントのユーザー名とパスワードに置き換える。<broker-list>
は、下図のように MSK クライアント情報から取得できる。
図4 MilvusのメッセージストレージとしてMSKを設定する.png
図4: MSKをMilvusのメッセージストレージとして設定する。
セクション3:Milvusサービスを公開し、クラスタ外部からのアクセスを可能にする。MilvusエンドポイントはデフォルトでClusterIPタイプのサービスを使用しており、EKSクラスタ内でのみアクセス可能です。必要に応じて、LoadBalancerタイプに変更してEKSクラスタ外部からのアクセスを許可することができます。ロードバランサータイプのサービスは、ロードバランサとしてAmazon NLBを使用します。セキュリティのベストプラクティスに従い、aws-load-balancer-scheme
はデフォルトで内部モードとして設定されており、Milvusへのイントラネットアクセスのみが許可されます。NLBの設定手順を見るにはクリックしてください。
セクション4:オープンソースのmilvus管理ツールであるAttuをインストールし、設定します。直感的なGUIでmilvusと簡単に対話することができます。Attuを有効にし、AWS ALBを使用してイングレスを構成し、Attuがインターネット経由でアクセスできるようにinternet-facing
タイプに設定します。ALB設定のガイドはこちらのドキュメントをクリックしてください。
セクション5:Milvus Core ComponentsのHAデプロイを有効にする。Milvusには複数の独立したコンポーネントが含まれています。例えば、コーディネータサービスは制御層として機能し、ルート、クエリ、データ、インデックスの各コンポーネントの調整を行います。アクセス層のProxyはデータベースアクセスのエンドポイントとして機能します。これらのコンポーネントのデフォルトは1つのポッド・レプリカのみです。Milvusの可用性を向上させるためには、これらのサービスコンポーネントの複数のレプリカをデプロイすることが特に必要です。
注意:Root、Query、Data、およびIndexコーディネータコンポーネントのマルチレプリカデプロイメントには、activeStandby
オプションを有効にする必要があります。
セクション6:Milvusコンポーネントのリソース割り当てを調整し、ワークロードの要件を満たす。Milvusのウェブサイトでは、データ量、ベクトルサイズ、インデックスタイプなどに基づいて構成案を生成するサイジングツールも提供しています。また、ワンクリックでHelm設定ファイルを生成することもできます。以下の構成は、100万個の1024次元ベクトルとHNSWインデックスタイプに対するツールによる提案です。
- Helmを使用してMilvus(名前空間
milvus
に配置)を作成します。注:<demo>
はカスタム名で置き換えることができます。
helm install <demo> milvus/milvus -n milvus -f milvus_cluster.yaml
- 以下のコマンドを実行し、デプロイ状況を確認します。
kubectl get deployment -n milvus
以下の出力は、MilvusコンポーネントがすべてAVAILABLEであり、コーディネーションコンポーネントで複数のレプリカが有効になっていることを示しています。
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
Milvusへのアクセスと管理
ここまでで、Milvusベクトルデータベースのデプロイは成功しました。次に、エンドポイントを通してMilvusにアクセスする。MilvusはKubernetesサービス経由でエンドポイントを公開している。AttuはKubernetes Ingress経由でエンドポイントを公開する。
Milvusエンドポイントへのアクセス
以下のコマンドを実行して、サービスのエンドポイントを取得します:
kubectl get svc -n milvus
いくつかのサービスを見ることができる。Milvusは2つのポート、ポート19530
とポート9091
をサポートしています:
- ポート
19530
は gRPC および RESTful API 用です。異なるMilvus SDKやHTTPクライアントでMilvusサーバに接続する場合のデフォルトポートです。 - ポート
9091
はKubernetes内のメトリクス収集、pprofプロファイリング、ヘルスプローブ用の管理ポートです。
demo-milvus
サービスはデータベースアクセスエンドポイントを提供し、クライアントからの接続を確立するために使用される。サービスのロードバランサーとしてNLBを使用します。サービスのエンドポイントは、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
Attuを使用したMilvusの管理
前述の通り、Milvusを管理するためにAttuをインストールしました。以下のコマンドを実行してエンドポイントを取得します:
kubectl get ingress -n milvus
demo-milvus-attu
というIngressが表示されます。ADDRESS
の列がアクセスURLです。
NAME CLASS HOSTS ADDRESS PORTS AGE
demo-milvus-attu <none> * k8s-attu-xxxx.us-west-2.elb.amazonaws.com 80 27s
Ingressのアドレスをブラウザで開くと、以下のページが表示されます。Connectをクリックしてログインします。
図 5 Attu アカウントへのログイン.png
図 5: Attu アカウントへのログイン
ログイン後、Attu を通して Milvus データベースを管理することができます。
図 6 Attu インターフェース.png
図 6: Attu インターフェース
Milvusベクトルデータベースのテスト
Milvusのサンプルコードを使ってMilvusデータベースが正しく動作しているかテストします。まず、hello_milvus.py
サンプルコードを以下のコマンドでダウンロードする:
wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
サンプルコードのホストをMilvusサービスのエンドポイントに変更する。
print(fmt.format("start connecting to Milvus"))
connections.connect("default", host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", port="19530")
コードを実行してください:
python3 hello_milvus.py
システムが以下の結果を返した場合、Milvusが正常に動作していることを示す。
=== 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 ===
まとめ
この記事では、最も人気のあるオープンソースのベクトルデータベースの1つであるMilvusを紹介し、より高い弾力性と信頼性を実現するためにAmazon EKS、S3、MSK、ELBなどのマネージドサービスを使用してAWS上でMilvusをデプロイするためのガイドを提供します。
様々なGenAIシステム、特にRAG(Retrieval Augmented Generation)のコアコンポーネントとして、MilvusはAmazon Sagemaker、PyTorch、HuggingFace、LlamaIndex、LangChainを含む様々な主流のGenAIモデルやフレームワークをサポートし、統合しています。今すぐMilvusでGenAIイノベーションの旅を始めましょう!
参考文献
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word