音田 司 BigDataといえば、大規模イベントログ収集は必須!! 簡単、かつ、リアルタイムにログを収集するために、 今、ストリーム転送が注目されています。 そのためのOSSプロダクトとして、 今回は、Javaで開発されている 「FlumeNG」 について、解説します。 本プロダクトはHadoopディストリビューションのCDHでサポートされている 「Flume」の進化系のプロダクトであり、今後要注目のプロダクトと考えています。

1. Advanced Tech Night No.04
ログ収集フレームワークの新バージョン
FlumeNG
の紹介
2012/03/01
Acroquest Technology
音田 司(@t_otoda)

2. 自己紹介
 氏名 ：音田 司
 所属 ： Acroquest Technology
 Twitter ： @t_otoda
 専攻 ：数学科（学部卒）
↑私は写ってません
 業務
• 現在、主にOSS(Hadoop等)の調査/検証/導入
支援を行っています。
• これまで、Hadoop、HBase、Flumeなどを中心
に扱ってきました。
2

3. 目次
1. Flume
1) Flumeとは
2) Flumeの特徴
3) アーキテクチャ
2. FlumeNG
1) FlumeNGとは
2) アーキテクチャ
3) FlumeOGからの改善点
4) FlumeNGで注意したい点
3

4. Flume
4

5. 1. Flumeとは
1. 大量のログデータを、多量のソースから中央のデー
タストアへ、効率的に収集、集約、移動することを目
的に開発された、高い信頼性と可用性を持つ分散型
のサービスです。
2. Clouderaが開発したHadoopエコシステムの1つ
3. CDHでHDFSやHBase、Hiveとともにサポートされて
いる
① CDH3u3では、Flume0.9.4+25.40
② Flume単体の最新バージョンは、Flume1.0.0
(=Flume NG)
5

6. (余談)大量のログデータ(BigData)とは？
6

7. 2. Flumeの特徴 （1/2）
1. ログのストリーム転送
 text1行を1イベントとしてリアルタイムに転送
2. 選べる3つの信頼性
信頼性のレベル 概要
End2End WALを残し、Flumeが生存する限りフロー末端までの
転送を保証
DiskFailOver 次のマシンへの転送障害発生時にログをディスクに保
存
BestEffort 受信の確認や再送は行わない
7

8. 2. Flumeの特徴 （2/2）
3. スケーラビリティ
 Agent、Collectorの追加によるスケールアウトが
可能
4. 設定の疎結合性
 ログの種類に影響されず、設定可能
5. ノード管理の簡易化
 FlumeMasterでの中央管理により、多数の
FlumeNodeに対する設定反映が動的かつ集約的
に可能
8

9. 3. アーキテクチャ(データフロー)
データ（ログ）を収集するAgent、Agentからの情報を集約する
Collectorに対して、一連のデータフローを設定します。
ログ
Agent
Collector
ログ
Agent
ログ蓄積サーバ
ログ
(HDFS・S3・ローカル)
Agent
Collector
ログ ログの転送/書込み
Agent
ログの転送
Master FlumeMasterは全サーバ上の
FlumeNode(Agent/Collector)の状態を管理
9

10. 3. アーキテクチャ(論理ノード)
FlumeNode（Agent/Collector）は論理ノード（Thread）を内
部に持ち、データの入力、変換、出力を行います。
Agent Collector
論理ノード(Thread) 論理ノード(Thread)
Sink Sink Source Sink Sink
Source
Decorator Decorator
入力 出力 入力 出力
 論理ノード内の設定には以下の３種類があります。
1. Source ⇒データ入力部
2. SinkDecorator ⇒SourceとSinkの間の中間処理(任意)
3. Sink ⇒データ出力部
 各部分は独自のPluginにより拡張可能です。
10

11. 検証事例
Agent
Agent
Agent
Agent
(Thread)
(Thread)
(Thread)
Collector
Agent
Collector
Agent
Agent Collector ログ蓄積サーバ
Agent (Thread)
(Thread)
(Thread) Collector
(Thread) (ローカル)
(Thread)
(Thread)
Agent
Agent
Agent ログの転送/書込み
Agent
(Thread)
(Thread)
(Thread)
ログの転送
ログ出力サーバ： 80 台 ログ収集/蓄積サーバ：1 台
3論理ノード/Agent(240Thread) 80論理ノード(80Thread)
ログ出力量：平均 60 MB/分 １日の全転送量：0.8 TB
最繁時 100 MB/分 １台当たりの転送速度：1.4 Gbps
11

12. FlumeNG
12

13. 1. FlumeNGとは
Flumeが抱える制限を解決するため、
達成する目的は変更せずにリファクタリングした、
次世代(NewGeneration)のFlume
※NGは「ダメダメ」ということではありません。。。
※慣例として、FlumeNG以前のFlumeは、FlumeOGと呼びます。
No. 変更点 Flumeの抱える制限
1 Channel・Transactionの Sinkの遅延がSourceの遅延に影響する
追加
2 状態管理の実装変更 状態変更に伴うスレッド制御について一部問
題がある
3 Propertiesファイルによる Masterサーバからしか設定変更できない
設定
4 Groupの追加 設定で個々のホスト名を使用する
13

