JP6872117B2 - 情報処理装置及びプログラム - Google Patents

Description

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

クラウドコンピューティングのように、サービス提供者が有するプロセッサやメモリ等のリソースを、例えば課金方式等の形式でユーザに使用させる技術が知られている。このようなサービスは、一般的に、処理に用いられるリソース（例えば処理部）を必要に応じて自動的に増減する、いわゆるオートスケーリング機能を備えている。一般的に、処理部の数を増加させる処理を「スケールアウト」と称し、処理部の数を減少させる処理を「スケールイン」と称している。

特許文献１には、複数のサービスプロバイダから、サービスレベルに合致するサービスプロバイダを抽出するシステムが開示されている。

特許文献２には、プライマリクラウドで提供したサービスのレベルに基づきセカンダリクラウドを選択してサービスを提供するシステムが開示されている。

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

ところで、リソースを提供するサービスとして、ホスティングサービス（Hosting Service）やクラウドサービス（Cloud Service）が知られている。

ホスティングサービスでは、一般的に、利用可能な処理部の数が定められている。そのため、ホスティングサービスに配置された処理部の数を超える数の処理要求が発生した場合等のように、処理要求に応じた処理を実行するための処理部をホスティングサービスに確保できない場合、サービスが提供されないことになる。

一方、クラウドサービスでは、一般的に、利用可能な処理部の数は定められておらず、リソース（例えば処理部の数等）の利用に応じて課金される。それ故、リソースの利用状況に応じて、利用コストが増大する場合がある。

本発明の目的は、処理部の数が定められた処理グループにて処理を実行できない場合であっても、処理を継続することができるようにすることにある。

請求項１に係る発明は、データの処理要求を受け付ける受付手段と、前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部と、を有し、各処理部は、複数の処理を並列的に実行可能であり、前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、各処理部の負荷と要求された処理の負荷とに応じて、別の処理を実行中の処理部に当該要求された処理を割り当て、予め定められた第１処理の要求を新たに受け付けた場合、第１処理を既に実行中の処理部に、その新たに受け付けた第１処理を割り当て、前記第１処理よりも負荷が大きい第２処理の要求を新たに受けた場合、処理を実行していない別の処理部に、その新たに受けた第２処理を割り当て、前記第１処理グループに含まれる全処理部が対応可能な負荷を超える処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当てる、ことを特徴とする情報処理装置である。

請求項２に係る発明は、前記第１処理は、ユーザのログイン処理を含む処理であり、前記第２処理は、画像処理を含む処理である、ことを特徴とする請求項１に記載の情報処理装置である。

請求項３に係る発明は、前記上限数は、各ユーザが要求可能な並列処理の数に基づいて決定される、ことを特徴とする請求項１又は請求項２に記載の情報処理装置である。

請求項４に係る発明は、前記第１処理グループは、個々のユーザ毎に、少なくとも１つの専用の処理部を含み、各ユーザに少なくとも１つの専用の処理部が予め割り当てられている、ことを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理装置である。

請求項５に係る発明は、前記第１処理グループは、ユーザの数以上の数の処理部を含む、ことを特徴とする請求項４に記載の情報処理装置である。

請求項６に係る発明は、前記制御部は、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、ことを特徴とする請求項１から請求項５のいずれか一項に記載の情報処理装置である。
請求項７に係る発明は、データの処理要求を受け付ける受付手段と、前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部と、を有し、前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、前記第１処理グループに含まれる処理部では処理しきれない処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当て、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、ことを特徴とする情報処理装置である。

請求項８に係る発明は、前記制御部は、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合において、ユーザのログイン処理の要求を受けた場合、前記緊急用の処理部に前記ログイン処理を割り当てる、ことを特徴とする請求項６又は請求項７に記載の情報処理装置である。

請求項９に係る発明は、コンピュータを、データの処理要求を受け付ける受付手段、前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め設定された上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部、として機能させ、前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、各処理部の負荷と要求された処理の負荷とに応じて、別の処理を実行中の処理部に当該要求された処理を割り当て、予め定められた第１処理の要求を新たに受け付けた場合、第１処理を既に実行中の処理部に、その新たに受け付けた第１処理を割り当て、前記第１処理よりも負荷が大きい第２処理の要求を新たに受けた場合、処理を実行していない別の処理部に、その新たに受けた第２処理を割り当て、前記第１処理グループに含まれる全処理部が対応可能な負荷を超える処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当てる、ことを特徴とするプログラムである。
請求項１０に係る発明は、コンピュータを、データの処理要求を受け付ける受付手段、前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部、として機能させ、前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、前記第１処理グループに含まれる処理部では処理しきれない処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当て、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、ことを特徴とするプログラムである。

請求項１，３，９に係る発明によると、処理部の数が定められた処理グループにて処理を実行できない場合であっても、処理を継続することが可能となる。

請求項１，２に係る発明によると、更に、処理部の数が定められた処理グループに含まれる全処理部が対応可能な負荷を超える処理要求が受け付けられた場合であっても、処理を継続することが可能となる。

請求項４，５に係る発明によると、処理部に割り当てられないユーザが発生することを防止できる。

請求項６，７，１０に係る発明によると、緊急用の処理部を用いない場合と比べて、より確実に処理が実行される。

請求項８に係る発明によると、緊急用の処理部を用いない場合と比べて、ユーザのログイン処理がより確実に実行される。

本実施形態に係る情報処理システムの一例を示す図である。 初期状態における情報処理システムの一例を示す図である。 起動後の情報処理システムの一例を示す図である。 ユーザ振り分け処理の一例を示すフローチャートである。 受入ＶＭ選択処理の一例を示すフローチャートである。 新規ＶＭ確保処理の一例を示すフローチャートである。 新規ＶＭ確保リトライ処理の一例を示すフローチャートである。

