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

MapR & マルチテナント (include Mesos検証)

Hadoopソースコードリーディング第8回
2012/02/08 (水)

中野猛 (RECRUIT) @tf0054
- 発表内容 - 高林貴仁 (RECRUIT)
1. 性能検証 @tatakaba
大坪正典 (NSSOL)
2. 機能検証（マルチテナント検証）
@tsubo0423
3. リクルートにおけるMapRの評価

Copyright(C)2012 Recruit Co.,Ltd All rights reserved

1. 性能検証

高林貴仁 (RECRUIT)


DOC.ID 2012/02/08
１. 性能検証

 検証内容
サマリ処理のバッチは中古車サイトで実際に行われてい
た3つ処理をHiveに置き換え、非パーティション＋非圧縮
とパーティション＋圧縮の2パターンを測定し検証の実施
VCA01
– 20Tableから、5つのTemporayTable を作成後、Summary Tableを作成
VCA02
–5Tableから、２つのTemporary Tableを作成後、Summary Tableを作成
VCA05
–5Tableから、２つの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

DOC.ID 2012/02/08
3. 検証結果(非パーティション・非圧縮)

 検証結果(非パーティション・非圧縮)
サマリ種別比較 [sec] MapReduce処理比較 [sec]

MapRの方が約1.3倍高速

DOC.ID 2012/02/08
3. 検証結果(パーティション化・圧縮)

 検証結果(パーティション化・圧縮)
サマリ種別比較 [sec] MapReduce処理比較 [sec]

注)圧縮は、MapRは独自,CDHはGzipで圧縮

MapRの方が約1.76倍高速

DOC.ID 2012/02/08
4. 確認結果

Disk I/Oの状態について（CDH3)

60秒以上にわたってREAD
80MB/秒の状態

先のCPUコアの利用率からもDiskI/Oに多くの時間が割かれている。
処理時間が長いため、一部をピックアップしたが、60秒以上にわたって
90MB/秒となっており、Diskが高負荷な状態となっている。
Ｄiskのボトルネックを避ける点からも、パーティション化および
圧縮化はパフォーマンス向上のために有効であると考えられる。


DOC.ID 2012/02/08
4. 確認結果

Disk I/Oの状態について(MAPR)

60秒以上にわたってREAD80MB/秒の状態
またCDH3に比べ、山の数も多い。

ＣＤＨ３以上にDiskが高負荷状態になっており、
こちらもDiskI/Oが処理のボトルネックとなっている。
単位時間あたり読み込み量はCDH3より多く、
結果的に処理時間の短縮につながっていると考えれる。
それでもDisk性能のピークとなっているので、MAPRについても
パーティション化および圧縮化はパフォーマンス向上のために有効であると考えられる。


DOC.ID 2012/02/08
5. 考察

 MapRの方が処理速度は、非圧縮時で1.3倍速い
 ビルドイン圧縮は、Gzip圧縮と比較して高速
 圧縮率は、gzip圧縮と比べて4割程度
個人的な意見としては・・・

Hadoopに手を加えて販売してる訳だから
早くて当然でしょって感じ！！


DOC.ID 2012/02/08
6. 最後に…

チューニングの方法によっては、今回の
結果が変わる可能性はあると思います。


2. 機能検証(マルチテナント検証)

大坪正典 (NSSOL)


DOC.ID 2012/02/08
検証目的とマルチテナントについて

検証目的

本検証では、以下の確認を目的とする。

• マルチテナントに必要な機能要件を満たすことができるか。
• マルチテナント化した際に、セキュリティ要件を満たしているか。
• クラスタをマルチテナントで運用した際のコスト感はどの程度か。

マルチテナント

本資料における「マルチテナント」とは、以下の要件を満たすものを指す。

• 複数のユーザに対し、同一のHW（サーバ筐体、ネットワーク）上にて、Hadoop
サービスを提供できること。
• 各ユーザは、他ユーザの情報にはアクセスできず、情報セキュリティが担保さ
れていること。
• 各ユーザは、互いのJob実行操作ができず、各々のJob実行計画が守られること。
• 一方がリソース（CPU, Memory）を使用していない場合は、他方が余剰リソー
スを有効活用できること。


DOC.ID 2012/02/08
機能検証（マルチテナント検証）内容

 MapR
1. [調査1] パーミッション権限
2. [調査2] FairScheduler
3. [検証1] Load処理, Job投入の同時実行
4. [検証2] フェイルオーバー時間
5. [検証3] DirectNFSでの転送
 mesos
1. [調査] mesos概要
2. [検証] マルチテナント適用
 まとめ


DOC.ID 2012/02/08
MapR [調査1] パーミッション権限 (1/3 ユーザ権限)

 MapRのユーザは、Linuxユーザに準拠する。
