Amebaにおけるログ解析基盤Patriotの活用事例

Amebaにおけるログ解析基盤Patriotの活用事例

株式会社サイバーエージェントアメーバ事業本部 Ameba Technology Laboratory 善明晃由、飯島賢志

2

本日の内容

• AmebaサービスとAmeba Technology Laboratoryについて

• ログ解析基盤Patriotの概要

• データ分析のためのPatriotの活用体制

• ログ転送システムとApache Flume

株式会社サイバーエージェント

Amebaサービスと Ameba Technology Laboratory

について

4

Ameba事業ー PC向けサービス


5

Ameba事業 - スマートフォンプラットフォーム

約40個のコミュニティサービスと約80個のソーシャルゲームを

抱えるプラットフォーム


6

Ameba Technology Laboratoryについて

• Amebaの大規模データを集約的に扱う組織

• 2011年4月に開設、現在約20名が所属


推薦フィルタリング

ログ解析データマイニング検索

大規模分散処理

(ログ解析基盤)

ログ解析基盤Patriotの概要

8

Amebaのログ解析基盤：Patriot

• Amebaのサービス共通のログ解析基盤 • Ameba Technology Laboratoryで開発・運用

• サービスのユーザ行動の分析

• レコメンド等の大規模データ活用による機能の提供

• Hadoopクラスタ上に構築 • HDFSにログデータを集約

• Hive/MapReduceを用いた集計

• HBaseを用いて処理結果を活用

• Flumeを用いたデータ収集

9 株式会社サイバーエージェント

システム構成 Ameba サービス

ログ転送（SCP） MySQLレプリ

【Logサーバ】ログの一時集約

Hadoop クラスタ

ログ整形 Hiveインポート

サマリView、アドホックHiveクエリ

（自作WebUI）

【Batchサーバ】ワークフロースケジューラ

HiveJobをキック

ログのリアルタイム転送（Flume）

各部門のレポーティングツール

【外部連携サーバ】サマリーデータ取得 Hiveクエリ実行ジョブステータス取得

10

これまでの経緯

• 2010年７月：初期リリース (CDH3b系)

• 2011年３月： CDH3u0にアップグレード

９月：独自開発のワークフロースケジューラ、サマリDBとしてHBaseを導入

• ２０１２年５月：スマートフォンプラットフォーム向けPatriotの構築 (CDH3u3)

１０月：ログ収集にFlumeを導入（Apache Flume1.3）

• ２０１３年３月：外部連携サーバ（Patriot Bridge）の導入

７月： PatriotのDC移設、CDHアップグレード(CDH4.3)

GHE、Jenkinsを用いた運用フローの見直し

８月：スマートフォンプラットフォーム向けPatriotを統合


11

ジョブ数の推移


0

2000

4000

6000

8000

10000

12000

14000

2012年4月 3154ジョブ

2013年11月 11639ジョブ

クラスタ統合

12

ジョブの内訳 (2013年11月1日時点)


8694

445

767

290

1443

集計クエリ

データ取り込みクエリ

その他Hiveクエリ

ログ転送

その他

約75%が集計クエリ (SELECT COUNT(1) など)

中間テーブル作成マスターデータ更新

ADD PARTITION、など

レコメンドバッチバックアップ、など

13

ワークフロースケジューラ

• MySQLでジョブと依存関係を管理

• 設定ファイル一つでジョブ追加可能


ジョブ管理DB (MySQL)

ジョブ登録 (cron)

(*.pbc (rubyDSL))

(*.pbc (rubyDSL))

バッチ設定 (*.pbc

(rubyDSL))

ワーカー (ruby daemon)

ワーカー (ruby daemon)

Hiveクエリ

ログ取り込み

ログ転送

レコメンドバッチ

14

ジョブ設定DSL

• 柔軟なジョブのグループ化により細粒度の依存関係を簡潔に記述

• プラグインとしてコマンドを追加可能


