ログ収集・分析基盤の検討

今の会社では、自社のWebシステムをBtoBで販売してて、そのサーバ・インフラ周りの面倒を見てるけど、プロダクト数が10くらいあってサーバの台数も200台ぐらいになってきてる。

 

この台数を2人でプロダクト毎に担当分け。

 

プラットフォームは主にAWSを利用していて一部IDCフロンティアも利用している感じ。

 

そのIDCフロンティア側も自分が担当していて、サーバ台数が25台ぐらい、CMSのシステムでWEBサーバ20台、DBサーバ5台って感じ。

んで、WEBサーバ中でVirtualHostが60個ぐらい存在するんで、正味800サイトぐらい存在している計算。

その中でTVとかに公開されてちょっとアクセスが増えるとすぐにCPUが上がってくるんで、どのサイトが原因なのか確認してた。

でも、実際ログも60個ぐらいあるんでタイムスタンプが最新のログとか見て目星つける感じなので、あまり正確なもんでもなかったし、tailとかで内容見てるけどそもそもそのログじゃなかったときとか意味ないなー。とは思ってた。

そこで、EFK(ElasticSearch+Fluentd+Kibana)に代表される、ログの収集分析基盤を導入すれば傾向とか掴みやすいだろうと思ってちょっと検証してみた。

 

前にも試しで構築とかしてたけど、ElasticSearch辺りが面倒な印象だったけど、今はAWSElasticSearch Serviceがあるんでクリック数回で立ち上げれる。(さすがAmazon様)

なので、実際はFluentdの辺りだけを頑張った感じ。

もちろんこの本も参考にしました。

 

https://www.amazon.co.jp/サーバ%EF%BC%8Fインフラエンジニア養成読本-ログ収集~可視化編-現場主導のデータ分析環境を構築!-Software-Design-ebook/dp/B00MPDUQQI

 

まだ、正式に導入はできてなくて、検証の段階だけど、大量のVirtualhostがあった場合にも、アクセス先のホスト名とかもログに出してしまえばサーバ側でログを分割する必要がないんじゃないかな、って思う。

しかも、同じElasticSearchのインデックスに投げればサーバ全体での傾向や、複数サーバのログを合わせて分析してCMSシステム全体での傾向も可視化することができるってのはなんとなくわかってきた。

 

「なんとなく」ってのは、CMSのシステム自体にはまだ導入できていないので他のプロダクトのログを投入して試験的に分析しているかんじなので。。。。

あとは、今まではApacheLogViewerとかでグラフ化してたのが、ブラウザだけでリアルタイムにできるんでかなり調査、分析するなら便利。

 

サーバログインとか、コマンドとかわからない非エンジニアの人に対しても状況把握とかはしやすいだろうし、kibanaの使い方を覚えれば自分の希望する分析もできる。

 

今後クラウド化が進んでいくにつれて、AWS AutoScalingみたいにサーバ自体が永続的なものではなくなっているんで、ログみたいな「あまり使わないんだけど、すぐに捨てるわけにはいかない」データを外出しして活用できる仕組みないと運用系のエンジニアはキツくなっていくだろうな。

 

ただ、まだWEBサーバのログの活用方法まではちゃんとできてないんで、そこらへんのメリットを他のマネージャなどにアピールできないと本格導入ができないんだよなー。