JP2017215901A - 情報処理装置、情報処理システム及びプログラム - Google Patents

Abstract

【課題】リソース量不足によりサービス性能が低下する前にリソース量の増加を図ることを可能とする。【解決手段】操作情報受信部３１は、クライアント装置２０の操作情報送信部２１から送信されてきた、クライアント装置２０の操作内容を示す情報である操作情報を受信する。リソース変更指示部３５は、リソース不足判定部３３により、操作情報受信部３１により受信された複数のクライアント装置２０における操作内容の情報の累積値が、リソース情報取得部３４により取得されたリソース量に対応して格納装置内の性能低下予測条件ＤＢに格納されている性能低下アクセス数等の閾値を超えると判定された場合、そのＷｅｂサーバ装置に対してリソース量を増加するよう指示する。【選択図】図３

Description

本発明は、情報処理装置、情報処理システム及びプログラムに関する。

特許文献１には、要求属性に合致する属性のサーバ装置の中から、実行対象プログラムの実行に適したリソースを持つサーバ装置を選択することで、ウェブサービスを提供するためのリソースコストを最適化するようにした情報処理装置が開示されている。

特許文献２には、サーバの応答時間から動的にリソースの過不足を判断して、リソースの再配分を行うサービス提供システムが開示されている。

特開２００７−２９３６０３号公報 特開２０１２−１３７８６５号公報

サービスの提供を行っているサーバ装置では、処理負荷に応じて使用するＣＰＵ、メモリ、ＨＤＤ等のハードウェアリソース（ハードウェア資源）量を増減することが行われている。

しかし、リソース量不足を検出してからリソース量の増加を行うような構成では、例えば、サービスを利用するクライアント装置の数が急激に増加したような場合、利用者にとっては一時的にサービス性能が低下してしまうことになる。

本発明の目的は、資源（リソース）量不足によりサービス性能が低下する前に資源（リソース）量の増加を図ることが可能な情報処理装置、情報処理システム及びプログラムを提供することである。

［情報処理装置］
請求項１に係る本発明は、クライアント装置から操作内容の情報を受信する受信手段と、
サーバ装置が使用している現在の資源量の情報を取得する取得手段と、
前記受信手段により受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得手段により取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示手段とを備えた情報処理装置である。

請求項２に係る本発明は、前記閾値が、予め定められた時間内に前記サーバ装置に接続するアクセス数である請求項１記載の情報処理装置である。

請求項３に係る本発明は、前記閾値が、前記複数のクライアント装置から前記サーバ装置に送信されるデータのデータ量である請求項１記載の情報処理装置である。

請求項４に係る本発明は、ネットワークを介してサービスを提供しているサーバ装置と、
前記サーバ装置により提供されるサービスを利用する複数のクライアント装置と、
前記複数のクライアント装置から操作内容の情報をそれぞれ受信する受信手段と、前記サーバ装置が使用している現在の資源量の情報を取得する取得手段と、前記受信手段により受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得手段により取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示手段とを備えた情報処理装置とを有する情報処理システムである。

請求項５に係る本発明は、前記複数のクライアント装置が、資源量が不足するか否かの判定対象となる操作内容の情報のみを前記情報処理装置に送信する請求項４記載の情報処理システムである。

[プログラム]
請求項６に係る本発明は、クライアント装置から操作内容の情報を受信する受信ステップと、
サーバ装置が使用している現在の資源量の情報を取得する取得ステップと、
前記受信ステップにおいて受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得ステップにおいて取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示ステップとをコンピュータに実行させるためのプログラムである。

請求項１〜３に係る本発明によれば、資源量不足によりサービス性能が低下する前に資源量の増加を図ることが可能な情報処理装置を提供することができる。

請求項４に係る本発明によれば、資源量不足によりサービス性能が低下する前に資源量の増加を図ることが可能な情報処理システムを提供することができる。

請求項５に係る本発明によれば、クライアント装置から情報処理装置に送信される情報量を削減して、情報処理装置における処理負担を軽減することが可能な情報処理システムを提供することができる。

請求項６に係る本発明によれば、資源量不足によりサービス性能が低下する前に資源量の増加を図ることが可能なプログラムを提供することができる。

