DEIM Forum2013 F2-5

Hadoop のノード脱退時および削除時のレプリカ生成に関する一考察
日開 朝美†

竹房あつ子††

中田 秀基††

小口正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 産業技術総合研究所 〒 305-8568 茨城県つくば市梅園 1-1-1
E-mail: †asami@ogl.is.ocha.ac.jp, ††{atsuko.takefusa,hide-nakada}@aist.go.jp, †††oguchi@computer.org
あらまし大規模データに対応した処理システムとして，汎用的なハードウェアを用いて高度な集約処理を行う分散ファイルシステムに注目が集まっている．本研究では，Apache Hadoop の基盤技術である Hadoop Distributed FileSystem(HDFS) に着目した．Hadoop はスケールアウトするシステムであり，システム規模に応じた運用や故障の発生などにより，ノードを脱退もしくは削除することが想定される．HDFS は通常複数の DataNode 上に複数のレプリカを保持し，ノード脱退時および削除時にはレプリカを自動的に生成する．この過程が長くなると一部の DataNodeに負荷がかかり性能が低下してしまうため，その高速化が重要である．本稿では，ノード脱退時および削除時の不足分を補うレプリカ生成処理に関するスループットを評価する．また，レプリカ生成を高速化するために，レプリカ生成先を制御する手法を提案する．制御手法により約 10MB/sec 程スループットが向上したこと，およびレプリカ生成処理が若干効率化したことを示す．
キーワード 分散ファイルシステム，HDFS，レプリカ生成，ノード削除，ノード脱退

A Study on Replica Generation
at Node Decommission and Deletion for Hadoop
Asami HIGAI† , Atsuko TAKEFUSA†† , Hidemoto NAKADA†† , and Masato OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyouku Tokyo 112-8610 JAPAN†† National Institute of Advanced Industrial Science and Technology (AIST) 1-1-1 Umezono, Tsukuba,
Ibaraki,305-8568, Japan
E-mail: †asami@ogl.is.ocha.ac.jp, ††{atsuko.takefusa,hide-nakada}@aist.go.jp, †††oguchi@computer.org

1. は じ め には削除する事が想定される．HDFS では通常複数の DataNode上に複数のレプリカを保持し，ノード脱退時および削除時には近年，通信技術や情報処理技術の発展と普及に伴い，データレプリカを自動的に生成する．この過程が十分に早くないと一量が爆発的に増加している．そこで汎用のハードウェアを用い部の DataNode に負荷がかかり性能が低下してしまうためそのて高度な集約処理を行う分散ファイルシステムに注目が集まっ高速化が重要である．ている．分散ファイルシステムは，高いスケーラビリティを持

本稿では，HDFS においてノード脱退時および削除時に不足つため，システムの規模に応じた運用が見込まれる．また，従分を補うレプリカ生成処理の特性を把握するためにスループッ

来では想定されていなかったような極めて大規模なシステム構トを測定した．またレプリカ生成の高速化のために，レプリカ成を取る機会が増えた．しかしながら，全てのマシンを正常に生成先を制御する手法を提案して，評価実験を行った．制御手動作させることは難しく，常に一定の割合で故障や動作不安定法により約 10MB/sec 程スループットが向上したこと，およびなマシンが存在してしまうという問題が新たに生じる．

レプリカ生成処理が若干効率化したことを示す．

Hadoop Distributed File System(以 下 HDFS) [1] は ，Apache Hadoop(以下 Hadoop) [2] の基盤技術であり，Google

2. 分散ファイルシステムの 分 散 ファイ ル シ ス テ ム GFS [3] に 基 づ い て 設 計 さ れ た ．

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

Hadoop はスケールアウトするシステムであり，システム規本研究では，汎用のハードウェアを用いて高度な集約処理を模に応じた運用や故障の発生などにより，ノードを脱退もしく行う分散ファイルシステムに注目した．分散ファイルシステム—1—

