JP2016184357A - 情報処理装置、プログラム及び情報処理方法 - Google Patents

Abstract

【課題】負荷がなくなった処理部をすぐに停止させる方式と比較して、処理要求への対応の遅れを少なくする。【解決手段】ＶＭ管理装置１４は、ログイン中のユーザが一人もいない起動状態のＶＭ１２があると、それを停止準備状態に遷移させる。停止準備状態のＶＭ１２は、ログイン要求もジョブも割り当てられないが、既に割り当てられたジョブは実行する。ログイン要求等の要求が来た際に、起動状態のＶＭ１２のすべてが上限までログインユーザやジョブを受け入れ済みの場合、停止準備中のＶＭ１２があればそれを起動状態に戻し、戻したＶＭ１２にその要求を割り当てる。停止準備状態のＶＭ１２は、時間のかかる起動処理を経なくても、単に状態を切り替えるだけで、起動状態に戻ることができるので、停止した処理部を起動する場合よりもその要求に早く応えることができる。【選択図】図１

Description

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

近年、クラウドコンピューティングサービスのように、サービス提供者の有するプロセッサやメモリ等の計算リソースをユーザに対して例えば課金方式等の形で利用させるシステムが普及しつつある。このようなサービスは、一般に、ユーザのための処理に用いる計算リソースを必要に応じて自動的に増減する、いわゆるオートスケーリング機能を有する。例えばＡｍａｚｏｎ ＥＣ２ (Elastic Compute Cloud)というクラウドサービスでは、ユーザに対してＥＣ２インスタンスと呼ぶ仮想マシンを割り当てるが、処理負荷に応じてそのインスタンスの数を自動的に増減する。一般的に、インスタンスの数を増加させることを「スケールアウト」、減少させることを「スケールイン」と呼んでいる。例えば、サービスの利用料金が使用するリソースの量に応じて定められている場合、処理負荷が低下したときに使用リソースの量を自動的に減らすことで、利用料金が節約される。

特許文献１に開示されたシステムでは、負荷情報収集部は、物理サーバと仮想サーバの負荷を収集して、各負荷を採取した時間に対応づけて、負荷情報として負荷情報テーブルに格納し、類似負荷情報選択部は、管理対象の負荷がスケールアウト閾値またはスケールイン閾値から外れたときに、現在時刻の負荷に類似する過去の負荷情報を負荷情報テーブルから選択し、スケールアウト判断部またはスケールイン判断部は、選択された負荷情報に従って管理対象の負荷が変化すると仮定して、管理対象の負荷が、その後も、いずれかの閾値から外れると予測したときには、スケールアウトまたはスケールインを実行する。

特開２０１１−１１８５２５号公報

１つ以上の処理部を負荷状況に応じて起動したり停止したりして処理能力を動的に調整するシステムでは、負荷がない処理部を停止させることが一般的である。しかし、負荷が増大してきて処理能力が足りなくなった場合、停止している処理部を起動することで処理能力を増大させるが、その起動のための処理にはある程度の時間がかかるので、負荷増大への対応が遅くなる。

本発明は、負荷がなくなった処理部をすぐに停止させる方式と比較して、処理要求への対応の遅れを少なくすることを目的とする。

請求項１に係る発明は、コンピュータを、処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部、各処理部の負荷状況の情報を保持する負荷状況保持手段、負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てる割り当て手段、負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行う状態制御手段、として機能させるためのプログラムである。

請求項２に係る発明は、前記処理には、ユーザからの接続要求を処理する接続処理と、データ処理要求に応じてデータを処理するデータ処理とがあり、前記負荷状況保持手段は、前記各処理部について、前記接続処理と前記データ処理のそれぞれの負荷状況の情報を保持し、前記状態制御手段は、前記接続処理の負荷がなくなった起動状態の処理部を停止準備状態に移行させる、ことを特徴とする請求項１に記載のプログラムである。

請求項３に係る発明は、前記割り当て手段は、到来した接続要求については、接続処理の負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した接続要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその接続要求を割り当てると共に、接続処理の負荷状況が上限負荷に達していない起動状態の処理部が複数ある場合は、それら複数のうちのデータ処理を実行していない処理部よりもデータ処理を実行中の処理部に優先的に前記接続要求を割り当てる、ことを特徴とする請求項２に記載のプログラムである。

請求項４に係る発明は、前記割り当て手段は、到来したデータ処理要求については、データ処理の負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来したデータ処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にそのデータ処理要求を割り当てると共に、データ処理の負荷状況が上限負荷に達していない起動状態の処理部が複数ある場合は、それら複数のうちの接続処理を実行していない処理部よりも接続処理を実行中の処理部に優先的に前記接続要求を割り当てる、ことを特徴とする請求項２又は３に記載のプログラムである。

請求項５に係る発明は、処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部と、各処理部の負荷状況の情報を保持する負荷状況保持手段と、負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てる割り当て手段と、負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行う状態制御手段と、を含む情報処理装置である。

請求項６に係る発明は、処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部を制御する方法であって、負荷状況保持手段が、各処理部の負荷状況の情報を保持するステップと、割り当て手段が、負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てるステップと、状態制御手段が、負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行うステップと、を含む情報処理方法である。

請求項１、５又は６に係る発明によれば、負荷がなくなった処理部をすぐに停止させる方式と比較して、処理要求への対応の遅れを少なくすることができる。

請求項２に係る発明によれば、接続処理よりも時間がかかる可能性が高いデータ処理が終わらない状況でも停止準備状態に移行することができ、停止状態への移行が行われやすくすることができる。

請求項３に係る発明によれば、データ処理を実行している処理部と実行していない処理部に差別無く割り当てる場合よりも、データ処理を実行していない処理部を停止準備状態に移行させやすくすることができる。

請求項４に係る発明によれば、接続処理を実行している処理部と実行していない処理部に差別無く割り当てる場合よりも、接続処理を実行していない処理部を停止準備状態に移行させやすくすることができる。

