JP6654467B2

JP6654467B2 - ユーザ収容管理システムおよびユーザ収容管理方法

Info

Publication number: JP6654467B2
Application number: JP2016036688A
Authority: JP
Inventors: 山田　剛史; 剛史山田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-02-29
Filing date: 2016-02-29
Publication date: 2020-02-26
Anticipated expiration: 2036-02-29
Also published as: JP2017156791A

Description

本発明は、ユーザ収容管理システムおよびユーザ収容管理方法に関する。

従来、柔軟なサービス提供やシステム有効活用等のために、ユーザに対し直接的にサービス提供を行うＡＰＬ（アプリケーション）サーバ等のサービス提供機能部と、複数のサービスの加入者データを一元的に収容管理するデータユーザ収容管理システムとして機能するデータベースサーバ等のデータベース機能部が分離したデータ分離型システムが知られている。このようなデータ分離型システムにおいて、サービス提供機能部は、ユーザに対しサービスの提供を行う際には、データベース機能部との間でデータ授受やデータ操作を行う。

サービス提供機能部で提供されるサービスは、それぞれ運用期間や販促状況、サービス内容が異なるため、加入者数や処理量がそれぞれ異なる。また、処理量は、時間経過とともに販促や加入者増減にともない変動するため、処理量が一部のサービス提供機能部の処理可能な量を超過し、その結果、サービス品質の低下が発生する場合がある。

これに対し、ネットワークの帯域制御を、処理量の変動に応じて動的に行う技術が知られている（例えば特許文献１）。また、図１１に示すように、ＡＰＬサーバの処理量がサービス品質を低下させない限界値を超えた際に、処理量が少ないＡＰＬサーバへ、手動でユーザの収容替えを行う方法も考えられる。図１１は、従来の管理方法を示す図である。

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

しかしながら、従来の方法では、処理量の変動によるＡＰＬサーバのサービス品質低下をメンテナンスフリーに維持することが困難であるという問題があった。

例えば、ネットワークの帯域制御を、処理量の変動に応じて動的に行う方法では、ＡＰＬサーバにおいて送受信されるデータ量を調整することはできるが、送受信されるデータ量の調整だけでは、処理量を低減することができない場合があるため、処理量の変動によるＡＰＬサーバのサービス品質低下をメンテナンスフリーに維持することができない場合がある。

また、ＡＰＬサーバの処理量がサービス品質を低下させない限界値を超えた際に、処理量が少ないＡＰＬサーバへ手動でユーザの収容替えを行う方法では、ユーザ数が急に増加した場合に、収容替えが行われるまでの間、サービス品質低下を避けることができない場合があり、処理量の変動によるＡＰＬサーバのサービス品質低下をメンテナンスフリーに維持することができない場合がある。

本発明のユーザ収容管理システムは、データベースとして機能するデータ管理システムとの間におけるデータの授受およびデータの操作と、収容しているユーザへのサービスの提供と、を行う複数のアプリケーションサーバの処理量を定期的に取得する取得部と、前記取得部によって取得された処理量を基に、前記複数のアプリケーションサーバそれぞれについて所定の処理量を計算する計算部と、前記複数のアプリケーションサーバそれぞれの処理量が、前記計算部によって計算された所定の処理量を基に、前記ユーザの収容先のアプリケーションサーバを変更させる指示部と、を有することを特徴とする。

また、本発明のユーザ収容管理方法は、データベースとして機能するデータ管理システムとの間におけるデータの授受およびデータの操作と、収容しているユーザへのサービスの提供と、を行う複数のアプリケーションサーバの処理量を定期的に取得する取得工程と、前記取得工程によって取得された処理量を基に、前記複数のアプリケーションサーバそれぞれについて所定の処理量を計算する計算工程と、前記複数のアプリケーションサーバそれぞれの処理量が、前記計算工程によって計算された所定の処理量を基に、前記ユーザの収容先のアプリケーションサーバを変更させる指示工程と、を含んだことを特徴とする。

本発明によれば、処理量の変動によるＡＰＬサーバのサービス品質低下をメンテナンスフリーに維持することが可能となる。

図１は、第１の実施形態に係るユーザ収容管理システムの構成の一例を示す図である。図２は、ＡＰＬサーバの現状の処理量の一例を示す図である。図３は、ＡＰＬサーバの理想の処理量の一例を示す図である。図４は、第１の実施形態の収容替え方法について説明するための図である。図５は、第１の実施形態に係るユーザ収容管理システムの処理の流れを示すフローチャートである。図６は、第２の実施形態の収容替え方法について説明するための図である。図７は、第２の実施形態の収容替え方法について説明するための図である。図８は、第２の実施形態の収容替え方法について説明するための図である。図９は、ユーザ収容管理システムのその他の構成の一例を示す図である。図１０は、プログラムが実行されることにより、ユーザ収容管理システムとして機能するデータベースサーバが実現されるコンピュータの一例を示す図である。図１１は、従来の管理方法を示す図である。

