JP6676098B2 - 情報処理システム、情報処理装置、制御方法、及びプログラム - Google Patents

Description

本発明は、マルチテナント型のサービスを提供する技術に関し、各テナントに対してのサービスを保証するための技術に関する。

クラウド−コンピューティングの発達により、様々なサービスがクラウド環境を用いて提供されている。これらのサービスは、各種サーバーのリソースを最大限に活用するため、マルチテナント型のサービスとして提供されることが多い。ここに、テナントとは、クラウドを利用する事業者又はユーザーを意味する。

マルチテナント型のサービスは、シングルテナント型のサービスと比較して、一般に、サービス導入コストの削減や、余分なハードウェアの削減が可能になるなど、様々なメリットが存在する反面、複数のユーザーで負荷のピークが重なった場合などに、他のテナントの処理性能に影響を及ぼすというデメリットもあるため、クライアントからのリクエストを何らかの形で制御することが求められる。
ここに、リクエストとは、クライアントＰＣからクラウド内の各種サーバーへの要求指示や要求コマンドを意味する。具体的には、Ｗｅｂサーバーを用いたクラウドサービスの基本的な仕組みは以下のとおりである。まず、クライアントがＷｅｂサーバーに対して、取得したいコンテンツを識別するＵＲＬ(Uniform Resource Locator)を付与したリクエストを送信する。Ｗｅｂサーバーがリクエストを受け取ると、リクエスト中のＵＲＬに対応するコンテンツをレスポンスとしてクライアントに送り返す。クラウドサービスは、このリクエストとレスポンスとの繰り返しによって提供される。

クライアントからのリクエストを制御し、各種サーバーのリソースを効率的に使用する方法としては様々な方法が提案されている。
特許文献１に記載された手法は、サービスを提供するエンドサーバーの同時接続セッション数と同一の数だけ仮想キューを設け、ユーザーからのリクエストをキュー長が最小のキューに振り分けることで、ユーザー端末の待機時間の短縮を図る手法である。

特許文献２に記載された手法は、１つ以上のクライアントと２つ以上のサーバーとの間に設置する負荷分散装置に関する手法で、サーバー毎に計測した応答待ちリクエスト数に応じてリクエストを振り分けることで、特定のサーバーに対して過剰な負荷をかけず、サーバー台数に見合う性能向上を図る手法である。

特許文献３に記載された手法は、親部分とサフィックス部分とから成るキューIDを含むメッセージをリクエストとして取扱うことで、複数のキュー間でリクエストを論理的に移動させることを可能にし、ローカルメッセージ処理の効率化を図る手法である。

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

前述の各手法は、サーバーリソースを如何に有効活用するかという観点からリクエストの制御を行う手法であり、マルチテナント特有の複数のテナントにて負荷のピークが重なった場合などに、他のテナントの処理性能に影響を及ぼすデメリットを解決する手法ではない。
よって、サーバーリソースの限界を上回る数のリクエストがクライアントから送信される状態が発生した場合、サービスを使用していなかったテナントにおいても、すでにサーバー側で受け付けられたリクエストが処理されるまで、サービスを利用できない状況が発生する。

本発明は、クライアントからのリクエストを効率的に処理することを目的とする。

前述した目的を達成するための第１の発明は、複数のリクエストを受付けて処理を実行する情報処理装置であって、前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段と、それぞれの分割処理部で分割されたリクエストを記憶する記憶手段と、前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段と、を備えたことを特徴とする情報処理装置である。

本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。
例えば、クライアントから１つのリクエストに関しての情報を入力するだけで、リクエストの送信先となるそれぞれのサーバで実行される処理に応じて当該リクエストを分割して処理を行うため、入力の簡略化とリクエストの並列処理による高速処理化等を図ることが可能となるので、クライアントからのリクエストを効率的に処理することができる。
また、クライアントからのリクエストが大量に発生している状態においては、送信先となるそれぞれのサーバの負荷が上がり過ぎることを抑制でき、逆に、クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。

第１の発明に係る前記分割処理は、前記リクエストの送信先で実行される処理に応じてリクエストを生成する処理を行うことを特徴とする。
これにより、送信先で実行される処理に応じて分割されたリクエストごとに処理を行うことができる。

第１の発明に係る情報処理装置は、それぞれの送信先で前記リクエストを実行した結果を合わせて前記リクエストの受付元へ送信する送信手段を更に備えることを特徴とする。
これにより、それぞれの送信先でリクエストを実行した結果を合わせてリクエストの受付元へ送信することができる。

第１の発明に係る前記送信先は、メールの受信日に基づいて当該メールを保存し、前記分割処理制御手段は、前記送信先で保存されるメールの受信日に基づいてメールを検索する検索対象期間を含むリクエストの分割処理の制御を行うことを特徴とする。
これにより、各送信先が保存しているメールの受信日（受信期間）に応じて、検索対象期間を含むリクエストの分割処理を行うことができる。

