オープンソースのベクターデータベースのコスト：エンジニアのためのDYI価格設定ガイド
エンジニアとして、私たちはしばしばオープンソースのソフトウェアを利用することからプロジェクトを始めます。例えば、Retrieval Augmented Generation (RAG)システムをセットアップするとき、私たちはMilvusのようなオープンソースのベクターデータベースを利用します。このデータベースは、簡単なpipインストールで稼働させることができます。この方法はシンプルで無料であるため、私たちにとっては何の問題もない。
それから、AWSのようなクラウドサービスの魅力もある。小規模なプロジェクトであれば、コストは驚くほど低く、月に数ドルということもある。しかし、プロジェクトの規模が大きくなり、ニーズが複雑になればなるほど、出費は急増する。これが使用量ベースの課金の核心であり、使用量が増えれば増えるほど、大きな金銭的負担になりかねない。
大規模なプロジェクトでは、MinIOのようなリソースを社内で管理するか、Amazon S3のようなサービスに依存するかという議論がしばしば展開される。こうした極めて重要な決定には、慎重な検討が必要だ。しかし、すべてのソフトウェア・エンジニアやエンジニアリング・マネージャーが、これらの選択肢を徹底的に評価するために必要な時間を投資しているわけではないことに、私たちは気づいています。
マネージドサービスが手頃なソリューションを提供している場合でも、オープンソースのベクターデータベースのセットアップを管理することを好むエンジニアもいる。その理由を尋ねると、ハンズオン管理から得られる満足感や、それによってもたらされるキャリアアップの機会から、"上司がこの費用を承認するはずがない "という諦めの姿勢まで、さまざまな答えが返ってくる。
エンジニアリング・マネジャーの回答はまちまちだ。外部のプロバイダーよりも、自分たちのチームの能力を信じている人もいる。多くの場合、メリットとデメリットを比較検討したり、マネージド・サービスに必要な投資を正当化したりする手助けを必要としている。多くのマネジャーにとって、マネージド・サービスの予算は必ずしも必要ではなく、メンテナンスのための人員増を要求するのがお決まりとなっている。
この習慣は、この分野におけるより広範な問題を浮き彫りにしている。クラウドサービスが普及してから10年以上が経過しているにもかかわらず、私たちはいまだにマネージド・サービスをどのように活用するのがベストなのかを模索している。
オープンソースのベクターデータベースは実際いくらかかるのか？
まずは明白で定量化しやすい費用から始めよう
Milvusのようなオープンソースのベクターデータベースをプロダクションフォーマットで運用する世界に飛び込むと、"フリーソフト "という最初のワクワク感は、すぐにハードウェアのコストによって現実のものとなります。ここでは、考慮すべき主なハードウェアの分野を2つに分けて説明しよう。
**まずはデータベースのバックボーンです。Milvusのような分散データベースの運用は、単にデータベースを稼働させるだけでなく、その稼働をサポートする依存関係を設定することでもあります。Milvusをセットアップする前に、WALのデプロイメント（KafkaやPulsarのようなオプションを使う）、安全なメタデータストレージ（hello、etcd）、そしてKubernetesを使った全体のオーケストレーションについて理解する必要がある。トラフィックを管理するロードバランサーや、すべてをチェックするための監視・ログツールも忘れずに。プロジェクトが小規模であれば、これらのコンポーネントはハードウェア予算に大きく影響する。ミニ・データセンターを立ち上げるようなもので、私たちはいじくるのが大好きだが、そのコストはさらなる挑戦のレイヤーを増やすことになる。
**ベクター・データベースのコストそのものだ。ワーカーノード用にEC2インスタンス（またはそれに相当するもの）をセットアップすることは不可欠であり、利用規模にかかわらず、特定のパフォーマンスと容量のニーズに合わせて調整する必要がある。S3やAzure Blobのようなストレージソリューションも必要だ。さらに、データの出し入れは必ず発生するため、ネットワークコストも忘れてはならない。
オープンソースのベクターデータベースを運用する上で、定量化するのが難しい側面もあります。
しかし、だからといって、それらを考慮することを避けるべきであるとか、望むと望まざるとにかかわらず、これらのコストを後で支払うことになるということではありません。
それはキャパシティ・プランニングから始まる。ベクターの数、その次元、メタデータのボリューム、1秒あたりのクエリー数（QPS）などです。しかし、正直に言うと、これらの推測はしばしば的外れです。オーバープロビジョニングは安全策に見えますが、決して使わないかもしれないリソースをロックしてしまいます。過小プロビジョニング？それは、ダウンタイムと緊急トラブルシューティングセッションへの早道です。
さらに、適切なキャパシティを得るには、適切な数のインスタンスを選択するだけでは不十分です。Zilliz](https://zilliz.com/)では、多様なユースケースの要件を深く理解し、それらのニーズを効率的に満たすためにインフラを継続的に調整することです。
単にハードウェアを選ぶだけでなく、全体的なセットアップフェーズがあります。Kubernetesの設定、Terraformによるスクリプト作成、GUIの開発、バックアップとレプリケーション戦略の最終決定といったタスクは、単純な作業ではない。時間を消費し、高度な専門知識が要求される。
**定期的なメンテナンスは派手ではないかもしれないが、サボるのはギャンブルだ。バグフィックスやセキュリティパッチを中心としたアップデートを怠らないことは譲れない。システムを機能的に保つだけでなく、既知の脆弱性からシステムを守り、新機能を効果的にサポートできるようにするためだ。
もうひとつの重要な運用タスクは、ワークロードのアンバランスを監視し、調整できるようにすることです。リソースを積極的に管理することで、パフォーマンスのボトルネックを防ぎ、長期的にコストを削減することができます。また、拡張の時期が来ても、戦略的に行うことで、すでに最大になったシステムの拡張に奔走する必要がなくなります。
物事がうまくいかないときの計画を立てることは、セットアップそのものと同じくらい重要です。オープンソースのベクターデータベースを使いこなすことがトラブルシューティングに役立つ。もう一つのプロとしてのコツは、影響を最小限に抑えて立ち直ることができるように、しっかりとしたディザスタリカバリプランを構築することだ。
「ベクターデータベースが遅いのはなぜですか？慎重なキャパシティプランニングとチューニングを行っても、最終的には誰かが "なぜ私のMilvusはこんなに遅いのですか？" と尋ねるでしょう。待ち時間の問題-100ミリ秒と予想されていたものが200ミリ秒になったり、時折5,000ミリ秒に跳ね上がったり-は謎となる。このような問題を解決するのは簡単ではなく、専門的な知識が必要です。チームがMilvus、Kafka、Elasticsearchにまたがって手薄になっている場合、速度低下の発見と解決はさらに難しくなります。特定のベクターデータベースに特化したエキスパートの雇用とトレーニングに投資するか、パフォーマンス問題の影響に備えるかの選択に帰結する。
定量化することがほぼ不可能なコストもある
エンジニアの時間の価値が分かれば計算できる、わかりやすいコストについて説明した。しかし、あるカテゴリーのコストについては、それを正確に把握するのがより困難である。特に、ミッション・クリティカルなワークロードのためのベクター・データベースのような複雑なものに関してはなおさらだ。
**特に、ミッションクリティカルなワークロード用のベクターデータベースのような複雑なものに関してはなおさらです。ここでの遅れは、些細な迷惑から競合他社をリードすることにまで及びます。単に先行するだけでなく、取り残されないようにすることが重要です。
エンジニアの士気と定着率。エンジニアは問題を解決したいのであって、システムのお守りをしたいわけではありません。もちろん、オンコール業務やメンテナンスも期待されるが、それはこれらの業務がバランスよく行われ、面倒なことを自動化する方向に進んでいることが前提だ。もし、終わりの見えないメンテナンスが延々と続くとしたら、それはやる気をなくし、チームを縮小させる早道だ。さらに、不幸なエンジニアは出口を探すだけでなく、仕事にベストを尽くしていない。
リスクとその波及効果。ベクター・データベースの魔術師のチームがありますか？素晴らしい、あなたのリスクは低くなったが、なくなったわけではない。完璧に近いアップタイムを達成できるかもしれません。しかし、もしあなたのチームが学習しながらやっているのであれば、バンプが発生することが予想されます。単なるダウンタイムではなく、データ損失、セキュリティ上の不手際、そして罰金の話です。また、ダウンタイムは目先の打撃だけでなく、復旧作業、午前4時の危機管理シフト、改善ではなく消火活動の頻度などにも影響します。
ベクターデータベース管理におけるコストの評価方法
エンジニアがMilvusのようなベクターデータベースをセットアップするのに費やす時間や、直接的なコストを計算した後、私たちはより大きな問題に直面する：すべてを自前で管理すべきか、それともマネージドサービスを利用したほうがいいのか。
まずはデータを集めるために、いくつかのパフォーマンステストに取り組むのがベストだろう。ベクター・データベースにとって最も重要なパフォーマンス・テストは、実際のワークロードをどのように処理するかを確認することから始まる。つまり、実際のオペレーションを模倣したテスト環境を構築し、それらをプッシュしてパフォーマンスを確認するのだ。このステップは、データベースの実行速度とストレス下での挙動を示すため非常に重要であり、セットアップが投資に値するかどうかを判断するために必要な情報である。
このパフォーマンスデータを収集した後、単純な比較に変えます：特定のデータ量や1秒あたりのクエリー数を処理するのに、どれだけのコストがかかるのか。コストを比較するこの方法は、データベースのベンチマークでよく認められており、どのオプションが最高の価値を提供するかを明確に把握するのに役立ちます。
コストの最適化
クエリーあたりのコストを削減することは、ユーザー側からもクラウドプロバイダー側からも可能です。1つの簡単な戦略は、ダイナミック・スケーリングを採用することで、使用していないリソースに対する支払いを回避することだ。しかし、すでに説明したプロビジョニング不足の可能性などの課題を覚えておく価値がある。
プロジェクトのニーズに応じて、想起精度、レイテンシー、スループットのバランスを調整することも、コスト管理に役立つ。これには、状況に応じて適切なインデックスタイプを選択することが含まれる。例えば、DiskANNは許容可能なレイテンシとスループットで中程度の想起を行うのに適していますが、IVF_Flatはレイテンシが高く、スループットが低いにもかかわらず、高精度のシナリオに適しています。
MMap](https://zilliz.com/blog/milvus-introduced-mmap-for-redefined-data-management-increased-storage-capability)を使用することで、メモリに格納するデータを少なくする方法もある。この選択は、ユースケースの要求に合わせるべきです。
Zillizでは、さまざまなユースケースに適合するコストの最適化に重点を置いています。Zilliz Cloud](https://zilliz.com/cloud)(Milvusのフルマネージド版)は、お客様のベクトルデータベースニーズに対して最高の価格性能比を保証するために、毎月リリースされる新機能で継続的に強化されています。
経済的な賢い選択
ベクターデータベースの管理方法を決定するには、最終的には数字を見て、最も費用対効果の高い方法を選択する必要があります。つまり、サーバーの運用にかかる直接的なコストから、より高度なハードウェアが必要かどうか、あるいはスマートなエンジニアリングによってより経済的に目標を達成できるかどうかまで、あらゆることを考慮する必要がある。
ここで重要なのは、選択肢とそのコストを把握しやすい形で提示し、チーム内の他のメンバーや意思決定者とこれらの選択肢について話し合うときに、明確でわかりやすい言葉で話せるようにすることです。大変な仕事を避けるのではなく、最もインパクトのあるところに努力とリソースを投資するようにするのだ。
Steffi LiSteffi is the Director of Product Marketing at Zilliz, with prior experience leading the GTM strategies for open-source data technologies such as Apache Kafka and Apache Airflow. Passionate about travel, yoga, and non-fiction reading, she brings a balanced and enriched worldview to her professional pursuits.
読み続けて
Deliver RAG Applications 10x Faster with Zilliz and Vectorize
Zilliz Cloud delivers reliable vector storage and search, while Vectorize automates your RAG pipelines and keeps your embeddings up-to-date.
Deploying a Multimodal RAG System Using vLLM and Milvus
This blog will guide you through creating a Multimodal RAG with Milvus and vLLM.
The Practical Guide to Self-Hosting Compound LLM Systems
BentoML shares its research insights in AI orchestration, demonstrating solutions for optimizing performance issues when self-hosting AI models.