job_group{

require ['base_tbl_#{$dt}']

hivequery{

require ['tmp_tbl_#{date_sub($dt,1)}']

produce ['tmp_tbl_#{$dt}']

hiveql 'INSERT OVERWRITE ...'

}

hive2hbase{

require ['tmp_tbl_#{$dt}']

hiveql 'SELECT count(distinct id) FROM ..'

}

}

Hiveの結果をHBaseにPutする

コマンド

Hiveクエリを実行するコマンド

ジョブをグループ化し依存関係を設定

日を跨ぐ依存関係

データ分析のためのPatriotの活用体制

16

データ分析部門マーケティング部門

運用、活用体制


GitHub Enterprise

バッチ設定リポジトリ

マーケティング部門

リポジトリ

データ分析部門

リポジトリ

ゲームコンサルデータマイニング

エンジニアプロデューサマーケティング

担当エンジニア担当エンジニア

Jenkins

Pull

Request

Pull

Request

構文チェックなど

17

バッチ設定のレビュー

•可能な部分はJenkinsで自動化 • 構文チェック

• キーの重複検査

•テンプレートを用いた効率化 • バッチ設定はERBテンプレートが利用可能

• 共通指標はテンプレート化しレビューを省略

•現在さらなる自動化を検討中 • クエリをパース・分析するライブラリを開発

• パーティションの選択の有無などレビュー時に必要な確認を自動化

• 最適化、リファクタリング

• クエリの複雑さを計測など


18

テンプレート化の例：アクセスログ解析

PV, レイテンシなど約20項目の集計を１つのテンプレートで設定

• PV • 日別、時間別

• デバイス、OS別

• レスポンスタイム • 中央値

• 最小、最大

• 上位、下位5%値

など


job_group{

# ログ取り込み設定、前処理など

}

import_erb_config 'accesslog_analysis_daily.erb',

{'service'=>'blog', 'dev'=>'pc', 'paths' => {

# 集計対象URL

...

}

}

19

Jenkinsを用いたレビューの自動化

入力パーティション数

非効率なJOIN

など


20

Jenkinsを用いたバッチ処理の分析の例

利用頻度の高いサブクエリ

→ 中間テーブル化、View、UDF、etc


21

活用例１：データマイニング用中間データ


GitHub Enterprise



リポジトリ

データマイニング

エンジニア

担当エンジニア

Jenkins

データマイニング用中間データ生成ジョブ (INSERT OVERWRITE)

分析結果

Hive Warehouse

中間データ更新

22

活用例２：レポーティングツール連携


GitHub Enterprise



リポジトリ

担当エンジニア

Jenkins 外部連携

API

集計クエリ (SELECT文) 通知スクリプト

レポーティングツール

集計完了通知

集計結果取得

ログ転送システムと Apache Flume

24

Patriotへのログ転送

• 2012.05以前 SCPでログ転送

• 2012.05 Scribeを使ったリアルタイムなログ転送を一部で開始

• 2012.10 ScribeをFlumeに置き換え、Amebaサービスに導入開始

• 2013.01 Patriot以外のシステムへの転送も開始

• 2013.09 主要AmebaサービスにほぼFlume導入完了

• 2013.11 Ameba SAP(CAグループ)のログ収集を計画中

25

Patriotへのログ転送

• Flume導入サービス： 80 service (導入拡大中)

• ログの種類： 160 log type (service×log type)

• 導入ホスト数： 1,000 host

• ピーク時： 90,000 lines / sec

• サイズ（Raw）： 1.0 TByte / day

26 株式会社サイバーエージェント

ログ転送システム構成

Hadoop クラスタ

Ameba サービス

Ameba サービス

Ameba サービス

Aggre gator

Aggregator

Aggre gator

HBase クラスタ

ストリーム処理 (HBase sink)

ストリーム処理 (Onix)

Recommend システム

Trend システムログ監視