第１の発明に係る前記送信先は、前記送信先は、メールの送受信者のメールアドレスに基づいて当該メールを保存し、前記分割処理制御手段は、前記送信先で保存されるメールの送受信者のメールアドレスに基づいて送受信者のメールアドレスを用いた検索に係るリクエストの分割処理の制御を行うことを特徴とする。
これにより、各送信先が保存しているメールのメールアドレスに応じて、メールアドレスを用いた検索を含むリクエストの分割処理を行うことができる。

第１の発明に係る前記分割処理手段によって分割されたリクエストを順次記憶する記憶手段を更に備え、前記分割リクエスト処理手段は、前記記憶手段に記憶されたリクエストを記憶された順に処理を行うことを特徴とする。
これにより、リクエストが少ない状態（混雑してない状態）においても送信先のリソースを最大限生かすことが可能となる。

第１の発明に係る前記記憶手段は、１つのキューであることを特徴とする。
これにより、記憶手段に入れられた順番に分割されたリクエストを処理することができる。

第１の発明に係る前記分割リクエスト処理手段は、前記リクエストを処理させる送信先の機器に応じて当該リクエストに対して分割処理を行うことを特徴とする。
これにより、リクエストを処理させる送信先の機器に応じたリクエストの分割処理を行うことができる。

前述した目的を達成するための第２の発明は、複数のリクエストを受付けて処理を実行する情報処理システムであって、前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段と、それぞれの分割処理部で分割されたリクエストを記憶する記憶手段と、前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段と、を備えたことを特徴とする情報処理システムである。
本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。例えば、クライアントから１つのリクエストに関しての情報を入力するだけで、リクエストの送信先となるそれぞれのサーバで実行される処理に応じて当該リクエストを分割して処理を行うため、入力の簡略化とリクエストの並列処理による高速処理化等を図ることが可能となるので、クライアントからのリクエストを効率的に処理することができる。また、クライアントからのリクエストが大量に発生している状態においては、送信先となるそれぞれのサーバの負荷が上がり過ぎることを抑制でき、逆に、クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。

前述した目的を達成するための第３の発明は、複数のリクエストを受付けて処理を実行する情報処理装置における情報処理方法であって、前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御ステップと、それぞれの分割処理部で分割されたリクエストを記憶する記憶ステップと、前記記憶ステップに記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理ステップと、を含むことを特徴とする情報処理方法である。
本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。例えば、クライアントから１つのリクエストに関しての情報を入力するだけで、リクエストの送信先となるそれぞれのサーバで実行される処理に応じて当該リクエストを分割して処理を行うため、入力の簡略化とリクエストの並列処理による高速処理化等を図ることが可能となるので、クライアントからのリクエストを効率的に処理することができる。また、クライアントからのリクエストが大量に発生している状態においては、送信先となるそれぞれのサーバの負荷が上がり過ぎることを抑制でき、逆に、クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。

前述した目的を達成するための第４の発明は、コンピュータを、複数のリクエストを受付けて処理を実行する情報処理装置として機能させるためのプログラムであって、前記コンピュータを、前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段、それぞれの分割処理部で分割されたリクエストを記憶する記憶手段、前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段、として機能させるためのプログラムである。
本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。例えば、クライアントから１つのリクエストに関しての情報を入力するだけで、リクエストの送信先となるそれぞれのサーバで実行される処理に応じて当該リクエストを分割して処理を行うため、入力の簡略化とリクエストの並列処理による高速処理化等を図ることが可能となるので、クライアントからのリクエストを効率的に処理することができる。また、クライアントからのリクエストが大量に発生している状態においては、送信先となるそれぞれのサーバの負荷が上がり過ぎることを抑制でき、逆に、クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。

前述した目的を達成するための第５の発明は、複数のリクエストを受付けて処理を実行する情報処理システムにおける情報処理方法であって、前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御ステップと、それぞれの分割処理部で分割されたリクエストを記憶する記憶ステップと、前記記憶ステップに記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理ステップと、を含むことを特徴とする情報処理方法である。
本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。例えば、クライアントから１つのリクエストに関しての情報を入力するだけで、リクエストの送信先となるそれぞれのサーバで実行される処理に応じて当該リクエストを分割して処理を行うため、入力の簡略化とリクエストの並列処理による高速処理化等を図ることが可能となるので、クライアントからのリクエストを効率的に処理することができる。また、クライアントからのリクエストが大量に発生している状態においては、送信先となるそれぞれのサーバの負荷が上がり過ぎることを抑制でき、逆に、クライアントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。

本発明によれば、クライアントからのリクエストを効率的に処理することが可能になる。

