マルチテナント Hadoop クラスタのための
モニタリング Best Practice
Mar 14, 2019
Tomomichi Hirano
Hadoop Platform Team
Cloud Platform Department
Rakuten, Inc.

2
Who am I ?
• 平野 智巌 （tomomichi.Hirano@rakuten.com）
• 2013年 楽天 入社、Server Provisioning Team に Join
• 2014年 Hadoop Administrator Team に Join
• 2019年 Hadoop Admin として5年目
• My Career
• Hadoop Admin
• DBMS、Server/OS/HW、HPC、etc.

3
楽天 Hadoop
Analysis
Output
Input
店舗情報
購入情報商品情報
アクセスログ/行動ログ
メンバーシップ情報
（楽天会員情報）
Index for 商品検索 / Suggest
店舗様向けレポート
Recommend
広告
マーケティング
ターゲティング
プラニング
サイト・デザイン
KPI マネージメント
データマート
DWH
DBMS

4
楽天 Hadoop の Spec
• クラスタサイズ
• # of slaves : 約 420 台
• HDFS capacity : 約 30 PB
• # of jobs per day : 70,000 - 80,000
• # of hadoop active user accounts : around 80
• Types of jobs : MR, Hive, Tez, Spark, Spark ML, Pig, sqoop, HBase, Slider, etc.
• Hadoop クラスタ数
• # of Production cluster (worldwide) : 4
• Some clusters for Staging and development

5
楽天 Hadoop の 特徴
• Large クラスタ / マルチテナント
• 600+ Hadoop アカウント、7万+ ジョブ...
• 細かなチェックやコントロールをしていない（できない）状態。
• Speed & Self-Service
• ユーザの開発スピードを落としたくないので、Self-Service を目指している。
• 基本は、Free ride、Free use。

6
楽天 Hadoop Admin Team の 特徴
• Role and Responsibility
• Hadoop ジョブ開発以外のすべて
• クラスタ運用（ノード追加/削除、ユーザ追加、ディスク交換など）
• クラスタのモニタリング、チューニング
• 新機能の検証、導入
• クラスタのトラブル・シューティング、原因調査
• ユーザ・サポート（QA対応、ジョブのトラブル・シューティングのサポート）
• Small Hadoop Admin Team
• 専任 2名、兼任 1名、マネージャ
• No Partner、No Support

7
なぜ モニタリング が クリティカル であるのか? （Before モニタリング）
• Large クラスタ / マルチテナント
• 問題であるのか、問題でないのかが判別できない...
• クラスタの問題であるのか、ジョブの問題であるのかがわからない...
• Speed & Self-Service
• ユーザは、Hadoop Admin Team に聞かないと、クラスタの状況がわからない...
• Small Hadoop Admin Team
• いろいろな UI や Ganglia グラフなどいろいろ確認しないと状況がわからない...
• ユーザへ説明するために情報を整理するために時間がかかった...

8
なぜ モニタリング がクリティカルであるのか? （After モニタリング）
• Large クラスタ / マルチテナント
• 問題か、問題でないかがわかる（ことがある）!!!
• クラスタの問題であるか、ユーザの問題であるかがわかる（ことがある）!!!
• Speed & Self-Service
• ユーザは、Hadoop Admin への問い合わせなしで、即座に状況を確認できる!!!
• Small Hadoop Admin Team
• 重要なグラフを集めたダッシュボードをみることで短時間で問題を把握できる!!!
• ユーザは自分でクラスタの状況を確認できるので、問い合わせ自体が減る!!!
• グラフを共有するだけで、ユーザに状況を説明できる!!!

9
今日のアジェンダ
“マルチテナント Hadoop クラスタのためのモニタリング Best Practice”
1. グラフの作り方
2. 最重要ダッシュボートにあるグラフを事例とともに紹介
• Tips: Slave ノードでの SSD 活用
3. マルチテナント特有のその他ダッシュボードを紹介
• Tips: HDFS small file 問題への対応
• この資料は公開します!

10
1. How to create graphs

11
グラフの作り方
• Hadoop 系は、基本、NameNode、ResourceManager を REST API 経由で取得。
• OS 系は、Infra Team 構成の Collectd plug-in で取得。
• ダッシュ・ボードは、Hadoop 系、OS 系のグラフを組み合わせて作成。
Graphite
for hadoop
carbon-cache
GrafanaCollectd
graphite-plugin
exec-plugin
scripts with jq
NameNode
ResourceManager
via REST API Graphite
for infra
Hadoop Cluster
Command/Job

