Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Apache Hadoopの未来 3系になって何が変わるのか?

2,233 views

Published on

2017年10月30日に開催されたNTTデータ テクノロジーカンファレンス2017での講演資料です。
Apache Hadoopの未来 3系になって何が変わるのか?
Introduction of Apache Hadoop security isssue and Hitchhiker Erasure Coding algorithm

Published in: Technology
  • Be the first to comment

Apache Hadoopの未来 3系になって何が変わるのか?

  1. 1. 1 © 2017 NTT DATA Corporation 株式会社NTTデータ 鯵坂 明 2017/10/30 NTTデータ テクノロジーカンファレンス2017 Apache Hadoopの未来 3系になって何が変わるのか?
  2. 2. 2  鯵坂 明 (Akira Ajisaka, @ajis_ka)  Hadoopと関わり続けて6年が経過  Hadoopの新機能や、関連するミドルウェアの検証  プロジェクトへの技術支援  サポートサービス  Apache Hadoop committer, PMC member  Java9がリリースされたので、対応中  JUnitやLog4Jのアップデートに苦戦  10年物のコードを直すことも 自己紹介 コミッタ選出 リリース投票 ブランド管理 ライセンス管理 など
  3. 3. 3 先月に、10年前から残っていたバグを直した
  4. 4. 4 Apache Hadoop 3のリリースが近い 20142011 20132012 2015 2.2.0 2.3.0 2.4.02.0.0-alpha 2.1.0-beta 0.23.0 0.23.11(final) NameNode Federation, YARN NameNode HA HDFS Snapshots NFSv3 support Windows Heterogeneous storage HDFS in-memory caching HDFS ACLs HDFS Rolling Upgrades Application History Server RM Automatic Failover 2.5.0 2.6.0 YARN Rolling Upgrades Transparent Encryption Archival Storage 2.7.0 Drop JDK6 support Truncate API 2016 branch-0.23 branch-2 trunk Hadoop2 Hadoop3 2017 2.8.0 3.0.0-alpha1 3.0.0-beta1 HDFS caller context S3A improvement Support Azure Data Lake 3.0.0-alpha4
  5. 5. 5 Hadoop 3で大きく変わるポイント  HDFS Erasure Coding  YARN Timeline Service v.2  Shell script rewrite  Shaded client jars  MapReduce task-level native optimization  Intra-datanode balancer  HDFS Router-Based Federation  ・・・ 全ては紹介しきれない Apache Hadoop 3で変わること
  6. 6. 6 技術的に面白く、世の中に情報が出ていない話を2つ紹介  YARN NodeManagerの脆弱性について  脆弱性修正の裏側を話せる範囲で紹介  先進的研究成果の取り込みについて  Hitchiker erasure codingの紹介 今回は技術的に面白い話がしたい
  7. 7. 7 技術的に面白く、世の中に情報が出ていない話を2つ紹介  YARN NodeManagerの脆弱性について  脆弱性修正の裏側を話せる範囲で紹介  先進的研究成果の取り込みについて  Hitchiker erasure codingの紹介 今回は技術的に面白い話がしたい
  8. 8. 8 すでに修正済かつ公になっているYARN NodeManagerの脆弱 性について、以下の流れで説明  脆弱性の内容  詳細解説  脆弱性の修正・公表  脆弱性の修正によるトラブルとその対策 まえがき
  9. 9. 9 CVE-2016-3086: Apache Hadoop YARN NodeMangaer vulnerability 今回紹介する脆弱性の内容 The YARN NodeManager in Apache Hadoop 2.6.x before 2.6.5 and 2.7.x before 2.7.3 can leak the password for credential store provider used by the NodeManager to YARN Applications. If you use the CredentialProvider feature to encrypt passwords used in NodeManager configs, it may be possible for any Container launched by that NodeManager to gain access to the encryption password. The other passwords themselves are not directly exposed. http://mail-archives.apache.org/mod_mbox/hadoop-general/201701.mbox/%3C0ed32746-5a53-9051-5877-2b1abd88beb6%40apache.org%3E
  10. 10. 10 sensitiveな情報を保存するための、Hadoopの機能 例: Hadoopで実行するジョブでS3にアクセスする  AWS(IAM)のaccess key/secret keyが必要  core-site.xmlに記載するのが最もシンプル  ただし、ジョブの設定に残るため、HistoryServerから keyが見えてしまう こういった問題を避けたい場合に利用する Credential Providerとは
  11. 11. 11 HDFSの/user/ajisakaa/s3.jceksに情報を保存 S3を利用するDistCpの実行 Credential Providerを利用してS3にアクセスする $ hadoop credential create s3a.access.key -value 123 -provider jceks://hdfs@nn1.example.com/user/ajisaka/s3.jceks $ hadoop credential create s3a.secret.key -value 456 -provider jceks://hdfs@nn1.example.com/user/ajisaka/s3.jceks $ hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@nn1.exampl e.com/user/ajisaka/s3.jceks /user/ajisaka/backup/ s3a://ajisaka- backup/
  12. 12. 12 jceksファイル: Java keystoreの実装  暗号化されているが、keystoreのパスワードが判明すれば ツールで読み書き可能  keystoreのパスワードは設定しなくてもよい  keystoreへのアクセス制御がなされていれば問題ない  パスワードを設定する場合、以下のいずれかの方法で Hadoopクラスタ内でパスワードを共有・同期する  環境変数HADOOP_CREDSTORE_PASSWORDに記載  password fileを利用 Credential Providerの設定
  13. 13. 13 通常の設定の取得 (Configuration.java) keystoreに保存した設定の取得 (Configuration.java) S3AFileSystemの場合 (S3AUtils#getAWSAccessKeys) keystoreに保存した設定の取得 public String get(String name) { public char[] getPassword(String name) throws IOException { String accesskey = getPassword(c, ACCESS_KEY, login.getUser()); String secretKey = getPassword(c, SECRET_KEY, login.getPassword());
  14. 14. 14 HDFS イラストでわかる攻撃手法 (1/3) NodeManager YARN container YARN Applicationを起動 Keystore
  15. 15. 15 HDFS イラストでわかる攻撃手法 (2/3) NodeManager YARN container containerの環境変数 HADOOP_CREDSTORE_ PASSWORDを取得 → NodeManagerの 環境変数と一致 Keystore
  16. 16. 16 HDFS イラストでわかる攻撃手法 (3/3) NodeManager YARN container Keystoreへのアクセス 制御が充分でない場合、 手に入れた環境変数 をパスワードとして Keystoreにアクセス可能 Keystore
  17. 17. 17 以下の全項目を満たす場合のみ、攻撃可能  2.6.0~2.6.4, 2.7.0~2.7.2のいずれかを利用  Credential Providerを利用  NodeManagerの環境変数 HADOOP_CREDSTORE_PASSWORDにkeystoreのパスワー ドを設定  NodeManagerが利用するkeystoreが攻撃者から読み取れ る状態になっている Kerberos認証はもちろん有効ですよね? 攻撃成功の必要十分条件
  18. 18. 18 Shell.java YARN containerがNodeManagerの環境変数を引き継がない ように、環境変数を消去する 脆弱性修正の方針 + // Remove all env vars from the Builder to prevent + // leaking of env vars from the parent process. + if (!inheritParentEnv) { + builder.environment().clear(); + }
  19. 19. 19 HDFS イラストでわかる攻撃手法 (2/3) (脆弱性修正後) NodeManager YARN container containerの環境変数 HADOOP_CREDSTORE_ PASSWORDを取得 → NodeManagerの 環境変数と一致しない Keystore
  20. 20. 20 本修正のコミットログ 通常のコミットには、JIRAのissue idが記載されている 脆弱性修正のコミットには、対応するJIRAがない commit 9d4d30243b0fc9630da51a2c17b543ef671d035c Author: Robert Kanter <rkanter@apache.org> Date: Thu Apr 28 19:24:38 2016 -0700 Remove parent's env vars from child processes commit 07694fc65ae6d97a430a7dd67a6277e5795c321f Author: Akira Ajisaka <aajisaka@apache.org> Date: Wed Aug 9 13:20:03 2017 +0900 HADOOP-14355. Update maven-war-plugin to 3.1.0.
  21. 21. 21 ASF Project Security for Committers https://www.apache.org/security/committers.html 脆弱性の修正と悟られないようにしている 9. The project team agrees the fix on their private list. 12. The project team commits the fix. No reference should be made to the commit being related to a security vulnerability.
  22. 22. 22 ASF Project Security for Committers https://www.apache.org/security/committers.html 脆弱性の公表は、修正されたリリースが出た後 15.The project team announces the vulnerability. The vulnerability announcement should be sent after, or at the same time as, the release announcement to the following destinations: a. the same destinations as the release announcement b. the vulnerability reporter c. the project's security list *snip*
  23. 23. 23 CVEの公表
  24. 24. 24 修正後、3系でMapReduceジョブが失敗するようになった 2016-12-02 04:54:52,413 INFO mapreduce.Job: Job job_1480654443168_0001 failed with state FAILED due to: Application application_1480654443168_0001 failed 2 times due to AM Container for appattempt_1480654443168_0001_000002 exited with exitCode: 1 Failing this attempt.Diagnostics: Exception from container-launch. Container id: container_1480654443168_0001_02_000001 Exit code: 1 Stack trace: ExitCodeException exitCode=1: at org.apache.hadoop.util.Shell.runCommand(Shell.java:974) at org.apache.hadoop.util.Shell.run(Shell.java:878) at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.jav a:1172) (snip)
  25. 25. 25 YARNコンテナが利用可能なNodeManagerの環境変数一覧に 赤字の部分を追加 MAPREDUCE-6704で、これがドキュメント化された MapReduceジョブを実行するためには追加設定が必要 <property name="yarn.nodemanager.env-whitelist" value="="JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HAD OOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME, HADOOP_MAPRED_HOME"/>
  26. 26. 26 MAPREDUCE-6704での議論を抜粋  *snip* since its a mapreduce property its not correct to add to the whitelist to yarn.  Who cares? It's all Apache Hadoop. Users have an expectation that this stuff will work out of the box and be consistent. *snip*  There was pushback to remove it because of the desire to keep Yarn and MR separate. 補足: HADOOP_MAPRED_HOMEの追加がデフォルトにならない理由
  27. 27. 27 2系では、HADOOP_CREDSTORE_PASSWORDのみ消去  そのため、3系のようにMapReduceを動作させるための追加 設定は不要 2系では互換性を考慮した修正がなされている + // Remove all env vars from the Builder to prevent + // leaking of env vars from the parent process. + if (!inheritParentEnv) { + // branch-2: Only do this for HADOOP_CREDSTORE_PASSWORD + // (snip) + builder.environment().remove( + AbstractJavaKeyStoreProvider.CREDENTIAL_PASSWORD_NAME); + }
  28. 28. 28 技術的に面白く、世の中に情報が出ていない話を2つ紹介  YARN NodeManagerの脆弱性について  脆弱性修正の裏側を話せる範囲で紹介  先進的研究成果の取り込みについて  Hitchiker erasure codingの紹介 今回は技術的に面白い話がしたい
  29. 29. 29 http://www.cs.cmu.edu/~nihars/publications/Hitchhiker_SIGCOMM14.pdf この論文を紹介します
  30. 30. 30 本論文のサマリ Erasure Codingでは、data blockの欠損を復旧するために必要 なデータ量が多い  RS(10,4)の場合、必要なデータは欠損したデータの10倍 この問題を回避するため、以下の3手法を提案  Hitchhiker-XOR  Hitchhiker-XOR+  Hitchhiker-nonXOR 復旧に必要なデータ量を35%削減 今回はApache Hadoopで実装されているHitchhiker-XORを紹介
  31. 31. 31 Erasure Codingとは (簡単に)  データをk個のdata unitに分割し、r個のparity unitを生成  k+r個のunitのうち、任意のk個からデータを復旧可能  parity生成にはReed-Solomon(RS)がよく利用される  RS(k=10,r=4)の場合、実データの1.4倍のディスク消費  HDFSの通常の3-replicationなら3倍 unit 1 unit 2 unit 3 unit 4 unit 5 unit 6 unit 7 unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14
  32. 32. 32 Erasure Codingでの障害復旧における課題 例: unit 6故障時の復旧パターン unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14
  33. 33. 33 Erasure Codingでの障害復旧における課題 例: unit 6故障時の復旧パターン 任意の10 unitのデータを取得 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 10 unit 12 unit 14
  34. 34. 34 例: unit 6故障時の復旧パターン 任意の10 unitのデータを取得 unit 6を生成 Erasure Codingでの障害復旧における課題 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 10 unit 12 unit 14 unit 6
  35. 35. 35 例: unit 6故障時の復旧パターン 任意の10 unitのデータを取得 unit 6を生成 Erasure Codingでの障害復旧における課題 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14 unit 1 unit 2 unit 3 unit 4 unit 5 unit 7 unit 8 unit 10 unit 12 unit 14 unit 6 失ったデータの10倍の データを読み込む必要がある! (ディスク、NWに負荷)
  36. 36. 36 Hitchhiker-XOR 通常のRSに一工夫加える a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) f3(a) f3(b) f4(a) f4(b) 1 byte 1 byte unit 1 unit 10 unit 11 unit 12 unit 13 unit 14 ... a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 1 byte 1 byte RS (10, 4) Hitchhiker-XOR for RS (10, 4) 元データ(a1, a2, ... , a10, b1, b2, ... , b10)
  37. 37. 37 Hitchhiker-XORでの障害復旧 例: unit 1の故障 unit 1 unit 10 unit 11 unit 12 unit 13 unit 14 ... a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 1 byte 1 byte
  38. 38. 38 Hitchhiker-XORでの障害復旧 例: unit 1の故障 b2~b10, f1(b)から b1を復旧 unit 1 unit 10 unit 11 unit 12 unit 13 unit 14 ... a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 1 byte 1 byte read read read
  39. 39. 39 Hitchhiker-XORでの障害復旧 例: unit 1の故障 b2~b10, f1(b)から b1を復旧 b1~b10, f2(b)⊕a1⊕a2⊕a3, a2, a3から a1を復旧 unit 1 unit 10 unit 11 unit 12 unit 13 unit 14 ... a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 1 byte 1 byte read read read read a2, a3のみread
  40. 40. 40 Hitchhiker-XORでの障害復旧 例: unit 1の故障 b2~b10, f1(b)から b1を復旧 b1~b10, f2(b)⊕a1⊕a2⊕a3, a2, a3から a1を復旧 unit 1 unit 10 unit 11 unit 12 unit 13 unit 14 ... a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 1 byte 1 byte read read read read a2, a3のみread 2bytesの復旧に13bytesで充分 RS(10, 4)だと20bytesなので、 35%のデータを削減
  41. 41. 41 Hitchhiker-XORの短所 単一障害に特化している  2重障害の場合、復旧に必要なデータを削減できない  Facebookによると、98.08%は単一障害なので問題はない unit 7~10を復旧する場合、13ではなく14bytes必要  これを13にするため、Hitchhiker-XOR+やnonXORがある  詳しくは論文を読もう  Apache Hadoopには現状実装されていない unit 11~14を復旧する場合、20bytes必要  仕方ない。諦める
  42. 42. 42 "Hop-and-Couple": ディスクI/O効率を高める工夫 単純に並べていくのは非効率 a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 c1 d1 ... ... c10 d10 f1(c) f1(d) f2(c) f2(d) ⊕ c1 ⊕ c2 ⊕ c3 f3(c) f3(d) ⊕ c4 ⊕ c5 ⊕ c6 f4(c) f4(d) ⊕ c7 ⊕ c8 ⊕ c9 ⊕ c10
  43. 43. 43 "Hop-and-Couple": ディスクI/O効率を高める工夫 単純に並べていくのは非効率  復旧時に1byteおきに読み込む必要がある a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3 f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6 f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 c1 d1 ... ... c10 d10 f1(c) f1(d) f2(c) f2(d) ⊕ c1 ⊕ c2 ⊕ c3 f3(c) f3(d) ⊕ c4 ⊕ c5 ⊕ c6 f4(c) f4(d) ⊕ c7 ⊕ c8 ⊕ c9 ⊕ c10
  44. 44. 44 "Hop-and-Couple": ディスクI/O効率を高める工夫 シーケンシャルI/Oになるよう並べ替える  下図は2byteおきだが、実際はもっと大きい値にする a1 b1 ... ... a10 b10 f1(a) f1(b) f2(a) f2(b) f3(a) f3(b) f4(a) f4(b) c1 d1 ... ... c10 d10 f1(c) f1(d) f2(c) ⊕ a1 ⊕ a2 ⊕ a3 f2(d) ⊕ b1 ⊕ b2 ⊕ b3 f3(c) ⊕ a4 ⊕ a5 ⊕ a6 f3(d) ⊕ b4 ⊕ b5 ⊕ b6 f4(c) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 f4(d) ⊕ b7 ⊕ b8 ⊕ b9 ⊕ b10
  45. 45. 45 数値実験の結果と考察 RSに比べ、エンコードは遅いが再構築は速い  エンコード時間はおよそ72%増加  単一障害時の再構築時間はおよそ35%減少 再構築の速度のほうが重視されるべき  エンコード処理は1回きり、バックグラウンドで実行可  再構築は何回でも起こる、読み込みのレイテンシに影響 ただし、この値をうのみにしてはいけない  論文の実装とApache Hadoopの実装が同じとは限らない  本当の値を知るには自分で試すべし
  46. 46. 46 今回のまとめ YARN NodeManagerの脆弱性について  脆弱性の修正および報告もコミッタおよびPMCの仕事  本件の報告は私が担当 先進的研究成果の取り込みについて  Hitchhiker-XOR以外でも、研究成果が次々と実装されている  Mercury(USENIX 2015): YARN-2877で実装済  Copysets(USENIX 2013): Ozone(HDFS-7240)で実装予定  ソースコードだけではなく、論文を読むことも時として必要 Hadoop 3.1の話(特にOzone)については、次のソースコードリー ディングなどで紹介したい
  47. 47. Copyright © 2017 NTT DATA Corporation お問い合わせ先: 株式会社NTTデータ システム技術本部 OSSプロフェッショナルサービス URL: https://oss.nttdata.com/ メール: hadoop@kits.nttdata.co.jp TEL: 050-5546-9000
  48. 48. 48© 2017 NTT DATA Corporation 本資料中に記載されている会社名、商品名、ロゴは、各社の商標または登録商標です。

×