JP2011175422A

JP2011175422A - 判定プログラム、方法及び装置

Info

Publication number: JP2011175422A
Application number: JP2010038560A
Authority: JP
Inventors: Yoshihide Nomura; 佳秀野村; Toshihiro Odaka; 敏裕小高
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2010-02-24
Filing date: 2010-02-24
Publication date: 2011-09-08
Anticipated expiration: 2030-02-24
Also published as: JP5598017B2

Abstract

【課題】レプリケーションによるスケールアウトを実現するために、スレーブＤＢに対するプログラムのアクセスの是非を自動的に判定する。
【解決手段】本判定方法は、アクセス履歴から参照のみを行っている参照系プログラムを特定して、アクセス履歴において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目への参照を行った参照系プログラムについての特定の履歴データが存在しており、且つ当該特定の履歴データのセッションと同一のセッションで上記所定のデータ項目への更新アクセスが発生したことを表す履歴データが当該特定の履歴データの後に記録されているという条件を満たすか判断し、当該条件が満たされていれば、当該参照系プログラムがレプリケーション先へのアクセスが不適であると判定する。
【選択図】図３

Description

本技術は、レプリケーションによるスケールアウトを実現するための技術に関する。

例えばユーザ数や利用頻度が非常に多いウェブ（Ｗｅｂ）システムにおいては、Ｗｅｂサーバ（Ｗｅｂ層に属するサーバ）やデータベース（ＤＢ）サーバ（ＤＢ層に属するサーバ）を増やすことによって性能を向上させるスケールアウト（Scale out）が行われる場合がある。Ｗｅｂ層のスケールアウトについては、クラスタリング、セッション・レプリケーションなどの手法を採用することが知られている。一方、一般的なＲＤＢ（Relational DataBase）を用いたＤＢ層のスケールアウトについては、従来はユーザ数やその利用形態を事前に予測し、よく使われ且つレプリケーションを行っても問題ないと判断された処理ロジックについては、更新用ＤＢ（マスタＤＢと呼ぶ）のレプリカである参照用ＤＢ（スレーブＤＢと呼ぶ）に接続するようにＷｅｂアプリケーションを構築する。これによって、マスタＤＢの負荷を減らし、スケールアウトを実現する。

例えば、図１に示すように、ＤＢサーバをマスタＤＢサーバに加えて１又は複数のスレーブＤＢサーバで実現する。マスタＤＢサーバ内のデータは、定期的にスレーブＤＢサーバにコピーされて、両方のＤＢの内容が一致するようにする。そして、Ｗｅｂサーバで実行されているＷｅｂアプリケーションのうちある処理については、マスタＤＢサーバのＤＢにおけるデータにアクセスし、他のある処理についてはスレーブＤＢサーバのＤＢにおけるデータにアクセスするようにする。これによって、負荷が分散されて性能向上が可能になる。

しかし、アプリケーションのログを用いて利用頻度や負荷が高い処理を特定して、当該処理については参照用ＤＢを用いるという手法では、以下のような問題がある。すなわち、マスタＤＢからスレーブＤＢへのレプリケーションにタイムラグが発生するため、不適切な処理を参照用ＤＢに割り当てると、それに続く更新処理において、直前の参照とは異なる値を参照又は書き込んでしまい、ユーザから見ると正しくないトランザクション結果を引き起こす。より具体的には、タイムセールなどで単価が変化するような場合、参照用ＤＢを参照して古い単価を確認してショッピングカートに商品を投入した後、実際にショッピングカートに投入されている商品の注文を確定させるために更新用ＤＢにアクセスすると、異なった単価で代金が計算されてしまうというような事態が生じてしまう。

なお、オブジェクトへのアクセス履歴と業務役割に応じたオブジェクトへのアクセスルールとの適合性判定を行うことで、オブジェクト自体のデータ処理を行うことなく、ユーザの業務役割の判定を行う技術が存在する。より具体的には、文書データベースに保持されたオブジェクト（例えば文書）へのアクセスユーザ情報とアクセス対象オブジェクト情報とアクセス操作情報とアクセス時間情報とを含んだアクセス履歴を保持する。そして、業務役割に対応したアクセス対象オブジェクト情報及びアクセス操作の振る舞い情報を含むアクセスルールに対して、アクセス履歴が適合するか否かを判定して、ユーザの業務役割を判定する。しかし、ユーザの業務役割が判定されるのであって、マスタＤＢではなくスレーブＤＢへアクセスすべきプログラムを特定することはできない。

