サービス改善はログデータ分析から

15,739 views

Published on

2014/09/09に行われた『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念!執筆者が語る大講演会! での発表資料です。
http://eventdots.jp/event/137658

Published in: Technology
0 Comments
52 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,739
On SlideShare
0
From Embeds
0
Number of Embeds
3,781
Actions
Shares
0
Downloads
80
Comments
0
Likes
52
Embeds 0
No embeds

No notes for slide

サービス改善はログデータ分析から

  1. 1. サービス改善は ログデータ解析から 鈴木健太 @suzu_v 『サーバ/インフラエンジニア養成読本 ログ収集~可視化編』出版イベント 2014/09/09 @ GMO Yours
  2. 2. 自己紹介 • 鈴木健太, すずけん, @suzu_v • VOYAGE GROUPの子会社adingoにて、広告データの分析基 盤(DMP)構築とR&Dを担当しています • 特集1「ログ解析から始めるサービス改善」を担当しました
  3. 3. このプレゼンではEFKスタックにはあまり触れず、ログ分析全般の一般的な話をします
  4. 4. 事例: 広告の話
  5. 5. 広告データの分析とは? • どんなユーザにどんな広告を出したか • どんな枠にどんな広告を出した時に効果が高かったか • どんな案件だとどのようなユーザに対してコンバージョンが 多かったか • コンバージョンするまでにどんな過程を経ていたか • ユーザごとにどんなクリエイティブを出したら効果的か
  6. 6. 配信サービスの設計表裏一体 配信サービスのデータ
  7. 7. 分析結果の活かし方 1. 広告配信してみる 2. 結果を分析する 3. 再度配信してみる
  8. 8. 分析結果の活かし方 1. 広告配信してみる 2. 結果を分析する 3. 再度配信してみる 全てを1人でやることはできない
  9. 9. 分析結果の活かし方 1. 広告案件を取ってくる(営業さん) 2. 広告配信してみる(オペレータ) 3. 結果を分析する (データをみるアナリスト) 4. 手を変えて、(配信エンジニア) 5. 再度配信してみる(オペレータ) という流れを支えるのが分析基盤に携わるエンジニアの役割
  10. 10. データの分析は、チームでつくるもの そして、データを活かせるようにするエンジニアが必要
  11. 11. 解析のフェーズ 1. 収集 2. 変換 3. 保存 4. 分析 5. 表示 6. 運用 「分析力を武器とする企業」 第8章 p.246より
  12. 12. 解析のフェーズ 1. 収集: 収集すべきデータの定義、的確なデータの収集および管理 2. 変換: データの前処理・変換 3. 保存: データおよびメタデータ(データに関するデータ)の保存 4. 分析: データの分析 5. 表示: データの可視化・加工 6. 運用: セキュリティ、エラー検出・処理、プライバシー保護など 「分析力を武器とする企業」 第8章 p.246より
  13. 13. How どのように実現するか?
  14. 14. 手段の多様化と進化 Fluentd, LogStash, Flume, Elasticsearch, Kibana, S3, RiakCS, InflexDB, MongoDB, Hadoop, YARN, Tez, Presto, BigQuery, Spark, Apache Hive, Redshift, Netezza, PureData, Teradata, TokuDB, MySQL, PostgreSQL, Oracle, MicroStrategy, Tableau, Metrics Insight, QlikView, Pentaho, Jaspersoft, R, Norikra, Storm, Amazon Kinesis, 自前で作る, etc.. ログを集めて、データを貯めて、見えるようにして、管理しや すくして・・・
  15. 15. 「いろいろあってよくわからないから、 ログの分析はあとにして、 他の機能追加しましょう・・・・・」 という話になりがち
  16. 16. Try まず試してみよう
  17. 17. ログ解析を、とりあえず試す 1. 収集: とりあえず、Fluentd 2. 変換: とりあえず、Fluentd 3. 保存: とりあえず、Elasticsearch 4. 分析: とりあえず、Elasticsearch 5. 表示: とりあえず、Kibana 6. 運用: なんとかする とりあえずは、それでいいのです。
  18. 18. 「難しいしよくわからないから、 ログの分析はあとにして、 他の機能追加しましょう・・・・・」 「あ、Fluentdでログ拾ってたら とりあえず どうにかなるんじゃない?」
  19. 19. エンジニアだからこそ、最初の一歩を はじめてみよう • そこにデータがあって、手を動かせるのはエンジニア • そこにあるデータを、伝えることの出来る形に変えることが できるのもエンジニア • どんなデータがあるのかを知っているのもエンジニア まずはそこにあるデータを使えるようにすることが大事
  20. 20. とはいえコストをかけて、 なぜ可視化をするのか?
  21. 21. • 現状を知りたい • データがあるから見せたい • ビジネスに活かしたい • かっこいい • 何となくやらないといけない気がしている • 上司から言われた • ・・・なんで可視化ってしないといけないんだっけ?
  22. 22. 可視化
  23. 23. 分析する内容が最初から決まっていなくてもいい可視化してから考えようもっとやりたいことが出てきたら、方法を変えれば良い
  24. 24. 可視化して気がつくこと • おーこういう風になっていたんだ、と気がつく • しかし、まだもっとここがみたい、あそこが知りたい、と思 い始める • いや、でもそれを知るためにはあのデータも必要だし、そも そもログの設計をもっとしっかりしないと。。と悟る 可視化によって気づき、伝えることができる
  25. 25. 分析を武器にする 仕組みをつくろう
  26. 26. 分析を活かすことはなかなか難しい • 最初から何を分析したいのか全てわかっている、ということ はまずない • なにより、チームとして「データを活かそう!」というスタ ンスにならないと進まない でも、Kibanaの画面を見せれば、利点をわかってもらいやす い。チームにデータを分析することのメリットを伝えやすくな る。うごくもの大事。
  27. 27. 可視化できた、で終わり? • 何かを変える。新しい機能を考える。既存の機能を見直す。 検索結果の表示を少し変えてみる。配信するユーザのセグメ ントを少し変えてみる。配信するクリエイティブの種類をユ ーザのクラスタごとに変えてみる。 • そしてデータを活かす文化を創ろう。 何かを決めるために、分析をする。 その結果を観察し、繰り返し改善する。
  28. 28. 長く分析の価値を提供する 継続して分析の価値を出せる基盤が必要 『分析の価値』 = 意思決定への寄与度 × 意思決定の重要性 『会社を変える分析の力』(河本薫 著,講談社,2013)p.27より
  29. 29. 分析基盤を作るときに考えること = 継続性 • EFKから始めれば良い • 関連するデータを取り込んで、柔軟に扱えること • 試した結果を取り込んで、考える事のできる基盤であること • 使ってもらいやすい基盤であること http://www.slideshare.net/suzuken/jenkinshadoop
  30. 30. データの分析は、チームでつくるもの
  31. 31. credits flickrのcreative commonsな写真より • https://www.flickr.com/photos/ 38451115@N04/15024431566 • https://www.flickr.com/photos/ 77654185@N07/7413019520/ トップ画像は @suzu_v 撮影です。
  32. 32. 参考資料
  33. 33. • 今年の1月にわたしたちが構築しているDMPの仕組みについ て発表した資料です • http://www.slideshare.net/suzuken/dmp-30079817 • 『エンジニアのための データ可視化[実践]入門 ―D3.js によるWebの可視化』,森藤大地、あんちべ 著,2014 • 可視化についてのまとまった解説のある日本語書籍です。 可視化のメリットや機能、適切な可視化の方法について知 りたい方におすすめです。 • http://gihyo.jp/book/2014/978-4-7741-6326-0
  34. 34. • 『会社を変える分析の力』 (河本薫 著,講談社,2013) • 分析とは何か、チームにおける分析の課題とは何か、そし て分析によって何を行っていくべきかがまとめられている 書籍です。簡潔で演じない以外の方にも読みやすいでしょ う。 • 『分析力を武器とする企業』(トーマス・H・ダベンポート、 ジェーン・G・ハリス 著、村井章子 訳,日経BP社,2008年) • 企業の分析力についてよくまとまっている書籍です。分析 を企業の機能としての側面から端的に述べられています。
  35. 35. 分析対象となるデータ • 全てのログ • ユーザの購入ログ、クリックログ、表示ログ… • DBに入っているデータ • ログから導出可能なものとそうでないもの • マスタデータ
  36. 36. Elasticsearchのスペック サービスラインごとに変えてるので一例です。 • r3.2xlarge (メモリ 61GB), EBS 1TB * 2 • 2000万レコード/日を1ヶ月分 • m1.xlarge (メモリ 15GB), ephemeral diskのみ • 600万レコード/日を1ヶ月分 クエリ頻度やメトリクスの重さにもよります。
  37. 37. on Elasticsearch • 広告におけるターゲティングのための仮説づくり • 配信ボリュームの見積もり • エラーログの分析 • どういうところでどういうエラーが起きているか • アトリビューション分析の取っ掛かり • どういう行動をしたユーザがコンバージョンしているか
  38. 38. not on Elasticsearch • マスタデータと組み合わせた分析 • 長期間に渡るデータを利用した分析 • 広告配信時に安定したレイテンシで返す仕組み • 準リアルタイムなユーザ分析 • 永続化(Source of Truthではない)

×