Flume

Flume について (“Flume Reliable Distributed Streaming Log Collection” by Jonathan Hsieh, Henry Robinson, Patrick Hunt ; http ://www.cloudera.com/resource/flume-reliable-distributed-streaming-log-collection-hsieh-robinson-hunt の非公式かつ不完全な日本語訳です。 ) Infoscience 永江哲朗

シナリオ
・シチュエーション :
　 - ログを生成するサービスがデータセンターに数百個ある。
　そのサービス群は解析したいログを大量に生成する。
　 - 大量のデータを処理する Hadoop システムを使っている。
・問題 :
　 - すべてのログを Hadoop が解析できる場所に送るにはどうしたらよいでしょうか ?

ユースケース
・ Hadoop クラスターにあるログを集めるとき
・ httpd, mail 等のサービスからログを集めるとき
・アドネットワーク用のカスタムアプリケーションから痕跡 (impressions) を集めるとき
・まだあります
　 - 可用性の尺度
　 - オンライン解析

サンプルトポロジー

“ Flume” があります
・ Flume はログをその生成ノードから取得し、処理ノードに集めるための分散系のシステムです。
・オープンソースです。ライセンスは Apache v2.0 です。
・ Flume の目標
　 - 信頼性 (Reliability)
　 - スケーラビリティ (Scalability)
　 - 拡張性 (Extensibility)
　 - 管理性 (Manageability)
コロンビア・ゴージブロートン用水路(木製) Columbia Gorge, Broughton Log Flume

主要な概念
・データパス (data path) とコントロールパス (control path)
・ノード (node) はデータパス上にあります。
　 - ノードはソース (source) とシンク ( 吸い込み ; sink) があります
　 - 異なる役割をします
　　　・典型的なトポロジーではエージェント (agent) ノードとコレクター (collector) ノードがあります
　　　・プロセッサー (processor) ノードというノードもオプション的に存在します。
・マスター (master) はコントロールパス上にあります。
　 - ノードのコンフィグレーションの中心点です。
　 - 各ノードのソースとシンクを指定します。
　 - ノード間のデータのフロー (flow) をコントロールできます。
　 - 1 つのマスターもしくは ZooKeeper のクォーラムを使った複数のマスターが使えます。

マスター

概要
・ Flume って何 ?
　 - 目標と構造
・信頼性
　 - フォールトトレランスと高可用性
・スケーラビリティ
　 - Flume ノードとマスターの水平方向のスケーラビリティ
・拡張性
　 - Unix の原則 (Unix principle) 、全てのデータ、全てのソース、全てのシンク
・管理性
　 - 動的なコンフィグをサポートする集中的な管理

The logs will still get there. 信頼性 (Reliability)

障害
・障害は様々なレベルで発生します。
　 - ソフトウェアアプリケーションは停止することがあります。
　 - ハードウェアも停止する可能性があります。
　 - ネットワーク機器も止まることがあります。
　 - ネットワークの輻輳やサーバーの過負荷
　 - メンテナンスでの停止
・ログが最終的な目的地に到達することをどうやって確かめればよいでしょうか。

データの信頼性のレベルを選べます
・ベストエフォート
　 - 送信後、確認しません。
・障害の場合は保存して後で再送
　 - ローカルな受信応答、エラーを検知できます。
　 - 障害を検知した場合はフェイルオーバーできます。
・エンドツーエンドな信頼性
　 - エンドツーエンドな受信応答
　 - 複数回リトライすることで、複合的な障害にもデータは耐えることができます。

エージェントの停止に対処する
・ ( 当然ながら ) データは失いたくありません。
・ログの生成ポイントでログに耐久性をもたせます。
　 - ログの生成ノードが停止したら、ログは生成されません。
　 - ログの生成ノードが停止後に復旧したら、データはエンドポイントに到達します。
　　　　・データに耐久性をもたせておけば、サーバ復旧後に使用できます。
　 - ログを生成するアプリケーションにおいて同期書込 (synchronous writes) を許可します。
・エージェントが停止したら再起動するようにウォッチドッグプログラムを使いましょう。

コレクターの停止に対処する
・エージェントのところではデータには耐久性があります。
　 - データロスの可能性とデータロスの可能性を最小化します。
　 - Not Necessary to durably keep intermediate state at collector ( コレクターの途中の状態を保持する必要はありません )
　 - コレクターが停止したらリトライします。
・エージェントが別のパスを使えるようにホットフェイルオーバーを使いましょう。
　 - コレクターが停止したらフェイルオーバーするようにマスターから設定できます。

マスターの停止
・マスターサーバーを単一障害点 (SPOF) にしないでください。
・マスターは以下の二種類の情報を保持します。
(1) コンフィグレーション情報 ( ノード / フローの設定 )
　 - 高可用性をもつ ZooKeeper に保存可能です。
　 - 障害からのリカバリーは容易です
(2) 一時的な情報 ( ハートビートや ACK 、メトリックのレポート )
　 - メモリ上に保存されます。
　 - 障害時にはデータロスします。
　 - これらの情報は非同期に複製できます (lazy replication)

ケミ川(フィンランド)に溢れるログ(丸太) Logs jamming the Kemi River スケーラビリティ (Scalibility)

データパスは水平方向にスケーラブルです
・可用性を増やすのとより多くのデータを扱うのにコレクターを追加します
　 - 1 つのエージェントはコレクターを占有しないと想定します
　 - ( エージェントと HDFS が直接やり取りするよりも )HDFS への接続は少なくなります。
　 - ( エージェントと HDFS が直接やり取りするよりも )HDFS に対するより効率的な書込み
・エージェントはサーバー性能トレードオフに対処するメカニズムをもちます
　 - コレクターのディスク I/O のボトルネックと壊滅的な障害を回避するためにログをローカルに書き込みます。
　 - 圧縮とバッチ処理 (N/W の帯域のために CPU を使います )
　 - Push computation into the event collection pipeline (I/O, メモリ、 CPU リソースのボトルネックのバランスをとります )

ロードバランシング
・エージェントは論理的に分割され異なるコレクターに送られます。
・多くのコレクターが存在するとき、フェイルオーバー先をランダムにするよう設定することができます。
　 - コレクターが停止した場合に負荷を分散できます。
　 - 新しいコレクターが追加された場合、負荷を分散できます。

コントロールパスも水平方向にスケーラブルです
・マスターはノードの設定を動的に変更できます。
　 - 状態の一貫性を保つために合意 (consensus) プロトコルを使用。
　 - 設定のトラフィックにもスケールします。
　 - 将来的なアダプティブな分割にも対応できます。
・ノードは任意のマスターと通信できます。
・マスターは ZooKeeper のメンバーにアクセスできます。

・マスターはノードの設定を動的に変更できます。
　 - 状態の一貫性を保つために合意 (consensus) プロトコルを使用。
　 - 設定のトラフィックにもスケールします。
　 - 将来的なアダプティブな分割にも対応できます。
・ノードはどのマスターとも通信できます。
・マスターは ZooKeeper のノードにアクセスできます。
コントロールパスも水平方向にスケーラブルです

生のログ（丸太)を役にたつものに変えましょう… Turn raw logs into something useful… 拡張性 (Extensibility)