実施形態のシステム構成の一例を示す図である。 ＶＭ（仮想マシン）情報のデータ内容の一例を示す図である。 ＶＭの状態遷移を説明するための図である。 ジョブ情報のデータ内容の一例を示す図である。 ログイン要求の割り当て処理の手順の例を示す図である。 ジョブの割り当て処理の手順の例を示す図である。 スケールインのための制御の手順の例を示す図である。 実施形態の制御を行った場合に、ログイン要求及びジョブの振り分けや、オートスケールの具体的な進み方の例を示す図である。

図１を参照して、実施形態のシステム構成の例を説明する。

図１に示すジョブ処理システム１０は、ＰＣ（パーソナルコンピュータ）やモバイル端末等のクライアント３０を操作するユーザに対して、印刷ジョブを実行するというサービスを提供する。印刷ジョブ（以下単に「ジョブ」とも呼ぶ）とは、ユーザが指定した印刷対象の文書データをプリンタで印刷するために行うデータ処理である。ジョブ処理システム１０は、図示しないネットワークを介してクライアント３０から文書データを受け取り、その文書データをプリンタ（図示省略）で取扱可能なデータ形式の印刷データに変換し、変換結果の印刷データをネットワーク経由でプリンタに提供して印刷を実行させる。

ジョブ処理システム１０は、０以上のＶＭ（Virtual Machine：仮想マシン）１２を有しており、それらＶＭ１２がそれぞれユーザからの印刷指示に対応するジョブを実行する。ＶＭ１２は、例えば、ＩａａＳ（Infrastructure as a Service）プロバイダから提供されるインフラ上に構築されるものであってよい。なお同様に、後述するＶＭ管理装置１４、振り分け装置１６も、そのインフラ上に構築される仮想マシン上に構築されたものであってよく、共有ストレージ２０はそのインフラ上のストレージであってよい。

ＶＭ１２が実行するジョブ処理は、文書データを印刷データに変換する処理や、変換結果の印刷データをユーザから指定されたプリンタに送信する処理を含む。

個々のＶＭ１２は、割り当てられたジョブの処理の他に、ユーザからの要求を処理するユーザインタフェース処理も実行する。ユーザインタフェース処理には、ジョブ処理システム１０に対するユーザの接続（ログイン）の可否を判定するログイン処理、ジョブについてのパラメータ（例えば印刷部数等の印刷属性）の設定を受け付ける処理、ジョブの実行開始要求を受け付ける処理、ジョブの状態確認の要求を受け付けてジョブの状態情報をユーザに提供する処理等が含まれる。

この例では、ＶＭ１２がユーザ（クライアント３０）から受け付ける処理要求には、ログイン要求、ジョブ実行要求、ジョブ状態確認要求などがある。

クライアント３０からログイン要求を受けると、振り分け装置１６からそのログイン要求を割り当てられたＶＭ１２が、クライアント３０から受け取ったパスワード等のユーザ認証情報を用いてユーザのログインを認めるか否かを判定する。ログインが認められると、ユーザはジョブ処理システム１０に対してログインしている状態となる。ログイン状態のユーザからの要求は、ログインを受け付けたＶＭ１２が受け取って処理する。すなわち、ユーザは、そのＶＭ１２にログインしたと捉えることもできる。

ログイン状態において、例えば、ユーザ（クライアント３０）からそのＶＭ１２に印刷データや印刷パラメータの入力が行われる。すると、ＶＭ１２は一意なジョブ識別子を発行し、それら入力された情報をそのジョブ識別子に対応づけて共有ストレージ２０に保存する（ジョブ情報２４）。その後クライアント３０からそのＶＭ１２にジョブ実行要求が入力されると、ＶＭ１２は、そのジョブ識別子をキュー（印刷待ち行列：図示省略）の末尾に追加する。このキューは、例えば振り分け装置１６が管理している。キュー内のジョブは、振り分け装置１６によりいずれかのＶＭ１２に振り分け（割り当て）られる。ログイン要求やジョブ実行要求を受けたＶＭ１２が、その要求に係るジョブを実行するとは限らない。

ユーザは、キューに入れられたジョブの状態を確認したい場合、ジョブ状態の確認を要求する。これに応じて、クライアント３０からジョブ処理システム１０にジョブ状態確認要求が送られる。この要求を受け取ったシステム１０内のＶＭ１２は、その要求の対象であるジョブの現在の状態を示す情報をクライアント３０に返す。

ユーザが明示的にログアウトを要求した場合、または操作をしない状態が所定時間続いてタイムアウトとなった場合、ユーザのログイン状態は解除される。ログイン解除の後、ユーザがジョブ処理システム１０に対して要求を行う場合は、再度ログインを行う必要がある。例えば、ユーザがログインしてジョブを投入し、ジョブ実行要求を行った後、ログインが解除され、その後そのユーザがそのジョブの状態を知りたいと思った場合、そのユーザは再びログイン要求を行ってシステム１０にログインした上で、ジョブ状態確認要求を行う。

ＶＭ管理装置１４は、ＶＭ１２の管理を行う装置であり、例えば停止状態のＶＭ１２を起動したり、起動状態（すなわち稼働状態）のＶＭ１２を停止させたりする。例えばジョブ処理システム１０の運営者とＩａａＳプロバイダとの契約により、ジョブ処理システム１０内で起動状態のＶＭ１２の上限数が決まっている。起動状態のＶＭ１２だけでは負荷に十分対応できなくなった場合でも、起動状態のＶＭ数がその上限数に達していない場合には、停止状態のＶＭ１２を起動することでシステムの処理能力を高めることができる（スケールアウト）。また、システムの負荷が低下してきた場合、起動状態のＶＭ１２を停止させる（スケールイン）ことで、起動状態のＶＭ１２の数に応じたＩａａＳプロバイダの従量制課金を抑制できる。

