Taste of Tech Topics

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

性能改善10事例

こんにちは、 @ です。

Acroquestでは、Elastic{ON}のような勉強会やカンファレンスに参加するだけでなく、社内向けの勉強会も開催しています。
新しい技術を調べて「使ってみた」的な発表をしたり、実際に開発の中で得られた知見を発表したり。
各自が得意分野で、様々なテーマで発表し、技術の研鑽を行っています。

私の場合、しばらく性能改善に取り組んでいたため、
その際に解決した問題からいくつか事例をフィードバックし、
性能問題を起こさないよう喚起しました。

www.slideshare.net

スライドでも書きましたが、特に大量に繰り返し実行される処理では、性能を意識した実装をしないと問題になりがちです。
問題があちこちに散らばると性能が大きく劣化し、解決も骨が折れます。
こういう問題は起こさないように、各チームメンバが気を付けて実装する必要があります。

ただ、もし、起きてしまった場合は、ENdoSnipeで解決するのがオススメです^^
www.endosnipe.com


それと、性能問題は解決が難しいケースもあります。
自力で解決できない場合は、JaTSサービスも是非ご利用ください!
jats.acroquest.co.jp

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

Elastic{ON} 2016レポート いよいよクロージング! #elasticon

最終日の今日は、朝食もランチも特別なものでした。
会場の外に何台かのバンが来ていて、それぞれのバンで、サンドイッチ、ピザ、ブリトー、ワッフル、ドーナツ、クレープなどを提供されていました。そこから自分で好きなものを(もちろん無料で)頼むのです。
f:id:acro-engineer:20160220190800j:plain:w480


しかも、美味しいんですよね。
というかelstic{ON}で提供される食事はだいたい美味しいんです。

同じサンフランシスコで開催される、僕がよく行くあのJavaイベントとは天と地の開きがありました。

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


要するに、Elastic{ON}最高です。

How to Build Your Own Kibana Plug-ins

さて、今日参加したセッションの1本は、Kibanaプラグインの作り方。
Kibanaプラグインの開発に使うツールや情報などは、次のURLからアクセスすることができます。

Some resources that are helpful for creating kibana plugins · GitHub



boilerplateはハックを作る時に使えるひな形です。
Kibanaの全画面に対して、ホットキーを設定したり、見た目を少し修正するなどの加工ができます。

こんな感じのindex.jsが提供されています。

export default function (kibana) {
  return new kibana.Plugin({
    uiExports: {
      hacks: [
        'plugins/my_plugin/hack'
      ]
    }
  });
}

どうやらuiExportsのhacksというのが、全画面に対するハックを行うもののようですね。


またgenerator-kibana-pluginは、Yeomanを使ったKibanaプラグインのGeneratorです。
https://github.com/elastic/generator-kibana-plugin

これを使うとSenseやTimelionのような、Kibanaプラットフォームを利用した独自アプリのひな形を生成することができます。

index.jsはこんな雰囲気です。

