JP2010044552A - リクエスト処理方法及び計算機システム - Google Patents

Abstract

【課題】冗長化されたリクエストのセッションが重複する場合であっても有効なセッション管理技術を提案する。
【解決手段】クライアントから送信されたリクエストを処理する複数のアプリケーションサーバと、リクエストを受信し、アプリケーションサーバに送信するプロキシ装置と、リクエストを管理するセッション管理装置とを含む計算機システムで、プロキシ装置は、受信したリクエストを冗長化して各アプリケーションサーバに送信し、各アプリケーションサーバは、リクエストの処理結果をプロキシ装置に送信し、アプリケーションサーバの識別子及びリクエストの識別子を含むセッション情報をセッション管理装置に通知し、プロキシ装置は、クライアントに応答する処理結果を決定し、決定された処理結果を送信したアプリケーションサーバの識別子及びリクエストの識別子をセッション管理装置に通知する。
【選択図】図６

Description

本発明は、受信したリクエストを冗長化して複数の計算機で実行する技術に関する。

近年、インターネット技術の成熟により、業務システムのＷｅｂアプリケーション化が広く実施されるようになった。Ｗｅｂアプリケーションによって実現されたユーザアプリケーション（以下、「ユーザＡＰ」）の実行基盤を提供するＷｅｂアプリケーションサーバ（以下、「ＡＰサーバ」）には、高い性能と信頼性が求められている。

現在、システムの性能を向上させるための技術として、負荷分散機を利用したシステム構築方法が提案されている。負荷分散機を利用したシステムでは、同一アプリケーションを実行可能な複数のＡＰサーバが配置され、負荷分散機を介して処理要求を受け付ける。

負荷分散機は、負荷状態に基づいて要求を処理させるＡＰサーバを選択する。特定のＡＰサーバに負荷が集中することを回避することによって、システムの応答性能を向上させる。

負荷分散機は、通常、後段に配置されたＡＰサーバの障害情報を監視し、障害が発生したＡＰサーバを回避してＡＰサーバを選択する。このようなホットスタンバイ方式による冗長化によってサービスの可用性を高めることができる。

ただし、ホットスタンバイ方式の冗長化では、リクエストを処理中のＡＰサーバに障害が発生すると、処理中だったリクエストはエラー又は無応答などになってしまう。従来の負荷分散機では、発生したエラーを回復することはできなかった。

特許文献１には、この問題を解決するために、負荷分散機の後段に配置したサーバを複数台からなる組として配置し、負荷分散機で受け付けた一つのリクエストを冗長化し、複数のサーバで同時並行に処理する技術が開示されている。

特許文献１に開示された技術では、リクエストを並行処理させる場合に、まず、各サーバに「仮実行」としてリクエスト処理を実行させる。最初に負荷分散機に「仮実行」のレスポンスが到達したサーバが「本実行」を実施し、最終的に応答する。他のサーバは「実行キャンセル」を実施する。「仮実行」「本実行」「実行キャンセル」の一連の技術は、一般にトランザクション処理と呼ばれ、処理開始から終了まで、システム内での一貫性を保つためにデータベースサーバなどに実装されている。

特許文献１に開示された技術では、負荷分散機の後段に配置されたサーバの処理が冗長化され、一台のサーバで障害が発生した場合も、別のサーバが同じリクエストに対するレスポンス処理を実行しているため、システムとしては処理を継続することができる。このようにして、システム内部におけるサーバの障害発生をシステム外部に影響させない、安定した応答性能を備えるシステムを実現可能になる。

さらに、冗長化構成を実現するための技術についても触れておくと、近年、サーバ装置の高性能化にともなって、仮想計算機技術の発展がめざましい。同一の物理計算機上で複数の仮想計算機を動作させることが可能になっている。

ハイパーバイザ型と呼ばれる仮想計算機では、仮想計算機を動作させるためのＯＳ（ホストＯＳ）を必要とせずに、物理計算機のリソース層を共有するための機能を提供し、複数の異なるＯＳを並行して動作させることが可能である。

冗長化構成システムを実現する場合において、複数の仮想計算機を用いる方法は、複数の物理計算機を用いる方法と比較して、管理運用コスト、省スペース化、消費電力の削減など、コスト面において優れている。
特開２００４−０３０２０４号公報

Ｗｅｂアプリケーションによる業務システムでは、複数のリクエスト及びレスポンスの流れによって一つの業務処理を実行し、画面遷移を含むアプリケーションを実現するためにセッション情報をサーバ上で保持する仕組みが必要となる。セッション情報をサーバ上で保持する仕組みとして、一般にスティッキー機能が用いられる。

スティッキー機能とは、負荷分散機がセッション情報を解析し、あるセッションＩＤが送信された場合の処理サーバを選択する場合に、過去に当該セッションＩＤを処理したサーバの記録を検索し、常に同じサーバを選択する。

しかし、負荷分散機は、スティッキー機能を用いると、負荷分散機能が発揮されず、システム全体での最適性能を実現できなくなる。

また、セッションを必要とするリクエストを処理することが可能なサーバが一意に固定されると、リクエストとサーバ間の依存性が高くなる。その結果、一台のサーバマシンに障害が発生した場合のシステムの継続性が保証されない。このことは、特許文献１に開示された技術であっても同様である。

回避方法としては、共有の外部データベース装置などを用いたセッション管理方法が知られている。セッション情報は、リクエストを処理するサーバとは異なる外部のデータベース上に記録され、すべてのサーバによって共有される。

セッション情報を外部データベースで管理する方法は、性能面でスティッキー機能に劣る。しかし、一般に性能については、ハードウェア装置の高性能化によって、低コストで実現が可能になる。高信頼性を要求される場合には、セッションをサーバ間で平等に共有できることが望ましい。

ここで、リクエストを冗長化した場合に発生するセッション衝突問題について説明する。通常、セッション情報は、システム内部の識別子（ＩＤ）で一意に管理されるため、同一のセッションＩＤを有するリクエストが並行して処理されることはない。そのため、同一のセッションＩＤに対して、複数のセッション登録要求が発生することはない。

しかしながら、リクエストを冗長化すると、クライアントは「同じリクエストのセッション情報」を複数のＡＰサーバから登録され、参照可能となっている場合がある。複数のセッション情報を登録され、各セッション情報の内容が異なっている場合には、どの情報を参照すべきか適切に選択しなければならない。選択を誤った場合には、システム内で矛盾が発生するおそれがある。このような問題は「セッション衝突の問題」と呼ばれる。

セッション衝突の問題は、「同一のユーザＡＰが同一のリクエストを受信した場合に、同一のセッション情報が生成される保証がない」ことが原因となる。典型的な例として、福引システムについて説明する。

福引システムでは、アプリケーションによって生成される乱数によって、「あたり」又は「はずれ」を抽選する。したがって、複数のＡＰサーバ上で同じリクエストを処理しても、すべての処理結果が同じになる保証はない。「あたり」の場合と「はずれ」の場合、一般にセッション情報は異なったものが生成される可能性が高い。

また、他の例として、締め切り時刻の判定処理を含んだチケット予約システムについて説明する。チケット予約システムの締め切り時刻の判定処理で、締め切り時刻の評価対象として「ＡＰサーバ装置の現在時刻」を使用していると、判定処理が参照する時刻が冗長化された各リクエストの処理で完全に同一になることは保証されない。その結果、「締め切り済みか否か」の判定結果は処理したＡＰサーバによって分かれ、各ＡＰサーバの生成するセッション情報が異なったものになる可能性がある。

特許文献１に開示された技術では、リクエストを冗長化した際に、スティッキー機能が実現可能である。セッション管理への適用を考慮したものであるが、スティッキー機能を利用したセッション管理では、セッション衝突の問題を解決することはできない。

具体的には、スティッキー機能の実現方法として、「実行キャンセル」を実施する際に、セッション情報を消去せずにサーバ上に残す。そして、再度当該セッション情報を必要とするリクエストを受け付けた場合に、同じサーバの組にリクエストを実施することによって、セッション情報を再利用する。この場合、生成されたセッション情報の内容がサーバごとに異なっていれば、サーバのペアで異なるセッション情報が管理されることになるため、システム内で矛盾が生じてしまうおそれがある。

以上より、ＡＰサーバシステムにおいてリクエスト冗長化を実現するためには、セッション衝突問題を解決可能なセッション管理方法が必要となる。本発明は、ＡＰサーバシステムにおいて、セッション衝突問題が解決されたリクエスト冗長化システムを実現することを目的とする。

なお、本発明は、技術の進歩によって計算機の処理能力がさらに向上し、コストも低減されることを前提として、「少ない計算機資源でどれだけ性能を向上させるか」という視点だけでなく、「余剰した計算機資源を活用することによって、処理性能の向上及び信頼性の向上を図る」といった視点で構築されたシステムを提案する。

本発明の一形態では、業務処理を要求するリクエストを送信するクライアントと、前記リクエストを処理する複数のアプリケーションサーバと、前記リクエストを受信し、前記アプリケーションサーバに送信するプロキシ装置と、前記リクエストを管理するセッション管理装置とを含む計算機システムにおいて、前記リクエストを処理する方法であって、前記プロキシ装置は、第１インタフェース、前記第１インタフェースに接続される第１プロセッサ、及び前記第１プロセッサに接続される第１メモリを備え、前記アプリケーションサーバは、第２インタフェース、前記第２インタフェースに接続される第２プロセッサ、及び前記第２プロセッサに接続される第２メモリを備え、前記プロキシ装置は、前記クライアントから送信されたリクエストを冗長化し、前記冗長化されたリクエストを各アプリケーションサーバに送信し、前記各アプリケーションサーバは、前記冗長化されたリクエストの処理結果を前記プロキシ装置に送信し、前記各アプリケーションサーバは、前記アプリケーションサーバの識別子及び前記冗長化されたリクエストの識別子を含むセッション情報を前記セッション管理装置に通知し、前記プロキシ装置は、前記冗長化されたリクエストの処理結果を受信すると、前記クライアントに応答する処理結果を決定し、前記プロキシ装置は、前記決定された処理結果を送信したアプリケーションサーバの識別子及び前記クライアントから送信されたリクエストの識別子を前記セッション管理装置に通知する。

本発明の代表的な一形態によれば、クライアントからのリクエストを冗長化して、各アプリケーションサーバで処理する場合に発生するセッションの衝突問題を解決することができる。

本発明では、リクエストを冗長化して処理するため、処理対象のリクエストに更新処理を含む場合には、二重に更新処理が実行されることによって矛盾が発生する可能性がある。本発明の実施の形態を具体的に説明する前に、まず、この問題について説明する。

一般的に、ＡＰサーバシステムでは、リクエストを処理する過程において、データベースサーバなど、ＡＰサーバの外部にあるシステムにアクセスして、情報を取得したり、外部システムの内容を更新したりする処理を含んでいる。ここでは、外部システムに対するアクセスとして、値を参照するアクセスを「参照系アクセス」、値を更新するアクセスを「更新系アクセス」と定義する。

リクエストを冗長化すると、元々一つのリクエストから、複数の外部アクセスが実行される。各リクエストがすべて参照系アクセスの場合には、システム内で矛盾が発生することはない。しかし、更新系アクセスの場合には、リクエストが冗長化されていない場合には発生するはずのない更新要求が発生するため、外部システムのデータが不正に更新されてしまう「更新系アクセスによる矛盾問題」が生じるおそれがある。

更新系アクセスによる矛盾問題の一例として、インターネットショッピングによる在庫管理システムについて説明する。ＡＰサーバ２０３の外部にあるデータベースシステムには、商品の在庫量が記憶されているものとする。ユーザＡＰ２１６には、商品が購入されたことを通知するリクエストを受信すると、商品の購入処理を実行し、在庫数を１つ減らす処理が記述されている。