振り分け装置１６は、ユーザからの要求を各ＶＭ１２に振り分ける（割り当てる）機能と、キュー内のジョブを各ＶＭ１２に振り分ける機能を有する。ユーザからの要求のうちログイン要求の振り分け先の決定手順については、後で具体例を挙げて説明する。ログイン後の要求（例えばジョブ実行要求やジョブ状態確認要求）については、従来からあるセッション維持技術を用いて、ログイン処理を行ったＶＭ１２に振り分けることで、セッション情報をＶＭ１２間で受け渡すためのオーバーヘッドをなくすようにしてもよい。振り分け装置１６のジョブ振り分けの処理についても、後で詳しく説明する。

共有ストレージ２０は、ＶＭ１２群、ＶＭ管理装置１４及び振り分け装置１６の間で共有される記憶装置である。共有ストレージ２０にはＶＭ情報２２とジョブ情報２４が記憶されており、ＶＭ１２群、ＶＭ管理装置１４及び振り分け装置１６はこれらの情報を参照しながら処理を進める。

図２にＶＭ情報２２のデータ内容の一例を示す。この例では、ＶＭ情報２２には、ＶＭ１２ごとに、そのＶＭ１２を一意に識別する「ＶＭ識別子」、そのＶＭ１２の「状態」 、そのＶＭ１２が同時に受付可能な「最大ユーザ数」、そのＶＭ１２に現在ログインしているユーザ数（「ログインユーザ数」）、現在ログインしているユーザのユーザ識別子のリスト（「ログインユーザ」）、そのＶＭ１２が並列的に実行可能な「最大ジョブ数」、そのＶＭ１２が現在実行しているジョブのジョブ識別子のリスト（「実行中ジョブ」）が登録されている。図２に示したテーブルの１つの行が、その行に対応するＶＭ１２の管理情報である。

「最大ジョブ数」及び「最大ユーザ数」は、個々のＶＭ１２の処理能力に応じてあらかじめ定められた値である。図示例ではこれらの値は全てのＶＭ１２で同じ値になっているが、ＶＭ１２毎に能力が異なる場合には、それらの値もＶＭ１２毎に異なってくる。

ＶＭ１２の「状態」として、前述の「起動」及び「停止」という状態の他に、「停止準備」状態がある。「起動」状態とは、ＶＭ１２が起動済みである状態、すなわちジョブやユーザインタフェース処理を実行可能な状態である。「停止」状態とは、ＶＭ１２が停止している状態である。ＶＭ情報２２内には「停止」状態のＶＭ１２の管理情報は存在するが、クラウドコンピューティングのインフラ上にはそのＶＭ１２は既に存在していない。「停止」状態のＶＭ１２（管理情報としてのみ存在）がジョブやユーザインタフェース処理（ユーザからの要求の受付等）を実行可能になるには、そのＶＭ１２を起動する起動処理が必要であり、この起動処理にはある程度の時間がかかる。「停止準備」状態とは、「起動」状態と「停止」状態の中間の状態であり、「停止」の準備段階である。この状態ではＶＭ１２はまだ停止しておらず、既に受け入れ済みのジョブを実行しているが、新たなジョブは受け入れないし、ユーザインタフェース処理も実行しない。新たなジョブの受け入れやユーザインタフェース処理を実行するには、ＶＭ１２は「起動」状態に復帰する必要がある。ただし、「停止準備」状態のＶＭ１２は、まだ停止していないので、起動処理を行わなくてもほぼ即座に「起動」状態に復帰し、新たなジョブやユーザインタフェース処理を実行することができる。

ＶＭ情報２２の内容は、ＶＭ管理装置１４、振り分け装置１６、及び各ＶＭ１２により随時更新される。例えばＶＭ管理装置１４がＶＭ１２の状態を遷移させた場合、ＶＭ情報２２内のそのＶＭ１２の「状態」が遷移後の値に更新される。また、振り分け装置１６がユーザからのログイン要求をいずれかのＶＭ１２に振り分けた場合、ＶＭ情報２２内のそのＶＭ１２の「ログインユーザ数」に１が加算される。また、ＶＭ１２がログイン処理を実行してユーザを認証した場合、そのユーザ識別子が「ログインユーザ」の欄に追加される。また、ＶＭ１２にログイン中のユーザがログアウトした場合、そのＶＭ１２の「ログインユーザ数」が１減算され、「ログインユーザ」の欄からそのユーザのユーザ識別子が削除される。また、振り分け装置１６がキュー内のジョブをいずれかのＶＭ１２に割り当て、そのＶＭ１２がそのジョブの実行を開始すると、そのＶＭ１２の「実行中ジョブ」の欄にそのジョブのジョブ識別子が追加される。そして、ＶＭ１２がジョブの実行を完了すると、「実行中ジョブ」の欄からそのジョブのジョブ識別子が削除される。

図３に、この例における「停止」、「起動」、「停止準備」の３状態間の状態遷移を示す。まず、「停止」から「起動」への遷移は、ジョブ処理システム１０の初期起動時又はＶＭ管理装置１４の管理下でのスケールアウト時に起こる。初期起動時は、あらかじめ定めた待機ＶＭの下限数のＶＭ１２が起動されて「起動」状態となる。この例では、ジョブ処理システム１０は、少なくともその下限数のＶＭ１２は常に「起動」（又は「停止準備」）状態としておくことで、ある程度の要求には即座に応えることができるようにしている。「起動」状態のＶＭ１２は、典型的には、ジョブ又はユーザインタフェース処理等を実行している。「起動」状態のＶＭ１２に対してログインしているユーザが無くなった場合、そのＶＭ２は「停止準備」状態に遷移する。「停止準備」状態のＶＭ１２は、ＶＭ管理装置１４からの停止準備解除指示に応じて「起動」状態に戻る。停止準備解除指示は、「起動」状態のＶＭ１２群の上限負荷（それらＶＭ１２の最大ユーザ数又は最大ジョブ数の総和）を超える場合に発行される。また「停止準備」状態に遷移してから、停止準備解除指示を受けないまま、あらかじめ定めた時間が経過すると、ＶＭ１２は「停止」状態に遷移する。ただし、そのＶＭ１２を「停止」させると、「起動」又は「停止準備」のＶＭ数が待機ＶＭの下限数を下回ってしまう場合は、「停止」させずに「停止準備」状態を維持するようにしてもよい。

