JP2016031682A

JP2016031682A - サービス提供システム及びその機能拡張方法

Info

Publication number: JP2016031682A
Application number: JP2014154386A
Authority: JP
Inventors: 裕三石田; Yuzo Ishida; 信昭小塚; Nobuaki Kozuka; 宏徳桂; Hironori Katsura
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2014-07-30
Filing date: 2014-07-30
Publication date: 2016-03-07

Abstract

【課題】複数のDBサーバによって同一データが冗長管理されている環境下で、比較的容易に機能の拡張を可能とする。
【解決手段】APサーバ14と、複数のDBサーバ16〜２２、２６、２８、30を備え、クライアント端末36にサービスを提供する。各DBサーバには、共通データを格納するテーブルが設けられ、各テーブルにはレコードの削除及び更新が禁止される制約が設けられている。業務処理部40からデータの登録依頼を受けたDB制御部42はデータを複製して全てのDB連絡部43〜52に渡し、各DB連絡部は担当するDBサーバにSQL文を発行してレコードの追加を求める。業務処理部から特定データの参照を求められた場合、DB制御部は任意のDB連絡部にデータの抽出を依頼し、DB連絡部は担当のDBサーバにSQL文を発行してレコードを抽出してDB制御部に渡し、DB制御部は受け取ったデータに演算処理を施し業務処理部に渡す。
【選択図】図２

Description

この発明はサービス提供システムおよびその機能拡張方法に係り、特に、多数のクライアント端末に対して情報処理サービスを提供するAPサーバによって生成された業務データを、複数のDBサーバによって重複管理するシステムに関する。

地震や津波、噴火等の大規模災害、あるいは原発事故やテロ等の人災によってデータベースが物理的に損壊する場合に備え、企業の基幹システムにおいては、業務データを遠隔地に設置したバックアップ用のデータベースに重複登録することが以前より行われている。
例えば、特許文献１においては、正制御装置のディスク装置にデータを登録した後、遠隔地に設置された副制御装置に同一データを送信し、その登録を求める技術が開示されている。

このように、正副２台の制御装置によってデータを二重持ちすることにより、一方の地域において地震等が発生し、ディスク装置が物理的に破損した場合であっても、生き残った他方のディスク装置内のデータを活用することで、業務処理の連続性を担保することが可能となる。
また、データベースの損壊は地震等によってデータセンター単位で被災する場合に限られるものではなく、DBサーバのマシントラブルによっても生じ得るため、同一構内においてもこのようなバックアップ体制を構築しておくことが望まれる。

ところで、このような複数のDBサーバとAPサーバとの連携を前提とする大規模なサービス提供システムにおいて、途中で機能の拡張を行う必要が生じた場合には、各DBサーバに格納されたテーブルに新機能に対応したカラムを追加する修正を施すと共に、APサーバ側のアプリケーションプログラムにも大幅な改変を施す必要があり、その過程でバグが生じやすいという問題があった。

すなわち、DBサーバに格納された業務データを利用するに際し、通常はAPサーバからDBサーバにSQL文を発行し、DBサーバにジョインやマッチング、ソート等の演算処理を依頼することとなるが、このためには業務処理用のアプリケーションプログラム中にSQL文を記述しておく必要がある（非特許文献１参照）。

このSQL文は、一般に複雑かつ長大な記述になるため第三者が内容を理解するのは容易でなく、しかもコンパイルチェックが効かないという問題がある。
また、一旦、各DBサーバに格納されたテーブルに修正を施してしまうと、何らかの不具合によって旧来のサービスに戻す必要が生じた場合に、大きな手間が発生する。
このため、ユーザの要望に迅速に対応したいサービスの運用部門と、システムの安全性を重視する開発部門との間で意見の対立が生じ、頻繁な機能の拡張が阻害されていた。

特開平１１−８５４０８号プログラムとデータベースの関係インターネットURL：http://www.limy.org/program/coding/program_db.html 検索日：２０１４年７月１５日

この発明は、このような現状に鑑みて案出されたものであり、複数のDBサーバによって同一の業務データが冗長管理されている環境下において、比較的容易にサービス提供システムの機能を拡張可能とする技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載したサービス提供システムは、APサーバと、このAPサーバと接続された複数のDBサーバとを備え、クライアント端末に対して所定の情報処理サービスを提供するサービス提供システムであって、上記APサーバは、上記の各DBサーバ単位で設けられた複数のDB連絡部と、業務処理部と、DB制御部とを備え、上記の各DB連絡部には、それぞれ担当するDBサーバの特定情報が設定されており、上記の各DBサーバには、相互に共通するデータを格納するテーブルがそれぞれ設けられており、各テーブルには、レコードの削除及び更新が禁止される制約が設けられており、上記業務処理部からデータの登録依頼を受けた際に、上記DB制御部は、当該データを複製して上記の全DB連絡部に渡し、これを受けた各DB連絡部は、自己の担当するDBサーバにSQL文を発行してレコードの追加を求め、上記業務処理部から特定データの参照を求められた場合に、上記DB制御部は、上記の各DBサーバの中から１または複数のDBサーバを特定し、当該DBサーバを担当しているDB連絡部に対してデータの抽出を依頼し、これを受けたDB連絡部は、自己の担当しているDBサーバに対してSQL文を発行してレコードの抽出を依頼すると共に、DBサーバから受け取ったデータをDB制御部に渡し、DB制御部は、受け取ったデータに必要な演算処理を施した上で、上記業務処理部に渡すことを特徴としている。