図１を参照して、本発明の実施形態に係る情報処理システムについて説明する。図１には、本実施形態に係る情報処理システムの一例が示されている。

本実施形態に係る情報処理システム１０は、処理を実行するというサービスをユーザに提供する。情報処理システム１０においては、一例として、複数のユーザ（テナント）がリソースを共有するマルチテナント方式が採用されている。処理は、例えば、印刷に関する処理（例えば印刷ジョブ）である。印刷ジョブ（以下「ジョブ」と称する）は、ユーザが指定した印刷対象の文書データをプリンタで印刷するために行うデータ処理（例えば画像処理）である。情報処理システム１０は、例えば、図示しないネットワーク等の通信経路を介して、ＰＣ（パーソナルコンピュータ）やモバイル端末等の端末装置１２から文書データを受け取り、その文書データを図示しないプリンタで取扱可能なデータ形式の印刷データに変換し、その印刷データを通信経路経由でプリンタに提供して印刷を実行させる。もちろん、情報処理システム１０は、印刷ジョブ以外の処理を実行してもよい。

情報処理システム１０は、１又は複数のＶＭ（Virtual Machine：仮想マシン）を含む。ＶＭは、ユーザからの指示に対応する処理（例えばジョブ）を実行する。ＶＭは、例えばＩａａＳ（Infrastructure as a Service）プロバイダから提供されるインフラ上に構築されるものであってよい。

ＶＭが実行するジョブ処理は、例えば、文書データを印刷データに変換する処理、変換結果の印刷データをユーザによって指定されたプリンタに送信する処理、文書データを画像に変換して画像から情報を抽出する処理、処理結果を他のサーバ等へ転送する処理、等を含む。

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

情報処理システム１０は、例えば、１又は複数のＶＭ群と、ＶＭ群を管理する１又は複数のＶＭ実行基盤と、を含む。図１に示す例では、情報処理システム１０は、ＶＭ群１４ａ，・・・，ＶＭ群１４ｎと、ＶＭ実行基盤１６ａ，・・・，１６ｎと、を含む。各ＶＭ群は１又は複数のＶＭを含む。各ＶＭ実行基盤は、対応するＶＭ群に含まれるＶＭの最大数を管理し、各ＶＭの状態（起動や停止）を示す情報を収集し、それらの情報（ＶＭ情報）を保持する。例えば、ＶＭ実行基盤１６ａは、対応するＶＭ群１４ａに含まれるＶＭの最大数を管理し、ＶＭ群１４ａに含まれる各ＶＭの状態（起動や停止）を示す情報を収集し、それらの情報を管理する。他のＶＭ実行基盤についても同様である。なお、ＶＭ実行基盤１６ａ，・・・，１６ｎも、仮想マシン上に構築されたものであってもよい。

テナント管理部１８は、情報処理システム１０が提供するサービスを利用するユーザ（テナント）に関する情報（以下「テナント情報」と称する）を管理する機能を備えている。テナント情報は、例えば、各テナントの名称（各ユーザの名称）を示す情報、各テナント（各ユーザ）の多重度を示す情報、等を含む。多重度は、同時実行可能な処理の数、つまり、並列的に実行可能な処理の数である。同時実行可能な処理の数は、例えばサービスの利用契約等に基づいて、テナント毎（ユーザ毎）に定められている。例えば、テナントＡ（ユーザＡ）が、情報処理システム１０が提供するサービスの利用契約を締結しており、その利用契約によって、テナントＡの多重度（同時実行可能な処理の数）が「３」に定められているものとする。この場合、テナントＡは、３つの処理が並列的に実行されるように要求することができる。例えば、テナントＡから要求された２つのジョブがＶＭによって実行中の場合において、テナントＡから別のジョブ（３つ目のジョブ）の実行要求が与えられた場合、当該別のジョブ（３つ目のジョブ）もＶＭによって実行される。テナントＡから要求された３つのジョブが実行中の場合において、テナントＡから別のジョブ（４つ目のジョブ）の実行要求が与えられた場合、当該別のジョブ（４つ目のジョブ）は実行されず、例えば、待機状態となる。この場合、実行中の３つのジョブの中で少なくとも１つのジョブの実行が終了すると、４つ目のジョブが実行される。

ユーザ振り分け部２０は、ユーザ（端末装置１２）からの処理要求をいずれかのＶＭに振り分ける（割り当てる）機能を備えている。ユーザ振り分け部２０は、各ユーザの多重度を参照して、ユーザからの処理要求をいずれかのＶＭに振り分ける。

ＶＭがユーザ（端末装置１２）から受ける処理要求は、例えば、ログイン要求、ジョブ実行要求、ジョブ状態確認要求、等を含む。

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

ログイン状態においては、例えば、ユーザ（端末装置１２）からそのＶＭに印刷データや印刷パラメータの入力が行われる。すると、当該ＶＭは、一意なジョブ識別子を発行し、それら入力された情報をそのジョブ識別子に対応付けて、当該ユーザ（テナント）用の共有ストレージに保存する。共有ストレージは、例えば、ＶＭによってユーザ毎（テナント毎）に構築される。端末装置１２からＶＭにジョブ実行要求が入力されると、そのＶＭは、そのジョブ識別子をキュー（印刷待ち行列）の末尾に追加する。各ＶＭは、それぞれ次のジョブを受け入れ可能になると、そのキューの先頭のジョブを受け入れる。

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

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

ＶＭ制御部２２は、各ＶＭを制御する機能を備えている。ＶＭ制御部２２は、例えば、停止状態のＶＭを起動させたり、起動状態（すなわち稼働状態）のＶＭを停止させたりする。

なお、テナント管理部１８、ユーザ振り分け部２０及びＶＭ制御部２２も、仮想マシン上に構築されたものであってもよい。