特開２００７−１２２１８号公報

以上のように、スケールアウトを行うには、レプリケーションによる更新遅延の影響をあまり受けないようなデータにアクセスするプログラムのみをスレーブＤＢに割り当てるようにしなければならない。また、このようなプログラムをソースコードを解析して見つけ出すのは非常に大きな工数がかかり、現実的ではない。

従って、本技術の目的は、レプリケーションによるスケールアウトを実現するために、スレーブＤＢに対するプログラムのアクセスの是非を自動的に判定するための技術を提供することである。

本判定方法は、（Ａ）セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に履歴データを読み出し、処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、（Ｂ）プログラムデータ格納部において参照を表す種別データが対応付けて登録されている判定対象のプログラムの各々について、アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれるデータ項目識別子及びセッションの識別子と同一のデータ項目識別子及びセッションの識別子と更新を表す処理種別とが関連付けられている履歴データが特定の履歴データの後に存在するという条件を満たすか判断するステップとを含む。

スレーブＤＢに対するプログラムのアクセスの是非を自動的に判定できるようになる。

図１は、従来のシステムの問題点を示す図である。図２は、Ｗｅｂアプリケーションの構成例を示す図である。図３は、本技術の実施の形態におけるシステム概要図である。図４は、サーブレットフィルタのWeb.xmlの定義例を示す図である。図５は、サーブレットフィルタのログ出力部分の一例を示す図である。図６は、アスペクト適用定義例を示す図である。図７は、アスペクト適用定義例を示す図である。図８は、アスペクト適用定義例を示す図である。図９は、アスペクト適用定義例を示す図である。図１０は、アクセス履歴収集処理を説明するためのシーケンス図である。図１１は、アクセス履歴収集処理によって出力されるログデータの一例を示す図である。図１２は、アクセス履歴収集処理によって出力されるログデータの一例を示す図である。図１３は、コントローラアクセス履歴データの一例を示す図である。図１４は、エンティティアクセス履歴データの一例を示す図である。図１５は、コントローラマスタの一例を示す図である。図１６は、エンティティマスタの一例を示す図である。図１７は、分析サーバの処理フローを示す図である。図１８は、コントローラ分類処理の処理フローを示す図である。図１９は、コントローラ分類処理の処理フローを示す図である。図２０は、コントローラ分類処理の処理結果の一例を示す図である。図２１は、コントローラ判定処理の処理フローを示す図である。図２２は、コントローラ判定処理の処理フローを示す図である。図２３は、コントローラ判定処理の処理結果の一例を示す図である。図２４は、スレーブＤＢへの割り当てが不可能なコントローラの例を示す図である。図２５は、スレーブＤＢへの割り当てが可能なコントローラの例を示す図である。図２６は、スケールアウト後のアクセス態様の一例を示す図である。図２７は、コンピュータの機能ブロック図である。図２８は、判定装置の機能ブロック図である。

本技術の実施の形態では、図１に示すようなＷｅｂシステムを想定する。また、Ｗｅｂサーバでは、Ｗｅｂアプリケーションが実行されており、当該Ｗｅｂアプリケーションは、図２に示すように、業務ロジックが規定されているコントローラと、データベース内のデータ項目に対応付けられており且つ当該データ項目にアクセスするエンティティとを含む。なお、コントローラは、特定のＵＲＬ（Uniform Resource Locator）に対してメソッドが対応付けられているクラスである。また、エンティティは、データベース内のデータ項目のデータをｇｅｔやｓｅｔインタフェースで読み書きを行うクラスである。

図２の例では、コントローラには、オーダーコントローラ（OrderController）とブックコントローラ（BookController）とが含まれる。エンティティには、オーダー（Order）というエンティティとブック（Book）というエンティティとが含まれる。オーダーコントローラは、オーダー・エンティティを呼び出し、ブックコントローラは、ブック・エンティティを呼び出す。オーダーコントローラは、所定のメソッド（confirm, submit）を実行して、オーダー・エンティティを呼び出す。同様に、ブックコントローラは、所定のメソッド（list, detail, update）を実行して、ブック・エンティティを呼び出す。オーダー・エンティティは、データベースにおける所定のデータ項目（customer, item, amount）のデータにアクセスする。また、ブック・エンティティは、データベースにおけるデータ項目（author, abstract, price）のデータにアクセスする。

