DEIM Forum 2016 G8-4

緊急時における外部情報を用いたデータ転送によるデータ管理の自動化
西出 彩花†

細谷 柚子†

小口 正人†† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2–1–1
E-mail: †{g1120531,oguchi}@is.ocha.ac.jp, ††yuzuko@ogl.is.ocha.ac.jp
あらまし

近年の情報技術の発達に伴い，企業が管理しなくてはならないデータ量は日々増え続けている．これに伴い，クラウドの利用が企業の間で急速に進んでいる．一方で重要な顧客データ，会計データ等を扱う基幹システムや，高速な処理を必要とするシステムなど，オンプレミスでの運用が適しているケースも少なくない．そのため企業のシステムは，「変動する可能性の高い，一般的なデータ」をコストや導入スピードに優れるパブリッククラウド（SaaS）に保管し，「会社内部の機密情報を含むデータ」をオンプレミス（プライベートクラウド）に保管するような，プライベートクラウドとパブリッククラウドで提供されるサービスを組み合わせた「ハイブリッドクラウド」の形へと進んでいる．このハイブリッドクラウド環境では，従来プライベートクラウドで構築，運用されていた様々な業務システムが，プライベートクラウドとパブリッククラウドに分散配置されることになる．また，新たにパブリッククラウドで提供されるサービスを利用する際は，プライベートクラウドでの既存の業務処理と連携させた運用が必要となる．
このため，パブリッククラウドとプライベートクラウド間でのデータベースの冗長的な同期が必要不可欠である．また，日本は火山やプレートに囲まれており，地震などの自然災害の影響を受けることが多い．災害時に重要なデータを失わないために，冗長的に遠隔地にバックアップを行っておく必要がある．また，災害時には安否確認などで，災害地へのアクセスの急増が予測される．そこで本研究では，そこで本研究では，通常時の冗長的なデータベースのバックアップに加え，緊急時には外部情報をトリガに，バースト的な負荷変動を避けるためデータベース処理を実行するインスタンスのマイグレーションを行うことにより，データを守り，データベースアクセスの継続を実現するための手法を考察する．
キーワード

クラウドコンピューティング，OpenStack，データベース，遠隔バックアップ，OpenFlow

1. は じ め にスト的なアクセスの増加が起こることが考えられる．これは，ネットワークに大きな負荷をかけ，サーバなどの機能の低下を近年，コンピュータシステムにおける情報量が爆発的に増加引き起こす．この際に安全にデータを転送するためには，帯している．その処理プラットフォームとして，クラウドの利用域が不足する経路を迂回してパケットを別の経路に振り分けが注目を集めている [1]．中でも，変動する可能性の高い一般的たり，マイグレーションの性能を上げたりする必要がある．そなデータをパブリッククラウドに保管し，会社内部の機密情報こで本研究では，データベースの冗長的な遠隔バックアップを含むデータをプライベートクラウドに保管する，といった，と，災害時の外部情報をトリガとするマイグレーションによっ複数のクラウドを効率的に使い分ける環境である，”ハイブリッて継続的なデータアクセスを実現するシステムを提案する．

ドクラウド”に特に着目する人が多い．

OpenStack [3] [4] を用いて仮想環境上にクラウド基盤を構築し，ハイブリッドクラウドを利用する際には，パブリッククラウデータベースの遠隔バックアップを動作させて，インスタンスドとプライベートクラウド間で，データベースの冗長的な同マイグレーションを行うことにより，提案システムを実現する．

期が必要である．一般にパブリッククラウドとプライベートク

さらに OpenFlow のスイッチ制御で，マイグレーション性能をラウドは別の場所に構築され，多くの場合，両者の距離は離れ向上させることにより，緊急時に確実なデータ転送を行う．ている．従って両者間でデータベースの遠隔同期や遠隔バックアップが行われることになる．

OpenStack とは，クラウドを構成する仮想マシンや物理サーバの運用管理を実行し，それを効率的に行うためのオープン

一方で，日本は火山やプレートに囲まれており，地震などのソースのクラウド構築ソフトウェアである．OpenStack の利

自然災害の影響を受けることが多い．2011 年の東日本大震災