以下に、本願に係るユーザ収容管理システムおよびユーザ収容管理方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本発明が限定されるものではない。

［第１の実施形態］
まず、図１を用いて第１の実施形態に係るユーザ収容管理システムの構成について説明する。図１は、第１の実施形態に係るユーザ収容管理システムの構成の一例を示す図である。図１に示すように、ユーザ収容管理システム２００は、ＡＰＬサーバ１、２および３とネットワーク等を介して接続されている。また、各ＡＰＬサーバは、ユーザの端末に対しサービスの提供を行う。

なお、ユーザ収容管理システム２００と接続されるＡＰＬサーバの数は、図１のように３つでなくてもよく、任意の数でよい。また、ユーザ収容管理システム２００は、ＡＰＬサーバ１、２および３によってデータの授受および操作が行われるデータ管理システムであるデータベースサーバ１００の機能として実現されているものとする。なお、ユーザ収容管理システム２００は、データベースサーバ１００と接続された他の装置として実現されてもよい。

また、図１に示すように、各ＡＰＬサーバには所定のユーザが収容されている。なお、以降の説明において、ユーザが端末からアプリケーションに対してサービスの提供を要求した際、当該サービスの提供の要求は、ＡＰＬサーバのうち、当該ユーザが収容されているＡＰＬサーバに対して送信されるものとする。そして、ユーザの端末からサービス提供の要求を受けたＡＰＬサーバは、データベースサーバ１００に対しデータの授受や操作を行い、また、ＡＰＬサーバ内で所定の処理を行うことでサービスを提供する。

また、ユーザからのサービス提供の要求を、収容先のＡＰＬサーバへ振り分ける方法としては、ユーザの端末にインストールされたアプリケーションのクライアントに、収容先のＡＰＬサーバのアドレスをサービス要求コマンドの送信先として設定しておく方法や、ユーザの端末と各ＡＰＬサーバとを接続するネットワークに備えられたルータ等によってルーティングを行う方法が考えられる。

図１に示すように、ユーザ収容管理システム２００は、取得部２０１、計算部２０２および指示部２０３を有する。取得部２０１は、ＡＰＬサーバの処理量を定期的に取得する。取得部２０１は、各ＡＰＬサーバのデータベースサーバ１００への単位時間当たりのデータ操作要求量を監視することで処理量を取得する。なお、取得部２０１は、処理量の取得を１時間単位や１日単位等のあらかじめ定められた期間ごとに行ってもよい。

また、各ＡＰＬサーバは、データベースサーバ１００との間でのデータ操作を行わず、各ＡＰＬサーバとユーザの端末間で完結する処理については、当該処理の処理量をデータベースサーバ１００に通知する。そして、取得部２０１は、ＡＰＬサーバによって通知された処理量を取得する。なお、各ＡＰＬサーバは、このような処理量を、データベースサーバ１００への操作要求信号に埋め込むことで通知するようにしてもよい。

計算部２０２は、取得部２０１によって取得された処理量を基に、ユーザの収容先のＡＰＬサーバを決定する際の基準となる基準処理量を計算する。ここで、図２を用いて、取得部２０１によって取得されたＡＰＬサーバの処理量について説明する。図２は、ＡＰＬサーバの現状の処理量の一例を示す図である。図２は、取得部２０１がＡＰＬサーバ１〜１２の１２個のＡＰＬサーバから処理量を取得した場合の例を示している。

図２より、ＡＰＬサーバ１、５、８および１１の処理量が性能限界に近いことが分かる。また、図２より、ＡＰＬサーバ７および１０は処理量が少ないことが分かる。これより、従来、例えばＡＰＬサーバ１、５、８および１１が収容しているユーザの一部を手動でＡＰＬサーバ７および１０に移動させ、ＡＰＬサーバ１、５、８および１１の処理量を低減させることが行われていた。

一方、第１の実施形態においては、計算部２０２により理想の処理量の計算が行われる。計算部２０２は、例えば、基準処理量として、複数のＡＰＬサーバの処理量の平均、すなわち理想の処理量を計算する。計算部２０２がこの方法で理想の処理量の計算を行った結果を図３に示す。図３は、ＡＰＬサーバの理想の処理量の一例を示す図である。図３より、ＡＰＬサーバ１、５、８および１１の処理量が理想の処理量を超えていることが分かる。

指示部２０３は、複数のＡＰＬサーバそれぞれの処理量が基準処理量となるように、理想の処理量を基に、ユーザの収容先のＡＰＬサーバを変更する。指示部２０３は、例えば図４に示す方法でユーザの収容替えを行う。図４は、第１の実施形態の収容替え方法について説明するための図である。

指示部２０３は、例えば以下の方法で、複数のＡＰＬサーバそれぞれの処理量が、理想の処理量となるように、ユーザの収容先のＡＰＬサーバを変更する。すなわち、指示部２０３は、まず、処理量が理想の処理量を超えているＡＰＬサーバのうち、最も番号が小さいＡＰＬサーバを選択する。次に、指示部２０３は、選択したＡＰＬサーバが収容しているユーザの収容先を、処理量が理想の処理量を超えていないＡＰＬサーバのうち、最も番号が小さいＡＰＬサーバに変更させる。指示部２０３は、これらの処理を、計算部２０２によって計算された処理量が理想の処理量を超えているＡＰＬサーバの全てについて繰り返し行う。

ここで、図５を用いて、ユーザ収容管理システム２００の処理の流れを説明する。図５は、第１の実施形態に係るユーザ収容管理システムの処理の流れを示すフローチャートである。図５に示すように、ユーザ収容管理システム２００の取得部２０１は、各ＡＰＬサーバの処理量を取得する（ステップＳ１０１）。次に、ユーザ収容管理システム２００の計算部２０２は、例えば全ＡＰＬサーバの処理量を計算することにより、ＡＰＬサーバの理想の処理量を計算する（ステップＳ１０２）。そして、ユーザ収容管理システム２００の指示部２０３は、各ＡＰＬサーバの処理量が理想の処理量に近くなるように、ＡＰＬサーバに対し、ユーザの収容替えを指示する（ステップＳ１０３）。

［第１の実施形態の効果］
取得部２０１は、データベースとして機能するデータ管理システムとの間におけるデータの授受およびデータの操作と、収容しているユーザへのサービスの提供と、を行う複数のＡＰＬサーバの処理量を定期的に取得する。また、計算部２０２は、取得部２０１によって処理量が取得されるたびに、取得部２０１によって取得された処理量を基に、ユーザの収容先のＡＰＬサーバを決定する際の基準となる基準処理量を計算する。また、指示部２０３は、計算部２０２によって基準処理量が計算されるたびに、基準処理量を基に、ユーザの収容先のＡＰＬサーバを変更する。

このように、定期的にＡＰＬサーバの処理量を取得し、取得した処理量に基づいてユーザの収容替えを行うことで、ＡＰＬサーバが限界性能に達する前に事前に対策を行うことができる。その結果、処理量の変動によるＡＰＬサーバのサービス品質低下をメンテナンスフリーに維持することができる。

また、例えば、計算部２０２は、基準処理量として、複数のＡＰＬサーバの処理量の平均を計算する。このとき、指示部２０３は、複数のＡＰＬサーバそれぞれの処理量が、基準処理量となるように、ユーザの収容先のＡＰＬサーバを変更する。これにより、処理量が多いＡＰＬサーバの負荷を処理量が少ないＡＰＬサーバに負担させることができ、ＡＰＬサーバの処理量が性能限界に達することを防止することができる。

［第２の実施形態］
ＡＰＬサーバによって性能限界が異なることが考えられる。そこで、第２の実施形態では、ＡＰＬサーバごとの処理量、性能限界になる処理量と現在の処理量との差である空容量、および性能限界になる処理量を超えた分の処理量である超過量を管理する。

第２の実施形態では、取得部２０１は、各ＡＰＬサーバの現在の処理量、および、性能限界に達する処理量としてあらかじめ設定された限界処理量をさらに取得する。そして、計算部２０２は、取得部２０１によって取得された処理量が限界処理量を超えていないＡＰＬサーバについて、限界処理量から取得部２０１によって取得された処理量を引くことで空容量を基準処理量として計算し、また、取得部２０１によって取得された処理量が限界処理量を超えているＡＰＬサーバについて、取得部２０１によって取得された処理量から限界処理量を引くことで超過量を基準処理量として計算する。

図６に示すように、ＡＰＬサーバ１、２、４、５は空容量を有し、性能限界に達していない。一方、ＡＰＬサーバ３には超過量が存在しており、性能限界を超えていると考えられる。図６は、第２の実施形態の収容替え方法について説明するための図である。

そして、指示部２０３は、超過量が存在するＡＰＬサーバに収容されているユーザの収容先を、空容量が存在するＡＰＬサーバに変更する。具体的に、指示部２０３は、超過量が存在するＡＰＬサーバから空き容量が最も多いＡＰＬサーバにユーザの収容替えを行うように指示する。例えば、指示部２０３は、ＡＰＬサーバ３からＡＰＬサーバ４へユーザの収容替えを行うように指示する。

さらに、指示部２０３は、指示部２０３によって変更後の収容先とされたＡＰＬサーバの処理量が所定量以下になった場合、指示部２０３によって収容先が変更されたユーザの収容先のＡＰＬサーバを、変更前のＡＰＬサーバに戻す。例えば、図７に示すように、指示部２０３は、ＡＰＬサーバ３からＡＰＬサーバ４に収容替えされたユーザの収容先を、ＡＰＬサーバ３に戻すように指示する。図７は、第２の実施形態の収容替え方法について説明するための図である。

このようなＡＰＬサーバの処理量の減少は、図８に示すように、サービスＳ３のユーザ数が減少すること等によって発生する。図８は、第２の実施形態の収容替え方法について説明するための図である。ここで、収容替え前には、サービスＳ３はＡＰＬサーバ３によって提供されていたところ、収容替えによって、サービスＳ３はＡＰＬサーバ３および４によって提供されるようになったものとする。

そして、図８に示すように、収容替え時から所定時間経過後に、サービスＳ３のユーザ数が減少し、サービスＳ３を再びＡＰＬサーバ３のみによって提供可能となった場合、指示部２０３は、ＡＰＬサーバ４のユーザのＡＰＬサーバ３への収容替えを指示する。

［第２の実施形態の効果］
取得部２０１は、複数のＡＰＬサーバそれぞれについて、性能限界に達する処理量としてあらかじめ設定された限界処理量をさらに取得する。そして、計算部２０２は、取得部２０１によって取得された処理量が限界処理量を超えていないＡＰＬサーバについて、限界処理量から取得部２０１によって取得された処理量を引くことで空容量を基準処理量として計算し、また、取得部２０１によって取得された処理量が限界処理量を超えているＡＰＬサーバについて、取得部２０１によって取得された処理量から限界処理量を引くことで超過量を基準処理量として計算する。このとき、指示部２０３は、超過量が存在するＡＰＬサーバに収容されているユーザの収容先を、空容量が存在するＡＰＬサーバに変更する。これにより、ＡＰＬサーバによって性能限界となる処理量が異なる場合であっても、ＡＰＬサーバの処理量が性能限界に達することを防止することができる。

さらに、指示部２０３は、指示部２０３によって変更後の収容先とされたＡＰＬサーバの処理量が所定量以下になった場合、指示部２０３によって収容先が変更されたユーザの収容先のＡＰＬサーバを、変更前のＡＰＬサーバに戻す。ユーザを本来と異なるＡＰＬサーバに収容した場合、サーバ間での処理が増加する場合がある。そのため、このように、収容替えの必要がなくなった際には、ユーザの収容先を元のＡＰＬサーバに戻すことにより、サーバ間の処理増加を最小限にとどめることができる。

［その他の実施形態］
本発明のユーザ収容管理システムは、上記の実施形態に限定されない。例えば、図９に示すように、ユーザ収容管理システム２００には、ルーティング制御部２０４がさらに備えられていてもよい。図９は、ユーザ収容管理システムのその他の構成の一例を示す図である。なお、ルーティング制御部２０４は、例えばルータ等のネットワーク機器によって実現される。

ルーティング制御部２０４は、ユーザがサービスの提供を受ける端末が、複数のＡＰＬサーバのいずれに接続するかを決定する。そして、指示部２０３は、ルーティング制御部２０４に、端末の接続先のＡＰＬサーバを変更させることによって、ユーザの収容先のＡＰＬサーバを変更する。これにより、ユーザの端末の設定等を変更することなく、収容替えを実現することができる。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵ（Central Processing Unit）および当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
一実施形態として、ユーザ収容管理システムは、パッケージソフトウェアやオンラインソフトウェアとして上記の処理量の管理を実行する管理プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の管理プログラムを情報処理装置に実行させることにより、情報処理装置をユーザ収容管理システムとして機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistant）等のスレート端末等がその範疇に含まれる。

