ElasticSearchClientを利用する際の注意点
これは「「はじめに」の Advent Calendar 2021」6日目の記事です。
TD;LR
- ElasticSearchは7.11からライセンスが部分的に変更され、7.14で完全に変更された
- Clientライブラリはサーバーサイドのライセンス変更に合わせ７.14からElasticSearch以外の互換ディストリビューションには接続できなくなった。
- ClientライブラリのライセンスはApache License 2.0である。
何が起きたか
とあるRubyのプロジェクトでElasticSearch-Railsを利用していました。
このライブラリはActiveRecordを利用し、モデルをElasticSearchに登録・検索をRails上で実現するライブラリです。Rails利用者からしたら使い勝手が良いものであり、非常に重宝していた。
RDBのレコードを登録・更新時のCallbackを利用してElasticSearchにあるIndexと同期をとることも簡単に行うことも出来ます。
使い方は簡単で、以下の記述をGemfileに追加し bundle install するだけです。
gem 'elasticsearch-rails', '7.1.1'
gem 'elasticsearch-model', '7.1.1'
※バージョンは当時のものを記載。最新ではありません。
しかし、そのままでは実行できず UnsupportedProductError が出てしまうようになり、仕方なく以下の行を追加する必要がありました。
gem 'elasticsearch-rails', '7.1.1'
gem 'elasticsearch-model', '7.1.1'
gem 'elasticsearch', '7.10.1'
Ruby on Railsを利用していて、 UnsupportedProductError が出た場合は多分上記の設定で解決するはずです。
ここから下は原因や考察になります。興味のある方はこのまま読んでみてください。
なぜelasticsearchのバージョンを直接指定する必要があったのか。
gem dependency で確認しても依存は正しく解決されるように見えます。
# gem dependency elasticsearch-model
Gem elasticsearch-model-7.1.1
activemodel (> 3, development)
activesupport (> 3)
bundler (>= 0, development)
cane (>= 0, development)
elasticsearch (> 1)
elasticsearch-extensions (>= 0, development)
...(略)
結論から言うと、以下の2つが原因でした。
- 接続先のサーバーがElasticSearchではなくAWSのOpenDistroを利用していた。
- クライアンライブラリでは、接続先がElasticSearchかどうかの確認が入っていた。
以前はそのようなことはなかったのに・・・と思い調べてみると、どうやらこのPRでサーバーの確認をするようになっているようです。
7.14に対するBackport
この確認が入ったライブラリを利用した結果、接続ができなくなり、このPRを含まないバージョンをGemで直接指定することで無事接続できるようになったというわけです。
(※7.13ではなく7.10と指定したのは利用しているバージョンと合わせたため)
この変更が何故入ったのか
この問題は、今年前半にElastic社から発表されたこの記事に起因します。
あわせてライセンスページも変更されています。
発表から半年も経っているので、経緯やその直後に起きた議論には今更言及いたしませんがElastic社と
某クラウド事業者(OpenDistroを提供していて、現在はOpenSearchSearviceを提供しているA社)の折り合いがつかなかった、ということです。
クライアントライブラリの提供目的はあくまで「ElasticSearchに繋ぐため」なので、他のサーバーに間違って接続すると危ないですものね。じゃけんちゃんとValidationしましょうね。という目的のPRですね。
当然、他の言語のライブラリにも同じ変更が入りました。
例えばPython版だと以下のPRです。
👎の多さがOSSコミュニティとしては、受け入れづらい変更だったことを物語っていますが・・・
AWSの発表とクライアントライブラリの現状
AWSとしては、OpenSearchを提供していて突然繋がらなくなった状況になるわけですから、この問題を受けてかどうかは不明ですがブログで声明を発表しました。 端的に言うと、
- 新規クライアントは別途作る予定
- OpenSearchはElastiｃSearch7.10とAPIの互換性を担保するからアプリケーションの変更は必要ない
です。
事実、OpenSearchと名を変えた最初のリリースでも互換を強調しています。
OpenSearch用の専用クライアントの現状はまだ以下の3つしかありません。
とはいえ、今の所7.10互換を継続するということですので当分はElasticSearchClientを7.10で利用すればおそらく問題ないと思われます。(将来的にはどうなるか不安ですが・・・)
クライアントライブラリはApache Liecense 2.0
サーバーサイドはElasticLicenseとSSPLの選択式ですが、クライアントライブラリはAapache License 2.0のままです。
APLはコピーレフトですので、好きなだけフォークして自分のライブラリとして公開してもライセンス上問題ありません。
よって、何らかの理由で新しいバージョンのクライアントライブラリで純正のElastiSearch以外と接続したくなった場合は自分で修正することも可能です。
とはいえ、AWSのOpenSearchを利用している限り、必要になる場面は今の所思いつきませんが・・・
一ユーザーからしてみると、なんだかなぁ・・・と思ったニュースの後に接続できなくなってイラッとしたという状況でした。
当分ElasticSearch周りのニュースは追いかけていこうと思います。
Discussion
わかりやすい記事をありがとうございます！
いくつかtypoと表記揺れなどがきになりました。Zennも編集リクエストみたいのができればいいのですが…