用者は，KVM などで構成されるハイパーバイザ上で動作するで多くのデータが失われた [2] ことなどから，災害発生時には仮想マシンに外部ネットワークからアクセスし，CPU，メモ迅速にデータを災害地から別の場所へ移す必要があることがわ

リ，HDD，IP アドレス等の計算資源を利用することができる．

かる．このとき，災害地付近でバースト的に大量のデータが転OpenStack は複数のコンポーネントから構成され，これらの送されることが考えられる．

コンポーネントが連携することで IaaS のサービスを提供する

また，SNS や高機能デバイスの普及に伴い，災害地にはバーアーキテクチャである．OpenStack の構成を図 1 に示す．

図 2 Pangea**える．そこで重要となるのが，外部情報をトリガとして緊急時に自動でデータを転送するシステムを用意しておくことである．
図 1 OpenStack の構成

本研究では Twitter などのソーシャル情報から関連する情報を引き出し，それを元に分析を行うことで，負荷のかかる

2. 先 行 研 究
2. 1 Pangea

ノードや障害発生場所の情報を入手し [7]，これらを元に OpenvSwitch [8] を用いて通信経路の制御を行う [9]．
本研究では，コントローラの代わりに RabbitMQ に notify

前述した Pangea [5] について説明する．Pangea は，NTT 研キューを作り，ここで Open vSwitch をコントロールする．

究所で開発されている，LAN 環境を前提としたデータベース

2. 4 負荷分散による効率的なデータマイグレーション

同期ミドルウェアである．コンシステンシを保ちながら，複数データマイグレーションを行うことは，緊急時のデータ保護

台のサーバでデータベースのクエリ処理を並列実行する事にと災害地付近のバースト的なアクセス負荷の分散に有用である

より，性能向上を実現した．これら複数台のサーバは，同一のと考えられる．しかし同時に，マイグレーションに伴うディスデータベースイメージを保持しており，同一 LAN 上に接続さクアクセスやネットワーク転送により，システム性能を一時的れている．サーバの 1 台を Leader，その他は Follower としてに低下させ得る．

おり，クライアントからこのミドルウェアを介してサーバにア

この性能低下を抑えることを目的とし，データマイグレークセスをして同期をとる．全てのクエリは照会処理と更新処理

ション時のみ複製データへアクセス要求を一部回送する手法を，に分類され，照会処理はどれか 1 台のサーバで，更新処理は全2004 年に東京工業大学の小林らは発表している [10]．これによてのサーバで実行される．更新処理の場合は Leader に対してり負荷集中時の円滑なデータ移動が可能となる．

更新をした後に，Follower に対しても同様に処理を行う．

また彼らは 2007 年までに，ストレージノード中に格納され2. 2 Pangea**

るバックアップデータを用いたデータの移動経路の変更とアク

次に Pangea** [6] について説明する．Pangea**とは，前述セスの回送により，円滑にマイグレーションを行う資源を確保の Pangea をベースに開発された，リモートバックアップ機能を有したクラスタデータベースシステムのことである．Pangeaは LAN 環境では非常に良い性能であるが，遠隔地にあるサーバにバックアップをとろうとすると，遅延の影響を多く受けてしまい大幅な性能低下をもたらすことが予想される．これを受する手法について [11] [12] も発表している．
これを大規模災害時のマイグレーション時にも適応させることが可能であると考えられる．

3. 提 案 手 法

けて，非同期バックアップを取り入れた Pangea**が開発され

3. 1 クラウドにおけるインスタンスマイグレーションている．Pangea**では，照会処理と更新処理に区別された後OpenStack ではコンポーネントの１つである Nova のマイにこの処理をマスタとスレーブに分離して，遠隔地に配置したグレーション機能を用いることが可能である．Nova のマイグスレーブへは非同期データ転送とし，さらにスレーブから遠隔レーション機能は大きく分けて以下の 3 つである．

ストレージへのアクセスを並列化することにより，遠隔バック（ 1 ） コールドマイグレーション

アップを行ってもデータベース処理性能が落ちないようになっ

停止している仮想マシンを他のノードに移動させる．ている．この様子を表したものが図 2 である．遠隔地でバック移動先は nova-scheduler により自動的に指定される．

