JP2014081709A - リソース管理プログラム、リソース管理方法、及び情報処理装置 - Google Patents

Abstract

【課題】複数のコンピュータへのリソース配分の柔軟性を向上させること。
【解決手段】リソース管理プログラムは、コンピュータに、要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、特定された他のコンピュータに前記リソースの解放を要求し、要求に応じて解放されたリソースを確保する処理を実行させる。
【選択図】図５

Description

本発明は、リソース管理プログラム、リソース管理方法、及び情報処理装置に関する。

オンラインシステムにおいて、システム全体の処理能力を増強するため、複数のアプリケーションサーバを並列に稼動させ、業務処理に必要な同時実行多重度を増やすことが行われている。

アプリケーションサーバを並列に稼動させる場合、各アプリケーションサーバは等価にされるのが一般的である。等価とは、例えば、同じ設定に基づいて同じ業務処理を実行することをいう。各アプリケーションサーバが等価であれば、クライアントからのリクエストがいずれのアプリケーションサーバによって処理されても同様の結果が得られる。また、各アプリケーションサーバの運用管理を簡易化できるといったメリットも有る。

特に、Ｗｅｂアプリケーションを運用するようなオンラインシステムにおいて、各アプリケーションサーバは、通常、セッションという概念によって区切られる、ログインからログアウトまでの一連の操作を継続的に処理する。

各セッション内で行われる業務処理の内容は、必ずしも均一とはならない。例えば、オンラインショッピングでは、利用者によって購入される商品数がばらばらであったり、購入までの所要時間もばらばらであったりする。このような利用者に依存した不均一さが、並列かつ等価に配置されたアプリケーションサーバ間での処理内容に不均一さを生じさせる。

そこで、セッション数や処理数等、各種の指標に基づいて負荷分散を行ったり、セッションをアプリケーションサーバ間で共有したりすることで、アプリケーションサーバ間の負荷の均一化が図られている。

他方において、クライアントからのリクエストに応答するため、各アプリケーションサーバが、バックエンドに配置されたデータベースサーバ等の他のサーバ（以下、「バックエンドサーバ」という。）と連携して処理を実行するといった構成も採用されている。各アプリケーションサーバがバックエンドサーバと連携する場合、各アプリケーションサーバによって、バックエンドサーバに関するリソースが共用される。バックエンドサーバに関するリソースの一例としてバックエンドサーバとの通信用のコネクションが挙げられる。通常、このようなリソースは有限である。すなわち、バックエンドサーバとのコネクション数には上限が有る。したがって、有限のリソースを、各アプリケーションにどのように配分するかが問題となる。

アプリケーションサーバに対するリソースの配分方法として、各アプリケーションサーバの最大負荷を想定し、最大負荷において必要であると推定される分のリソースを、各アプリケーションサーバに予め配分しておくといった方法が有る。または、各アプリケーションサーバは、リソースが必要になったときに必要な分だけリソースの配分を受けるといった方法も有る。

特開２００２−４１３０４号公報 特開２００６−２０９２９４公報 特許第３６７２２３６号公報

しかしながら、各アプリケーションサーバの処理内容を完全に均一化することは困難である。処理内容に偏りが発生した場合、各アプリケーションサーバが必要とするリソース数にはばらつきが生じうる。

したがって、最大負荷に応じた分のリソースが予め配分される場合、負荷の軽いアプリケーションサーバではリソースが余っているにも拘わらず、想定した最大負荷を超えたアプリケーションサーバにおいては、リソースが不足してしまうといった可能性がある。

また、必要なときに必要な分だけリソースが配分される場合、高負荷のアプリケーションサーバによって上限分のリソースが先に確保されてしまい、後からリソースを必要とするアプリケーションサーバはリソースが不足してしまう可能性がある。

そこで、一側面では、複数のコンピュータへのリソース配分の柔軟性を向上させることを目的とする。

一態様のリソース管理プログラムは、コンピュータに、要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、特定された他のコンピュータに前記リソースの解放を要求し、要求に応じて解放されたリソースを確保する処理を実行させる。

一態様によれば、複数のコンピュータへのリソース配分の柔軟性を向上させることができる。

