『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』の出版記念イベントで発表してきました。会場を提供していただいたGMOのみなさま、主催のTreasure Data / 技術評論社のみなさま、そして聴きに来てくださった方々、どうもありがとうございました。

http://eventdots.jp/event/137658

各特集の著者によるそれぞれの特集の導入が前半にあり、後半はnaoyaさんとのパネルディスカッションがありました。

養成読本、おかげさまで多くの方に読んでいただいており、嬉しい限りです。僕のところは導入の章ということで、「なぜログの分析をするのか？」という点に絞って発表しました。内容としてはざっくりいうと、

• ElasticsearchやFluentdを使いつつも、何をやりたいかによって使うツールは変えなければならない
• 分析するにはデータがなければならない。どんなデータが生じるかはサービスの設計と紐づく。なので分析はチームで行うものである。

というものでした。

パネルディスカッション

後半のパネルディスカッションでは、ざっくばらんにリラックスした雰囲気の中でログの分析について話をすることができました。楽しかったです。（楽しんでいただけたでしょうか・・・？）naoyaさんから事前に話すトピックが共有されており、それをピックアップしつつ話していきました。rebuild.fm スタイルなのだそうです。ちなみにどういう順番で話を進めるかは決まっておらず、その場のノリで決められていったのでした。

トピックが点々としたので自分でもうろ覚えなのですが、ポイントで。

• ログまわりのエンジニアリングをするのはインフラエンジニアなのか？というとharukasanの話にもあったように「趣味」でいれる、というか権限があるからインフラエンジニアから始めやすい、というのはあると思う
• でも、ちゃんと整備してETL整理してストアの選定してある程度使いやすく整備して分析するエンジニアのための環境をつくっていく、となると専任の人がいたほうがやりやすい
• BigQuery最強説
• DWHを使っていたり知っている、という方が会場に少なくて意外な印象を受けた
• Elasticsearchのインデックスのバックアップについて。これはうちだとsnapshotでdailyでやってる、んだけど全部やってるわけではない。保持期間が2,3日程度の運用だとそもそも古いログをElasticsearchにrestoreする必要があまりない。かつ、Elasticsearchをsource of truthとして使う、という運用は現状ではない。でもKibanaのdashboard設定はbackupしておいたほうがいいですよ。
• 「ログの分析やっても面白い革新的なサービスは出てこないんじゃないか」っていうのはまさにその通りで、あくまで既存のものの改善をするエンジニアリング。なのであんまりログエンジニアが増えても仕方ない、といわれるとまぁそうですね、という感じがある。

などなど。色々話しました。

四方山話

あと終わったあとに飲みながら話していたのですが、僕がそもそも分析周りのことに興味をもったのは、 https://trippiece.com を作っていた頃に遡ります。trippieceは「旅をつくる」サービスで、僕はそのサービスの設計とサーバサイドとフロントエンドのエンジニアリングを1年ほどしていました。最初はプロトタイプづくりに苦心し、リリースしたものの全然使われず、また作りなおして・・・というようなことを繰り返し繰り返しやっていく過程で、ユーザがどのようにサービスを使っているのか、ということばかり考えていたのです。そのときは自分がアプリケーションの実装の大部分をやっていたので、ログをしっかりまとめて管理して分析できるような状態にする、ということは全然できませんでした。とりあえずGoogle Analyticsをつかって動向を見守る、ということをしていました。でももっと細かく見たいものや、改善に使えそうなデータはあることはわかっているにもかかわらず、当時はどのようにアプローチしていけばわからなかったのです。なので新卒でVOYAGE GROUPに入社した時から、データ周りのことに携わり始めた、という背景が有ります。もし当時の僕だったら何を知りたかっただろうか、というのを思いながら書いたのでした。そういう意味では、今は改善する仕事をしているけれど、新しいものを生み出しているとは言えないのかもな、、などとパネルディスカッション中に思ったのでした。