広域分散環境における分散ファイルシステム …oguchi_lab/Publications/paper2011/...DEIM Forum 2012 C2-6 広域分散環境における分散ファイルシステムHadoopの

DEIM Forum 2012 C2-6

広域分散環境における分散ファイルシステムHadoopのデータ配置手法の提案と実装

百瀬明日香† 小口 正人†

† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1E-mail: †[email protected], ††[email protected]

あらまし 情報爆発時代を担うストレージシステムとして分散ファイルシステムを採用し，なかでも広域分散環境に

おける性能向上に着目した．対象となるシステムとしては，Web時代対応のデータインフラサービスとして，多対多

アクセスに特化したシステムである Hadoop Distributed File System を採用した．高遅延環境における基本性能とし

て遠隔ノードを含む Hadoopクラスタでファイルシステム I/O測定のためのベンチマーク，いくつかの実用的なアプ

リケーションでの性能評価を行った．ファイルシステム I/Oにおいてはリード性能において特に遅延の影響が謙虚で

あること，いくつかのアプリケーションにおいて遅延が大きいほど処理時間が増加する相関関係が見られること，ま

た，必ずしも遅延の影響を受けないアプリケーションが存在することなどが確認された．こうした遅延の影響を軽減

するため，遠隔アクセス制御手法の提案を行った．ファイルのレプリカ生成時，レプリカの分散先をラック毎に任意

の割合に制御することで，明示的データ配置制御を実現した．提案手法を用いた性能測定により，今回採用した転置

インデックス作成プログラムについて，遠隔アクセス制御を行うことによってデフォルトよりも性能向上することを

確認した．またこうした制御について，遠隔アクセス回避と処理分散のバランスから導かれる，性能上の最適な分散

割合が存在することが考察された．

キーワード 情報爆発，分散ファイルシステム，Hadoop，遠隔データアクセス制御

A Study about the Remote Data Access Control

for Hadoop Distributed File System

Asuka MOMOSE† and Masato OGUCHI†

† Ochanomizu University 2-1-1 Otsuka, Bunkyouku Tokyo 112-8610 JAPANE-mail: †[email protected], ††[email protected]

1. は じ め に

情報爆発の現代において企業や個人のデータ処理の負荷とス

トレージコストの増加が大きな問題となっている．このような

問題に対してコモディティなハードウェアを用いて高度な集約

処理を行う分散ファイルシステムに注目が集まっている．

こうした分散ファイルシステムのなかでも，本研究では特に

分散ファイルシステムにおけるデータ・アフィニティに着目し

た．データ・アフィニティとはデータとその処理を行う計算ノー

ドの位置を近くなるよう配置することにより，ネットワーク通

信量の削減とデータ処理効率の向上が望めるという概念であ

る．データの位置を考慮した処理スケジューリングをデータ・

アフィニティ・スケジューリングと呼ぶ．このようなシステム

ではジョブが常にデータローカルに処理されることで高い並列

分散処理性能・フォールトトレーランス性を維持することが知

られており，近年特に処理データ量が爆発的に増大しているこ

とに伴い重要性を増している概念である．

一方で，インターネット回線の高速化などネットワーク網の

発展に伴い広域環境におけるファイル分散が現実化していると

いう素地が存在するという点から，このようなデータ・アフィ

ニティな分散ファイルシステムの広域分散環境における性能に

着目した．こうした実装における運用に際しては，遠隔地への

アクセスによるネットワーク遅延がデータ処理効率に影響を及

ぼすことが分かっている [1]．そこで本研究では遠隔ノードへ

のデータ配置制御手法を提案および実装し，遠隔データアクセ

ス制御を用いて広域分散環境における分散ファイルシステムの

実装に関する適切なデータ配置の検討を行った．分散ファイル

システムの実装としてはオープンソースソフトウェア Hadoop

— 1 —

Distributed File System（以下 HDFS）[2]を使用した．

2. 分散ファイルシステム

本研究では近年のストレージ負荷問題の解決手法として分散

ファイルシステムを採用している．これはハードウェアの制約

