DEIM Forum 2016 G8-2

Apache Storm を用いたリアルタイム動画像データ解析フレームワークの性能解析
黒崎裕子†

竹房あつ子††

中田 秀基††

小口 正人†† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2–1–1†† 産業技術総合研究所 〒 305–8560 茨城県つくば市梅園 1–1–1
E-mail: †yuko-k@ogl.is.ocha.ac.jp, ††{atsuko.takefusa,hide-nakada}@aist.go.jp, †††oguchi@computer.org
あらまし

カメラやセンサ等が手軽に利用できるようになり，一般家庭やオフィスビルでもデータを取得して，防犯対策，お年寄りや子供のための安全サービスを目的とした動画像解析アプリケーションが数多く開発されている．それらのアプリケーションは一般的にクラウドで全ての処理が行われている．しかし，動画像を含む多数のセンサデー
タをクラウドに送信して画像の特徴抽出等の前処理から解析まで，全ての工程をクラウド側で行うと，各センサとクラウド間のネットワーク帯域やクラウド側の資源の制限により，リアルタイムに処理できない可能性がある．我々は，動画像解析処理全体の高速化を目的として，負荷分散機能をもつ分散型リアルタイム計算基盤である Apache Stormを導入し，前処理をセンサ側とクラウド側で負荷分散させた．本研究では，提案フレームワークの性能について，より詳しく解析する．解析結果より，処理スレッド数が多い環境において，スレッドのポーリング間隔を調整することで，性能が向上することがわかった．
キーワード

ストリーム処理，Apache Storm，リアルタイム処理，性能評価

Performance Evaluation of a Real-time Video Stream Analysis
Application Framework Using Apache Storm
Yuko KUROSAKI† , Atsuko TAKEFUSA†† , Hidemoto NAKADA†† , and Masato OGUCHI†† Ochanomizu University Otsuka 2–1–1,Bunkyo-Ku, Tokyo 112–8610, Japan†† National Institute of Advanced Industrial Science and Technology (AIST) 1-1-1 Umezono, Tsukuba,
Ibaraki 305–8560, Japan
E-mail: †yuko-k@ogl.is.ocha.ac.jp, ††{atsuko.takefusa,hide-nakada}@aist.go.jp, †††oguchi@computer.org

1. は じ め にわちクライアント側にある程度の機能を持たせ，クラウド側の処理を軽減するファットクライアントと呼ばれるパラダイムが近年ではカメラやセンサ等を手軽に利用できるようになり，注目されている．また，ユーザと物理的に近く配置された小規

一般家庭でライフログを取得して，防犯対策やセキュリティ，模なエッジサーバと連携してクラウドの負荷を軽減しつつサー

お年寄りや子供のための安全サービスを目的としたライフログ

ビスの応答遅延を減らすことを目指したエッジコンピューティ

解析アプリケーションが数多く開発されている．それらのアプ

ング [1] や，クラウドとデバイスの間に分散処理環境を置くこ

リケーションを一般家庭で採用する場合，サーバやストレージとにより，クラウドへの一極集中を防ぐフォグコンピューティを設置して解析までを行うことは難しいため，クラウドでの処

ング [2] が提案されている．

理が必要となる．しかし，センサとクラウド間のネットワーク我々は，前処理をセンサ側とクラウド側で負荷分散させるこ

帯域やクラウド側の資源の制限により，クラウドに動画像を含とで，動画像解析処理全体の高速化を図る．負荷分散機能をもむ多数のセンサデータを送信し，特徴抽出等の前処理から解析

つ分散型リアルタイム計算基盤 Apache Storm(以降，Storm とまでの全ての工程をクラウド側でリアルタイムに行うことは困呼ぶ) [3] を導入し，センサ・クラウド間で負荷分散を行う動画難である．

像データ解析フレームワークを実装した．既発表研究 [4] では，クラウド側で全ての処理を行う方式に対し，センサ側，すな大規模クラスタ環境においてネットワーク帯域を考慮した実験を行い，低帯域環境においてセンサ・クラウド間の負荷分散が有効であることがわかった．

