【速報】Elastic Stack 5.0.0-alpha1がリリースされました

藤本 真司

2016.04.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

※ 現在、α版のため、GAまでに実装が変わる可能性があることはご了承ください。

はじめに

藤本です。

遂に来ました！！Elastic{ON}2016で発表されて一ヶ月半！！

α版ですが、Elastic Stack 5.0.0がリリースされました。Elastic{ON}2016で発表されていたロードマップのあんな機能や、こんな機能が触れるようになりました。

既に日本語の記事は@johtaniさんが翻訳済みです。

概要

本エントリではまずリリースされたことをお伝えするとともに私が注目する機能をご紹介します。
各種機能レビューは別途試して、エントリします。

Elasticsearch 5.0.0

Ingest Node

ElasticsearchはNodeの役割にData、Master、Client、Tribeがありましたが、5.0.0でIngestの役割が追加されました。
Ingest NodeはElasticsearchにIndexされるドキュメントに対してデータの加工を行うことができます。例えば、Logstashのgrok、split、dateといったFilterの作用をElasticsearchで動作させることができます。

現在、データの加工の種類（Processor）は以下がサポートされています。

これにより特に期待することがBeatsから送られたデータの加工です。Beatsは現在、データ取得・送信だけに集中させることでサーバへの影響・負荷を限りなく低くし、動作するようになっています。そのため取得したデータを加工したい場合、LogstashやFluentdを経由させる必要がありました。LogstashやFluntdを経由する場合、加工用にサーバを立てなくてはいけなかったり、そのためにSPOFのポイントができ、可用性を下げたりが懸念されました。
それがIngest Nodeが加わることでデータを加工したい場合でもBeatsからLogstashを経由することなく、Elasticsearchへ直接データを送信し、ElasticsearchのIngest Nodeでデータを加工することが可能となりました。

またAWSで言えば、AWSのリソースがS3に出力するログファイルをKibanaで可視化したいユースケースがあります。その場合、私はS3 PutObjectイベントをトリガーに、AWS Lambdaでメッセージを取得、パース、Elasticsearchへの出力を実装しています。そのパース処理をElasticsearchへオフロードできれば、処理制限時間(5分間)や時間課金といった課題への有効な対策となります。

Painless Scripting

ElasticsearchはAPIにScriptを利用することが可能でした。
2.x系までは対応言語として、Goovy、Javascript、Pythonをサポートしていました。
5.0.0からは早い、安全、安心なElastic独自のPainless Scripting Languageが追加されました。構文はJavascriptやGroovyに似ているようです。

動的型付けで可読性の高いコードも書ければ、静的型付けで高速に動作するコードも書けます。動的型付けと静的型付けで10倍ぐらい処理速度が変わることがあるとのことなのでまずは動的型付けでプロトタイプを書いてみて、実運用時は静的型付けで書くのが良いようです。

Logstash 5.0.0

Monitorig API

LogstashがAPIに対応しました。データ送信が役割のLogstash。止まったり、過負荷により落ちるとデータロストの危険がありますよね。そのために監視関連のAPIが実装されました。。

  • Root Resource API
    Logstashノードの情報を取得します。Elasticsearchの/と同じような情報を取得できます。

  • Plugins API
    Pluginの情報を取得できます。

  • Stats Info API
    Logstashを起動してから発生したイベント数、jvmのステータスを取得することができます。イベントは入力、フィルタ、出力それぞれの数を取得することができます。jvmはJVM statsやGCの情報を取得することができます。

GET /_node/stats/events

{
    "events": {
        "in": 91,
        "filtered": 91,
        "out": 91
    }
}

GET /_node/stats/jvm

"jvm":{
   "timestamp":1453233447702,
   "uptime_in_millis":211125811,
   "mem":{
      "heap_used_in_bytes":58442576,
      "heap_used_percent":5,
      "heap_committed_in_bytes":259522560,
      "heap_max_in_bytes":1037959168,
      "non_heap_used_in_bytes":56332256,
      "non_heap_committed_in_bytes":57475072,
      "pools":{
         "young":{
            "used_in_bytes":41672000,
            "max_in_bytes":286326784,
            "peak_used_in_bytes":71630848,
            "peak_max_in_bytes":286326784
         },
         "survivor":{
            "used_in_bytes":260552,
            "max_in_bytes":35782656,
            "peak_used_in_bytes":8912896,
            "peak_max_in_bytes":35782656
         },
         "old":{
            "used_in_bytes":16510024,
            "max_in_bytes":715849728,
            "peak_used_in_bytes":16510024,
            "peak_max_in_bytes":715849728
         }
      }
   }

curl localhost:9600/_node/hot_threads?human

Hot threads at 2016-03-30T20:08:22-07:00, busiestThreads=3:
     5.22 % of of cpu usage by waiting thread named '[main]>worker3'
        java.lang.Object.wait(Native Method)
        java.lang.Object.wait(Object.java:460)
        org.jruby.RubyThread$SleepTask.run(RubyThread.java:1050)
        org.jruby.RubyThread.executeBlockingTask(RubyThread.java:1066)
        org.jruby.RubyThread.wait_timeout(RubyThread.java:1414)
        org.jruby.ext.thread.Queue.pop(Queue.java:152)
        org.jruby.ext.thread.Queue.pop(Queue.java:127)
        org.jruby.ext.thread.SizedQueue.pop(SizedQueue.java:111)
        org.jruby.ext.thread.SizedQueue$INVOKER$i$pop.call(SizedQueue$INVOKER$i$pop.gen)
        org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
     2.44 % of of cpu usage by timed_waiting thread named '[main]-pipeline-manager'
        java.lang.Object.wait(Native Method)
        ....

そういえば、DeatLetterQueueやDiskバッファの機能もリリースに含まれているのかな。

Kibana 5.0.0

A new design

画面UIのデザインが変わりました。一言で言うならば、ポップになりました。

新しいデザインに関してはKibana v5.0.0を触ってみた #elasticonのエントリをご参照ください。

Beats 5.0.0

Kafka output

Beatsは1.x系までは出力先にElasticsearch、Logstash、File、Consoleをサポートしていました。
Beats 5.0.0からはApache Kafkaへの出力をサポートしています。（Redisへの出力のDeprecatedも気づけば取りていました）
大規模環境ではElasticsearchがAPIを受け切れない問題が発生します。最悪データロストの危険性が発生します。Kafkaへの出力をサポートすることにより、Beatsからの出力にFast、Scalableが特徴のKafkaを挟むことで、データをロストしないようにします。KafkaからElasticsearchへはLogstashを並列実行などして、一定量のAPIをElasticsearchに送り続けることで安定したデータのインデックスが可能なのではないでしょうか？

Elastic{ON}2016の事例でもKafkaを利用しているケースは多いように見受けられました。

まとめ

いかがでしたでしょうか？気になる機能はありましたか？
新機能は多くありますので、リリースノートやドキュメントを眺めてみることをオススメします。

*

関連記事

ElasticSearchのDemo環境で、Kibana DevToolsのConsoleからcat APIを一通り叩いてみた。

横山嵩人

2023.05.19

ElasticSearchのDemo環境で、cat APIについて学んでみた

横山嵩人

2023.05.19