DEIM Forum 2017 H4-5

OpenStack 環境下におけるデータベースの管理システムの検討
西出 彩花†

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

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

OpenStack，データベース，ハイブリッドクラウド，マイグレーション

1. は じ め にスト的なアクセスの増加が起こることが考えられる．これは，ネットワークに大きな負荷をかけ，サーバなどの機能の低下を

近年，コンピュータシステムにおける情報量が爆発的に増加引き起こす．この際に安全にデータを転送するためには，帯している．その処理プラットフォームとして，クラウドの利用

域が不足する経路を迂回してパケットを別の経路に振り分けが注目を集めている [1]．中でも，変動する可能性の高い一般的

たり，マイグレーションの性能を上げたりする必要がある．そなデータをパブリッククラウドに保管し，会社内部の機密情報

こで本研究では，データベースの冗長的な遠隔バックアップ

を含むデータをプライベートクラウドに保管する，といった，と，災害時の外部情報をトリガとするマイグレーションによっ複数のクラウドを効率的に使い分ける環境である，”ハイブリッて継続的なデータアクセスを実現するシステムを提案する．

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

OpenStack [3] [4] を用いて仮想環境上にクラウド基盤を構築し，ハイブリッドクラウドを利用する際には，パブリッククラウ

データベースの遠隔バックアップを動作させて，インスタンス

ドとプライベートクラウド間で，データベースの冗長的な同マイグレーションを行うことにより，提案システムを実現する．

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

さらに OpenFlow のスイッチ制御で，マイグレーション性能をラウドは別の場所に構築され，多くの場合，両者の距離は離れ向上させることにより，緊急時に確実なデータ転送を行う．

ている．従って両者間でデータベースの遠隔同期や遠隔バック
アップが行われることになる．
一方で，日本は火山やプレートに囲まれており，地震などの

2. 既 存 技 術
2. 1 OpenStack

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

まず，本研究でシステム構築に用いた OpenStack についてで多くのデータが失われた [2] ことなどから，災害発生時には説明する．OpenStack [3] [4] は，クラウドを構成する仮想マ

迅速にデータを被災地から別の場所へ移す必要があることがわ

シンや物理サーバの運用管理を実行し，それを効率的に行う

かる．このとき，被災地付近でバースト的に大量のデータが転ためのオープンソースのクラウド構築ソフトウェアである．

送されることが考えられる．

OpenStack の利用者は，KVM などで構成されるハイパーバ

また，SNS や高機能デバイスの普及に伴い，災害地にはバー

イザ上で動作する仮想マシンに外部ネットワークからアクセス

し，CPU，メモリ，HDD，IP アドレス等の計算資源を利用す

クアクセスやネットワーク転送により，システム性能を一時的ることができる．複数のコンポーネントから構成され，これらに低下させ得る．

のコンポーネントが連携することで IaaS のサービスを提供するアーキテクチャである．

OpenStack の構成を図 1 に示す．

この性能低下を抑えることを目的とし，データマイグレー
ション時のみ複製データへアクセス要求を一部回送する手法を，2004 年に東京工業大学の小林らは発表している [10]．これにより負荷集中時の円滑なデータ移動が可能となる．
また彼らは 2007 年までに，ストレージノード中に格納されるバックアップデータを用いたデータの移動経路の変更とアクセスの回送により，円滑にマイグレーションを行う資源を確保する手法についても発表している．[11] [12]これを大規模災害時のマイグレーション時にも適応させることが可能であると考えられる．

3. 提 案 手 法
緊急地震速報のような外部からの緊急災害や負荷変動を予告するシグナルが入って来る際に，それをトリガとしてシステム構成を切り替えるシステムについて説明する．
これを図 2 に表す．
図 1 OpenStack の構成

2. 2 Pangea
次に，前述した Pangea [5] について説明する．Pangea は，LAN 環境を前提としたデータベース同期ミドルウェアである．
コンシステンシを保ちながら，複数台のサーバでデータベースのクエリ処理を並列実行する事により，性能向上を実現した．
これら複数台のサーバは，同一のデータベースイメージを保持しており，同一 LAN 上に接続されている．サーバの 1 台をLeader，その他は Follower としており，クライアントからこのミドルウェアを介してサーバにアクセスして同期をとる．全てのクエリは照会処理と更新処理に分類され，照会処理はどれ

図2

緊急災害時のシステムのイメージ図

か 1 台のサーバで，更新処理は全てのサーバで実行される．更新処理の場合は Leader に対して更新をした後に，Follower にまず，トリガとなる外部情報を取得する．

対しても同様に処理を行う．

この手法として，災害の情報を Twitter などの外部情報から