本発明の実施の形態における情報処理システムの構成例を示す図である。 本発明の実施の形態における情報処理システムの論理構成を示す図である。 本発明の実施の形態におけるアプリケーションサーバのハードウェア構成例を示す図である。 本発明の実施の形態におけるアプリケーションサーバの機能構成例を示す図である。 リソース管理部の機能構成例を示す図である。 リソースの払い出し要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。 リソース管理テーブルの構成例を示す図である。 リソース状態記憶部の構成例を示す図である。 不使用リソースの解放要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。 リソースの回収要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理システムの構成例を示す図である。図１に示される情報処理システム１において、複数のクライアント端末４０と、負荷分散装置３０と、複数のアプリケーションサーバ１０と、バックエンドサーバ２０とは、例えば、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク５０を介して通信可能とされている。図１では、アプリケーションサーバ１０の一例として、アプリケーションサーバ１０ａ、１０ｂ、及び１０ｃが示されている。また、クライアント端末４０の一例として、クライアント端末４０ａ、４０ｂ、及び４０ｃが示されている。各装置の機能については、図２を参照しつつ説明する。

図２は、本発明の実施の形態における情報処理システムの論理構成を示す図である。図２では、情報処理システム１に含まれる各装置間の論理的な関係が示されている。

クライアント端末４０は、アプリケーションサーバ１０に対して処理要求を送信するＰＣ（Personal Computer）、スマートフォン、携帯電話、タブレット型端末、又はＰＤＡ（Personal Digital Assistance）等の情報処理装置である。

負荷分散装置３０は、クライアント装置より送信された処理要求の転送先を、各アプリケーションサーバ１０の負荷が略均一化されるように選択し、選択されたアプリケーションサーバ１０に当該処理要求を転送する情報処理装置である。

アプリケーションサーバ１０は、負荷分散装置３０によって転送された処理要求に応じた処理を実行するコンピュータである。アプリケーションサーバ１０は、必要に応じてバックエンドサーバ２０と連携して処理要求に応じた処理を実行する。

バックエンドサーバ２０は、データベースサーバやレガシーシステム等、アプリケーションサーバ１０によって利用されるコンピュータ又はコンピュータシステムである。なお、本実施の形態では、アプリケーションサーバ１０とバックエンドサーバ２０との間のコネクションが、複数のアプリケーションサーバ１０によって共用されるリソース（資源）の一例とされる。アプリケーションサーバ１０とバックエンドサーバ２０との間のコネクションとは、アプリケーションサーバ１０がバックエンドサーバ２０と通信するために開設されるリソースである。同時に開設可能なコネクション数は有限であり、上限値が定められている。

図３は、本発明の実施の形態におけるアプリケーションサーバのハードウェア構成例を示す図である。図３のアプリケーションサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

アプリケーションサーバ１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってアプリケーションサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図４は、本発明の実施の形態におけるアプリケーションサーバの機能構成例を示す図である。図４に示されるように、各アプリケーションサーバ１０は、一以上の業務ロジック部１１、リソース管理部１２、及び分散キャッシュ実現部１３等を有する。これら各部は、各アプリケーションサーバ１０にインストールされた一以上のプログラムが、各アプリケーションサーバ１０のＣＰＵ１０４に実行させる処理により実現される。また、各アプリケーションサーバ１０は、リソース状態記憶部１４及び設定情報記憶部１５を有する。リソース状態記憶部１４及び設定情報記憶部１５は、例えば、各アプリケーションサーバ１０の補助記憶装置１０２を用いて実現可能である。但し、リソース状態記憶部１４は、情報を永続的に記憶する必要はないため、メモリ装置１０３を用いて実現されるのが好適である。また、設定情報記憶部１５は、各アプリケーションサーバ１０にネットワークを介して接続される記憶装置によって実現されてもよい。また、各アプリケーションサーバ１０に対して共通の記憶装置によって、一元的に設定情報記憶部１５が実現されてもよい。

業務ロジック部１１は、クライアント端末４０からの処理要求に応じた処理（例えば、業務ロジック等）を実行する。業務ロジック部１１は、要求の内容又は種類に応じて実行される処理内容ごとに複数存在してもよい。業務ロジック部１１は、例えば、ＷｅｂアプリケーションプログラムがＣＰＵ１０４に実行させる処理によって実現されてもよい。

