OpenSearch
全文検索、ログ分析、可視化を提供するオープンソースの検索 / 分析エンジン
OpenSearch とは
OpenSearch は、全文検索、ログ分析、リアルタイムダッシュボードを提供するオープンソースの検索・分析エンジンである。2021 年 1 月に Elastic が Elasticsearch と Kibana のライセンスを Apache 2.0 から Elastic License / SSPL へ変更したのを受け、AWS が最後の Apache 2.0 版である Elasticsearch 7.10.2 と Kibana 7.10.2 を起点にフォークし、同年 4 月にプロジェクトを OpenSearch として発表した。派生元が 7.10.2 のため、取り込み・検索・管理の REST API とクエリ構文には Elasticsearch 7.10 との互換性が残っている。
2026 年 8 月時点では、プロジェクトの管理は AWS 単独ではなく Linux Foundation 傘下の OpenSearch Software Foundation が担い、Elastic 側も 2024 年 8 月に Elasticsearch のライセンス選択肢へ AGPL v3 を追加している。「ライセンス変更に反発したフォーク」という 2021 年当時の対立図式のまま理解すると現状を読み違える。なお Amazon OpenSearch Service は AWS のマネージドサービスの名前であり、OpenSearch 本体 (Linux Foundation のプロジェクト) とは層が違う点に注意する。
主な用途
用途は転置インデックスが得意な領域に集まる。部分一致や表記ゆれを含む文字列の探索、関連度順の並べ替え、そして時系列に積み上がるログの絞り込みと集計がその中心である。
| 用途 | 具体例 |
|---|---|
| 全文検索 | EC サイトの商品検索、ドキュメント検索 |
| ログ分析 | CloudWatch Logs → OpenSearch → ダッシュボード |
| メトリクス可視化 | OpenSearch Dashboards (Kibana 7.10.2 からのフォーク) |
| セキュリティ分析 | SIEM (Security Information and Event Management) |
DynamoDB との使い分け
同じデータを両方に置く構成が多いのは、得意な問い合わせの形が重ならないからである。次の 4 点で性質が分かれる。
| 観点 | DynamoDB | OpenSearch |
|---|---|---|
| クエリ | キーベースの検索 | 全文検索、ファジー検索、集計 |
| データモデル | キーバリュー / ドキュメント | 転置インデックス |
| 適するケース | CRUD、トランザクション | 検索、ログ分析 |
| 読み取りの鮮度 | 既定は結果整合性・強い整合性の読み取りも選べる | 更新は refresh を待って検索対象になる |
DynamoDB は「userId = 123 の注文を取得」に適し、OpenSearch は「"TypeScript 入門" を含む記事を検索」に適している。
読み取りの鮮度は運用の落とし穴になりやすい。DynamoDB は全ての読み取り操作で結果整合性が既定で、必要な箇所だけ強い整合性の読み取りを指定する。OpenSearch は書き込んだ文書が即座に検索できるわけではなく、index.refresh_interval を明示していないインデックスでは 1 秒ごとの refresh を待って初めて検索結果に現れる (検索要求が一定時間来ないシャードでは自動 refresh が止まる)。登録直後のデータを画面に出す必要がある導線では、OpenSearch を待たずに DynamoDB から直接読む設計にする。
CDC で DynamoDB と同期
変更を取りこぼさずに OpenSearch へ流すには、アプリケーションから 2 か所へ書き込むのではなく、DynamoDB 側の変更ログを唯一の起点にする。経路は次の 4 段になる。
[DynamoDB] → [DynamoDB Streams] → [Lambda] → [OpenSearch]
DynamoDB をプライマリデータストアとし、DynamoDB Streams + Lambda で OpenSearch に同期する。検索は OpenSearch、CRUD は DynamoDB で行う。
OpenSearch Serverless
OpenSearch Serverless は、ノード数やインスタンスタイプを指定せずに使う形態だ。容量は OCU (OpenSearch Compute Unit) で測り、1 OCU は 6 GiB のメモリと対応する vCPU、共有ストレージおよび Amazon S3 への転送を含む。OCU の下限と上限はコレクショングループ単位で、取り込みと検索を別々に設定できる。下限を 0 にすればアイドル時に OCU を確保しないが、下限を大きく取ると無通信の時間帯もその分が確保され続ける。低トラフィックのサイト検索では、この下限の置き方が月額をそのまま決める。
クエリ例
検索は JSON でクエリ DSL を組み立てる。次の例は、複数フィールドを重み付きで横断する multi_match と、綴り誤りを許容する fuzzy の 2 つである。
// 全文検索
GET /products/_search
{
"query": {
"multi_match": {
"query": "TypeScript 入門",
"fields": ["title^2", "description", "tags"]
}
}
}
// ファジー検索 (タイポ許容)
{
"query": {
"fuzzy": { "title": { "value": "TypeScrpt", "fuzziness": "AUTO" } }
}
}
導入で最初に決めるべきはマッピング (フィールドの型) である。文字列を text で持てば解析されて全文検索の対象になり、keyword で持てば解析されず完全一致・集計・並べ替えに向く。既存フィールドの型は後から変えられず、変更するにはインデックスを作り直して再取り込みするしかないため、検索したい軸と集計したい軸を先に洗い出しておく。
この記事は役に立ちましたか?