本発明の一実施形態の情報処理システムのシステム構成を示す図である。 本発明の一実施形態におけるリソース管理装置１０のハードウェア構成を示すブロック図である。 本発明の一実施形態におけるリソース管理装置１０の機能構成を示すブロック図である。 サービス情報管理ＤＢの一例を示す図である。 リソースタイプ管理ＤＢの一例を示す図である。 クライアント操作情報管理ＤＢの一例を示す図である。 性能低下予測条件管理ＤＢの一例を示す図である。 クライアント装置２０においてＷｅｂサーバ装置４１へのユーザ登録操作が行われる際に、リソース管理装置１０、Ｗｅｂサーバ装置４１に情報が送信されるタイミング例を説明するためのシーケンスチャートである。 ユーザ登録画面の一例を示す図である。 本発明の一実施形態のリソース管理装置１０におけるリソース不足判定処理を説明するためのフローチャートである。 ファイル選択画面の一例を示す図である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

図１は本発明の一実施形態の情報処理システムの構成を示すブロック図である。

本発明の一実施形態の情報処理システムは、図１に示されるように、インターネット等のネットワーク３０により相互に接続されたリソース管理装置（情報処理装置）１０、複数のクライアント装置２０およびＷｅｂサーバ装置（アプリケーションサーバ装置）４１〜４３により構成される。

なお、本実施形態では、説明を簡単にするために３台のＷｅｂサーバ装置４１〜４３がクライアント装置２０に対してサービスを提供している場合を用いて説明するが、本発明はこのような構成に限定されるものではない。

Ｗｅｂサーバ装置４１〜４３は、ネットワーク３０を介してクライアント装置２０に対して各種サービスを提供するサーバ装置である。

具体的には、Ｗｅｂサーバ装置４１は、ホスト名が「ａａａ」となっており、データ管理サービスを提供している。また、Ｗｅｂサーバ装置４２は、ホスト名が「ｂｂｂ」となっており、チケット売買サービスを提供している。また、Ｗｅｂサーバ装置４３は、ホスト名が「ｃｃｃ」となっており、宿泊予約サービスを提供している。

そして、クライアント装置２０は、ネットワーク３０経由にてＷｅｂサーバ装置４１〜４３にアクセスして、Ｗｅｂサーバ装置４１〜４３により提供される各種サービスを利用している。

なお、リソース管理装置１０は、Ｗｅｂサーバ装置４１〜４３のＣＰＵ、メモリ、ＨＤＤ（Hard Disc Drive）等のリソース量（資源量）を管理（監視）しており、Ｗｅｂサーバ装置４１〜４３に対して使用するリソース量の増減を指示している。

次に、本実施形態の情報処理システムにおけるリソース管理装置１０のハードウェア構成を図２に示す。

リソース管理装置１０は、図２に示されるように、ＣＰＵ１１、メモリ１２、ハードディスクドライブ（ＨＤＤ）等の記憶装置１３、ネットワーク３０を介してクライアント装置２０、Ｗｅｂサーバ装置４１〜４３等の外部装置との間でデータの送信及び受信を行う通信インタフェース（ＩＦ）１４を有する。これらの構成要素は、制御バス１６を介して互いに接続されている。

ＣＰＵ１１は、メモリ１２または記憶装置１３に格納された制御プログラムに基づいて所定の処理を実行して、リソース管理装置１０の動作を制御する。なお、本実施形態では、ＣＰＵ１１は、メモリ１２または記憶装置１３内に格納された制御プログラムを読み出して実行するものとして説明したが、当該プログラムをＣＤ−ＲＯＭ等の記憶媒体に格納してＣＰＵ１１に提供することも可能である。

図３は、上記の制御プログラムが実行されることにより実現されるリソース管理装置１０の機能構成を示すブロック図である。

本実施形態のリソース管理装置１０は、図３に示されるように、操作情報受信部３１と、格納装置３２と、リソース不足判定部３３と、リソース情報取得部３４と、リソース変更指示部３５とを備えている。

また、クライアント装置２０は、操作情報送信部２１を備えている。さらに、Ｗｅｂサーバ装置４１〜４３は、それぞれ、リソース制御部５１と、ＣＰＵ、メモリ、ＨＤＤ等のリソース５２を備えている。

ここでリソースとは、Ｗｅｂサーバ装置４１における処理を実現するために利用されるＣＰＵ数、メモリ容量、ストレージ容量、マシン数等のハードウェア資源を意味する。

操作情報送信部２１は、クライアント装置２０におけるユーザの操作履歴、操作画面等の操作情報を、サービスの提供を行っているＷｅｂサーバ装置４１〜４３のリソースを管理しているリソース管理装置１０に送信する。

