Hadoopを活用して実運用を成功させるためには、マスター記録システムとしてデータを保存し24時間365日アプリケーションを確実に稼働させるだけでなく、企業内のその他のデータアーキテクチャやツールと容易に統合ができる必要があります。MapRは卓越したアーキテクチャにより、それらを実現可能な唯一のディストリビューションです。


標準的なサーバを用いて高信頼性、高性能のクラスタを構築するにはエンジニアの多大な労力が必要です。クラスタノードの障害によってデータへのアクセスが失われたり、クラスタ上で動作するサービスが停止したりすることを防ぐだけではなく、全体的な処理性能への影響も抑えなくてはなりません。従来の企業向けのソリューションでは、不揮発性メモリやノード間に冗長なデータパスを作るための専用接続、RAID構成といった特殊なハードウェアを利用して可用性と性能を担保することが試みられてきましたが、それらの利用を前提としない標準的なサーバでは、より困難が伴います。

標準的なハードウェアで高い可用性を実現する一つの方法は、データを複製して複数の場所に格納する、レプリケーションを使うことです。クラスタは、通常の運用時には、受け取ったデータをできる限り高速に書き込んで複製することで読み取りの一貫性を保ち、さらにメタ情報とサービスの状態に関しても冗長性を持って確実に維持しなければなりません。一方、障害が発生した場合、複製データへのアクセスが復旧してデータの同期が取れるまでは、データ損失の危険に晒され続けることになります。平均データ損失時間 (Mean Time To Data Loss、MTTDL) はこの障害復旧のひとつの尺度であり、本質的に目標とすべきことは、クラスタ全体の性能と信頼性に影響を与えることなく、失った複製を速やかに再同期することによってMTTDLを最大化することです。

HDFS ソリューション

この課題に対してHDFSは別のアプローチを採用しています。HDFSはすべてを読み取り専用にすることによってこの重要な問題を完全に回避しています。確かにこれならば再同期は容易です。ファイルに書き込みが行われている間は、他からの読み出しは禁止され、書き込みを完了してファイルが閉じられたときに初めて読み出しが許可されます。障害が発生した場合には閉じられていないファイルは削除されます。このモデルでは、変更途中のデータは誰にも見えていないため、あたかもそのデータが始めから存在しなかったかのように、破棄しても問題ないということが仮定されています。

このアプローチはHDFSの元々の用途であったWebページ収集の目標は満たしていました。ダウンロードされたWebページが失われても、収集をやり直せばよいからです。しかし、企業のCIOやCFOが、あえてこのようなモデルを重要なビジネスに関する情報に採用するでしょうか。誰もそのデータを読み取っていない場合に、データは存在していなかったと断言できるでしょうか。答えは明らかに否です。

このHDFSの制限からは、さらにいくつかの別の問題が浮かび上がります。

HDFSではリアルタイム処理をすることができません。HDFSでデータを見ることができるようにするには、書き込み後ただちにファイルを閉じなければなりません。そのため、小さなデータを書き込んでファイルを閉じるプロセスを繰り返すことを余儀なくされるでしょう。問題は、この結果、あまりに多くのファイルを作ることになってしまうことです。HDFSはクラスタのメタ情報を1カ所で集中管理するアーキテクチャであり、大量のファイルの生成は大きな性能上、運用上の影響を及ぼします。

さらに、HDFSはNFS経由での読み書きを厳密にサポートすることはできません。NFSプロトコルにはファイルを「閉じる」という操作が存在しないためです。つまり、HDFSはいつファイルが閉じられるか、ということを推測することしかできません。もしこの推測が間違っていれば、データは失われます。 したがって、重要なファイルシステムの機能を維持しつつこの問題を解決するには別のアプローチが必要であるのは明らかです。

レプリカを高速にオンライン化する

2TBのディスクを12台搭載した、計24TBのディスク容量を持つサーバを想定します。1秒あたり1GBのデータ転送レートとすると、再同期には7時間ほどかかるでしょう。しかし実際にはスループットは毎秒200MB程度なので、35時間かかることになります。これをオンラインで行うとすると、再同期レートは10分の1に抑えざるを得ないでしょう。これは再同期に350時間 (15日) かかることを意味します。

それでは、平均データ損失時間 (MTTDL) はどうなるでしょうか。3年ごとに1回障害が発生するディスクを考えます。平均故障時間が3年ということです。次に、各ノードに10台のディスクを備えた100ノードのクラスタがあると想定します。このクラスタには1,000台のディスクがあることになります。1台のドライブが3年に1度故障すると考えると、ディスクの障害はほぼ毎日発生することになります。それでは二重ディスク障害または三重ディスク障害の発生まではどのくらいかかるでしょうか。再同期が完了するまでの15日間、本当に待つことができるでしょうか。その間、他の15台のディスクに障害が発生するのです。この再同期レートでは、データを失う可能性が非常に高くなることが予想されます。

従来のソリューション