本発明の実施形態におけるマルチテナント型サービス実行制御装置の構成を示す図 本発明の実施形態における各種端末のハードウェア構成を示す図 本発明の実施形態におけるリクエスト待機入力処理のフローチャート 本発明の実施形態におけるリクエスト不待機入力処理のフローチャート 本発明の実施形態におけるリクエスト待機出力処理のフローチャート 本発明の実施形態におけるリクエスト不待機出力処理のフローチャート 本発明の実施形態におけるリクエスト移行処理のフローチャート 本発明の実施形態を利用したマルチテナント型アプリケーションサーバーの構成を示す図 本発明の実施形態を利用したマルチテナント型分散処理システムの構成を示す図 本発明の実施形態におけるリクエスト受付処理のフローチャート 本発明の実施形態におけるリクエスト実行処理のフローチャート 本発明の実施形態におけるリクエスト分割処理のフローチャート 本発明の実施形態における分割リクエスト送信処理のフローチャート

以下、図面を参照して、本発明の実施形態を詳細に説明する。なお、説明の簡略化のため、以下、マルチテナント型サービス実行制御装置をＭＴＱ（Multi Tenant Queue：マルチテナントキュー）と表記する。

（基本構成：マルチテナント型サービス実行制御装置）
図１は、本発明の実施形態におけるＭＴＱの構成を示す図である。ＭＴＱ１００は、複数の入力用キュー１１０と、１つの出力用キュー１２０と、リクエスト入力処理部１３０と、リクエスト移行処理部１４０と、リクエスト出力処理部１５０とを備える。尚、入力用キュー１１０によって、本発明に係る入力用記憶手段の一例が構成されている。また、出力用キュー１２０によって、本発明に係る出力用記憶手段の一例が構成されている。また、リクエスト入力処理部１３０によって、本発明に係るリクエスト入力処理手段の一例が構成されている。また、リクエスト移行処理部１４０によって、リクエスト移行処理手段の一例が構成されている。

入力用キュー１１０は、テナントごとのリクエストを受け付けるキューで、テナントごとに対応するキューが１つ以上存在する。尚、テナントによって、本発明に係る送信元の一例が構成されている。図１において、ＭＴＱ１００は、テナントＡに対応する入力用キュー１１１、テナントＢに対応する入力用キュー１１２、および、テナントＣに対応する入力用キュー１１３、１１４を備える。
出力用キュー１２０は、リクエストの処理順序をＦＩＦＯ形式で管理するキューで、各テナントで共有して用いる。

ＣＰＵ２０１及びメモリで構成されたリクエスト移行処理部１４０は、入力用キュー１１０からリクエストを取得し、出力用キュー１２０へ順次移行する。
ＣＰＵ２０１及びメモリで構成されたリクエスト入力処理部１３０における入力用キュー１１０へのリクエスト入力処理、リクエスト出力処理部１５０における出力用キュー１２０からのリクエスト出力処理、および、リクエスト移行処理部１４０におけるリクエスト移行処理については、それぞれ詳しく「（リクエスト入力処理）」「（リクエスト出力処理）」「（リクエスト移行処理）」にて後述される。

（ハードウェア構成：マルチテナント型サービス実行制御装置）
次に、図１のＭＴＱ１００のハードウェア構成について、図２を用いて説明する。
図中、ＣＰＵ２０１は、システムバス２０４に接続される後述の各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Basic Input / Output System）やオペレーティングシステムプログラム（以下、ＯＳ）や、ＭＴＱ１００に後述する各種の処理を実行させるために必要な各種プログラムやデータ等が記憶されている。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。尚、以下、ＲＡＭ２０２及びＲＯＭ２０３を単にメモリと称す。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０２にロードして、プログラムを実行することで後述する各種処理を実現するものである。また、入力コントローラ（入力Ｃ）２０５は、キーボードやポインティングデバイス等で構成される入力装置２０９からの入力を制御する。ビデオコントローラ（ＶＣ）２０６は、ディスプレイ装置２１０等の表示装置への表示を制御する。ディスプレイ装置２１０は、例えばＣＲＴディスプレイや液晶ディスプレイ等で構成される。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。以上が、マルチテナント型サービス実行制御装置１００のハードウェア構成の説明であるが、後述する各種の処理を実行可能であれば、必ずしも図２に記載のハードウェア構成を有していなくとも構わないことは言うまでもない。

（リクエスト入力処理）
次に、リクエスト入力処理部１３０におけるリクエスト入力処理について、図１、図３、図４を用いて詳しく説明する。
このリクエスト入力処理は、リクエスト入力処理部１３０が、入力用キュー１１０に空きが発生するまで入力処理を待機するリクエスト待機入力処理と、入力用キュー１１０に空きが存在しない場合はエラーを発生させるリクエスト不待機入力処理とを実行する、２つの処理を示している。

図３は、リクエスト待機入力処理のフローチャートを示しており、図４は、リクエスト不待機入力処理のフローチャートを示している。なお、ＭＴＱ１００を用いた各入力処理に用いるリクエストは、テナントを一意に識別するＩＤ（テナントＩＤ）に関する情報を含む。
リクエスト待機入力処理では、まず、ステップＳ３０１において、ＭＴＱ１００のＣＰＵ２０１は、入力として与えたテナントＩＤに該当する入力用キューを取得する。例えば、リクエスト１６１に含まれるテナントＩＤがテナントＡを表す識別子である場合、リクエスト入力処理部１３０は、テナントＡ入力用キュー１１１を取得する。