在庫管理システムに在庫数を１減らすリクエストが入力されると、リクエストが冗長化されていない場合には、データベースサーバの在庫数は１減った状態となる。しかし、リクエストを２つに冗長化した場合には、並行して処理されている２つのユーザＡＰそれぞれから、「在庫量を１減らす」要求がデータベースサーバに送信される。このとき、データベースサーバの在庫数は２減らされてしまい、期待されていた結果と異なる結果になってしまう。このように、外部システムに更新系のアクセスが実行されるユーザＡＰでは、リクエストを冗長化することによって、本来期待していた結果と異なる結果となってしまう可能性がある。

特許文献１に開示された技術では、「仮実行」「本実行」「実行キャンセル」によるトランザクション処理をサーバに実装することで「更新系アクセスによる矛盾問題」を解決しようとしている。

ＡＰサーバは、ＡＰサーバ内部で実行されるＷｅｂアプリケーション上でトランザクション処理を実現するための技術として、ＪＴＡ（Ｊａｖａ Ｔｒａｎｓａｃｔｉｏｎ ＡＰＩ、「Ｊａｖａ」は登録商標、以下同じ）などの機能を実装している。しかし、ＡＰサーバ自身へのリクエストに対してトランザクション処理を実施するような機能は、一般のＡＰサーバに備えられておらず、当該機能の有無はＷｅｂアプリケーションの設計に依存する。

また、ＡＰサーバへの入力となるＵＲＬ文字列の情報は、一般に、ＵＲＬ文字列自体が更新系アクセスの有無を表すものではないため、トランザクション処理が必要か否かを判定する手段は無い。したがって、特許文献１の手法をＡＰサーバシステムに適用する場合、ＵＲＬでトランザクション処理が必要か否かを判定可能な場合を除いて、すべてのリクエストに対してトランザクション処理を実行する必要がある。トランザクション処理は、排他処理、及び処理開始から処理完了までの一連のトランザクション処理内容を記録する大量のバッファ制御が必要になるなど、一般に負荷の大きい処理である。

一方、ＡＰサーバシステム固有の特性として、ＡＰサーバシステムにおける「参照系アクセス」「更新系アクセス」の発生頻度に着目すると、大半の処理が「参照系アクセス」のみで成り立っていることが知られている。この発生頻度の比率は９９：１とも３００：１ともいわれている。

したがって、特許文献１に開示された技術をＡＰサーバシステムに適用するには、性能面のデメリットが大きい。

本発明では、更新系アクセスによる矛盾問題の解決手段として、「更新系リクエストが発生するかどうか」に応じて、リクエスト冗長化の多重度を決定する処理をインテリジェントプロキシ処理部又はＡＰサーバに追加する。具体的には、更新系アクセスによる矛盾問題が発生する可能性が生じたタイミングで、冗長化されたリクエストの枝刈りを実施する。詳細な処理手順については、図５にて後述する。

以上のように処理することによって、外部システムとの連携処理があるＡＰサーバシステムにおいて、冗長化されたリクエストが発生した場合に、更新系アクセスによる二重更新などの矛盾問題を回避することができる。

以下、前述した「セッション衝突問題」及び「更新系アクセスによる矛盾問題」を解決する本発明の実施の形態について図面を用いて説明する。

（第１の実施の形態）
図１は、本発明の第１の実施の形態の計算機システムの物理構成図である。

本発明の第１の実施の形態の計算機システムは、クライアント２０１、インテリジェントプロキシ装置２０２、ＡＰサーバ装置３３０、セッション管理装置３４０、及びデータベース（ＤＢ）サーバ装置（外部サーバ）２０５を含む。

クライアント２０１は、ネットワークを介してインテリジェントプロキシ装置２０２に接続する。また、ＡＰサーバ装置３３０、セッション管理装置３４０、及びＤＢサーバ装置２０５は、ネットワークを介してインテリジェントプロキシ装置２０２に接続する。クライアント２０１は、インテリジェントプロキシ装置２０２を介して、ＡＰサーバ装置３３０、セッション管理装置３４０、及びＤＢサーバ装置２０５にアクセスする。

クライアント２０１は、利用者からの業務処理の実行要求を受け付け、インテリジェントプロキシ装置２０２を介して、ＡＰサーバ装置３３０にリクエストを送信する。本発明の第１の実施の形態では、クライアント２０１の数は、単数でも複数でもよく、二つのクライアント２０１が図１に示されている。

インテリジェントプロキシ装置２０２は、いわゆる負荷分散機であって、クライアント２０１から送信されたリクエストをＡＰサーバ装置３３０に振り分ける。インテリジェントプロキシ装置２０２は、受信したリクエストを冗長化し、それぞれ異なるＡＰサーバ装置３３０に送信する。

インテリジェントプロキシ装置２０２は、ＣＰＵ３２１、主記憶３２２、ネットワークインタフェースカード（ＮＩＣ）３２３Ａ、及びＮＩＣ３２３Ｂを備える。

ＣＰＵ３２１は、主記憶３２２に記憶されたプログラムを実行し、各種処理を実行する。主記憶３２２は、ＣＰＵ３２１によって実行されるプログラム及び処理に必要なデータを記憶する。例えば、受信したリクエストをＡＰサーバ装置３３０に振り分けるインテリジェントプロキシ処理部２１１が記憶される。インテリジェントプロキシ処理部２１１は、クライアント２０１から送信されたリクエストを冗長化し、冗長化されたリクエストを処理するＡＰサーバ装置３３０を選択し、各ＡＰサーバ装置３３０に振り分ける。インテリジェントプロキシ処理部２１１の詳細については後述する。

ＮＩＣ３２３Ａは、ネットワークを介してクライアント２０１に接続される。ＮＩＣ３２３Ｂは、ネットワークを介して、ＡＰサーバ装置３３０、セッション管理装置３４０、及びＤＢサーバ装置２０５に接続される。

ＡＰサーバ装置３３０は、クライアント２０１から送信されたリクエストを処理し、処理結果をクライアント２０１に送信する。ＡＰサーバ装置３３０は、計算機システムに複数備えられる。各ＡＰサーバ装置３３０は、インテリジェントプロキシ装置２０２によって冗長化されたリクエストをそれぞれ処理する。なお、各ＡＰサーバ装置に共通する内容について説明する場合には、符号を３３０とし、個別のＡＰサーバ装置を区別して説明する場合には、符号を「３３０Ａ」「３３０Ｂ」などとする。また、ＡＰサーバ装置を構成するプログラムなどの要素についても同様に扱う。

ＡＰサーバ装置３３０は、ＣＰＵ３３１、主記憶３３２、及びＮＩＣ３３３を備える。ＣＰＵ３３１は、主記憶３３２に記憶されたプログラムを実行し、各種処理を実行する。主記憶３３２は、ＣＰＵ３３１によって実行されるプログラム及び処理に必要なデータを記憶する。例えば、クライアント２０１から送信されたリクエストを処理するＡＰサーバ２０３が記憶される。ＮＩＣ３３３は、ネットワークに接続される。

セッション管理装置３４０は、クライアント２０１とＡＰサーバ装置３３０との間のセッションを管理する。セッション管理装置３４０は、ＣＰＵ３４１、主記憶３４２、ＮＩＣ３４３、及び補助記憶装置３４４を備える。

ＣＰＵ３４１は、主記憶３４２に記憶されたプログラムを実行し、各種処理を実行する。主記憶３４２は、ＣＰＵ３４１によって実行されるプログラム及び処理に必要なデータを記憶する。具体的には、セッションを管理するセッション管理処理部２０４が記憶される。ＮＩＣ３４３は、ネットワークに接続される。補助記憶装置３４４は、不揮発性記憶媒体によって、セッション情報を記憶する。

ＤＢサーバ装置２０５は、ＡＰサーバ装置３３０が業務を処理するために使用するデータなどが格納される。ＤＢサーバ装置２０５は、ＣＰＵ３５１、主記憶３５２、ＮＩＣ３５３、及び補助記憶装置３５４を備える。

ＣＰＵ３５１は、主記憶３５２に記憶されたプログラムを実行し、各種処理を実行する。主記憶３５２は、ＣＰＵ３５１によって実行されるプログラム及び処理に必要なデータを記憶する。具体的には、データを管理するデータベース管理システム（ＤＢＭＳ）３５５が記憶される。ＮＩＣ３５３は、ネットワークに接続される。補助記憶装置３５４は、業務処理に利用されるデータが格納される。なお、図１には、外部サーバとしてＤＢサーバ装置２０５が計算機システムに含まれているが、ＤＢサーバ以外のサーバであってもよい。

ここで、セッション衝突の問題を回避するために、インテリジェントプロキシ処理部２１１とセッション管理処理部２０４が相互に通信し、インテリジェントプロキシ処理部２１１がセッション管理処理部２０４におけるセッションの登録を制御する手順の概要について説明する。

セッション情報は、セッション管理処理部２０４のバッファ上に記録され、セッション衝突が発生しないように管理される。インテリジェントプロキシ処理部２１１が最終的にクライアント２０１に送信するリクエストを決定した時点で、当該リクエストに対応したセッション情報をセッション記憶データベースに記録する。

図２は、本発明の第１の実施の形態のセッション管理の概要を説明する図であって、セッション情報を登録する手順を説明する図である。

クライアント２０１は、まず、インテリジェントプロキシ装置２０２に業務処理の要求を含むリクエストを送信する。インテリジェントプロキシ装置２０２は、クライアント２０１から送信されたリクエストを受信すると、インテリジェントプロキシ処理部２１１によって、受信したリクエストを冗長化する。

また、インテリジェントプロキシ処理部２１１には、リクエスト冗長化制御部２１２及び結果解析処理部２１４が含まれている。リクエスト冗長化制御部２１２は、受信したリクエストを冗長化し、冗長化されたリクエストに共通のリクエストＩＤを付与する。共通のリクエストＩＤを付与することによって、複数のリクエストが並行して処理された場合にも、冗長化する前のリクエストが同一であるか否かを判定することができる。複数のリクエストの処理結果を解析する結果解析処理部２１４については後述する。

ＡＰサーバ２０３は、冗長化されたリクエストを処理する。図２に示すように、インテリジェントプロキシ処理部２１１によって冗長化されたリクエストがＡＰサーバ２０３Ａ及びＡＰサーバ２０３Ｂによって処理される。

ＡＰサーバ２０３Ａは、Ｗｅｂサーバ２１５Ａ、ユーザＡＰ２１６Ａ、セッション獲得処理部２１７Ａ、及びセッション登録処理部２１８Ａを含む。ＡＰサーバ２０３Ｂについても同様である。

Ｗｅｂサーバ２１５Ａは、クライアント２０１が送信する業務処理の要求を受け付けるためのインタフェースを提供し、クライアント２０１から送信されたリクエストを受信する。ユーザＡＰ２１６Ａは、Ｗｅｂサーバ２１５Ａが受け付けた要求を処理する。セッション獲得処理部２１７Ａは、セッション管理処理部２０４に登録されたセッションを取得する。セッション登録処理部２１８Ａは、クライアント２０１とＡＰサーバ２０３Ａとの間で確立されたセッションをセッション管理処理部２０４に登録する。

また、ＡＰサーバ２０３Ａは、セッション登録処理部２１８Ａによって、セッション管理処理部２０４にセッションの登録を要求する。セッション登録処理部２１８Ａは、セッション登録処理を実行する場合に、セッション情報に加え、リクエストを処理したＡＰサーバ２０３のサーバＩＤ、及び当該リクエストのリクエストＩＤをセッション管理処理部２０４に通知する。このように、ＡＰサーバ２０３のアドレス、リクエストを処理したプロセスＩＤ及びスレッドＩＤなどの情報に基づいて、リクエストを処理したサーバＩＤを一意に特定できるようにする。なお、セッション登録処理部２１８Ｂについても同様である。

