DEIM Forum 2016 D5-2

リモートバックアップ機能を有したクラスタデータベースシステムにおける性能向上手法の提案
細谷 柚子†

三島健††

小口 正人†† お茶の水女子大学 〒 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
あらまし

金融や証券などのミッションクリティカルなビジネスでは，データベースシステムに対して高性能化と高信頼化を同時に満たすことが求められている．また，近年長引く不況から低コスト化も重要な要件となる．更に，東日本大震災などを教訓に遠隔バックアップのニーズも高いものとなっている．これら 4 つの要件を同時に満たすことのできる手法の確立が本研究の課題である．我々は，既存のデータベース同期ミドルウェア Pangea をベースに，遠隔バックアップ機能を有する新たなミドルウェア Pangea**を検討し，実装を行った．そのシステムを検証した結果，前述した 4 つの要件を満たすことのできる手法であることを確認した．
キーワード

遠隔バックアップ，クラスタデータベースシステム，トランザクション処理，ミドルウェア

A Proposal of Performance Improvement Method
in a Cluster Database System having a Remote Backup Function
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. は じ め に
金融や証券などミッションクリティカルなビジネスではデー
タベースシステムに対して高性能化と高信頼化を同時に満たすことが求められている．また近年の長引く不況により低コスト

ク [7] を使い Pangea**を評価することで，高性能化，高信頼化，低コスト化を損なわない遠隔バックアップの実現可能性を議論する．

2. 既存手法：Pangea化も重要な要件となり，更に，東日本大震災などを教訓に遠隔Pangea はサーバの 1 台を Leader，その他は Follower としバックアップのニーズもますます高くなっている．これらの 4て，クライアントからミドルウェアを介してサーバにアクセスつの要件を同時に満たせる手法の確立が本研究の課題である．

することで同期をとる．照会処理は 1 台のサーバで，更新処まず高性能化と高信頼化のためには，レプリケーションを導入

理は全てのサーバで実行され，更新処理の場合は Leader に対し，複数レプリカによる負荷分散が必要である．そして低コスして更新をした後に，Follower に対しても同様に処理を行う．

ト化のためには，汎用 IA サーバ上で OSS 等の利用が望まし

Pangea では全てのデータベースサーバが同期されていること

い．更に，遠隔バックアップによる性能低下を防ぐために非同から，そのうちの 1 台を遠方に配置させることで，Pangea を無期レプリケーションも必要となる．

改造で遠隔バックアップの実現は可能である．しかし，Pangea

そこで我々は，OSS のデータベース同期ミドルウェア中では最も高性能である Pangea [1] に着目し，Pangea が前述の 4からバックアップサーバへの通信による大きな遅延の影響により，大幅な性能低下を招く．

つの要件を満たすために必要となる，非同期レプリケーション

また，我々は過去に，Pangea を拡張させて非同期的にバッによる遠隔バックアップ機能を加えた新たなミドルウェアを検クアップを行う手法の Pangea++の検討を行った．しかし，討した．これを Pangea**と呼ぶ．我々は TPC-W ベンチマー

Pangea++はバックアップへの処理をシリアルに行う手法であり，バックアップを行うのに多くの時間を要した [2]．そのため，Worker スレッドは，クライアントからのトランザクション

本研究ではバックアップへの処理を並列に実行するためのプロを受け取り，ローカルサーバにクエリを実行させる．またこトコルを検討し，効率化を図る．のとき，マスタのトランザクションの順序を明確にするため

3. 提案手法：Pangea**
3. 1 Pangea**の概要のタイムスタンプと，同時開始トランザクション数 (ParallelStart：PS) をトランザクションごとに付与する．本研究で扱うトランザクションは図 3 のようなフォーマットになっている．

本研究では，Pangea に遠隔バックアップ機能を加えたタイムスタンプは，トランザクションの開始時刻 (Start Time

Pangea**を提案する (図 1)．ローカルデータベースサーバ用

Stamp：STS) と終了時刻 (End Time Stamp：ETS) の 2 種類をマスタ，バックアップサーバ用をスレーブと呼ぶ．クライアを用意した．そして，クエリと 2 種のタイムスタンプ，PS のントからの処理を分担するローカルのデータベースサーバは，値を Synchronizer スレッドに転送する．

従来の Pangea 同様，1 台を Leader，その他を Follower としConductor スレッドは Worker スレッドの起動時にマスタかている．クライアントからの処理はマスタを介して行われる．

