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

(1)

DEIM Forum 2016 D5-2

リモートバックアップ機能を有した

クラスタデータベースシステムにおける性能向上手法の提案

細谷柚子

†

三島

健

††

小口正人

†

お茶の水女子大学

〒 112–8610 東京都文京区大塚 2–1–1

††

NTT ソフトウェアイノベーションセンタ

〒 180–8585 東京都武蔵野市緑町 3–9–11

E-mail:

†

††

†††

あらまし

金融や証券などのミッションクリティカルなビジネスでは，データベースシステムに対して高性能化と高

信頼化を同時に満たすことが求められている．また，近年長引く不況から低コスト化も重要な要件となる．更に，東

日本大震災などを教訓に遠隔バックアップのニーズも高いものとなっている．これら 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:

†

††

†††

1. はじめに

金融や証券などミッションクリティカルなビジネスではデータベースシステムに対して高性能化と高信頼化を同時に満たすことが求められている．また近年の長引く不況により低コスト化も重要な要件となり，更に，東日本大震災などを教訓に遠隔バックアップのニーズもますます高くなっている．これらの4 つの要件を同時に満たせる手法の確立が本研究の課題である．まず高性能化と高信頼化のためには，レプリケーションを導入し，複数レプリカによる負荷分散が必要である．そして低コスト化のためには，汎用IAサーバ上でOSS等の利用が望ましい．更に，遠隔バックアップによる性能低下を防ぐために非同期レプリケーションも必要となる．そこで我々は，OSSのデータベース同期ミドルウェア中では最も高性能であるPangea [1]に着目し，Pangeaが前述の4 つの要件を満たすために必要となる，非同期レプリケーションによる遠隔バックアップ機能を加えた新たなミドルウェアを検討した．これをPangea**と呼ぶ．我々はTPC-Wベンチマーク[7]を使いPangea**を評価することで，高性能化，高信頼化，低コスト化を損なわない遠隔バックアップの実現可能性を議論する．

2. 既存手法：

Pangea

Pangeaはサーバの1台をLeader，その他はFollowerとして，クライアントからミドルウェアを介してサーバにアクセスすることで同期をとる．照会処理は1台のサーバで，更新処理は全てのサーバで実行され，更新処理の場合はLeaderに対して更新をした後に，Followerに対しても同様に処理を行う． Pangeaでは全てのデータベースサーバが同期されていることから，そのうちの1台を遠方に配置させることで，Pangeaを無改造で遠隔バックアップの実現は可能である．しかし，Pangea からバックアップサーバへの通信による大きな遅延の影響により，大幅な性能低下を招く．また，我々は過去に，Pangeaを拡張させて非同期的にバックアップを行う手法のPangea++の検討を行った．しかし， Pangea++はバックアップへの処理をシリアルに行う手法であ

(2)

り，バックアップを行うのに多くの時間を要した[2]．そのため，本研究ではバックアップへの処理を並列に実行するためのプロトコルを検討し，効率化を図る．

3. 提案手法：

Pangea**

3. 1 Pangea**の概要本研究では，Pangeaに遠隔バックアップ機能を加えた Pangea**を提案する(図1)．ローカルデータベースサーバ用をマスタ，バックアップサーバ用をスレーブと呼ぶ．クライアントからの処理を分担するローカルのデータベースサーバは，従来のPangea同様，1台をLeader，その他をFollowerとしている．クライアントからの処理はマスタを介して行われる．データベースの実行処理を担当しないバックアップサーバは，スレーブを介して非同期的に更新処理のみ行われるようにした．図 1 Pangea**構成 3. 2 Pangea**の実装図 2 Pangea**モデル図 3 トランザクションのフォーマット Pangea**の実装を図2に示す．Pangea**のマスタでは複数の Workerスレッドが，スレーブではConductorスレッド， Man-agerスレッドが１つずつと，Synchronizerスレッド，Senderスレッドが複数動作している．WorkerスレッドとSynchronizer スレッドは１対１に対応付けられており，トランザクション１つを，Workerスレッド１つが処理するようになっている． Workerスレッドは，クライアントからのトランザクションを受け取り，ローカルサーバにクエリを実行させる．またこのとき，マスタのトランザクションの順序を明確にするためのタイムスタンプと，同時開始トランザクション数(Parallel Start：PS)をトランザクションごとに付与する．本研究で扱うトランザクションは図3のようなフォーマットになっている．タイムスタンプは，トランザクションの開始時刻(Start Time

Stamp：STS)と終了時刻(End Time Stamp：ETS)の2種類