請求項２に記載したサービス提供システムは、請求項１のシステムであって、さらに、上記業務処理部は、既存データを更新する必要がある場合に、更新後の値を備えたデータを新たに生成し、上記DB制御部及び各DB連絡部を介してこのデータを各DBサーバに設けられた既存のテーブルに追加登録させることにより、既存データの実質的な更新を実現することを特徴としている。

請求項３に記載したサービス提供システムは、請求項１または２のシステムであって、さらに、上記業務処理部は、既存の業務データを削除する必要がある場合に、当該業務データのIDを格納するデータ項目を備えたデータ取消用のデータを生成し、上記DB制御部及び各DB連絡部を介してこのデータ取消用のデータを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存データの実質的な削除を実現することを特徴としている。

請求項４に記載したサービス提供システムは、請求項１〜３のシステムであって、さらに、上記APサーバ及び複数のDBサーバの中の少なくとも一部が、同一のコンピュータ上に形成されており、このコンピュータは、複数のCPUコアを内蔵したCPUパッケージと、複数のテーブルを格納しておく記憶装置を備え、このコンピュータ上でAPサーバ用プログラムを起動させることによって上記APサーバが構成されると共に、このAPサーバ上で専用のアプリケーションプログラムを起動させることによって上記の業務処理部、DB制御部及び複数のDB連絡部が構成され、同コンピュータ上でDBサーバ用プログラムを複数起動させることによって上記の各DBサーバが構成され、上記APサーバ及び各DBサーバには、それぞれ複数の異なるCPUコアが専用的に割り当てられており、上記DBサーバにデータの抽出及び登録を依頼するに際しては、上記DB連絡部から当該処理を担当するCPUコアを具体的に指定した形でSQL文が発行され、これを受けたDBサーバでは、指定されたCPUコアによって対応の処理が実行されることを特徴としている。

請求項５に記載したサービス提供システムの機能拡張方法は、請求項１のシステムにおいて、クライアント端末に対して提供するサービスの機能を拡張するに際し、拡張後の機能に対応したテーブルを上記の各DBサーバ内に追加すると共に、拡張前の機能に係るテーブルを各DBサーバ内に置いたまま処理の対象外に設定し、上記APサーバの業務処理部、DB制御部及び各DB連絡部を、追加したテーブルに対応した拡張バージョンに置き換えることを特徴としている。

請求項１に記載したサービス提供システムの場合、各DBサーバに格納されたテーブルにレコードの削除及び更新が禁止される制約が課されており、APサーバから発行されるSQL文はデータの抽出及び登録を求めるものに限定されると共に、抽出したデータの演算処理はAPサーバ側で実行され、DBサーバに対して演算処理を指令する必要もないため、業務処理部やDB制御部を実現するためのプログラム中にSQL文を記載する必要が一切ない。この結果、これらプログラムの開発効率が向上し、サービスの早期リリースや機能の頻繁な拡張が可能となる。
また、DB連絡部を実現するためのプログラム中にはSQL文を記述する必要があるとしても、自己が担当するDBサーバに対して単純にデータの抽出や登録を求める内容に限定されるため、サービスの機能拡張の度に更新する必要はない。

この発明の場合、DBサーバのテーブルにはレコードの削除及び更新が禁止される制約が設けられているが、請求項２及び３に記載の仕組みを用いることにより、データの実質的な削除や更新を実現することができる。

請求項４に記載したサービス提供システムの場合、同一コンピュータ上にAPサーバと複数のDBサーバが起動され、APサーバの各DB連絡部からDBサーバにデータ抽出用のSQL文を発行するに際しては処理を担当すべきCPUコアを指定した形でなされるため、マルチコア化されたCPUの潜在能力を極限まで引き出し、迅速な処理が可能となる。

請求項５に記載したサービス提供システムの機能拡張方法にあっては、機能拡張に際し、各DBサーバに拡張後の機能に対応したテーブルが新設され、当該新規テーブルに基づいたサービスの提供に移行するものであり、既存のテーブルについてはカラムが追加されることもなく、そのまま維持されることになるため、何らかの事情によって旧来のサービスに戻す必要が生じた場合にも迅速に対応可能となる。

図１は、この発明に係るサービス提供システム10の全体構成図である。
まず、データセンター12内には、APサーバ14と、第１のDBサーバ16と、第２のDBサーバ17と、第３のDBサーバ18と、第４のDBサーバ19と、第５のDBサーバ20と、第６のDBサーバ21と、第７のDBサーバ22が設置されている。

詳細は後述するが、APサーバ14と第１のDBサーバ16〜第６のDBサーバ21は同一のサーバコンピュータ24内に設けられており、マザーボード上の信号線を介して接続されている。
これに対し第７のDBサーバ22は、別筐体のサーバコンピュータ上に設けられており、LAN経由でAPサーバ14と接続されている。

またAPサーバ14は、遠隔地に設置された第８のDBサーバ26、第９のDBサーバ28及び第１０のDBサーバ30と、通信回線32を介して接続されている。
さらにAPサーバ14は、インターネット34を介して、複数のクライアント端末36とも接続されている。

第１のDBサーバ16〜第１０のDBサーバ30には、それぞれ共通のテーブルが設けられている（詳細は後述）。