この操作情報送信部２１は、クライアント装置２０内に送信用アプリケーションプログラム（以下、アプリと略す。）がインストールされることにより実現される。

例えば、Ｗｅｂサーバ装置４１〜４３から提供されるサービスを利用するためのアプリをクライアント装置２０内にインストールする際に、ユーザ自身がクライアント装置２０内に送信用アプリをインストールするようにしても良いし、サービスを利用するためのアプリを最初に使用した際に送信用アプリを自動的にクライアント装置２０にインストールするようにしても良い。

また、クライアント装置２０内にサービスを利用するためのアプリをインストールせずにサービスの利用を行うクライアント仮想化環境を利用するような場合には、送信用アプリをクライアント仮想化環境にインストールして操作情報送信部２１を実現する。

なお、操作情報送信部２１が操作情報をリソース管理装置１０に送信するタイミングとしては、下記の（１）〜（３）に示すようないずれかのタイミングを用いることができる。

（１）操作情報送信部２１からリソース管理装置１０に対して、例えば、１秒毎または１分毎のような一定期間ごとに、その一定期間内に操作された情報を操作情報として送信する。操作情報送信部２１は、例えば、現在表示されている画面内容の情報や、入力フォームに対して入力している情報等を操作情報として送信する。

このようなタイミングで操作情報の送信が行われる場合には、あるページが表示されている状態で変化が無い場合でも、そのページが表示されているという情報が一定期間毎にリソース管理装置１０に送信されることになる。

（２）操作情報送信部２１からリソース管理装置１０に対して、最小単位の操作が行われたタイミングで操作情報を送信する。ここで、最小単位の操作とは、クライアント装置２０においてユーザが行う意味のある１つの操作を意味する。例えば、アプリを起動する、テキストフォームに入力する、画面遷移（ＨＴＴＰ（Hyper Text Transfer Protocol）リクエスト）を行う等の操作が最小単位の操作に相当する。

このようなタイミングで操作情報の送信が行われる場合には、何も操作が行われなければ操作情報は送信されないため、例えばマウスが移動されただけ等の情報は送信されない。

（３）操作情報送信部２１は、Ｗｅｂサーバ装置４１〜４３により提供されるサービス内容に性能低下が発生する可能性のある性能低下予測対象の操作内容の情報、つまり、リソース量が不足するか否かの判定対象となる操作内容の情報のみをリソース管理装置１０に送信する。

このようなタイミングで操作情報の送信が行われる場合には、性能低下予測対象でない操作内容の情報についてはリソース管理装置１０に送信されないため、操作情報送信部２１からリソース管理装置１０に送信される情報量は、上記の（１）、（２）に示した場合よりも削減されることになる。

操作情報受信部３１は、クライアント装置２０の操作情報送信部２１から送信されてきた、クライアント装置２０の操作内容を示す情報である操作情報を受信する。

格納装置３２は、サービス情報管理ＤＢ（データベース）、リソースタイプ管理ＤＢ、クライアント操作情報管理ＤＢ、性能低下予測条件管理ＤＢを格納している。

サービス情報管理ＤＢには、リソース管理装置１０がリソース量の管理を行っているＷｅｂサーバ装置４１〜４３の情報が保存されている。

このサービス情報管理ＤＢの一例を図４に示す。図４に示したサービス情報管理ＤＢでは、Ｗｅｂサーバ装置４１〜４３のサービスＩＤ、ホスト名、サービス名、ＩＰアドレス、現在使用しているリソースのリソースタイプが保存されている。

例えば、データ管理サービスを提供しているＷｅｂサーバ装置４１については、サービスＩＤが「１２００１」、ホスト名が「ａａａ」、ＩＰアドレスが「10.0.0.1」、現在のリソースタイプは「Ａ」というように登録されている。

次に、格納装置３２に格納されるリソースタイプ管理ＤＢの一例を図５に示す。図５に示したリソースタイプ管理ＤＢには、リソースタイプ毎に、ＣＰＵ数、メモリ容量、ストレージ容量、マシン数等のリソース情報が保存されている。

図４に示したサービス情報管理ＤＢにおける現在のリソースタイプは、このリソースタイプ管理ＤＢにおけるリソースタイプに対応しており、サービス情報管理ＤＢとリソースタイプ管理ＤＢを参照することにより、Ｗｅｂサーバ装置４１〜４３の現在のリソース状況を把握することができるようになっている。