ＶＭ実行基盤１６ａ等によって管理されるＶＭ情報には、例えば、ＶＭ毎に、そのＶＭを一意に識別するＶＭ識別子、そのＶＭの状態、そのＶＭが同時に受付可能なユーザ数、そのＶＭに現在ログインしているユーザ数（ログインユーザ数）、現在ログインしているユーザのユーザ識別子のリスト（ログインユーザ）、そのＶＭが並列的に実行可能な最大ジョブ数、及び、そのＶＭが現在実行しているジョブのジョブ識別子のリスト（実行中ジョブ）が登録されている。

最大ジョブ数と最大ユーザ数は、各ＶＭの処理能力に応じて予め定められた値である。ＶＭの状態として、起動及び停止という状態の他に、アイドル状態を設けてもよい。起動状態とは、ＶＭが起動済みである状態、すなわち、ジョブやユーザインターフェース処理を実行可能な状態である。停止状態とは、ＶＭが停止している状態である。停止状態のＶＭがジョブやユーザインターフェース処理（ユーザからの要求の受付等）を実行可能になるには、そのＶＭを起動させる起動処理が必要であり、この起動処理にはある程度の時間がかかる。アイドル状態とは、起動状態と停止状態の中間の状態であり、いわば停止の準備段階である。この状態ではＶＭはまだ停止していないが、新たなジョブは受け入れないし、ユーザインターフェース処理も実行しない。これらのことを実行するには、ＶＭは起動状態に復帰する必要がある。ただし、アイドル状態のＶＭは、まだ停止していないので、起動処理を行わなくても起動状態に復帰し、新たなジョブやユーザインターフェース処理を実行することができるので、起動処理に要する時間が削減される。

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

以下、図２を参照して、初期状態における情報処理システム１０について詳しく説明する。図２には、初期状態における情報処理システム１０の構成が示されている。初期状態は、ユーザ（テナント）によって処理要求が与えられておらず、ＶＭにユーザや処理が割り当てられていない状態である。

情報処理システム１０は、一例として、第１処理グループとしてのホスティングサービス（Hosting Service）２４と、第２処理グループとしてのクラウドサービス（Cloud Service）２６と、を含む。

ホスティングサービス２４は、複数種類のＶＭを含む。ＶＭの種類として、各テナント（各ユーザ）の間で共通して使用されるテナント共通ＶＭ２８、各テナント内にて共通して使用されるテナント内共通ＶＭ３０等、及び、ジョブやユーザインターフェース処理を実行する処理部としてのサービスＶＭ３６等がある。

テナント共通ＶＭ２８は、例えば、上述したテナント管理部１８、ユーザ振り分け部２０、及び、ＶＭ制御部２２として機能する。

テナント内共通ＶＭは、テナント毎（ユーザ毎）に予め用意されてホスティングサービス２４に配置されている。つまり、ホスティングサービス２４は、テナント数（ユーザ数）分のテナント内共通ＶＭを含む。例えば、ユーザＡ，Ｂ，Ｃ（テナントＡ、Ｂ，Ｃ）が、情報処理システム１０が提供するサービスの利用契約（例えばユーザと運営者との間の契約）を締結して、サービスを利用するものとする。テナント数（ユーザ数）が「３」であるため、３つテナント内共通ＶＭ（テナント内共通ＶＭ３０，３２，３４）がホスティングサービス２４内に配置される。例えば、テナント内共通ＶＭ３０にテナントＡ（ユーザＡ）が予め割り当てられ、テナント内共通ＶＭ３２にテナントＢ（ユーザＢ）が予め割り当てられ、テナント内共通ＶＭ３４にテナントＣ（ユーザＣ）が予め割り当てられている。テナント内共通ＶＭは、例えば、そのテナント内共通ＶＭに割り当てられたテナント（ユーザ）用のストレージとして使用され、そのユーザが要求したジョブ等の情報を記憶する。例えば、テナント内共通ＶＭ３０には、ユーザＡが要求したジョブ等の情報が記憶される。

なお、テナント共通ＶＭ２８とテナント内共通ＶＭ３０，３２，３４は、初期状態において予め起動している。

ホスティングサービス２４は、予め定められた上限数（最大数）よりも少ない数のサービスＶＭを含む。上限数は、例えば、各テナントの同時実行可能な（並列的に実行可能な）処理の数（多重度）の総数である。上述したように、同時実行可能な処理の数は、例えばサービスの利用契約等に基づいて、テナント毎（ユーザ毎）に予め定められている。例えば、テナントＡ，Ｂ，Ｃ（ユーザＡ，Ｂ，Ｃ）が、情報処理システム１０が提供するサービスの利用契約を締結して、サービスを利用するものとする。この場合において、各テナントの同時実行可能な処理の数は、利用契約に基づいてユーザ毎に定められる。例えば、テナントＡ（ユーザＡ）の多重度（同時実行可能な処理の数）が「３」に定められ、テナントＢ（ユーザＢ）の多重度が「２」に定められ、テナントＣ（ユーザＣ）の多重度が「４」に定められたとする。この場合、上限数（テナントＡ，Ｂ，Ｃの同時実行可能な処理の数の総数）は「９」であり、ホスティングサービス２４には、「９」よりも少ない数のサービスＶＭが配置される。図１に示す例では、４個のサービスＶＭ（サービスＶＭ３６，３８，４０，４２）がホスティングサービス２４に配置されている。初期状態においては、各サービスＶＭは、各テナント（各ユーザ）に割り当てられていない。

クラウドサービス２６は、１又は複数の処理部としてのサービスＶＭの配置が可能なグループである。初期状態においては、クラウドサービス２６にサービスＶＭは配置されていない。クラウドサービス２６には、少なくとも、ホスティングサービス２４に含まれるサービスＶＭとともに、上記の上限数の処理を実行できる数のサービスＶＭの配置が可能なグループである。具体的には、クラウドサービス２６は、上記の上限数とホスティングサービス２４に含まれるサービスＶＭの数との差分に相当する数以上のサービスＶＭの配置が可能なグループである。例えば、上限数が９であり、ホスティングサービス２４に４個のサービスＶＭが予め配置されている場合、クラウドサービス２６は、５個以上のサービスＶＭが配置可能なグループであればよい。

