本日、Luceneの4.10.4ベースのElasticsearch 1.6.0をリリースしました。これはElasticsearchの最新の安定版で、素晴らしい新機能が満載されています：

Synced flushによる再起動の高速化
シャードアロケーションは、未終了タスクを阻害しません
JSONレスポンスボディフィルタリング
共有ファイルシステム・リポジトリのセキュリティフィックス
古いインデックスのためのUpgrade API
Kibanaユーザーのためのより寛容なハイライト
Windowsユーザーのためのmlockall
より詳細なスクリプト設定

変更内容の一覧とElasticsearch 1.6.0はここからダウンロードしてください。

Synced flushによる再起動の高速化

今回のリリース以前では、メンテナンスやローリングアップグレード時のノードの再起動で、必要であるかどうかに関わらず、ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。この新しいsynced flush機能により、synced flushされたインデックスに対して既存のデータを再利用し、より早くクラスタを正常な状態にすることができます。

変更前：既存のレプリカシャードは、ノードの再起動後にプライマリからリカバリすると、まずプライマリにあるセグメントとレプリカにあるセグメントを比較して、セグメントが異なる場合はコピーされます。しかし、セグメントプライマリのセグメントのマージとレプリカのセグメントのマージはそれぞれ独自に行われているため、各シャードのセグメントが全く異なっていても、同じデータを保持していることがあります。

変更後：新しいsynced flushフラッシュ機能では、sync_idがプライマリシャードとレプリカシャードに書き込まれ、2つのシャードのコンテンツが同じであると判別できるようになります。つまり、リカバリ時に行っていたセグメントの比較を省略できます。これにより、リカバリがスピードアップします。

直前の5分間でデータが登録、更新削除されていないアイドル状態のインデックスで自動的に実行されます。これは、ロギングの使用で特に便利です。昨日のインデックスは、インデックス作成が停止した後、5分で自動的に同期されます。

ノードまたはクラスタ全体を再起動する必要があり、自動的に発生する同期を待ちたくない場合は、以下のようにします。

注：アロケーションの無効化は不可欠です。これを省略すると、Elasticsearchはただちに再起動するノードのシャードを、別のノードに再配置し始めます。これは、新しいノードにすべてのシャードデータをコピーする必要があります。

ドキュメントのインデキシング、更新、削除後に最初のフラッシュが発生したときに、シャードのsync_idは、自動的に無効になります。詳細は #11336 および #11179 をご覧ください。

シャードアロケーションは、未終了タスクを阻害しません

ノードやインデックスを多数抱えているユーザーは、クラスタ全体の再起動後のシャードのリカバリで、長時間リカバリが止まって見えることに気付くかもしれません。リカバリが停止して見える間には、クラスタ設定の更新のような軽いアクションに例外が発生したり、その設定が反映されるまでに長い時間かかるなどが起こっていました。この問題の兆候は保留中のタスクのキューが大きくなることです。

このような遅延の原因は、シャード割り当てプロセスにあります。このプロセスでは、すべてのデータノードにアクセスして、割り当てる必要があるシャードのコピーがあるかどうかが確認されます。シャードの数が多く、ディスクの速度が遅いデータノードは、応答に時間がかかります。特に、シャードのリカバリですでに大量のI/Oを利用している場合には、遅くなります。以前のバージョンでは、シャード情報のリクエストは同時に処理されていました。つまり、クラスタ状態の更新は、割り当てプロセスの継続に必要な情報を待つ間、停止されます。

今回の変更 #11262 では、この情報のリクエストを非同期にします。このタスクが、クラスタ状態の更新を阻むことはありません。保留中のタスクはより速く処理され、クラスタは変更に対してより早く反応できます。処理中のシャード情報リクエストの数は cluster-health APIでnumber_of_in_flight_fetchキーとして報告されます。

さらに、シャードが、何らかの理由でリカバリに失敗した場合、クラスタはシャードのリカバリが成功するまで、同じノードにシャードをアロケーションしないようにします。

JSONレスポンスボディフィルタリング

Elasticsearchは、アプリケーションが決定を下すために必要なすべての情報を返します。例えば、検索リクエストは_index、_type、_id、 _score、_sourceを返します。しかし、すべての情報が必要でない場合もあります。このような不要データを遅いネットワークで転送すると遅延の原因となります。

この検索メタデータを無効にする特殊な設定、他のAPIのレスポンスのフォーマットを制御する設定があります。 #10980の変更では、filter_pathパラメータを使用して、任意のレスポンスボディのJSONにから必要な要素だけを取得する機能が追加されました。

例えば、検索で必要なのがヒット数のtotalと、hits配列の各要素だけであれば、次のように指定します：

GET _search?filter_path=hits.total,hits.hits

nodes-info APIから各ノードに対するhttp_addressだけを取得するには、ノード名と一致するようにワイルドカード（*）を使用します。

