エンタープライズ向けにファイルシステムを進化させた
効率的に並列分散処理が行えるHadoopのアーキテクチャは、ビッグデータ時代にかなり有効な仕組みだろう。「とはいえ、Hadoopをいざ企業が利用しようとすると、さまざまな問題が発生します。発生する問題の多くは、Hadoopの分散処理を実現するためのファイルシステム『HDFS』にあります」と述べるのは、マップアール・テクノロジーズのセールスディレクター 平林良昭氏だ。
このHDFSの課題を解決するために、MapRでは独自のMapRファイルシステムを生み出した。そのMapRファイルシステムのLockless Storage Serviceアーキテクチャを考え出したのが、同社の創業メンバーでありChief Technology OfficerのM.C. Srivas氏。彼は、NetAppの前身であるSpinnaker NetworksでChief Architectを勤めた人物であり、専門はファイルシステムだ。
MapRファイルシステムの大きな特長の1つが、NFS（Network File System）としてマウントできること。Hadoopでビッグデータ活用をしようとした際に、大きな問題となるのがリレーショナルデータベースや外部のデータソースからのデータ移動だ。すべてのデータが最初からHDFSにあれば問題ないが、大抵はHadoop以外のリレーショナルデータベースやストレージにデータは存在する。それらをHadoop上で処理したければ、HDFSの上に載せなければならない。このデータ移動の処理が、データが大きくなればなるほど大きな負荷を伴い時間がかかることになる。
MapRファイルシステムはNFSでマウントできる。マウントすればHadoop以外のアプリケーションからは、単なるネットワークストレージに見える。これにより、データを専用のツールやスクリプトを使用しHDFSに移動するという手間なく、他のアプリケーションやデータベースとの間でデータ共有が可能となる。
「WebサーバーのログファイルをHadoopで分析したい。通常はサーバーから吐き出されたログファイルを取得し、それを加工してHDFSに載せる処理が必要になります。MapRの場合はNFSマウントされたMapRのファイルシステムにWebサーバーが直接ログを吐き出すように設定すれば、MapRのHadoopでそれをそのまま処理できます。バッチ処理によるファイル転送などが必要ないので、常に最新のWebログを参照し分析が行えます」（平林氏）
また、独自ファイルシステムとしたことで、企業利用で必要なデータ保護機能も強化できた。オープンソース版のHadoopでもJobTrackerを障害時にフェイルオーバーさせることはできる。しかしながら、障害発生時の処理は継続されず、ジョブ起動前まで戻ってしまう。MapRではもともと構成がHA（High Availability）化しており、フェイルオーバー時にも処理は継続されるようになっている。時間のかかるバッチ処理などでは、処理を継続できるかできないかの違いは運用に大きく影響する。
さらに、MapRにはマルチテナント機能もある。ファイルシステムの中をボリュームという単位に分けることででき、ボリュームごとに利用できるデータ容量に制限を設けたり、きめ細かいアクセス制限をしたりすることができる。「マルチテナントはMapRならではの機能であり、まさにエンタープライズ向けのものです」と平林氏は言う。
企業ユースのためには、ファイルシステムのアーキテクチャの見直しが必要だった
「MapRでは、ファイルシステムのアーキテクチャを変えています。それにより、オープンソースHadoopのさまざまなボトルネックを解消しています」と述べるのは、マップアール・テクノロジーズ システムエンジニアの草薙昭彦氏だ。巷ではよく、MapRは高速化のためにHDFSのJavaの実装をC++で書き換えたと言われている。たしかにC++を使って書き換えてはいるが、単純にプラットフォームのネイティブ実装にすることで高速化しようとしたのではない。
「HDFSにあるオーバーヘッドを取り除きたい。その1つがJavaのレイヤーだったのです。これを取り除くべきと判断し、結果的にC++で書き換えることになったのです」（草薙氏）
一例として、Javaレイヤーが入ってしまうと、どうしてもガベージコレクションの問題が発生する。大容量メモリーを管理している状況で、内部的にデータの生成、削除を繰り返すとガベージコレクションが起こり動きが極端に遅くなってしまう。この問題を、Javaレイヤーをなくすことで解消したい。その結果がC++の採用と言うわけだ。
同様な方針で、MapRではネームノード部分のアーキテクチャも変更した。オープンソースのHadoopでは、基本的にネームノードが1つのクラスタに1つという構成となっている。このため、障害が発生すればクラスタ全体が使えなくなる。ネームノードのHA化によって障害に対応することもできるが、処理が1箇所に集中しボトルネックになるという問題は変わらないままである。
MapRでは、ネームノードをクラスタの中で分散するアーキテクチャをとっている。これで単一障害ポイントはなくなり、さらにネームノード処理のボトルネックもなくなる。これら以外にも、独自のファイルシステムとしたことでミラーリング機能による災害対策や、スナップショット機能によるデータ保護と任意の時点へのリカバリといった、エンタープライズ向けのストレージ装置が持つような機能もファイルシステムのレベルで実装している。またApache Hadoopでは全体の1/3程度しか利用しきれないハードウェアリソースも、MapRであればほぼ性能限界まで使い切れるようにもなっている。
「このようにファイルシステムのアーキテクチャを変更していても、インターフェイス部分は100％ Apache Hadoopとの互換性を守っています」と平林氏は言う。これは、MapRの顧客が望んでいることでもあり、これからもこの方針は変わることはない。互換性があるので、HadoopのエコシステムでもあるImpalaやHiveなどのさまざまなHadoop上のアプリケーションもすべてそのまま動かすことができる。
「Apache Hadoopで動くアプリケーションやライブラリが既にあっても何も手を加えずに動きます。既存の資産は無駄にしません」（草薙氏）
互換性があるだけでなく、運用環境の柔軟性も高い。Hadoo 2.xで導入された新しいアプリケーションフレームワークにYARNがある。Hadoop 1.0を動かしていてさらにYARNを動かしたければ、通常は別のクラスタが必要だ。MapRではこれを1つのクラスタだけで動かせる。これにより運用コストの削減が可能となり、さらに古いアプリケーションフレームワークからの移行の際の手間とリスクを低減できる。
また一般にディストリビューションを利用する場合にはHadoopクラスタのバージョンを上げる際に、その上で動くエコシステムのアプリケーションもバージョンを上げなければならない。MapRでは、クラスタとエコシステムを別々に運用できるようにしている。そのため、クラスタをバージョンアップしても、必ずしも今動いているアプリケーションのバージョンを上げなくてもいいのだ。ユーザーは、安定したシステムを長く使い続けることが可能となる。