セッション管理処理部２０４は、バッファテーブル２２４及びセッション記憶データベース２２５を含む。

バッファテーブル２２４は、セッション情報を一時的に格納する。バッファテーブル２２４は、サーバＩＤ２２４１、リクエストＩＤ２２４２、セッションＩＤ２２４３、及びセッション内容２２４４を含む。

サーバＩＤ２２４１は、ＡＰサーバ２０３の識別子である。リクエストＩＤ２２４２は、クライアント２０１から送信されたリクエストの識別子であって、一意の番号又は文字列である。

セッションＩＤ２２４３は、クライアント２０１とユーザＡＰ２１６とが、リクエスト及びレスポンスを送受信することによって連続して状態が遷移する場合、一連の流れを特定するための識別子である。セッション内容２２４４は、セッションＩＤ２２４３によって識別されるセッションの状態を示す情報が格納される。以降、セッション情報とは、セッションＩＤとセッション内容の組み合わせのことを指す。

セッション記憶データベース２２５は、セッション情報を格納する。セッション記憶データベース２２５は、セッションＩＤ２２５１及びセッション内容２２５２を含む。セッション記憶データベース２２５には、リクエストが冗長化された場合にインテリジェントプロキシ処理部２１１によって選択され、クライアント２０１に実際にレスポンスが送信されたセッションの内容が記録される。

セッション管理処理部２０４は、セッション登録要求を受け付けると、まず、バッファテーブル２２４にセッション登録要求に含まれる情報を記録する。この際、冗長化されたリクエストであっても、サーバＩＤとリクエストＩＤの組み合わせによって識別可能であるため、バッファテーブル２２４においてセッションの衝突は発生しない。

図３は、本発明の第１の実施の形態のセッション管理の概要を説明する図であって、リクエストの処理結果をクライアントに送信する手順を説明する図である。

結果解析処理部２１４は、ＡＰサーバ２０３からリクエストに対する処理結果を受信すると、最終的にクライアントに応答するレスポンスを確定させる。結果解析処理部２１４は、最終的にクライアントに応答するレスポンスが確定すると、当該レスポンスを応答したＡＰサーバ２０３に対応するセッション情報をセッション記憶データベース２２５に登録する処理を開始する。インテリジェントプロキシ処理部２１１は、セッション管理処理部２０４と通信し、セッション管理処理部２０４のコミット処理部２１９に、最終的にレスポンスとして採用するリクエストを処理したＡＰサーバ２０３とリクエスト内容とを識別する識別子を通知する。具体的な処理の内容については、図４を参照しながら後述する。

コミット処理部２１９は、セッション情報のセッション記憶データベース２２５に対する登録要求を受信すると、受信した識別子に基づいて、バッファテーブル２２４のレコードを検索し、発見したデータをセッション記憶データベース２２５に登録する。さらに、バッファテーブル２２４に記録されている同一のリクエストＩＤを有するレコードをすべて削除する。具体的な処理の内容については後述する。

図４は、本発明の第１の実施の形態のクライアントから受け付けた処理要求に応答する手順を示すフローチャートである。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、インテリジェントプロキシ処理部２１１に含まれる結果解析処理部２１４を実行し、ＡＰサーバ２０３のＷｅｂサーバ２１５から正常なレスポンスを受信したことを確認すると、受信したレスポンスに含まれる「サーバＩＤ」及び「リクエストＩＤ」を取得する（Ｓ４０１）。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、別のＡＰサーバ２０３からのレスポンスを受信した場合に本処理を実行しないように排他処理を開始する（Ｓ４０２）。

さらに、インテリジェントプロキシ装置２０２のＣＰＵ３２１は、取得されたリクエストＩＤに対応する処理が実行済みか否かを判定する（Ｓ４０３）。実行済みの場合には（Ｓ４０３の結果が「Ｙｅｓ」）、当該リクエストＩＤに対応する処理結果を応答するための処理が実行済みであるため、Ｓ４０２の処理で実行された排他処理を解放し（Ｓ４０８）、本処理を終了する。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、処理が実行されていない場合には（Ｓ４０３の結果が「Ｎｏ」）、セッション管理装置３４０のセッション管理処理部２０４に含まれるコミット処理部２１９に、セッションの選択を確定するコミット要求を送信し、処理が完了するまで待機する（Ｓ４０４）。コミット要求には、Ｓ４０１の処理で取得されたサーバＩＤ及びリクエストＩＤが含まれる。コミット処理部２１９によって実行される処理については後述する。なお、この場合には、Ｓ４０１の処理で受信したレスポンスが、当該リクエストＩＤについて、ＡＰサーバ２０３から最初に応答されたレスポンスとなる。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、Ｓ４０１の処理で取得されたリクエストＩＤに対応する処理が完了すると、処理の実行が完了したことを主記憶３２２に記憶する（Ｓ４０５）。さらに、Ｓ４０２の処理で実行された排他処理を解放する（Ｓ４０６）。最後に、クライアント２０１にレスポンスを送信し（Ｓ４０７）、本処理を終了する。

ここで、クライアント２０１に送信されるレスポンスが確定し、対応するセッション情報をセッション管理処理部２０４によって登録する手順について説明する。

セッション管理装置３４０のＣＰＵ３４１は、まず、結果解析処理部２１４によって送信されたコミット要求を受信する。

セッション管理装置３４０のＣＰＵ３４１は、コミット処理部２１９によって、受信したコミット要求に含まれるサーバＩＤ及びリクエストＩＤに基づいてバッファテーブル２２４を検索し、該当するレコードを取得する。

セッション管理装置３４０のＣＰＵ３４１は、受信されたレコードに含まれるセッションＩＤ及びセッション内容をセッション記憶データベース２２５に登録する。

さらに、セッション管理装置３４０のＣＰＵ３４１は、受信したリクエストＩＤと一致するレコードをバッファテーブル２２４から検索し、該当するレコードを削除する。

最後に、セッション管理装置３４０のＣＰＵ３４１は、インテリジェントプロキシ処理部２１１の結果解析処理部２１４に処理完了を通知し、本処理を終了する。

以上、説明した手順によって、リクエストしたクライアントが受信する情報と、システム内部で管理されるセッション情報の内容が矛盾することを防ぐことができ、セッション衝突の問題を解決することができる。

さらに、更新系アクセスによる矛盾問題の解決手段としては、前述のように、「更新系リクエストが発生するかどうか」に応じて、リクエスト冗長化の多重度を決定する処理をインテリジェントプロキシ処理部２１１又はＡＰサーバ２０３に追加する。例えば、更新系アクセスによる矛盾問題が発生する可能性が生じたタイミングで、冗長化されたリクエストの枝刈りを実施する。以下、処理の概要を説明する。

図５は、本発明の第１の実施の形態の更新系アクセスを含むリクエストの多重度を単一にする手順を示すフローチャートである。

本処理では、更新系アクセスを実行する可能性があるリクエストを１つに絞りこみ、処理されたレスポンスのみをクライアントに送信することによって、更新系アクセスによる矛盾問題の発生を防止する。したがって、各リクエストについて、「仮実行」「本実行」「実行キャンセル」の処理は必要ない。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、クライアント２０１から送信されたリクエストを受信すると（Ｓ６０１）、「更新系アクセスが発生するか否か」を判定可能なタイミングまで処理を継続する（Ｓ６０２）。「更新系アクセスが発生するか否か」を判定する基準としては、例えば、所定のモジュールを実行した場合、又は、実際に外部にアクセスしようとした場合などである。なお、更新系アクセスが発生するか否かを確実に判定する必要はなく、更新系アクセスが発生する可能性があるか否かを判定できればよい。また、リクエストはＡＰサーバ２０３で処理されるが、ＡＰサーバ２０３とインテリジェントプロキシ装置２０２との間では、リクエストとレスポンスとが送受信されている。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、更新系アクセスが発生しない場合には（Ｓ６０３の結果が「Ｎｏ」）、冗長化されたリクエストについてそのまま処理を継続する（Ｓ６０８）。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、更新系アクセスが発生する可能性がある場合には（Ｓ６０３の結果が「Ｙｅｓ」）、リクエストＩＤが一致する他のレスポンス処理が実施済みか否かを判定する（Ｓ６０４）。リクエストＩＤが一致する他のレスポンス処理が実施済みの場合には（Ｓ６０４の結果が「Ｙｅｓ」）、処理対象となっている冗長化されたリクエストの処理を中止する（Ｓ６０５）。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、リクエストＩＤが一致する他のレスポンス処理が実施済みでない場合には（Ｓ６０４の結果が「Ｎｏ」）、リクエストＩＤが一致する他の冗長化されたリクエストの処理を中止させる（Ｓ６０６）。さらに、処理対象となっているリクエスト処理が完了するまで待機し、処理結果をクライアント２０１に応答する（Ｓ６０７）。

なお、リクエストの多重度が１になった場合には、サーバ障害を検知する機能と自動リトライ機能とを備えた負荷分散機と同等とすることができる。そのため、参照系アクセスのみの場合に実現可能な、障害発生時に影響を受けない応答性能を実現することはできなくなる。ただし、本発明が主に適用されるＷｅｂアプリケーションシステムでは、クライアントから送信されるリクエストの大半が「参照系アクセス」であるため、システム全体としての応答性能は十分に確保される。

図６は、本発明の第１の実施の形態のシステム構成を説明する図である。

本発明の第１の実施の形態では、リクエストＵＲＬによって、外部システムへの更新系アクセスが発生するか否かを判定可能である場合に適用される。

インテリジェントプロキシ装置２０２には、図２で説明した構成に加え、サーバアドレステーブル２２１、更新系アクセス有無定義テーブル２２２、及びリクエストＩＤ状態テーブル２２３が含まれる。

サーバアドレステーブル２２１は、クライアント２０１から送信されたリクエストを処理するＡＰサーバ２０３のアドレスの一覧を格納する。例えば、ＩＰ（インターネットプロトコル）アドレスとポート番号の組み合わせなどが用いられる。図６では、サーバアドレスのみが記載されているが、さらに、「稼動中」又は「故障中」などのサーバの稼動状態などの情報も格納される。

インテリジェントプロキシ装置２０２は、リクエストを送信するＡＰサーバ２０３を選択する場合に、サーバアドレステーブル２２１を参照する。具体的には、ラウンドロビン法によってサーバを選択する。また、インテリジェントプロキシ装置２０２には、サーバアドレスの故障情報を記録する手段、故障中のサーバがある場合に故障中のサーバアドレスを参照させない手段、及びサーバアドレスを追加及び削除する手段などが備えられる。

更新系アクセス有無定義テーブル２２２は、クライアント２０１からリクエストされるＵＲＬに対し、外部システムへの更新系アクセスが発生するか否かを示す情報を格納する。

リクエストＩＤ状態テーブル２２３は、クライアント２０１から受信したリクエストの状態が、リクエストＩＤごとに記録される。リクエストの状態は、例えば、「未使用」「処理中」「完了」の３つのステータスである。本発明の第１の実施の形態では、クライアント２０１からリクエストを受信するたびにリクエストＩＤを生成するのではなく、あらかじめ一意のリクエストＩＤを生成しておく。リクエストを受信すると、生成済みのリクエストＩＤを受信したリクエストに対応付ける。「未使用」はリクエストが対応付けられていない状態のリクエストＩＤである。

インテリジェントプロキシ処理部２１１には、図２に示した構成の他に、リトライ処理部２１３が含まれる。リトライ処理部２１３は、ＡＰサーバ２０３に障害が発生した場合に別のＡＰサーバ２０３にリクエストを再送する。具体的な処理については、後述する。

ＡＰサーバ２０３Ａ及び２０３Ｂには、同一のユーザＡＰ２１６Ａ及び２１６Ｂが配置されている。インテリジェントプロキシ装置２０２からＡＰサーバ２０３Ａ及び２０３Ｂに同時にリクエストが送信された場合、ユーザＡＰ２１６Ａ及び２１６Ｂはそれぞれ独立してリクエストを処理する。なお、図６では、２台のＡＰサーバ２０３のみを示しているが、適用するシステムの規模としては、１０台以上から数百台規模のシステムを想定している。