を用意した．そして，クエリと2種のタイムスタンプ，PSの値をSynchronizerスレッドに転送する． ConductorスレッドはWorkerスレッドの起動時にマスタからの接続を受け付け，ファイルディスクリプタ(fd)を Synchro-nizerスレッドに渡す処理のみを行う． Synchronizerスレッドはクエリとタイムスタンプ，PSを受け取り，トランザクションごとに保存する．これをDatasetと呼ぶ．Datasetの構造は，図3に示したトランザクションのフォーマットと同等である．そして，Datasetにcommitまでのクエリを保存できたらDatasetListにつなげる．DatasetList は，マスタにおけるトランザクションの開始順に並ぶようにする． Managerスレッドは，後述する並列転送プロトコルに従って Senderスレッドに指示を出す．

Senderスレッドは，DatasetListの先頭からDatasetを取り出し，Managerスレッドの指示に応じてバックアップサーバにてクエリを実行する．次の章から，タイムスタンプ，同時開始トランザクション数，並列転送プロトコルについて詳しく述べる． 3. 2. 1 Pangea**：タイムスタンプタイムスタンプを記録するために，マスタの時刻を表すカウンタ(Master Logical Clock：MLC)を用意する．MLCは，ト

ランザクション1つがcommitしたらインクリメントされる． Workerスレッドが各トランザクションの最初のクエリ実行時に，その時点のMLCの値をSTSとして記録し，commit実行時には，その時点のMLCの値をETSとして記録する．図 4 タイムスタンプの例タイムスタンプの例を図4に示す．MLCの初期値は0である．トランザクション1(T1)とトランザクション2(T2)は， MLCが0のときに開始されたため，それぞれのSTSに0を記録する．その後T1がcommitされ，T1のETSに0を記録する．MLCはインクリメントされて1になる．次にT2が commitされると，T2のETSには1を記録する．その後に開

(3)

始されたトランザクション3(T3)とトランザクション(T4)についても同様にして，T3のSTSには1，ETSには2を，T4 のSTSには1，ETSには3を記録する． 3. 2. 2 Pangea**：同時開始トランザクション数同時開始トランザクション数は，マスタで同時刻に開始されたトランザクションがいくつあるかを示すものである．同時刻とは，同MLCのことであり，Workerスレッドが同MLC内に始まったトランザクションの数をカウントし，各トランザクションのPSに記録する．また，同時開始トランザクション数は，いずれかのトランザクションのcommit実行のタイミングで決定する．同時開始トランザクション数は，いずれかのトランザクションのcommit実行のタイミングで決定するため， MLC=ETSを満たすトランザクションのPSに記録する．図 5 同時開始トランザクション数の例例を図5に示す．まず，トランザクション(T1)とトランザクション(T2)の2つのトランザクションはMLC=0のときに開始される．つまりMLC=0のときの同時開始トランザクション数は2である．この情報をETS=MLCであるDatasetに記録するため，T1のDatasetのPSに2が記録される．次に，トランザクション(T3)とトランザクション(T4)の2つのトランザクションはMLC=1のときに開始される．つまりMLC=1 のときの同時開始トランザクション数は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スレッドは，並列転送プロトコルを実現するため，各トランザクションのSTS，ETSを参照しながら動作する．その際のManagerスレッドとSenderスレッドのアルゴリズムをそれぞれ図6，7に示す．また説明のために，変数を表1に定義する． ManagerスレッドはSLCが更新されるごとに1回動作する．表 1 変数の定義 SLC スレーブの時刻を表すカウンタ PSN ある SLC における同時開始トランザクション数 PCN ある SLC における同時 commit 可能トランザクション数 PSTS これから最初のクエリを実行する Dataset の STS の中で最も小さいもの NSTS PSTS の次に小さいもの並列転送プロトコル 1 STS＝SLCを満たす全Datasetのうち最初のクエリ実行全クエリの終了を待つ 2 STS＝SLCを満たす全Datasetのうちcommitを除いた全クエリ実行 3 NSTS取得