12
[Reference] REST API of NameNode and ResourceManager
Contents Queries
HDFS cluster curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=FSNamesystemState"
NameNode JVM info curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=JvmMetrics"
NameNode and DataNode curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeInfo"
NameNode state curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeStatus"
NameNode RPC curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=RpcActivityForPort8020“
curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=RpcActivityForPort8040“
NameNode CMS curl -s "${NN}:50070/jmx?qry=java.lang:type=GarbageCollector,name=ConcurrentMarkSweep"
NameNode Heap curl -s "${NN}:50070/jmx?qry=java.lang:type=Memory"
jobs finished in last 10 min curl -s "${RM}:8088/ws/v1/cluster/apps?finishedTimeBegin=`date -d '10 minutes ago' +%s%3N`"
running jobs curl -s "${RM}:8088/ws/v1/cluster/apps?state=RUNNING"
accepted jobs curl -s "${RM}:8088/ws/v1/cluster/apps?state=ACCEPTED"
ResourceManager status curl -s "${RM}:8088/ws/v1/cluster/info”
YARN cluster curl -s "${RM}:8088/ws/v1/cluster/metrics" | jq "."
NodeManager curl -s "${RM}:8088/ws/v1/cluster/nodes" | jq "."
NNTop curl -s "${NN}:50070/jmx?qry=Hadoop:service=NameNode,name=FSNamesystemState"

13
2. Graphs on Main Dashboard
[ Multi-Tenant ] Useful for Multi-Tenant Hadoop Cluster
[ Rank S ] Must
[ Rank A ] Very useful
[ Rank B ] Useful
[ Rank C ] Nice to have

14
[YARN][Rank S][Multi-Tenant] Yarn Memory Usage per User/Queue
• とあるユーザからの問い合わせ:「クラスタが遅いんだけど…」
• まったく原因がわからない。そもそも問題かどうかもわからなかった。
Yarn memory usage per User Yarn memory usage per Queue
• クラスタが遅いわけではなく、そのユーザが複数のキューで多くのリソースを使っているこ
とが原因であることわかる。
• 4年前に作成したグラフで、メイン・ダッシュボードの一番上にあり、すべての起点。

15
[YARN][Rank A][Multi-Tenant] Graphs to monitor Yarn Busyness
• とあるユーザからの問い合わせ:「全然ジョブが始まらないんだけど…」
• クラスタの忙しさは、基本、これらのグラフを組み合わせてモニタリング。
• Pending jobs で検知、Queue 毎の数と、Pending 時間をモニタリング。
Pending jobs per Queue
Longest Peinding job per QueueRunning, Pending, Killed, Failed Jobs

16
[YARN][Rank B][Multi-Tenant] Number of preemptions per Yarn Queue
• とあるユーザからの問い合わせ:「ジョブが終わんないんだけど…」
Yarn memory usage
Yarn memory usage per Queue
• さらに、Queue 毎の Preemption 数をモニタリング。
• 上記は、昔の “Never Ending jobs” 問題発生時のグラフ。Preemption や
“mapreduce.job.reduce.slowstart.completedmaps”のチューニングで解消済み。
• 不当に⾧く走り続けるジョブの検知もできる。

17
[HDFS][Rank S] Last contact values of DataNodes
• とある日、Datanodes の Last Contact の値が時々大きいことに気づく
Last contact
• スナップショット情報 => ヒストリカル情報
• HDFSクラスタの問題は、DataNode の LastContact のモニタリングで検知はできる。
Last Contact values of all DNs

18
[HDFS][Rank B] CPU I/O wait of all DNs (OS)
• 問題:原因を特定できない High Data I/O Load
• HDFS の I/O 性能が極端に落ちる。もしくは、HDFS write が失敗。
• DN Last Contant グラフと DN の CPU I/O
wait の組み合わせで、何らかの HDDs の
I/O 負荷によって問題が発生していること
が判明。
• しかし、誰が、どのようなI/O負荷を発生さ
せているかはわからない…
Last Contact values of all DNs
CPU I/O wait of all DNs