– MapR独自のユーザ体系は無い。
– データアクセス権に関して、基本的にApache Hadoopと同等。
 HDFSに対する、直接的なPermission制御しかない。
– 但し、Hadoopと異なり、ノード同士の通信は、ユーザ名だけの認証でない。
 同じ"mapr"ユーザでも、UIDがずれているとエラーが起きる。
 MapR内におけるPermissionは以下の2種類。

MapRの機能としては、上記に挙げた権限以外の制御は行っていない。
JOBの実行権限やデータのアクセス権などは、Apache Hadoopと同じ。


DOC.ID 2012/02/08
MapR [調査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に対して一定の監視を行い、運用管理者に付加的な情報を与える存在。


DOC.ID 2012/02/08
MapR [調査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に対して一定の監視を行い、運用管理者に付加的な情報を与える存在。

Print 12/2/13 1時10分

DOC.ID 2012/02/08
MapR [調査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）


DOC.ID 2012/02/08
MapR [調査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が割り当てられる。


DOC.ID 2012/02/08
MapR [調査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から割り当てられる。


DOC.ID 2012/02/08
MapR [検証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


DOC.ID 2012/02/08
MapR [検証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


DOC.ID 2012/02/08
MapR [検証1] Load処理, Job実行 (3/6 実行環境②)

 CLDBは、4台以上でも正常に動作するので、
その場合の性能も測定する。
 同様にJobTrackerも、スタンバイ機が
3台以上あっても正常に動作するので、
計算ノード全てにJobTrackerを配備する。
 Master/Slave間の差異を無くすため、
ZooKeeperも全ての計算ノードに配備する。
 以降、本構成を「11台環境」と呼ぶ。


SiteA
ZooKeeper
Hive
SiteB
CLDB
Hive
Job
JobTracker JobTracker SiteC
Tracke
Standby Standby Hive
r



DOC.ID 2012/02/08
MapR [検証1] Load処理, Job実行 (4/6 実行環境③)

 ロード性能を計測するにあたり、
ロード処理が分散されているかを調べるため
ノード数を11台→3台に下げて計測してみる。
 以降、本構成を「3台環境」と呼ぶ。


SiteA
ZooKeeper
Hive
SiteB
CLDB
Hive
Job
JobTracker SiteC
Tracke 不使用
Standby Hive
r



DOC.ID 2012/02/08
MapR [検証1] Load処理, Job実行 (5/6 Load処理結果)

 計測結果
No. 同時実行数構成 Load時間
1 1テナント 2m10.36s
2m56.94s
2 2テナント
3+8台 3m05.08s
環境
3m21.79s
3 3テナント 3m38.27s
3m43.89s
4 1テナント 2m02.34s
2m58.15s
5 2テナント
11台 3m07.58s
環境
3m13.50s
6 3テナント 3m24.52s
3m26.77s
7 1テナント 2m36.69s
5m01.13s
8 2テナント
3台 5m03.20s  ロードの同時実行数が増えるとロード時間は延びるが、
環境ノード数を増やすことで短縮できる。 [グラフ青＋緑]
6m03.84s
 また、10台程度のMapRクラスタにおいて、CLDBの数と
9 3テナント 6m09.42s
ロード実行時間との関係性は低い。 [グラフ青＋赤]
6m13.18s


DOC.ID 2012/02/08
MapR [検証1] Load処理, Job実行 (6/6 Select処理結果)

 計測結果
No. 同時実行数構成 Select時間
1 1テナント 1m35.28s
2m25.17s
2 2テナント
3+8台 2m39.79s
環境
3m56.47s
3 3テナント 4m07.07s
4m13.13s
4 1テナント 1m32.46s
2m29.90s
5 2テナント
11台 2m41.00s
環境
4m12.48s
6 3テナント 4m16.42s
4m21.96s
7 1テナント 4m14.32s
7m39.71s
8 2テナント  同時実行数と実行時間の関係は、グラフの傾向から、
3台 7m50.59s
ロード処理時と同じことがわかる。
環境
12m57.73s  また左表より、同時実行された各テナントの
9 3テナント 13m41.15s JOB実行時間はほぼ一定であるため、
13m45.03s FairSchedulerが上手く機能していることがわかる。


DOC.ID 2012/02/08
MapR [検証2] フェイルオーバー (1/2 HA機能の差異)

Apache Hadoop MapR
Heartbeat + DRBD

MasterNode1 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

Warden

SlaveNode1 SlaveNode2 SlaveNode3 SlaveNode4 Node5 Node6 Node7 Node8
TaskTracke 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は、継続実行される。


DOC.ID 2012/02/08
MapR [検証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分程度要する。


DOC.ID 2012/02/08
MapR [検証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固有通信による高速な転送


DOC.ID 2012/02/08
MapR [検証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


DOC.ID 2012/02/08
MapR [検証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%程度の改善が見られた。


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)


DOC.ID 2012/02/08

10GBx1の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて
FileServerノード MapRクラスタにマウントした場合ローカルマウントした場合

3分 3分
CPU
(%)

MEM
(%)

HDD
(KB/s)
①はサーバ側のNWがボトル
ネックになっている。②は
MapR独自通信により、NIC2枚
を両方使っているため限界に
達していない。

NW
(Byte/s)


DOC.ID 2012/02/08

20MBx500の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて
Clientノード MapRクラスタにマウントした場合ローカルマウントした場合

9分 9分
CPU
(%)

MEM
(%)

②に比べ、①は
HDDの性能を使い
きれていない。
別のところにボ
トルネックがあ HDD
ると思われる。 (KB/s)

①に比べ、②の通信量がかなり
尐ない。MapR独自通信により、
ファイル数の多さが緩和されて
いると考えられる。

NW
(Byte/s)


DOC.ID 2012/02/08

20MBx500の転送 ①ClientにNFS Gatewayを立てず ②ClientにNFS Gatewayを立てて
FileServerノード MapRクラスタにマウントした場合ローカルマウントした場合

9分 9分
CPU
(%)

MEM
(%)

HDD
(KB/s)

NIC1つで通信しているため、
NWネックになっている可能性
が高い。（ファイル数が多い
ため正確な数値は不明。）

NW
(Byte/s)


DOC.ID 2012/02/08
MapR [検証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ライセンスが必要となるため、注意が必要。


DOC.ID 2012/02/08
Mesos [調査] 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の様な長期的に動くサービス同士のリソース共有。
– 既存環境を共有利用することで、インフラの再構築なく新規クラスタを構築。


DOC.ID 2012/02/08
Mesos [調査] 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


DOC.ID 2012/02/08
Mesos [検証] マルチテナント適用 (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
アクセスアクセス


DOC.ID 2012/02/08
Mesos [検証] マルチテナント適用 (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


DOC.ID 2012/02/08
Mesos [検証] マルチテナント適用 (3/4 ユーザとアクセス)

 ユーザ権限に関して
– Hadoopに対するアクセス権は、OSユーザに対して与えられる。
そのため、任意の権限を持つOSユーザを作成できれば良い。
– テナント毎にHadoopインスタンスを分割しているため、
各々のOS上の実ファイルへのアクセス権限にて、データアクセスを制御できる。
– 単一インスタンスのHDFS上にて、権限管理を意識する必要はない。

 テナントへのアクセスに関して
– Mesosを用いたマルチテナント構成は、Hadoopインスタンスが
テナント毎に異なるため、データへのアクセス権限は期待通りに分離できる。
– sudoコマンドなど、他ユーザとしてHadoopコマンドを実行できる場合、
他インスタンスのデータアクセスが許されてしまうので、
他ユーザでHadoopコマンドを利用できないようにする必要がある。
– Hadoop設定ファイルの書き変えにより、接続先が変更された場合、
他インスタンスへのアクセスが許されてしまうので、
設定ファイルを変更できないようにする対処が必要。


DOC.ID 2012/02/08
Mesos [検証] マルチテナント適用 (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


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への対応も不明）
ソースを共有することができる。


3. リクルートにおけるMapRの評価

高林貴仁 (RECRUIT)


DOC.ID 2012/02/08
RecruitとしてのMaprの評価

 Recruitでは、全社Hadoop環境の為、MaprとCDHを約50項
目に細分化して比較評価を行ってます。
製品主なメリット課題
MapR • パフォーマンス
•
•
運用(運用人員を含む)
障害性 • 保守
• バックアップ
• NFS
• 将来性
• ドキュメント
CDH • 運用(運用人員を含む)
• 保守 • 障害性

• 将来性
• ドキュメント

DOC.ID 2012/02/08
リクルートでのMapR

 早いだけじゃダメ・・・！
– もし、何かあったらどうする？
– もしがかなりの重要性をしめる場合がある
– 保守/サポートがないとすごい不安に思う人たちもい
る
– 保守サポートだとCDH(NTTデータさん)の方の圧勝
– ドキュメントやトレーニングも充実させてほしい。

もう尐し保守/サポートを強化してほしい。

Print 12/2/13 1時10分

DOC.ID 2012/02/08
全社Hadoop

MapR or CDHを利用した、新しい全社Hadoop環
境を現在検討しております。

Print 12/2/13 1時10分

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie Hadoopソースコードリーディング8/MapRを使ってみた (20)

Mehr von Recruit Technologies

Mehr von Recruit Technologies (20)

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