リソース管理部１２は、業務ロジック部１１が使用するリソースの管理を行う。例えば、リソース管理部１２は、リソースの確保や解放等を実行する。また、リソース管理部１２は、当該アプリケーションサーバ１０におけるリソースの確保数が足りない場合、不使用リソースを確保している他のアプリケーションサーバ１０のリソース管理部１２に対してリソースの解放を要求し、解放されたリソースを確保する。不使用リソースとは、使用されていないリソースをいう。過去に使用されていたリソースであっても、現在使用されていなければ、不使用リソースに該当する。

なお、本実施の形態において、リソースの「確保」は、直ちにリソースの「使用」を意味しない。すなわち、リソースに関して、「確保」された状態と、「使用」されている状態とは必ずしも一致しない。リソースを使用したいアプリケーションサーバ１０は、まず、リソースを確保する必要がある。アプリケーションサーバ１０は、自らが確保しているリソースを使用することができる。したがって、リソースには、確保されているが不使用であるという状態が有る。本実施の形態では、このような状態のリソース分に関して、アプリケーションサーバ１０間の受け渡しを可能とする。

本実施の形態におけるリソースは、バックエンドサーバ２０とのコネクションであるため、リソースの確保は、バックエンドサーバ２０とのコネクションの開設に相当する。リソースの利用は、バックエンドサーバ２０との通信の実行に相当する。したがって、開設されているコネクションであって、通信に使用されていないコネクションは、確保されているが不使用であるリソースに相当する。

各アプリケーションサーバ１０の分散キャッシュ実現部１３は、論理的又は仮想的に複数のアプリケーションサーバ１０を跨いで分散キャッシュＣ１を実現する。分散キャッシュＣ１とは、複数のコンピュータを用いてキャッシュを実現する公知技術である。本実施の形態では、分散キャッシュＣ１を、複数のアプリケーションサーバ１０が情報共有するための手段として利用する。共有される情報は、後述されるリソース管理テーブル１６である。リソース管理テーブル１６は、アプリケーションサーバ１０ごとに、リソースの使用状況を示す情報を記憶するテーブルである。

リソース状態記憶部１４は、当該アプリケーションサーバ１０において確保されているリソースの状態を示す情報、すなわち、使用されているか不使用であるかを示す情報を記憶する。

設定情報記憶部１５は、バックエンドサーバ２０との連携に関する設定情報を記憶する。本実施の形態では、バックエンドサーバ２０とのコネクションの上限数を示す値（以下、「上限値」という。）が設定情報記憶部１５に記憶される。上限値は、複数のアプリケーションサーバ１０に対する上限値である。すなわち、複数のアプリケーションサーバ１０とバックエンドサーバ２０とのコネクションの合計数が、上限値を超えることはできない。

図５は、リソース管理部の機能構成例を示す図である。図５において、リソース管理部１２は、要求受付部１２１、不使用有無判定部１２２、確保部１２３、検索部１２４、解放要求部１２５、解放部１２６、払出部１２７、及び回収部１２８等を有する。

要求受付部１２１は、業務ロジック部１１からのリソースの払い出し要求を受け付ける。例えば、業務ロジック部１１は、バックエンドサーバ２０との通信を開始する際に、要求受付部１２１に対してリソースの払い出し、具体的には、バックエンドサーバ２０とのコネクションの使用を要求する。要求受付部１２１は、また、業務ロジック部１１からのリソースの回収要求をも受け付ける。例えば、業務ロジック部１１は、バックエンドサーバ２０との通信が終了した際に、当該リソースの回収を要求受付部１２１に要求する。

不使用有無判定部１２２は、当該アプリケーションサーバ１０において確保済みのリソースのうち、不使用リソースの有無を判定する。当該判定は、分散キャッシュＣ１に記憶されているリソース管理テーブル１６を参照して行われる。確保部１２３は、リソースの確保を実行する。すなわち、確保部１２３は、バックエンドサーバ２０とのコネクションを開設する。検索部１２４は、不使用リソースを確保している他のアプリケーションサーバ１０を検索する。当該検索は、リソース管理テーブル１６を参照して行われる。解放要求部１２５は、検索部１２４によって検索された他のアプリケーションサーバ１０に対して、不使用リソースの解放要求を送信する。解放部１２６は、他のアプリケーションサーバ１０からの不使用リソースの解放要求に応じ、不使用リソースを解放する。リソースの解放とは、リソースが確保されている状態を解消することをいう。本実施の形態において、リソースの解放は、バックエンドサーバ２０との間で開設されているコネクションの切断に相当する。払出部１２７は、リソースの払い出し要求に応じ、払い出し要求元に、確保済みのリソースを払い出す。リソースの払い出しとは、確保済みのリソースの使用を許可することをいう。例えば、リソースの払い出しでは、当該リソースを使用するために必要な識別子（以下、「リソースＩＤ」という。）等が払い出し要求元に返却される。