19
[YARN] SSD for Hadoop jobs
• Hadoop ジョブの高速化のため、新規の Slaves にSSDを追加
• 以下の OS ディレクトリに SSDを使用
• yarn.nodemanager.local-dirs:Where to store localized files in.
• yarn.nodemanager.log-dirs:Where to store container logs.

20
[YARN][RANK S][Multi-Tenant] SSD usage (OS)
• 容量が十分であるかを確認するために SSD の使用率のモニタリングを始める。
• 大きなジョブでも、通常は 200 GB ~ 300 GB 程度。
Usage of SSD for NMs

21
[HDFS][Combination] For Unknown high Disk I/O load of Slaves
• 原因不明の High Load は、Container の OS file write であることが判明。
Usage of SSD for NMs Last Contact of DNs
CPU I/O wait Stale DataNodes (Yellow)
• OSディレクトリにapplication id も含まれるので、du コマンドでジョブの特定も可能となった。

22
[Best Practice] Slave ノードの構成
• この問題のまとめと、Slave 構成に関する Best Practice
• SSD を利用し、DataNode と NodeManager の Disk I/O を分離!
• Hadoop ジョブの高速化 + 問題ジョブの特定のため。
• すべての Slaves に SSD を追加することにより、根本対応が可能（と見込まれる）。
LastContact of all DNs
Usage of SSD for NMs
LastContact of slaves
without SSD
LastContact of slaves
with SSD
200
8

23
[NodeManager][Rank B] Load average and CPU idle of Slaves (OS)
• Load average (short) + CPU idle
• CPU の Utilization や Slave ノードのバランスをみるために重要。
Load average of Slaves
CPU idle of Slaves

24
[NameNode][Rank A] Response time of “hdfs dfs –ls /”
• Response time of “hdfs dfs -ls /”
• NameNode の負荷状況を利用側からモニタリング。
Usage of SSD for NMs

25
[NameNode][HDFS][Rank C] NNTop, UnderReplicatedBlocks
• NNTop
• NameNode オペレー
ション回数と、HDFSク
ラスタの負荷がリンクし
ないことが多いが、役立
つときもある。
• UnderReplicatedBlocks
• HDFS write に関する異
常を検知。
Number of NN operations per user
UnderReplicatedBlocks

26
[Hadoop][Rank S] Pending and elapsed time of MR pi job
• 最近追加したおすすめグラフ
• ジョブのペンディング, メモリ・アローケーション、hdfs write を含めた完了時間。
• クラスタを総合的に利用側からモニタリング。
Pending and longest running job of
a yarn queue with MR pi sample job

27
[Hive][Rank B] Response time of “show databases;”
• ユーザの Bad クエリによる負荷をモニタリング。
• Cron 監視し、レスポンスが 10分を超えた場合にリスタート。
Hive Response time of “show databases;”

28
[ResourceManager][Rank C] To monitor RM problem
• ResourceManager プロセスに問題はないが、スケジューリングに問題がある
ケースへの対応。
• AMRegisterDelayNumOps, AMLaunchDelayNumOps, RegisterApplicationMasterNumOps
• モニタリングでなく、Yarn クラスタの Health チェックとしては [Rank S]
Monitor for RM problem

29
[Slaves][Rank B] Status of DataNodes and NodeManagers
• DataNode 、NodeMamager のステータス
• DataNode: Dead/Decom/Decommissioning/DecomLive/Stale
• NodeManagers: unhealthy/lost/decommissioned
Status of DataNodes and NodeManagers

30
[Best Practice] ダッシュボードの配置 for マルチテナント Hadoop クラスタ ①
[S] Yarn memory usage
per User
[A]
Running/Pending/Killed/
Failed jobs
[S] Yarn memory usage
per Queue
[A] Response time of
“hdfs dfs -ls /”
[S] Usage of SSDs for
NMs
[S] Pending and
Running time of MR pi
job
[S] Counter of
LastContact
[B] Hive response time
of “show databases;”
[B] Monitor for RM
problem
[C]
UnderReplicatedBlocks

31
[Best Practice] ダッシュボードの配置 for マルチテナント Hadoop クラスタ ②
[B] CPU I/O wait
[B] CPU idle
[B] DataNodes and
NodeManagers
[A] Pending jobs per
Queue
[B] Load average short [A] Longest Pending
jobs per Queue
[C] Number of NN
operations per user
[B] Total number of
Preempted containers of
RUNNING jobs per
Queue (Non-AM)