アップをとることで，災害時のデータ損失を防ぐことができる．

•Pangea**は 2 台のサーバに展開する．本研究ではまず Pangea

nova-compute が稼働しているノードから任意の 1 台をランをミドルウェアとして利用する．

チャンススケジューラ

ダムに選択する．

2. 3 外部情報を用いたトラフィックの制御•

本研究では，緊急時のトラフィック制御にも着目している．災「フィルタ」と「重み」の 2 種類の条件で，最適なノードを害時のバースト的な負荷変動はネットワークに大きな影響を与フィルタスケジューラ選択する．

このコールドマイグレーションが Horizon による GUI からマラウドとする．本研究ではパブリッククラウドには 2014 年 4イグレーションを行った時の標準の仕様となっている．

月リリースの Icehouse を用いて，コントローラノード 1 台，（ 2 ） ライブマイグレーション

ネットワークノード 1 台，コンピュートノード 4 台の計 6 台の稼働している仮想マシンを他のノードに移動させる．

サーバからなるクラウド基盤を構築した．コントローラノード

共有ディスクの利用が必須である．には RabbitMQ,NTP，Keystone，Glance，Nova，Neutron，（ 3 ） ブロックマイグレーション

Cinder，Ceilometer，Swift，Heat，セキュリティグループ，フ稼働している仮想マシンを他のノードに移動させる．

ロントエンドを，ネットワークノードには Neutron を，コンディスクとメモリのみをコピーするので共有ディスク環境は

ピュートノードには Nova，Neutron，Ceilometer，Swift を配必要がない．

置した．

本研究では，コールドマイグレーションを中心に実験を行った

一方で，プライベートクラウドには 2015 年 10 月リリース

が，将来的にはブロックマイグレーションへの応用が有用であの Liberty を用いてコントローラノード 1 台とコンピュートると考えられる．

ノード 4 台の計 5 台のサーバからなるクラウド基盤を構築

3. 2 本研究でのクラウドの利用した．コントローラノードには RabbitMQ, NTP, MariaDB,

本研究では複数のクラウドを用いて，異なるクラウド間でKeystone，Glance，Nova，Neutron，Linux Bridge Agent，L3のマイグレーションに着目する．外部情報をトリガに，プライAgent，DHCP Agent，Metadata Agent，Cinder を，コンピベートクラウドからパブリッククラウドへ仮想マシンをマイグュートノードには Linux KVM，Nova Compute，Linux Bridge

レートする場合について考える．

Agent を配置した．

これを図 3 に表す．共有ストレージとの間に Pangea**を介

そのほかにマイグレーション時に共有ストレージとするためすることで，マイグレーションの際に遠隔地にあるクラウド内のサーバを 1 台用意した．この２つのクラウド間でリソースのデータベースへのアクセスを行う必要がなくなるため，負荷の転送を行うことで異なるクラウド構築環境をまたいだハイブの軽減が予想される．

リッドクラウドの環境が実現される．構築に用いた物理サーバ

まず，元々仮想マシンが置かれていた compute1 上の DB1のスペックを表 1 に，構築した環境を図 4 に示す．と仮想マシンを切り離す．DB1 の上のデータでパブリッククラウドからもアクセスが可能であるべきだと判断されたデータ

表 1 使用サーバのスペック

OS

Linux3.13.0-43-generic Ubuntu14.04.3 64bitに関わるクエリは Pangea**をベースとするミドルウェアを介CPUIntel(R)Xeon CPU E3-1270V2 @3.50GHz 4C/8T

し，共有ストレージにバックアップされる．DB2 がここにアクMemory 16GBセスすることで，必要なデータを取得することができる．同時Disk500GBに OpenStack クラウド上のマイグレーション機能を用いて仮想マシンをプライベートクラウドからパブリッククラウドへマイグレートする．
これにより仮想マシンとデータベースのクラウドを跨いだマイグレーションが可能となる．

図4

実験環境 (物理サーバ)

4. 2 基本性能検証
まずパブリッククラウド内で，インスタンスマイグレーショ
図 3 クラウドを挟んだデータベースマイグレーション