は，ハードウェアの制約が無く，高いスケーラビリティを持つ転送する．この時 NameNode が定期的に DataNode に指示すため，システム規模に応じた運用が可能である．また多数の計る転送間隔は変数 replicationRecheckInterval で定義され，算機が並列分散処理を行うため，大規模データに対して効率良

転送レプリカブロック数は，クラスタに接続されている DataN-く処理を行うことができる．

ode 数*変 数 REPLICATION WORK MULTIPLIER PER ITERATION

2. 2 Hadoop Distributed File Systemで 定 義 さ れ る ．DataNode が 生 成 完 了 の ACK を 受 け 取 ら

Hadoop は Apache Software Foundation で開発されているない状態のまま，レプリカ生成先の DataNode へ転送でき

分散コンピューティング関連のプロジェクト群で，様々なサブプる ブ ロック 数 は 変 数 dfs.max-repl-stream で 定 義 さ れ る ．

ロジェクトの集合体である (図 1)．HDFS はそのサブプロジェ

replicationRecheckInterval と REPLICATION WORK MULTIP

クトの一つで，Google の分散ファイルシステム GFS に倣っ

LIER PER ITERATION は ，FSNamesystem.java の Replica-て設計されたオープンソースの分散ファイルシステムである．

tionMonitor ク ラ ス で 定 義 さ れ て い る 変 数 で あ り，

HDFS は，ファイルのメタデータやクラスタ内のノード管理をdfs.max-repl-stream はプロパティで変更可能な変数であ行う一台の NameNode と，実際にデータを格納している複数る．各変数のデフォルト値は表 1 のようになっている．

台の DataNode からなる．ファイルを最小単位であるブロックに分割して DataNode 間で分散して保存することで，耐故障性と対多クライアントでの高いパフォーマンスを維持している．

PigSqoopMapReduce

HDFS

Hadoop Common

Hive

表1

各変数のデフォルト値

変数
replicationRecheckInterval
REPLICATION WORK MULTIPLIER PER ITERATION
dfs.max-repl-stream

デフォルト値322Hbase
Zookeeper
Avro

4. 基本性能評価
4. 1 実 験 環 境
本実験ではレプリカ生成に関する評価を行うために，ノー

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

ドを切り離す方法の違いと，ブロックサイズおよび同時に処理するデータ量の変化がレプリカ生成処理のスループットに与3. ノード脱退時および削除時のレプリカ生成の流れ
3. 1 ノード脱退とノード削除
HDFS はクラスタからノードを切り離す際，該当ノードが保持しているデータのレプリカを残りのノードに移行することで，える影響を調査する．ブロックのレプリカ数を 3 とし，1 台のDataNode をクラスタから切り離す際のスループットを示す．
ここでスループットは以下のように定義した．
スループット [MB/sec] =脱退及び削除ノードが保持しているデータ量 [MB]データの複製が開始してから完了するまでの時間 [sec]指定したレプリカ数を維持する．本研究ではクラスタからノードを切り離す方法として，ノード脱退とノード削除の二種類が存在する．
ノード脱退とは，事前に脱退ノードが保持しているデータのレプリカを他のノードに複製してからそのノードをクラスタかローカルクラスタ上で Hadoop-1.0.3 をインストールしたマ
シン 7 台を用いた．そのうち 1 台を NameNode とし，残りの6 台を DataNode とした．マシンのスペックは全て同一で表 2に示す通りである．

ら切り離す方法である．クラスタ規模の縮小やエラー率が非常に高いノードが存在する時など，意図的にクラスタからノードを切り離す場合を想定している．
ノード削除とは，クラスタからノードが離脱後，残ったノー

表 2 マシンスペック
OSCPUMain MemoryHDDRAID Controller

Linux 2.6.32-5-amd64 Debian GNU/Linux 6.0.4Quad-Core Intel(R) Xeon(R) CPU @ 1.60GHz
2GB
73GB SAS × 2(RAID0)
SAS5/iR

ド間で削除ノードが保持していたデータのレプリカを複製し補完する方法である．ノードの故障や動作不良あるいはネット

4. 2 ノード脱退およびノード削除の基本性能