32
3. Other Dashboards
for Multi-Tenant Hadoop Cluster

33
[YARN][Rank B][Multi-Tenant] Longest Running Jobs per User/Queue
• ユーザやキューごとのジョブの最大実行時間。
• 今日の状況が、過去と比べてどうか?他のユーザと比べてどうか?が見える。
Longest Running jobs of a Queue
Longest Running jobs per Queue

34
[HDFS][Multi-Tenant] HDFS small file problem and for Cost allocation
• 現在、HDFS small file 問題に対応中。
• ユーザ毎のファイル数、データサイズ、平均サイズ を確認できる。
Number of files per User Total data size per User Average data size per User
HDFS usage Number of HDFS files Heap usage

35
[HDFS][Multi-Tenant] HDFS small file problem and for Cost allocation
Active
NameNode
Standby NameNode
Batch Server
hdfs -oiv
Hadoop
FSImage file Readable file
Create Hive table_raw
Hdfs -put
scp
FSImage file
Create (insert)
Hive table_date
|Path|Replication|ModificationTime|AccessTime|PreferredBlockSize|BlocksCount|FileSize|
NSQUOTA|DSQUOTA|Permission|UserName|GroupName|
FSImage のフォーマット

36
[HDFS][Multi-Tenant] HDFS small file problem and for Cost allocation
• For small file proble 対応のための分析可能
• NameNode の直接的な負荷なしで実行できる。
• ex1) UserA の 1MB 以下のファイル数
• ex2) 1年以上だれもReadしていないファイルのリスト
• Cost Allocation
• CPU:Memory:# of HDFS files:HDFS data size
• すべて Grafana から取得し、ユーザごとのUsageを計算し、コスト配布。
select count(*) from table_date where username=‘userA' and PATH like '/user/userA/%' and
permission not like 'd%' and FileSize!='0' and FileSize <'1048576';
insert overwrite directory '/output/older_than_1year' row format delimited fields terminated by '|' stored
as textfile select * from table_date where username=‘userA' and permission not like 'd%' and
accesstime<'2018-03-14 00:00:00.0' order by path;

37
まとめ

38
[Best Practice] 例えば、グラフを単体でみると…
• Yarn メモリは 常に 100%、100以上の Pending ジョブも発生している。
• ただ単に、リソースが足りないだけなのか、何か悪いジョブが走っているのかがわからない。

39
[Best Practice] 組み合わせると…
• NameNode の レスポンス (hdfs dfs -ls /) には問題がない。
• Test MapReduce ジョブ（sample pi program）のレスポンスにも問題がない。
• 問題は問題だが、他のユーザには ”遅い” 以外の影響は出ていないと判断できる。

40
[Best Practice] マルチテナント Hadoop クラスタのモニタリング
• 組み合わせてみること
• 1つのグラフを見ていても、あまりわかるこはあまりない。
• 複数のグラフを組み合わせることで、発見/判断できることがある。
• メイン・ダッシュボードは、常に表示させて、常にみられるようにしておくこと。
• 常にみていると、時々、思いついたり、何かが見えてくることがあります。
• また、過去に起こったことがあるか、ないかにより、問題の重要度も見えることがある。
• “Always Improve, Always advance”
• 必要に応じて、新しいグラフを作ること。
• グラフの並べ方を、常に工夫すること。
• これらの取り組みで、皆さんにとっての Best なダッシュボードが出来上がると思います!

41
最重要事項

42
[最重要] Hadoop Administrator 募集!
• Hadoop Admin Export 及び、Hadoop DevOpe エンジニアを募集しています。
• Hadoop Admin Export
• 新機能、新コンポーネントの検証 / POC / Architect / Design
• ユーザのHadoopを利用した新しいサービス導入に対するコンサルティング
• Patch 作成、Hadoop オープン・コミュニティへの貢献
• Hadoop DevOps
• 運用やオンボーディング・プロセスの自動化・サービス化
• Hadoopクラスタのための CI
E-mail : tomomichi.hirano@rakuten.com
http://global.rakuten.com/corp/careers/
[Hadoop Admin] https://talent.rakuten.careers/jobs/administrator-of-hadoop-clusters-and-other-platforms-for-bigdata-1955
[DevOps] https://talent.rakuten.careers/jobs/full-stack-infrastructure-devops-engineer-cloud-platform-department-8210