OpenSearchは、2021年4月にAmazon Web Servicesが主導してElasticsearch 7.10.2系から分岐させたオープンソースの分散検索・分析エンジンです。Elastic社が2021年初頭にElasticsearchとKibanaのライセンスをApache 2.0からSSPL/Elastic Licenseへ変更したことを受け、「真にオープンな後継」をうたうコミュニティ主導プロジェクトとしてApache 2.0で公開されました。検索エンジン本体のOpenSearchとダッシュボードのOpenSearch Dashboardsからなり、ログ分析・全文検索・観測性プラットフォームのバックエンドとして広く採用されています。2024年9月にはOpenSearch ProjectがLinux Foundation配下のOpenSearch Software Foundationへ移管され、AWS単独運営からマルチベンダ体制へ移行しました。
この記事の目次
- 誕生の経緯とライセンス論争
- アーキテクチャと主要コンポーネント
- OpenSearchが選ばれる現場のユースケース
- Elasticsearchとの違いと採用判断
- まとめ
誕生の経緯とライセンス論争
OpenSearchが誕生した直接の引き金は、2021年1月14日にElastic社が公表したライセンス変更です。Elasticsearch 7.11以降のソースコードがApache 2.0からServer Side Public License（SSPL）またはElastic Licenseのデュアルライセンスに切り替わり、AWSをはじめとするマネージドサービス事業者は「事実上のクラウド事業者排除」だと反発しました。AWSは即座に最後のApache 2.0版である7.10.2系をフォークすることを表明し、4月12日にOpenSearch 1.0アルファ版を公開しました。
プロジェクトは当初AmazonGitHubオーガニゼーション配下で運営されましたが、コミュニティからは「結局はAWS主導ではないか」という指摘が続きました。そこで2024年9月にAWSは商標を含めた一切の資産をLinux Foundation傘下の独立財団OpenSearch Software Foundationへ寄贈し、SAP、Uber、Aiven、Aryn、Canonical、NetAppなど複数のスポンサーが参加するガバナンス体制へと移行しました。皮肉にもElastic社自身は2024年8月にAGPLv3を追加する形でElasticsearchを「オープンソースに戻す」と発表しており、両陣営の関係は新たな局面を迎えています。
アーキテクチャと主要コンポーネント
OpenSearchはApache LuceneをコアにJVM上で動作する分散システムで、複数のノードがクラスタを構成し、データはインデックス単位で複数のシャードに分割して配置されます。各シャードはプライマリとレプリカの組で冗長化され、ノード障害時にはレプリカが自動的に昇格してサービスを継続します。ノードの役割はクラスタマネージャ（旧master）、データ、ingest、coordinatingといった専用ロールに分離でき、大規模クラスタでは役割を明示的に切り分けるのが定石です。
派生元のElasticsearchと比べた独自機能としては、SQLプラグイン、PPL（Piped Processing Language）、観測性向け機能、Anomaly DetectionやAlerting、k-NN検索プラグインなどが標準同梱されています。特にOpenSearch 2.x系ではベクトル検索ライブラリFAISSやLucene HNSWを組み込んだk-NNプラグインがファーストクラス機能として強化され、2.9以降はNeural Searchプラグインによって埋め込みベクトル生成からハイブリッド検索までを内部で完結できるようになりました。
OpenSearchが選ばれる現場のユースケース
もっとも採用が多い領域はログ集約と観測性で、FluentdやLogstash、OpenTelemetry Collectorからデータを送り込み、OpenSearch Dashboardsで可視化する構成は事実上のデファクトと言える広がりを見せています。Amazon OpenSearch Serviceというマネージド版がAWS上で提供されていることもあり、CloudWatch LogsやVPC Flow Logsとの連携シナリオで採用される場面が多い構造です。また、SIEM用途ではWazuhやSecurity Onionといったセキュリティ製品がOpenSearchをバックエンドに採用しており、脅威検知ルールとアラート連携を標準で組み込めます。
ECや業務システムの商品検索でも、Apache Solrからの移行先として選ばれる事例が増えています。REST APIによる扱いやすさ、PainlessスクリプトでのスコアカスタマイズやFunction Scoreの柔軟性が評価されている点で、近年はNeural Search経由でLLMの埋め込みを格納し、ハイブリッド検索とRAGのバックエンドに使うパターンも一般化しました。Amazon Bedrockと組み合わせた構成例がAWS公式ブログでも継続的に紹介され、生成AI時代の検索基盤の選択肢として明確に位置付けられています。
Elasticsearchとの違いと採用判断
OpenSearchとElasticsearchはコードのルーツを共有しますが、フォークから数年を経てAPI互換性は徐々に乖離し、現在では「ほぼ互換だが完全互換ではない」状態です。Elasticsearch 8.x系ではES|QLという新クエリ言語、Elastic Searchable Snapshots、Frozen Tierといった高度な階層化ストレージが投入され、OpenSearch側はPPLやSegment Replication、リモートストア対応など独自路線の進化を続けています。
採用判断では、ライセンスの自由度を最優先するならOpenSearch、Elastic純正機能やSaaSであるElastic Cloudの一体運用を重視するならElasticsearchという棲み分けが現実的です。AWS環境であればOpenSearch Service、マルチクラウドや自前運用ではOSSのOpenSearchを直接動かす選択肢が増えており、「Lucene互換」「REST API」「Kibana系UI」という共通点を活かして将来的な相互移行を見据えた設計を取る組織も少なくありません。
まとめ
OpenSearchはライセンス対立を発端としつつも、Linux Foundation配下で独立性を確立し、観測性・ベクトル検索・SIEMといった広範な領域を支える基盤に成長しました。Elasticsearchと共通の血を引きながら独自進化を続ける現状を踏まえ、ライセンス・運用形態・必要機能の3軸で冷静に評価することが賢明な選択につながります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント