(57)【特許請求の範囲】
【請求項１】
セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に、前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを、前記処理種別に更新が含まれる場合には更新を表す種別データを、当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、
前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたデータ項目識別子を特定し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子である場合には、前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたセッションの識別子を特定し、
前記アクセス履歴格納部において、特定された前記セッションの識別子と同一のセッションの識別子が関連付けられた後続のプログラムの識別子を特定し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されているか判断し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されている場合には、前記アクセス履歴格納部において、特定された前記後続のプログラムの識別子に関連付けられた前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断するステップと、
を、コンピュータに実行させるための判定プログラム。
【請求項２】
特定された前記後続のプログラムの識別子に関連付けられた前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であると判断された前記判定対象のプログラムの識別子に対応付けて前記レプリケーション先へのアクセスが不適であることを表すデータを前記プログラムデータ格納部に格納するステップ
をさらに前記コンピュータに実行させるための請求項１記載の判定プログラム。
【請求項３】
特定された前記後続のプログラムの識別子に関連付けられた前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であると判断されなかった前記判定対象のプログラムの識別子に対応付けて前記レプリケーション先へのアクセスが適切であることを表すデータを前記プログラムデータ格納部に格納するステップ
を前記コンピュータにさらに実行させるための請求項１又は２記載の判定プログラム。
【請求項４】
セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に、前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを、前記処理種別に更新が含まれる場合には更新を表す種別データを、当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、
前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたデータ項目識別子を特定し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子である場合には、前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたセッションの識別子を特定し、
前記アクセス履歴格納部において、特定された前記セッションの識別子と同一のセッションの識別子が関連付けられた後続のプログラムの識別子を特定し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されているか判断し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されている場合には、前記アクセス履歴格納部において、特定された前記後続のプログラムの識別子に関連付けられた前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断するステップと、
を含み、コンピュータにより実行される判定方法。
【請求項５】
セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に、前記履歴データを読み出し、前記処理種別に更新が含まれない場合には参照を表す種別データを、前記処理種別に更新が含まれる場合には更新を表す種別データを、当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するプログラム分類部と、
前記プログラムデータ格納部において前記参照を表す種別データが対応付けて登録されている前記判定対象のプログラムの各々について、
前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたデータ項目識別子を特定し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断し、
特定された前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子である場合には、前記アクセス履歴格納部において、当該判定対象のプログラムの識別子に関連付けられたセッションの識別子を特定し、
前記アクセス履歴格納部において、特定された前記セッションの識別子と同一のセッションの識別子が関連付けられた後続のプログラムの識別子を特定し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されているか判断し、
前記プログラムデータ格納部において、特定された前記後続のプログラムの識別子に対応付けて前記更新を表す種別データが対応付けて格納されている場合には、前記アクセス履歴格納部において、特定された前記後続のプログラムの識別子に関連付けられた前記データ項目識別子が、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目の識別子であるかを判断するプログラム判定部と、
を含む判定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、レプリケーションによるスケールアウトを実現するための技術に関する。
【背景技術】
【０００２】
例えばユーザ数や利用頻度が非常に多いウェブ（Ｗｅｂ）システムにおいては、Ｗｅｂサーバ（Ｗｅｂ層に属するサーバ）やデータベース（ＤＢ）サーバ（ＤＢ層に属するサーバ）を増やすことによって性能を向上させるスケールアウト（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）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００５４】
以上述べた本実施の形態をまとめると、以下のようになる。
【００５５】
本判定方法は、（Ａ）セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部から、判定対象のプログラム毎に履歴データを読み出し、処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部に格納するステップと、（Ｂ）プログラムデータ格納部において参照を表す種別データが対応付けて登録されている判定対象のプログラムの各々について、アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれるデータ項目識別子及びセッションの識別子と同一のデータ項目識別子及びセッションの識別子と更新を表す処理種別とが関連付けられている履歴データが特定の履歴データの後に存在するという条件を満たすか判断するステップとを含む。
【００５６】
このようにすれば、上で述べた条件を導入することによって、レプリケーションによる悪影響を最小限に抑えて、レプリケーションによるスケールアウトを行うことができるようになる。
【００５７】
また、上記判定方法は、上記条件を満たす判定対象のプログラムの識別子に対応付けてレプリケーション先へのアクセスが不適であることを表すデータをプログラムデータ格納部に格納するステップをさらに含むようにしてもよい。また、上記条件を満たさない判定対象のプログラムの識別子に対応付けてレプリケーション先へのアクセスが適切であることを表すデータをプログラムデータ格納部に格納するステップをさらに含むようにしても良い。レプリケーション先へのアクセスが不適なプログラムと適切なプログラムとのうち少なくともいずれかが自動的に特定されるようになる。
【００５８】
なお、アクセス履歴格納部が、セッションの識別子とプログラムの識別子とスレッドの識別子とを対応付ける第１の履歴データとスレッドの識別子とアクセス先のデータ項目を識別するためのデータ項目識別子と処理種別とを対応付ける第２の履歴データとを格納するようにしてもよい。その際、スレッドの識別子により第１の履歴データと第２の履歴データとが関連付けられているような場合もある。スケールアウトを実施するシステムによっては、上で述べたような２系統の履歴データが取得される場合もある。
【００５９】
さらに、アクセス先のデータ項目を識別するためのデータ項目識別子が、プログラムから呼び出され且つアクセス先のデータ項目に対応付けられている別のプログラムの識別子である場合もある。データベース内の特定のデータ項目へのアクセスが、特定のプログラムにより行われるような実装の場合にも対処可能である。また、上記プログラムがコントローラであり、上記別のプログラムがエンティティである場合もある。
【００６０】
本判定装置（図２８）は、（Ａ）セッションの識別子とプログラムの識別子とデータベース内におけるアクセス先のデータ項目を識別するためのデータ項目識別子と参照又は更新を表す処理種別とが関連付けられて履歴データとして格納されているアクセス履歴格納部（図２８：３０１０）から、判定対象のプログラム毎に履歴データを読み出し、処理種別に更新が含まれない場合には参照を表す種別データを当該判定対象のプログラムの識別子に対応付けてプログラムデータ格納部（図２８：３０３０）に格納するプログラム分類部（図２８：３０２０）と、（Ｂ）プログラムデータ格納部において参照を表す種別データが対応付けて登録されている判定対象のプログラムの各々について、アクセス履歴格納部において、レプリケーションによる影響を受けるとして予め定められている所定のデータ項目を識別するための識別子と当該判定対象のプログラムの識別子とが関連付けられている特定の履歴データが存在しており、且つ当該特定の履歴データに含まれるデータ項目識別子及びセッションの識別子と同一のデータ項目識別子及びセッションの識別子と更新を表す処理種別とが関連付けられている履歴データが特定の履歴データの後に存在するという条件を満たすか判断するプログラム判定部と（図２８：３０４０）とを有する。
【００６１】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【符号の説明】
【００６２】
３００  分析サーバ    ３１０  マスタ格納部
３２０  アクセス履歴格納部    ３３０  コントローラ分類部
３４０  コントローラ判定部
１２０  アクセス履歴収集部
【図１】
0005598017.tif 000002
【図２】
0005598017.tif 000003
【図３】
0005598017.tif 000004
【図４】
0005598017.tif 000005
【図５】
0005598017.tif 000006
【図６】
0005598017.tif 000007
【図７】
0005598017.tif 000008
【図８】
0005598017.tif 000009
【図９】
0005598017.tif 000010
【図１０】
0005598017.tif 000011
【図１１】
0005598017.tif 000012
【図１２】
0005598017.tif 000013
【図１３】
0005598017.tif 000014
【図１４】
0005598017.tif 000015
【図１５】
0005598017.tif 000016
【図１６】
0005598017.tif 000017
【図１７】
0005598017.tif 000018
【図１８】
0005598017.tif 000019
【図１９】
0005598017.tif 000020
【図２０】
0005598017.tif 000021
【図２１】
0005598017.tif 000022
【図２２】
0005598017.tif 000023
【図２３】
0005598017.tif 000024
【図２４】
0005598017.tif 000025
【図２５】
0005598017.tif 000026
【図２６】
0005598017.tif 000027
【図２７】
0005598017.tif 000028
【図２８】
0005598017.tif 000029