がなく高いスケーラビリティを持つため，システムの規模によ

らず様々な場面での運用が見込まれる点を評価したものである．

こうした分散ファイルシステムの中でも，特にWeb時代対応

のデータインフラサービスとして，多対多アクセスに特化した

システムに着目した．Webサービスにおいては単一ユーザあた

りのデータ通信量・トラフィック確保よりも，莫大なアクセス

に対してトータルスループットを維持することが優先されると

いう特徴がある．

2. 1 Hadoop Distributed File System

本研究では分散ファイルシステムの実装としてオープンソース

ソフトウェア Hadoop Distributed File System（以下 HDFS）

を使用した [2]．Hadoopは Apache Software Foundationで開

発されている分散コンピューティング関連のプロジェクト群

を指し，コンポーネントの Hadoop Common をはじめとし，

ファイルシステムである HDFS，分散処理アルゴリズムであ

るMapReduce，データベースである hBaseなど複数のサブプ

ロジェクトから構成される（図 1）．本研究ではこのうちの特

に HDFS と Hadoop MapReduce の実装を実験環境として使

用した．

図 1 Hadoop のサブプロジェクト（2010 年 5 月現在）

2. 2 Hadoopにおけるデータ・アフィニティ

HDFSはデータ格納のマスタであるNamenode，スレーブで

ある Datanodeと，ジョブ管理を行う JobTracker，個々のジョ

ブを実行する TastTracker などのプロセスからなる（図 2）．

Hadoop における特徴的な実装である分散処理アルゴリズム

MapReduceでは，プログラムをMap，Reduceというフェー

ズに分けて並列実行するが，このとき各Mapper，Reducerは

TaskTrackerに分配され，当該ノードのローカル Datanodeに

存在するデータブロック（レプリカと呼ぶ）に対して処理を実

行する．Hadoopにおける処理はこうしたデータ・アフィニティ

なスケジューリングを考慮し得る環境で行われるため，レプリ

カをどのように配置するかという問題が，計算処理性能などに

も大きな影響を及ぼすと考えられる．

3. 実 験 環 境

クラスタ自動構築・管理ツール Rocks [3] を用いて構築し

たローカルクラスタ上に Hadoop-0.20.2 をインストールし，

Hadoopクラスタを構築した．マシンスペックは表 1に示す通

りである.また分散されるファイルの最小単位であるブロックサ

イズは 2.0MBとし，測定のためのベンチマークには，Hadoop

Master

JobTracker

Slave

TaskTracker

ksaT

Datanode

ksaT

ksaT

Slave

TaskTracker

ksaT

ksaT

ksaT

Slave

TaskTracker

ksaT

ksa T

ksaT

Namenode

Ra

cil

pe

Ra

cil

pe

Ra

cil

pe

Datanode

Ra

cil

pe

Ra

cil

pe

Ra

cil

pe

Datanode

Ra

cil

pe

Ra

cil

pe

Ra

cil

pe

図 2 Hadoop のプロセス

に付属の TestDFSIO プログラムと Map/Reduce 処理をメイ

ンに行うベンチマークである自作の転置インデックスプログラ

ムを使用した．

転置インデックスプログラムでは URLとテキスト 50,000行

からなる入力データを用意し，Map処理として文書を N-gram

モデルを用いて切り出し，URL をキー，含まれるテキストを

バリューとして抽出する．中間処理で（キー，バリュー）デー

タをバリューでソートし，Reduce処理で重複したキーの削除

を行う．なお，N-gramにより切り出す文字列の長さは n=5の

場合を採用した．

4. 高遅延環境における基本性能

4. 1 実 験 概 要

人工遅延装置 dummynet を使用して高遅延接続を含む模擬

的な広域分散環境を構築し，Namenode1台とDatanode3台の

うち Datanode1台が遠方に存在すると仮定した環境での測定

を行う（図 3）．分散されるファイルのレプリカ数は 2とした．

ただしレプリカがどこに配置されるかは高遅延ノードの物理的

な有無にはよらず，デフォルトではノード間で均等になるよう

分散配置されることが分かっている．

Local Area

Datanode

