础蝉辫别肠迟闯を用いた大规模分散システム贬补诲辞辞辫の监视とプロファイリング
- 2. 導入
? 近年、注目されている大規模分散システム
- クラウドコンピューティング
- ビッグデータ
?Google, Yahoo!, Amazon, Twitter, Facebook, etc..
? 大規模分散処理フレームワークであるApache
Hadoopを用いることで比較的容易に大規模な分散シ
ステムが構築できる
2
- 3. Hadoop
ビッグデータを扱う為の分散並列処理フレームワーク
- Googleの分散処理システムのオープンソースクローン
Yahoo!のDoug Cutting氏によって開発
高いスケールアウト性能
コモディティハードウェアで構築可能
処理タスク、ファイルのレプリケーションによるフ
ォールトトレラントと高可用性
透過性
3
- 4. 大規模分散システム開発における課題
大規模分散システムのためのデバッグ手法
? ログは各ノードに分散して作成される
- 従来のソフトウェアに対するテキストベースのログを開発者が確認?解析す
る手法は、クラスタを構成しているノード数が大規模な場合、現実的では
ない 。重要なログ情報を見落とす可能性。
? 既存の提供されている各種メトリクスは運用者向け。粒度が粗く、開
発者には不十分
リアルタイムでの監視と解析(動作解析、障害検知)
? 事前のテストや検証によって全ての障害を取り除くことは困難
4
- 7. Hadoop のアーキテクチャ
Master
Slaves
Name Job Map
Map
Node Tracker
Data Reduce Data Reduce
Blocks Blocks
RPC
Data Task Data Task
Node Tracker Node Tracker
RPC
? マスタスレーブ型
? Hadoop分散ファイルシステム = NameNode + DataNode
? Hadoop MapReduce処理基盤 = JobTracker + TaskTracker
? ノード間の通信はRPC通信によって行われる
7
- 9. 一般的な贬补诲辞辞辫动作の解析手法(2)
Hadoop job_201211301554_0002 on sirius
User: hadoop
Job Name: TeraSort
Job File: hdfs://sirius.csl.ec.t.kanazawa-
u.ac.jp:54310/hadoop/mapred/staging/hadoop/.staging/job_201211301554_0002/job.xml
各種メトリクスを確認(ファイルに
Submit Host: sirius.csl.ec.t.kanazawa-u.ac.jp
Submit Host Address: 192.168.1.10
Job-ACLs: All users are allowed
Job Setup: Successful
Status: Succeeded
出力、Web インターフェース経
Started at: Fri Nov 30 16:19:39 JST 2012
Finished at: Fri Nov 30 16:33:20 JST 2012
Finished in: 13mins, 40sec
Job Cleanup: Successful
由、Ganglia経由)
Failed/Killed
Kind % Complete Num Tasks Pending Running Complete Killed
Task Attempts
map 100.00% 102 0 0 102 0 0/9
-
reduce 100.00% 10 0 0 10 0 0/0
MapReduce処理の進行状況や
Counter Map Reduce Total
File Input Format
Bytes Read 10,002,745,698 0 10,002,745,698
Counters
各タスクの処理にかかった時
SLOTS_MILLIS_MAPS 0 0 8,594,755
Launched reduce tasks 0 0 10
Total time spent by all
reduces waiting after 0 0 0
間、HDFS内のデータサイズ等の
reserving slots (ms)
Rack-local map tasks 0 0 81
Job Counters
Total time spent by all maps
waiting after reserving slots 0 0 0
情報が取得可能
(ms)
Launched map tasks 0 0 111
Data-local map tasks 0 0 30
?運用者向け
SLOTS_MILLIS_REDUCES 0 0 7,463,804
File Output Format
Bytes Written 0 10,000,000,000 10,000,000,000
Counters
FILE_BYTES_READ 10,317,741,238 10,200,000,300 20,517,741,538
?分散システムの開発には不十分
HDFS_BYTES_READ 10,002,757,938 0 10,002,757,938
FileSystemCounters
FILE_BYTES_WRITTEN 20,402,514,180 10,200,241,332 30,602,755,512
HDFS_BYTES_WRITTEN 0 10,000,000,000 10,000,000,000
Map output materialized
bytes 10,200,006,120 0 10,200,006,120
Map input records 100,000,000 0 100,000,000
Reduce shuffle bytes 0 10,119,092,736 10,119,092,736
9
- 10. 目次
1. 導入
2. 基盤技術
3. 提案手法
- 実行命令のランタイムモニタ
- 取得した実行命令列を用いたアダプテ
ィブな統計的解析
4. 実装と実験
5. 考察?まとめ
10
- 11. 提案手法の構成要素
Hadoop Monitor Profiler
?MapReduce
Fluentd
?HDFS AspectJ
Zabbix
?RPC
?監視 ?リアルタイムで
?実行命令のロギング のログの解析?
?収集 可視化
11
- 14. モニタ機能の技術 - AspectJ -
? アスペクト指向プログラミングのJava実装
- アスペクト指向プログラミング
-- オブジェクト指向プログラミングではモジュール化を行いにく
い横断的関心事をアスペクトとしてモジュール化する技術 --
-- G. Kiczales, ECOOP 2001
?HadoopはJavaで記述されている
?Hadoopのオリジナルコードを変更することなく、ロギ
ングの機能などを実装することが可能
14
- 15. モニタを配置した検証対象システム
Master
Name Job Slaves
Node Tracker
Map Map
Data Reduce Data Reduce
Blocks Blocks
Monitor
Data Task Data Task
Node Tracker Node Tracker
RPC
RPC
Monitor Monitor
? Hadoopクラスタの各ノードにモニタを配置
15
- 16. モニタを配置した検証対象システム
Master
Name Job Slaves
Node Tracker
Map Map
Data Reduce Data Reduce
Blocks Blocks
Monitor
Data Task Data Task
Node Tracker Node Tracker
RPC
RPC
Monitor Monitor
? システム動作時、モニタは各種デーモン?プロセスの
実行命令を監視し、実行命令をロギングする 16
- 17. モニタを配置した検証対象システム
Master
Name Job Slaves
Node Tracker
Map Map
Data Reduce Data Reduce
Blocks Blocks
Monitor
Data Task Data Task
Node Tracker Node Tracker
RPC
RPC
Monitor Monitor
Master Trace Slave Traces
?NameNode Trace ?DataNode Trace
?JobTracker Trace ?TaskTracker Trace
?RPC Trace ?RPC Trace 17
- 19. アダプティブなプロファイリング
Master
Slaves
Name Job Map
Map
Node Tracker
Data Reduce Data Reduce
Blocks Blocks
RPC
Data Task Data Task
Node Tracker Node Tracker
RPC
? 粒度ごとに実行命令をカウント
19
- 20. ノードレベルでのプロファイリング
Master
Slaves
Name Job Map
Map
Node Tracker
Data Reduce Data Reduce
Blocks Blocks
RPC
Data Task Data Task
Node Tracker Node Tracker
RPC
? ノードごとに実行命令をカウント
20
- 21. デーモン?プロセスレベルでのプロファイリング
Hadoop MapReduce
Master
Slaves
Name Job Map
Map
Node Tracker
Data Reduce Data Reduce
Blocks Blocks
RPC
Data Task Data Task
Node Tracker Node Tracker
RPC
HDFS
? デーモン?プロセスごとに実行命令をカウント
21
- 22. トレース解析环境の技术
Fluentd
-
&
統合ログ管理基盤
- 各ノードで?uentdデーモンがログを収集
- ログはJSON形式で扱われる
?各ノードで生成されたトレースを解析用サーバに転送
Zabbix
- 統合監視ソフトウェア
- サーバ、ネットワークに接続されたデバイスを監視
- 収集したデータのグラフ化、トリガーによるアラート機能
? 収集したトレース解析結果の可視化 22
- 24. 実験環境
CPU Intel Core i5-3470 CPU
クロック数 3.20 GHz
コア数 4
RAM 8 GB
ディスク 1TB SATA HDD (7200 回転)
OS Linux 2.6.3-279.el6.x86_64 SMP
Hadoop 1.0.3
AspectJ 1.7.1
Java 1.7.0
※ 上記の計算機を6台用いる
24
- 25. モニタ実装 RPC通信のためのパッケージ
を監視対象に指定
privileged aspect RPCMonitor {
public pointcut MethodExecute()
: execution(public * *.*(..))
&& within(org.apache.hadoop.ipc.*)
&& !execution(* *.run*())
&& !execution(* org.apache.hadoop.metrics2.**.*(..))
&& !execution(* org.apache.hadoop.security.**.*(..))
&& !withincode(* java.lang.**.*(..))
? 各ノードの、稼働するデーモン、プロセスごとにモ
ニタを配置
? メトリクスや、セキュリティ関連の実行命令はロギ
ングの適用範囲から除く
25
- 26. トレース情報
システム時刻 ホスト名 デーモン?
プロセス名
1352777292269-sirius-namenodetrace={
DatanodeCommand[]
org.apache.hadoop.hdfs.server.namenode.NameNode.send
Heartbeat(DatanodeRegistration, long, long, long,
int, int),
[DatanodeRegistration(192.168.1.15:50010,
storageID=DS-2031755896-192.168.1.15-50010-135217219
3708, infoPort=50075, ipcPort=50020),
922985177088,30648860672,845179580416,0,1]
}
実行命令 引数
26
- 27. パフォーマンス ベンチマーク
スループット[MB/sec] = 入力データサイズ / 経過時間
入力データサイ スループット トレースデータ
モニタの有無 経過時間 [sec]
ズ[GB] [MB/sec] サイズ[MB]
1 ? 2m 25s (145sec) 6.9 2.4
84.1%
1 × 2m 2s (122s) 8.2 0
10 ? 8m 45s (525sec) 19.0 3.6
88.3%
10 × 7m 45s (465sec) 21.5 0
1h 21m 54s
100 ? 20.4 31.6
96.2%
(4,914sec)
1h 18m 37s
100 × 21.2 0
(4,717sec)
? 使用したMapReduceサンプルプログラム - “terasort”
? トレースサイズの増加率 6.43KB/sec
27
- 29. Filter
プロファイリング結果 - ノードレベル -
03.12.2012 01:24 - 03.12.2012 02:24 (now!)
01h 00m (fixed)
カウント数
2 3
1K
時間
■192.168.1.10 Master
■■■■■192.168.1.11 15 Slaves
1. 各ノードで実行された実行命令の回数を、単位時間を10秒としてカウント
アップ
2. ジョブ起動時には、マスターにおいて10秒間に約1K回ものメソッドが実行
されている
3. Reduceフェーズにおいて全ノードで多くのメソッドが実行されている
29
- 30. Filter
プロファイリング結果 - ノードレベル -
03.12.2012 01:24 - 03.12.2012 02:24 (now!)
01h 00m (fixed)
カウント数
1 2
1K
時間
■192.168.1.10 Master
CPU使用
■■■■■192.168.1.11 15 Slaves
おいて、
ト値を示 す時間に
1. 各ノードで実行された実行命令の回数を、単位時間を10秒としてカウント
大きなカ ウン 値の原因 となる実
アップ
、大きな カウント
率も多 いならば とは有効 と言える
を計るこ
2. ジョブ起動時には、マスターにおいて10秒間に約1K回ものメソッドが実行
されている ついて効率化
行命令に
3. Reduceフェーズにおいて全ノードで多くのメソッドが実行されている
30
- 31. h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All 03.12.2012 01:25 - 03.12.2012 02:25
プロファイリング結果 -プロセスレベル-
1m 1w 1d 12h 1h | 1h 12h 1d 1w 1m 6m 1y ?? 01h 00m (fixed)
Master Slave1 Slave2
Slave3 Slave4 Slave5
■RPC
■HDFS(NameNode, DataNode)
■Hadoop MapReduce(JobTracker, TaskTracker)
? マスタのNameNodeは、ジョブの投入時に単位時間あたり0.75Kのメソ
ッドを実行する
? スレーブ群のRPC、TaskTrackerについてはほぼ同様のグラフが得られ
たが、DataNodeについてはノード間で差が見られる
? DataNodeのレプリケーションポリシーのランダム性による負荷の偏り
- 32. プロファイリング結果 -メソッドレベル 1-
SCREENS
hadoop cluster monitor - SLAVE1
Slave3
Filter
SCREENS
hadoop cluster monitor - SLAVE5
Slave5
Filter
Zoom: 1h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All 03.12.2012 01:25 - 03.12.2012 02:25 (now!) Zoom: 1h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All 03.12.2012 01:26 - 03.12.2012 02:26 (now!)
?? 1y 6m 1m 1w 1d 12h 1h | 1h 12h 1d 1w 1m 6m 1y ?? 01h 00m (fixed) ?? 1y 6m 1m 1w 1d 12h 1h | 1h 12h 1d 1w 1m 6m 1y ?? 01h 00m (fixed)
RPC DN TT RPC DN TT
各メソッドについてログ収集期間内に実行された回数が
プロセスごとの発生回数全体に占める割合
32
- 33. プロファイリング結果 -メソッドレベル 1-
Slave3 Slave5
SCREENS SCREENS
hadoop cluster monitor - SLAVE1 hadoop cluster monitor - SLAVE5
Filter Filter
Zoom: 1h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All 03.12.2012 01:25 - 03.12.2012 02:25 (now!) Zoom: 1h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All 03.12.2012 01:26 - 03.12.2012 02:26 (now!)
?? 1y 6m 1m 1w 1d 12h 1h | 1h 12h 1d 1w 1m 6m 1y ?? 01h 00m (fixed) ?? 1y 6m 1m 1w 1d 12h 1h | 1h 12h 1d 1w 1m 6m 1y ?? 01h 00m (fixed)
?Slave3とSlave5のDNについてのプロファイリング結果の乖離の原因と
して、org.apache.hadoop.hdfs.server.datanode.FSDataset.
getChannelPositionメソッドがあげられる
? FSDatasetはデータブロックの集合を扱うクラス、各ブロックは
ユニークな名前とディスク上の位置情報を持つ。FSDirはUnixでのデ
ィレクトリで、子にFSDirまたは、ブロックをもつ。 33
- 34. org.apache.hadoop.hdfs.server.datanode-
GRAPHS
SLAVE3 DN - method level
Filter
! -FSDataset. getChannelPosition
Zoom: 1h 2h 3h All 03.12.2012 01:25 - 03.12.2012 02:25
?? 1h | 1h ?? 01h 00m (fixed)
Filter
カウント数
03.1
時間
? FSDatasetはデータブロックの集合を扱
うクラス、各ブロックはユニークな名前と
ディスク上の位置情報を持つ
? getChannelPositionは、次のデータを書
き込むブロック内のオフセットを取得する
メソッド
34
- 35. org.apache.hadoop.hdfs.server.datanode-
GRAPHS
SLAVE3 DN - method level
Filter
! -FSDataset. getChannelPosition
Zoom: 1h 2h 3h All 03.12.2012 01:25 - 03.12.2012 02:25
?? 1h | 1h ?? 01h 00m (fixed)
Filter
カウント数
03.1
時間
? FSDatasetはデータブロックの集合を扱
HDFSのランダム書き込みがボトルネックの可能性
うクラス、各ブロックはユニークな名前と
→ バッファとしてSDDにデータを保存、ブロックの
ディスク上の位置情報を持つ
オフセット値でソーティング、可能な部分をシーケン
?FSDirはUnixでのディレクトリで、子に
シャルライトで高速化が図れる可能性
FSDirまたは、ブロックをもつ
? getChannelPositionは、次のデータを書
き込むブロック内のオフセットを取得する
メソッド
35
- 36. 関连研究
[M. K. Aguilera 2003]
? 通信メッセージをモニタリング、集約アルゴリズムの提案
? 目的： 因果パスの検出
? 入出力メッセージ乖離がもっとも大きいものをボトルネックとする
[Chen, 2003:PinPoint]
? 障害の原因の可能性が高い分散システム内のコンポーネントを検出
? 一回の考察の単位：単一マシンのひとつのリクエスト
[Hellerstein,1999 :ETE]
? メソッドレベルのログを受動的に取得
? ノード間通信のみではなくメソッドレベルで内部動作を解析可能
? 大規模な分散システム向けのメソッドの発生回数によるシステム
動作の解析
? 厳密な時刻は扱わない 36
- 37. まとめ
提案手法
1. AspectJを用いたメソッドレベルのモニタ
- 検証対象システムのオリジナルコードへの変更は必要ない
- システムのパフォーマンスへの負荷は少ない
2. トレースを用いたアダプティブなプロファイリング手法
- 開発者がシステム動作を理解?解析することを支援
- パフォーマンスの改善に有効な情報を提供する
成果
? Hadoopの動作の解析に有効
- 具体的にボトルネックの原因を指摘
今後の展望
? ユーザプログラム、プラグインに対しても提案するプロファイリングを適用
? FIと組み合わせる ?OpenFlowが使えそう
? プロファイリング結果を用いたセキュリティチェック
37
![トレース情報
システム時刻 ホスト名 デーモン?
プロセス名
1352777292269-sirius-namenodetrace={
DatanodeCommand[]
org.apache.hadoop.hdfs.server.namenode.NameNode.send
Heartbeat(DatanodeRegistration, long, long, long,
int, int),
[DatanodeRegistration(192.168.1.15:50010,
storageID=DS-2031755896-192.168.1.15-50010-135217219
3708, infoPort=50075, ipcPort=50020),
922985177088,30648860672,845179580416,0,1]
}
実行命令 引数
26](https://image.slidesharecdn.com/comsys2012-cs405-121211105016-phpapp01/85/AspectJ-Hadoop-26-320.jpg)
![パフォーマンス ベンチマーク
スループット[MB/sec] = 入力データサイズ / 経過時間
入力データサイ スループット トレースデータ
モニタの有無 経過時間 [sec]
ズ[GB] [MB/sec] サイズ[MB]
1 ? 2m 25s (145sec) 6.9 2.4
84.1%
1 × 2m 2s (122s) 8.2 0
10 ? 8m 45s (525sec) 19.0 3.6
88.3%
10 × 7m 45s (465sec) 21.5 0
1h 21m 54s
100 ? 20.4 31.6
96.2%
(4,914sec)
1h 18m 37s
100 × 21.2 0
(4,717sec)
? 使用したMapReduceサンプルプログラム - “terasort”
? トレースサイズの増加率 6.43KB/sec
27](https://image.slidesharecdn.com/comsys2012-cs405-121211105016-phpapp01/85/AspectJ-Hadoop-27-320.jpg)
![関连研究
[M. K. Aguilera 2003]
? 通信メッセージをモニタリング、集約アルゴリズムの提案
? 目的： 因果パスの検出
? 入出力メッセージ乖離がもっとも大きいものをボトルネックとする
[Chen, 2003:PinPoint]
? 障害の原因の可能性が高い分散システム内のコンポーネントを検出
? 一回の考察の単位：単一マシンのひとつのリクエスト
[Hellerstein,1999 :ETE]
? メソッドレベルのログを受動的に取得
? ノード間通信のみではなくメソッドレベルで内部動作を解析可能
? 大規模な分散システム向けのメソッドの発生回数によるシステム
動作の解析
? 厳密な時刻は扱わない 36](https://image.slidesharecdn.com/comsys2012-cs405-121211105016-phpapp01/85/AspectJ-Hadoop-36-320.jpg)