バッファテーブル２２４及びセッション記憶ＤＢ２２５については、図２にて説明したとおりである。

図７は、本発明の第１の実施の形態のクライアントからのリクエストを処理する手順を示すシーケンス図である。

クライアント２０１は、利用者からの業務処理の要求を受け付け、インテリジェントプロキシ装置２０２にリクエストを送信する（Ｓ８０１）。

インテリジェントプロキシ装置２０２のリクエスト冗長化制御部２１２は、受信したリクエストをＡＰサーバ２０３に送信する（Ｓ８０２）。具体的には、まず、リクエストＩＤ状態テーブル２２３を参照し、「未使用」のリクエストＩＤを取得する。さらに、取得されたリクエストＩＤに対応するレコードの状態を「未使用」から「処理中」に変更する。

次に、リクエスト冗長化制御部２１２は、図５のフローチャートに示した処理を実行することによってリクエストを冗長化する多重度を決定する。すなわち、参照系アクセスのみの場合には、複数のＡＰサーバ２０３が冗長化されたリクエストを処理する。更新系アクセスを含む場合には、リクエストを冗長化しない、又は、冗長化されたリクエストを単一化する。

まず、リクエスト冗長化制御部２１２は、更新系アクセス有無定義テーブル２２２を参照し、クライアント２０１から受信したリクエストに更新系アクセスが発生する可能性があるか否かを判定する（図５のＳ６０３）。具体的には、リクエストに対応するＵＲＬに基づいて、更新系アクセス有無定義テーブル２２２を検索し、更新の有無を示す情報を取得する。

リクエスト冗長化制御部２１２は、更新系アクセスが発生する可能性がある場合には、リクエスト冗長化の多重度を１に設定し、リクエストを冗長化しない。すでに、リクエストが冗長化されている場合には、１つのリクエスト以外は処理を中止させる。

リクエスト冗長化制御部２１２は、更新系アクセスが発生しないリクエストの場合には、リクエストを２以上の多重度で冗長化する。多重度の決定方法は、固定値でもよいし、動的に変更させてもよい。動的に変更する方法については、本発明の第５の実施の形態にて後述する。

リクエスト冗長化制御部２１２は、多重度が決定されると、サーバアドレステーブル２２１を参照し、リクエストを送信するＡＰサーバ２０３のアドレスを取得する。ＡＰサーバ２０３の選択方法については、前述したように、例えば、ラウンドロビン方式で選択する。ＡＰサーバ２０３を選択する他の方法については、第３の実施の形態及び第４の実施の形態にて説明する。

リクエスト冗長化制御部２１２は、選択されたＡＰサーバ２０３に、並行してクライアント２０１から受信したリクエストを送信する。第１の実施の形態では、ＡＰサーバ２０３ＡとＡＰサーバ２０３Ｂ両方に対して、リクエストを送信する。また、送信されるリクエストには、リクエストＩＤが付加される。

ＡＰサーバ２０３Ａは、Ｗｅｂサーバ２１５Ａによって、リクエストの内容及びリクエストＩＤを受信する。さらに、ユーザＡＰ２１６Ａにリクエストを処理させる。ＡＰサーバ２０３Ｂでも同様に処理される（Ｓ８０３Ｂ〜Ｓ８０８Ｂ）。

ユーザＡＰ２１６Ａは、このとき、セッション獲得処理部２１７Ａによって、セッション管理処理部２０４のセッション記憶ＤＢ２２５からセッション情報を取得する（Ｓ８０３Ａ、Ｓ８０４）。

また、ユーザＡＰ２１６Ａは、リクエストを処理すると（Ｓ８０５Ａ）、セッション登録処理部２１８Ａによって、セッション管理処理部２０４にセッション情報を登録する。具体的には、バッファテーブル２２４にサーバＩＤ２２４１、リクエストＩＤ２２４２、セッションＩＤ２２４３、及びセッション内容２２４４を登録する処理をセッション管理処理部２０４に要求する（Ｓ８０６Ａ、Ｓ８０７Ａ）。ここで、サーバＩＤとは、リクエストを処理したＡＰサーバ２０３を一意に示す文字列で、例えば、サーバアドレスとＡＰサーバのプロセスＩＤ及びスレッドＩＤに基づいて生成された文字列である。サーバＩＤとリクエストＩＤとの組み合わせは、リクエストが冗長化された状態でも一意であるため、バッファテーブル２２４への登録において、セッションの衝突を生じさせない。

ユーザＡＰ２１６Ａは、リクエストの処理を完了すると、Ｗｅｂサーバ２１５Ａを介して、レスポンスを結果解析処理部２１４に送信する（Ｓ８０８Ａ）。

結果解析処理部２１４は、ＡＰサーバ２０３からレスポンスを受信すると、レスポンスの内容を解析し、解析結果に基づいてクライアント２０１に応答するレスポンスを特定する（Ｓ８０９）。また、結果解析処理部２１４は、ＡＰサーバ２０３からレスポンスを受信する際にリクエストを処理したＡＰサーバ２０３のサーバＩＤをさらに受信する。

具体的に説明すると、結果解析処理部２１４は、まず、レスポンスの内容を解析し、正常終了か異常終了かを判定する。この場合の異常終了とは、システム障害又は処理時間切れなどによるものであって、システムが正常にリクエストを処理した結果のエラー画面（例えば、リクエストされたファイルが見つからなかったエラーを表す画面）の表示などではない。結果解析処理部２１４は、それぞれのＡＰサーバ２０３からレスポンスを受信した場合に実行され、インテリジェントプロキシ装置２０２の内部で複数の処理が並行に実行される。

結果解析処理部２１４は、異常終了が検知された場合には、まず、障害情報をサーバアドレステーブル２２１に反映する。次に、リクエストＩＤ状態テーブル２２３を参照し、異常終了したリクエストＩＤのリクエストが「処理中」か否かを確認する。「処理中」の場合には、リトライ処理部２１３によってリトライ処理を依頼する。「完了」の場合には、レスポンスが既に応答されているので、そのまま処理を終了する。以降、障害が発生したＡＰサーバ２０３が復旧するまで、障害の発生したサーバを選択できないようにする。

リトライ処理部２１３は、サーバアドレステーブル２２１から次にリクエストを処理するＡＰサーバのアドレスを取得し、取得されたサーバアドレスに対してリクエストＩＤを付与したリクエストを送信する。これにより、リクエスト処理中は、常に一定の多重度が確保され、所定数のＡＰサーバ２０３で冗長化されたリクエストの処理が継続される。したがって、同時に複数のＡＰサーバで障害が発生した場合でも、安定した信頼性と継続性を実現することができる。なお、すべてのＡＰサーバで障害が発生した場合には、リトライ処理部２１３は処理の継続を断念し、処理対象のリクエストＩＤに対応するリクエストＩＤ状態テーブル２２３のレコードの状態に「完了」を記録し、クライアント２０１にエラーを通知する。

結果解析処理部２１４は、正常終了が検知された場合には、同じリクエストＩＤの処理に排他処理を実行する。排他処理の実行に成功すると、以降、同じリクエストＩＤを有し、並行して動作していた同じリクエストＩＤの結果解析処理は、排他処理が終了するまで休止状態となる。排他処理は、結果解析処理部２１４のみで実施され、他の処理部（例えばＡＰサーバ２０３Ｂなど）では、この間も並行して処理が継続される。

結果解析処理部２１４は、リクエストＩＤ状態テーブル２２３を参照し、処理対象のリクエストが「処理中」か否かを確認する。処理対象のリクエストが「完了」の場合には、既に当該リクエストＩＤに対応するリクエストのレスポンスがクライアント２０１に送信されているため、処理を継続する必要がない。結果解析処理部２１４は、排他を解放し、処理を終了する。

一方、結果解析処理部２１４は、リクエストＩＤのリクエストが「処理中」の場合、レスポンスを受信したＡＰサーバ２０３Ａの「サーバＩＤ」と「リクエストＩＤ」の情報をセッション管理処理部２０４のコミット処理部２１９にメッセージとして送信する（Ｓ８１０）。

コミット処理部２１９は、メッセージを受信すると、バッファテーブル２２４を参照し、リクエストＩＤが一致するレコードをすべて取得する。取得されたレコードからＡＰサーバ２０３Ａの「サーバＩＤ」と一致するレコードをセッション記憶データベース２２５に登録する（Ｓ８１１）。その後、バッファテーブル２２４に含まれるリクエストＩＤが一致するレコードをすべて削除する。以上の処理が完了すると、コミット処理部２１９は、結果解析処理部２１４に完了通知を送信する。

結果解析処理部２１４は、コミット処理部２１９から完了通知を受信すると、処理対象のリクエストＩＤに対応するリクエストＩＤ状態テーブル２２３のレコードの状態を「完了」に変更する。その後、排他を解放し、クライアント２０１にＡＰサーバ２０３Ａからのレスポンスを送信する（Ｓ８１２）。

以上の手順によって、セッション衝突の問題を解決することができる。

なお、セッション情報を参照しないユーザＡＰ２１６のみがＡＰサーバ２０３で動作するシステムであれば、一連のセッション管理処理部２０４への問い合わせを実行する処理は不要である。

本発明の第１の実施の形態では、結果解析処理部２１４の処理において、結果として、複数のＡＰサーバ２０３で並行処理されたレスポンスのうち、最も応答性能が高速であったレスポンスを採用する。この場合、冗長化の多重度が大きくなればなるほど、従来の負荷分散機における、「最も負荷の少ない、応答性能の良さそうなＡＰサーバにリクエストを転送する」場合に得られる最適な応答性能に近似する。

したがって、本発明の第１の実施の形態によれば、冗長化したリクエストを処理するサーバの選択方法として「ラウンドロビン法」といった単純な方法で、最も負荷の低いサーバを選択する負荷分散機を利用した場合と近似した処理性能を得ることができる。

本発明の第１の実施の形態では、セッション管理処理部２０４に負荷が集中するため、セッション管理処理部２０４の冗長性を高めた構成にしてもよい。

本発明の第１の実施の形態では、セッション管理処理部２０４がすべてのＡＰサーバに対して平等に処理を実行し、かつ、インテリジェントプロキシ処理部２１１にリトライ処理部２１３を備えているため、リクエストを処理するために、すべてのＡＰサーバの組み合わせが使用される可能性がある。したがって、すべてのＡＰサーバで障害が発生しない限り、リクエスト処理の実行を継続することができる。

本発明の第１の実施の形態によれば、リクエストを冗長化することによって、信頼性、可用性及び処理性能を向上させ、堅牢なＡＰサーバシステムを構築することができる。

さらに、本発明の第１の実施の形態によれば、余剰リソースとして存在し、稼働率の少ないサーバを活用することによって、システムの信頼性向上などに当該サーバを貢献させることができる。

また、本発明の第１の実施の形態によれば、クライアントから送信されるリクエスト及び当該リクエストを処理するサーバ間の依存度を低減させることを可能とし、例えば、ＡＰサーバ上で動作させるＷｅｂアプリケーションがセッション情報を必要とする場合であっても、セッション衝突問題を回避することができる。

また、本発明の第１の実施の形態によれば、外部システムとの連携処理があるＡＰサーバシステムにおいて、冗長化されたリクエストが発生した場合に、更新系アクセスによる二重更新などの矛盾問題を回避することができる。

また、本発明の第１の実施の形態によれば、Ｗｅｂサーバなどの参照系アクセスの多いシステムにおいて、トランザクション管理を実行することによって整合性を確保するシステムと比較して性能を向上させることができる。