らの接続を受け付け，ファイルディスクリプタ (fd) を Synchro-

データベースの実行処理を担当しないバックアップサーバは，nizer スレッドに渡す処理のみを行う．

スレーブを介して非同期的に更新処理のみ行われるようにした．

Synchronizer スレッドはクエリとタイムスタンプ，PS を受け取り，トランザクションごとに保存する．これを Dataset と呼ぶ．Dataset の構造は，図 3 に示したトランザクションのフォーマットと同等である．そして，Dataset に commit までのクエリを保存できたら DatasetList につなげる．DatasetList
は，マスタにおけるトランザクションの開始順に並ぶように

図 1 Pangea**構成する．

Manager スレッドは，後述する並列転送プロトコルに従って3. 2 Pangea**の実装

Sender スレッドに指示を出す．
Sender スレッドは，DatasetList の先頭から Dataset を取り出し，Manager スレッドの指示に応じてバックアップサーバにてクエリを実行する．
次の章から，タイムスタンプ，同時開始トランザクション数，並列転送プロトコルについて詳しく述べる．

3. 2. 1 Pangea**：タイムスタンプ
タイムスタンプを記録するために，マスタの時刻を表すカウンタ (Master Logical Clock：MLC) を用意する．MLC は，トランザクション 1 つが commit したらインクリメントされる．

Worker スレッドが各トランザクションの最初のクエリ実行時に，その時点の MLC の値を STS として記録し，commit 実行
図 2 Pangea**モデル

図 3 トランザクションのフォーマット

時には，その時点の MLC の値を ETS として記録する．

図4

タイムスタンプの例

Pangea**の実装を図 2 に示す．Pangea**のマスタでは複数のタイムスタンプの例を図 4 に示す．MLC の初期値は 0 でWorker スレッドが，スレーブでは Conductor スレッド，Man-ある．トランザクション 1(T1) とトランザクション 2(T2) は，ager スレッドが１つずつと，Synchronizer スレッド，Sender ス

MLC が 0 のときに開始されたため，それぞれの STS に 0 をレッドが複数動作している．Worker スレッドと Synchronizer記録する．その後 T1 が commit され，T1 の ETS に 0 を記

スレッドは１対１に対応付けられており，トランザクション１録する．MLC はインクリメントされて 1 になる．次に T2 がつを，Worker スレッド１つが処理するようになっている．

commit されると，T2 の ETS には 1 を記録する．その後に開始されたトランザクショ ン 3(T3) とトランザクション (T4) に

表1

変数の定義ついても同様にして，T3 の STS には 1，ETS には 2 を，T4
SLC

スレーブの時刻を表すカウンタ

PSN

ある SLC における同時開始トランザクション数

3. 2. 2 Pangea**：同時開始トランザクション数

PCN

ある SLC における同時 commit 可能トランザクション数

同時開始トランザクション数は，マスタで同時刻に開始されPSTS これから最初のクエリを実行するの STS には 1，ETS には 3 を記録する．

たトランザクションがいくつあるかを示すものである．同時刻とは，同 MLC のことであり，Worker スレッドが同 MLC 内

Dataset の STS の中で最も小さいもの
NSTS PSTS の次に小さいものに始まったトランザクションの数をカウントし，各トランザクションの PS に記録する．また，同時開始トランザクション数

並列転送プロトコル

は，いずれかのトランザクションの commit 実行のタイミング

1 STS ＝ SLC を満たす全 Dataset のうち最初のクエリ実行で決定する．同時開始トランザクション数は，いずれかのトランザクションの commit 実行のタイミングで決定するため，

MLC=ETS を満たすトランザクションの PS に記録する．

全クエリの終了を待つ

2 STS ＝ SLC を満たす全 Dataset のうち commit を除いた全クエリ実行

3 NSTS 取得
4 ETS ＜ NSTS を満たす全 Dataset のうち commit 実行
全クエリの終了を待つ

5 PSTS=NSTS，SLC 更新

図 5 同時開始トランザクション数の例

例を図 5 に示す．まず，トランザクション (T1) とトランザクション (T2) の 2 つのトランザクションは MLC=0 のときに開始される．つまり MLC=0 のときの同時開始トランザクション数は 2 である．この情報を ETS=MLC である Dataset に記録するため，T1 の Dataset の PS に 2 が記録される．次に，トランザクション (T3) とトランザクション (T4) の 2 つのトランザクションは MLC=1 のときに開始される．つまり MLC=1