回収部１２８は、リソースの回収要求に応じ、当該リソースを回収する。回収されたリソースは、不使用リソースとなり、新たな払い出し要求に応じて払い出しが可能となる。

以下、アプリケーションサーバ１０のリソース管理部１２が実行する処理手順について説明する。図６は、リソースの払い出し要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、要求受付部１２１は、業務ロジック部１１より、リソースの払い出し要求を受け付ける。続いて、不使用有無判定部１２２は、当該アプリケーションサーバ１０に関して、確保済みであって、かつ、不使用であるリソースの有無を、リソース管理テーブル１６を参照して判定する（Ｓ１０２）。

図７は、リソース管理テーブルの構成例を示す図である。図７において、リソース管理テーブル１６は、アプリケーションサーバ１０ごとに、サーバ名、確保数、及び不使用数等を記憶する。サーバ名は、各アプリケーションサーバ１０の識別名である。本実施の形態において、「Ａ」、「Ｂ」、「Ｃ」は、それぞれ、アプリケーションサーバ１０ａ、アプリケーションサーバ１０ｂ、アプリケーションサーバ１０ｃのサーバ名であるとする。確保数は、確保済みのリソースの数である。不使用数は、不使用リソースの数である。したがって、（確保数−不使用数）は、使用されているリソースの数となる。

リソース管理テーブル１６は、分散キャッシュＣ１に配置されている。したがって、各アプリケーションサーバ１０は、論理的又は仮想的に共通のリソース管理テーブル１６を参照することになる。「論理的又は仮想的に共通」というのは、リソース管理テーブル１６にアクセスする側からは、物理的な配置位置を意識する必要はなく、複数のアプリケーションサーバ１０に対して一つのリソース管理テーブル１６が存在しているように見えるからである。

なお、リソース管理テーブル１６に記憶される情報が物理的にどのように配置されるかは、分散キャッシュ実現部１３の実装に依存する。例えば、分散キャッシュＣ１の実装形態の一例として、次のような形態が挙げられる。

第一の実装形態では、各アプリケーションサーバ１０のメモリ装置１０３にリソース管理テーブル１６の全部が記憶される。この場合、各アプリケーションサーバ１０の分散キャッシュ実現部１３は、いずれかのアプリケーションサーバ１０におけるリソース管理テーブル１６の更新を、自らのアプリケーションサーバ１０のリソース管理テーブル１６に反映するための処理を実行する。

第二の実装形態では、各アプリケーションサーバ１０のメモリ装置１０３には、当該アプリケーションサーバ１０に関する情報のみが記憶される。すなわち、図７に示される各行が、各アプリケーションサーバ１０のメモリ装置１０３に分散されて記憶される。この場合、各アプリケーションサーバ１０の分散キャッシュ実現部１３は、当該アプリケーションサーバ１０以外に記憶されている情報を、当該アプリケーションサーバ１０に記憶されているかのように見せかけるための処理を実行する。

なお、上記以外の実装形態によって分散キャッシュＣ１が実現されてもよい。

ステップＳ１０２において、当該アプリケーションサーバ１０が、アプリケーションサーバ１０ａ又はアプリケーションサーバ１０ｃである場合、不使用数は０である。したがって、この場合、ステップＳ１０２では、不使用リソースは無いと判定される。

不使用リソースが無い場合（Ｓ１０２でＹｅｓ）、確保部１２３は、リソース管理テーブル１６に記憶されている各アプリケーションサーバ１０の確保数の合計値が、設定情報記憶部１５に記憶されている上限値未満であるか否かを判定する（Ｓ１０３）。すなわち、新たなリソースの確保の可否が判定される。図７の例では、確保数の合計値は５＋１０＝１５である。したがって、例えば、上限値が１６以上である場合、ステップＳ１０３では、確保数の合計値は上限値未満であると判定される。

