(57)【要約】【課題】マルチテナント型システムにおいて、テナント毎のメモリ使用量を精度良く監視する。【解決手段】処理部１１２は、それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセス１５１とメインプロセス１５２とを実行する。サンプリング部１１１は、複数の属性の中の、監視候補である１以上の属性の内のいずれか１つをサブプロセス１５１に関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストをサブプロセス１５１に送信し、それ以外の属性を含む場合、当該リクエストをメインプロセス１５２に送信する。サブプロセス監視部１１３は、サブプロセス１５１におけるリクエストの処理に伴うメモリ使用量を、リクエストの属性毎に取得して出力する。【選択図】図１
2012113380.tif 000002
【特許請求の範囲】
【請求項１】
それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行する処理手段と、
前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信するサンプリング手段と、
前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力するサブプロセス監視手段と
を含むサービス提供装置。
【請求項２】
前記サンプリング手段は、前記入力されたリクエストの属性が前記監視候補の場合、前記サブプロセスが他のリクエストを処理していなければ、当該入力されたリクエストの属性を前記サブプロセスに関連づけ、当該リクエストを前記サブプロセスに送信する
請求項１に記載のサービス提供装置。
【請求項３】
さらに、前記監視候補の属性を含むリクエストを保持するサンプリングキューを含み、
前記サンプリング手段は、前記入力されたリクエストの属性が前記監視候補であり、前記サブプロセスに送信されない場合、当該リクエストを前記サンプリングキューに格納し、当該リクエストが前記サンプリングキューに格納されてから所定時間以内に、当該リクエストの属性が前記サブプロセスに関連づけられた、または、前記サブプロセスにおける他のリクエストの処理が行われていない状態となったときは、当該リクエストを前記サブプロセスに送信し、そうでないときは、当該リクエストを前記メインプロセスに送信する
請求項２に記載のサービス提供装置。
【請求項４】
前記サンプリング手段は、前記サブプロセス監視手段において確保されたメモリ量の属性毎の監視回数をもとに、前記入力されたリクエストに含まれる属性が前記監視候補の属性であるか否かを判定する
請求項１乃至３のいずれかに記載のサービス提供装置。
【請求項５】
さらに、前記メインプロセスにおいて確保されたメモリ量の概算値を、属性毎に取得するメインプロセス監視手段を含み、
前記サンプリング手段は、属性毎の前記メモリ量の概算値をもとに、前記入力されたリクエストに含まれる属性が前記監視候補の属性であるか否かを判定する
請求項１乃至３のいずれかに記載のサービス提供装置。
【請求項６】
さらに、前記サブプロセスにおけるリクエストの処理で、所定データの参照が要求された場合、前記メインプロセスの前記メモリ上に存在する当該データの取得を行い、前記サブプロセスに提供するプロセス固有情報媒介手段を含む
請求項１乃至５のいずれかに記載のサービス提供装置。
【請求項７】
前記処理手段は、複数の前記サブプロセスを実行し、
それぞれが前記複数の前記サブプロセスのそれぞれにおける前記メモリ量を取得する複数の前記サブプロセス監視手段を含み、
前記サンプリング手段は、前記複数の属性の中の、監視候補である１以上の属性のそれぞれを前記複数の前記サブプロセスのそれぞれに関連づけ、前記入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを当該属性が関連づけられた前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信する
請求項１に記載のサービス提供装置。
【請求項８】
それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行し、
前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信し、
前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力する
サービス提供方法。
【請求項９】
前記入力されたリクエストの属性が前記監視候補の場合、前記サブプロセスが他のリクエストを処理していなければ、当該入力されたリクエストの属性を前記サブプロセスに関連づけ、当該リクエストを前記サブプロセスに送信する
請求項８に記載のサービス提供方法。
【請求項１０】
コンピュータに、
それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行し、
前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信し、
前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力する
処理を実行させるサービス提供用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサービス提供装置、サービス提供方法、及び、プログラムに関し、特に、リクエストに対するメモリ使用量を監視するサービス提供装置、サービス提供方法、及び、プログラム。
【背景技術】
【０００２】
システムを構成するリソースが複数の利用者組織（以下、テナントとする）間で共有されるとき、このようなシステムは、一般にマルチテナント型システムと呼ばれる。マルチテナント型システムには様々な実現方式があるが、ここでは複数のテナントがコンピュータ上のプロセスを共有し、プロセス上で稼働する複数のスレッドが複数のテナントにサービスを提供するものとする。
【０００３】
図２３は、マルチテナント型システム上で稼働するスレッドとテナントとの対応関係の例を示す図である。マルチテナント型システムにおいては、プロセス上で稼働する各スレッドが各テナントに属する個々の利用者からのリクエストを処理する。図２３の例では、利用者１、２、３、…、Ｍによるリクエストは、それぞれ、サービス提供装置１００のプロセス上で動作するスレッド１、２、３、…、Ｍが処理する。ここで、利用者１はテナント１に、利用者２と利用者３はテナント２に、利用者ＭはテナントＮにそれぞれ属する。すなわち、テナント１によるリクエストはスレッド１が処理し、テナント２によるリクエストはスレッド２とスレッド３が処理し、テナントＮによるリクエストはスレッドＭが処理する。このような利用者とスレッドとの対応関係は１つの処理が終了する度に解消され、あるスレッドは、別のタイミングにおいては異なるテナントに属する利用者からのリクエストを処理する。
【０００４】
このように、マルチテナント型システムでは、複数のテナント間でリソースを共有することにより、システムのテナントあたりの運用コストが軽減できる。一方、利用者であるテナントにとっては、可能な限り、他のテナントとリソースが共有されない一般的なシステムと同様の条件で、マルチテナント型システムを利用できることが望ましい。このような条件として、例えば、あるテナントに対するサービスの提供やサービス品質が、他のテナントによる共有リソースの使用量に影響されないようにすること、すなわち性能隔離がある。性能隔離を実現するためには、例えば、共有リソースを大量に使用するテナントに対しては、専用のリソースプールを割り当てる、或いは、リソースの使用制限を設けるというように、テナント毎のリソース使用量に応じた対応が行われる。このような性能隔離を行うためには、各テナントのリソース使用量を把握することが必要となる。
【０００５】
非特許文献１には、マルチテナント型システムにおける、リソース監視機能やリソース監視結果に基づいた対応機能などからなる性能隔離の枠組みが記載されている。しかしながら、非特許文献１には、リソース監視の具体的な実現方法は開示されていない。
【０００６】
ここで、監視対象のリソースをメモリ使用量とした場合の、マルチテナント型システムのリソース監視の問題点を説明する。
【０００７】
図２４は、マルチテナント型システムのプロセスにおけるメモリ使用量の変化の例を示す図である。マルチテナント型システムでは、同一のプロセス上で、複数のスレッドの処理が同時並行で実行され（以下、これをマルチスレッドプロセスとする）、かつ、複数のスレッドのそれぞれが互いにプロセスのメモリ空間を共有する。そして、あるメモリ領域は、同時に複数のスレッドによって使用されることがある。このため、メモリ使用量をスレッド毎に監視することができず、テナント毎のメモリ使用量も監視することができない。
【０００８】
このようなマルチスレッドプロセスのメモリ使用量をスレッド毎に監視する方法が、例えば、特許文献１に開示されている。特許文献１記載のシステムは、プロセス全体のメモリ使用量と実行されていたスレッドとを監視し、プロセス全体のメモリ使用量を、同時に実行されていた各スレッドに所定の割合で案分することで、スレッド毎のメモリ使用量の概算値を算出する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００９−１１０２１３号公報
【非特許文献】
【００１０】
【非特許文献１】Xu Cheng, Yuliang Shi, Qingzhong Li, "A Multi-tenant Oriented Performance Monitoring, Detecting and Scheduling Architecture Based on SLA", 2009 Joint Conferences on Pervasive Computing (JCPC), pp.599-604, 2009.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、特許文献１に記載の方法では、プロセス全体のメモリ使用量を各スレッドに案分することによりスレッド毎のメモリ使用量の概算値を算出するため、メモリ使用量の監視精度が低いという課題があった。特に、同時に実行されるスレッド数が多いシステムに適用した場合、各スレッドのメモリ使用量の概算値は、他のスレッドのメモリ使用量の影響を大きく受けるため、その監視精度は大幅に低下する。
【００１２】
本発明の目的は、上述した課題を解決し、マルチテナント型システムにおいて、テナント毎のメモリ使用量を精度良く監視できるサービス提供装置、サービス提供方法、及び、プログラムを提供することにある。
【課題を解決するための手段】
【００１３】
本発明のサービス提供装置は、それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行する処理手段と、前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信するサンプリング手段と、前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力するサブプロセス監視手段とを含む。
【００１４】
本発明のサービス提供方法は、それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行し、前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信し、前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力する。
【００１５】
本発明のプログラムは、コンピュータに、それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセスとメインプロセスとを実行し、前記複数の属性の中の、監視候補である１以上の属性の内のいずれか１つを前記サブプロセスに関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストを前記サブプロセスに送信し、それ以外の属性を含む場合、当該リクエストを前記メインプロセスに送信し、前記サブプロセスが確保したメモリ量を、リクエストの属性毎に取得して出力する処理を実行させる。
【発明の効果】
【００１６】
本発明の効果は、マルチテナント型システムにおいて、テナント毎のメモリ使用量を精度良く監視できることである。
【図面の簡単な説明】
【００１７】
【図１】本発明の第一の実施の形態の特徴的な構成を示すブロック図である。
【図２】本発明の第一の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【図３】本発明の第一の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【図４】本発明の第一の実施の形態におけるサービス提供装置１００のレスポンス処理の動作を示すフローチャートである。
【図５】本発明の第一の実施の形態におけるサービス提供装置１００のサブプロセス監視処理の動作を示すフローチャートである。
【図６】本発明の第一の実施の形態におけるメモリ監視ログ１３１の例を示す図である。
【図７】本発明の第一の実施の形態におけるメモリ監視結果情報１３２の例を示す図である。
【図８】本発明の第一の実施の形態における監視回数情報１３３の例を示す図である。
【図９】本発明の第一の実施の形態における監視回数情報１３３の他の例を示す図である。
【図１０】本発明の第一の実施の形態における監視対象情報１３４の例を示す図である。
【図１１】本発明の第一の実施の形態におけるサービス提供装置１００のメモリ使用量の変化の例を示す図である。
【図１２】本発明の第二の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【図１３】本発明の第二の実施の形態におけるサービス提供装置１００のプロセス固有情報アクセス処理の動作を示すフローチャートである。
【図１４】本発明の第三の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【図１５】本発明の第三の実施の形態における概算メモリ監視結果情報１３５の例を示す図である。
【図１６】本発明の第四の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【図１７】本発明の第四の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【図１８】本発明の第四の実施の形態におけるサービス提供装置１００のサンプリングキュー処理の動作を示すフローチャートである。
【図１９】本発明の第五の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【図２０】本発明の第五の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【図２１】本発明の第五の実施の形態におけるサービス提供装置１００のレスポンス処理の動作を示すフローチャートである。
【図２２】本発明の第五の実施の形態における監視対象情報１４０の例を示す図である。
【図２３】マルチテナント型システム上で稼働するスレッドとテナントとの対応関係の例を示す図である。
【図２４】マルチテナント型システムのプロセスにおけるメモリ使用量の変化の例を示す図である。
【発明を実施するための形態】
【００１８】
（第一の実施の形態）
次に、本発明の第一の実施の形態について図面を参照して詳細に説明する。はじめに、本発明の第一の実施の形態の構成について説明する。
【００１９】
図２は、本発明の第一の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【００２０】
図２を参照すると、マルチテナントシステムは、サービス提供装置１００と複数の利用者端末２００とを含む。サービス提供装置１００と利用者端末２００とは、ネットワーク等により通信可能に接続される。
【００２１】
サービス提供装置１００は、サンプリング部１１１、処理部１１２、サブプロセス監視部１１３、メモリ監視ログ記憶部１２１、メモリ監視結果記憶部１２２、監視回数記憶部１２３、及び、監視対象記憶部１２４を含む。
【００２２】
ここで、サンプリング部１１１は、複数の利用者端末２００のそれぞれからリクエストを受信し、そのリクエストの属性が監視候補であるか（監視すべきか）どうかを判定し、監視候補であれば、その属性を監視対象として、そのリクエストを処理部１１２上のサブプロセス１５１へ送信し、監視候補でなければ、そのリクエストを処理部１１２上のメインプロセス１５２に送信する。
【００２３】
なお、本発明の実施の形態では、各リクエストは、そのリクエストの属性として、テナントを識別するテナントＩＤを含むものとし、サンプリング部１１１は、テナントＩＤをもとに各テナントが監視候補であるかどうかを判定するものとする。
【００２４】
また、各リクエストが、テナントＩＤの代わりに利用者を識別する利用者ＩＤを含み、サンプリング部１１１が図示しない対応テーブルによりそれぞれの利用者ＩＤが属するテナントのテナントＩＤを取得し、そのテナントＩＤをリクエストの属性としてもよい。
【００２５】
処理部１１２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であり、サブプロセス１５１とメインプロセス１５２との処理を実行する。
【００２６】
なお、本発明の実施の形態において、サブプロセス１５１の処理、メインプロセス１５２の処理、または、各スレッドの処理は、実際には、処理部１１２が実行するものであるが、以下の説明においては、プロセスが実行、または、各スレッドが実行するものとして記載する。
【００２７】
メインプロセス１５２は、サンプリング部１１１から受信した監視対象以外のリクエストを処理する。メインプロセス１５２上では、図２３に示したように、複数のスレッドが動作し、それぞれのスレッドが複数のリクエストのそれぞれを同時並行で処理する。
【００２８】
サブプロセス１５１は、サンプリング部１１１から受信した監視対象のリクエストを処理する。サブプロセス１５１上でも、メインプロセス１５２と同様に、複数のスレッドが動作し、それぞれのスレッドが、複数のリクエストのそれぞれを同時並行で処理する。
【００２９】
なお、メインプロセス１５２とサブプロセス１５１のそれぞれには、動作に必要な固有のメモリ空間が割り当てられており、各スレッドは、リクエストの処理に必要なメモリを確保し、そのリクエストを処理する。また、メインプロセス１５２上の各スレッドは、互いにプロセスに割り当てられたメモリ空間を共有しており、そのメモリ空間上のあるメモリ領域が、同時に複数のスレッドによって使用されることがあるものとする。同様に、サブプロセス１５１上の各スレッドも、互いにプロセスに割り当てられたメモリ空間を共有し、そのメモリ空間上のあるメモリ領域が同時に複数のスレッドによって使用されることがあるものとする。
【００３０】
サブプロセス監視部１１３は、サブプロセス１５１のメモリ使用量（サブプロセス１５１で確保されたメモリ量）を取得し、監視対象のテナントＩＤとともに、メモリ監視ログ記憶部１２１のメモリ監視ログ１３１に記録する。
【００３１】
メモリ監視ログ記憶部１２１は、メモリ監視ログ１３１を記憶する。図６は、本発明の第一の実施の形態におけるメモリ監視ログ１３１の例を示す図である。メモリ監視ログ１３１は、図６に示すように、サブプロセス１５１における、テナントＩＤ毎の受付リクエスト数、開始時メモリ使用量、及び終了時メモリ使用量を含むレコード１４１を記録する。
【００３２】
メモリ監視結果記憶部１２２は、メモリ監視結果情報１３２を記憶する。図７は、本発明の第一の実施の形態におけるメモリ監視結果情報１３２の例を示す図である。メモリ監視結果情報１３２は、図７に示すように、テナントＩＤに対するメモリ使用量を含む。
【００３３】
監視回数記憶部１２３は、監視回数情報１３３を記憶する。図８は、本発明の第一の実施の形態における監視回数情報１３３の例を示す図である。監視回数情報１３３は、テナントＩＤ毎の監視回数を含む。ここで、監視回数は、サブプロセス監視部１１３により、当該テナントＩＤ対するメモリ使用量の監視が行われた回数（メモリ監視ログ１３１に、当該テナントＩＤ対して生成されたレコード１４１の数）を示す。
【００３４】
監視対象記憶部１２４は、監視対象情報１３４を記憶する。図１０は、本発明の第一の実施の形態における監視対象情報１３４の例を示す図である。監視対象情報１３４は、サブプロセス１５１で処理中の（サブプロセス１５１に関連づけられた）監視対象のテナントＩＤを含む。
【００３５】
なお、本発明の実施の形態においては、スレッドはＪａｖａ（登録商標）スレッドとし、サブプロセス１５１とメインプロセス１５２とのそれぞれでＪａｖａＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）が動作し、それぞれのＪａｖａＶＭ上で、複数のスレッドが動作するものとする。また、スレッドによるメモリ使用量は、図２４に示すように、リクエストの処理とともに累積的に増加し、所定のタイミングでＪａｖａにより提供されるガベージ・コレクションにより解放されるものとする。
【００３６】
また、サービス提供装置１００は、プログラムを記憶した記憶媒体を含み、プログラムに基づく制御によって動作するコンピュータであってもよい。この場合、サンプリング部１１１及びサブプロセス監視部１１３も、処理部１１２上でプログラムに基づく制御によって動作してもよい。また、メモリ監視ログ記憶部１２１と、監視回数記憶部１２３と、監視対象記憶部１２４とは、それぞれ個別の記憶媒体でも、１つの記憶媒体によって構成されてもよい。
【００３７】
次に、本発明の第一の実施の形態におけるサービス提供装置１００の動作について説明する。
【００３８】
はじめに、本発明の第一の実施の形態におけるサービス提供装置１００のリクエスト処理について説明する。図３は、本発明の第一の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【００３９】
サンプリング部１１１は、利用者端末２００からリクエストを受信する（ステップＳ１０１）。
【００４０】
サンプリング部１１１は、リクエストのテナントＩＤが監視候補かどうかを判定する（ステップＳ１０２）。ここで、サンプリング部１１１は、監視回数記憶部１２３の監視回数情報１３３を参照し、監視回数が所定値以下のテナントＩＤを監視候補と判定する。
【００４１】
なお、テナントＩＤは、リクエストとともに送信されるＵＲＬに含まれていてもよい。この場合、例えば、ＵＲＬを「ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｔｅｎａｎｔ＿ｘｘｘ／」とし、このＵＲＬに含まれる「ｔｅｎａｎｔ＿ｘｘｘ」をテナントＩＤとする。
【００４２】
ステップＳ１０２において、リクエストのテナントＩＤが監視候補であると判定された場合（ステップＳ１０２／Ｙｅｓ）、サンプリング部１１１は、リクエストが監視可能かどうかを判定する（ステップＳ１０３）。
【００４３】
ここで、サンプリング部１１１は、リクエストが監視可能かどうかを判定する条件（以下、監視可能条件とする）を、「監視可能監視対象記憶部１２４の監視対象情報１３４にテナントＩＤが設定されていない（サブプロセス１５１で処理中の他のリクエストが無い）」、または、「監視対象情報１３４に設定されているテナントＩＤが、そのリクエストのテナントＩＤと同じ（サブプロセス１５１で処理中のリクエストのテナントＩＤが、受信したリクエストのテナントＩＤと同じ）である」こととし、監視可能条件を満たす場合、そのリクエストを監視可能と判定する。
【００４４】
なお、同じテナントＩＤに対して、同時に複数のリクエストが発生しない場合は、監視可能条件を、「監視可能監視対象記憶部１２４の監視対象情報１３４にテナントＩＤが設定されていない」こととしてもよい。
【００４５】
ステップＳ１０３において、リクエストが監視可能であると判定された場合（ステップＳ１０３／Ｙｅｓ）、監視対象情報１３４にテナントＩＤが設定されていなければ、サンプリング部１１１は、監視対象情報１３４にリクエストのテナントＩＤを設定する（サブプロセス１５１にテナントＩＤを関連づける）（ステップＳ１０４）。
【００４６】
そして、サンプリング部１１１は、リクエストのテナントＩＤをサブプロセス監視部１１３に通知し（ステップＳ１０５）、リクエストをサブプロセス１５１に送信する（ステップＳ１０６）。
【００４７】
例えば、監視回数記憶部１２３に図８のような監視回数情報１３３が記憶されており、リクエストのテナントＩＤが「ｔｅｎａｎｔ＿Ｂ」であるものとする。ここで、監視回数が最小のテナントＩＤを監視候補と判定する場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」の監視回数「５回」が最小であるため、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」を監視候補と判定とする。
【００４８】
ここで、監視対象情報１３４にテナントＩＤが設定されていない場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」を監視可能と判定し、図１０のように、監視対象情報１３４にテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」を設定する。そして、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」をサブプロセス監視部１１３に通知し、リクエストをサブプロセス１５１に送信する。
【００４９】
また、監視対象情報１３４にテナントＩＤにテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」が設定されていた場合も、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」を監視可能と判定し、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」をサブプロセス監視部１１３に通知し、リクエストをサブプロセス１５１に送信する。
【００５０】
サブプロセス１５１は、サンプリング部１１１から受信したリクエストの処理を行う。
【００５１】
一方、ステップＳ１０２において、リクエストのテナントＩＤが監視候補ではないと判定された場合（ステップＳ１０２／Ｎｏ）、または、ステップＳ１０３において、リクエストが監視不可能と判定された場合（ステップＳ１０３／Ｎｏ）、サンプリング部１１１は、リクエストをメインプロセス１５２に送信する（ステップＳ１０７）。
【００５２】
例えば、図８のような監視回数情報１３３が監視回数記憶部１２３に記憶されており、リクエストのテナントＩＤが「ｔｅｎａｎｔ＿Ａ」であった場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」の監視回数「１０回」は最小でないため、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」は監視候補ではないと判定し、リクエストをメインプロセス１５２に送信する。
【００５３】
また、図１０のように、監視対象情報１３４にテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」が設定されており、リクエストのテナントＩＤ「ｔｅｎａｎｔ＿Ｃ」が監視候補と判定された場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｃ」は監視不可能と判定し、リクエストをメインプロセス１５２に送信する。
【００５４】
次に、本発明の第一の実施の形態におけるサービス提供装置１００のレスポンス処理について説明する。図４は、本発明の第一の実施の形態におけるサービス提供装置１００のレスポンス処理の動作を示すフローチャートである。
【００５５】
サンプリング部１１１は、サブプロセス１５１、または、メインプロセス１５２からリクエストの処理結果であるレスポンスを受信する（ステップＳ１２１）。
【００５６】
レスポンスをサブプロセス１５１から受信した場合（ステップＳ１２２／Ｙｅｓ）、サンプリング部１１１は、サブプロセス１５１に送信した全てのリクエストに対してレスポンスを受信したかどうかを判定する（ステップＳ１２３）。
【００５７】
ステップＳ１２３において、全てのリクエストに対してレスポンスを受信した場合（ステップＳ１２３／Ｙｅｓ）、サンプリング部１１１は、監視対象記憶部１２４の監視対象情報１３４からテナントＩＤを削除する（ステップＳ１２４）。
【００５８】
例えば、図１０のように、監視対象情報１３４にテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」が設定されており、サブプロセス１５１に送信した全てのリクエストに対してレスポンスを受信した場合、監視対象情報１３４からテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」を削除する。
【００５９】
サンプリング部１１１は、レスポンスをリクエストの送信元の利用者端末２００に送信する（ステップＳ１２５）。
【００６０】
また、ステップＳ１２２において、レスポンスをメインプロセス１５２から受信した場合（ステップＳ１２２／Ｎｏ）、または、ステップＳ１２３において、サブプロセス１５１に送信したリクエストに対して受信していないレスポンスがある場合（ステップＳ１２３／Ｎｏ）、サンプリング部１１１は、レスポンスをリクエストの送信元の利用者端末２００に送信する（ステップＳ１２５）。
【００６１】
このように、サンプリング部１１１は、監視対象情報１３４に設定されるテナントＩＤを、そのテナントＩＤに対して同時に発生した複数のリクエストに対するレスポンスを全て受信してから削除する。これにより、サブプロセス１５１は、同時に同一のテナントＩＤだけが処理されるように、制御される。
【００６２】
次に、本発明の第一の実施の形態におけるサービス提供装置１００のサブプロセス監視処理について説明する。図５は、本発明の第一の実施の形態におけるサービス提供装置１００のサブプロセス監視処理の動作を示すフローチャートである。
【００６３】
サブプロセス監視部１１３は、サンプリング部１１１から、サブプロセス１５１に送信されたリクエストのテナントＩＤを受信する（ステップＳ２０１）。
【００６４】
サブプロセス監視部１１３は、サブプロセス１５１のメモリ使用量を取得する（ステップＳ２０２）。
【００６５】
例えば、サブプロセス監視部１１３は、ＪａｖａＶＭが提供する、プロセスのメモリ使用量の測定機能を用いて、サブプロセス１５１全体のメモリ使用量を取得する。
【００６６】
サブプロセス監視部１１３は、ステップＳ２０１で受信したテナントＩＤが、メモリ監視ログ１３１に保存されている最新のレコード１４１のテナントＩＤと同じかどうかを判定する（ステップＳ２０３）。
【００６７】
ステップＳ２０３において、受信したテナントＩＤが最新のレコード１４１のテナントＩＤと違う場合（ステップＳ２０３／Ｎｏ）、サブプロセス監視部１１３は、メモリ監視ログ１３１に保存されている最新のレコード１４１の終了時メモリ使用量を、ステップＳ２０２で取得したメモリ使用量で更新する（ステップＳ２０４）。
【００６８】
サブプロセス監視部１１３は、監視回数記憶部１２３の監視回数情報１３３における、最新のレコード１４１のテナントＩＤに対する監視回数に１を加算する（ステップＳ２０５）。
【００６９】
そして、サブプロセス監視部１１３は、メモリ監視ログ１３１に新たなレコード１４１を追加する（ステップＳ２０６）。ここで、サブプロセス監視部１１３は、追加した新たなレコード１４１のテナントＩＤにステップＳ２０１で受信したテナントＩＤを、受付リクエスト数に1を、また、開始時メモリ使用量と終了時メモリ使用量の双方にステップＳ２０２で取得したメモリ使用量を、それぞれ設定する。
【００７０】
例えば、メモリ監視ログ１３１に、図６のレコード１４１ａ、ｂ、ｃが記録されており、受信したテナントＩＤが「ｔｅｎａｎｔ＿Ｂ」であった場合、サブプロセス監視部１１３は、レコード１４１ｃの終了時メモリ使用量を「２５０ＭＢ」で更新する。そして、サブプロセス監視部１１３は、監視回数情報１３３のテナントＩＤ「ｔｅｎａｎｔ＿Ｂ」に対する監視回数に１を加算する。さらに、サブプロセス監視部１１３は、テナントＩＤが「ｔｅｎａｎｔ＿Ｂ」であるレコード１４１ｄを追加し、開始時メモリ使用量と終了時メモリ使用量とに「２５０ＭＢ」を設定する。
【００７１】
一方、ステップ２０３において、受信したテナントＩＤが最新のレコード１４１のテナントＩＤと同じ場合（ステップＳ２０３／Ｙｅｓ）、サブプロセス監視部１１３は、メモリ監視ログ１３１に保存されている最新のレコード１４１の受付リクエスト数に１を加算する（ステップＳ２０７）。
【００７２】
例えば、メモリ監視ログ１３１に、図６のレコード１４１ａ、ｂ、ｃ、ｄが記録されており、受信したテナントＩＤが「ｔｅｎａｎｔ＿Ｂ」であった場合、サブプロセス監視部１１３は、レコード１４１ｄの受付リクエスト数に１を加算する。
【００７３】
ステップＳ２０６、または、ステップＳ２０７が終了すると、サブプロセス監視部１１３は、ステップＳ２０１〜ステップＳ２０７の処理を繰り返す。
【００７４】
これにより、メモリ監視ログ１３１には、サブプロセス１５１が処理するテナントＩＤが切り替わる度に、新たなレコード１４１が追加され、次にテナントＩＤが切り替わるまでの期間における、受付リクエスト数、開始時メモリ使用量、及び、終了時メモリ使用量が記録される。
【００７５】
そして、サブプロセス監視部１１３は、管理者により要求された場合、または、管理者により設定された所定のタイミングで、メモリ監視ログ１３１に記録されたメモリ使用量をテナントＩＤ毎に集計し、メモリ監視結果情報１３２として、メモリ監視結果記憶部１２２に保存する。
【００７６】
例えば、サブプロセス監視部１１３は、図６のメモリ監視ログ１３１の各レコード１４１について、終了時メモリ使用量と開始時メモリ使用量との差分を計算することにより、各レコード１４１に対応する期間における当該レコード１４１に対応するテナントＩＤの総メモリ使用量を算出し、それを受付リクエスト数で割ることで、メモリ使用量の平均値を算出する。そして、サブプロセス監視部１１３は、各レコード１４１のメモリ使用量の平均値を、テナントＩＤ毎に集計し、図７のようなメモリ監視結果情報１３２をメモリ監視結果記憶部１２２に保存する。
【００７７】
なお、サブプロセス監視部１１３は、メモリ監視ログ１３１の各レコード１４１に、監視の開始時間や終了時間を併せて記録し、所定の時間帯におけるメモリ使用量を計算したり、時間に対するメモリ使用量の推移を算出してもよい。
【００７８】
また、サブプロセス１５１がリクエストを処理中に、ガベージ・コレクションが発生することを抑制するために、サンプリング部１１１は、例えば、監視対象情報１３４にテナントＩＤが設定されている間は、ＪａｖａＶＭに対して、ガベージ・コレクションを行わないように制御してもよい。この場合、サブプロセス１５１においてメモリ不足が発生したときは、サンプリング部１１１は、監視対象のテナントＩＤのリクエストをサブプロセス１５１に送信することを中止し、サブプロセス１５１からの全てのリプライを受信後に、ＪａｖａＶＭに対して、強制的にガベージ・コレクションを行うように制御する。
【００７９】
ここで、本発明の第一の実施の形態におけるサービス提供装置１００において監視されるメモリ使用量について説明する。図１１は、本発明の第一の実施の形態におけるサービス提供装置１００のメモリ使用量の変化の例を示す図である。
【００８０】
本発明の第一の実施の形態では、監視候補のテナントＩＤを含むリクエストは、サブプロセス１５１上のスレッドで処理され、監視候補のテナントＩＤを含まないリクエストは、メインプロセス１５２上のスレッドで処理される。従って、サブプロセス監視部１１３が、サブプロセス１５１のメモリ使用量を監視することにより、監視候補のテナントのメモリ使用量を他のテナントのメモリ使用量から区別して、正確に取得できる。
【００８１】
例えば、図１１に示すように、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」のリクエストは、サブプロセス１５１上のスレッド２で処理され、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」「ｔｅｎａｎｔ＿Ｃ」のリクエストは、メインプロセス１５２上のスレッド１で処理される。サブプロセス監視部１１３は、サブプロセス１５１のメモリ使用量を監視することにより、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」のメモリ使用量を精度よく監視できる。
【００８２】
以上により、本発明の第一の実施の形態の動作が完了する。
【００８３】
なお、本発明の第一の実施の形態においては、サブプロセス監視部１１３が、サブプロセス１５１で処理されるテナントＩＤの切り替えを検出し、監視回数情報１３３の監視回数を加算しているが、これをサンプリング部１１１が行うようにしてもよい。
【００８４】
また、本発明の第一の実施の形態においては、サンプリング部１１１が、テナント毎の監視回数をもとに、監視回数が所定値以下のテナントＩＤを監視候補としているが、監視候補は他の方法により与えられてもよい。
【００８５】
例えば、サンプリング部１１１は、テナントＩＤ毎に、受信した全リクエスト数に対する監視回数を算出し、その値が所定値以下のテナントＩＤを監視候補としてもよい。
【００８６】
図９は、本発明の第一の実施の形態における監視回数情報１３３の他の例を示す図である。図９の例では、監視回数情報１３３は、テナントＩＤ毎の監視回数、及び、全リクエスト数を含む。図９のような監視回数情報１３３の場合、監視回数は、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」が最小であるが、全リクエスト数に対する監視回数は、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」が０．１と最小となる。従って、全リクエスト数に対する監視回数が最小のテナントＩＤを監視候補とする場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」を監視候補とする。
【００８７】
また、監視候補のテナントＩＤとして、管理者等により予め指定されたテナントＩＤが指定されていてもよい。
【００８８】
また、監視候補のテナントＩＤとして、管理者等により予め設定された複数のテナントＩＤのいずれかが、所定の時間間隔で切り替えて指定されてもよい。
【００８９】
また、サンプリング部１１１は、本発明の第一の実施の形態により所定期間の間に監視されたメモリ使用量の履歴をもとに、メモリ使用量が大きいテナントを優先的に監視候補としてもよい。同様に、サンプリング部１１１は、所定期間の間に監視されたメモリ使用量の履歴をもとに、１か月の中の各日、曜日、または、時間帯毎にメモリ使用量が大きいテナントを抽出し、監視を行う日、曜日、または、時間帯で、メモリ使用量が大きいテナントを優先的に監視候補としてもよい。
【００９０】
次に、本発明の第一の実施の形態の特徴的な構成を説明する。図１は、本発明の第一の実施の形態の特徴的な構成を示すブロック図である。
【００９１】
サービス提供装置１００は、サンプリング部１１１と、処理部１１２と、サブプロセス監視部１１３と、を含む。
【００９２】
ここで、処理部１１２は、それぞれが複数の属性のいずれかを含むリクエストを、当該リクエストの処理に必要なメモリを確保して処理する、サブプロセス１５１とメインプロセス１５２とを実行する。サンプリング部１１１は、複数の属性の中の、監視候補である１以上の属性の内のいずれか１つをサブプロセス１５１に関連づけ、入力されたリクエストが当該関連づけられた属性を含む場合、当該リクエストをサブプロセス１５１に送信し、それ以外の属性を含む場合、当該リクエストをメインプロセス１５２に送信する。サブプロセス監視部１１３は、サブプロセス１５１におけるリクエストの処理に伴うメモリ使用量を、リクエストの属性毎に取得して出力する。
【００９３】
次に、本発明の第一の実施の形態の効果を説明する。
【００９４】
本発明の第一の実施の形態によれば、マルチテナント型システムにおいて、テナント毎のメモリ使用量を精度良く監視できる。
【００９５】
その理由は、サンプリング部１１１が、入力されたリクエストの属性が監視候補である場合、そのリクエストをサブプロセス１５１に送信し、サブプロセス監視部１１３が、サブプロセス１５１におけるリクエストの処理に伴うメモリ使用量を取得するためである。これにより、取得された監視候補のテナントのメモリ使用量は、他のテナントのメモリ使用量から区別され、かつ、プロセス上で動作するスレッドの数の影響を受けないため、その監視精度は高くなる。
【００９６】
また、本発明の第一の実施の形態によれば、特許文献１のようにプロセスがリクエストを受け付ける毎にメモリ使用量を記録する方法に比べ、低い処理負荷で、メモリ使用量を取得できる。その理由は、サブプロセス１５１は、監視候補のテナントのリクエストのみを処理し、サブプロセス監視部１１３は、監視候補のテナントのリクエストのみについて、サブプロセス１５１のメモリ使用量を記録するためである。
【００９７】
また、本発明の第一の実施の形態によれば、特定のテナントのメモリ使用量を取得するような柔軟な監視の制御を行うことができる。その理由は、サブプロセス１５１は、監視候補のテナントのリクエストのみを処理し、サブプロセス監視部１１３は、監視候補のテナントのリクエストのみについて、サブプロセス１５１のメモリ使用量を取得するためである。これにより、管理者が特定のテナントを監視候補に設定、または、サービス提供装置１００が監視履歴をもとに監視候補を設定することにより、その特定のテナントだけを効率よく取得できる。
【００９８】
（第二の実施の形態）
次に、本発明の第二の実施の形態について図面を参照して詳細に説明する。
【００９９】
本発明の第二の実施の形態においては、サブプロセス１５１が、メインプロセス１５２からプロセス固有情報を取得する点において、本発明の第一の実施の形態と異なる。
【０１００】
プロセス固有情報とは、例えば、プロセス固有のメモリ領域に保持されたデータのように、プロセス内部からしかアクセスできないデータのうち、利用者からの複数のリクエストにまたがって参照、または、更新されるデータである。例えば、ＷＥＢアプリケーションにおけるセッションデータがプロセス固有情報に該当する。このようなプロセス固有情報の参照、更新を行う一連のリクエストが、サブプロセス１５１とメインプロセス１５２とに分かれて処理されると、サブプロセス１５１とメインプロセス１５２とは、同一のプロセス固有情報を参照することができないために、その一連のリクエストの処理は正しく行われない。
【０１０１】
本発明の第二の実施の形態においては、プロセス固有情報媒介部１１４が、サブプロセス１５１からの要求に応じて、メインプロセス１５２のメモリ空間に存在するプロセス固有情報の更新、参照を行う。
【０１０２】
次に、本発明の第二の実施の形態の構成について説明する。本発明の第二の実施の形態において、第一の実施の形態と同様の構成要素については、第一の実施の形態（図２）と同じ符号を付与し、詳細な説明を省略する。
【０１０３】
図１２は、本発明の第二の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【０１０４】
図１２を参照すると、本発明の第二の実施の形態におけるサービス提供装置１００は、本発明の第一の実施の形態の構成に加えて、プロセス固有情報媒介部１１４を含む。
【０１０５】
プロセス固有情報媒介部１１４は、サブプロセス１５１からの要求に応じて、メインプロセス１５２のメモリ空間に存在するプロセス固有情報の更新、参照を行う。
【０１０６】
次に、本発明の第二の実施の形態におけるサービス提供装置１００の動作について説明する。
【０１０７】
図１３は、本発明の第二の実施の形態におけるサービス提供装置１００のプロセス固有情報アクセス処理の動作を示すフローチャートである。
【０１０８】
ここで、プロセス固有情報媒介部１１４は、メインプロセス１５２とサブプロセス１５１との上で動作するプログラムにより実現されているものとする。
【０１０９】
サブプロセス１５１上のスレッドにおいて、プロセス固有情報の参照や更新といったアクセス処理が発生した場合（ステップＳ３０１）、サブプロセス１５１のプロセス固有情報媒介部１１４は、そのアクセス処理に割り込み、メインプロセス１５２のプロセス固有情報媒介部１１４に対して、プロセス間通信によりアクセス処理を要求する（ステップＳ３０２）。ここで、サブプロセス１５１のプロセス固有情報媒介部１１４は、アクセス処理が参照であれば、参照するプロセス固有情報の変数名を通知し、アクセス処理が更新であれば更新するプロセス固有情報の変数名と更新後の値とを通知する。
【０１１０】
メインプロセス１５２のプロセス固有情報媒介部１１４は、サブプロセス１５１のプロセス固有情報媒介部１１４からの要求に従って、メインプロセス１５２のメモリ空間上に存在する、指定された変数名のプロセス固有情報の参照や更新を実施する（ステップＳ３０３）。
【０１１１】
メインプロセス１５２のプロセス固有情報媒介部１１４は、参照や更新の結果を、アクセス処理結果としてサブプロセス１５１のプロセス固有情報媒介部１１４に送信する（ステップＳ３０４）。
【０１１２】
サブプロセス１５１のプロセス固有情報媒介部１１４は、メインプロセス１５２から受信した処理結果を、スレッドで発生したアクセス処理の結果として返答する（ステップＳ３０５）。
【０１１３】
例えば、プロセス固有情報へのアクセス処理に対する割り込みとして、ＡＯＰ（Ａｓｐｅｃｔ  Ｏｒｉｔｅｎｔｅｄ  Ｐｒｏｇｒａｍｉｎｇ）を用いた場合、サブプロセス１５１では、プロセス固有情報を参照するメソッドｇｅｔＳｔａｔｅ（）の代わりに行う処理とに対して、メインプロセス１５２に対してプロセス固有状態情報を要求する処理が定義される。サブプロセス１５１のプロセス固有情報媒介部１１４は、サブプロセス１５１上のスレッドで要求されたｇｅｔＳｔａｔｅ（）の実行をキャンセルし、プロセス間通信により、メインプロセス１５２に、プロセス固有状態情報を要求する。メインプロセス１５２のプロセス固有情報媒介部１１４は、この要求に応じて、ｇｅｔＳｔａｔｅ（）メソッドを実行し、その結果をプロセス間通信により、サブプロセス１５１へ応答する。そして、サブプロセス１５１のプロセス固有情報媒介部１１４は、受け取った結果をｇｅｔＳｔａｔｅ（）メソッドの結果として返答する。
【０１１４】
以上により、本発明の第二の実施の形態の動作が完了する。
【０１１５】
本発明の第二の実施の形態によれば、監視候補のテナントのリクエストがプロセス固有情報の参照、更新を行う場合でも、そのテナントを監視候補として、サブプロセス１５１によるメモリ使用量の監視を行うことができる。その理由は、プロセス固有情報媒介部１１４が、サブプロセス１５１からの要求に応じて、メインプロセス１５２のメモリ空間に存在するプロセス固有情報の更新、参照を行うためである。
【０１１６】
（第三の実施の形態）
次に、本発明の第三の実施の形態について図面を参照して詳細に説明する。
【０１１７】
本発明の第三の実施の形態においては、サンプリング部１１１がメインプロセス１５２におけるテナント毎のメモリ使用量の概算値をもとに監視候補のテナントを決定する点において、本発明の第一の実施の形態と異なる。
【０１１８】
次に、本発明の第三の実施の形態の構成について説明する。本発明の第三の実施の形態において、第一の実施の形態と同様の構成要素については、第一の実施の形態（図２）と同じ符号を付与し、詳細な説明を省略する。
【０１１９】
図１４は、本発明の第三の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【０１２０】
図１４を参照すると、本発明の第三の実施の形態におけるサービス提供装置１００は、本発明の第一の実施の形態の構成に加えて、メインプロセス監視部１１５と概算メモリ監視結果記憶部１２５とを含む。
【０１２１】
メインプロセス監視部１１５は、メインプロセス１５２におけるテナント毎のメモリ使用量（メインプロセス１５２でテナント毎に確保されたメモリ量）の概算値（以下、概算メモリ使用量とする）を取得し、概算メモリ監視結果記憶部１２５の概算メモリ監視結果情報１３５に保存する。
【０１２２】
概算メモリ使用量は、サブプロセス１５１における監視候補のテナントを決定するために使用する情報である。概算メモリ使用量の監視精度は、サブプロセス監視部１１３により取得されるメモリ使用量の監視精度よりも低くてよい。また、概算メモリ使用量は、メインプロセス１５２への影響が少なく、かつ、簡易な方法で取得されることが望ましい。本発明の第三の実施の形態においては、メインプロセス監視部１１５は、特許文献１に記載された方法と同様の方法により、メインプロセス１５２におけるテナント毎の概算メモリ使用量を取得するものとする。すなわち、メインプロセス監視部１１５は、メインプロセス１５２全体のメモリ使用量と、メインプロセス１５２で処理が実行されていたテナントを監視し、メインプロセス１５２全体のメモリ使用量を実行されていた各テナントに所定の割合で案分することで、テナント毎の概算メモリ使用量を算出する。
【０１２３】
概算メモリ監視結果記憶部１２５は、概算メモリ監視結果情報１３５を記憶する。図１５は、本発明の第三の実施の形態における概算メモリ監視結果情報１３５の例を示す図である。概算メモリ監視結果情報１３５は、図１５に示すように、メインプロセス１５２におけるテナントＩＤ毎の累積概算メモリ使用量、総リクエスト数、及び、概算メモリ使用量を含む。
【０１２４】
サンプリング部１１１は、概算メモリ監視結果情報１３５を参照し、メインプロセス１５２の概算メモリ使用量をもとに、監視候補のテナントＩＤを決定する。
【０１２５】
次に、本発明の第三の実施の形態におけるサービス提供装置１００の動作について説明する。
【０１２６】
はじめに、メインプロセス監視部１１５は、特許文献１と同様の方法により、メインプロセス１５２におけるテナント毎の概算メモリ使用量を取得する。
【０１２７】
例えば、メインプロセス監視部１１５は、ある期間におけるメモリ使用量が３００ＭＢであり、その期間において処理したリクエストのテナントＩＤが「ｔｅｎａｎｔ＿Ａ」と「ｔｅｎａｎｔ＿Ｂ」であれば、これらのテナントが１５０ＭＢずつメモリを使用したものとみなして、概算メモリ監視結果情報１３５の各テナントの累積概算メモリ使用量へ加算し、各テナントの総リクエスト数に１を加算する。そして、メインプロセス監視部１１５は、所定のタイミングで、各テナントの累積概算メモリ使用量を総リクエスト数で割ることにより、リクエストあたりの概算メモリ使用量を算出し、概算メモリ監視結果情報１３５へ保存する。この結果、概算メモリ監視結果記憶部１２５には、例えば、図１５のような概算メモリ使用量が保存される。
【０１２８】
次に、本発明の第三の実施の形態におけるリクエスト処理について説明する。本発明の第三の実施の形態におけるリクエスト処理の動作は、テナントＩＤを監視候補とするかどうか判定する処理（ステップＳ１０２）を除き、本発明の第一の実施の形態（図３）と同様となる。
【０１２９】
ステップＳ１０２において、サンプリング部１１１は、概算メモリ監視結果記憶部１２５の概算メモリ監視結果情報１３５を参照し、概算メモリ使用量が所定値以下のテナントＩＤを監視候補とする。
【０１３０】
例えば、概算メモリ監視結果記憶部１２５に図１５のような概算メモリ監視結果情報１３５が記憶されており、概算メモリ使用量が最大のテナントＩＤを監視候補と判定する場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」の概算メモリ使用量「３０ＭＢ」が最大であるため、テナントＩＤ「ｔｅｎａｎｔ＿Ａ」を監視候補とする。
【０１３１】
また、サンプリング部１１１は、監視回数記憶部１２３の監視回数情報１３３を参照し、監視回数あたりの概算メモリ使用量が所定値以上のテナントＩＤを監視候補としてもよい。
【０１３２】
例えば、監視回数記憶部１２３に図８のような監視回数情報１３３、概算メモリ監視結果記憶部１２５に図１５のような概算メモリ監視結果情報１３５が記憶されている場合、サンプリング部１１１は、テナントＩＤ「ｔｅｎａｎｔ＿Ｃ」の監視回数あたりの概算メモリ使用量「２８ＭＢ／７＝４ＭＢ」が最大であるため、テナントＩＤ「ｔｅｎａｎｔ＿Ｃ」を監視候補とする。
【０１３３】
このように、本発明の第一の実施形態のように、監視回数をもとに監視候補を決定した場合には、テナントＩＤ「ｔｅｎａｎｔ＿Ｂ」が監視候補として決定されるのに対し、本発明の第三の実施形態においては、メインプロセス１５２における概算メモリ使用量が大きいテナントＩＤ「ｔｅｎａｎｔ＿Ａ」、または、テナントＩＤ「ｔｅｎａｎｔ＿Ｃ」が監視候補として決定される。
【０１３４】
以上により、本発明の第三の実施の形態の動作が完了する。
【０１３５】
なお、本発明の第三の実施の形態においては、サンプリング部１１１が、メインプロセス１５２における概算メモリ使用量が所定値以上のテナントＩＤを監視候補としているが、サンプリング部１１１は、概算メモリ使用量の測定結果を用いた他の方法により監視候補を決定してもよい。
【０１３６】
例えば、メインプロセス監視部１１５が、メインプロセス１５２における概算メモリ使用量とともに、同時に処理されたテナント数をテナント毎に算出し、サンプリング部１１１は、同時に処理されたテナント数が多いほど、その概算メモリ使用量の精度が低いとし、概算メモリ使用量の精度が低いテナントを優先的に監視候補としてもよい。
【０１３７】
また、サンプリング部１１１は、概算メモリ使用量とその概算メモリ使用量の精度との両方を用い、例えば、概算メモリ使用量に対するその概算メモリ使用量の精度が低いテナントを優先的に監視候補としてもよい。
【０１３８】
本発明の第三の実施の形態によれば、メインプロセス１５２におけるメモリ使用量が大きいと推定されるテナントについて、メモリ使用量を優先的に監視できる。その理由は、サンプリング部１１１が、メインプロセス１５２における概算メモリ使用量を算出し、サンプリング部１１１が、概算メモリ使用量をもとに監視候補のテナントＩＤを決定するためである。
【０１３９】
（第四の実施の形態）
次に、本発明の第四の実施の形態について図面を参照して詳細に説明する。
【０１４０】
本発明の第四の実施の形態においては、サンプリング部１１１が、監視候補のテナントＩＤを含むリクエストをサンプリングキュー１１６に格納し、処理する点において、本発明の第一の実施の形態と異なる。
【０１４１】
次に、本発明の第四の実施形態の構成について説明する。本発明の第四の実施の形態において、第一の実施の形態と同様の構成要素については、第一の実施の形態（図２）と同じ符号を付与し、詳細な説明を省略する。
【０１４２】
図１６は、本発明の第四の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【０１４３】
図１６を参照すると、本発明の第四の実施の形態におけるサービス提供装置１００は、本発明の第一の実施の形態の構成に加えて、サンプリングキュー１１６を含む。
【０１４４】
サンプリングキュー１１６は、所定数のリクエストを保持する。
【０１４５】
サンプリング部１１１は、リクエストのテナントＩＤが監視候補の場合、そのリクエストをサンプリングキュー１１６に格納する。そして、サンプリング部１１１は、サンプリングキュー１１６に格納されているリクエストが監視可能となった場合、そのリクエストをサブプロセス１５１へ送信する。
【０１４６】
次に、本発明の第四の実施の形態におけるサービス提供装置１００の動作について説明する。
【０１４７】
はじめに、本発明の第四の実施の形態におけるサービス提供装置１００のリクエスト処理について説明する。図１７は、本発明の第四の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【０１４８】
はじめに、サンプリング部１１１は、利用者端末２００からリクエストを受信する（ステップＳ４０１）。
【０１４９】
サンプリング部１１１は、リクエストのテナントＩＤが監視候補かどうかを判定する（ステップＳ４０２）。
【０１５０】
ステップＳ４０２において、リクエストのテナントＩＤが監視候補であると判定された場合（ステップＳ４０２／Ｙｅｓ）、サンプリング部１１１は、リクエストをサンプリングキュー１１６に格納する（ステップＳ４０３）。
【０１５１】
一方、ステップＳ４０２において、リクエストのテナントＩＤが監視候補でないと判定された場合（ステップＳ４０２／Ｎｏ）、サンプリング部１１１は、リクエストをメインプロセス１５２に送信する（ステップＳ４０４）。
【０１５２】
次に、本発明の第四の実施の形態におけるサービス提供装置１００のサンプリングキュー処理について説明する。図１８は、本発明の第四の実施の形態におけるサービス提供装置１００のサンプリングキュー処理の動作を示すフローチャートである。
【０１５３】
サンプリング部１１１が、リクエストをサンプリングキュー１１６に格納（ステップＳ４０３）、または、監視対象情報１３４からナントＩＤを削除（ステップＳ１２４）した場合、サンプリング部１１１は、サンプリングキュー１１６のリクエストを先頭から順番に１つ読み出す（ステップＳ４４１）。
【０１５４】
サンプリング部１１１は、リクエストが監視可能かどうかを判定する（ステップＳ４４２）。ここで、サンプリング部１１１は、本発明の第一の実施の形態と同様の監視可能条件により、リクエストが監視可能かどうかを判定する。
【０１５５】
ステップＳ４４２において、リクエストが監視可能であると判定された場合（ステップＳ４４２／Ｙｅｓ）、監視対象情報１３４にテナントＩＤが設定されていなければ、サンプリング部１１１は、監視対象情報１３４にリクエストのテナントＩＤを設定する（ステップＳ４４３）。
【０１５６】
そして、サンプリング部１１１は、リクエストのテナントＩＤをサブプロセス監視部１１３に通知し（ステップＳ４４４）、リクエストをサブプロセス１５１に送信する（ステップＳ４４５）。
【０１５７】
ステップＳ４４２において、リクエストが監視不可能であると判定された場合（ステップＳ４４２／Ｎｏ）、サンプリング部１１１は、そのリクエストが所定時間以上サンプリングキュー１１６に滞留しているかどうかを判定する（ステップＳ４４７）。
【０１５８】
ステップＳ４４７において、所定時間以上サンプリングキュー１１６に滞留していると判定された場合（ステップＳ４４７／Ｙｅｓ）、サンプリング部１１１は、リクエストをメインプロセス１５２に送信する（ステップＳ４４８）。
【０１５９】
また、ステップＳ４４７において、所定時間以上サンプリングキュー１１６に滞留していないと判定された場合（ステップＳ４４７／Ｎｏ）、サンプリング部１１１は、リクエストをそのままサンプリングキュー１１６に保持する。
【０１６０】
リクエストがサブプロセス１５１、または、メインプロセス１５２に送信された場合（ステップＳ４４５、または、ステップＳ４４８）、サンプリング部１１１は、そのリクエストをサンプリングキュー１１６から削除する（ステップＳ４４６）。
【０１６１】
サンプリング部１１１は、ステップＳ４４１〜Ｓ４４７を、サンプリングキュー１１６に格納されている全てのリクエストを処理するまで繰り返す（ステップＳ４４９）。
【０１６２】
なお、本発明の第四の実施の形態におけるサービス提供装置１００のレスポンス処理、及び、サブプロセス監視処理の動作は、本発明の第一の実施の形態（図４、図５）と同様となる。
【０１６３】
以上により、本発明の第四の実施の形態の動作が完了する。
【０１６４】
本発明の第四の実施の形態によれば、本発明の第一の実施の形態に比べて、複数の監視候補のテナントを効率よく監視できる。その理由は、サンプリング部１１１が、監視候補のテナントＩＤを含むリクエストをサンプリングキュー１１６に保持し、サンプリングキュー１１６に格納されたリクエストが監視可能となった場合、そのリクエストをサブプロセス１５１に送信するためである。これにより、サブプロセス１５１においてあるテナントが監視されているときに他のテナントのリクエストを受信した場合でも、監視中のテナントの監視終了を待って、他のテナントの監視を開始でき、複数のテナントを効率よく監視できる。
【０１６５】
（第五の実施の形態）
次に、本発明の第五の実施の形態について図面を参照して詳細に説明する。
【０１６６】
本発明の第五の実施の形態においては、処理部１１２上で複数のサブプロセス１５１が動作し、複数のテナントのそれぞれを、各サブプロセス１５１で監視する点において、本発明の第一の実施の形態と異なる。
【０１６７】
次に、本発明の第五の実施形態の構成について説明する。本発明の第五の実施の形態において、第一の実施の形態と同様の構成要素については、第一の実施の形態（図２）と同じ符号を付与し、詳細な説明を省略する。
【０１６８】
図１９は、本発明の第五の実施の形態におけるマルチテナントシステムの構成を示すブロック図である。
【０１６９】
本発明の第五の実施の形態においては、処理部１１２は、複数のサブプロセス１５１の処理を実行する。また、本発明の第五の実施の形態においては、サービス提供装置１００は、複数のサブプロセス監視部１１３を含む。複数のサブプロセス監視部１１３のそれぞれは、複数のサブプロセス１５１のそれぞれのメモリ使用量を取得する。
【０１７０】
サンプリング部１１１は、監視候補のテナントＩＤを含むリクエストがサブプロセス１５１のいずれかに関して監視可能条件を満たす場合、そのリクエストを、監視可能条件を満たすサブプロセス１５１に送信し、サブプロセス１５１のいずれも監視可能条件を満たさない場合、そのリクエストをメインプロセス１５２に送信する。
【０１７１】
サブプロセス監視部１１３は、各サブプロセス１５１のメモリ使用量を取得し、メモリ監視ログ１３１に記録する。
【０１７２】
図２２は、本発明の第五の実施の形態における監視対象情報１３４の例を示す図である。監視対象情報１３４は、サブプロセス１５１を識別するサブプロセスＩＤ毎に、そのサブプロセス１５１で処理中の（そのサブプロセス１５１に関連づけられた）監視対象のテナントＩＤを含む。
【０１７３】
次に、本発明の第五の実施の形態におけるサービス提供装置１００の動作について説明する。
【０１７４】
はじめに、本発明の第五の実施の形態におけるサービス提供装置１００のリクエスト処理について説明する。図２０は、本発明の第五の実施の形態におけるサービス提供装置１００のリクエスト処理の動作を示すフローチャートである。
【０１７５】
サンプリング部１１１は、利用者端末２００からリクエストを受信する（ステップＳ５０１）。
【０１７６】
サンプリング部１１１は、リクエストのテナントＩＤが監視候補かどうかを判定する（ステップＳ５０２）。
【０１７７】
ステップＳ５０２において、リクエストのテナントＩＤが監視候補であると判定された場合（ステップＳ５０２／Ｙｅｓ）、サンプリング部１１１は、リクエストが、複数のサブプロセス１５１のいずれかにおいて監視可能かどうかを判定する（ステップＳ５０３）。
【０１７８】
ここで、サンプリング部１１１は、複数のサブプロセス１５１のいずれかにおいて、上述の監視可能条件を満たす場合、そのリクエストは、そのサブプロセス１５１で監視可能と判定する。なお、サンプリング部１１１は、監視可能条件の判定において、処理中のリクエストが無いサブプロセス１５１があっても、リクエストのテナントＩＤと同一のテナントＩＤのリクエストを処理しているサブプロセス１５１がある場合は、そのサブプロセス１５１を監視可能なサブプロセス１５１と判定する。
【０１７９】
ステップＳ５０３において、リクエストが監視可能であると判定された場合（ステップＳ５０３／Ｙｅｓ）、監視対象情報１３４における監視可能と判定されたサブプロセスＩＤに対してテナントＩＤが設定されていなければ、サンプリング部１１１は、そのサブプロセスＩＤに対して、リクエストのテナントＩＤを設定する（そのサブプロセスＩＤにテナントＩＤを関連づける）（ステップＳ５０４）。
【０１８０】
そして、サンプリング部１１１は、リクエストのテナントＩＤを監視可能と判定されたサブプロセス１５１を監視するサブプロセス監視部１１３に通知し（ステップＳ５０５）、リクエストを監視可能と判定されたサブプロセス１５１に送信する（ステップＳ５０６）。
【０１８１】
一方、ステップＳ５０２において、リクエストのテナントＩＤが監視候補ではないと判定された場合（ステップＳ５０２／Ｎｏ）、または、ステップＳ５０３において、リクエストが複数のサブプロセス１５１のいずれにおいても監視不可能と判定された場合（ステップＳ５０３／Ｎｏ）、サンプリング部１１１は、リクエストをメインプロセス１５２に送信する（ステップＳ５０７）。
【０１８２】
次に、本発明の第五の実施の形態におけるサービス提供装置１００のレスポンス処理について説明する。図２１は、本発明の第五の実施の形態におけるサービス提供装置１００のレスポンス処理の動作を示すフローチャートである。
【０１８３】
サンプリング部１１１は、サブプロセス１５１、又は、メインプロセス１５２からリクエストに対するレスポンスを受信する（ステップＳ５２１）。
【０１８４】
レスポンスをサブプロセス１５１から受信した場合（ステップＳ５２２／Ｙｅｓ）、サンプリング部１１１は、そのサブプロセス１５１に送信した全てのリクエストに対してレスポンスを受信したかどうかを判定する（ステップＳ５２３）。
【０１８５】
ステップＳ５２３において、そのサブプロセス１５１に送信した全てのリクエストに対してレスポンスを受信した場合（ステップＳ５２３／Ｙｅｓ）、サンプリング部１１１は、監視対象記憶部１２４の監視対象情報１３４から、そのサブプロセス１５１に対するテナントＩＤを削除する（ステップＳ５２４）。
【０１８６】
サンプリング部１１１は、レスポンスをリクエストの送信元の利用者端末２００に送信する（ステップＳ５２５）。
【０１８７】
また、ステップＳ５２２において、レスポンスをメインプロセス１５２から受信した場合（ステップＳ５２２／Ｎｏ）、または、ステップＳ５２２において、サブプロセス１５１に送信したリクエストに対して受信していないレスポンスがある場合（ステップＳ５２３／Ｎｏ）も、サンプリング部１１１は、レスポンスをリクエストの送信元の利用者端末２００に送信する（ステップＳ５２５）。
【０１８８】
次に、本発明の第五の実施の形態におけるサービス提供装置１００のサブプロセス監視処理について説明する。本発明の第五の実施の形態におけるサブプロセス監視処理は、本発明の第一の実施の形態におけるサブプロセス監視処理（図５）と同様の処理を、それぞれのサブプロセス監視部１１３が行う。
【０１８９】
以上により、本発明の第五の実施の形態の動作が完了する。
【０１９０】
本発明の第五の実施の形態によれば、本発明の第一の実施の形態に比べて、複数のテナントの監視を効率よく行うことができる。その理由は、処理部１１２上で複数のサブプロセス１５１が動作し、サンプリング部１１１が、監視候補のテナントＩＤを含むリクエストを複数のサブプロセス１５１のいずれかに転送し、サブプロセス監視部１１３が、各サブプロセス１５１のメモリ使用量を取得するためである。これにより、複数のテナントを同時並行で、効率よく監視できる。
【０１９１】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１９２】
例えば、本発明の実施の形態では、リクエストの属性としてテナントＩＤを対象とし、テナント毎のメモリ使用量を監視しているが、対象とする属性はこれに限らず、リクエストを送信した利用者の識別子や、リクエストにより実行される処理内容（機能）の識別子を対象とすることにより、利用者や処理内容（機能）毎のメモリ使用量を監視してもよい。
【０１９３】
また、本発明の実施の形態では、プロセス上で複数のスレッドが動作し、これら複数のスレッドがプロセスのメモリ空間を共有し、複数のリクエストを同時並行処理するものとしたが、プロセス上で複数のリクエストを同時並行処理できるものであれば、スレッド以外の手法で、リクエストの処理が行われてもよい。
【０１９４】
また、本発明の実施の形態においては、プロセスにおけるメモリ使用量は、リクエストの処理とともに累積的に増加し、ガベージ・コレクションにより解放されるものとしたが、メモリは、リクエストの処理の途中で必要になった時点で確保され、不要となった時点で解放されてもよい。この場合、サブプロセス監視部１１３は、定期的にサブプロセス１５１のメモリ使用量を監視し、その最大値を、メモリ監視ログ１３１の各レコード１４１におけるメモリ使用量としてもよい。
【符号の説明】
【０１９５】
１００    サービス提供装置
１１１    サンプリング部
１１２    処理部
１１３    サブプロセス監視部
１１４    プロセス固有情報媒介部
１１５    メインプロセス監視部
１１６    サンプリングキュー
１２１    メモリ監視ログ記憶部
１２２    メモリ監視結果記憶部
１２３    監視回数記憶部
１２４    監視対象記憶部
１２５    概算メモリ監視結果記憶部
１３１    メモリ監視ログ
１３２    メモリ監視結果情報
１３３    監視回数情報
１３４    監視対象情報
１３５    概算メモリ監視結果情報
１４１    レコード
１５１    サブプロセス
１５２    メインプロセス
２００    利用者端末
【図１】
2012113380.tif 000003
【図２】
2012113380.tif 000004
【図３】
2012113380.tif 000005
【図４】
2012113380.tif 000006
【図５】
2012113380.tif 000007
【図６】
2012113380.tif 000008
【図７】
2012113380.tif 000009
【図８】
2012113380.tif 000010
【図９】
2012113380.tif 000011
【図１０】
2012113380.tif 000012
【図１１】
2012113380.tif 000013
【図１２】
2012113380.tif 000014
【図１３】
2012113380.tif 000015
【図１４】
2012113380.tif 000016
【図１５】
2012113380.tif 000017
【図１６】
2012113380.tif 000018
【図１７】
2012113380.tif 000019
【図１８】
2012113380.tif 000020
【図１９】
2012113380.tif 000021
【図２０】
2012113380.tif 000022
【図２１】
2012113380.tif 000023
【図２２】
2012113380.tif 000024
【図２３】
2012113380.tif 000025
【図２４】
2012113380.tif 000026