次に、図３に、本実施の形態のシステム概要図を示す。図１と同様に、Ｗｅｂサーバ１００とＤＢサーバ２００とはネットワークで接続されている。また、Ｗｅｂサーバ１００では、Ｗｅｂアプリケーション１１０が実行されており、ＤＢサーバ２００は、ＲＤＢＭＳ（Relational DataBase Management System）２１０を管理している。図２に示したように、Ｗｅｂアプリケーション１１０は、複数のコントローラ１１１と、複数のエンティティ１１３と、Ｏ／Ｒ（Object/Relation）マッパライブラリ（図示せず）とを含み、Ｏ／Ｒマッパライブラリがエンティティ１１３を通じてＤＢサーバ２００のＲＤＢＭＳ２１０にアクセスするようになっている。本実施の形態では、Ｗｅｂサーバ１００にはアクセス履歴収集部１２０を導入すると共に、分析サーバ３００を導入して、ネットワークを介してＷｅｂサーバ１００に接続する。

なお、分析サーバ３００の処理には影響がないため、以下ではＯ／Ｒマッパライブラリについては説明を省略して、エンティティ１１３がＲＤＢＭＳ２１０にアクセスするものとして説明する。

分析サーバ３００は、マスタ格納部３１０と、アクセス履歴格納部３２０と、コントローラ分類部３３０と、コントローラ判定部３４０とを有する。Ｗｅｂサーバ１００に導入されたアクセス履歴収集部１２０は、分析サーバ３００のアクセス履歴格納部３２０にアクセス履歴データを格納する。

アクセス履歴収集部１２０は、Ｗｅｂサーバ１００に対して、例えば図４及び図５で規定されるようなサーブレット（servlet）フィルタを導入すると共に、例えば図６乃至図９で規定されるようなアスペクトをＷｅｂアプリケーション１１０に適用することによって、実現される。図４は、Ｗｅｂ．ｘｍｌの定義例を示しており、全てのＵＲＬ（＊で表す）についてlogFilterというフィルタ名のフィルタを導入することを示している。また、logFilterはSessionIdLogFilterというクラスとして実装される。さらに、図５に示すように、SessionIDLogFilterでは、スレッドＩＤ及びセッションＩＤを含むログを出力するようになっている。

また、図６にコントローラについてのアスペクト適用定義例を示す。ここではオーダーコントローラのconfirmメソッドを実行する際には、ログを生成するために、ControllerLogAroundAdviceというクラスが呼び出されることが規定されている。なお、図６では示していないが、他のコントローラ及びメソッドについても定義するものとする。図７に、ControllerLogAroundAdviceクラスにおいて、ログ出力コードの部分が示されている。ここでは、スレッドＩＤ、コントローラのクラス名及びメソッド名を含むログを出力するようになっている。なお、本実施の形態では、コントローラのクラス名及びメソッド名で、１つのプログラムとして特定され、コントローラＩＤとして識別子（ＩＤ）が付与されるものとする。

さらに、図８にエンティティについてのアスペクト適用定義例を示す。ここでは、オーダー・エンティティにおいてamountというデータ項目に値をセットするsetAmountメソッドを実行する際には、ログを生成するために、EntityLogAroundAdviceというクラスが呼び出されることが規定されている。なお、図８では示していないが、他のエンティティ及びメソッドについても定義するものとする。図９に、EntityLogAroundAdviceクラスにおいて、ログ出力コードの部分が示されている。ここでは、スレッドＩＤ、エンティティのクラス名、エンティティ・フィールド名及び処理種別（アクセス種別）を含むログを出力するようになっている。なお、本実施の形態では、エンティティのクラス名及びエンティティ・フィールド名で、１つのデータ項目が特定され、エンティティＩＤとして識別子（ＩＤ）が付与されるものとする。

以上述べたように、アクセス履歴収集部１２０は、既に知られているアスペクト指向プログラミングＡＯＰ（Aspect Oriented Programming）を利用して実現するものであり、これ以上は述べない。なお、以下で述べるようなアクセス履歴データを収集することができるのであれば、他の実現方法を採用するようにしても良い。

