大規模クラスタでのHadoop課題

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

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

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

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

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

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

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

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

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

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

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

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

今の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 12/09-05:29 12/09-05:30 12/09-05:31 12/09-05:32 13 user 3.1 2.4 3.1 3.2 nice 0.0 0.0 0.0 0.0 sys 0.7 0.8 0.9 2.2 intr 0.0 0.0 0.0 0.0 idle iowait 96.3 0.0 96.8 0.0 96.0 0.0 94.6 0.0 • ロック制御がシングルスレッド • サーバ自体のリソースは余裕があるのに 性能が頭打ちになっている • HW的な対応では、単一coreの性能が高 いものに切り替える必要があるが、最近 のHWのトレンドを考えると適当でない • Namenodeの同時書き込み可能なファイ ル数は1000ファイルが目安

userlogに着目した対策を検討 ある日のcreate発行対象ファイルの内訳 14 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%

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

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

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

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

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

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

• http://www.slideshare.net/HadoopSummit/evolving-

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

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

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