SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

検索エンジンとしての「Amazon OpenSearch Serverless」の実用性を探る

2023.10.5

こんにちは、NRIデジタルの島です。

弊社では現在「情報検索システム」 をAWSクラウド上で開発中です。この検索システムはルールベースのみではなく、AI技術を活用した「意味的な検索（文脈の自動解釈）」 も可能とする検索システムです（以下 AI情報検索システム と呼びます）。簡単な構成図は以下となります。

このAI情報検索システムの実現には、当然これまで幾多の研究を積み重ねて実装した「AIアルゴリズム」 が必要ですが、それと同じくらい必要なもう一つの技術要素は、高性能で多様な検索機能を搭載した「検索エンジン※」 です。本システムの設計において最も頭を悩ませたのは、「検索エンジンをどのように構成するか」でした。

※ ここでの「検索エンジン」とはGoogleやYahoo等の検索エンジンではなく、全文検索機能を提供するソフトウェアプロダクトやサービスのこと を指します。

検索エンジンの選択

検索エンジンというカテゴリにおいては、 多くのソフトウェアプロダクト が存在しますが、本システムの検索要件から以下「Elasticseach」 を採用すること自体はすぐに決まりました。

Elasticserch
Elasticsearch | オフィシャルの分散型検索/分析エンジン | Elastic
※NRIのOpenStandiaにも紹介されていますので、是非ご参照ください
強力なデータ検索・分析で業務を効率化「Elasticsearch」｜OSSサポートのOpenStandia™【NRI】 /


しかしながら、Elasticsearchの提供形態には以下の通り複数の候補があり、「どれを選択すべきか？」に相当な時間と労力を費やしました。

① Elasticsearch（Self Hosted on EC2）

高機能で高性能な検索・分析エンジンとして代表的なソフトウェアプロダクトである「Elastisearch」を「Amazon Elastic Compute Cloud （以下 EC2)」上に自前で構築し、運用管理していく構成

EC2
Amazon EC2（安全でスケーラブルなクラウド上の仮想サーバー）| AWS

② Elasticsearch（Self Hosted on EKS）

Elastisearchを「Amazon Elastic Kubernetes Service（以下 EKS)」に自前で構築し、運用管理していく構成
※Kubernetes Operator Frameworkをベースにして開発された「Elastic Cloud on Kubernetes（以下 ECK）」を使用することで、運用の自動化（オートスケーリングやセルフヒーリング、バックアップ/リストアなど）が可能

EKS

ECK

Kubernetes Operator Framework

③ Elastic Cloud

ElasticsearchのSaaSサービスで、構築、運用管理は全てElastic社が実施する。

Elastic Cloud

④ Amazon OpenSearch Service（以下OpenSearch）

上記Elasticsearchをベースにした全文検索エンジンサービス
OpenSearch とは? – オープンソース検索エンジンの説明 – AWS
※詳細は省きますが、2021年にOSSベースだったElasticsearchをForkして、独自開発していくことを発表しています
「Amazon Elasticsearch Service」の名称が「Amazon OpenSearch Service」に変更。ElasticsearchからフォークしたOpenSearchも採用

上記各構成パターンの特徴、メリットデメリットを整理しながら検討を進めていきましたが、どれも一長一短で、決定打がないのが実情でした。各パターンの主なデメリット を記載すると以下の通りでした。

① Elasticsearch（Self Hosted on EC2）
運用管理（バックアップ/リストアやノードのスケーリングなど）の仕組み構築も実際の運用も全て自前で行う必要がある為、コストも運用リスクも大。

② Elasticsearch（Self Hosted on EKS）
世の中のKubernetes Operatorの利用実績がまだあまり多くなく、また学習コストも大。

③ Elastic Cloud
EOLを迎えたバージョンは強制アップデートされるため、アップデートを前提としたサービス影響確認や対応に関する運用が強制される（塩漬けが出来ない）。また、費用がかなり高額。

④ OpenSearch
Analyzerなど3rd Partyのプラグインの導入ができない。また、運用観点で以下の懸念点がある。
・自動スケール不可
・手動でクラスタ構成変更（ノード追加やスケールアップなど）に長時間要する場合がある
・各種設定変更中にMasterノードの負荷があがり、検索の遅延が発生する場合がある