tuple

tuple
bolt

spout

本研究では，提案フレームワークの性能について，使用している Apache Storm に焦点を当ててより詳しく解析する．解

boltboltboltspout析結果より，処理スレッド数が多い環境において，スレッドのboltポーリング間隔を調整することで，性能が向上することがわかった．

topology

2. 関 連 技 術

図 1 Topology の流れ

我々が開発しているアプリケーションでは，前処理のセンサ側とクラウド側の負荷分散の基盤として Storm を，クラウドず，MIX という処理の中で学習後のモデルのみを緩やかに共有側の解析にはオンライン機械学習フレームワーク Jubatus を使することで，並列分散処理を可能にしている．

用する．以下に各ソフトウェアの概要を述べる．

Jubatus は解析の時に Datum という key-value データ形式

2. 1 Apache Stormを用いる．Datum には 3 つのタイプの key-value が存在する．

Storm は，Back Type 社によって開発された分散型のリアル

value が文字列の文字列データ，value が数値の数値データ，タイム計算システムである [3]．現在は Twitter 社に買収されてvalue が任意のバイナリデータがあり，key は 3 タイプとも文字おり，Twitter でのつぶやきのリアルタイム解析に用いられて列である．バイナリデータには画像や音声などのマルチメディいる．Apache Hadoop はバッチで大規模処理を行うのに対し，アデータなど，任意のバイナリデータを入れることが可能であStorm はリアルタイムでの分散処理に特化している．また，同る．この 3 つのデータから，機械学習を行う際に必要となるじストリーム処理フレームワークに Apache Spark [5] がある．

特徴量を Jubatus のデータ変換モジュールが抽出する．また，ストリーム処理を 1 秒間に受信したイベント群に対するバッチ

Jubatus の特徴ベクトル変換器は，この特徴抽出処理を JSON処理の連鎖としてバッチ処理の性質を保ったまま実行するのが形式ファイルでカスタマイズすることが可能であり，特徴抽出

Spark の特徴であり，スループットは向上するものの，遅延は器にはプラグインを利用することができる．プラグインは動的0.5〜2.0 秒程発生するため純粋なストリーム処理より遅くなっライブラリファイル (.so ファイル) からなり，JSON 形式ファてしまう [6]．

イルでパスを通すことによって利用可能である．

Storm は，図 1 のような Spout と Bolt からなる Topologyと呼ばれるネットワーク構造を，Storm クラスタで指定するこ

3. 動画像データ解析フレームワークとによって処理を行う．Spout とは，Steam を流し始める処理

本節では我々が提案する動画像データ解析アプリケーションの起点となるプロセスで，Bolt は流れてくるデータの変換処理

フレームワークの設計概要について説明する．動画像データ解を行うプロセスを指す．Stream は，Tuple の無限の連続であ析は，基本的に (1) 画像の取得，(2) 特徴量抽出 (前処理)，(3)り，標準データ型を表したり，シリアライズ・コードを追加し機械学習処理の 3 つのステップからなる．クラウド側で全てのたユーザ定義型を表したりすることができる構造体のようなもセンサデータを収集して処理を行う場合は，センサ側で (1) ののである．

処理を行った後，動画像を含むセンサデータをクラウドに送信

ま た ，Storm ク ラ ス タ は ，Master Node，Slave Node，してクラウド側で (2)，(3) の処理を行う．一方，クラウド側処

ZooKeeper から構成される．Master Node 上には Nimbus と理の負荷の軽減と，センサとクラウド間のデータ転送量を削減呼ばれるデーモンを走らせる．Nimbus は主に Slave Node へのする場合，(1)，(2) をセンサ側で行い，特徴量データのみをクタスクの割り振りを行っている．Slave Node 上には Supervisor

ラウド側に送信して (3) の処理を行う．と呼ばれるデーモンを走らせる．Supervisor 上には，Supervi-sor を起動する際に指定した数だけ Worker スレッドが立ち上

