Fess 13に向けて

Fess 13ではElasticsearch 7系を採用する予定だけど、Elasticsearch 6から7への変更はBreaking changesに書いてある。まだ、7.0.0-beta1がリリースされている段階だが、Elasticsearch 6のときにはrc1がリリースされた頃からFess 12に対応したため、ちょっと時間がかかったりで、6.1がリリースされたときにFess 12.0がリリースされたので、Elasticsearchとはマイナーバージョンがずれる感じになってしまった。ということで、今回はちょっと早めのbeta1から対応を始めている。

とはいえ、Breaking changesにあるように変更はいろいろとある。今回はFessで遭遇した変更点を上げておく

typeの削除が始まる

Elasticsearch 8で完全になくなると思うが、7では消し始めていかないとエラーになったりする箇所がある。なので、使っていれば積極的に消していく必要がある。Java APIとかだと、client.prepareDelete(index, type, id)みたいに指定できてしまう箇所とかもあるけど、これらはclient.prepareDelete().setIndex(index).setId(id) みたいにtypeを消したりとどんど消していったほうが良い。_docとかをtypeに指定しておけば良いかもしれないが、修正漏れとか出たりするので思い切って消す方針で進めるのが良いかも。

hits.totalがオブジェクトになる

ここにあるように、件数が整数で返ってきたのがオブジェクトになるので、JSONのパースとかしている箇所では注意が必要。オブジェクトになったことに合わせて、track_total_hitsなど、件数表示の指定などがあったり、件数の考え方に確認しておく必要がある。

Transport Clientは非推奨

Elasticsearchとの通信にはHTTP(9200)とTransport(9300)の2種類があったが、Transportの方は非推奨になっている。8では削除される。なので、TransportClientは利用せず、HTTPでElasticsearchと通信するようにしておくのが良い。Fessでは普通にRESTに書き直すのは変更が大きすぎてつらすぎるため、elasticsearch-httpclientを作成して、TransportClientを単純置き換えで、移行した。

楽観的排他制御の変更

_versionでoptimistic concurrency controlを実装していたが、(たぶん)Elasticsearch 6の後半あたりで、_seq_noと_primary_termを利用するように変更されている。Elasticsearch 7では_seq_noと_primary_termを利用する必要があるので、これに置き換える必要がある。

スクロールのコンテキストの上限

スクロールで検索するとサーチコンテキストがオープンされるのだが、search.max_open_scroll_contextが500に設定され、オープンするコンテキストの上限が500になった。今までは上限なしだった。というわけで、スクロール検索している箇所では、スクロールの終了時にはscroll_idは削除しないと、指定時間だけ保持されることになり、上限になってエラーになる。サーチコンテキストは不要なら明示的に削除していく必要がある。

というあたりのところが、Fessでは問題なった箇所かな…。Elasticsearch 7とは関係なく、言語判定部分などみなしたい箇所があるので、fessインデックスのマッピングなどは見直すことになると思います。Elasticsearch 7が出た後の近いうちにはFess 13をリリースできるようにしたいところではありますね。

cluster.routing.use_adaptive_replica_selection

Elasticsearch 6までは複数のレプリカがある場合、レプリカの使われ方はラウンドロビンで順番に使われます。たとえば、
・シャード1P, シャード1R1 シャード1R2
・シャード2P, シャード2R1 シャード2R2
のように2シャードの3レプリカの場合は、1回目の検索で1P&2P, 2回めの検索で1R1&2R1, 3回目の検索で1R2&2R2みたいな感じで使われることになります(実際には非同期で処理されるのでシャード1と2ではそのときのが選択されて場合によってはPとRはずれる気はするけど)。という感じで、デフォルトはラウンドロビンということ。

Elasticsearch 7からはラウンドロビンでなくなり、それを6でも試すなら、cluster.routing.use_adaptive_replica_selectionをtrueにする。7ではtrueになっている。

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"transient": {
"cluster.routing.use_adaptive_replica_selection": true
}
}
'

Ubuntu 18.04でCorretto 11を使う

Corretto 11プレビューが公開されたので、使ってみることにする。まず、java-commonを入れておく

$ sudo apt-get update && sudo apt-get install java-common

次にここからCorrettoをダウンロードする。今回はjava-11-amazon-corretto-jdk_11.0.2.9-1_amd64.debをインストールする。

$ wget https://d2jnoze5tfhthg.cloudfront.net/java-11-amazon-corretto-jdk_11.0.2.9-1_amd64.deb
$ sudo dpkg --install java-11-amazon-corretto-jdk_11.0.2.9-1_amd64.deb

インストールすると設定されるので、以下で確認。

$ java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment Corretto-11.0.2.9.1 (build 11.0.2+9)
OpenJDK 64-Bit Server VM Corretto-11.0.2.9.1 (build 11.0.2+9, mixed mode)

Types cannot be provided in get mapping requests, unless include_type_name is set to true.

Elasticsearch 7になると、typeを指定していると怒られる。たとえば、

$ curl "http://localhost:9201/fess.20190224/_mapping/_doc?pretty"
{
"error" : {
"root_cause" : [
{
"type" : "illegal_argument_exception",
"reason" : "Types cannot be provided in get mapping requests, unless include_type_name is set to true."
}
],
"type" : "illegal_argument_exception",
"reason" : "Types cannot be provided in get mapping requests, unless include_type_name is set to true."
},
"status" : 400
}

という感じで、Mapping APIで…/_mapping/{type} みたいなことしているとエラーになる。とりあえず、回避したいのであれば、

$ curl "http://localhost:9201/fess.20190224/_mapping/_doc?include_type_name=true&pretty"

とすれば、今までどおりに返ってくる。まぁ、本来はtypeを指定しないようにするようになおすのが良いが、URLからtypeを消すだけでなく、レスポンスの中のtypeもなくなるので、レスポンスをパースしている仕組みも合わせて修正する必要がある。