2014年8月28日ヒカ☆ラボにて菊池氏に登壇頂いた際の資料です。

1. 1
Log にまつわるエトセトラ
2014.8.28@ ヒカラボ 菊池佑太

2. 2
Log の重要性

3. 3
話しません (´;ω; ｀ )
● GrowthHack
✔
Retention/ConversionUP 施策
✔
A/B テストによる UI 改善
●
可視化
✔
BI ツール

4. 4
サービス Log
広告 Log

5. 5
Page View (PV)
Impression (Imps)
Click (CTs)
Conversion (CV)

6. 6
アジェンダ
0. 自己紹介
1. Log を記録する
2. Log を集める
3. Log を集計する
4. Log を分析する
5. 質疑応答

7. 7
自己紹介
● 菊池佑太 @yutakikuc
●
EX. Yahoo! AD-Science
●
旅行で世界 30 都市制覇！
●
http://d.hatena.ne.jp/yutakikuchi

8. 8
経験のあるテクノロジー

9. 9
仕事内容
開発 20%
研究 10%
データ出し 10%
ログ調査 60%
開発
研究
データ出し
ログ調査
雑用がメイン
( ｷﾘｯ

10. 10
Log や Data を軽視する人
／）
／／／）
／ ,.= ﾞ ''" ／
／ i f ,.r='"-‐' つ＿
/ / _,.-‐'~ ／⌒ ⌒＼
／ ,i , 二ﾆ⊃（ ●） . （●）＼
/ ﾉ il ﾞフ ::::::⌒ （ __ 人 __ ）⌒ ::::: ＼
, ｲ｢ﾄ､ ,!,!| |r┬-| |
/ i ﾄヾヽ _/ ｨ " ＼ ` ー '´ ／
Log はどうでもいいんだよ !!

11. 11
Log や Data 取得が後回しにされる理由
●
サービスの開発が最優先
●
無くてもサービスは動く
●
LogSystem の開発は簡単という誤解 ( 怒 )( 怒 )( 怒 )
●
UserData を取得すると User の入力負荷が高くなる
●
Data 分析方法が分からない

12. 12
Log エンジニアの現場人数
アプリエンジニアの
1/20

13. 13

14. 14
アジェンダ
0. 自己紹介
1. Log を記録する
2. Log を集める
3. Log を集計する
4. Log を分析する
5. 質疑応答

15. 15
Log の記録目的 ( 冗談 )
元気があれば何でもできる！
Log があれば何でも分かる！

16. 16
Log の記録目的 ( 真面目 )
Log ≒ Evidence
Log ⇒ Next Strategy

17. 17
大事な事なので 2 度言います
Log 分析は
サービス戦略に繋がる

18. 18
Log の記録で重要な事
3W1H (When,Who,What,How)
Log だけで情報が揃うように

19. 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 Values
host<^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. 20
どの Format が良いか？
●
Log 項目の付け足し / 削除は後から必ず発生する
●
Parse 後の添字参照 ( 順番依存 ) はキツい
●
Parse 後に連想配列 (key => value) 展開する
●
付け足しが発生しても順番依存が無い
●
人目で見ても項目が分かり易い
LTSVFormat がお勧め

21. 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. 22
BrowserID
UserID/Attribute
超重要

23. 23
何が美味しいの？
( 後で！ )

24. 24
「 mod_oreore 」による BrowserID 発行
●
Server への初回アクセス時に Cookie を発行する
●
ApacheModule だから楽
●
mod_usertrack,mod_session_cookie の不足点をカバー
●
https://github.com/yutakikuchi/apache_module.git
●
30 秒で設定可能

25. 25
UserID/Attribute の記録
●
UserID/Attribute は Login をした段階で Cookie に付与 ( アプリ
ケーションのレイヤーで実装 )
●
Hacking されないように変換や暗号化

26. 26
Cookie を Log に落とす

27. 27
LogServer 構成

28. 28
PV, Imps, Click, ConversionLog
⑤Staus:302
Location:Url
①Request
② HTML,PVBeaconURL
③BeaconRequest
④Click⑥Buy
⑦HTML,ConversionBeaconURL
⑧ConversionRequest
WebServer
PV/ImpBeacon
ClickRedirector広告主 Server
ConversionBeacon

29. 29
CTs と CVLog
もう少し詳しく

30. 30
Click 情報
どこに掲載したら押されたのか

31. 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. 32
ClickLog の失敗点
アプリエンジニアの実装にミスが発生する！
CTR 集計結果に影響が出る！！
戦略チームから @yutakikuc が怒られる！！！
@yutakikuc がアクセスログから実装ミスをカバーする！！！！

33. 33
ConversionLog に必要な事
●
( 外部 ) サイトに検知用 Beacon を設定してもらう
●
Log にどのサイトでどのような CV が発生したのか記録する
- Parameter で表現する
( 例 )<img src='http://cbeacon.hikalab.com?
siteid=25&productid=13&actionid=2&sign=hikalabo0828' />

34. 34
ConversionLog の活用
●
購入済み商品は Recommend の対象外
●
類似商品の Recommend
●
同じような行動履歴の User への Recommend

35. 35
「 Log を記録する」まとめ
●
Log 分析は戦略に繋がる
●
BrowserID,User,Attribute の記録
●
LTSV Format
●
Click,ConversionLog の記録

36. 36
アジェンダ
0. 自己紹介
1. Log を記録する
2. Log を集める
3. Log を集計する
4. Log を分析する
5. 質疑応答

37. 37
Log の管理構成
RealTime or Batch ?
Push or Pull ?
IP 制限
WebServer①
WebServer②
BeaconServer
Redirector
LogAggregator
MongoDB
FS
Redis
Batch
Mysql
LogFile 取得
集計値格納

38. 38
RealTime or Batch
Push 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. 39
RealTime Log 転送で気をつけたい事
●
処理が詰まらないように (Server 性能の限界を確認しておこう )
●
転送完了した Line 数を記録する
●
HotStandy の用意
●
Batch に切り替える手段を用意
●
小規模かつ重要でない Log から導入テストしてみるとか

40. 40
Batch Log 転送で気をつけたい事
●
Rotate 処理と転送処理の時間が重なった時の取りこぼし
※ チェックサムの確認
●
転送時間が大きくならない事
※ 複数のデータセンターへの転送
●
冗長化サーバー毎に転送開始時間をづらす
●
ファイルの圧縮

41. 41
広告配信での実例
Imps ： 500,000 、 Clicks ： 2000 、 Log 容量： 200M

42. 42
集計の土台
安定した Pull 型 Batch
※Batch は 1 日 1 回
広告主への正確なレポート提出のため
Rsync + FuelPHP Task

43. 43
+α
Imps,CTs は Push 型
RealTime 集計を準備中
※Imps 保証数を必要以上に超過させない
RealTime でのリターゲティング
Fluentd + fuent-plugin-redis

44. 44
強力ツールで出来ない事
●
ページ内コンテンツの配信数
●
Browser 毎の履歴集計
●
無料では出来る事が限られる
●
長期的なログ蓄積には不向き

45. 45
最小構成でも
トラフィック問題は
発生せず ... or2

46. 46
冗長化対応での問題
回収先サーバーの
追加設定漏れ

47. 47
「 Log を回収する」まとめ
●
回収方法の特性を理解
●
集計の土台は Pull 型 Batch で安定稼働
●
配信制御に関わる事は極力 RealTime で

48. 48
KPI / KGI

49. 49
アジェンダ
0. 自己紹介
1. Log を記録する
2. Log を集める
3. Log を集計する
4. Log を分析する
5. 質疑応答

50. 50
原始的な集計
cut -f 2 log | sort | uniq | wc -l

51. 51
強力なツール
※ 要件が合えば利用

52. 52
強力ツールで出来ない事
●
ページ内コンテンツの配信数
●
Browser 毎の履歴集計
●
無料では出来る事が限られる
●
長期的なログ蓄積には不向き

53. 53
BeaconTool(GA) と ServerLog の違い
BeaconTool ServerLog
0
200000
400000
600000
800000
1000000
1200000
1400000
1000000
1200000
300000
250000
PV
User
✔
ServerLog の PV 値は BeaconTool の 120% 程
✔
ServerLog の User 値は BeaconTool の 70% 程
✔
CSC と SSC : 表示数と Request 数の違い
✔
BeaconTool 集計は BlackBox
✔
通信 Error, noscript, 非対応機種 ...
✔
BeaconCookie と独自 Cookie の付与状況

54. 54
独自集計
ツールとの棲み分け
緊急性と重要度の判定

55. 55
緊急性と重要度
データの種類 データの項目 緊急性 重要度 格納先
広告 Imp 速報 高 中 Redis
広告 CTs 高 中 Redis
広告 効果レポート 低 高 Mysql
サービス PV 低 高 Mysql
サービス CTR 低 高 Mysql
サービス PV / UU / UB 低 高 Mysql
全て 生ログ 低 高 FS
全て 準生ログ 高 中 MongoDB

56. 56
Mysql は安定している
心配なのは Write 速度

57. 57
Mysql Table 設計
●
テーブル設計 = 集計する項目の決定
●
Relationは作らない
– 冗長的な登録は許容
●
古いデータは消す事が前提
– 日付のPartitioningでparge
●
複雑な処理は多段集計
– 1次集計Table、2次集計Table

58. 58
Mysql への Write
●
Batch 処理
✔ Batch で OnMemory( 連想配列 ) に集計結果を乗せてから BulkInsert
✔ Hadoop で集計し Sqoop で結果を Import
●
RealTime 処理
✔ RunTime で MongoDB へ格納。 MogoDB のデータを Batch で集計
し、 Mysql へ格納
✔ Mysql の BlackHoleEngine を利用。実体を Slave に
✔ 特定行数を一度 Queue/Summary して、 BulkInsert

59. 59
Redis の利用
●
データ管理を Memory と Storage の両方で旨くこなす凄い奴
●
大量データの INSERT/SELECT も Mysql より高速
●
Memory と Storage の両方から消えた場合が大変
●
広告の Imp 制御で利用
✔ 超過 Impは極力発生させたく無い
✔ RealTime で広告ID とImp した回数を書き込む
✔ 保険として Batch でも整合性を確認

60. 60
MongoDB の利用
●
スキーマ定義が不要でカラム追加の運用も要らない
●
大量データのInsertがMysqlより速い(SELECTは同等)
●
Index, Sharding等の機能もある
●
fnd条件指定が簡単でCross集計も可能(例. Android×LoginしているUB数)
●
データが消えるという事例報告がある
●
準生ログを保存(BIツールからのみ参照させる)

61. 61
速度担保への最終手段
サンプリング集計
※ 広告は除く

62. 62
「 Log を集計する」まとめ
●
集計の緊急度と重要度で集計方法を変える
●
Mysql の INSERT 速度が心配
●
MongoDB や Redis なんかも導入すると良い

63. 63
アジェンダ
0. 自己紹介
1. Log を記録する
2. Log を集める
3. Log を集計する
4. Log を分析する
5. 質疑応答

64. 64
BrowserID
UserID/Attribute
超重要

65. 65
何が美味しいの？

66. 66
その① 行動履歴の集約
識別子を key に sort で纏める
行動素性の抽出
MapReduce との相性

67. 67
その② 分類済み正解データからの推定
BrowserID : 1
UserID : A
女性 × 20 代
BrowserID : 2
UserID : ?
女性 ? 20 代 ?
@cosme
zexy.net
@cosme
zexy.net
？

68. 68
その③ User× デバイスデータ取得可能
1 人で複数台利用
(1 つの UserID での紐付け )
複数人で 1 台を利用
( 複数の UserID での紐付け )
※ 分析データから除外する

69. 69
性別推定 Model

70. 70
性別推定
●
性別に対してコンテンツや広告をtargetingしたい
●
性別が取れるUserは20%以下。推定によりRearchを増やす
●
2値分類(random推定でも50%)
●
仕組みが単純で高精度が望ましい
●
精度とカバー率の塩梅

71. 71
条件付き確率
●
推定手法の一例
その他決定木やVectorでの分類がある
●
仕組みが単純、実装しやすい
●
並列分散処理OK
●
P(C|D) P: 確率, C:カテゴリ, D:事象
例) 「サッカー」で検索したUserは80%男性である
●
対数化や正規化などの処理が最後に必要