図４に、ジョブ情報２４のデータ内容の一例を示す。ジョブ情報２４には、ジョブ毎に、そのジョブを一意に識別する「ジョブ識別子」、そのジョブを投入したユーザのユーザ識別子（「ユーザ」）、そのジョブの印刷画質設定（「設定」）、そのジョブでの印刷対象の印刷データの格納場所（「入力」）、そのジョブの処理負荷の総量（言い換えれば、ＶＭ１２がそのジョブを処理するのに要する時間）を示す情報（「総ページ」）、そのジョブの現在の「状況」、及びそのジョブの処理済み量を示す情報（「完了ページ」）の各項目が含まれる。この例でＶＭ１２が実行するジョブ処理の負荷は、大略的には印刷する画像のサイズ（用紙サイズ）に比例し、また当然ながらページ数にも比例する。このため、ジョブの処理負荷の総量や処理済み量は用紙サイズとページ数の組で表現している。例えば、図４の例では、ジョブ「Job1」の総処理負荷は、Ａ４サイズ１０ページ分であり、現時点ではそのうちのＡ４サイズ４ページの処理が完了している。

ジョブ情報２４の内容は、各ＶＭ１２により随時更新される。例えばＶＭ１２がユーザからジョブ実行要求を受けた場合、一意なジョブ識別子が生成され、そのジョブ識別子に対応するエントリがジョブ情報２４内に作成され、そのエントリ内に、その要求を発した「ユーザ」、そのジョブについての「設定」（実行要求の発行前にユーザが入力済み）、そのジョブの印刷データの格納場所を示す「入力」、そのジョブの「総ページ」の値が登録される。このとき、そのジョブは「実行待ち」状態となり、実行要求の受付順にキューに入れられている。また、振り分け装置１６からキュー内のジョブの割り当てを受けたＶＭ１２がそのジョブの実行を開始すると、ジョブ情報２４内のそのジョブの「状況」が「（そのＶＭ１２で）実行中」に変更され、そのＶＭ１２がそのジョブの処理（例えば印刷可能なデータ形式への変換）を１ページ終える毎に、そのジョブの「完了ページ」のページ数に１が加算される。

次に図５を参照して、振り分け装置１６が実行するログイン要求の割り当て処理の手順の例を説明する。この手順では、「停止準備」状態のＶＭ１２よりも「起動」状態のＶＭ１２を優先的にログイン要求を割り当てる。

この手順では、まず振り分け装置１６は、ユーザからログイン要求を受けた場合、ＶＭ情報２２を参照して、「起動」状態でありかつ「ログインユーザ数」が上限、すなわち「最大ユーザ数」に達していないＶＭ１２があるかどうかを判定する（Ｓ１０）。そして、該当するＶＭ１２があれば、そのＶＭ１２にそのログイン要求を割り当てる（Ｓ１２）。Ｓ１０の判定条件に該当するＶＭ１２が複数ある場合には、選択基準に従ってその中からログイン要求の割当先を選択する。選択基準は、その時点での各ＶＭ１２の状況を考慮しない固定的な基準（例えばＶＭ１２の識別子の若い順）であってもよいし、各ＶＭ１２の状況を考慮に入れた基準であってもよい。状況を考慮に入れた基準の例としては、（ｉ）ログインユーザ数が多いＶＭ１２ほど優先的に選択する、（ｉｉ）実行中のジョブの終了タイミングが遅いＶＭ１２ほど優先的に選択する、等がある。基準（ｉ）は、ログインユーザを少ない数のＶＭ１２に集中させる（ただし最大ユーザ数以内に制限される）という作用をもつ。ログインユーザを特定のＶＭ１２に集中させることで、他のＶＭ１２にはログイン処理等のユーザインタフェース処理が割り振られにくくなるので、それら「他のＶＭ１２」は停止準備状態、ひいては停止状態へと遷移しやすくなる。基準（ｉｉ）は、実行中のジョブの終了が相対的に早いＶＭ１２にユーザインタフェース処理が割り当てられにくいので、そのようなＶＭ１２が停止準備状態、ひいては停止状態へと遷移しやすくなる。逆の観点から言えば、実行中のジョブの終了が早いＶＭ１２にログイン要求を割り振ると、ジョブが終了したにもかかわらず、ユーザインタフェース処理を実行しているために停止準備状態に移行できないといった事態が起こりやすいが、基準（ｉｉ）によればそのような事態が生じにくくなる。

なお、Ｓ１０の条件に該当するＶＭ１２の中に、ジョブを実行中のものとジョブを実行していないものとの両方が含まれる場合には、前者に優先的にログイン要求を割り当てるようにしてもよい。このようにすることで、ジョブを実行していないＶＭ１２にログイン要求が割り当てられにくくなり、そのＶＭ１２が停止準備状態（ひいては停止状態）に移行しやすくなる。

Ｓ１０の判定結果がＮｏの場合、起動状態のＶＭ１２はすべて上限（最大ユーザ数）一杯のログインユーザを有していることになる。この場合、対象のログイン要求を起動状態のＶＭ１２に割り当ててしまうと、上限を超えてしまう。そこで、この場合振り分け装置１６は、ＶＭ情報２２を参照して、停止準備状態のＶＭ１２があるかどうかを判定する（Ｓ１４）。そして、該当するＶＭ１２があれば、そのＶＭ１２の状態を起動状態に戻し（Ｓ１６）、その後そのＶＭ１２にそのログイン要求を割り当てる（Ｓ１８）。