システム

• Flumeで分岐・統合など柔軟にルーティングを構築

27

Flume Collector

• 収集対象ファイルが出力されるホストで起動するFlume Agent。

• 収集したログはAggregatorに転送する。

• Flumeの設定

• 秒間1000linesほどのログでもヒープは128Mで十分。

• 監視としてMBeansの各種メトリクスをGangliaに送信。

• アラート監視にはJolokiaを使ってhttp経由でMBeansを参照。

http://www.jolokia.org/

※リアルタイムにMBeansを見るときはVisualVMなどを使用。

Intermediate Aggregator

Final Aggregator

Collector


Collector

Collector




28

Flume Aggregator

• Intermediate Aggregator

• Final Aggregatorにログ転送するFlume Agent。

• ルーティングの中継としてDC毎に設置。

• スペック：物理×2 / 4Core / Mem8G / RAID1 × 2

VM×3 / 4Core / Mem8G

• Final Aggregator

• 転送されたログを最終的に集約するFlume Agent。

• HDFSなどへの書込み、他システムへのルーティングをする役割。

• スペック：物理サーバ×5 / 4Core / Mem24G / RAID1 × 2


Final Aggregator

Collector


Collector

Collector

29

ログ転送で使っている機能

• Channel Selector ：他システムへの振り分け、Multiplexing

• TimeStamp Bucket ：日時などでBucketingしてHDFSに書込み

• Reset Connection ： LoadBalancer経由のログ転送

• Deflate Compression ：圧縮転送

• HBase sink ： HBaseに書込み

• File Channel ：ロストを許さないログで使用（集計 / 監視）

• Memory Channel ：若干のロストを許容するログで使用（Recommend / Trend）

30

Flume Agent (JVM)

Channel Selector

• 機能

• Sourceで受け取ったログを指定したChannelに流し込む。

• 複数のChannelに同じログを同時に転送も可能（Multiplexing）。

• この機能で他システムへの振り分けをしている。

• これで同じログを他システムで重複して取得する必要がなくなった。

• optional channels(FLUME-1768, 1769)が実装された CDH4.2.0以降のものが使い勝手がよい。

• optional channelsはもしChannelへのputを失敗してもリトライしない設定。

• リトライしないことで他の重要なChannelに影響を及ぼさない。

• Memory Channelのようなロストを許容できる場合との組合せに適している。

Source

Selector

Channel Channel Channel

Sink Sink Sink

31

TimeStamp Bucket (HDFS Sinkの機能)

• 機能

• HDFSに書込みむとき、ログのHeaderのTimeStampを元に日付や時間で正確にBucketingできる。

• TimeStampをsetするInterceptorについて

• Flumeの TimestampInterceptor では転送時の現在時刻をTimeStampとするがログの日時をパースするように自社でInterceptorを独自実装。

• JSON、TSV、Syslogなど多様なログに対応。

hdfs://namenode/flume/%{header1}/%{header2}/%Y-%m-%d/%H/

32

Reset Connection

• 機能

• Collectorで転送先をLoadBalancerにするときに使用。

• 指定した間隔でLBに再接続するので、LBに登録した host:port に分散して転送ができる。

• 使用経緯

• Flumeの設定で元々LoadBalance機能はあるが、100近いサービスを横断した設定ファイル変更はChefを使っているとはいえ手間。

• 設定ファイルでは宛先をLBのIPにして、LBの設定を変えるだけで転送先の増設などに対応できる。

• 弊社FlumeコミッターのJuhaniが作ったパッチで稼働中。 (FLUME-2154, CDH5.0.0 beta1で適用)

agent.sinks.avro.reset-connection-interval = 60

Aggregator Load

Balancer

Aggregator

Aggregator

Collector

33

Deflate Compression

• 機能

• Avroを使った転送で圧縮した転送ができる。

• ZlibEncoder と ZlibDecoder を用いて通信を圧縮している。