（第２の実施の形態）
本発明の第２の実施の形態は、クライアント２０１のリクエストＵＲＬに基づいて外部システム９０４への更新系アクセス要求の有無を判定できない場合に適用される。第１の実施の形態のように、リクエストＵＲＬに基づいて更新系アクセス要求の有無を判定可能な場合は、あらかじめ意図してシステムを設計した場合に実現可能であって、通常のＡＰサーバシステムは第２の実施の形態に属する。なお、第１の実施の形態と共通する内容については適宜説明を省略する。

図８は、本発明の第２の実施の形態のシステム構成を説明する図である。

セッション制御の手順については、第１の実施の形態と同じであるため、説明を省略する。また、図８において、セッションを制御するための構成を一部省略する。

インテリジェントプロキシ装置２０２は、特権制御付リクエストＩＤ状態テーブル９２２を含む。特権制御付リクエストＩＤ状態テーブル９２２は、第１の実施の形態のリクエストＩＤ状態テーブル２２３を拡張したものである。具体的には、リクエストＩＤに対するリクエスト処理の現在の状態を「未使用」「処理中」「完了」に加えて、「特権中」の４種類のステータスによって表す。また、リクエストＩＤ単位で特権制御付リクエストＩＤ状態テーブル９２２に対するアクセスの排他処理を実施可能である。結果解析処理部９１４における排他処理についても、当該機能を利用して実装される。

また、インテリジェントプロキシ処理部２１１には、特権付与処理部９１９が含まれる。特権付与処理部９１９は、リクエスト冗長化制御部９１２及びリトライ処理部９１３によって実行される。

リクエスト冗長化制御部９１２は、第１の実施の形態のリクエスト冗長化制御部２１２とは異なり、リクエストＵＲＬの内容に関わらず、常にリクエストを２以上に冗長化して複数のサーバに並行して送信する。この際、冗長化されたリクエストの中で一つのリクエストを選択し、選択されたリクエストに対して特権付与処理部９１９が更新特権を付与する。

更新特権を付与するリクエストの選択方法についてはどのような方法を使ってもよく、ランダムであってもよいし、負荷の少ないＡＰサーバを選択してもよい。なお、第４の実施の形態にて、更新特権を付与するリクエストの選択方法について説明する。

Ｗｅｂサーバ９１５は、リクエスト冗長化制御部９１２によって冗長化されたリクエストを受信すると、受信したリクエストに更新特権が付与されているか否かを判定する。更新特権の有無を識別する情報は、例えば、ＨＴＴＰ（ハイパーテキスト転送プロトコル）のリクエストヘッダを拡張することによって付与する。

また、本発明の第２の実施の形態では、ＡＰサーバ２０３は、外部アクセス制御処理部９１７を備える。ＡＰサーバ２０３による外部システムへのアクセスは、すべて外部アクセス制御処理部９１７を介して実行される。

外部アクセス制御処理部９１７は、外部システム９０４へのアクセスが更新系か参照系かを判定するアクセス判別処理部９１８を備える。アクセス判別処理部９１８は、ユーザＡＰ９１６から受信した外部システム９０４に対する要求の内容が、「参照系アクセス」「更新系アクセス」「判別不能」のいずれかに判定する。ユーザＡＰ９１６と外部システム９０４とが通信するためのプロトコル（例えば、データベースへのアクセスに用いられるＳＱＬなど）は、構築するシステムによって異なる。したがって、アクセス判別処理部９１８の実装は適用するシステムごとに相違してもよい。例えば、ユーザがテキストで定義可能な定義ファイルのような形式であってもよいし、ＡＰサーバ２０３に組み込まれるモジュールのような形式として、システムを構築するユーザが独自に実装し、外部アクセス制御処理部９１７に組み込む形式にしてもよい。

ユーザＡＰ９１６による外部システム９０４へのアクセス要求がアクセス判別処理部９１８によって「参照系アクセス」と判定された場合には、当該アクセス要求は、更新系アクセスによる矛盾問題を生じさせない。したがって、この場合には、外部アクセス制御処理部９１７は、外部システム９０４に対するアクセスを許可するように制御する。

一方、ユーザＡＰ９１６による外部システム９０４へのアクセス要求がアクセス判別処理部９１８によって「更新系アクセス」と判定された場合、又は「判別不能」と判定された場合には、外部アクセス制御処理部９１７は、処理中のリクエストに更新特権が付与されているか否かを判定する。

外部アクセス制御処理部９１７は、処理中のリクエストに更新特権が付与されていない場合には、現在処理中のリクエストを枝刈り対象リクエストとみなし、リクエスト処理を終了する。このとき、Ｗｅｂサーバ９１５は、枝刈りが実施されたことを示すレスポンスを結果解析処理部９１４に通知する。結果解析処理部９１４は、当該レスポンスを受信すると、リトライ処理を実施せず、処理を終了する。

処理中のリクエストに更新特権が付与されている場合には、特権制御付リクエストＩＤ状態テーブル９２２にアクセスし、リクエストＩＤの排他処理を実行し、リクエストＩＤが「処理中」か否かを判定する。リクエストＩＤが「完了」の場合には、既に当該リクエストＩＤのクライアント２０１へのレスポンスは、別のサーバの処理によって完了している。したがって、排他を解放し、外部システム９０４にアクセスすることなく、リクエスト処理を終了する。

一方、リクエストＩＤが「処理中」の場合には、特権制御付リクエストＩＤ状態テーブル９２２のリクエストＩＤの状態を「特権中」に更新し、排他処理を終了する。そして、「特権中」に更新を完了すると、以降、更新系アクセスを実行する。「特権中」に更新する処理はリクエストＩＤあたり１回のみ実施され、以降、外部システム９０４に対するアクセス要求を受け付けると、外部アクセス制御処理部９１７は、アクセスの種類を判定することなく、そのまま、外部システム９０４にアクセスするように制御する。

特権制御付リクエストＩＤ状態テーブル９２２のリクエストＩＤが「特権中」に更新されると、当該リクエストＩＤに対して特権発動中となる。このとき、更新特権を付与されたリクエストが優先的に処理され、当該リクエストの処理結果が得られるクライアント２０１に対するレスポンスとして送信される。以上の処理の手順を図９に示す。

図９は、本発明の第２の実施の形態のクライアントからの要求を処理し、外部システムに対するアクセスを制御する手順を示すシーケンス図である。

クライアント２０１は、第１の実施の形態と同様に、まず、クライアント２０１からインテリジェントプロキシ処理部２１１にリクエストを送信する（Ｓ１００１）。

インテリジェントプロキシ処理部２１１のリクエスト冗長化制御部９１２は、リクエストを冗長化し、各ＡＰサーバ２０３に送信する（Ｓ１００２）。このとき、冗長化されたリクエストの１つに更新特権を付与する。その後、各ＡＰサーバ２０３は要求されたリクエストを処理する（Ｓ１００３〜Ｓ１０１３）。この際、外部システム９０４へのアクセスについては、ＡＰサーバ２０３の外部アクセス制御処理部９１７がリクエストの更新特権の有無に基づいて、前述のとおり外部アクセスを制御する（Ｓ１００６、Ｓ１００７、Ｓ１００８、Ｓ１００９、Ｓ１０１４）。

インテリジェントプロキシ処理部２１１の結果解析処理部９１４は、ＡＰサーバ２０３からレスポンスを受信する（Ｓ１０１５、Ｓ１０１６）。受信したレスポンスが更新特権を有するリクエストを処理したレスポンスであれば、更新特権を含むレスポンスであることを認識することができる。例えば、ＨＴＴＰのレスポンスヘッダを拡張してＷｅｂサーバ９１５が情報を付与してもよいし、別の方法を用いてもよい。結果解析処理部９１４は、第１の実施の形態と同様に、排他処理を実行後、特権制御付リクエストＩＤ状態テーブル９２２にアクセスし、リクエストＩＤの状態を確認する。

結果解析処理部９１４は、リクエストＩＤに対応するレコードの状態が「処理中」又は「完了」の場合には、第１の実施の形態と同様に処理する。

一方、結果解析処理部９１４は、リクエストＩＤに対応するレコードの状態が「特権中」の場合には、既に外部システム９０４に更新系アクセスが実行されたことを意味している。この場合には、更新特権の有さないリクエストの処理結果がレスポンスとしてクライアント２０１に返送されると、システムに矛盾を生じさせる。したがって、まず、ＡＰサーバ２０３から受信したレスポンスが更新特権を有するか否かを判定する。レスポンスが更新特権を有さない場合には、結果解析処理部９１４は実行中の排他処理を中止し、処理を終了する（Ｓ１０１５）。もし、レスポンスが更新特権を有する場合には、第１の実施の形態における、セッション登録処理以降の処理と同様の処理を実行する（Ｓ１００９、Ｓ１０１０、Ｓ１０１３、Ｓ１０１６、Ｓ１０１７）。

更新特権が付与されたリクエストの処理が特権発動中の場合、更新特権を付与されていないリクエストの処理は、「外部アクセス制御処理部９１７に更新系アクセスを要求したタイミング」（Ｓ１００８）、又は「リクエスト処理を完了し、結果解析処理部９１４にレスポンスを応答したタイミング」（Ｓ１０１５）のいずれかで処理が中止され、枝刈りされる。

ここで、障害発生時の結果解析処理部９１４の処理手順を以下に説明する。

まず、特権制御付リクエストＩＤ状態テーブル９２２にアクセスし、各リクエストＩＤの状態を判定する。

リクエストＩＤの状態が「処理中」の場合には、リトライ処理部９１３に処理を依頼する。このとき、障害が発生したリクエストに更新特権が付与されていた場合には、リトライされたリクエストにも更新特権を付与する。同様に、障害の発生したリクエストに更新特権が付与されていない場合には、リトライされたリクエストに更新特権を付与しない。以降、ＡＰサーバ２０３の障害が復旧するまで、障害の発生した「サーバＩＤ」「リクエストＩＤ」の組み合わせによる特権制御付リクエストＩＤ状態テーブル９２２へのアクセスを拒否する。

また、リクエストＩＤの状態が「完了」の場合には、リトライ処理を実行する必要はない。第１の実施の形態と同様に処理を終了する。

さらに、リクエストＩＤの状態が「特権中」の場合、障害の発生したリクエストに更新特権が付与されていたか否かを判定する。更新特権が付与されていなかった場合には、すでに更新特権が発動中であるため、リトライ処理を実行する必要はなく、そのまま処理を終了する。更新特権が付与されていた場合には、更新処理中にサーバの障害が発生し、リクエスト処理が完了できなかったことになる。この場合には、まず、外部システム９０４に対して、対象サーバからのトランザクション処理の失敗を通知し、外部システム９０４のロールバック処理を実行する。ロールバック処理の成功後、特権制御付リクエストＩＤ状態テーブル９２２にアクセスし、リクエストＩＤの状態を「特権中」から「処理中」に戻す。さらに、リトライ処理部９１３にリトライを依頼する。リトライ処理部９１３は、リトライされるリクエストを送信する場合には、当該リクエストに更新特権を付与する。以降、ＡＰサーバ２０３の障害が復旧するまで、障害の発生した「サーバＩＤ」「リクエストＩＤ」の組み合わせによる特権制御付リクエストＩＤ状態テーブル９２２へのアクセスを拒否する。

以上の手順によって、外部システムに対する更新アクセスによって矛盾が生じる問題を回避することができる。

本発明の第２の実施の形態では、冗長化されたリクエストを枝刈りするタイミングについて、更新特権を発動するタイミングを特権処理が必要になる最大限まで遅らせている。前述したとおり、Ｗｅｂアプリケーションシステムでは、外部システムへのアクセス処理の大半は参照系アクセスである。したがって、同一のＵＲＬに対するリクエストであっても、更新系の処理が必要になる前に参照系のアクセスのみで処理が完了する可能性が高い。第２の実施の形態では、参照系のアクセスが多い場合の応答性能を高めることができる。

