(58)【調査した分野】(Int.Cl.,DB名)
前記リクエスト分割処理手段は、前記リクエストを処理させる送信先の機器に応じて当該リクエストに対して分割処理を行うことを特徴とする請求項1乃至4のいずれか1項に記載の情報処理装置。
クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理装置における情報処理方法であって、
前記情報処理装置は、
クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理ステップと、
前記入力用記憶部それぞれのリクエストの取得処理を行う入力リクエスト処理ステップと、
前記入力リクエスト処理ステップにより取得処理されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理ステップと、
を含むことを特徴とする情報処理方法。
クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理システムにおける情報処理方法であって、
前記情報処理システムは、
クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理ステップと、
前記入力用記憶部それぞれのリクエストを取得して出力用記憶部に記憶する処理を行う入力リクエスト処理ステップと、
前記出力用記憶部に記憶されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理ステップと、
を含むことを特徴とする情報処理方法。
【発明の概要】
【発明が解決しようとする課題】
【0008】
前述の各手法は、サーバーリソースを如何に有効活用するかという観点からリクエストの制御を行う手法であり、マルチテナント特有の複数のテナントにて負荷のピークが重なった場合などに、他のテナントの処理性能に影響を及ぼすデメリットを解決する手法ではない。
よって、サーバーリソースの限界を上回る数のリクエストがクライアントから送信される状態が発生した場合、サービスを使用していなかったテナントにおいても、すでにサーバー側で受け付けられたリクエストが処理されるまで、サービスを利用できない状況が発生する。
【0009】
本発明は、マルチテナント型のサービスを提供するにあたり、
テナントのリクエストに応じた処理を効率的に
行うことを目的とする。
【課題を解決するための手段】
【0010】
前述した目的を達成するための第1の発明は、クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理装置であって、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理手段と、前記入力用記憶部それぞれのリクエスト
の取得
処理
を行う入力リクエスト処理手段と、前記入力
リクエスト処理手段により取得処理されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理手段と、を備えることを特徴とする情報処理装置である。
【0011】
本発明によれば、クライアントからのリクエストを受付けて処理を実行する情報処理装置において、入力用記憶手段によって、リクエストの送信元毎にクライアントからのリクエストが記憶される。ここに、本発明に係る入力用記憶手段とは、コンピュータの基本的なデータ構造の一つであり、例えば、キュー(queue)、又は、待ち行列を実現可能な記憶手段を意味する。典型的には、データを先入れ先出し(FIFO: First In First Out)のリスト構造で保持する記憶手段である。リクエスト入力処理手段によって、受付けたリクエストの送信元に応じてリクエストが入力用記憶手段に記憶される。リクエスト処理手段によって、入力用記憶手段に記憶されたリクエストを処理した後、このリクエストの処理を行ったリクエストとは異なる送信元のリクエストの処理が行われる。
【0012】
これにより、例えば入力用のキュー等の入力用記憶手段において、リクエストの送信元毎にクライアントからのリクエストが記憶される。
これにより、各テナントの例えば各入力用のキュー等の各入力用記憶手段を順番に参照してリクエストを移行することができる。これにより、送信元毎、即ち、テナント毎に各入力用のキューにおけるリクエストの処理であるサービスの実行に制限を設けることができる。これにより、特定の送信元がサーバーのリソースを占有することを防ぎ、各送信元のリクエストが処理されるまでの待ち時間が、待ち行列理論で決定される最大待ち時間を超えないことを保証することができる。
【0013】
よって、サーバーリソースの限界を上回る数のリクエストがクライアントから送信される状態が発生した場合、サービスを使用していなかった送信元においても、サーバーリソースが予め割り当てられているので、すでにサーバー側で受け付けられたリクエストの全てが処理されるのを待つ必要なく、サービスを利用することができる。
以上の結果、マルチテナント型のサービスを提供するにあたり、送信元毎にリクエストの処理を行うことを実現することで、リクエストの処理を実行する実行サーバーのリソースを効率的に利用することが可能になる。
【0014】
第1の発明に係る前記分割処理は、前記リクエストの送信先で実行される処理に応じてリクエストを生成する処理を行う。
【0015】
第1の発明に係る情報処理装置は、前記分割処理によって分割されたリクエストを順次記憶する分散処理用記憶手段と、前記分散処理用記憶手段に記憶されたリクエストの処理を順次行う分散出力処理手段と、を更に備える。
また、第1の発明に係る前記入力用記憶部は、前記クライアントからのリクエストを受付けるテナントに対応させて複数備えられており、前記
入力リクエスト
処理手段は、未処理のリクエストが記憶されている入力用記憶部それぞれの先頭のリクエストを順に一つずつ取得して、前記それぞれの入力用記憶部から取得したリクエストを順次処理する。
【0016】
第1の発明に係る前記入力用記憶
部は、テナント毎に備えられたキューである。
これにより、テナント毎に各入力用のキューにおけるリクエストの処理であるサービスの実行に制限を設けることができる。
【0019】
第1の発明に係る前記分
散処理用記憶手段は、1つのキューである。前記分散出力処理手段は、前記分散処理用記憶手段に記憶されたリクエストを送信先の機器へ送信する。前記リクエスト分割処理手段は、前記リクエストを処理させる送信先の機器に応じて当該リクエストに対して分割処理を行う。
【0020】
これにより、マルチテナント型のサービスを提供するにあたり、
テナント毎にリクエストの処理を行うことを実現することで、
分散処理実行サーバーのリソースを効率的に利用することが可能になる。
特に、分割リクエスト送信手段が、分散処理用記憶手段から取得した分割リクエストを順次処理することにより、分散処理実行サーバーにおいて、同時期に実行される分割リクエストの上限は、分割リクエスト送信手段の数と等しくなる。
これにより、テナントからのリクエストが大量に発生している状態においては、各分散処理実行サーバーの負荷が上がり過ぎることを抑制でき、逆に、テナントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。
【0021】
前述した目的を達成するための第2の発明は、クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理システムであって、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理手段と、前記入力用記憶部それぞれのリクエストを取得して出力用記憶部に記憶する処理を行う入力リクエスト処理手段と、
前記出力用記憶部に記憶されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理手段と、を備えたことを特徴とする情報処理システムである。
これにより、マルチテナント型のサービスを提供するにあたり、リクエストの処理を実行する実行サーバーのリソースを効率的に利用することが可能になる。
【0022】
第2の発明に係る情報処理システムは
、前記分割処理によって分割されたリクエストを順次記憶する分散処理用記憶手段と、前記分散処理用記憶手段に記憶されたリクエストの処理を順次行う分散出力処理手段と、を更に備える。
これにより、マルチテナント型のサービスを提供するにあたり
、分散処理実行サーバーのリソースを効率的に利用することが可能になる。特に、分割リクエスト送信手段が、分散処理用記憶手段から取得した分割リクエストを順次処理することにより、分散処理実行サーバーにおいて、同時期に実行される分割リクエストの上限は、分割リクエスト送信手段の数と等しくなる。
これにより、
クライアントからのリクエストが大量に発生している状態においては、各分散処理実行サーバーの負荷が上がり過ぎることを抑制でき、逆に、
クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。
【0024】
前述した目的を達成するための第3の発明は、クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理装置における情報処理方法であって、前記情報処理装置は、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理ステップと、前記入力用記憶部それぞれのリクエストの取得処理を行う入力リクエスト処理ステップと、前記入力リクエスト処理
ステップにより取得処理されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理ステップと、を含むことを特徴とする情報処理方法である。これにより、マルチテナント型のサービスを提供するにあたり、リクエストの処理を実行する実行サーバーのリソースを効率的に利用することが可能になる。
【0025】
前述した目的を達成するための第4の発明は、コンピュータを、クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理装置として機能させるためのプログラムであって、前記コンピュータを、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理手段、前記入力用記憶部それぞれのリクエスト
の取得
処理
を行う入力リクエスト処理手段、前記入力
リクエスト処理手段により取得処理されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理手段、として機能させるためのプログラムである。
第4の発明を汎用のコンピュータにインストールすることによって、第1の発明に係る情報処理装置を得て、第3の発明の情報処理方法を実行することができる。
【0026】
前述した目的を達成するための第5の発明は、クライアントからのリクエストを受付ける当該クライアントに対応する入力用記憶部を複数備え、当該リクエストの処理を実行する情報処理システムにおける情報処理方法であって、前記情報処理システムは、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理ステップと、前記入力用記憶部それぞれのリクエストを取得して出力用記憶部に記憶する処理を行う入力リクエスト処理ステップと、
前記出力用記憶部に記憶されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理ステップと、を含むことを特徴とする情報処理方法である。
これにより、マルチテナント型のサービスを提供するにあたり、リクエストの処理を実行する実行サーバーのリソースを効率的に利用することが可能になる。
【0027】
前述した目的を達成するための第6の発明は、コンピュータを、クライアントからのリクエストを受付ける当該クライアントに対応する処理を実行する情報処理システムとして機能させるためのプログラムであって、前記コンピュータを、クライアントからのリクエストを、対応する入力用記憶部に記憶させるリクエスト入力処理手段、前記入力用記憶部それぞれのリクエストを取得して出力用記憶部に記憶する処理を行う入力リクエスト処理手段、
前記出力用記憶部に記憶されたリクエストを分割するための分割条件に従って前記リクエストの分割処理を行うリクエスト分割処理手段、として機能させるためのプログラムである。
これにより、マルチテナント型のサービスを提供するにあたり、リクエストの処理を実行する実行サーバーのリソースを効率的に利用することが可能になる。
【発明の効果】
【0028】
本発明によれば、マルチテナント型のサービスを提供するにあたり、テナント毎にリクエスト
に応じた処理を行うことを実現することで、
テナントのリクエスト
に応じた処理を
効率的に
行うことが可能になる。
【発明を実施するための形態】
【0030】
以下、図面を参照して、本発明の実施形態を詳細に説明する。なお、説明の簡略化のため、以下、マルチテナント型サービス実行制御装置をMTQ(Multi Tenant Queue:マルチテナントキュー)と表記する。
【0031】
(基本構成:マルチテナント型サービス実行制御装置)
図1は、本発明の実施形態におけるMTQの構成を示す図である。MTQ100は、複数の入力用キュー110と、1つの出力用キュー120と、リクエスト入力処理部130と、リクエスト移行処理部140と、リクエスト出力処理部150とを備える。尚、入力用キュー110によって、本発明に係る入力用記憶手段の一例が構成されている。また、出力用キュー120によって、本発明に係る出力用記憶手段の一例が構成されている。また、リクエスト入力処理部130によって、本発明に係るリクエスト入力処理手段の一例が構成されている。また、リクエスト移行処理部140によって、リクエスト移行処理手段の一例が構成されている。
【0032】
入力用キュー110は、テナントごとのリクエストを受け付けるキューで、テナントごとに対応するキューが1つ以上存在する。尚、テナントによって、本発明に係る送信元の一例が構成されている。
図1において、MTQ100は、テナントAに対応する入力用キュー111、テナントBに対応する入力用キュー112、および、テナントCに対応する入力用キュー113、114を備える。
出力用キュー120は、リクエストの処理順序をFIFO形式で管理するキューで、各テナントで共有して用いる。
【0033】
CPU201及びメモリで構成されたリクエスト移行処理部140は、入力用キュー110からリクエストを取得し、出力用キュー120へ順次移行する。
CPU201及びメモリで構成されたリクエスト入力処理部130における入力用キュー110へのリクエスト入力処理、リクエスト出力処理部150における出力用キュー120からのリクエスト出力処理、および、リクエスト移行処理部140におけるリクエスト移行処理については、それぞれ詳しく「(リクエスト入力処理)」「(リクエスト出力処理)」「(リクエスト移行処理)」にて後述される。
【0034】
(ハードウェア構成:マルチテナント型サービス実行制御装置)
次に、
図1のMTQ100のハードウェア構成について、
図2を用いて説明する。
図中、CPU201は、システムバス204に接続される後述の各デバイスやコントローラを統括的に制御する。また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるBIOS(Basic Input / Output System)やオペレーティングシステムプログラム(以下、OS)や、MTQ100に後述する各種の処理を実行させるために必要な各種プログラムやデータ等が記憶されている。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。尚、以下、RAM202及びROM203を単にメモリと称す。
【0035】
CPU201は、処理の実行に際して必要なプログラム等をRAM202にロードして、プログラムを実行することで後述する各種処理を実現するものである。また、入力コントローラ(入力C)205は、キーボードやポインティングデバイス等で構成される入力装置209からの入力を制御する。ビデオコントローラ(VC)206は、ディスプレイ装置210等の表示装置への表示を制御する。ディスプレイ装置210は、例えばCRTディスプレイや液晶ディスプレイ等で構成される。
【0036】
メモリコントローラ(MC)207は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク(HD)やフロッピー(登録商標)ディスク或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)メモリ等の外部メモリ211へのアクセスを制御する。
【0037】
通信I/Fコントローラ(通信I/FC)208は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いたインターネット通信等が可能である。
【0038】
なお、CPU201は、例えばRAM202内の表示情報用領域へアウトラインフォントの展開(ラスタライズ)処理を実行することにより、ディスプレイ装置210上での表示を可能としている。また、CPU201は、ディスプレイ装置210上の不図示のマウスカーソル等でのユーザ指示を可能とする。以上が、マルチテナント型サービス実行制御装置100のハードウェア構成の説明であるが、後述する各種の処理を実行可能であれば、必ずしも
図2に記載のハードウェア構成を有していなくとも構わないことは言うまでもない。
【0039】
(リクエスト入力処理)
次に、リクエスト入力処理部130におけるリクエスト入力処理について、
図1、
図3、
図4を用いて詳しく説明する。
このリクエスト入力処理は、リクエスト入力処理部130が、入力用キュー110に空きが発生するまで入力処理を待機するリクエスト待機入力処理と、入力用キュー110に空きが存在しない場合はエラーを発生させるリクエスト不待機入力処理とを実行する、2つの処理を示している。
【0040】
図3は、リクエスト待機入力処理のフローチャートを示しており、
図4は、リクエスト不待機入力処理のフローチャートを示している。なお、MTQ100を用いた各入力処理に用いるリクエストは、テナントを一意に識別するID(テナントID)に関する情報を含む。
リクエスト待機入力処理では、まず、ステップS301において、MTQ100のCPU201は、入力として与えたテナントIDに該当する入力用キューを取得する。例えば、リクエスト161に含まれるテナントIDがテナントAを表す識別子である場合、リクエスト入力処理部130は、テナントA入力用キュー111を取得する。
【0041】
次に、ステップS302において、MTQ100のCPU201は、S301で取得した入力用キュー110に空きができるまで待機し、ステップS303でリクエストを当該キューに格納し、S304で入力用キュー110への入力が完了したことを示す実行結果をリクエスト入力要求元(即ち、クライアントたるテナント)へ返す。
リクエスト不待機入力処理では、S401で、S301と同様に、MTQ100のCPU201は、入力として与えたテナントIDに該当する入力用キュー110を取得する。
【0042】
次に、ステップS402で、MTQ100のCPU201は、ステップS401で取得した入力用キュー110の状態を確認する。ここで、入力用キュー110に空きが存在する場合(ステップS401でYes)、MTQ100のCPU201は、ステップS403でリクエストを当該キューに格納し、ステップS404で入力用キュー110への入力が完了したことを示す実行結果をクライアントたるテナントへ返す。
【0043】
他方で、ステップS402で、入力用キュー110に空きが存在しない場合(ステップS401でNo)、MTQ100のCPU201は、ステップS405で、入力用キュー110への入力が失敗したことを示す実行結果をリクエスト入力要求元(即ち、クライアントたるテナント)へ返す。特に、このステップS402において、CPU201及びメモリで構成されたリクエスト入力処理部130が、入力用キュー110に対して、リクエストを記憶する際に、リクエスト自体の容量が、リクエストの送信元たるテナントに応じた記憶容量を超えたか否かを判定してよい。そして、リクエスト自体の容量が、リクエストの送信元たるテナントに応じた記憶容量を超えた場合、MTQ100のCPU201は、リクエストの送信元たるテナントへ受付け不可の通知を行ってもよい。
【0044】
(リクエスト出力処理)
次に、リクエスト出力処理部150におけるリクエスト出力処理について、
図1、
図5、
図6を用いて詳しく説明する。
このリクエスト出力処理は、リクエスト出力処理部150は、出力用キュー120にリクエストが入力されるまで待機するリクエスト待機出力処理と、出力用キュー120にリクエストが存在しない場合はエラーを発生させるリクエスト不待機出力処理とを実行する、2つの処理を示している。
【0045】
図5は、リクエスト待機出力処理のフローチャートを示しており、
図6は、リクエスト不待機出力処理のフローチャートを示している。
リクエスト待機出力処理では、まず、MTQ100のCPU201は、ステップS501において、出力用キュー120にリクエストが入力されるまで待機する。次に、ステップS502で、MTQ100のCPU201は、出力用キュー120からリクエストを1つ取得し、ステップS503で当該リクエスト163をリクエスト出力要求
元へ返す。
【0046】
リクエスト不待機出力処理では、まず、MTQ100のCPU201は、ステップS601において、出力用キュー120が空であるか確認する。空でなく、リクエストが存在する場合(ステップS601でNoの場合)、MTQ100のCPU201は、ステップS602で出力用キュー120からリクエストを1つ取得し、ステップS603で当該リクエストをリクエスト出力要求
元へ返す。
ステップS601で、出力用キュー120が空である場合(ステップS601でYesの場合)、MTQ100のCPU201は、ステップS604で、リクエストが存在しないことを示す実行結果をリクエスト出力要求
元へ返す。
【0047】
(リクエスト移行処理)
次に、リクエスト移行処理部140におけるリクエスト移行処理について、
図1、
図7を用いて詳しく説明する。
リクエスト入力処理部130、および、リクエスト出力処理部150が、外部からの要求を受けて各処理を実行するのに対し、リクエスト移行処理部140は、MTQ100が停止するまで、自立的にリクエスト移行処理を繰り返す。
【0048】
CPU201、RAM及びROM等のメモリによって構成されたリクエスト移行処理部140は、ステップS701からステップS704において、各入力用キュー111乃至114を順次参照して、リクエストを出力用キュー120へ移行する。
CPU201及びメモリによって構成されたリクエスト移行処理部140は、ステップS702では、参照中の入力用キュー110にリクエストが存在する場合は、ステップS703で出力用キュー120に空きができるまで待機し、ステップS704で当該入力用キュー110からリクエストを1つ取得して出力用キュー120へ移行する。特に、リクエスト移行処理部140は、入力用キュー110からリクエストを出力用キュー120へ移行する際に、入力用キュー111乃至114のうち毎回異なるいずれか一つからのリクエストを順次取得してよい。
【0049】
次に、ステップS705で、CPU201及びメモリによって構成されたリクエスト移行処理部140は、ステップS701〜ステップS704においてリクエストを移行したか否かを判定し、リクエストを1つも移行していないと判定した場合、すなわち、入力用キュー110にリクエストが存在しなかった場合は、ステップS706でいずれかの入力用キュー110にリクエストが格納されるまで待機する。
その後、ステップS707において、CPU201及びメモリによって構成されたリクエスト移行処理部140は、MTQ100が稼働中であるか否かを確認し、稼働中である間、ステップS701からステップS706の処理を繰り返す。
【0050】
以上で説明したMTQ100は、テナントごとに占用の入力用キュー110が1つ以上存在するため、あるテナントのリクエストを、対応する入力用キュー110のサイズ分だけ同時に受け付けられることを保証できる。
また、出力用キュー120が1つであるため、MTQ100を参照してリクエストを取得するワーカー(例えば、
図8にて後述されるリクエスト実行部821、又は、
図9にて後述されるリクエスト分割処理部920)は、通常のFIFO形式のキューと同じように、1つのキューを監視することによりリクエストを取得できる。
【0051】
この出力用キュー120へは、CPU201及びメモリによって構成されたリクエスト移行処理部140が、各テナントの入力用キュー110を順番に参照してリクエストを移行する。これにより、特定のテナントがサーバーのリソースを占有することを防ぎ、各テナントのリクエストが処理されるまでの待ち時間が、待ち行列理論で決定される最大待ち時間を超えないことを保証することができる。
【0052】
ここで、あるテナントの入力用キュー110における先頭のリクエストが処理されるまでの最大待ち時間を、当該リクエストがMTQ100から出力されるまでに出力されるリクエストの数と定義すると、最大待ち時間は、出力用キューサイズ+(入力用キュー数−1)で表すことができる。
【0053】
さらに、MTQ100では、入力用キュー110の本数をテナントごとに変化させることにより、単位時間あたりに出力されるリクエスト数をテナントごとに調整することができる。例えば、MTQ100において、テナントA、テナントB、テナントCの入力用キュー110の本数は、それぞれ、1本、1本、2本であるため、すべての入力用キュー110にリクエストが存在する場合、すなわち、各テナントが同時にサービスを利用している場合、各テナントのリクエストは1:1:2の割合で出力される。
【0054】
(動作原理:マルチテナント型サービスを提供するシステム)
次に、MTQ100を用いたマルチテナント型サービスを提供するシステムの実施形態について、
図8を用いて説明する。
図8は、MTQ100を組み込んだマルチテナント型アプリケーションサーバー800の構成を示す図であり、マルチテナント型アプリケーションサーバー800は、リクエスト受付部810と、MTQ100と、リクエスト実行部821、822、823とを備える。尚、リクエスト実行部821によって、本発明に係るリクエスト処理手段の一例が構成されている。また、
図8及び後述される
図9中のsocket(ソケット)とは、ホスト間の通信や1つのコンピュータ上のプロセス間の通信を可能とするインタフェースを意味する。
【0055】
CPU201及びメモリによって構成されたリクエスト受付部810は、アプリケーションを利用するクライアントのリクエストの受付処理を行い、MTQ100にリクエストの入力要求を行い、CPU201及びメモリによって構成されたリクエスト実行部821は、MTQ100からリクエストを取得し、リクエストに応じた処理を実行する。
【0056】
(リクエスト受付処理)
図10は、リクエスト受付部810における、リクエスト受付処理のフローチャートを示している。
リクエスト受付処理では、まず、ステップS1001で、CPU201及びメモリによって構成されたリクエスト受付部810は、リクエストの送信元に対応するテナントIDを取得し、ステップS1002で、MTQ100のリクエスト不待機入力処理によるリクエストの入力を試みる。
【0057】
次に、ステップS1003で、CPU201及びメモリで構成されたリクエスト受付部810は、ステップS1002におけるリクエスト不待機入力処理の成否を判定し、リクエスト不待機入力処理がエラーを返した場合(ステップS1003でNoの場合)は、ステップS1004を実行し、成功した場合(ステップS1003でYesの場合)はステップS1005を実行する。
【0058】
ステップS1004では、CPU201及びメモリで構成されたリクエスト受付部810は、サーバーが過負荷な状態であることを示すエラー情報をクライアントに返して、リクエスト受付処理を終了する。
ステップS1005では、CPU201及びメモリで構成されたリクエスト受付部810は、MTQ100に入力したリクエストが実行されるまで待機し、ステップS1006で、リクエストの実行結果をクライアントに送信する。
【0059】
(リクエスト実行処理)
図11は、CPU201及びメモリで構成されたリクエスト実行部821、822、823における、リクエスト実行処理のフローチャートである。
【0060】
リクエスト実行処理では、まず、ステップS1101で、CPU201及びメモリで構成されたリクエスト実行部821、822、823は、MTQ100のリクエスト待機出力処理を用いてリクエストを取得し、ステップS1102で、リクエストに応じた処理を実行する。
【0061】
次に、ステップS1103で、CPU201で構成されたリクエスト実行部821、822、823は、マルチテナント型アプリケーションサーバーの稼働状況を判定し、稼働中であれば、ステップS1101、ステップS1102の処理を繰り返し、稼働中でなければ、リクエスト実行処理を終了する。
【0062】
マルチテナント型アプリケーションサーバー800では、リクエスト受付部810が、MTQ100の不待機入力処理を使用するため、入力用キュー数に空きが存在しないテナント、すなわち、リクエストを大量に送信しているテナントのリクエストを制限することが可能である。
また、MTQ100は、FIFO形式の順序付きキューと併用して用いることで、複数台のサーバーが並列的に処理を分散して実行するような環境におけるサービス実行制御にも効率的に用いることが可能である。
【0063】
(基本構成:MTQを含む分散処理型のマルチテナント型アプリケーションシステム)
図9は、MTQ100を組み込んだ分散処理型のマルチテナント型アプリケーションシステムの構成を示す図で、マルチテナント型アプリケーションシステムは、リクエストの受付け、リクエストの分割を実行する分散処理振分けサーバー901と、分割されたリクエストを実行する分散処理実行サーバー902から成る。
【0064】
分散処理振分けサーバー901は、リクエスト受付部910と、MTQ100と、リクエスト分割処理部920と、FIFOキュー930と、分割リクエスト送信部940とを備え、分散処理実行サーバー902は、分割リクエスト実行部950を備える。尚、リクエスト分割処理部920によって、本発明に係るリクエスト分割処理手段の一例が構成されている。FIFOキュー930によって、本発明に係る分散処理用記憶手段の一例が構成されている。分割リクエスト送信部940によって、本発明に係る分割リクエスト送信手段の一例が構成されている。
【0065】
CPU201及びメモリで構成されたリクエスト受付部910は、先に説明したリクエスト受付部810と同様に、アプリケーションを利用するクライアントのリクエストの受付処理を行い、MTQ100にリクエストの入力要求を行う。
リクエスト分割処理部920は、MTQ100から取得したリクエストを分割してFIFOキュー930に格納する。FIFOキュー930は、FIFO形式の順序付きキューである。
【0066】
ここで分割を行うための条件としては、MTQ100を組み込むシステムの種類によるが、例えば、メールアーカイブを検索するシステムにおいて、日毎のインデックスを分割して異なるサーバーに保存している構成を備えていれば、分割を行う条件は、検索のリクエストに含まれる検索対象期間によって決定することができる(詳細は後述される「(メールアーカイブの具体例)」を参照)。
【0067】
また、送受信者のメールアドレスを用いてインデックスを生成することで、サーバーにメールを保存するような構成を備えていれば、分割を行う条件は、検索のリクエストに含まれる送受信者のメールアドレスによって決定することができる。
CPU201及びメモリで構成された分割リクエスト送信部940は、FIFOキュー930から取得した分割リクエストをCPU201及びメモリで構成された分散処理実行サーバー902に送信し、CPU201及びメモリで構成された分割リクエスト実行部950が処理したリクエストの実行結果を受け取る。
【0068】
(リクエスト分割処理)
次に、
図12及び上述した
図9を参照して、リクエスト分割処理について説明する。
図12は、リクエスト分割処理部920におけるリクエスト分割処理のフローチャートを示している。リクエスト分割処理では、まず、ステップS1201で、MTQ100のリクエスト待機出力処理によりリクエストを取得する。
【0069】
次に、ステップS1202で、リクエストを、当該リクエストの送信先である分散処理実行サーバー902ごとのリクエストに分割し、ステップS1203で、分割したリクエストをFIFOキュー930に格納する。以下、分割したリクエストの各要素を分割リクエストと呼ぶ。尚、分割リクエストには、リクエストの送信先である分散処理実行サーバー902の識別情報、および、分割処理対象となるデータの情報を含む。
【0070】
例えば、
図9において、CPU201及びメモリで構成されたリクエスト分割処理部920は、MTQ100から取得したリクエスト961を、分割リクエスト971、分割リクエスト972、分割リクエスト973に分割し、各分割リクエストをFIFOキュー930に格納する。
【0071】
(メールアーカイブの具体例)
前述の例を用いるならば、リクエスト961が検索対象期間を2012年10月22日〜2012年10月24日とするメールアーカイブを検索するリクエストである場合、2012年10月22日の分の検索処理を要求する分割リクエスト971、2012年10月23日の分の検索処理を要求する分割リクエスト972、2012年10月24日の分の検索処理を要求する分割リクエスト973に分割する。このとき、各分割リクエストの送信先となる分散処理実行サーバー902は、検索対象の検索インデックスを保管するサーバーとなる。
【0072】
次に、ステップS1204で、各分割リクエストの実行が完了するのを待機し、各実行結果をマージする。マージするための条件としては、MTQ100を組み込む種類によるが、例えば、メールアーカイブを検索するシステムにおいて、日毎のインデックスを分割して異なるサーバーに保存しているのであれば、各々検索した結果を、メールの受信時刻が降順(または、昇順)になるようにマージを行う(詳細については後述される「ステップS1204」を参照されたし)。
【0073】
次に、ステップS1205で、分散処理実行サーバー902の稼働状況を判定し、稼働中であれば、ステップS1201〜ステップS1204の処理を繰り返し、稼働中でなければ、リクエスト分割処理を終了する。
【0074】
(分割リクエスト送信処理)
次に、
図13と上述した
図9を参照して、分割リクエスト送信処理について説明する。
図13は、分割リクエスト送信部940における分割リクエスト送信処理のフローチャートである。分割リクエスト送信処理では、まずステップ1301で、CPU201及びメモリで構成された分割リクエスト送信部940は、FIFOキュー930から分割リクエストを取得する。
【0075】
次に、ステップ1302で、ステップ1301において取得した分割リクエストを、分散処理実行サーバー902へ送信し、実行結果を取得する。
次に、ステップS1303で、分散処理実行サーバー902の稼働状況を判定し、稼働中であれば、ステップS1301、ステップS1302の処理を繰り返し、稼働中でなければ、分割リクエスト送信処理を終了する。
CPU201及びメモリで構成された分割リクエスト送信部940が、FIFOキュー930から取得した分割リクエストを順次処理することにより、
図9の分散処理システムにおいて、同時期に実行される分割リクエストの上限は、分割リクエスト送信部940の数と等しくなる。
【0076】
これにより、テナントからのリクエストが大量に発生している状態においては、各分散処理実行サーバー902の負荷が上がり過ぎることを抑制でき、逆に、テナントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。
つまり、複数台の分散処理実行サーバー902に対して、並列的にリクエストを送信する場合、同時に送信可能な分割したリクエストの数は、分散処理振分けサーバー901の最大同時接続数(最大ソケット数)となる。
【0077】
FIFO形式の順序付きキューを用いない場合、リクエスト分割処理部920が分割したリクエストを送信することになるが、この場合、1つあたりのリクエスト分割処理部920に割り当てることが可能なソケット(socket)の数は、(最大ソケット数をリクエスト分割処理部920の数で除したもの)となる。
この場合、テナントからのリクエストが1つしかない場合においても、リクエスト分割処理部920に割り当てられたソケット数分の並列数しか得られないため、サーバーのリソースを最大限生かすことが難しい。
【0078】
一方、FIFO形式の順序付きキューを1つ設置し、分割リクエスト送信部940を別途設けた場合、リクエストが少ない状態(混雑してない状態)においてもサーバーのリソースを最大限生かすことが可能となる。
このように、MTQ100とFIFOキュー930を併用することにより、システム全体で処理する分割リクエストの数を制御しつつ、テナントごとのサービス実行制御を実施することが可能になる。
【0079】
図9の分散処理型のマルチテナント型アプリケーションシステムにおけるより具体的な応用例として、メールアーカイブを検索するシステムがある。
メールアーカイブ検索システムは、企業活動により生じたメールアーカイブから監査目的でメール情報を検索するためのシステムであり、日々増加する大量のメール情報から、実時間で検索結果を返すことが求められるため、メールアーカイブ検索システムの中には、日毎の検索インデックスを複数のサーバーに分割して保存し、並列的に検索処理を実行することで、検索時間の短縮を図るシステムがある。
【0080】
このようなシステムを、
図9の分散処理型のマルチテナント型アプリケーションシステム上で稼働させる場合、リクエスト分割処理部920が取得するリクエスト961は、メールの検索対象期間や検索キーワードを含む検索のリクエストである。
CPU201及びメモリで構成されたリクエスト分割処理部920は、ステップS1202では、リクエスト961を検索対象期間に対応する検索用のインデックスを保持する分散処理実行サーバー902ごとのリクエストに分割し、ステップS1204では、各分割リクエストの実行結果、すなわち、各分割リクエスト実行部950が出力した検索結果を、メールの受信時刻が降順、または、昇順となるようにマージする。
【0081】
以上説明したように、本実施形態によれば、マルチテナント型のサービスを提供するにあたり、テナント毎にリクエストを行うことを実現することで、サーバーのリソースを効率的に利用することが可能になる。
以上、実施形態例を詳述したが、本発明は、例えば、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【0082】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な内容で構成されることは言うまでもない。
また、本発明は、システム或いは装置にプログラムを供給することにとって達成される場合にも適用できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システム或いは装置に読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。
【0083】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバー、データーベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。
【0084】
以上、添付図面を参照しながら、本発明に係る情報処理装置、情報処理システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。