Elasticsearch 1.7.0および1.6.1をリリース
本日、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以前のバージョンでは、トランスポートプロトコル（ノードとJavaクライアント間での通信に利用）での、 リモートでコードが実行される脆弱性があります。この問題は、 CVE-2015-3253のGroovyアナウンスメントに関係しています。
Groovyの動的スクリプトが無効になっている場合でも脆弱性があります。アップグレードを希望しないユーザーは、トランスポートプロトコルのポート（デフォルトは9300）を信頼できるエージェントによるアクセスのみに限定することにより、この脆弱性に対処することができます。
この問題を CVE-2015-5377 としました。
Elasticsearch 1.0.0から1.6.0のバージョンには、ディレクトリトラバーサル攻撃に対する脆弱性があります。Elasticsearch JVMプロセスで読取り可能なファイルが攻撃者によって取得されてしまう恐れがあります。アップグレードを希望しないユーザーは、信頼できないソースからの Snapshot-RestoreAPI呼び出しを防止するために、ファイアウォール、リバースプロキシ、またはShieldを使用することができます。
この問題を CVE-2015-5531としました。
Elasticsearch 1.6.0 では Synced Flushingが導入されました。 これは、ノードのリスタート時に、更新が停止したシャードのリカバリを劇的にスピードアップします。 ただし、この変更は、シャードのアロケーションを無効にしている環境でのみ有効です。 ノードが一時的にクラスタから外れている場合や予期せぬリブート時には役に立ちません。
次のような状況が考えられます。
- ノードの予期外のシャットダウン。
- マスターが、他のノードにそのシャードを再配置。
- 各シャードは、ネットワーク経由で新しい場所にコピーされる。
- 一方、外れていたノードがクラスタに再び加わります。
- マスターが、 "新しい"ノードを活用するためにシャードを再配布。新しいノードに存在する既存のシャードが全く再利用されない可能性があります。
ノードレベルとクラスタレベルの両方で、並列的リカバリを制御していても、この「シャードシャッフル」がクラスタに負荷をかける可能性があります。これは外れたノードが再度加わるのを待つことで防ぐことができます。
Elasticsearch 1.7.0は index.unassigned.node_left.delayed_timeout 設定を追加しました。デフォルトでは1分です。 これにより、クラスタからノードが外れると、マスターは1分待ってから、他のノードにこれらのシャードを再配置します。 ノードがこの1分以内に復帰した場合、マスターはローカルにあるシャードを再度配置します。
ノードが、シャットダウン、再起動、クラスタに戻るために十分な時間が1分だからです。ただしノードが戻らない場合は再割り当てされることを意味します。適切なデフォルトの選定は困難です。どのくらい密接にクラスタを監視するかに応じて、この設定を増減することもできます。
このデフォルト値は、config/elasticsearch.ymlファイルに設定できますが インデックス設定更新APIを使用して、ライブインデックスに動的に更新することもできます。
デフォルトを改善するために、実際の使用経験に基づくフィードバックをお待ちしています。
1.7.0の2つ目の重要な機能は、フルクラスタリスタートなどの後で、 どの順番でインデックスをリカバリするかという優先順位付けです。
電源障害により全体のロギングクラスタがダウンしたことを想像してみてください。クラスタが戻ると500のインデックスを復旧する必要がありますが、そのうち499のデータは古く、必要なのは500番目とします。最後に作成されたインデックスが復旧するまでは、インデックス作成を再開することはできません。
これまで、インデックスはランダムな順序で復旧し、必要なインデックスがオンラインに戻るまで待つしかありませんでした。1.7.0では、次のプロパティに基づく優先度の順にインデックスが復旧されます。
- optional index.priority 設定（高い方が優先度が高い）
- インデックス作成日（新しい方が優先度が高い）
- インデックス名（高い方が優先度が高い）
既存のクラスタに変更を加えることなく、最も新しく作成されたインデックスが、古いインデックスより先に復元されます。古いインデックスの優先度を上げる必要がある場合は、動的 index.priority にゼロより大きい数値を設定します。
PUT important_index/_settings
{
"index.priority": 5
}
この設定は、実在するインデックス、さらにリカバリ中でも変更することができます。
ぜひElasticsearch 1.7.0をダウンロード してお試しください。Twitter (@elastic) または私たちの フォーラムに感想をよせてください。また問題がありましたら GitHub issues pageにて報告してください。