2014.8.28＠ヒカラボ 菊池佑太

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

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

3. 3
Log集計/解析
必要な事

4. 4
Webサービス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
経験のあるテクノロジー

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

11. 11
解決しなければならない
大きな問題

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

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

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

15. 15

16. 16
理解して欲しいこと
Logの重要性

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

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

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

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

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

22. 22
Logの種類と記録項目
● AccessLog
✔ RequestTime(When), RequestURI(What), Referer(How)
✔ AccessIP, UA
✔ ResponseTime, Status
✔ Cookie(Who)
✔ BrowserID
✔ UserID
✔ UserAttribute
✔ DeviceID(Who)

23. 23
ServerLogの種類と記録項目
● ErrorLog
✔ RequestTime, RequestURI, UA, Cookie
✔ ErrorLevel, ErrorFile&Line, ErrorComment
● ApplicationLog
✔ Applicationが特定の状況下で記録するLog

24. 24
BrowserID
UserID/Attribute
超重要

25. 25
何が重要なの？
(後で！)

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

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

28. CookieをLogに落とす
28

29. 29
Logに落とすCookieの例
oreore_cookie:id=MTkyLjE2OC41Ni4xMDE0MDkxMTk2ODQ
wMzg3MTMyMDE2NTQyNzI1MDMzMTY0OA..&attr=Mjg0Z
mUyMzk0Yzg0ZGIzZTIzYTI3N2ExYzhmYTZmMGY3Mzk1MjM
4Ng..
● id : TimeStamp + LocalIP + ProcessNum + ConnectionNum
● attr: UserID + Gender + Age をAES-CBCで暗号化

30. 30
LogFormat
● Default(Apache)
::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

31. 31
どのFormatが良いか？
● Log項目の付け足し/削除は後から必ず発生する
● 付け足しが発生してもParse後の順番依存が無い事
● 人目で見ても項目と値が分かり易い
LTSVFormatがお勧め

32. 32
LogServer構成

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

34. 34
CTsとCVLog
少し詳しく

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

36. 36
導入した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ツールで共有が必要(改善ポイント)

37. 37
Click検知の失敗点
アプリエンジニアの実装にミスが発生する！
CTR集計結果に影響が出る！！
戦略チームから@yutakikucが怒られる！！！
@yutakikucがアクセスログから実装ミスをカバーする！！！！

38. 38
CVLogに必要な事
● (外部)サイトに検知用Beaconタグを埋め込んでもらう
● LogにどのサイトでどのようなCVが発生したのか記録する
- Parameterで表現する
(例)<img src='http://cbeacon.hikalab.com?
siteid=25&productid=13&actionid=2&sign=hikalabo0828' />
● BrowserID等のCookieは当然記録する

39. 39
CVLogの活用
● Userの購入プロセスの状況把握
● 購入済み商品はRecommendの対象外
● 類似商品のRecommend
● 同じような行動履歴のUserへのRecommend

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

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

42. 42
Logの管理構成
RealTime or Batch ?
Push or Pull ?
IP
Restriction
WebServer①
WebServer②
BeaconServer
Redirector
LogAggregator
MongoDB
FS
Redis
LogFile
Reference
Batch Mysql
Save Result

43. 43
RealTime or Batch
Push or Pull
● RealTime(Fluentd,Storm)
✔ 即時集計/解析
✔ 一度の転送量を抑える
✗ Batchと比較して転送/解析の技術
ハードルが高い
● Batch(Rsyslog,[RD]sync)
✔ 定期集計/解析
✔ 安定した集計
✗ 一度の転送量が多くなる
● Push(Fluentd,[RD]Sync)
✔ 送信元ServerがLog転送する
✔ Logを出力=>転送が自然な流れ
✗ 送信元Serverの負荷が心配
● Pull(Rsyslog,Storm,[RD]Sync)
✔ 受信元ServerLogがLogを回収する
✔ メインの設定が受信元Serverで出来
る
✔ 送信元Serverの負荷は軽減?
✗ 実装/設定が面倒

44. 44
RealTime Log転送で気をつけたい事
● 処理が詰まらないように(Server性能の限界を確認しておこう)
● 転送完了したファイル名とLine数を記録する
● HotStandyの用意
● Batchに切り替える手段を用意
● 小規模かつ重要でないLogから導入テストしてみるとか

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

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

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

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

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

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

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

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

53. 53
KPI / KGI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

68. 68
BrowserID
UserID/Attribute
超重要

69. 69
何が重要なの？

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

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

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

73. 73
性別推定

74. 74
性別推定
● Userの性別に対してコンテンツや広告をtargetingしたい
●性別が取れるUserは20%以下。※Login必須サイトで無い場合
● 2値分類(random推定でも50%)
●仕組みが単純で高精度が望ましい
●精度とカバー率の塩梅

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

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

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

78. 78
毎日推定
● 次にオンラインで
● 2年前はOozie × Pigで素性抽出/Model作成/推定を完全自動化
● 今ならhivemallを使いますかね
● R言語でも簡単にできます
● BrowserIDを基に推定確率をRedisに格納

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

80. 80
気をつけたい事
●導入後のKPI変動の監視
✔ Targeting増 => CTs増 => CV下
✔導入前のシミュレーションも欠かさずに行う
●推定Modelの定期的な評価
✔完全自動化での安定運用のため

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

82. 82
「Logを解析する」まとめ
● 分類済み正解データの取得
● 推定によりTargeting数を増やす
● 素性抽出、推定Model作成、推定
● 推定確率により配信する/しない

83. 83
以上

84. 84
質疑応答