ユーザ振り分け部２０は、ユーザ（端末装置１２）から処理要求（例えばジョブやユーザインターフェース処理）を受け付けた場合、ホスティングサービス２４に含まれるサービスＶＭを優先的に起動してそのサービスＶＭに処理を割り当て、ホスティングサービス２４に含まれるサービスＶＭでは処理しきれない処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭに処理を割り当てる。例えば、ユーザ振り分け部２０は、ホスティングサービス２４に含まれるサービスＶＭの総数を超える数の処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭに処理を割り当てる。別の例として、ユーザ振り分け部２０は、ホスティングサービス２４に含まれる全サービスＶＭ（サービスＶＭ３６，３８，４０，４２）が対応可能な負荷を超える処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭに処理を割り当ててもよい。

以下、図３を参照して、サービスＶＭのスケールアウトとスケールインの制御について詳しく説明する。図３には、起動後の情報処理システム１０の構成が示されている。

ＶＭ制御部２２は、各テナント（各ユーザ）からのサービスＶＭの起動要求に応じて、ホスティングサービス２４に含まれるサービスＶＭを優先的に起動させる（スケールアウト）。ＶＭ制御部２２は、ホスティングサービス２４に含まれるサービスＶＭの総数を超える数の起動要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭを起動させる（スケールアウト）。また、ユーザ振り分け部２０は、ホスティングサービス２４に含まれるサービスＶＭに優先的にユーザを振り分け、ホスティングサービス２４に含まれるサービスＶＭに優先的に処理（例えばジョブ処理やユーザインターフェース処理）を割り当てる。ユーザ振り分け部２０は、ホスティングサービス２４に含まれるサービスＶＭの総数を超える数の処理要求を受け付けた場合、クラウドサービス２６内のサービスＶＭに処理を割り当てる。ＶＭ制御部２２は、ユーザがログアウトしたサービスＶＭや、割り当てられた処理の実行が完了したサービスＶＭを停止させる（スケールイン）。

以下、スケールアウトの具体例について説明する。例えば、起動要求Ａ１，Ｂ１，Ｃ１，Ａ２，Ｂ２，Ｃ２の順で、サービスＶＭの起動要求が各テナント（各ユーザ）から情報処理システム１０に与えられたものとする。起動要求Ａ１，Ａ２は、テナントＡ（ユーザＡ）から与えられた起動要求であり、起動要求Ｂ１，Ｂ２は、テナントＢ（ユーザＢ）から与えられた起動要求であり、起動要求Ｃ１，Ｃ２は、テナントＣ（ユーザＣ）から与えられた起動要求である。

ＶＭ制御部２２は、起動要求Ａ１に応じてホスティングサービス２４内のサービスＶＭ（例えばサービスＶＭ３６）を起動させ（スケールアウトし）、起動要求Ｂ１に応じてホスティングサービス２４内のサービスＶＭ（例えばサービスＶＭ３８）を起動させ（スケールアウトし）、起動要求Ｃ１に応じてホスティングサービス２４内のサービスＶＭ（例えばサービスＶＭ４０）を起動させ（スケールアウトし）、起動要求Ａ２に応じてホスティングサービス２４内のサービスＶＭ（サービスＶＭ４２）を起動させる（スケールアウトする）。この段階で、ホスティングサービス２４に含まれる全サービスＶＭが起動しているため、ＶＭ制御部２２は、起動要求Ｂ２に応じてクラウドサービス２６内にサービスＶＭ４４を新たに配置してサービスＶＭ４４を起動させ（スケールアウトし）、起動要求Ｃ２に応じてクラウドサービス２６内にサービスＶＭ４６を新たに配置してサービスＶＭ４６を起動させる（スケールアウトする）。

また、ユーザ振り分け部２０は、起動要求Ａ２に対応するサービスＶＭ４２よりも優先して、起動要求Ａ１に対応するサービスＶＭ３６にユーザＡ（テナントＡ）を振り分けて、ユーザＡが要求する処理（例えばジョブやユーザインターフェース処理）をサービスＶＭ３６に優先的に割り当てる。同様に、ユーザ振り分け部２０は、起動要求Ｂ２に対応するサービスＶＭ４４よりも優先して、起動要求Ｂ１に対応するサービスＶＭ３８にユーザＢ（テナントＢ）を振り分けて、ユーザＢが要求する処理（例えばジョブやユーザインターフェース処理の要求）をサービスＶＭ３８に割り当てる。同様に、ユーザ振り分け部２０は、起動要求Ｃ２に対応するサービスＶＭ４６よりも優先して、起動要求Ｃ１に対応するサービスＶＭ４０にユーザＣ（テナントＣ）を振り分けて、ユーザＣが要求する処理（例えばジョブやユーザインターフェース処理）をサービスＶＭ４０に割り当てる。

ＶＭ制御部２２は、ユーザがログアウトしたサービスＶＭや、割り当てられた処理の実行が完了したサービスＶＭを停止させる（スケールイン）。例えば、サービスＶＭ４４において、当該サービスＶＭ４４に割り当てられた処理（例えばジョブやユーザインターフェース処理）の実行が完了した場合、ＶＭ制御部２２は、サービスＶＭ４４を停止させる（スケールイン）。

以上のように、本実施形態に係る情報処理システム１０によると、ホスティングサービス２４に含まれるサービスＶＭの数を超える数の処理要求が受け付けられた場合、クラウドサービス２６に含まれるサービスＶＭが利用される。それ故、ホスティングサービス２４に配置されたサービスＶＭによって処理を実行できない場合であっても、クラウドサービス２６を利用して処理が継続される。