• ネットワーク負荷を数分の一に低減できる。

• CDH4.3.0以降のもので利用可（FLUME-1915）。

agent.sinks.avro.compression-type = deflate

34

HBase Sink

• 機能

• 転送したログなどをHBaseに保存できる。

• HBase SinkとAsync HBase sinkの2タイプがある。

• Async HBase sinkの方が高速。ただしHBase Sinkにあるケルベロス認証は非サポート。

• Async HBase sinkを使うにはHBaseのvalueをLong型にする必要あり。

• HBase SinkのSerializerをフォークして作りこみ、ストリーム処理した結果を Patriotのデータ構造に変換してHBaseにリアルタイム反映するのに利用している。

HBase クラスタ

処理結果をSerializerで変換

Aggregator

35

コンポーネントのカスタマイズ

• カスタマイズしたコンポーネントをFlumeに簡単に組み込める。

• Jarファイルにして /usr/lib/flume/lib などに配布して下記のように指定する。

• このようにしてFlume自体に実装されてない機能、独自システムとの連携などに対応できる。

# example agent.xxx.custom.type = [カスタマイズしたClass名やMethod名など] agent.xxx.custom.channel = ch1 agent.xxx.custom.port = 12345 ※ xxx : sources, channels, sinks などのコンポーネント

36

コンポーネントのカスタマイズ - HBase Sink

• typeには自分で作ったClass名を指定。

※ type = hbase と指定した場合はデフォルトのHBase Sinkになる。

• serializerのみClass指定することもできる。

• 設定項目もカスタマイズできる。

agent.sinks.hbase.type = jp.co.cyberagent.flume.sink.hbase.PatriotHBaseSink agent.sinks.hbase.serializer = jp.co.cyberagent.flume.sink.hbase.PatriotSerializer agent.sinks.hbase.channel = ch1 agent.sinks.hbase.table = table_name agent.sinks.hbase.columnFamily = data agent.sinks.hbase.custom = custom

HBase クラスタ

処理結果をSerializerで変換

Aggregator

37

Flume Agent (JVM)

コンポーネントのカスタマイズ - Channel Selector

• デフォルトのSelectorは1headerでのみの判別になるが、複数headerをみてChannelに流し込むようにカスタマイズ。

• 設定例

• trend-log は trend-ch に流し込み、

• applog で、サービス名が「girlfriend」、行動タイプが spend のログは hdfs-ch と spend-ch の両方に流し込み、

• それ以外のログはデフォルトで hdfs-ch だけに流し込む設定。

agent.sources.avro.selector.type = jp.co.cyberagent.flume.selector.MultiHeaderSelector agent.sources.avro.selector.headers = category,service,type agent.sources.avro.selector.required.trend-log = trend-ch agent.sources.avro.selector.required.applog.girlfriend.spend = hdfs-ch spend-ch agent.sources.avro.selector.default = hdfs-ch

Source

Selector

hdfs-ch trend-ch spend-ch

Sink Sink Sink

trend-log applog.girlfriend.spend

default

38

スケールアウトについて

• Final Aggregator - HDFS Sink

• HDFSへの書込みは最初は1Channel ： 1HDFS Sinkで十分。

• 基本的にはホスト追加でスケールアウトできる。

• もし転送量が大きくなり(秒間数万とか)リソースが余ってるのにスループットが出なくなったら、hdfs.batch-sizeを上げるより 1Channelに対してHDFS Sinkを並列化する方がスケールする。

http://blogs.apache.org/flume/

• 1Channel ： 2HDFS Sink （2並列）より並列数を増やしてもスケールはあまりしない。 ※同時書込みファイル数が1万近い場合

• Performance Test by Cloudera

1ホストにおいてもChannelを複数に分けた方がスケールする。 https://cwiki.apache.org/confluence/display/FLUME/Flume+NG+Syslog+Performance+Test+2012-04-30