ンに関する性能の検証を行った．3 章で述べた提案手法において，インスタンスのマイグレーションは重要な役割を持ってお4. OpenStack を用いた実験
4. 1 実 験 環 境り，その性能が提案手法のパフォーマンスに大きな影響を与える．
複数のコンピュートノード下に複数の仮想マシンを作り，一本研究で想定するクラウド環境を，IaaS のクラウド環境構方からもう一方へ Iperf [13] コマンドを用いてパケットを流し築ソフトウェアの OpenStack（Icahouse）を用いて構築した．

ながらマイグレーションを行った．ライブマイグレーションの

12 台の物理サーバを用意し，6 台ずつを用いてクラウド環境

際にはマイグレーション先の指定が可能であるが，そうでないを構築し，それぞれをパブリッククラウドとプライベートク

ときには OpenStack 内の Nova のスケジューラ機能がマイグレーション先のノードを指定する．本研究ではコールドマイち上がるように設定する．

グレーションを行うため，マイグレーション先のノードはスケデータベース配置サーバに Postgresql サーバをインストールジューラ機能に委ねることとなる．この実験のイメージ図を図し，クライアントサーバには tpc-w 用の Tomcat を，Pangea

5 に表す．

配置サーバでは Pangea を立ち上げる．この環境下でデータベース間で転送を行い，スループットやレスポンス時間を計測することで，Pangea の利用により転送の性能があがることを確認する．構築した環境の物理イメージを図 7 に，作成した仮想マシンのネットワークイメージを図 8 に示す．

図5

実験イメージ図

結果を図 6 に示す．この結果から，パケットを流さずにマイグレーションを行った際には平均 26.3 秒程度だったものと比較することから，対象のマイグレーションに関係のないパケット

図7

物理イメージ図について，他の経路を経由する様なパケット制御をすることによるマイグレーション効率の向上が期待できることが分かった．
また，本研究では compute11 上に共有ディスクを置き，ここに NFS マウントすることでマイグレーションを行うように環境を構築した．構築時に最も安定する構成だったからである．

compute11 から，または compute11 へのマイグレーション時間が極端に短いため，compute11 に共有ディスクが置かれていることが実験結果に与える影響が大きいことがわかる．
このことから，共有ディスクを介するマイグレーションを必要最小限にすることで，通信性能を安定化させることが可能であると考えられる．

図 8 仮想マシンイメージ図

4. 4 実 験 結 果
4.3 節で紹介した環境下で性能検証を行う．TPC-W における仮想ブラウザ数 EB（クライアントからの負荷量）を変化させた時のスループットを 9，レスポンス時間を図 10 に示す．
インスタンスを介さず物理サーバ上で直接同じ実験を行った結果である図 11，12 と比較すると，最大スループット値が39%低下するなどの大きな性能の低下がみられる．
この要因として，まず，仮想化によるオーバヘッドがあげら
図 6 VM 間で Iperf を用いたマイグレーション結果れる．これは DB までクライアントサーバと Pangea サーバと共にインスタンス上に置いていたため，ストレージアクセス

4. 3 OpenStack への Pangea**の導入のコストが高くなっていたと考えられることから，これを物理クラウド上で Pangea を用いる性能考察を行うために, 構築しサーバに直接置くようにすることで，改善されることが見込またクラウド環境内に仮想マシンを立ち上げる．OpenStack におれる．

いては，コントローラノードから指示を出し，この指示に従っまた，今回の測定環境ではメモリサイズの大きさが仮想マシてコンピュートノード上でインスタンスが起動される．本実験

ンと物理サーバで大きく異なるため，これも差が出た要因の一では OpenStack のコンピュートノード 4 台のうち，1 台をクつであると考えられる．これは今後の測定の際に仮想マシンとライアントサーバ，1 台を Pangea 配置サーバ，2 台をデータ物理サーバのメモリサイズを調整することで，正確な比較がでベース配置サーバとする．この際，仮想マシンのインスタンスきるようになる事が期待される．

