Fluentd、Amazon RedshiftとTableauを用いたカジュアルなデータ可視化

https://github.com/moaikids/fluent-plugin-jsonbucket 行えることは極めて単純で、

{"a":1, "b":2, "c":3 } -> {"log": {"a":1, "b":2, "c":3 } }

という感じで左辺のようなデータを右辺のような形式に変換するpluginです。 こちらと組み合わせてnginxのアクセスログをRedshiftに保存するサンプルを例示します。

まずnginxですが

log_format  ltsv  'time:$time_localt'
                    'host:$remote_addrt'
                    'req:$requestt'
                    'status:$statust'
                    'size:$body_bytes_sentt'
                    'referer:$http_referert'
                    'ua:$http_user_agentt';

ここでは単純化して、上記７つの項目がLTSV形式で出力されているとします。 保存されるログの中身は以下のような形式になります。

time:02/Oct/2013:19:26:31 +0900	host:xxx.xxx.xxx.xxx	req:GET /musicians/famous/ HTTP/1.1	status:200	size:2172	referer:-	ua:Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_2 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A501 Safari/9537.53

データ保存先のRedshiftでは以下のようなテーブルが存在するとします。

create table access_log(
    time varchar(255),
    host varchar(255),
    req varchar(255),
    status integer,
    size integer,
    referer varchar(255),
    ua varchar(255)
);

Fluentdでの読み込みはin_tailで行い、先述のjsonbucketで形式を変換した上でRedshiftに保存します。

<source>
    type tail
    tag nginx.access
    format ltsv
    path /var/log/nginx/access.log
    pos_file /var/log/fluentd/nginx_access.log.pos
</source>

<match nginx.access>
    type jsonbucket
    out_tag redshift.nginx.access
    json_jey log
</match>

<match redshift.nginx.access>
    type redshift
    # s3 (for copying data to redshift)
    (snip.)
    # redshift
    (snip.)
    redshift_tablename access_log
    file_type json
    # buffer
    (snip.)
</match>

上記のような形で設定を行うと、FluentdのflushのタイミングでデータがRedshiftに書き込まれるようになります。

flydata

Tableauによる可視化

Tableauはマウス操作でデータの問い合わせ方法や表示方式を選択していく事でリッチなダッシュボードが手軽に作成できる、非常に使い勝手の良いBIツールです。データの取得方法やキャッシュ方法、描画のアルゴリズム等々に先端的な手法が用いられていると言われており、データ規模がある程度大きくても非常に快適に使用することができます。

ビジネス要件や知りたい情報は刻一刻と変わっていくので、エンジニア/非エンジニアに関わらずSQLやプログラムを書くこと無く迅速にかつアドホックに欲しいデータを簡単に取得出来る環境が、非常に重要です。それを実現する手段の一つとして、Tableauは有力な選択肢の一つと感じています。

可視化手法としては一般的な表形式やグラフ形式の他に、位置情報に基づいた地図上へのデータのプロットについても対応しています。こちらは見た目にも派手で人目を引くので、サンプルとして例示してみたいと思います。

fluent-plugin-geoipによる位置情報の付与

geoip pluginは、MaxMind社が提供しているgeoipデータベースを用いて、IPアドレスを基に地域情報の抽出を行うFluentd plluginです。geoipデータベースには有償版もありますが、精度の低めな無償版も存在しており、無償版を使用することで手軽に試すことが出来ます。

なおgeoip plulginを使用するにはC言語版のgeoipと、Ruby版のラッパー実装のインストールが事前に必要になります。以下はCentOS/Redhat系OS向けの、Chefを用いたinstall recipeの例です。

package "zlib" do
    action :install
end

package "zlib-devel" do
    action :install
end

package "GeoIP" do
    action :install
end

package "GeoIP-devel" do
    action :install
end

execute "install_fluentd_geoip_plugin" do
    command <<-EOH
        fluent-gem install geoip-c -v 0.9.0
        fluent-gem install fluent-plugin-geoip -v 0.0.4
    EOH
    user "root"
    group "root"
end

先述のnginxのアクセスログをRedshiftに保存するサンプルを拡張し、位置情報についても保存できるようにしてみます。

まず、テーブル定義に以下のように緯度(latitude)、経度(longitude)、ならびに都市名(city)を追加します。

create table access_log(
    time varchar(255),
    host varchar(255),
    req varchar(255),
    status integer,
    size integer,
    referer varchar(255),
    ua varchar(255),
    city varchar(100),
    latitude real,
    longitude real
);

Fluentdの設定ファイルにもgeoip pluginを用いた地域情報の変換処理を追加します。nginxのアクセスログの情報のうち、”host” に含まれているIPアドレスを使用して地域情報を抽出します。

<source>
    type tail
    tag nginx.access
    format ltsv
    path /var/log/nginx/access.log
    pos_file /var/log/fluentd/nginx_access.log.pos
</source>

<match nginx.access>
    type geoip
    geoip_lookup_key host
    enable_key_city city
    enable_key_latitude latitude
    enable_key_longitude longitude
    add_tag_prefix geoip.
</match>

<match geoip.nginx.access>
    type jsonbucket
    out_tag redshift.nginx.access
    json_key log
</match>

<match redshift.nginx.access>
    type redshift
    # s3 (for copying data to redshift)
    (snip.)
    # redshift
    (snip.)
    redshift_tablename access_log
    file_type json
    # buffer
    (snip.)
</match>

Tableauでの操作方法は割愛しますが、Tableau上で上記のRedshiftのテーブルの接続設定を行うとlongitudeとlatitudeが自動的に地域情報として認識され、集計対象のカラムがメジャー情報(数を集計する対象の情報)として認識されます。それらを組み合わせると以下のような地図を作成することができます。

まとめにかえて

システムの観点で言うと、大量のデータを安定して保存し、高頻度で解析していくためには、技術的なバックボーンとノウハウの習得が必要となってきます。今回は文量的な制約もあり表面的な話のみ記載をしていますが、その裏には技術的に様々な試行錯誤があることをご察しください。

今回は商用ソフトを用いた事例となりましたが、OSSの組み合わせで言うと最近技術者の間でトレンドとなっている「Fluentd」「elasticsearch」「Kibana」を用いたログ分析の可視化も非常に面白い組み合わせと思います。 [参考] Kibanaってなんじゃ？（Kibana+elasticsearch+fluentdでログ解析）

また、今回の事例では紹介いたしませんでしたが、データの保存先・解析プラットフォームとしては、Treasure Data社が提供しているプラットフォームが技術的にも将来性としても非常に魅力的です。 http://www.treasure-data.com/

Hadoop界隈においてもMesosやSparkなどの並列分散処理系周りの動向も活発で、データ解析に関する分野は非常にレッドオーシャンな感じで盛況なので、常に新しい情報のウォッチが必要な分野と感じています。

なお、今回記事中に”さだまさし”ネタが含まれておりませんが、特に上司に怒られたとかそういう事は一切なく、単にネタ切れである事を謹んでご報告申し上げます。