ワークの切断等により，想定外にノードが突然クラスタから離ブロックサイズをデフォルトで設定されている 64MB とし，脱してしまう場合を表す．

ノード脱退とノード削除の 2 つの方法でクラスタから DataN-

3. 2 レプリカ生成の流れ

ode を切り離した際の，スループットを測定した結果を図 2 にノード脱退もしくは削除処理が実行されると，その DataNode示す．図 2 より，ノード脱退時の方がノード削除時に比べてスで管理されていたレプリカの再配置のためにレプリカ生成処理がループットが高いことが分かる．これはノード削除時には，削行われる．レプリカ生成はブロック単位に処理が進み，まず Na-除ノードを除く残りのノードでレプリカ生成処理が行われるの

meNode が定期的にレプリカ生成の指示をそれぞれの DataNodeに対して，ノード脱退時には，脱退ノード自身がレプリカ生成に転送する．DataNode は受けとった指示をもとに，レプリカ生元としてレプリカ生成処理に参加することができるためである．

成先の DataNode へデータの転送を始める．生成先でデータの複製が完了すると，生成元の DataNode に生成完了の ACK を—2—

160存在してしまうことが考えられる．これらは通信効率を悪化さ140せる要因であり，これらを改善することでレプリカ生成が効率)
ce 120s/
B100(M的に行われることが期待できる．そこでレプリカ生成の高速化

トッ 80
プ 60
ール40スに向けて，まずはレプリカ生成先を制御する手法を提案し，制0

ドをリング状に配置し，そのリング構造に従って一方向にデー御前後でスループットを比較して有効性を検証する．

5. 1 提 案 手 法
Dolly [4] や catwalk-ROMIO [5] で用いられてるように，ノー20

ノード脱退

ノード削除

タ通信を行うと，ネットワーク内で通信のボトルネックとなるデータの集中が避けられるため効率が良いことが知られている．

図 2 ノード脱退時とノード削除時のスループット

そこで本提案手法では，ノードがリング状に配置されていると仮定し，レプリカ生成先を以下のように定義する (図 4)．

4. 3 同時転送ブロック数を変化させた実験
ブロックサイズ 16，32，64，128，256MB に対して，レプリカ生成時の NameNode と DataNode の同時転送ブロック数に関連する，REPLICATION WORK MULTIPLIER PER ITERATION とdfs.max-repl-stream の 2 つの変数を共に同じ値αとし，αを 1〜8 に変化させてノード削除を行った際のスループットを図3 に示す．図 3 より，αが小さいとき，すなわち同時転送ブロッ(1) レプリカ生成先をリング上の次のノードに指定する．
(2) もしそのノードがすでにレプリカを持っている場合は，さらに次のノードをレプリカ生成先にする．
このようにレプリカ生成先を制御することで，データの流れを一方向に制御し，多数のノードと通信する事を回避して，通信効率を向上させることを目指す．

ク数が少ない場合，ブロックサイズが小さい時にはスループットが低くなる．これはブロックサイズが小さいと DataNode はレプリカ生成処理が早く完了して，NameNode から定期的に送られてくるレプリカ生成の指示を待っている状態が生じるからと考えられる．そのためこの状態にある間は，αに比例してほぼ線形にスループットが増加している．またこの指示待ち状態が解消された後は，αの増加，すなわち同時転送ブロック数の増加に伴い，スループットが若干低下している．多数のスレッドが生成されたために，ディスクへの書き込みや通信の衝突によるオーバヘッドが発生しているためと考えられる．

図 4 提案手法のレプリカ生成先160

5. 2 提案手法の評価

140

4. 3 節と同様の実験を提案手法に関して行い，ブロックサイ)
ce 120s/
B
100
M(16MB

トッ 80
プ60
ール40
ス

32MB
64MB
128MB
256MB

200123456同時転送ブロック数のパラメータ
同時転送ブロック数のパラメータ α78ズ毎の制御前後のスループットの測定結果を図 5 に示す．図 5より，DataNode が生成完了の ACK を受け取らない状態のま
ま，レプリカ生成先の DataNode に転送できるブロック数以上のレプリカ生成の指示を NameNode から受け取っている時には，全ての場合で提案手法のスループットが 10MB/sec 前後向上している．16，32，64MB においてαが小さい時には，制御前後のスループットに変化がないが，これは 4. 3 節で述べた

図 3 各ブロックサイズにおける同時処理するブロック数に応じたスループット

ように DataNode は NameNode からのレプリカ生成の指示を待っている状態であると考えられることから，スループットが向上する余地が無いため妥当な結果である．また提案手法は，

5. レプリカ生成先を考慮した制御手法の提案
HDFS では，ノードが同一ラックに配置されている場合，レプリカの生成先は該当のレプリカを保持していないノードからランダムに選出される．一見レプリカの生成先が分散し効率がブロックサイズが大きいほど有効であることが確認できる．ブ
ロックサイズが大きい方が 1 つのブロックのレプリカ生成にかかる時間が長く，複数ノード間での通信効率を向上させる提案
手法の効果が大きいためである．

良さそうだが，分散させた結果，一対多の通信が多発してしまうことや，生成先の選出はランダムでありながらも，偶発的にあるノードに集中してしまうことにより，idle 状態のノードが—3—

ムにした．ここではデータ数が多いため，デフォルトの設定で16MB160ある 64MB，α=2 のときと，ブロックサイズおよび同時転送

140

ブロック数が多い場合の 256MB, α=８の時のヒストグラムを)
ce120s/それぞれ図 6 と 7 に示す．実験毎にレプリカ生成処理の実行時

