Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）

本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。

ダウンロードおよびすべての変更については次のリンクをごらんください。

最新安定版：Elasticsearch 1.7.0
1.6系バグフィックス：Elasticsearch 1.6.1

1.7.0が1.x系の最後のリリースとなります。今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。

Elasticsearch 1.7.0は小さなリリースですが、2つの重要なセキュリティフィックスとクラスタの安定化とリカバリに関する2つの重要な機能を含んでいます。

セキュリティフィックス
シャードアロケーションを遅らせる
インデックスリカバリの優先度

セキュリティフィックス

Elasticsearch 1.6.1 と 1.7.0 は次の2つのセキュリティフィックスを含んでいます。

リモートコード実行の脆弱性

Elasticsearch 1.6.1より前のバージョンには、transport protocol（ノードとJavaクライアント間での通信に利用）により、リモートでコードが実行される脆弱性があります。これは、CVE-2015-3253でのGroovyに関係しています。

Groovyのダイナミックスクリプティングがオフでも脆弱性があります。アップグレードをしないユーザは、transport protocol のポート（デフォルトで9300）信頼したエージェントからのみのアクセスに限定することで、脆弱性から保護できます。

この問題をCVE-2015-5377としました。

ディレクトリ探索の脆弱性

Elasticsearch 1.0.0から1.6.0までのバージョンで、ElasticsearchのJVMプロセスによって読み込みが可能なファイルを取得することができるディレクトリ探索攻撃の脆弱性があります。アップグレードをしないユーザは、信頼できない場所からのSnapshot-Restore APIの呼び出しを防ぐためにファイアウォール、リバースプロキシやShieldを使用することができます。

この問題をCVE-2015-5531としました。

シャードアロケーションを遅らせる

Elasticsearch 1.6.0でSynced Flushingが導入されました。これは、ノードのリスタート時に、更新が止まっているシャードのリカバリを劇的にスピードアップします。しかし、この変更は、シャードの配置を無効にしている環境でのみうまく実行されます。ノードが一時的にクラスタから外れている場合や予期せぬリブートの場合には役に立ちません。

このシナリオとは次のようなものです。

ノードの想定外のシャットダウン
マスタがたのノードにシャードを再配置
各シャードが新しい場所にネットワーク越しにコピー
その間に、外れていたノードが再度クラスタにジョイン
マスタは新しいノードにシャードを再配置。新しいノードに存在する既存のシャードが全く再利用されない可能性がある

ノードレベルとクラスタレベルの両方の並列的なリカバリを抑制しても、この"シャードシャッフル"がクラスタに対して負荷をかける可能性があります。これは、外れたノードが再度ジョインするのを単に待つことにより防げるかもしれません。

待ちましょう！

Elasticsearch 1.7.0はindex.unassigned.node_left.delayed_timeout設定を追加しました。デフォルトでは1分です。これは、ノードがクラスタから外れたとき、ほかのノードにこれらのノードを再配置するまでマスタが1分待つということです。ノードがこの1分の間に復帰した場合、マスタはローカルにあるシャードを再度配置します。

なぜ1分？

ノードがシャットダウンし、リスタートし、復帰するために十分な時間が1分だからです。しかし、ノードが復帰しない場合にはまだ再配置が発生することを意味します。デフォルト値を決定するのは難しいです。この設定をどのくらいに減らすか、増やすかを決める必要があるかもしれません。

このデフォルト値は、config/elasticsearch.ymlファイルに設定できますが、インデックス設定の更新APIを使って設定することも可能です。

このデフォルトに関する知見をぜひフィードバックしてください。

インデックスリカバリの優先度

1.7.0の2つ目の重要な機構はフルクラスタリスタートのような後に、どの順番でインデックスをリカバリするかという優先度をつけることができるという機能です。

電源故障による、ロギング用のクラスタのダウンを想像してください。クラスタが普及した場合、500個のインデックスをリカバリするような場合、499個のインデックスのデータは古く、 500番目のインデックスが重要です。もっとも最近作成されたインデックスがリカバリされるまで、インデキシングを待つというようなことはできません。

これまでは、インデックスはランダムな順序でリカバリされ、重要なインデックスがリカバリされるまで待つしかありませんでした。 1.7.0では、インデックスは優先度の順番でリカバリされます。この優先度は次のプロパティで指定できます。

index.priority設定（大きな値が優先度が高い）
インデックス作成日（新しいものが優先度が高い）
インデックス名

既存のクラスタについて特に変更せずとも、最も最近作成されたインデックスが古いものよりも復旧されます。古いインデックスの優先度を上げるためには、index.priority設定に0よりも大きな値を設定します。

PUT important_index/_settings
{
  "index.priority": 5
}

この設定は、存在するインデックスに対して更新できます。リカバリ中にもです。

まとめ

ぜひ、Elasticsearch 1.7.0をダウンロードして、試してみてください。そして、感想をTwitter(@elastic)などで教えて下さい。また、問題がありましたら、GitHub issues pageで報告をお願いします。