はじめに
こんにちは。情報システム部の桝冨です。
Linkers Sourcing / Marketing (LS/LM) では日頃からさまざまな内部改善を行なっています。
その中で、Apache Solr の撤廃と henkei の導入を担当させていただきましたので、共有したいと思います。
Apache Solr を撤廃したい
LS/LM では過去、全文検索エンジンとして Apache Solr が利用されていました。
現在は Elasticsearch を利用しているため、全文検索用途ではこちらに移行済みです。
一方、文書ファイル（Word、PDF）からテキストやメタ情報を抽出する用途でも Apache Solr が利用されていて、こちらの用途での利用は細々と続いていました。
これは Apache Tika の機能を Apache Solr のインターフェイスを通して利用している状態で、用途に比してシステム構成が大袈裟な状態でした。
運用コストも大きかったため、Apache Solr を撤廃したいという話になりました。
henkei への置き換え
Apache Solr の代わりに導入することになったのが henkei gem です。
henkei の使い方はシンプルで、以下のように数行の Ruby プログラムで簡単にファイルからテキストやメタ情報を抽出できます。
data = File.read 'sample.pages' text = Henkei.read :text, data metadata = Henkei.read :metadata, data
henkei の特徴は次のとおりです。
- 文書ファイルからテキストやメタ情報の抽出ができる
- Apache Tika のラッパーライブラリ
- Apache Tika のバイナリは gem に梱包されているため、別途インストールは不要
- ただし、Java の実行環境は必要
移行前後のシステム構成の差異は図の通りです。
ともに Rails アプリケーション上で動作させる想定です。
システム構成変更前では、Rails アプリケーションから外部の Apache Solr を利用する形を取っていました。
移行後は外部の Apache Solr が不要となり、Rails アプリケーション単体で動作するようになります。
henkei の特性上、Rails アプリケーションの実行インスタンスで Java ランタイムが必要となります。
移行作業
大きな問題は発生しませんでしたが、いくつかつまずきポイントがあったため記載しておきます。
JDK ディストリビューションの選定で少し悩んだ
一昔前は特に悩むことなく Oracle JDK を利用すれば良かったのですが、現在はいくつかの JDK ディストリビューションから適したものを選んで使う必要があります。詳細には立ち入りませんがライセンス周りで紆余曲折あったようで、普段 Java を触らない自分は少々混乱させられました。
Oracle JDK、Adoptium Eclipse Temurin、Amazon Corretto の間で比較検討し、Amazon Corretto を利用することにしました。
Apache Solr 運用時にも Amazon Corretto を利用していたことが最大の理由ですが、下記のような点も安心材料でした。
- LS/LM では AWS を利用しており親和性が高い
- ライセンス上の問題がない
- サポート体制も安心できる
- きちんとアップデートされており、LTSもある
- 動作環境も特に問題ない
- macOS の開発マシンへの導入も容易
文字コードの扱いが怪しい
今回のユースケースでは問題とはなりませんでしたが、henkei の文字コードの扱いが少し微妙だと感じました。
- 文書ファイルから抽出したテキストがバイナリで返されるため、
.force_encoding('utf-8')が必要 - UTF-8 以外のテキストファイルがうまく扱えない
- 扱える文字コードはシステムロケールによりそう
これらは henkei 内部での Apache Tika の呼び出し方法に起因する問題のようです。
実際、henkei にバンドルされている Apache Tika を直接実行した場合には、これらの問題を回避できることが確認できています。
所感
Apache Solr から henkei へと移行してみて感じたのはとにかく手軽だということです。
Ruby プロセスから容易に Apache Tika の機能を呼び出せるのは良いと感じました。
一方、導入する際には以下の点に気をつける必要があると感じました。
- 呼び出しのたびに Java プロセスが立ち上がる方式のため、実行時間のオーバーヘッドがある
- 呼び出し元の Ruby プロセスと Java プロセスが同一インスタンスに相乗りすることになるため、システム構成次第ではマシンリソースが効率的に利用できない
このあたりは手軽さとのトレードオフなので、性能が必要なユースケースではシステム構成に工夫が必要そうです。
おわりに
いかがでしたでしょうか。
もし文書ファイルの中身を精査するケースがありましたら、henkei の利用を検討してみてもいいかもしれません。