B100
M(

トッ 80
プ60ー
ル40
ス200

制御前16MB
制御後16MB1234567

同時転送ブロック数のパラメータ α8

信 (上) と受信 (下) の 3 回分の実験結果をまとめたもので，デーがスループット (MB/sec) のデータ区間で，0，(0，10]，(10，20]，…と 10 刻みとし，縦軸が各データ区間のデータ数である．
ブロックサイズが 64MB，α=2 と扱うデータが比較的小さ

制御前32MB
制御後32MB

いとき，図 6 より，送信の結果では，制御前に比べて制御後のデータ区間 0 のデータ数が増加し，ヒストグラムのピーク値が右にシフトしている．データ区間 0 の増加は，通信をしていな

0123456

同時転送ブロック数のパラメータ α78）ce 140
s/B120M（ 100トッ 80
プー60ル40ス

い時間が増加したということである．提案手法は生成先を隣のノードに制御しているため，処理が均一に分散しやすく，また多数のノードとの通信を回避できるため，通信効率が上がり，

64MB

1604. 3 節で述べたように各 DataNode で NameNode からの指示待ち状態が増えたためであると考えられる．またヒストグラムのピーク値が右にシフトしているのは，通信効率の向上に起因制御前64MB
制御後64MB20するものと考えられる．
受信の結果では，制御前に比べて制御後のデータ区間０のデータ数が減少していること，およびデータ区間 60，70 が増

1234567

同時転送ブロック数のパラメータ α8加していることがわかる．データ区間 0 の減少は，通信をしていない時間が減少したということであり，送信とは逆の結果であるが，これは提案手法により処理が均一に分散しやすくなっ

128MB

160たためデータを受信しない機会が減少したためだと考えられる．

) 140
ces 120/B
100M(

またデータ区間 60，70 が増加したのは，通信効率が向上したためであると考えられる．

トッ 80
プ60
ー40
ル20ス

制御前128MB
制御後128MB

64MB， α=2 send600

123456

同時転送ブロック数のパラメータ α78256MB

160

500
400
数
タ300
ーデ200制御前制御後100) 140
ces/ 12000B100M(トッ 80プ60ー40ル20ス0は，100 秒× DataNode5 台の計 500 個であり，図 6 と 7 は送タ数は，それぞれ 500 個×実験 3 回の計 1500 個である．横軸

32MB

1600

理の終了時刻も異なることから，データはレプリカ生成処理の開始 1 秒から 100 秒までを扱っている．一回の実験のデータ数）ce140/sB120M（ト10080
ップ 60ー40ル20ス0間が若干異なり，また一回の実験においても各 DataNode の処

1020304050スループット

制御前256MB制御後256MB607080

90 100 110 120のデータ区間(MB/sec)

64MB， α=2 receive600

123456

同時転送ブロック数のパラメータ α78

図 5 ブロックサイズ毎の制御前後のスループット500400数
タ300
ーデ200

制御前
制御後

100

通信効率の向上を目指す提案手法による通信効率の向上および，制御前後のスループットの変化を示すために，制御前後の各 DataNode の 1 秒毎の送受信のスループットをヒストグラ

001020304050

スループット60708090 100 110 120のデータ区間(MB/sec)

図 6 64MB，α=2 の時の送受信のヒストグラム—4—ブロックサイズが 256MB，α=８と扱うデータが大きいとき，図 7 より，データ区間 0 のデータ数が送受信ともに 0 かそれに近い値であることが分かる．これはブロックサイズが大きく，同時転送ブロック数も多いため，常に通信が継続して行われているためである．また送受信ともに，ヒストグラムのピーク値が右にシフトしている．これもまた通信効率が向上したためであると考えられる．

256MB， α=8 send
600
500
400

数
タ300
ーデ200

制御前
制御後

文献[1] Dhruba Borthakur, ”HDFS Architecture,” 2008 The
Apache Software Foundation.
[2] Tom White(著), 玉川竜司，兼田聖士 (訳):Hadoop, オライリー・ジャパン,2010[3] Ghemawat, Sanjay; Gobioﬀ, Howard; Leung, Shun-Tak(October 2003), ”The Google File System,” 19th Symposium on Operating Systems Principles (conference), LakeGeorge, NY: The Association for Computing Machinery,
CiteSeerX: 10.1.1.125.789, retrieved 2012-07-12.
[4] Felix Rauch, Christian Kurmann, Tomas M.Stricker, ”Partition Repositories for Partition Cloning ― OS IndependentSoftware Maintenance in Large Clusters of PCs,” Proceedings of the IEEE International Conference on Cluster Computing 2000, Chemnitz, Germany, Nov 28 - Dec 2, 2000.
[5] 堀敦史，鴨志田良和，松葉浩也，安井隆，住元真司，石川裕：
ファイルステージングシステム Catwalk の MPI-IO 実装，情報処理学会研究報告，2009 年 8 月．

100001020304050607080

90 100 110 120スループット（MB/sec）のデータ区間

256MB， α=8 receive
600
500
400
数タ300ー
デ200

制御前制御後100001020304050607080

90 100 110 120スループット（MB/sec）のデータ区間

図 7 256MB，α=8 の時の送受信のヒストグラム

6. まとめと今後の課題
分散ファイルシステムの一つである HDFS 上で，ノード脱退時とノード削除時のレプリカ生成に関する基本性能の評価を行った．ノード脱退時の方が削除時に比べてスループットが高いことと，レプリカ生成処理のブロックサイズが小さく，同時転送ブロック数も少ないとスループットが低いこと，および同時転送ブロック数を増加させると，処理のオーバヘッドによりスループットが低下することを確認した．またレプリカ生成の高速化のためにレプリカ生成先を制御する手法を提案し，実装した．評価実験から制御手法によりスループットが 10MB/sec程向上した．また，制御手法により若干であるがデータが均一に分散されて，効率の良い処理が実現できた．
今後の課題としては，本稿のレプリカ生成先の制御に加えて，生成元の制御も行い，更なるレプリカ生成の高速化を目指した
い．また HDFS では複数のレプリカは，信頼性と読み書きに必要な帯域のトレードオフを考慮し，異なるラックに分散して配置される．本実験環境は全てのノードが同一のラック上にあるためラックを考慮しないレプリカ配置を行っていたので，より現実的環境を想定し，ラックを意識した制御にも取り組んでいきたい．

—5—