また、第２の実施の形態の特徴によれば、第１の実施の形態で前提としていた「ＵＲＬによって処理中の更新系アクセスの有無が判別可能」というユーザＡＰの設計に関する制約が無いため、従来システムからの移行性に優れる。

（第３の実施の形態）
本発明の第３の実施の形態では、複数の物理計算機上に複数の仮想計算機を稼働させ、ＡＰサーバの冗長性を高めた構成となっている。冗長性を高めるために必要となる物理計算機の台数が削減できるため、設置スペース及び消費電力などの面において、すべての計算機を物理的に用意するよりも現実的なシステム構成となる。

第１の実施の形態及び第２の実施の形態では、サーバの選択方法としてラウンドロビン法を利用していたが、複数の仮想計算機を含むシステム構成に適用するためにラウンドロビン法を拡張したサーバの選択方法を第３の実施の形態では説明する。

図１０は、本発明の第３の実施の形態のシステム構成を説明する図である。

仮想計算機とは、一つの物理計算機上に、並列して動作可能な複数の仮想的な計算機をソフトウェアによって構築し、複数のＯＳなどを同時に実行する技術である。

図１０に示す例では、同一の物理計算機上に２台ずつの仮想計算機を作成し、それぞれの仮想計算機上で１つのＡＰサーバを動作させる構成となっている。

同一の物理計算機上に構築された仮想計算機同士は、それぞれ独立した動作が可能であるが、物理計算機上のネットワークインタフェースカード（ＮＩＣ）など、リソースの一部を共有して使用する。

したがって、例えば、複数の仮想計算機が動作している物理計算機において、ＮＩＣが故障するなどの物理的な障害が発生すると、同一の物理計算機上で動作しているすべての仮想計算機に障害の影響が及んでしまうというデメリットがある。

また、共有のリソースを使用するため、同一の物理計算機上で動作している特定の仮想計算機に負荷が集中すると、その他の仮想計算機の性能が悪化するおそれがある。

以上より、同一物理計算機に処理が集中することは、処理性能の悪化及び障害発生時の影響などの問題が生じる可能性がある。そこで、第３の実施の形態では、処理を均等に分散させることを目的として、冗長化したリクエストを処理するサーバを選択する以下のアルゴリズムを導入する。以下のアルゴリズムを物理計算機均等配分ラウンドロビン法とする。

物理計算機均等配分ラウンドロビン法では、まず、物理計算機均等配分テーブル１１２１を作成する。物理計算機均等配分テーブル１１２１は、以下の手順で作成される。なお、物理計算機均等配分テーブル１１２１は、図１０に示すように、インテリジェントプロキシ装置２０２に格納される。

まず、各物理計算機１、２、…ｎそれぞれで動作している仮想計算機の台数（Ｎ１、Ｎ２、…、Ｎｎ）を求める。次に、Ｎ１、Ｎ２、…、Ｎｎの最小公倍数Ｍを算出する。各物理計算機単位でレコード数Ｍの作業用テーブルＴ１、Ｔ２、…Ｔｎを作成し、テーブルのレコードとして、物理計算機上の仮想計算機で動作するサーバアドレスを、ラウンドロビン方式で順に並べる。次に、物理計算機均等配分テーブル１１２１として、レコード数Ｍ×ｎのテーブルＳを作成し、Ｓ［１］＝Ｔ１［１］、Ｓ［２］＝Ｔ２［１］、…、Ｓ［ｎ］＝Ｔｎ［１］、Ｓ［１＋ｎ］＝Ｔ１［２］、Ｓ［２＋ｎ］＝Ｔ２［２］…のように、Ｓ［ｉ＋（ｊ−１）×ｎ］＝Ｔｉ［ｊ］が成り立つようにＴ１、Ｔ２、…ＴｎのサーバアドレスをテーブルＳに登録する。テーブルＳを作成した後は、作業用テーブルＴ１、Ｔ２、…、Ｔｎは削除してもよい。

以上の手順によって作成された物理計算機均等配分テーブル１１２１を作成する手順の一例を図１１に示す。

図１１は、本発明の第３の実施の形態の物理計算機均等配分テーブル１１２１を作成する例を示す図である。

図１１に示す例では、物理計算機が３台含まれている（ｎ＝３）。各計算機には、それぞれ、３、２、２台の仮想計算機が稼働している（Ｎ１＝３、Ｎ２＝２、Ｎ３＝２）。したがって、Ｎ１、Ｎ２、Ｎ３の最小公倍数Ｍは６である。各物理計算機について、レコード数Ｍ（＝６）の作業用テーブルＴ１、Ｔ２及びＴ３を図１１に示すように作成する。作業用テーブルＴ１ではＡ→Ｂ→Ｃを２回、Ｔ２ではＤ→Ｅを３回、Ｔ３ではＦ→Ｇを３回繰り返す内容となる。最後に、Ｔ１［１］（＝Ａ）、Ｔ２［１］（＝Ｄ）、Ｔ３［１］（＝Ｆ）、Ｔ１［２］（＝Ｂ）、…といった順序で、レコード数Ｍ×ｎ（＝１８）のテーブルＳ、すなわち、物理計算機均等配分テーブル１１２１に値が格納される。

第３の実施の形態では、作成された物理計算機均等配分テーブル１１２１を参照し、冗長化されたリクエストを処理するサーバがラウンドロビン方式で選択される。

サーバ選択方法として物理計算機均等配分ラウンドロビン法を適用すると、物理計算機の台数が冗長化の多重度より多い場合、必ず異なる物理計算機上に配置された仮想計算機上で動作するサーバに冗長化したリクエストが送信される。物理計算機の台数が冗長化の多重度より少ない場合においても、必ず異なる物理計算機上で同じリクエストの処理が実行され、また、振り分けられる冗長化したリクエストの量は物理計算機単位で均等に分散される。いずれの場合においても、すべての物理計算機で故障が発生した場合を除いて、常にリクエスト処理を継続することが可能になる。

以上より、本発明の第３の実施の形態によれば、物理計算機均等配分ラウンドロビン法の適用によって、システムの負荷分散と信頼度を最適化することができる。

なお、サーバのメンテナンス及び縮退運転などを容易化するために、図１１に示した処理を自動的に実行するツールをあらかじめ用意しておくことが望ましい。システムの構成変更に応じて自動的に物理計算機均等配分テーブル１１２１を再作成することによって、システム全体を停止させることなく、仮想計算機又は物理計算機の一部リブート、機器入れ替えなどの作業を実行可能とし、運用を容易にすることができる。

なお、物理計算機、仮想計算機、又はＡＰサーバに障害が発生した場合には、障害の発生したサーバを除いて物理計算機均等配分テーブル１１２１を再構成するとよい。

また、厳密に処理量を分散する必要が無い場合には、物理計算機均等配分テーブル１１２１を図１１に示したように均等に分散させるようにしなくてもよく、例えば、処理能力の高い物理計算機上の複数の仮想計算機で処理を実行させるようにしてもよい。

第３の実施の形態では、仮想計算機１台につき、１つのＡＰサーバが動作する場合について示している。仮想計算機１台につき複数台のＡＰサーバを動作させて冗長化する構成の場合には、前述した物理計算機均等配分テーブル１１２１の作成方法を拡張し、物理計算機上で分散され、かつ、仮想計算機単位でも分散されるように物理計算機均等配分テーブル１１２１を作成すればよい。

（第４の実施の形態）
本発明の第４の実施の形態では、第３の実施の形態の各仮想計算機が利用可能なリソース配分に重み付けを加えたものである。近年の仮想計算機及び中央演算処理装置の技術では、各仮想計算機で使用可能なリソースの配分を制御することが可能である。

第４の実施の形態は、リクエストを冗長化する場合に、「主系」「副系」を明確に区別する場合に適している。「主系」の冗長化リクエストを処理するために与えられるリソースの量が、第３の実施の形態と比較して多くなるため、第３の実施の形態よりもシステムの応答性能を向上させることができる。そのかわり、「主系」のリクエストを処理していた仮想計算機又は物理計算機で障害が発生した場合の応答性能は悪化する。したがって、仮想計算機又は物理計算機の故障率などに基づいて、第３の実施の形態又は第４の実施の形態のいずれをシステムに適用するかを判断するとよい。

図１２は、本発明の第４の実施の形態のシステム構成を説明する図である。

第４の実施の形態では、各物理計算機で稼働している各仮想計算機が、「主系処理用」又は「副系処理用」に区別される。「主系処理用」の仮想計算機には、「副系処理用」の仮想計算機と比較して、より多くのリソースが配分される。図１２に示す例では、仮想計算機１３０３Ａ及び１３０３Ｃが主系処理用、仮想計算機１３０３Ｂ及び１３０３Ｄが副系処理用になる。

主系処理用の仮想計算機上で動作しているＡＰサーバを主系処理用のＡＰサーバ、副系処理用の仮想計算機上で動作しているＡＰサーバを副系処理用のＡＰサーバとする。図１２の例では、ＡＰサーバ１３０４Ａ及び１３０４Ｃが主系処理用、ＡＰサーバ１３０４Ｂ及び１３０４Ｄが副系処理用になる。

第４の実施の形態では、図１２に示すように、主系処理用のＡＰサーバの主系テーブル１３２１と副系処理用のＡＰサーバの副系テーブル１３２２をそれぞれ用意する。主系テーブル１３２１及び副系テーブル１３２２の作成方法は、第３の実施の形態に示した方法を採用し、同一物理計算機に対する同一リクエストの分散を図るようにする。

リクエスト冗長化制御部１３１２は、リクエストを冗長化する際、冗長化されたリクエストの一つを「主系」リクエスト、残りを「副系」リクエストとみなす。「主系」リクエストを処理するサーバのアドレスを主系テーブル１３２１からラウンドロビン法で選択する。「副系」リクエストを処理するサーバのアドレスを副系テーブル１３２２からラウンドロビン法で選択する。

この場合、２つのテーブルからラウンドロビンでＡＰサーバを選択するため、同一物理計算機に対する同一リクエストの分散が厳密に実施されない場合がある。厳密に分散する場合には、「副系」リクエストを処理するサーバの選択方法として、「主系」と同一の物理計算機を除外したテーブルを物理計算機ごとに作成し、「副系」を選択する場合に「主系」で使用する物理計算機が除外された副系テーブルを参照するようにしてもよい。

また、第１の実施の形態のように、リクエストＵＲＬに基づいて外部システムに対する更新系アクセスの有無を判別可能な場合には、更新系アクセスを含むリクエストでは「主系」リクエスト１つに絞って処理するとよい。

さらに、第２の実施の形態のようにリクエストＵＲＬから外部システムへの更新系アクセスの有無が分からない場合には、常に「主系」リクエストに更新特権を与えるとよい。

本発明の第４の実施の形態によれば、システム負荷が小さい場合の応答性能は、従来の負荷分散機システムよりも優れている。また、ＡＰサーバを選択するためのアルゴリズムが単純であるため、負荷分散機におけるサーバ選択処理にかかる負荷も小さくすることができる。

さらに、本発明の第４の実施の形態によれば、大半のレスポンス結果は「主系」リクエストを処理したＡＰサーバから得られるようになる。したがって、あるリクエスト処理において、「主系」の一つのサーバからのレスポンス処理が完了した時点で「副系」で処理されている同一リクエスト処理をキャンセルするような処理を含めてもよい。具体的には、副系を処理している仮想計算機をすべて再起動するような単純な方法であってもよいし、当該リクエストを処理するプロセスを中止させる方法であってもよい。

（第５の実施の形態）
本発明の第５の実施の形態では、第３の実施の形態又は第４の実施の形態に、リクエストを冗長化させる多重度を動的に決定する処理を追加した形態である。