アクセス履歴収集部１２０は、図１０に示すようにアクセス履歴を収集する。ユーザ端末が、Ｗｅｂサーバ１００のＷｅｂアプリケーション１１０にリクエストを送信すると（ステップ（１））、Ｗｅｂアプリケーション１１０は、リクエストを受信し、該当するコントローラ１１１を呼び出す（ステップ（２））。このコントローラ呼び出しに応答して、アクセス履歴収集部１２０は、アクセス履歴のログデータ（履歴データとも呼ぶ）を、分析サーバ３００のアクセス履歴格納部３２０に格納する（ステップ（３））。例えば図４乃至図７に基づき、図１１に示すようなデータを格納する。図１１の例では、セッションＩＤ、スレッドＩＤ、コントローラクラス名及びコントローラメソッド名が格納される。なお、以下で述べるように、マスタ格納部３１０では、コントローラのクラスとメソッドの組み合わせ毎にコントローラＩＤが規定されているので、以後コントローラクラス名及びコントローラメソッド名を対応するコントローラＩＤに置換した形で示すものとする。

アクセス履歴収集部１２０は、受信したコントローラ呼び出しに対応する処理呼び出しを出力する（ステップ（４））。該当するコントローラ１１１は、リクエストに対する処理を実施するため、該当するエンティティ１１３を呼び出す（ステップ（５））。このエンティティ呼び出しに応答して、アクセス履歴収集部１２０は、アクセス履歴のログデータ（履歴データとも呼ぶ）を、分析サーバ３００のアクセス履歴格納部３２０に格納する（ステップ（６））。例えば図８及び図９に基づき、図１２に示すようなデータを格納する。図１２の例では、スレッドＩＤ、エンティティ・クラス名、エンティティ・フィールド名及び処理種別（参照（Ｒ）／更新（Ｗ））が格納される。なお、以下で述べるように、マスタ格納部３１０では、エンティティのクラスとフィールドの組み合わせ毎にエンティティＩＤが規定されているので、以後エンティティ・クラス名及びエンティティ・フィールド名を対応するエンティティＩＤに置換した形で示すものとする。

その後、アクセス履歴収集部１２０は、受信したエンティティ呼び出しに対応するエンティティ呼び出しを出力する（ステップ（７））。該当するエンティティ１１３は、要求された処理、すなわちＤＢサーバ２００のＲＤＢＭＳ２１０へのアクセス（参照又は更新）を実施する。

このような処理を繰り返し、所定時間後、例えば図１３及び図１４に示すようなデータが、アクセス履歴格納部３２０に格納されているものとする。図１３は、コントローラアクセス履歴データの一例を示す。図１３の例では、レコードＩＤと、セッションＩＤと、スレッドＩＤと、コントローラＩＤとが登録されるようになっている。なお、図１３の状態は、時刻（図示せず）及びセッションＩＤでソート済みであるものとする。図１４は、エンティティアクセス履歴データの一例を示す。図１４の例では、レコードＩＤと、スレッドＩＤと、エンティティＩＤと、処理種別とが登録されるようになっている。なお、図１４の状態は、時刻（図示せず）及びスレッドＩＤでソート済みであるものとする。このように、スレッドＩＤで、セッションＩＤとエンティティＩＤとコントローラＩＤとが関連付けられている。

なお、マスタ格納部３１０には、図１５及び図１６のデータが予め格納されている。図１５に、コントローラマスタの一例を示す。図１５の例では、コントローラマスタには、コントローラＩＤと、クラス名と、メソッド名とが予め格納されるようになっている。また、コントローラマスタには、参照のみを行うのか否かを表す更新分類と、スレーブＤＢへアクセスさせることが適切か否かを表す判定結果とが、後の処理にて登録されるようになっている。但し、これらのデータについては、別の記憶装置に格納するようにしても良い。

また、図１６に、エンティティマスタの一例を示す。図１６の例では、エンティティマスタには、エンティティＩＤと、クラス名と、フィールド名と、クリティカルフィールドであるか否かを表すクリティカルフラグとが予め格納されるようになっている。クリティカルフィールドというのは、レプリケーションによる更新遅延などの影響を受けて出力結果が変わってしまうと問題とされるようなデータ項目であって、予め指定されるものである。但し、クリティカルフラグがＴｒｕｅであるレコードのみをエンティティマスタに登録するようにしても良い。

次に、図１７乃至図２６を用いて、分析サーバ３００の動作について説明する。まず、分析サーバ３００のコントローラ分類部３３０は、コントローラ分類処理を実施する（ステップＳ１）。処理結果は、マスタ格納部３１０のコントローラマスタにおける更新分類の列に登録される。このコントローラ分類処理については後に詳細に説明する。そして、コントローラ分類処理の処理結果を用いて、コントローラ判定部３４０は、コントローラ判定処理を実施する（ステップＳ３）。処理結果は、マスタ格納部３１０のコントローラマスタにおける判定結果の列に登録される。このコントローラ判定処理については後の詳細に説明する。

