OpenSearchCon KOREA 2025のセッション「OpenSearch as the Unified Backend: From Log Storage to Agentic Search Platform at LINE」をまとめます。
- スピーカー
- LINEにおけるOpenSearch
- サービスのスケーリング：ログストレージからプラットフォームへ
- プラットフォームとしてのOpenSearch：スケールへの取り組み
- バックエンドシステムとしての拡大
- OpenSearchによるAgentic Searchへのロードマップ
- OpenSearchによるAgentic Searchへの展望
- まとめ
スピーカー
Sun Ro Lee氏はLINE PlusのCloud Engineerとして、OpenSearchサービスの開発と運用を担当しています。5年間にわたってLINEでOpenSearchの運用に携わってきた経験を持ち、今年5月にヨーロッパで開催されたOpenSearchカンファレンスでも発表を行いました。
LINEにおけるOpenSearch
LINEはグローバルコミュニケーションプラットフォームとして、メッセンジャーサービスを中心に事業を展開しています。メッセンジャーだけでなく、エンターテインメント、ライフスタイル、ショッピング、フィンテックなど多様な分野でサービスを提供しており、現在アジア地域で約1億9千万人の月間アクティブユーザーを抱えています。このように多様なサービスと膨大なユーザーベースを持つLINEでは、OpenSearchが重要な役割を果たしています。
LINEでのOpenSearch利用規模を先月調査したところ、現在1,280を超えるOpenSearchクラスターがサービスを支えています。これらのクラスターを稼働させるために1万を超えるノードが動いており、そこに保存されているデータ量は10PBを少し超える規模に達しています。
5月のカンファレンス時点ではクラスター数は約1,200でしたが、この6ヶ月間で80を超えるクラスターが新たに作成されました。特に最近になってOpenSearchクラスターの利用が急増していることがわかります。
サービスのスケーリング：ログストレージからプラットフォームへ
もちろん、現在のように多くのクラスターを最初から保有していたわけではありません。当初はログを保存し分析する程度の機能として使い始めましたが、時間とともに規模が拡大し、用途も多様化していきました。これから、どのようにして現在の規模まで成長させることができたのか、その経緯を紹介していきます。
最初のOpenSearch導入以前、私たちは約100台の物理サーバーでElasticsearchを運用していました。Kubernetes上にElasticsearchクラスターを構築し、主にログストレージとして活用していたのです。当時はいくつかの開発チームがログの保存や分析目的で利用する程度でしたが、時間の経過とともに規模が急速に拡大していきました。
規模の拡大に伴い、物理サーバーの管理負担だけでなく、KubernetesやElasticsearch自体の運用負荷も増大していきました。こうした様々な課題に直面する中で、私たちはOpenSearchへの移行を決断することになったのです。
OpenSearchへの移行を決断した理由は、同じような状況に置かれた方なら共感いただけるのではないでしょうか。まず重要だったのは、OpenSearchがオープンソースとして管理されており、Apache Licenseを採用している点でした。当時、コミュニティは非常に速いペースでリリースを行っており、新機能が次々と出てきていました。これにより、将来的に新しい機能が必要になった際も、コミュニティが迅速に対応してくれるだろうという期待が持てました。
さらに、セキュリティプラグインや監査ログといった機能も、当時の企業レベルで非常に重要視していた要素でした。これらの要因を総合的に検討した結果、OpenSearchへの移行を実行することになったのです。
OpenSearchへの移行に伴い、アーキテクチャも変更しました。現在はKubernetesを使用していますが、コントロールプレーンとデータプレーンの両方を使うのではなく、データプレーンにはOpenStackを採用しています。OpenStackからVM、ストレージ、ロードバランサーなどのリソースを提供してもらい、その上でOpenSearchクラスターを構築・運用しています。
このアーキテクチャでは、用途に応じて異なるタイプのノードを使い分けています。Hot Nodeは最大2.2TBまでのデータを扱い、検索とインデックス作成に特化しています。一方、Cold Nodeは最大12TBという大容量の長期ストレージを提供します。こうした構成により、現在1,280を超えるOpenSearchクラスターを複数の環境で運用することが可能になっています。
プラットフォームとしてのOpenSearch：スケールへの取り組み
アーキテクチャの変更とサービス規模の拡大に伴い、単にクラスター数を増やすだけでなく、安定性と性能の面でも様々な改善を実施してきました。
高可用性の実現
高可用性の観点では、OpenSearch自体がシャードアフィニティなどの機能を持っていますが、私たちはさらに一歩進んだ対応を行いました。OpenSearchクラスターを構築する際、自動的にプライベートクラウドにおけるすべてのAvailability Zoneにノードを均等に分散配置し、その設定値もクラスター作成時に自動で注入されるようにしています。これにより、ユーザーは特別な設定をすることなく、マルチゾーンレベルのアフィニティを利用できるようになりました。
また、現在2つのリージョンでOpenSearchサービスを提供していますが、バックアップは自動的に別のリージョンに定期的に取得される仕組みを構築しました。ユーザーはクラスターを作成するだけで、リージョン間バックアップが自動的に実行されます。これらの取り組みにより、ここ数年間、OpenSearchサービスでのデータ損失は一度も発生していません。
データティアリング戦略
データティアの面では、高性能ワークロードへの対応を強化しました。2000〜3000 rps以上の検索クエリや、秒間数GBのインデックス処理が必要なクラスターに対して、NVMe over Fabric技術を活用した高性能ノードを提供しています。同時に、Cold Tierというデータティアポリシーを導入し、アクセス頻度の低いデータを低コストで数百TB以上保存できるようにしました。
スケールへの対応
スケールの観点では、OpenSearchのSearchable Snapshot機能を活用しています。これはデータをOpenSearchクラスター外のリモートストレージにバックアップしながら、そのデータを直接検索可能にする機能です。ペタバイト級のデータや1年以上の長期保管が必要なケースに対して、この機能の管理を自動化しました。データをインデックスすると、一定期間経過後に自動的にSearchable Snapshotに変換され、さらに長期間経過後には自動削除される仕組みを構築しています。これにより、ユーザーは別途パイプラインを構築することなく、OpenSearchだけで長期データ保管のニーズに対応できるようになりました。
性能面でも継続的な改善を進めています。数世代にわたって機器の更新とチューニングを重ね、OpenSearchに最適化されたノードを作り上げてきました。
第1世代から第2世代への移行では、ハードウェアのアップグレードにより性能面で大きな改善を達成しました。第2世代ではより高性能な機器を採用していましたが、第3世代では興味深いアプローチを取りました。第3世代では標準的な機器を使用しながら、OpenSearchベンチマークを通じて最適なカーネルチューニング値を見つけ出すことで、高価な機器を使わずとも第2世代を上回る性能を実現することができたのです。
実際のベンチマーク結果を見ると、インデックス性能では第3世代が最も優れており、検索性能においても第3世代が第2世代より大幅に改善されています。これらの活動はすべて、増え続けるOpenSearchユーザーのニーズに応え、より安定したプラットフォームを提供するために実施してきたものです。
バックエンドシステムとしての拡大
こうした安定性と性能の改善を積み重ねた結果、現在ではLINE内の様々な大規模サービスがOpenSearchをバックエンドとして採用するようになりました。LINEにおけるDatachainやモニタリングサービス、Log as a Service、Unified log storeなど、大量のデータを扱うサービスがOpenSearchを基盤として動いています。
これらの大型サービスがOpenSearchを採用しているという事実は、私たちのOpenSearchサービスが安定した性能とサービス品質を提供できていることの証明でもあります。単なるログストレージから始まったOpenSearchは、今やLINEの様々なサービスを支える重要なプラットフォームへと成長したのです。
過去5年間のサービス規模の成長を振り返ると、2020年には約300個のOpenSearchクラスターから始まりました。2021年にOpenSearchサービスを正式にリリースし、その後着実に成長を続けてきました。この間、新しいリージョンのオープンや大規模なマイグレーションプロジェクトを実施し、特に2024年のDatachainマイグレーションプロジェクトは大きな転機となりました。
そして2025年現在、新しい統合クラウド環境への移行を経て、1,280を超えるOpenSearchクラスターを運用するまでに成長しています。この急速な成長は、OpenSearchが単なるログストレージツールから、LINEの様々なサービスを支える基盤プラットフォームとして認知され、採用が進んでいることを示しています。
OpenSearchによるAgentic Searchへのロードマップ
OpenSearchが検索とログ保存の分野でLINEの様々なサービスを支えている中、私たちは次の計画としてAIエージェントへの対応を進めています。これは私たちがAIエージェントそのものを開発するということではなく、AIエージェントをサポートする基盤を提供するという意味です。
現在、LINE全体でAIエージェントへの関心が非常に高まっています。実際、多くの開発チームが新たにOpenSearchクラスターを立ち上げ、それをAIエージェントと連携させてサービスを構築しようという試みが活発に行われています。最近の6ヶ月間で80を超える新規クラスターが作成されたのも、こうしたAI関連の取り組みが背景にあります。
OpenSearchがAI関連の様々な機能を提供していることが、この動きを後押ししています。これから、私たちがどのようにしてOpenSearchをAIエージェントの中核プラットフォームとして発展させようとしているか、その戦略について詳しく説明していきます。
OpenSearchによるAgentic Searchへの展望
OpenSearchがAI関連で提供している機能の豊富さは、リリース履歴を見れば一目瞭然です。OpenSearch 2.10から始まったハイブリッド検索を皮切りに、マルチモーダル検索、スパースニューラル検索、そしてconversational searchなど、次々と新機能が追加されてきました。
2.13ではベクトル量子化やLLMガードレール、2.14ではMLモデルとingestの統合やセマンティックキャッシュ、KNN検索フィルタリングなどが導入されました。さらに2.17ではディスク最適化ベクトル検索、3.0では待望のGPU加速機能、ハイブリッド検索のパフォーマンス改善、そしてagentic searchやネイティブMCP対応が実現しています。
最新の3.3では、Chat UI for DashboardsやMCP向けのstreamable HTTPなど、より実用的な機能が追加されています。OpenSearchのリリースサイクルが速いこともあり、新機能が非常に速いペースで出てきています。実際、私たちはまだ3.3バージョンを内部でサポートしていないのですが、ユーザーからはハイブリッド検索などの新機能をいつ使えるようになるのかという問い合わせを多数いただいています。このことからも、AI機能への期待の高さがうかがえます。
こうした豊富なAI機能を、単に提供するだけでなく、より使いやすい形でユーザーに届けることが私たちの目標です。
すでに完了したプロジェクトとして、2025年下半期にOpenSearch 2.19のサポートを実現しました。現在進行中のプロジェクトとしては、2025年下半期にML embeddingを含むVector Search Serviceのリリースを予定しています。これにより、ユーザーは複雑な設定なしにベクトル検索機能を利用できるようになります。また、Agentic Search機能を含むOpenSearch 3.3のサポートも同時期に提供予定です。
2026年上半期に向けては、さらに野心的な計画を立てています。Rerankingを含むHybrid Searchのサポート、ML runnerとingestパイプラインの統合、そしてマルチモーダル検索の実現を目指しています。これらはすべてOpenSearch AIプロジェクトの一環として進めています。さらに、量子化を含むGPUサポートも計画しており、これによりベクトル検索のパフォーマンスが大幅に向上することが期待されます。
私たちの目標は、OpenSearchの最新バージョンを提供するだけでなく、AI関連機能をより簡単に、より便利に使えるようにすることです。AIエージェントに特化した検索サービスを構築し、LINE内の開発チームがAI機能を活用しやすい環境を整えていきます。
私たちがOpenSearchのAI機能を提供するにあたって、4つの重点領域に注力しています。
まず、Agentic search機能の自動化です。OpenSearchに慣れた方なら簡単にできるかもしれませんが、ベクトル検索パイプラインの構築やモデルの登録・統合といった複雑なデプロイメントワークフローには、多くの作業が必要です。モデルのデプロイ、管理、そしてサービス規模の拡大に伴うスケーリングなど、様々な運用作業が発生します。私たちはこれらの作業をクラウドレベルで統合し、モデルembeddingとパイプラインへの接続まで、便利なインターフェースと自動化機能で提供する計画です。
次に、AIデータ管理の自動化も進めています。クラウドの機械学習サービスやストレージサービスと統合することで、カスタムモデルの登録やマルチモーダル検索パイプラインをサポートします。将来的には、ユーザーがクラウド内でAIモデルを登録するだけで、デプロイ、管理、ingestパイプラインへの組み込みまですべて自動化される仕組みを目指しています。
検索パフォーマンスとコストの改善も重要な課題です。特にベクトル検索やハイブリッド検索で十分な性能が出るかという問い合わせを多く受けています。GPUノードのサポートと最新のOpenSearchアップグレードサポートを通じて、インフラレベルでコスト、パフォーマンス、運用の利便性を向上させていきます。
最後に、データセキュリティとアクセス制御の強化です。AIエージェントとデータが連携する際には、データ保護とアクセス制御が極めて重要になります。OpenSearchのセキュリティプラグインとLINEクラウドのアクセス制御機能を統合し、ACLやIAMなどを活用してベクトル検索パイプライン全体にわたる集中管理を実現します。ユーザーがOpenSearchで直接権限管理を行わなくても、クラウドレベルの統合された権限管理を通じて、強力なAI機能を安全に利用できる環境を提供することが目標です。
まとめ
私は数年にわたってOpenSearchに携わってきましたが、その経験から、OpenSearchがより多くの場所で活用されることを心から願っています。特にLINE内でも多くの開発チームがOpenSearchを採用し続けています。これは単にOpenSearchが多様な機能を提供し、安定しているというだけではありません。OpenSearchが真の意味で中核プラットフォームとして活用できるほど、多様で安定した性能を発揮していることの証明だと考えています。
OpenSearchはログストレージから始まり、検索プラットフォームへと進化し、そして今、AIエージェントのための基盤へと変貌を遂げようとしています。今後もOpenSearchコミュニティから新しい機能が生まれ、私たちがそれらを活用できることを楽しみにしています。LINEは引き続きOpenSearchとともに成長し、より良いサービスを提供していきます。