また，日本とブラジルのような遠隔地でデータベースを同期検知することが挙げられる．例えば，大地震後におけるデータする際の性能向上を図った Pangea** [6] は，タイムスタンプな

センタ本体の物理的損傷対策の場合，気象庁が発表する緊急地どに着目して，距離がボトルネックとなっている問題を解決し震速報の BOT は，投稿される形式が決まっているため，そのようとしたものである．

ツイートから Twitter Stream Reader を用いて，震源地や震2. 3 外部情報を用いたトラフィックの制御

度や地震の規模を取得することが可能である．

本研究では，緊急時のトラフィック制御にも着目している．災Twitter Stream Reader は緊急地震速報のツイートをトリガ

害時のバースト的な負荷変動はネットワークに大きな影響を与に，テキストファイルを書き換える．incron により，テキスト

える．そこで重要となるのが，外部情報をトリガとして緊急時

ファイルに変更があった際に，シェルスクリプトが実行されるに自動でデータを転送するシステムを用意しておくことである．

ように設定しておく．

Twitter などのソーシャル情報から関連する情報を引き出し，

シェルスクリプトを実行することにより，マイグレートに必

それを元に分析を行うことで，負荷のかかるノードや障害発生

要のないポートを落としたり，安定した通信の環境下でデータ

場所の情報を入手し [7]，これらを元に Open vSwitch [8] を用

ベースと共有用ストレージの再同期を行ったりすることが可能

いて通信経路の制御を行う [9]．

である．その後，仮想マシンをマイグレートし，遠隔地にある

2. 4 データマイグレーションを効率化する負荷分散

データセンタでマイグレートされたサーバを起動させる．

データマイグレーションを行うことは，緊急時のデータ保護

最後に，その新しいサーバと共有用ストレージを同期し，必と被災地付近のバースト的なアクセス負荷の分散に有用である

要なポートを開放しなおす．仮想マシンがマイグレーションさと考えられる．しかし同時に，マイグレーションに伴うディスれる際に Pangea の接続は解除されるが，転送中も Pangea が置かれているサーバ上のデータベースが起動しているため，転常に別のコンピュートノードと同期されている．また，マイグ

送後に差分を抽出することで，仮想マシン転送中に受けるアク

レート中に送られたクエリ分の更新が補完されているのを確認

セスについても対応可能となっている．これにより新しいデー

するために，同様にクラウド上に Ubuntu14.04 の 10GB のイ

タセンタ上で新しくシステムを動かすことができる．

メージを用意し，このイメージから作成した仮想マシンからク

4. 実 験 環 境

エリを出すようにした．本システムの構成の全体のイメージ図を図 4 に，データベース部についてのイメージ図を図 5 に表す．

本提案システムで想定するクラウド環境を，IaaS のクラウ

action1.sh が実行されると，Pangea の動きは停止し，同時にド環境構築ソフトウェアの OpenStack（Icehouse）を用いて構Pangea 用ポートの 3333 が PostgreSQL サーバに共有される．

築した．6 台の物理サーバを用意し，これらを用いてクラウド

転送中にユーザが投げたクエリは，一度 Pangea 用サーバの環境を構築する．本研究ではパブリッククラウドには 2014 年

PostgreSQL のみに反映され，マイグレーション終了後に，そ4 月リリースの Icehouse を用いて，コントローラノード 1 台，の間に Pangea サーバのある PostgreSQL に貯められた WAL

ネットワークノード 1 台，コンピュートノード 4 台の計 6 台のデータを他のサーバ上で展開することで反映させる．

サーバからなるクラウド基盤を構築した．コントローラノードには RabbitMQ, NTP，Keystone，Glance，Nova，Neutron，

Cinder，Ceilometer，Swift，Heat，セキュリティグループ，フロントエンドを，ネットワークノードには Neutron を，コン
ピュートノードには Nova，Neutron，Ceilometer，Swift を配置した．構築に用いた物理サーバのスペックを表 1 に，構築した環境を図 3 に示す．
表 1 使用サーバのスペック

OS

Linux3.13.0-43-generic Ubuntu14.04.3 64bit

CPUIntel(R)Xeon CPU E3-1270V2 @3.50GHz 4C/8T

Memory 16GB
Disk

500GB

図 4 提案システムのイメージ図

図 5 データベース共有のイメージ

4. 1 予備実験 1
図 3 OpenStack 構成図

4. 1. 1 実 験 環 境
クラウド上で Pangea を利用する際の性能評価を行うため

まず，クラウド上で性能考察を行うために, 構築したクラウドに， Pangea で利用する全てのサーバにクラウド上にある仮想環境内に仮想マシンを立ち上げる．OpenStack においては，コ

