マゾいログ回収の話と未来

Fluentd Meetup 新しい応用事例とv1に関する発表
http://eventdots.jp/event/49560

Transcript

1. マゾいログ回収の話と未来 加藤慶一 株式会社フリークアウト 2014/05/13
2. about me
3. Norikazu Kato (@s_wool or s-wool) ログ @ フリークアウト fluentd, Hadoop, elasticsearch … 経歴 2011.04 グリー株式会社 とあるソーシャルゲームを運営 Treasure Dataの導入時にちょっと手伝ったり 2013.01 株式会社フリークアウト 5月くらいからログ担当 趣味：サバゲー
4. about
5. FreakOut 国内で初めてRTBによる広告枠の買付を行うDSPを開始 2011.01～ RTB -> Real Time Bidding DSP -> Demand Side Platform
6. RTB? DSP?
7. RTBの簡単なしくみ
8. RTBの簡単なしくみ この間大体100ms
9. 50ms or die.
10. この記事がとてもわかりやすい http://blog.katty.in/5143
11. 本もいろいろ
12. それはさておき
13. フリークアウトにおける ログ回収の歴史と fluentd(td-agent)
14. 今の構成
15. 現構成までのタイムライン 時期 トピック 2011.1  FreakOut RTB開始  rsyncによるログ回収 + MySQLへ格納 2012.11  fluentdの利用開始  一部のログをTDへ転送 2013.1  fluentdによる本格的なログ回収の開始  転送先はs3 + ログサーバー  Hadoop運用開始（CDH3） 2013.5  データセンター移行 2013.7  CDH4へアップグレード 2014.01  elasticsearch使い始める
17. rsync + MySQL 入札、配信サーバーなどからログをrsyncでログサーバーへ転送 ログサーバーでサマリー作成（30分区切り） 今でも動いている
19. fluentd使い始め 新機能開発時のログの格納場所に困り始める TDに白羽の矢が立つ
21. fluentdによるログ回収の開始 s3（バックアップ用）とログサーバーへ転送 ログサーバーはtsv（hive用）にしてhdfsにput
22. ＿人人人人人人人人＿ ＞ 突然のDC移行 ＜ ￣Y^Y^Y^Y^Y^Y^Y￣
23. DC移行 とあるDCからとあるDCへ 諸事情によりログサーバーから先に移行開始
24. DC間転送をどうするか VPNはあるけど お前それTB越えてて同じこと言えんの？
25. DC間転送をどうするか もともとS3に転送していたので 移行元DCにアグリゲーションノードを用意し S3を挟んでログサーバーへ転送
26. 移行中の構成
27. CDH4 CDH4.3へアップグレード マスターノード系を分割 スレーブノードも一気に増築
28. ちなみに スレーブノードは 自作機
29. CDH4 WebHDFSへ直接転送開始 fluent-plugin-webhdfs 分単位のtime_slice
30. このあたりでいろいろハマリはじめる out_s3が詰まる queue size exceeds limit アプリケーションサーバーでのログのparseがしんどくなる msgpackのunpackエラー aggregatorに飛んでくるデータが壊れてる？ LAの高まり
31. 対処 out_s3が詰まる aggregatorでfluentdを複数起動する out_s3のnum_threadを増やす buffer_queue_limitを増やす td_monitor_agent便利 parseがしんどくなる tail時のformatをシンプルに hiveへのetl時に頑張ることに 複数起動しようとするとconfの管理とかが大変になる initスクリプトに手をくわえる # /etc/init.d/td-agent start conf-name confはpuppet側で吸収（するつもり）
32. お世話になってます
34. Elasticsearch 使用されているapiの状況をkibanaで監視 （fluentdとは関係ないけど）Hiveからログ加工して異常監視とかにも 使ってる
35. 今後がんばりたい話
36. 話は戻って
37. rsync + MySQL 入札、配信サーバーなどからログをrsyncでログサーバーへ転送 ログサーバーでサマリー作成（30分区切り） 今でも動いている
38. こういうこと
39. こういうこと ほぼ同じログ流してて リソースがもったいないね
40. 解決への課題 現状すべての入札ログをfluentdで回収されてはいない 必要なカラム、必要ないカラムとかの精査 fluentdにやさしいログフォーマットへの統一 hiveにLoadされるまで分析できないデータになってる カラム増えた際の対応とか
41. 解決から見える未来 リアルタイムな異常監視 ここでいう異常はシステムではなく、RTBの状況の監視 CPM, CTR, … 入札ロジック変更を即時に評価しよりよい入札へ
42. 50ms or die. から芸術的な 1 impressionを