ホスティングサービス２４に含まれるサービスＶＭでは処理しきれない処理要求が発生した場合に、つまり必要に応じて、クラウドサービス２６が利用されるので、クラウドサービス２６の利用に応じて課金される場合であっても、クラウドサービス２６のみを利用する場合と比べて、課金が制限され、サービスの利用コストが削減される。また、ホスティングサービス２４に含まれるサービスＶＭが優先的にスケールアウトするため、スケールインはクラウドサービス２６に含まれるサービスＶＭから行われ易くなり、この観点からしても、サービスの利用コストが削減される。

上記の上限数（同時実行可能な処理の数の総数）のサービスＶＭをホスティングサービス２４に配置して、ホスティングサービス２４のみを利用することが考えられる。例えば、上記の例で示したように、テナントＡの多重度が「３」であり、テナントＢの多重度が「２」であり、テナントＣの多重度が「４」である場合、必要となるサービスＶＭは「９」となる。つまり、上限数は「９」となる。この場合、９個のサービスＶＭがホスティングサービス２４に配置される。また、テナント共通ＶＭ２８と各テナント用のテナント内共通ＶＭ（テナント内共通ＶＭ３０，３２，３４）が、ホスティングサービス２４に配置される。従って、合計で１３個のＶＭが必要となる。しかし、すべてのサービスＶＭ（上記の例では９個のサービスＶＭ）が並列的に処理を実行するとは限らない。例えば、図３に示すように、６個の処理要求が発生した場合、９個のサービスＶＭの中の６個のサービスＶＭのみが処理を実行することになり、残り３個のサービスＶＭは、停止状態になる、又は、起動しているが処理を実行しないことになる。それ故、ホスティングサービス２４に含まれるサービスＶＭの稼働率が低下する。本実施形態では、上限数（同時実行可能な処理の数の総数）よりも少ない数のサービスＶＭがホスティングサービス２４に配置されるので、上限数のサービスＶＭをホスティングサービス２４に配置する場合と比べて、ホスティングサービス２４に配置されたサービスＶＭの稼働率が高くなる。

また、発生する処理要求の数を予め想定し、その数に対応するためのサービスＶＭをホスティングサービス２４に予め配置し、ホスティングサービス２４のみを利用することも考えられる。しかし、想定した数を超える数の処理要求が発生する場合もあり、その場合には、超過した処理要求に応じた処理が実行されないことになる。本実施形態では、超過した処理要求に応じた処理はクラウドサービス２６を利用して実行されるので、このような問題の発生が防止される。

以下、変形例について説明する。

（変形例１）
ユーザ振り分け部２０は、ホスティングサービス２４に含まれる全サービスＶＭ（サービスＶＭ３６，３８，４０，４２）が対応可能な負荷を超える処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭに処理を割り当ててもよい。例えば、各サービスＶＭは複数の処理を並列的に実行可能であるとする。ユーザ振り分け部２０は、各サービスＶＭの負荷（例えばＣＰＵの使用率）と要求された処理の負荷とに応じて、別の処理を実行中のサービスＶＭに当該要求された処理を割り当て、ホスティングサービス２４に含まれる全サービスＶＭ（サービスＶＭ３６，３８，４０，４２）が対応可能な負荷を超える処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭ（例えばサービスＶＭ４４，４６）を配置してそのサービスＶＭに処理を割り当てる。例えば、ユーザ振り分け部２０は、第１処理としての軽い処理（例えばユーザインターフェース処理）を新たに受け付けた場合、軽い処理を既に実行中のサービスＶＭに、その新たに受け付けた軽い処理を割り当てる。一方、ユーザ振り分け部２０は、軽い処理よりも負荷が大きい第２処理としての重い処理（例えばジョブ処理）を新たに受け付けた場合、処理を実行していない別のサービスＶＭに、その新たに受け付けた重い処理を割り当てる。この場合において、ユーザ振り分け部２０は、ホスティングサービス２４に含まれる全サービスＶＭ（サービスＶＭ３６，３８，４０，４２）が対応可能な負荷を超える処理要求を受け付けた場合、クラウドサービス２６にサービスＶＭを配置してそのサービスＶＭに処理を割り当てる。この場合においても、上述した実施形態と同様に、ホスティングサービス２４に配置されたサービスＶＭによって処理を実行できない場合であっても、クラウドサービス２６を利用して処理が継続される。

（変形例２）
ホスティングサービス２４は、情報処理システム１０が提供するサービスを利用するテナントの数（ユーザの数）以上のサービスＶＭを含んでもよい。上記の例では、テナントＡ、Ｂ，Ｃ（ユーザＡ，Ｂ，Ｃ）がサービスを利用しているため、テナント数は「３」である。この場合、ホスティングサービス２４には、３個以上のサービスＶＭが配置される。また、ホスティングサービス２４は、個々のテナント毎（個々のユーザ毎）に、少なくとも１つの専用のサービスＶＭを含み、各テナントに少なくとも１つのサービスＶＭが予め割り当てられていてもよい。例えば、サービスＶＭ３６がテナントＡ専用のサービスＶＭであり、サービスＶＭ３８がテナントＢ専用のサービスＶＭであり、サービスＶＭ４０がテナントＣ専用のサービスＶＭであるとする。この場合、サービスＶＭ３６にテナントＡが予め割り当てられ、サービスＶＭ３８にテナントＢが予め割り当てられ、サービスＶＭ４０にテナントＣが予め割り当てられる。ユーザ振り分け部２０は、テナントＡからの処理要求をサービスＶＭ３６に割り当て、テナントＢからの処理要求をサービスＶＭ３８に割り当て、テナントＣからの処理要求をサービスＶＭ４０に割り当てる。各テナントには少なくとも１つのサービスＶＭが割り当てられるので、ホスティングサービス２４内のサービスＶＭに割り当てられないテナントの発生が防止される。

