フリルのログ収集基盤について

以下は2015-12-25に会社（Fablic, inc.）の技術ブログinFablicに投稿した記事（http://in.fablic.co.jp/entry/2015/12/25/110618）になります。
inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。

元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。

この記事は Fablic Advent Calendar 2015 の25日目のエントリです。

こんにちは、Fablicでサーバーサイドエンジニアをしている@yutadayoです。今回はフリルのアクセスログをどのように収集し、活用しているかを紹介します。

ログ収集で実現したいこと

ログ収集にあたり、以下のような実現したいことがありました。

KPIデータの算出
ユーザーの行動分析、機能開発時に考える仮説の裏付けとなるデータの抽出
エラーや障害時の調査

MySQLを使用したデータ分析や管理画面などの整備も行っていますが、ログからしか分からないものに関しては収集してきちんと利用できるようにするのが最終的なゴールです。

使用している技術

使用している技術は以下の通りです。

システム構成

フリルのシステム構成の概略を図にすると以下のようになります。フリルでは数十台のサーバを運用しているので、アプリケーションサーバから集約サーバに一旦ログを集め、そこからBigQuery、Elasticsearch、S3に転送しています。

f:id:yutadayo:20151224213354p:plain

処理の流れ

ログを収集するまでの大まかな設定を紹介します。fluentdのインストールや各ツールの設定などは、情報も豊富なので省略します。

収集しているログ

nginxのアクセスログ
アプリケーションが出力するログ
- 検索ログ
- 出品や、いいね、コメントなどのアクションログ

1. ログの出力

フリルのAPIサーバはRailsプロジェクトで作成されており、 td-loggerを使用しています。td-logger-rubyのドキュメントに記載の通り、アプリケーションサーバ内で動いている td-agent daemon への設定を以下に記載します。

config/treasure_data.yml

production:
  agent: localhost:24224
  tag: fril

例として検索ログを出力する際は下記のようにメソッドを呼び出します。検索時に呼び出されるAPI endpointのパラメータを整形しセットしています。

TD.event.post('search', {'user_id' => ..., 'ip'=> ..., 'user_agent' => ...})

このとき出力するログ形式のschemaとBigQueryに作成するテーブルのschemaを合わせておくと良いでしょう。

f:id:yutadayo:20151224235115p:plain

2. td-agentの設定

アプリケーションサーバのログコレクタ

<match fril.search>
  type forward

  <server>
    host XX.XX.XX.XX
    port 24224
  </server>

  flush_interval 60s
</match>

アプリケーション内で設定したログのマッチ設定を記載し、集約サーバへforwardするようにします。

集約サーバのログコレクタ

集約サーバ側のtd-agentでS3やBigQueryに保存する設定を以下に記載します。なお、BigQueryへは fluent-plugin-bigquery を使用しています。

<match fril.search>
  type copy

  <store>
    type s3

    path logs/search_log/
    aws_key_id XXXXXXXXXXXX
    aws_sec_key XXXXXXXXXXXX
    s3_bucket XXXXXXXXXXXX
    s3_region ap-northeast-1
    buffer_path /var/log/td-agent/buffer/search_log
    check_apikey_on_start true
    time_slice_format %Y/%m/%d/%H
    time_slice_wait 10m
  </store>

  <store>
    type bigquery

    method insert

    auth_method private_key
    email XXXXXX@developer.gserviceaccount.com
    private_key_path /etc/td-agent/XXXXXXXXX.p12

    project XXXXXXXXXX
    dataset XXXXXXXXXX
    auto_create_table true
    table searchlog_%Y%m%d

    time_format %s
    time_field time
    schema_path /etc/td-agent/schema/search_log.json

    buffer_chunk_records_limit   300
    buffer_chunk_limit           768k
    buffer_queue_limit           5000
    flush_interval               1
    try_flush_interval           0.05
    num_threads                  4
    queued_chunk_flush_interval  0.01
  </store>
</match>

注意点

BigQueryを使う上で注意が必要なのは、課金の部分です。BigQueryはクエリ発行毎（走査したデータの分）に料金が掛かってしまうため、保存するテーブルはある程度小さめにしておくと安全です。

そのため、定期的にBigQueryにテーブルを作成するバッチを実行し、日毎にテーブルを分けてログを保存するようにしています。このテーブルは searchlog_20151225 のような形式で作成されます。

活用方法

BigQueryの導入でユーザーの行動に紐づくデータの解析が誰でもできるようになり、仮説の検証がとてもしやすくなりました。

その他にも、ログを使って検索ランキングを実装したり、日時のバッチ処理でログデータからKPIデータを作成したり、アクセスログをKibanaで可視化したりなど、色々な箇所で役立てています。

f:id:yutadayo:20151224220902p:plain

また、Fablicでは開発者だけでなく、デザイナーやマーケティングの担当者もBigQueryを使ってデータの分析を行っています。このため、全社での知見共有や、新しい方が入社された際にもすぐに業務ができるように、QiitaTeamなどでTipsを社内公開するようにしています。

f:id:yutadayo:20151224221345p:plain

まとめ

フリルで行っているログの収集とそれの活用事例を紹介させていただきました。サービスを開発する上での仮説検証や、改善サイクルを回す上でログから分かるデータは非常に有用です。

Fablicでは日々より良いサービスを作るために、データを活用し、プロダクト開発を行っています。ログ解析基盤の構築や、データを活用してサービス改善を行いたいエンジニアの方のご応募をお待ちしております！