確保数の合計値が上限値未満である場合（Ｓ１０３でＹｅｓ）、確保部１２３は、リソース管理テーブル１６において、当該アプリケーションサーバ１０に対する確保数及び不使用数のそれぞれに１を加算する（Ｓ１０４、Ｓ１０５）。確保数に１が加算されるのは、後述のステップＳ１０６において確保される分を確保数に反映させるためである。不使用数に１が加算されるのは、確保されるリソースは、確保された時点では不使用であるため、斯かる状態を不使用数に反映させるためである。

続いて、確保部１２３は、新たにリソースを確保する（Ｓ１０６）。本実施の形態では、バックエンドサーバ２０との間に、新たなコネクションが開設される。確保部１２３は、確保されたリソースのＩＤ及び状態を、当該アプリケーションサーバ１０におけるリソース状態記憶部１４に記憶する。

図８は、リソース状態記憶部の構成例を示す図である。図８において、リソース状態記憶部１４は、当該アプリケーションサーバ１０において確保されているリソースごとに、リソースＩＤ及び状態を記憶する。状態は、「使用」又は「不使用」のいずれかである。ステップＳ１０６では、確保されたリソースは使用されていないため、状態には「不使用」が記憶される。

新たなリソースの確保に成功した場合（Ｓ１０７でＹｅｓ）、払出部１２７は、新たに確保されたリソースを、払い出し要求元の業務ロジック部１１に払い出す（Ｓ１０８）。払出部１２７は、リソース状態記憶部１４に記憶されている、払い出されたリソースの状態を、「不使用」から「使用」に更新する。すなわち、本実施の形態において、リソースが払い出された状態と使用状態とは等価である。また、リソースが回収された状態と不使用状態とは等価である。

続いて、払出部１２７は、当該アプリケーションサーバ１０に対す不使用数から１を減算する（Ｓ１０９）。不使用数から１が減算されるのは、リソースが業務ロジック部１１に払い出されるということは、当該リソースが使用されることを意味するからである。

ステップＳ１０６において、何らかの原因でリソースの確保に失敗した場合（Ｓ１０７でＮｏ）、確保部１２３は、リソース管理テーブル１６において、当該アプリケーションサーバ１０に対する確保数及び不使用数のそれぞれから１を減算する（Ｓ１１０、Ｓ１１１）。確保数及び不使用数のそれぞれから１が減算されるのは、リソースの確保の成功を見込んでステップＳ１０４及びＳ１０５において加算された分を解消するためのである。

続いて、払出部１２７は、払い出し要求元の業務ロジック部１１にエラーを返却する（Ｓ１１２）。但し、所定時間待機した後に、改めてステップＳ１０６以降が実行されてもよい。

一方、ステップＳ１０２において、不使用リソースが有る場合（Ｓ１０２でＹｅｓ）、ステップＳ１０３〜Ｓ１０７は実行されずに、ステップＳ１０８以降が実行される。ステップＳ１０８では、未使用リソースのうちの一つが、払い出し要求元の業務ロジック部１１に返却される。未使用リソースのリソースＩＤは、リソース状態記憶部１４を参照して特定することができる。

例えば、当該アプリケーションサーバ１０が、アプリケーションサーバ１０ｂである場合、図７に示されるように不使用数は１０である。したがって、この場合、ステップＳ１０２に続いて、ステップＳ１０８及びＳ１０９が実行される。

また、ステップＳ１０３において、各アプリケーションサーバ１０の確保数の合計値が上限値に達している場合（Ｓ１０３でＮｏ）、検索部１２４は、リソース管理テーブル１６を参照して、不使用数が１以上である他のアプリケーションサーバ１０を検索する（Ｓ１１３）。例えば、図７において、アプリケーションサーバ１０ｂの不使用数は、１０である。ここで、当該アプリケーションサーバ１０が、アプリケーションサーバ１０ａであり、かつ、設定情報記憶部１５に記憶されている上限値が、確保数の合計値と同じである１５であるとする。この場合、ステップＳ１１３では、不使用数が１以上である他のアプリケーションサーバ１０としてアプリケーションサーバ１０ｂが検索される。

該当する他のアプリケーションサーバ１０が検索された場合（Ｓ１１３でＹｅｓ）、解放要求部１２５は、当該他のアプリケーションサーバ１０のリソース管理部１２に対して不使用リソースの解放要求を送信する（Ｓ１１４）。続いて、解放要求の送信後、当該アプリケーションサーバ１０（解放要求を送信した側のアプリケーションサーバ１０）のリソース管理部１２は、所定時間待機する（Ｓ１１５）。続いて、ステップＳ１０３以降が繰り返される。すなわち、解放要求に応じて不使用リソースが解放されること、又は所定時間内のうちに、いずれかのアプリケーションサーバ１０において偶然的に不使用リソースが解放されることを期待して、ステップＳ１０３以降が再実行される。所定時間待機のうちに、不使用リソースが解放されていれば、ステップＳ１０４以降が実行される。