72. 72
「 Naive Bayes 」
でぐぐれ！

73. 73
Model 作成と評価
●
素性はスペース区切り検索Query
●
訓練データ、推定対象データの準備 (過去28日間)
✔ 訓練データ: 性別が分かるBrowserID×Query
✔ 推定対象データ: 性別が分からないBrowserID×Query
✔ 複数のUserIDが紐づくBrowserIDは対象外
●
訓練データからModelを評価
✔ K-fold Cross Validation(k-1個のデータセットからModelを作成し、その他1個で精度評価)
●
Modelを使って推定対象データから予測
✔ 男性の確率:90%、女性の確率:10%

74. 74
毎日推定
●
2 年前は Oozie × Pig で素性抽出〜推定をやってました
●
今なら hivemall を使いますかね
●
R 言語でも簡単にできます
●
推定結果を Redis に格納

75. 75
精度とカバー率と配信の閾値
80% は女性と推定
精度 80% 以上のカバー率は 2 割
この人は女性で配信しますか？
配信側の閾値調整

76. 76
性別推定
●
性別に対してコンテンツや広告をtargetingしたい
●
性別が取れるUserは20%以下。推定によりRearchを増やす
●
2値分類(random推定でも50%)
●
仕組みが単純で高精度が望ましい
●
精度とカバー率の塩梅

77. 77
年代 (10 歳区切り ) 推定
マルチ分類への応用

78. 78
「 Log を分析する」まとめ
●
分類済み正解データの取得
●
推定により Reach 数を増やす
●
データセット作成、予測 Model 作成、推定
●
推定確率により配信する / しない

79. 79
以上

80. 80
質疑応答