Datanode

Datanode

Namenodedummynet

図 3 システム構成

表 1 マシンスペックOS CPU Main Memory

Master nodeLinux 2.6.9-55.0.2.Elsmp(CentOS 4)

Intel(R) Xeon(R)

@3.6GHz 4.0GB

Slave nodeLinux 2.6.9-55.0.2.Elsmp(CentOS 4)

Quad-Core Intel(R)

Xeon(R) @1.60GHz 2.0GB

— 2 —

4. 2 TestDFSIOベンチマーク

TestDFSIO プログラムでは 10MB のファイルをシーケン

シャルライトで 100個作成，作成したファイルをシーケンシャ

ルリードしファイルシステム I/O 性能を計測した．ここで，

“Throughput”は，ファイルシステム内部における単位時間辺

りのデータ処理量を表している．

ローカルエリアと高遅延マシン間の往復遅延時間 (以下RTT)

を 0msecから 20msecまで変化させ測定を行った．レプリカ数

1の場合を比較すると，ライトスループットは遅延が増加して

もほぼ一定であるのに対し，リードでは大きく低下した（図 4，

図 5）．ファイルの書込はバッファを介して行われるためライ

トでは遅延分の差異が出づらい形となったのに対して，リード

ではレプリカ数 1であるため一定の割合で高遅延ノードへのア

クセスが行われ，その結果スループットが低下したものと考え

られる．

0

5

10

15

20

25

30

0 2 4 6 8 10 12 14 16 18 20

( tu

ph

gu

orh

Tces/

BM

)

RTT(msec)

1Replica

2Replica

3Replica

図 4 Write スループット

0

5

10

15

20

25

30

0 2 4 6 8 10 12 14 16 18 20

ce s/B

M ( tu

ph

gu

orh

T)

RTT(msec)

1Replica

2Replica

3Replica

図 5 Read スループット

一方，レプリカ数を増加させた場合，ライトのスループット

が低下し，リードのスループットは上昇することが確認された．

ライトでは書き込むべきデータ量が増加するため性能が劣化

し，反対にリードでは高遅延のノードにアクセスする確率が減

るためスループットが向上したものと見られる．各ノードへの

アクセス頻度はレプリカ数 1の場合と同様，遅延によらず平等

である．

4. 3 転置インデックスプログラム

転置インデックスプログラムを使用し，クライアントがHDFS

にジョブを投げ，その結果が再びクライアントへ返されるまで

の所要時間を 12回計測し，最大最小値を除いた 10回の試行に

おける平均を採用している．横軸を RTTとして実行時間を示

した．図 6より遠隔ノードへの遅延が増加するにつれてプログ

ラム実行時間は増加し，HDFS内部性能の影響が順当に反映さ

れていることが分かる．

0

100

200

300

400

500

600

700

800

900

0 2 4 6 8 10 12 14 16 18 20

exec

tim

e(s

ec)

RTT(msec)

図 6 転置インデックス実行時間

4. 4 その他のアプリケーションによる評価

高遅延環境における Hadoopの振舞について，さらにいくつ

かのアプリケーションで検討を行った．まず RandomWriteプ

ログラムでバイナリデータを生成したときの性能を測定した．

100MBのデータを生成するジョブを各ノードに与え,合計 1GB

の書き込みを行った．次に RandomWriteで生成したファイル

をソートするプログラムを実行した．

RandomWriteの実行時間は遅延が大きくなってもほとんど

変化がないのに対し，Sortの実行時間は RTTの増加に伴い上

昇した (図 7，図 8)．TestDFS I/Oベンチマークの結果と同様

に，ライトではバッファに遅延が吸収されるのに対して，Sort

ではファイルの読出を行っているため遅延の影響が発生してい

ると考えられる．これらの結果から，必ずしも高遅延の影響を

受けないアプリケーションも存在することが考察された．

0

5

10

15

20

25

0msec 2msec 10msec 20msec

Test

exec

tim

e (

sec )

RTT

図 7 RandomWrite 実行時間

5. パケット解析による動作解析

本章ではデフォルト状態の Hadoopにおいて，遠隔アクセス

