Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Report

可視化ミドルウェアのスイッチングモジュールの設計と実装
石田 和也1,a)

木戸 善之2,b)

伊達 進2,c)

下條 真司2,d)

概要：Tiled Display Wall (TDW) を制御するために用いられる可視化ミドルウェアは，ハードウェアアクセラレーション機能を用いることで高速化を図っているミドルウェアが多く，システムライブラリ等の特定のバージョンに依存関係を持っている場合がある．そのため，複数の可視化ミドルウェアを TDW に導入する場合，ライブラリのバージョン依存性から来る競合が発生し，導入および共存が困難になる．本研
究では，コンテナ型仮想化によって可視化ミドルウェア環境を分離し，必要に応じて切り替える（スイッチングする）ことで，複数の可視化ミドルウェアの共存を可能にする手法を提案する．また評価としては，提案手法による可視化ミドルウェア環境のスイッチング時間と，コンテナ型仮想化によるオーバーヘッドを計測し，提案手法の実用性について検討する．
キーワード：Tiled Display Wall，可視化ミドルウェア，スイッチング，Docker，SAGE2，ParaView

1. 背景

き，実際に薬物候補になりえるかを検討することが可能となる [2]．

仮想実験，いわゆるシミュレーションによって科学的知

4K や 8K の解像度を持つディスプレイが市販される昨見を得るためには，結果を可視化することが重要である．

今，大規模可視化装置もまた重要な意味を持っている．大規「京」や Oakforest-PACS といった様々な超並列計算機や模可視化装置の 1 つである Tiled Display Wall (TDW) [3]

スーパーコンピュータが普及し，運用されるようになったは，モニタを複数連動させることによって，仮想的に 1 枚ことで，スーパーコンピュータを用いたシミュレーションのディスプレイを構成する技術である．TDW は，複数のが少人数や個人での研究においても利用できるようになりモニタをタイル状に並べることにより，市販のディスプレつつある．こうしたシミュレーションの結果は膨大な分量イよりも巨大なディスプレイを構築することができる．人の数値データとして得られるため，高解像度の可視化装置の高さよりも大きく壁一面に配置された TDW は，高解像を用いて可視化し，実験結果を目視で確認することが必要

度な可視化コンテンツを人の視野を占有するほど大きく表とされる．例えば，建築物や重要文化財の構造健全性評価示することができ，かつそれを複数人で視聴することを可はシミュレーションによって行われるが，シミュレーショ能にする．すなわち TDW は，研究グループにおいて同じン結果を可視化することで地震発生時における構造物限界可視化コンテンツを視聴しながら複数人で議論することを性能や破断後の構造物の変形を確認でき，構造物の補強す可能にする技術であると言える．

べき箇所を特定することが可能となる [1]．また，化合物こうした大規模な TDW を個人もしくはグループ単位でとタンパク質との複合体の結合は，未知の化合物とタンパ購入・所有することは，設置場所やコスト面において簡単ク質との分子動力学シミュレーションによって複合体の可とは言い難い．そこで，大学や研究所などの公共機関が保能性を知ることができるが，シミュレーション結果を可視有する大型計算機センターに大規模可視化装置を設置し，化することでタンパク質の変形や結合部位の詳細を把握でそれを研究者間で共有利用することがある．大阪大学サイバーメディアセンターでは大規模可視化装置として TDW12a)b)c)d)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,Osaka University
大阪大学サイバーメディアセンター
Cybermedia Center, Osaka University
ishida.kazuya@ais.cmc.osaka-u.ac.jp
kido@ais.cmc.osaka-u.ac.jp
date@ais.cmc.osaka-u.ac.jp
shimojo@ais.cmc.osaka-u.ac.jp

c 2017 Information Processing Society of Japan⃝を設置し，可視化サービスとして運用している [4]．可視化サービスでは，TDW およびその附置システムにインストールされている可視化アプリケーションあるいはミドルウェアに対応した形式の可視化コンテンツをユーザが持参し，それを TDW に表示する．したがって，可視化サービスとして TDW を運用する場合，その TDW には多様な可1Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告IPSJ SIG Technical Report