リソース情報取得部３４は、Ｗｅｂサーバ装置４１〜４３が使用している現在のリソース量の情報を取得し、格納装置３２内のサービス情報管理ＤＢのリソースタイプを更新する。

また、格納装置３２に格納されるクライアント操作情報管理ＤＢの一例を図６に示す。図６に示したクライアント操作情報管理ＤＢは、操作情報受信部３１により受信された操作情報を管理するためのデータベースである。図６に示した例では、クライアント操作情報管理ＤＢには、クライアント端末装置２０のＩＰアドレス、接続先のホスト名、操作内容（開いている画面内容）、日時、入力フォームへの入力が行われているか否かを示す入力有無の情報が保存される。

なお、このクライアント操作情報管理ＤＢでは、保存されたデータは、保存後から例えば３０分間のような一定期間経過後に順次削除されていく。つまり、このクライアント操作情報管理ＤＢには、過去一定期間内におけるクライアント装置２０の操作内容が保存されることになる。

次に、格納装置３２に格納される性能低下予測条件管理ＤＢの一例を図７に示す。図７に示した性能低下予測条件管理ＤＢには、予測条件ＩＤ、サービスＩＤ、リソースタイプ、操作内容、処理詳細、性能低下アクセス数、性能低下データ容量、リソース増加方法の情報が保存されている。

この性能低下予測条件管理ＤＢは、Ｗｅｂサーバ装置４１〜４２毎に、使用しているリソース量に対応して、提供するサービス内容に性能低下が発生すると予測される閾値が、予め設定されて格納されている。

図７では、Ｗｅｂサーバ装置４１〜４３に同時接続するアクセス数の上限値である性能低下アクセス数が閾値として設定されている。ここで同時接続するアクセス数とは、予め定められた時間内にＷｅｂサーバ装置４１〜４３に接続するアクセス数である。また、複数のクライアント装置２０からＷｅｂサーバ装置４１〜４３に送信されるデータのデータ量の上限値である性能低下データ容量が閾値として設定されている。

例えば、サービスＩＤが「１２００１」のＷｅｂサーバ装置４１については、使用するリソースのリソースタイプが「Ａ」の場合、ユーザ登録の操作内容については、性能低下アクセス数が「１０００」であると設定されている。

つまり、Ｗｅｂサーバ装置４１は、リソースタイプが「Ａ」のリソースを用いてサービスの提供を行っている場合、ユーザ登録のアクセス数が１０００を超えると提供するサービス内容に性能低下が発生することが予測されるものとして登録されている。

そして、同じＷｅｂサーバ装置４１について、リソースタイプが「Ｂ」のリソースを用いてサービスの提供を行っている場合、ユーザ登録のアクセス数が２０００を超えると提供するサービス内容に性能低下が発生することが予測されるものとして登録されている。

この性能低下予測条件管理ＤＢにおける性能低下予測条件は、ユーザが任意のタイミングで予め登録しておく。図７に示したユーザ登録のような操作内容については、「ユーザ登録画面を開く」→「テキストフォームに文字列を入力する」→「登録ボタンを押す」というようにユーザの操作が想定し易すく、負荷テスト等を行うことにより性能低下が予測される閾値を設定しやすい。

なお、この性能低下予測条件管理ＤＢにおける性能低下予測条件は、サービス低下中に実際に処理性能の低下が発生した場合に、その時の過去のクライアント装置２０の操作情報から一連の操作履歴を解析して、新しい性能低下予測条件として自動的に登録されるようにしても良い。

このように性能低下予測条件が自動的に登録されるようにすることにより、一度性能低下が発生した場合、２回目以降に同一の条件が発生した場合でも、性能低下が予測されてリソース量の増加が行われることになる。

リソース不足判定部３３は、操作情報受信部３１により受信された複数のクライアント装置２０における操作内容の情報の累積値が、リソース情報取得部３４により取得されたリソース量に対応して格納装置内の性能低下予測条件ＤＢに格納されている性能低下アクセス数等の閾値を超えるか否かを判定する。

リソース変更指示部３５は、リソース不足判定部３３により、操作情報受信部３１により受信された複数のクライアント装置２０における操作内容の情報の累積値が、リソース情報取得部３４により取得されたリソース量に対応して格納装置内の性能低下予測条件ＤＢに格納されている性能低下アクセス数等の閾値を超えると判定された場合、そのＷｅｂサーバ装置に対してリソース量を増加するよう指示する。