一方、不使用数が１以上である他のアプリケーションサーバ１０が無い場合（Ｓ１１３でＮｏ）、ステップＳ１１２が実行される。但し、この場合も、所定時間待機後、ステップＳ１０３以降が繰り返されてもよい。所定時間待機後に、不使用数が１以上である他のアプリケーションサーバ１０が発生するかもしれないからである。

なお、図７に示したリソース管理テーブル１６では、アプリケーションサーバ１０ごとに不使用数が記憶される例を示したが、ステップＳ１１３では、不使用リソースの有無が特定できればよい。したがって、リソース管理テーブル１６には、必ずしも不使用リソースの数まで記憶されなくてもよく、不使用リソースの有無を示す情報が記憶されてもよい。不使用数は、不使用リソースの有無を示す情報の一例であるといえる。

続いて、ステップＳ１１４において送信される不使用リソースの解放要求を受信したアプリケーションサーバ１０のリソース管理部１２によって実行される処理について説明する。

図９は、不使用リソースの解放要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。

他のアプリケーションサーバ１０より送信された不使用リソースの解放要求が受信されると（Ｓ２０１）、解放部１２６は、リソース管理テーブル１６を参照して、当該アプリケーションサーバ１０の不使用数は１以上であるか否かを確認する（Ｓ２０２）。例えば、アプリケーションサーバ１０ａからアプリケーションサーバ１０ｂに対して不使用リソースの解放要求が送信された場合、図９の説明における当該アプリケーションサーバ１０は、アプリケーションサーバ１０ｂである。

不使用数が１以上である場合（Ｓ２０２でＹｅｓ）、解放部１２６は、リソース管理テーブル１６において、当該アプリケーションサーバ１０に対する確保数及び不使用数のそれぞれから１を減算する（Ｓ２０３、Ｓ２０４）。続いて、解放部１２６は、不使用リソースの一つを解放する（Ｓ２０５）。本実施の形態では、バックエンドサーバ２０とのコネクションの一つが切断される。当該アプリケーションサーバ１０においていずれが不使用リソースであるかは、当該アプリケーションサーバ１０のリソース状態記憶部１４を参照することにより特定可能である。解放部１２６は、リソースの解放に伴って、当該リソースに対応するレコードを、リソース状態記憶部１４より削除する。なお、ステップＳ２０３及びＳ２０４における減算は、ステップＳ２０５における不使用リソースの解放に対応したものである。

解放要求に応じて不使用リソースが解放されることにより、確保数の合計値は、上限値未満となる。したがって、解放要求元のアプリケーションサーバ１０において、新たなリソースを確保できる可能性が高まる。すなわち、不使用リソースの解放を要求したアプリケーションサーバ１０は、不使用リソースを解放したアプリケーションサーバ１０に対するリソースの割り当て分を譲り受けることができる。

一方、不使用リソースが無い場合（Ｓ２０２でＮｏ）、ステップＳ２０３以降は実行されない。

続いて、リソースの払い出し先の業務ロジック部１１からリソースの回収要求が受け付けられた際にリソース管理部１２が実行する処理手順について説明する。

図１０は、リソースの回収要求に応じてリソース管理部が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、要求受付部１２１は、業務ロジック部１１より、リソースの回収要求を受け付ける。例えば、回収要求には、回収対象のリソースのリソースＩＤが指定される。続いて、回収部１２８は、リソース管理テーブル１６において、当該アプリケーションサーバ１０に対する不使用数に１を加算する（Ｓ３０２）。リソースの回収により、不使用リソースが増加するからである。続いて、回収部１２８は、回収対象のリソースを回収する（Ｓ３０３）。具体的には、当該アプリケーションサーバ１０のリソース状態記憶部１４において、回収対象のリソースのリソースＩＤに対応する状態を、「使用」から「不使用」に更新する。

