(57)【要約】【課題】  データ管理システムで、所定期間中にデータベースの処理性能を下げることのできる上限回数に達した後の、データベースの処理性能を下げることのできない期間を短く抑えることを目的とする。【解決手段】  本発明のデータ管理システムは、データベースにアクセスする必要があるリクエストを監視する監視手段と、前記監視されるリクエストの量と、前記監視されるリクエストの量が第１基準値を下回った際に前記データベースの処理能力を下げる調整を行うまでに待機すべき所定時間とに基づき、前記データベースの処理能力を下げるように調整する調整手段と、を有し、前記調整手段は、前記監視されるリクエストの量が前記第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視されるリクエストの量が該第１基準値を下回っていたことに応じて、前記データベースの処理能力を下げるように調整する。【選択図】  図６
2017033142.tif 000002
【特許請求の範囲】
【請求項１】
所定期間中に処理能力を下げるように調整することのできる回数が制限されているデータベースの処理能力を、該データベースにアクセスする必要があるリクエストの増加に応じて、上げるように調整するデータ管理システムであって、
前記データベースにアクセスする必要があるリクエストを監視する監視手段と、
前記監視手段により監視されるリクエストの量と、前記監視手段により監視されるリクエストの量が第１基準値を下回った際に前記データベースの処理能力を下げる調整を行うまでに待機すべき所定時間とに基づき、前記データベースの処理能力を下げるように調整する調整手段と、を有し、
前記調整手段は、前記監視手段により監視されるリクエストの量が前記第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視手段により監視されるリクエストの量が該第１基準値を下回っていたことに応じて、前記データベースの処理能力を下げるように調整することを特徴とするデータ管理システム。
【請求項２】
データベースにアクセスする必要があるリクエストの量を監視する監視手段と、
前記監視手段により監視されるリクエストの量の増減に応じて、前記データベースの処理能力を調整する調整手段と、
所定期間中に前記調整手段が前記データベースの処理能力を下げるように調整した回数を示す調整回数、及び、当該所定期間中に前記調整手段が前記データベースの処理能力を下げるように調整することができる回数を示す上限回数を管理する管理手段と、を有し、
前記調整手段は、前記所定期間中の前記上限回数以内の前記データベースの処理能力を下げる調整において、前記監視手段により監視されるリクエストの量が第１基準値を下回った時から、前記所定期間を前記上限回数で割った時間より短い時間である所定時間の経過時に前記監視手段により監視されるリクエストの量が該第１基準値を下回っていたことに応じて前記データベースの処理能力を下げるように調整した後、前記監視手段により監視されるリクエストの量の増加に応じて上げるように調整された前記データベースの処理能力を再び下げるように調整する際には、
前記監視手段により監視されるリクエストの量が第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視手段により監視されるリクエストの量が該第１基準値を下回っていたことに応じて前記データベースの処理能力を下げるように調整することを特徴とするデータ管理システム。
【請求項３】
前記調整手段は、前記監視手段により監視されるリクエストの量が第１基準値を下回った時から所定時間の経過時に前記監視手段により監視されるリクエストの量が該第１基準値を下回っていなかった場合には、前記データベースの処理能力を下げるような調整を行わないことを特徴とする請求項２に記載のデータ管理システム。
【請求項４】
前記監視手段は、前記データベースにデータを書き込むためのリクエストの単位時間当たりのリクエストの量を監視し、
前記データベースの処理能力は、該単位時間当たりに処理可能なリクエストの量に応じたリソース量で定められることを特徴とする請求項２または３に記載のデータ管理システム。
【請求項５】
前記調整手段は、前記データベースの処理能力を下げるように調整する際には、前記データベースの処理能力について前記第１基準値まで下げるように調整することを特徴とする請求項２乃至４のいずれか１項に記載のデータ管理システム。
【請求項６】
前記調整手段は、前記所定期間中において、前記監視手段により監視されるリクエストの量が、前記データベースの処理能力に応じて定められる第２基準値を上回っている場合、前記監視されるリクエストの量に基づいて決定される調整量を用いて前記データベースの処理能力を上げるように調整することを特徴とする請求項２乃至５のいずれか１項に記載のデータ管理システム。
【請求項７】
前記データベースにアクセスする必要があるリクエストの量が前記データベースの処理能力を超えた場合に、該リクエストの一部を一時的に記憶する一時記憶手段と、
前記一時記憶手段に記憶されているリクエストの量を取得する取得手段を更に有し、
前記調整手段は、前記所定期間中において、前記監視手段により監視されるリクエストの量が、前記データベースの処理能力に応じて定められる第２基準値を上回っている場合、前記取得手段により取得される前記リクエストの量に基づいて決定される調整量を用いて前記データベースの処理能力を上げるように調整することを特徴とする請求項２乃至６のいずれか１項に記載のデータ管理システム。
【請求項８】
前記監視手段は、前記監視されるリクエストの量の過去データを更に保存し、
前記調整手段は、前記所定期間中の前記管理手段により管理される前記調整回数が前記管理手段により管理される前記上限回数に達した後、前記監視手段により監視されるリクエストが前記データベースの処理能力に応じて定められる第２基準値を上回っている場合、前記監視手段により保存される前記過去データの平均値を超えないようにして、前記データベースの処理能力を調整することを特徴とする請求項２乃至７のいずれか１項に記載のデータ管理システム。
【請求項９】
前記監視手段は、前記監視されるリクエストの量の過去データを更に保存し、
前記調整手段は、前記所定期間中の前記管理手段により管理される前記調整回数が前記管理手段により管理される前記上限回数に達した後、前記監視手段により監視されるリクエストが前記データベースの処理能力に応じて定められる第２基準値を上回っている場合、前記監視手段により保存される前記過去データの平均値を超えないようにして、前記所定期間の残りの期間に基づいて、前記データベースの処理能力を調整することを特徴とする請求項２乃至７のいずれか１項に記載のデータ管理システム。
【請求項１０】
前記監視手段は、前記監視されるリクエストの量の過去データを更に保存し、
前記調整手段は、前記監視手段により保存される過去データに基づいて決定される調整量を用いて前記第１基準値を更新することを特徴とする請求項２乃至７のいずれか１項に記載のデータ管理システム。
【請求項１１】
前記調整手段は、前記所定期間の残り時間が前記所定時間未満である場合において、前記監視手段により監視されるリクエストの量が前記第１基準値を下回った時から前記所定時間の経過前であっても、前記所定期間内に、前記データベースの処理能力を下げるように調整することを特徴とする請求項２乃至１０のいずれか１項に記載のデータ管理システム。
【請求項１２】
所定期間中に処理能力を下げるように調整することのできる回数が制限されているデータベースの処理能力を、該データベースにアクセスする必要があるリクエストの増加に応じて、上げるように調整するデータ管理システムの制御方法であって、
前記データベースにアクセスする必要があるリクエストを監視する監視工程と、
前記監視工程で監視されるリクエストの量と、前記監視工程で監視されるリクエストの量が第１基準値を下回った際に前記データベースの処理能力を下げる調整を行うまでに待機すべき所定時間とに基づき、前記データベースの処理能力を下げるように調整する調整工程と、を有し、
前記調整工程では、前記監視工程で監視されるリクエストの量が前記第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視工程で監視されるリクエストの量が該第１基準値を下回っていたことに応じて、前記データベースの処理能力を下げるように調整することを特徴とする制御方法。
【請求項１３】
データベースにアクセスする必要があるリクエストの量を監視する監視工程と、
前記監視工程で監視されるリクエストの量の増減に応じて、前記データベースの処理能力を調整する調整工程と、
所定期間中に前記調整工程で前記データベースの処理能力を下げるように調整した回数を示す調整回数、及び、当該所定期間中に前記調整工程で前記データベースの処理能力を下げるように調整することができる回数を示す上限回数を管理する管理工程と、を有し、
前記調整工程では、前記所定期間中の前記上限回数以内の前記データベースの処理能力を下げる調整において、前記監視工程で監視されるリクエストの量が第１基準値を下回った時から、前記所定期間を前記上限回数で割った時間より短い時間である所定時間の経過時に前記監視工程で監視されるリクエストの量が該第１基準値を下回っていたことに応じて前記データベースの処理能力を下げるように調整した後、前記監視工程で監視されるリクエストの量の増加に応じて上げるように調整された前記データベースの処理能力を再び下げるように調整する際には、
前記監視工程で監視されるリクエストの量が第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視工程で監視されるリクエストの量が該第１基準値を下回っていたことに応じて前記データベースの処理能力を下げるように調整することを特徴とするデータ管理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理システムにおけるデータベースの処理能力の調整技術に関する。
【背景技術】
【０００２】
近年、インターネット上にあるサーバーコンピュータで動作する各種アプリケーションを利用することができるサービスとして、クラウドサービスがある。ＩａａＳやＰａａＳなどのクラウドサービスでは、クラウドサービスベンダーが、ネットワークを介して、仮想マシンやストレージなどのリソースをシステム管理者に提供する。仮想マシンとは、仮想化技術によって、サーバーコンピュータを物理的な構成にとらわれずに論理的な単位で分割または統合し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。システム管理者は、クラウドサービスベンダーによって提供される仮想マシンやストレージ、キューなどのリソースを用いて、独自のサービスを提供するためのシステムを構築することができる。
【０００３】
上述したクラウドサービスを利用するシステムとして、例えば、クライアントコンピュータからのリクエストを受信して、そのリクエストに係るデータをデータベースで管理するデータ管理システムが存在する。データ管理システムにおける、データの入出力に関するデータベース処理性能の指標の１つに、スループットがある。スループットとは、一定のデータサイズ以下のリクエストについての、ある単位時間当たりにデータベースが処理可能なリクエストの量である。また、スループットは、データ書き込みに関するものとデータ読み出しに関するものとそれぞれについて設定される。クラウドサービスでは、基本的に、スループットの設定値やリソースの利用時間に応じて利用料金が定められる。
【０００４】
システムの利用状況を監視し、その負荷状況に応じてシステムを自動でスケール制御する技術がある。特許文献１では、クライアント端末からジョブの実行要求を受けた場合に、ジョブ管理データベースが記憶するそのジョブの実行条件と、リソース監視部が監視する負荷状況に基づいて、そのジョブを実行させるサーバーの台数を決定する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−０６０２７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したデータ管理システムにおいて、データベースへのデータ書き込みやデータ読み出しに係るリクエストの数は時期によって変動する。単位時間当たりにデータベースにアクセスする必要のあるリクエストが、スループットとして設定されるデータベースの処理能力を超えた場合、処理されないリクエストについては要求元へエラーが返ってしまう。そのため、リクエストが多い時にはスループットの値を高く設定する必要がある。
【０００７】
また、スループットの設定値に応じて、クラウドサービスの利用料金が決定されるため、常時スループットの値を高く設定すると利用料金が高額になるおそれがある。そこで、リクエストが少ない時にはスループットの設定値を低くすることで、利用料金を抑えることができる。したがって、データベースへアクセスするリクエストの増減に応じて、スループットの値を適切に調整することが求められる。
【０００８】
一方で、上述したクラウドサービスにおいては、所定期間中にスループットを下げてデータベース処理能力を低く調整することのできる回数に制限が課されている場合がある。スループットを下げることのできる回数が上限回数に達すると、データ管理システムのシステム管理者は、残りの期間中にリクエストをエラー処理させないために、スループットの値を高く設定したまま使用し続けなければならない場合がある。こういった場合、スループットの値を高く設定したままの期間が長引くと、そのための利用料金が高額になってしまうという課題が生じる。
【０００９】
ここで、上述した特許文献１で開示される技術は、スループットの設定値などデータベースの処理能力の調整に関するものではない。また、データベースの処理性能の調整の回数に制限があるといったことをまったく想定していない。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明のデータ管理システムは、所定期間中に処理能力を下げるように調整することのできる回数が制限されているデータベースの処理能力を、該データベースにアクセスする必要があるリクエストの増加に応じて、上げるように調整するデータ管理システムであって、前記データベースにアクセスする必要があるリクエストを監視する監視手段と、前記監視手段により監視されるリクエストの量と、前記監視手段により監視されるリクエストの量が第１基準値を下回った際に前記データベースの処理能力を下げる調整を行うまでに待機すべき所定時間とに基づき、前記データベースの処理能力を下げるように調整する調整手段と、を有し、前記調整手段は、前記監視手段により監視されるリクエストの量が前記第１基準値を下回った時から前記所定時間よりも長い時間の経過時に前記監視手段により監視されるリクエストの量が該第１基準値を下回っていたことに応じて、前記データベースの処理能力を下げるように調整することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、所定期間中にデータベースの処理性能を下げることのできる上限回数に達した後の、データベースの処理性能を下げることのできない期間を短く抑えることが可能となる。
【図面の簡単な説明】
【００１２】
【図１】システム構成の一例を示す図である。
【図２】情報処理装置のハードウェア構成の一例を示す図である。
【図３】ソフトウェア構成の一例を示す図である。
【図４】スループット更新処理の処理手順の一例を示すフローチャートである。
【図５】スループット引き下げ処理の処理手順の一例を示すフローチャートである。
【図６】スループット引き上げ処理の処理手順の一例を示すフローチャートである。
【図７】一日のスループットおよび監視リクエスト数の推移を示すグラフの例である。
【図８】第１基準値更新処理の処理手順の一例を示すフローチャートである。
【図９】スループット引き上げ処理の処理手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１４】
（実施例１）
図１は、本発明の実施形態に係るシステム構成の一例を示す図である。システム１００は、クラウドサービス上に構築されるシステムであり、アプリケーションサーバー１０１、データベースサーバー１０２、キューサーバー１０３および非同期サーバー１０４などを有する。
【００１５】
システム１００は、クラウドサービスを用いて提供されるプラットフォームやリソースを利用して構築されるシステムであり、本実施例ではファイル管理システムを例に挙げて説明する。ファイル登録リクエストには、ファイルそのものと、ファイルの属性を表すメタデータとが含まれる。ファイル管理システムでは、ファイルをストレージシステム（不図示）に登録し、メタデータをデータベースに登録する。本実施例では、メタデータをデータベースに登録して管理するシステムをデータ管理システムと呼ぶ。
【００１６】
クラウドサービスは、リソースとして、例えばインターネット上のデータセンターに存在するサーバーコンピュータ上で動作する複数の仮想マシンやストレージなどを提供する。複数の仮想マシン上で様々なアプリケーションプログラムを実行することで、システム１００としての様々な管理サービスが実現される。
【００１７】
アプリケーションサーバー１０１は、クライアントコンピュータ（不図示）からファイル登録リクエスト（以降、単にリクエストと呼ぶ。）を受信するアプリケーションが動作する。アプリケーションサーバー１０１上で動作するアプリケーションについては、図３（Ａ）を用いて後述する。
【００１８】
データベースサーバー１０２は、ファイル登録リクエストに含まれるメタデータを保存する。以降、データベース１０２と呼ぶ。アプリケーションサーバー１０１は、ファイルのメタデータをデータベース１０２へ登録する。メタデータとは、ファイルに付随する付加的なデータである。メタデータの内容としては、例えば、ファイルの名前やサイズ、更新日時などがある。
【００１９】
また、データベース１０２には、単位時間あたりに処理可能なリクエスト数であるスループットが設定される。本実施例におけるスループットとは、データベース１０２が１秒間にデータ書き込み可能なリクエスト数を指す。設定されたスループットを実現するためのリソース量をスループット容量と呼ぶ。本実施例のデータ管理システムでは、データサイズが１ＫＢまでのデータ書き込みリクエストを１つのリクエストとして数えることとし、例えば、１．５ＫＢのデータ書き込みリクエストの場合、２つのリクエストとして数える。また、データ読み込みに関するスループットについては、データサイズが４ＫＢまでのデータ読み込みリクエストを１つのリクエストとして数える。なお、スループットを定めるデータサイズの基準はこれらの例以外であってもよい。
【００２０】
システム管理者の指示に従って、アプリケーションサーバー１０１によりスループットの値が設定変更される。また、アプリケーションサーバー１０１は、クライアントコンピュータ（不図示）からのリクエスト監視状況やデータベース１０２の負荷状況に応じて、データベース１０２のスループット容量を動的に変更可能である。なお、スループットは、上述したようなリクエスト数ではなく、１秒間にデータ入出力可能なデータサイズで定義されてもよい。
【００２１】
キューサーバー１０３では、データベースのスループットを超えたリクエストを一時的に溜め置く記憶領域（キュー）が確保されている。以降、キュー１０３と呼ぶ。キュー１０３に溜まったリクエストをメッセージと呼ぶ。メッセージには、データベース１０２に登録される予定のメタデータが含まれる。
【００２２】
非同期サーバー１０４は、キュー１０３のメッセージを取得し、データベース１０２へ再度メタデータを登録するアプリケーションが動作する。非同期サーバー１０４上で動作するアプリケーションについては、図３（Ｂ）を用いて後述する。
【００２３】
アプリケーションサーバー１０１、データベース１０２、キュー１０３および非同期サーバー１０４は、ネットワーク１０５を介して通信可能に接続されている。ネットワーク１０５は、例えば、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などである。
【００２４】
アプリケーションサーバー１０１および非同期サーバー１０４の機能は、１以上の仮想マシン上で実現される。また、データベースサーバー１０２の機能は、ストレージなどによって実現され、キュー１０３の機能は、リソースとしてのキューを用いて実現される。このように、これらの機能はクラウドサービスによって提供されるリソースを用いて実現される。
【００２５】
図２は、本発明の実施形態に係る情報処理装置のハードウェア構成の一例を示す図である。本実施例における情報処理装置としては、システム１００を実現するためのデータセンター上に存在するサーバーコンピュータなどがある。
【００２６】
情報処理装置は、ＲＯＭ２５３に格納されているプログラムを実行するＣＰＵ２５１を備え、内部バス２５６を介して各デバイスを総括的に制御する。内部バス２５６には、ＲＡＭ２５２、ＲＯＭ２５３、記憶装置２５４、ネットワークＩ／Ｆ２５５、入出力Ｉ／Ｆ２５７が接続されている。また入出力Ｉ／Ｆ２５７は、例えばＰＳ／２やＵｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ  Ｉ／Ｆ）、アナログやデジタルのディスプレイＩ／Ｆを備える。入出力Ｉ／Ｆ２５７により、情報処理装置に対して、不図示のキーボードやマウス、ＣＲＴや液晶ディスプレイなどを接続することができる。情報処理装置はネットワークＩ／Ｆ２５５によりＬＡＮ、イントラネット環境、インターネットを介した通信を行う。それにより、情報処理装置は、ネットワークデバイスや、他の情報処理装置と通信を行うことができる。ＣＰＵ２５１は、ＲＡＭ２５２やＲＯＭ２５３と共にプログラムの実行処理を行う。さらに、ＣＰＵ２５１は、仮想化技術を実現するためのプログラムを実行することも可能である。また、ＣＰＵ２５１は、記憶装置２５４等の記録媒体にデータを記録する処理を行う。記憶装置２５４は外部記憶装置として機能し、様々な情報を記憶するほか、ＲＡＭ２５２に代わって、各種システム情報及び処理情報を保存することも可能である。
【００２７】
図３は、本発明の実施形態に係るアプリケーションサーバー１０１および非同期サーバー１０４のソフトウェア構成の一例を示す図である。これらのソフトウェアは、アプリケーションサーバー１０１および非同期サーバー１０４として機能する仮想マシンのＣＰＵ上で動作する。
【００２８】
図３（Ａ）は、アプリケーションサーバー１０１の機能構成の一例を示す図である。本実施例でのアプリケーションサーバー１０１は、監視するリクエスト数に基づいてデータベース１０２の処理能力を示すスループットを調整するなどの機能を備える。
【００２９】
リクエスト受信部３０１は、クライアントコンピュータから送られる、データベース１０２にアクセスする必要のある、ファイル登録リクエストを受信する。
【００３０】
データベース登録部３０２は、リクエスト受信部３０１が受信したリクエストから抽出されたメタデータをデータベース１０２に登録する。
【００３１】
リクエスト監視部３０３は、データベース１０２にアクセスする必要のあるリクエストの単位時間当たりのリクエスト数を監視する。例えば、リクエスト監視部３０３は、単位時間当たりにリクエスト受信部３０１が受信したリクエスト数を監視する。また、リクエスト監視部３０３は、単位時間当たりにデータベース登録部３０２がデータベース１０２に登録するメタデータに係るリクエスト数を監視してもよい。ここでの単位時間とは、スループットの定義に含まれる単位時間と同じである。また、リクエスト監視部３０３は、過去に監視したリクエスト数を過去データとして保存する。
【００３２】
スループット調整部３０４は、スループット更新処理を実行し、スループットを調整する。スループット更新処理には、スループット引き下げ処理とスループット引き上げ処理が含まれる。これらの処理について、図４〜６を用いて後述する。
【００３３】
スループット引き上げ処理とは、システム管理者によって設定されるスループットを実現するためのスループット容量を増やす処理のことである。この処理によってデータベース１０２が１秒間にデータ書き込み可能なリクエスト数が増え、データベース１０２の処理能力が上がる。また、スループット引き下げ処理とは、システム管理者によって設定されるスループットを実現するためのスループット容量を減らす処理のことである。この処理によって、データベース１０２が１秒間にデータ書き込み可能なリクエスト数が減り、データベース１０２の処理能力が下がる。
【００３４】
メッセージ格納部３０５は、リクエスト監視部３０３によって監視されるリクエスト数がスループットを超えた場合、超えた分のリクエストをメッセージとしてキュー１０３に格納する。この処理によって、スループットを超えた分のリクエストは、エラーとならずに、キュー１０３に一時的に記憶された後、データベース１０２で処理されることとなる。なお、監視リクエストの一部を記憶する一時記憶手段としてのメッセージ格納部３０５は、キューではなく、スタックでもよい。
【００３５】
メッセージ数取得部３０６は、キュー１０３に格納されているメッセージの数を取得する。メッセージ数は、後述するスループット引き上げ処理（図６）の際に用いられる。
【００３６】
調整回数管理部３０７は、スループット調整部がスループットを更新した回数を管理する。本実施例では、所定期間（例えば、一日間）中でスループットを引き下げられる回数について、上限回数が設定され、制限が課されている。なお、所定期間は一日の単位ではなく、例えば一週間や一カ月であってもよい。各所定期間の中で、スループットを引き下げられる回数について上限回数が設定されてもよい。また、追加料金なしでスループットを下げる際には上限回数があり、追加料金を払えばその回数以上スループットを下げることができるシステムも存在する。
【００３７】
図３（Ｂ）は、非同期サーバー１０４の機能構成の一例を示す図である。本実施例での非同期サーバー１０４は、キュー１０３に格納されているメッセージをデータベース１０２に登録するなどの機能を備える。
【００３８】
メッセージ取得部３５１は、キュー１０３に格納されているメッセージを取得する。メッセージ取得部３５１は、キュー１０３にメッセージが格納されているかどうかを定期的に確認する。
【００３９】
データベース登録部３５２は、メッセージ取得部３５１が取得したメッセージから抽出されたメタデータをデータベース１０２に登録する。この時、データベース登録部３５２は、メッセージ取得部３５１がメッセージを取得した後、一定時間経ってから、取得したメッセージをデータベース１０２に登録しても良い。
【００４０】
メッセージ格納部３５３は、データベース登録部３５２が登録に失敗したメッセージを再度キュー１０３に登録する。
【００４１】
図４は、本発明の実施形態に係るスループット更新処理の処理手順の一例を示すフローチャートである。この処理は、アプリケーションサーバー１０１がクライアントコンピュータからリクエストを受信した時から定期的に、または、アプリケーションサーバー１０１のスケジュールなどで定められたタイミングで、アプリケーションサーバー１０１によって実行される。
【００４２】
フローチャートの各ステップでは、各処理部がＲＯＭやＨＤＤから読みだしたプログラムをＣＰＵが実行し、処理結果やデータをＲＡＭ、ＲＯＭ、ＨＤＤに保存することでそれぞれの構成間でデータの受け渡しを行う。またネットワークインタフェースカードを用いて、各サーバー間でデータの送受信を行う。なお、以降のフローチャートについても同様である。
【００４３】
スループット調整部３０４は、リクエスト監視部３０３によって監視されている、データベース１０２にアクセスする必要のあるリクエストの単位時間当たりのリクエスト数を確認する（Ｓ４０１）。
【００４４】
次に、スループット調整部３０４は、Ｓ４０１で確認したリクエスト数が、その日のスループット初期値（第１基準値）を下回っているかどうかを判定する（Ｓ４０２）。
【００４５】
Ｓ４０２でリクエスト数が第１基準値を下回っていると判定された場合、スループット調整部３０４は、スループット引き下げ処理を行う（Ｓ４０３）。スループット引き下げ処理では、一定の条件を満たした場合に、スループットは所定の値に更新される。ここでの所定の値とは、例えば、その日のスループット初期値などである。この処理については、図５を用いて後述する。
【００４６】
Ｓ４０２でリクエスト数が第１基準値を下回っていないと判定された場合、さらに、スループット調整部３０４は、Ｓ４０１で確認したリクエスト数が、スループットに対する所定の割合で定められる値（第２基準値）を上回っているかどうかを判定する（Ｓ４０４）。例えば、第２基準値はスループットに対する９０％の値というように定められる。この所定の割合は、システム管理者によって予め設定されてもよい。
【００４７】
Ｓ４０４でリクエスト数が第２基準値を上回っていると判定された場合、スループット調整部３０４は、スループット引き上げ処理を行う（Ｓ４０５）。スループット引き上げ処理では、スループットは、キュー１０３に溜まっているメッセージ数に基づき算出された値に更新される。この処理については、図６を用いて後述する。
【００４８】
なお、Ｓ４０４でリクエスト数が第２基準値を上回っていないと判定された場合、スループット調整部３０４はスループット引き上げ処理（図６）を行わない。
【００４９】
図５は、本発明の実施形態に係るスループット引き下げ処理の処理手順の一例を示すフローチャートである。本処理は、図４のＳ４０２で第１リクエスト数がその日のスループット初期値（第１基準値）を下回っていると判定された場合に、Ｓ４０３で実行される処理である。
【００５０】
スループット調整部３０４は、調整回数管理部３０７よって管理されている、所定期間にスループットが引き下げられた回数を確認する（Ｓ５０１）。
【００５１】
スループット調整部３０４は、所定期間にスループットが引き下げられた回数が、上限回数未満であるかどうかを判定する（Ｓ５０２）。
【００５２】
Ｓ５０２で所定期間にスループットが引き下げられた回数が上限回数未満であると判定された場合、スループット調整部３０４は、待機すべき所定時間を取得する（Ｓ５０３）。待機時間は、監視リクエスト数が第１基準値を下回った時からの所定時間を指す。例えば、以下のような式を用いて、スループット調整部３０４は、上限回数以内のスループットを引き下げる調整において、待機すべき所定時間を算出する。具体的には、所定期間にスループットが引き下げられた回数が多くなるにつれて、待機時間を長めに設定する。例えば、以下のような式を用いて、スループット調整部３０４は、待機時間を算出する。
（待機時間）＝（１回目の待機時間）＋（係数α）×（所定期間にスループットを下げた回数）
１回目の待機時間や係数αは、アプリケーションサーバー１０１で予め設定されてもいいし、システム管理者によって変更されても良い。例えば、１回目の待機時間は０分〜数分とする。待機時間を短くすることで、監視リクエストの減少に伴ってスループットを引き下げることができ、クラウドサービスの利用料金を節約することができる。なお、所定期間内にスループットを下げる調整が適切に行われるようにするために、１回目の待機時間は、最長でも「（所定期間）／（上限回数）」で算出される時間であり、実際には、この算出される時間よりも十分短く設定されるべきである。
【００５３】
また、時間帯によって、待機時間を変えるようにしてもよい。例えば、以下のような式を用いて、スループット調整部３０４は待機時間を算出する。
（待機時間）＝（基本の待機時間）＋Ｔ
基本の待機時間は、上述した１回目の待機時間と同じでもよい。Ｔは、時間帯によって変動する追加時間である。例えば、リクエストの量が多く更に変動が多い時間帯（例えば、日中や業務時間中など）には、Ｔで表される追加時間を長めに設定する。それ以外の時間帯などには、Ｔを短めに設定する。
【００５４】
なお、Ｓ５０２で所定期間にスループットが引き下げられた回数が上限回数に達していると判定された場合、スループット調整部３０４は、スループットを引き下げない。
【００５５】
また、上述したような待機時間は、予めデータベース１０２やアプリケーションサーバー１０１内にＲＯＭ２５３や記憶装置２５４で、テーブルで保持されても良い。その場合は、スループット調整部３０４は、そのテーブルを参照して、待機時間を取得する。
【００５６】
スループット調整部３０４は、すぐにスループットを引き下げるのではなく、所定の待機時間経過後にも尚、監視リクエスト数が第１基準値を下回っている場合に、スループットをその日のスループット初期値に更新する。スループット調整部３０４は所定の待機時間を経過してからスループットを引き下げることで、スループットを引き下げる回数を少なくできる場合がある。これは、特に待機時間中にスループットが増加した場合などに有効である。
【００５７】
スループット調整部３０４は、リクエスト監視部３０３によって監視されている監視リクエスト数を確認する（Ｓ５０４）。
【００５８】
スループット調整部３０４は、Ｓ５０４で確認したリクエスト数が、スループットに対する所定の割合で定められる値（第２基準値）を上回っているかどうかを判定する（Ｓ５０５）。Ｓ５０４で確認した監視リクエスト数が第２基準値を上回っていたら、スループット調整部３０４は、後述する、スループット引き上げ処理（図６）を実行する（Ｓ５０９）。
【００５９】
Ｓ５０４で確認した監視リクエスト数が第２基準値を上回ってない場合、Ｓ５０６で待機時間を経過したと判定されると、スループット調整部３０４は、Ｓ５０４で確認した監視リクエスト数が第１基準値を下回っているかどうかを判定する（Ｓ５０７）。Ｓ５０４で確認した監視リクエスト数が第１基準値を下回っている場合、スループット調整部３０４は、その日のスループット初期値（第１基準値）と同じ値にスループットを更新する（Ｓ５０８）。
【００６０】
Ｓ５０７で監視リクエスト数が第１基準値を上回っていると判定された場合、スループット調整部３０４は、スループットを引き下げずに本処理を終了する。なお、本処理を終了せずに、スループット調整部３０４は、待機時間を延長する処理を行い、延長した待機時間の経過後にスループットを第１基準値に引き下げてもよい。
【００６１】
なお、スループット調整部３０４は、待機時間中、常に監視リクエスト数が第１基準値を下回っていた場合に、スループットを引き下げるようにしてもよい。
【００６２】
図６は、本発明の実施形態に係るスループット引き上げ処理の処理手順の一例を示すフローチャートである。本処理は、図４のＳ４０４で監視リクエスト数がスループットに対する所定の割合で定められる値（第２基準値）を上回っていると判定された場合に、Ｓ４０５で実行される処理である。
【００６３】
スループット調整部３０４は、メッセージ数取得部３０６によって取得される、キュー１０３に格納されているメッセージ数を確認する（Ｓ６０１）。スループットを超えた分のリクエストは、すぐにはデータベース１０２に登録されずに、メッセージとして一旦キュー１０３に格納される。その後、メッセージは、非同期サーバー１０４によってデータベースに登録される。ここの処理では、現在キュー１０３に溜まっているメッセージの数が確認される。
【００６４】
次に、スループット調整部３０４は、調整回数管理部３０７よって管理されている、所定期間にスループットが引き下げられた回数を確認する（Ｓ６０２）。
【００６５】
スループット調整部３０４は、所定期間にスループットが引き下げられた回数が、上限回数未満であるかどうかを判定する（Ｓ６０３）。
【００６６】
Ｓ６０３で所定期間にスループットが引き下げられた回数が上限回数未満であると判定された場合、スループット調整部３０４は、図４で示したＳ４０１の監視されているリクエストの数、および、Ｓ６０１の格納されているメッセージ数に基づいて、新たなスループットを算出する（Ｓ６０４）。
【００６７】
具体的には、スループット調整部３０４は、キュー１０３に積まれているメッセージが多い場合は、スループットを大きく引き上げて、逆にキュー１０３に積まれているメッセージが少ない場合は、スループットをあまり引き上げないようにする。例えば、以下のような式を用いて、スループット調整部３０４は、調整量を算出して新たなスループットを決定する。
（新しいスループット）＝（現在のスループット）＋（スループット最大引き上げ量）−（スループットの下げ幅）／（メッセージ数＋１）
スループット最大引き上げ量は、スループットに対する監視リクエスト数が一定の割合（例えば５０％など）になるようなスループットにする場合の引き上げ量のことである。また、スループットの下げ幅は、アプリケーションサーバー１０１で予め設定されてもいいし、システム管理者によって変更されても良い。
【００６８】
Ｓ６０３で所定期間にスループットが引き下げられた回数が上限回数に達していると判定された場合、スループット調整部３０４は、過去の監視リクエスト数を取得する（Ｓ６０６）。この場合、所定期間にスループットが引き下げられた回数が上限回数に達しているため、スループット調整部３０４は、スループットをあまり引き上げないようにする。そのために、スループット調整部３０４は、Ｓ６０１で確認したメッセージの数に加えて、過去の監視リクエスト数や過去のスループットなどを考慮して新たなスループットを決定する。過去の監視リクエスト数や過去のスループットは、データベース１０２に保持されても良いし、アプリケーションサーバー１０１内にＲＯＭ２５３や記憶装置２５４で保持されても良い。
【００６９】
例えば、以下のような式を用いて、スループット調整部３０４は、新たなスループットを算出する。
（新しいスループット）＝（所定期間の監視リクエスト数の最大値）×０．９
スループット調整部３０４は、Ｓ６０６で取得した過去の監視リクエスト数の平均値を超えないようにして、Ｓ４０１の監視されているリクエストの数に基づいて、スループットを算出する（Ｓ６０７）。なお、スループット調整部３０４は、Ｓ６０１で確認した格納メッセージ数に基づいて、スループットを算出してもよい。例えば、スループット調整部３０４は、所定期間の監視リクエスト数の平均値や所定期間のスループットの平均値を新たなスループットとして算出してもよい。
【００７０】
スループット調整部３０４は、Ｓ６０４またはＳ６０７で算出された値を新たなスループットとして更新する（Ｓ６０５）。
【００７１】
なお、スループット引き下げ処理（図５）における待機時間中に、監視リクエスト数が、スループットに対する所定の割合で定められる値（第２基準値）を上回った場合にも、スループットを引き上げるための処理が実行される。
【００７２】
図７は、一日のスループットおよび監視リクエスト数の推移を示すグラフの例である。縦軸はリクエスト数を表し、横軸は時刻を表す。図７において、横軸の時刻０は、所定期間の始まりの時刻として午前０時を表す。
【００７３】
７０１はスループット、７０２は監視リクエスト数を示す。基本的には、監視リクエスト数の増減に応じてスループットは調整される。
【００７４】
７０３の値は、その日のスループット初期値（第１基準値）である。監視リクエスト数が第１基準値を下回った時から所定の待機時間経過時にも尚、監視リクエスト数が第１基準値を下回っていたら、スループット調整部３０４は、スループットを第１基準値まで引き下げる。
【００７５】
スループット引き下げ処理（図５）での待機時間の一例について説明する。
【００７６】
７０４は３回目にスループットが引き下げられる際の待機時間を示し、１回目や２回目よりも待機時間を長めにとった後、スループットを引き下げられていることがわかる。監視リクエスト数が第１基準値を下回った時、待機時間が開始される。なお、スループット調整部３０４は、１回目と２回目の待機時間を同じにして、３回目の待機時間を１回目より長くするようにしてもよい。
【００７７】
３回目にスループットが引き下げられようとする際に、長めの待機時間をとらずにスループットが引き下げられたとする。すると、７０５で監視リクエスト数が増加してスループットが引き上げられた後、さらに監視リクエスト数が減少した時、スループットは再び引き下げられることになる。これに対して、図７で示すように、７０４の待機時間経過後にスループットが引き下げられることで、スループットを引き下げる回数が１回少なくなる。このように、スループットを引き下げる回数が上限回数に近づくにつれて待機時間を長めにとることで、スループットを引き下げる回数を減らすことができる場合がある。
【００７８】
スループット引き上げ処理（図６）での、スループットを引き下げられる回数が上限回数に達した場合のスループット算出の一例について説明する。
【００７９】
７０６、７０７はスループット引き上げ処理（図６）で算出される新たなスループットを示す。ここでは、スループットを引き下げられる回数の上限回数が４回であるとすると、既に４回スループットは引き下げられているので、スループット調整部３０４は、過去の監視リクエスト数や過去のスループットなどを考慮して算出される値である７０７に引き上げる。監視リクエスト数に応じて算出される値である７０６にスループットが引き上げられる場合と比べて、スループットの引き上げ幅を少なくすることができる。
【００８０】
上述したように、所定時間よりも長い待機時間をとることで、スループットを引き下げることのできる上限回数に達した後に、スループットを引き下げることのできない時間を短く抑えることができる。また、スループットを引き下げる回数の上限回数に近づくにつれて、スループットを引き下げ処理（図５）での待機時間を長く取ることによって、スループットを下げる回数を減らすことができる場合がある。さらに、スループットを引き下げることのできる上限回数に達した後にスループット引き上げ処理を行う場合に、キュー１０３のメッセージ数や過去の監視リクエスト数に基づいて、スループットを適切な値に調整することができる。
【００８１】
（実施例２）
実施例１では、スループット初期値に対して監視リクエスト数の変化に対応させてスループットを更新する処理を行った。数日間、あるいは一か月の間で、１日に受けるリクエスト数が異なる場合があり、本発明は、スループット初期値を固定した値とせず、スループット調整部３０４により可変とする構成であってもよい。本実施例は、スループット初期値である第１基準値を更新する処理を、図８のフローチャートを用いて説明する。なお、第１基準値をその日のスループット初期値以外で定めてもよい。
【００８２】
図８は、第１基準値の更新処理の処理手順の一例を示すフローチャートである。この処理は、１日ごとなど定期的な間隔で、例えば一日の終わり（午前０時０分になる前）に、アプリケーションサーバー１０１によって実行される。１日ごとに本処理が実行された場合には、新たな第１基準値は本処理が実行された日の次の日のスループット初期値として設定されることになる。以下では、本処理が実行されている時刻が属する所定期間を第１の所定期間とし、翌日などその次の所定期間のことを第２の所定期間と呼ぶ。
【００８３】
スループット調整部３０４は、リクエスト監視部３０３によって監視されている監視リクエスト数を、現在から、例えば、過去一日分について確認する（Ｓ８０１）。
【００８４】
なおＳ８０１で確認される対象となる監視リクエスト数は、過去一日分だけではなく、過去一週間分や一か月分などでもよい。さらに、曜日ごとに監視リクエスト数の大小し、例えば月曜は監視リクエスト数が多いから第１基準値を上げる、日曜は監視リクエスト数が少ないから第１基準値を下げるといった判断をしても良い。
【００８５】
スループット調整部３０４は、Ｓ８０１で得られた監視リクエスト数を用いて、新たな第１基準値を算出する（Ｓ８０２）。例えば、スループット調整部３０４は、その日の監視リクエスト数の平均値や同じ曜日の過去の監視リクエスト数の平均値を次の日の第１基準値とする。
【００８６】
Ｓ８０１で得られた監視リクエスト数が多ければ新たな第１基準値は高くなり、少なければ低くなることになる。スループット調整部３０４はＳ８０２で算出した値を新たな第１基準値として記憶する（Ｓ８０３）。Ｓ８０３で記憶した第１基準値は、第２の所定期間（例えば、次の日）のスループット初期値となる。
【００８７】
Ｓ８０４で、Ｓ８０１で確認された現在の監視リクエスト数がＳ８０３で記憶した新たな第１基準値を下回っているかどうかを判定する。新たな第１基準値を下回っていた場合にはＳ８０５に進み、新たな第１基準値を下回っていなかった場合には本処理を終了する。
【００８８】
スループット調整部３０４は、調整回数管理部３０７よって管理されている、第１の所定期間にスループットが引き下げられた回数を確認する（Ｓ８０５）。スループット調整部３０４は、第１の所定期間にスループットが引き下げられた回数が、上限回数未満であるかどうかを判定する（Ｓ８０６）。
【００８９】
Ｓ８０６でスループットを引き下げた回数が上限回数未満である場合、スループット調整部３０４は、Ｓ８０３で記憶した新たな第１基準値を用いて、第１の所定期間内（例えば、０時直前）に、スループット引き下げ処理を実行する。なお、スループット調整部３０４は、図５の処理で用いた待機時間の経過前であっても第１の所定期間内にスループット引き下げ処理を行う。とくに、第１の所定期間の残り時間が該待機時間より短い場合に、この待機時間を待たずにスループット引き下げ処理を行うことで、第１の所定期間におけるスループットを下げることのできる回数を有効に消費することができる。
【００９０】
Ｓ８０６でスループットを引き下げた回数が上限回数未満でない場合、スループット調整部３０４は、Ｓ８０３で記憶した新たな第１基準値を用いて、第２の所定期間に入ってすぐ（例えば、０時直後）に、スループット引き下げ処理実行する。しかし、この場合は、一日のうちでスループットを引き下げられる回数を図５の処理で用いた待機時間を待たずに、１回消費してしまうことになる。そのため、０時後すぐにスループット引き下げ処理実行するかどうかをシステム管理者が設定できるようにしても良い。
【００９１】
上述したように、第１の所定期間内の終わり（例えば、午前０時０分になる前）に、スループット調整部３０４は第１基準値の更新処理を行う。日付が変わるタイミングで第１基準値を設定し直すことで、クラウドサービスの利用料金を抑えつつ、スループットを調整することができる。スループットを引き下げられた回数を考慮して、第１の所定期間内に本実施例の第１基準値更新処理を行うことで、スループットを引き下げられる回数の残りの回数を有効に活用できる場合がある。
【００９２】
（実施例３）
実施例１では、スループット引き上げ処理（図６）において、スループットが引き下げられた回数が上限回数に達した場合、キュー１０３に格納されているメッセージ数および過去の監視リクエスト数から新たなスループットを算出した。しかし、一日の始まりに近い時刻に、スループットを引き下げた回数が上限回数に達した場合には、スループットをあまり引き上げないようにする必要がある。本実施例では、Ｓ６０７のスループット算出において、キュー１０３に格納されているメッセージ数および過去の監視リクエスト数だけでなく、現在時刻も考慮して、新たなスループットを算出する。本実施例のスループット引き上げ処理について、図９のフローチャートを用いて説明する。
【００９３】
図９は、本実施例に係るスループット引き上げ処理の処理手順の一例を示すフローチャートである。図６との差異は、Ｓ９０１が追加されている点である。
【００９４】
スループット調整部３０４は、現在時刻を取得する（Ｓ９０１）。なお、現在時刻ではなく、Ｓ６０１で監視リクエストを取得したタイミングの時刻などでもよい。
【００９５】
スループット調整部３０４は、スループットを引き下げる回数が上限回数に達したあとにスループットを引き上げる場合（Ｓ６０７）に、Ｓ６０１で確認したメッセージの量と、Ｓ６０６で取得した過去の監視リクエスト数だけでなく、Ｓ９０１で取得した時刻も考慮する。スループットを引き下げる回数が上限回数に達したあとにスループットを引き上げようとする時刻が一日の中の早い時刻である場合に、スループット調整部３０４は、スループットを引き上げる量を小さくする。一日の中の早い時刻にスループットを大きく引き上げてしまうと、それ以降その日にスループットを引き下げられずに、長時間に渡って高いスループットに設定されるため高額な料金が発生してしまう。したがって、一日の中の早い時刻にスループットを引き下げられる回数が上限回数に達した場合には、スループット調整部３０４は、スループットをあまり引き上げないようにする。
【００９６】
一方、スループットを引き下げる回数が上限回数に達したあとにスループットを引き上げようとする時刻が一日の中の遅い時刻である場合には、スループットを大きく引き上げるようにしてもよい。
【００９７】
なお、Ｓ６０４でも、スループット調整部３０４は、Ｓ９０１で取得した時刻を考慮して、新たなスループットを算出するようにしてもよい。
【００９８】
上述したように、スループット引き上げ処理において、スループット調整部３０４は、例えば現在時刻などを考慮してスループットを算出するようにする。これにより、スループット調整部３０４は、柔軟にスループット引き上げる量を調整できる。
【符号の説明】
【００９９】
１０１  アプリケーションサーバー
３０３  リクエスト監視部
３０４  スループット調整部
【図１】
2017033142.tif 000003
【図２】
2017033142.tif 000004
【図３】
2017033142.tif 000005
【図４】
2017033142.tif 000006
【図５】
2017033142.tif 000007
【図６】
2017033142.tif 000008
【図７】
2017033142.tif 000009
【図８】
2017033142.tif 000010
【図９】
2017033142.tif 000011