次に、図１８乃至図２０を用いて、コントローラ分類処理について説明する。まず、コントローラ分類部３３０は、エンティティアクセス履歴を時刻（図示せず）及びスレッドＩＤでソートして、アクセス履歴格納部３２０に格納する（図１８：ステップＳ１１）。図１４のような状態になる。また、コントローラ分類部３３０は、コントローラアクセス履歴を時刻（図示せず）及びセッションＩＤでソートして、アクセス履歴格納部３２０に格納する（ステップＳ１３）。図１３のような状態になる。

その後、コントローラ分類部３３０は、エンティティアクセス履歴において、未処理のスレッドＩＤを１つ特定する（ステップＳ１５）。また、コントローラ分類部３３０は、特定されたスレッドＩＤのレコードの処理種別に「更新」が含まれているか確認する（ステップＳ１７）。図１４の例では、スレッドＩＤが「Ｔ００１」であるレコードを見てみると、処理種別は参照「Ｒ」だけであるので、「更新」は含まれない。一方、スレッドＩＤが「Ｔ００２」であるレコードを見てみると、処理種別に更新「Ｗ」が含まれている。処理は、端子Ａを介して図１９の処理に移行する。

図１９の処理の説明に移行して、処理種別に「更新」が含まれる場合には（ステップＳ１９：Ｙｅｓルート）、コントローラ分類部３３０は、特定されたスレッドＩＤでコントローラアクセス履歴を検索し、該当するコントローラＩＤを特定する（ステップＳ２１）。スレッドＩＤが「Ｔ００２」の場合、「Ｔ００２」で図１３で示したコントローラアクセス履歴を検索して、該当するレコードにおけるコントローラＩＤ「Ｃ００２」を取得する。その後、コントローラ分類部３３０は、コントローラマスタにおいて、特定されたコントローラＩＤに対応付けて、更新分類の値として「更新（Ｗ）」を登録する（ステップＳ２３）。そしてステップＳ２９に移行する。

一方、処理種別に「更新」が含まれない場合には（ステップＳ１９：Ｎｏルート）、コントローラ分類部３３０は、特定されたスレッドＩＤでコントローラアクセス履歴を検索し、該当するコントローラＩＤを特定する（ステップＳ２５）。ステップＩＤが「Ｔ００１」の場合、「Ｔ００１」で図１３に示したコントローラアクセス履歴を検索して、該当するレコードにおけるコントローラＩＤ「Ｃ００１」を取得する。その後、コントローラ分類部３３０は、コントローラマスタにおいて、特定されたコントローラＩＤに対応付けて、更新分類の値として「参照（Ｒ）」を登録する（ステップＳ２７）。

ステップＳ２３又はＳ２７の後に、コントローラ分類部３３０は、エンティティアクセス履歴において全てのスレッドＩＤを処理したか判断する（ステップＳ２９）。未処理のスレッドＩＤが存在する場合には端子Ｂを介してステップＳ１５に戻る。一方、全てのスレッドＩＤを処理した場合には、元の処理に戻る。

このような処理を実施することによって、図２０のようにコントローラマスタが更新される。すなわち、更新分類の列に参照（Ｒ）又は更新（Ｗ）が登録されるようになる。本実施の形態では、「参照」だけを行う、コントローラのメソッドのうち以下で述べる特徴を有する一部のメソッドを、スレーブＤＢへアクセスするように変更すれば、スケールアウトの効果をそのまま得ることができるようになる。従って、以下の処理で、参照のみを行う、コントローラのメソッドのみについて、スレーブＤＢへのアクセスに変更することが適切か否かを判断する。

次に、図２１乃至図２６を用いてコントローラ判定処理について説明する。コントローラ判定部３４０は、コントローラマスタにおいて未処理の参照系コントローラ（より具体的には、コントローラ・クラスのメソッド）を１つ特定する（ステップＳ３１）。具体的には、コントローラマスタの更新分類の列に「参照」が登録されている未処理のコントローラのコントローラＩＤを１つ特定する。

そして、コントローラ判定部３４０は、未処理の参照系コントローラが存在しているか判断する（ステップＳ３３）。未処理の参照系コントローラが存在しない場合には、元の処理に戻る。一方、未処理の参照系コントローラが存在した場合には、コントローラ判定部３４０は、コントローラアクセス履歴において、特定された参照系コントローラに該当するスレッドＩＤを特定する（ステップＳ３５）。例えば、ステップＳ３１でコントローラＩＤ「Ｃ００１」が特定された場合、図１３のコントローラアクセス履歴においては、スレッドＩＤ「Ｔ００１」が特定される。またステップＳ３１でコントローラＩＤ「Ｃ００３」が特定された場合、図１３のコントローラアクセス履歴においては、スレッドＩＤ「Ｔ００３」が特定される。