3. 1 動画像データ解析フレームワークの設計実装したアプリケーションは次の 3 つのプロセスに分かれてがる．Topology を受け取った Nimbus は，各 Supervisor 上のいる．

Worker スレッドに Spout スレッド，Bolt スレッドを割り振り，（ 1 ） WEB カメラからのキャプチャ処理を実行する．Zookeeper は，Storm クラスタのノード間の（ 2 ） Bag-of-Features を用いた特徴抽出

状態管理，同期に用いられている．

（ 3 ） Jubatus での解析

2. 2 オンライン機械学習 Jubatus
Jubatus とは，NTT SIC と Preferred Infrastructure により以下に各プロセスの詳細について述べる．

3. 1. 1 WEB カメラからのキャプチャ

共同開発された，オンライン機械学習フレームワークである．

まず，データストリームの起点となるセンサ側に，WEB カ

本来トレードオフの関係であった「ストリーム (オンライン) 処

メラからのキャプチャ部分を実装する．OpenCV [8] を用いて理」「並列分散処理」「深い解析」の要素を満たすオンライン機

WEB カメラから画像を取得し，取得した画像を構造体に格納

械学習フレームワークである [7]．オンライン機械学習をそのまし，(2)Bag-of-Features を用いた特徴抽出処理を行うプロセス

ま分散処理すると同期コストが大きくなるという問題が生じるとなる Bolt に，構造体を渡す．

が，Jubatus では，UPDATE の処理ではデータ自体は共有せ3. 1. 2 Bag-of-Features を用いた特徴抽出
2 つ目のプロセスが，OpenCV を用いた特徴量の抽出と BagApache Storm

of-Features [9] による画像データのベクトル化である．ベクト
ル化したデータを，ネットワークを介して，(3)Jubatus での解Jubatus(2) Feature
Extraction(1) Getting Image(2) Feature
Extraction

析プロセスに転送する．

(3) Analysis

Bag-of-Features とは，画像から得られた局所特徴量の集合(1) Getting Image

から，あらかじめ複数画像の特徴量データから K-means 手法(3) Analysis(2) Feature
Extraction

を用いて特徴量をクラスタリングした辞書データをもとに，各グループに属する特徴量をもつ特徴点の数をヒストグラム化す(3) Analysis(1) Getting Image(2) Feature
Extraction

る手法である．Bag-of-Features の抽出手順は以下のようになる．まず，OpenCV を用いて画像から局所特徴量を抽出する．

(2) Feature
Extraction

Client Side

Cloud Side

局所特徴量にはいくつか種類があり，中でも有名な SIFT は，照明変化や回転，拡大縮小に不変な頑強な特徴量である．その図 2 提案するフレームワーク

SIFT より認識精度は少し落ちるが，特徴点検出の処理を軽量化，高速化したものが SURF である．本研究では，局所特徴量に SURF 特徴量を用いた．SURF では keypoint と呼ばれる画像中の特徴的な点をいくつか抽出する．各 keypoint は 128 次

解析結果が送信される．

3. 2 Storm を用いたフレームワークの実装

元の特徴ベクトルとなるが，抽出される keypoint の数は画像

動画像データ解析アプリケーションはリアルタイム処理であによって異なるため，画像全体の特徴ベクトルとして機械学習ることから，負荷の高い処理を適宜並行実行して高速化を図るでそのまま使用するのは困難である．局所特徴量をクラスタリ必要があるため，分散型リアルタイム計算基盤の Storm を導ングして各クラスタの中心ベクトルを Visual Word と呼ばれる入した．本研究では，図 2 に示すようにセンサ側およびクラウ特徴的なパターンとし，辞書を作成する．この辞書を使ってあド側で前処理を負荷分散処理するフレームワークを実装した．

る画像から抽出された特徴ベクトル群を Visual Word にマッチ

