Flume cassandra real time log processing (日本語）

：
Cassandra + Flume：
リアルタイム、大容量ログ処理
リアルタイム、大容量ログ処理ログ

ジェミナイ・モバイル・テクノロジーズ

2011/3/7 Gemini Mobile Technologies, Inc. 1

概要
1. ログ収集、データベースへの格納
ログ収集、データベースへの格納
収集
• 複数のアプリケーション・ノードからの、 Flumeによる信頼性や効率の高いログ収集。
• Cassandraデータベースへの生ログや処理済みログの格納。

2. リアルタイム、オンデマンドのレポート
リアルタイム、
• ウェブGUIからCassandraへのクエリー。
（例）1秒当たりトランザクション処理件数（TPS) VS 時間、ユーザーのCDR検索。

によるサマリーレポート
3. Map-Reduceによるサマリーレポート
• （例）ユーザー群毎の種類別（音声、データ、メール等）月間利用

アプリケーアプリケー … アプリケー
ション・ノードション・ノードション・ノード

ログ・ログ・
OA&M
アグリゲータアグリゲータ

レポート (Web
GUI) Cassandra
Cassandra

2011/3/7 Gemini Mobile Technologies, Inc. All rights reserved. 2

主な利点
1. リアルタイム、最新のビジネス・インテリジェンス
リアルタイム、最新のビジネス・インテリジェンス
• 準リアルタイムの動的レポート。

2. 大容量の履歴データのフレキシブルな分析
大容量の履歴データのフレキシブルな分析
データのフレキシブルな
• 時間範囲、生ログ・フィールド、処理済みログ・フィールドによるインスタント・クエリー
（フラット・ログファイルでなく、データベース内にデータを格納して高速なクエリー対応）。
• Map-Reduceによる、オンデマンドでサマリー・レポートのカスタマイズ生成。

3. 複数のデータセンター対応
複数のデータセンター対応
のデータセンター
• 近接のデータセンター内で収集、保存。データセンター間のクエリー、分析。

4. 信頼性の高い、簡単なオペレーション、保守、拡張性
信頼性の簡単なオペレーション、保守、
なオペレーション
• ネットワークやPC障害時にもデータ損失がない。
• データ量（格納データのサイズ）の増加や速度（データ受信速度）の高速化に合わせ、PCを水平的に
増設し、最大数百台のノード、テラバイト級データ/日に拡張可能。
• 大規模ネットワーク向けに容易なセットアップ、設定、監視。

5. 容易なカスタマイズ
容易なカスタマイズ
• オープンソース。ログフォーマットのカスタマイズやレポートのカスタマイズ、クエリー向けに容易に変更
可能。


ログ収集：
ログ収集：Flume
収集
• オープンソースのログ収集システム：http://archive.cloudera.com/cdh/3/flume/UserGuide.html
• Flumeエージェント：設定可能な間隔でログを読込み（例、100ms）、コレクター・ノードに送信。
• Flumeコレクター：ログを解析し、Cassandraへ挿入。
• Flumeマスター：エージェントやコレクターの健全性や処理状態を監視。

アプリケーション・
ノード 1

Flume
agent1_src1 Flumeアグリゲーター

Flume
Flume collector_src1
agent1_src2
Cassandra
Flume
アプリケーション・ collector_src2
ノード 2
Flume
agent2_src1 Cassandra
Flume
Flume マスター
agent2_src2
4
2011/3/7 Gemini Mobile Technologies, Inc. All rights reserved.

ストレージ・レイヤ：
ストレージ・レイヤ：Cassandra

