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

2. 梅田　永介 ● 2012年6月入社 ● 技術本部　秋葉原ラボ所属 ● データ解析基盤Patriotの開発・運用 ● 量産型Hadoop/HBaseクラスタの運用 ● HBase徹底入門の執筆自己紹介

3. ● データ解析基盤Patriotのご紹介 ● 運用してみて感じたメリット・デメリット ● 事例紹介 ● 今回紹介しなかった取り組み ● 現在の取り組み本日の内容

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. リアルタイム処理基盤システム構成 Patriot MySQL etc... 機械学習基盤 HTTP API / WebUI データ転送管理 Flume

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. ● 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. ● 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. ● Presto ○ https://github.com/prestodb/presto/pull/8394 Support connecting to Kerberos secured Kafka #7990, updated to Kafka 0.10.1.2 ← NEW!!! 適用しているパッチ

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. ● 構成管理 ○ AnsibleでInventoryを環境ごとに用意 ● 監視・モニタリング ○ Sensu, Grafana/OpenTSDB ■ HBaseにモニタリングデータも集約 ○ Kafka Manager ○ Burrow 構成管理、監視・モニタリングなど

14. ● メリット ○ 最新のバージョンをいち早く使うことができる ○ ベンダーが提供しているディストリビューションよりもパッチが当てやすい ■ ベンダー各社はいろいろなパッチを独自に当てているため、 JIRAに投稿されているパッチを当てるの難しい場合がある運用してみて感じたメリット・デメリット

15. ● デメリット ○ Cloudera ManagerやApache Ambariなどの管理ツールを使うことができないため手間がかかる ■ 特にローリングアップグレードやローリングリスタート ■ 本番環境でコマンド打つのは精神的に疲れる運用してみて感じたメリット・デメリット

17. ● カーネルパニック多発 ● DataNodeのアップグレードでOOM発生 ● DataNodeのアップグレードが中途半端に終わる ● Zookeeperに再接続できない事例紹介

18. ● 事象 ○ 本番環境の運用開始後、1日に1台(多いときで3台)slaveサーバがカーネルパニックを起こしていた ○ 同じサーバが連続してカーネルパニックを起こすことは無かったカーネルパニック多発

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. ● 補足 ○ cgroups ■ タスクをグループ化し、そのグループに対してCPU、システムメモリ、ネットワークなどのリソース制限をかけたりすることができる ■ 階層的に構成されている ● 構成はcgroupsfs上のディレクトリツリーで表される ■ サブシステムと呼ばれる機能でリソースを扱う ● サブシステムにはcpu(cpuのスケジューリング)、cpuacct(cpuリソースについての自動レポートの生成)、memory(メモリに対する制限や自動レポートの生成)などがあるカーネルパニック多発

21. ● 補足 ○ YARNとcgroups ■ YARNでは厳密なCPUリソース制限を行う場合、cgroupsを用いる ■ YARNでcgroupsを用いる設定にした場合のcgroupsのディレクトリ構成例(OSのバージョンによって異なる) カーネルパニック多発 cgroup └ cpu └ yarn ├ コンテナ1 ├ コンテナ2 ├ コンテナ3 └ コンテナ4 ←実行が完了すると削除される

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. ● 対応 ○ 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. ● 事象 ○ 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. ● 事象 ○ Hadoop2.8.0からDataNodeのストレージレイアウトが変更されているため、DataNodeをアップグレードした後に起動すると自動的にストレージレイアウトがアップデートされる ○ ステージング環境でアップグレード検証 ■ NameNodeのアップグレードまでは順調 ■ DataNodeのアップグレードでOOM発生 DataNodeのアップグレードでOOM発生

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. ● 対応 ○ DataNodeのアップグレード時は一時的にヒープサイズを大きくすることにした ■ 4GB → 16GB ○ 再度ステージング環境で再度検証を行った結果、無事アップグレードを完了することができた DataNodeのアップグレードでOOM発生

28. ● 事象 ○ Hadoop2.7.3 → Hadoop2.8.1へのローリングアップグレードを実施 ○ NameNodeのアップグレードまでは順調 DataNodeのストレージレイアウトのアップデートが中途半端に終わる

29. ● 事象 ○ DataNodeのアップグレード ■ 恐る恐る一台目をアップグレード ■ 普通に立ち上がってきたが、hdfsのログをtailしてたコンソールに一瞬スタックトレースが表示された ■ HDFSのログを確認したところ、ものすごく怪しいログが出いていた ● 「Failed to analyze storage directories for block pool ブロックプール名」→ アップデートできてなさそう ● 「loadBlockPoolSliceStorage: 7 upgrade tasks」→ ストレージは12本あるので12タスク動くはず DataNodeのストレージレイアウトのアップデートが中途半端に終わる

30. ● 実験 ○ リトライされるかもしれないので数分待ってみた ■ リトライされる様子なし ○ DataNodeを再起動(1台死亡してもなんとかなるので) ■ 「loadBlockPoolSliceStorage: 5 upgrade tasks」が出力されていた ■ 初回の起動で失敗したとしても、再起動すればリトライされることが判明 DataNodeのストレージレイアウトのアップデートが中途半端に終わる

31. ● 対応 ○ DataNodeのストレージアップデートのログを確認し、全てのストレージがアップデートされたのを見届けてから次のDataNodeのアップグレードを行うようにした DataNodeのストレージレイアウトのアップデートが中途半端に終わる

32. ● 事象 ○ Zookeeperサーバの1台を再作成した ■ サーバの起動までに時間がかかってしまい、DNSキャッシュサーバから該当ホストの情報が落ちてしまった ■ サーバ起動前にDNSにアクセスがあり、ネガティブキャッシュが残ってしまった ○ その後、Zookeeper Client(Apache Curator)を使っているソフトウェアがZookeeprに再接続できなくなった ○ Zookeeperに常時接続しているもの(HBaseなど)には影響が無かった Zookeeperに再接続できない

33. ● 調査 ○ https://issues.apache.org/jira/browse/ZOOKEEPE R-1576 ■ Zookeeperのアンサンブルに指定されたサーバのうち一台でもUnknownHostExceptionになってしまうとZookeeperに接続できなくなる ■ Zookeeperのアンサンブルに、実在しないホスト名を記述しても同様の事象が発生するため注意が必要 ■ 3.5系では修正されている Zookeeperに再接続できない

34. ● 対応 ○ ネガティブキャッシュが消えた後、Zookeeprに再接続できなかったプロセスを再起動 ○ Zookeeperサーバを作り直す際は、念のため /etc/hostsにZookeeperサーバの情報を記述するようにした Zookeeperに再接続できない

36. ● Presto YARNの導入 ○ Presto on YARN/Slider ● ファイルフォーマット変換 ○ SequenceFile → ORC ○ 順次変換中今回紹介しなかった取り組み

38. ● サーバOSの変更 ○ CentOS6.8 → Ubuntu16.04 ○ CentOSだとソフトウェアのバージョンが全体的に古い ■ gitのバージョンが低くてBigtop1.2が動かなかった ○ カーネルのトレーシング周りはUbuntuのほうが良さそう ● Hadoopクラスタ管理ツールの開発 ○ 各プロセスの開始・停止、ローリングリスタート、ローリングアップグレードなどの手作業をなくす ● Zookeeperのアップグレードの検討 ○ 3.4系にはバグがあるので3.5系に現在の取り組み

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

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

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

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

Similar a 最新版Hadoopクラスタを運用して得られたもの(20)

Mais de cyberagent

Mais de cyberagent(20)

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