Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Elastic{ON} 2016レポート What's Evolving in Elasticsearch #elasticon

キーノートの次は、Elasticsearch本体のプロダクト紹介セッションに参加しました。

最近のElasticsearch 2.xは?

最近のElasticsearch 2.x系では、ユーザビリティの改善、Javaヒープ使用量の削減、セキュリティの強化、テストの強化などが行われています。
特にElasticsearch 2.0で、doc valuesというオプションがデフォルトで有効になったおかげで、
ヒープ使用量がグッと下がり、それなりに少ないメモリでも機嫌よく動いてくれるようになったと実感しています。

たぶんもう1.x系には戻れないですね。

f:id:acro-engineer:20160218181304j:plain:w480


また、2.2ではプロファイルAPIという機能が追加されました。
これはちょうどSQLの実行計画を取得するようなもので、Elasticsearchに対するクエリが、
どのようなLuceneクエリに分解されて、
それぞれのLuceneクエリの処理に掛かった時間や取得したデータ件数などを確認できるようになる機能です。

パフォーマンス改善で利用できるのはもちろんのこと、Elasticsearchのクエリに不慣れなうちは、
自分が書いたクエリが期待通りのクエリに分解されるかどうかを確認するという用途でも使えます。
ほら、Elasticsearchのクエリの文法とかよく分からないから、最初はOR検索をうまくできなかったりするじゃないですか。
(主に僕がそうだったんですが。)

そういう人にも便利なので、プロファイルAPIはぜひ使ってみてください。
検索クエリに "profile": true とつけるだけで実行できます。

新機能その1、加工や更新のためのAPI

これから追加される新機能の目玉の一つが、Ingest Node。
データの加工やフィルタリングなど、LogstashのFilterプラグインで実現していた機能をElasticsearch自身が持つというものです。

f:id:acro-engineer:20160218181521j:plain:w480

たとえばApacheやnginxのアクセスログを分解して、それぞれのフィールドに格納するだとか、
IPアドレスから位置情報を取得するとか、そのような加工をElasticsearchで行うことができるようになる、というものです。

これまでは、データ加工を行いたければLogstashを挟む必要がありましたが、その必要なくなるということですね。

これはデータの流れなどが変わる要因になる、大きな機能追加と言えます。


続いて大きな変更になるのが、Re-Index API

f:id:acro-engineer:20160218181328j:plain:w480
次のようなクエリを発行することで、old_indexに対して検索を掛けて、一致したドキュメントだけをnew_indexにコピーすることができます。

POST _reindex
{
  "src": {
    "index": "old_index",
	"query": {
	  "match": {
	    "user": "twitter"
	  }
	}
  },
  "dest": {
    "index": "new_index"
  }
}

たとえばHTTPサーバのアクセスログを全部投入したうえで、
検索APIへのアクセスだけを別indexに入れて細かく検索条件を分析するだとか、
ログインしたユーザとそうでないユーザでindexを分けて異なる分析をする、
ということができるようになります。


同じような形で、もう一つ追加されるのが、Update by Query API
これはindexに対して検索を掛けて、一致したドキュメントを、指定した条件で更新するというものです。



Ingest Node、Re-Index、Update By Queryを組み合わせれば、とにかくいったんElasticsearchにデータを投げ込んでおいて、
後で加工しながらindexを分ける、ということができるようになりそうです。

この辺りは実際にどういう形になるのかもう少し先にならないと分からないのですが、
何にせよElasticsearchにログを流し込むアーキテクチャをよりシンプルにできるものだと思います。

新機能その2、Java Http Client。

もう一つ、目が離せないのがJavaのHTTP Client。

Elasticsearchは標準で9200番ポートと9300番ポートの2つを利用しており、
9200番ポートがHTTP用(RESTクライアント用)、9300番ポートがクラスタ間通信の独自プロトコル用で使われていました。
それでcurlコマンドやSenseなどからは9200番ポートを使い、Javaのクライアントは9300番ポートを使っています。

9300番ポートの方がHTTPのオーバーヘッドがない分、パフォーマンスが良いと思うのですが(計測したことはないです)、
その反面、9300番ポートを使うJava APIのライブラリには、Elasticsearchサーバで必要なクラス群が含まれていました。

だって、元々クラスタ間通信のためのポートですからね。


今回、Java用に9200番ポートを使ったHTTP Clientができるおかげで、フットプリントの小さなJARライブラリができることになります。

f:id:acro-engineer:20160218181425j:plain:w480

また、Java APIは頻繁に(バージョンアップのたびに)APIが変わっていたのですが、HTTP APIは比較的安定していました。
特にJava APIを使う外部ツールを作っていた場合には、バージョンアップに追従するのが大変だったことも、一つの問題になっていました。

そういう点でも、HTTP APIJavaでも使えるようになる恩恵は大きいと言えますね。

まぁこれだけ説明してきましたが、本音で言えば「やっとかよ、最初から作っとけよ!」なんですけどね!(笑)

その他は・・・

あとはk-dimensional treeを使ったPoint field encodingを数値型や日付型に対して行うことで、
データサイズの削減や検索パフォーマンスの向上、ヒープサイズの削減などが行われます。

f:id:acro-engineer:20160218181353j:plain:w480
この辺りあまり詳しくないので仕組みはよく分かりません、すみません。


そんなElasticsearch 5.0のalpha版は、まもなくダウンロード可能になるとのこと。

f:id:acro-engineer:20160218181632j:plain:w480

とにかく、早く試してみよう!