もくじ
LINE Developer Meetup in Tokyo #27 -Elastic-
以下のイベントに参加してきました。
3つの発表が行われたのですが、今回はこのうち『ログ収集プラットフォーム開発におけるElasticsearchの運用』を聞きながら書いた僕のメモを公開していきます。
資料
発表資料はこちらで公開されています。発表資料と並行して見るのがいいかも。
www.slideshare.net
本
今回の勉強会で登壇したElasticの大谷さんが書いた本もあるようなので参考にしてみるといいかもしれません。
![データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]](https://m.media-amazon.com/images/I/51DaJ8XniUL.jpg "データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]")
以下僕のメモです
自己紹介
- 齋藤 智之さん
- LINE株式会社 開発3室
- LINEアプリまわりのログ収集だとかそういうところをやっている部署
概要
ラインサーバー開発者向けのログ分析環境
- talkサーバー
- Authサーバー
などなど向けのログ分析環境を提供する部署。
ログ分析インフラ
- elastic
- hadoop
- Apache kafka
などなどを部署として提供している。
システム
Log Producer→Apache kafka→Sink→elastic, hadoop, kafka 等...
ログを出しているサーバーからkafkaにメッセージ送信。Sinkというシステムががメッセージを受け取って各基盤に蓄積させる。
Apache kafka
- メッセージング。各種サーバーはログを一旦kafkaに送りつける
- Protocol Buffer を使ってkafkaに送りつける
protobuf
message RequestLog {
date
url
}
みたいな感じ。
ログ→Protobufの変換を行うSDKは開発3室が提供
sink
kafkaから受け取ったデータをelasticやhadoopなどに貯める。
課題
- ログの増加で管理コスト増加
- ヘテロジニアスクラスタ
index template
templateにマッチしたindexに設定を適用できる。
protobufのstringのフィールドをelasticのkeywordに変更するなど
また、protobuf上にelasticの型へのマッピング
elasticシャードのサイズをどうやって決定するか
シャード数が多くなるとオーバーヘッドが大きくなる シャード数が少なくなるとindexingに時間がかかるようになる
どうするか
- まずはできるだけシャード数をできるだけ少なくする
- indexingが分散されるようにシャード数を増やす
- 50GB/shardを目安にindex rolling periodを大きくする
課題
- 結局シャードあたりを考えるのにコストがかかる
- Rollover Index API（elastic 5.0 から実装されるとのこと） で size-base rolling
indexing throttling
Disk書き込みがボトルネックに。 segmentのmergeにindexingが追いつかない。
shard数を1から2に増やすと、diskが2つに増える。約1.4倍の高速化。