マシンを利用し，そのスループットを評価する．データベース

ントローラノードから指示を出し，この指示に従ってコンピュー配置サーバに PostgreSQL サーバをインストールし，クライア

トノード上でインスタンスが起動される．今回は，マイグレー

ントサーバには TPC-W 用の Tomcat を，Pangea 配置サーション用の仮想マシンとして，ダウンロードした Ubuntu14.04

バでは Pangea を立ち上げる．この環境下でデータベース間でのインストールイメージを元に，80GB のディスク領域を使用

転送を行い，スループットやレスポンス時間を計測することで，した Linux OS を利用した．このとき，クラウドの外にある物

Pangea の利用により転送の性能があがることを確認する．構

理サーバを Pangea 用サーバとして利用する．これは，後述す

築した環境の物理イメージを図 6 に，作成した仮想マシンのる予備実験１により考えられた構成である．

ネットワークの利用のされ方のイメージを図 7 に示す．

また，この仮想マシンはアプリケーションとして利用する
データベースの一部は，本体が置かれているコンピュートノー
ド上のデータ領域を利用しており，これは Pangea を用いて

図 8 VM 上で Pangea を動かしたときのスループット値
図6

物理イメージ図

図 9 VM 上で Pangea を動かしたときのレスポンス時間

図 7 物理マシンイメージ図

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

図 10 物理サーバ上で Pangea を動かしたときのスループット値れる．これは DB までクライアントサーバと Pangea サーバ
と共にインスタンス上に置いていたため，ストレージアクセスのコストが高くなっていたと考えられることから，これを物理
サーバに直接置くようにすることで，改善されることが見込まれる．
また，今回の測定環境ではメモリサイズの大きさが仮想マシ
ンと物理サーバで大きく異なるため，これも差が出た要因の一つであると考えられる．これは今後の測定の際に仮想マシンと
物理サーバのメモリサイズを調整することで，正確な比較ができるようになる事が期待される．

4. 2 予備実験 1’

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

4. 2. 1 予備実験 1 の再考察
前述のように，このシステムを構築する際に，全てのサーバの経路から転送するのは，時間がかかりすぎてしまうというこをクラウド上に載せて構築すると，仮想化によるオーバヘッド

とも考えられる．本章では，前章でスループットの大幅な低下により，転送時のスループットが大きく低下してしまうことがが確認されたことから，システムの構成を再検討することによ分かる．加えて，緊急時に仮想マシンをマイグレートしようとり効率的にデータベースのマイグレーションを行うことのできする際に，データベースまで仮想化されたものを，同時に一つる構成を検討する．

本研究ではシステム中のどの部分を物理サーバに残すべきか

これらより，データベース用のサーバを物理サーバ上におくを検討した．クライアントサーバ用のサーバは，実際に企業でことが有用であると考えた．これは，データベースを物理サー使われる際にほとんどの場合でクラウド上で作成される仮想マ

バ上に置くことで，緊急時以外にクラウド上に重要なデータをシンである．そのためこれを物理サーバ上での運用することは置かずに済むため，セキュリティ面を考えても有用なシステム

非現実的である．

だと考えられる．

これより，Pangea 用のサーバかデータベース用のサーバを

4. 2. 2 実 験 環 境

物理サーバ上で運用することを検討したい．Pangea 用のサー

前節の考察より，本実験では，クライアント用サーバとバの動作について考えると，仮想マシン上にあるクライアント

Pangea 用サーバをクラウド上に構築した仮想マシンを用い，用サーバからクエリを受け取り，それを自サーバ内で分類し，データベース用サーバに前述した物理サーバを用いて実験を行

データベース用サーバに転送する．この動作内で，仮想化によう．前章と同様にデータベース配置サーバに PostgreSQL サー

るオーバヘッドを考えることは難しい．

バをインストールし，クライアントサーバには TPC-W 用の次に，データベースの転送の際に最もボトルネックとなるのTomcat を，Pangea 配置サーバでは Pangea を立ち上げる．こは，ストレージアクセスにかかるコストである．仮想マシンをの環境下でデータベース間で転送を行い，スループットやレス

利用する際には，仮想マシンのデータベースが物理サーバのポンス時間を計測することで，Pangea の利用により転送の性

データベースへアクセスする際にコストがかかる．そのため，能があがることを確認する．構築した環境の物理イメージを図よく使うデータベース上のデータはバッファプール上にまとめ

13 に，作成した仮想マシンのネットワークイメージを図 14 にておいた方がアクセスが速くなり良いと考えられる．

示す

