logにまつわるエトセトラ
DESCRIPTION
2014年8月28日ヒカ☆ラボにて菊池氏に登壇頂いた際の資料です。TRANSCRIPT
1
Log にまつわるエトセトラ
2014.8.28@ ヒカラボ 菊池佑太
2
Log の重要性
3
話しません (´;ω; ｀ )● GrowthHack
✔ Retention/ConversionUP 施策✔ A/B テストによる UI 改善
● 可視化✔ BI ツール
4
サービス Log広告 Log
5
Page View (PV)Impression (Imps)Click (CTs)Conversion (CV)
6
アジェンダ0. 自己紹介1. Log を記録する2. Log を集める3. Log を集計する4. Log を分析する5. 質疑応答
7
自己紹介● 菊池佑太 @yutakikuc
● EX. Yahoo! AD-Science
● 旅行で世界 30 都市制覇！
● http://d.hatena.ne.jp/yutakikuchi
8
経験のあるテクノロジー
9
仕事内容
開発 20%
研究 10%
データ出し 10%ログ調査 60%
開発
研究
データ出し
ログ調査
雑用がメイン( ｷﾘｯ
10
Log や Data を軽視する人 ／） ／／／） ／ ,.= ﾞ ''" ／ ／ i f ,.r='"-‐' つ＿ / / _,.-‐'~ ／⌒ ⌒＼ ／ ,i , 二ﾆ⊃（ ●） . （●）＼ / ﾉ il ﾞフ ::::::⌒ （ __ 人 __ ）⌒ ::::: ＼ , ｲ｢ﾄ､ ,!,!| |r┬-| | / i ﾄヾヽ _/ ｨ " ＼ ` ー '´ ／
Log はどうでもいいんだよ !!
11
Log や Data 取得が後回しにされる理由● サービスの開発が最優先
● 無くてもサービスは動く
● LogSystem の開発は簡単という誤解 ( 怒 )( 怒 )( 怒 )
● UserData を取得すると User の入力負荷が高くなる
● Data 分析方法が分からない
12
Log エンジニアの現場人数
アプリエンジニアの
1/20
13
14
アジェンダ0. 自己紹介1. Log を記録する2. Log を集める3. Log を集計する4. Log を分析する5. 質疑応答
15
Log の記録目的 ( 冗談 )
元気があれば何でもできる！Log があれば何でも分かる！
16
Log の記録目的 ( 真面目 )
Log ≒ EvidenceLog ⇒ Next Strategy
17
大事な事なので 2 度言います
Log 分析はサービス戦略に繋がる
18
Log の記録で重要な事
3W1H (When,Who,What,How)
Log だけで情報が揃うように
19
LogFormat● Default
::1 - - [08/Feb/2014:21:32:10 +0900] "GET / HTTP/1.1" 403 5039 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
● Labeled Tab-Separated Values(LTSV)host:::1<Tab>ident:-<Tab>user:-<Tab>time:[08/Feb/2014:21:32:10 +0900]<Tab>Request:GET / HTTP/1.1<Tab>status: 403 <Tab>size:5039<Tab>referer:-<Tab>agent:curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
● ControllCharcter Separeted Valueshost<^B>::1<^A>ident<^B>-<^A>user<^B>-<^A>time<^B>[08/Feb/2014:21:32:10 +0900]<^A>Request<^B>GET / HTTP/1.1<^A>status<^B> 403 <^A>size<^B>5039<^A>referer<^B>-<^A>agent<^B>curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
20
どの Format が良いか？● Log項目の付け足し /削除は後から必ず発生する● Parse 後の添字参照 (順番依存 ) はキツい● Parse 後に連想配列 (key => value)展開する● 付け足しが発生しても順番依存が無い● 人目で見ても項目が分かり易い
LTSVFormat がお勧め
21
ServerLog の種類と記録項目1. AccessLog
– Request時間 (When), RequestURI(What), Access 元 IP, UA, Referer(How)– 処理時間 , ResponseStatus– Cookie(Who)
● BrowserID● UserID● UserAttribute
– DeviceID(Who)
2. ErrorLog– Request時間 , RequestURI, UA, Cookie– ErrorLevel, ErrorFile&Line, ErrorComment
3. ApplicationLog
– 特定の状況下で記録したい Data
22
BrowserIDUserID/Attribute
超重要
23
何が美味しいの？( 後で！ )
24
「mod_oreore」による BrowserID 発行
● Serverへの初回アクセス時に Cookie を発行する● ApacheModule だから楽● mod_usertrack,mod_session_cookie の不足点をカバー● https://github.com/yutakikuchi/apache_module.git● 30秒で設定可能
25
UserID/Attribute の記録
● UserID/Attribute は Login をした段階で Cookie に付与 ( アプリケーションのレイヤーで実装 )
● Hacking されないように変換や暗号化
26
Cookie を Log に落とす
27
LogServer構成
28
PV, Imps, Click, ConversionLog
⑤Staus:302Location:Url
①Request
②HTML,PVBeaconURL
③BeaconRequest
④Click⑥Buy
⑦HTML,ConversionBeaconURL
⑧ConversionRequest
WebServer PV/ImpBeacon
ClickRedirector広告主 Server
ConversionBeacon
29
CTs と CVLogもう少し詳しく
30
Click 情報
どこに掲載したら押されたのか
31
導入したClick検知方法● 外部Domainへの遷移検知には Redirector を入れる● Log にどのページのどのリンクが押されたのか記録する
✔ 予約Parameter(?__uri=hoo&__link=bar_1)✔ Click 計測用 Cookie(ClickCookie:__uri=hoo&__link=bar_1)✔ ※Referer は送信しないブラウザがあるので注意
● 識別子の付与は Javascript:Onclick() で出来ると吉● 集計処理で Parameter の値を CountUP● 識別子の管理が FE と BI ツールで共有が必要 ( 改善ポイント )
32
ClickLog の失敗点
アプリエンジニアの実装にミスが発生する！
CTR 集計結果に影響が出る！！
戦略チームから @yutakikuc が怒られる！！！
@yutakikuc がアクセスログから実装ミスをカバーする！！！！
33
ConversionLog に必要な事
● (外部 ) サイトに検知用 Beacon を設定してもらう
● Log にどのサイトでどのような CV が発生したのか記録する- Parameter で表現する(例 )<img src='http://cbeacon.hikalab.com?siteid=25&productid=13&actionid=2&sign=hikalabo0828' />
34
ConversionLog の活用
● 購入済み商品は Recommend の対象外
● 類似商品の Recommend
● 同じような行動履歴の Userへの Recommend
35
「 Log を記録する」まとめ
●Log 分析は戦略に繋がる
●BrowserID,User,Attribute の記録●LTSV Format●Click,ConversionLog の記録
36
アジェンダ0. 自己紹介1. Log を記録する2. Log を集める3. Log を集計する4. Log を分析する5. 質疑応答
37
Log の管理構成
RealTime or Batch ?Push or Pull ?
IP 制限
WebServer①
WebServer②
BeaconServer
Redirector
LogAggregator
MongoDB
FS
Redis
Batch Mysql
LogFile 取得
集計値格納
38
RealTime or BatchPush or Pull
● RealTime(Fluentd,Storm)✔ 即時集計 / 解析✔ 一度の転送量を抑える✗ Batch と比較して転送 / 解析の技術ハードルが高い
● Batch(Rsyslog,[RD]sync,Hadoop)✔ 定期集計 / 解析✔ 安定した集計✗ 一度の転送量が多くなる✗ Hadoop は ServerResource が心配
● Push(Fluentd,[RD]Sync)✔ 送信元 Server が Log転送する✔ Log を出力 =>転送が自然な流れ✗ 送信元 Server の負荷が心配
● Pull(Rsyslog,Storm,[RD]Sync)✔ 受信元 ServerLog が Log を回収する✔ メインの設定が受信元 Server で出来
る✔ 送信元 Server の負荷は軽減 ?✗ 実装 /設定が面倒
39
RealTime Log転送で気をつけたい事● 処理が詰まらないように (Server 性能の限界を確認しておこう )
● 転送完了した Line 数を記録する
● HotStandy の用意
● Batch に切り替える手段を用意
● 小規模かつ重要でない Log から導入テストしてみるとか
40
Batch Log転送で気をつけたい事● Rotate処理と転送処理の時間が重なった時の取りこぼし※ チェックサムの確認
● 転送時間が大きくならない事※ 複数のデータセンターへの転送
● 冗長化サーバー毎に転送開始時間をづらす
● ファイルの圧縮
41
広告配信での実例Imps： 500,000、Clicks： 2000、 Log 容量： 200M
42
集計の土台
安定したPull型Batch※Batch は 1日 1 回
広告主への正確なレポート提出のためRsync + FuelPHP Task
43
+αImps,CTs は Push型
RealTime 集計を準備中※Imps保証数を必要以上に超過させない
RealTime でのリターゲティングFluentd + fuent-plugin-redis
44
強力ツールで出来ない事●ページ内コンテンツの配信数
● Browser毎の履歴集計
● 無料では出来る事が限られる
●長期的なログ蓄積には不向き
45
最小構成でも
トラフィック問題は発生せず ... or2
46
冗長化対応での問題
回収先サーバーの追加設定漏れ
47
「 Log を回収する」まとめ
●回収方法の特性を理解●集計の土台は Pull型Batch で安定稼働●配信制御に関わる事は極力 RealTime で
48
KPI / KGI
49
アジェンダ0. 自己紹介1. Log を記録する2. Log を集める3. Log を集計する4. Log を分析する5. 質疑応答
50
原始的な集計
cut -f 2 log | sort | uniq | wc -l
51
強力なツール
※要件が合えば利用
52
強力ツールで出来ない事●ページ内コンテンツの配信数
● Browser毎の履歴集計
● 無料では出来る事が限られる
●長期的なログ蓄積には不向き
53
BeaconTool(GA) と ServerLog の違い
BeaconTool ServerLog0
200000
400000
600000
800000
1000000
1200000
1400000
1000000
1200000
300000250000
PVUser
✔ ServerLog の PV値は BeaconTool の 120%程✔ ServerLog の User値は BeaconTool の 70%程✔ CSC と SSC : 表示数と Request 数の違い✔ BeaconTool 集計は BlackBox✔ 通信 Error, noscript, 非対応機種 ...✔ BeaconCookie と独自 Cookie の付与状況
54
独自集計
ツールとの棲み分け緊急性と重要度の判定
55
緊急性と重要度データの種類 データの項目 緊急性 重要度 格納先
広告 Imp速報 高 中 Redis
広告 CTs 高 中 Redis
広告 効果レポート 低 高 Mysql
サービス PV 低 高 Mysql
サービス CTR 低 高 Mysql
サービス PV / UU / UB 低 高 Mysql
全て 生ログ 低 高 FS
全て 準生ログ 高 中 MongoDB
56
Mysql は安定している心配なのは Write速度
57
Mysql Table設計● テーブル設計 = 集計する項目の決定
● Relationは作らない– 冗長的な登録は許容
●古いデータは消す事が前提– 日付のPartitioningでparge
●複雑な処理は多段集計– 1次集計Table、2次集計Table
58
Mysql への Write● Batch処理
✔ Batch でOnMemory(連想配列 ) に集計結果を乗せてから BulkInsert✔ Hadoop で集計し Sqoop で結果を Import
● RealTime処理✔ RunTime でMongoDBへ格納。MogoDB のデータを Batch で集計
し、Mysqlへ格納✔ Mysql の BlackHoleEngine を利用。実体を Slave に✔ 特定行数を一度Queue/Summary して、BulkInsert
59
Redis の利用● データ管理をMemory と Storage の両方で旨くこなす凄い奴
● 大量データの INSERT/SELECT もMysql より高速
● Memory と Storage の両方から消えた場合が大変
● 広告の Imp 制御で利用✔ 超過 Impは極力発生させたく無い✔ RealTime で広告 ID と Imp した回数を書き込む✔ 保険として Batch でも整合性を確認
60
MongoDB の利用● スキーマ定義が不要でカラム追加の運用も要らない
● 大量データのInsertがMysqlより速い(SELECTは同等)
● Index, Sharding等の機能もある
●fnd条件指定が簡単でCross集計も可能(例 . Android×LoginしているUB数)
●データが消えるという事例報告がある
●準生ログを保存(BIツールからのみ参照させる)
61
速度担保への最終手段
サンプリング集計※広告は除く
62
「 Log を集計する」まとめ
●集計の緊急度と重要度で集計方法を変える●Mysql の INSERT速度が心配●MongoDB や Redis なんかも導入すると良い
63
アジェンダ0. 自己紹介1. Log を記録する2. Log を集める3. Log を集計する4. Log を分析する5. 質疑応答
64
BrowserIDUserID/Attribute
超重要
65
何が美味しいの？
66
その① 行動履歴の集約
識別子を key に sort で纏める行動素性の抽出
MapReduce との相性
67
その② 分類済み正解データからの推定BrowserID : 1
UserID : A女性× 20代
BrowserID : 2UserID : ?女性 ? 20代 ?
@cosmezexy.net
@cosmezexy.net
？
68
その③ User×デバイスデータ取得可能1 人で複数台利用
(1 つの UserID での紐付け )複数人で 1台を利用
(複数の UserID での紐付け )
※分析データから除外する
69
性別推定Model
70
性別推定● 性別に対してコンテンツや広告をtargetingしたい
● 性別が取れるUserは20%以下。推定によりRearchを増やす
● 2値分類 (random推定でも50%)
● 仕組みが単純で高精度が望ましい
●精度とカバー率の塩梅
71
条件付き確率●推定手法の一例その他決定木やVectorでの分類がある
● 仕組みが単純、実装しやすい
●並列分散処理OK
● P(C|D) P: 確率 , C:カテゴリ, D:事象例) 「サッカー」で検索したUserは80%男性である
●対数化や正規化などの処理が最後に必要
72
「Naive Bayes」でぐぐれ！
73
Model作成と評価●素性はスペース区切り検索Query
●訓練データ、推定対象データの準備 (過去28日間)✔ 訓練データ : 性別が分かるBrowserID×Query✔ 推定対象データ : 性別が分からないBrowserID×Query✔ 複数のUserIDが紐づくBrowserIDは対象外
●訓練データからModelを評価✔ K-fold Cross Validation(k-1個のデータセットからModelを作成し、その他1個で精度評価)
●Modelを使って推定対象データから予測✔ 男性の確率 :90%、女性の確率 :10%
74
毎日推定● 2年前はOozie × Pig で素性抽出〜推定をやってました
● 今なら hivemall を使いますかね
● R 言語でも簡単にできます
● 推定結果を Redis に格納
75
精度とカバー率と配信の閾値80%は女性と推定
精度 80%以上のカバー率は 2割
この人は女性で配信しますか？
配信側の閾値調整
76
性別推定● 性別に対してコンテンツや広告をtargetingしたい
● 性別が取れるUserは20%以下。推定によりRearchを増やす
● 2値分類 (random推定でも50%)
● 仕組みが単純で高精度が望ましい
●精度とカバー率の塩梅
77
年代 (10歳区切り )推定マルチ分類への応用
78
「 Log を分析する」まとめ
● 分類済み正解データの取得● 推定によりReach 数を増やす● データセット作成、予測Model作成、推定● 推定確率により配信する / しない
79
以上
80
質疑応答