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 クラスタのためのモニタリング Best Practice

513 views

Published on

Hadoop / Spark Conference Japan 2019
『マルチテナント Hadoop クラスタのためのモニタリング Best Practice』
平野 智巌(楽天株式会社)

Published in: Technology
  • Be the first to comment

マルチテナント Hadoop クラスタのためのモニタリング Best Practice

  1. 1. マルチテナント Hadoop クラスタのための モニタリング Best Practice Mar 14, 2019 Tomomichi Hirano Hadoop Platform Team Cloud Platform Department Rakuten, Inc.
  2. 2. 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. 3. 3 楽天 Hadoop Analysis Output Input 店舗情報 購入情報商品情報 アクセスログ/行動ログ メンバーシップ情報 (楽天会員情報) Index for 商品検索 / Suggest 店舗様向けレポート Recommend 広告 マーケティング ターゲティング プラニング サイト・デザイン KPI マネージメント データマート DWH DBMS
  4. 4. 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. 5. 5 楽天 Hadoop の 特徴 • Large クラスタ / マルチテナント • 600+ Hadoop アカウント、7万+ ジョブ... • 細かなチェックやコントロールをしていない(できない)状態。 • Speed & Self-Service • ユーザの開発スピードを落としたくないので、Self-Service を目指している。 • 基本は、Free ride、Free use。
  6. 6. 6 楽天 Hadoop Admin Team の 特徴 • Role and Responsibility • Hadoop ジョブ開発以外のすべて • クラスタ運用(ノード追加/削除、ユーザ追加、ディスク交換など) • クラスタのモニタリング、チューニング • 新機能の検証、導入 • クラスタのトラブル・シューティング、原因調査 • ユーザ・サポート(QA対応、ジョブのトラブル・シューティングのサポート) • Small Hadoop Admin Team • 専任 2名、兼任 1名、マネージャ • No Partner、No Support
  7. 7. 7 なぜ モニタリング が クリティカル であるのか? (Before モニタリング) • Large クラスタ / マルチテナント • 問題であるのか、問題でないのかが判別できない... • クラスタの問題であるのか、ジョブの問題であるのかがわからない... • Speed & Self-Service • ユーザは、Hadoop Admin Team に聞かないと、クラスタの状況がわからない... • Small Hadoop Admin Team • いろいろな UI や Ganglia グラフなどいろいろ確認しないと状況がわからない... • ユーザへ説明するために情報を整理するために時間がかかった...
  8. 8. 8 なぜ モニタリング がクリティカルであるのか? (After モニタリング) • Large クラスタ / マルチテナント • 問題か、問題でないかがわかる(ことがある)!!! • クラスタの問題であるか、ユーザの問題であるかがわかる(ことがある)!!! • Speed & Self-Service • ユーザは、Hadoop Admin への問い合わせなしで、即座に状況を確認できる!!! • Small Hadoop Admin Team • 重要なグラフを集めたダッシュボードをみることで短時間で問題を把握できる!!! • ユーザは自分でクラスタの状況を確認できるので、問い合わせ自体が減る!!! • グラフを共有するだけで、ユーザに状況を説明できる!!!
  9. 9. 9 今日のアジェンダ “マルチテナント Hadoop クラスタのためのモニタリング Best Practice” 1. グラフの作り方 2. 最重要ダッシュボートにあるグラフを事例とともに紹介 • Tips: Slave ノードでの SSD 活用 3. マルチテナント特有のその他ダッシュボードを紹介 • Tips: HDFS small file 問題への対応 • この資料は公開します!
  10. 10. 10 1. How to create graphs
  11. 11. 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. 12. 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. 13. 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. 14. 14 [YARN][Rank S][Multi-Tenant] Yarn Memory Usage per User/Queue • とあるユーザからの問い合わせ:「クラスタが遅いんだけど…」 • まったく原因がわからない。そもそも問題かどうかもわからなかった。 Yarn memory usage per User Yarn memory usage per Queue • クラスタが遅いわけではなく、そのユーザが複数のキューで多くのリソースを使っているこ とが原因であることわかる。 • 4年前に作成したグラフで、メイン・ダッシュボードの一番上にあり、すべての起点。
  15. 15. 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. 16. 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. 17. 17 [HDFS][Rank S] Last contact values of DataNodes • とある日、Datanodes の Last Contact の値が時々大きいことに気づく Last contact • スナップショット情報 => ヒストリカル情報 • HDFSクラスタの問題は、DataNode の LastContact のモニタリングで検知はできる。 Last Contact values of all DNs
  18. 18. 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. 19. 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. 20. 20 [YARN][RANK S][Multi-Tenant] SSD usage (OS) • 容量が十分であるかを確認するために SSD の使用率のモニタリングを始める。 • 大きなジョブでも、通常は 200 GB ~ 300 GB 程度。 Usage of SSD for NMs
  21. 21. 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. 22. 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. 23. 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. 24. 24 [NameNode][Rank A] Response time of “hdfs dfs –ls /” • Response time of “hdfs dfs -ls /” • NameNode の負荷状況を利用側からモニタリング。 Usage of SSD for NMs
  25. 25. 25 [NameNode][HDFS][Rank C] NNTop, UnderReplicatedBlocks • NNTop • NameNode オペレー ション回数と、HDFSク ラスタの負荷がリンクし ないことが多いが、役立 つときもある。 • UnderReplicatedBlocks • HDFS write に関する異 常を検知。 Number of NN operations per user UnderReplicatedBlocks
  26. 26. 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. 27. 27 [Hive][Rank B] Response time of “show databases;” • ユーザの Bad クエリによる負荷をモニタリング。 • Cron 監視し、レスポンスが 10分を超えた場合にリスタート。 Hive Response time of “show databases;”
  28. 28. 28 [ResourceManager][Rank C] To monitor RM problem • ResourceManager プロセスに問題はないが、スケジューリングに問題がある ケースへの対応。 • AMRegisterDelayNumOps, AMLaunchDelayNumOps, RegisterApplicationMasterNumOps • モニタリングでなく、Yarn クラスタの Health チェックとしては [Rank S] Monitor for RM problem
  29. 29. 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. 30. 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. 31. 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. 32. 32 3. Other Dashboards for Multi-Tenant Hadoop Cluster
  33. 33. 33 [YARN][Rank B][Multi-Tenant] Longest Running Jobs per User/Queue • ユーザやキューごとのジョブの最大実行時間。 • 今日の状況が、過去と比べてどうか?他のユーザと比べてどうか?が見える。 Longest Running jobs of a Queue Longest Running jobs per Queue
  34. 34. 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. 35. 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. 36. 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. 37. 37 まとめ
  38. 38. 38 [Best Practice] 例えば、グラフを単体でみると… • Yarn メモリは 常に 100%、100以上の Pending ジョブも発生している。 • ただ単に、リソースが足りないだけなのか、何か悪いジョブが走っているのかがわからない。
  39. 39. 39 [Best Practice] 組み合わせると… • NameNode の レスポンス (hdfs dfs -ls /) には問題がない。 • Test MapReduce ジョブ(sample pi program)のレスポンスにも問題がない。 • 問題は問題だが、他のユーザには ”遅い” 以外の影響は出ていないと判断できる。
  40. 40. 40 [Best Practice] マルチテナント Hadoop クラスタのモニタリング • 組み合わせてみること • 1つのグラフを見ていても、あまりわかるこはあまりない。 • 複数のグラフを組み合わせることで、発見/判断できることがある。 • メイン・ダッシュボードは、常に表示させて、常にみられるようにしておくこと。 • 常にみていると、時々、思いついたり、何かが見えてくることがあります。 • また、過去に起こったことがあるか、ないかにより、問題の重要度も見えることがある。 • “Always Improve, Always advance” • 必要に応じて、新しいグラフを作ること。 • グラフの並べ方を、常に工夫すること。 • これらの取り組みで、皆さんにとっての Best なダッシュボードが出来上がると思います!
  41. 41. 41 最重要事項
  42. 42. 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

×