この再同期の問題を回避するための従来のアプローチは、待機スペアデスク付きのRAID6で構成されたデュアルポートディスクを使用することです。デュアルポートディスクアレイは、それぞれのポートに1台ずつ、計2台のサーバと接続されます。サーバはNVRAM (不揮発性RAM) を使用してディスクを管理しています。プライマリサーバはNVRAMの内容を絶えずレプリカサーバにコピーします。プライマリサーバまたはレプリカサーバに障害が発生した場合、もう一方が動作を引き継ぎ、再同期は発生しません。ディスクが動作するためにはこれで十分だからです。このシナリオはうまく機能しますが、複数年に渡る保守パーツの用意に必要な高額な購入契約を締結しなければならないため、大規模な展開は難しいでしょう。

さらに、このソリューションは性能の点で問題を抱えています。データベースに接続したSANまたはNASと、そのデータベースに接続した多くのアプリケーションがあり、データは処理が行われる場所へ頻繁に転送されます。このような従来型のアーキテクチャでは、大規模な構成で高い性能を発揮することはできません。真に必要とされているのは、Hadoopのような分散ストレージと処理プラットフォームが統合されたアーキテクチャです。必要な機能はデータのある場所で処理が実行され、システムは限界まで (地理的に分散した場所までも) リニアにスケールします。

MapR ソリューション

MapR は通常のファイルアクセス機能を実装しており、書き込み後すぐにデータは見えるようになります。そして、標準的なハードウェアの利用に伴う、複製の再同期を高速かつ信頼性の高い形で行うために、MapR は新しいアーキテクチャを導入しました。

コンテナアーキテクチャ

MapRは各ノードのデータをコンテナと呼ぶ数千の要素に分割します。コンテナはクラスタ全体にレプリケーションされます。たとえば、100ノードのクラスタがあり、各ノードのデータを1,000の要素に分割して均一に分散させるとします。各ノードはすべてのノードのデータの100分の1ずつを保持することになります。

1台のサーバに障害が発生した場合、クラスタ全体で障害ノードのデータの再同期が行われます。この時の再同期の速度はどうなるでしょうか。クラスタの残りの99ノードが並列で処理をするため、1ノードで再同期を行う場合と比較して、99倍の数のディスク、イーサネットポート、CPU、VRAMモジュールを活用することができます。各ノードは100分の1のデータを再同期するため、正味のスピードアップは100倍になります。つまり、MTTDLは100倍改善します。もしクラスタのサイズがもっと大きくなれば、MTTDLはさらに改善します。1,000ノードのクラスタでは、MTTDLの改善は実に1,000倍になるのです。

より極端な状況での再同期

より極端な状況においてもMapRは高速でコンテナを再同期することが可能です。たとえば、図の3つのコンテナを見てみましょう。 これらのコンテナの複製は、始めは同期された状態です。1つのコンテナに障害が起きた場合は、他のコンテナから最新の状態に更新してやればよいだけであり、特に難しい問題ではありません。しかし、しばらく運用が続いた後、3つが同時に障害に見舞われたときはどうなるでしょうか。クラスタ内では同時に様々な操作が行われているため、3つの複製が別々の状態に分岐してしまう可能性が非常に高いでしょう。したがって、復旧したときにどれがマスター(複製の基準)になるべきかが問題となります。

ここでの問題は、どの複製が障害後に生き残るかを事前に予測することは不可能ということです。したがって、どの複製も新しくマスターになれるようなしくみが備わっていることが求められます。MapRのイノベーションおよび特許の核心は、この非常に難しいコンピュータサイエンスの問題を解決したところにあります。

基本的に、応答を返したすべての書き込みは、障害後も存在することが保証されなければなりません。MapRは、更新レートがたとえ毎秒2GBであっても、複製が分岐した時点を正確に検出することができます。MapRは3つの複製のいずれか一つを新しいマスターとしてランダムに選択し、その他の残っている複製を分岐時点までロールバックし、その後、選択したマスターに合わせてロールフォワードすることが可能です。MapRはこの動作を稼働中に、通常の運用にはほとんど影響を与えることなく実行することができます。これはきわめて難しいことなのです。

コンテナアーキテクチャの活用

MapR はアーキテクチャにおけるイノベーションを活用し、一連のユニークな機能をHadoopユーザに提供します

NameNode の無いアーキテクチャ

MapRのコンテナアーキテクチャは、NAS、SAN、HDFSと比較して、メタ情報の扱いに多くの優れた点があります。従来のNameNodeで管理されていたデータは、MapRではクラスタ全体に分散して格納されます。また、NameNode内に存在した機能すべて (下の図の左側のグレーの部分) を通常のクラスタノードに移動しました。MapRディストリビューションの「No NameNode」 ソリューションによってすべてが三重化され、極めて信頼性が高くなっています。NameNodeがなくなったことにより、MapRに格納できるファイル数の上限は実質的に取り払われ、エクサバイトの規模まで拡張できます。さらに、この方式はコスト削減にも大きく貢献します。HDFSではファイル数の上限を増やすために複数のNameNodeを用意し、NameNodeの可用性を高めるために複数のアクティブ/スタンバイサーバを構成する必要がありましたが、MapRではこれらの追加ハードウェアは不要になるからです。

真の高可用性クラスタ