図 6 Manager スレッドのアルゴリズムのときの同時開始トランザクション数は 2 である．この情報をETS=MLC である Dataset に記録するため，T2 の Dataset のPS に 2 が記録される．また，MLC=2，3 のときに開始されるトランザクションはないため，T3，T4 の PS には 0 が記録される．

3. 2. 3 Pangea**：並列転送プロトコル
下記に示した並列転送プロトコルは，ローカルデータベースサーバとバックアップデータベースサーバの一貫性を保ちながら，バックアップのためのクエリを複数個，並列に実行するためのものであり，効率的にバックアップを行うことを可能にする．本研究では，トランザクション分離はスナップショット分離を前提とする．このプロトコルのために，スレーブの時刻を表すカウンタ（Slave Logical Clock：SLC）を用意する．SLC
は前節の MLC 同様，トランザクション１つが commit したらインクリメントされる．Manager スレッドと Sender スレッド
は，並列転送プロトコルを実現するため，各トランザクション

図 7 Sender スレッドのアルゴリズムの STS，ETS を参照しながら動作する．その際の Manager ス
レッドと Sender スレッドのアルゴリズムをそれぞれ図 6，7 に

まず SLC=ETS を満たす Dataset の PS を PSN にセットし示す．また説明のために，変数を表 1 に定義する．

(M-1)，Sender スレッドにシグナルを送る (M-2)．次にこれかManager スレッドは SLC が更新されるごとに 1 回動作する．

ら実行する Dataset の中から NSTS を取得し (M-3)，PSTS と

NSTS の値を使って PCN を算出する (M-4)．そして Sender ス

したため，SLC=0+1=1 となる．またこのとき PCN をディクレッドにシグナルを送る (M-5)．その後 Sender スレッドからリメントし，PCN=０となるため，Sender スレッド１は Man-のシグナルを待ち (M-6)，シグナルを受けたら PSTS=NSTS

ager スレッドにシグナルを送る．そして，Manager スレッドとして (M-7)，M-1 に戻る．

が PSTS=NSTS とする．その後も同様にして処理を繰り返す．

各 Sender スレッドは DatasetList に Dataset が繋がっている間，それぞれ動作し続ける．まず，DatasetList に Dataset

4. 評 価 実 験が繋がったら Dataset を取りに行く (S-1)．そして，Dataset の4. 1 実 験 概 要

STS と SLC の値を比較し (S-2)，STS ＝ SLC を満たせば最初Pangea と Pangea**を用いて，遠隔バックアップ機能がトラのクエリを実行させる (S-4，S-5)．満たさなければ，Managerンザクション処理に与える影響を調査した．実験環境は，Webスレッドからのシグナルを待つ (S-3)．各 Sender スレッドはサーバとアプリケーションサーバに Tomcat6.0.37 [9] を用いて，最初のクエリを実行したら PSN をディクリメントする (S-6)．

ローカルデータベースサーバ，バックアップデータベースサー

PSN の値が０よりも大きかったら他の Sender スレッドによるバは１台ずつ用意，それぞれに PostgreSQL9.2.6 [8] を配置さディクリメントを待ち，PSN が０であれば，STS=SLC を満せた．バックアップは遠方にあることを想定し，Dummynet

たす全ての Dataset の最初のクエリの実行が終了しているたを用いて 3 種類の遅延を挿入した (表 2)．Pangea**用マシン

め，次に進む (S-7)．その後，commit 以外の更新クエリを実のスペックは，1.60GHz Intel(R) Xeon(R) E5310 の CPU，4行させる (S-8，S-9)．次に，Dataset の ETS と NSTS の値をつの core，メモリ 2GB で，DB サーバ用マシンのスペック比較し (S-10)，ETS ＜ NSTS を満たせば commit を実行させは，3.60GHz Intel(R) Xeon(TM) の CPU，1 つの core，メモる (S-12，S-13)．満たさなければ，Manager スレッドからのリ 4GB のものである．OS はどちらも Ubuntu14.04 である．

シグナルを待つ (S-11)．commit 実行後，SLC のインクリメン

TPC-W は仮想的なブラウザ (EB) が，それぞれ照会処理と更ト (S-14) と PCN のディクリメント (S-15) を行う．PCN の値