制御が行われていないことを説明する．

— 3 —

0

10

20

30

40

50

60

70

0msec 2msec 10msec 20msec

Test

exec

tim

e (

sec )

RTT

図 8 Sort 実行時間

5. 1 システム構成

性能測定と併せて，ファイルシステム内で実際にどのような

通信が行われたかパケット解析を用いた調査を行った．解析に

はパケット解析ソフトウェアであるWireshark [4]を使用し，シ

ステム構成は基本性能測定と同様である（図 3）．Namenode

のみWiresharkをインストールし，Namenodeと各Datanode

間で行われたパケット通信を抽出した．

5. 2 Datanode毎の通信量の比較

レプリカ数 1において性能測定と同様のシーケンシャルライ

ト，シーケンシャルリードを交互に 5回ずつ実行したとき，各

Datanodeのパケット通信量を調べた（図 9）．3台のDatanode

との合計通信量，高遅延の Datanodeの通信量どちらを見ても

RTTが変化しても増減が見られず，HDFSで遅延によるパケッ

トロスや再転送が発生していないことが分かる．

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

0 6 10 16 20

RTT(msec)

Local node 1

Local node 2

Total

図 9 各ノードとの通信量

続いて同じくレプリカ数 1 においてシーケンシャルライト，

リードを交互に 5 回ずつ実行した際の，各ジョブで発生した

パケット通信量を調べた（図 10，図 11）．高遅延ノードの

RTT=20msecとしている．各回毎にパケット数にはばらつき

があり，Datanode3台のうち 1台特に通信量の増えるノードが

発生していることが分かる．これは Namenode が単一障害点

になることを防ぐため Datanodeのうち 1台が Namenodeの

仕事を一部肩代わりする実装によるものと見られる．ラックを

設定した場合はパケット通信量には 50% 程度の変化が見られ

たが，デフォルトの状態でも 10～30% くらいの変動があるこ

とが分かる．ただしこちらの場合ではローカルエリアのノード

と高遅延環境のノードの間で Namenode からのアクセス頻度

に差は見られず，通信量の多いノードはランダムに選出されて

いる．

0

500

1000

1500

2000

2500

3000

3500

4000

4500

write1 write2 write3 write4 write5

Local node 1

Local node 2

図 10 write 実行時のパケット数

0

500

1000

1500

2000

2500

3000

3500

read1 read2 read3 read4 read5

Local node 1

Local node 2

図 11 read 実行時のパケット数

5. 3 パケット解析考察

以上の結果から HDFS を高遅延ノードを含む構成で実装す

ると応答の遅いノードに対しても均等にデータアクセスが行わ

れ，デフォルトの実装ではシステムによるアクセス制御は行わ

れないということが確認された．

6. 遠隔データアクセス制御のための提案手法

基本性能の測定結果より，HDFSクラスタ内に遠隔ノードが

含まれることによってシステムの性能劣化が起こる場合がある

ことが分かっている．また前章より，こうした遠隔ノードに対

して Hadoopによるアクセス制御などの処理は行われていない

ことが確認された．そこで以下ではファイルシステムを書き換

え，高遅延環境における遠隔アクセス制御がシステムに及ぼす

影響についての検討を行う．

6. 1 提案手法におけるシステム構成

提案手法では，Hadoopの性能向上のためネットワーク遅延

の大きい遠隔ノードへのアクセスを制御することでシステムの

性能改善を行うことを目的とする．本手法におけるシステム構

成は図 12の通りであり，ラック単位でのアクセス制御を実装

した．

— 4 —

rack0 rack1

Datanode

Namenode

Remote

Datanode

default

rack

dummynet

図 12 提案手法のシステム構成

6. 2 制 御 手 法

Hadoop のラック設定を利用し，(i)1stレプリカはジョブが

現在存在するラックへ配置，(ii)2ndレプリカは指定した確率で

Remote rack へ，残りを Local rack へ配置，というデータ配

置ポリシーに基づいて HDFS を実装した．この際のブロック

配置は表 2）のようになり，Remote rackへのデータ配置を最

