ファットクライアント型リアルタイム動画像解析 アプリケーションフレームワークの提案 黒崎 裕子1 竹房 あつ子2 中田 秀基2 小口 正人1 概要：一般家庭でカメラやセンサ等によりライフログを取得して，防犯対策やセキュリティ，お年寄りや 子供のための安全サービスを目的としたライフログ解析アプリケーションが数多く開発されている．それ らのアプリケーションを一般家庭で採用する場合，サーバやストレージを設置して解析までを行うことは 難しいため，クラウドでの処理が必要となる．しかし，センサとクラウド間のネットワーク帯域やクラウ ド側の資源の制限により，クラウドに動画像を含む多数のセンサデータを送信し，特徴量抽出等の前処理 から解析までの全ての工程をクラウド側でリアルタイムに行うことは困難である．我々は，ファットクラ イアントの概念を取り入れ，センサ側で画像から特徴量抽出し，前処理済みの小さいデータをクラウドに 収集して解析する動画像データ解析アプリケーションフレームワークを提案しているが，動画像解析では センサ側での前処理により多くの時間がかかってしまうことが明らかになった．本研究では，前処理を センサ側とクラウド側で負荷分散させることで，動画像解析処理全体の高速化を図る．提案するアプリ ケーションフレームワークはリアルタイム分散処理システムの Apache Storm を用いて実装し，実際に画 像データをセンサ側とクラウド側で分散処理した場合の画像 1 枚あたりの処理時間と一定時間内に処理で きるジョブ数を調査した．実験結果より，処理スレッド数を増やすことによって画像 1 枚当たりの処理時 間は増加するが，一定経過時間に処理できる総画像数が増加し，ファットクライアントとクラウドを連携 させた分散処理の有用性が示された． Proposal of a Fat Client-based Application Framework for Real Time Video Streaming Analysis Yuko Kurosaki1 Atsuko Takefusa2 1. はじめに 一般家庭やオフィスビルでカメラやセンサ等によりライ フログを取得して，防犯対策やセキュリティ，お年寄りや 子供のための安全サービスを目的としたライフログ解析 Hidemoto Nakada2 Masato Oguchi1 側の資源の制限により，リアルタイムに処理できない可能 性がある．また，動画像はデータ量が大きく，連続的であ るため，大容量ストリームデータに対して継続的に特徴量 抽出から解析までの高負荷な処理を行う必要がある． クラウド側で全ての処理を行う方式に対し，センサ側， アプリケーションが数多く開発されている．それらのアプ すなわちクライアント側にある程度の機能を持たせ，クラ リケーションを一般家庭で採用する場合は，サーバやスト ウド側の処理を軽減するファットクライアントと呼ばれる レージを設置して解析までを行うことは難しいため，クラ パラダイムが注目されている．また，ユーザと物理的に近 ウドでの処理が必要となる．しかし，動画像を含む多数の く配置された小規模なエッジサーバと連携してクラウドの センサデータをクラウドに送信してクラウド側で処理する 負荷を軽減しつつサービスの応答遅延を減らすことを目指 と，各センサとクラウド間のネットワーク帯域やクラウド したエッジコンピューティング [1] や，クラウドとデバイ スの間に分散処理環境を置くことにより，クラウドへの一 1 2 お茶の水女子大学 Ochanomizu University， Bunkyo， Tokyo 112-8610， Japan 産業技術総合研究所 AIST， Tsukuba， Ibaraki 305-8568， Japan 極集中を防ぐフォグコンピューティング [2] が提案されて いる． 我々はファットクライアントモデルを取り入れた動画像 データ解析アプリケーションフレームワークを提案してい る [3]．動画像データはデータ量が大きく，連続的である tuple tuple bolt spout ため，センサ側で画像から特徴抽出等の前処理を行い，前 処理済みの小さいデータをクラウドに収集してオンライン bolt bolt bolt spout 機械学習フレームワーク Jubatus を用いて解析する．しか bolt しながら，既発表研究 [3] により，画像処理では前処理に より多くの時間がかかるため，センサ側での処理がボトル ネックになることが示された． topology 図 1 Topology の流れ 本研究では，動画像データ解析アプリケーションはリア ルタイム処理であることから，前処理をセンサ側とクラウ また，Storm には Local mode と Distributed mode の 2 ド側で負荷分散させることで高速化を図る．負荷分散機能 種類が存在する．Local mode とは，Storm クラスタを 1 をもつ Apache Storm(以降，Storm と呼ぶ) を導入し，動 台の計算機の中で実行可能なモードであり，Distributed 画像データ解析フレームワークを実装した．評価実験で mode は，Storm クラスタを複数ノードに動的に負荷分散し て実行するモードである．本研究では，Distributed mode を利用し，画像データ解析フレームワークを実装する． は，Storm で画像データを分散処理した場合の画像 1 枚あ たりの処理時間と一定時間内に処理できるジョブ数を調査 した．実験より，処理スレッド数を増やすことによって画 像 1 枚当たりの処理時間は多くかかってしまうが，一定経 過時間に処理できる総画像数が増加することがわかった． 多くのストリームデータが生成する環境において，ファッ トクライアントとクラウドを連携させた分散処理が有用で あることが示された． 2. 関連技術 我々が開発しているアプリケーションでは，前処理の センサ側とクラウド側の負荷分散の基盤として Storm を， クラウド側の解析にはオンライン機械学習フレームワー ク Jubatus を使用する．以下に各ソフトウェアの概要を述 べる． 2.1 Apache Storm Storm は，Back Type 社によって開発された分散型のリ アルタイム計算システムである [4]．現在は Twitter 社に 買収されており，Twitter でのつぶやきのリアルタイム解 析に用いられている．Apache Hadoop はバッチで大規模 処理を行うのに対し，Storm はリアルタイムでの分散処理 に特化している．また，同じストリーム処理フレームワー クに Apache Spark[5] がある．ストリーム処理を 1 秒間に 受信したイベント群に対するバッチ処理の連鎖としてバッ チ処理の性質を保ったまま実行するのが Spark の特徴で あり，スループットは向上するものの，遅延は 0.5∼2.0 秒 程発生するため純粋なストリーム処理より遅くなってしま う [6]． Storm は，図 1 のような Spout と Bolt からなる Topology と呼ばれるネットワーク構造を，Storm クラスタで指定す ることによって処理を行う．Spout とは Steam を流し始め る処理の起点となるプロセスで，Bolt は流れてくるデータ の変換処理を行うプロセスを指す．Stream とは，Tuple の 無限の連続であり，標準データ型を表したり，シリアライ ズ・コードを追加したユーザ定義型を表したりすることが できる構造体のようなものである． 2.2 オンライン機械学習 Jubatus Jubatus とは，NTT SIC と Preferred Infrastructure に より共同開発された，オンライン機械学習フレームワーク である．本来トレードオフの関係であった「ストリーム (オ ンライン) 処理」「並列分散処理」「深い解析」の要素を満 たすオンライン機械学習フレームワークである [7]．オン ライン機械学習をそのまま分散処理すると同期コストが大 きくなるという問題が生じるが，Jubatus では，UPDATE の処理ではデータ自体は共有せず，MIX という処理の中で 学習後のモデルのみを緩やかに共有することで，並列分散 処理を可能にしている． Jubatus は解析の時に Datum という key-value データ形 式を用いる．Datum には 3 つのタイプの key-value が存在 する．value が文字列の文字列データ，value が数値の数値 データ，最後に value が任意のバイナリデータがあり，key は 3 タイプとも文字列である．バイナリデータには画像 や音声などのマルチメディアデータなど，任意のバイナリ データを入れることが可能である．この 3 つのデータから， 機械学習を行う際に必要となる特徴量を Jubatus のデータ 変換モジュールが抽出する．また，Jubatus の特徴ベクト ル変換器は，この特徴抽出処理を JSON 形式ファイルでカ スタマイズすることが可能であり，特徴抽出器にはプラグ インを利用することができる．プラグインは動的ライブラ リファイル (.so ファイル) からなり，JSON 形式ファイル でパスを通すことによって利用可能である． 3. 動画像データ解析フレームワーク 本節では我々が提案する動画像データ解析アプリケー ションフレームワークの設計概要について説明する．動画 像データ解析は，基本的に (1) 画像の取得，(2) 特徴量抽 出 (前処理)，(3) 機械学習処理の 3 つのステップからなる． クラウド側で全てのセンサデータを収集して処理を行う場 合は，図 2 に示すようにセンサ側で (1) の処理を行った後， 動画像を含むセンサデータをクラウドに送信してクラウド もとに，各グループに属する特徴量をもつ特徴点の数をヒ ストグラム化する手法である．Bag-of-Features の抽出手 image data (2) Feature extraction (1) Image acquisition Feature Vector (3) Video Analysis Resulting output 順は以下のようになる．まず，OpenCV を用いて画像か ら局所特徴量を抽出する．局所特徴量にはいくつか種類 があり，中でも有名な SIFT は，照明変化や回転，拡大縮 小に不変な頑強な特徴量である．その SIFT より認識精度 analysis result は少し落ちるが，特徴点検出の処理を軽量化，高速化した cloud side computer sensor side computer ものが SURF である．本研究では，局所特徴量に SURF 特徴量を用いた．SURF では keypoint と呼ばれる画像中 図 2 の特徴的な点をいくつか抽出する．各 keypoint は 128 次 クラウド側で特徴抽出 元の特徴ベクトルとなるが，抽出される keypoint の数は 画像によって異なるため，画像全体の特徴ベクトルとし て機械学習でそのまま使用するのは困難である．局所特 (1) Image acquisition 徴量をクラスタリングして各クラスタの中心ベクトルを Feature Vector image data (2) Feature extraction (3) Video Analysis Resulting output analysis result cloud side computer sensor side computer 図 3 センサ側で特徴抽出 側で (2)，(3) の処理を行う．一方，クラウド側処理の負荷 の軽減と，センサとクラウド間のデータ転送量を削減する ため，既発表研究 [3] では図 3 に示すように (1)，(2) をセ ンサ側で行い，特徴量データのみをクラウド側に送信して (3) の処理を行うアプリケーションフレームワークを提案 した． 3.1 動画像データ解析フレームワークの設計 実装したアプリケーションは次の 3 つのプロセスに分か れている． ( 1 ) WEB カメラからのキャプチャ ( 2 ) Bag-of-Features を用いた特徴抽出 ( 3 ) Jubatus での解析 以下に各プロセスの詳細について述べる． 3.1.1 WEB カメラからのキャプチャ まず，データストリームの起点となるセンサ側に，WEB カメラからのキャプチャ部分を実装する．OpenCV[8] を 用いて WEB カメラから画像を取得し，取得した画像を構 造体に格納し，(2)Bag-of-Features を用いた特徴抽出処理 を行うプロセスとなる Bolt に，構造体を渡す． 3.1.2 Bag-of-Features を用いた特徴抽出 2 つ目のプロセスが，OpenCV を用いた特徴量の抽出 と Bag-of-Features[9] による画像データのベクトル化であ る．ベクトル化したデータを，ネットワークを介して， (3)Jubatus での解析プロセスに転送する． Bag-of-Features とは，画像から得られた局所特徴量の集 合から，あらかじめ複数画像の特徴量データから K-means 手法を用いて特徴量をクラスタリングした辞書データを Visual Word と呼ばれる特徴的なパターンとし，辞書を作 成する．この辞書を使ってある画像から抽出された特徴ベ クトル群を Visual Word にマッチさせ，画像全体の特徴 パターンの頻度をヒストグラムで表現する．このヒストグ ラムを Bag-of-Features と呼ぶ．一度辞書を作成してしま うと，Visual Word 数は一定であるため，各画像の特徴量 を同じサイズのベクトルデータに変換することができる． 次に，生成したベクトルデータを Jubatus で扱う形式に 変換する．2 節より，Jubatus は解析時に Datum という データ形式を使用する．よって，作成したヒストグラムを Datum に変換する．ヒストグラムの各値を 1 つずつリス ト形式で Datum に格納し，Jubatus へ転送可能なデータ に変換する．最後に，Jubatus サーバとコネクションを確 立し，画像から取得した特徴ベクトルの格納された Datum を Jubatus サーバへ転送する． 3.1.3 Jubatus での解析 Jubatus では分類，推薦，線形回帰などいろいろな解析 が可能であり，今回は Classifier API を用いて学習と分類 を行う．ライフログ解析を行う前に trainAPI を利用し， 予め教師あり学習を行う．その学習結果を用いて分類する には，classifyAPI を利用する．Jubatus サーバに送られて きた Datum はフィルター，特徴抽出という 2 段階のデー タ変換を経て解析される．フィルター処理では，学習に不 要なものを取り除き，特徴抽出では，フィルターされた データから特徴を抽出する．フィルター処理でデータから どのような要素を取り除くか，特徴抽出でどのアルゴリズ ムを使用し，どのように重み付けをするかは，サーバ起動 時に指定する JSON ファイルで設定することが可能であ る．今回はフィルターはデフォルトを利用し，特徴抽出で は与えられた数値をそのまま重みに利用する．分類に使用 するアルゴリズムには Adaptive Regularization of Weight vectors を選択した．学習に対する感度パラメータは 1.0 に 設定する．Jubatus サーバで 2 段階のデータ変換を終えた 後，解析され，解析結果が送信される． 192.168.10.28 (GUI!") Bolt (2)#$%& Monitor the storm cluster Apache Storm Spout Bolt (1)キャプチャ+, (2)#$%& Supervisor Zookeeper : 2181 Jubatus Slavenode 192.168.10.26 Worker : 6700~6703 (3) !" ・・・ Bolt (2)#$%& センサ0での34 Nimbus : 6627 クラウド0での34 Supervisor Submit jar file Master node 192.168.10.29 図 4 提案するフレームワーク 4. 評価実験 Worker : 6700~6703 UI : 8080 図 5 Storm クラスタの構成 350 300 1!あたりの&'()*+ (ms) 3.2 Storm と Jubatus を用いたフレームワークの実装 動画像データ解析アプリケーションはリアルタイム処理 であることから，負荷の高い処理を適宜並行実行して高速 化を図る必要があるため，分散型リアルタイム計算システ ムの Storm を導入した．既発表研究 [3] では，センサ側計 算機上で Storm による分散処理で OpenCV を用いた特徴 抽出等の前処理を行い，クラウド側計算機で画像の分類処 理を Jubatus を用いて行った．本研究では，図 4 に示すよ うにセンサ側およびクラウド側で前処理を負荷分散処理す るフレームワークを実装した．3.1 節で説明した (1) はセ ンサ側，(2) はセンサ側とクラウド側で処理される．また， (3) の処理はクラウド側で行われるようにした．(2) の処理 を全てセンサ側で行う場合は，クラウドへの通信量は少な くなるものの，前処理の負荷が大きくなる．(2) の処理を センサ側とクラウド側の両方で行う場合は，クラウドで処 理する場合は前処理の負荷が分散できるものの，クラウド への通信量が大きくなり，そのオーバーヘッドによる性能 劣化が懸念される． Slavenode 192.168.10.27 250 200 node01, 10ms/! node01, 30ms/! node01, 50ms/! node02, 10ms/! node02, 30ms/! node02, 50ms/! 150 100 50 0 1 3 6 boltスレッド0 図6 ストリーム生成速度と処理スレッド数の変化に伴う 1 ストリー ムデータあたりの平均処理時間 せて，画像 1 枚の処理時間を計測した．Spout のスレッド 数は 1 に固定し，Bolt のスレッド数を 1，3，6 と変化させ 本研究は，動画像データ解析フレームワークの前処理を る．また，1 ストリームデータの生成時間を 10ms，30ms， センサ側およびクラウド側で負荷分散する場合の性能を調 50ms と変化させる．計測結果を図 6 に示す．縦軸は画像 1 枚あたりの平均処理時間をミリ秒で表している．横軸は Bolt スレッド数を表す．グラフから Bolt スレッド数が増 加するにつれて，画像 1 枚の平均処理時間は増加したこ とが分かる．しかし，ストリーム生成速度を速くした場 合には処理時間に大きな変化はみられなかった．これは， Storm が処理待ちのストリームデータを溜めてしまってい ることが原因と考えられる．Bolt スレッド数が多い場合， Slave node2 台の方が 1 台よりも処理時間が大幅に減少し た．これは，Slave node を 2 台用いた場合，Storm の自動 負荷分散機能が働き，2 台に処理スレッドが負荷が均等に なるように割り振られたためである． 次に，ストリーム生成時間を 10ms に固定し，Bolt スレッ ド数と Slave ノード数を変化させて，一定時間に処理でき るジョブ数の計測を行った．計測結果は図 7 に示す．縦軸 は処理したジョブ数の合計を表し，横軸は経過時間を表す． グラフより，Bolt スレッド数，Slave node 数を増やすこと によって処理できるジョブ数が増加することが分かった． また，使用する計算機の CPU のコア数分の worker を用意 査する． 実験では，実装したフレームワークを用いて２種類の人 の行動を判別する．予め 100 枚の画像を用いて「ドアを開 けた」状態と「イスに座った」状態を学習させた後，画像サ イズ 320 × 240 の画像データを Spout で定義するストリー ム生成時間毎にランダムに選出し，選出された画像データ の特徴量抽出を行い，生成されたベクトル値を Datum に 格納して Jubatus に転送した．特徴量抽出における Visual Words 数は 100 に設定した．Storm の設定は，Topology は Spout を 1 つ，Bolt を 1 つ用意する．センサ側計算機，ク ラウド側計算機ともに，Intel Xeon E31220(3.10GHz，4 コ ア，メモリ 8GByte) を使用し，OS には Ubuntu 14.04LTS を用いた．構築した Storm クラスタは図 5 のような構成を とる．Master node を 1 台，Zookeeper node を 1 台，Slave node を 2 台用意し，Slave node には worker を 4 つずつも たせる．Slave node のうち，1 台がセンサ側，もう 1 台が クラウド側計算機であると想定する． まず，Bolt のスレッド数やストリーム生成時間を変化さ 入し，センサ側およびクラウド側で前処理を負荷分散処理 4000 3000 2500 ジョブ% する動画像データ解析フレームワークを設計，実装した． node%1, boltスレッド%1 node%1, boltスレッド%3 node%1, boltスレッド%6 node%2, boltスレッド%1 node%2, boltスレッド%3 node%2, boltスレッド%6 3500 評価実験より，1 ノード内で処理スレッド数を増やすこと によって画像 1 枚当たりの処理時間は増加するが，一定経 過時間に処理できる画像数はスレッド数を増やすことで増 2000 加することがわかった．多くのストリームデータが生成す 1500 る環境では，ファットクライアントとクラウドを連携させ 1000 た分散処理が有効であることが示された． 500 今後は，クラウド側計算機とセンサ側計算機の間のネッ 0 0 10 図 7 20 30 40 50 60 !"#$(sec) 70 80 90 100 経過時間あたりの処理ジョブ数の比較 トワーク遅延や帯域を考慮した評価実験を行うとともに， Raspberry Pi[13] のような小型コンピュータを複数台用意 し，複数センサ環境で本フレームワークを用いた場合の性 能特性を調査する． し，各 worker に 1 つの処理スレッドを割り当てることが 適切であると考えられるが，node 数 1 の場合の結果から， 参考文献 1 つの worker に 2 つの Bolt スレッドを割り当てた場合も 一定時間における処理ジョブ数がわずかに増加することが 確認できた． 2 つの計測結果より，Storm を用いて並列分散処理を行 うことによって，1 つのジョブあたりの処理時間は増加す るが，一定時間内に処理できるジョブ数は増加することが できることが分かった．これより，ストリームデータ量が 多い環境において，センサ側とクラウド側で負荷分散する 手法は有効であることが示せた． [1] 5. 関連研究 [2] [3] [4] [5] [6] クラウド技術を用いた動画像データ解析は，近年数多く 研究されているが，クラウド上での効率的な動画像データ の内容検索や，クラウドプラットフォームを使用した動画 像データのオンデマンドシステムにおけるロードバランス に焦点が当てられていた．既にストリーム動画像データの 検出，追跡，解析を行う内蔵システム [10] や，人々の異常 [7] [8] [9] 行動の追跡や活動の検出する自動監視システム [11] が開発 されているが，これらは 1 ノード上で動作するシステムと して開発されており，スケーラビリティについて考慮され [10] ていない． Abdullah ら [12] は，クラウド上で動画像データの取得， 処理，解析を行うストリーム処理フレームワークを構築し ている．時間のかかる高画質の画像処理を GPU を用いる ことで高速化し，クラスド上でのスケーラブルなフレー ムワークを提案している．大量の動画像データを扱い，ス ケーラビリティを考慮したフレームワークの設計は本研究 と近いが，全ての処理をクラウド上で行っているのに対し， 本研究はファットクライアントモデルを採用している点で 異なる． 6. まとめと今後の予定 本研究では，動画像データ解析アプリケーションはリア ルタイム処理であることから，前処理をセンサ側とクラウ ド側で負荷分散させることで高速化を図った．Storm を導 [11] [12] [13] Milan Patel，Brian Naughton，Caroline Chan，Nurit Sprecher，Sadayuki Abeta，Adrian Neal, “Mobile-edge computing”，ETSI, Tech. Rep., 09 2014． Flavio Bonomi, Rodolfo Milito, Jiang Zhu, and Sateesh Addepalli, “Fog computing and its role in the internet of things,” in Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, ser. MCC ’12. ACM,2012, pp. 13–16. 黒崎裕子，竹房あつ子，中田秀基，小口正人， “ファットク ライアントを利用した動画像データ解析アプリケーション フレームワークの提案” ，DEIM2015，F2–5，2015 年 3 月． Apache Storm，https://storm.apache.org/ Apache Spark，https://spark.apache.org/ 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． オンライン機械学習向け分散処理フレームワーク Jubatus，http://jubat.us/ja/ 画像ライブラリ OpenCV，http://opencv.org/ 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． B. S. System,“IVA 5.60 intelligent video analysis” ，Bosh Security System, Tech. Rep.，2014． Project BESAFE，http://imagelab.ing.unimore.it/besafe/. Tariq Abdullah，M Fahim Tariq，Yusuf Baltaci and Nick Antonopoulos，“Traffic Monitoring Using Video Analytics in CloudsTraffic Monitoring Using Video Analytics in Clouds”，7th International Conference on Utility and Cloud Computing，pp.39-48，2014． Raspberry Pi，http://www.raspberrypi.org/
© Copyright 2024 ExpyDoc