次に、ステップＳ３０２において、ＭＴＱ１００のＣＰＵ２０１は、Ｓ３０１で取得した入力用キュー１１０に空きができるまで待機し、ステップＳ３０３でリクエストを当該キューに格納し、Ｓ３０４で入力用キュー１１０への入力が完了したことを示す実行結果をリクエスト入力要求元（即ち、クライアントたるテナント）へ返す。
リクエスト不待機入力処理では、Ｓ４０１で、Ｓ３０１と同様に、ＭＴＱ１００のＣＰＵ２０１は、入力として与えたテナントＩＤに該当する入力用キュー１１０を取得する。

次に、ステップＳ４０２で、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ４０１で取得した入力用キュー１１０の状態を確認する。ここで、入力用キュー１１０に空きが存在する場合（ステップＳ４０１でＹｅｓ）、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ４０３でリクエストを当該キューに格納し、ステップＳ４０４で入力用キュー１１０への入力が完了したことを示す実行結果をクライアントたるテナントへ返す。

他方で、ステップＳ４０２で、入力用キュー１１０に空きが存在しない場合（ステップＳ４０１でＮｏ）、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ４０５で、入力用キュー１１０への入力が失敗したことを示す実行結果をリクエスト入力要求元（即ち、クライアントたるテナント）へ返す。特に、このステップＳ４０２において、ＣＰＵ２０１及びメモリで構成されたリクエスト入力処理部１３０が、入力用キュー１１０に対して、リクエストを記憶する際に、リクエスト自体の容量が、リクエストの送信元たるテナントに応じた記憶容量を超えたか否かを判定してよい。そして、リクエスト自体の容量が、リクエストの送信元たるテナントに応じた記憶容量を超えた場合、ＭＴＱ１００のＣＰＵ２０１は、リクエストの送信元たるテナントへ受付け不可の通知を行ってもよい。

（リクエスト出力処理）
次に、リクエスト出力処理部１５０におけるリクエスト出力処理について、図１、図５、図６を用いて詳しく説明する。
このリクエスト出力処理は、リクエスト出力処理部１５０は、出力用キュー１２０にリクエストが入力されるまで待機するリクエスト待機出力処理と、出力用キュー１２０にリクエストが存在しない場合はエラーを発生させるリクエスト不待機出力処理とを実行する、２つの処理を示している。

図５は、リクエスト待機出力処理のフローチャートを示しており、図６は、リクエスト不待機出力処理のフローチャートを示している。
リクエスト待機出力処理では、まず、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ５０１において、出力用キュー１２０にリクエストが入力されるまで待機する。次に、ステップＳ５０２で、ＭＴＱ１００のＣＰＵ２０１は、出力用キュー１２０からリクエストを１つ取得し、ステップＳ５０３で当該リクエスト１６３をリクエスト出力要求元へ返す。

リクエスト不待機出力処理では、まず、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ６０１において、出力用キュー１２０が空であるか確認する。空でなく、リクエストが存在する場合（ステップＳ６０１でＮｏの場合）、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ６０２で出力用キュー１２０からリクエストを１つ取得し、ステップＳ６０３で当該リクエストをリクエスト出力要求元へ返す。
ステップＳ６０１で、出力用キュー１２０が空である場合（ステップＳ６０１でＹｅｓの場合）、ＭＴＱ１００のＣＰＵ２０１は、ステップＳ６０４で、リクエストが存在しないことを示す実行結果をリクエスト出力要求元へ返す。

（リクエスト移行処理）
次に、リクエスト移行処理部１４０におけるリクエスト移行処理について、図１、図７を用いて詳しく説明する。
リクエスト入力処理部１３０、および、リクエスト出力処理部１５０が、外部からの要求を受けて各処理を実行するのに対し、リクエスト移行処理部１４０は、ＭＴＱ１００が停止するまで、自立的にリクエスト移行処理を繰り返す。

ＣＰＵ２０１、RAM及びROM等のメモリによって構成されたリクエスト移行処理部１４０は、ステップＳ７０１からステップＳ７０４において、各入力用キュー１１１乃至１１４を順次参照して、リクエストを出力用キュー１２０へ移行する。
ＣＰＵ２０１及びメモリによって構成されたリクエスト移行処理部１４０は、ステップＳ７０２では、参照中の入力用キュー１１０にリクエストが存在する場合は、ステップＳ７０３で出力用キュー１２０に空きができるまで待機し、ステップＳ７０４で当該入力用キュー１１０からリクエストを１つ取得して出力用キュー１２０へ移行する。特に、リクエスト移行処理部１４０は、入力用キュー１１０からリクエストを出力用キュー１２０へ移行する際に、入力用キュー１１１乃至１１４のうち毎回異なるいずれか一つからのリクエストを順次取得してよい。

次に、ステップＳ７０５で、ＣＰＵ２０１及びメモリによって構成されたリクエスト移行処理部１４０は、ステップＳ７０１〜ステップＳ７０４においてリクエストを移行したか否かを判定し、リクエストを１つも移行していないと判定した場合、すなわち、入力用キュー１１０にリクエストが存在しなかった場合は、ステップＳ７０６でいずれかの入力用キュー１１０にリクエストが格納されるまで待機する。
その後、ステップＳ７０７において、ＣＰＵ２０１及びメモリによって構成されたリクエスト移行処理部１４０は、ＭＴＱ１００が稼働中であるか否かを確認し、稼働中である間、ステップＳ７０１からステップＳ７０６の処理を繰り返す。

以上で説明したＭＴＱ１００は、テナントごとに占用の入力用キュー１１０が１つ以上存在するため、あるテナントのリクエストを、対応する入力用キュー１１０のサイズ分だけ同時に受け付けられることを保証できる。
また、出力用キュー１２０が１つであるため、ＭＴＱ１００を参照してリクエストを取得するワーカー（例えば、図８にて後述されるリクエスト実行部８２１、又は、図９にて後述されるリクエスト分割処理部９２０）は、通常のＦＩＦＯ形式のキューと同じように、１つのキューを監視することによりリクエストを取得できる。

この出力用キュー１２０へは、ＣＰＵ２０１及びメモリによって構成されたリクエスト移行処理部１４０が、各テナントの入力用キュー１１０を順番に参照してリクエストを移行する。これにより、特定のテナントがサーバーのリソースを占有することを防ぎ、各テナントのリクエストが処理されるまでの待ち時間が、待ち行列理論で決定される最大待ち時間を超えないことを保証することができる。

ここで、あるテナントの入力用キュー１１０における先頭のリクエストが処理されるまでの最大待ち時間を、当該リクエストがＭＴＱ１００から出力されるまでに出力されるリクエストの数と定義すると、最大待ち時間は、出力用キューサイズ＋（入力用キュー数−１）で表すことができる。

さらに、ＭＴＱ１００では、入力用キュー１１０の本数をテナントごとに変化させることにより、単位時間あたりに出力されるリクエスト数をテナントごとに調整することができる。例えば、ＭＴＱ１００において、テナントＡ、テナントＢ、テナントＣの入力用キュー１１０の本数は、それぞれ、１本、１本、２本であるため、すべての入力用キュー１１０にリクエストが存在する場合、すなわち、各テナントが同時にサービスを利用している場合、各テナントのリクエストは１：１：２の割合で出力される。

（動作原理：マルチテナント型サービスを提供するシステム）
次に、ＭＴＱ１００を用いたマルチテナント型サービスを提供するシステムの実施形態について、図８を用いて説明する。
図８は、ＭＴＱ１００を組み込んだマルチテナント型アプリケーションサーバー８００の構成を示す図であり、マルチテナント型アプリケーションサーバー８００は、リクエスト受付部８１０と、ＭＴＱ１００と、リクエスト実行部８２１、８２２、８２３とを備える。尚、リクエスト実行部８２１によって、本発明に係るリクエスト処理手段の一例が構成されている。また、図８及び後述される図９中のsocket（ソケット）とは、ホスト間の通信や1つのコンピュータ上のプロセス間の通信を可能とするインタフェースを意味する。

ＣＰＵ２０１及びメモリによって構成されたリクエスト受付部８１０は、アプリケーションを利用するクライアントのリクエストの受付処理を行い、ＭＴＱ１００にリクエストの入力要求を行い、ＣＰＵ２０１及びメモリによって構成されたリクエスト実行部８２１は、ＭＴＱ１００からリクエストを取得し、リクエストに応じた処理を実行する。

（リクエスト受付処理）
図１０は、リクエスト受付部８１０における、リクエスト受付処理のフローチャートを示している。
リクエスト受付処理では、まず、ステップＳ１００１で、ＣＰＵ２０１及びメモリによって構成されたリクエスト受付部８１０は、リクエストの送信元に対応するテナントＩＤを取得し、ステップＳ１００２で、ＭＴＱ１００のリクエスト不待機入力処理によるリクエストの入力を試みる。

次に、ステップＳ１００３で、ＣＰＵ２０１及びメモリで構成されたリクエスト受付部８１０は、ステップＳ１００２におけるリクエスト不待機入力処理の成否を判定し、リクエスト不待機入力処理がエラーを返した場合（ステップＳ１００３でＮｏの場合）は、ステップＳ１００４を実行し、成功した場合（ステップＳ１００３でＹｅｓの場合）はステップＳ１００５を実行する。

