情報処理学会第67回全国大会

1K-5

データベース同期複製のための JavaAPI の拡張
藤山健一郎

ＮＥＣ中村暢達

平池龍一

インターネットシステム研究所

1. はじめに既存システムサービス要求を発行

クライアント

従来、障害によるデータの破壊や損失を防ぐ手AP
DB非依存のサービス提供のため法として、データベース（DB）のレプリケーショ
データ処理要求
データ処理要求を発行
ン機能を用いてデータを複製する方法がある。レ
データ処理要求多重化
接続API
プリケーション[1]とは、複製元であるプライマリ データ処理要求を変換しDB非固有の汎用的な接続を提供
データ処理要求
DB が行ったデータ処理のログ等を、複製先のバッDBDB
同期複製
クアップ DB に転送し、同じデータ処理を行わせる
データ
データ
データ処理・管理
プライマリ側バックアップ側ことで、DB ごとデータの複製を行う技術である。
図 1：接続 API を介した DB 接続と提案方式
データ処理毎にプライマリ DB とバックアップ DBで同期を取るレプリケーションを Eager レプリケ
以上に述べた特徴を鑑み、接続 API におけるデーションと呼ぶ。データの損失を最小限にするにータ処理要求を多重化することで DB 同期複製を行は、この Eagar レプリケーションが必要となるが、 う方式を提案する。すなわち、AP が接続 API を介
Eagar レプリケーションは商用 DB の高価な上位製して発行しようとする DB 非依存なデータ処理要求品のみでしか提供されていない。一部のフリーDBをトラップし、複製した後、改めて接続 API を介には、Eager レプリケーションを付加する拡張ソフして、プライマリ DB、バックアップ DB それぞれにトも存在するが、その DB 専用のものであり、かつデータ処理要求を発行する。このようにすることAP のソースを書き換える等の作業が必要なため、で、両方の DB で同じデータ処理を行わせて、DB 同導入は困難である。したがって、Eager レプリケー期複製を実現する。
ションを備えない DB で構成されたシステムの場合、前述のとおり、接続 API は独立した共通基盤でDB を移行する必要があるが、データ管理の要でああるため、既に接続 API を介して DB アクセスを行る DB の移行には大きなリスクが伴う。しかも、２っているシステムであれば、どのような DB が用い系統分の DB が必要なため、商用 DB に移行する場られていても、既存システムの構成を変えること合は、構築コストが大幅に増加してしまう。
なく、提案方式を適用することができる。
本稿では、既存システムで用いられている DB の2.2. JavaAPI への実装
種類にかかわらず汎用的に、かつ、そのシステム
Java における接続 API である JDBC を拡張し、提の構成を変えることなく容易にレプリケーション案方式を実装した。JDBC にデータ処理要求を多重機能をアドオンし、DB 同期複製を実現する方式を化する機能を組み込み、JDBC へのデータ処理要求提案する。
をトラップ、複製してから、本来の JDBC に転送す
2. JavaAPI 拡張による DB 同期複製るようにする。この拡張機構を JDBC ゲートウェイ（JDBC-GW）と呼ぶ。JDBC-GW を用いた場合の AP か2.1. 方式提案
ら DB へのデータ処理要求の流れを図 2に示す。
DB と連携したアプリケーション（AP）では、直AP
接 DB にアクセスするのではなく、汎用的な DB 接同じIFを備え透過的に多重化
DB非依存のデータ処理要求（JDBC-APIに対応）
続を提供する API を介してアクセスするのが一般的である。図 1に接続 API を介して DB アクセスを
JDBC-ゲートウェイ
多重化
接続API：
DB非依存のデータ処理要求行うシステムのデータ処理の流れを示す。接続 API
Java（JDBC-APIに対応）
Data
は、AP、DB の両方から独立した共通基盤であり、JDBC-AJDBC-B
Base
変換
Connectivity
AP が発行した DB 非依存なデータ処理要求を、個々DB固有のデータ処理要求の DB 固有のものに変換することで、DB の種類によ（DBプロトコルに対応）
DB-A
DB-B
らない汎用的な DB アクセスを可能にする。
プライマリ側バックアップ側

図 2：JDBC-GW を介した DB 接続

Enhanced Java-API for Synchronous Database Replication.
Ken-ichiro FUJIYAMA, Nobutatsu NAKAMURA,and Ryuichi HIRAIKE.
Internet Systems Research Laboratories, NEC Corporation.

なお、JDBC-GW は JDBC と同じインタフェースを備えることで、AP からは普通の JDBC として、JDBCからは AP として認識される。つまり、既存システ
ムに対し影響を与えず、透過的に扱われるため、

3−47

システムの構成を変更する必要がない。

2.3. 動作ー ル と し て 、 Microsoft Web Application StressTool 1.1（以下 WAS ツール）を使用した。
操作

多重化

データ処理