また、ユーザ収容管理システムは、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の処理量の管理に関するサービスを提供するサーバ装置として実装することもできる。例えば、ユーザ収容管理システムは、ＡＰＬサーバの処理量を入力とし、処理量の平滑化の結果を出力とする管理サービスを提供するサーバ装置として実装される。この場合、ユーザ収容管理システムは、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の管理に関するサービスを提供するクラウドとして実装することとしてもかまわない。

図１０は、プログラムが実行されることにより、ユーザ収容管理システムとして機能するデータベースサーバが実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、データベースサーバの各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、データベースサーバにおける機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid State Drive）により代替されてもよい。

また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３およびプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３およびプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１、２、３ＡＰＬサーバ
１００データベースサーバ
２００ユーザ収容管理システム
２０１取得部
２０２計算部
２０３指示部
２０４ルーティング制御部

Claims

データベースとして機能するデータ管理システムとアプリケーションサーバとを有するシステムにおいて、
前記データ管理システムとの間におけるデータの授受およびデータの操作と、収容しているユーザへのサービスの提供と、を行う複数の前記アプリケーションサーバの前記データ管理システムとの間の処理量と前記ユーザがサービスの提供を受ける端末との間の処理量とを定期的に取得する取得部と、
前記取得部によって処理量が取得されるたびに、前記取得部によって取得された処理量を基に、前記ユーザの収容先のアプリケーションサーバを決定する際の基準となる基準処理量を計算する計算部と、
前記計算部によって前記基準処理量が計算されるたびに、前記基準処理量を基に、前記ユーザの収容先のアプリケーションサーバを変更する指示部と、
前記ユーザがサービスの提供を受ける端末が、前記複数のアプリケーションサーバのいずれに接続するかを決定するルーティング制御部と、を有し、
前記指示部は、前記ルーティング制御部に、前記端末の接続先のアプリケーションサーバを変更させることによって、前記ユーザの収容先のアプリケーションサーバを変更し、前記指示部によって変更後の収容先とされたアプリケーションサーバの処理量が所定量以下になった場合、前記指示部によって収容先が変更されたユーザの収容先のアプリケーションサーバを、変更前のアプリケーションサーバに戻すことを特徴とするユーザ収容管理システム。
前記計算部は、前記基準処理量として、前記複数のアプリケーションサーバの処理量の平均を計算し、
前記指示部は、前記複数のアプリケーションサーバそれぞれの処理量が、前記基準処理量となるように、前記ユーザの収容先のアプリケーションサーバを変更することを特徴とする請求項１に記載のユーザ収容管理システム。
前記取得部は、前記複数のアプリケーションサーバそれぞれについて、性能限界に達する処理量としてあらかじめ設定された限界処理量をさらに取得し、
前記計算部は、前記基準処理量として、前記取得部によって取得された処理量が前記限界処理量を超えていないアプリケーションサーバについて、前記限界処理量から前記取得部によって取得された処理量を引くことで空容量を前記基準処理量として計算し、また、前記取得部によって取得された処理量が前記限界処理量を超えているアプリケーションサーバについて、前記取得部によって取得された処理量から前記限界処理量を引くことで超過量を前記基準処理量として計算し、
前記指示部は、前記超過量が存在するアプリケーションサーバに収容されているユーザの収容先を、前記空容量が存在するアプリケーションサーバに変更することを特徴とする請求項１に記載のユーザ収容管理システム。
データベースとして機能するデータ管理システムとアプリケーションサーバとを有するシステムにおいて、
前記データ管理システムとの間におけるデータの授受およびデータの操作と、収容しているユーザへのサービスの提供と、を行う複数の前記アプリケーションサーバの前記データ管理システムとの間の処理量と前記ユーザがサービスの提供を受ける端末との間の処理量とを定期的に取得する取得工程と、
前記取得工程によって処理量が取得されるたびに、前記取得工程によって取得された処理量を基に、前記ユーザの収容先のアプリケーションサーバを決定する際の基準となる基準処理量を計算する計算工程と、
前記計算工程によって計算が行われるたびに、前記基準処理量を基に、前記ユーザの収容先のアプリケーションサーバを変更する指示工程と、
前記ユーザがサービスの提供を受ける端末が、前記複数のアプリケーションサーバのいずれに接続するかを決定するルーティング制御工程と、を含み、
前記指示工程は、前記ルーティング制御工程に、前記端末の接続先のアプリケーションサーバを変更させることによって、前記ユーザの収容先のアプリケーションサーバを変更し、前記指示工程において変更後の収容先とされたアプリケーションサーバの処理量が所定量以下になった場合、前記指示工程において収容先が変更されたユーザの収容先のアプリケーションサーバを、変更前のアプリケーションサーバに戻すことを特徴とするユーザ収容管理方法。