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.

最新版Hadoopクラスタを運用して得られたもの

2,468 views

Published on

2017/9/22(金) 開催
サイバーエージェントのデータ分析基盤とデータ活用およびそれらの技術についての勉強会「Data Engineering and Data Analysis Workshop #2」

Published in: Data & Analytics
  • Be the first to comment

最新版Hadoopクラスタを運用して得られたもの

  1. 1. 最新版Hadoopクラスタを運用して得られたも の 2017 Sep 22 CyberAgent, Inc. All Rights Reserved
  2. 2. 梅田 永介 ● 2012年6月入社 ● 技術本部 秋葉原ラボ所属 ● データ解析基盤Patriotの開発・運用 ● 量産型Hadoop/HBaseクラスタの運用 ● HBase徹底入門の執筆 自己紹介
  3. 3. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  4. 4. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  5. 5. ● Hadoopベースのデータ解析基盤 ○ HDFS, YARN, Hive, HBase, Flume, Spark, etc ○ Apache Bigtopで内製化したパッケージを使用 ● メディアサービスのデータを集約 ○ 2.5 PB / 3.0 PB (3 replica) ■ 5〜7 TB / day ○ 約700テーブル、12,000,000パーティション ○ 6000スケジュールジョブ + アドホックジョブ データ解析基盤Patriot
  6. 6. リアルタイム処理基盤 システム構成 Patriot MySQL etc... 機械学習基盤 HTTP API / WebUI データ 転送管理 Flume
  7. 7. ● Hadoop 2.7.3 + patch → 2.8.1 + patch ● Zookeeper 3.4.6 ● HBase 1.3.0 → 1.3.1 + patch ● Hive 2.1.1 + patch (ORC関連のpatch追加) ● Tez 0.8.4 ● Flume 1.8.0 (trunk) + patch ● Spark 2.1.0 + patch ● Presto 0.179 + patch (kafka対応追加) ● Presto YARN 1.5 ● Slider 0.92.0 ● Kafka 0.11.0 現在利用中のパッケージ Presto YARNのために追加
  8. 8. ● Hadoop ○ HADOOP-12366 : expose calculated paths ○ HADOOP-11628 : SPNEGO auth does not work with CNAMEs in JDK8 ● HBase ○ HBASE-18000 : Make sure we always return the scanner id with ScanResponse ← NEW !!! ● Flume ○ FLUME-3026 : Add Kafka 0.10 support for Flume ○ FLUME-3065 : Enable multiple monitoring types ○ FLUME-3100 : Support arbitrary header substitution for topic of Kafka ● Spark ○ SPARK-14958 : Failed task hangs if error is encountered when getting task result 適用しているパッチ
  9. 9. ● Hive ○ HIVE-14029 : Update Spark version to 2.0.0 ○ HIVE-14999 : SparkClientUtilities does not support viewFS ○ HIVE-15101 : Spark client process can be stuck when UNHEALTHY NodeManager exists ○ HIVE-15237 : Propagate Spark job failure to Hive ○ HIVE-15239 : hive on spark combine equivalent work get wrong result because of TS operation compare ○ HIVE-15513 : GroupByOperator should initialize GenericUDAFEvaluator before AggregationBuffer (recurrence of HIVE-697) ○ HIVE-15580 : Eliminate unbounded memory usage for orderBy and groupBy in Hive on Spark ○ HIVE-16402 : Upgrade to Hadoop 2.8.0 ○ HIVE-15178 : ORC stripe merge may produce many MR jobs and no merge if split size is small ← NEW!!! 適用しているパッチ
  10. 10. ● Presto ○ https://github.com/prestodb/presto/pull/8394 Support connecting to Kerberos secured Kafka #7990, updated to Kafka 0.10.1.2 ← NEW!!! 適用しているパッチ
  11. 11. ● Masterサーバ (Namenode, ResourceManager, etc) ○ 24 CPU core, 64 GB RAM, 2TB (RAID10) ○ 6 ノード ● Slaveサーバ (Datanode, NodeManger, etc) ○ 56 CPU core, 256 GB RAM, 6TB x 12 disks ○ 48 ノード(増設予定) ● Kafkaサーバ ○ 16 CPU core, 32 GB RAM, 3TB (RAID10) ○ 9 ノード ハードウェア
  12. 12. ● 構成管理 ○ AnsibleでInventoryを環境ごとに用意 ● 監視・モニタリング ○ Sensu, Grafana/OpenTSDB ■ HBaseにモニタリングデータも集約 ○ Kafka Manager ○ Burrow 構成管理、監視・モニタリングなど
  13. 13. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  14. 14. ● メリット ○ 最新のバージョンをいち早く使うことができる ○ ベンダーが提供しているディストリビューションよりもパッチが当て やすい ■ ベンダー各社はいろいろなパッチを独自に当てているため、 JIRAに投稿されているパッチを当てるの難しい場合がある 運用してみて感じたメリット・デメリット
  15. 15. ● デメリット ○ Cloudera ManagerやApache Ambariなどの管理ツールを使うこ とができないため手間がかかる ■ 特にローリングアップグレードやローリングリスタート ■ 本番環境でコマンド打つのは精神的に疲れる 運用してみて感じたメリット・デメリット
  16. 16. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  17. 17. ● カーネルパニック多発 ● DataNodeのアップグレードでOOM発生 ● DataNodeのアップグレードが中途半端に終わる ● Zookeeperに再接続できない 事例紹介
  18. 18. ● 事象 ○ 本番環境の運用開始後、1日に1台(多いときで3台)slaveサーバ がカーネルパニックを起こしていた ○ 同じサーバが連続してカーネルパニックを起こすことは無かった カーネルパニック多発
  19. 19. ● 調査 ○ コンソールログを手掛かりに調査を実施し、YARNのJIRAでカー ネルパニックに関連しそうなチケットを発見 ■ https://issues.apache.org/jira/browse/YARN-5040 ● 大規模なジョブを実行するとカーネルパニックが発生する ● カーネルのバージョンを4.8.1にアップデートしたら改善したとい う人もいた ■ https://issues.apache.org/jira/browse/YARN-4382 ● コンテナのプロセスをkillするのが設定値 (yarn.nodemanager.linux-container-executor.cgroups.delete-delay-ms)より も遅れるとcgroupsのディレクトリを消せなくなる ● cgroupsのディレクトリが増えすぎるとCPUビジーになる カーネルパニック多発
  20. 20. ● 補足 ○ cgroups ■ タスクをグループ化し、そのグループに対してCPU、システム メモリ、ネットワークなどのリソース制限をかけたりすることが できる ■ 階層的に構成されている ● 構成はcgroupsfs上のディレクトリツリーで表される ■ サブシステムと呼ばれる機能でリソースを扱う ● サブシステムにはcpu(cpuのスケジューリング)、cpuacct(cpuリ ソースについての自動レポートの生成)、memory(メモリに対す る制限や自動レポートの生成)などがある カーネルパニック多発
  21. 21. ● 補足 ○ YARNとcgroups ■ YARNでは厳密なCPUリソース制限を行う場合、cgroupsを 用いる ■ YARNでcgroupsを用いる設定にした場合のcgroupsのディ レクトリ構成例(OSのバージョンによって異なる) カーネルパニック多発 cgroup └ cpu └ yarn ├ コンテナ1 ├ コンテナ2 ├ コンテナ3 └ コンテナ4 ←実行が完了すると削除される
  22. 22. ● 調査 ○ NodeManagerのログを見てみると ○ /cgroup/cpu/yarn/ の下にできたディレクトリを定期的にカウント → 徐々に数が増えていっている ○ YARN-4382の事象と似ている カーネルパニック多発 WARN util.CgroupsLCEResourcesHandler: Unable to delete cgroup at: /cgroup/cpu/yarn/container_e59_1505389468296_48619_01_000176, tried to delete for 1000ms
  23. 23. ● 対応 ○ cgroupsのディレクトリ削除のタイミングを変更 ■ yarn.nodemanager.linux-container-executor.cgroups.dele te-timeout-msを10000msに変更(デフォルトは1000ms) ● JIRAのチケットでは yarn.nodemanager.linux-container-executor.cgroups.delete -delay-msについて触れていたが、ソースコードを読む限りは delete-timeout-msを調整したほうがいいと判断した ○ 念のため/cgroup/cpu/yarn/ の下にできたディレクトリ のうち、更新日付から1日経過したものを削除するよう にcronを設定 カーネルパニック多発
  24. 24. ● 事象 ○ Hadoop2.7.3 → Hadoop2.8.1へのローリングアップグレードを実 施 ■ おおまかな手順 ● ローリングアップグレードのprepare ○ ロールバック用のfsimage作成 ● NameNodeのアップグレード ● DataNodeのアップグレード ● ローリングアップグレードのfinalize ■ 詳細な手順 ● https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/Hdf sRollingUpgrade.html DataNodeのアップグレードでOOM発生
  25. 25. ● 事象 ○ Hadoop2.8.0からDataNodeのストレージレイアウトが変更されて いるため、DataNodeをアップグレードした後に起動すると自動的 にストレージレイアウトがアップデートされる ○ ステージング環境でアップグレード検証 ■ NameNodeのアップグレードまでは順調 ■ DataNodeのアップグレードでOOM発生 DataNodeのアップグレードでOOM発生
  26. 26. ● 調査 ○ HDFSのJIRAのチケットに類似事象の報告が無いか検索し、類 似の事象を発見 ■ https://issues.apache.org/jira/browse/HDFS-9536 ● HDFS-8578の影響でメモリを多大に消費している可能性あり ■ https://issues.apache.org/jira/browse/HDFS-8578 ● これまでDataNodeのストレージレイアウトのアップグレードは ストレージを順次処理していたため、時間がかかっていた ● ストレージを並列に処理することで大幅な処理時間の改善を実 現するという素晴らしいチケット DataNodeのアップグレードでOOM発生
  27. 27. ● 対応 ○ DataNodeのアップグレード時は一時的にヒープサイズを大きくす ることにした ■ 4GB → 16GB ○ 再度ステージング環境で再度検証を行った結果、無事アップグ レードを完了することができた DataNodeのアップグレードでOOM発生
  28. 28. ● 事象 ○ Hadoop2.7.3 → Hadoop2.8.1へのローリングアップグレードを実 施 ○ NameNodeのアップグレードまでは順調 DataNodeのストレージレイアウトのアップデートが中途半端 に終わる
  29. 29. ● 事象 ○ DataNodeのアップグレード ■ 恐る恐る一台目をアップグレード ■ 普通に立ち上がってきたが、hdfsのログをtailしてたコンソー ルに一瞬スタックトレースが表示された ■ HDFSのログを確認したところ、ものすごく怪しいログが出いていた ● 「Failed to analyze storage directories for block pool ブロッ クプール名」→ アップデートできてなさそう ● 「loadBlockPoolSliceStorage: 7 upgrade tasks」→ ストレージ は12本あるので12タスク動くはず DataNodeのストレージレイアウトのアップデートが中途半端 に終わる
  30. 30. ● 実験 ○ リトライされるかもしれないので数分待ってみた ■ リトライされる様子なし ○ DataNodeを再起動(1台死亡してもなんとかなるので) ■ 「loadBlockPoolSliceStorage: 5 upgrade tasks」が出力されていた ■ 初回の起動で失敗したとしても、再起動すればリトライされることが 判明 DataNodeのストレージレイアウトのアップデートが中途半端 に終わる
  31. 31. ● 対応 ○ DataNodeのストレージアップデートのログを確認し、全てのスト レージがアップデートされたのを見届けてから次のDataNodeの アップグレードを行うようにした DataNodeのストレージレイアウトのアップデートが中途半端 に終わる
  32. 32. ● 事象 ○ Zookeeperサーバの1台を再作成した ■ サーバの起動までに時間がかかってしまい、DNSキャッシュ サーバから該当ホストの情報が落ちてしまった ■ サーバ起動前にDNSにアクセスがあり、ネガティブキャッシュ が残ってしまった ○ その後、Zookeeper Client(Apache Curator)を使っているソフト ウェアがZookeeprに再接続できなくなった ○ Zookeeperに常時接続しているもの(HBaseなど)には影響が無 かった Zookeeperに再接続できない
  33. 33. ● 調査 ○ https://issues.apache.org/jira/browse/ZOOKEEPE R-1576 ■ Zookeeperのアンサンブルに指定されたサーバのうち一台で もUnknownHostExceptionになってしまうとZookeeperに接 続できなくなる ■ Zookeeperのアンサンブルに、実在しないホスト名を記述し ても同様の事象が発生するため注意が必要 ■ 3.5系では修正されている Zookeeperに再接続できない
  34. 34. ● 対応 ○ ネガティブキャッシュが消えた後、Zookeeprに再接続 できなかったプロセスを再起動 ○ Zookeeperサーバを作り直す際は、念のため /etc/hostsにZookeeperサーバの情報を記述するよう にした Zookeeperに再接続できない
  35. 35. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  36. 36. ● Presto YARNの導入 ○ Presto on YARN/Slider ● ファイルフォーマット変換 ○ SequenceFile → ORC ○ 順次変換中 今回紹介しなかった取り組み
  37. 37. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み 本日の内容
  38. 38. ● サーバOSの変更 ○ CentOS6.8 → Ubuntu16.04 ○ CentOSだとソフトウェアのバージョンが全体的に古い ■ gitのバージョンが低くてBigtop1.2が動かなかった ○ カーネルのトレーシング周りはUbuntuのほうが良さそう ● Hadoopクラスタ管理ツールの開発 ○ 各プロセスの開始・停止、ローリングリスタート、ローリングアップ グレードなどの手作業をなくす ● Zookeeperのアップグレードの検討 ○ 3.4系にはバグがあるので3.5系に 現在の取り組み

×