「スキーマレスなログデータの収集と集計のためのデザインパターン」 (Crocos社 柄沢聡太郎氏)
柄沢氏の所属するCrocos社は2011年に創業したソーシャルメディアを主としたオンラインマーケティングサービスの企画,
ログはスキーマレスな形式で持つこと
TDでログを集めよう,
- どんなユーザが
- どんな端末で
- どこから
- いつ何をしたのか
- どんなボタンをクリック,
タップしたのか
こういったユーザの行動履歴を集めるとなると,
では,
また,
それに比べて,
基本的なログ設計3つのポイント
次に柄沢氏は,
- ポイント1:1イベント1レコードとなるように記録すること
Webアプリケーションの場合,
ユーザの1アクションで, 最初のリクエストのログのほかに, CSSや画像を取得するたびにトランザクションが発生することがあります。こういうアプリケーションの観点からは必要のないトランザクションのログがあると分析がうまくいきません。そのため, ユーザの1アクションが1レコードになるように記録します。 - ポイント2:基本的なスキーマを決めること
ログの項目を決める際,
スキーマレスとはいっても, どのようなデータを扱うかのルールはきちんと決めておく必要があります。具体的には, 「項目としてはWebサーバのログにあるような基本的なスキーマ (日付, ステータス, URIなど) を持つ」, 「項目名はLTSV (Labeled Tab-Separated Values) の名前に合わせる」 などといったルールを決めて, 項目を定義する必要があります。 さらに,
Webサーバのログ情報以外にも, アプリケーションとして意味のある値 (フレームワーク内でのルーティング名やコントローラ名, プロセスが始まってから終わるまでの実行時間など) を持っておくことが大事です。URIベースで分析しようとすると, TwitterやFacebookなどのようにサービスによってはURIに独自のパラメータを付けてくることがあり, 解析に手間がかかります。しかし, アプリケーションの中できちんとルーティングが決まっていれば, ログのルーティング名でユーザのアクションを一意に決められます。 - ポイント3:アプリケーションの知り得る属性を非正規化してレコードに含めること
ユーザがサービスを初めて利用する際に登録してもらった属性情報
(ユーザID, 性別, 年齢, デバイスの情報など) は, 本来ならデータベースに入っているデータですが, それらを正規化せずにログに含めておくと便利です。こうしておけば, JOIN (表結合) せずに集計関数にかけられるため, 分析が楽になります。 ただ,
セキュリティの観点からユーザIDやセッションIDなどはハッシュ化しておくほうが良いでしょう。
スキーマレスなアプリケーションログを扱うコツ
ログをスキーマレスにしておく利点は,
たとえば,
これは,
発表を締めくくるにあたって,