Zilliz Cloud Serverlessを利用したGenAIアプリ構築で最大50倍のコスト削減を実現
#はじめに
近年の生成AIの進歩に伴い、ベクトルデータベースのユースケースは指数関数的に増加している。例えば、Retrieval Augmented Ggeneration(RAG)は、一般的な大規模言語モデル(LLM)の強化手法であり、MilvusやZilliz Cloud(マネージドMilvus)のようなベクトルデータベースを活用して、LLMがより正確な結果を生成できるように、関連情報を保存、インデックス付け、検索している。
サンフランシスコで最近開催されたUnstructured Data Meetupでは、Zillizのエンジニアリング担当副社長であるJames Luanが、Zillizの新サービスであるZilliz Cloud ServerlessをGenerative AIアプリケーションで開発者がどのように活用できるかについて議論した。一言で言えば、Zillizのこの新しいサービスは、ユーザが膨大な量のベクトル埋め込みをほんのわずかなコストで保存、インデックス、クエリすることを可能にする。Zilliz Cloud Serverlessの性能は、インメモリ・ベクター・データベースと比較しても非常に優れている。
この記事では、Jamesの重要なポイントをまとめ、Zilliz Cloud Serverlessをより深く掘り下げていく。詳細はYouTubeで彼の講演を見ることもできる。
.AI時代にベクターデータベースが重要な理由
検索拡張世代(RAG)、推薦システム、AI搭載チャットボット、セマンティック検索エンジンなどの最新のAIアプリケーションや技術は、大量の非構造化データを効率的に処理する信頼性の高いシステムを必要とします。ベクトル・データベースは、このようなデータを効率的に保存、索引付け、検索することを可能にするストレージ・システムである。
MilvusやZilliz Cloudのようなベクターデータベースは、効率的で高速なデータ検索のためにユーザーが選択できる高度なインデックス作成方法を備えている。それらの多く、特にMilvusやZilliz Cloudは、LangChain、Spark、Snowflake、Hugging Faceのような一般的なAIフレームワークやプラットフォームとの容易な統合も提供しており、生成AI開発者が洗練されたAIアプリケーションを構築することを容易にしている。密なベクトル検索や密なベクトルと疎なベクトルのハイブリッド検索など、さまざまな意味検索アプローチにより、開発者はどのようなユースケースに対しても最も関連性の高い結果を得ることができる。
Milvusコミュニティ](https://zilliz.com/community)の1,000人のジェネレーティブAI開発者を対象とした最近の2024年の調査では、AIアプリケーションでの使用を検討する前にベクトルデータベースに求める7つの側面が特定された：
1.検索品質：*与えられたクエリに対して、フェッチされた結果はどの程度関連性があるか？
2.**コスト効率データベースの運用・保守費用について、どの程度経済的か。
3.使いやすさ使いやすさ：開発者にとって、そのデータベースはどの程度使いやすく、直感的に導入・管理できるか。
4.パフォーマンス：データベースがクエリーを処理し、結果を返すまでの速さと効率はどうか？
5.スケーラビリティスケーラビリティ：データベースは、パフォーマンスを低下させることなく、どれだけ多くのデータやテナントを処理できるか？
6.高可用性** データベースの稼働時間をどれだけ確実に維持し、障害発生時のデータ損失を防ぐことができるか？
7.**データベースは、機密データをどの程度保護し、不正アクセスを防止できるか。
図1：1000人のGen AI開発者から収集したベクターデータベースを選択するための主な考慮事項](https://assets.zilliz.com/Figure_1_Key_considerations_for_selecting_a_vector_database_gathered_from_1000_Gen_AI_developers_dae2470476.png)
Milvusは検索品質が高く評価されている。性能と想起のバランスをとるために、異なる索引付けとベクトル検索方法を選択し、深さと文脈の両方で関連情報を検索することができる。
Flat、IVFFlat、HNSWなどのインデックス方式を選択することができます。それぞれのインデックス作成法には長所と短所があり、これらの方法の詳細な説明は ベクトル・インデックスの選択に関するこの記事で見ることができる。
ベクトル検索操作では、密、疎 や ハイブリッド検索 を使って、クエリに関連する結果を得ることができる。スカラー・フィルタリング](https://zilliz.com/blog/metadata-filtering-hybrid-search-or-agent-in-rag-applications)とブーリアン演算を併用することで、検索結果をさらに絞り込むこともできる。
Zillizクラウドサーバーレス](https://zilliz.com/serverless)の導入は、上記のベクトルデータベースの2番目と3番目に望ましい側面を大幅に強化します：コスト効率と使いやすさである。以下のセクションでは、Zilliz Cloud Serverlessがこの2つの側面においてMilvusをどのように改善したかを示す。
AIアプリケーション開発でよくある問題
AIアプリケーションを開発する場合、どのベクターデータベースを使用するかを決定した後、プロトタイプを開発することが次のステップとなる。この段階では通常、データのすべてまたはサブセットをベクトルデータベースに格納し、次に ラージ言語モデル(LLM)を選択し、 プロンプトを開発する。そして、ユースケースの品質目標を満たすLLMとプロンプトのセットを選択する。最後に、AIアプリケーションを本番環境にデプロイする。
しかし、AIアプリケーションのユーザーベースが大きくなるにつれて、インフラストラクチャの維持とスケーリングの複雑さが顕著になります。ユーザーあたりのコスト、本番環境でのアプリケーションのパフォーマンスの監視、マルチテナントへの対応、バーストトラフィックの管理、ソフトウェアのバグへの対応などの側面を考慮する必要があります。
ユーザーベースが大きくなればなるほど、検索品質、待ち時間、可用性などの主要なパフォーマンス指標を維持しながらユーザーのニーズに対応するためには、より多くのコストがかかるようになります。したがって、AIアプリケーションを本番環境にデプロイする際には、適切なインフラとソフトウェア・アーキテクチャを選択することが非常に重要です。
AIアプリケーションを拡張する1つのソリューションは、Zilliz Cloudの専用クラスタです。
図2：Zilliz専用クラスタのアーキテクチャ](https://assets.zilliz.com/Figure_2_The_architecture_of_Zilliz_dedicated_clusters_62a801f5f8.png)
専用クラスタは、AIアプリケーションのための専用環境とリソースを提供し、より大きなデータセットをより高いパフォーマンスで処理することを可能にします。以下のような高度な機能を提供します：
ストレージと計算の分離
バッチワークロード用の弾力的なリソースプール
S3のようなオブジェクトストレージシステムへのデータバックアップ。
より高速な検索速度のためのデータキャッシング。
これらのクラスタはクラウドでホストされるため、ローカルでのインフラ管理が不要になります。
しかし、専用クラスタの大きな欠点は、初期費用と継続費用が高いことです。クラスタがアイドル状態で検索アクティビティがない場合でも、月額100ドル以上のコストがかかる可能性がある。さらに、保存データとボリュームのユーザーベースが大きくなるにつれて、パフォーマンスが低下する可能性がある。したがって、コスト効率が高いだけでなく、我々のAIアプリケーションがより多くのユーザーベースに到達するにつれて拡張できるアーキテクチャを構築するための、より良いソリューションが必要である。
Zillizクラウド・サーバーレス、最大50倍のコスト削減を実現
Zilliz Cloud Serverlessは、AIアプリケーションを本番環境で円滑に稼働させるためのインフラコストを最小化するために、Zillizが提供する最新のアーキテクチャの進化を表しています。様々なワークロードに適応する従量課金やオートスケーリングなどの機能により、インメモリ・ベクターデータベースと比較して最大50倍のコスト削減を実現します。サーバーレスのサービスは、AWSやGCPを含む主要なクラウドプロバイダーで利用可能で、Azureでも近日中に利用可能になる予定です。
図3- Zilliz Cloudサーバーレスの主なメリット](https://assets.zilliz.com/Figure_3_Zilliz_Cloud_Serverless_Key_Benefits_e9c3847956.png)
Zilliz Cloud Serverlessは、AIアプリケーションのコストを最適化する4つの主要技術を実装しています：
1.論理クラスタと自動スケーリング
2.ストリーミングデータと履歴データの分離
3.さまざまなデータ・ストレージ・ニーズに対応する階層型ストレージ
4.マルチテナントとホットコールドのデータ分離
それでは、これらのテクノロジーをそれぞれさらに深く掘り下げてみよう。
論理クラスタとオートスケーリング
Zilliz Cloud Serverlessは論理クラスタとオートスケーリングの概念を導入している。論理クラスタは物理クラスタ内のデータベースに対応する。物理クラスタは複数のノードタイプで構成され、それぞれが独自の機能を持つ：
1.**プロキシノードトラフィックをルーティングし、クォータに基づいてリクエストをスロットルし、CPUとネットワーク帯域幅に応じてスケールする。
2.ストリーミング・ノード: ストリーミング・データ検索を提供し、書き込みキュー時間とCPU/メモリ使用量に基づいてスケールする。
3.**クエリーノード過去のデータ検索リクエストを処理し、検索キュー時間とCPU/メモリ使用量に応じてスケールする。
4.**インデックス・ノードオブジェクトストレージに保存されたブロブデータにインデックスを構築する。
図4：論理クラスタの図](https://assets.zilliz.com/Figure_4_The_diagram_of_logical_clusters_59bbb3ffe6.png)
論理クラスタは、APIキーを介した各テナントの認証メカニズムを使用して動作する。各テナントは固有のAPIキーを持ち、システムはこれを使用してリクエストをルーティングし、クエリ操作中に正しいデータが取得されるようにする。
データ書き込み操作の間、その場で生成されたすべてのデータは、ストリーミング・ノード内に特定の時間間隔で保存される。これにより、新鮮なデータを低レイテンシーで取得できる。しばらくすると、このストリーミング・データはブロブ・ストレージ（S3など）にフラッシュされ、インデックス・ノードが全データのインデックスを構築する。
クエリー操作中、インデックス化されたデータはすべてクエリーノードのローカルディスクにキャッシュされる。この方法は、インメモリーインデキシングに比べてストレージコストを大幅に削減する。
ストリーミングデータと履歴データの分離
前のセクションで説明したように、Zilliz Cloud Serverlessはアーキテクチャに異なるノードタイプを実装することで、ストリーミングデータと履歴データを効果的に分離している。
ストリーミング・データとは、その場で処理されるリアルタイムで継続的に生成されるデータのことであり、履歴データとは、過去に収集され保存されたデータのことである。ストリーミング・データには新鮮な最新情報が含まれ、ストリーミング・ノード内に一定期間保存されるため、クエリ操作時に高速な検索が可能になる。
所定の期間が経過すると、ストリーミング・ノード内のデータはブロブ・ストレージにフラッシュされ、事実上、履歴データの一部となる。一般的に、ブロブ・ストレージは、リアルタイム・データやフレッシュ・データと同レベルの即時アクセスを必要としない大量のデータに対して、より費用対効果の高いソリューションであるため、この移行は極めて重要である。
図5-論理クラスタ内の異なるノードのワークフロー](https://assets.zilliz.com/Figure_5_The_workflow_of_different_nodes_in_a_logical_cluster_0eef248035.png)
検索操作中、すべての履歴データはクエリ・ノードにキャッシュされる。その後、システムはストリーミング・ノードとクエリ・ノードからの検索結果をマージし、包括的な結果を提供する。
階層型ストレージ
ベクターデータベースの運用コストが高い主な理由の一つは、全てのデータがRAMに保存されていることである。この問題に対処するため、Zilliz Cloud Serverlessはアーキテクチャに階層型データストレージ技術を導入している。
階層型データ・ストレージとは、性能要件、コスト、アクセス頻度に基づいてデータを異なるレベルに整理するという分かりやすいものだ。アクセス頻度の高いデータはより高価で高性能なストレージに、アクセス頻度の低いデータはより安価で低速なストレージに保存されるというのが一般的なルールだ。データカテゴリーごとに異なるストレージ階層を実装することで、データストレージの全体的なコストを最適化できる。
図6-階層型ストレージ図](https://assets.zilliz.com/Figure_6_Tiered_storage_diagram_ce6076948e.png)
低レイテンシーで取り出す必要のある、頻繁にアクセスされるデータはRAMに保存される。上図のように、RAMにデータを保存するには、ストレージ1GBあたり約5ドルのコストがかかる。しかし、その見返りとして、他の階層と比較して最速の約100ナノ秒で結果を得ることができる。
一方、アクセス頻度の低いデータは、Amazon S3などのブロブ・ストレージに保存される。これはストレージ1GBあたり約0.023ドルかかるが、結果を取り出すのに10ミリ秒以上かかる。
マルチテナントとホットコールド分離
Zilliz Cloud Serverlessは、特にマルチテナンシーユースケースのために、マルチレイヤーのデータキャッシングを導入している。ホット "テナントと "コールド "テナントのデータストレージを区別する。
ホット・テナントとは、データの検索やクエリーを頻繁に行うアクティブなユーザーを指す。逆に、コールド・テナントはアクティブ度が低く、データ検索を頻繁に行わない。
テナントがホットに分類される場合、そのデータはローカルメモリに保存され、低レイテンシーでの検索が保証されます。一方、テナントがコールドに分類され、データ検索を実行したい場合、まずすべてのデータをブロブストレージ（S3など）からロードする必要があり、ホットテナントよりも検索時間が長くなります。
図7：マルチテナントのユースケースにおけるホットとコールドの分離](https://assets.zilliz.com/Figure_7_Hot_cold_separation_in_a_multi_tenant_use_case_677868f74b.png)
アプリケーションは、すべてのデータをブロブストレージからローカルメモリにロードすることで、レイテンシーを改善するために事前にウォームアップすることができます。その後、ユーザーがAIアプリケーションにアクセスすると、低レイテンシーで検索プロセスを完了できる。
Zilliz Cloud Serverlessは、データ検索プロセスをさらに高速化するために、パーティション・キーによるデータ・クラスタリングも実装している。データ検索中、システムは利用可能なすべてのデータではなく、有望なパーティション内のデータのみを検索する。
以下は、ホット検索、ウォーム検索、コールド検索のコスト比較である：
| --------------- | --------------- | --------------- | -------------- | | コールド・サーチ｜ウォーム・サーチ｜ホット・サーチ｜1M、768インチ | 1M、768Dim｜2.3s｜80ms｜4ms｜｜です。 | 10M、768Dim**｜7s｜150ms｜7ms｜｜｜です。
表 単一テナントにおけるコールドサーチとホットサーチのレイテンシー比較。
図示されているように、コールド検索（すべてのデータがブロブ・ストレージに存在する）では、検索操作中のデータ検索により多くの時間を要する。1,000万個の埋め込みデータ（それぞれ768次元ベクトル）の場合、システムは検索操作を完了するのに約7秒を必要とする。この速度は、RAGのような一般的な生成AIのユースケースにはまだ許容範囲である。対照的に、すべてのデータがローカルメモリに存在する場合、同じシナリオではわずか7ミリ秒しか必要としない。
しかし、コールドサーチを実行すると、大幅なコスト削減につながる。コールドサーチ用のデータベースは約16ドルかかるのに対し、ホットサーチは915ドルだ。これは、Zilliz Cloudのサーバーレス・アーキテクチャによる50倍のコスト削減に相当する。
Zilliz Cloudの新機能は？
サーバーレスオファリングに加えて、Zillizは最近、本番環境でAIワークロードを実行するためのサポートを強化するZilliz Cloudの新機能を発表した。これらの新機能の概要は以下の通りです：
サーバーレス一般提供（GA）**。
マイグレーションサービス**](https://zilliz.com/blog/zilliz-introduces-migration-services) ****データベースと他のデータシステム間でベクトルデータをシームレスに転送するためのもの。
500以上のソースからの非構造化データの取り込み機能を大幅に拡張するFivetranとの新しい統合。
Multi-replica**：クラスタレベルでのレプリケーションを可能にし、クエリーパフォーマンスとシステムの可用性を大幅に向上。
オートスケーリング（プライベートプレビュー）***：Zilliz Cloudは、変動する需要に対応したクラスターキャパシティの管理という、本番環境における一般的な課題に対処するオートスケーリング機能をプライベートプレビューで展開します。
Zilliz Cloudの新しいリージョンがオンラインになりました：AWS東京(ap-northeast-1)**は、アジア太平洋地域および近隣地域のユーザーにとって、より低いレイテンシー、より優れたパフォーマンス、より大きなデータ主権を意味します。
その他にもより詳細な情報については、最新のZilliz Cloud ローンチブログをご覧ください。
結論
Zilliz Cloud Serverlessは、AIアプリケーションシステムの運用とコストを最適化するためにZillizが実装した最新の進歩である。4つの主要テクノロジーを活用することで、ユーザーはAIアプリケーションをインメモリ・ベクターデータベースよりも最大50倍低いコストで運用できる可能性がある。これらのテクノロジーには、論理クラスタ、ストリーミングと履歴データの分解、階層型ストレージ、マルチテナントのホットコールド分離が含まれる。
Zilliz Cloud Serverlessを始めたい方は、無料でお試しいただけます。詳しくはこのページをご覧ください！
読み続けて
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.
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.