大で 30%軽減する．この値は，Hadoopの耐故障性維持のため

必要最低限のデータ分散であるものとした．このようなデータ

配置制御を与えた場合の HDFS 性能について，ベンチマーク

プログラムによる測定を行う．

表 2 ブロック配置 (Remote rack : Local rack)

Math.random 係数 ブロック比 データ配置

0.5 , 0.5 10 : 10 50% - 50%

0.4 , 0.6 9 : 11 45% - 55%

0.3 , 0.7 8 : 12 40% - 60%

0.2 , 0.8 7 : 13 35% - 65%

0.1 , 0.9 6 : 14 30% - 70%

6. 3 変更後のブロック配置

実際に上記のように変更したHDFSにおいて，一定量のデー

タ書き込みを与えた際のブロック配置は表（3）の通りである．

このときMath.Random係数は 0.8に指定しており（表 2）で

求めた通りの 13:7 の割合でデータ配置制御が行われることが

確認された．

表 3 データ書込後のブロック配置 (Remote rack : Local rack)

Rack Node 比 Blocks

rack0 Datanode1 122

rack0 Datanode2 127

rack1 Datanode3 62

rack1 Datanode4 65

7. 遠隔アクセス制御時のHDFS性能

7. 1 転置インデックスプログラムを用いた性能評価

前章の通り提案手法を用いて実装した HDFS において，遠

隔アクセス制御の割合を変化させ，HDFS のプログラム処理

性能へ与える影響を調べた．転置インデックスプログラム実行

時間を比較すると遠隔ノードへのアクセスを制限した場合の方

が，制限を行わない場合よりも概ね性能が良い傾向が見られる

（図 13）．デフォルトの HDFS性能と提案手法を比較した場合，

遅延が最も大きくなる RTT200msecにおいて最大で 51.9% の

処理時間の減少が見られた．また提案手法を用いた性能同士を

比較した場合，遠隔ノードのデータ配置割合をローカルと均

等である 50%から最小で 30%まで徐々に減らして行くと，制

御 50%に比べ制御 30%の方が平均して 15%程度性能向上する

ことが確認された．今回の測定で採用したアクセス制御割合

30-50%の範囲内では，高遅延になるほど、アクセス制御割合の

上昇に伴って，プログラム処理時間が短くなる結果が得られた．

0

500

1000

1500

2000

2500

3000

3500

0 4 10 20 50 100 150 200

)ces(

emit c

ex

e

RTT(msec)

30% 35% 40% 45% 50% default

図 13 提案手法適用時の転置インデックス実行時間

この点に関して，既存研究より [1]，こうした振舞は HDFS

ライトの結果と似た傾向であることが知られている．図 14，

図 15より遠隔ノードへのアクセスを軽減した場合（optimized

rack），ライトではデフォルトよりも平均的にスループットが

上昇し，リードでは反対に性能が低下することが分かっている．

ここで，ライトではレプリカの分散先に遅延ノードが含まれる

確率が減少したことによって性能が向上し，リードの性能は偶

発的に遠隔ノードのデータを読み出すことが多かった場合に性

能が低下したものと考えられる．

0

5

10

15

20

25

30

0 2 4 6 8 10 12 14 16 18 20

)ces/B

M(

RTT(msec)

optimized rack

default

simple rack

図 14 Write スループット

転置インデックスプログラム処理性能と HDFS ライト性能

の傾向に類似が見られた点に関して，そもそも HDFS 性能で

はリードよりライトの方が単位時間辺りの処理データ量スルー

プットが 30～50% 程度低く，今回使用したプログラムではラ

— 5 —

0

5

10

15

20

25

30

0 2 4 6 8 10 12 14 16 18 20

)ces/B