例えば、リソース変更指示部３５は、Ｗｅｂサーバ装置４１がリソースタイプ「Ａ」のリソースを用いてサービスを行っていて、このＷｅｂサーバ装置４１に対するユーザ登録のアクセス数の合計が１０００を超えた場合、Ｗｅｂサーバ装置４１に対してリソース量をリソースタイプＡからＢに増加するよう指示を行う。

リソース制御部５１は、リソース管理装置のリソース変更指示部３５からのリソース増加指示に基づいて、使用するリソース５２のリソース量を増加させる。

次に、図８のシーケンスチャートを参照して、クライアント装置２０においてＷｅｂサーバ装置４１へのユーザ登録操作が行われる際に、リソース管理装置１０、Ｗｅｂサーバ装置４１に情報が送信されるタイミング例を説明する。

例えば、図９に示すように、クライアント装置２０においてＷｅｂサーバ装置４１にユーザ登録するためのユーザ登録画面が開かれた場合(ステップＳ１０１)、クライアント装置２０からリソース管理装置１０に対してユーザ登録画面が開かれたという内容の操作情報が送信される(ステップＳ１０２)。

すると、リソース管理装置１０では、そのクライアント装置２０からの操作情報に基づいてリソース量不足が発生することが予測されるか否かが判定される(ステップＳ１０３)。

そして、クライアント装置２０において、開かれたユーザ登録画面においてテキストフォーマットに文字列が入力されると(ステップＳ１０４)、クライアント装置２０からリソース管理装置１０に対してテキストフォームに文字列が入力されたという内容の操作情報が送信される(ステップＳ１０５)。

すると、リソース管理装置１０では、そのクライアント装置２０からの操作情報に基づいてリソース量不足が発生することが予測されるか否かが判定される(ステップＳ１０６)。

そして、最後にクライアント装置２０においてユーザ登録画面への入力が完了して登録ボタンが押されると（ステップＳ１０７）、クライアント装置２０からＷｅｂサーバ装置４１に対して登録情報が送信される(ステップＳ１０８)。

この図８に示したシーケンスチャートを見ると分かるように、クライアント装置２０からＷｅｂサーバ装置４１に対して登録情報が送信される前に、リソース管理装置１０では、Ｗｅｂサーバ装置４１においてリソース量不足が発生するか否かの予測が行われている。

そして、図８では示されていないが、Ｗｅｂサーバ装置４１においてリソース量不足が発生するとリソース管理装置１０が予測した場合、登録情報がクライアント装置２０から送信される前に、リソース管理装置１０からＷｅｂサーバ装置４１に対して、リソース量の増加が指示される。

次に、本実施形態のリソース管理装置１０におけるリソース不足判定処理を図１０のフローチャートを参照して説明する。

なお、この図１０のフローチャートでは、性能低下アクセス数を閾値としてリソース量不足の判定を行う場合について説明する。

クライアント装置２０の操作情報送信部２１からリソース管理装置１０に送信された操作情報は、クライアント操作情報管理ＤＢとして格納装置３２に保存されている。

そして、リソース管理装置１０では、リソース不足判定部３３は、クライアント操作情報管理ＤＢから保存してある操作情報のうち過去一定期間内に行われた操作情報を取得する（ステップＳ２０１）。

ここで、リソース不足判定部３３は、例えば１分毎のような一定期間毎に操作情報を取得してリソース不足判定を行っても良いし、クライアント装置２０から一定量の操作情報が送信された場合に操作情報を取得してリソース不足判定を行っても良い。また、リソース不足判定部３３は、性能低下判定処理対象の操作情報がクライアント装置２０から送信されてきた場合に、クライアント操作情報管理ＤＢから操作情報を取得してリソース不足判定を行っても良い。

そして、リソース不足判定部３３は、取得した操作情報を分析して、操作内容が性能低下予測条件管理ＤＢに保存されているものであるか否かの判定を行う（ステップＳ２０２）。

取得した操作情報の操作内容が、性能低下予測条件管理ＤＢに保存されたものでなかった場合（ステップＳ２０２においてｎｏ）、リソース不足判定部３３は、ステップＳ２０１の処理に戻る。

取得した操作情報の操作内容が性能低下予測条件管理ＤＢに保存されたものである場合（ステップＳ２０２においてｙｅｓ）、リソース不足判定部３３は、操作内容がある性能低下予測条件のサービスＩＤを特定して、サービスＩＤが特定された判定対象サービスの現在のリソースタイプをサービス情報管理ＤＢから取得する（ステップＳ２０３）

