「スキーマレスなログデータの収集と集計のためのデザインパターン」（Crocos社　柄沢聡太郎氏）

柄沢氏の所属するCrocos社は2011年に創業したソーシャルメディアを主としたオンラインマーケティングサービスの企画，開発，提供を行う企業です。同社が提供するサービスのログ解析基盤としてTDのサービスを利用しています。同社ではTDを利用して，どんなデータをどういう形で貯めているのか，これまでに培ったノウハウについて発表が行われました。

ログはスキーマレスな形式で持つこと

TDでログを集めよう，解析しようとしたときに最初にぶち当たる壁として，「⁠どんなログを集めるのか」という問題があります。単純にWebサーバやミドルウェアのログを集めればいいのでしょうか？　これらのログを分析したところでわかることは限られています。アプリケーションの観点で本当にほしいデータとして，柄沢氏は次のようなものを挙げました。

• どんなユーザが
• どんな端末で
• どこから
• いつ何をしたのか
• どんなボタンをクリック，タップしたのか

こういったユーザの行動履歴を集めるとなると，収集の対象として考えられるのはアプリケーションログでしょう。

では，アプリケーションログはどんな形式で集めるのが良いのでしょうか？　今までによくあるログの形式として，項目がタブで区切られたTSV形式があります。ただ，これを解析しようとすると，ログをオープンして行ごとに項目を分割して，カラムの1番目が日付で，2番目がステータスで……というふうに処理しなければならず，手間がかかります。

また，このような形式でスキーマを決めてしまったログは，項目を増やしたいときに容易に対応ができません。柄沢氏は，ログを解析するためのスクリプトやツールと，データが密な関係になっているのが問題だと言います。

それに比べて，TD（Fluentd）のログはJSON形式です。項目の順序などのルールはありません。項目名が付いているためデータの量は増えてしまいますが，そのかわり，人間が見てもわかりやすいですし，項目を容易に追加できます。

基本的なログ設計3つのポイント

次に柄沢氏は，基本的なログ設計のポイントととして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などはハッシュ化しておくほうが良いでしょう。

スキーマレスなアプリケーションログを扱うコツ

ログをスキーマレスにしておく利点は，特定のレコードに特別な意味をもたせることができることだ，と柄沢氏は言います。

たとえば，トランザクションを記録する場合，URIやルーティングの情報だけしか記録していないと，リクエストの数は数えられても，成功した処理の件数まではわかりません。こういう場合によく採られるのは，処理が成功したときに特定の画面を表示させるなどしてトランザクションを記録するという方法です。しかし，ログがスキーマレスになっていれば，そんな必要はありません。処理が成功したときに，ログに登録完了の記録を追加するだけで済みます。登録完了の記録とともに，属性情報（どんなユーザが，どこ経由できたのかなど）を一緒に入れておけば，経路別の登録完了数も簡単に集計できるようになります。

これは，JavaScriptによるイベント，TwitterやFacebookへのシェアなどユーザのアクセスに依存しないイベントの発生を記録する場合にも同じことができるとのことです。

発表を締めくくるにあたって，柄沢氏は，「⁠スキーマレスのログを扱ううえで最も重要なのは，ビジネス側（データ解析したいと思う人の側）で解釈のルールを決めることだ」述べています。また，「⁠スキーマレスと言えども，事前のログ設計はしっかりやりましょう」とも言っています。データ分析を行うためには，ログ設計の段階からすでにデータの利用方法を考慮しておかなければいけないと言うことでしょう。サービス開始時からデータ分析のことを考えておくべきというTDの田村氏の主張とも通ずるところがある発表内容でした。