ponkiti's blog

主に自分用、イベント参加メモや備忘録として利用

『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』出版記念！執筆者が語る大講演会！に行ってきた。

Event

セルリアンタワーのシナジーカフェ GMO Yoursで行なわれたのですが、どちらも初めて入りました。うっかりお隣のセルリアンタワー東急ホテルに迷いこむという・・・。

このイベント、Treasure Dataが企画/主催していたんですね。受付や司会も担当されてました。秋にもFluentd関係のイベントを開催するようです。

まとめはこちら　

まずは、各特集の執筆者による15分ずつのトークをノンストップで。

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

@suzu_v　すずけんメモ

メモ

  • 広告データのログを扱っている
  • 「ログ分析全般の話をします」
  • YAPCのBigQueryの話が一瞬出てきた
  • 分析に使用できるツール、アプリケーション、サービスが多種多様
  • 「いろいろあってよくわからないから、ログの分析はあとにして、他の機能追加しましょう」
  • 「Fluentdでログ拾ってきたらとりあえずどうにかなるんじゃない？」
  • 「可視化してから考えよう」
  • ログ専門の人は少ない
  • 営業さんも分析基盤に携わっているとか
  • 「Kinbanaの画面を見せれば、利点をわかってもらいやすい」

所感

広告配信サービスではログをどのように業務で活かすべきなのか。ログ分析とはどういうフローであり、各フェーズは何を利用して処理すればいいのか。ログ分析を必要とするであろう人達を支えるのが分析基盤に携わるエンジニアの役割であるが、エンジニアだけでなく、チームで作り上げるべし。というような内容。

ログの分析結果を意思決定に利用する人や、実際に分析を行なうアナリストではなく、インフラやサーバサイドエンジニアなど、ログに直接扱うことのできる立場からのトーク。

ログを可視化すれば業務に活かせるから、継続的に利用できるようログ分析を認知してチームで運用していこう、と推奨しているのですが、これはログを扱うエンジニアが分析や可視化に対して興味がないとなかなか難しい。ログ環境を直接扱えない非エンジニアにはどうしようもない話ではある。なんとかエンジニアの時間を確保して空き時間に試してもらうか、分析をすると決めてプロジェクト化し、がっつりと進めてもらうしかないような・・・。

私も社内のログを分析するために分析基盤を導入しようとしている真っ最中ですが、インフラやサーバの知識・経験が足りず苦戦しているところです。

データ分析担当の私がサーバへFluentdやその他の設定をすればいいところ、前述したとおりスキルセット不足。また、分析対象の部署と私の所属部署が異なるためアクセス権がない。それらの事情があり、ログ分析に必要となる作業はそのサービスを担当しているサーバサイドエンジニアの方を業務の合間におかりして進めている状態です。

@suzu_vさんのおっしゃるとおり、分析する環境を作り上げるのは一人では無理だと実感しています。「画面を見せれば、利点をわかってもらいやすい」というのもその通り。ただ、その画面を出すまでが難しい。こういうものは会社の売上に直接影響することはないので後回しにされがちです。データ分析基盤を作る前段階の、データ分析への理解を進めるが課題になるように思います。

スライド内で引用されていた『会社を変える分析の力』は具体的な例が挙げられており、非常に分かりやすく、短時間で読めるのでお勧め。データ分析に本格的に関わるようになってから初めて読んだ本でした。そしてもう一冊、『分析力を武器とする企業』は知らなかったので時間ができたら読んでみたい。

Fluentd構成のお勧めデザインパターン

@yoshi_ken　Fluentdのお勧めシステム構成パターンについて発表しました - Y-Ken Studio

メモ

  • 「逆引きFluentdプラグイン」はかなり便利
  • exec_filter、標準出力で外部プログラムを実行できる
  • Norikraの話
  • 不正ユーザ抽出
  • CPUコア一つで処理しきれないフィルタ処理、死活監視システムは向かない
  • 詳細なフィルタリングをする場合はどうなんだろう
  • syslogと平行稼働できる

elasticsearch、もうちょっと入門

@johtani　@johtaniの日記 2nd

メモ

  • 「本に書いてない話をします」
  • ElasticsearchはJavaで記述された全文検索ライブラリのApache Lucene（ルシーン）を内部で使っている
  • 設定なしで簡単に試せる
  • プラグインはまだ少ない
  • 「Treasure Dataの方は目をつぶっていただいて」とlogstashを紹介
  • elasticsearch社はlogstash（JRuby）で集めるのを推奨しているらしい
    • logstashは知らなかったけれど、自分の7月のノートを見ると「logstash推奨」というメモが・・・。
    • そしてJRubyについて、この場にはいない@repeatedlyさんからの言及
  • 「もう目を開けていただいて大丈夫です」
  • 今回紹介したいのはaggregation機能
    • Facetよりも強力でより柔軟な集計が可能
    • Kibana3では使えない
    • 多段で集計可能、メモリ消費量に注意
  • 勉強会ではaggregation機能の詳しい話をするらしい
  • デモでは先週放送されたエヴァをQueryで指定しての検索
    • 場所のデータは入っている方が少ないらしい