• アパッチ・プロジェクトに参画するCassandraは、ストレージ・レイヤのオープンソース・ソフト
ウェアであり、高性能、高拡張性の分散型データベース。
• アパッチ・プロジェクトの中でもトップレベルのソフトウェア
(http://cassandra.apache.org/)。

• 主な機能
• 小さなデータ（各々100KB以下）の高速書込みに最適化。
• P2Pノード。アドホックでのノードの増設、低減が容易。
• クラスターをノード2台から数百台まで拡張可能。
• 複数のデータセンター間の複製に対応。
• コンシステンシー（一貫性）レベルをリクエスト毎に調整可能。

ログ収集システム監視（
ログ収集システム監視（Flumeマスター）
収集システム監視マスター）
マスター


レポート

• 属性による検索
• データ範囲
• ログ・フィールド（例、ユーザーID、メッセージ・タイプ）

• リスト表示（ログデータの行）
• グラフ表示（量 vs 時間）
• CSVフォーマットへのデータ出力対応


レポート（）：
レポート（例）：CDR検索
検索


レポート（）：
レポート（例）：CDR検索結果
検索結果


レポート（）：グラフ
レポート（例）：グラフ


サイジング（
サイジング（例）
ノード（ハードウェア）
ノード（ハードウェア）
• Supermicro (CPU: 2 quad-core Intel E5420, 32GB RAM, 16- 1TB SATA HD) ~ $6,000.
監視レイヤ
監視レイヤ
• 必要なノード数：2台（高可用性の為、マスター1台＋スタンドバイ1台）

コレクター・レイヤ
• 必要なノード数＝Max(2, Node Write Throughput (MB/S) / (log bytes per transaction * transactions per second (TPS)))
• 例：1 MB/秒の書込みスループット/ノード、1K B/トランザクション、1000 TPSシステム＝1MB/sの書込み

5
＜例＞必要な
4
コレクター・
ノード数 3
2

200 300 400 500 KB/Sec (log bytes/tx * TPS)
ストレージ・レイヤ
• 必要なノード数＝Max(Replication Factor, Data Per Day * # of Days to keep / (Node Storage / Replication Factor) )
• 例：データ/日＝100 GB、保存日数＝365、実効ノード・ストレージ＝8 TB、レプリケーション因子= 2の場合、
必要なノード数＝100 * 365 / (8000 / 2) = 9.125 = 10台
実効ストレージ
実効ストレージレプリケーションログ(GB) / 日
ログ(GB) データ日数
日数/
データ日数/ノード 365日間のノード
365日間のノード
日間
(GB) / ノード因子数

＜例＞ 8000 2 10 400 2
8000 3 10 266 3
8000 2 100 40 10


オープンソースのコンポーネント

• FlumeやCassandraはオープンソース化されている。弊社は下記のコンポーネントをさらに加
える。
• カスタマイズのFlume-Cassandraコネクター（弊社のログ・フォーマットを読取り、Cassandraへ挿入）
• Cassandraデータ設計（スキーマ、設定を含む）
• ブラウザーUI、Cassandraへのクエリー
• 後処理プロセッサ（カスタマイズのログフォーマット・ファイルを生成）


のデータ・モデル
Cassandraのデータ・モデル 1/2
現在、Flumeは四つのテーブルにデータを挿入する。
1. 生データ・テーブル
• 関数：受取ったままのログデータを格納。
• 行キー：YYYYMMDDHH、一時間毎に一つ。
• 列：列名: ログエントリーUUID。値：ログデータ。列
• その時間内の各ログエント
AAB32431352 ABC32433781 BCD32433901 リー毎に追加。
•UUID (Unique Log Entry
2011 01S,Market1,12345AA,2011011107 04RR,Market1,12345ZZ,201101110712 07S,Market1,12345BB,2011011107120 ID)でソート。
0111 1200000,10.10.2.9,,10.10.2.10,0901 00005,10.10.2.9,,10.10.2.10,09012345 0010,10.10.2.9,,10.10.2.10,090123456
07 2345673,carrier.ne.jp,carrier.ne.jp,,, 675,carrier.ne.jp,carrier.ne.jp,,,,, 73,carrier.ne.jp,carrier.ne.jp,,,,,
,,
行
• 各時間毎に追加。

エントリー・テーブル
2. CDRエントリー・テーブル
• 関数：各ログフィールドを列で表す。クエリーやインデックスに便利。
• 行キー：ログエントリーUUID.
• 列：列名：ログデータ・フィールド名。値：ログデータ・フィールドの値。
typ market id timestamp moipaddr mtipaddre msisdn senderdoma recipientdom
e ess ss in ain
行
AAB32431 01S Market1 1235AA 2011011107 10.10.2.9 10.10.2.10 0901234567 carrier.ne.jp carrier.ne.jp • 各ログエント
352 1200000 3 リー毎に追加。
ABC32433 04 Market1 1235ZZ 2011011107 10.10.2.9 10.10.2.10 0902345689 carrier.ne.jp carrier.ne.jp
781 RR 1200005 0
BCD32433 07S Market1 1235BB 2011011107 10.10.2.9 10.10.2.10 0901234567 carrier.ne.jp carrier.ne.jp
901 1200010 3

のデータ・モデル
Cassandraのデータ・モデル 2/2
タイムライン・テーブル
3. MSISDNタイムライン・テーブル
• 関数： MSISDN、次にタイムスタンプで構成。
• 行キー： MSISDN.
• 列：列名: タイムスタンプ。値：CDRエントリーを指し示すログエントリーUUID。
行
20110111071200000 20110111071200010 列 •各MSISDN毎に追加。
•そのMSISDNに関す
09012345673 AAB32431352 BCD32433901
る各ログエントリー毎
に追加。
20110111071200005 •タイムスタンプでソー
09023456890 ABC32433781 ト。

毎時タイムライン・テーブル
4. 毎時タイムライン・テーブル
• 関数：時間（毎時）、次にタイムスタンプで構成。
• 行キー： YYYYMMDDHH.
• 列：列名: タイムスタンプの値。値：CDRエントリーを指し示すUUID。
20110111071200000 20110111071200005 20110111071200010 行
列 •各時間毎に追加。
2011011107 AAB32431352 ABC32433781 BCD32433901 •その時間内の各ログエン
トリー毎に追加。
20110111081200001 20110111081200010
•タイムスタンプでソート。
2011011108 BDB32431352 CDC32431352


次のステップ

• オープンソースとしてリリースしています。https://github.com/geminitech/logprocessing
• Readme、サンプルデータ、パッケージ。

• 以下のステップを試してください。
• Flume、Cassandra、弊社のコードをダウンロード、インストールしてください。
• サンプルデータで試しください。
• 商用システム向けにご使用になる場合、
• 実際のシステムからサンプルログを取得し、必要に応じてFlume Plug-inをカスタマイズしてくだ
さい。
• 必要なレポートについて決め、必要に応じてCassandraのテーブル・フォーマット、UIをカスタマイ
ズしてください。
• サンプルログで機能性や性能を試験してください。
• 展開：まずラボ環境で、次に商用システムへの展開をご予定ください。


Backup


データベース・ストレージの選択肢
データベース・ストレージの選択肢

ストレージ・システムにはCassandraを使用。

一部の選択肢との比較：
• SQL：高速で大量のデータ挿入が難しい。水平拡張が容易でない。
：
• Hadoop：データベースのようなシステム内にない為、柔軟なクエリーやデータ編集が難しい
：
。
• またはHibari：Cassandraの持つ機能の大半を提供。
または
Hbaseまたは：

Cassandraが選ばれた理由：
• 小さいデータの書込み性能に優れる。
• 複数のデータセンターに対応。
• 調整可能なコンシステンシー（一貫性）。
• 現在は使用していないが、複数のデータセンターが存在する場合や、異なるデータ・クラス（例
、課金レコード vs 統計レコード）が存在する場合に有益。


FAQ (1/2)
Q. 古いデータはどのように削除するのか?
削除するのか
いデータはどのように削除するのか
A. Cassandraには各列にTime to Live (TTL)（秒単位）があり、TTLの有効期間が0になると、圧縮
時に自動的に削除される。

Q. データ・ストアが一杯になった場合、その検出やアラーム処理はどのように行うのか？デ
データ・ストアが一杯になった場合、その検出やアラーム処理はどのように行うのか？
一杯になった場合検出やアラーム処理はどのように
ータ・ストアが一杯になり、拡張可能となる時期をどのように予測するのか
一杯になりとなる時期をどのように予測するのか？
ータ・ストアが一杯になり、拡張可能となる時期をどのように予測するのか？
A. SNMP (netsnmp)を用いてサーバーのディスク使用量を監視し、閾値を超える場合、SNMPト
ラップが生成される。

Q. Hadoopベースのログ処理システムとはどのように違うのか？
ベースのログ処理システムとはどのように違うのか？
ベースのログ処理システムとはどのように
A. データベース（Cassandra）を加えることで、リアルタイム対応、複雑なクエリーの発行、その他
データベースのようなオペレーションが可能になる。

Q. Map/Reduceは使用するのか
は使用するのか?
するのか
A. Map/Reduceのスクリプトを用いて、ログデータの後処理、他のログ・フォーマットの生成や分
析が可能になる。（＊弊社による試験検証は未実施。）

FAQ (2/2)
Q. このシステムのリアルタイム性はどの程度か（具体的に、最善の状況における遅延の程
このシステムのリアルタイム性はどの程度か具体的に最善の状況における遅延の
程度における遅延
度は）？リアルタイム性を高めるにはどうすれば良いか？
リアルタイム性めるにはどうすれば良いか？
A. ログファイル読取りの設定可能な遅延をAとし、エージェント・ノードからコレクター・ノード
へのデータ送信の時間をBとし、Cassandraへのデータ挿入をCとすると、遅延の合計は「A
+ B + C」となる。例えば、A=100ms、B=50ms、C=10msという場合、合計で160msである。

Q. コードの行数はどれくらいか？言語は何か？
コードの行数はどれくらいか？言語は
行数はどれくらいか
A. FlumeからCassandraのプラグイン(~40行、Java）、UI（ ~2000行、Java、JSP ）、後処理プロセ
スのログフォーマット（ ~250行、Java）。

Q. 改善点は?
改善点は
A. 1. どんなログフォーマットにも対応できるよう、 UIを一般化。
2. 高い負荷と大規模システムの試験。
3. 後処理ログデータにPigスクリプトを追加。


Cassandra向けのPig
向けの

• Pig (http://pig.apache.org/)は高水準言語の関係型言語で、クエリーの書込みに用いる。クエ
リーはその後、Map/Reduceのジョブ向けに翻訳される。
• Map/ReduceのジョブはCassandraが対応する。

• Pigスクリプトの例：2011年1月1日以降、ログレコードの数の多い上位100件のMSISDNを検
索。
msisdn = LOAD 'cassandra://CDRLogs/MSISDNTimeline' USING CassandraStorage();
cdrs = FOREACH msisdn GENERATE flatten($1);
cdrtime = FOREACH cdrs GENERATE $0;
givenhourcdr = FILTER cdrtime BY $0 > 20110101000000
msisdnByHour = GROUP givenhourcdr BY $0;
msisdnByHourCount = FOREACH msisdnByHour GENERATE COUNT($1), group;
orderedMsisdn = ORDER msisdnByHourCount BY $0;
topUserAfterNewYear = LIMIT orderedMsisdn 100;
dump topUserAfterNewYear;


Flume cassandra real time log processing (日本語）

More Related Content

Flume cassandra real time log processing (日本語）