初めまして。
AWS上で大規模な会員向けアプリケーションの構築・運用に携わっています。
本記事では、OpenSearchとSageMakerを組み合わせたセマンティック検索基盤の構築事例を紹介します。
既存のOpenSearchにカスタムAIモデルを連携する構成について、検討の過程と構成例を整理しています。
また、当初のデプロイ時に直面した課題や、最終的にSageMakerを採用するに至った技術選定の背景についても触れています。
2. 現状の検索構成
先日、アプリケーション開発チームより、次のような相談を受けました。
「クーポン検索機能を高度化するカスタムAIモデル（DistilUSE）を作ったので、こちらをAWS上にデプロイして既存のOpenSearchと連携してほしい」
現状の検索機能は、OpenSearchを中心とした比較的シンプルな構成になっていました。
アプリケーションユーザーからのクーポン検索リクエストは、まず ECS上で稼働しているアプリケーション（コンテンツ取得API） に送信されます。このAPIが検索条件を受け取り、OpenSearch Serviceの検索APIを呼び出すことで検索処理を実行します。
OpenSearch側ではクーポン情報をインデックスとして保持しており、検索処理は主に キーワード検索（完全一致・部分一致） によって行われていました。検索結果はAPIを経由してアプリケーションに返却され、最終的にユーザー画面へ表示されます。
また、OpenSearch ServiceおよびECSは同一VPC内に配置されており、通信はALBを介して行われる構成です。
この構成では、検索処理の責務はすべてOpenSearchが担っており、検索クエリの解釈や意味的な理解といった処理は行っていない状態でした。
図1：ECS上のAPIからOpenSearchを直接呼び出し、検索結果を返す構成
3.構成検討の過程
アプリケーションチームから依頼を受け、まずは既存の構成を大きく変えずにカスタムAIモデルを組み込めないかを検討しました。
その選択肢の一つとして、OpenSearchが提供する ML Commons 機能の利用を検討しました。
ML Commonsでは、S3に配置したモデルをOpenSearch側でロードし、検索処理の中で推論を実行する仕組みが提供されています。
この仕組みを利用すれば、推論用のサーバーを新たに用意する必要がなく、アーキテクチャを比較的シンプルに保てると考えました。
そこで、アプリケーション開発チームから受領したカスタムAIモデル（DistilUSE / tar.gz） をS3に配置し、OpenSearch Serviceからモデルのロードを試みました。
しかし、結果としてこの構成は実現できませんでした。
今回受領したカスタムモデルは、OpenSearch Service（マネージド環境）におけるML Commonsの制約により、そのまま有効化することができない仕様だったからです。
このため、OpenSearch内部でモデルを実行する構成は断念し、別のアーキテクチャを検討することにしました。
図2：S3に配置したモデルをOpenSearch内部で実行する構成（検討時）
ML Commons を利用できなかった理由
ML Commons の利用を見送った理由は、主に 実行環境とマネージドサービスとしての制約 にあります。
受領したカスタムAIモデルは Python（PyTorch）ベース で構築されていましたが、OpenSearch Service の ML Commons は Javaベースの実行環境 を前提としています。そのため、モデルをそのまま実行することが難しく、形式変換などの追加対応が必要となりました。
これらの対応は工数や運用面の負荷が大きく、今回は現実的ではないと判断しました。
また、OpenSearch Service はマネージドサービスであるため、外部から持ち込んだカスタムモデルを柔軟に実行すること自体に制約があります。
以上の検討を通じて、検索エンジンに計算処理を持たせる構成は適切ではないと判断し、計算処理は専用の実行基盤に切り出す方針としました。
次章では、この方針を踏まえて採用したSageMakerを用いた構成について説明します。
4.最終アーキテクチャ
検討の結果、計算処理は計算専用のリソースに切り出すべきと判断し、カスタムAIモデルの実行基盤として Amazon SageMaker を採用しました。
最終的なアーキテクチャを図3に示します。
本構成では、検索機能そのものは引き続きOpenSearchが担い、検索クエリやドキュメントのベクトル化といった 計算負荷の高い処理をSageMakerの推論エンドポイントに委譲しています。
これにより、OpenSearchに過度な処理を持たせることなく、役割を明確に分離した構成とすることができました。
図3：SageMaker推論エンドポイントと連携した最終構成
5. SageMaker採用の背景
ここは今回の構築において、最も検討に時間を要したポイントです。
「Amazon Bedrock（サーバーレス）を利用すれば、より簡単に実装できたのではないか」 という選択肢もありましたが、最終的には SageMakerを用いた自前構築が最適と判断しました。
理由は大きく2点あります。
理由1：カスタムモデルの利用要件
Amazon Bedrockは、あらかじめ用意された基盤モデルをAPI経由で利用できるサービスです。 一方で、利用できるモデルはBedrock側で提供されているものに限定されます。今回のケースでは、アプリケーション開発チームより特定のカスタムモデル（DistilUSE）を利用したい という明確な要件がありました。
この要件を満たすには、モデルや実行環境を自由に構成できるSageMakerを採用する必要がありました。
理由2：スケールとコストの観点
今回対象としたシステムは、全国規模のECサイトであり、検索リクエストが高頻度かつ継続的に発生することが想定されます。
BedrockのようなAPIベースのサービスは従量課金であるため、
- リクエスト数の増加に伴うコストの増大
- レート制限（スロットリング）による影響
といった点が懸念されました。
一方、SageMakerの推論エンドポイントは、インスタンスをプロビジョニングすることで、一定のコストで安定した処理能力を確保できます。大規模なトラフィックを前提とした場合、コストの見通しやすさと安定性の面でSageMakerの方が適していると判断しました。
6. 構築時のポイント
構築にあたっては、以下の点を重視しました。
-
役割の分離
検索処理はOpenSearch、ベクトル化などの計算処理はSageMakerとし、各コンポーネントの責務を明確に分離しました。 -
閉域網でのセキュリティ確保
SageMakerの推論エンドポイントはVPC内に配置し、OpenSearchとはVPCエンドポイント経由で通信させています。
データがインターネットを経由しない構成としました。 -
アプリケーションへの透過性
OpenSearchのIngestionパイプラインを活用することで、アプリケーション（ECS）側は裏でSageMakerが動作していることを意識せず、従来通り検索リクエストを送信するだけで利用可能としています。
なお、AIモデルのデプロイにはAWS公式のDeep Learning Containerを使用し、アプリケーションチームから受領した model.tar.gz（モデル本体・設定・辞書）をそのまま推論環境として利用しています。
7. まとめ
本構成により、コストや運用リスクを抑えつつ、柔軟な検索機能を実現できるアーキテクチャを構築することができました。
また、補足として、S3に配置したシノニム辞書をOpenSearchと連携させることで、検索精度の底上げも行っています。
今回の取り組みを通じて、AI機能の実装においては用途や規模に応じたサービスの使い分けが重要であると改めて感じました。
-
Amazon Bedrock
手軽に始めたい場合や、小〜中規模でモデルに強い制約がないケース -
Amazon SageMaker
特定のモデルを利用したい場合や、大規模アクセスを前提とするケース
単に動作する仕組みを作るだけでなく、将来的なスケールや運用まで見据えた設計を行うことの重要性を学ぶ良い機会となりました。