導入編～Hadoopクラスタを構築するまで

Hadoopを気持ちよく使っていますか？

　突然ですが、DBエンジニアのみなさま、Hadoopは使っていますか？バリバリ使っているよ！という方がいらっしゃる一方で、そろそろ新しい技術にも触れなければと焦って手元の環境にHadoopをインストールしたものの、特に使い道が思い浮かばずHDFSにファイルをアップロードしたりベンチマークを動かしたりしただけであとは放置、という方も多いのではないでしょうか。かくいう私もそうでした。しかも、もっさりとしか動かない仮想環境にこぢんまりと1台クラスタ(ってクラスタではないですね)を作ってデータ量を気にしながらちまちまと動かしていたので、使っていてもちっとも気持ちよくない！使っていて気持ちがよくなければいい発想も生まれませんね。

　そんな折、10月に開催される「db tech showcase」の発表のために「Insight Qube PYTHON」でHadoopクラスタを組んでみることにしました。実際に組んでみると、速い！サクサク動く！クラスタの各ノードが一斉にジョブを実行する様が壮観！と、すっかり気持ちよくなってしまいました。そこで、一丁このHadoopクラスタでバリバリ分析してやろうか！と、勢いに任せてHadoopのジョブをぐりぐり動かしてTwitterのデータを分析した、その過程を今回の連載でお見せします。第1回は導入編として、今回使ったHadoopクラスタを構築するまでをご紹介します。

　※「Insight Qube PYTHON」とは
　たった8台。でも100台分のパワー。HadoopのR&Dを誰にでも可能にしたマシンです。詳しくはこちら。

Hadoopクラスタを作ってみよう

　ではさっそくHadoopのクラスタを作ってみましょう。今回は以下の構成のマシンを8台用意しました。

図1：今回活躍するマシンのスペックと雄姿。去年のdb tech showcaseではOracle RACが動いていました

　CPUはコア数が多いものを用意し、かつSSDを使用してI/O待ちを排除することでHadoopの並列処理がフルに生かされるようにします。また、ノード間通信にはInfiniBandを使用し、ネットワークI/O待ちも排除しています。今回はIPoIB(IP over InfiniBand)というプロトコルを使うことで、Gigabit Ethernet使用時と変わらない使い勝手としています。

　次に、Hadoopの各サービスをクラスタ内のどのノードに配置するかを設計します。HadoopはHDFSと呼ばれるファイルシステムとMapReduceと呼ばれるデータ処理のための仕組みを持ち、それぞれ全体を管理するサービス(HDFSはNameNode、MapReduceはJobTracker)と、それを受けて実際にデータを保存したり加工したりといった仕事をするサービス(HDFSはDataNode、MapReduceはTaskTracker)があります。

図2：HDFSのサービスの仕組み

図3：MapReduceのサービスの仕組み

　一般にNameNodeとJobTrackerをマスタ、DataNodeとTaskTrackerをスレーブと呼び、大規模なクラスタではリソース消費の観点からマスタとスレーブは別のノードに置いた方がよいとされています。具体的には、NameNodeはHDFS上のファイル数や使用ブロック数が増えるほどメモリを消費し、JobTrackerはMapReduceジョブが同時に大量に実行されるほどCPUリソースを消費します。

　しかしながら、今回用意したのはわずか8台のマシンで、しかも利用者は筆者のみ。よってマスタとスレーブは同居させてしまいます。

　また、実運用では可用性もしっかりと考慮する必要があります。特にマスタノードは今回使用するバージョンのHadoopでは単一障害点(SPOF)となる部分です。よって環境によっては別途PacemakerやDRBDといったプロダクトを用いてHA構成をとることが望ましい場合があります。しかし今回はR&Dということで、このあたりは一切考慮せずHA構成はとらないこととします。壊れたら潔く作り直しです。

　以上の方針で図4の通りにHadoopの各サービスを割り当て、クラスタを構成します。

図4：Hadoop各サービスのクラスタ内での割り当て