リバナレテックブログPublicationへの投稿
🗒️

OpenSearch Serverless から Managed へ移行した話 ~日本語検索とカスタムアナライザーの壁があった件について~

ToMY F.
に公開
AWS
Amplify
Serverless
検索
OpenSearch
idea

はじめに

AWS Amplify Gen2 で検索機能を実装する際、最初は管理の手間が少ない OpenSearch Serverless を採用しました。
「サーバーレスならインフラ管理不要だし、モダンでいいよね」——そんな軽い気持ちでした。

しかし結論から言うと、日本語検索の要件が出てきた時点で Serverless は詰みました。
カスタムアナライザー（Kuromoji 等）が使えないという致命的な制約により、開発途中で Managed (Provisioned) OpenSearch Service への移行を余儀なくされたのです。

本記事は、Serverless を選んで後悔し、Managed へ移行するまでの経験を共有するものです。
同じ轍を踏まないよう、技術選定の参考にしていただければ幸いです。

Serverless を選んだ理由（当初）

プロジェクト開始時、以下の理由から Serverless が最適だと判断しました。
今思えば、日本語検索の要件を軽視していたのが敗因です。

  1. 運用負荷ゼロ: インスタンス管理、パッチ適用、スケーリング設定が不要
  2. モダンな構成: サーバーレスアーキテクチャで将来的なスケーラビリティを確保したかった
  3. コスト: 待機コストがかからない（※実際には最低 OCU のコストがかかりますが、小規模なら安いと想定）

直面した壁：日本語検索ができない

開発が進み、日本語の検索機能を実装しようとした段階で致命的な問題が発覚しました。

1. カスタムアナライザーが使えない

日本語検索の精度を上げるには、形態素解析エンジン（Kuromoji など）を使ったカスタムアナライザーの設定が必須です。
しかし、OpenSearch Serverless は（執筆時点では）サードパーティプラグインやカスタムプラグインをサポートしていません。

標準の standard アナライザーや、一部の組み込みアナライザーは使えますが、辞書のカスタマイズや詳細なトークナイズ設定（kuromoji_tokenizer の詳細設定など）を行おうとすると、無慈悲にもエラーが返ってきました。

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "Custom analyzers are not supported in Serverless"
      }
    ]
  }
}

このエラーを見た瞬間、血の気が引きました。
日本語検索をまともにやりたいなら、Serverless は選択肢から外れる——これが現実でした。

2. インデックステンプレートの制限

Managed 版では当たり前にできる「インデックステンプレート API を叩いて設定を流し込む」作業も、Serverless では権限周りや API の仕様が微妙に異なり、CDK からの自動化に苦労しました。
「サーバーレスで楽になるはず」だったのに、むしろハマりどころが増えている始末です。

Managed 版への移行を決断

これらの制約から、泣く泣く Managed 版（t3.small.search 等のインスタンスタイプを指定する従来型）への移行を決断しました。
開発途中でのインフラ構成変更は、データの再インデックスや CDK コードの大幅な書き換えを伴い、決して軽い作業ではありませんでした。

Managed 版で実現できたこと

移行の苦労はありましたが、Managed 版にしたことで以下が実現できました。

  1. Kuromoji のフル活用: kuromoji_tokenizer, kuromoji_part_of_speech, ja_stop などを組み合わせた高度な日本語アナライザーを定義できた
  2. 辞書管理: ユーザー辞書や同義語辞書のアップロードが可能に
  3. コストの予測可能性: リザーブドインスタンスの購入などで、長期的なコストをコントロールしやすくなった

Managed 版のデメリット

もちろん、以下の運用負荷は増えました。これは受け入れるしかありません。

  • 起動時間: ドメイン作成に15〜20分かかる（Serverless は数分）
  • スケーリング: ディスク容量やノード数を監視し、手動（または Auto Scaling 設定）で拡張する必要がある
  • バージョン管理: OpenSearch のバージョンアップ計画が必要

⚠️ 注意: 開発環境と本番環境の不一致

コスト削減のために「開発環境は Serverless、本番環境は Managed」という構成を検討するかもしれません。
しかし、本記事で触れたように「使える機能（アナライザー等）」や「API の挙動」に差異があるため、この構成は非推奨です。
開発環境も本番と同じ Managed (t3.small.search x 1 など) で構築し、環境差異によるデプロイエラーを防ぐことを強くお勧めします。

比較まとめ：どちらを選ぶべきか？

もちろん、Serverless にも「インフラ管理が不要」「自動スケーリング」という強力なメリットがあります。
ログ分析用途や、単純なキーワード検索、あるいは英語のみの検索であれば、Serverless は非常に有力な選択肢です。

しかし、日本語全文検索を含む要件では、Managed 版の機能性が必要になるケースが多いです。

パイプライン（OSIS）の考慮事項

Managed 版を採用する場合、データの取り込み経路（Ingestion）も考慮する必要があります。
Serverless では統合されたインジェスチョン機能が使いやすい場合がありますが、Managed 版でも OpenSearch Ingestion (OSIS) を組み合わせることで、サーバーレスなデータ取り込みパイプラインを構築可能です。
つまり、「検索エンジンは Managed（インスタンス型）、取り込みは Serverless（OSIS）」というハイブリッド構成が、現時点での現実的な解となることが多いです。

項目 Serverless Managed
主な用途 ログ分析、単純なキーワード検索 本格的な全文検索、ECサイト検索
言語要件 英語メイン、または標準機能で十分 日本語など高度な解析が必要
データ量 変動が激しい、予測困難 ある程度予測可能
コスト感 最低でも約 $170/月 (0.5 OCU x 2)〜 t3.small.search x 1 なら約 $30/月〜 ※1
運用チーム インフラ担当不在 インフラ担当がいる、または学習コストを払える

※1: OSIS（データ取り込みパイプライン）を使用する場合は、別途パイプラインあたり月額 $235〜 が加算されます。

※ ベクトル検索とキーワード検索を組み合わせた「ハイブリッド検索」を行う場合も、日本語トークナイザーの精度が検索品質に直結するため、Managed 版の優位性が高まります。

おわりに

「サーバーレス＝正義」と考えがちですが、検索エンジンのようなステートフルで高度な機能を持つミドルウェアに関しては、まだ Managed 版（インスタンス型）の方に機能的な分があるケースが多いです。

特に日本語検索を要件に含む場合は、最初から Managed 版を選択してください。
後から移行するのは、データの再インデックスやインフラ構成の変更など、大きな手戻りが発生します。私のように開発途中で路線変更する羽目になりたくなければ、Serverless の制限（Kuromoji が使えない等）を許容できるか、プロジェクトの初期段階で慎重に検証してください。

関連記事

リバナレテックブログ
リバナレテックブログPublication

使い倒せ、テクノロジー。（MAX OUT TECHNOLOGY）をミッションに掲げる、株式会社リバネスナレッジのチャレンジを共有するブログです。Buld in Publichの精神でオープンに綴ります。 Qiita：qiita.com/organizations/leaveanest

Discussion