ステップＳ１００４では、ＣＰＵ２０１及びメモリで構成されたリクエスト受付部８１０は、サーバーが過負荷な状態であることを示すエラー情報をクライアントに返して、リクエスト受付処理を終了する。
ステップＳ１００５では、ＣＰＵ２０１及びメモリで構成されたリクエスト受付部８１０は、ＭＴＱ１００に入力したリクエストが実行されるまで待機し、ステップＳ１００６で、リクエストの実行結果をクライアントに送信する。

（リクエスト実行処理）
図１１は、ＣＰＵ２０１及びメモリで構成されたリクエスト実行部８２１、８２２、８２３における、リクエスト実行処理のフローチャートである。

リクエスト実行処理では、まず、ステップＳ１１０１で、ＣＰＵ２０１及びメモリで構成されたリクエスト実行部８２１、８２２、８２３は、ＭＴＱ１００のリクエスト待機出力処理を用いてリクエストを取得し、ステップＳ１１０２で、リクエストに応じた処理を実行する。

次に、ステップＳ１１０３で、ＣＰＵ２０１で構成されたリクエスト実行部８２１、８２２、８２３は、マルチテナント型アプリケーションサーバーの稼働状況を判定し、稼働中であれば、ステップＳ１１０１、ステップＳ１１０２の処理を繰り返し、稼働中でなければ、リクエスト実行処理を終了する。

マルチテナント型アプリケーションサーバー８００では、リクエスト受付部８１０が、ＭＴＱ１００の不待機入力処理を使用するため、入力用キュー数に空きが存在しないテナント、すなわち、リクエストを大量に送信しているテナントのリクエストを制限することが可能である。
また、ＭＴＱ１００は、ＦＩＦＯ形式の順序付きキューと併用して用いることで、複数台のサーバーが並列的に処理を分散して実行するような環境におけるサービス実行制御にも効率的に用いることが可能である。

（基本構成：ＭＴＱを含む分散処理型のマルチテナント型アプリケーションシステム）
図９は、ＭＴＱ１００を組み込んだ分散処理型のマルチテナント型アプリケーションシステムの構成を示す図で、マルチテナント型アプリケーションシステムは、リクエストの受付け、リクエストの分割を実行する分散処理振分けサーバー９０１と、分割されたリクエストを実行する分散処理実行サーバー９０２から成る。

分散処理振分けサーバー９０１は、リクエスト受付部９１０と、ＭＴＱ１００と、リクエスト分割処理部９２０と、ＦＩＦＯキュー９３０と、分割リクエスト送信部９４０とを備え、分散処理実行サーバー９０２は、分割リクエスト実行部９５０を備える。尚、リクエスト分割処理部９２０によって、本発明に係るリクエスト分割処理手段の一例が構成されている。ＦＩＦＯキュー９３０によって、本発明に係る分散処理用記憶手段の一例が構成されている。分割リクエスト送信部９４０によって、本発明に係る分割リクエスト送信手段の一例が構成されている。

ＣＰＵ２０１及びメモリで構成されたリクエスト受付部９１０は、先に説明したリクエスト受付部８１０と同様に、アプリケーションを利用するクライアントのリクエストの受付処理を行い、ＭＴＱ１００にリクエストの入力要求を行う。
リクエスト分割処理部９２０は、ＭＴＱ１００から取得したリクエストを分割してＦＩＦＯキュー９３０に格納する。ＦＩＦＯキュー９３０は、ＦＩＦＯ形式の順序付きキューである。

ここで分割を行うための条件としては、ＭＴＱ１００を組み込むシステムの種類によるが、例えば、メールアーカイブを検索するシステムにおいて、日毎のインデックスを分割して異なるサーバーに保存している構成を備えていれば、分割を行う条件は、検索のリクエストに含まれる検索対象期間によって決定することができる（詳細は後述される「（メールアーカイブの具体例）」を参照）。

また、送受信者のメールアドレスを用いてインデックスを生成することで、サーバーにメールを保存するような構成を備えていれば、分割を行う条件は、検索のリクエストに含まれる送受信者のメールアドレスによって決定することができる。
ＣＰＵ２０１及びメモリで構成された分割リクエスト送信部９４０は、ＦＩＦＯキュー９３０から取得した分割リクエストをＣＰＵ２０１及びメモリで構成された分散処理実行サーバー９０２に送信し、ＣＰＵ２０１及びメモリで構成された分割リクエスト実行部９５０が処理したリクエストの実行結果を受け取る。

（リクエスト分割処理）
次に、図１２及び上述した図９を参照して、リクエスト分割処理について説明する。
図１２は、リクエスト分割処理部９２０におけるリクエスト分割処理のフローチャートを示している。リクエスト分割処理では、まず、ステップＳ１２０１で、ＭＴＱ１００のリクエスト待機出力処理によりリクエストを取得する。

次に、ステップＳ１２０２で、リクエストを、当該リクエストの送信先である分散処理実行サーバー９０２ごとのリクエストに分割し、ステップＳ１２０３で、分割したリクエストをＦＩＦＯキュー９３０に格納する。以下、分割したリクエストの各要素を分割リクエストと呼ぶ。尚、分割リクエストには、リクエストの送信先である分散処理実行サーバー９０２の識別情報、および、分割処理対象となるデータの情報を含む。