すべてのHadoopコンポーネントも高可用性の恩恵を享受できます。たとえば、Apache YARNでは、ApplicationMaster (旧Job Tracker) や TaskTrackerは、常に状態をMapRファイルシステムに記録します。ノードに障害があった場合、ApplicationMasterはMapRファイルシステム上の情報から状態を復旧させます。つまり、MapRは、すべてのジョブを障害発生時の状態から再開させることができます。これはクラスタ全体を再起動した場合にも同様に動作します。もし全体の80%まで進んだところでクラスタが障害でダウンしても、80%の状態からジョブを継続することが可能です。

MapRディストリビューションが提供する独自の高可用性機能は、開発者も自身のコードで容易に利用することができます。サービスの状態とデータをMapRファイルシステムに保存し、Zoookeeperを使用してサービスの障害を通知し、いずれかのノードでサービスを再起動します。データとサービスの状態は自動的にそのノードに移動します。Impala、Hive、Oozie、Storm、MySQL、SOLR/Lucerne、Kafkaも高可用化されており、これはMapRでのみ実現されています。ここで重要なのは、このしくみはHadoopエコシステムの各プロジェクト向けの1回限りのソリューションではなく、共通のインフラ基盤であり、開発者のプログラムで利用できるのと同様に、Hadoopのあらゆる要素でメリットを享受できます。

性能と規模の比較

下の図は、NameNodeの性能を計測するベンチマークの結果です。このベンチマークでは、ファイルを生成し100バイトを書き込んで閉じるという操作を繰り返し行う処理をします。ここではHDFSがリアルタイム動作をしようとする場合の問題が明確に示されています。このテストは、10ノードのクラスタで実施されました。青い線がMapRの性能で、下のほうの赤い線がHDFSベースのディストリビューションの性能です。X軸が作成したファイルの累積数、Y軸が1秒あたりに作成されたファイルの数です。MapRの性能は他のディストリビューションの約40倍です。仮にHDFSの性能が2倍、3倍、4倍になったとしても、MapRは1桁高速ということになります。

ジョブの処理性能に関しては、MapRはMapReduceの世界記録を持っています。TeraSortは1TBのデータをいかに早くソートできるかのベンチマークです。MapRは45秒という最新の記録を保持しています。また、MinuteSortは1分間でどれだけの量をソートできるかを測定するベンチマークです。MapRはここでも世界記録を持っています。

MapR NFSによるデータの直接投入

MapRのアーキテクチャは、読み書き可能なファイルシステム機能を持ち、クラスタアクセスのために標準のNFSインターフェースを提供しています。これによって、特別なコネクタを必要とせずにクラスタにデータを直接投入することができるようになります。Webサーバであろうと、データベースサーバであろうと、あるいはアプリケーションサーバであろうと、データを直接MapRに高速に書き込むことができます。MapRは完全な高可用性を持つ巨大なNFSサーバとして利用することができます。これによりデータをHadoopに投入するために使っていた時間と労力を節約して、これまで必要だった中間的な手順を取り除くことができます。

MapR M7 Enterprise Database Editionのテーブル機能

MapR M7 Enterprise Database Edition では、Apache HBaseとバイナリ互換のデータベーステーブル機能を組み込んでいます。HBaseとは別のパス名を指定するだけで容易にアクセスすることができます。M7の特徴は、テーブルをストレージシステムに統合している点である。テーブル機能はコンテナアーキテクチャ上に構築され、すべてのノードで常時利用可能な状態にあり、100%のデータローカリティを提供しています。データベーステーブル特有の管理操作は不要で、管理できるテーブルの数は事実上無制限です。さらに重要な点は、MapRはデータ更新を即時に完了させるため、コンパクション(格納ファイルの再構築処理)が発生しないことです。その結果、HBaseと比較して約5倍のスループットと安定した低レイテンシーを得ることができます。

まとめ

MapRは、頑強な基盤アーキテクチャのおかげで、Hadoop市場においてテクノロジーリーダーの位置を占めています。これはソフトウェアパッチの追加では作り上げることができません。何年にも渡り、HDFSを基盤とする他ディストリビューションでは、個別最適の手法でMapRプラットフォームが提供する重要な機能への追随が試みられてきました。NameNodeの高可用性ソリューションやJobTrackerの別の高可用性のしくみ、さらに全く異なるHBaseの高可用性アーキテクチャなどです。さらに、エンタープライズ分野で求められる基本的な機能への対応も試みられていますが、未だ不完全なものです。例えば、スナップショット機能では、特定時刻の一貫性のあるデータの復旧ができず、NFSアクセスに関しては低速な読み出しにしか利用ができません。

常時稼働し、最高の性能を発揮し、かつ容易に運用できるということがビッグデータプラットフォームに求められています。そのようなプラットフォームの実現のためには、やはりアーキテクチャの選択が非常に重要です。低コストの標準的なハードウェアを活用して、障害からの即時復旧、スナップショットやミラーリングによるデータ保護、単一障害点の排除といったエンタープライズ向け機能を提供し、Hadoopの標準インターフェースに加えNFSやODBCといった標準プロトコルに対応できるアーキテクチャを備えているHadoopディストリビューションは、唯一MapRのみです。