Tweet
Tweet

Slide 1

Slide 1 text

マゾいログ回収の話と未来 加藤慶一 株式会社フリークアウト 2014/05/13

Slide 2

Slide 2 text

about me

Slide 3

Slide 3 text

Norikazu Kato (@s_wool or s-wool) ログ @ フリークアウト fluentd, Hadoop, elasticsearch … 経歴 2011.04 グリー株式会社 とあるソーシャルゲームを運営 Treasure Dataの導入時にちょっと手伝ったり 2013.01 株式会社フリークアウト 5月くらいからログ担当 趣味：サバゲー

Slide 4

Slide 4 text

about

Slide 5

Slide 5 text

FreakOut 国内で初めてRTBによる広告枠の買付を行うDSPを開始 2011.01～ RTB -> Real Time Bidding DSP -> Demand Side Platform

Slide 6

Slide 6 text

RTB? DSP?

Slide 7

Slide 7 text

RTBの簡単なしくみ

Slide 8

Slide 8 text

RTBの簡単なしくみ この間大体100ms

Slide 9

Slide 9 text

50ms or die.

Slide 10

Slide 10 text

この記事がとてもわかりやすい http://blog.katty.in/5143

Slide 11

Slide 11 text

本もいろいろ

Slide 12

Slide 12 text

それはさておき

Slide 13

Slide 13 text

フリークアウトにおける ログ回収の歴史と fluentd(td-agent)

Slide 14

Slide 14 text

今の構成

Slide 15

Slide 15 text

現構成までのタイムライン 時期 トピック 2011.1  FreakOut RTB開始  rsyncによるログ回収 + MySQLへ格納 2012.11  fluentdの利用開始  一部のログをTDへ転送 2013.1  fluentdによる本格的なログ回収の開始  転送先はs3 + ログサーバー  Hadoop運用開始（CDH3） 2013.5  データセンター移行 2013.7  CDH4へアップグレード 2014.01  elasticsearch使い始める

Slide 16

Slide 16 text

2011

Slide 17

Slide 17 text

rsync + MySQL 入札、配信サーバーなどからログをrsyncでログサーバーへ転送 ログサーバーでサマリー作成（30分区切り） 今でも動いている

Slide 18

Slide 18 text

2012

Slide 19

Slide 19 text

fluentd使い始め 新機能開発時のログの格納場所に困り始める TDに白羽の矢が立つ

Slide 20

Slide 20 text

2013

Slide 21

Slide 21 text

fluentdによるログ回収の開始 s3（バックアップ用）とログサーバーへ転送 ログサーバーはtsv（hive用）にしてhdfsにput

Slide 22

Slide 22 text

＿人人人人人人人人＿ ＞ 突然のDC移行 ＜ ￣Y^Y^Y^Y^Y^Y^Y￣

Slide 23

Slide 23 text

DC移行 とあるDCからとあるDCへ 諸事情によりログサーバーから先に移行開始

Slide 24

Slide 24 text

DC間転送をどうするか VPNはあるけど お前それTB越えてて同じこと言えんの？

Slide 25

Slide 25 text

DC間転送をどうするか もともとS3に転送していたので 移行元DCにアグリゲーションノードを用意し S3を挟んでログサーバーへ転送

Slide 26

Slide 26 text

移行中の構成

Slide 27

Slide 27 text

CDH4 CDH4.3へアップグレード マスターノード系を分割 スレーブノードも一気に増築

Slide 28

Slide 28 text

ちなみに スレーブノードは 自作機

Slide 29

Slide 29 text

CDH4 WebHDFSへ直接転送開始 fluent-plugin-webhdfs 分単位のtime_slice

Slide 30

Slide 30 text

このあたりでいろいろハマリはじめる out_s3が詰まる queue size exceeds limit アプリケーションサーバーでのログのparseがしんどくなる msgpackのunpackエラー aggregatorに飛んでくるデータが壊れてる？ LAの高まり

Slide 31

Slide 31 text

対処 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側で吸収（するつもり）

Slide 32

Slide 32 text

お世話になってます

Slide 33

Slide 33 text

2014

Slide 34

Slide 34 text

Elasticsearch 使用されているapiの状況をkibanaで監視 （fluentdとは関係ないけど）Hiveからログ加工して異常監視とかにも 使ってる

Slide 35

Slide 35 text

今後がんばりたい話

Slide 36

Slide 36 text

話は戻って

Slide 37

Slide 37 text

rsync + MySQL 入札、配信サーバーなどからログをrsyncでログサーバーへ転送 ログサーバーでサマリー作成（30分区切り） 今でも動いている

Slide 38

Slide 38 text

こういうこと

Slide 39

Slide 39 text

こういうこと ほぼ同じログ流してて リソースがもったいないね

Slide 40

Slide 40 text

解決への課題 現状すべての入札ログをfluentdで回収されてはいない 必要なカラム、必要ないカラムとかの精査 fluentdにやさしいログフォーマットへの統一 hiveにLoadされるまで分析できないデータになってる カラム増えた際の対応とか

Slide 41

Slide 41 text

解決から見える未来 リアルタイムな異常監視 ここでいう異常はシステムではなく、RTBの状況の監視 CPM, CTR, … 入札ロジック変更を即時に評価しよりよい入札へ

Slide 42

Slide 42 text

50ms or die. から芸術的な 1 impressionを