図２は、APサーバ14の内部構成を示すものであり、業務処理部40と、DB制御部42と、第１のDB連絡部43と、第２のDB連絡部44と、第３のDB連絡部45と、第４のDB連絡部46と、第５のDB連絡部47と、第６のDB連絡部48と、第７のDB連絡部49と、第８のDB連絡部50と、第９のDB連絡部51と、第１０のDB連絡部52を備えている。

業務処理部40は、クライアント端末36からのリクエストに応じてデータの登録や検索等の業務処理を実行するものであり、サーバコンピュータ24のCPUが専用のアプリケーションプログラムに従って動作することにより、実現される。

第１のDB連絡部43〜第１０のDB連絡部52には、それぞれ第１のDBサーバ16〜第１０のDBサーバ30が予め専属的に割り当てられており、担当のDBサーバに対してSQL文を発行し、データの登録及び抽出を指令する機能を果たす。
各DB連絡部は、専用のミドルウェアに従ってサーバコンピュータ24のCPUが動作することにより、実現される。

DB制御部42は、業務処理部40からデータ登録の指令を受けた際に、データをDBサーバの数だけ複製し、それぞれを各DB連絡部に渡す機能と、業務処理部40からデータ参照の指令を受けた際に、何れかのDB連絡部を介して特定のDBサーバからデータを抽出し、必要な演算処理を施す機能を果たす。
このDB制御部42は、専用のアプリケーションプログラムに従ってサーバコンピュータ24のCPUが動作することにより、実現される。

図３は、サーバコンピュータ24内部のハードウェア構成例を示すものであり、第１のCPUパッケージ60、第２のCPUパッケージ62、第３のCPUパッケージ64、第４のCPUパッケージ66を備えたマザーボード68が筐体内に収納されている。

各CPUパッケージ内には、それぞれ15個のCPUコアが形成されているため、サーバコンピュータ24は、合計で60個ものCPUコアを有していることとなる。
各CPUパッケージは、マザーボード68上に設けられたCPUソケット（図示省略）にそれぞれ装着されている。

各CPUパッケージには、それぞれ専用のメモリ（ローカルメモリ）が割り当てられている。
すなわち、第１のCPUパッケージ60には第１のメモリ70が、第２のCPUパッケージ62には第２のメモリ71が、第３のCPUパッケージ64には第３のメモリ72が、第４のCPUパッケージ66には第４のメモリ73が専属的に設けられている。

サーバコンピュータ24には、SSD（Solid State Drive）よりなる補助記憶装置74が接続されており、この補助記憶装置74内には各種テーブル（詳細は後述）が格納されている。SSDの代わりに、ハードディスクによって補助記憶装置74を構成することもできる。

各CPUコアには、それぞれ固有の機能が予め割り当てられている。
すなわち、第１のCPUパッケージ60内に形成されたコア(01)〜コア(15)には、APサーバ14が専用的に割り当てられている。

また、第２のCPUパッケージ62内に形成されたコア(16)には、カーネルスレッド（OS）76が専用的に割り当てられている。
第２のCPUパッケージ62内に形成されたコア(17)〜コア(23)には、第１のDBサーバ16が専用的に割り当てられている。
同じく、第２のCPUパッケージ62内に形成されたコア(24)〜コア(30)には、第２のDBサーバ17が専用的に割り当てられている。

第３のCPUパッケージ64内に形成されたコア(31)〜コア(38)には、第３のDBサーバ18が専用的に割り当てられている。
同じく、第３のCPUパッケージ64内に形成されたコア(39)〜コア(45)には、第４のDBサーバ19が専用的に割り当てられている。

第４のCPUパッケージ66内に形成されたコア(46)〜コア(53)には、第５のDBサーバ20が専用的に割り当てられている。
同じく、第４のCPUパッケージ66内に形成されたコア(54)〜コア(60)には、第６のDBサーバ21が専用的に割り当てられている。

以上のように、１台のサーバコンピュータ24内には、１つのAPサーバ用プログラムと、６つのDBサーバ用プログラム（インスタンス）が起動されており、各サーバにはそれぞれ複数のCPUコアが専用的に割り当てられている。

また、上記した通り、APサーバ14には第１のメモリ70が、カーネルスレッド（OS）76、第１のDBサーバ16及び第２のDBサーバ17には第２のメモリ71が、第３のDBサーバ18及び第４のDBサーバ19には第３のメモリ72が、第５のDBサーバ20及び第６のDBサーバ21には第４のメモリ73が、それぞれローカルメモリとして専用的に割り当てられている。

この場合、各CPUコアはローカルメモリにはダイレクトに（高速に）アクセスできるが、他のCPUパッケージに割り当てられたリモートメモリにアクセスするためには、当該CPUパッケージに属するCPUコアを経由する必要があり、その分、処理速度が低下する問題が生じる。
このため、このシステム10においては、各CPU コアがアクセスできるのはローカルメモリのみに限定され、他のCPUパッケージの配下にあるリモートメモリへのアクセスは禁止されている。

このような割当て及び制約は、OS起動時に次のような「NUMAコントロール」のコマンドを入力することにより、実現される。

［１］APサーバ14に関する割当て
「#numactl
-physcpubind=1-15 ←コア(01)〜(15)の割当て
-membind=0 ←第１のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
java -jar aloha.jar」 ←APサーバプロセス（Java／登録商標）の起動

