123RFはいかにしてZilliz Cloudでビジュアル検索を2億件以上のアセットにスケールしたか

123RFについて

Inmagine Groupの一員である123RF, は、世界最大級のストックコンテンツプラットフォームの一つであり、2億点を超える画像、動画、音声ファイルのライブラリで、何百万人ものクリエイティブプロフェッショナルにサービスを提供しています。検索は123RF体験の中核です。あらゆるクエリで、膨大かつ常に拡大し続けるカタログから最も関連性の高いビジュアルコンテンツを表示しなければなりません。OpenSearchのコスト上昇と不安定なパフォーマンスがその体験を脅かしたとき、123RFはZilliz Cloudに移行しました。その結果、インフラコストを50%以上削減し、クエリレイテンシを半減させ、以前の構成で悩まされていたインデックス作成の失敗を解消しました。

課題

以前、123RFは主要な検索インフラとしてOpenSearchに依存していました。このプラットフォームはもともと全文キーワード検索を中心に構築されていましたが、AI時代の到来に伴い、チームはより関連性の高い結果を提供するために、埋め込みベースのセマンティック検索の実験を開始しました。ゼロから再構築するのではなく、既存のOpenSearchクラスターにKNNプラグインを重ねる形を取りました。

その決定には、増大するコストが伴いました。最終的に、3つの相互に関連する問題によって、現状維持は不可能になりました。

• 増大するコスト： 2億以上のベクトル規模でKNN対応のOpenSearchクラスターを運用すると、月間運用費は5桁台に達し、さらに上昇し続けました。

• 不安定なパフォーマンス： 実際の本番トラフィック下でレイテンシとクエリスループットが予測不能になり、エンドユーザーの検索体験が低下しました。

• インデックス作成の不安定性： 123RFのライブラリは日々増加するため、新しいアセットを継続的にインデックス化する必要があります。OpenSearchクラスターでは、これらのインデックス作成処理中に頻繁にノード障害が発生し、継続的なDevOpsの介入が必要でした。

OpenSearchは、ベクトル類似検索専用に設計されたものではありませんでした。そのKNNプラグインは回避策を提供しましたが、それを大規模に管理することは、チームが持続的に吸収できない運用上の負担を生み出しました。

Zilliz Cloudを選んだ理由

Su-Meng Yongと彼のチームが代替手段を探し始めた際、PineconeやWeaviateなど、複数の専用ベクトルデータベースの選択肢を評価しました。意思決定を導いた基準は3つでした。

• スケール： ソリューションは、数億のベクトルをパフォーマンス低下なしに安定して処理できる必要がありました。

• コスト効率： 123RFに必要な規模で運用するとコストが高くなるため、一部の代替案は除外されました。

• 成熟度とコミュニティからの評価： Zilliz Cloudは、活発なコミュニティを持つオープンソースのMilvusベクトルデータベースを基盤としたフルマネージドサービスです。

ソリューション

123RFは、2つの補完的な検索ワークフローを支えるためにZilliz Cloudを導入しました。

• テキストから画像への検索： ユーザークエリはベクトル埋め込みに変換され、その後、ベクトル類似性を用いてインデックス化された画像ライブラリと照合され、意味的に関連性の高い結果が返されます。

• 逆画像検索： ユーザーが画像をアップロードすると、システムがその埋め込みを生成し、ライブラリ全体から視覚的に類似したアセットを検索します。

埋め込みレイヤーには、オープンソースのマルチモーダル埋め込みモデルであるCLIPが使用されており、チームはZillizのソリューションチームの支援を受けながら、2つのモデルバージョンにわたって反復改善を行いました。指定されたベンダーモデルではなく、任意の埋め込みモデルを使用できる柔軟性は、重要な利点として評価されました。

日次バッチパイプラインが、すべての新規コントリビューター投稿を埋め込みに変換し、Zilliz Cloudクラスターに取り込むことで、手動介入なしにインデックスを最新の状態に保っています。

導入時には、3つのプラットフォーム機能が特に有用であることがわかりました。

• 動的スケーリング： 予想されるクエリ負荷に基づいてクラスターをスケールアップまたはスケールダウンできるようになりました。これは、以前の OpenSearch 環境では利用できなかった機能です。

• 一括インポートジョブ： Zilliz Cloud のインポートジョブ機能により、数百万から数千万行を数時間以内にインデックス化できるようになり、OpenSearch でノード障害を引き起こしていた慢性的なインデックス作成のボトルネックを解消しました。

• Boost Ranker（カスタム機能）： 123RF は検索ランキングにおいてカスタムのビジネスロジックを必要としていました。Zilliz のエンジニアリングチームは、このユースケースに特化した Boost Ranker 機能を開発し、現在本番環境で稼働しています。

結果とメリット

>50% のコスト削減

最も即効性のある影響は財務面でした。Zilliz チームの支援により、123RF は月々の検索インフラコストを当初の支出の一部にまで削減し、50% を超える削減を実現しました。

「検索は私たちのプラットフォームの中心です。何百万人ものユーザーが適切なコンテンツを見つけるための手段だからです。Zilliz Cloud への移行は、インフラコストを大幅に削減しただけではありません。検索がビジネスの足かせになるのではなく、ビジネスとともにスケールできるという確信を、エンジニアリングチームに与えてくれました。」

— Su-Meng Yong, Engineering Team Lead, 123RF

< 50ms のレイテンシを達成

Zilliz チームとの複数回にわたる最適化の反復を経て、123RF は平均クエリレイテンシを 100ms から 30〜50ms に短縮しました。これは約 50% の改善に相当し、本番レベルのスループットと日々のトラフィック負荷を維持しながら実現されました。

ゼロダウンタイムのインデックス作成

日々のコンテンツ取り込み時に OpenSearch を悩ませていたノード脱落の問題は完全に解消されました。以前は、ライブユーザー向けの検索性能を低下させることなく、新しい画像を十分な速度でクラスターにインデックス化することができませんでした。Zilliz Cloud の一括インポート機能を使用することで、チームは現在、数百万から数千万の新規行を数時間以内にインデックス化できており、クエリ性能への影響はゼロです。日次の自動パイプラインが新たに投稿されたストックコンテンツを embeddings に変換し、クラスターに取り込むことで、手作業なしに検索インデックスを最新の状態に保っています。

運用面での自由

フルマネージドサービスである Zilliz Cloud により、DevOps チームの時間を費やしていたクラスター管理の負担が解消されました。エンジニアリングチームは、インフラ問題への対応に追われる状態から、プロダクト機能の構築へと注力を移しました。

「クラスターに関する多くの問題や、多くの自己管理に対処する必要がなくなるため、私のチームにとっても、開発者にとっても、本当に多くの時間を節約できます。」 — — Su-Meng Yong, Engineering Team Lead, 123RF

今後の展望

画像検索が完全に移行され安定したことで、123RF は動画および音声検索のワークフローも Zilliz Cloud に移行する計画です。またチームは、将来的に LangChain や LlamaIndex との統合を検討し、プラットフォームの検索機能を拡張することにも前向きです。