第1回　halookでHadoop/HBaseを可視化しよう

この連載では、HadoopやHBaseのトラブルを解決する手順をご紹介します。第1回目となる今回は、本連載のキーとなるツール「halook」を紹介します。「⁠halook」はオープンソースで開発しているHadoop/HBase用の可視化ツールで、トラブルの発生を可視化して把握し、原因究明するために利用できます。まずは「halook」の概要から紹介します。

Hadoop、HBaseの難しさ

Hadoopは大量データの保存と分散処理のために、数十台～数千台のマシンを扱います。そのため、何かトラブルがあったときに、どこに原因があるのか突き止めるのが難しい場合が多く、あるいは、そもそもトラブルが起こっていることに気付くのが遅れてしまうこともあります。たとえば、次のような点が挙げられます。

データは正しく分散配置されているか
処理は分散して実行されているか
設定ミスをしていないか
問題の報告の難しさ

1．データは正しく分散配置されているか

HadoopやHBaseを採用した際、HDFSに保存するデータが、特定のスレーブに偏らず、うまく分散配置されているかどうかは、運用上気になるところです。データの偏りが生じると、MapReduce実行時に、スレーブ間でのデータ転送が発生してしまい、「⁠ローカルのデータを処理対象にすることでネットワーク転送量を減らす」という特性が発揮されないか、あるいは特定のスレーブに処理が集中することとなり、いずれにせよパフォーマンスに影響が出る可能性があります。

Hadoopの機構として、データが自動的にバランス良く配置されるようになっていますが、たとえば新規にマシンを追加してスレーブの台数を増やした場合などは、元々保存されていたデータが新しいノードに自動で移動するわけではないため、手動でリバランスのコマンドを実行するか、新規に投入するデータが使用量の少ないノードに優先的に保存された結果としてばらつきがなくなるのを待つことになります。また、サーバごとにHDFSに割り当てられている容量が異なる場合、このようなケースでのデータ割り当てルールが単純ではないことから、バランスの良い配置になっているかどうかはなおのこと確認しておきたいところです。

HBaseについても同様です。HBaseは、Regionと呼ばれる単位でデータを管理します。HBaseへのreadやwriteは、対象のRegionを持っているRegionServerへの問い合わせの形で行われます。そのため、たとえばあるテーブルへの書き込みが行われる際、対象のテーブルのRegionが特定のRegionServerにしかなかった場合、そのRegionServerへのアクセスが集中してしまいます。このようなことが、読み書きの速度が思うように上がらない原因となります。また、「⁠各RegionServerの持つRegion数」は均一になるように自動で調整されますが、テーブルごとに見た場合、「⁠あるテーブルのRegionが特定のRegionServerに偏っている」という状況も起こり得ます。以下の図は、30台のノードを持つHBaseクラスタにデータを投入したときのRegion分布を表したグラフです。テーブルごとに色分けがされています。各サーバのRegion数合計はほぼ同じですが、テーブルごとに見ると、ほとんどRegionが割り当てられていないノードとそうでないノードがあることがわかります。

2．処理は分散して実行されているか

MapReduceは、分散処理を簡単に記述するためのフレームワークです。しかし、「⁠簡単に」とはいっても、処理の特性を理解して効率的なアプリケーションを作成するにはそれ相応の知識を必要とします。うまく分散しない処理を書いてしまうと、対象となるデータ量が増えたときに、マシンの台数を増やしてもパフォーマンスが上がらないという事態を招いてしまいます。もしくは、ある日突然「reduce処理中にOutOfMemoryErrorで落ちた」なんてことになるかもしれません。検証段階できちんとチェックすることが必要です。

また、PigやHiveなどの高級言語で処理を記述した場合も、結果的にどんなMapReduce処理が実行されているのかは気になるところです。いちいちMapReduceのログを確認するのは面倒ですが、定期的に実行されるジョブと、アドホックに実行されるジョブとを共存させることを考えた場合は、どのようなMapReduceジョブが実行されるかを把握した上で、スケジューラの設定、各処理に割り当てるスロット数を調整する必要が生じます。

3．設定ミスをしていないか

Hadoopの設定項目は多岐にわたります。データ量の増加や、分析したい内容の変更に応じて、クラスタ自体の設定を見直すこともあると思いますが、変えた結果、「⁠結局どういう動きをするようになったのか」は確認しておかなければなりません。設定の変更が反映されたかどうかは、普通は設定変更後に確認するでしょうが、それに加えて、意図しない動きをするようになっていないかも見ておく必要があります。単に処理が正常に終了したことを見るだけではなく、何らかの可視化手法で直感的に動きが捉えられれば、「⁠期待通りに処理が変わった」ことや、「⁠おかしな動作をしている」ことが、把握できるようになります。特にHadoopは、マシンの台数が多くなるため、「⁠一部のスレーブに設定変更が反映されていない」というミスも起こり得ます。そのため、なおのこと俯瞰的に処理の状態を見ることが求められます。

4．問題の報告の難しさ

システム運用時にトラブルが発生した場合、開発者本人はログを見れば問題がわかるかもしれませんが、その報告がネックになることがあります。「⁠マシンの追加が必要だ」「⁠このマシンの交換が必要だ」「⁠この現象を解決するために、稼働中の商用クラスタに追加でこのような設定変更が必要だ」など、こういったことをステークホルダーに説明するためにエンジニアが資料を作るのですが、その作成に大きな工数がかかる場合があります。（⁠システムの）現状の可視化は、このような場面でも役に立ちます。

Hadoop、HBaseを可視化しよう