モニタ群

視化アプリケーション及びミドルウェアをインストールすることが求められる．

TDW を制御するために用いられる可視化ミドルウェアには，Scalable Amplified Group Environment (SAGE2) [5]，ParaView [6]，COllaborative VIsualisation and Simulation
Environment (COVISE) [7] など，多種多様なものが存在する．ユーザは，可視化の目的や扱うデータ形式に適した可視化ミドルウェアを選択して利用することを求めるが，異なる可視化ミドルウェア間では使用するライブラリの競合などが生じることがある．共有利用する TDW に複数の可視化ミドルウェアを導入し，運用する場合，こうした問題PCクラスタが運用を複雑にする．そこで本研究では，TDW を可視化サービスとして運用する場合を想定し，可視化ミドルウェ

図 1 TDW のアーキテクチャ

ア環境を仮想化技術によって分離する手法を提案する．
本論文の構成は以下の通りである．2 節で技術的背景とン (SAGE2 に対応した可視化アプリケーション) のウィン

本研究の課題について概説し，3 節で提案手法の詳細とそドウをストリーミング配信することで，リモート可視化をの実装について述べる．4 節でまとめと今後の課題につい実現する．て述べる．

2. 技術的背景と問題

SAGE2 の ア ー キ テ ク チ ャ を 図 2 に 示 す ．SAGE2 はSAGE2 Server，Display Client，Interaction Client の 3 つの要素から構成される．SAGE2 のアーキテクチャでは，この章では TDW のアーキテクチャを説明し，続けて可TDW のモニタ群を構成する各モニタは，0 から始まる個別視化ミドルウェアの特徴について述べる．その後，TDWの番号 (Client ID) を持つ Display Client となる．SAGE2を共有利用するための運用における問題点を述べる．

Server は，表示するウィンドウの映像ストリームを WebSocket を用いて配信する．各 Display Client は，フルスク

2.1 TDW のアーキテクチャ

リーンモードの Chromium ブラウザで自身の Client ID に

図 1 に，TDW のアーキテクチャを示す．TDW は，モ対応した URL を開くことにより，SAGE2 Server からのニタ群と PC クラスタという 2 つの要素から構成される．

映像ストリームの受信と表示処理を行う．各ウィンドウのモニタ群は，通常サイズのモニタをタイル状に複数配置す位置やサイズの変更は，Interaction Client 上で起動したることで構成される．PC クラスタは TDW のバックエン

SAGE UI を用いて行う．SAGE UI も SAGE2 Server がドシステムであり，モニタを 1 台以上接続したノード群かWebSocket を用いて配信しており，Chromium ブラウザでら構成される．一般的に，TDW がモニタ群を連動させて専用の URL を開くことで利用できる．

ディスプレイを構成する際には，PC クラスタ上で可視化

Display Clients

ミドルウェアのプロセスをモニタ数と同じ数だけ連携駆動させる．これらのプロセスはいずれかのモニタと一対一対応し，それぞれが自身と対応するモニタが表示すべき領域!"#$%&'()*+!"#$%&'()*+!"#$%&'()*,!"#$%&'()*-!"#$%&'()*.

!"#$%&'()*/!"#$%&'()*0

SAGE UIに関するレンダリングと表示処理を行う．このようにして，可視化ミドルウェアは TDW を制御する役割を果たす．

2.2 本研究で利用する可視化ミドルウェア
2.2.1 SAGE2

Interaction
ClientScalable Amplified Group Environment (SAGE2) [5] は，PCクラスタ米国のイリノイ大学シカゴ校の Electronic Visualization

Laboratory (EVL) が開発した，オープンソースの可視化
1'!2345#65
1'!"#$%&'1'()*+,&-ミドルウェアである．SAGE2 は Chromium ブラウザを用いたウェブベースでの動作が特徴であり，ネットワーク