3.1 節で説明した (1) はセンサ側，(2) はセンサ側とクラウド側させ，画像全体の特徴パターンの頻度をヒストグラムで表現すで処理される．また，(3) の処理はクラウド側で行われるようる．このヒストグラムを Bag-of-Features と呼ぶ．一度辞書をにした．(2) の処理を全てセンサ側で行う場合は，クラウドへ作成してしまうと，Visual Word 数は一定であるため，各画像の通信量は少なくなるものの，前処理の負荷が大きくなる．(2)の特徴量を同じサイズのベクトルデータに変換することができの処理をセンサ側とクラウド側の両方で行う場合は，クラウドる．次に，生成したベクトルデータを Jubatus で扱う形式に変で処理する場合は前処理の負荷が分散できるものの，クラウド換する．2.2 節より，Jubatus は解析時に Datum というデータへの通信量が大きくなり，そのオーバーヘッドによる性能劣化形式を使用する．よって，作成したヒストグラムを Datum にが懸念される．

変換する．ヒストグラムの各値を 1 つずつリスト形式で Datum

既存研究 [4] では，大規模クラスタ環境においてネットワーに格納し，Jubatus へ転送可能なデータに変換する．最後に，ク帯域を考慮して提案フレームワークが有効かどうか評価実験

Jubatus サーバとコネクションを確立し，画像から取得した特を行った．実験結果より，低帯域環境においてセンサ・クラウ徴ベクトルの格納された Datum を Jubatus サーバへ転送する．

ド間の負荷分散が有効であることがわかった．

3. 1. 3 Jubatus での解析
Jubatus では分類，推薦，線形回帰などいろいろな解析が可能であり，今回は Classifier API を用いて学習と分類を行う．
ライフログ解析を行う前に train API を利用し，予め教師あり学習を行う．その学習結果を用いて分類するには，classifyAPI を利用する．Jubatus サーバに送られてきた Datum はフィルタ，特徴抽出という 2 段階のデータ変換を経て解析される．フィルタ処理では，学習に不要なものを取り除き，特徴抽出では，フィルタされたデータから特徴を抽出する．フィル
タ処理でデータからどのような要素を取り除くか，特徴抽出でどのアルゴリズムを使用し，どのように重み付けをするかは，サーバ起動時に指定する JSON ファイルで設定することが可能である．今回はフィルターはデフォルトを利用し，特徴抽出では与えられた数値をそのまま重みに利用する．分類に使用するアルゴリズムには Adaptive Regularization of Weight vectorsを選択した．学習に対する感度パラメータは 1.0 に設定する．

Jubatus サーバで 2 段階のデータ変換を終えた後，解析され，4. 提案フレームワークの性能解析
提案フレームワークの性能をより向上させるため，以下の 2点に関して Storm の性能解析を行った．
（ 1 ） Spout 数の変化に伴う性能解析（ 2 ） スレッドのポーリング間隔の変化に伴う性能解析
各実験では経過時間あたりに完了したジョブ数を比較する．

4. 1 実 験 概 要
実験では，実装したフレームワークを用いて２種類の人の行動を判別する．予め 320 × 240 ピクセルの画像を 100 枚を用いて「ドアを開けた」状態と「イスに座った」状態を学習させる．次に，画像データを Spout で定義するストリーム生成時間毎にランダムに選出し，選出された画像データの特徴量抽出を行う．特徴量抽出における Visual Words 数は 100 に設定した．
構 築 し た Storm ク ラ ス タ は 図 3 の よ う な 構 成 を と る ．
セ ン サ 側 計 算 機 ，ク ラ ウ ド 側 計 算 機 と も に ，Intel Xeon

W5590((3.33GHz，4 コア) × 2 ソケット) を使用した．Su-40000

default(bolt×24)

35000

sleep 1ms(bolt×24)

Number of JOBs

30000

Supervisor
node

Nimbus node Supervisor Supervisor ZooKeeper
Supervisor node
nodenode

Cloud SideSensor Side

default(bolt×16)
sleep 1ms(bolt×16)

25000
20000
15000
10000
5000
00

