18ヶ月でZilliz Cloudを構築：パブリック・クラウド上でスケーラブルなベクトル検索サービスを構築する際に学んだ教訓
序文
ベクターデータベースは、2023年のデータベース業界をリードするトレンドとして浮上している。この投稿では、オープンソースのベクターデータベースとして最も採用されているMilvusを利用したフルマネージドサービスであるZilliz Cloudを18ヶ月かけてゼロから開発した詳細を紹介する。この間、私たちは包括的なクラウドサービスをゼロから開発し、大規模言語モデル(LLM)の急拡大に後押しされ、トラフィックが10倍に急増する事態を乗り切りました。この回顧録は、私たちの旅で得た重要な設計上の選択と貴重な洞察を共有することに焦点を当てています。
Zillizクラウド専用クラスタ - 旅の始まり
時計の針を2022年5月に戻すと、オープンソースのベクターデータベースMilvus 2.0は、何度かの大きな繰り返しの後、ようやく安定し始めました。ユーザーとの会話を通じて、安定した商用ホスティングバージョンの必要性が再三の要望として浮上した。Milvusの開発会社であるZillizにとって、商業化に乗り出すには絶好のタイミングであった。経験豊富なエンジニアのチーム、成熟しつつある製品、そして緊急のニーズを持つ熱心なユーザーベースがあったからだ。このことを念頭に置いて、私たちは6ヶ月以内に製品を発売するという野心的な目標を設定しました。
プロジェクトを開始するにあたり、私たちは現在の能力と目標を評価しました：
- 私たちのコアテクノロジーであるクラウドネイティブでオープンソースのベクトル・データベースは、ストレージとコンピューティングの分離とマイクロサービスのフレームワークで設計されており、Kubernetes（K8s）クラスタにシームレスに統合できるように設計されています。このクラウドネイティブなフレームワークにより、クラウドの本番環境に迅速に適応することができます。
図1：Milvusアーキテクチャ](https://assets.zilliz.com/Milvus_architecture_0c65c05f6e.png)
私たちはKubernetes Operatorを利用しているため、AWSやGCPといった主要なパブリッククラウドプラットフォームにサービスを迅速にデプロイすることができます。これは、パブリッククラウド上で本番サービスの実装に成功した複数のユーザーによって確認されています。
私たちのプラットフォームには、モニタリングやロギングといった基本的な観測機能が含まれていましたが、本番環境では重要なアラート機能が必要でした。
前述の要素に加え、サービスとしては、ユーザーログイン認証、メータリングと課金、支払いメカニズム、ネットワーク、セキュリティ、ウェブコンソール、OpenAPIサポート、リソーススケジューリング、ワークフロー管理など、いくつかの重要なコンポーネントが欠けていました。
6ヶ月以内に構築すべき必須モジュールを絞り込むことは、困難な課題でした。そこで私たちは、重要な自己評価を行いました：利用可能なリソースを最も効率的に活用するにはどうすればよいか？利用可能なリソースを最も効率的に活用するにはどうすればよいか？これらの極めて重要な疑問が私たちの熟考を導き、最終的に一連の基本設計原則を形作ったのです：
車輪の再発明を避けるため、成熟したサードパーティ製品を最大限に活用する：
迅速に市場に投入することを重視し、すでに確立されたクラウド・サービスやサードパーティ・サービスを戦略的に活用した。EKS、EC2、S3、EBS、ALBといったAWSのコアサービスに加え、AWSが管理するKafkaやRDSをインフラのバックボーンとして活用した。このアプローチにより、当面のニーズが容易になっただけでなく、このようなコンポーネントが将来的にマルチクラウド環境に適応するための費用対効果の高い道筋を提供し、イノベーションのペースを加速させることが明らかになりました。GCP/AzureのメッセージングキューとマネージドKafkaサービスの互換性の問題に直面し、Apache Bookkeeperを軸とした分散ログシステムを開発しました。信頼性が高く、オープンソース、またはクラウドネイティブの分散ログソリューションがないことが、この試みの原動力となりました。このギャップに突き動かされ、私たちはこのソリューションのオープンソース化を検討しています。
サードパーティのSaaSプロバイダーは、私たちのプラットフォームの開発を迅速に進める上で役に立った。たとえば、決済処理の管理にStripeを採用し、複雑なメータリングや課税要件に対応した。マルチクラウド・マーケットプレイスとの接続を容易にするため、Sugar.ioを統合しました。さらに、課金業務を強化するために、OrbやMetronomeなどの課金サービスプラットフォームを評価しました。Auth0は、アカウント管理とログイン機能のために選択した製品です。さらに、認証とログイン機能を拡張し、Googleログインをサポートしました。PagerDutyは、既存のモニタリング・ツールとの統合が容易で、通知ルールのカスタマイズが可能なことから選択しました。
エンティティを不必要に増やすべきではない
オッカムの剃刀の哲学に導かれ、私たちはミニマリストのデザインアプローチを採用しました：
アーキテクチャの簡素化:** 当初、私たちの設計には60を超えるマイクロサービスが含まれており、開発とテストの調整に大きな課題がありました。アーキテクチャを簡素化するために、ユーザー、課金、CloudService、リソース、メタデータ、スケジューリングなど、コアとなるマイクロサービスを10個以下に絞りました。この削減により、依存関係が明確になり、テストの負担が軽減されました。
機能の簡素化:**初期段階では、Zilliz Cloudは登録、クラスタデプロイメント、課金などのコアユーザー機能に重点を置き、スケーリングやバックアップのような緊急性の低い機能は、作業負荷を軽減するために意図的に延期しました。特筆すべきは、堅牢なフィードバックループの確立へのコミットメントで、当初は電子メールベースのフィードバックを促進し、その後Zendeskとの統合でそれを補強し、迅速かつ高品質なフィードバックがさらなる改善の指針となるようにしました。
設計の簡素化：*** 私たちのクラウド・サービスの設計は、効率的なコミュニケーションとユーザー・エンゲージメントの可能性を優先し、規律正しく集中的なアプローチを必要としました。迅速なA/Bテストを活用することで、迅速に機能を検証し、ユーザーエンゲージメントの指標に基づいて適応させることができました。
1日目から2日目の課題を予測：
クラウドサービスのダイナミックなランドスケープでは、ユーザー・インターフェースとサービスの信頼性を犠牲にすることなく、迅速に進化させる能力が最も重要である。この複雑な操作は、「空中でジェットエンジンを交換する」ことに似ている。外部からは、サービスが完璧に動作しているように見えるが、内部では革新と改善のサイクルが活発に行われている。エンド・イン・マインドの開発アプローチを取り入れることは極めて重要である。
マルチクラウド対応:当初はAWSに焦点を当てていましたが、私たちのアプローチは常にクラウドにとらわれないことを優先してきました。GCPやAlibaba Cloudのようなプロバイダーを幅広く評価し、パブリッククラウド全体の互換性を確保しました。オープンソースプロジェクト「Crossplane」のカスタマイズを通じて、「クラウドアダプター」レイヤーを開発し、マルチクラウドサポートに関連するコストを削減しました。この設計により、GCPとの迅速な統合がわずか1カ月で実現し、他のパブリッククラウドプロバイダーとの統合も合理化されました。
セキュリティ：* AIGCのアプリケーション開発者はセキュリティ以外のことを優先するかもしれませんが、Zilliz Cloud Servicesはデータ・セキュリティを最も重視しています。クラウドIAM標準を厳格に遵守し、データへのアクセス許可を綿密に管理し、転送中および静止中のすべてのデータに暗号化を採用しています。最適なパフォーマンスを実現するためにネットワークの分離を重視し、効率性と使いやすさを考慮してAWSのEKSネットワークアドオンを選択しました。データ層と制御層の間の相互作用の境界を明確にすることで、BYOC 製品の展開時に大幅なコスト削減を実現しました。
リソース・プーリング: Zilliz Cloud Servicesは「クラウド・コミューティビティの法則」を採用し、リソース・プーリングによる弾力的なスケーラビリティを優先しています。ストレージと計算を分離し、動的な負荷分散を行うことで、クラウドリソースの効率的な利用を実現します。このアプローチにより、必要なときだけリソースを確保することができ、コストを削減しながらスポットインスタンスとラムダファンクションの利用率を大幅に向上させることができます。
運用フレンドリー： Zilliz Cloudは、他のベクターデータベースとは異なり、開発者や運用スタッフを念頭に設計されています。包括的なGUIと洗練された監視機能を特徴とするこのプラットフォームは、トリプルAZディザスタリカバリを提供し、厳格なSLAを遵守することで、本番環境の安定性と信頼性を保証します。
コアとなる設計哲学に導かれ、私たちはわずか6ヶ月で商用ベクトル検索製品の発売というマイルストーンを達成し、その過程で最初のシード顧客グループを確保しました。以下は、初回リリースのアーキテクチャ図です。
図2- Zillizクラウドアーキテクチャ](https://assets.zilliz.com/Figure_2_Zilliz_Cloud_Architecture_904d69aed2.png)
サーバーレス：新規ユーザー獲得コストを300円から5円へ
成長は予期せぬ瞬間に起こることが多い。AutoGPT](https://zilliz.com/blog/harnessing-vector-databases-to-empower-autogpt)の爆発的な人気に後押しされ、Zillizクラウドの成長は最高潮に達しました。ベクターデータベースを大規模言語モデルの長期記憶として捉えることが徐々に受け入れられ、Zillizのユーザーベースは急速に増加し、毎日追加される新しいクラスタの数はあっという間に数百に達しました。
しかし、この成長はZillizに安定性とコストという2つの大きな課題をもたらしました。私たちは常にスケーラビリティを重視していましたが、突然の高トラフィックの急増により、すべてのサービスが麻痺しそうになりました。クラウド・サービス・プロバイダーが提供するAPIはスロットルされ、私たちのロギング・ストレージ・システムであるLokiは、わずか数日の間に2度も満杯になり、リソース不足のために多くのサービスの中断を余儀なくされました。
さらに、Zilliz Cloudが最初に採用した無料トライアル戦略では、新規ユーザーに300ドルのクレジットを提供し、全機能を体験してもらうというものでしたが、ユーザー数の急増（そのほとんどがお試し利用）に伴い、コストが急増し、ビジネスモデルの見直しを余儀なくされました。このような痛みは、私たちがZilliz Cloud Serverlessを立ち上げるきっかけとなりました。Zilliz Cloud Serverlessは、より柔軟で、参入障壁が低く、ベクターデータベースの旅を始めたばかりのAIGCユーザーに適した製品です。
聖杯はまだそこにある：RAGアプリケーション開発のためのスケーラビリティ、コスト、レイテンシーの調整
Retrieval-Augmented Generation (RAG) ](https://zilliz.com/learn/Retrieval-Augmented-Generation)のユースケースでは、理想的なフリー層のソリューションは以下を考慮する必要がある：
図3：RAGアプリケーションにおけるスケーラビリティ、コスト、レイテンシの調整
1.スケーラビリティ - これには2つの重要な側面がある：
1.個々のテナント・レベルでは、システムを動的に拡張してデータを効率的に処理する必要があります。この動的なスケーリングには、処理するデータセットの大小にかかわらず、テナントごとに変動するデータ量に対応できるよう、ベクターデータベースが汎用性を持つことが必要です。また、扱うデータの大小にかかわらず、常に安定したクエリ応答時間を維持しなければならない。
2.多数のテナントを管理する場合、システムは最大数百万テナントのスケーラビリティを効率的にサポートしなければならない。具体的には、「ホット」（アクティブ度が高い）使用パターンと「コールド」（アクティブ度が低い）使用パターンをインテリジェントに区別して対応し、全体にわたって最適なリソース配分とパフォーマンスの一貫性を確保する必要がある。
2.コスト - 無料ティアのコスト管理は極めて重要である。理想的には、768 次元ベクトル 100 万個をサポートするのに十分なリソースを提供しながら、コストを 1 ￢ドル以下に抑えることです。しかし、メモリ内ベクトルインデックスに依存する場合、768 次元ベクトル 100 万個を処理するための価格は、簡単に 10 ㎉を超えます。このコストは、企業向けサービスを対象とするSaaS企業にとっては許容範囲かもしれませんが、消費者向けのToCアプリケーションにとっては過剰です。
3.低レイテンシ - RAGのユースケースは、検索やレコメンデーションの領域ほどレイテンシに敏感ではないかもしれませんが、ベクトル検索のパフォーマンスは "Time-to-first-token "に大きく影響します。したがって、低レイテンシを維持することは、ユーザーエクスペリエンスとシステムの応答性を高めるために極めて重要です。
Zilliz Cloudの最初の提供は、大量のデータを処理し、低レイテンシを実現する優れたスケーラビリティを示し、ユーザーの期待を上回るものでした。数多くのテナントを管理し、コストをコントロールしても、専用クラスターソリューションではユーザーの要求を十分に満たすことはできませんでした。この問題を解決するために、私たちは「Zilliz Serverless Tier」を開発しました。これは、AIGCの個人ユーザーの参入障壁を下げるために特別に設計されたサービスモデルです。このティアは、上記の課題に効果的に対処するために、最も費用対効果の高いストレージ・ソリューションとスケーラビリティを提供します。
Zillizクラウド・サーバーレス・アーキテクチャ
図4- Zilliz Cloudサーバーレスアーキテクチャ](https://assets.zilliz.com/Figure_4_The_Zilliz_Cloud_Serverless_Architecture_bda959067b.png)
Zilliz Cloud Serverlessは論理クラスタの概念を導入しており、各論理クラスタは物理クラスタ内のデータベースに対応している。データベースとAPIキーベースの認証メカニズムにより、単一の物理クラスタ内のすべてのテナントの論理的分離を実現する。クエリーの際、システムはAPIキーに基づいてリクエストをルーティングし、ルーティングのためにプロキシノードを使用して、ユーザーがアクセスする必要のあるデータを決定する。
データの書き込み操作はまずログノードのプールに送られ、ログノードはデータをWrite-Ahead Logging（WAL）サービスに書き込み、定期的にデータを再編成してオブジェクトストレージにフラッシュする。CompactionServiceは、小さなデータセグメントを大きなデータセグメントに統合し、削除されたエントリーをパージして、ストレージスペースとアクセス速度を最適化する役割を担うプーリングサービスである。IndexServiceは、生データにインデックスを構築し、クエリノードによってロードされ、クエリの効率性を確保する。
クエリ操作中、私たちの戦略では、クエリ・ノードのローカル・ディスクにすべてのデータをキャッシュし、メモリからディスクへのスワッピングをローカルで実行します。この方法論は、メモリベースのインデックス作成と比較して、サーバーレスユーザーのストレージコストを10倍以上大幅に削減する。しかし、主な課題は、テナントのホットスポット問題やノイジーな隣人によって引き起こされるクエリーノードの過負荷を防ぐために、リソースを効果的に管理することにある。これは、各クエリーノードが複数のテナントからのデータロードを処理しなければならないため、特に重要です。
システムの安定性を高めるために、我々は以下の3つの重要なメカニズムを導入した：
分散クォータ：分散クオータ：集中クオータサービスに基づくこのメカニズムでは、クエリノードの負荷に応じてリソースのクオータを動的に割り当て、調整します。この動的な割り当てにより、各テナントの公平なリソース消費が保証されます。
1.分散クォータ：このメカニズムは、集中型クォータサービスに基づいており、リソースクォータを動的に割り当て、クエリノードの負荷に基づいて調整します。これにより、各テナントの公平なリソース消費が保証されます。
2.メトリクスに基づく動的なリソースのスケーリング：メモリ、ディスク、CPU負荷、リクエストキューイングを包括的に管理するクラウド・リソース・スケジューラー・モジュールを組み込みました。さまざまなシナリオで変化するリソース需要に対応するため、物理リソースの動的なスケーリングを可能にします。
3.多階層スケジューリング：リソースのグループ化による物理的な分離、リソースグループ内での負荷分散、ノードレベルでのクエリキューとキャッシュスケジューリングの管理など、さまざまなレベルで運用されるリソーススケジューリングフレームワークを確立しました。このアプローチは、複数のテナント間で公平なリソース割り当てを保証すると同時に、単一のテナントがリソースを独占するリスクを軽減します。
私たちのサーバーレス・サービスを通じて、個人ユーザーのトライアル費用を5ドルに抑えることに成功し、何万人ものAIGC開発者をサポートしています。Zilliz Cloudの次期リリースでは、Serverlessソリューションをさらに強化し、コスト効率と弾力性をさらに向上させます。この新しいバージョンでは、各Serverlessユーザーは、単一のコレクションで数百万のテナントからのデータを扱うことができるようになり、現在のソリューションと比較してストレージコストを10分の1に大幅に削減しながら、データの分離を実現します。Zilliz Cloud Serverlessの技術的な詳細については、今後の記事で掘り下げていく予定だ。
オープンソースのVectorDBからクラウドサービスを構築して学んだ6つの教訓
1.クラウドの限界を認識する： Milvusのようなクラウドネイティブなシステムであっても、クラウドSaaSへの移行には大きな課題がある。それはEC2やEBSへの単純なデプロイにとどまらない。オープンソースデータベースの領域では、水平スケーリング、障害回復、綿密なノブチューニングによるパフォーマンス最適化を実現するために、ユーザーは製品の複雑さを深く理解する必要がある。クラウドサービスの真の課題は、高い信頼性と弾力性を維持しながら運用を合理化することにある。S3レートの制限やOpenAPI呼び出し頻度の制限など、クラウド環境の特定の制約に対処することは、クラウドコンピューティングの弾力性とスケーラビリティの可能性を十分に活用する上で極めて重要です。
2.**製品の初期段階で継続的に新機能を追加することは、顧客を引き付けるために魅力的に見えるかもしれないが、ユーザーの真のペインポイントに対処することを優先すべきである。SaaS版よりもオープンソース製品の機能のリードタイムを約6ヶ月に保つことは、良い妥協点である。このリードタイムを確保することで、これらの機能がサービス提供のためにロールアウトされる前に、徹底的なテストと改善が行われる。
3.適切な限度を設定する：どんな製品も完璧ではありません。例えばS3。その洗練されたインターフェースと広範囲に及ぶ改良にもかかわらず、開発者がその価値を最大限に発揮できるのは特定の状況においてのみである。オープンソースの製品が持つ自由とは異なり、SaaS製品は自らを守るためにより厳しい制約を必要とする。これらの制約は製品の不可欠な部分を形成し、ユーザーに対するガイダンスと教育の役割を果たす。合理的な制約は、ユーザーをよりスマートな製品の使い方へと導き、全体的な価値とユーザー体験を向上させます。
4.クラウドに依存しないサービスの選択：主要なクラウドプラットフォームで広く利用可能なS3、EC2、K8sマネージドサービスなど、クラウドにとらわれない依存サービスの採用を検討することで、コスト削減とマルチクラウド採用の複雑さの簡素化という点で大きなメリットを提供できる。あるいは、マルチクラウドの利用を本質的にサポートするSaaSサービスを選択することで、プロセスを合理化することもできる。クラウド・サービス・プロバイダーによって実装にばらつきがある可能性はあるものの、マルチクラウド適応レイヤーを早期に確立することで、冗長な開発作業を効果的に最小化し、全体的な効率を高めることができる。
5.**パブリック・クラウドでは、一見手頃に見えるリソースが予想外に高コストになることがある。例えば、請求書分析を実施する前は、ALBネットワークの帯域幅コストが全体的な費用のかなりの部分を占めるかもしれないことをまだ予想していなかった。コストを最適化し、パフォーマンスを最大限に最適化するには、異なるインスタンスタイプとサービスのパフォーマンスを徹底的に理解することが不可欠です。例えば、GP3クラウドの各ディスクは3000IOPSを提供します。1台のマシンに複数のディスクをバンドルし、RAIDを構成することで、ディスクのスループットを大幅に向上させることができ、追加IOPSに対する高額な請求を避けることができます。
6.オープンAPIの重要性を認識する： エージェントの採用が進むにつれ、オープンAPIと関連文書の役割がますます重要になっている。従来のクラウド・サービスは、機能を提供するためにウェブ・コンソールやグラフ・インターフェースに依存していたが、将来のクラウド・サービスの相互作用と統合は、ますますOpenAPIに依存するようになるだろう。サービスの自動化のレベル、エージェントの使いやすさ、観測可能性は、将来のクラウドサービスの極めて重要な評価基準となっています。
エピローグ
この1年半を振り返ってみると、我々は非常にスリリングでチャレンジングな旅に出た。この急速な進歩にはいくつかの重要な要因がある：第一に、LLMの登場によってコーディングの効率が劇的に向上したこと。第二に、RAGユースケースの価値に関するユーザーの迅速かつ満場一致の認識が、新しいユーザーを獲得するためのベクトル検索の主要なユースケースとなった。最後に、私たちが頼りにしているオープンソース、SaaS、クラウド・サービス・プロバイダーすべてに感謝しなければなりません。
我々は、Zilliz CloudとMilvusの忠実なユーザーに特別な感謝を捧げます。皆様からのきめ細かく忍耐強いフィードバックは、私たちに貴重なアドバイスと指針を与えてくれました。SaaSの領域であれサーバーレスの領域であれ、私たちが行ってきたことはすべて始まりに過ぎないと固く信じています。費用対効果、パフォーマンス、スケーラビリティ、使いやすさを追求することに、限界はありません。
##謝辞
Zilliz Cloudの開発には、熱心なユーザーの皆様のご支援が不可欠でした。皆様の励ましは、Zilliz Cloudを構築する私たちの旅を共有し、クラウドサービスを開発しようとしている他の人々に有益な洞察を提供する上で極めて重要でした。300人以上のMilvusコミュニティの貢献者の方々のたゆまぬ努力と、CEOのCharlesの革新的な技術的試みへの揺るぎない支援に特別な敬意を表します。
ベクター検索サービスにご興味のある方は、ぜひZilliz Cloudにサインアップしてください。新規登録者には100ドルの無料クレジットを差し上げます。
James LuanJames Luan is the VP of Engineering at Zilliz. With a master's degree in computer engineering from Cornell University, he has extensive experience as a Database Engineer at Oracle, Hedvig, and Alibaba Cloud. James played a crucial role in developing HBase, Alibaba Cloud's open-source database, and Lindorm, a self-developed NoSQL database. He is also a respected member of the Technical Advisory Committee of LF AI & Data Foundation, contributing his expertise to shaping the future of AI and data technologies.
読み続けて
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.
Vector Databases vs. In-Memory Databases
Use a vector database for AI-powered similarity search; use an in-memory database for ultra-low latency and high-throughput data access.