Flume は容易に拡張可能です
・シンプルなソースとシンク (sink)API
　 - イベント粒度のストリーミング設計 (Event granularity streaming design)
　 - シンプルな命令が多数あり、複雑な動作を構成できます。
・エンドツーエンドの原則
　 - Put smarts and state at the end points. Keep the middle simple. ( 処理と状態をエンドポイントに入れます。パスの間をシンプルに保ちます )
・ Flume には信頼性があります。
　 - Just add a new source or add a new sink and Flume has primitives to deal with reliability. ( 新しいソースとシンクを追加するだけです。 Flume は信頼性を扱う基本構造をもちます )

多様なデータソース
・プッシュ型とプル型のソースを扱えます。
・たくさんのレガシーなイベント ( ログ ) ソースをサポートします。
　 - ファイルの tail
　 - exec されたプログラムからの定期的な出力
　 - syslog, syslog-ng
　 - Experimental: IRC / Twitter / Scribe / AMQP

多様なデータ出力
・データを様々なシンク (sink) に送信できます。
　 - ファイル、 HDFS, コンソール、 RPC
　 - Experimental: HBase, Voldemort, S3, など
・拡張可能な出力フォーマットと出力先をサポートします
　 - 言語中立性とオープンなデータフォーマット (JSON, avro, text)
　 - 圧縮された出力ファイルは開発中です
・送信中のイベントデータを処理するのにデコレーター (decorators) を使えます
　 - サンプリング、属性抽出、フィルタリング、投影 (projection) 、チェックサム、バッチ処理、送信中の圧縮など…

