DEIM Forum 2014 D9-5

ハイブリッドクラウドにおけるデータベース同期方式の検討
細谷 柚子†

三島健††

小口 正人†† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2–1–1†† NTT ソフトウェアイノベーションセンタ 〒 180–8585 東京都武蔵野市緑町 3–9–11
E-mail: †yuzuko@ogl.is.ocha.ac.jp, ††mishima.takeshi@lab.ntt.co.jp, †††oguchi@computer.org
あらまし近年，クラウドコンピューティングモデルの出現に伴いパブリッククラウドやプライベートクラウドが普及しつつあり，その両者をシームレスに結合するハイブリッドクラウドが注目されつつある．しかし，実社会においてはデータの一貫性などの技術的な問題によりハイブリッドクラウドの導入はあまり進んでいない．他方で，データベースサーバは企業の基幹を構成しているため，クラウドで動作させるべき重要度の高いシステムである．そこで，
本研究では，ハイブリッドクラウド環境でデータベースを同期させることに注目した．LAN 環境を前提としてデータベースサーバを同期する Pangea という既存のミドルウェアがある．これをハイブリッドクラウドに適用し，TPC-Wベンチマークを用いて評価実験を行った．データセンタが遠隔地にあることを想定して，Dummynet を使って人工的に遅延を挿入した．近隣の街にバックアップを置く場合と，海外のような遠隔にバックアップを置く場合を想定し，遅延は RTT16ms と RTT256ms で測定した．LAN 環境における結果と 2 つの遅延時間における結果とを比較し，考察を行った．
キーワード

ハイブリッドクラウド，データベース同期

A Study on Database Replication in the Hybrid Cloud
Yuzuko HOSOYA† , Takeshi MISHIMA†† , and Masato OGUCHI†† Ochanomizu University Otsuka 2–1–1,Bunkyo-Ku, Tokyo 112–8610 Japan†† NTT Software Innovation Center Midoricho 3–9–11,Musashino-Shi, Tokyo 180–8585 Japan
E-mail: †yuzuko@ogl.is.ocha.ac.jp, ††mishima.takeshi@lab.ntt.co.jp, †††oguchi@computer.org

1. は じ め に
近年，クラウドコンピューティングモデルの出現に伴い，パブリッククラウドやプライベートクラウドが普及しつつある．
さらに，それらのクラウドをシームレスに結合する形態のハイブリッドクラウドの検討も行われてきている．パブリッククラウドでは，スケールアウト/スケールダウンできることにより無駄なくリソースを使用でき，コスト削減が期待できる．また
データ管理を専門の業者に預けることにより，技術面のリスク削減にも繋がる．しかし，社外のサービスを利用することによるセキュリティへの不安の声も多くあり，これはクラウド導入が積極的に行われていないことの要因でもある．他方でプライベートクラウドは，社内のシステムとして構築されており，パブリッククラウドに比べるとセキュリティの不安は少ない．
この２つのクラウドを併用するハイブリッドクラウドでは，それぞれの持つ拡張性や安全性などのメリットを利用することができる．例えば，自社でデータセンタを保有し，通常はデータ管理に自社システムのプライベートクラウドを使用して，時期により短期間に大容量データ処理が必要になった場合やアクセスが急増したときの対応手段として，拡張性の高いパブリッククラウドを利用することが挙げられる．また，通常パブリッククラウドを使用している場合でも，セキュリティ面を考慮し，個人情報や社外秘の情報はプライベートクラウドで管理するといった利用方法も検討されて，現在まででハイブリッドクラウドの有用性は強調されている．しかし，実社会においては，ハイブリッドクラウドの導入はあまり進んでいない．その理由は，２つのクラウド間で，データの一貫性をとらなければならないという技術的な問題があるためである．
本研究ではハイブリッドクラウドにおいてデータベースを同期させることに注目した．データベースサーバは企業の基幹を成していることを考えると，クラウドの重要なテーマである．

LAN 環 境 を 前 提 と し て デ ー タ ベ ー ス サ ー バ を 同 期 す る
Pangea [1] という既存のミドルウェアがある．これをハイブリッドクラウド環境に適用し，TPC-W ベンチマーク [2] を用いて評価実験を行った．

マシン 2 台を用いた．どちらのマシンも表 1 に示すスペック

実験では東京―大阪間を想定した RTT16ms と日米間や日欧である．データベースサーバには PostgreSQL9.2.6 を使用し間を想定した RTT256ms の場合を測定した．高遅延の測定は，た．クライアントとデータベースサーバの間に Pangea を接続

外資系の企業や，日本企業の海外進出による海外支店が増えた