14. 2. アーキテクチャ
データ（ログ）を収集するAgent、Agentからの情報を集約する
Collectorに対して、一連のデータフローを設定する所は変わら
ず、内部構造が変更になった。
ログ
Agent
Collector
ログ
Agent
ログ蓄積サーバ
ログ
(HDFS・S3・ローカル)
Agent
Collector
ログ ログの転送/書込み
Agent
ログの転送
Master FlumeMasterは全サーバ上の
FlumeNode(Agent/Collector)の状態を管理
14

15. 3.1 Channel・Transactionの追加（1/2）
 Channel 論理ノードという概念がなくなる
Agent1 Client Sink
Agent2
Sink Source Channel
Sink
出力 入力 Channel
出力
 改善点
 いままでSourceまたはSinkの遅延は、他方に影響を与えた
 Channelの導入により、FlumeOGの時の論理ノードThreadがなくなり、
SourceとSinkがそれぞれThreadになることで非同期化される
15

16. 3.1 Channel・Transactionの追加（2/2）
 Transaction
Agent１ Agent２
Channel１ Sink１ Source2 Channel2
Transaction開始
データ取得
データ転送
Transaction開始
データ登録
Commit
Commit Agent２でのtransactionをCommitしたあと、
Agent１でのtransactionをCommitする。
エラー発生時は開始前にRollbackする。
16

17. 3.2 状態管理の実装変更
1. FlumeMasterが行っていた状態管理の実装変更
 状態に合わせてスレッドを起動/停止するのではなく、
スレッドの起動/停止に合わせて状態を変化させる。
Agentが起動した
論理ノードThreadを
Source,Sinkのスレッ
コントロールできない
ドを直接管理する。
⇒動的設定変更でお
かしくなりやすい。
Agent(Process) Agent(Process)
論理ノード(Thread) Source(Thread) Sink(Thread)
Source Sink Source Sink
Channel
17

18. 3.3 Propertiesファイルによる設定（1/2）
1. FlumeOGでは設定変更にはFlumeMasterからの
変更が必須。
2. FlumeNGではプロパティファイルによる設定が可
能になる。
 FlumeMasterを用意するか選択ができる。
3. プロパティファイルによる設定の導入には、以下
のコンセプトが関わっている？
Centralized is important to about 50% of users. The
other half don't want it and would prefer simple local
files. Everyone agrees dynamic configuration (runtime
reconfiguration) is critical as downtime for data ingest
systems hurts.
18

19. 3.3 Propertiesファイルによる設定（2/2）
Avro(0.0.0.0:41414)をLISTEN⇒メモリに一時保存⇒ログ出力
という構成時の設定例
# now that we've defined all of our components, tell 使用するコンポーネントを定義
# host1 which ones we want to activate. <ホスト名>.
host1.sources = avro-source1
host1.channels = ch1
[sources|channels|sinks]=xxx
host1.sinks = log-sink1
# Define an Avro source called avro-source1 on host1 and
tell it 各コンポーネントを定義
# to bind to 0.0.0.0:41414. Connect it to channel ch1.
host1.sources.avro-source1.type = avro <ホスト名>.
host1.sources.avro-source1.bind = 0.0.0.0 [sources|channels|sinks].
host1.sources.avro-source1.port = 41414 xxx.type=yyy
host1.sources.avro-source1.channels = ch1
…
# Define a memory channel called ch1 on host1
host1.channels.ch1.type = memory
Channelは現在3種類
# Define a logger sink that simply logs all events it receives (処理が早い) (信頼性高い)
# and connect it to the other end of the same channel. Memory > File > JDBC
host1.sinks.log-sink1.type = logger
host1.sinks.log-sink1.channel = ch1
19

20. 3.4 Groupの追加
1. 「Group」という概念の追加
① すべてのClientとサーバはGroupに属する。
② 転送先の設定は、特定の物理ノード(ホスト名)を指定せず、
Groupで指定する。
20

21. 4. FlumeNGで注意したい点
1. 未実装の機能が多く残っている
① FlumeMasterや設定投入、監視用メトリクス
（Source、Sinkの挙動を示すカウンターなど）など
② Flume1.1.0にて対応予定
2. FlumeOGとの互換性は保証されていない
① 通信プロトコルは現在Avroのみ対応
② プラグインの実装方法が変わる
③ 設定内容が変わる(Channelの追加、Source/Sink
の名前変更)
21

22. （余談）FlumeNGの現状(３/１時点)
1. ２０１２/１/５リリース(Flume1.0.0)されています。
2. まだまだ実装中
(実装残タスク：8/１４)
3. ２０１２年上旬
安定版リリース？
22

23. まとめ
1. Flumeは大量のログデータを、多量のソースか
ら中央のデータストアへ、効率的に収集、集約、
移動することを目的に開発された、高い信頼性
と可用性を持つ分散型のサービスです。
2. FlumeNGはFlumeOGの問題点を、大胆なリ
ファクタリングにより、改善させています。
(現在進行形)
23

24. 参考資料
1. Inside Flume
• http://www.slideshare.net/cloudera/inside-flume
2. Flume(日本語)
• http://www.slideshare.net/ashitanoken/flume
3. Apache Flume (incubating)
• https://blogs.apache.org/flume/entry/flume_ng_architecture
4. Flumeユーザガイド
• http://oss.infoscience.co.jp/flume/UserGuide/index.html
5. Flume Wiki
• https://cwiki.apache.org/FLUME/flume-ng.html
6. FlumeNG UserGuide
• http://dl.dropbox.com/u/27523578/Flume/FlumeUserGuide.pdf
24

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