• Save
Hadoopソースコードリーディング8/MapRを使ってみた
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Hadoopソースコードリーディング8/MapRを使ってみた

on

  • 6,397 views

Hadoopソースコードリーディングでの発表資料抜粋です。

Hadoopソースコードリーディングでの発表資料抜粋です。

Statistics

Views

Total Views
6,397
Views on SlideShare
4,530
Embed Views
1,867

Actions

Likes
11
Downloads
0
Comments
0

5 Embeds 1,867

http://atl.recruit-tech.co.jp 1391
http://www.demo-atl.net 448
https://twitter.com 16
http://demo-atl.net 11
http://54.248.123.3 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Hadoopソースコードリーディング8/MapRを使ってみた Presentation Transcript

  • 1. MapR & マルチテナント (include Mesos検証) Hadoopソースコードリーディング 第8回 2012/02/08 (水) 中野 猛 (RECRUIT) @tf0054- 発表内容 - 高林 貴仁 (RECRUIT)1. 性能検証 @tatakaba 大坪 正典 (NSSOL)2. 機能検証(マルチテナント検証) @tsubo04233. リクルートにおけるMapRの評価 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 2. 1. 性能検証高林 貴仁 (RECRUIT) Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 3. DOC.ID 2012/02/08 1. 性能検証 検証内容 サマリ処理のバッチは中古車サイトで実際に行われてい た3つ処理をHiveに置き換え、非パーティション+非圧縮 とパーティション+圧縮の2パターンを測定し検証の実施 VCA01 – 20Tableから、5つのTemporayTable を作成後、Summary Tableを作成 VCA02 –5Tableから、2つのTemporary Tableを作成後、Summary Tableを作成 VCA05 –5Tableから、2つのTemporary Tableを作成後、Summary Tableを作成 最多レコード数と平均レコード数 VCA01 VCA02 VCA05 最多Record 38,128,643件 99,984,347件 22,975,964件 平均Record 7,841,582件 32,241,189件 3,889,790件 P 2 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 4. DOC.ID 2012/02/08 3. 検証結果(非パーティション・非圧縮) 検証結果(非パーティション・非圧縮) サマリ種別比較 [sec] MapReduce処理比較 [sec] MapRの方が約1.3倍高速 P 3 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 5. DOC.ID 2012/02/08 3. 検証結果(パーティション化・圧縮) 検証結果(パーティション化・圧縮) サマリ種別比較 [sec] MapReduce処理比較 [sec] 注)圧縮は、MapRは独自,CDHはGzipで圧縮 MapRの方が約1.76倍高速 P 4 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 6. DOC.ID 2012/02/08 4. 確認結果Disk I/Oの状態について(CDH3) 60秒以上にわたってREAD 80MB/秒の状態先のCPUコアの利用率からもDiskI/Oに多くの時間が割かれている。処理時間が長いため、一部をピックアップしたが、60秒以上にわたって90MB/秒となっており、Diskが高負荷な状態となっている。Diskのボトルネックを避ける点からも、パーティション化および圧縮化はパフォーマンス向上のために有効であると考えられる。 P 5 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 7. DOC.ID 2012/02/08 4. 確認結果Disk I/Oの状態について(MAPR) 60秒以上にわたってREAD80MB/秒の状態 またCDH3に比べ、山の数も多い。CDH3以上にDiskが高負荷状態になっており、こちらもDiskI/Oが処理のボトルネックとなっている。単位時間あたり読み込み量はCDH3より多く、結果的に処理時間の短縮につながっていると考えれる。それでもDisk性能のピークとなっているので、MAPRについてもパーティション化および圧縮化はパフォーマンス向上のために有効であると考えられる。 P 6 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 8. DOC.ID 2012/02/08 5. 考察 MapRの方が処理速度は、非圧縮時で1.3倍速い ビルドイン圧縮は、Gzip圧縮と比較して高速 圧縮率は、gzip圧縮と比べて4割程度 個人的な意見としては・・・Hadoopに手を加えて販売してる訳だから早くて当然でしょって感じ!! P 7 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 9. DOC.ID 2012/02/08 6. 最後に…チューニングの方法によっては、今回の結果が変わる可能性はあると思います。 P 8 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 10. 2. 機能検証(マルチテナント検証) 大坪 正典 (NSSOL) Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 11. DOC.ID 2012/02/08 検証目的とマルチテナントについて 検証目的 本検証では、以下の確認を目的とする。 • マルチテナントに必要な機能要件を満たすことができるか。 • マルチテナント化した際に、セキュリティ要件を満たしているか。 • クラスタをマルチテナントで運用した際のコスト感はどの程度か。マルチテナント 本資料における「マルチテナント」とは、以下の要件を満たすものを指す。 • 複数のユーザに対し、同一のHW(サーバ筐体、ネットワーク)上にて、Hadoop サービスを提供できること。 • 各ユーザは、他ユーザの情報にはアクセスできず、情報セキュリティが担保さ れていること。 • 各ユーザは、互いのJob実行操作ができず、各々のJob実行計画が守られること。 • 一方がリソース(CPU, Memory)を使用していない場合は、他方が余剰リソー スを有効活用できること。 P 10 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 12. DOC.ID 2012/02/08 機能検証(マルチテナント検証)内容 MapR 1. [調査1] パーミッション権限 2. [調査2] FairScheduler 3. [検証1] Load処理, Job投入の同時実行 4. [検証2] フェイルオーバー時間 5. [検証3] DirectNFSでの転送 mesos 1. [調査] mesos概要 2. [検証] マルチテナント適用 まとめ P 11 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 13. DOC.ID 2012/02/08MapR [調査1] パーミッション権限 (1/3 ユーザ権限)  MapRのユーザは、Linuxユーザに準拠する。 – MapR独自のユーザ体系は無い。 – データアクセス権に関して、基本的にApache Hadoopと同等。  HDFSに対する、直接的なPermission制御しかない。 – 但し、Hadoopと異なり、ノード同士の通信は、ユーザ名だけの認証でない。  同じ"mapr"ユーザでも、UIDがずれているとエラーが起きる。  MapR内におけるPermissionは以下の2種類。 MapRの機能としては、上記に挙げた権限以外の制御は行っていない。 JOBの実行権限やデータのアクセス権などは、Apache Hadoopと同じ。 P 12 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 14. DOC.ID 2012/02/08MapR [調査1] パーミッション権限 (2/3 Volumeについて)  Volumeの定義(MapRマニュアルより) – Volumeとは、以下のものにポリシーを設定できる論理ユニットである。  ファイルセット  ディレクトリ  サブボリューム – Volumeを利用することで、以下の事項が可能となる。  ディスク利用量の制限 – 制限量に近づいた時のアラートを含む  レプリケーション数の設定  トポロジー制限 – 任意のVolumeをあるノード/ラックだけで稼動できる。  マニュアルに以下の記述があるものの、注意が必要。 – "File Permissions - Unix-style read/write permissions on volumes"  MapRのControl Systemを通して、ということではない。  HDFS互換のインターフェースからCLIで設定する必要がある。  要するにVolumeは、 DFSとユーザ(mapreduce, dfs利用者)の間に立つものではない。 DFSに対して一定の監視を行い、運用管理者に付加的な情報を与える存在。 P 13 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 15. DOC.ID 2012/02/08MapR [調査1] パーミッション権限 (3/3 Volume概念図) Volume: ・Diskキャパシティ管理 ・NameContainer、DataContainerの管理境界 ・上記に関連するReplication数やsnapshotの境界 アクセス可否はHDFSの パーミッションで制御 1 HDFS 1 全サイト共有 1 n n n サイトユーザ n 1 1 n サイト Volume (データ利用者) 1 n n 管理ユーザ サイトユーザと管理ユーザは (Volume管理者) n Volumeに直接紐付くのは 同じでも別でもよい 管理ユーザ DFSとユーザ(mapreduce, dfs利用者)の間に立つものではない。 DFSに対して一定の監視を行い、運用管理者に付加的な情報を与える存在。 P 14 Copyright(C)2012 Recruit Co.,Ltd All rights reserved Print 12/2/13 1時10分
  • 16. DOC.ID 2012/02/08MapR [調査2] FairScheduler (1/3 概要)  MapRでは、デフォルトでFairSchedulerを使用する設定になっている。  FairSchedulerは、複数のpoolを持つことができるJobスケジューラである。  Unixユーザ毎、Unixグループ毎に管理するpoolを用意できる。  各pool毎に、以下の項目を設定できる。 パラメータ 概要 minMaps 最低同時確保Map Slot数 minReduces 最低同時確保Reduce Slot数 maxMaps 最大同時確保Map Slot数 maxReduces 最大同時確保Reduce Slot数 schedulingMode pool内でのスケジュール方針 (fairもしくはfifo) maxRunningJobs pool内での同時実行Job数 weight クラスタ全体でのそのpoolの重み(優先度) minSharePreemptionTimeout 最低同時確保数を下回っている場合、 他poolのタスクをkillするまでの猶予時間 (デフォルトはinfini) P 15 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 17. DOC.ID 2012/02/08MapR [調査2] FairScheduler (2/3 pool内割当)  FairSchedulerを利用して、 一つのテナントから複数のJobが実行された場合の動作を確認。  スケジューリングモードは「 schedulingMode=Fair」で設定。 poolの設定 Priorityには、以下の5種類がある。 VERY_HIGH(4.0), HIGH(2.0), NORMAL(1.0), LOW(0.5), VERY_LOW(0.25) Max Slot数 12 Priority 優先度 割当Slot数 Job A Job B Job A Job B Job A Job B NORMAL 実行なし 1.0 ---- 12 0 NORMAL NORMAL 1.0 1.0 6 6 NORMAL HIGH 1.0 2.0 4 8 NORMAL VERY_HIGH 1.0 4.0 2 10 pool内の合計Slot数が、poolの設定Slot数を守るように分配される。 優先度に応じてSlot数が計算され、各JobにSlotが割り当てられる。 P 16 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 18. DOC.ID 2012/02/08MapR [調査2] FairScheduler (3/3 pool間割当)  FairSchedulerを利用して、 複数のテナントから同時にJobが実行された場合の動作を確認  FairSchedulerでは、pool毎に設定されたMin/Max値の遵守を基本とし、 それを満たした上で、極力poolごとの割当量を平等に保つ。クラスタの設定 合計 合計Map Slot数 8 Slots 12 Slots 合計PreFetch Slot数 4 Slots pool A Map Slot数 pool B Map Slot数 割当Slot数 Max Min Max Min pool A pool B 未設定 未設定 実行なし 12 0 → 1Jobの場合、クラスタの全Slotを割り当てる。 10 未設定 実行なし 10 0 → Max Slot数よりも多くは割り当てない。 未設定 5 実行なし 12 0 → 1Jobの場合、Min Slot数に意味はない。 未設定 未設定 未設定 未設定 6 6 → 2Jobの場合、クラスタの全Slotを平等に割り当てる。 5 未設定 5 未設定 5 5 → 2Jobの場合も、Max Slot数が割当上限となる。 未設定 10 未設定 未設定 10 2 → Min Slot数分のSlotは、最優先で高く割り当てられる。 → Min Slot数の合計が、合計Slot数を超えている場合、 未設定 20 未設定 10 8 4 その割合に応じてSlotが配分される。 → Min Slot数の合計が、合計Slot数未満の場合、 未設定 7 未設定 3 7 5 余剰Slotは、割当の尐ないpoolから割り当てられる。 P 17 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 19. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (1/6 処理内容, 実行環境)  処理内容①: Load処理 set mapred.reduce.tasks=100; – じゃらんPVデータ1か月分のロード。 CREATE TABLE search AS – NFSからMFSへのロード処理を行う。 SELECT count(row_no),  処理内容②: Job実行 (Select処理) search_engine, – じゃらんPVデータ1か月分に対し、 search_engine_keywords 検索キーワード、検索エンジンによる FROM GroupBy+CountのJOBを実行。(詳細右表) pv_data GROUP BY – 各テナントは別ユーザでJOBを実行し、 search_engine, FairSchedulerにより別プールで管理される。 search_engine_keywords  実行環境 ; – IBM BladeCenter HS21 × 14  CPU : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz × 4コア  Memory : 8GB  Disk : 30GB × 2  Network : Gigabit Ethernet × 2 – Software/Middle ware  OS : CentOS 5.7  MapR : MapR 1.2.0 P 18 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 20. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (2/6 実行環境①)  計測環境は下図の通り。 – MapRのマニュアルにある通り、 以下の推薦環境にて実行する。  ZooKeeperは奇数台(今回は3台)  CLDB、JobTrackerは最大3台  以降、本構成を「3+8台環境」と呼ぶ。 Node1 Node2 Node3 Node4 Node5 Node6 Node7 Node8 Node9 Node10 Node11 Node12 Node13 Node14 SiteA ZooKeeper Hive SiteB CLDB Hive Job JobTracker SiteC Tracke Standby Hive r TaskTracker Webserver FileServer NFS Gateway P 19 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 21. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (3/6 実行環境②)  CLDBは、4台以上でも正常に動作するので、 その場合の性能も測定する。  同様にJobTrackerも、スタンバイ機が 3台以上あっても正常に動作するので、 計算ノード全てにJobTrackerを配備する。  Master/Slave間の差異を無くすため、 ZooKeeperも全ての計算ノードに配備する。  以降、本構成を「11台環境」と呼ぶ。 Node1 Node2 Node3 Node4 Node5 Node6 Node7 Node8 Node9 Node10 Node11 Node12 Node13 Node14 SiteA ZooKeeper Hive SiteB CLDB Hive Job JobTracker JobTracker SiteC Tracke Standby Standby Hive r TaskTracker Webserver FileServer NFS Gateway P 20 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 22. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (4/6 実行環境③)  ロード性能を計測するにあたり、 ロード処理が分散されているかを調べるため ノード数を11台→3台に下げて計測してみる。  以降、本構成を「3台環境」と呼ぶ。 Node1 Node2 Node3 Node4 Node5 Node6 Node7 Node8 Node9 Node10 Node11 Node12 Node13 Node14 SiteA ZooKeeper Hive SiteB CLDB Hive Job JobTracker SiteC Tracke 不使用 Standby Hive r TaskTracker Webserver FileServer NFS Gateway P 21 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 23. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (5/6 Load処理結果)  計測結果No. 同時実行数 構成 Load時間1 1テナント 2m10.36s 2m56.94s2 2テナント 3+8台 3m05.08s 環境 3m21.79s3 3テナント 3m38.27s 3m43.89s4 1テナント 2m02.34s 2m58.15s5 2テナント 11台 3m07.58s 環境 3m13.50s6 3テナント 3m24.52s 3m26.77s7 1テナント 2m36.69s 5m01.13s8 2テナント 3台 5m03.20s  ロードの同時実行数が増えるとロード時間は延びるが、 環境 ノード数を増やすことで短縮できる。 [グラフ青+緑] 6m03.84s  また、10台程度のMapRクラスタにおいて、CLDBの数と9 3テナント 6m09.42s ロード実行時間との関係性は低い。 [グラフ青+赤] 6m13.18s P 22 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 24. DOC.ID 2012/02/08MapR [検証1] Load処理, Job実行 (6/6 Select処理結果)  計測結果No. 同時実行数 構成 Select時間1 1テナント 1m35.28s 2m25.17s2 2テナント 3+8台 2m39.79s 環境 3m56.47s3 3テナント 4m07.07s 4m13.13s4 1テナント 1m32.46s 2m29.90s5 2テナント 11台 2m41.00s 環境 4m12.48s6 3テナント 4m16.42s 4m21.96s7 1テナント 4m14.32s 7m39.71s8 2テナント  同時実行数と実行時間の関係は、グラフの傾向から、 3台 7m50.59s ロード処理時と同じことがわかる。 環境 12m57.73s  また左表より、同時実行された各テナントの9 3テナント 13m41.15s JOB実行時間はほぼ一定であるため、 13m45.03s FairSchedulerが上手く機能していることがわかる。 P 23 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 25. DOC.ID 2012/02/08MapR [検証2] フェイルオーバー (1/2 HA機能の差異) Apache Hadoop MapR Heartbeat + DRBDMasterNode1 MasterNode2 MasterNode3 MasterNode4 Node1 Node2 Node3 Node4 JobTracke JobTracke CLDB CLDB CLDB CLDB r r JobTracke JobTracke JobTracke JobTracke NameNode NameNode r r r r Secondary Secondary TaskTracker TaskTracker TaskTracker TaskTracker NameNode NameNode FileServer FileServer FileServer FileServer WardenSlaveNode1 SlaveNode2 SlaveNode3 SlaveNode4 Node5 Node6 Node7 Node8TaskTracke TaskTracke TaskTracke TaskTracke CLDB CLDB CLDB CLDB r r r r JobTracke JobTracke JobTracke JobTracke DataNode DataNode DataNode DataNode r r r r TaskTracker TaskTracker TaskTracker TaskTracker FileServer FileServer FileServer FileServer 1. Master/Slaveを意識した設計が必要。 1. Master/Slaveを意識する必要がない。(要検討) 2. 冗長構成を自前で構築する必要がある。 →Master系プロセスをinstallだけしておき、 3. Master障害時に、Slaveノードを使い回せない。 必要になったらプロセスON/OFFすればよい。 4. Master/Slave形式のため、Slaveノードの台数が減 2. 冗長構成はWardenが全てのノードを対象に行う。 り、全体の計算スペックが落ちてしまう。 3. Master障害時に、全ノードがMaster役になり得る。 5. Master障害時に実行中のJOBは失われてしまうため、 4. 全てのノードにおいてTask実行可能である。 再投入して最初から実行のやり直しとなる。 5. Master障害時に実行中のJOBは、継続実行される。 P 24 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 26. DOC.ID 2012/02/08MapR [検証2] フェイルオーバー (2/2 ノード切替時間)  MapRのHA機能は、以下の2サービスに対応している。  CLDB:普段から複数立っているサービス。HA時には数が減るだけ。  JobTracker:常に1つ立っているサービス。HA時には別のノードにプロセスが移る。 – CLDBは切り替えでないため、本検証ではJobTrackerについて取り扱う。  JobTrackerの切り替え時間として、以下の2パターンを計測する。 ① Jobが1つも実行されていない時の切替時間 ② Jobが3テナントにて実行中、かつMapタスクが50%程度完了時の切替時間 ③ Jobが3テナントにて実行中、かつMapタスクが100%完了(Reduceタスク実行)時の切替時間  以下の方法により、計測する。(環境は7.1のCLDB数3と同様) 1. JobTrackerノードを再起動する。"shutdown -r now" 2. JobTrackerが切り替わる時間を計測する。 3. Job実行時には、Jobの引継ぎ時間とTask再開までの時間を計測する。  結果は以下の通り。[累積時間] JobTrackerの JobTrackerの 実行中Jobの Task実行の No. 停止検知まで 切替終了まで 引継ぎ完了まで 再開まで ① 0分36秒 1分07秒 (6分13秒) ---- ② 0分30秒 0分57秒 5分38秒 14分46秒 ③ 0分28秒 0分59秒 5分39秒 13分57秒 JobTrackerのHAが発生した場合、次のTaskが実行できる状態に、5分程度で移行する。 また、HA発生時に実行されていたタスクが再開されるまでに、15分程度要する。 P 25 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 27. DOC.ID 2012/02/08MapR [検証3] DirectNFSでの転送 (1/8 DirectNFS概要)① HDFSをNFS経由で利用  DirectNFS機能を用いたマウントに より、hadoopコマンドを利用するこ Client Node MapR Node となく、HDFS(MFS)中のCRUD操作が mount mapr:/cluster01 /mapr_nfs できる。 NFSGateway  さらに、lsコマンドを実行する際、 FileServe 「hadoop dfs -ls」コマンドよりも、 r かなり速いレスポンスが得られる。② VIP/Volumeを利用したマウント MapR Node  クラスタ全体にVIPを割り当てるこ NFSGateway とで、ノード障害にも強いNFSを実 Client Node 現できる。 FileServer mount vip:/volume01 /vol01_nfs VIP  また、Volumeの付与されたパスに対 mount vip:/volume02 /vol02_nfs MapR Node してマウントすることにより、各マ NFSGateway ウントポイントの容量制限、複製数 FileServer を管理できる。③ NFS通信の高速化  NFSGatewayプロセスをClient側に立 てることにより、Client-MapR間の Client Node mount client:/cluster01 /mapr_nfs MapR Node 転送速度を上げることができる。  但し、ClientNodeにもMapRを導入す FileServe るため、ライセンス料が余分にかか NFSGateway ることには注意が必要。 r Mapr固有通信による高速な転送 P 26 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 28. DOC.ID 2012/02/08MapR [検証3] DirectNFSでの転送 (2/8 高速通信)  「NFS GatewayをSever側に立ててNFSマウントする場合」と、 「NFS GatewayをClient側に立ててNFSマウントする場合」との NFS転送性能の違いを計測する。  前者は、ノード間の通信はNFSプロトコル通信、 後者はMapR Filesystemの独自プロトコル通信となる。  NFSクライアントノードから見た場合、以下の違いがある。 – 前者はサーバにファイルを転送した後にMapR圧縮が施される。 – 後者はMapR圧縮がかかったファイルをサーバに転送する。 【NFS GatewayをServer側に立てる】 【NFS GatewayをClient側に立てる】 MapR Server Client Node MapR Server Client Node Client Client NFS Gateway NFS Gateway FileServer FileServer P 27 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 29. DOC.ID 2012/02/08MapR [検証3] DirectNFSでの転送 (3/8 計測結果)  ローカルディスクのRead性能がボトルネックになってしまっていたため、コ ピー元となるクライアントノードを3台に増やして同様の実験を行った。  クライアントノードが1台の場合と同様、10GBのファイル1個をコピーする場 合と、20MBのファイル500個をコピーする場合を計測する。  計測結果を以下に示す。 10GB × 1ファイル 20MB × 500ファイル クライアント1台 クライアント3台 クライアント1台 クライアント3台 5m02.037s 18m00.241s ① 5m02.345s 18m34.453s NFS GatewayをServer側に立てる 3分17秒 10分04秒 5m06.151s 18m34.628s (=MapRクラスタにマウントする) 平均:5分04秒 平均:18分23秒 3m14.739s 9m12.139s ② 3m17.508s 9m29.586s NFS GatewayをClient側に立てる 3分24秒 9分18秒 3m20.200s 9m32.861s (=ローカルにマウントする) 平均:3分18秒 平均:9分25秒 転送時間比率(②÷①) 1.036 0.651 0.924 0.512 クライアントが1台の時は出なかった優位差が、3台になると顕著に表れた。 クライアントノードにNFS Gatewayを立て、MapR独自通信を用いたコピーは、 1つの大ファイルで35%程度、大量の小ファイルで50%程度の改善が見られた。 P 28 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 30. DOC.ID 2012/02/08 MapR [検証3] DirectNFSでの転送 (4/8 stat-1) 10GBx1の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて Clientノード MapRクラスタにマウントした場合 ローカルマウントした場合 3分 3分 CPU (%) MEM (%)②はHDD性能を使いきっているものの、①は別のところにボト HDDルネックがある。 (KB/s) NW (Byte/s) P 29 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 31. DOC.ID 2012/02/08 MapR [検証3] DirectNFSでの転送 (5/8 stat-2) 10GBx1の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて FileServerノード MapRクラスタにマウントした場合 ローカルマウントした場合 3分 3分 CPU (%) MEM (%) HDD (KB/s) ①はサーバ側のNWがボトル ネックになっている。②はMapR独自通信により、NIC2枚を両方使っているため限界に 達していない。 NW (Byte/s) P 30 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 32. DOC.ID 2012/02/08 MapR [検証3] DirectNFSでの転送 (6/8 stat-3) 20MBx500の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて Clientノード MapRクラスタにマウントした場合 ローカルマウントした場合 9分 9分 CPU (%) MEM (%) ②に比べ、①はHDDの性能を使い きれていない。 別のところにボ トルネックがあ HDD ると思われる。 (KB/s)①に比べ、②の通信量がかなり尐ない。MapR独自通信により、ファイル数の多さが緩和されて いると考えられる。 NW (Byte/s) P 31 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 33. DOC.ID 2012/02/08 MapR [検証3] DirectNFSでの転送 (7/8 stat-4) 20MBx500の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて FileServerノード MapRクラスタにマウントした場合 ローカルマウントした場合 9分 9分 CPU (%) MEM (%) HDD (KB/s)NIC1つで通信しているため、NWネックになっている可能性が高い。(ファイル数が多い ため正確な数値は不明。) NW (Byte/s) P 32 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 34. DOC.ID 2012/02/08MapR [検証3] DirectNFSでの転送 (8/8 DirectNFSまとめ)  追加検証結果 – 10GB×1ファイルの転送実験では、FileServer側のNWネックが差異となって、クラ スタマウント時の転送時間に比べ、ローカルマウント時の転送時間は35%程度削減 された。 – 20MB×500ファイルの転送実験では、ローカルマウント時の通信量削減により、転 送時間は50%程度削減された。  まとめ – 複数のクライアントからMFSへDirectNFSマウントする場合、FileServer側のNWネ ックになる可能性がある。  MapRが持つVirtual IPの機能は、固定ノードへの割り付けを行い、ロードバ ランシングは行わないので、解決にならない。  サーバ側のNICが2本以上あるのであれば、本検証で行った通り、NFS Gateway をクライアント側に立てることで、クライアントサーバ間の通信が全てのNIC を使って通信するので、NWネックになることを防げる。 – 小さなファイルを読み書きする場合にも、圧縮によるネットワーク通信量の削減 が期待されるため、クライアントにNFS Gatewayを置く効果がある。  但し、NFSクライアントノードにNFS Gatewayを置く場合、NFS Gatewayを導入 したクライアント数分のMapRライセンスが必要となるため、注意が必要。 P 33 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 35. DOC.ID 2012/02/08Mesos [調査] Mesos概要 (1/2 Mesosとは)  Mesosとは – Apache IncubatorのOSS。C++により実装されている。  SVN: https://svn.apache.org/repos/asf/incubator/mesos  git: git://git.apache.org/mesos.git – 役割  効率的なリソース分離、リソース共有機能を提供するクラスタマネージャ。 – 対象  以下のような分散型AP, FW。 – Hadoop – MPI – Spark – Hypertable, etc.  ユーザ 【引用】 Apache Mesos: Dynamic Resource Sharing for Clusters http://www.mesosproject.org/ – Twitter, UC Berkeley, UC San Francisco, etc.  利用シーン – HadoopやSparkなどを、共有プール上で動作。 – 複数のHadoop(versionが異なっていてもよい)を同一クラスタ上で実行。 – HypertableやHBaseの様な長期的に動くサービス同士のリソース共有。 – 既存環境を共有利用することで、インフラの再構築なく新規クラスタを構築。 P 34 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 36. DOC.ID 2012/02/08Mesos [調査] Mesos概要 (2/2 構成)  Mesosの構成  右図の通り以下の要素により構成される。  Mesos master  Mesos slave  Mesos applications (frameworks)  アプリケーションは以下の2つを含む。  scheduler  executor  現在のMesosプロジェクトのtrunkには、 Hadoop0.20.2が含まれている。  リソース割当 1. Mesos slaveは、自分のリソース空き状況を Mesos masterに通知する。 2. Mesos masterが持つAllocation moduleは、 リソースを要求しているFrameworkに対し、 現在の空きリソース状況を通知する。 3. Hadoopインスタンスは、mesosが持つFW Schedulerを利用して、タスクの実行を Mesos Masterに依頼する。 4. Mesos Masterは、各FWからの依頼に基づい て、Mesos slaveに処理を投げる。 5. Mesos slaveは、FW ExecuterによりTaskを 【引用】 Mesos Architecture - GitHub 実行する。 https://github.com/mesos/mesos/wiki/Mesos-Architecture P 35 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 37. DOC.ID 2012/02/08Mesos [検証] マルチテナント適用 (1/4 Hadoop on Mesos) 本検証では、下図の様な構成にてマルチテナントの実現を図った。  テナント毎に、独立したHadoopインスタンスを持つ。[Hadoop A, Hadoop B]  各テナントは、各々独立したDataNodeインスタンスを持つが、筐体は共有する。  全てのテナントは、Mesosクラスタを共有する。  全てのSlaveノードで、Mesos Slaveが動作する。  Hadoopインスタンスから見たとき、Mesos MasterはJobTrackerとして、 Mesos SlaveはTaskTrackerとして動作しているように見える。 Master Hadoop A JOB JOB Hadoop B 投入 投入 Mesos Master データ (≒JobTracker) データ アクセス アクセス TASK割当 Slave Hadoop A Mesos Slave Hadoop B DataNode データ (≒TaskTracker) データ DataNode アクセス アクセス P 36 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 38. DOC.ID 2012/02/08Mesos [検証] マルチテナント適用 (2/4 環境構成)  前頁にて述べた環境設計を、本検証では下図のようなサービス配置 で実現した。  一部のノードでMasterとSlaveが共存しているものの、 制御フロー、データフローは前頁で述べた通り。 Node1 Node2 Node3 Node4 Node5 Node6 Node7 Mesos Master Mesos Slave Hadoop A Hadoop A NameNode Hive Hadoop A Datanode Hadoop B Hadoop B NameNode Hive Hadoop B Datanode P 37 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 39. DOC.ID 2012/02/08Mesos [検証] マルチテナント適用 (3/4 ユーザとアクセス)  ユーザ権限に関して – Hadoopに対するアクセス権は、OSユーザに対して与えられる。 そのため、任意の権限を持つOSユーザを作成できれば良い。 – テナント毎にHadoopインスタンスを分割しているため、 各々のOS上の実ファイルへのアクセス権限にて、データアクセスを制御できる。 – 単一インスタンスのHDFS上にて、権限管理を意識する必要はない。  テナントへのアクセスに関して – Mesosを用いたマルチテナント構成は、Hadoopインスタンスが テナント毎に異なるため、データへのアクセス権限は期待通りに分離できる。 – sudoコマンドなど、他ユーザとしてHadoopコマンドを実行できる場合、 他インスタンスのデータアクセスが許されてしまうので、 他ユーザでHadoopコマンドを利用できないようにする必要がある。 – Hadoop設定ファイルの書き変えにより、接続先が変更された場合、 他インスタンスへのアクセスが許されてしまうので、 設定ファイルを変更できないようにする対処が必要。 P 38 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 40. DOC.ID 2012/02/08Mesos [検証] マルチテナント適用 (4/4 リソース管理) 2012/2/8 Mesosを用いた場合、既存実装だけでは最大CPU使用率 時点のtrunk や最大メモリ使用率に制限をかけることができない。 Mesosにおけるリソースの割当方針は、Allocation module が担当している。 パッケージに含まれるAllocation moduleは SimpleAllocatorのみ。SimpleAllocatorは、リソースが空 いている限り、全て割り当てる実装である。 各インスタンス毎に、リソースの利用制限をかける場合、 Allocation moduleを独自実装する必要がある。 【引用】 Mesos Architecture - GitHub https://github.com/mesos/mesos/wiki/Mesos-Architecture P 39 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 41. DOC.ID 2012/02/08 マルチテナント検証 まとめ製品 利点 欠点、課題感MapR 1. Volume機能の一つにディスク容量制限があ 1. テナント(Volume)間のデータセキュリティ るため、容量課金を容易に実現できる。 を担保するには工夫が必要。 2. FairSchedulerにより、Job実行のリソース 2. ログやJob管理画面をテナント毎に分離で 割当がテナント(pool)毎に管理可能。 きないため、テナントに直接提供できない。 3. アラートやHA, DirectNFS機能により、運 3. ライセンス体系がノード課金なため、HW増 用負荷を下げることができる。 強時やClientのクラスタ参加時など、ライ 4. Apache Hadoopに比べて高速なため、同一 センスコストが線形に増加してしまう。 性能ならば、HW数を削減可能。 4. Hadoopのバージョンアップに、どの程度ベ 5. EMC Japanによる日本語サポートが存在。 ンダが対応するのか未定。(Hadoop 0.23 には対応予定)Mesos 1. 複数のHadoopインスタンスでリソースを共 1. Job実行時、リソース制限をかけることが 有するため、CPUやメモリを有効活用でき できない。(空きがあれば利用する。) る。 2. 各ノードにて、複数のDataNodeが起動する 2. リソースのキャパシティを超えたタスクが ため、テナント数が多くなるとメモリ量な 動作することを防げる。 どの制約が出てくる。 3. 動作するHadoop自体が、Apache Hadoopな 3. Incubatorプロジェクトであり、情報量も ので、現行の運用ツールが再利用できる。 尐ないため、保守体制の実現に不安がある。 4. Sparkなど、Hadoop以外のシステムともリ (Hadoop 0.23への対応も不明) ソースを共有することができる。 P 40 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 42. 3. リクルートにおけるMapRの評価 高林 貴仁 (RECRUIT) Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 43. DOC.ID 2012/02/08 RecruitとしてのMaprの評価  Recruitでは、全社Hadoop環境の為、MaprとCDHを約50項 目に細分化して比較評価を行ってます。製品 主なメリット 課題MapR • パフォーマンス • • 運用(運用人員を含む) 障害性 • 保守 • バックアップ • NFS • 将来性 • ドキュメントCDH • 運用(運用人員を含む) • 保守 • 障害性 • 将来性 • ドキュメント P 42 Copyright(C)2012 Recruit Co.,Ltd All rights reserved
  • 44. DOC.ID 2012/02/08 リクルートでのMapR 早いだけじゃダメ・・・! – もし、何かあったらどうする? – もしがかなりの重要性をしめる場合がある – 保守/サポートがないとすごい不安に思う人たちもい る – 保守サポートだとCDH(NTTデータさん)の方の圧勝 – ドキュメントやトレーニングも充実させてほしい。 もう尐し保守/サポートを強化してほしい。 P 43 Copyright(C)2012 Recruit Co.,Ltd All rights reservedPrint 12/2/13 1時10分
  • 45. DOC.ID 2012/02/08 全社HadoopMapR or CDHを利用した、新しい全社Hadoop環 境を現在検討しております。 P 44 Copyright(C)2012 Recruit Co.,Ltd All rights reservedPrint 12/2/13 1時10分