Channel

HDFS Sink

Channel

HDFS Sink

HDFS Sink

Channel

HDFS Sink

HDFS Sink

Channel

HDFS Sink

HDFS Sink



https://cwiki.apache.org/confluence/display/FLUME/Flume+NG+Syslog+Performance+Test+2012-04-30





39

スケールアウトについて

• Intermediate Aggregator

• 他のホストに転送するだけなら大きなサーバリソースは不要。

• Collectorが100台ほどでもホスト2,3台の冗長化構成で十分。

• もし負荷が高くなってもホストを追加すればスケールできる。

• Aggregator共通

• File Channel より Memory Channel の方が低レイテンシでスケールしやすい。

• File Channelを使っていてログ量が大きければ物理サーバ、そうでなけばVMで基本問題なし。

• File Channel で物理サーバの場合、I/O負荷低減のためディスクを2つ用意し下記のようにPartitionを分けるとよい。

/data1 ： checkpointDir用のパーティション

/data2 ： dataDirs用のパーティション

40

HDFSに保存したログの重複について

• HDFS Client にはトランザクションの仕組みがなく、HDFSとの通信でタイムアウトなどが起こると、成功したか分からないものは処理をやり直すため若干の重複が起こりえる。

• HDFSに書き込む batch-size が大きいほど重複は起こりやすい。

• 重複率は0%〜0.005%程度。

※秒間1000linesほどのWebサーバのログ、batch-size=100の設定で調べた結果。

• 重複を許容できなければMapReduceでユニークにするなどで対応する。

• 逆にデータのロストは File Channel を使えば発生しない。

※Memory Channelは停止前にChannelにデータがあれば、その分は失われるしまう。その代わり、パフォーマンスが高い。

41

過去のトラブル解決

• HDFSへの同時書込みファイル数のlimitに達した

• Flume Aggr側： ulimitの上限を65536に変更。

• DataNode側： Xceiverの上限引き上げ。

• 起動時のReplayに時間がかかる場合

• ChannelSizeが数千万以上溜まったときに稀に発生。

• use-fast-replayをtrueにするなど他のReplay方式を試すと速く終わることも。

• File ChannelのCheckPointでファイルのlock取得でタイムアウト

• I/O負荷が高いホストで発生。

• I/O負荷の原因となっている元を解消する。

• もしくはFile Channelの設定で write-timeout の値を引き上げ(default：3秒)。

42

今後の展望

• Flume導入範囲の拡大

• SSL通信機能(FLUME-997, CDH4.4.0で実装)の検証

• Final Aggregatorの負荷軽減

• HDFS上に作るファイル単位ごとに担当するAggregatorを振り分ければより少ないサーバリソースでHDFSへ書込みできそう。

43

まとめ

• Amebaのログ解析基盤Patriotについて

• GithubEnterpriseとJenkinsを用いて他部門が利用できる体制

• データマイニングエンジニアやレポーティングツールとの連携

• FlumeでHadoopクラスタへリアルタイムに大規模なログ転送を実現

• HDFSへの書込みだけでなく、一度のログ転送で同時に他システムへログを流し込み、ネットワーク負荷を軽減

44

最後に

• 以前の発表

• Patriot （Hadoop Conference 2011 winter）

http://www.slideshare.net/toutouzone/hadoop-conferencejapan2011

• Flume （Hadoop Conference 2013 winter）

http://www.slideshare.net/iijiji0314/flumeameba

• Onix （Data Stream Processing and Analysis with Akka @ Scala Conference 2013）

http://www.slideshare.net/romanshtykh/data-stream-processing-and-analysis-with-akka






















45

最後に

• Ameba Technology Lab ではエンジニアを募集しています！

http://www.cyberagent.co.jp/recruit/career/

• Hadoop / データマイニング / 機械学習/ 検索などに興味がある人はお声がけください。





ご清聴ありがとうございました。