NECは、ビッグデータ分析を高速化する分散処理フレームワーク「Feliss」を開発した（発表資料）。ビッグデータ分析でよく用いられるHadoopは、Map-Reduce型の単純な分析であれば高速に実行できるが、繰り返し演算を多用する機械学習処理では、ジョブ間でストレージを経由してデータをやり取りするHDFSがボトルネックとなり、演算の効率を上げにくい。
そこでNECのFelissでは、ジョブ間のデータのやり取りをインメモリーで実施するようにした。さらに演算ノード間の通信などにおいて、並列処理の際のメッセージパッシングのAPIとして一般的な「MPI」を同時に使えるようにした。これにより、機械学習のような複雑な演算について、通常のHadoopを用いる場合と比べて10倍ほど高速に実行できるようにした。FelissはHDFSのインタフェースを備えており、最初のデータ読み出しはHDFSから行える。
Felissの詳細について、開発を主導した同社グリーンプラットフォーム研究所 主任研究員の荒木拓也氏に聞いた。
現状のHadoopの何が問題か。
単純な分析処理であれば、Map-Reduce型のプログラミングモデルはうまく行く。しかし、Hadoopを機械学習などに応用しようとした場合、多数のジョブを組み合わせ、それらを反復的に処理する必要がある。ジョブ間のデータの受け渡しは、ストレージ（HDD）を用いるHDFSで行う必要があるため、これがボトルネックとなる。
Hadoopでは、あるタスクの計算を行うノードに障害などが発生した際、HDFSからデータを再び読み出し、別のノードなどで再計算することで耐障害性を高めている。このため、データ自体は永続性のあるストレージに格納する必要があった。
その課題にどう対処したのか。
単純に高速化するだけであれれば、ジョブ間のデータの受け渡しをHDFSのようなストレージ経由ではなく、メモリー経由にすれば済む。ただし、その場合、データの耐障害性が問題となる。データの受け渡しをメモリー経由にしてしまえば、計算ノードに障害が発生した場合、計算の途中結果が消えてしまう。これでは、それまでに実施した演算がムダになってしまう。
そこでメモリー経由であっても、計算の途中結果を一定頻度で自動保存できる技術を開発した。我々はこの技術を「継続（continuation）ベースのcheckpointing」と呼んでいる。
continuationというのは、LISP系言語の「Scheme」での「continuation」をヒントに命名した。ある時点において、これから継続される「残りの計算」という意味だ。プログラム全体のデータを保存するのと比べて、continuationベースであれば必要な部分のみ保存できるため効率的だ。
Felissでのcontinuationは、一種のタスクのような形で実装してある。continuationのプールが「タスクプール」のような形で用意されており、システム側はこのプールからcontinuationを一つずつ取り出して、ごく短時間だけ実行する。残りの演算は、再びcontinuationに変換され、プールに戻される。これを繰り返す。
プールにたまっているcontinuationは、実行されていない状態のため、シリアライズしてストレージに保存できる。保存動作はシステム側が自動で行う。保存の頻度は自由に設定可能だが、あまり短く設定すると、HDFSを用いるのと変わらなくなってしまう。実行するアプリケーションなどにも依存するが、例えば、1週間掛かる演算が途中の5日目で止まってしまったとすると被害は大きい。10分おきや1時間おきなどになるだろう。
Felissを使うプログラマは、continuationのプログラミングモデルで記述する必要があるということか。
そういうことだ。continuationの作成や、プールへの格納処理は、プログラムの切れ目の部分でプログラマが明示的に記述する必要がある。ある関数の関数ポインタと引数を渡して、continuationを作成する。ただし、代表的な機械学習アルゴリズムなどについては、将来的にはライブラリなどを用意するなどし、プログラマがcontinuation関連の詳細を記述しなくても済むようにしたい。また、MapReduceで処理する場合は、この処理はライブラリ側が行うため、プログラマが記述する必要はない。