［２］第１のDBサーバ16に関する割当て
「#numactl
-physcpubind=17-23 ←コア(17)〜(23)の割当て
-membind=1 ←第２のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data1 start"←第１のDBサーバプロセスの起動
（データ領域data1に対するデータベース）」

［３］第２のDBサーバ17に関する割当て
「#numactl
-physcpubind=24-30 ←コア(24)〜(30)の割当て
-membind=1 ←第２のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data2 start" ←第２のDBサーバプロセスの起動
（データ領域data2に対するデータベース）」

［４］第３のDBサーバ18に関する割当て
「#numactl
-physcpubind=31-38 ←コア(31)〜(38)の割当て
-membind=2 ←第３のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data3 start" ←第３のDBサーバプロセスの起動
（データ領域data3に対するデータベース）」

［５］第４のDBサーバ19に関する割当て
「#numactl
-physcpubind=39-45 ←コア(39)〜(45)の割当て
-membind=2 ←第３のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data4 start" ←第４DBサーバプロセスの起動
（データ領域data4に対するデータベース）」

［６］第５のDBサーバ20に関する割当て
「#numactl
-physcpubind=46-53 ←コア(46)〜(53)の割当て
-membind=3 ←第４のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data5 start" ←第５のDBサーバプロセスの起動
（データ領域data5に対するデータベース）」

［７］第６のDBサーバ21に関する割当て
「#numactl
-physcpubind=54-60 ←コア(54)〜(60)の割当て
-membind=3 ←第４のメモリの割当て
nice -n -5 ←プロセスの優先度の指定
su -postgres ←プロセスの実行ユーザをpostgresに切り替え（su）
-c "pg_ctl -D data6 start" ←第６のDBサーバプロセスの起動
（データ領域data6に対するデータベース）」

APサーバ14の業務処理部40、DB制御部42、第１のDB連絡部43〜第１０のDB連絡部52は、上記のように専用のプログラムに従い、CPUコア(01)〜コア(15)が所定の処理を実行することにより実現されるのであるが、この際、OSやミドルウェアによって複数のスレッドが起動されて各CPUコアに割り当てられることにより、マルチタスク処理が実現される。

図４は、各CPUコアと複数のスレッド78との対応関係を表しており、各スレッド78にはスレッドプール80が設けられ、そこに配置された複数のタスク82をスレッド78が順次処理していくイメージが描かれている。
この図におけるスレッド78が、APサーバ14の業務処理部40、DB制御部42、第１のDB連絡部43〜第１０のDB連絡部52として機能し、これらの各機能構成部が実行する具体的な処理が、タスク82に相当する。

各スレッド78は、スレッドプール80に蓄積されたタスク82を古い順に次々と実行していき、自己のスレッドプール80が空になった場合には、他のスレッド78のスレッドプール80に蓄積されたタスク82を、新しい順に実行していく。

図５に示すように、第１のDB連絡部43〜第６のDB連絡部48と、第１のDBサーバ16〜第６のDBサーバ21間は、各DBサーバに割り当てられたCPUコア数に対応した本数のコネクションプール84を介して接続されている。
例えば、第１のDBサーバ16には７個のCPUコアが割り当てられているため７本のコネクションプール84が設けられ、各コネクションプール84は予め第１のDBサーバ16の特定のCPUコアと関連付けられている。
また、第５のDBサーバ20には８個のCPUコアが割り当てられているため８本のコネクションプール84が設けられ、各コネクションプール84は予め第５のDBサーバ20の特定のCPUコアと関連付けられている。

補助記憶装置74内には、例えば、仕入テーブル86、注文テーブル87、注文明細テーブル88、注文取消テーブル89、品目テーブル90、完成品テーブル91、原材料テーブル92、原材料目録テーブル93、原価テーブル94、供給者テーブル95、顧客テーブル96等を含むテーブル群が、各DBサーバ単位で複数セット格納されている。

ここでは、第１のDBサーバ16〜第６のDBサーバ21が設けられているため、Ａ〜Ｆの６セットのテーブル群が、それぞれ各DBサーバ専用として補助記憶装置74内の別個の領域に格納されている。
また、後述のように、各テーブル群に属する同一名称のテーブルには、それぞれ同一のレコードが同時に重複して格納される。

図示は省略したが、第７のDBサーバ22〜第１０のDBサーバ30の補助記憶装置内にも、それぞれ仕入テーブル86、注文テーブル87、注文明細テーブル88、注文取消テーブル89、品目テーブル90、完成品テーブル91、原材料テーブル92、原材料目録テーブル93、原価テーブル94、供給者テーブル95、顧客テーブル96等を含むテーブル群が設けられており、第１のDBサーバ16〜第６のDBサーバ21と同一内容のデータが格納される。

図６は、各テーブルに格納されているレコードの構成を例示するものである。
すなわち、仕入テーブル86には、「仕入ID」、「原価ID」、「数量」のデータ項目を備えたレコードが格納されている。
また、注文テーブル87には、「注文ID」、「顧客ID」、「注文日時」のデータ項目を備えたレコードが格納されている。
注文明細テーブル88には、「注文明細ID」、「注文ID」、「品目ID」、「数量」のデータ項目を備えたレコードが格納されている。
注文取消テーブル89には、「注文明細ID」、「取消日時」のデータ項目を備えたレコードが格納されている。