新処理の割合が異なる browsing mix，shopping mix，orderingが０よりも大きかったら他の Sender スレッドによるディクリ

mix の 3 種のワークロードで DB にトランザクションを発行

メントを待ち，PCN が０であれば，ETS ＜ NSTS を満たすする．本稿ではその中で最も更新トランザクション処理の多い

全ての Dataset の commit の実行が終了しているため (S-16)，ordering mix で評価を行った．性能評価指標は，スループット

Manager スレッドにシグナルに送り (S-17)，S-1 に戻る．

(1 秒あたりの Web 画面表示数) とレスポンス時間 (1 画面データの転送時間) とした．遠隔バックアップをしない Pangea の通常動作を性能のベースラインとした．そして，Pangea で遠隔バックアップを行う場合 (Pangea (backup)) と Pangea** とで性能比較を行った．実験環境を図 9，図 10 に示す．
表 2 挿入した遅延

図 8 並列転送プロトコルの例

図 8 に具体例を示す．５つの Sender スレッドが，DatasetListから Dataset をそれぞれ取ってきたとする．まず Manager ス

RTT

想定される距離16ms

東京，大阪間64ms

日本，アジア間

256ms

日本，欧米間レッドは，SLC=0 であるため，ETS=0 である Dataset1 の PSを PSN にセットする．PSN=2 となる．そして，STS が 0 である Dataset の最初のクエリを実行するよう Sender スレッドに指示を出す．STS=0 の Dataset1，Dataset2 を保有する Sender
スレッド 1，Sender スレッド 2 が，それぞれ最初のクエリを実行させる．このとき，それぞれ PSN をディクリメントし，PSN=０になるまで待つ．続いて，Sender スレッド 1，Sender
スレッド 2 は，それぞれの Dataset の commit 以外のクエリ

図 9 Pangea バックアップ時を実行させる．次に，Manager スレッドは NSTS を取得する．

NSTS は，Dataset1 から Dataset5 の STS の中で，PSTS の次に小さいものである．このとき PSTS=0 であるため，NSTS=1となる．また，PSTS と NSTS の値を使って PCN を算出する．

PCN=1-0=1 となる．そして，Manager スレッドは，NSTS=1であるため，ETS が 1 より小さい Dataset の commit を実行するよう Sender スレッドに指示を出す．ETS=0 の Dataset1を保有する Sender スレッド 1 が，commit を実行させる．その後，SLC を更新する．今，1 つのトランザクションが commit

図 10 Pangea**バックアップ時

4. 2 トランザクション処理への影響調査
Pangea と Pangea**を用いて，遠隔バックアップ機能がトランザクション処理に与える影響を調査した．

Pangea の通常動作時の性能を図 11 に示す．本稿における環境での Pangea の通常動作時の最大スループットは，EB 数が270 のとき，37WIPS であった．またその時のレスポンス時間は 0.25ms であった．レスポンス時間は，負荷を増やすにつれ緩やかに上昇し，最大スループット以降は急上昇することが分

図 12 Pangea と Pangea**の最大スループットかった．

図 13 Pangea と Pangea**のレスポンス時間
図 11 Pangea 基本動作時の基本性能

Pangea での遠隔バックアップ時と Pangea**の性能を図 12，13 に示す．Pangea で遠隔バックアップを行った場合の最大ス
ループットとレスポンス時間はそれぞれ，RTT16ms のとき，36.58WIPS，0.34ms，RTT64ms のとき，29.38WIPS，3.07ms，RTT256ms のとき，7.2WIPS，9.49ms であった．Pangea の通常動作時と比較すると，最大スループットについては，RTT16msのときは約 1.1 ％，RTT64ms のときは約 20.6 ％，RTT256msのときは約 80.5 ％の低下がみられた．レスポンス時間については，RTT16ms のときは Pangea 通常動作時とほぼ変わらなかったが，遅延を大きくするにつれ，著しく上昇していた．

Pangea**の最大スループットとレスポンス時間はそれぞれ，

図 14 Pangea++のトランザクションキュー

