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

1. 最新版Hadoopクラスタを運用して得られたも
の
2017 Sep 22
CyberAgent, Inc. All Rights Reserved

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

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

4. ● データ解析基盤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
構成管理、監視・モニタリングなど

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

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

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

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

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に再接続できない

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

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

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

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