Kibanaではじめるダッシュボード

@harukasan　Kibanaではじめるダッシュボードについて発表してきました #gihyo_efk - BLOG::はるかさん

メモ

  • デプロイは1日17回
  • 2年前（可視化基盤：Fluentd→MongoDB）からデータ分析を始めた
    • この可視化基盤はそれなりに使われていた
  • サービスのグロースのためならなんでもやる「グロースチーム」
    • データ分析チームはグロースチームと開発チーム（可視化、継続的デリバリーの手段）がある
  • 分析ではなく、分析したものを利用して
  • 昨年Kibana2を知り可視化したが、他の人が使い始めるとデータが欠損していると怒られるように
  • Kibana利用者は会場の3割程
  • Dashboardは見たい数値が一画面に収まっている
  • デモにて、pixivで実際に使われているDashboard画面を参照
  • 変化について議論する機会をつくる
  • Kibana with Bigquery
  • Tableauを利用しているらしい
  • とりあえずKibanaを初めてみる

特別パネルディスカッション

@naoya_ito さんをファシリテーターとした執筆陣とのトーク。
「TDの太田さんからやってくれと言われて断れなかった」とのこと。報酬は寿司らしいw

  • ログ収集はスコープなのか？

    • 「権限があったから入れました」が大きい
    • 2、3年前、Tresure Dataにメールを出して
    • 趣味で

  • どういう立ち位置なのか？

    • サーバサイドエンジニア、インフラエンジニア
    • 「ジャパニーズカンパニー特有」で担当範囲などがあやふや

  • ログ収集エンジニア

    • とある会社ではログのみを扱うログエンジニアがいた。一人、二人はりついてなければできなくて
    • 時間的には厳しい。グロースハックチームはフルタイム
    • ログをつっこんだら可視化できる。タイムスタックだけあればいい

  • kibana、Elasticsearchがない頃はどうやってた？

    • （ログを扱うことに関して）システムモニタリング側、ビジネス側で異なるが
    • モニタリングは昔からある
    • 当時はまだやることを探している段階じゃなかった。グロースTはGoogle Analyticsバリバリ使っているが、遅い
    • うちも使っている。Google Analyticsに強い人がいる。
    • 体系化されてなかった

  • DWHは？

    • Treasure Data
    • BIツールは統計値でバクッとした結果。Elasticsearchはよりトレースしやすい。

  • DWHって知ってる人、DWH使っている人

    • 会場内で使っている人は少ない
    • DWHの説明
    • 正規化しないイメージ

  • 領域はかぶっている。棲み分けは？

    • Elasticsearchは入れるのが簡単なのでとりあえず入れてみて、試すためのものとしてElasticsearchを使ってもらえればいいかな
    • 瞬間的なものはElasticsearch
    • Elasticsearchは一ヶ月分以外は消す。BigQuery

  • 溜め込んだデータはどうする？古いデータは？

    • 消してるところも
    • 保存しておくけど、検索できない、消さずによけておく
    • Eの使用は限定的
    • 社内ではKibana見やすいよね

  • Tableauについて

    • エンジニアの感覚として勝手にSQLに繋がっていると気持ち悪い

  • いらなくなったログを残して何になるんだ

    • エコじゃない
    • 資源をずっと使い続けているのが生理的に気持ちが悪い

  • 10年たったら新しいジョブが誕生し、ログエンジニアにクラスチェンジするのでは

  • 心の中でぶっちゃけどう思っているのか？

    • 続けるために
    • どうやって検索するのか、どういった軸でやるのか
    • 自分がプロキシになる場合もある
    • アルバイトさんでもSQL書いちゃう、様々な立場の人がSQLをたたいている
    • ABテストは3回目でやめた。数値だけではだめ
    • うちのトーク的にはやばい
    • ログエンジニアも意思決定に巻き込まれる
    • ログエンジニアの悩み

  • ログ収集システムの規模感

    • Elasticsearchサーバ2台（Kibanaのフロントも含まれている）、ちゃんとしたサーバ、Elasticsearch書き込みでよく止まる、3週間程で準備、その際はデータセンターからかりてきた
    • アクティビティ、ログインのタイミング、全リクエストだと大変、サンプリングしている
    • PV1億、Kibanaじゃ追いつかない、BigQueryに
    • 15台、メンテめんどい&高い
    • ほとんどオンプレ、保守切れサーバを使用？
    • 32Gまでは結構のせられる
    • メモリ重要

  • SQLはBIツールと言えるか？

  • BigQueryのバックアップについて

    • スナップショットをとっている
    • バックアップはとっていない

  • クラウド脳。なるべく自分でつくらない、という思考になっている

  • 広い意味で検索と言っている
  • ポジショニングの問題
  • hatenaとかはsolrからElasticsearchにスイッチ
  • @typesterさんの話
  • ログに関してはスキーマは特に決めていない