品目テーブル90には、「品目ID」のデータ項目を備えたレコードが格納されている。
完成品テーブル91には、「品目ID」のデータ項目を備えたレコードが格納されている。
原材料テーブル92には、「品目ID」のデータ項目を備えたレコードが格納されている。
原材料目録テーブル93には、「原材料目録ID」、「親品目ID」、「子品目ID」、「数量」のデータ項目を備えたレコードが格納されている。
原価テーブル94には、「原価ID」、「供給者品目ID」、「原価」のデータ項目を備えたレコードが格納されている。
供給者テーブル95には、「供給者品目ID」、「供給者ID」、「品目ID」のデータ項目を備えたレコードが格納されている。
顧客テーブル96には、「顧客ID」のデータ項目を備えたレコードが格納されている。

上記の各テーブル86〜96に関しては、以下の(1)〜(4)の制約が予め課せられている。
(1)キー項目は一つに限定される。
したがって、複数の項目の組合せによってキー項目を構成すること（複合キー）は、禁止される。

(2)APサーバ14が各テーブルにアクセスするに際しては、レコードの参照と追加のみが許容され、既存レコードの削除と更新は禁止される。

このため、既存データを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードを追加することによって削除と同等の状態が実現される。例えば、注文の取り消しがなされた場合、一般的には取消の対象となる注文データに「取消」を示す値を記述することで状態が管理されることになるが、このシステム10においては、注文取消テーブル89に対象となる「注文明細ID」のレコードを追加することで「取消」の事実が表現される。

また、既存レコードの値に変更が生じた場合には、修正済みの値を備えた異なるプライマリキーのレコードを同一テーブルに追加することで、実質的に値の更新が実現される。例えば、原価テーブル94に格納されたあるレコードの原価を「３００円」から「５００円」に変更する場合、原価を「５００円」とした新たなレコードが原価テーブル94に追加される。各レコードにはミリ秒精度のタイムスタンプが刻印されているため、これを比較することでレコード間の新旧（更新の事実）が明確化される。

このようにAPサーバ14によるレコードの削除及び更新が禁止されているため、各テーブルには過去の如何なる時点のデータも温存されることとなり、将来において変更履歴の再現が必要となった場合にも対応できる利点がある。
ただし、十分に時間が経過し、データ保持の必要性が完全になくなった場合には、各DBサーバに直接ログインして削除のSQLを発行することにより、レコードを削除することはできる。

(3)各テーブルのカラムには、NULL値禁止制約、フラグ値禁止制約、区分値禁止制約が課せられる。
まず「NULL値禁止制約」とは、データ項目の値としてNULL（値なし）を充填することが禁止されることを意味しており、このようなNULL値の充填を想定したデータ項目の設定自体が許容されないことになる。
つぎに「フラグ値禁止制約」とは、データ項目の値としてフラグ値（「１／０」、「ON／OFF」、「TRUE／FALSE」等の２値データ）を充填することが禁止されることを意味しており、このようなフラグ値の充填を想定したデータ項目の設定自体が許容されないことになる。
「区分値禁止制約」とは、データ項目の値として区分値（「１：正社員」、「２：パート」、「３：アルバイト」等）を充填することが禁止されることを意味しており、このような区分値の充填を想定したデータ項目の設定自体が許容されないことになる。

(4)機能の拡張に際し、既存テーブルにカラムを追加する代わりに、テーブルの新設で対応する。
すなわち、上記のように「注文明細テーブル88」に格納された注文を取り消すに際し、現状では「注文取消テーブル89」に取り消したい注文の注文明細IDを登録することによって対応しているため、図７(a)に示すように、注文自体は維持したまま数量のみを減じたい場合であっても、一旦、全数量について取り消されてしまう。このためユーザは、減らした数量で再度発注する必要がある。

ここで、注文を維持したまま数量のみを減じることができるように機能を拡張するとなると、図７(b)に示すように、注文取消テーブル89に「取消数量」のカラムを追加することが考えられる。この結果、確かに注文を維持したまま数量のみを減じるという目的は達成できるが、多数のDBサーバにおいて現に使用中のテーブルに対して一斉に改変を加えるのは容易ではなく、また新機能に対応させたアプリケーションプログラムに不具合が生じた等の理由で元の機能に戻す必要が生じた場合でも、迅速に対応できないという問題が生じる。

このため、このシステム10では図８に示すように、従来の注文取消テーブル89は残したまま、「注文明細ID」、「取消数量」、「取消日時」のデータ項目を備えた部分取消テーブル89'を各DBサーバ内に新設する方式を採用している。
すなわち、数量単位での部分取消を認める新サービスに切り替わった時点で、注文取消テーブル89はシステム10から切り離される一方、注文の取消は部分取消テーブル89'に対象となる注文明細ID及び取消数量を備えたレコードを追加することによって記録される（注文自体を取り消す場合には、注文の全数量が「取消数量」として設定される。）

このように、多数のDBサーバにおいて現在稼働中のテーブルに対して一斉に修正を加えることに比べ、各DBサーバに新規のテーブルを追加する方が容易に実現できる。また、機能拡張前のテーブル（注文取消テーブル89）は改変されることなく温存されるため、万一、サービスを元に戻す必要が生じた場合にも迅速に対応できる利点がある。

上記(1)〜(4)の制約ルールは、新規テーブルの設計時やSQL文発行時に、各DBサーバのデータベース管理システムによって適否がチェックされ、制約ルールに違反する処理の実行が拒絶されることにより、その実効性が担保される。

