[デブサミ秋2015] 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ
•11 likes•5,293 views
Report
Share
Download to read offline
「新卒入社エンジニアが２年間fluentdを運用して学んだ事いろいろ」 グリー株式会社 開発統括本部所属 データエンジニア 山田 龍寛 ※Developers Summit 2015 Autumnでの発表資料です http://event.shoeisha.jp/devsumi/20151014/timetable
Recommended
More Related Content
What's hot
What's hot(20)
Viewers also liked
Viewers also liked(16)
Similar to [デブサミ秋2015] 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ
Similar to [デブサミ秋2015] 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ(20)
More from gree_tech
More from gree_tech(20)
Recently uploaded
Recently uploaded(8)
[デブサミ秋2015] 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ
- 1. Copyright © GREE, Inc. All Rights Reserved. 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ グリー株式会社 開発本部 山田 龍寛 @ Developers Summit 2015 Autum
- 2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 • 山田 龍寛 • グリー株式会社 開発本部 • 週末は野球か自転車か秋葉原 • 2013年新卒入社 • プロダクトが分析するためのログ を回収したり • 集計の手伝いをしたり • BIツールをつくったり • 気づいたらfluentdとは2年 の付き合い
- 3. Copyright © GREE, Inc. All Rights Reserved. グリーでの fluentd の利用方法 • サービスごとに数台のアグリゲーターを用意 • TreasureData や 内製のHadoopクラスタにデー タ転送 webサーバ アグリゲーター Copyright © 2014 The Apache Software Foundation. Apache Hadoop, Hadoop, Apache, the Apache feather logo, and the Apache Hadoop project logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and other countries.
- 4. Copyright © GREE, Inc. All Rights Reserved. fluentdの運用で こうした方がよいと思うこと
- 5. Copyright © GREE, Inc. All Rights Reserved. webサーバのfluentdの設定変 更が少ないかたちに
- 6. Copyright © GREE, Inc. All Rights Reserved. webサーバの設定変更が少ないかたちに • サーバ台数が多く再起動のコストが高い • プロダクト側がログを追加しやすく • データの保存先はtagを利用して決定 • アグリゲータで制御可能 webサーバ アグリゲーター 容易にログを増やせる ような設定にする 集計やtagの書き換えなど 複雑なことはこっちで
- 7. Copyright © GREE, Inc. All Rights Reserved. ログを追加しやすい設定例 • ログは基本的にJSONで • カラムの追加が容易 • アプリケーション側でtagをつけるようにする <source> type unix </source> 例１ <source> type tail format json path /path/to/log.json tag log </source> <match log> type rewrite_tag_filter rewriterule1 _tag ^(.+)$ db.$1 </match> 例２ tagとrecordを 自由に渡せる レコード内でテーブルに相 当するtagを指定する
- 8. Copyright © GREE, Inc. All Rights Reserved. プラグインをforkして改造しない
- 9. Copyright © GREE, Inc. All Rights Reserved. プラグインをforkして改造しない • fluentdのバージョンアップに追従しづらくなる • 例1: 拡張 out_webhdfs • 問題点 • fluentdのバージョンアップ時にデータが壊れてしまった • 本家のアップデートをマージするのが大変だった • 対応 • 一部のメソッドに変更点をまとめることができた • WebHDFSOutput を継承するようにした
- 10. Copyright © GREE, Inc. All Rights Reserved. プラグインをforkして改造しない • fluentdのバージョンアップに追従しづらくなる • 例2: 拡張 in_tail • 昔のfluentdの時から使ってる( fluentd-0.10.35 以前 ) • 問題点 • 公式のtailに追加された機能を取り入れるのが難しい • 内製のパーサが動かなくなった • 対応 • どうしようもなかった • 割りきって使っている • 運用でカバー • テストをたくさん追加した
- 11. Copyright © GREE, Inc. All Rights Reserved. プラグインで何でもできるからといって やり過ぎてしまうと後々つらい...
- 12. Copyright © GREE, Inc. All Rights Reserved. 公開されているプラグインを使う 機能追加は本家にコントリビュート シンプルな構成に留める
- 13. Copyright © GREE, Inc. All Rights Reserved. ドキュメントを書く(自戒)
- 14. Copyright © GREE, Inc. All Rights Reserved. まとめ • fluentdの運用でこうした方が良いと思うこと • webサーバのfluentdの設定変更が少ない形にする • プラグインをforkして改造しない • ドキュメントを書く(自戒) • なるべく公開されているプラグインを使う • 追加機能は本家にコントリビュート • シンプルに使う • 困ったら#fluentdをつけてtwitterでつぶやくと吉 : )
Editor's Notes
- それでは、新卒入社エンジニアが2年間fluentdを運用して学んだこといろいろと題しまして、発表いたします。
- 私はグリー株式会社、開発本部データエンジニアリンググループ所属、山田龍寛と申します。 2013年に新卒入社し、今の部署に配属となり、主にプロダクトの方達が分析するのをサポートしたりしています。 配属時からfluentdを扱うようになり、気づいたらfluentdとの付き合いは2年ほどになりました。 本日は、これまでfluentdを運用してきてこうした方が良いなと思ったことを簡単にですが紹介いたします
- 本題に入る前にまずは、グリーでのfluentdの利用方法について紹介いたします。 各webサーバにインストールされているfluentdでログを収集し、一度アグリゲータに集約して、それをTreasureDataや内製のHadoopクラスタに転送するという 非常にシンプルな構成で利用しています
- それでは、fluentdの運用でこうしたほうが良いと思うことをいくつか紹介していきます。
- まず１つ目は、webサーバのfluentdの設定変更が少ないかたちにしたほうが良い、ということです。
- webサーバ全台のfluentdの再起動はわりと作業コストが高く、 その作業がネックでプロダクトがイベントに合わせてログを追加するのを妨げるわけにはいきません。 そのため、webサーバ側の設定は、プロダクトにログを追加しやすいような設定にしています。 また、簡易集計などの複雑な処理はアグリゲーターで行うようにしています。
- 具体的にログを追加しやすい設定例を簡単に紹介します。 １つは、カラム追加に柔軟に対応ができるように、JSON形式でログを吐くようにすること。 もう１つは、保存先を決定するtagをアプリケーションでつけてもらうようにしています。 例えば、unix domain socktを利用すれば、tagとrecordをアプリケーションから自由に渡すことが可能です。 ほかにも、テーブル情報をレコード内に追加して、tagを書き換えることで、 fluentdの設定を増やすことなくレコードのルーティングをしています。 このようにして、プロダクトがログを追加しやすい設定にしています。
- もう１つのfluentdの運用でこうした方が良いとおもうことは、 pluginをforkして改造しない方が良いということです。
- pluginの自作が容易なのが、fluentdの魅力の１つですが、forkしてしまうとその後の保守コストが高くなりがちです。 グリーでもいくつかforkしているものがありますが、そうしたpluginの存在がfluentdのバージョンアップのしにくさの原因の１つだったりします 例えば、内製Hadoopにデータを転送するout_webhdsf pluginはforkして改造したものを利用しています。 tagを利用してファイルパスを生成するようになっており、非常に便利で強力なのですが、 fluentdのバージョンアップ時にデータが壊れてしまったり、本家のfluent-plugin-webhdfsのアップデートをマージするのが大変でした。 このpluginは、 変更部分が一部のメソッドに偏っていたので、本家のfluent-plugin-webhdfsを継承するように書きなおして 保守コストを少しでも下げるようにしました。
- もう１つ、古くからグリーで利用されていた形式のログを回収できるように改造したtail pluginが存在します。 fluentdの導入当初から利用されており、かかせないpluginなのですが、 公式のtail に追加された機能を取り入れるのが難しく、fluentdのバージョンアップ時にはパーサが動かなくなったりもしました。 こちらのpluginは、変更箇所が多く、切り出すことが難しかったため、割りきってそのまま利用しています。
- これらのpluginはなんとかなっているのですが、pluginで何でもできるからといってやり過ぎてしまうと後々つらいことになります
- こうした状態を回避するためには、 なるべく公開されているプラグインを使うようにする、 機能追加が必要な場合には、本家にpull reqを投げましょう。僕も助かります。 また、シンプルな構成に留めることも大切です
- #また、どうしても独自のpluginを作成しないといけない場合は、私もそうですが、ドキュメントを書いておきたいです。 あと、やっぱりドキュメントが大切だと思います。 後回しになりがちだし、なかなか手が進みませんが、、、がんばって書きましょう。 はい、書きます。すみません。 挙動よりもそれをつくった理由や経緯がわかると良いと思います。
- fluentdを2年運用して学んだこと、もとい、こうやって運用した方が良いと思うことを紹介させていただきました。 最後に、fluentdで困ったことがあったら #fluentdをつけてぼそっとついーとしてみたりすると良いことがあったりすると思います ごせいちょうありがとうございました。