その後、コントローラ判定部３４０は、特定されたスレッドＩＤで、エンティティアクセス履歴を検索し、該当するレコードを特定する（ステップＳ３７）。スレッドＩＤ「Ｔ００１」の場合には、図１４のテーブルの第１及び第２行が特定される。また、スレッドＩＤ「Ｔ００３」の場合、図１４のテーブルの第６及び第７行が特定される。そして、コントローラ判定部３４０は、特定されたレコードのエンティティＩＤを特定し、エンティティマスタに登録されているクリティカルフィールドへの参照が含まれているか確認する（ステップＳ３９）。エンティティアクセス履歴において第１及び第２行が特定された場合、該当するエンティティＩＤは「Ｅ００１」及び「Ｅ００３」である。一方、エンティティマスタ（図１６）からすると、クリティカルフラグが「Ｔｒｕｅ」となっているエンティティＩＤは「Ｅ００３」及び「Ｅ００６」である。従って、クリティカルフィールドへの参照が含まれていると判断される。このような場合には、クリティカルフラグが「Ｔｒｕｅ」であるエンティティＩＤ「Ｅ００３」を保持しておく。

一方、エンティティアクセス履歴において第６及び第７行が特定された場合、該当するエンティティＩＤは「Ｅ００４」及び「Ｅ００６」である。従って、クリティカルフィールドへの参照が含まれていると判断され、クリティカルフラグが「Ｔｒｕｅ」であるエンティティＩＤ「Ｅ００６」を保持しておく。

処理は端子Ｃを介して図２２の処理に移行する。図２２の処理の説明に移行して、ステップＳ３９でクリティカルフィールドへの参照が存在しないと判断された場合には（ステップＳ４１：Ｎｏルート）、コントローラ判定部３４０は、ステップＳ３１で特定された参照系コントローラに対応付けて、判定結果として「参照可能」を登録する（ステップＳ４３）。すなわち、クリティカルフィールドへの参照がなければ、スレーブＤＢへアクセスするように変更しても問題は発生しない。従って、ステップＳ４３で、その旨を登録する。そして、端子Ｄを介してステップＳ３１に戻る。

一方、ステップＳ３９でクリティカルフィールドへの参照が存在すると判断された場合には（ステップＳ４１：Ｙｅｓルート）、コントローラ判定部３４０は、コントローラアクセス履歴において、ステップＳ３１で特定された参照系コントローラのセッションＩＤを特定する（ステップＳ４５）。例えば、ステップＳ３１で特定されたコントローラＩＤが「Ｃ００１」であれば、セッションＩＤ「Ｓ００１」が特定される。また、ステップＳ３１で特定されたコントローラＩＤが「Ｃ００３」であれば、セッションＩＤ「Ｓ００２」が特定される。

そして、コントローラ判定部３４０は、特定されたセッションＩＤと同じセッションにおいて、後続のコントローラが更新系であるかを確認する（ステップＳ４７）。例えば、セッションＩＤ「Ｓ００１」であれば、処理に係るコントローラＩＤ「Ｃ００１」の後に出現するコントローラＩＤは「Ｃ００２」である。コントローラマスタを、コントローラＩＤ「Ｃ００２」で検索すれば、当該コントローラＩＤに対応付けて「更新（Ｗ）」が登録されている。従って、後続のコントローラは更新系であることが分かる。一方、セッションＩＤ「Ｓ００２」であれば、処理に係るコントローラＩＤ「Ｃ００３」の後に出現するコントローラＩＤは「Ｃ００４」である。コントローラマスタを、コントローラＩＤ「Ｃ００４」で検索すれば、当該コントローラＩＤは参照系であることが分かる。

そうすると、後続のコントローラが更新系でなければ（ステップＳ４９：Ｎｏルート）、ステップＳ４３に移行する。すなわち、判定結果として「参照可能」が登録される。一方、後続のコントローラが更新系であれば（ステップＳ４９：Ｙｅｓルート）、コントローラ判定部３４０は、該当する後続の更新系コントローラのスレッドＩＤをコントローラアクセス履歴において特定し、エンティティアクセス履歴において当該スレッドＩＤに該当するレコードを特定する（ステップＳ５１）。上で述べたように、後続の更新系コントローラのコントローラＩＤが「Ｃ００２」であれば、スレッドＩＤは「Ｔ００２」である。よって、エンティティアクセス履歴において、第３乃至第５行が特定される。