var exampleRoute = require('./server/routes/example');
module.exports = function (kibana) {
  return new kibana.Plugin({

    name: 'ceroplugin',
    require: ['kibana', 'elasticsearch'],
    uiExports: {
      app: {
        title: 'Ceroplugin',
        description: 'Cero-t's Kibana plugin',
        main: 'plugins/myplugin/app'
      }
    },
// (以下略)

uiExportsのappを使うことで、アプリを作ることができるようです。
Kibanaのプラグインとハックとアプリの区別がよく分からなかったのですが、この辺りを見てようやく分かりました。


なお、Kibanaプラグイン(ハック、アプリ)のフレームワークやテンプレートなどは、今後も変更されやすい点には注意が必要です。
ただ、generator-kibana-pluginは、元々は開発者個人が作ったツールでしたが、
現在はelasticの公式Githubリポジトリに移動され、バージョンも1.0.1となっています。
(セッションを聞いていた時点では1.0.0だったのですが)

そのような状況を見ていると、そろそろプラグイン開発を始めても大丈夫なのかな、という気になりますね。

B-b-b-b-b-beats! How to Build Your Own

Beatsの作り方のセッション。
キャパが30〜40名ぐらいの小さなブースで行われたのですが、立ち見が続出、入れずに諦める人が多数という、大人気セッションでした。
f:id:acro-engineer:20160220191025j:plain:w480

僕自身、Beatsを作ったことがあるということを事前にスピーカーの人と話していたため、「最前列の彼はBeatsを作ったことがあるんだ」など簡単に紹介される嬉しいサプライズもありました。


さて、Beatsの作り方は、基本的にGeneratorを使うのが良いです。
https://github.com/elastic/beat-generator

beat-generatorはcookiecutterというテンプレートツールを使っているので、先にインストールしておく必要があります。
Generatorを起動して、ウィザードに従って名前などを決めれば、設定ファイルやGolangソースのひな形などが生成されます。

以前、beatの作り方をこのブログにも書きましたが、その時にはGeneratorは存在していませんでした。なのでいずれ改めて、作り方の紹介エントリーを書きたいと思います。とっても簡単ですよ。


なおセッション中には、beatの出力先として、Elasticsearch、Logstashに加えて、RedisとKafkaに対応することも紹介されました。この辺りの出力先も、徐々に増えていきそうですね。

そして、クロージングキーノート。

嵐のような3日間は、最後のクロージングキーノートをもって閉幕です。

クロージングキーノートは、elasticのCTOであるShay Banonと、CiscoのCTOであるLew Tuckerのパネルディスカッションや、
会場からの質問に答えるという形で進みました。
f:id:acro-engineer:20160220191149j:plain:w480


OSS企業のあり方や、ビジネスモデルの考え方、またMicroserviceの捉え方などに話は広がりました。
また会場からの質問では、CTOになったけどプログラミングしたくならないかとか、
5年後のElasticsearchの姿はどうなっているのか、など、割と自由奔放な質問が飛びだしていました。
っていうか正味、ちゃんと聞き取れるわけないじゃないですか!!

特にElasticsearchのメインターゲットとなっている「Splunk」に対してどう考えているのかという質問では、
単にSplunk対抗のものを作っているわけではないし、
もし対抗するなら必要なものをリストアップして一つずつ実装していくけど、そのような事はしていないと明言していました。

あくまでも、Elasticsearchを中核として使いやすいものを作るということに注力しているとのことでした。


そんな形でクロージングキーノートも絞まり、いよいよElastic{ON}は閉幕です。
f:id:acro-engineer:20160220191311j:plain:w480


ところで、
Elastic{ON}の来場者の出身地ですが、当然トップの2つはアメリカとカナダ、それを追ってイギリスとドイツ。そして5位はどこでしょう? という質問が投げかけられたのですが・・・もしかして、、、と思ったら、やはり「日本」でした。

昨年はスタッフ以外の来場者が1人もいなかった日本ですが、今年は日本からの来場者がたくさんいます。
もちろんこれは、須田さんをはじめとした日本のelasticスタッフの貢献があってこそだと思います。


Elastic{ON}のサプライズを含むテクニカルな発表や、AMAのような納得度の高いコンテンツ、
また美味しい食事、そして美味しい食事など、とっても良いイベントでした。

僕自身、来年も参加したいと思いますし、またこのブログを読んで一人でも参加したいと思った方がいらっしゃれば、
夜な夜なブログを書いた意義もあったのかなと思います。

elasticの社員、Elastic{ON}のスタッフはじめ、参加者も含めてイベント関わった皆さん、お疲れ様でした&ありがとうございました!!

Stay elastic, see you!

Elastic{ON} 2016レポート AMA = Ask Me Anything! #elasticon

いよいよElastic{ON}も3日目、最終日を迎えました。

今日はライブコーディング中心のプラグイン開発セッションや、
AMA (Ask Me Anything) と呼ばれる自由にQ&Aができるブースで1日を過ごしました。

まずはこのAMAについてレポートしたいと思います。

AMA = Ask Me Anything

もしかすると、AMAこそがElastic{ON}の一番の目玉なのかも知れません。
会場にたくさん来ているelastic社のエンジニアに、直接、様々な質問ができるというブースです。
f:id:acro-engineer:20160220185359p:plain:w575

Elasticスタックのプロダクトやロードマップについて質問するのはもちろんのこと、
最近困っている不具合を目の前で見せて解決を依頼したり、
Elasticsearchを利用した独自プロダクトのアーキテクチャの相談をしたり、
とにかく何でも自由に質問できます。

サブスクリプションを買ったりコンサル費用を払うよりも、
Elastic{ON}で直接聞いたほうが安い(笑)と言われるぐらいにオススメの高いコンテンツのようです。

ここで聞いたことを、簡単に紹介します。

1. Timelionのグラフを、Kibanaダッシュボードに載せられるようになるぞ

Timelionを使い込んでいる皆様方におかれましては、TimelionのグラフをKibanaのダッシュボードに配置できないものかなと思っているかと思います。
その点をKibanaの開発者であるRashid Khan(@)に聞いたところ、「近々対応するつもり、今週もそれを作ってるんだ」と回答してくれました。
わーい。

2. Beatsの設定や管理も、中央集約されるぞ

今回のElastic{ON}の中で、Logstash 5.0になれば、Logstashの設定やステータス情報を個別に扱うのではなく、
Elasticsearchに集約する(そして各Beatsに配信する)ということが明言されていました。

しかしBeatsでは、そのような設定やステータスの中央集約は明言されていませんでした。

その辺りどうなのよと、Beatsの開発者であるMonica Sarbu(@)に聞いたところ、
まだその開発をスタートしてないけど、対応する計画をしているとのことでした。
5.0には間に合わないけど、バージョン5.1ぐらいの時点で提供したいとのことです。
わーい。

3. Kafkaが入った時のアーキテクチャは?

BeatsシリーズからKafkaに出力できるようになることは、以前のエントリーにも書いた通りです。
また、Elasticsearch 5.0のIngest Nodeを使えば、Logstashの加工の機能が必要なくなることも、前に書きました。

現在の構成では、たとえばFilebeatを使って、Kafkaを挟むと次のような形になります。

Filebeat → Logstash(加工) → Kafka(キュー) → Logstash(転送) → Elasticsearch(保存)

これが、BeatsのKafka連携機能と、ElasticsearchのIngest Nodeを使うと、このような構成にできます。

Filebeat → Kafka(キュー) → Logstash(転送) → Elasticsearch(加工、保存)

ただこうなると、Logstashが何のために存在するのか分からなくなるので、削りたくなります。

Filebeat → Kafka(キュー) → Elasticsearch(加工、保存)

こんなことができるのか、Monica Sarbuにぶつけてみました。


まず結論としては、できない。
やはりKafkaからElasticsearchに直接転送するような方法が用意されていないため、転送のためにLogstashを挟むことは必須のようです。

また、ElasticsearchのIngest Nodeで加工することは確かに可能だが、
より細かい制御が必要になる場合は、Logstashを使う必要があるんじゃないかという見解でした。
なるほどですね。

いずれにせよ、この件はしっかりと話ができたので、僕の中でも腑に落ちた感じになりました。


それ以外にも、JMX経由で取った情報をBeatsと連携させるパターンの相談や、
実際に業務上で困っていることなど、ちょっとここでは書けないようなことも色々と質問、相談させてもらいました。

それにしても、いつもは壇上や動画、あるいはツイッターの向こう側にいるエンジニアの方たちと、
マンツーマンでディスカッションできる機会というのは本当に貴重ですよね。

つたない英語でも一生懸命に聞いてくださいますし、とっても捗りました!

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!