して同期を行う．Web サーバとアプリケーションサーバにはことで，日本と海外でのデータの同期が必要になってくると考Tomcat6.0.37 を用いた．性能評価は TPC-W ベンチマークをえたためである．また，日本のように自然災害が多い国では，使用した．TPC-W は仮想的なブラウザ (以下 EB とする) が，近隣にバックアップを置いておくと，大規模災害が起こった際データベースにトランザクションを発行する．TPC-W には 3には両方とも失ってしまう恐れもあるため，遠隔バックアップ種類のワークロードがあり，それらの違いは表 2 に示すようにの需要が高くなっていることも考えられる．

照会処理と更新処理の割合が異なる．性能評価指標は，スルー以上の評価をもとに，ハイブリッドクラウドにおけるデータプット (1 秒あたりの Web 画面表示:(WIPS)) とレスポンス時

ベース同期方式の課題の抽出とその解決法について検討を行う．

間 (1 画面データの転送時間:(秒)) とした．TPC-W は平均 7 秒の Thinking Time が存在するため，次のリクエストを送るまでに，平均 7 秒の時間がかかる．そのため，リクエスト率は2. Pangea
Pangea は図 1 に示すように，LAN 環境を前提として複数のデータベースサーバ間でスナップショット分離を保証するデー
タベースレプリケーションミドルウェアである．クライアントからサーバ側に直接アクセスするのではなく，ミドルウェアを介してデータベースにアクセスする方式となっていることから，データベースを改造することなく，サーバを増やすことで性能を向上させることが可能である．Pangea では照会処理は１台のレプリカで，更新処理は全レプリカで実行される．クライアン
トからミドルウェアまでの処理を Global transaction，ミドルウェアからサーバまでの処理を Local transaction といい，全1/7 リクエスト/秒となる．
また，パブリッククラウドは遠隔地にあることを想定してDummynet を使用して人工的に遅延を発生させた．今回は東京大阪間を想定した比較的低遅延の 16ms の場合と，日米間や日欧間を想定した高遅延の 256ms の場合で実験を行った．実験環境を図 2 に示す．
表1

表2

マシンのスペック

ワークロードOS

Linux 2.6.32

ワークロードCPUIntel(R) Xeon(R) CPU

Browsing mix

95 ％

5％

@ 1.60GHz

Shopping mix

80 ％

20 ％

Ordering mix

50 ％

50 ％

Memory 2GByte

Read-only Update

レプリカでの Local transaction がコミットされ次第，Globaltransaction のコミット処理が完了する．また，レプリカの中の１台を Leader，その他は Follower とされ，更新処理の場合は Leader に対して更新をした後に，他の Follower に対しても同様に処理を行う．

図2実験環境3. 2 基 本 性 能
TPC-W の 3 種類のワークロードにおけるスループット(WIPS) とレスポンス時間 (秒) をそれぞれ図 3，4，5 に表す．
上の折れ線グラフはスループット，下の折れ線グラフはレスポンス時間を表している．
図 1 Pangea

最大スループットの値，そのときの EB 数ともに，ワークロードによって異なる．browsing mix では EB が 80 のとき最本研究では Pangea の基礎性能測定をした後に，ハイブリッ大スループットが 9.1WIPS，shopping mix では EB が 110 のドクラウド環境での性能測定を行い，遅延による影響を分析しとき最大スループットが 14.7WIPS，ordering mix では EB がた．また，その結果から Pangea の拡張を検討する．

290 のとき最大スループットが 38.9WIPS となった．３種類と3. 基礎性能評価
3. 1 実 験 環 境Pangea の基本性能評価を行った．データベースサーバ用にも EB 数を増やしていくにつれ，スループットも上がっていく．
特にレスポンス時間は指数関数的に上昇する．レスポンス時間が上昇していき，1 より大きくなるあたりでオーバーロード

状態になるため，EB 数を増やしてもスループットは下降していく．

図 6 browsing mix の性能比較

図3

ローカル環境における browsing mix の性能

図 7 shopping mix の性能比較

図 4 ローカル環境における shopping mix の性能

図 8 ordering mix の性能比較れなかった．
図5ローカル環境における ordering mix の性能

一方で，ordering mix では，RTT256ms の場合に遅延による影響がみられた．このときの最大スループットは，ローカル環境
では EB 数 290 のとき 38.9WIPS であったのに対して，EB 数

4. 応 用 実 験

300 のとき 36.1WIPS であり，およそ 7.2 ％下回る．RTT16ms

4. 1 広域ネットワーク環境における性能評価の場合は，ローカル環境とスループット，レスポンス時間ともにパブリッククラウドは遠隔地にあることを想定し，Dum-ほとんど差がなく，性能の低下はみられなかった．RTT256ms

mynet を使って遅延を入れた場合の測定を行った．近隣の街にの場合は，ローカル環境と比較するとスループットが下回り，バックアップを置く場合と，海外のような遠隔にバックアップレスポンス時間がほとんどのケースで 1 秒を超えていることかを置く場合を想定して RTT16ms と 256ms で評価した．3 種のら，高遅延環境では性能低下が無視できない．ordering mix はワークロードそれぞれの結果とローカル環境の結果との比較を更新クエリの割合が 1 番多いため (表 2) 更新クエリの扱いが原

