halookで始めるHadoop/HBaseトラブルシューティング

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

この記事を読むのに必要な時間:およそ 3 分

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

Hadoop,HBaseの難しさ

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

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

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が割り当てられていないノードとそうでないノードがあることがわかります。

図1 HBaseのテーブルごとのRegion数を表したグラフ

図1 HBaseのテーブルごとの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を表しており,容量に対する,現在の使用量を表示しています。使用率が設定した閾値を超えると,バーの色が青からオレンジ色に変わるようになっています。これにより,容量に余裕があるか,データに偏りがないかが,一目で確認できるようになります。過去データも参照できるため,時系列に追っていくことで,クラスタの成長も見て取ることができます。

図2 HDFSの可視化

図2 HDFSの可視化

著者プロフィール

落合雄介(おちあいゆうすけ)

Acroquest Technology株式会社 オブジェクトフレームワークディヴィジョン エンジニアリングクリエーター

http://www.acroquest.co.jp/

コメント

コメントの記入