大規模HDFS & ErasureCoding#yjdsw3

社外秘 大規模HDFS  &  ErasureCoding 分散コンピューティング黒帯 鄭 輝 15/12/02

自己紹介 • 2004年 来日 • 2008年 ヤフージャパンに入社 – 2013年 大規模Hadoopクラスタを構築、運用 – 2015年  OSS(Hadoopエコシステム)開発 （※今ここ） • 2015年10月 分散コンピューティング黒帯 P2

Agenda • ヤフージャンパンのHadoopが取り巻く環境 • 大規模HDFSクラスタで直面する課題 P3

Agenda • ヤフージャンパンのHadoopが取り巻く環境 • 大規模HDFSクラスタで直面する課題 P4

データ使用量も「指数関数的」に増加 P5 HDFS  使⽤用量量  →  年年2.1倍（予測） y = 3.284 e 0.0021x 年年2.1倍 Copyright  (C)  2015  Yahoo  Japan  Corporation.  All  Rights  Reserved.  無断引⽤用・転載禁⽌止

CPU使用量「指数関数的」に増加 P6 CPU  使⽤用量量  →  年年3.3倍 y = 19.859 e 0.0033x 3.3倍 1年年 Copyright  (C)  2015  Yahoo  Japan  Corporation.  All  Rights  Reserved.  無断引⽤用・転載禁⽌止

P7 ⼤大規模なHadoop環境 6,000台 〜～2010年年 2011年年〜～2012年年 2013年年 2014年年 最大のクラスタ 3,000台 Copyright  (C)  2015  Yahoo  Japan  Corporation.  All  Rights  Reserved.  無断引⽤用・転載禁⽌止

Agenda • ヤフージャンパンのHadoopが取り巻く環境 • 大規模HDFSクラスタで直面する課題 P8

普通のHDFS P9 NameNode create,rm…        ※active / client ls,  cr eate,  mv… editlog edit log fsimage JournalNode Block DataNode client Repo rt k k k k k block block block editlog NameNode        ※standby fsimage k block block block

大規模のHDFS P10 two NameNode 1.6億ブロック        ※active client 遅い / create,rm… 3000  connection  BlockReport DataNode 3000台 fsimage JournalNode k ガベージコ レクション 遅い k client k client k client k client k k k k        ※standby k k 有効データ:1/3 k k k 60PB->20PB 3000  connection block BlockReport fsimage 1.3億 k block block block block block block block block block block block block block block block block NameNode ※2015年11月ファイル数: k 遅い files  and  directories,   1.6億  blocks block

Agenda • ヤフージャンパンのHadoopが取り巻く環境 • 大規模HDFSクラスタで直面する課題 – BlockReportが遅い(解決済み) – Storageコスト（開発中） P11

BlockReportの遅い影響 P12 • NameNodeの起動が遅い（数時間） NameNode DataNode BlocksMap blockId dn1,dn2 ,dn3 fsimage rt BlockRepo k k k k k … k k k blockId dn4,dn5 ,dn6 blockId dn7,dn8 ,dn9 k k k k k k k block block block block block block block block block block block block block block block block BlockReport … block blockと存在するdn の情報を揃わないと データをアクセスで きない k block

BlockReportなぜ遅いか P13 HDFS-7980の影響 機能してない BlockReport 重い処理 追加、削除、失効のdiffを取る 更新/追加/削除/失効処理 under/over  Replicationの処理 pendingReplicationsの処理 corruptReplicasの処理 firstBlockReport 軽い処理 blockと所在するDNの 情報を集めるのみ

firstBlockReport機能しない原因 • BlockReport – fullBlockReport(1.6億) NameNode DataNode 再起動 ①full • 頻度：24時間に１回 – incrementBlockReport（差 分のみ） P14 軽い処理 ②increment • 頻度：数分間に1回 NameNode DataNode 再起動 ②full 軽い処理 ①increment 稼働中 busy

BlockReportが遅い対策① • 暫定対策 – 運用手順(incrementBlockReportをなくす) • 全DataNode  stop • NameNode起動/再起動 • 全DataNode  start – 10分内確実完了 P15

BlockReportが遅い対策② P16 • 根本対策 – コンミュニティと連携(HDFS-7980)   • 一つ目のfullBlockReportに軽い処理を適用する • Hadoop2.6.1から NameNode DataNode 再起動 ②full 軽い処理 ①increment 稼働中 busy

Agenda • ヤフージャンパンのHadoopが取り巻く環境 • 大規模HDFSクラスタで直面する課題 – BlockReportが遅い(解決済み) – Storageコスト（開発中） P17

HDFSのOverhead-200% P18 Replication(3) dn1 dn2 dn3 rep2 rep3 File Block1 Block1 Block2 Block3 Block1 rep1 Durabality=2 Overhead=200%

ErasureCodingで改善 ReedSolomon(6,3) HDFS-­‐7285 dn1 File P19 dn2 dn6 dn7 dn8 dn9 Block1 stripe1 s1 s1 s2 s2 s6 s6 p1 p1 p2 p2 p3 p3 stripe2 s7 s8 s12 p4 s5 s6 Block1 Block2 StripeN DataBlock BlockN Durabality=3 Overhead=50% ParityBlock データ復元用

コミュニティーと一緒に開発 ヤフージャパンRESOLVED: 56 P20

Replication  vs  ErasureCoding Ac<on Read Wr<e   Keep Reconstruc<on P21 Resource Replica<on ErasureCoding Network  Traffic ◯ ✖ CPU ◯ ◯ Disk ー ー Network  Traffic △※量3倍、locality   △※量1.5、localityなし CPU ◯ ✖ Disk ー ー Network  Traffic ー ー CPU ー ー Disk ✖ ◯ Network  Traffic ◯ ✖ CPU ◯ ✖ Disk ー ー • EC最大のメリット：Disk容量が少ない • ECのデメリット：network  traffic、CPU使用用が多く発生

パフォーマンステスト • HDFS-8425で報告 • テストケース：TestDFSIO • クラスタ情報 P22 2015年１０月バー ジョン、まだ改善中 DataNode数 20 CPU Xeon  E5-­‐2630L  2.00GHz/2CPU RAM 64G Disk SATA  3TB  x4発 Network 1G

パフォーマンステスト-Readスループット • TestDFSIO  -nrFiles  (10,20,30,40,50,60,70,80,90,100)  -size  384MB P23

パフォーマンステスト-Writeスループット • TestDFSIO  -nrFiles  (10,20,30,40,50,60,70,80,90,100)  -size  384MB ErasureCodingが勝つ P24

パフォーマンステスト-CPU使用率 • P25 110~200  filesをwriteする時のDataNode  CPU使用率 平均値を計算す ると5.5%上がる replicaPon ErasureCoding

ErasureCodingに関する結論 • Network、CPUのデメリットが許容できる • Storageコストのメリット（半減）が大きい • クラスターのリソース状況にあわせて使う P26

今後の導入計画 P27 • HDFS-6584 – Storage  Policyの概念が紹介された Storage  Policy Dataのアクセス頻度 HOT 毎日、毎週   WARM 毎月 COLD 殆どアクセスしない 対象とする:メリットを享受、デ メリット回避 例えば：一年前のlogデータ

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