また通常，PostgreSQL のテーブルスペースには，データ
ベースオブジェクトが格納されるが，デフォルトテーブルス
ペースには，これに加えて PostgreSQL の管理情報など，様々な付随データが格納される．その中でも，特に重要なものがト
ランザクションログである．これはデータベースの全ての更新
内容をログとして保存し続けるため，データ量が非常に多い特徴がある．このデータ量の多いトランザクションログがデフォ
ルトテーブルスペースに格納されているため，これが載っているハードディスクは I/O 負荷が非常に高い状態となる．このため，新たなデータベース用のテーブルスペースとしてシステム
上のデータベース部だけを物理サーバに置くことで，デフォル
トテーブルスペースにはできるだけデータベースを作成しないようにすることができる．こうすると，トランザクションログ

図 13 物理イメージ図のための I/O 負荷はデフォルトテーブルスペースが載っているクラウド上のデータベースに，データベースアクセスのための I/O 負荷は物理サーバ上に置いたハードディスクにといった
ように，I/O 負荷の分散ができる．これは，コンピュートノー
ドのうちの１つに共有用ストレージを置き，NFS マウントを利用して構築した本システムでライブマイグレーションをした
際の所要時間が移動先ノードにより大きく異なったことからもわかる．これを図 12 に表す．コンピュートノード 11 に NFS
マウントディスクを置き，仮想マシンをコンピュートノード 11から 14 の間でマイグレートし，その所要時間を計測した．縦軸は転送先ノードである．

図 14

図 12

ライブマイグレーション所要時間

仮想マシンイメージ図

4. 2. 3 実 験 結 果
前節で紹介した環境下で性能検証を行う．TPC-W における仮想ブラウザ数 EB（クライアントからの負荷量）を変化させた時のスループット値を図 15，レスポンス時間を図 16 に示す．この結果，EB 数が 900 の時に，最大スループット値は122.1WIPS，レスポンス時間は 0.31WIRT となることが分かる．これは，インスタンスを介さず物理サーバ上で直接同じ実験を行った結果である，EB 数が 1000 の時の最大スループッ
ト値 126.78WIPS と比較しても約 4%の低下に収まっていることが分かる．
図 17システムをクラウド上に置いた場合と，全てのサーバをオンプ
レミスで構築した際のレスポンス時間の比較

図 15

システムのみをクラウド上に置き Pangea を動かしたときのス
ループット

図 18 実験イメージ図

4. 3. 2 実 験 結 果
この結果を図 19 に示す．横軸の数字のコンピュートノード
上にある仮想マシンを，縦軸の数字のコンピュートノード上に マイグレートした際の所要時間（秒）である．この結果から， パケットを流さずにマイグレーションを行った際の所要時間が 平均 26.3 秒程度だったものと比較して，目的のマイグ
図 16システムのみをクラウド上に置き Pangea を動かしたときのレ
スポンス値

また，本実験と第 4 章での実験で計測されたレスポンス時間について比較したものを図 17 に示す．これよりレスポンス時間についても本構成下で Pangea をクラウド上で利用したことによるオーバヘッドが僅かであることが分かる．

4. 3 予備実験 2
通常，ネットワーク上では，意図した通信以外の通信も行われている．これは，意図した通信の性能を妨げることが考えられる．そこで一方のノードからもう一方のノードへ [13] コマン
ドを用いてパケットを流しながらマイグレーションを行った．

4. 3. 1 実 験 環 境
この実験のイメージ図を図 18 に表す．
例えばこの図ではコンピュートノード 01 上にある仮想マシ
ンからコンピュートノード 02 上にある仮想マシンに Iperf コ
マンドを用いてパケットを流す間に，他の仮想マシンのマイグ
レーションを行う．

レーショ ンに関係のないパケットについて，他の経路を経由する，など のパケット制御をすることによりマイグレーション効率の向上 が期待できることが分かった．また，本研究ではコンピュートノード１上に共有ディスクを置き，ここに NFS マ
ウントすることでマイグレーションを行うように環境を構築した．これは構築時に最も安定する構成だったからである．コン
ピュートノード１から，またはコンピュートノード１へのマイ
グレーション時間が極端に短いため，コンピュートノード１に共有ディスクが置かれていることが実験結果に与える影響が大きいことがわかる．このことから，共有ディスクを配置する場
所を工夫することで，通信性能を安定化させることが可能であると考えられる

5. 実 験 結 果
5. 1 転送中にクエリを投げ続けた場合の性能比較
次に，本システムを用いて転送中にクエリを投げ続けた場合の転送時間を計測し，その性能評価を行った．例えば，同一ク
ラウド上の別の仮想マシン２台から Pangea にクエリを投げ続図 19 VM 上で Iperf を用いたマイグレーション結果
図 22 転送に影響を及ぼすクエリ量の計測

