Taste of Tech Topics

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

Elastic{ON} 2016レポート Ingest Node: Enriching Documents within Elasticsearch #elasticon

Elasticsearch 5.0の目玉機能の一つである、Ingest Nodeのセッションに参加しました。
Ingest Nodeとは、Logstashが持つ加工機能をElasticsearchに移植したものです。
f:id:acro-engineer:20160219104038j:plain:w480

セッションは少し小さめの部屋で行われたのですが、立ち見まで出る満席っぷり。
かなり注目の機能ですし、実際、インパクトのあるデモも見られました。今日イチのセッションですね。

ユースケースは2種類

Ingest Nodeのユースケースとして2種類紹介されました。

  1. FilebeatからLogstash経由せずに、直接Elasticsearchにデータを送り込む
  2. Reindex APIと組み合わせて使う

f:id:acro-engineer:20160219104225j:plain:w400

前者は、これまでFilebeat(転送) → Logstash(加工) → Elasticsearch(保存)としていたところを、
Filebeat(転送) → Elasticsearch(加工&保存)とできるようなる、というパターンです。
また後者は、Elasticsearchに投入済みのデータを取り出しながら加工し、別のindexに投入するというパターンです。

いずれもありそうなシチュエーションですね。

なおElasticsearch 5.0では、デフォルトでIngest Nodeが有効になるように設定されているとのことです。

パイプラインの作り方

Ingest Nodeで行われる個別の処理はプロセッサと呼ばれ、それらを組み合わせたものをパイプラインと呼びます。
パイプラインの作成、更新、取得、削除はREST API経由で行います。