※Amazon OpenSearch Service での設定変更 より抜粋

クラスターの専用マスターノードに負担がかかる可能性があり、管理するノードが突然増える可能性があります。また、OpenSearch Service が古いクラスターから新しいクラスターにデータをコピーするため、検索とインデックス作成の遅延が増加する可能性があります。

本記事においては、どの構成を採用したかは伏せますが、引き続きより良い他の選択肢を模索中の段階です。そんな中、OpenSearchがServerless対応 しました。

公式ページ

ブログ

過日「Amazon Aurora Serverless v2（以下 Aurora Serverless v2）」 を検証し、そのスケーリング能力の高さを以下ブログに投稿させていただいた経緯もあり、新たな検索エンジンの候補として非常に高い期待を持ちました。
Amazon Aurora Serverless V2のスケーリング能力を試してみる

前述した構築パターンに選択肢が一つ加わったことになりますので、AI情報検索のユースケースにおける検索エンジンとして「Amazon OpenSearch Serverless（以下OpenSearch Serverless）」 が利用可能か、その実用性について、主に「機能性」「スケーリング性能」「コスト」 の3点について検証していきたいと思います。

コンセプトとアーキテクチャ

検証の前にコンセプト及びアーキテクチャについて、前述したブログを参考に簡単に触れておきます。

（再掲）Amazon OpenSearch Serverless が一般利用可能になりました | Amazon Web Services

コンセプト

OpenSearch Serverlessのコンセプトは、「よりシンプルでありながら、不規則で予測不可能なリクエストを安定したパフォーマンスを発揮させるように、利用者から以下のチューニング要素を取り除き、ビジネスアプリケーションに集中させる」ことです。

  • インスタンスの選択とプロビジョニング
  • シャードとインデックスのサイズ管理
  • サイジングと運用を目的としたインデックスとデータの管理
  • ワークロードの需要を満たすための継続的な設定の監視とチューニング
  • システム障害やリソースの閾値違反に備えたプランニング
  • セキュリティアップデートとサービスソフトウェアアップデート


結果、実現すべき目標は以下となります。

  • シンプルかつセキュア
  • オートスケーリング、耐障害性、耐久性
  • コスト効率
  • エコシステムの統合


アーキテクチャ

上記目標を実現する為に採用しているアーキテクチャが以下となります。


上記ブログより抜粋

前述した「Aurora Serverless v2」や「Amazon RedShift Serverless」 のサーバレースアーキテクチャと同様、ストレージとコンピュートリソースを分離することで、ワークロードの需要に応じて各レイヤーを独立してスケール可能です。また、インデックス用とクエリ検索用のコンピュートノードも分離されている為、競合することなく独立してスケール可能です。なお、スケールの単位は「OpenSearch Compute Units (以下 OCU)」 単位となっており、1OCUは「6 GiB のメモリと対応する仮想 CPU (vCPU)、および Amazon S3 へのデータ転送を組み合わせたもの」 となります。
Amazon OpenSearch Serverless でのキャパシティ制限の管理 – Amazon OpenSearch Service

OCU数について、デフォルトで最小OCU数が定義されており、クエリ検索用、インデックス用でそれぞれ2OCU、計4OCUとなります。

環境構築

検証用のOpenSearch Serverless環境を構築します。手順は非常に簡単で、管理コンソールから構築する場合は基本的に以下の開発者ガイドやチュートリアルの手順のみです。

開発者ガイド

チュートリアル
以下ページに記載の通り、2023 年 5 月 10 日以降、OpenSearch Dashboardへのアクセスには「aoss:DashboardsAccessAll」ポリシーが、APIアクセスには「aoss:APIAccessAll」ポリシーが必要な為注意してください。 Identity and Access Management for Amazon OpenSearch Serverless – Amazon OpenSearch Service

機能検証