GET _nodes?filter_path=nodes.*.http_address

1つの「*」は、JSON階層の1階層に対してワイルドカードとして機能します。 2つの「**」は複数の階層に有効です。カンマ区切りで複数のフィルタが指定可能です。詳細はResponse filteringをご覧ください。

共有ファイルシステム・リポジトリのセキュリティフィックス

今回のリリースでは、snapshot-restoreで使用される共有ファイルシステム・リポジトリ周辺のセキュリティが強化されています。現在、Elasticsearchのユーザーは、Elasticsearchプロセスで書き込み可能なすべてのディレクトリに.snapshotファイルを書き込むことができます。 #11284の変更により、リポジトリに使用できるディレクトリを指定することが必須になりました。適切なディレクトリをconfig/elasticsearch.yml設定ファイルのpath.repoに指定する必要があります。

適切に設定されたElasticsearchインスタンスは、このセキュリティ問題の影響を受けにくくなっています。

rootではなくelasticsearchユーザーとしてElasticsearchを実行
elasticsearchユーザーはdataディレクトリに対してのみ書き込み権限を持ち、任意ディレクトリは共有ファイルシステム・リポジトリに利用できる
ファイアウォール、プロキシ、シールドを使用して、任意のユーザーからのsnapshot API の呼び出しを防止

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

古いインデックスのためのUpgrade API

Elasticsearch 2.0より Lucene 5ベースになり、Lucene 3 （Elasticsearchのバージョンでは0.90以前）によって書き出されたセグメントを含むインデックスは読み込めなくなります。これらの「古いインデックス」はLucene 4にアップグレードして、2.0と互換性のあるとマークされる必要があります。そうでなければ、Elasticsearch2.0に移行できません。

パフォーマンスの向上とバグ修正を利用するために、最新のLuceneフォーマットにインデックスの全セグメントをアップグレードするには、 upgrade APIを使用できます。古いインデックスを2.0-compatibleとしてマークする設定も書き込むことができます。さらに、upgrade_only_ancient_segmentsオプションの利用で、 Lucene 3のセグメントだけをアップグレードでき、移行前に必要な処理を減らすことができます。

Kibanaユーザーのためのより寛容なハイライト

KibanaユーザーはElasticsearchのハイライトの問題点を2点見つけていました。

ワイルドカードでフィールド名を指定すると、ハイライトに適さないフィールドが返される（日付や数値のフィールドなど）
一部の古いインデックスには非常に大きなターム（> 32kB）が含まれ、ハイライトが失敗する。最近のバージョンでは、このような大きなタームはインデックス時に除去される

#11364の変更でこの両方の問題が修正されました。ワイルドカードを利用したフィールド名は、文字列フィールドのみを返し、非常に長いタームによる例外は無視されます。

Windowsユーザーのためのmlockall

高速なガベージコレクションは、ノードの安定性とパフォーマンスのために必須です。たとえ数バイトのヒープでも、ディスクにスワップすることを許可してしまうと、ガーベッジコレクションに大きな影響を与える可能性があるため、絶対に避けるべきです。

Linuxユーザーは、起動時にJVMヒープをRAMに固定する bootstrap.mlockall settingをこれまでも利用できましたが、 #10887 の変更により、Windowsユーザーも、同様の機能を利用できるようになりました。

より詳細なスクリプト設定

スクリプトは、リクエストにインラインで指定できます。特別な.scriptsインデックスにインデックス付けもでき、config/ディレクトリ下にファイルで保存もできます。以前は、プロキシまたはシールドで.scriptsインデックスを保護できても、インラインとインデックス付きのスクリプトの両方を一緒に有効または無効のどちらかを選択しなければなりませんでした。

#10116に追加されたより詳細なスクリプト設定により、インライン、インデックスされたもの、ファイルスクリプトを個別に言語ごとに設定できるようになりました。さらに、search APIではスクリプトを許可するが、update APIでは許可しない、といったような設定も可能です。

まとめ

ぜひElasticsearch 1.6.0をダウンロードしてお試しください。Twitter（@elastic) または私たちのフォーラムに感想をよせてください。また問題がありましたらGitHub issues pageまでご報告をお願いします。

Elasticsearch Platform

ELK Stack

Elastic Cloud

オブザーバビリティ

セキュリティ

Search

業界別

ソリューション別

お客様事例

開発者

つながる

学習

ヘルプ

Elasticの最新情報

<

2015

<

11月

Beats 1.0.0

Timelion: Kibanaの時系列コンポーザ

Elasticsearchを時系列データストアに

Elasticsearch 2.0のインデキシングのパフォーマンスに関する考慮事項

SNSリンク

会社概要

参加する

報道資料

パートナー

信頼とセキュリティ

投資家向け情報

Excellence Awards