（同期複製）
通常時の動作（DB 同期複製）JDBC
AP JDBC
プライマリDBGW
JDBC
WASツールJDBC-GW が、AP の発行するデータ処理要求を多Oracle 9i
WeblogicWindowsLinuxLinux重化することで、DB 同期複製を行う。両 DB からのクライアントマシンAPサーバマシン
プライマリDBサーバマシン
データ処理の応答は、一旦、JDBC-GW が受けて、ププライマリ側
100Base-T イーサネット
バックアップDB
ライマリ DB の応答のみを AP に返す。AP にとってOracle 9i
Linuxは、通常通り JDBC を介してデータ処理要求を発行
バックアップDBサーバマシン
して応答が１つだけ返ってくるので、複製処理はバックアップ側
図 3：実験環境
意識されない。
障害発生時の動作（データ保護）
3.2. 実験方法・結果
プライマリ DB に障害が発生した場合、プライマ提案方式を適用していない発注 ASP と、適用しリ DB のデータが破壊されても、バックアップ DB
た発注 ASP それぞれに、WAS ツールを用いて、発注には破壊前のデータが複製されている。また、デ作業を行う一連のサービス要求を発行し、各要求ータが破壊されなくても、データ更新中に障害がの応答時間を計測した。
発生した場合は、プライマリ DB はデータ処理が中比率[％]
応答時間[ms]サービス
差分 比率 応答時間[ms]途状態となり不整合が発生する可能性がある。し No. 要求種類[％] 1500
未適用時 適用時 [ms]
1 開始
166.4
23.5 16.4
80
かし、バックアップ側は、データ処理要求の段階 2 ログイン１ 142.9
184.9
224.8
39.9 21.6
3
ログイン２
163.6
152.3
-11.3-6.9で多重化されているため、プライマリ DB での障害 4 ログイン３
6090.5138.2
47.7 52.7 1000の影響を受けず、正常にデータ処理を行えるので、 5 ログイン４ 155.8 166.6 10.8 6.9406 発注開始 1058.8 1463.1 404.3 38.2
不整合は発生しない。このため、バックアップ DB 7 登録508641.7 133.7 26.3
平均8 確認１
145.3
207.9
62.6 43.120の整合の取れたデータを用いて、データの損失な 9 確認２113.3
210.3
97.0 85.6 500
10確認３119170.1
51.1
42.9
くサービスを継続、すなわち RPO（Recovery Point 11 確認４0132.2
153.7
21.5 16.3
12 確定１538.8
944.6 405.8 75.3Objective）＝0 でサービスを復旧できる。
0-20
13 確定２616829.3 213.3 34.6
1 2・・ サービス要求種類 ・・14
14 終了
障害発生後の動作（フェイルオーバー）
105.6
158.6
53.0 50.2
：未適用時
：適用時
：比率
合計
4074.7 5627.6 1552.9 ＋38.1
JDBC-GW は障害の発生したプライマリ DB を切り
図 4：実験結果離し、稼動しているバックアップ DB にのみデータ実験結果を図 4に示す。作業全体で応答時間が処理要求を発行する。バックアップ DB には整合の約 38％延びている。なお、１サービス要求あたりとれたデータが保存されているため、正常なデーの応答時間の遅れは平均 110ms 程度である。発注
タ処理を行い、応答を返す。バックアップ DB の応
ASP のような WEB アプリケーションでは、ユーザに答は JDBC-GW を介して AP に返されるため、AP にはよる待ち時間等が発生するため、それに比べれば、それがどの DB の応答かは意識されない。そのため提案方式を適用したことによる応答時間の遅れはプライマリ DB の障害は隠蔽され、無停止、すなわ十分小さく、実用上は問題ないと考える。実際に、
ち RTO(Recovery Time Objective)＝0 でサービス手動で実験システムを操作したところ、体感的なを復旧できる。
レスポンスの低下は感じられなかった。
以上のように、障害時にデータの損失なく、無停止でサービスを継続することができる。

4. おわりに

3. 評価実験

本稿では、単一 DB からなる既存システムに、DBJDBC-GW による DB 同期複製機構を、実際に販売、 同期複製機能を容易にアドオンする、API 拡張による DB 同期方式について述べた。提案方式では接続運用されている WEB アプリケーション製品に適用
API を拡張することで、DB の種類によらず、またし、同期複製のオーバーヘッドにより、どの程度既存システムの構成を変更することなく、DB 複製性能が低下するかを検証する評価実験を行った。
機能を実現できる。また本方式を Java における接3.1. 実験環境
続 API である JDBC に実装し、実運用製品に適用し実験システムの構成を図 3 に示す。AP サーバマ評価を行った。その結果、実用的な性能が得られシンでは、AP サーバとして BEA WebLogic Serverることを確認した。
8.1、WEB アプリケーション製品として住宅業向け
今後は複数 AP 間の順序制御機能、災害対策を考工事発注 ASP サービス（以下、発注 ASP）を使用し慮した遠距離複製機能等の開発を行う予定である。
た。２つの DB サーバマシンでは、それぞれ DB と参考文献
して Oracle9i Database Standard Edition を使用[1] J.Gray et al, "The Dangers of Replication
した。クライアントマシンには、発注 ASP にサーand a Solution" ACM SIGMOD Conference, 1996.
ビス要求を発行して、処理時間を計測する実験ツ3−48