PUT _ingest/pipeline/pipeline-name
GET _ingest/pipeline/pipeline-name
GET _ingest/pipeline/*
DELETE _ingest/pipeline/pipeline-name

PUTするJSONはこんな感じ。

{
  "description": "mysql pipeline",
  "processors": [
    {
	  "grok": {
	    "field": "message",
		"pattern": "..."
	  }
	},
	{
	  "remove": {
	    "field": "message"
	  }
	}
  ]
}

Logstashの設定は独自の文法で行うものでしたが、Ingest Nodeのパイプラインは普通にJSONで記述するようですね。


このパイプライン用に利用できるプロセッサは、mutate、grok、geoipなど、LogstashにあるFilterはだいたいあります。
f:id:acro-engineer:20160219104702j:plain:w400

というかむしろIngest NodeのプロセッサはLogstashのFilterと相互に互換性があるそうです。こういうものって得てして別物になりがちなので、これは嬉しいところですね。


エラーが発生した時の処理は、プロセッサの on_failure で記述できます。
次のJSONは、bytesという名前のフィールドを数値(integer)に変換し損ねた場合には、値を0にするという例です。

{
  "convert": {
    "field": "bytes",
	"type": "integer",
	"on_failure": [
	  {
	    "set": {
		  "field": "bytes",
		  "value": 0
		}
	  }
	]
  }
}

なるほど、違和感ないですね。


またテストのためにSimulate APIが用意されており、実際にindexを行わずに、ドキュメントを試しに投入するテストを行えます。
最初からこういうものが用意されているのは、ありがたいところ。

Simulate APIは、こんな形をしています。

POST _ingest/pipeline/pipeline-name/_simulate
POST _ingest/pipeline/_simulate
POST _ingest/pipeline/_simulate?verbose

verboseオプションをつけることで、最終的な結果だけでなく、パイプラインの途中の処理結果を確認することができるようになります。

パフォーマンスは?

パフォーマンスは、平たく言えば、いつものマジックワード「depends on」です。プロセッサの内容、プロセッサの数、追加/削除するフィールドの数、などなど。
ベンチマーク結果も示されていましたが、あまりピンと来ませんでした。
f:id:acro-engineer:20160219105747j:plain:w400


ただどうあれ、このような加工処理がindexに影響を与えることは間違いありません。それでパフォーマンス問題が起きるようなことを想定して、
通常のノードとは別に、Ingest専用のノード(dedicated ingest nodes)を作るというパターンも紹介されていました。
f:id:acro-engineer:20160219105927j:plain:w400
masterノードからingest nodeに行って来いする形ですね。

デモがやばい。

パイプラインを実際に作成するデモも行われました。って、このデモが想像以上でした。

Elasticsearch 5.0 + Kibana 4.4の組み合わせでしょうか、Kibana上のindicesのsettingsに「Tail a File」というオプションが追加されており、
ここからパイプラインを作成したり、ファイルを流し込んだりできるようでした。


デモでは、実際にTail a Fileが行われました。まずはテキストエリアに、読み込み対象となるファイルのサンプルを適当に貼り付けます。
f:id:acro-engineer:20160219110314j:plain:w480


そうすると、パイプラインの処理結果としてどういうJSONが得られるかというサンプルが表示されます。
この例ではまだ何のプロセッサも設定していないため message というフィールドに、貼り付けたログの1行が表示されるだけになっています。
f:id:acro-engineer:20160219110153j:plain:w480


その後、プロセッサを追加してパターンなどを設定すると、どんどんOutputの形が変わっていきます。
この写真の例では(すごく見えにくいですが)最終結果のOutputが、source、message、contentの3フィールドが出力されることや、プロセッサの結果として、sourceとcontentが取得できることが分かります。
f:id:acro-engineer:20160219110127j:plain:w480


実際にファイルのサンプルを使いながら、トライ&エラーで設定を変更できるのは、本当にありがたい機能です。Logstashにはこの機能がないために、
ちょっと修正してはLogstashプロセスを再起動して、試しにデータを流し込んでみて、また修正してはプロセスを再起動して・・・という作業を繰り返さざるを得ませんでした。
(Logstash 5.0では設定が自動でリロードされるようになり、少しは楽になりますけども)

このパイプラインの作成の手軽さを考えると、もうLogstashなんて使っていられないな・・・と思うほどです。

まとめと、今後?

という感じで、Ingest Nodeをとても使いたくなるセッションでした。むしろこれから先、Logstashがどういう位置づけになるのか、微妙だと思います。
まず、小さな規模であれば、Logstashを完全に省いて、Filebeat(や他のBeats)とElasticsearchだけで運用することができるようになるのは間違いないでしょう。

問題は、規模が大きくなってきた時。今の標準的な構成としてはKafkaを挟んだ形になります。

Filebeat → Logstash(加工) → Kafka(キュー) → Logstash(転送) → Elasticsearch(保存)
※それとは別に、Kafka or Logstash からファイルサーバに転送


これが、FilebeatがKafka出力に対応し、ElasticsearchがIngest Nodeを持つことになると、こうなります?

Filebeat → Kafka(キュー) → Logstash(転送) → Elasticsearch(加工&保存)
※それとは別に、Kafka or Logstash からファイルサーバに転送

Logstashは転送の役割だけで、むしろKafkaからElasticsearchが直接繋がれば、Logstashは完全に要らなくなるのに・・・と思ってしまいます。
この辺りがどうなるのか、今後の動向も含めて数ヶ月ぐらいはウォッチしたいと思います。


いやー、Ingest Node、便利ですよ!

Elastic{ON} 2016レポート My own google? FaceChimpを見せてもらいました。 #elasticon

お昼前に、Elasticの方から興味深いデモを見せてもらいました。
FaceChimpという検索エンジン系のKibanaアプリです。
f:id:acro-engineer:20160219084134p:plain:w480


KibanaのFaceChimpアプリで、検索対象のindex(複数指定可能)や、検索対象のフィールド、
検索結果に表示するフィールドなどを選択すると、GoogleライクなUIを生成できるというものです。
f:id:acro-engineer:20160219084214p:plain:w480


通常のキーワード検索に加えて、画像検索や地図検索での結果も表示できます。
また、キーワードのサジェストもあれば、Did you mean? 機能もあります。
f:id:acro-engineer:20160219084200p:plain:w480


簡単ですが、アクセス統計などが見られるダッシュボードも用意されています。
f:id:acro-engineer:20160219084244p:plain:w480


Elasticsearchって検索のバックエンドのエンジンとして利用できるのですが、検索用のUIは(Sense以外には)用意されていませんでした。
そこにFaceChimpを使うことで、検索用のUIも提供できるようになったということですね。
これで完全にSolrの息の根が止まりますよね

FaceChimpはまだ公開されていませんが、いずれTimelionなどと同じくオープンソースで提供される模様です。なかなか助かりそうに思うので、こちらもいち早く使ってみたいですね。

Elastic{ON} 2016レポート What's the Latest in Logstash #elasticon

世界の皆さん、おはようございます @ です。
今日も一日、elastic{ON}でがんばります。

2日目最初のセッションは、Logstashのプロダクト紹介を選びました。
f:id:acro-engineer:20160219055533j:plain:w480

Logstashの現在

まずはLogstashの歴史から。
f:id:acro-engineer:20160219055929j:plain:w400
Logstashは2009年に初めてリリースされ、その後、Logstashにデータを転送するLogstash-forwarderやPacketbeatなどが開発され、それらがまとめてBeatsシリーズとして整理されました。

また5.0シリーズではElasticsearchにLogstashのFilterを機能を移植して、Ingest Nodeという形で提供されることになりました。


LogstashはJenkinsできちんとテストサイクルを回しています。こんな画面も共有されました。
f:id:acro-engineer:20160219055903j:plain:w400
Java7/8でテストしているそうです。

またキーノートでも触れられていた通り、Logstash自身の性能もバージョンを追うごとに改善しています。
f:id:acro-engineer:20160219060008j:plain:w400

データを決してロストしないLogstashに向けて

Logstashはマシンリソースやネットワークリソースが不足した程度では情報を失わないのですが、Logstash自身のプロセスが止まるような状況では情報をロストしてしまいます。
f:id:acro-engineer:20160219060219j:plain:w400

というのもInput、Filter、Outputの間でそれぞれキューを持っており、プロセスが落ちた時点でその情報が失われてしまうためです。
f:id:acro-engineer:20160219055717j:plain:w400


LogstashのInputは、現時点でもKafkaやRabbitMQのAcknowledgeに対応していてInput処理の成功したときだけ、キューから要素を削除するようになっています。要するにトランザクション的なあれです。
f:id:acro-engineer:20160219055949j:plain:w400
ただしFilterやOutputまでは含めたAcknowledgeはまだサポートされておらず、これは今後の対応になります。
f:id:acro-engineer:20160219055626j:plain:w400

Logstash 2.2.0ではバッチ処理もサポートされました。
f:id:acro-engineer:20160219060134j:plain:w400

また、Javaをシリアライゼーションに用いることができるようになるようです。ちょっとよく分かりませんでした。
f:id:acro-engineer:20160219055556j:plain:w400


今後の一番大きな目玉は、キューの永続化でしょう。Logstashに入った情報をディスクなどに永続化することができるようになります。
f:id:acro-engineer:20160219060239j:plain:w400
また デッドレターキューも実装され、Outputで失敗したものはデッドレターキューに入る形になります。


ということでLogstash 5.x系では、Logstashのプロセスが停止しようが、OSごと落ちようが、情報が残ることになります。Logstash最高かよ!
f:id:acro-engineer:20160219055744j:plain:w400

Logstashの管理も改善

後半は、Logstashの管理について。

現行のLogstashでもREST APIを用いてステータスや、重いスレッドの情報などを取得することができるそうです。知らなかった。
f:id:acro-engineer:20160219055803j:plain:w400
f:id:acro-engineer:20160219060044j:plain:w400


また、 次のバージョンではこれらの情報を可視化することが計画されています。もうこの辺りは必須になっていますね。
f:id:acro-engineer:20160219060109j:plain:w400


また、設定周りの改善も計画されています。まずは設定ファイルの自動リロード
f:id:acro-engineer:20160219060259j:plain:w400
ファイルの更新をチェックして、自動的にリロードして、パイプライン処理を新しく始めるというもの。プロセスを再起動する必要はありません。
(うーん、別に自動ではなく、reloadをコマンドでできれば良いと思うんですけど・・・)

なおデモを見る限り、ファイルの更新が検出されてからパイプライン処理が再開されるまでは一瞬で、Logstashの起動時のあの待たされる感じはありませんでした。それは嬉しいところ。


次は、設定の中央管理。
f:id:acro-engineer:20160219055839j:plain:w400
Logstashのクラスタリングを始めたり、Logstashを多段構成で使うようになると、どうしても設定の管理が煩雑になります。その改善として、設定をElasticsearchに集約して、ElasticsearchからLogstashに設定を送りこむことができるようになります。


そして、ノードの管理。
Logstashの各ノードが生きているかどうかの管理をElasticsearchで行えるようになります。f:id:acro-engineer:20160219055649j:plain:w400

Elasticsearch側に、Logstashの管理APIも追加されるようです。
f:id:acro-engineer:20160219060153j:plain:w400

Logstashの管理についてはElasticsearchに集約するという方針が示されています。Beatsシリーズも同様の中央集約を検討していると聞いたことがありますので、Elasticスタック全体として、設定や管理が中央集約されていくようですね。


ということで、Logstashのキュー周りの改善による安定化と、設定・管理の中央集約という大きな方向性が示されています。
キューについてはこれまでKafkaなどに頼ることで解決してきたと思うのですが、ここをLogstashを強化することでKafka不要とするのか、あるいは、引き続きやはりキューの強力な機能はKafkaに任せるのか、注目したいと思います。

Elastic{ON} 2016レポート What's Brewing in Beats #elasticon

1日目、最後のセッションはBeatsです。
BeatsはElasticsearchやLogstashにデータを転送するエージェントで、要するにtd-agentとか、Mackerelのエージェントのようなものです。
Go言語で書かれているので、僕もGoの勉強がてらBeatsを書いてみたこともありました。

Filebeatが想像以上にちゃんとしていた件

Beatsシリーズのうち、Topbeat/ Packetbeatは以前このブログでも紹介しました。
acro-engineer.hatenablog.com

簡単なセットアップで、サーバのCPU、メモリ、ディスクなどのリソース情報や、
パケットを流れる情報を元にSQLの内容や実行回数などを確認できるという、
なかなかインパクトあるプロダクトです。

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


これに加えてWinlogbeatが最近追加され、WindowsXP以降のWindowsイベントログを転送できるようになりました。

恐らくこれはセキュリティ監視などの用途で使われるものなのかなと思います。
ウィルスに感染したり外部からアタックを受けていることを、Windowsのイベントログから拾おうとするんじゃないかなと。


また、今回のセッションでかなり詳細に紹介されたのがFilebeatです。
Filebeatはログファイルのようなファイルを監視し、その内容を転送するプロダクトです。
Filebeat自体にはログを解釈するような仕組みはないため、そこはLogstashに任せることになります。
なので、Filebeat -> Logstash -> Elasticsearchという構成になるわけですね。

ここでFilebeat + Logstashの組み合わせで利用する場合、ファイルのデータを転送し損なわないよう、
バックプレッシャー的な手法を用いるそうです。

つまり転送先であるLogstashの方からFilebeatに対して「読み込めない」という通知が来ると、
Filebeatは転送対象のログファイルの読み込みをストップし(どこまで読み込んだかはFilebeat自身が保持しておき)
またLogstashから「読み込めるよ」という通知が来ると、転送を再開するそうです。

うん、これはバックプレッシャーでありリアクティブだ!(←言いたかっただけ)


またElasticsearch 5.0になれば、先に紹介したIngest Nodeという機能のおかげでLogstashなしでもログの解釈などができるようになるため、
Filebeatから直接Elasticsearchに転送することができるようになります。簡易的なログ分析であれば、そのような形式の方が楽でしょうね。

逆に、より規模が大きくなって、ログの転送し損ないが許されない状況下では、
Kafkaのようなバッファを挟んで過負荷に耐えられるようにしなくてはいけません(←しつこい)

その点も考慮して、Beats 5.0ではElasticsearch、Logstashに加えて、
Kafkaへの転送機能も付くそうです(っていう事をクラスメソッドさんのブログで知りました!)
dev.classmethod.jp

Create your own beat!

Beatsのようなプロダクトは、自分でエージェントないしプラグインのようなものを作りたくなるものです。
コミュニティベースのBeatsも既に14種類ほど作られており @ さんの作成したHsbeatもそのうちの一つとして紹介されていました。
f:id:acro-engineer:20160218195430j:plain:w480


Beatsは正式に作り方が公開されており、Generatorも提供されています。
github.com


またBeats Packerというビルドツールも提供されています。
これは自作したBeatsを各プラットフォーム用のバイナリをクロスコンパイルして作成したうえ、
RPMDEBも作ってくれるスグレモノです。
github.com
Beats PackerはTravis CIからも実行できるようにしているなど、至れり尽くせりなようです。
なるほどですね。


ただBeatsは今後コミュニティベースでどんどん数が増える一方で、よくある放置状態になるのではないか、という懸念も湧いてきますよね。
そこに対する解の一つが、Metricbeatだと思います。

きちんと管理されるMetrisbeat

Metricbeatは様々なミドルウェアの情報を収集するモジュールでありライブラリです。
最初にApache / Redis / MySQL / Golangに対応させようとしているようです。

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

こちらはElastic社が管理するプロダクトになり、Metricbeatに対する拡張を作りたい場合は、Elasticのgithubにプルリクする形になります。


そんなMetricbeatですが、そもそもミドルウェアの情報はどうやって取ってくるの? というのが当然の疑問になります。
セッション後にスピーカーに聞いてみたところ、それぞれのミドルウェアに定期的にメトリクス情報を取りに行く形を採用しているとのこと。
ソースも合わせて確認してみたら、Apacheならserver-status?autoを叩くとか、Goならexpvarのmetricsを使うとか、そういう形になっていました。なるほどですね。


なんか全体を通じて、なるほど感のあるセッションでした。変に奇をてらわずに、実直にデータを集める、抜けを防ぐ、そして管理する。
Beatsは今後も安定したエージェントとして活躍してくれそうな予感がします。


それでは本日のセッションレポートは以上になります。
また明日のレポートも楽しみにしてください。

Stay elastic, see you!

Elastic{ON} 2016レポート What's Cookin' in Kibana #elasticon

続いては、Kibanaのプロダクトセッション。
キーノートでも一番プッシュされていたのはKibanaでしたし、Elasticスタックの中でいま一番ホットな感じがします。

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

そんなKibanaのこれまでと、これからです。

Hack the Kibana!

Kibanaが可視化のためのWebアプリであることは既に皆さんご存じのことと思いますので割愛して、Kibanaアプリの作り方からです。

ところで、なんだかKibanaアプリなのかKibanaプラグインなのか、割と表記揺れしててはっきりしないのですが、
基本的には同じモノを指しているんだろうなというのが今の感覚です。

さて、KibanaアプリはAngular + node.jsの組み合わせで作られており、自分で開発することも可能です。
アプリのひな形を作るYeoman Generatorが用意されており、それを使った作り方が紹介されました。

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

一番大事なところだけ抜粋すると、

yo kibana-plugin 

ということで、yoしましょう。

セッション中には、Hot Keyを作るサンプルが紹介されました。

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

サンプルは、この辺りを見ると良いとのことです。
https://github.com/simianhacker/kibana-hacks
https://github.com/rashidkpc/kibana-hacks


また、3日目の金曜日には、Kibanaプラグインを作ることに主眼を置いたセッションが行われるとのことなので、
割とガチでKibanaアプリを作らなくてはならない状況の僕としては、そちらも参加しようと思います。

What's new in Kibana 5.0?

続いてKibana 5.0の新機能。
Kibana 5.0は、とにかく見た目がシンプルになって、無駄な余白がなくなったことが大きいです。

f:id:acro-engineer:20160218185025j:plain:w480
そうなんです、Kibanaを業務で使い始めると、たくさんグラフを置いたダッシュボードなどを作りたくなり、そうすると余白が邪魔だなと思うようになるんです。
そういう点で、5.0の新しいUIはとても良い印象です。


しかもKibana 5.0は4.x系と完全な後方互換を保つとのこと。マジか。
Elasticスタックはとにかく後方互換を切り捨てることでスピーディーに進化してきている印象でしたが、
ここに来てさすがに「切り捨て過ぎ」の声も大きくなってきたのでしょうか。

とにかくこれも重要なポイントです。


また、KibanaはAppliation Orientedな構成になります。Marvel、Sense、Timelionなどなど、
いずれもKibana本体ではなく、プラグインであるKibanaアプリとして提供されています。

f:id:acro-engineer:20160218185055j:plain:w480
元々、プラグインは非推奨だと言われていた3.x系の頃から、4.x系ではプラグインを正式に作れるようになり、
5.x系ではアプリが中心と謳われるようになったうえ後方互換を保つなど、かなりの力の入れようです。


ということで、全体を通じてKibanaアプリに主眼を置いたような内容でした。
ちょうど僕も業務でKibanaアプリを開発しようとしている所で、バージョンアップ追従が大変なことを懸念していたのですが、
昨今の様子を見ていると、割とそこは気を遣ってもらえるのかな・・・と思えるようになりました。

まぁそう思ってたら、いきなりハシゴが外されちゃうのが、Elasticのスリリングなところですけどね!

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

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

Elastic{ON} 2016 キーノートレポート Elastic goes 5.0! #elasticon

いよいよ始まりました、Elastic{ON} 2016 サンフランシスコ。キーノートセッションで開幕です。

f:id:acro-engineer:20160218163338p:plain:w600

イベント会場には「Elastic Cloud」や「X-Pack」という聞き慣れないプロダクトの垂れ幕が出ていたので、これらがいったい何なのか、始まる前からワクワクです。
f:id:acro-engineer:20160218163044p:plain:w300
f:id:acro-engineer:20160218163048p:plain:w300

Elastic stack goes 5.0

まず最初の大きなアナウンスは、Elasticのプロダクト群がバージョン統一されること。
現行では、Elasticsearch 2.2 + Logstash 2.2 + Kibana 4.4 + Beats 1.1という感じでバージョンの付け方がバラバラでしたが、次のメジャーバージョンは「5.0」として全プロダクトのバージョンが統一されます。
f:id:acro-engineer:20160218163555j:plain:w480


これに合わせて、各プロダクトのロゴも一新。これまでデザインがバラバラで、何種類かあったりなかったりの製品ロゴも、同じテイストで統一されました。

元々はこんな感じのロゴ多すぎ問題がありましたが。
f:id:acro-engineer:20160218163432j:plain:w480

こんな風にすっきりします。
f:id:acro-engineer:20160218163632j:plain:w480

また、Elasticsearch + Logstash + Kibanaを合わせてELKスタックと呼んだり、そこに後からBeatsを加えてELKBやKELBと呼んだりしていましたが、これからはElastic stackという呼び方に変わります。
f:id:acro-engineer:20160218163713j:plain:w480
ELK B(ee)のアイコンは初めて見ましたが、これで見納めになりました。


5.0系では、Kibanaが独自のタイルの上にヒートマップを作る機能や、タグクラウド機能の追加。
f:id:acro-engineer:20160218164015j:plain:w400
f:id:acro-engineer:20160218164021j:plain:w400

Logstashのさらなる性能改善。
f:id:acro-engineer:20160218164051j:plain:w400

Metricbeatによるモニタリングの統一。
f:id:acro-engineer:20160218164102j:plain:w400

などなどが発表されました。
これらはこの後の各セッションでも詳細が紹介されるはずです。

Packs and X-Packs comes

続いて、Packsの紹介です。
Elasticスタックのプラグイン群をひとまとめにしたもので、プラグインの導入を容易にする狙いがあるようです。
f:id:acro-engineer:20160218164219j:plain:w480

これまでは、たとえばMarvelというモニタリングプラグインを導入するには、ElasticsearchにMarvel AgentとLicenceプラグインを入れて、KibanaにMarvelプラグインを入れて、、、という感じで、それぞれのプロダクトにそれぞれのプラグインをインストールする必要がありました。

Packsはこれを容易にするもので、単一のzipファイルに全プラグインを入れて、これを一気にインストールできるようにする、というものです。


そんなPacksの一つの形が、X-Pack。
Shield、Watchr、Marvelなどの商用プラグイン群を一つにまとめたもの。このX-Packには、さらにPDFレポート作成機能や、グラフAPI(いわゆる有限グラフの方)なども含まれます。
f:id:acro-engineer:20160218164244j:plain:w480

PDFレポートはガチに仕事で必要になるやつですし、グラフAPIも注目度は高いです。
f:id:acro-engineer:20160218164454j:plain:w480
こんなグラフが拡大/縮小しながらグリグリ動くんですよ!

ただこれらは商用サポートが必要になる(はずです)ので、興味を持った方はぜひ導入をご検討のうえ、販売代理店である弊社にご連絡いただければ僕が大いに喜びます。わーい。

Found is now Cloud

ElasticsearchをSaaSとして提供する、Foundというサービスがあります。
Foundという名前の割に見つけるのが難しい(hard to find)サービスなのですが、これの名前が変わります。

変わった名前は、Elastic Cloud、通称Cloud。
f:id:acro-engineer:20160218164739j:plain:w480
残念ながら見つけにくさに変わりはありませんでした。
むしろ検索してもAWSのサイトにしか行けなくなる気がしてなりません。

たまたま最近Foundのトライアルに申し込んだところでしたので、早速Cloudにログインしてみたところ、サイトが刷新されており、テイストが5.0系のものになりました。ただ、いまのところ機能的には既存のFoundと同じでした。


そして、このCloudを自前でホスティングできるようになるサービスが、Elastic Cloud Enterprise。
AWSやAzuleにインストールして、クラスタを作って管理することができるようになるプロダクトです。
f:id:acro-engineer:20160218164933j:plain:w480

私の仕事上の経験でも、ひとたびElasticsearchを使い始めると、他の部門から「こんな可視化ができないか」「うちもやりたい」などと声が掛かるようになります。これまでは、同じElasticsearchに相乗りさせたり、それぞれごとにサーバを立てて管理したりしていたのですが、Elastic Cloud Enterpriseは、そういう用途で使えるものになりそうです。

ライセンス費用が気になるところなので、継続的にウォッチしたいと思います。

最後に、IBMのデモ

最後に、プラチナスポンサーのIBMによる、IBMでのElasticsearchの利用について。
アプリケーションのログをいったんKafkaに入れて、そこからLogstashを経由して、データストレージとElasticsearchに転送しているようです。
f:id:acro-engineer:20160218165133j:plain:w480

このような規模が大きいElasticsearchの事例など聞くにつれ、間に挟むログストリームのハブというか、中間バッファは、Kafkaで決まりという感じがしますね。
名前的に過負荷にも強そうですしね。ズコー。


という感じでオチもついたところで、キーノートセッションのレポートは以上としたいと思います。
この後も、楽しそうなセッションが目白押しですよ!

See you!