では、まずは機能的な観点での確認です。AIによる意味的検索というユースケースを考えると、テキストベースのキーワード検索のみではなく、より高度な検索が必要です。本AI情報検索システムにおいては、機械学習モデルでベクトル化されたフィールドの類似度ベクトル検索（以下 k 最近傍 (k-NN) 検索） が必要です。

「k 最近傍 (k-NN) 検索」はElasticSearchや通常のOpenSearchでは使用可能な機能です。
Amazon OpenSearch Service での K 最近傍 (k-NN) 検索 – Amazon OpenSearch Service


起動したOpenSearch Dashboardより試してみます。


残念ながら、上記の通りk-NNベースのインデックスの作成ができないようです。念の為以下ページを参考に導入されているプラグインを確認してみます。
Amazon OpenSearch Service のエンジンバージョンに応じたプラグイン – Amazon OpenSearch Service

結果、OpenSearch Serverlessでは、そもそもAPIエンドポイント経由での導入済みプラグインの確認は出来ないようで、ドキュメントベースで確認するしかない ようです。また、利用者が個別に3rd Partyのプラグインを追加導入するなどはできない ようです。

導入済みプラグイン
Supported operations and plugins in Amazon OpenSearch Serverless – Amazon OpenSearch Service

上記ドキュメントよりOpenSearch Serverlessにはk-NNのプラグインが導入されておらず、「k 最近傍 (k-NN) 検索」には対応していないようです。また、利用者側でのプラグイン追加も不可の為、検証時点ではやはり使用できないようです（※）。また、本システムでは形態素解析処理も必要ですが、通常のOpenSearchと同様、日本語対応のAnalyzerは「Kuromoji 」しか導入されておらず、他のAnalyzer（Sudachi など）の利用もできなそうです。

※ 検証時点では使用できませんでしたが、執筆時点では使用可能になっているようです。
Working with vector search collections – Amazon OpenSearch Service
ただ、常時検索精度の改善が必要なAI情報検索のユースケースにおいては、必要なプラグインを自由に追加できないことはかなりのデメリットだと考えています。

スケーリング性能

次にスケーリングの検証をしていきます。AI情報検索システムは、その特性上重い処理が多く、また想定トラフィックも多いシステムとなっており、検索エンジン側にも相応のスループットが求められます。ここでは、多重でクエリ検索リクエストを送信することで負荷をかけ、どれだけOCUが迅速にスケールし、それらのリクエストへの影響（レスポンスタイムやエラー）を最小限にとどめられるのか を確認します。

① インデックスデータの登録
まず検索対象のインデックスを作成します。以下ブログのサンプルデータ「movies-index」を登録します。
Build a search application with Amazon OpenSearch Serverless | Amazon Web Services


② Curlスクリプトの準備
以下のようなスクリプトを準備します。常時固定は現実味がない為、「30-120リクエスト/秒」の間でランダムにリクエストします。検索クエリはmovies-indexに対する全件検索とします。なお、OpenSearch Serverlessへのアクセスには以下の「Signature V4 署名」 が必要です。
他のクライアントを使用した HTTP リクエストの署名

curl-stress.sh 