その後、コントローラ判定部３４０は、特定されたレコードに、ステップＳ３１で特定された参照系コントローラの参照クリティカルフィールドと同一のフィールドに対する更新が含まれるか確認する（ステップＳ５３）。ステップＳ３９で特定されたクリティカルフィールドに対応するエンティティＩＤが「Ｅ００３」であり、エンティティアクセス履歴の第３乃至第５行に、エンティティＩＤ「Ｅ００３」及び処理種別「Ｗ」が登録されている行が存在するか判断する。第５行がこの条件を満たしていることが分かる。

ステップＳ５３で特定されたレコードに、ステップＳ３１で特定された参照系コントローラの参照クリティカルフィールドと同一のフィールドに対する更新が含まれない場合には（ステップＳ５５：Ｎｏルート）、ステップＳ４３に移行する。すなわち、判定結果として「参照可能」が登録される。一方、ステップＳ５３で特定されたレコードに、ステップＳ３１で特定された参照系コントローラの参照クリティカルフィールドと同一のフィールドに対する更新が含まれる場合には（ステップＳ５５：Ｙｅｓルート）、コントローラ判定部３４０は、コントローラマスタにおいて、特定された参照系コントローラに対応付けて判定結果として「参照不可」を登録する（ステップＳ５７）。コントローラＩＤ「Ｃ００１」の場合、判定結果として「参照不可」が登録される。そして、処理は端子Ｄを介してステップＳ３１に戻る。

以上の処理を、コントローラマスタに登録されている全ての参照系コントローラについて処理が完了するまで繰り返す。

このような処理を実施することによって、コントローラマスタ（図２０）は、図２３に示すような状態に変化する。すなわち、コントローラＩＤ「Ｃ００１」についてのみ「参照不可」が登録され、コントローラＩＤ「Ｃ００３」及び「Ｃ００４」については「参照可能」が登録される。

図２４に示すように、セッション「Ｓ００１」で、スレッド「Ｔ００１」において、例えば参照系コントローラ「Ｃ００１」で実行される注文確認処理でクリティカルフィールド「注文金額」を参照した後に、同一セッション「Ｓ００１」で、スレッド「Ｔ００２」において、更新系コントローラ「Ｃ００２」で実行される注文決済処理で同一クリティカルフィールド「注文金額」を更新するようなケースでは、注文確認処理を実施する参照系コントローラ「Ｃ００１」については、スレーブＤＢへのアクセスに変更させることができない。これは、レプリケーションによる更新遅延の影響が、外部からアクセスしてきているユーザに対して現れてしまうからである。

一方、図２５に示すように、セッション「Ｓ００２」で、スレッド「Ｔ００３」において、例えば参照系コントローラ「Ｃ００３」で実行されるリスト確認処理でクリティカルフィールド「単価」を参照した後に、同一セッション「Ｓ００２」で、スレッド「Ｔ００４」において、参照系コントローラ「Ｃ００４」で実行される詳細確認処理で同一クリティカルフィールド「単価」を参照するケースでは、参照系コントローラ「Ｃ００３」を、スレーブＤＢへのアクセスに変更しても問題がない。

以上のように、コントローラ・クラスのメソッド単位で、スケールアウトする際にスレーブＤＢへのアクセスに変更することができるか否かを、アクセス履歴という比較的容易に取得できるデータにより自動的に判定することができるようになる。

従って、コントローラマスタに登録された判定結果に従って、例えば図２６に示すようなアクセス態様に変更しても問題を発生させずに、スケールアウトを行うことができるようになる。図２６の例では、図２４の状況に基づき、Ｗｅｂアプリケーションにおいて注文確認処理を実行する参照系プログラム及び注文決済処理を実行する更新系プログラムについては、マスタＤＢサーバで管理されるデータベースにアクセスするが、注文履歴参照を実行する参照系プログラムについては、定期的にレプリケーションが実施されるスレーブＤＢサーバのデータベースにアクセスするような構成変更が行われるようになる。

以上本技術の実施の形態について説明したが、本技術はこれに限定されるものではない。例えば、上では良く使用されるフレームワークに従ってコントローラとエンティティに分けられる場合を説明したが、このような前提的な構成に適用範囲が限定されるわけではない。