SAGE2 Serverを介してリモート可視化 (遠隔地のデータの可視化) を行うことができる．具体的には，遠隔地で動作する SAGE2

図 2

SAGE2 のアーキテクチャ

Server が，仮想デスクトップ上の SAGE2 アプリケーショ

c 2017 Information Processing Society of Japan⃝

2Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Reportの可視化ミドルウェアが持つ依存関係のごく一部であり，2.2.2 ParaView
ParaView [6] は，米国のサンディア国立研究所や Kitware

これらのミドルウェアを同一環境，同一計算機上に導入す社等が開発した，オープンソースの可視化ミドルウェアでる場合は，ライブラリの競合毎に管理方法やインストールある．ParaView は VTK や OpenFOAM，Plot3D といっディレクトリを変更する必要がある．

た多様な形式のデータを扱うことができる．また，可視化したデータを柔軟かつプログラマブルに加工するための可視化ミドルウェア

依存関係にあるライブラリ

SAGE2 (v2.0.0)

FFmpeg (v3.0 以上)

Python スクリプティング機能を有している．

Node.js (v6.9 以上)

ParaView のアーキテクチャを図 3 に示す．ParaView はImageMagick (v6.9 以上)

クライアント，サーバ，モニタ群の 3 つの要素から構成さVTK (v6.0 以上)れる．ParaView のアーキテクチャでは，モニタ群を構成

ParaView (v5.1.2)

する各モニタは，0 から始まる個別の番号 (ID) を持つ．また，PC クラスタはサーバとしての役割を果たす．サーバ上

VTK (v6.0 以上)

では，Message Passing Interface (MPI) を用いて pvserver

COVISE (v2016.12)

Python (v3.0 以上)
OpenSceneGraph (v3.2 以上)(ParaView が提供する分散レンダリング用プログラム) をモニタ数と同じ数だけ連携駆動させる．各 pvserver は自身

Python (v2.7 以上)
FFmpeg (v2.3 以上)

表 1

SAGE2・ParaView・COVISE と依存関係にあるライブラリの持つランクと同じ値の ID を持つモニタと対応し，そのモニタが表示すべき領域に関するレンダリングと X Window

可視化サービスのユーザは，利用する可視化ミドルウェSystem を用いた表示処理を行う．一方，クライアント上でアとして特定の種類もしくは特定のバージョンのミドルは，可視化されたデータを操作するための GUI が起動し，ウェアを要求する場合がある．しかし，共有環境下で全種

ランク 0 の pvserver との間に制御用コネクションを確立す類・全バージョンの可視化ミドルウェアを導入・運用するる．GUI 上でのユーザの操作内容は，制御用コネクションのは困難である．また，可視化サービスのユーザは，これを介して送られた制御メッセージに基づき，各 pvserver がら特定の可視化ミドルウェアの他にユーザ独自の可視化ソ再度レンダリングと表示処理を行うことで反映される．

フトウェアを作成している場合や，システムライブラリやモニタ群!-./!

グラフィックライブラリを独自カスタマイズしている場合"-./"#-./#などもあるため，可視化サービスのユーザの要求に対して，可視化環境は多様性を求められる．

0,1,234567,89):*;0,!"#$%&'

3. 提案手法

GUI$-./$%-./%&-./&