このシステム10の場合、各テーブルに格納される個々のレコードが上記の通り極限まで正規化されており、またデータ間の演算処理は、後述のようにAPサーバ14のDB制御部42によって行われ、DBサーバ側の演算処理によって冗長な中間データが生成されることもないため、レコードの削除や更新の代わりに新規レコードの挿入によって対応するとしても、ディスク容量が従来に比べて徒に圧迫されることはない。また、キャッシュメモリのヒット率が向上するため、DBサーバの処理の高速化にも資する。

このようなテーブル群によって業務データが管理されている状況下において、新規データの登録を希望するユーザは、業務処理部40からクライアント端末36に送信されたデータ入力画面（図示省略）を通じて、データを入力する。

この入力データを業務処理部40から受け取ったDB制御部42は、第１のDB連絡部43〜第１０のDB連絡部52に対してデータの登録を依頼する。
各DB連絡部は、この入力データの登録を依頼するSQL文を、それぞれ自己の担当するDBサーバに発行する。

これを受けた各DBサーバでは、対応のテーブルに対するレコードの挿入が一斉に実行される。
この結果、各DBサーバが独立して管理している同名テーブルに、同一レコードが重複して格納されることとなる。

なお、第１のDB連絡部43〜第６のDB連絡部48は、それぞれが担当する各DBサーバ（第１のDBサーバ16〜第６のDBサーバ21）に対し、特定のCPUコアに関連付けられたコネクションプール84を通じてSQLを発行することにより、各DBサーバにおける担当CPUコアが指定される。
これを受けた各DBサーバでは、指定されたCPUコアにより、対応のテーブルに対するレコードの挿入が一斉に実行される。

各DBサーバは、DB連絡部からデータを受け取って自身のメモリに格納した時点で、DB連絡部に対して受取完了通知を送信し、その後、ハードディスクやSSD等の補助記憶装置内に設けられたテーブルに対応のレコードを格納する。

このDBサーバから送信された受取完了通知は、各DB連絡部を経由してDB制御部42に集められる。
DB制御部42は、全てのDB連絡部から受取完了通知が返ってきた時点で、業務処理部40に対して登録完了通知を出力する。

業務処理部40は、この登録信完了通知をDB制御部42から受け取った時点で、上記データを読み込みの対象と認識する。逆に言えば、登録完了通知が返ってくるまでの間、業務処理部40は当該データを読み込みの対象外とすることで、各DBサーバにおける登録のタイミングがずれて不正なデータが読み込まれてしまう危険性を回避している。

このシステム10の場合、上記のように、各業務データは挿入のみが許容され、削除や更新が認められないルールが適用されているため、データの復旧が極めて容易となる。
すなわち、データの削除や更新が許容されることを前提とした場合、データを復旧させるためにはDBサーバが保持している更新履歴情報に基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに長い時間と大きな負荷を要することになる。また、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要がある。

これに対し、このシステム10のようにデータの挿入のみが許容され、削除と更新が禁止される前提の場合、他の正常なDBサーバに登録されたデータと障害が発生したDBサーバに登録されたデータを比較し、単純に足りないデータをコピーするだけで済み、データの順序（先後関係）を考慮する必要がなくなる。

例えば、サーバコンピュータ24自体が故障した場合には、同一構内に設置された第７のDBサーバ22内のデータを新たなサーバコンピュータ内に取り込むことで、極めて容易にデータの復旧が可能となる。
あるいは、地震等の大規模災害が発生し、データセンター12が壊滅的な打撃を受けた場合には、遠隔地に設置された第８のDBサーバ26〜第１０のDBサーバ30内のデータに基づいて、比較的早期にデータの復旧が可能となる。

このシステム10にあっては、上記のようにDB連絡部から送信されたデータがDBサーバのメモリに格納された時点で、DBサーバから受取完了通知がAPサーバ14に発行されるため、極めて短時間の中に業務処理部40は当該データを読み込みの対象とすることができる。

これまでの常識では、メモリは揮発性の記憶手段であり、電源供給が停止された時点でデータが喪失してしまうため、不揮発性の記憶手段（ハードディスク等）にデータが格納された時点で完了通知が返されるべきとなる。
これに対し、このシステム10の場合には、あるDBサーバでデータの欠損が発生しても、他のDBサーバから不足データをコピーするだけで追い着くことができるため、データがハードディスク等に格納されるまで待機する必要がない。

つぎに、ある完成品（例えば品目ID「NRI-0001」）の在庫数についてクライアント端末から参照リクエストが送信された場合の処理手順について、図９及び図１０のフローチャートに従い説明する。

まず、業務処理部40から送信された検索条件指定画面（図示省略）上でユーザが完成品である品目ID「NRI-0001」の在庫検索を指定すると、この検索リクエストの実現に必要な処理が、業務処理部40によって特定される（図９のＳ10）。