リクエストを処理するために使用が許可されるリソースの量は、レスポンス性能に直結する。リクエストの多重度を大きくしてリソース量を多くすると、処理能力の高いサーバに処理される可能性が高まるため、クライアントに対する応答性能が早くなる。一方、多重度を大きくすると、別のリクエストを処理するためのリソース量が制限されるため、別のリクエストの応答性能が低下する。したがって、すべてのリクエストに対して多重度を大きくすればよいわけではない。

そこで、第５の実施の形態では、リクエスト冗長化制御部１４１２において、多重度を動的に制御する多重度決定処理部１４１３を備えている。

図１３は、本発明の第５の実施の形態のシステム構成を説明する図である。

本発明の第５の実施の形態では、前述したように、リクエスト冗長化制御部１４１２に多重度を動的に制御する多重度決定処理部１４１３を備える。多重度決定処理部１４１３は、ＡＰサーバが実行される計算機のリソース量などに基づいて、リクエストを冗長化する多重度を決定する。以下に、多重度決定処理部１４１３によって多重度を決定する３つの例について説明する。

（Ａ）リクエストＵＲＬの重要度に基づいた多重度動的決定方法
図１４は、本発明の第５の実施の形態のリクエストＵＲＬの重要度に基づいた多重度動的決定方法を実行するための構成を示す図である。

リクエストＵＲＬの重要度に基づいた多重度動的決定方法では、インテリジェントプロキシ装置２０２に、リクエストＵＲＬの重要度を表したＵＲＬ重要度テーブル１５２１が格納される。

ＵＲＬ重要度テーブル１５２１は、システム管理者によって作成され、ＵＲＬごとに重要度が規定されている。そして、重要度が高いと判定されたリクエストにマッチした場合には、冗長化の多重度を大きくすることによって、信頼性を向上させる。また、重要度が低いと判定された場合には、他のリクエストを処理するために使用されるリソースが増加するように多重度を小さくする。

リクエストＵＲＬの重要度に基づいた多重度動的決定方法は、クライアントからリクエストされるＵＲＬに対し、受信したリクエストの重要度があらかじめ認識されている場合に適用される。ＵＲＬ重要度テーブル１５２１は、第１の実施の形態で説明したＵＲＬ単位の更新系アクセス有無定義テーブル２２２を拡張したものである。

ＵＲＬ重要度テーブル１５２１は、クライアント２０１から送信されたリクエストに対応するＵＲＬについて、リクエストの重要度を対応させたものである。重要度の情報としては、例えば、「高」「中」「低」「更新有」などの情報が格納される。

リクエスト冗長化制御部１５１２は、第１の実施の形態のリクエスト冗長化制御部２１２が拡張されている。具体的には、第１の実施の形態では、リクエスト冗長化制御部２１２は「更新有」なら多重度を１、そうでなければ複数の多重度に設定していたが、リクエスト冗長化制御部１５１２は、「更新有」の場合に１を、それ以外の場合には重要度に応じて多重度が高くなるように段階的に設定する。多重度を決定するために用いられる関数は、重要度に応じて多重度が高くなるように段階的に設定するものであれば、どのような関数であってもよい。

このように、クライアント２０１から送信されたリクエストのリクエストＵＲＬに対応する重要度に応じて、リクエスト冗長化の多重度を変化させることができる。

また、ＵＲＬ重要度テーブル１５２１には、「高」「中」「低」などの情報ではなく、リクエストＵＲＬに対応した多重度の数値を直接設定してもよい。

さらに、リクエストＵＲＬの重要度に基づいた多重度動的決定方法は、前述した第２の実施の形態に対しても適用可能である。ただし、リクエストＵＲＬに基づいて更新系アクセス要求の有無を判定できない構成であり、ＵＲＬ重要度テーブル１５２１に「更新有」が設定されないため、常に多重度は２以上の値になる。

（Ｂ）システム負荷状態に基づいた多重度動的決定方法
システム全体の負荷が高い状態で、多重度の高い冗長化リクエストを処理させようとすると、さらにシステム全体の負荷が高くなるため、応答性能が悪化する可能性がある。そこで、「システム全体の負荷が高い場合には多重度を低く」「システム全体の負荷が低い場合には多重度を高く」するように、システム全体の負荷状態に応じて多重度を動的に制御する。

図１５は、本発明の第５の実施の形態のシステム負荷状態に基づいた多重度動的決定方法を説明する図である。

インテリジェントプロキシ装置２０２は、システム内部の冗長化リクエストの送受信を制御する。したがって、インテリジェントプロキシ装置２０２に冗長化リクエストの送受信数を計測する処理中リクエスト総数カウンタ１６２１を追加することによって、現在、ＡＰサーバで処理されているリクエストの総数を取得することができる。

図１５に示すインテリジェントプロキシ装置２０２には、処理中リクエスト総数カウンタ１６２１及びＡＰサーバ総数カウンタ１６２２が含まれる。処理中リクエスト総数カウンタ１６２１は、現在処理中のリクエスト総数を格納する。また、ＡＰサーバ総数カウンタ１６２２は、故障していない、稼動中のＡＰサーバの台数を格納する。

リクエスト冗長化制御部１６１１は、クライアント２０１から受信したリクエストを冗長化すると、処理中リクエスト総数カウンタ１６２１の値に冗長化されたリクエストの個数を加算する。結果解析処理部１６１４は、１つの処理結果を受信した場合に、処理中リクエスト総数カウンタ１６２１の値を１減算する。リトライ処理部１６１３は、リクエストをリトライする場合に、処理中リクエスト総数カウンタ１６２１の値を１加算する。

ここで、システム全体の負荷は、処理中リクエスト総数カウンタ１６２１の値と、ＡＰサーバ総数カウンタ１６２２の値の比率から概算する。多重度決定処理部１６１２は、負荷が大きい場合は２に近く、負荷が小さい場合は可能な限り大きい値になるように、冗長化するリクエストの多重度を制御する。

多重度を決定する関数は、上記の性質を満たすものであればどのようなものでもよく、例えば、「リクエスト処理していない余剰なＡＰサーバがある場合には、余剰なＡＰサーバの半数を多重度として設定し、システム負荷の高い状態では多重度を２に設定する」といった関数を使用することができる。具体的には、以下に示す式の通りである。

多重度Ｍ ＝ ｍａｘ（２，ｃｅｉｌｉｎｇ（（Ｚ−Ｙ）÷２））
ここで、Ｙは処理中リクエスト総数カウンタ１６２１の値、ＺはＡＰサーバ総数カウンタ１６２２の値である。ｍａｘ（ｘ，ｙ）は２つの値ｘ、ｙのうち大きい方の値を表す関数である。ｃｅｉｌｉｎｇ（ｘ）は天井関数であり、ｘの切り上げ値を表す。

以上により、システム全体の負荷状態に基づいて、多重度を動的に制御することが可能となる。

（Ｃ）「更新系アクセスの発生しやすさ」に基づいた多重度動的決定方法
第２の実施の形態によるリクエストの枝刈り方法では、更新系アクセスが発生した時点で、冗長化されたリクエストは自動的に枝刈り対象となり、最終的に処理されるのは更新特権を持つリクエストのみとなる。

したがって、冗長化の多重度を決定する前の段階で更新系リクエストが発生する可能性が高いことを認識可能な場合には、可能な限り更新特権を持たない冗長化リクエストの多重度を小さくすることが望ましい。

また、第２の実施の形態で前提としたように、通常のＡＰサーバシステムでは、入力データであるＵＲＬから更新系アクセスが発生するかどうかを判定することは困難である。しかし、リクエスト処理結果の統計的な情報に基づいて、特定のＵＲＬについて、リクエストを処理する過程における更新系アクセスの発生のしやすさを推定することは可能である。リクエスト処理結果の統計的な情報に基づいて冗長化の多重度を制御する方法を図１６〜図１８を参照しながら説明する。

図１６は、本発明の第５の実施の形態の統計情報に基づいた多重度動的決定方法を実現するための構成を示す図である。

本発明の第５の実施の形態では、インテリジェントプロキシ処理部２１１に機械学習処理部１７１５、機械学習の結果を格納した統計情報テーブル１７２１、及び統計情報テーブル１７２１に基づいて「更新系アクセスの発生しやすさ」を判定する判定処理部１７１３が含まれる。

また、第２の実施の形態では、更新系アクセスが発生した時点で特権制御付リクエストＩＤ状態テーブル９２２に更新系アクセスの発生が通知される。特権制御付リクエストＩＤ状態テーブル９２２を利用することによって、リクエスト処理が完了した場合に、当該リクエストＵＲＬを処理した過程で、外部システムへの更新系アクセスが発生したか否かを認識することができる。

結果解析処理部１７１４は、第２の実施の形態の結果解析処理部９１４を拡張したものである。拡張された処理について、手順を図１７に示す。

図１７は、本発明の第５の実施の形態の結果解析処理部１７１４の特権制御付リクエストＩＤ状態テーブル９２２の状態を「完了」に変更する処理手順を示すフローチャートである。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、結果解析処理部１７１４によって、特権制御付リクエストＩＤ状態テーブル９２２の状態を「完了」に変更する場合に、まず、処理対象のリクエストＩＤに基づいて、特権制御付リクエストＩＤ状態テーブル９２２を検索する（Ｓ１８０１）。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、検索されたレコードの変更前の状態が「特権中」であるか否かを判定する（Ｓ１８０２）。変更前の状態が「特権中」の場合には（Ｓ１８０２の結果が「Ｙｅｓ」）、リクエストＵＲＬで更新系アクセスが発生したことを、機械学習処理部１７１５に通知する（Ｓ１８０３、Ｓ１８０５）。変更前の状態が「特権中」でない場合には（Ｓ１８０２の結果が「Ｎｏ」）、リクエストＵＲＬで更新系アクセスが発生しなかったことを、機械学習処理部１７１５に通知する（Ｓ１８０４、Ｓ１８０５）。最後に、インテリジェントプロキシ装置２０２のＣＰＵ３２１は、結果解析処理部１７１４によって、特権制御付リクエストＩＤ状態テーブル９２２の状態を「完了」に変更する（Ｓ１８０６）。その後の処理については、第１の実施の形態の結果解析処理部９１４による処理と同じである。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、機械学習処理部１７１５によって、結果解析処理部１７１４によって通知された情報を学習データとして、リクエストＵＲＬに対する更新系アクセスの発生しやすさを統計的学習手法によって学習する。

機械学習処理部１７１５による統計的学習手法は、単純に各ＵＲＬに対するカウンタを設置してＵＲＬごとの更新系アクセスの発生頻度を計算してもよいし、ＵＲＬ文字列をＮ−ｇｒａｍなどによってベクトル化し、サポートベクタマシン又はニューラルネットワークなどによる、高度な機械学習を適用してもよい。前者の場合は未知のＵＲＬに対するリクエストを正しく判別することはできないが、後者の場合には、未知のＵＲＬに対するリクエストの場合でも、より良い推定結果を得られる可能性がある。

本発明の第５の実施の形態では、統計的学習を利用しているため、「絶対に更新系アクセスが発生しない」と断言することはできない。したがって、多重度決定処理部１７１２は、処理対象のリクエストについて最低でも２以上の多重度を与える。

リクエスト冗長化制御部１７１１は、第２の実施の形態のリクエスト冗長化制御部９１２が拡張されたものである。拡張された処理について手順を図１８に示す。

図１８は、本発明の第５の実施の形態のリクエスト冗長化制御部１７１１の多重度決定の処理手順を示すフローチャートである。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、クライアント２０１からのリクエストを受け付けると（Ｓ１９０１）、判定処理部１７１３に問い合わせることによって、当該リクエストＵＲＬで更新系アクセスが発生しやすいか示す情報を取得する（Ｓ１９０２）。判定処理部１７１３は、機械学習結果が格納されている統計情報テーブル１７２１に基づいて、リクエストＵＲＬに対する「更新系らしさ」を算出する。