としては，ダウンロードした Ubuntu14.04 のインストールイメージを元に，80G のディスク領域を使用した Linux OS が立を小さくする工夫が必要となる．また，DB1 と DB2 の間にダミーネットを挿入することで，遠隔地でのマイグレーションの性能についても再考する必要があると考える．本稿では，データベースサーバ内の全てのデータを同期することを前提としている．しかし，実際にハイブリッドクラウドとしてクラウドを利用する際にはセキュリティの問題などから，パブリッククラウドとプライベートクラウドに保存されるデータは一部異なることが予想される．そのため，要求されたクエリがパブリック
図 9 VM 上で Pangea を動かしたときのスループット

クラウドからのアクセスが認められたデータであるかどうかもPangea**内で区別することにより，テーブルごとのデータ管理を可能としていきたい．これは，Pangea**がパケットを元にクエリの種類の判断をしていることから，可能であると判断される．

謝辞

本研究を進めるにあたり，NTT 三島健様に数多くの助言を賜りました．深く感謝いたします．
文
図 10 VM 上で Pangea を動かしたときのレスポンス時間

図 11

物理サーバ上で Pangea を動かしたときのスループット

図 12 物理サーバ上で Pangea を動かしたときのレスポンス時間

5. まとめと今後の課題
OpenStack(Icehouse) を用いて構築した環境内での仮想マシンマイグレーションの性能検証を行った．
この結果から，汎用的な利用には相応しくないと判断し，ブロックマイグレーションを行う環境を整えるために OpenStackの最新バージョンである Liberty を用いて共有ストレージを用いないデータベースマイグレーションについて検討している．
今後は，Pangea をクラウド上に上げる際に，オーバヘッド

献[1] Naoto Matsumoto : ”クラウドコンピューティングへの誤解と注意点”，IEICE Communications Society Magazine，Vol．7
No．3，March 2014，pp．175–177．
[2] Masugi Inoue : ”頼れる情報通信インフラストラクチャの実現を目指して”，IEICE Communications Society Magazine，Vol．5 No．3，March 2012，pp．203–208．
[3] OpenStack : http://www.oprnstack.org/[4] 中井悦司，中島倫明：「オープンソース・クラウド基盤 OpenStack入門」2014 年 7 月 29 日第一版第三刷[5] T.Mishima and H.Nakamura :”Pangea:An Eager
Database Replication Middleware guaranteeing Snapshot Isolation without Modication of Database Servers”,
Proc.VLDB2009,pp.1066-1077, August 2009. PVLDB2009.
[6] 細谷 柚子，小口 正人：「リモートバックアップ機能を有するクラスタデータベースシステムの提案」電子情報通信学会 データ
工学研究会，信学技報，Vol.115，No.230, pp. 35 – 39, 2015
年 9 月．
[7] Chihiro Maru, Miki Enoki, Akihiro Nakao, Shu Yamamoto,Saneyasu Yamaguchi, and Masato Oguchi, ”Network Failure Detection System for Traﬃc Control using Social Information in Large-Scale Disasters,” ITU Kaleidoscope Conference 2015: Trust in the Information Society, S5.3, December
2015.
[8] Open vSwitch : http://openvswitch.org/[9] 原瑠理子，小口正人：「緊急地震速報に基づくハイブリッドクラウドにおけるバックアップシステムの検討」 マルチメディア，分散，協調とモバイル (DICOMO2015) シンポジウム， 8B-4,pp. 1659 - 1663，2015 年 7 月．
[10] 小林大，渡邊明嗣，山口宗慶，田口亮，上原年博，横田治夫 :「複製データを併用した効率的なデータマイグレーションの検討」，DBSJ LettersVeL3，No .2，2004[11] 小林大，田口亮，横田治夫 :「並列ストレージにおけるサービス性能を保った複製利用負荷均衡化に対する更新リクエストの影
響」，DEWS2007 論文集，pp.L2-1，March 2007[12] 小林大，渡邊明嗣，山口宗慶，田口亮，上原年博，横田治夫 :「負荷分散のためのデータ移動による性能低下を抑制するアクセス回送制御」，TECHNICAL REPORT OF IEICE，DE2004-112，
DC2004-27[13] Iperf - The TCP/UDP Bandwidth Measurement Tool
:https://iperf.fr/