Edited at

Elastic Stack にふれて


きっかけ

それまでサーバやアプリケーションのログをためるため elasticsearch 2.x を使っていました。サーバ9台(マスターノード2台、データノード6台、検索ノード1台)でクラスタを組んで運用していたのですが、2年ほどたってくるとindexやdocumentの数が増えてきて常にクラスタの負荷が高い状態になってしまっていました。うーん、なんとかしないとなと考えていたところ少し余裕ができたのでクラスタごと置き換えることにしました。とはいえ潤沢に時間があるわけではないのでデータの移行は考えず、新しいクラスタを作ってそちらに新しくデータを流しはじめることにしました。


Elastic Stackってなんだろう?

さてさてまずは情報集めです。情報を集めたときの最新バージョンは6.4でそれまで elasticsearch 2.x を使っていたのでだいぶバージョンアップが行われていました。とくに5.xからは elasticsearch 関連製品をまとめて Elastic Stack と呼ぶようになっており浦島太郎状態です。インストールマニュアルをみるといろいろな製品をインストールする必要があり以前よりハードルがあがっているなと感じながら、それぞれの役割を整理していきました。

製品名
役割
可動環境

Elasticsearch
データ保存と検索
Elastic Stackクラスタ

Kibana
データの可視化
Elastic Stackクラスタ

Logstash
データの変換
Elastic Stackクラスタ

Beats
データの収集エージェント
サーバ

可動環境はそれぞれの製品をどの環境にインストールして使うかです。Beats以外はElastic Stackクラスタを組むサーバに、Beatsはデータを収集したいサーバにインストールして使うことにしました。BeatsはさらにFilebeat、Metricbeatなど複数の製品にわかれています。


クラスタ構成

実際に新旧環境でデータの流れがどうかわったのかを図で説明します。


旧環境

サーバにインストールしたfluentdからfluentdのクラスタにデータを転送して、そこからElastichseachクラスタにデータを転送していました。

elasticsearch2x.png


新環境

サーバにインストールしたBeatsからElastic Stackクラスタにデータを転送するようになりました。

elasticseach6.4.png


まとめ

情報を整理する前は扱いが難しくなった印象があったのですが、整理してみるとそんなことありませんでした。個人的にはfluentdを使わなくて済むようになり、サーバにBeats製品のGoバイナリを置くだけでElastic Stackと連携できるようになったのは管理するサーバが減ってメリットだなと感じました。