上述したように、本実施の形態によれば、或るアプリケーションサーバ１０においてリソース不足が発生した場合、すなわち、リソースを確保しようとしたときに、確保数の合計値が上限値に達していた場合、他のアプリケーションサーバ１０の不使用リソースが解放される。リソース不足のアプリケーションサーバ１０は、解放されたリソースを確保することができる。すなわち、アプリケーションサーバ１０間において、不使用リソースの受け渡しを実現することができる。したがって、各アプリケーションサーバ１０へのリソース配分の柔軟性を向上させることができる。その結果、例えば、クライアント端末４０からのリクエストに応じた処理について、アプリケーションサーバ１０間で偏りが生じ、各アプリケーションサーバ１０が必要とするリソースがばらついたとしても、各アプリケーションサーバ１０が安定した応答を行える可能性を高めることができる。

また、各アプリケーションサーバ１０が、最大負荷を想定して予め過大なリソースを確保しておく必要性を低減させることができる。

また、各アプリケーションサーバ１０に対して共通のリソース管理テーブル１６には、各アプリケーションサーバ１０のリソースの使用状況が記憶される。したがって、リソース不足となったアプリケーションサーバ１０は、リソース管理テーブル１６を参照して、未使用のリソースを確保している他のアプリケーションサーバ１０を迅速に検索することができる。

また、リソース管理テーブル１６に各アプリケーションサーバ１０のリソースの確保数が記憶されることで、各アプリケーションサーバ１０は、確保数の合計値を把握することができる。したがって、各アプリケーションサーバ１０は、当該合計値と上限値とを比較することで、新たなリソースの可否を迅速に判定することができる。なお、リソースの確保数は、必ずしも各アプリケーションサーバ１０に対して共通のリソース管理テーブル１６に記憶されていなくてもよい。但し、その場合、各アプリケーションサーバ１０には、リソースの確保に失敗することにより、リソース不足を検出するといった負荷の高い処理の実行が要求される。本実施の形態では、斯かる処理の発生を回避することができる。

また、本実施の形態では、アプリケーションサーバ１０の数に依存した設定値が各アプリケーションサーバ１０に設定される必要性は小さい。したがって、システム管理に必要なコストの削減を期待することができる。アプリケーションサーバ１０の数に依存した設定値の一例としては、予めアプリケーションサーバ１０ごとに、リソース確保数が割り当てられる場合の割当数が挙げられる。割当数は、例えば、リソースの上限値÷アプリケーションサーバ１０の数といった演算により求められる。したがって、アプリケーションサーバ１０の数に依存した設定値であるといえる。

また、本実施の形態では、特定のサーバによって集中的に制御が行われるのではなく、各アプリケーションサーバ１０が、能動的に処理を実行する。したがって、特定のサーバの動作不正等による制御不能といった事態の発生を回避することができる。

なお、本実施の形態におけるリソース管理テーブル１６は、必ずしも分散キャッシュＣ１を用いて実現されなくてもよい。各プリケーションサーバから物理的に共通にアクセス可能な記憶装置にリソース管理テーブル１６が記憶されてもよい。但し、分散キャッシュＣ１は確立された技術であり、そのアクセス性能も高い。したがって、分散キャッシュＣ１を利用することで、リソース管理テーブル１６の操作性を向上させることができる。

また、リソースは、コネクションに限られない。例えば、複数のアプリケーションサーバ１０によって共用される記憶装置であってもよい。この場合、各アプリケーションサーバ１０は、確保済みであって未使用の記憶領域を、他のアプリケーションのために解放するようにしてもよい。

更に、リソースは、ハードウェア資源及びソフトウェア資源のいずれであってもよい。