Wheeeeeeee! ※ 訳注 : “Splash Mountain is a themed log flume ( ここでの’ log flume’ は用水路の意味 ) attraction at Disneyland, Tokyo Disneyland, and the Magic Kingdom” (wikipedia) ということを使った洒落のようです管理性 (Manageability)

一元的なデータフローの管理
・ノードのソース (source) 、シンク (sink) 、データフローを 1 箇所で指定します。
　 - ノードの役割をシンプルに明示します：コレクター、エージェント
　 - ノードに対してカスタム化されたコンフィグも指定できます
・コントロールインターフェース：
　 - Flume shell
　 - web 画面
　 - HUE + Flume Manager App (Enterprise users)

出力のバケット (Output bucketing)
・出力ファイルの自動的なマネジメント
　 - 時刻ベースで HDFS ファイルを管理

シンプル化されたコンフィグレーション
・ flume ノードをより抽象的なレベルで設定するには、論理ノード (logical node) を使います。
　 - Flume ノードは物理ノード (physical node) です。
　 - それぞれの Flume ノードプロセスは複数の論理ノードをもてます
・ ( 論理ノードによって ) 以下のことが可能です :
　 - 設定時に指定する量を減らせます。
　 - 管理プロセス中心の管理のオーバーヘッドを減らせます。
　 - より細かい粒度のリソースコントロールとフローの分離

フローの分離 (Flow Isolation)
・生成された時刻と場所で、異なる種類のデータを分離できます
　 - 複数の論理ノードをサーバーにもつ
　 - それぞれの論理ノードが独自のデータソースをもつ
　 - それぞれの論理ノードが独自のデータシンク (sink) をもつ

習熟したユーザー向け ( の話 )
・任意のデータパスを設定するのに簡潔かつ正確なコンフィグレーション言語があります。
　 - データフローは基本的に DAG( 無閉路有向グラフ、 Directed Acyclic Graph ）です。
　 - 特定の ( ログ ) イベントのフローを制御
　　　・耐久性とフェイルオーバーのためのメカニズム
　　　・上記メカニズムのパラメータをチューニング
　 - 設定の動的更新
　　　・フェイルオーバー方法の動的更新
　　　・新規に追加されたサーバーの管理
　　　・分析方法の変更

結論 northern new mexico, 1957 logpile

要約
・ Flume は、ログのような大量の連続的なイベントを収集・配信するための分散性と信頼性、およびスケーラビリティをもつシステムです。
　 - 変更可能な信頼性レベル
　 - ZooKeeper をバックエンドに使った、信頼性のあるマスター
　 - バッチ処理にも使えるように、 HDFS 上でバケット化したファイルにデータを書き込めます。
　 - 動的に設定可能なノード
　 - エージェントとコレクターのトポロジーに対する、単純化され自動化された管理
・ Apache v2.0 ライセンス

Contribute!
• GitHub source repo
– http://github.com/cloudera/flume
• Mailing lists
– User: https://groups.google.com/a/cloudera.org/group/flume-user
– Dev: https://groups.google.com/a/cloudera.org/group/flume-dev
• Development trackers
– JIRA (bugs/ formal feature requests): https://issues.cloudera.org/browse/FLUME
– Review board (code reviews):
http://review.hbase.org -> http://review.cloudera.org
• IRC Channels
– #flume @ irc.freenode.net

http://twitter.com	2
https://twitter.com	1
http://www.onlydoo.com	1
http://paper.li	1

Flume

by あしたのオープンソース研究所　 on Aug 04, 2011

Accessibility

Tags

Upload Details

Usage Rights

4 Embeds 5

Statistics

Flume — Presentation Transcript

Flume

by あしたのオープンソース研究所 on Aug 04, 2011

Accessibility

Tags

Upload Details

Usage Rights

4 Embeds 5

Statistics

Flume — Presentation Transcript

by あしたのオープンソース研究所　 on Aug 04, 2011