具体的には、以下の処理内容が特定された後、順次実行される。
(01)注文明細テーブル88から、品目ID「NRI-0001」を備えた全レコードを抽出する（Ｓ12）。
(02)品目ID「NRI-0001」の累積注文数量を算出する（Ｓ14）。
(03)注文取消テーブル89から、品目ID「NRI-0001」を備えた全レコードを抽出する（Ｓ16）。
(04)品目ID「NRI-0001」の累積注文取消数量を算出する（Ｓ18）。
(05)品目ID「NRI-0001」の累積注文数量から累積注文取消数量を減算して、現時点における累積実注文数量を算出する（Ｓ20）。
(06)原材料目録テーブル93を参照し、品目ID「NRI-0001」を親品目IDとしている子品目IDと、その数量を取得する（Ｓ22）。この子品目IDが、完成品である品目ID「NRI-0001」の原材料を示している。
(07)各子品目IDをキーにして、供給者テーブル95から供給者品目IDを取得する（図１０のＳ24）。
(08)供給者品目IDをキーにして、原価テーブル94から原価IDを取得する（Ｓ26）。
(09)原価IDをキーにして、仕入テーブル86から当該原材料に係る全レコードを抽出する（Ｓ28）。
(10)原材料毎に、累積仕入数量を算出する（Ｓ30）。
(11)各原材料の累積仕入数量に基づいて、品目ID「NRI-0001」の生産可能数量を算出する（Ｓ32）。
(12)この生産可能数量から累積実注文数量を減算することにより、当該完成品の現在における在庫数量を算出する（図９のＳ34）。
(13)最後に、「NRI-0001」の在庫数量が記載された処理結果画面（図示省略）をクライアント端末36に送信する（Ｓ36）。

これらの処理の中、データの抽出処理は、第１のDB連絡部43〜第６のDB連絡部48の何れかが、第１のDBサーバ16〜第６のDBサーバの何れかに対してSQL文を発行することによって実行される。
この際、各DB連絡部は各DBサーバに対し、特定のCPUコアに関連付けられたコネクションプール84を通じてSQL文を送信する。この結果、DBサーバにおけるレコードの抽出処理は、指定されたCPUコアによって実行される。
また、各DBサーバから送信されたデータに対しては、DB制御部42によってソートやマージ、マッチング、コントロールブレイク等の必要な演算処理が施される。

ところで、上記の各処理の中には、先行する処理が完了しないと後続の処理を実行できないものと、同時並行して処理が可能なものとがある。
例えば、図９に示したように、注文明細テーブル88から該当品目IDのレコードを抽出するＳ12の処理と、注文取消テーブル89から該当品目IDのレコードを抽出するＳ16の処理と、原材料目録テーブル93を参照し、該当品目IDを親品目IDとしている子品目ID及び数量を取得するＳ22の処理は、品目IDが特定された時点で同時並行することができる。
このため、DB制御部42は、上記の処理をそれぞれ別個のCPUコアを指定し、対応のDB連絡部を通じて各DBサーバに抽出処理を依頼する。

また、Ｓ22の処理によって完成品を生産するのに必要な原材料の種類が特定された時点で、図１０に示したように、各原材料の仕入数量を算出するのに必要なデータの抽出処理が開始されることになるが、このＳ24〜Ｓ28も原材料毎に同時並行で処理される。
例えば、原材料の数が50種類であった場合、DB制御部42は、それぞれ異なる50個のCPUコアを指定し、対応のDB連絡部を通じて各DBサーバにレコードの抽出を依頼する。
このように、特定のCPUコアに具体的なレコードの抽出を直接的に割り振ることにより、効率的にデータの参照が可能となる。

なお、原材料の種類が数百種以上に及ぶ場合、原材料単位の処理を一度に異なるCPUコアに割り当てることができなくなる。
このような場合、DB制御部42は各CPUコアに順番に原材料毎の処理を依頼し、処理が完了した時点で当該CPUコアに残りの原材料単位の処理を順番に割り当てることを繰り返す。

特定の業務処理を実現するために必要なデータの種類や抽出手順についてはAPサーバ14のアプリケーションプログラムが認識しているため、具体的なレコードの抽出を各DBサーバに対しCPUコアを指定した形で依頼することにより、マルチコアCPUの潜在能力を最も効果的に引き出すことが可能となる。

なお、OSには統計情報に基づいてデータ処理の効率化や省電力化を実現するため、処理の途中で敢えてCPUのクロック数をダウンさせる機能が設けられているが、本システム10のようにCPUコア単位で処理内容をきめ細かく制御する際には邪魔になるため、この種の余計なサービスは事前に無効化しておくことが望ましい。

上記のように、このシステム10の場合、各DBサーバには同一のデータが重複して蓄積されているため、DB制御部42は必要なデータを最も高速で処理可能なDBサーバから自由に取得することができるし、複数のDBサーバから分散的にデータを取得して結合させることもできる。

また、データの参照や登録に必要なSQL文は各DB連絡部によって発行されるため、業務処理部40やDB制御部42を実現するためのアプリケーションプログラム中にSQL文を記述する必要がなくなる。
しかも、各DBサーバに格納されたテーブルは極度に正規化されており、各DB連絡部はDB制御部42に指定されたデータの登録と抽出のみを担当するものであるため、DB連絡部用のプログラム中に記述されるSQL文も極めて簡素なもので間に合い、サービスの機能拡張に際して一々改変する必要がない。
もちろん、サービスの機能拡張時には業務処理部40及びDB制御部42を実現するためのアプリケーションプログラムについては修正を施す必要があるが、SQL文の記述を含まない分、見通しが良好となり、バグの発見が容易となる。

この発明に係るサービス提供システムの全体構成図である。 APサーバの機能構成を示すブロック図である。 APサーバのハードウェア構成を示す模式図である。 APサーバの各CPUコアと複数のスレッドとの対応関係を示す模式図である。 APサーバの一部のDB連絡部と、APサーバと同一の筐体内に設けられた各DBサーバとの間の対応関係を示す模式図である。各テーブルに格納されているレコードの構成例を示す図である。サービスの機能拡張時におけるテーブル構成の変更例を示す図である。サービスの機能拡張時におけるテーブル構成の変更例を示す図である。このシステムにおけるデータ抽出時の処理手順を例示するフローチャートである。このシステムにおけるデータ抽出時の処理手順を例示するフローチャートである。