インテリジェントプロキシ装置２０２のＣＰＵ３２１は、多重度決定処理部１７１２によって、算出された数値データに基づいて、「更新系アクセスが発生しやすい」場合には多重度を２に近い値に、「参照系アクセスが発生しやすい」場合には多重度をより大きな値に設定する（Ｓ１９０３）。

多重度決定処理部１７１２が多重度を決定するために用いる関数は、「更新系アクセスが発生しやすい」場合には多重度を２に近い値に、「参照系アクセスが発生しやすい」場合には多重度を大きくするものであれば、どのような関数を用いてもよい。例えば、更新系アクセスの発生しやすさが閾値以上の場合には多重度を２に、閾値以下の場合には前述した（Ａ）リクエストＵＲＬの重要度に基づいた多重度動的決定方法、又は（Ｂ）システム負荷状態に基づいた多重度動的決定方法を用いるようにしてもよい。

多重度決定処理部１７１２によって多重度が決定された後の処理は、第２の実施の形態のリクエスト冗長化制御部９１２と同じである。

以上より、リクエストＵＲＬに応じて「更新系アクセスの発生しやすさ」を学習することによって、冗長化されるリクエストについて、より適正な多重度を取得することができる。

本発明の第５の実施の形態によれば、リクエストを処理するＡＰサーバの負荷などに基づいて、冗長化されるリクエストの多重度を決定することができる。したがって、リクエストに更新系アクセスが発生しやすい場合、システムの負荷状況などに応じて適正な多重度を決定することが可能となる。

本発明の第１の実施の形態の計算機システムの物理構成図である。 本発明の第１の実施の形態のセッション管理の概要を説明する図であって、セッション情報を登録する手順を説明する図である。 本発明の第１の実施の形態のセッション管理の概要を説明する図であって、リクエストの処理結果をクライアントに送信する手順を説明する図である。 本発明の第１の実施の形態のクライアントから受け付けた処理要求に応答する手順を示すフローチャートである。 本発明の第１の実施の形態の更新系アクセスを含むリクエストの多重度を単一にする手順を示すフローチャートである。 本発明の第１の実施の形態のシステム構成を説明する図である。 本発明の第１の実施の形態のクライアントからのリクエストを処理する手順を示すシーケンス図である。 本発明の第２の実施の形態のシステム構成を説明する図である。 本発明の第２の実施の形態のクライアントからの要求を処理し、外部システムに対するアクセスを制御する手順を示すシーケンス図である。 本発明の第３の実施の形態のシステム構成を説明する図である。 本発明の第３の実施の形態の物理計算機均等配分テーブルを作成する例を示す図である。 本発明の第４の実施の形態のシステム構成を説明する図である。 本発明の第５の実施の形態のシステム構成を説明する図である。 本発明の第５の実施の形態のリクエストＵＲＬの重要度に基づいた多重度動的決定方法を実行するための構成を示す図である。 本発明の第５の実施の形態のシステム負荷状態に基づいた多重度動的決定方法を説明する図である。 本発明の第５の実施の形態の統計情報に基づいた多重度動的決定方法を実現するための構成を示す図である。 本発明の第５の実施の形態の結果解析処理部の特権制御付リクエストＩＤ状態テーブルの状態を「完了」に変更する処理手順を示すフローチャートである。 本発明の第５の実施の形態のリクエスト冗長化制御部の処理手順を示すフローチャートである。

符号の説明

２０１ クライアント
２０２ インテリジェントプロキシ装置
２０３ ＡＰサーバ
２０４ セッション管理処理部
２０５ データベースサーバ装置
２１１ インテリジェントプロキシ処理部
２１２、９１２、１３１２、１４１２、１５１２、１６１１、１７１１ リクエスト冗長化制御部
２１３、９１３、１６１３ リトライ処理部
２１４、９１４、１６１４、１７１４ 結果解析処理部
２１５、９１５ Ｗｅｂサーバ
２１６、９１６ ユーザＡＰ
２１７ セッション獲得処理部
２１８ セッション登録処理部
２１９ コミット処理部
２２１ サーバアドレステーブル
２２２ 更新系アクセス有無定義テーブル
２２３ リクエストＩＤ状態テーブル
２２４ バッファテーブル
２２５ セッション記憶データベース
９１７ 外部アクセス制御処理部
９１８ アクセス判別処理部
９１９ 特権付与処理部
９２２ 特権制御付リクエストＩＤ状態テーブル
１１２１ 物理計算機均等配分テーブル
１３２１ 主系テーブル
１３２２ 副系テーブル
１４１３、１６１２、１７１２ 多重度決定処理部
１５２１ ＵＲＬ重要度テーブル
１６２１ 処理中リクエスト総数カウンタ
１６２２ ＡＰサーバ総数カウンタ
１７１３ 判定処理部
１７１５ 機械学習処理部
１７２１ 統計情報テーブル

Claims (10)

1. 業務処理を要求するリクエストを送信するクライアントと、前記リクエストを処理する複数のアプリケーションサーバと、前記リクエストを受信し、前記アプリケーションサーバに送信するプロキシ装置と、前記リクエストを管理するセッション管理装置とを含む計算機システムにおいて、前記リクエストを処理する方法であって、
   前記プロキシ装置は、第１インタフェース、前記第１インタフェースに接続される第１プロセッサ、及び前記第１プロセッサに接続される第１メモリを備え、
   前記アプリケーションサーバは、第２インタフェース、前記第２インタフェースに接続される第２プロセッサ、及び前記第２プロセッサに接続される第２メモリを備え、
   前記プロキシ装置は、前記クライアントから送信されたリクエストを冗長化し、前記冗長化されたリクエストを各アプリケーションサーバに送信し、
   前記各アプリケーションサーバは、前記冗長化されたリクエストの処理結果を前記プロキシ装置に送信し、
   前記各アプリケーションサーバは、前記アプリケーションサーバの識別子及び前記冗長化されたリクエストの識別子を含むセッション情報を前記セッション管理装置に通知し、
   前記プロキシ装置は、前記冗長化されたリクエストの処理結果を受信すると、前記クライアントに応答する処理結果を決定し、
   前記プロキシ装置は、前記決定された処理結果を送信したアプリケーションサーバの識別子及び前記クライアントから送信されたリクエストの識別子を前記セッション管理装置に通知することを特徴とするリクエスト処理方法。
2. 前記アプリケーションサーバは、前記業務処理で利用されるデータを格納する外部サーバにアクセスし、
   前記プロキシ装置は、前記クライアントから送信されたリクエストに前記外部サーバに格納されたデータの更新要求が含まれる場合には、前記冗長化されたリクエストの中で最初に更新処理が完了したリクエスト以外のリクエストの処理を中止することを特徴とする請求項１に記載のリクエスト処理方法。
3. 前記アプリケーションサーバは、前記業務処理で利用されるデータを格納する外部サーバにアクセスし、
   前記プロキシ装置は、
   前記冗長化されたリクエストから一つのリクエストを選択し、
   前記選択されたリクエストに更新特権を付与し、
   前記クライアントから送信されたリクエストによって、前記外部サーバに格納されたデータを更新する処理が実行される場合には、前記更新特権が付与されていないリクエストの処理を中止することを特徴とする請求項１に記載のリクエスト処理方法。
4. 前記アプリケーションサーバは、前記アプリケーションサーバの計算機資源を論理的に分割することによって仮想計算機を提供し、
   前記冗長化されたリクエストは、前記仮想計算機によって処理されることを特徴とする請求項１に記載のリクエスト処理方法。
5. 前記プロキシ装置は、前記冗長化されるリクエストを処理する仮想計算機を選択する順序を含む計算機配分情報を管理し、
   前記計算機配分情報は、前記仮想計算機を提供するアプリケーションサーバが均等に分散されるように、前記仮想計算機の選択順序が設定されていることを特徴とする請求項４に記載のリクエスト処理方法。
6. 前記仮想計算機は、前記主系計算機と、前記主系計算機より処理能力の低い副系計算機とに分類され、
   前記プロキシ装置は、一台の前記主系計算機と、少なくとも一台の前記副系計算機とを選択し、前記選択された主系計算機及び副系計算機に前記冗長化されたリクエストを送信することを特徴とする請求項４に記載のリクエスト処理方法。
7. 前記プロキシ装置は、
   前記アプリケーションサーバの負荷情報を管理し、
   前記負荷情報に基づいて、前記冗長化されたリクエストの多重度を決定することを特徴とすることを特徴とする請求項１に記載のリクエスト処理方法。
8. 前記プロキシ装置は、
   前記クライアントから送信されたリクエストに含まれるアクセス先情報ごとに、前記外部サーバに格納されたデータが更新されたか否かを含む情報を蓄積し、
   前記蓄積された情報に基づいて、前記冗長化されたリクエストの多重度を決定することを特徴とすることを特徴とする請求項１に記載のリクエスト処理方法。
9. 業務処理を要求するリクエストを送信するクライアントと、前記リクエストを処理する複数のアプリケーションサーバと、前記リクエストを受信し、前記アプリケーションサーバに送信するプロキシ装置と、前記リクエストを管理するセッション管理装置とを含む計算機システムにおいて、前記リクエストを処理する方法であって、
   前記プロキシ装置は、第１インタフェース、前記第１インタフェースに接続される第１プロセッサ、及び前記第１プロセッサに接続される第１メモリを備え、
   前記アプリケーションサーバは、第２インタフェース、前記第２インタフェースに接続される第２プロセッサ、及び前記第２プロセッサに接続される第２メモリを含む計算機資源を備え、前記計算機資源を論理的に分割することによって仮想計算機を提供し、
   前記プロキシ装置は、前記クライアントから送信されたリクエストを冗長化し、前記冗長化されたリクエストを各アプリケーションサーバによって提供される仮想計算機に送信し、
   前記各仮想計算機は、前記冗長化されたリクエストの処理結果を前記プロキシ装置に送信し、
   前記各仮想計算機は、前記仮想計算機の識別子及び前記冗長化されたリクエストの識別子を含むセッション情報を前記セッション管理装置に通知し、
   前記プロキシ装置は、前記冗長化されたリクエストの処理結果を受信すると、前記クライアントに応答する処理結果を決定し、
   前記プロキシ装置は、前記決定された処理結果を送信した仮想計算機の識別子及び前記クライアントから送信されたリクエストの識別子を前記セッション管理装置に通知することを特徴とするリクエスト処理方法。
10. 業務処理を要求するリクエストを送信するクライアントと、前記リクエストを処理する複数のアプリケーションサーバと、前記リクエストを受信し、前記アプリケーションサーバに送信するプロキシ装置と、前記リクエストを管理するセッション管理装置とを含む計算機システムであって、
    前記プロキシ装置は、第１インタフェース、前記第１インタフェースに接続される第１プロセッサ、及び前記第１プロセッサに接続される第１メモリを備え、
    前記アプリケーションサーバは、第２インタフェース、前記第２インタフェースに接続される第２プロセッサ、及び前記第２プロセッサに接続される第２メモリを備え、
    前記プロキシ装置は、前記クライアントから送信されたリクエストを冗長化し、前記冗長化されたリクエストを各アプリケーションサーバに送信し、
    前記各アプリケーションサーバは、前記冗長化されたリクエストの処理結果を前記プロキシ装置に送信し、
    前記各アプリケーションサーバは、前記アプリケーションサーバの識別子及び前記冗長化されたリクエストの識別子を含むセッション情報を前記セッション管理装置に通知し、
    前記プロキシ装置は、前記冗長化されたリクエストの処理結果を受信すると、前記クライアントに応答する処理結果を決定し、
    前記プロキシ装置は、前記決定された処理結果を送信したアプリケーションサーバの識別子及び前記クライアントから送信されたリクエストの識別子を前記セッション管理装置に通知することを特徴とする計算機システム。

Images