GMO最新ネット業界レポート【第7回】テクノロジー編（後編）

ホーム > GMO最新ネット業界レポート一覧 > GMO最新ネット業界レポート

第7回テクノロジー編（後編）

前編では、「GMOとくとくショップ」で利用しているHadoopの説明や問題点などをレポートした。今回は、Hadoopを使った構築方法やチューニングポイント、運用管理などを紹介する。

1.Hadoopの構築

Hadoopでクラスタを構築する際、動作させるインスタンス毎にどういったサーバーが必要になるか検討する必要があります。GMOとくとくショップでは、Hadoopクラスタで動作させるプロセスの種類によってサーバーの種類を分けて構築しています。

NameNode
JobTracker
DataNode/TaskTracker

図3 Hadoop Cluster構成

NameNodeは前回説明したように、バックアップ用サーバーを用意して冗長性を確保しています。

また、JobTrackerはMapReduce処理におけるSPOFであるため、NameNodeのバックアップサーバー上で動作させ、停止時にはNameNodeのマスター上に切り替わるようにします。一方でDataNodeとTaskTrackerは同じサーバー上で動作させるようにします。このように、SPOFを排するようにHadoopクラスタを構築したものが図3です

なお、NameNode、JobTrackerは比較的スペックの良いサーバーを用い、DataNode/TaskTrackerは通常のスペックのサーバーを用いています。それぞれのスペックは以下のようになっています。

NameNode/JobTracker ：Intel Xeon L5520、16Gbyte memory、RAID有
DataNode/TaskTracker ：Intel Xeon L5520、 8Gbyte memory、RAID無

2.Hadoopのチューニングポイント

Hadoopは初期設定のままで動作させても特に問題無く動きますが、今回は以下の3点について考えてみましょう。

ブロックサイズは初期の設定値は64Mbyteになっています。これは、64Gbyteのファイルを Hadoop上に置くと、1,000個のブロックができるということです（実際はレプリケーション分積算される）。1つのファイルが1Mbyteしかないものを置いた場合も、64Mbyteのブロックが１個使われます。

Hadoopは元々大きいデータを扱うことを想定しているため、ファイルサイズが数Gbyte～Tbyteに及ぶことを考えると大きいブロックサイズの方が良いのですが、画像データのような比較的小さいデータを扱う場合、大きいブロックサイズでは非効率です。反対にブロックサイズを小さくしてしまうと、ログ・集計データのような大きいデータを扱う場合、Hadoop上にデータを置くのにパフォーマンスが悪くなってしまいます。

図4 ブロックサイズ毎の処理時間

図4は、４Mbyte～128Mbyteのブロックサイズ毎に１GbyteのファイルをHadoop上に置いた時の処理時間を表しています。

そこで、Hadoop上にデータを置くアプリケーション毎にdfs.block.sizeの値を変えることで、画像ファイルはなるべく小さく、ログ・統計情報は大きいブロックサイズを設定して最適化を行います。

次に大量のファイルを利用する場合における、NameNodeのメモリサイズについて考えます。

NameNodeは1ディレクトリ・ファイル・ブロック当たり大体150byteのメモリを消費するので、大量のファイルを扱う場合は事前にメモリの容量計算が必要になります。Hadoopが利用するメモリサイズは、HADOOP_HEAPSIZEで設定することができます。事前に計算されたHADOOP_HEAPSIZE以上のメモリを使ってファイルを扱おうとすると、OutOfMemoryErrorでNameNodeが停止する現象を確認しているため、サイズ変更を行い、ある程度パラメータの調整をしておく必要があります。

最後に、Hadoopは一つのデータブロックを複数のサーバーにレプリケーションすることで、可用性を高めていますが、XEN上に複数のHadoopを構築する場合、障害が発生したとき同じXEN上にデータブロックが存在すると、データにアクセスできなくなってしまいます。それに対処するため、ラック認識機能を利用します。ラック認識機能を利用するとデータブロックやMapReduceの際にタスクの割振りを管理することができます。何も設定を行わないと、全て同じトポロジーに存在していると見なされ、同じXEN上に割り振られる可能性があるのです。

そこで、topology.script.file.nameにDataNodeが位置するラックを返すスクリプトを設定し、データの割振りを管理することが必要になります。このパラメータはNameNodeでのみ設定可能であり、DataNodeで設定を行うとエラーとなってしまい当該DataNodeが起動しなくなるため注意が必要です。

3.Hadoopの運用管理

図5 データブロックの配置

Hadoopの運用には大きく、ログ・プロセス・死活監視、リソース監視に加えて、リソースが足りなくなった場合の拡張性、バックアップ・システム更改が考えられます。

動作状況については、Hadoopにデフォルトで備わっているWebの管理画面によってNameNode、JobTrackerを確認することができます。また、コマンドを使うことで、MapReduceタスクの管理、fsckのようなHDFSの検査、データブロックの修復を行うことができるようにもなっています。これらのHadoopに備わっている機能に加え、Nagios、Cactiといったミドルウェアを用いて、監視機能を補完しています。

拡張性については、NameNode/JobTrackerとDataNode/TaskTrackerにおいて対応方法が変わってきます。HDFS容量不足やMapReduce処理の遅れといったHadoopのリソースに起因する場合は、DataNode/TaskTrackerのサーバーをHadoopクラスタに追加することで容易にスケールアウトできます。しかし特にNameNodeのメモリが不足するといった場合においては、メモリを増強するといったスケールアップの道しか残されていません。これについては事前のサイズ変更、メモリの容量計算で把握しておく必要があります。

バックアップについては、定期的に取得しているメタデータを保存することで対応を行い、NameNodeのHA構成が壊れた場合でも復旧を行えるようにする必要があります。

最後に、バージョンアップによるシステム更改の対応も重要です。Hadoopはクラスタ構成を取っているため、NameNodeについては単一点障害、DataNodeについては複数のサーバーが落ちたとしても動作し続けます。しかし、Hadoopのバージョンアップ時にはクラスタの全閉塞が必要になります。手動によるバージョンアップになるため、慎重に行う必要がありますが、rollbackによって前のバージョンに戻すことも可能です。

最後に…次世代システム研究室ではクラウドを作りたいエンジニアを募集しています。ご興味がある方はこちらからエントリーをお願いします。