また、分析サーバ３００の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成が一致しない場合もある。さらに、マスタデータ及びアクセス履歴のテーブル構成についても一例に過ぎず、他の構成を採用するようにしても良い。処理フローについても、処理結果が変わらない限り、処理ステップの順番を入れ替えたり、並列実行するようにしても良い。

また、参照可のみ又は参照不可のみをコントローラマスタに登録するようにしても良い。

なお、上で述べた分析サーバ３００は、コンピュータ装置であって、図２７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

このようにすれば、上で述べた条件を導入することによって、レプリケーションによる悪影響を最小限に抑えて、レプリケーションによるスケールアウトを行うことができるようになる。

また、上記判定方法は、上記条件を満たす判定対象のプログラムの識別子に対応付けてレプリケーション先へのアクセスが不適であることを表すデータをプログラムデータ格納部に格納するステップをさらに含むようにしてもよい。また、上記条件を満たさない判定対象のプログラムの識別子に対応付けてレプリケーション先へのアクセスが適切であることを表すデータをプログラムデータ格納部に格納するステップをさらに含むようにしても良い。レプリケーション先へのアクセスが不適なプログラムと適切なプログラムとのうち少なくともいずれかが自動的に特定されるようになる。

なお、アクセス履歴格納部が、セッションの識別子とプログラムの識別子とスレッドの識別子とを対応付ける第１の履歴データとスレッドの識別子とアクセス先のデータ項目を識別するためのデータ項目識別子と処理種別とを対応付ける第２の履歴データとを格納するようにしてもよい。その際、スレッドの識別子により第１の履歴データと第２の履歴データとが関連付けられているような場合もある。スケールアウトを実施するシステムによっては、上で述べたような２系統の履歴データが取得される場合もある。

さらに、アクセス先のデータ項目を識別するためのデータ項目識別子が、プログラムから呼び出され且つアクセス先のデータ項目に対応付けられている別のプログラムの識別子である場合もある。データベース内の特定のデータ項目へのアクセスが、特定のプログラムにより行われるような実装の場合にも対処可能である。また、上記プログラムがコントローラであり、上記別のプログラムがエンティティである場合もある。

本判定装置（図２８）は、（Ａ）セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部（図２８：３０１０）から、判定対象のプログラム毎に履歴データを読み出し、処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部（図２８：３０３０）に格納するプログラム分類部（図２８：３０２０）と、（Ｂ）プログラムデータ格納部において参照を表す種別データが対応付けて登録されている判定対象のプログラムの各々について、アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれるデータ項目識別子及びセッションの識別子と同一のデータ項目識別子及びセッションの識別子と更新を表す処理種別とが関連付けられている履歴データが特定の履歴データの後に存在するという条件を満たすか判断するプログラム判定部と（図２８：３０４０）とを有する。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

３００分析サーバ３１０マスタ格納部
３２０アクセス履歴格納部３３０コントローラ分類部
３４０コントローラ判定部
１２０アクセス履歴収集部

Claims

セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、前記アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれる前記データ項目識別子及び前記セッションの識別子と同一のデータ項目識別子及びセッションの識別子と前記更新を表す処理種別とが関連付けられている履歴データが前記特定の履歴データの後に存在するという条件を満たすか判断するステップと、
を、コンピュータに実行させるための判定プログラム。
前記条件を満たす判定対象のプログラムの識別子に対応付けて前記レプリケーション先へのアクセスが不適であることを表すデータを前記プログラムデータ格納部に格納するステップ
をさらに前記コンピュータに実行させるための請求項１記載の判定プログラム。
前記条件を満たさない判定対象のプログラムの識別子に対応付けて前記レプリケーション先へのアクセスが適切であることを表すデータを前記プログラムデータ格納部に格納するステップ
を前記コンピュータにさらに実行させるための請求項１又は２記載の判定プログラム。
セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、前記アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれる前記データ項目識別子及び前記セッションの識別子と同一のデータ項目識別子及びセッションの識別子と前記更新を表す処理種別とが関連付けられている履歴データが前記特定の履歴データの後に存在するという条件を満たすか判断するステップと、
を含み、コンピュータにより実行される判定方法。
セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するプログラム分類部と、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、前記アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれる前記データ項目識別子及び前記セッションの識別子と同一のデータ項目識別子及びセッションの識別子と前記更新を表す処理種別とが関連付けられている履歴データが前記特定の履歴データの後に存在するという条件を満たすか判断するプログラム判定部と、
を含む判定装置。