10 サービス提供システム
12 データセンター
14 APサーバ
16 第１のDBサーバ
17 第２のDBサーバ
18 第３のDBサーバ
19 第４のDBサーバ
20 第５のDBサーバ
21 第６のDBサーバ
22 第７のDBサーバ
24 サーバコンピュータ
26 第８のDBサーバ
28 第９のDBサーバ
30 第１０のDBサーバ
32 通信回線
34 インターネット
36 クライアント端末
40 業務処理部
42 DB制御部
43 第１のDB連絡部
44 第２のDB連絡部
45 第３のDB連絡部
46 第４のDB連絡部
47 第５のDB連絡部
48 第６のDB連絡部
49 第７のDB連絡部
50 第８のDB連絡部
51 第９のDB連絡部
52 第１０のDB連絡部
60 第１のCPUパッケージ
62 第２のCPUパッケージ
64 第３のCPUパッケージ
66 第４のCPUパッケージ
68 マザーボード
70 第１のメモリ
71 第２のメモリ
72 第３のメモリ
73 第４のメモリ
74 補助記憶装置
78 スレッド
80 スレッドプール
82 タスク
84 コネクションプール
86 仕入テーブル
87 注文テーブル
88 注文明細テーブル
89 注文取消テーブル
90 品目テーブル
91 完成品テーブル
92 原材料テーブル
93 原材料目録テーブル
94 原価テーブル
95 供給者テーブル
96 顧客テーブル

Claims

APサーバと、このAPサーバと接続された複数のDBサーバとを備え、クライアント端末に対して所定の情報処理サービスを提供するサービス提供システムであって、
上記APサーバは、上記の各DBサーバ単位で設けられた複数のDB連絡部と、業務処理部と、DB制御部とを備え、
上記の各DB連絡部には、それぞれ担当するDBサーバの特定情報が設定されており、
上記の各DBサーバには、相互に共通するデータを格納するテーブルがそれぞれ設けられており、
各テーブルには、レコードの削除及び更新が禁止される制約が設けられており、
上記業務処理部からデータの登録依頼を受けた際に、上記DB制御部は、当該データを複製して上記の全DB連絡部に渡し、
これを受けた各DB連絡部は、自己の担当するDBサーバにSQL文を発行してレコードの追加を求め、
上記業務処理部から特定データの参照を求められた場合に、上記DB制御部は、上記の各DBサーバの中から１または複数のDBサーバを特定し、当該DBサーバを担当しているDB連絡部に対してデータの抽出を依頼し、
これを受けたDB連絡部は、自己の担当しているDBサーバに対してSQL文を発行してレコードの抽出を依頼すると共に、DBサーバから受け取ったデータをDB制御部に渡し、
DB制御部は、受け取ったデータに必要な演算処理を施した上で、上記業務処理部に渡すことを特徴とするサービス提供システム。
上記業務処理部は、既存データを更新する必要がある場合に、更新後の値を備えたデータを新たに生成し、
上記DB制御部及び各DB連絡部を介してこのデータを各DBサーバに設けられた既存のテーブルに追加登録させることにより、既存データの実質的な更新を実現することを特徴とする請求項１に記載のサービス提供システム。
上記業務処理部は、既存の業務データを削除する必要がある場合に、当該業務データのIDを格納するデータ項目を備えたデータ取消用のデータを生成し、
上記DB制御部及び各DB連絡部を介してこのデータ取消用のデータを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存データの実質的な削除を実現することを特徴とする請求項１または２に記載のサービス提供システム。
上記APサーバ及び上記DBサーバの中の少なくとも２以上のDBサーバが、同一のコンピュータ上に形成されており、
このコンピュータは、複数のCPUコアを内蔵したCPUパッケージと、複数のテーブルを格納しておく記憶装置を備え、
このコンピュータ上でAPサーバ用プログラムを起動させることによって上記APサーバが構成されると共に、このAPサーバ上で専用のアプリケーションプログラムを起動させることによって上記の業務処理部、DB制御部及び複数のDB連絡部が構成され、
同コンピュータ上でDBサーバ用プログラムを複数起動させることによって上記の各DBサーバが構成され、
上記APサーバ及び各DBサーバには、それぞれ複数の異なるCPUコアが専用的に割り当てられており、
上記DBサーバにデータの抽出及び登録を依頼するに際しては、上記DB連絡部から当該処理を担当するCPUコアを具体的に指定した形でSQL文が発行され、
これを受けたDBサーバでは、指定されたCPUコアによって対応の処理が実行されることを特徴とする請求項１〜３の何れかに記載のサービス提供システム。
請求項１に記載したサービス提供システムにおいて、クライアント端末に対して提供するサービスの機能を拡張するに際し、
拡張後の機能に対応したテーブルを上記の各DBサーバ内に追加すると共に、拡張前の機能に係るテーブルを各DBサーバ内に置いたまま処理の対象外に設定し、
上記APサーバの業務処理部、DB制御部及び各DB連絡部を、追加したテーブルに対応した拡張バージョンに置き換えることを特徴とするサービス提供システムの機能拡張方法。