ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.23
  6. 2.技術トレンド

Internet Infrastructure Review（IIR）Vol.23
2014年5月28日発行RSS

目次

3.2 ビッグデータ解析基盤の技術動向：リアルタイム化

前述のようなM2M、IoT、CPSのコンセプトに基づくデバイスネットワークから生成されるビッグデータの解析には、即時性が求められることは自明ですので、必然的にビッグデータ解析基盤は、リアルタイム解析の要請に応えなければならなくなります。

ビッグデータ解析の基盤技術と言えば、特にMapReduceに基づく分散処理基盤の技術を思い浮かべる方々が多いかと思いますが、バッチ処理を前提として設計されたMapReduceのアーキテクチュアをリアルタイム解析に適用するには困難が伴います。バッチ処理ではジョブが終了するまでに処理結果が確定しないので、処理時間分の遅延が発生してしまいます。この時間を縮小する対策としては、まず処理そのものの最適化・高速化を図ることになりますが、自ずと限界があります。次なる対策としてはバッチ処理のサイズを小さくしていくことになりますが、あまり小さくしてしまうとバッチ処理として意味をなさなくなってしまいます。通常、MapReduceジョブは数分から数時間という処理時間を要することが一般的ですが、これをウェブサービスで許容される応答時間の数秒程度まで時間短縮することは事実上不可能だと言えるでしょう。

ビッグデータ解析基盤のリアルタイム化の研究では、2つのアプローチが検討されてきました。その1つは、「ユーザのリクエストにリアルタイムで応答する」アプローチで、この場合「MapReduceの基盤そのものを機能強化」して応答性能を向上させるケースと、「MapReduceを内包する基盤システム」として考えて、内部的にはMapReduceを利用しつつ、それ以外のところで応答性能の向上を図るケースがあります。もう1つは、「実際に実時間でデータ処理を実行する」、いわゆる「リアルタイムストリーム処理」を実現する基盤技術を用いるアプローチで、この場合はMapReduceに置き換わる形になります。

「MapReduceの基盤そのものを機能強化」の事例としては、MapReduce Online（※4）があります。この事例ではHadoopを大幅に改造してMap処理とReduce処理の間のデータの受け渡しのパイプライン化を図っています。この機能拡張によりユーザは処理中のジョブの状態を詳細に把握する、すなわちイベントモニタリングが可能になります。また、MapReduceアプリケーションでストリーム処理を記述することが可能です。

「MapReduceを内包する基盤システム」の事例としては、GoogleのDremel（※5）のアイデアを踏襲する2つのオープンソース・クローン「Apache Drill（※6）」と「Cloudera Impala（※7）」が上げられます。いずれも、リアルタイムでのデータ処理を行っているわけではありませんが、それに匹敵する低遅延でのクエリー応答性能を発揮します。

「リアルタイムストリーム処理」の事例としては、Apache Storm（Twitter Storm）（※8）があります。Stormは元々Twitterの分析を行っていたBackType社が開発したシステムですが、Twitter社によるBackType社の買収にともなってApache Project経由でオープンソース化された経緯がありますが、それ自体は汎用のビッグデータ処理基盤です。

Stormは、Complex Event-Processing（CEP）を実現するストリームエンジンが搭載されており、Spout/Boltと呼ばれるビッグデータ処理を行うエンティティに欠損のないデータストリームの供給を保証します。Stormでのストリームは、Tupleと呼ばれるデータ単位のフローで表現され、SpoutとBoltを繋ぎ合わせるTopolozyを定義することにより、ストリーム処理全体を記述します。Spoutはデータソースを表現するエンティティであるのに対し、Boltはデータの変換・加工を司るエンティティです。定義や機能は全く異なりますが、MapReduceにおけるMap及びReduceを想像すると理解しやすいでしょう。

StormもHadoopと同じようにクラスタを構成することが可能で、Nimbus、Zookeeper、Supervisor、Workerの4種類のソフトウェアが動作します。Nimbusは、Workerのスケジューリングやモニタリングを司るマスター、Zookeeperは、Hadoopでも使用されている分散ロックマネージャ、SupervisorはNimbusからのリクエストを受け付けWorkerの起動・停止を制御し、Workerは、実際の処理を実行するプロセスとして機能します。これらのソフトウェアをクラスタ内のノードに適切に配置することにより、高いスケーラビリティや耐障害性を実現しています。Storm自身は、Clojureと呼ばれるLISPライクな言語で記述されていますが、JavaVMの上で動作します。従って、JavaをはじめとするJavaVMの上で動作する各種の開発言語を使ってSpoutやBoltを記述することができます。

以上、ビッグデータ解析基盤のリアルタイム化に関する課題と幾つかの事例を紹介してきましたが、Apache Stormの登場をリアルタイムビッグデータ解析基盤のデファクトスタンダード化のトレンドと捉える見方が増えているように思えます。やはり、Hadoop（MapReduce）と共通するシンプルなプログラミングモデルとTwitter分析での実績は、汎用的なプラットフォームに期待される要件でしょう。

では、StormはHadoopに置き換わるオープンソースのビッグデータ解析基盤になるのでしょうか？この質問に対する答えは、「両者による棲み分けが進む」ということになりそうです。というのも、すべてのビッグデータ解析が即時性を求められる訳ではないからです。前述のような、即時応答を求められるビッグデータ解析の需要は、Stormに置き換わって行くでしょうが、従来のバッチ処理で十分（あるいはそれが必要）な需要にはHadoopが使われ続けることになるでしょう。またHadoopでの解析の前処理（データの整形、フィルタリング、マッチング）にStormを活用したり、ラムダアーキテクチュアと呼ばれるバッチ処理とストリーム処理を組み合わせたハイブリッドなシステム構築法も提案されています。現時点では、両者は相互補完の関係にあるという理解が一般的なようです。

3.技術トレンド

ページの終わりです

ページの先頭へ戻る