（変形例３）
情報処理システム１０は緊急用のサービスＶＭを含んでもよい。例えば、ホスティングサービス２４とクラウドサービス２６に、割り当て可能なサービスＶＭが存在しない場合、ユーザ振り分け部２０は、緊急用のサービスＶＭに処理を割り当ててもよい。割り当て可能なサービスＶＭは、例えば、起動しているサービスＶＭであって、別の処理を実行していないＶＭである。例えば、すべてのサービスＶＭが処理を実行している場合、割り当て可能なサービスＶＭが存在しないことになる。緊急用のサービスＶＭは、通常動作においては使用されないサービスＶＭである。緊急用のサービスＶＭは、例えばホスティングサービス２４内に予め用意されたサービスＶＭであってもよいし、オーバーコミット可能なＶＭ実行基盤が管理するＶＭ群に含まれるサービスＶＭであってもよいし、コンテナ技術を用いてＶＭ内に起動されてもよい。緊急用のサービスＶＭは、例えば、特定の処理（例えばユーザインターフェース処理）を実行するための専用のサービスＶＭであってもよい。この場合、ユーザ振り分け部２０は、割り当て可能なサービスＶＭが存在しない場合において、ログイン処理の要求を受け付けた場合、緊急用のサービスＶＭにユーザインターフェース処理を割り当てる。これにより、緊急用のサービスＶＭを用いない場合と比べて、ログイン処理要求に対して、何らかのレスポンス（例えばログイン成功又は不成功）がより迅速に返される。なお、ユーザ振り分け部２０は、ジョブ処理の要求を受け付けた場合、緊急用のサービスＶＭにジョブを割り当てない。この場合であっても、ジョブはキューの末尾に追加され、順番に従って実行されることになる。

以下、図４を参照して、ユーザ振り分け部２０によるユーザ振り分け処理について詳しく説明する。図４には、ユーザ振り分け処理に関するフローチャートが示されている。

まず、ユーザは端末装置１２を用いて情報処理システム１０に接続し（Ｓ０１）、ユーザ振り分け部２０は、そのユーザのテナントを決定する（Ｓ０２）。例えば、ユーザがテナントＡに属する場合、そのユーザのテナントはテナントＡである。

次に、ユーザ振り分け部２０は、ユーザのテナント内（例えばテナントＡ内）に受け入れ可能なサービスＶＭが存在するか調査する（Ｓ０３）。つまり、ユーザ振り分け部２０は、テナントＡに既に割り当てられているサービスＶＭであって、起動が完了しているが処理を実行していないサービスＶＭが存在するか調査する。そのようなサービスＶＭが存在する場合（Ｓ０４，Ｙｅｓ）、ＶＭ制御部２２は、受入ＶＭ選択処理を実行する（Ｓ０５）。そのようなサービスＶＭが存在しない場合（Ｓ０４，Ｎｏ）、ＶＭ制御部２２は、新規ＶＭ確保処理を実行する（Ｓ０６）。

ステップＳ０５，Ｓ０６の処理によってサービスＶＭが確保されると、ユーザ振り分け部２０は、そのサービスＶＭにユーザを振り分ける（Ｓ０７）。例えば、ユーザ振り分け部２０は、ジョブやユーザインターフェース処理をそのサービスＶＭに割り当てる。なお、ユーザ振り分け部２０は、テナントＡの多重度を参照し、テナントＡからの要求数が多重度を超えている場合、ユーザをサービスＶＭに振り分けない。

以下、図５を参照して、上記の受入ＶＭ選択処理（図４中のＳ０５の処理）について詳しく説明する。図５には、受入ＶＭ処理に関するフローチャートが示されている。

ＶＭ制御部２２は、図１に示されているＶＭ実行基盤１６ａ，・・・，１６ｎの中から１つのＶＭ実行基盤（ｉ）を選択する（Ｓ１０）。ＶＭ制御部２２は、基盤番号の小さい順にＶＭ実行基盤を選択してもよいし、処理速度の速い順にＶＭ実行基盤を選択してもよいし、利用単価の安い順にＶＭ実行基盤を選択してもよい。この場合においても、ＶＭ制御部２２は、クラウドサービス２６内のＶＭよりもホスティングサービス２４内のＶＭを優先的に選択する。

次に、ＶＭ制御部２２は、ＶＭ実行基盤（ｉ）が管理するＶＭ群の中に受け入れ可能なサービスＶＭが存在するか調査する（Ｓ１１）。例えば、起動しているが処理を実行していないサービスＶＭが、受け入れ可能なサービスＶＭに該当し、割り込み処理等によって別の処理を実行しているサービスＶＭが、受け入れ不可能なサービスＶＭに該当する。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中に受け入れ可能なサービスＶＭが存在する場合（Ｓ１２，Ｙｅｓ）、ＶＭ制御部２２は、そのサービスＶＭを確保する（Ｓ１３）。この場合、ユーザ振り分け部２０は、そのサービスＶＭにユーザを振り分ける（図４中のＳ０７）。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中に受け入れ可能なサービスＶＭが存在しない場合であって（Ｓ１２，Ｎｏ）、他のＶＭ実行基盤の選択が可能な場合（Ｓ１４，Ｙｅｓ）、つまり、未調査のＶＭ実行基盤が存在する場合、処理はステップＳ１０に移行する。この場合、ＶＭ制御部２２は、次のＶＭ実行基盤を選択し（Ｓ１０）、そのＶＭ実行基盤が管理するＶＭ群の中に受け入れ可能なサービスＶＭが存在するか調査する（Ｓ１１）。受け入れ可能なサービスＶＭが存在する場合（Ｓ１２，Ｙｅｓ）、そのサービスＶＭが確保される。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中に受け入れ可能なサービスＶＭが存在しない場合であって（Ｓ１２，Ｎｏ）、他のＶＭ実行基盤の選択が不可能な場合（Ｓ１４，Ｎｏ）、つまり、未調査のＶＭ実行基盤が存在しない場合、ＶＭ制御部２２は、緊急用のサービスＶＭを確保する（Ｓ１５）。この場合、ユーザ振り分け部２０は、緊急用のサービスＶＭにユーザを振り分ける（図４中のＳ０７）。なお、ユーザ振り分け部２０は、要求されている処理の内容を確認し、その処理がログイン処理の場合、緊急用のサービスＶＭにユーザを振り分けてログイン処理を割り当て、その処理がジョブ処理の場合、緊急用のサービスＶＭにユーザを振り分けずジョブ処理を割り当てなくてもよい。