停止準備状態のＶＭ１２が複数ある場合には、選択基準に従ってその中からログイン要求の割当先を選択する。ここで用いる選択基準としては、例えば、（ａ）ＶＭ識別子が小さい順に選択するという基準、（ｂ）起動されたタイミングが早い順に選択するという基準、（ｃ）起動されたタイミングが遅い順に選択するという基準等がある。これらの基準は、「停止準備」状態のＶＭ１２がスケールイン可能になるタイミングを考慮に入れない、固定的で簡便な選択基準である。これに対し、スケールイン（停止）可能になるタイミングを考慮に入れた選択基準の例として、「停止準備」状態に遷移してからの経過時間が短いものほど優先的に選択するという基準がある。経過時間が長いものは「停止準備」状態が維持されやすいので、もう少しでスケールインできるＶＭ１２が「起動」状態に戻ってしまうという事態が生じにくい。

また選択基準の別の例として、「停止準備」のＶＭ１２のうちその選択の時点でジョブを実行しているものとしていないものとがある場合、ジョブを実行しているものを優先的に選択するという基準がある。ジョブを実行していないＶＭ１２は停止準備状態（ひいては停止状態）に遷移しやすいので、そのようなＶＭ１２を起動状態に戻さないことで、スケールインが妨げられにくくすることができる。

更に選択基準の別の例として、「停止準備」のＶＭ１２のうち、実行しているジョブの処理が終了するまでの残り時間が長いＶＭ１２ほど優先的に選択するという基準もある。その残り時間が長いほどスケールイン（「停止」状態への遷移）が可能になるタイミングが遅いので、この基準によれば、スケールインしやすい（残り時間が短い）ＶＭ１２が「起動」状態に戻るという事態が起こりにくい。ここで残り時間の長さを示す値としては、ＶＭ情報２２及びジョブ情報２４から、「停止準備」のＶＭ１２が実行中のジョブの「総ページ数」から「完了ページ」を引き算した結果の値を用いればよい。このとき、「総ページ数」及び「完了ページ」は、基準とする用紙サイズでのページ数に換算した上で上述の引き算を行う。

更に別の選択基準として、停止準備状態に遷移した時点で実行中のジョブの実行開始時刻が遅いＶＭ１２ほど優先的に選択するという基準もある。この基準は、例えば各ジョブの残り時間（言い換えれば、そのジョブが終了すると予測される時刻）が見積もれない場合に用いる。図４の例のように、実行中のジョブの完了ページ数をジョブ情報２４内に含め、随時更新している例では、残り時間の見積もりが可能であるが、そのようなことをおこなっていない場合、残り時間の見積もりができないことがある。この場合に対応すべく、この選択基準では、全てのジョブの処理に要する時間は同じであると仮定し、遅く開始されたジョブほど遅くまで実行されているとみなしている。

Ｓ１４の判定結果がＮｏの場合、振り分け装置１６は、起動状態のＶＭ１２の数と停止準備状態のＶＭ１２の数との和が、契約により定められた最大ＶＭ数に達しているかどうかを判定する（Ｓ２０）。この判定は、停止状態のＶＭ１２が存在するか否かの判定と等価である（起動状態、停止準備状態、停止状態のＶＭ１２の合計数は、最大ＶＭ数に等しい）。Ｓ２０の判定結果がＹｅｓの場合、これ以上ＶＭ１２を増やすことはできないので、その時点ではログイン要求を割り当てることはできない。この場合、例えばあらかじめ定めた時間だけ待って再度Ｓ１０からの処理を繰り返す。時間の経過によりいずれかのユーザがログアウトするなどにより、そのログイン要求を受け入れ可能なＶＭ１２が出てくる可能性がある。なお、Ｓ２０の判定結果がＹｅｓの場合、ログインできるまでにある程度の時間がかかることなどを説明するメッセージをユーザに返すようにしてもよい。

Ｓ２０の判定結果がＮｏの場合、スケールアウトを行う余地がある。この場合、図５の例では、振り分け装置１６は、直ちにスケールアウトを実行するようＶＭ管理装置１４に依頼する（Ｓ２２）。ＶＭ管理装置１４はその依頼に応じ、停止状態のＶＭ１２を起動する起動処理を実行する。なお、起動処理にはある程度の時間を要するので、図５の手順では、Ｓ２２の後、新たなＶＭ１２が起動状態になるのを待たず、（あらかじめ定めた時間だけ待って）Ｓ１０に戻っている。そして、その間に他のユーザがログアウトするなどしてそのログイン要求を受け入れ可能なＶＭ１２が現れていれば、そのＶＭ１２にそのログイン要求を割り当てる。こうすることで、スケールアウトしてＶＭ１２の起動処理の完了を待つよりもログイン処理を早く実行できる場合が出てくる。

次に、図６を参照して、振り分け装置１６が行うジョブ割り当て処理の例を説明する。この処理は、あらかじめ定めた時間間隔毎に実行される。

この処理では、まず振り分け装置１６は、キュー内にジョブが有るかどうかを判定する（Ｓ３０）。キュー内にジョブがない場合、ＶＭ１２へ割り当てる対象がないので、処理は終了する。

キュー内にジョブがある場合には、ログイン中のユーザがあり、かつ実行中のジョブ数が上限（図２の「最大ジョブ数」）に達していないＶＭ１２が有るかどうかを判定する（Ｓ３２）。このようなＶＭ１２は、起動状態である。該当するＶＭ１２があれば、そのＶＭ１２にキューの先頭のジョブを割り当てる（Ｓ３４）。Ｓ３２の条件に該当するＶＭ１２が複数ある場合には、ラウンドロビン方式等の公知の負荷分散アルゴリズムに従って、それら複数のＶＭ１２の中からジョブの割当先を決定すればよい。

Ｓ３２の判定結果がＮｏの場合、起動状態のＶＭ１２の中に、ログイン中のユーザが無く、かつ実行中のジョブ数が上限に達していないものが有るかどうかを判定する（Ｓ３６）。該当するＶＭ１２があれば、そのＶＭ１２にキューの先頭のジョブを割り当てる（Ｓ３８）。該当するＶＭ１２が複数ある場合には、公知の負荷分散アルゴリズムに従ってジョブの割当先を決定すればよい。

