べにやまぶろぐ

技術寄りの話を書くつもり

『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 出版記念!執筆者が語る大講演会!』 聴講メモ

今日は表題の通り下記イベントに参加してきました。

http://eventdots.jp/event/137658

以下、個人的に響いたところ中心に聴講メモです。

『サービス改善はログデータ解析から』鈴木 健太氏

  • adingo 社で DMP 構築、R&D を担当されている
  • EFK スタック (ElasticSearch / Fluentd / Kibana) という言葉があるらしい
  • 広告ログの分析を行っている
    • どんなユーザー・枠に広告を出したか、キャンペーン、効果が高かった広告、 CV までの過程
  • 配信サービスの設計と配信サービスのデータは表裏一体
  • 配信、結果の分析、再度配信… 一人ではできない
    • 実際は案件をとってきたり、アナリストがいたり、手を変えるエンジニアがいたりする
  • データの分析はチームで作るもの、活かせるようにするエンジニアが必要
  • 収集、変換、保存、分析、表示、適用というステップ(書籍『分析力を武器とする企業』より)
  • ログの分析は後にして他の機能追加しましょうという話になりがち、だけどログ解析をとりあえず試してみるべき
  • 分析する対象が最初から決まっていなくても可視化してから考えてみる
    • サーバのレスポンスが遅くなっている処理を可視化してみて15分おきに重くなっていることがわかった
  • 分析を武器にする仕組みをつくろう
  • 長く分析の価値を提供する基盤が必要
    • 『分析の価値』= 意思決定への寄与度 x 意思決定の重要性
    • 分析基盤を作るときに考えるべきこと = 継続性

『Fluentd構成のお勧めデザインパターン』吉田 健太郎氏

  • リブセンスで web エンジニアをされている
  • 実用性のある Fluentd プラグインを読みあさって養成読本第5章で逆引きリストを作ったのがおすすめ
  • log ディレクトリを踏み台サーバーに NFS マウントして読み出すなどという運用形態があった
  • Fluentd は構造化された LTSV (Labeled Tab-separated Values) 形式で出力することで awk の処理がやりやすくなる
  • これまで集めて終わっていたログが今はリアルタイム分析などに活用できる
  • Fluentd が適さないところ
    • Exactly Once を必要とする処理(Fluentd は At Most Once)
    • CPU コア一つでさばけない処理
    • ビジネスロジックが日々変化する場合
      • 扱いやすい形式で集約するところまでが Fluentd の処理範囲
      • メトリクス収集を超えた死活監視システムとしてに利用
  • 安定運用する上で意識したいこと
    • 各ノードは単一責任とすることでシンプルな構成にする
    • Aggregator で集約する
    • バッファした後にフィルタ処理するなど

『elasticsearch、もうちょっと入門』大谷 純 氏

  • ElasticSearch 社で働いている
  • ElasticSearch では検索だけでなくハイライト・集計・ソート・ページング・サジェストなどの機能を提供できる
  • ElasticSearch は Java で書かれている
  • ElasticSearch では(EFK で言うところの Fluentd にあたる) Logstash という製品を売っている (ELK スタック)

『Kibanaではじめるダッシュボード』道井 俊介氏

  • pixiv でインフラエンジニアをされている
  • 平均17回/日デプロイ
  • グロースチーム
    • サービスのグロースのためなら何でもやる
    • 様々な施策の検証のためにログを使用している
    • どのようなイラストが閲覧されているかなどを分析
  • 開発チーム
    • 可視化は継続的デリバリーの手段
    • 機能をリリースしたときにテストすることと一緒
  • 社内で Fluentd x MongoDB で可視化ツールをつくって決まった値を出し続けていた
  • ふと Kibana を使い始めた
  • 見たい数値が1画面に収まっているのがダッシュボード
    • 一つのデータに対して複数の面から分析する
    • 毎日毎週継続して変化を見ることが出来る
    • 一つの画面だけ見れば良い
      • スタンプ機能追加の際につくられた機能で、スタンプの利用状況やコメントの状況を可視化した
  • デプロイスクリプトを工夫することでデプロイしたタイミングを記録してグラフに表示できる
  • URL を生成して share できる
  • Google Big Query と Jenkins を連携させて集計させておくこともできる
    • Big Query は Tableau のバックエンドにもなる

特別パネルディスカッション (モデレーター 伊藤 直也 氏)

  • ログ解析は現在大きく分けて二つ
    • システムモニタリング
    • ビジネス要件寄りのグロースハックのための可視化
  • 昔はログを吸い上げるよりアプリから直接 DB にログ入れてた
  • 昔からあった DWH はどうするのか
    • DWH は正規化しないイメージ
  • scheme-on-write から scheme-on-read へ: 入れるときではなく読むときにスキーマを決める時代
  • 『ログエンジニア』が出現するかもしれない
  • Developer productivity という言葉がある
  • ログ解析ベースだと非連続な変化を起こしづらい
  • 真実だったとしても『数値化できていなかった』だけで意思決定から外れてしまう懸念
    • 数字を追いすぎてわからなくなることがある
    • 数字がないと議論すらできない風潮があるのではないか
  • A/B は適当にやると罠に落ちるからそこを注意しましょうというコンサル込みで売っている(PlanBCD)
  • Pixiv の ElasticSearch は2台
  • BigQuery は何秒か待たないといけない感じで使い勝手に多少の難

個人的には ElasticSearch 社の製品、とくに Elasticsearch.org Kibana | Overview | Elasticsearch は全く知らなかったのでこれ OSS で使えるんなら世の中の KPI ツールはとりあえずデータつっこんでこれで見てみてあーだこーだ言えばいいんじゃなくてという気分になったりして何となく Tableau のデモ見たときと同じような心地になりました。カスタマイズできるダッシュボード、デプロイのタイミングも KPI に重ねられたり、URL シェアできたりいろいろ便利そうです。

サーバ/インフラエンジニア養成読本 ログ収集~可視化編 [現場主導のデータ分析環境を構築!] (Software Design plus)
鈴木 健太 吉田 健太郎 大谷 純 道井 俊介
技術評論社
売り上げランキング: 7,058