例えば、図９において、ＣＰＵ２０１及びメモリで構成されたリクエスト分割処理部９２０は、ＭＴＱ１００から取得したリクエスト９６１を、分割リクエスト９７１、分割リクエスト９７２、分割リクエスト９７３に分割し、各分割リクエストをＦＩＦＯキュー９３０に格納する。

（メールアーカイブの具体例）
前述の例を用いるならば、リクエスト９６１が検索対象期間を２０１２年１０月２２日〜２０１２年１０月２４日とするメールアーカイブを検索するリクエストである場合、２０１２年１０月２２日の分の検索処理を要求する分割リクエスト９７１、２０１２年１０月２３日の分の検索処理を要求する分割リクエスト９７２、２０１２年１０月２４日の分の検索処理を要求する分割リクエスト９７３に分割する。このとき、各分割リクエストの送信先となる分散処理実行サーバー９０２は、検索対象の検索インデックスを保管するサーバーとなる。

次に、ステップＳ１２０４で、各分割リクエストの実行が完了するのを待機し、各実行結果をマージする。マージするための条件としては、ＭＴＱ１００を組み込む種類によるが、例えば、メールアーカイブを検索するシステムにおいて、日毎のインデックスを分割して異なるサーバーに保存しているのであれば、各々検索した結果を、メールの受信時刻が降順（または、昇順）になるようにマージを行う（詳細については後述される「ステップＳ１２０４」を参照されたし）。

次に、ステップＳ１２０５で、分散処理実行サーバー９０２の稼働状況を判定し、稼働中であれば、ステップＳ１２０１〜ステップＳ１２０４の処理を繰り返し、稼働中でなければ、リクエスト分割処理を終了する。

（分割リクエスト送信処理）
次に、図１３と上述した図９を参照して、分割リクエスト送信処理について説明する。
図１３は、分割リクエスト送信部９４０における分割リクエスト送信処理のフローチャートである。分割リクエスト送信処理では、まずステップ１３０１で、ＣＰＵ２０１及びメモリで構成された分割リクエスト送信部９４０は、ＦＩＦＯキュー９３０から分割リクエストを取得する。

次に、ステップ１３０２で、ステップ１３０１において取得した分割リクエストを、分散処理実行サーバー９０２へ送信し、実行結果を取得する。
次に、ステップＳ１３０３で、分散処理実行サーバー９０２の稼働状況を判定し、稼働中であれば、ステップＳ１３０１、ステップＳ１３０２の処理を繰り返し、稼働中でなければ、分割リクエスト送信処理を終了する。
ＣＰＵ２０１及びメモリで構成された分割リクエスト送信部９４０が、ＦＩＦＯキュー９３０から取得した分割リクエストを順次処理することにより、図９の分散処理システムにおいて、同時期に実行される分割リクエストの上限は、分割リクエスト送信部９４０の数と等しくなる。

これにより、テナントからのリクエストが大量に発生している状態においては、各分散処理実行サーバー９０２の負荷が上がり過ぎることを抑制でき、逆に、テナントからのリクエストが少ない場合においては、同時並列実行数を最大限に生かした処理が可能になる。
つまり、複数台の分散処理実行サーバー９０２に対して、並列的にリクエストを送信する場合、同時に送信可能な分割したリクエストの数は、分散処理振分けサーバー９０１の最大同時接続数（最大ソケット数）となる。

ＦＩＦＯ形式の順序付きキューを用いない場合、リクエスト分割処理部９２０が分割したリクエストを送信することになるが、この場合、１つあたりのリクエスト分割処理部９２０に割り当てることが可能なソケット（socket）の数は、（最大ソケット数をリクエスト分割処理部９２０の数で除したもの）となる。
この場合、テナントからのリクエストが１つしかない場合においても、リクエスト分割処理部９２０に割り当てられたソケット数分の並列数しか得られないため、サーバーのリソースを最大限生かすことが難しい。

一方、ＦＩＦＯ形式の順序付きキューを１つ設置し、分割リクエスト送信部９４０を別途設けた場合、リクエストが少ない状態（混雑してない状態）においてもサーバーのリソースを最大限生かすことが可能となる。
このように、ＭＴＱ１００とＦＩＦＯキュー９３０を併用することにより、システム全体で処理する分割リクエストの数を制御しつつ、テナントごとのサービス実行制御を実施することが可能になる。

図９の分散処理型のマルチテナント型アプリケーションシステムにおけるより具体的な応用例として、メールアーカイブを検索するシステムがある。
メールアーカイブ検索システムは、企業活動により生じたメールアーカイブから監査目的でメール情報を検索するためのシステムであり、日々増加する大量のメール情報から、実時間で検索結果を返すことが求められるため、メールアーカイブ検索システムの中には、日毎の検索インデックスを複数のサーバーに分割して保存し、並列的に検索処理を実行することで、検索時間の短縮を図るシステムがある。