次に、リソース不足判定部３３は、性能低下予測条件ＤＢから、判定対象サービスの取得したリソースタイプに対応した性能低下アクセス数を取得する（ステップＳ２０４）。

そして、リソース不足判定部３３は、サービス情報管理ＤＢから取得した操作情報に基づいて判定対象サービスに対する現在のアクセス数を算出し、算出した現在のアクセス数と取得した性能低下アクセス数を比較する（ステップＳ２０５）。

現在のアクセス数が性能低下アクセス数以下の場合（ステップＳ２０５においてｎｏ）、リソース不足判定部３３は、ステップＳ２０１の処理に戻る。

そして、現在のアクセス数が性能低下アクセス数を超えた場合（ステップＳ２０５においてｙｅｓ）、リソース不足判定部３３は、リソース量の増加が必要であると判定して、性能低下予測条件ＤＢからリソース量の増加方法を取得する。すると、リソース変更指示部３５は、Ｗｅｂサーバ装置４１〜４３のうちの判定対象サービスを提供しているＷｅｂサーバ装置に対してリソース増加方法とともにリソース量を増加する旨の指示を行う（ステップＳ２０６）。

なお、図１０に示したフローチャートでは、性能低下アクセス数を用いてリソース不足判定処理を行う場合について説明したが、図７に示したような性能低下データ容量を用いてリソース不足判定処理を行う場合も同様な処理により実現することができる。

ただし、性能低下データ容量を用いてリソース不足判定処理を行う場合には、クライアント装置２０がＷｅｂサーバ装置に送信しようとするデータ量の合計値と、性能低下データ容量を比較してリソース不足が発生するか否かの判定が行われる。

例えば、リソース管理装置１０では、図１１に示すようなクライアント装置２０の表示画面情報を取得して、これからアップロードしようとするファイル容量の合計値を算出する。図１１は、ファイル選択画面の一例を示す図であり、リソース管理装置１０では、このような操作情報に基づいてアップロードしようとするファイル容量の合計値を算出する。そして、リソース不足判定部３３は、算出されたファイル容量の合計値が性能低下データ容量を超えた場合には、リソース不足が発生する可能性があると判定する。

１０ リソース管理装置
１１ ＣＰＵ
１２ メモリ
１３ 記憶装置
１４ 通信インタフェース（ＩＦ）
１６ 制御バス
２０ クライアント装置
２１ 操作情報送信部
３０ ネットワーク
３１ 操作情報受信部
３２ 格納装置
３３ リソース不足判定部
３４ リソース情報取得部
３５ リソース変更指示部
４１〜４３ Ｗｅｂサーバ装置（ＡＰサーバ装置）
５１ リソース制御部
５２ リソース

Claims (6)

1. クライアント装置から操作内容の情報を受信する受信手段と、
   サーバ装置が使用している現在の資源量の情報を取得する取得手段と、
   前記受信手段により受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得手段により取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示手段と、
   を備えた情報処理装置。
2. 前記閾値が、予め定められた時間内に前記サーバ装置に接続するアクセス数である請求項１記載の情報処理装置。
3. 前記閾値が、前記複数のクライアント装置から前記サーバ装置に送信されるデータのデータ量である請求項１記載の情報処理装置。
4. ネットワークを介してサービスを提供しているサーバ装置と、
   前記サーバ装置により提供されるサービスを利用する複数のクライアント装置と、
   前記複数のクライアント装置から操作内容の情報をそれぞれ受信する受信手段と、前記サーバ装置が使用している現在の資源量の情報を取得する取得手段と、前記受信手段により受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得手段により取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示手段とを備えた情報処理装置と、
   を有する情報処理システム。
5. 前記複数のクライアント装置は、資源量が不足するか否かの判定対象となる操作内容の情報のみを前記情報処理装置に送信する請求項４記載の情報処理システム。
6. クライアント装置から操作内容の情報を受信する受信ステップと、
   サーバ装置が使用している現在の資源量の情報を取得する取得ステップと、
   前記受信ステップにおいて受信された複数のクライアント装置における操作内容の情報の累積値が、前記取得ステップにおいて取得された資源量に対応して設定された閾値を超えた場合、当該サーバ装置に対して資源量を増加するよう指示する指示ステップとをコンピュータに実行させるためのプログラム。