目次
※この記事は次のブログを翻訳したものになります。
原文：Elasticsearch 1.6.0 released
本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。
- synced flushによるリスタートの高速化 * シャード配置は保留中のタスクをブロックしない
- レスポンスボディのJSONのフィルタリング
- 共有ファイルシステムリポジトリに対するセキュリティフィックス
- 古いインデックスのためのUpgrade API
- Kibanaユーザのためのハイライトの強化
- Windowsユーザのための
mlockall - より詳細なスクリプト設定
すべての変更リストとダウンロードはこちらをごらんください。
synced flushによるリスタートの高速化
1.6.0より前のバージョンでは、メンテナンスやローリングアップグレード時の ノードの再起動で、必要であるかどうかに関わらず、多くの場合、 ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。 この新しいsynced flush機能により、 sync-flushされたインデックスに対して、既存のデータを再利用し、 より早くクラスタを正常な状態にすることができるようにします。
ここで、この変更以前にどのように動いていたかを説明します。 すでにあるレプリカシャードは、ノードがリスタートした後に、 プライマリから復元するときに、 最初のステップはプライマリにあるセグメントとレプリカにあるセグメントを 比較することです。そして、セグメントに違いがあった場合にコピーされます。 問題は、セグメントプライマリのセグメントのマージと レプリカのセグメントのマージが別々に起こっており、 各シャードのセグメントが完全に異なるが、 それらが同じデータを持っているという点です。
新しいsynced-flush機能では、sync_idがプライマリと
レプリカシャードに、シャードのコンテンツが同一であるという判別するために、
書き込まれます。これは、リカバリがセグメントの比較のステップを
スキップできることを意味します。
リカバリのスピードを高速にします。
synced flushはアイドル状態のインデックスで自動的に実行されます。 直前の5分間でデータが登録、更新削除されていないインデックスに対してです。 これは、ロギングのユースケースで特に役に立ちます。 機能のインデックスはインデキシングがストップしたあとの5分で自動的に syncされるでしょう。
ノードのリスタートやクラスタのリスタートが必要で、 自動的に発生するsyncを待てない場合は次のようなことが可能です。
- インデキシングを停止（実行中のリクエストが停止するのも待つ）
- シャードのアロケーションを停止
- synced-flushリクエストの発行
- ノードのリスタート
- シャードのアロケーションの再開
- クラスタの状態がグリーンになるまで待つ
- インデキシングの再開
NOTE: “シャードのアロケーションを停止"のステップが必要です。 これがない場合、Elasticsearchはノードの再起動が始まると、 異なるノードにシャードの再配置を始めます。 これは、新しいノードにシャードデータの全てをコピーする必要があります。
ドキュメントのインデキシング、更新、削除のあとに最初のフラッシュが
発生したときに、
シャードのsync_idが自動的に無効化されます。
詳細については#11336と#11179をごらんください。
シャード配置は保留中のタスクをブロックしない
多数のノードやインデックスを持っているユーザは クラスタ全体のリスタートのあとのシャードのリカバリで、 長い間、リカバリが止まって見えることに気づいたかもしれません。 これらのリカバリが止まって見える間は、クラスタ設定の更新のような軽微なアクションでさえ、 例外が発生したり、その設定が反映されるまでに長時間かかるといったことが起きていました。 この問題の兆候は保留中のタスクのキューが大きくなることです。
これらの遅延の原因はシャードの配置のプロセスにあります。 配置されるべきシャードのコピーを 持っているのがどのノードかを全てのデータノードに聞きます。 多くのシャードや遅いディスクを持ったデータノードは 反応するのに時間がかかります。 特に、シャードのリカバリがすでにI/Oを利用しているような時です。 このバージョン以前のものは、シャード情報のためのリクエストを 同期的に処理していました。 クラスタ状態の更新はアロケーションプロセスを続けるために 必要な情報を待っている間、ブロックされます。
#11262での変更は
この情報のためのリクエストを非同期にします。
クラスタ状態の更新はこのタスクによってブロックされません。
これは、保留中のタスクがより早く処理でき、
クラスタが変更に対してより早く反応できます。
処理中のshard infoリクエストの数は
number_of_in_flight_fetchキーとしてcluster-health APIで取得できます。
さらに、シャードがある理由で復旧に失敗すると、 クラスタは、シャードのリカバリが成功するまで、同じノードに対して シャードをアロケーションしないようにします。
レスポンスボディのJSONのフィルタリング
Elasticsearchは全ての情報を返します。
例えば、検索リクエストは_index、_type、_id、
_score、_sourceを返します。
しかし、全ての情報が必要でない場合があります。
また、これらのデータを遅いネットワークで転送することは
遅延の原因となります。
ユーザはこの検索メタデータを無効にするための特殊な設定を
行ったり、他のAPIのレスポンスのフォーマットを
コントロールするための設定があります。
#10980の変更で、任意のレスポンスボディのJSONに対して、
必要な要素だけを取得する機能が追加されました。
filter_pathパラメータを使用します。
例えば、検索リクエストからはtotal数と、各要素のhitsの配列を欲しい場合、
次のように指定します。
GET _search?filter_path=hits.total,hits.hits
nodes-info APIから各ノードのhttp_addressだけを取得したい場合は、
ノード名の部分にワイルドカード(*)を使用します。
GET _nodes?filter_path=nodes.*.http_address
単一の*がJSON階層の1つの階層に対しての
ワイルドカードとして機能します。
2つの**は複数階層に対してとなります。
複数のフィルタはカンマ区切りで指定可能です。
詳細についてResponse filteringをごらんください。
共有ファイルシステムリポジトリに対するセキュリティフィックス
本リリースはsnapshot-restoreで使われる
共有ファイルシステムリポジトリに関するセキュリティ強化の変更が含まれます。
現在、Elasticsearchのユーザは、Elasticsearchプロセスによって書き込み可能
任意のディレクトリに.snapshotファイルを書き込むことができます。
#11284の変更で、リポジトリのために使用できるディレクトリを
強制的に指定できるようになりました。
適切なディレクトリがconfig/elasticsearch.yml設定ファイルの
path.repoに指定される必要があります。
次のように設定されたElasticsearchインスタンスはこのセキュリティ問題に対して影響を受けにくいです。
rootではなくelasticsearchユーザとしてElasticsearchを実行elasticsearchユーザがdataディレクトリに対してのみ 書き込み権限を持っていて、共有ファイルシステムリポジトリに対しても利用できる- ファイアウォールやプロキシ、Shieldを使って、snapshot APIの実行を任意のユーザから実行されるのを防いでいる
この問題をCVE-2015-4165としています。
古いインデックスのためのUpgrade API
Elasticsearch 2.0以降では、 Lucene 5ベースとなり、Lucene 3 （Elasticsearchのバージョンでは0.90以前） によって書き出されたセグメントを含んだインデックスを読み込むことが できなくなります。 これらの「古いインデックス」はLucene 4にアップグレードする必要があり、 2.0-compatibleとして印をつける必要があります。 そうしなければ、Elasticsearch 2.0に以降できないでしょう。
upgrade APIは
、最新のLuceneフォーマットにインデックスにある全てのセグメントを
アップグレードするためにすでに利用できます。
また、最新のフォーマットは性能向上やバグフィックスといった利点もあります。
さらに、2.0-compatibleとして古いインデックスをマークする設定も
書き込むことができます。
さらに、upgrade_only_ancient_segmentsオプションが
Lucene 3のセグメントだけをアップグレードするために利用でき、
移行前の必要な処理を減らすことができます。
Kibanaユーザのためのハイライトの強化
KibanaユーザはElasticsearchのハイライトについて2つの点で問題を見つけていました。
- ワイルドカードでフィールド名を指定した場合に、ハイライトに適さないフィールドも帰ってくる（日付や数値のフィールドなど）
- 古いインデックスが非常に大きなターム（> 32kB）を含んでいて、ハイライトが失敗する。 最近のバージョンでは、これらの大きなタームはインデックス時に除去される
#11364の変更で これらの問題が修正されました。 ワイルドカードを利用したフィールド名では、stringフィールドのみを返し、非常に長いタームによる例外は無視するようになります。
Windowsユーザのためのmlockall
速いGCはノードの安定性と性能について重要です。 小さなバイトのヒープでさえ、ディスクにスワップすることを許可してしまうと、GCに対して大きな影響が出てしまいます。 ですので、これらのコストは排除されるべきです。
Linuxユーザはbootstrap.mloclall設定による恩恵を受けています。
これは、RAMにJVMのヒープを起動時にロックします。
#10887では、同様の機能をWindowsユーザにも提供します。
より詳細なスクリプト設定
Scriptsはリクエストにインラインで指定できます。
.scriptsインデックスにインデックスもでき、config/ディレクトリ配下にファイルとして保存もできます。
これまでは、インラインかインデックスされたスクリプトの両方を同時に有効無効にすることが選択できましたが、
.scriptsインデックスをプロキシやShieldで保護することもできました。
#10116で追加されたより詳細なスクリプトの設定で、インラインか、インデックスされたものか、ファイル化を個別に言語ごとに設定できるようになりました。 また、例えば、search APIではスクリプトを許可するが、update APIでは許可しないといったような設定も可能です。
最後に
ぜひ、Elasticsearch 1.6.0を試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。
comments powered by Disqus
See Also by Hugo
- Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）
- Elasticsearch 1.5.1リリース（日本語訳）
- Elasticsearch 1.4.2および1.3.7リリース（日本語訳）
- Elasticsearch 1.3.1 リリース（日本語訳）
- Elasticsearch 2.0.0.beta1リリース間近（日本語訳）