50

100

150

200

250300Time [sec]

図3

実験環境

図 5 異なるポーリング間隔，Bolt 数における処理ジョブ数の比較

50000
45000

Number of JOBs

40000
35000

5ms/tuple, Spout×2必要があり，そのための監視であると考えられる．この Sleep

5ms/tuple, Spout×4

時間を default 時の 100ms から 1ms に短縮させた場合，どの5ms/tuple, Spout×6ような性能差が出るかを解析した．Spout スレッド数を 4，ス10ms/tuple, Spout×2

30000
25000
20000

10ms/tuple, Spout×4

トリームデータの生成速度は 10ms/tuple とし，Bolt スレッド10ms/tuple, Spout×6数を 16，24 と変化させた．Sleep 時間は default の 100ms と1ms の場合で計測を行った．

15000

実験結果は図 5 に示す．縦軸は処理した総ジョブ数を表し，10000

横軸は経過時間を秒で表している．Bolt 数 16 の場合は，ジョブ5000
0050

100150200250300Time [sec]

図 4 異なる Spout スレッド数，データ生成速度における処理ジョブ数の比較

数の変化は見られなかったが，Bolt 数が 24 の場合，性能向上がみられた．これは，十分な処理スレッド数がある場合，Sleep時間が短いほうが処理の持ち時間が少なくなるためと考えられる．よって，Sleep 時間を短くすることによる性能向上が期待できることを示された．

pervisor ノードを 4 台用意し，1 台がセンサ側，3 台がクラウ

5. 関 連 研 究

ド側計算機であると想定する．Supervisor ノードには worker

クラウド技術を用いた動画像データ解析は，近年数多く研究をコア数に合わせて 8 つずつもたせ，Supervisor ノードの 4 台されているが，クラウド上での効率的な動画像データの内容検のうち 1 台は Nimbus ノードとしても機能させ，クラウド側に索や，クラウドプラットフォームを使用した動画像データのオ配置する．また，クラウド側に Zookeeper を稼働させた計算機

ンデマンドシステムにおけるロードバランスに焦点が当てられを 1 台用意した．ていた．既にストリーム動画像データの検出，追跡，解析を行

4. 2 Spout 数の変化に伴う性能解析

う内蔵システム [10] や，人々の異常行動の追跡や活動の検出すSpout スレッド数の変化に伴う性能解析を行った．Spout スる自動監視システム [11] が開発されているが，これらは 1 ノー

レッド数を 2，4，6 と変化させ，ストリームデータの生成速ド上で動作するシステムとして開発されており，スケーラビリ

度は 5ms/tuple と 10ms/tuple とし，Bolt スレッド数を 24 とティについて考慮されていない．

する．

Abdullah ら [12] は，クラウド上で動画像データの取得，処実験結果は図 4 に示す．縦軸は処理したジョブ数の合計を理，解析を行うストリーム処理フレームワークを構築している．

表し，横軸は経過時間を秒で表している．実験結果より，計時間のかかる高画質の画像処理を GPU を用いることで高速化

算上同じストリーム量 (spout × 4, 10ms/tuple と spout × 2,し，クラスド上でのスケーラブルなフレームワークを提案して5ms/tuple) を流した場合，スレッド数が少なく，かつ速度がいる．大量の動画像データを扱い，スケーラビリティを考慮し速い方が性能がよいことがわかった．これはスレッドが増える

たフレームワークの設計は本研究と近いが，全ての処理をクラことによるスレッド切り替えオーバーヘッドがボトルネックにウド上で行っているのに対し，本研究はファットクライアントなったと考えられる．

モデルを採用している点で異なる．

4. 3 スレッドのポーリング間隔の変化に伴う性能解析

ま た ，Storm の 高 速 化 を 目 指 し て Twitter 社 は Apache

スレッドのポーリング間隔の変化に伴う性能解析を行った．

Heron(以降，Heron と呼ぶ) を開発した [13]．Storm では Mas-

Storm では Spout および Bolt スレッドが Topology が active