このように、図６の手順では、実行中のジョブ数が上限に達していない起動状態のＶＭ１２のうち、ログイン中のユーザがあるものに優先的にジョブを割り当てる。こうすることで、ユーザが一人もログインしていないＶＭ１２にジョブが割り当てられにくくなり、そのＶＭ１２が停止準備状態に遷移しやすくなる。

Ｓ３６の判定結果がＮｏの場合、起動状態のＶＭ１２はすべて上限（最大ジョブ数）一杯のジョブを有していることになる。この場合、対象のジョブを起動状態のＶＭ１２に割り当ててしまうと、上限を超えてしまう。そこで、この場合振り分け装置１６は、ＶＭ情報２２を参照して、停止準備状態のＶＭ１２があるかどうかを判定する（Ｓ４０）。そして、該当するＶＭ１２があれば、そのＶＭ１２の状態を起動状態に戻し（Ｓ４２）、その後そのＶＭ１２にそのログイン要求を割り当てる（Ｓ４４）。

ここで停止準備状態のＶＭ１２が複数ある場合には、Ｓ１８の場合と同様の選択基準に従ってその中からログイン要求の割当先を選択してもよいし、ラウンドロビン方式等の公知の負荷分散アルゴリズムに従って割当先を決めてもよい。

Ｓ４０の判定結果がＮｏの場合、振り分け装置１６は、起動状態のＶＭ１２の数と停止準備状態のＶＭ１２の数との和が、契約により定められた最大ＶＭ数に達しているかどうかを判定する（Ｓ４６）。Ｓ４６の判定結果がＹｅｓの場合、これ以上ＶＭ１２を増やすことはできないので、その時点ではジョブをＶＭ１２に割り当てて実行させることはできない。この場合、例えばあらかじめ定めた時間だけ待って再度Ｓ１０からの処理を繰り返す。時間の経過によりいずれかのジョブの実行が完了するなどにより、そのジョブを受け入れ可能なＶＭ１２が出てくる可能性がある。なお、Ｓ４６の判定結果がＹｅｓの場合、ログインできるまでにある程度の時間がかかることなどを説明するメッセージをユーザに返すようにしてもよい。

Ｓ４６の判定結果がＮｏの場合、スケールアウトを行う余地がある。この場合、直ちにスケールアウトを行ってもよいが、図６の手順では、キュー内のジョブ数（実行待ち状態のジョブの数）と、起動状態及び停止準備状態のＶＭ１２のうち現在ジョブを実行中のものの数とを比較し（Ｓ４８）、キュー内のジョブ数の方が多い（Ｓ５０の判定結果がＹｅｓ）場合にのみ、スケールアウトを実行する（Ｓ５２）ようにしている。キュー内のジョブ数の方が多いということは、それだけジョブが待たされる傾向が強いということであり、スケールアウトしてＶＭ１２の数を増やす必要性が高いといえる。これに対し、キュー内のジョブ数がジョブ実行中のＶＭ１２の数以下の場合は、スケールアウトしなくてもジョブの実行待ちは許容範囲内であると見なし、スケールアウトを行わない。Ｓ４８及びＳ５０では、スケールアウトしなくてもキュー内のジョブが実行を待機させられる時間が許容できるそうかどうかを判定できればよく、キューのジョブ数とジョブ実行中のＶＭ１２の数の大小関係以外の判定条件を用いてもよい。

図６の手順でも、スケールアウトの実行（Ｓ５２）により新たなＶＭ１２が起動するのを待たず、Ｓ１０に戻って、既に起動状態にあるＶＭ１２がジョブを受け入れ可能になっていないかどうかを調べる。

次に図７を参照して、ＶＭ管理装置１４が行うスケールイン制御の手順の例を説明する。この手順は、例えばあらかじめ定められた時間間隔毎に実行される。

この手順では、ＶＭ管理装置１４は、まずＶＭ情報２２を参照して、起動状態のＶＭ１２の中にログイン中のユーザがいないものがあるかどうかを判定する（Ｓ５０）。該当するＶＭ１２がある場合には、該当するすべてのＶＭ１２の状態を起動状態から停止準備状態に変更する（Ｓ５２）。そして、あらかじめ定めた判断期間の長さのタイマーをセットし、その判断期間が経過するのを待つ。判断期間が経過する前に、ログイン要求やジョブの増加によりそのＶＭ１２の状態を起動状態に戻すと、タイマーはリセットされる。停止準備状態を維持したまま判断期間が経過すると、ＶＭ管理装置１４は、そのＶＭ１２がジョブを実行中か否かを判定する（Ｓ５６）。ここでは、停止準備状態に遷移した時点でそのＶＭ１２が既に受け入れていたジョブが完了していることを確認する。完了していない場合（Ｓ５６の判定結果がＹｅｓ）、あらかじめ定めた時間だけ待ってＳ５４、Ｓ５６の処理を繰り返し、受け入れ済みのジョブの実行が完了するのを待つ。そして受け入れ済みのジョブが完了すると（Ｓ５６の判定結果がＮｏ）、そのＶＭ１２を停止準備状態から停止状態へと遷移させる（Ｓ５８）。

次に図８を参照して、本実施形態の方法を用いた場合のログイン要求及びジョブの処理の様子のシミュレーション例を説明する。

このシミュレーション例は、１１人のユーザ「user 1」〜「user 11」が順にジョブ処理システム１０にログインし、１人１つずつジョブを投入し、ジョブの実行を要求してログアウトした場合に、ログイン要求やジョブがどのようにＶＭ１２群に割り当てられ、またＶＭ１２群のオートスケールがどのように行われていくのかを示している。

このシミュレーションでは、１つのＶＭ１２に同時にログインできるユーザの最大数は３人であるとし、１つのＶＭ１２が同時に処理可能なジョブの最大数は１ジョブである。また、停止状態のＶＭ１２が起動状態になるための起動処理には２分を要し、停止準備状態から停止状態に移行するまでの判断期間は４分間である。

