re:annkara

日々学んだことを書き留めておく。

第26回Elasticsearch勉強会に参加してきました。

だいぶ前の話なんですが、第26回Elasticsearch勉強会に参加してきたので簡単にまとめておこうかと思います。 こういった勉強会の内容ってすぐまとめるべきだと常々思っているのですが、知って満足してしまっているのかなかなか書く気になれないのです。 GoConferenceや本日と明日開催されるJapan Container Daysにも参加しているので、おいおいちゃんとまとめておきたいと思います。

当日の発表は3つあって、そのうち2つの発表資料は以下のリンク先に載ってます。 www.meetup.com

弊社でも最近オンプレ環境のKubernetesでWebアプリケーションを稼働させるという話が出てきており絶賛検証中です。 Kubernetes上でアプリケーションを実行させる場合、CI/CD、監視、メトリクスの収集やログ管理などの仕組みはKubernetes単体では提供しないので、自前で用意してあげないといけません。

私の場合ログ周りの環境を構築するということで、Elastic Stackを利用してアプリケーションログの一括管理などの仕組みを構築し検証してはいるものの、他社さんの事例などを知りたいと思い参加してきました。

こういった勉強会が都内で頻繁に開催されているのをみると、都内に勤めている人は羨ましいなぁと常々思います。

ということで以下当日のセッションの感想です。

(elasticビギナーが考えた)beatsを使った監査サービスの提案

一つ目はサーバの監査ログに関する発表でした。 最初はElastic Stackの存在を知らず、auditd + SCP で実装することを考えていたそうなのですが、Elastic Stack の存在を知りこちらを採用することを検討したそう。 自社でもアプリケーションログの収集に filebeat を利用しているのですが、Beats ファミリーの中に auditbeat というサーバの監査ログを収集するツールもあるそうで、この時初めて知りました。こういった自分が普段あまり関わることない分野に関して知ることができるのも勉強会のいいところだと感じました。 環境構築する際には、 Elastic Cloud というSaaSの利用を検討したそうなのですが、いざKibanaへとアクセスしようとすると、解放できるPortの問題で採用できず。。。ここらへんは、リバースプロキシを立てて、リバースプロキシ経由でKibanaにアクセスすれば良いと思ったのですが、きっと運用やコスト面で出来なかったんだろうなぁと思いました。

Logstashとともに振り返るやっちまった事例ごった煮

二つ目の事例もセキュリティ案件に関する事例でしたが、主にはLogstashの性能面に関する発表でした。 netflowから流れてくるネットワークトラフィック(約20,000/秒フロー!!)をLogstashで受け取る際に発生したデータロスについて、仮説を立て、チューニング(Logstash / カーネルパラメータ)を行うも改善せず、最終的にはサーバのスケールアップ/スケールアウトによって対処したというお話でした。

文章にまとめてしまうと非常に簡単そうに見えますが、自分もアプリケーションのパフォーマンスチューニングをやっていたこともあり、非常に苦労されたんだなと思いました。最終的にはLogstashサーバをスケールアウトすることにより解決を図っていますが、これがあらかじめ用意されていたリソース内でやりきれと言われていたらと思うとぞっとします。

テストの詳細な結果や環境構成等も載せてくれてますので、自社の環境を考える際の指標にもなるなと思い非常に参考になる発表でした。

ElasticsearchのQueryが遅い時のトラブルシューティング

クエリ遅いよ!!と言われた時のトラブルシューティングの方法についての発表でした。 Profile APIやProfiling Toolsが用意されていることを初めて知りました。 Elasticsearchもだいぶ奥が深いのでまずは公式ドキュメントをざっと眺めないとなぁと思いました。

凄いざっくりとした感想でしたが、改めて他社さんの事例を聞くことができて非常に学びある時間でした。 遅くなりましたが、主催者並びに発表者の方々、会場を提供してくださったFJCTさんには感謝しかありません。ありがとうございました!!