ter Node が多くの機能を持っており，負荷が集中し，ボトルネッかどうか，Spout スレッドが active かどうか定期的に判断し，クになっていた．Heron では，Topology 毎に Storm におけるactive になければ Sleep する実装になっている．これは，StormNimbus にあたる Topology Manager を持たせ，各 Topologyはストリーム処理であるため，常にスレッドが動作しているが互いに独立して管理されるようにすることで，ボトルネックを解消した．また，大規模な Topology において，高いスループットと低レンテンシを両立しており，Storm よりも高性能なフレームワークとなっているが，まだ公開されていない．

6. まとめと今後の課題
本研究では，動画像データ解析アプリケーションのリアルタイム処理を実現するため，Storm を導入して，センサ側およびクラウド側で前処理を負荷分散処理する動画像データ解析フレームワークを設計，実装している．提案フレームワークの性能について，使用している Apache Storm に焦点を当ててより詳しく解析した結果より，処理スレッド数が多い環境では，スレッドのポーリング間隔を調整することで，性能が向上することがわかった．
本研究では，一定速度のストリームデータを対象に実験を行ってきたが，実環境では，動体検知した時に動画像解析を行うため，ストリームデータ量が変動することが考えられる．今後は，このような大きく変動するストリームデータに対応できるよう，適切な負荷分散手法を開発する．

謝辞

この成果の一部は，国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) の委託業務の結果得られたものです．
文献[1] Milan Patel，Brian Naughton，Caroline Chan，Nurit Sprecher，
Sadayuki Abeta，Adrian Neal, Mobile-edge computing ，ETSI, Tech. Rep., 09 2014．
[2] Flavio Bonomi, Rodolfo Milito, Jiang Zhu, and Sateesh
Addepalli, Fog computing and its role in the internet ofthings, in Proceedings of the First Edition of the MCC
Workshop on Mobile Cloud Computing, ser. MCC 12.
ACM,2012, pp. 13–16.
[3] Apache Storm，https://storm.apache.org/[4] Yuko Kurosaki, Atsuko Takefusa, Hidemoto Nakada, asatoOguchi， A Study of Load Balancing between Sensors andthe Cloud for a Real-Time Video Streaming Analysis Application Framework ，IMCOM2016, Danang, Vietnam, January 2014.
[5] Apache Spark，https://spark.apache.org/[6] Matei Zaharia，Tathagata Das，Haoyuan Li，Timothy
Hunter，Scott Shenker，Ion Stoica， Discretized Streams:
A Fault-Tolerant Model for Scalable Stream Processing ，Electrical Engineering and Computer Sciences，
UCB/EECS-2012-259，2012．
[7] オンライン機械学習向け分散処理フレームワーク
Jubatus，http://jubat.us/ja/[8] 画像ライブラリ OpenCV，http://opencv.org/[9] Tomoyuki Nagahashi, Hironobu Fujiyoshi， Object Category Recognition by Bag-of-Features using Co-occurrence
Representation by Foreground and Background Information ，Machine Vision Applications，pp.413， 2011．
[10] B. S. System, IVA 5.60 intelligent video analysis ，BoshSecurity System, Tech. Rep.，2014．
[11] Project BESAFE，http://imagelab.ing.unimore.it/besafe/.
[12] Tariq Abdullah，M Fahim Tariq，Yusuf Baltaci and Nick
Antonopoulos， Traﬃc Monitoring Using Video Analytics inCloudsTraﬃc Monitoring Using Video Analytics in Clouds ，7th International Conference on Utility and Cloud Computing，pp.39-48，2014．
[13] Sanjeev Kulkarni，Nikunj Bhagat，Maosong Fu，VikasKedigehalli，Christopher Kellogg，Sailesh Mittal，Jignesh
M. Patel，Karthik Ramasamy，Siddarth Taneja， Twitter
Heron: Stream Processing at Scale ，The 2015 ACM SIGMOD International Conference on Management of Data，pp.239-250，2015．