それでは、halookを使って可視化できる内容を紹介しましょう。halookは、Acroquest Technology株式会社が2012年11月に公開した、Hadoop/HBase可視化のためのOSSです。halookと同時期に製品版をOSSとして公開した、Javaシステムの見える化・診断ツールENdoSnipeの機構を使ってデータを収集します。なお、halookはCDH3u5の他、コミュニティ版のApache Hadoop 0.20.2でも動作確認を行っています。

HDFSの使用量を可視化する

まずはhalookのロゴにもなっている、HDFSビューを見てみましょう（図2⁠）⁠。1本のバーが、1つのDataNodeを表しており、容量に対する、現在の使用量を表示しています。使用率が設定した閾値を超えると、バーの色が青からオレンジ色に変わるようになっています。これにより、容量に余裕があるか、データに偏りがないかが、一目で確認できるようになります。過去データも参照できるため、時系列に追っていくことで、クラスタの成長も見て取ることができます。

MapReduce Jobを時系列に表示する

続いて、MapReduce Jobガントチャートです（図3⁠）⁠。名前のとおり、MapReduce Jobの一覧を、ガントチャートで表示します。Hadoopの標準のWebUIだと、表形式で一覧化されるだけなので、たとえば「処理時間の長かったJobはどれか」というのもすぐにはわかりません。このように、Jobの開始時刻と終了時刻を線で表現することによって、時間のかかったJobがわかるようになり、同時に複数のJobが実行されている様子も把握できるようになります。

MapReduceのタスク実行状況を表示する

MapReduce Jobの一覧画面で、どれかのJobを選択すると表示される画面です。MapReduce Jobの実行内容を、Map TaskとReduce Taskを矢印で表現することで詳細に表します。時系列にソートしたり、Taskの実行ホストごとにソートしたりすることができるため、時系列にソートすれば処理の進む様子を視覚的に追うことができ、ホストごとにソートすれば各ノード上での実行状況を把握することができます。特定のノードで、Taskの失敗が集中していることや、他のノードより処理時間が長くなっていることがわかれば、ノードを切り離して調査するなどの対策を取ることができます。また、画面の下の方に表示されているグラフは、同時に実行しているTask数を表します。

たとえば、Jobの実行時間が長くなっている原因を調べる際に、このグラフによりTaskの同時実行数が少なくなっている時間帯があることがわかれば、「⁠遅くなった原因は、同時に実行された他のJobによりTaskの実行数が制限されたから」と結論付けることが可能になります。

MapReduce Jobの特性を現すグラフを表示する

MapReduce Jobの特性を把握するのに便利なグラフを表示します。とくに、Map TaskとReduce Taskの数が多いときに効果を発揮します。横軸がTaskの開始時間もしくは終了時間、縦軸がTaskの実行時間です。このグラフにより、Taskの処理時間のばらつきを把握することができます。たとえば、Map Taskの処理時間が長いものと短いものがあれば、どこか特定のサーバで問題が発生し、処理に時間がかかるようになっているのではないか、などを疑うことになります。Reduce Taskの中に極端に処理時間の長いものがあれば、Partitionerの設定やMapperの実装見直しでJob全体の処理時間が短くなる可能性があると考えることもできます。

また、失敗したTaskの傾向も把握できます。たとえば、同じ処理時間で失敗するTaskが多ければ、Timeoutによる失敗を疑うことができます。うまく活用すれば便利なグラフです。

HBaseのRegion数の推移を表示する

HBaseのRegion数の推移を表したグラフで、HBaseクラスタの成長の様子を把握することができます。Region数の増加は、予想外の動きを示すことがあるので注意が必要です。HBaseに一定のペースでデータを書き込み続けた場合、RegionのSplitを自動に任せると、Splitのタイミングが集中し、グラフが階段状になる場合があります。

HBaseのRegionは、デフォルトでは256Mバイトに達すると、128MバイトのRegionに2分割されます。そのため、すべてのRegionに均等に書き込みが発生するケースでは、すべてのRegionのSplitが同時期に起こり、しばらくSplitが起こらない状態が続いたあと、ほぼ同時にすべてのRegionのサイズが256Mバイトに達し、Splitのタイミングがまた集中します。Splitにはコストがかかるので、Splitが集中するタイミングでパフォーマンスが低下する可能性があります。こういったことも、グラフ化することによって把握することができ、事前に手を打つことができます。

HBaseのRegion分布を表示する

HBaseのRegionの分布をサーバごとに表示します。グラフがテーブルごとに色分けされており、合計したRegion数の分布だけでなく、テーブルごとのRegion数の分布もわかるようになっています。Region数は各サーバで均等になっていても、テーブルごとのRegion数には偏りがあるかもしれません。この場合、テーブルへのデータ書き込みが分散せず、パフォーマンスが低下します。そのような状況がグラフ化でわかるようになります。

他のアプリケーションと合わせて監視する

halookはENdoSnipeのプラグインとして開発されたため、Hadoopの監視をしながら、同時に他のJavaシステムを監視することもできます。この図は、2つのHadoopクラスタとフロントエンドのWebアプリケーションを同時に監視した場合の、ツリー表示のメニュー部分を表示したものです。

今回はここまでです。なお、今回紹介したhalookの機能は、次の動画で見ることができますので、もしよければご覧ください。次回、halookの適用方法と使用例を紹介します。

halookデモ(1) 機能紹介 - Hadoop Conference Japan 2013 Winter: http://youtu.be/rH16eS2_SJ8
halook: https://github.com/endosnipe/halook