Treasure Data Analytics 第2回 〜Treasure Data Cloud Warehouse について（後編）〜
本記事は移転しました。新サイトにリダイレクトします。
はじめに
Treasure Data Cloud Warehouse（前編）では，サービスの概観を紹介しました。第2回では，実践的なデータ･アナリティクスを行う上で解決しなければならない問題をTreasure Dataではどのように解決しているのか，具体的に述べていきたいと思います：
- データ収集の問題：様々な種類のログをどのようにデータを集約･収集して，横断的な解析を可能にするか？
- ストレージの問題：増え続けていく大量のログを，どこに，どのようなフォーマットで，解析可能な状態のまま保管していくか？
- 解析結果の活用に関する問題：ログを解析した結果を，どのように可視化するか。あるいはどのように既存のシステムに統合・フィードバックしていくのか？
1. データ収集の問題
図1: fluentd はログ解析の前段，ログ収集における問題を解決してくれる
「解析対象のログを収集してくる」という作業は本質的では無いと思われるかもしれませんが，実践的なデータ･アナリティクスを始めるためには極めて重要なフェーズです。そのためにはアクセスログをはじめ，データベースに書き込まれるユーザーの行動ログ，プログラムから書き出されるカスタムログ（アプリケーションログ），CPU使用率などのシステムメトリクスなど，様々なデータソースから統一的にログを収集してくる必要があります。実際の解析フェーズにおいては，これらの複数のデータソースを同時に参照・結合することによって有用な結果を得られるケースも多々あります。
1-1. アクセスログの収集
多くのWebサービスではサーバの負荷分散を行っているため，アクセスログの収集もまた複数のサーバにまたがって行わなければなりません。場合によっては数十台〜数百台のサーバからログを収集する必要があります。旧来の方法では，1日に1回ログが特定のディレクトリにローテートされるのを待って，そのテキストログを転送するという方法が一般的に行われていましたが，この方法には次に挙げるように多くの問題があります：
- 多数のサーバからログを転送する特定の時間に，ネットワーク負荷が集中して発生する
- 最短でも1日ごとにしか集計を行えないため，解析結果の鮮度が落ちる
- 複数のサーバーから収集するためのスクリプトの開発・管理が必要
- 集計を行う際にテキストログのパースが必要になる
上記の問題に対して Treasure Data では，ログ収集ツールである「fluentd」（インストールパッケージ名：td-agent）を利用します：
- アクセスログがファイルに書かれるたびに追従してストリーミング転送を行うことで，ネットワーク負荷のピーク値を軽減する
- ログを書き出してから数分後には集計が可能になる
- あらかじめ用意されたスクリプトを使うだけでアクセスログを収集可能
- アクセスログを読み取った際にログの構造化処理を行う
fluentd には Tail Plugin というプラグインが用意されています。これを利用することで所定のログファイルを継続的に読み出し，構造化したログをストリーミング転送することが可能になります。
これらの詳細に関してはドキュメントおよび有志の皆様のブログを参考にしていただければと思います：
- fluentd の公式ページ
- 作者古橋のスライド，ブログ
- Subsonic+Nginxのアクセスログをfluentdを利用してMongoDBに入れてみた
- EC2インスタンス上でnginxのログをfluentd経由でS3へ飛ばしてみる
Apache のアクセスログを収集するのであれば，各Webサーバーに以下の様な fluentd の設定ファイルをインストールしておけば，ログの集約が可能になります。
type tail path /var/log/httpd-access.log tag apache.access format apache
1-2. 多種多様のデータソースからの収集
fluentd では，アクセスログに限らず，プラグイン機能によって様々なデータソースからログを収集できます。プラグインの導入および使用は非常に簡単で，かつプログラムを書く必要も無く設定ファイルの簡単な記述だけで済みます。
公式サイトのプラグインリストには，ダウンロード回数順に非常に多くのプラグインがリストアップされています。特にダウンロード回数上位である MongoDB と fluentd はフロント側では共に同じ JSON での受け渡しが可能であるという事から fluentd のインプット/アウトプットとして，シームレスな連携が可能です。
他にも fluentd でログを転送しながら中継点で集計を行っていくようなストリーミング処理もプラグインによって実現することができます。これと node.js などとの連携によってほぼリアルタイムなカウンターをWeb上に実装することも可能です。
1-3 コード内からの記述（カスタムログ）
また，fluentd は各言語向けに用意された fluentd-logger ライブラリ（例： fluent-logger-ruby ）を使用することによって，プログラム内から出力されるログを fluentd に乗せてストリーミング転送することが可能になります。今まで log4j などのライブラリから独自フォーマットログを出力・解析していた場合はそのライブラリを fluent-logger へ置き換え，それを用いてコード内の該当箇所から Post してやれば良いことになります。
fluent-logger は，その活用方法によっては非常に強力で柔軟なデータ解析を実現することができます。例えば Social Gaming Analytics においてはユーザーのアクセス履歴にはそれほど意味は無く，有用なのは個々のユーザーのアクション（ログイン・登録・メッセージの書き込み・アイテムの購入・友達とカード交換…）履歴であり，これらを取得することが重要になってきます。fluent-logger はこのための最適なツールと言うことができます。
1-4. Heroku Add-on
また，Heroku などの PaaS プラットフォーム上でアプリケーションを構築・運用している場合には，Treasure Data のサービスをアドオンという非常に簡潔な方法で活用すことができます。
Treasure Data Heroku Add-on を使用した場合には，アプリケーションのアクセスログは自動で収集され，かつ Treasure Data Storage に自動的に蓄積されていきます。また，前述した logger ライブラリの利用によって構造化されたカスタムログを簡単に Treasure Data Storage に流すことが可能です。Heroku を活用されている方は是非一度導入してみてください。使い方は非常にシンプルです。ドキュメントはこちらです。
また Heroku の他，Treasure Dataでは EngineYard との連携も行なっており，近く同社顧客向けの Treasure Data サービスも開始される予定です。EngineYard ユーザの皆様は，是非ご期待ください。
図2: Treasure Data Hadoop は現在 Public Beta として運用中です
2. ストレージの問題
「先月のデータと比較したい」あるいは「去年の冬のデータと比較したい」といった要求は，データ･アナリティクスを実践的に活用していく上では一般的なニーズです。
このため収集されたログは，常に解析可能な状態で保管・管理しておかなければ，その価値が失われます。しかし，ここにも問題があります：
- 大容量のストレージが必要になる
- 障害に備えてバックアップしたりレプリケーションしておく必要がある
- ストレージ･ミドルウェアの永続的な運用は困難
- 数年後でも読み出せるように，データフォーマットを設計しなければならない
単純な記録メディアの価格は下がり続けていますが，データを継続的かつ適切に管理し続けるコストは，依然として高く付きます。
大容量のログデータを保持する方法としては，HDFS などのミドルウェアを使用する方法がありますが，HDFS の永続的な管理は容易ではなく，あくまで分散処理を行うための一時的な保管場所になります。
Treasure Data では，ログデータを Amazon S3 上に保管します。S3 はクラウド上に構築されたオブジェクト･ストレージで，安価でありながら高い堅牢性と可用性が担保されています。自前でストレージサーバーを管理するという神経質な作業から解放されるという点で，S3 は現状より良いストレージと言えるでしょう。
さらに Treasure Data では，Amazon S3 上に独自の列指向型データベースを構築しました。これによって，ログを「構造化されていない生のログファイル」ではなく，「構造化されたテーブル」として保持します。つまり，fluentd を使って収集した構造化されたデータを，そのままの状態でTreasure Data Storage に保存しておくことが可能です。このデータベースに保存されているログには，いつでも解析クエリを発行することができます。
つまり Treasure Data では，データの管理をすべてクラウド側で行うことによってストレージにまつわる問題を解決し，実践的なデータ･アナリティクスに集中できるようにしています。
図3: Treasure Data Cloud Warehouse のアーキテクチャ（再掲）
3. 解析結果の活用に関する問題
最後に，解析された結果をどのように既存のシステムに統合･フィードバックし，活用していくかについて紹介します。
Treasure Data では，解析結果を「MySQLなどの各種データベースに書き出す機能」を提供しています。また，その解析を定期的に行うスケジューリング機能も提供しています。例えば，最新のランキング集計の結果を常に表示しておきたいというケースでは，ランキング集計を行う解析クエリをスケジュールに登録しておきます。Webアプリケーションは，その結果が書き出されるMySQLを参照していれば，その結果は定期的に自動更新されます。
またお客様の要望に応じて，解析結果の可視化を行うダッシュボードの提供も可能です。このダッシュボードでは，分〜年単位でのインターバルで定期的にSQLクエリを実行し，その結果をテーブル・ピボットおよび多種のグラフによって可視化することができます。
図4: TDクエリとシームレスにつながるダッシュボード
さらに，JDBC ドライバによってその他多くのレポーティングツール・ダッシュボードツールへの連携が可能です。今後は ODBC ドライバの提供およびメジャーな BI ツールや可視化ツールとのネイティブな連携を，技術・事業の両輪で進めて行きたいと考えています。
終わりに
さて，前後半の2回に渡って Treasure Data Cloud Warehouse について紹介してきましたが，その概要およびメリットをうまくお伝えすることができていれば幸いです。第3回では実際に導入から簡単なデータ解析を行ってもらうためのチュートリアルを行います。その際にぜひとも一緒に手を動かしていきたいと考えておられる方は，Sign Up Page よりデモアカウントを取得しておいて下さい。
また，質問およびリクエストなどを以下のメールアドレスより受け付けております。何かあれば気軽にコンタクト下さい。（英語・日本語どちらでも対応可能です。）
support[at]treasure-data.com