以下、図６を参照して、上記の新規ＶＭ確保処理（図４中のＳ０６の処理）について詳しく説明する。図６には、新規ＶＭ確保処理に関するフローチャートが示されている。

ＶＭ制御部２２は、図１に示されているＶＭ実行基盤１６ａ，・・・，１６ｎの中から１つのＶＭ実行基盤（ｉ）を選択する（Ｓ２０）。ＶＭ制御部２２は、基盤番号の小さい順にＶＭ実行基盤を選択してもよいし、処理速度の速い順にＶＭ実行基盤を選択してもよいし、利用単価の安い順にＶＭ実行基盤を選択してもよい。この場合においても、ＶＭ制御部２２は、クラウドサービス２６内のＶＭよりもホスティングサービス２４内のＶＭを優先的に選択する。

次に、ＶＭ制御部２２は、ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できるか調査する（Ｓ２１）。例えば、処理を実行していないサービスＶＭが、新規に確保可能なサービスＶＭに該当し、割り込み処理等によって別の処理を実行しているサービスＶＭが、新規に確保不可能なサービスＶＭに該当する。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できる場合（Ｓ２２，Ｙｅｓ）、ＶＭ制御部２２は、そのサービスＶＭを確保する（Ｓ２３）。この場合、ユーザ振り分け部２０は、そのサービスＶＭにユーザを振り分ける（図４中のＳ０７）。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できない場合であって（Ｓ２２，Ｎｏ）、他のＶＭ実行基盤の選択が可能な場合（Ｓ２４，Ｙｅｓ）、つまり、未調査のＶＭ実行基盤が存在する場合、処理はステップＳ２０に移行する。この場合、ＶＭ制御部２２は、次のＶＭ実行基盤を選択し（Ｓ２０）、そのＶＭ実行基盤が管理するＶＭ群の中で新規のサービスＶＭを確保できるか調査する（Ｓ２１）。新規のサービスＶＭを確保できる場合（Ｓ２２，Ｙｅｓ）、そのサービスＶＭが確保される。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できない場合であって（Ｓ２２，Ｎｏ）、他のＶＭ実行基盤の選択が不可能な場合（Ｓ２４，Ｎｏ）、つまり、未調査のＶＭ実行基盤が存在しない場合、ＶＭ制御部２２は、新規ＶＭ確保リトライ処理を実行する（Ｓ２５）。

以下、図７を参照して、上記の新規ＶＭ確保リトライ処理（図６中のＳ２５の処理）について詳しく説明する。図７には、新規ＶＭ確保リトライ処理に関するフローチャートが示されている。

ＶＭ制御部２２は、図１に示されているＶＭ実行基盤１６ａ，・・・，１６ｎの中から１つのＶＭ実行基盤（ｉ）を選択する（Ｓ３０）。リトライ処理においては、ＶＭ制御部２２は、基盤番号の小さい順から予め定められた数（例えば５個）のＶＭ実行基盤を選択してもよいし、処理速度の速い順に予め定められた数（例えば５個）のＶＭ実行基盤を選択してもよいし、オーバーコミット可能なＶＭ実行基盤を選択してもよい。この場合においても、ＶＭ制御部２２は、クラウドサービス２６内のＶＭよりもホスティングサービス２４内のＶＭを優先的に選択する。

次に、ＶＭ制御部２２は、ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できるか調査する（Ｓ３１）。例えば、処理を実行していないサービスＶＭが、新規に確保可能なサービスＶＭに該当し、割り込み処理等によって別の処理を実行しているサービスＶＭが、新規に確保不可能なサービスＶＭに該当する。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できる場合（Ｓ３２，Ｙｅｓ）、ＶＭ制御部２２は、そのサービスＶＭを確保する（Ｓ３３）。この場合、ユーザ振り分け部２０は、そのサービスＶＭにユーザを振り分ける（図４中のＳ０７）。なお、図６に示されている新規ＶＭ確保処理にて新規のサービスＶＭを確保できなかった場合であっても、リトライ処理中に、サービスＶＭにて処理の実行が完了する場合がある。この場合、そのサービスＶＭが新規のサービスＶＭとして確保される。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できない場合であって（Ｓ３２，Ｎｏ）、他のＶＭ実行基盤の選択が可能な場合（Ｓ３４，Ｙｅｓ）、つまり、未調査のＶＭ実行基盤が存在する場合、処理はステップＳ３０に移行する。この場合、ＶＭ制御部２２は、次のＶＭ実行基盤を選択し（Ｓ３０）、そのＶＭ実行基盤が管理するＶＭ群の中で新規のサービスＶＭを確保できるか調査する（Ｓ３１）。新規のサービスＶＭを確保できる場合（Ｓ３２，Ｙｅｓ）、そのサービスＶＭが確保される。