なお、本実施の形態において、アプリケーションサーバ１０は、コンピュータ又は情報処理装置の一例である。不使用有無判定部１２２は、判定部の一例である。検索部１２４は、特定部の一例である。解放要求部１２５は、要求部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
コンピュータに、
要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、
前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、
特定された他のコンピュータに前記リソースの解放を要求し、
要求に応じて解放されたリソースを確保する、
処理を実行させるリソース管理プログラム。
（付記２）
前記特定する処理は、前記リソースを共用する複数のコンピュータのリソースの確保数の合計値が、前記リソースの上限数に達している場合であって、前記コンピュータにおいて前記不使用リソースが無い場合に、不使用リソースを確保している他のコンピュータを特定する付記１記載のリソース管理プログラム。
（付記３）
前記コンピュータと前記リソースを共用する他のコンピュータからの前記リソースの解放の要求に応じ、前記コンピュータが確保済みのリソースのうちの不使用リソースを解放する処理を前記コンピュータに実行させる付記１又は２記載のリソース管理プログラム。
（付記４）
コンピュータが、
要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、
前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、
特定された他のコンピュータに前記リソースの解放を要求し、
要求に応じて解放されたリソースを確保する、
処理を実行するリソース管理方法。
（付記５）
前記特定する処理は、前記リソースを共用する複数のコンピュータのリソースの確保数の合計値が、前記リソースの上限数に達している場合であって、前記コンピュータにおいて前記不使用リソースが無い場合に、不使用リソースを確保している他のコンピュータを特定する付記４記載のリソース管理方法。
（付記６）
前記コンピュータと前記リソースを共用する他のコンピュータからの前記リソースの解放の要求に応じ、前記コンピュータが確保済みのリソースのうちの不使用リソースを解放する処理を前記コンピュータが実行する付記４又は５記載のリソース管理方法。
（付記７）
情報処理装置であって、
要求に応じて実行する処理において使用するリソースを共用する複数の情報処理装置それぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記情報処理装置における不使用リソースの有無を判定する判定部と、
前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他の情報処理装置を特定する特定部と、
特定された他の情報処理装置に前記リソースの解放を要求する要求部と、
要求に応じて解放されたリソースを確保する確保部とを有する情報処理装置。
（付記８）
前記特定部は、前記リソースを共用する複数の情報処理装置のリソースの確保数の合計値が、前記リソースの上限数に達している場合であって、前記情報処理装置において前記不使用リソースが無い場合に、不使用リソースを確保している他の情報処理装置を特定する付記７記載の情報処理装置。
（付記９）
前記情報処理装置と前記リソースを共用する他の情報処理装置からの前記リソースの解放の要求に応じ、前記情報処理装置が確保済みのリソースのうちの不使用リソースを解放する解放部を有する付記７又は８記載の情報処理装置。

１ 情報処理システム
１０ アプリケーションサーバ
１１ 業務ロジック部
１２ リソース管理部
１３ 分散キャッシュ実現部
１４ リソース状態記憶部
１５ 設定情報記憶部
１６ リソース管理テーブル
２０ バックエンドサーバ
３０ 負荷分散装置
４０ クライアント端末
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１２１ 要求受付部
１２２ 不使用有無判定部
１２３ 確保部
１２４ 検索部
１２５ 解放要求部
１２６ 解放部
１２７ 払出部
１２８ 回収部
Ｂ バス
Ｃ１ 分散キャッシュ

Claims (5)

1. コンピュータに、
   要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、
   前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、
   特定された他のコンピュータに前記リソースの解放を要求し、
   要求に応じて解放されたリソースを確保する、
   処理を実行させるリソース管理プログラム。
2. 前記特定する処理は、前記リソースを共用する複数のコンピュータのリソースの確保数の合計値が、前記リソースの上限数に達している場合であって、前記コンピュータにおいて前記不使用リソースが無い場合に、不使用リソースを確保している他のコンピュータを特定する請求項１記載のリソース管理プログラム。
3. 前記コンピュータと前記リソースを共用する他のコンピュータからの前記リソースの解放の要求に応じ、前記コンピュータが確保済みのリソースのうちの不使用リソースを解放する処理を前記コンピュータに実行させる請求項１又は２記載のリソース管理プログラム。
4. コンピュータが、
   要求に応じて実行する処理において使用するリソースを共用する複数のコンピュータそれぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記コンピュータにおける不使用リソースの有無を判定し、
   前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他のコンピュータを特定し、
   特定された他のコンピュータに前記リソースの解放を要求し、
   要求に応じて解放されたリソースを確保する、
   処理を実行するリソース管理方法。
5. 情報処理装置であって、
   要求に応じて実行する処理において使用するリソースを共用する複数の情報処理装置それぞれの、確保済みのリソースのうちの不使用リソースの有無を示す情報を参照して、前記情報処理装置における不使用リソースの有無を判定する判定部と、
   前記不使用リソースが無い場合に、前記情報を参照して、不使用リソースを確保している他の情報処理装置を特定する特定部と、
   特定された他の情報処理装置に前記リソースの解放を要求する要求部と、
   要求に応じて解放されたリソースを確保する確保部とを有する情報処理装置。

Images