#!/bin/sh

ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/`
CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}`
AWS_ACCESS_KEY_ID=`echo $CRED | jq -r ".AccessKeyId"`
AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r ".SecretAccessKey"`
AWS_SESSION_TOKEN=`echo $CRED | jq -r ".Token"`
REGION="ap-northeast-1"
SERVICE="aoss"

URL=https://$1.ap-northeast-1.aoss.amazonaws.com/movies-index/_search
RESULT_FILE=result.txt

rm ${RESULT_FILE}

for i in $(seq $2);do
  tps=`shuf -i 30-120 -n 1`
  echo "current tps-> ${tps}"
  for j in $(seq ${tps});do
    curl  ${URL} -H "X-Amz-Security-Token: ${AWS_SESSION_TOKEN}" --aws-sigv4 "aws:amz:${REGION}:${SERVICE}" --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" -o /dev/null -s -w "code: %{http_code}, speed: %{time_total}\n" >> ${RESULT_FILE} &done
  sleep 1
done
通常のOpenSearchに対しては、Elasticsearchの「 Rally 」 というベンチマークツールをForkした「 OpenSearch Benchmark 」 というツールが使用可能ですが、検証時点ではOpenSearch Serverlessでは使用不可のようです。理由は以下Issueの通り、OpenSearch ServerlessへのAPIコールで必要な「Signature V4 署名」に未対応 の為です。

SigV4 support in OpenSearch Benchmark · Issue #158 · opensearch-project/opensearch-benchmark

③ Curlスクリプトの実行
このスクリプト数時間実行します。 

./curl-stress.sh ${コレクションID} 10800

結果は以下の通りです。


Amazon CloudWatch Dashboard

上段：OCU数（平均）
下段（左）：平均検索クエリ数（平均）
下段（中）：検索クエリに対するレイテンシ（平均）
下段（右）：検索クエリに対するエラー数

平均OCU数が「3」で、デフォルトの「2」からあまり変動していません。その結果、検索エラーが発生しており、平均レイテンシも悪いです。

ダッシュボードからは読み取れませんが、多くは「タイムアウトエラー」で、その影響でレイテンシが悪化しているという見解です。なお、本検索クエリの通常のレイテンシは100-200ms程度です。

残念ながら、前述した「Aurora Serverless v2」のような爆速なスケールは期待できないようです。また、スケーリング検証を通して以下の運用上の課題を検知しましたので共有しておきます。


① OCU数の統計収集間隔が長い
以下の通り、OCU数が「Amazon CloudWatch Metrics」に反映されるタイミングが非常に遅いです。

e.g. 16時時点で、まだ15時台のOCU数が見えない


公式ドキュメントによると、OCU数メトリクスの統計頻度が「1時間」 のようです。
Amazon CloudWatch を使用した OpenSearch Serverless のモニタリング – Amazon OpenSearch Service

OCU数の遷移がリアルタイムに参照できないので、パフォーマンスの調査などが大変しにくいです。


② OCU最小数が設定できない
OCUの最大数は設定可能ですが、最小数は設定できず 、検索、インデックスそれぞれ「2」固定です。よって、仮に今回の検証のようにエラーが散発した際にも、一時的に増やして凌いだり、最初から多めにしたりなどの対処もできません。「自前でのチューニングが不可能」 となりますので、運用上の大きな課題になりそうです。

③ Amazon CloudWatch Logsに未対応
検証時点で、OpenSearch Serverlessはログ出力未対応 です。よって、何か問題が発生した際には、アクセス元のクライアント起点で原因を調査するか、AWSサポートに問い合わせるしかありません。これも運用上の大きな課題になりそうです。

コスト

最後にコストです。OpenSearch及びOpenSearch Serverlessのコストは以下ページに記載されております。
Open-Source Search Engine – Amazon OpenSearch Service の料金 – Amazon Web Services

OpenSearch Serverlessのコストを整理すると以下のようになります。
※執筆時点での東京リージョンのコストです

  • インデックス作成
    $0.334 per OCU per hour
  • 検索
    $0.334 per OCU per hour
  • マネージドストレージ
    $0.026 per GB / month
  • OpenSearch Dashboards
    無料


単価はかなり高く、OCUの最小値の4OCU（インデックス 2OCU + 検索 2OCU）で試算しても、「20万円/月」を超える金額となります。全く同スペックにはできませんので正確な比較はできませんが、近しいスペックで試算すると、通常のOpenSearchの方がだいぶ安いです。

さいごに

「機能、スケーリング性能、コスト」について検証してきましたが、残念ながら3点とも検証時点では期待したような結果とは言えず、通常のOpenSearchと比較して見劣りする内容でした。また、記事内で述べた通り、実際の運用を考えるとOCUの設定やモニタリングにも課題が多く存在するように思います。この結果から、AI情報検索のユースケースによらず、多くのユースケースでまだOpenSearch Serverlessを採用するのは時期尚早というのが筆者の見解です。
今回は残念な結果でしたが、可用性や運用性、コスト効率などを考慮すると、サーバレス化は非常にニーズが高いと思っています。まだGA後間もないサービスですので、本検証の結果や課題等は可能な限りAWSサポートを通じてフィードバックさせていただき、今後の改善に積極的に協力していきたいと思っております。