ＶＭ実行基盤（ｉ）が管理するＶＭ群の中で新規のサービスＶＭを確保できない場合であって（Ｓ３２，Ｎｏ）、他のＶＭ実行基盤の選択が不可能な場合（Ｓ３４，Ｎｏ）、つまり、未調査のＶＭ実行基盤が存在しない場合、ＶＭ制御部２２は、緊急用のサービスＶＭを確保する（Ｓ３５）。この場合、ユーザ振り分け部２０は、緊急用のサービスＶＭにユーザを振り分ける（図４中のＳ０７）。なお、ユーザ振り分け部２０は、要求されている処理の内容を確認し、その処理がログイン処理の場合、緊急用のサービスＶＭにユーザを振り分けてログイン処理を割り当て、その処理がジョブ処理の場合、緊急用のサービスＶＭにユーザを振り分けずジョブ処理を割り当てなくてもよい。

上記の実施形態及び変形例では、情報処理システム１０が印刷ジョブの実行サービスをユーザに提供する例について説明したが、情報処理システム１０は、スキャンによって得られた画像に対するデータ処理や画像の転送処理等の他のジョブを実行してもよい。この場合、端末装置１２は、スキャナ、ファクシミリ装置、複合機（プリンタ、スキャナ、コピー機、ファクシミリ装置等の機能を併せ持つ装置）等であってもよい。

上記の情報処理システム１０は、一例としてハードウェアとソフトウェアとの協働により実現される。具体的には、情報処理システム１０は、図示しないＣＰＵ等の１又は複数のプロセッサを備えている。当該１又は複数のプロセッサが、図示しない記憶装置に記憶されたプログラムを読み出して実行することにより、情報処理システム１０の各部の機能が実現される。上記プログラムは、ＣＤやＤＶＤ等の記録媒体を経由して、又は、ネットワーク等の通信経路を経由して、記憶装置に記憶される。別の例として、情報処理システム１０の各部は、例えばプロセッサや電子回路やＡＳＩＣ（Application Specific Integrated Circuit）等のハードウェア資源により実現されてもよい。その実現においてメモリ等のデバイスが利用されてもよい。更に別の例として、情報処理システム１０の各部は、ＤＳＰ（Digital Signal Processor）やＦＰＧＡ（Field Programmable Gate Array）等によって実現されてもよい。

１０ 情報処理システム、１２ 端末装置、１４ａ，１４ｎ ＶＭ群、１６ａ，１６ｎ ＶＭ実行基盤、１８ テナント管理部、２０ ユーザ振り分け部、２２ ＶＭ制御部。

Claims (10)

1. データの処理要求を受け付ける受付手段と、
   前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部と、
   を有し、
   各処理部は、複数の処理を並列的に実行可能であり、
   前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、各処理部の負荷と要求された処理の負荷とに応じて、別の処理を実行中の処理部に当該要求された処理を割り当て、予め定められた第１処理の要求を新たに受け付けた場合、第１処理を既に実行中の処理部に、その新たに受け付けた第１処理を割り当て、前記第１処理よりも負荷が大きい第２処理の要求を新たに受けた場合、処理を実行していない別の処理部に、その新たに受けた第２処理を割り当て、前記第１処理グループに含まれる全処理部が対応可能な負荷を超える処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当てる、
   ことを特徴とする情報処理装置。
2. 前記第１処理は、ユーザのログイン処理を含む処理であり、
   前記第２処理は、画像処理を含む処理である、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記上限数は、各ユーザが要求可能な並列処理の数に基づいて決定される、
   ことを特徴とする請求項１又は請求項２に記載の情報処理装置。
4. 前記第１処理グループは、個々のユーザ毎に、少なくとも１つの専用の処理部を含み、各ユーザに少なくとも１つの専用の処理部が予め割り当てられている、
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理装置。
5. 前記第１処理グループは、ユーザの数以上の数の処理部を含む、
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記制御部は、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、
   ことを特徴とする請求項１から請求項５のいずれか一項に記載の情報処理装置。
7. データの処理要求を受け付ける受付手段と、
   前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部と、
   を有し、
   前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、前記第１処理グループに含まれる処理部では処理しきれない処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当て、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、
   ことを特徴とする情報処理装置。
8. 前記制御部は、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合において、ユーザのログイン処理の要求を受けた場合、前記緊急用の処理部に前記ログイン処理を割り当てる、
   ことを特徴とする請求項６又は請求項７に記載の情報処理装置。
9. コンピュータを、
   データの処理要求を受け付ける受付手段、
   前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め設定された上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部、
   として機能させ、
   前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、各処理部の負荷と要求された処理の負荷とに応じて、別の処理を実行中の処理部に当該要求された処理を割り当て、予め定められた第１処理の要求を新たに受け付けた場合、第１処理を既に実行中の処理部に、その新たに受け付けた第１処理を割り当て、前記第１処理よりも負荷が大きい第２処理の要求を新たに受けた場合、処理を実行していない別の処理部に、その新たに受けた第２処理を割り当て、前記第１処理グループに含まれる全処理部が対応可能な負荷を超える処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当てる、
   ことを特徴とするプログラム。
10. コンピュータを、
    データの処理要求を受け付ける受付手段、
    前記受付手段が処理要求を受け付けた場合、データを処理する処理部を含むグループであって予め定められた上限数よりも少ない数の処理部を含む第１処理グループ、又は、１又は複数の処理部の配置が可能な第２処理グループ、のいずれかに処理を割り当てる制御部、
    として機能させ、
    前記制御部は、前記第１処理グループに含まれる処理部から優先的に起動して処理を割り当て、前記第１処理グループに含まれる処理部では処理しきれない処理要求を受け付けた場合、前記第２処理グループに処理部を配置してその処理部に処理を割り当て、前記第１処理グループ及び前記第２処理グループに割り当て可能な処理部が無い場合、緊急用の処理部に処理を割り当てる、
    ことを特徴とするプログラム。

Images