図８に示される４つのチャートのうち最も左側のものは、各ユーザがジョブ処理システム１０にログイン要求を発してからログアウトするまでの期間を示している。縦軸が時間の流れを示し、区切り１つが１分を示す。横軸はユーザ識別子を示す。ユーザ識別子の縦列と時間の横行が交差するセル内の符号は、「１」がログイン要求を発してからログアウトするまでの期間内であることを示し、「０」がその期間でないことを示す。例えばユーザ「user 1」は、１分目にログイン要求を発し、その後５分目にログアウトするまでの間、ジョブ処理システム１０に対していくつかの要求（例えばログイン要求、印刷パラメータ設定要求、ジョブ実行要求）を発していることが読み取れる。

左から２番目のチャートは、各ユーザが投入したジョブがいずれかのＶＭ１２で実行されている期間を示している。ユーザ識別子の縦列と時間の横行が交差したセル内の符号は、「１」が当該ユーザのジョブの実行期間内であることを示し、「０」がその期間でないことを示す。例えばユーザ「user 1」については、（そのユーザが４分目にジョブ実行要求を発してログアウトした後）６分目にそのジョブの実行が開始され、９分目にそのジョブの実行が完了している

左から３番目のチャートは、各ＶＭ１２のユーザインタフェース処理の実行状況を示す。横軸は各ＶＭ１２の識別子を示す。識別子の縦列と時間の横行が交差したセルは、その時間スロットにおいてそのＶＭ１２にログインしているユーザの識別子のリストを表している。例えば、「ＶＭ１」には、１分目では「user 1」のみがログインしているが、２分目では「user 1」及び「user 2」がログインしており、３分目では「user 1」〜「user 3」の３人がログインしている。

またこのチャート及びその右隣のチャートにおけるセルの背景の濃さは、そのセルにおけるＶＭ１２の状態を示している。白色のセルは「起動」状態を、最も濃いグレーのセルは「停止」状態を、それら両者の中間濃度のグレーのセルは「停止準備」状態を示している。また、「起動処理」と記載されたセルは、当該ＶＭ１２が「停止」から「起動」に遷移するための起動処理（ブートアップ）を行っていることを示している。例えば「ＶＭ２」は４分目までは停止状態であるが、５〜６分目に起動処理を行い、７分目以降は起動状態となっている。そして、１５分目に停止準備状態に遷移し、その後起動状態に戻ることなく４分間が経過して、１９分目に停止状態に遷移（スケールイン）している。

最も右側のチャートは、各ＶＭ１２のユーザインタフェース処理の実行状況を示す。横軸は各ＶＭ１２の識別子を示す。識別子の縦列と時間の横行が交差したセルは、その時間スロットにおいてそのＶＭ１２が実行しているジョブの識別子を表している。このシミュレーションでは、各ユーザがそれぞれ１つずつジョブを投入しているので、ジョブの識別子にはユーザの識別子と同じ数字を用いている。例えば、「ＶＭ１」は、６分目に「user 1」のジョブの実行を開始して９分目にそのジョブを完了し、７分目から９分目までは「user 3」のジョブを実行している。

このシミュレーション例では、「ＶＭ１」はジョブ処理システム１０の起動時から起動しており、最初のログイン要求（「user 1」からのもの）は「ＶＭ１」が受け付ける。ＶＭは３人までのユーザに同時に対応できるので、ログイン期間が重なっている「user 1」から「user 3」までについても同時に対応している。５分目に「user 4」からログイン要求が来た際、起動状態である唯一の「ＶＭ１」は既に最大ユーザ数３人までのユーザに対応しており、停止準備中のＶＭもないので、「ＶＭ２」が起動される（スケールアウト）。「ＶＭ２」は２分間の起動処理を経て７分目には起動状態になる。５分目の「user 4」からのログイン要求は、その時点では受け入れ可能なＶＭは存在しないが、５分目で「user 1」がログアウトして「ＶＭ１」に１人分の空きができた結果、６分目に「ＶＭ１」に割り当てられる。この時点では「ＶＭ２」はまだ起動処理中である。

「user 1」のジョブは、６〜９分目の間「ＶＭ１」で処理される。「user 2」がジョブ実行要求を行った７分目では、「ＶＭ１」は他のジョブを実行していてその要求を受け付けられないが、「ＶＭ２」が起動状態となっているので、その要求は「ＶＭ２」に振り分けられる。「user 3」がジョブ実行要求を行った８分目では、起動状態にある「ＶＭ１」及び「ＶＭ２」は共に他のジョブを実行していてその要求を受け付けることができない。このため、新に「ＶＭ３」が起動される。

「ＶＭ３」は２分後の１０分目に起動状態となるが、「ＶＭ１」及び「ＶＭ２」はその１０分目の時点では他のジョブの処理を完了しており、他のジョブを受け入れ可能になっている。したがって、起動状態の「ＶＭ１」〜「ＶＭ３」の全てが、「user 3」のジョブの振り分け先の候補となる。図６のジョブ割り当ての手順によれば、そのうちの「ＶＭ１」と「ＶＭ２」が、ログイン中のユーザがあり且つ実行中のジョブ数が上限（１個）に達していないので、Ｓ３２の判定結果はＹｅｓとなり、この例では例えば識別子の若い順という選択基準（あくまで一例である）からそのうちの「ＶＭ１」がそのジョブの振り分け先に選ばれる。したがって、１０分目では、「ＶＭ１」はユーザインタフェース処理とジョブ処理の両方を実行しており、「ＶＭ１」はユーザインタフェース処理のみを実行しており、「ＶＭ３」はユーザインタフェース処理とジョブ処理のどちらも行っていない。せっかく起動した「ＶＭ３」であるが、１０分目の時点でユーザインタフェース処理を行っていない状態となったので、停止準備状態に移行する（図７のＳ５０及びＳ５２参照）。