4 ETS＜NSTSを満たす全Datasetのうちcommit実行全クエリの終了を待つ 5 PSTS=NSTS，SLC更新図 6 Manager スレッドのアルゴリズム図 7 Sender スレッドのアルゴリズムまずSLC=ETSを満たすDatasetのPSをPSNにセットし (M-1)，Senderスレッドにシグナルを送る(M-2)．次にこれから実行するDatasetの中からNSTSを取得し(M-3)，PSTSと

(4)

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

レッドにシグナルを送る(M-5)．その後Senderスレッドから

のシグナルを待ち(M-6)，シグナルを受けたらPSTS=NSTS

として(M-7)，M-1に戻る．

各SenderスレッドはDatasetListにDatasetが繋がっている間，それぞれ動作し続ける．まず，DatasetListにDataset が繋がったらDatasetを取りに行く(S-1)．そして，Datasetの STSとSLCの値を比較し(S-2)，STS＝SLCを満たせば最初のクエリを実行させる(S-4，S-5)．満たさなければ，Manager スレッドからのシグナルを待つ(S-3)．各Senderスレッドは最初のクエリを実行したらPSNをディクリメントする(S-6)． PSNの値が０よりも大きかったら他のSenderスレッドによるディクリメントを待ち，PSNが０であれば，STS=SLCを満たす全てのDatasetの最初のクエリの実行が終了しているため，次に進む(S-7)．その後，commit以外の更新クエリを実行させる(S-8，S-9)．次に，DatasetのETSとNSTSの値を比較し(S-10)，ETS＜NSTSを満たせばcommitを実行させる(S-12，S-13)．満たさなければ，Managerスレッドからのシグナルを待つ(S-11)．commit実行後，SLCのインクリメント(S-14)とPCNのディクリメント(S-15)を行う．PCNの値が０よりも大きかったら他のSenderスレッドによるディクリメントを待ち，PCNが０であれば，ETS＜NSTSを満たす全てのDatasetのcommitの実行が終了しているため(S-16)， Managerスレッドにシグナルに送り(S-17)，S-1に戻る．図 8 並列転送プロトコルの例図8に具体例を示す．５つのSenderスレッドが，DatasetList からDatasetをそれぞれ取ってきたとする．まずManagerスレッドは，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以外のクエリを実行させる．次に，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 したため，SLC=0+1=1となる．またこのときPCNをディクリメントし，PCN=０となるため，Senderスレッド１は Man-agerスレッドにシグナルを送る．そして，ManagerスレッドがPSTS=NSTSとする．その後も同様にして処理を繰り返す．

4. 評価実験

4. 1 実験概要 PangeaとPangea**を用いて，遠隔バックアップ機能がトランザクション処理に与える影響を調査した．実験環境は，Web サーバとアプリケーションサーバにTomcat6.0.37 [9]を用いて，ローカルデータベースサーバ，バックアップデータベースサーバは１台ずつ用意，それぞれにPostgreSQL9.2.6 [8]を配置させた．バックアップは遠方にあることを想定し，Dummynet を用いて3種類の遅延を挿入した(表2)．Pangea**用マシンのスペックは，1.60GHz Intel(R) Xeon(R) E5310のCPU，4