M(

RTT(msec)

optimized rack

default

simple rack

図 15 Read スループット

イト性能がプログラム処理のボトルネックとなる可能性が高い

ことが推察された．

7. 2 提案手法の性能評価まとめ

前節の結果より，本研究の実験環境において提案手法を用い

た遠隔アクセス制御を加えることで，転置インデックスプロ

グラム実行時間にデフォルトから最大で 51.9%の差が得られ

（RTT200msec 時），RTT0msec から RTT200msec の間では

平均して 22.9%程度，遠隔アクセス制御による実行時間の減少

が見られた．

なお，このとき RTT20msecは東京-大阪間の往復遅延時間，

RTT200msecは東京-米国東海岸間の往復遅延時間を想定して

いる．

8. まとめと今後の課題

8. 1 ま と め

情報爆発時代を担うストレージシステムとして分散ファイル

システムを採用し，なかでも広域分散環境における性能向上に

着目した．対象となるシステムとしては，Web時代対応のデー

タインフラサービスとして，多対多アクセスに特化したシステ

ムである Hadoop Distributed File System を採用した．

高遅延環境における基本性能として遠隔ノードを含むHadoop

クラスタでファイルシステム I/O 測定のためのベンチマーク，

いくつかの実用的なアプリケーションでの性能評価を行った．

ファイルシステム I/Oにおいてはリード性能において特に遅延

の影響が謙虚であること，いくつかのアプリケーションにおい

て遅延が大きいほど処理時間が増加する相関関係が見られるこ

と，また，必ずしも遅延の影響を受けないアプリケーションが

存在することなどが確認された．

こうした遅延の影響を軽減するため，遠隔アクセス制御手法

の提案を行った．ファイルのレプリカ生成時，レプリカの分散

先をラック毎に任意の割合に制御することで，明示的データ配

置制御を実現した．提案手法を用いた性能測定により，今回採

用した転置インデックス作成プログラムについて，遠隔アクセ

ス制御を行うことによってデフォルトよりも性能向上すること

を確認した．またこうした制御について，遠隔アクセス回避と

処理分散のバランスから導かれる，性能上の最適な分散割合が

存在することが考察された．

8. 2 今後の課題

今後はより詳しいパケット解析や HDFS のソースコード解

析などを行い，高遅延を含む実装での HDFS の振舞をより詳

細に分析する．具体的には遠隔アクセス頻度の最適化を目指し，

より複雑なシステム構成モデルを用いた遠隔アクセス制御とそ

の性能評価を行う．また遠隔アクセス頻度が処理性能にもたら

す影響に関して多角的な評価を行い，HDFS性能の総合的な向

上のための指針を検討する．これらの結果から広域分散ファイ

ルシステム性能向上のための手法を提案したい．

9. 謝 辞

本研究を進めるにあたり，独立行政法人産業技術総合研究所

の竹房あつ子氏，中田秀基氏，高野了成氏，工藤知宏氏には，

お忙しいなか貴重なご指導，ご助言賜りましたことを厚く御礼

申し上げます．

文 献[1] 百瀬 明日香，小口 正人：「高遅延環境における分散ファイルシ

ステム Hadoop の遠隔データアクセス特性の評価」，電子情報通信学会　 DE研&PRMU研 (パターン認識・メディア理解研)

共催 6月第一種研究会，信学技報，Vol.111，No.76，pp.19-24，2011 年 6 月.

[2] Dhruba Borthakur，HDFS Architecture，2008 The Apache

Software Foundation．[3] Rocks Cluster：http://www.rocksclusters.org/

[4] Wireshark：http://www.wireshark.org/

[5] Sanjay Ghemawat，Howard Gobioff，and Shun-Tak Leung：The Google File System，ACM SIGOPS Operating Systems

Review, Vol.37, No.5, pp.29-43, December 2003．[6] Tom White，玉川竜司，兼田聖士訳：Hadoop，2010 O’Reilly

Japan, Inc．[7] Jason Venner：Pro Hadoop，2009 Apress．[8] 建部修見，曽田哲之：「広域分散ファイルシステムGfarm v2の実

装と評価」，情報処理学会研究報告，2007-HPC-113，pp.7-12，2007 年 12 月．

[9] 三上 俊輔，太田 一樹，建部 修見：「広域分散ファイルシステムGfarm 上での MapReduce を用いた大規模分散データ処理」，SWopp2010，Vol.2010-HPC-126，2010 年 8 月．

— 6 —