2016/12/22のBDI研究会での発表資料

1. ヤフー株式会社 データ＆サイエンスソリューション統括本部
杉山 朋広・藤本 謙志・北嶋 昇
大規模クラスタでのHadoop課題

2. 2
杉山 朋広
• 2002年 入社
• 2011年にヤフーで最初の大規模Hadoopクラスタ
の構築に携わる
• 現在は、コマース向けのデータプラットフォーム
の整備を担当している
自己紹介
藤本 謙志
• 2010年 入社
• 2011年のヤフーで最初の大規模クラスタの構築
メンバー
• これまでに1000〜4000台規模のHadoopクラスタ
を構築・運営
• 現在はHadoopクラスタのDevOpsチームのマ
ネージャを務める

3. アジェンダ
ヤフークラスタの規模
処理量の増大への対応
データ量の増大への対応

4. アジェンダ
ヤフークラスタの規模
処理量の増大への対応
データ量の増大への対応

5. データは2014年ごろから激増
0
10
20
30
40
50
60
70
80
90
100
0
1,000
2,000
3,000
4,000
5,000
6,000
2009 2010 2011 2012 2013 2014 2015 2016
RowHDFSStorage(inPB)→
NumberofNodes→
Hadoopクラスタの総ノード数とデータ量の推移
Nodes HDFS

6. 半年余りで計算リソースが不足
6
2014 2015
Resource Manager Cluster Queue last year
2014年の計算リソース使用率推移
（3000ノード・クラスタメモリ約180TB）

7. 効率化の中で直面した課題をシェア
2013 2014 2015 2016
設備投資額のイメージ
7
計画
効率化

8. アジェンダ
ヤフークラスタの規模
処理量の増大への対応
データ量の増大への対応

9. ジョブ数は半年で２倍に
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
80,000
90,000
1日あたりジョブ数の推移

10. 効率化によりスループット向上を狙う
• 非効率な設計のアプリケーション
• コンテナメモリサイズが不適当
• NM→RMのHeartBeat間隔が長い
• タスクでFullGC頻発
• userlog書込みボトルネック
10

11. 効率化によりスループット向上を狙う
• 非効率な設計のアプリケーション
• コンテナメモリサイズが不適当
• NM→RMのHeartBeat間隔が長い
• タスクでFullGC頻発
• userlog書込みボトルネック
11

12. 12
リソースの使用状況とCallQueueLengthの関係
処理量とNN負荷が連動
• ピーク時にHDFSアクセスが遅い
• クラスタリソースのピークと
CallQueueLengthが連動しているこ
とがわかった

13. 13
今のNNではHW的な対応ができない
# 同時 1,000ファイルの書込み
$ zgrep app-logs hdfs-audit.log.2016-12-09-05.gz
|grep rename |cut -d, -f1 |uniq -c | sort -nr | head
–n4
1126 2016-12-09 05:31:08
875 2016-12-09 05:31:13
753 2016-12-09 05:32:19
657 2016-12-09 05:05:44
# 1cpu-coreを占有(100% ÷ 40core = 2.5%)
Time user nice sys intr idle iowait
12/09-05:29 3.1 0.0 0.7 0.0 96.3 0.0
12/09-05:30 2.4 0.0 0.8 0.0 96.8 0.0
12/09-05:31 3.1 0.0 0.9 0.0 96.0 0.0
12/09-05:32 3.2 0.0 2.2 0.0 94.6 0.0
• ロック制御がシングルスレッド
• サーバ自体のリソースは余裕があるのに
性能が頭打ちになっている
• HW的な対応では、単一coreの性能が高
いものに切り替える必要があるが、最近
のHWのトレンドを考えると適当でない
• Namenodeの同時書き込み可能なファイ
ル数は1000ファイルが目安

14. userlogに着目した対策を検討
userlog 49.4%
.gz 36.4%
partファイル 1.2%
.jar 2.9%
.so 0.2%
COMMIT,SUCCESS 1.4%
.xml 1.4%
conf.xml 2.0%
other 5.2%
14
ある日のcreate発行対象ファイルの内訳

15. 今のところ適当なソリューションが無い
15
userlogを
出力しない
userlogの
保存を分離
HDFS
Federation
• もっとも簡単な方法
• トラブルシュートに支障
• 移行コスト大
• 採用Distributionが非対応
• 運用コスト大
• userlog専用は勿体ない
別のHDFS
HDFSではないスト
レージへ保存
• 開発や機能追加が必要

16. アジェンダ
ヤフークラスタの規模
処理量の増大への対応
データ量の増大への対応

17. HDFSは１年足らずで75%消費
0
5
10
15
20
25
30
35
40
2014/8 2015/2 2015/8
NumberofNodes→
HDFS Max
17

18. 18
データの増加がNN性能に影響
• NNメモリの増加
• BlockReportの増加

19. 19
Federationにも課題がある
• Federationの効果
• クライアントリクエストの分散
• NNメモリの分散
• 問題点
• HDFS上のディレクトリにマッピングされる
ので偏りやすい
• ひとつのPoolの限界は、単一の
Namenodeと同程度
/data /apps /user

20. 20
次世代HDFSに期待
• ブロック管理をDatanodeで
• Object Store Metadataのサポート
http://www.slideshare.net/HadoopSummit/evolving-
hdfs-to-a-generalized-distributed-storage-subsystem

21. 21
HDFS
NNの一部機能をDNへ移譲
HDFS on Container
DN1
b1 b2 b3
DN2
b2 b3 b4
DN3
b3 b4 b1
DN4
b4 b1 b2
BlockMap
b1 => DN1, DN3, DN4
b2 => DN1, DN2, DN4
b3 => DN1, DN2, DN3
b4 => DN2, DN3, DN4
MasterNode SlaveNodes
ContainerMap
c1 => DN1,DN2,DN3
c2 => DN2,DN3,DN4
MasterNode SlaveNodes
DN2
b1 b2 b3 b4c1 c2
DN3
b1 b2 b3 b4c1 c2
DN1
b1 b2c1
DN4
b3 b4c2

22. まとめ
• データ量だけでなく、計算リソースの有効活用の観
点でも、Namenode性能が問題となる
• 次世代HDFSのContainer化により、Namenodeの性
能問題を是正していく
• Namenodeのスケーラビリティを引き上げられれば、
より大きなクラスタを作ることができる

23. ご清聴ありがとうございました