つのcore，メモリ2GBで，DBサーバ用マシンのスペック

は，3.60GHz Intel(R) Xeon(TM)のCPU，1つのcore，メモリ4GBのものである．OSはどちらもUbuntu14.04である．

TPC-Wは仮想的なブラウザ(EB)が，それぞれ照会処理と更新処理の割合が異なるbrowsing mix，shopping mix，ordering

mixの3種のワークロードでDBにトランザクションを発行する．本稿ではその中で最も更新トランザクション処理の多い ordering mixで評価を行った．性能評価指標は，スループット (1秒あたりのWeb画面表示数)とレスポンス時間(1画面データの転送時間)とした．遠隔バックアップをしないPangeaの通常動作を性能のベースラインとした．そして，Pangeaで遠

隔バックアップを行う場合(Pangea (backup))とPangea**と

で性能比較を行った．実験環境を図9，図10に示す．表 2 挿入した遅延 RTT 想定される距離 16ms 東京，大阪間 64ms 日本，アジア間 256ms 日本，欧米間図 9 Pangea バックアップ時図 10 Pangea**バックアップ時

(5)

4. 2 トランザクション処理への影響調査 PangeaとPangea**を用いて，遠隔バックアップ機能がトランザクション処理に与える影響を調査した． Pangeaの通常動作時の性能を図11に示す．本稿における環境でのPangeaの通常動作時の最大スループットは，EB数が 270のとき，37WIPSであった．またその時のレスポンス時間は0.25msであった．レスポンス時間は，負荷を増やすにつれ緩やかに上昇し，最大スループット以降は急上昇することが分かった．図 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**の最大スループットとレスポンス時間はそれぞれ， RTT16msのとき，36.9WIPS， 0.23ms，RTT64msのとき， 36.67WIPS，0.29ms，RTT256msのとき，36.6WIPS，0.32ms であった．Pangeaの通常動作時と比較すると，最大スループット，レスポンス時間共に，いずれの遅延環境下においても殆ど性能低下はみられなかった．この結果から，Pangeaは，東京，大阪間など，バックアップが近隣にある場合には，クライアントからのトランザクション処理にほとんど影響を与えることなくバックアップ可能であるが，バックアップが海外にある場合には，遅延の影響を大きく受けることがわかった．一方Pangea**は，バックアップが海外にある場合においてもクライアントからのトランザクション処理に影響を殆ど与えずに，バックアップ可能であることが明らかになった． 4. 3 バックアップ性能調査 Pangea++とPangea**のバックアップのためのトランザクションキューをそれぞれ監視して，バックアップ処理が輻輳していないかを調査した．本稿での実験環境で最大スループットとなったEB数で実験を行った．結果を図14，15に示す．Pangea++では，いずれの遅延環境下においても，時間の経過とともにキューの長さが右上がりになっていることから，バックアップへの処理が輻輳図 12 Pangea と Pangea**の最大スループット図 13 Pangea と Pangea**のレスポンス時間図 14 Pangea++のトランザクションキュー図 15 Pangea**のトランザクションキューしてしまっていることがわかる．Pangea**では，いずれの遅延環境下においても，キューの長さが頻繁に0になっていることから，処理がスムーズに行われていることがわかる．本稿で提案したPangea**は，バックアップ処理を並列に行うことで，シーケンシャルにバックアップ処理を行うPangea++と比較して，効率よくバックアップ可能であることが明らかになった．

(6)

5.

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] R¨ohm，U．，B¨ohm，K．，Schek，H． and Schuldt，H．：FAS-a Freshness-Sensitive Coordination Middleware for a Cluster of OLAP Components，VLDB (2002)．

[4] Plattner，C．and Alonso，G．：Ganymed：Scalable Repli-cation for Transactional Web AppliRepli-cations ，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/

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

DEIM Forum 2016 D5-2