一旦おしまい - Kibanaを立ててみた

Kibanaを立ててみた - なからなLifeにて当初予定していたもの全部は記事化できなかったのですが、一旦締めさせていただこうと思います。

以下テーマは、間に合わなかったので後ほど

Amazon Elasticsearch連携

AWS契約して、マネジメントコンソールからAmazonElasticsearchの画面に遷移して数クリックで立ち上がりますが、現時点で提供されているのが「5.3」まで、というのがちょっとね。

諸事情により、近々触る予定はあるので、その時の話をどこかでアウトプットできればと思います。
新しいの触った後に古いの触るの、複雑な心境ですね。

S3へアウトプットする

fluentdのプラグインリスト上にS3用は1つしかないので、これを入れて認証とS3 Buket情報入れてあげればいいだけなんですけどね。
実案件で使われている一方で、ほどよくテストできる環境がなかったので、一旦保留。

Kibanaでのグラフ作り

これ、ブログネタにしようとすると、ある程度具体的なシナリオと、それを表現するデータ、そして、大量の画面キャプチャが必要なんですよね。そこが最大のネック。
これもネタが用意できれば記事化しますが、ちょっと時間かかりそうです。

ずっと紹介してきたサーバ／インフラエンジニア養成読本ログ収集〜可視化編 [現場主導のデータ分析環境を構築！] Software Design plusにも、グラフづくりのあたりの説明はそんなにないのと、そもそも最近Kibanaのグラフ作りの操作仕様が結構変わってたりして、あんまり良い情報が揃ってないんです。

その点では、一度紹介したElastic Stackで作るBI環境　誰でもできるデータ分析入門 (NextPublishing)が、わりとしっかりページを割いて解説しているので、急ぐ方にはこちらをお薦めします。

一連の作業、記事化を通じての、雑感

まだまだ比較検証したほうがいいものはあるのでしょうし、扱ったものにおいても、深みの足りない部分があるかと思います。実運用をガチにやっていれば欠かせないであろうパラメータも、今回は殆ど取り扱っていません。fluentdやLogstashの場合、転送や加工の負荷を考慮して、各サーバーに入れたエージェントから、一旦収集転送専用のサーバーに転送して、そこで加工してからElasticsearchに流し込む、という構成も一般的なようですが、そういった話にも踏み込めていません。

その辺は、もう少し理解度、経験値が溜まってから触れられたらと思います。

それにしても、今回、一連のプロダクトを触ってみて、どれもセットアップはかんたんになっているなー、と関心しました。環境立てる「だけ」なら、どれも数分で終わりますね。

「サーバレスで数クリックで環境構築」とか言われても、「それコマンド数回叩けば終わるし」ってレベルまで来てます。

サーバレスのメリットは、立ち上げ後の運用面の自動化の方がより重要になってくる、というのは、elasticsarchに限った話ではないです。「マネージドサービス」と呼ばれる、そのマネージの内容が、よりシビアに評価されていくようになるのかなと。

あと、結果的にサーバレスやXaasなものを使うことになったとしても、オンプレな状態で一通り手を動かしてみるというのは、やはり大事だなと思いました。ちょいちょいハマリどころでどっぷりハマって、新しいことを身に染み込ませていくわけです。

そして、今回全然触っていない、システムの成長にあわせたスケーラブルな構成のための設定なんかも重要になってきます。
そういうハマリどころ、ややこしいことの多くを最初からやらなくて良くしてくれているのがマネージド・サービスなわけで、本家のElasticCloudだったり、Amazon Elasticsearch Service（Amazon ES）だったりするわけです。

オンプレ構築・運用のツラみを知ってこそ、マネージド・サービスのありがたみ、何がメリットなのかが、よくわかるというものでしょう。

私自身はMySQLもいじっていて、一応検証用にPC上にVM立ててやってますけど、リードレプリカ立ててラグのこと気にしながらあれこれしたり、バックアップ・リカバリ計画立てたりするの、実案件でAmazon RDSにおまかせしてて、考えることが1/100くらいになって幸せを噛み締めてるところです。

マネージド・サービスで話を一番ややこしくしているのは、ElasticCloudもまたAWS上で展開されていて、それとは別にAmazon ESが提供されていることだったりして。:-p

クライアントサイドについては、日本ではfluentdが人気ですが、個人的にはLogstashが扱いやすいなと思いました。一番利用が多いファイル読み取りについても、fluentdのtailプラグインで指定するformatの正規表現まわりが意図したとおりに拾えなかったり、その他のプラグインを使うときも、「似たようなのがあった場合、どれを選んでよいか悩む」のもfluentdの特徴でしょうか。それだけプラグイン開発が容易であること、プラグイン開発含めたエコシステムが発達していることの裏返しだと思います。情報量の多さもfluentdに軍配が上がります。そのあたりも考慮しつつ、プロダクト選定をするのが大事かなと。

なお、今回、Kibanaを使う上でElasticsearchを立てるわけですが、Kibana用にIndex生成するという目的以外に全く使ってません。全文検索システムとして非常にパワフルなプラットフォームなのにもったいない！でも、語れるほどのノウハウもない！

本業がDBメインなインフラ屋さん？の私としては、全文検索はそれが得意なシステムに任せたほうがいい、と思っていますので、そっちのノウハウも溜めていきたいと思います。