図 6，7，8 に示す．遅延を入れた場合においても，スループッ因で遅延による性能低下がみられたと考える．

トとレスポンス時間の変化はローカル環境と同じく，EB 数を増

4. 2 Pangea の修正提案

やしていくにつれスループットも大きくなり，レスポンス時間

4. 2. 1 更新クエリ修正提案

は指数関数的に上昇する．ある点において最大のスループット

広域ネットワーク環境での性能向上を図るために，Pangeaとなり，その後は EB 数を増やしても下降していく． browsingの修正を検討する．本節では更新クエリ処理の修正を提案すmix と ordering mix では，図 6，7 からも分かる通り，スルーる．修正前の Pangea の更新クエリのプロトコルを表 3 に示し

プット，レスポンス時間ともに遅延による影響はほとんどみらた．第 2 節でも示した通り，このプロトコルの場合，遠隔にあるデータベースからの応答を待つ時間がかかってしまうために，RTT256ms での測定を行った．スループットは，EB が 300 を性能低下がみられると考える．そのため，全レプリカからの応超えても低下しないことから本修正により改善が見える．また，答を待たず，Leader から応答が帰ってきた時点でクライアントレスポンス時間も 300 を超えても悪化しないことから改善してに応答を返すように修正する．修正プロトコルを表 4 に示す．

いると言える．

表 3 更新クエリプロトコル
1 クライアントから Pangea に

表 4 更新クエリプロトコル修正
1 クライアントから Pangea にリクエスト送信

リクエスト送信2 Pangea から Leader に

2 Pangea から Leader にリクエスト送信

リクエスト送信3 Leader から応答が返る

3 Leader から応答が返る

4 全 follower にリクエスト送信

4 Pangea からクライアントに応答が返る

5 全 follower から応答が返る
6 Pangea からクライアントに応答が返る

5 全 follower にリクエスト送信
6 全 follower から応答が返る

修正プロトコルの場合，クライアントは応答を受け取ると次

図 10 COMMIT 修正後の ordering mix の性能のクエリを送るため，Follower に対するクエリが前のクエリを追い越して順番が前後になると，コンシステンシが崩れてしまうことが懸念される．そこで，次のクエリが追い越さないように全 Follower からの応答を受け取ってから，次のクエリを受信

5. まとめと今後の課題
データベース同期システム Pangea についての基本性能評価を行った．TPC-W ベンチマークの 3 種のワークロードにおけする．
修正した Pangea での測定結果と修正前の結果とを比較した

るローカル環境での性能を測定し，EB 数が増えればスループッものを図 9 に示す．遅延による影響が見られた ordering mix

トも上がることが確認できた．EB 数が多すぎればリクエストにおける RTT256ms での測定を行った．本節で提案した修正数も膨大になり飽和状態になるため，最大のスループットを超により，クライアントに早く応答が返るためレスポンス時間がえた後に下降することは，妥当だといえる．

短くなると予想していたが，差がほとんどみられなかった．こパブリッククラウドは遠隔にあることを想定し，遅延をいれは，クライアントに応答を即座に返しても Pangea が次のクれた場合の測定も行った．広域ネットワーク環境の場合もローエリを処理をするのは Follower からの応答を待ってからであ

カル環境の場合と同じく，ある点で最大スループットの値になるため，更新クエリの応答を早く返したとしても，レスポンスり，その後は下降していくことが確認できた．browsing mix

時間に関して改善がみられなかったためであると考えられる．と shopping mix では遅延による性能低下がみられなかったが，ordering mix の高遅延の場合にスループット，レスポンス時間の性能低下がみられた．

Pangea の更新クエリに対する修正と COMMIT に対する修正を提案した．更新クエリ修正においては性能の向上がみられず，COMMIT 修正においてはレスポンス時間とスループットの改善が見られた．
今後の課題としては，Pangea の更なる修正を検討し，性能向上を目指したい．
文
図9

更新クエリ修正後の ordering mix の性能

4. 2. 2 Pangea の COMMIT 修正
次に COMMIT 処理に対する修正を提案する．本節で提案する COMMIT 修正では更新クエリ修正と同じく，Leader への COMMIT が終了した時点でクライアントに応答を返し，その後に Follower に対しても COMMIT を行うというものである．COMMIT は重い書き込み処理を伴うクエリであるため，Follower への処理を投げる前にクライアントに応答を返すことにより，レスポンス時間が短くなると予想する．
修正した Pangea での測定結果と修正前の結果とを比較したものを図 10 に示す．4.2.1 節と同様に，ordering mix における

献[1] T.Mishima and H.Nakamura,”Pangea:An Eager Database
Replication Middleware guaranteeing Snapshot Isolation
without Modiﬁcation of Database Servers”, Proc.VLDB2009,
pp.1066-1077, August 2009. PVLDB2009.
[2] TPC-W http://www.tpc.org/tpcw