本研究では，2.3 節で述べた可視化環境の構築を目指し，可視化ミドルウェア環境の仮想化技術による分離を提案'()*+(*+,$'()*+(*+,%'()*+(*+,&'()*+(*+,!

'()*+(*+,"'()*+(*+,#する．仮想化技術には多様な方式があり，独立した仮想マ
シンにて自由に OS をインストールすることができるハイパーバイザ型，OS 部分をホストと共有するコンテナ型などがある．本研究では，実用可能性を探るための準備段階とクライアント
図 3

PCクラスタParaView のアーキテクチャして，コンテナ型仮想化技術を用いた可視化ミドルウェア環境の分離，およびそのスイッチング機能の実装を試みる．
本章では，まず提案モジュールの構成技術であるコンテナ型仮想化技術 Docker について説明し，続けて提案モ

2.3 可視化ミドルウェア環境の分離の必要性
2.2 節で述べたように，可視化ミドルウェアは種類によっジュールのアーキテクチャを示す．その後，本研究で実装した提案モジュールについて概説する．てアーキテクチャが全く異なるが，使用するライブラリの種類については同様のものが多い．一方で，多くの可視化

3.1 Docker

ミドルウェアはハードウェアアクセラレーション機能を用

Docker [8] は，Docker 社によって開発されたコンテナいることで高速化を図っているため，ライブラリの特定の型仮想化技術である．Docker は，Docker イメージと呼ばバージョンに依存関係を持っている場合がある．例えば，れる仮想イメージを基にして，コンテナと呼ばれる仮想環

表 1 に示した SAGE2・ParaView・COVISE が持つ依存関境を構築することができる．コンテナは，ホスト OS 上に係のように，共通するライブラリを使用するが，そのバー構成された論理的な区画であり，ホスト OS 上で動作するジョンが異なるような依存関係がある．表 1 はこれら 3 つDocker Engine によって管理される．

c 2017 Information Processing Society of Japan⃝

3Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Report

Docker をはじめとするコンテナ型仮想化の特徴は，非常に軽量な仮想環境を構築できるという点である．ハイ!"#$"%!"#$"%
&'()

&'()

&'()

&'()

パーバイザ型仮想化で構築される仮想マシン (Virtual Ma-chine: VM) とコンテナ型仮想化で構築されるコンテナの!"#$%&'()*+)%!"#$%&'()*+)%

アーキテクチャの比較を，図 4 に示す．VM は，ホスト OS上 (またはハードウェア上) で動作するハイパーバイザによって管理される．VM はホスト OS と完全に隔離された!"#$%&&*'%!"#$%& '%&()#%*#&%+,%*--&%./)#+'*0*'+1./%!"#$%&'()*+)%&'()

区画であるため，内部で独立にゲスト OS を起動し，その&'()*+",-$"%上にアプリケーションを起動する必要がある．一方，コンテナはカーネル部分をホスト OS と一部共有するため，内

図 5部でゲスト OS を起動することなくアプリケーションを起Docker Swarmクラスタ

Docker Swarm のアーキテクチャ動できる．そのため，コンテナ内のアプリケーションは，上のいずれかのボタンをタッチすると，そのボタンに対応VM に比べて極めて小さいオーバーヘッドで動作させるこするパラメータ (ボタン名を表す文字列) を含む GET リクとができる．また，コンテナは内部にゲスト OS を持たなエストが制御サーバに送信される．

いため，起動や停止を VM よりも高速に行うことが可能である．

制御サーバは Web UI の配信とスイッチングの制御を行う Web サーバであり，Docker Swarm クラスタのマネージャノード上で起動する．制御サーバは Web UI からの4556 74556 8%&'()&*+%&'()&*+.()!"

.()!"

#$

#$

GET リクエストを受信すると，このリクエストに含まれるパラメータの内容に対応するスイッチング用スクリプト4556 74556 8を選択・実行する．各スイッチング用スクリプトは Docker%&'()&*+%&'()&*+!*+",*-

/012

/012

Swarm クラスタ上のコンテナの停止・起動やコンテナ内で'()!"'()!"!"#$%&!"#$%&

仮想マシン (VM),-./01
2'3&'0コンテナ

図 4 VM とコンテナの比較の初期設定を行うための Docker コマンド群を含んでおり，実行することで可視化ミドルウェア環境のスイッチングに必要な一連の処理が行われる．

Docker Swarm クラスタは，可視化ミドルウェア環境のコンテナが起動するクラスタで，TDW の PC クラスタ全体から構成される．マネージャノード上の Docker Engine

また，Docker は Docker Swarm [9] と呼ばれる，複数のホは，スイッチング用スクリプト内で実行された Docker コ

スト上で起動するコンテナのオーケストレーション (一括マンドに従って Docker Swarm クラスタ上のコンテナ全体操作) を行うための機能を有している．Docker Swarm ののオーケストレーションを行う．一方，ワーカノード上のアーキテクチャを図 5 に示す．Docker Swarm を利用する

Docker Engine は，マネージャノードからの指示に従って際には，コンテナが起動する複数ホストをまとめて Docker

コンテナの停止と起動を行う．

Swarm クラスタを構成する．Docker Swarm クラスタに含まれる各ホストは，マネージャノードもしくはワーカノーモニタ群

Web UIドとなる．マネージャノード上の Docker Engine は，コマンドラインで入力された Docker コマンドに応じて，コンテタブレットPCナ操作 (起動・停止・再起動など) の指示を Docker Swarmクラスタの全ノードに送る．ワーカノードと指示を送ったマネージャノード上の Docker Engine は，この指示に従って必要なコンテナ操作を行う．
3.2 提案モジュールのアーキテクチャ
提案モジュールのアーキテクチャを図 6 に示す．提案モ
ジュールは Web UI，制御サーバ，Docker Swarm クラス
タの 3 つの要素によって構成される．

Web UI はワンタッチ操作が可能な提案モジュールの UIであり，タブレット PC 上の Web ブラウザ上で利用される．Web UI 上には，可視化ミドルウェア環境をスイッチングする際に利用するボタンが用意されている．Web UI

c 2017 Information Processing Society of Japan⃝/-'0(1-,;&/<=7839:536

制御サーバ!"#$%&'()*+)%

234536234536!"#$%&'()*+)%!"#$%&'()*+)%.- &'()"*+&,-./01,-'!"#$%&'()"*

Docker Swarmクラスタ (PCクラスタ)!"#$%&'()*+,-./012345

図 6 提案モジュールのアーキテクチャ

4Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Report

3.3 提案モジュールの実装• Stop モード起動スクリプト

本研究では，TDW 上で SAGE2 の実行環境が起動して( 1 ) TDW の現状態が SAGE2 モードであるなら，起いる状態 (SAGE2 モード) ・ParaView の実行環境が起動

動中のすべての Chromium ブラウザを停止する．

している状態 (ParaView モード) ・両者ともに停止してい( 2 ) Docker Swarm クラスタ上のすべてのコンテナをる状態 (Stop モード) という 3 状態間でのスイッチングが可能な提案モジュールを実装した．本節では，実装の概略を説明する．

停止する．

4. 評価

Web UI 上には，SAGE2 ボタン・ParaView ボタン・Stop

本研究では，提案手法の実用性について検討するため，ボタンの 3 種類のボタンを実装した．これらのボタンは，2 つの実験 (実験 1・実験 2) を行った．実験 1 では，3.3 節

それぞれ TDW の状態を SAGE2 モード・ParaView モーで実装した提案モジュールを用いて，可視化ミドルウェア

ド・Stop モードにスイッチングするためのものである．3.2

環境のスイッチング時間を計測した．実験 2 では，コンテ節で述べたように，Web UI 上のいずれかのボタンがタッ

ナ内の可視化ミドルウェアがレンダリングを行う際に発生チされると，そのボタンに対応するパラメータを含む GETする，Docker によるオーバーヘッドを計測した．

リクエストが制御サーバに向けて送信される．制御サーバ
がこの GET リクエストを受信すると，このリクエストに4.1 評価環境含まれるパラメータに対応するスイッチング用スクリプ

評価のため，3.3 節で実装したモジュールを，2 × 2 のトが実行される．このスイッチング用スクリプトとして，モニタ群と 4 ノードの PC クラスタから成る評価用 TDW

SAGE2 モード起動スクリプト・ParaView モード起動スク上で利用した．図 7 に，評価用 TDW の構成を示す．利用

リプト・Stop モード起動スクリプトという 3 種類のシェルしたモニタの解像度は全て 1366 × 768 ピクセルである．

スクリプトを実装した．以下では，各スイッチング用スク

TDW の PC クラスタを構成する 4 ノードの性能は，表 2リプトによって行われる処理の大まかな流れを説明する．に示す通りである．また，本評価で使用した各種ソフト

なお，本実装では，SAGE2 モードで利用する Chromium

ウェアのバージョンは，表 3 にまとめた．

ブラウザは，コンテナ内ではなくホスト OS 上で動作させるものとした．また，ParaView モードでは，各コンテナモニタ群 (2×2)

タブレットPC

内で起動する pvserver の数は 1 プロセスとした．

• SAGE2 モード起動スクリプト( 1 ) TDW の現状態が ParaView モードである場合，Docker Swarm クラスタ上で起動中のすべてのpvserver のコンテナ群を停止する．
( 2 ) マネージャノード上に，SAGE2 Server のコンテナを起動する．

( 3 ) (2) で起動したコンテナ内で，SAGE2 の初期設定

PCクラスタ!"#$%&

ト'$()*+,-.と SAGE2 Server の起動を行う．

'$/0123415'$617415

図 7 評価用 TDW( 4 ) 各 モ ニ タ 上 に て ，フ ル ス ク リ ー ン モ ー ド のChromium ブラウザを表示し，自身の持つ ClientCPUIntel Core i3-4150 (3.5GHz)

Memory8.0GB

GPUIntel HD Graphics 4400

OSCentOS 7.3

ID に対応する URL を開く．
• ParaView モード起動スクリプト( 1 ) TDW の現状態が SAGE2 モードである場合，起動中のすべての Chromium ブラウザ及び SAGE2

表 2PC クラスタのノードの仕様

Server のコンテナを停止する．
( 2 ) Docker Swarm クラスタ上で，pvserver のコンテ

ソフトウェア名バージョン

ナ群を，モニタ数と同じ数だけ起動する．

Docker

1.12.6( 3 ) (2) で起動した全コンテナの IP アドレスを収集

SAGE22.0.0

し，マネージャノード上の pvserver のコンテナ内ParaView

5.1.2に MPI 用のホストファイルを作成する．

Chromium

55.0.2883.87( 4 ) (3) で作成したホストファイルを用いて，全コンテ

表 3

評価で使用したソフトウェアのバージョン

ナ内の pvserver を MPI によって連携駆動させる．

c 2017 Information Processing Society of Japan⃝

5Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Report

4.2 実験内容

によって can.ex2 を可視化し，test.py を適用して実行

4.2.1 実験 1

時間を計測する．

実験 1 では，実装したモジュールが実行できる以下の 6( 3 ) (1) と (2) で得られた実行時間を次式に代入し，コン通りのスイッチング (A) 〜 (F) について，それぞれの所要テナ内の pvserver がレンダリングを行う際に生じる，時間 (スイッチング時間) を計測した．この計測は，スイッDocker によるオーバーヘッドを実行時間に対する比チング時に停止・起動する必要のある可視化ミドルウェア率として求める．

(のプロセス数を変えながら行った．可視化ミドルウェアのプロセスとは，SAGE2 モードで利用する Chromium ブラ

オーバーヘッド [%] =)(1) での実行時間 [s]− 1 × 100
(2) での実行時間 [s]ウザのプロセス及び ParaView モードで利用する pvserverのプロセスのことである．これらのプロセスは TDW のモ

4.3 評価結果

ニタ群を構成するモニタの台数と同じ数だけ必要になるた

4.3.1 実験 1め，プロセス数の変化範囲は 1〜4 とした．

図 9 に，実験 1 での計測結果を示す．図 9 の縦軸はス(A) SAGE2 モード → ParaView モード

イッチング時間 [s] であり，横軸はスイッチング時に起動・(B) SAGE2 モード → Stop モード

停止する必要のある可視化ミドルウェアのプロセス数であ(C) ParaView モード → SAGE2 モード

る．図 9 から，プロセス数が変化しても，(A) は約 13.5 秒，(D) ParaView モード → Stop モード(B) は約 5.6 秒，(C) は約 17.5 秒，(D) は約 5.2 秒，(E) は(E) Stop モード → SAGE2 モード

約 12.6 秒，(F) は約 8.3 秒のスイッチング時間を維持する(F) Stop モード → ParaView モード

ことを確認した．この結果から，提案モジュールによるスイッチング (A) 〜 (F) は，可視化ミドルウェアのプロセ4.2.2 実験 2

ス数が変化しても，実用上問題無い程度の時間で完了する

実験 2 では，コンテナ内の pvserver がレンダリングを行ことを確認できた．

う際に生じる Docker によるオーバーヘッドを計測した．
この計測では，2.2.2 節で述べた ParaView の Python スク
リプティング機能を利用した．本計測で用いた Python ス
クリプト (test.py) のソースコードは，本論文の付録に示す．このスクリプトは，可視化された 3D データに対して「x 軸方向に 1 度回転させて再描画する」という処理を 360回繰り返すことで 1 回転させ，その実行時間 (10 回の実行の平均) を計測するという内容である．また，計測の際にParaView によって可視化するデータとして，図 8 に示す
can.ex2 (ParaView に付属する 17MB のサンプル 3D データ) を用いた．
図 9

提案モジュールによるスイッチング時間

4.3.2 実験 2
図 10 に，実験 2 での計測結果を示す．図 10 の縦軸はDocker によるオーバーヘッドの比率 [%] であり，横軸はpvserver のプロセス数である．図 10 から，Docker による
図 8

ParaView で可視化した can.ex2

オーバーヘッドの比率は，pvserver のプロセス数が変化しても 3%前後で維持されることを確認した．3.1 節で述

実験 2 の具体的な手順を以下に示す．以下の手順を，べたように，プロセス実行時のコンテナ型仮想化のオー

pvserver のプロセス数を 1〜4 の範囲で変えながら行った．

バーヘッドは極めて小さい．実験 2 で観測されたオーバーヘッドの主な原因は，可視化するデータを各コンテナ内の( 1 ) Docker を利用してコンテナ内で起動した pvserver にpvserver のバッファにロードするために，Docker のオー

よって can.ex2 を可視化し，test.py を適用して実行時

バーレイネットワーク機能 (複数ホストにまたがるコンテ間を計測する．

ナ間通信を実現する機能) を利用する際に生じた遅延にあ( 2 ) Docker を利用せずにホスト OS 上で起動した pvserverc 2017 Information Processing Society of Japan⃝ると考えられる．

6

Vol.2017-OS-140 No.17
2017/5/17

情報処理学会研究報告
IPSJ SIG Technical Report

ParaView は，OpenGL によるグラフィックボードのアクセラレーションを用いて 3D の描画を行う．このようなOpenGL を用いた描画では，ダブルバッファリング等のバッファ多重化技術が用いられる．バッファを多重に持つことで，描画とデータロードを並行して行うことが可能と[3]なり，レンダリング速度の向上につながる．したがって，pvserver がオーバーレイネットワーク機能を利用する際に生じる遅延の影響は，pvserver のバッファを増やすことである程度軽減できると考えられる．

[4]
[5]

[6]

[7]
図 10

レンダリング時の Docker によるオーバーヘッド

5. まとめと今後の課題[8]

本研究では，共有利用を想定した TDW での可視化ミド
ルウェア環境の分離とスイッチング機能の提案を行った．
環境の分離にはコンテナ型仮想化技術 Docker を利用し，スイッチング機能としては SAGE2 モード・ParaView モード・Stop モードという 3 状態間でのスイッチングを可能[9]

Yamanaka, H., Kawai, E., Takemura, H. and Shimojo, S.:
SAGE-based Tiled Display Wall enhanced with dynamicrouting functionality triggered by user interaction, Future
Generation Computer Systems, Vol. 56, pp. 303–314(2016).
Humphreys, G., Buck, I., Eldridge, M. and Hanrahan, P.:
Distributed rendering for scalable displays, Proceedingsof the 2000 ACM/IEEE conference on SuperComputing,No. 30 (2000).
大阪大学サイバーメディアセンター大規模可視化システ
ム，http://vis.cmc.osaka-u.ac.jp/.
Marrinan, T., Aurisano, J., Nishimoto, A., Bharadwaj,K., Mateevitsi, V., Renambot, L., Long, L., Johnson, A.
and Leigh, J.: SAGE2: A New Approach for Data Intensive Collaboration Using Scalable Resolution Shared Displays, Proceedings of the 2014 IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing, pp. 177–186 (2014).
Cedilnik, A., Geveci, B., Moreland, K., Ahrens, J. andFavre, J.: Remote large data visualization in the paraview framework, Proceedings of the 2006 Eurographics
Symposium on Parallel Graphics and Visualization, pp.
163–170 (2006).
Wierse, A.: Performance of the collaborative visualization
environment (COVISE) visualization system under diﬀerent conditions, Proceedings of the 1995 International Society for Optics and Photonics’s Symposium on Electronic Imaging: Science & Technology, Vol. 2410, pp.
218–229 (1995).
Kan, C.: DoCloud: An elastic cloud platform for Web
applications based on Docker, Proceedings of the 2016
International Conference on Advanced Communication
Technology, pp. 478–483 (2016).
Naik, N.: Building a virtual system of systems using
docker swarm in multiple clouds, Proceedings of the 2016
IEEE International Symposium on Systems Engineering, pp. 1–3 (2016).にする提案モジュールを実装した．評価としては，提案手法の実用性について検討するために，2 つの実験 (実験 1・実験 2) を行った．実験 1 の結果，提案モジュールによるスイッチング時間は，可視化ミドルウェアのプロセス数が変化しても実用上問題無い程度で維持されることを確認した．また，実験 2 の結果，コンテナ内の pvserver によるレンダリングの際に生じる Docker のオーバーヘッドの比率は，pvserver 数が変化しても 3%前後で維持されることを確認した．これらの結果から，提案手法の実用性を確認することができた．
今後の課題としては，より大規模な TDW を用いた評価実験の実施や，ハイパーバイザ型仮想化を用いることによる提案モジュールの改良がある．
謝辞

本研究は JSPS 科研費 JP26540053 の助成を受けたものです．
参考文献
[1]

[2]

山田知典，野口紘一，淀薫，和田義孝，藤井秀樹，吉村忍：
大規模耐震シミュレーション結果のサーバーサイドスクリーニング，日本計算工学会論文集，Vol. 2016, pp. 1–7(2016).
Kido, Y., Ichikawa, K., Date, S., Watashiba, Y., Abe, H.,

c 2017 Information Processing Society of Japan⃝

7情報処理学会研究報告IPSJ SIG Technical Report付Vol.2017-OS-140 No.17
2017/5/17

録

付録として，4.2.2 節で述べた Python スクリプト (test.py)のソースコードを以下に示す．

1 # test.py
23 import paraview
4 import time5
6 # 変数の初期化
7 average = 0
8
9 # 計 測 を10回 実 行
10 f o r i i n r a n g e (1 , 1 1 ) :11# 開始時刻の取得

12

start_time = time.time()

13
14# 360回 再 描 画 を 実 行

15camera = GetActiveCamera()16

f o r a n g l e i n r a n g e (1 , 3 6 1 ) :17# x軸方向に1度回転

18

camera.Roll(1)

19

# 再描画

20Render()21
22# 終了時刻の取得23

end_time = time.time()

24
25# 実行時間の計測

26

interval = end_time - start_time

27

average += interval

28
29 # 実 行 時 間 の 平 均 を 計 算
30 a v e r a g e / = 1 0
31 p r i n t a v e r a g ec 2017 Information Processing Society of Japan⃝8