このようなシステムを、図９の分散処理型のマルチテナント型アプリケーションシステム上で稼働させる場合、リクエスト分割処理部９２０が取得するリクエスト９６１は、メールの検索対象期間や検索キーワードを含む検索のリクエストである。
ＣＰＵ２０１及びメモリで構成されたリクエスト分割処理部９２０は、ステップＳ１２０２では、リクエスト９６１を検索対象期間に対応する検索用のインデックスを保持する分散処理実行サーバー９０２ごとのリクエストに分割し、ステップＳ１２０４では、各分割リクエストの実行結果、すなわち、各分割リクエスト実行部９５０が出力した検索結果を、メールの受信時刻が降順、または、昇順となるようにマージする。

以上説明したように、本実施形態によれば、マルチテナント型のサービスを提供するにあたり、テナント毎にリクエストを行うことを実現することで、サーバーのリソースを効率的に利用することが可能になる。
以上、実施形態例を詳述したが、本発明は、例えば、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な内容で構成されることは言うまでもない。
また、本発明は、システム或いは装置にプログラムを供給することにとって達成される場合にも適用できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システム或いは装置に読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバー、データーベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステム或いは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。

以上、添付図面を参照しながら、本発明に係る情報処理装置、情報処理システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

１００ マルチテナント型サービス実行制御装置（ＭＴＱ）
１１０ 入力用キュー
１１１ テナントＡ用入力キュー
１１２ テナントＢ用入力キュー
１１３ テナントＣ用入力キュー(1)
１１４ テナントＣ用入力キュー(2)
１２０ 出力用キュー
１３０ リクエスト入力処理部
１４０ リクエスト移行処理部
１５０ リクエスト出力処理部
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆ（インターフェース）コントローラ
２０９ 入力装置
２１０ ディスプレイ装置
２１１ 外部メモリ

Claims (11)

1. 複数のリクエストを受付けて処理を実行する情報処理装置であって、
   前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段と、
   それぞれの分割処理部で分割されたリクエストを記憶する記憶手段と、
   前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段と、
   を備えたことを特徴とする情報処理装置。
2. 前記分割処理は、前記リクエストの送信先で実行される処理に応じてリクエストを生成する処理を行うことを特徴とする請求項１に記載の情報処理装置。
3. それぞれの送信先で前記リクエストを実行した結果を合わせて前記リクエストの受付元へ送信する送信手段を備えたことを特徴とする請求項２に記載の情報処理装置。
4. 前記送信先は、メールの受信日に基づいて当該メールを保存し、
   前記分割処理制御手段は、前記送信先で保存されるメールの受信日に基づいてメールを検索する検索対象期間を含むリクエストの分割処理の制御を行うことを特徴とする請求項２または３に記載の情報処理装置。
5. 前記送信先は、メールの送受信者のメールアドレスに基づいて当該メールを保存し、
   前記分割処理制御手段は、前記送信先で保存されるメールの送受信者のメールアドレスに基づいて送受信者のメールアドレスを用いた検索に係るリクエストの分割処理の制御を行うことを特徴とする請求項２乃至４の何れか１項に記載の情報処理装置。
6. 前記記憶手段は、１つのキューであることを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
7. 前記分割リクエスト処理手段は、前記リクエストを処理させる送信先の機器に応じて当該リクエストに対して分割処理を行うことを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
8. 複数のリクエストを受付けて処理を実行する情報処理システムであって、
   前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段と、
   それぞれの分割処理部で分割されたリクエストを記憶する記憶手段と、
   前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段と、
   を備えたことを特徴とする情報処理システム。
9. 複数のリクエストを受付けて処理を実行する情報処理装置における情報処理方法であって、
   前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御ステップと、
   それぞれの分割処理部で分割されたリクエストを記憶する記憶ステップと、
   前記記憶ステップに記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理ステップと、
   を含むことを特徴とする情報処理方法。
10. コンピュータを、
    複数のリクエストを受付けて処理を実行する情報処理装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御手段、
    それぞれの分割処理部で分割されたリクエストを記憶する記憶手段、
    前記記憶手段に記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理手段、
    として機能させるためのプログラム。
11. 複数のリクエストを受付けて処理を実行する情報処理システムにおける情報処理方法であって、
    前記リクエストを分割するための分割条件に従って複数の分割処理部で前記複数のリクエストのいずれのリクエストを取得させて分割処理の制御を行う分割処理制御ステップと、
    それぞれの分割処理部で分割されたリクエストを記憶する記憶ステップと、
    前記記憶ステップに記憶された分割されたリクエストを記憶された順に複数の送信処理部で分割されたリクエストを取得させて送信先の機器への送信処理の制御を行う分割リクエスト処理ステップと、
    を含むことを特徴とする情報処理方法。

Images