AspectJを用いた大規模分散システムHadoopの  監視とプロファイリング    清水裕亮 櫻井孝平 山根智     金沢大学自然科学研究科          1
導入• 近年、注目されている大規模分散システム -   クラウドコンピューティング -   ビッグデータ     ➡Google, Yahoo!, Amazon, Twitter, Facebook, etc..• 大規模分散処理フレームワーク...
Hadoopビッグデータを扱う為の分散並列処理フレームワーク-   Googleの分散処理システムのオープンソースクローン    Yahoo!のDoug Cutting氏によって開発      高いスケールアウト性能      コモディティハー...
大規模分散システム開発における課題大規模分散システムのためのデバッグ手法➡   ログは各ノードに分散して作成される-   従来のソフトウェアに対するテキストベースのログを開発者が確認・解析す    る手法は、クラスタを構成しているノード数が大規...
提案手法1. 実行命令のランタイムモニタ2. 実行命令列を用いたアダプティブなプロファイリング• システムの動作時の実行命令を受動的に取得、ロギング• ロギングされた実行命令を収集し、統計的解析を行う➡開発者がシステムの内部動作を理解・把握する...
目次1. 導入2. 基盤技術 - Hadoop - Hadoopのデバッグ・監視手法3. 提案手法4. 実装と実験5. 考察・まとめ                      6
Hadoop のアーキテクチャ Master                                                 SlavesName       Job                               ...
一般的なHadoop動作の解析手法(1)テキストベースのログを確認➡ログは各ノードに分散して作成    される-   クラスタを構成するノード数は数10    数1000-   各ノードでは複数のデーモンが動作➡重要なログの見落とし➡障害対応へ...
一般的なHadoop動作の解析手法(2)                        Hadoop job_201211301554_0002 on sirius                        User: hadoop    ...
目次1. 導入2. 基盤技術3. 提案手法 - 実行命令のランタイムモニタ - 取得した実行命令列を用いたアダプテ   ィブな統計的解析4. 実装と実験5. 考察・まとめ                       10
提案手法の構成要素 Hadoop         Monitor    Profiler•MapReduce                            Fluentd•HDFS           AspectJ          ...
実行命令のランタイムモニタ• システム振る舞いを監視• 実行された命令を受動的にロギングする -   ロギングされた実行命令の列を トレース と呼ぶ                               12
実行命令のランタイムモニタ• システム振る舞いを監視• 実行された命令を受動的にロギングする -   ロギングされた実行命令の列を トレース と呼ぶ 要件:     少ない負荷     モニタ機能の着脱の容易性                 ...
モニタ機能の技術 - AspectJ -• アスペクト指向プログラミングのJava実装 -   アスペクト指向プログラミング      -- オブジェクト指向プログラミングではモジュール化を行いにく      い横断的関心事をアスペクトとしてモ...
モニタを配置した検証対象システムMasterName      Job                                        SlavesNode    Tracker                          ...
モニタを配置した検証対象システム MasterName      Job                                        SlavesNode    Tracker                         ...
モニタを配置した検証対象システムMasterName       Job                                        SlavesNode     Tracker                        ...
アダプティブなプロファイリング手法の提案• Hadoopのような大規模な分散システムでは分割統治の アルゴリズムを採用 → 主要な機能のための命令が繰り返し実行される → システム動作と実行命令の発生回数間の関係性➡実行命令の出現回数を用いたシ...
アダプティブなプロファイリング Master                                               SlavesName     Job                                   ...
ノードレベルでのプロファイリング Master                                               SlavesName     Job                                  ...
デーモン・プロセスレベルでのプロファイリング                       Hadoop MapReduce Master                                                Slaves...
トレース解析環境の技術    Fluentd-                            &    統合ログ管理基盤-   各ノードでfluentdデーモンがログを収集-   ログはJSON形式で扱われる    ➡各ノードで生成された...
目次1. 導入2. 基盤技術3. 提案手法4. 実装と実験 - モニタの実装 - ベンチマークテスト - プロファイリング結果5. 考察・まとめ                23
実験環境 CPU            Intel Core i5-3470 CPUクロック数                 3.20 GHzコア数                       4 RAM                   ...
モニタ実装            RPC通信のためのパッケージ                                         を監視対象に指定privileged aspect RPCMonitor {  public poi...
トレース情報 システム時刻      ホスト名          デーモン・                           プロセス名1352777292269-sirius-namenodetrace={  DatanodeComman...
パフォーマンス ベンチマークスループット[MB/sec] = 入力データサイズ / 経過時間入力データサイ                                      スループット      トレースデータ           モ...
プロファイリング テスト• 使用するMapReduceプログラム - terasort• 入力データサイズ - 10GB(サンプルプログラム teragenで作成)• カウントを行う単位時間 - 10sec      ノード、プロセス、メソッド...
Filterプロファイリング結果 - ノードレベル -                                             03.12.2012 01:24 - 03.12.2012 02:24 (now!)        ...
Filterプロファイリング結果 - ノードレベル -                                             03.12.2012 01:24 - 03.12.2012 02:24 (now!)        ...
h 2h 3h 6h 12h 1d 1w 2w 1m 3m 6m 1y All                                                    03.12.2012 01:25 - 03.12.2012 0...
プロファイリング結果 -メソッドレベル 1-SCREENShadoop cluster monitor - SLAVE1                                                      Slave3  ...
プロファイリング結果 -メソッドレベル 1-                                                      Slave3                                        ...
org.apache.hadoop.hdfs.server.datanode-GRAPHSSLAVE3 DN - method level                                    Filter! -FSDatase...
org.apache.hadoop.hdfs.server.datanode-GRAPHSSLAVE3 DN - method level                                    Filter! -FSDatase...
関連研究    [M. K. Aguilera 2003]•   通信メッセージをモニタリング、集約アルゴリズムの提案➡ 目的: 因果パスの検出➡ 入出力メッセージ乖離がもっとも大きいものをボトルネックとする    [Chen, 2003:Pi...
まとめ提案手法1. AspectJを用いたメソッドレベルのモニタ    -   検証対象システムのオリジナルコードへの変更は必要ない    -   システムのパフォーマンスへの負荷は少ない2. トレースを用いたアダプティブなプロファイリング手法...
Upcoming SlideShare
Loading in …5
×

AspectJを用いた大規模分散システムHadoopの監視とプロファイリング

1,131
-1

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,131
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

AspectJを用いた大規模分散システムHadoopの監視とプロファイリング

  1. 1. AspectJを用いた大規模分散システムHadoopの 監視とプロファイリング 清水裕亮 櫻井孝平 山根智 金沢大学自然科学研究科 1
  2. 2. 導入• 近年、注目されている大規模分散システム - クラウドコンピューティング - ビッグデータ ➡Google, Yahoo!, Amazon, Twitter, Facebook, etc..• 大規模分散処理フレームワークであるApache Hadoopを用いることで比較的容易に大規模な分散シ ステムが構築できる 2
  3. 3. Hadoopビッグデータを扱う為の分散並列処理フレームワーク- Googleの分散処理システムのオープンソースクローン Yahoo!のDoug Cutting氏によって開発 高いスケールアウト性能 コモディティハードウェアで構築可能 処理タスク、ファイルのレプリケーションによるフ ォールトトレラントと高可用性 透過性 3
  4. 4. 大規模分散システム開発における課題大規模分散システムのためのデバッグ手法➡ ログは各ノードに分散して作成される- 従来のソフトウェアに対するテキストベースのログを開発者が確認・解析す る手法は、クラスタを構成しているノード数が大規模な場合、現実的では ない 。重要なログ情報を見落とす可能性。➡ 既存の提供されている各種メトリクスは運用者向け。粒度が粗く、開 発者には不十分リアルタイムでの監視と解析(動作解析、障害検知)➡ 事前のテストや検証によって全ての障害を取り除くことは困難 4
  5. 5. 提案手法1. 実行命令のランタイムモニタ2. 実行命令列を用いたアダプティブなプロファイリング• システムの動作時の実行命令を受動的に取得、ロギング• ロギングされた実行命令を収集し、統計的解析を行う➡開発者がシステムの内部動作を理解・把握することを 支援する➡開発者がパフォーマンス改善を行うための効果的な情 報を提供する 5
  6. 6. 目次1. 導入2. 基盤技術 - Hadoop - Hadoopのデバッグ・監視手法3. 提案手法4. 実装と実験5. 考察・まとめ 6
  7. 7. Hadoop のアーキテクチャ Master SlavesName Job Map MapNode Tracker Data Reduce Data Reduce Blocks BlocksRPC Data Task Data Task Node Tracker Node Tracker RPC• マスタスレーブ型• Hadoop分散ファイルシステム = NameNode + DataNode• Hadoop MapReduce処理基盤 = JobTracker + TaskTracker• ノード間の通信はRPC通信によって行われる 7
  8. 8. 一般的なHadoop動作の解析手法(1)テキストベースのログを確認➡ログは各ノードに分散して作成 される- クラスタを構成するノード数は数10 数1000- 各ノードでは複数のデーモンが動作➡重要なログの見落とし➡障害対応への遅れ
  9. 9. 一般的なHadoop動作の解析手法(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. 10. 目次1. 導入2. 基盤技術3. 提案手法 - 実行命令のランタイムモニタ - 取得した実行命令列を用いたアダプテ ィブな統計的解析4. 実装と実験5. 考察・まとめ 10
  11. 11. 提案手法の構成要素 Hadoop Monitor Profiler•MapReduce Fluentd•HDFS AspectJ Zabbix•RPC ‣監視 ‣リアルタイムで ‣実行命令のロギング のログの解析・ ‣収集 可視化 11
  12. 12. 実行命令のランタイムモニタ• システム振る舞いを監視• 実行された命令を受動的にロギングする - ロギングされた実行命令の列を トレース と呼ぶ 12
  13. 13. 実行命令のランタイムモニタ• システム振る舞いを監視• 実行された命令を受動的にロギングする - ロギングされた実行命令の列を トレース と呼ぶ 要件: 少ない負荷 モニタ機能の着脱の容易性 13
  14. 14. モニタ機能の技術 - AspectJ -• アスペクト指向プログラミングのJava実装 - アスペクト指向プログラミング -- オブジェクト指向プログラミングではモジュール化を行いにく い横断的関心事をアスペクトとしてモジュール化する技術 -- -- G. Kiczales, ECOOP 2001 ➡HadoopはJavaで記述されている ➡Hadoopのオリジナルコードを変更することなく、ロギ ングの機能などを実装することが可能 14
  15. 15. モニタを配置した検証対象システムMasterName Job SlavesNode Tracker Map Map Data Reduce Data Reduce Blocks Blocks Monitor Data Task Data Task Node Tracker Node TrackerRPC RPC Monitor Monitor• Hadoopクラスタの各ノードにモニタを配置 15
  16. 16. モニタを配置した検証対象システム MasterName Job SlavesNode Tracker Map Map Data Reduce Data Reduce Blocks Blocks Monitor Data Task Data Task Node Tracker Node TrackerRPC RPC Monitor Monitor• システム動作時、モニタは各種デーモン・プロセスの 実行命令を監視し、実行命令をロギングする 16
  17. 17. モニタを配置した検証対象システムMasterName Job SlavesNode Tracker Map Map Data Reduce Data Reduce Blocks Blocks Monitor Data Task Data Task Node Tracker Node TrackerRPC RPC Monitor Monitor Master Trace Slave Traces ‣NameNode Trace ‣DataNode Trace ‣JobTracker Trace ‣TaskTracker Trace ‣RPC Trace ‣RPC Trace 17
  18. 18. アダプティブなプロファイリング手法の提案• Hadoopのような大規模な分散システムでは分割統治の アルゴリズムを採用 → 主要な機能のための命令が繰り返し実行される → システム動作と実行命令の発生回数間の関係性➡実行命令の出現回数を用いたシステム動作の解析➡ 粒度 ごとにカウント → ノードレベル 、 プロセスレベル 、 メソッドレベル 18
  19. 19. アダプティブなプロファイリング Master SlavesName Job Map MapNode Tracker Data Reduce Data Reduce Blocks BlocksRPC Data Task Data Task Node Tracker Node Tracker RPC‣ 粒度ごとに実行命令をカウント 19
  20. 20. ノードレベルでのプロファイリング Master SlavesName Job Map MapNode Tracker Data Reduce Data Reduce Blocks BlocksRPC Data Task Data Task Node Tracker Node Tracker RPC‣ ノードごとに実行命令をカウント 20
  21. 21. デーモン・プロセスレベルでのプロファイリング Hadoop MapReduce Master SlavesName Job Map MapNode Tracker Data Reduce Data Reduce Blocks BlocksRPC Data Task Data Task Node Tracker Node Tracker RPC HDFS‣ デーモン・プロセスごとに実行命令をカウント 21
  22. 22. トレース解析環境の技術 Fluentd- & 統合ログ管理基盤- 各ノードでfluentdデーモンがログを収集- ログはJSON形式で扱われる ➡各ノードで生成されたトレースを解析用サーバに転送Zabbix- 統合監視ソフトウェア- サーバ、ネットワークに接続されたデバイスを監視- 収集したデータのグラフ化、トリガーによるアラート機能 ➡ 収集したトレース解析結果の可視化 22
  23. 23. 目次1. 導入2. 基盤技術3. 提案手法4. 実装と実験 - モニタの実装 - ベンチマークテスト - プロファイリング結果5. 考察・まとめ 23
  24. 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. 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. 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. 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
  28. 28. プロファイリング テスト• 使用するMapReduceプログラム - terasort• 入力データサイズ - 10GB(サンプルプログラム teragenで作成)• カウントを行う単位時間 - 10sec ノード、プロセス、メソッドレベルの各 粒度についてプロファイリングを行う 28
  29. 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 Slaves1. 各ノードで実行された実行命令の回数を、単位時間を10秒としてカウント アップ2. ジョブ起動時には、マスターにおいて10秒間に約1K回ものメソッドが実行 されている3. Reduceフェーズにおいて全ノードで多くのメソッドが実行されている 29
  30. 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. 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. 32. プロファイリング結果 -メソッドレベル 1-SCREENShadoop cluster monitor - SLAVE1 Slave3 Filter SCREENS hadoop cluster monitor - SLAVE5 Slave5 FilterZoom: 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. 33. プロファイリング結果 -メソッドレベル 1- Slave3 Slave5SCREENS SCREENShadoop cluster monitor - SLAVE1 hadoop cluster monitor - SLAVE5 Filter FilterZoom: 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. 34. org.apache.hadoop.hdfs.server.datanode-GRAPHSSLAVE3 DN - method level Filter! -FSDataset. getChannelPositionZoom: 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. 35. org.apache.hadoop.hdfs.server.datanode-GRAPHSSLAVE3 DN - method level Filter! -FSDataset. getChannelPositionZoom: 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. 36. 関連研究 [M. K. Aguilera 2003]• 通信メッセージをモニタリング、集約アルゴリズムの提案➡ 目的: 因果パスの検出➡ 入出力メッセージ乖離がもっとも大きいものをボトルネックとする [Chen, 2003:PinPoint]➡ 障害の原因の可能性が高い分散システム内のコンポーネントを検出➡ 一回の考察の単位:単一マシンのひとつのリクエスト [Hellerstein,1999 :ETE] ‣ メソッドレベルのログを受動的に取得 ‣ ノード間通信のみではなくメソッドレベルで内部動作を解析可能 ‣ 大規模な分散システム向けのメソッドの発生回数によるシステム 動作の解析 ‣ 厳密な時刻は扱わない 36
  37. 37. まとめ提案手法1. AspectJを用いたメソッドレベルのモニタ - 検証対象システムのオリジナルコードへの変更は必要ない - システムのパフォーマンスへの負荷は少ない2. トレースを用いたアダプティブなプロファイリング手法 - 開発者がシステム動作を理解・解析することを支援 - パフォーマンスの改善に有効な情報を提供する成果• Hadoopの動作の解析に有効 - 具体的にボトルネックの原因を指摘今後の展望• ユーザプログラム、プラグインに対しても提案するプロファイリングを適用• FIと組み合わせる ・OpenFlowが使えそう• プロファイリング結果を用いたセキュリティチェック 37
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×