「user 5」及び「user 6」のジョブの実行が要求された１２分目では、起動状態の「ＶＭ１」及び「ＶＭ２」は共に上限（１個）のジョブを実行中であり、新たなジョブを受け入れることができない。そこで停止準備状態のＶＭを探すと、「ＶＭ３」が見つかるので、「ＶＭ３」を起動状態に戻す（図６のＳ４０、Ｓ４２）。「ＶＭ３」は即座に起動状態に戻り、それら２つのジョブのうち例えば「user 5」のジョブの割り当てを受けて実行する。この時点では「user 6」のジョブの割当先が決まっていないが、起動状態の「ＶＭ１」〜「ＶＭ３」は全て上限までジョブを実行しており、停止準備状態のＶＭもないので、スケールアウトを試みる。この例では最大ＶＭ数は５なので、スケールアウトの余地がある。そこで、「ＶＭ４」を起動する。

「user 1」〜「user 11」に対するユーザインタフェース処理は、時間がずれているため「ＶＭ１」と「ＶＭ２」の２つでまかなえている。したがって、１２分目にジョブの割り当てを受けた「ＶＭ３」はユーザインタフェース処理をしないので、次の１３分目で停止準備状態に戻る。「ＶＭ３」は、その後ログイン処理もジョブも割り当てられないので、４分後の１７分目に停止状態に移行する（スケールイン）。

起動された「ＶＭ４」及び「ＶＭ５」には１４分目及び１５分目にそれぞれジョブが割り当てられるが、ログイン要求が割り当てられることはないので、次の１５分目及び１６分目にそれぞれ停止準備状態に移行する。

「ＶＭ２」は、１５分目にログインユーザが０になったので、１６分目に停止準備状態に移行するが、１７分目に「user 10」のジョブを処理するために起動状態に戻される。そして、ログイン要求が無いため、次の１８分目に停止準備状態に戻り、その後再び起動状態に戻ること無く判断期間（４分）が経過し、２０分目に停止状態に移行する（スケールイン）。

以上では、ジョブ処理システム１０が印刷ジョブの実行サービスをユーザに提供する例を説明したが、ジョブ処理システム１０は、スキャンした画像に対するデータ処理や画像の転送処理等の他のジョブを実行するものであってもよい。この場合クライアント３０は、スキャナ、ファクシミリ装置、複合機（プリンタ、スキャナ、コピー機、ファクシミリ装置等の機能を併せ持つ装置）等であってもよい。

また、仮想マシンではなく物理的なコンピュータでジョブ処理やユーザインタフェース処理を分散して実行するシステムにおいても、上記実施形態の手法を用いてそれらコンピュータの起動（スケールアウト）や停止（スケールイン）を制御することができる。

以上に例示したＶＭ１２、ジョブ管理装置１４、振り分け装置１６は、例えば、汎用のコンピュータにそれら各装置の処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

１０ ジョブ処理システム、１２ ＶＭ（仮想マシン）、１４ ＶＭ管理装置、１６ 振り分け装置、２０ 共有ストレージ、２２ ＶＭ情報、２４ ジョブ情報、３０ クライアント。

Claims (6)

1. コンピュータを、
   処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部、
   各処理部の負荷状況の情報を保持する負荷状況保持手段、
   負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てる割り当て手段、
   負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行う状態制御手段、
   として機能させるためのプログラム。
2. 前記処理には、ユーザからの接続要求を処理する接続処理と、データ処理要求に応じてデータを処理するデータ処理とがあり、
   前記負荷状況保持手段は、前記各処理部について、前記接続処理と前記データ処理のそれぞれの負荷状況の情報を保持し、
   前記状態制御手段は、前記接続処理の負荷がなくなった起動状態の処理部を停止準備状態に移行させる、
   ことを特徴とする請求項１に記載のプログラム。
3. 前記割り当て手段は、
   到来した接続要求については、接続処理の負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した接続要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその接続要求を割り当てると共に、
   接続処理の負荷状況が上限負荷に達していない起動状態の処理部が複数ある場合は、それら複数のうちのデータ処理を実行していない処理部よりもデータ処理を実行中の処理部に優先的に前記接続要求を割り当てる、
   ことを特徴とする請求項２に記載のプログラム。
4. 前記割り当て手段は、
   到来したデータ処理要求については、データ処理の負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来したデータ処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にそのデータ処理要求を割り当てると共に、
   データ処理の負荷状況が上限負荷に達していない起動状態の処理部が複数ある場合は、それら複数のうちの接続処理を実行していない処理部よりも接続処理を実行中の処理部に優先的に前記接続要求を割り当てる、
   ことを特徴とする請求項２又は３に記載のプログラム。
5. 処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部と、
   各処理部の負荷状況の情報を保持する負荷状況保持手段と、
   負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てる割り当て手段と、
   負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行う状態制御手段と、
   を含む情報処理装置。
6. 処理要求に応じた処理をあらかじめ定められた上限負荷まで実行可能であり、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が可能である起動状態、処理要求の受け入れ及びその処理要求に応じた処理の実行の両方が不可能である停止状態、処理要求に応じた処理の実行は可能であるが処理要求の受け入れは禁止されている停止準備状態、の３つの状態を選択的にとることができる処理部であって、停止状態の処理部が処理要求を受け入れるためには起動処理を行って起動状態に移行する必要があるのに対し、停止準備状態の処理部が処理要求を受け入れるためには起動処理を行わずに起動状態に戻せばよい、複数の処理部を制御する方法であって、
   負荷状況保持手段が、各処理部の負荷状況の情報を保持するステップと、
   割り当て手段が、負荷状況が上限負荷に達していない起動状態の処理部がある場合には、到来した処理要求をその処理部に割り当て、そうでない場合には、停止準備状態の処理部があればその停止準備状態の処理部を起動状態に戻し、戻した処理部にその処理要求を割り当てるステップと、
   状態制御手段が、負荷がなくなった起動状態の処理部を停止準備状態に移行させ、停止準備状態のままあらかじめ定めた時間が経過した処理部を停止状態に移行させる制御を行うステップと、
   を含む情報処理方法。