図 20

実験のイメージ図

図 23 転送に影響を及ぼすクエリ量の計測

場合の所要時間である．これより，クエリを投げながら転送を行うとその分転送に時間がかかってしまうこと，またその差は転送される仮想マシンの大きさが大きいほど大きくなることがわかる．

5. 2 転送に影響を及ぼすクエリ量の計測
図 21

受信クエリによる転送時間の比較

次に仮想マシンのサイズを固定し，同一クラウド上の別の２台の仮想マシンから送るクエリの数を変化させた状態でマイグけた際には，仮想マシン転送中にもクライアントからクエリは投げ続けられ，マイグレート中に受け取ったクエリは，マイグ
レート後にそれぞれのサーバに展開される．そして，クエリの展開が終了した後に転送された仮想マシンから Pangea へのア
クセスが再開される．このイメージ図を図 20 に表す．
図の例では同一クラウド内の２台の仮想マシンが Pangea へ
アクセスを行っているが，クラウド外の物理サーバ等，SSH 接続が可能であればどんなサーバからも Pangea にクエリを投げ続けることができる．様々な状況下で本システムを導入し，転送の性能を比較した．この実験結果を図 21 に表す．青いグラ
フが本システムを用いてクエリを投げずに転送を行った場合，赤いグラフが本システムを用いて、外部の物理サーバから 1 秒
間に 3000 クエリを送り続けながら転送を行った場合，緑色のグラフが本システムを用いて、クラウド内の仮想マシンから１秒間，3000 クエリを送り続けながら転送を行った場合，紫色のグラフが本システムを用いて、クラウド内の 2 つの仮想マシン
から１秒間に 3000 クエリずつを送り続けながら転送を行った

レーションを行った際の転送時間を計測し図 22 に表す．クエリの内容は、存在するテーブルを削除し，新しく同じ名前のテー
ブルを作成し，その中にデータを任意の数ずつ入れるというものとした．2 台の仮想マシンから，1 秒ごとにこのクエリの送信を行った．横軸は，一度に挿入したデータの数である．これより，ある一定のクエリの量を超えるとそれ以上転送速度の低下は起こらないこと，また，仮想マシンの大きさが大きいほどクエリによって伸びる転送時間が大きいことがわかる．

5. 3 PostgreSQL のデータの有無による転送時間の比較
最後に仮想マシンの中に PostgreSQL で作成した大きなデー
タを置き，通常の転送を行った場合と，提案手法を用いて転送を行った場合の転送時間の比較を行った．これを図 23 に表す．
これより，提案手法を用いた場合，転送中のクエリが補完されることに加え，転送速度もかなり短くなるため，本提案手法が有用であるということが分かった．

6. まとめと今後の課題
OpenStack を用いて構築した環境内で，緊急時に自動的にデータを転送するシステムの提案を行った．
外部情報をトリガに，バックアップを行うべきであるデータ
ベースを選択し，適切であると考えられるデータを，安全であると考えらえる地域に転送する．この際，データを共有するためのストレージを外部に置いておくことで，より効率的なデータ転送ができると考えられる．
５章よりデータベースに複数のサーバからアクセスがある際の性能の低下が大きいことがわかった．今後，この対策を行っていきたい．
また，本稿では，データベースサーバ内の全てのデータを同期することを前提としている．しかし，実際にハイブリッドク
ラウドとしてクラウドを利用する際にはセキュリティの問題などから，パブリッククラウドとプライベートクラウドに保存されるデータは一部異なることが予想される．そのため，要求されたクエリがパブリッククラウドからのアクセスが認められたデータであるかどうかも Pangea 内で区別することにより，テーブルごとのデータ管理を可能としていきたい．これは，Pangea がパケットを元にクエリの種類の判断をしていることから，可能であると判断される．

謝辞

本研究を進めるにあたり，NTT 細谷柚子様に数多くの助言を賜りました．深く感謝いたします．
文

献[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, ”Development ofFailure Detection System for Network Control using Collective Intelligence of Social Networking Service in Large-Scale
Disasters” 27th ACM Confernce on Hypertext and Social
Media (HT2016), pp.267-272, July 2016[8] Open vSwitch : http://openvswitch.org/[9] 原瑠理子，小口正人：「緊急災害情報に基づく OpenFLow を用いたバックアップシステムの実装と評価」 第 8 回データ工学と情報マネジメントに関するフォーラム (DEIM2016), E7-5,
2016 年 3 月[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/