RTT16ms のとき，36.9WIPS， 0.23ms，RTT64ms のとき，36.67WIPS，0.29ms，RTT256ms のとき，36.6WIPS，0.32msであった．Pangea の通常動作時と比較すると，最大スループッ
ト，レスポンス時間共に，いずれの遅延環境下においても殆ど性能低下はみられなかった．
この結果から，Pangea は，東京，大阪間など，バックアップが近隣にある場合には，クライアントからのトランザクション処理にほとんど影響を与えることなくバックアップ可能であるが，バックアップが海外にある場合には，遅延の影響を大きく受けることがわかった．一方 Pangea**は，バックアップが海外にある場合においてもクライアントからのトランザクション処理に影響を殆ど与えずに，バックアップ可能であることが明らかになった．

図 15 Pangea**のトランザクションキュー

4. 3 バックアップ性能調査
Pangea++と Pangea**のバックアップのためのトランザクションキューをそれぞれ監視して，バックアップ処理が輻輳していないかを調査した．
本稿での実験環境で最大スループットとなった EB 数で実験を行った．結果を図 14，15 に示す．Pangea++では，いずれの遅延環境下においても，時間の経過とともにキューの長さが右上がりになっていることから，バックアップへの処理が輻輳してしまっていることがわかる．Pangea**では，いずれの遅延環境下においても，キューの長さが頻繁に 0 になっていることから，処理がスムーズに行われていることがわかる．本稿で提案した Pangea**は，バックアップ処理を並列に行うことで，シーケンシャルにバックアップ処理を行う Pangea++と比較して，効率よくバックアップ可能であることが明らかになった．

5. 関 連 研 究
本手法は非同期レプリケーションによるバックアップであるが，非同期レプリケーションを用いた既存手法の [3]，[4] では，バックアップにクエリをシリアルに実行している．[5] は，更新クエリは並列に行うことができるプロトコルであるが，commitはシリアルに実行しなければならない．我々の本手法と比較す
ると，これらの手法は，バックアップがローカルデータベースサーバと同期されるまでに多くの時間を要してしまう．
また，PostgreSQL のストリーミングレプリケーションのよ
うな，トランザクションログを用いてバックアップを行う手法も考えられる [6]．この場合，トランザクションログのフォー
マットはバージョンによって違うため，異なるバージョンからなるシステムは構成できない．それに対して Pangea**では標準の SQL を使っているため，ヘテロ構成が可能となる．これは例えば，サービスを止めずにバージョンアップする場合などに応用することができる．

6. まとめと今後の課題
遠隔バックアップ機能を有したクラスタデータベースミドルウェア，Pangea**の提案を行った．Pangea**は，既存のデータベース同期ミドルウェアである Pangea をベースにしており，ローカルサーバ処理のためのマスタと，バックアップ処理のためのスレーブから成る．本手法は，非同期レプリケーションによるアプローチでバックアップを行う．また，バックアップへの処理を効率化するために，並列転送プロトコルを検討し，導入した．評価を行った結果，クライアントからの処理に殆ど影響を与えず，バックアップ可能であったことから，本手法は，高性能化，高信頼化，低コスト化を損なわない遠隔バックアップ手法であることが示せた．
今後は，Pangea**のスケーラビリティの調査や既存のバックアップシステムとの比較を行い，本手法の有用性を示したい．
文献[1] Mishima，T． and Nakamura，H．：Pangea:An Eager
Database Replication Middleware guaranteeing Snapshot
Isolation without Modification of Database Servers， VLDB
(2009)．
[2] 細谷柚子，三島健，小口正人， データベース同期ミドルウェア
による遠隔バックアップの活用手法の検討 DEIMForum2015，
B6-5，2015 年 3 月[3] Röhm，U．
，Böhm，K．
，Schek，H． and Schuldt，H．
：FAS-aFreshness-Sensitive Coordination Middleware for a Clusterof OLAP Components，VLDB (2002)．
[4] Plattner，C．and Alonso，G．：Ganymed：Scalable Replication for Transactional Web Applications ，Middleware(2004)．
[5] Daudjee，K．and Salem，K．：Lazy Database Replication
with Snapshot Isolation，VLDB(2006)．
[6] 藤塚 勤也，澤井 健，高畑 知也， こちら検証ラボ PostgreSQL9.1
はどう進化したのか–同期レプリケーションで性能低下，スレーブサーバーの構成に要注意 日経 systems，2011 年 11 月
[7] TPC-W http://www.tpc.org/tpcw[8] PostgreSQL https://www.postgresql.jp/[9] Tomcat http://tomcat.apache.org/