JP2017162059A - 情報処理装置、制御方法、プログラム - Google Patents

Abstract

【課題】本発明の目的は、処理サーバ数を制御可能なシステムにおいて、負荷状況に応じて適切なタイミングで処理サーバ数を変更制御することを可能にする仕組みを提供することである。【解決手段】メッセージキューに滞留している処理すべきメッセージの数を取得し、当該メッセージ数がスケールアウト第一閾値を上回り、メッセージの増加数が所定数を上回る場合、または、当該メッセージ数がスケールアウト第二閾値を上回る場合はスケールアウトを実行する。また、当該メッセージ数がスケールイン第一閾値を下回り、メッセージの減少数が所定数を上回る場合、または、当該メッセージ数がスケールイン第二閾値を下回る場合はスケールインを実行する。【選択図】図３

Description

本発明は、処理要求の状況に応じて処理サーバの起動数を制御する技術に関する。

近年、情報システムに対する予測できないアクセス数の増大に対応するため、計算資源を柔軟に利用できるクラウド環境上に、システムを構築するケースが増えている。クラウド事業者が提供するクラウド環境上では、仮想化されたサーバを従量課金で利用できるため、柔軟なサーバ運用が可能である。例えば、システムへの処理要求が増大したら、新規にサーバを立ち上げて処理能力を高めて対応（スケールアウト）したり、処理要求が減少した時に、サーバを廃棄（スケールイン）して利用料金を削減したりできる。さらに、システムの負荷状況を監視して、自動で仮想サーバを増減する機能（オートスケーリング）を提供するクラウドがある。

オートスケーリングは、メッセージ処理システム１００において、負荷状況に応じてバックエンドサーバを迅速に増減する手段として利用されることがある。メッセージ処理システム１００は、システムへの処理要求を非同期で処理するシステム形態で、リアルタイムに応答できない時間のかかる処理で利用されることが多い。利用者から処理要求を受け付けると、処理要求をメッセージとしてキューに保管し、利用者には処理要求を受け付けたことを通知する。その後、バックエンドサーバが、キューからメッセージを取り出して処理を実行し、利用者へ完了通知する。

メッセージ処理システム１００では、メッセージに関わる処理を早く完了した方が利用者の満足度向上につながる一方、そのために、どの程度の計算資源をバックエンドサーバに割り当てるのかが課題となる。キュー内に多数のメッセージが滞留される場合は、それに応じた複数の仮想サーバを用意して、並列処理することで対応する。一方、事前に予測できないキュー滞留数の増減への対応には、クラウド上のオートスケーリング機能が有効である。例えば、キュー滞留数が事前設定した閾値を超えた際に自動で仮想サーバを増やすことで、滞留数の増大に対応できる。また、キュー滞留数が事前設定した閾値を下回った際に自動で仮想サーバを減らすことで、利用料金を削減できる。

オートスケーリングは、キュー滞留数の閾値によって仮想サーバの増減を行うため、キュー滞留数が短時間の間に増減を繰り返すとスケールアウトやスケールインを繰り返し、処理オーバーヘッドが増加し処理効率が悪くなる問題がある。例えば、キュー滞留数がスケールアウト閾値を超えたため、仮想サーバを増やしたとする。その後、処理要求の増加傾向が伸び悩んだため、キュー滞留数が減少し、スケールイン閾値を下回ると、増やした仮想サーバをすぐに減らすことになってしまう。

特許文献１では、このような問題に、負荷傾向に応じてスケールアウト／スケールインの閾値を動的に変更することで対応する。負荷が下降傾向ならば積極的にスケールインを実施するためにスケールイン／スケールアウトの可否判断のための閾値（スケールイン／スケールアウト閾値）を高く変更し、負荷が上昇傾向ならばスケールインを遅らせるために当該閾値を低く変更する。

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

しかしながら、特許文献１のように、負荷傾向に応じてスケールイン／スケールアウト閾値を変更すると、適切な負荷状況でスケールアウトおよびスケールインを実行しない可能性がある。

例えば負荷が徐々に上昇していく場合、スケールイン／スケールアウト閾値を繰り返し低く変更することになるため、負荷が必要以上に低い状況でスケールアウトを実施する可能性がある。

逆に、負荷が徐々に下降していく場合、スケールイン／スケールアウト閾値を繰り返し高く変更することになるため、負荷が上昇傾向に転じた時にスケールアウトのタイミングが遅れる可能性がある。

また、負荷が負荷が徐々に下降していく場合、スケールイン／スケールアウト閾値を繰り返し高く変更することになるため、負荷が必要以上に高い状況でスケールインを実施する可能性があり、その後負荷が上昇傾向に転じたならば再度スケールアウトの必要が生じることが想定される。

逆に、負荷が徐々に上昇していく場合、スケールイン／スケールアウト閾値を繰り返し低く変更することになるため、負荷が下降傾向に転じた時にスケールインのタイミングが遅れる可能性がある。

一般的に負荷状況については許容範囲が存在し、その許容範囲は特許文献１のように負荷の変動傾向で決まるものではない。つまり、スケールイン／スケールアウトの可否判断のためには、スケールイン／スケールアウトを即時実行しなければ問題が発生する「必須領域」、スケールイン／スケールアウトを状況によって実行してもよい「可能領域」が存在し、それぞれハードウェアの性能や、各仮想サーバに割り当てられるリソースによって決まる。

つまり、負荷がスケールイン必須領域で継続した場合はリソースの無駄な消費につながり、負荷がスケールアウト必須領域で継続した場合はシステム全体の性能低下を引き起こす危険性がある。

また、負荷がスケールイン可能領域にある場合でも、負荷の上昇が予測される場合はスケールインを実施したとしてもすぐにスケールアウトしなければならない可能性が高く、一方、急激な下降が予測される場合は即時にスケールインを実施した方がリソースの無駄な消費を抑えられる。また、負荷がスケールアウト可能領域にある場合でも、負荷の下降が予測される場合はスケールアウトを実施したとしてもすぐにスケールインしなければならない可能性が高く、一方、急激な上昇が予測される場合は即時にスケールアウトを実施した方がシステム全体の性能低下のリスクを軽減できる。

そこで、本発明の目的は、処理サーバ数を制御可能なシステムにおいて、負荷状況に応じて適切なタイミングで処理サーバ数を変更制御することを可能にする仕組みを提供することである。

本発明の情報処理装置は、起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能な情報処理装置であって、前記記憶装置に格納された前記処理要求の数を取得する取得手段と、前記処理要求の数に関して、複数の範囲に分ける閾値を記憶する閾値記憶手段と、前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示手段と、を備えることを特徴とする。

本発明の制御方法は、起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能であり、前記処理要求の数に関する閾値を記憶する閾値記憶手段を備える情報処理装置の制御方法であって、取得手段が、前記記憶装置に格納された前記処理要求の数を取得する取得ステップと、指示手段が、前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示ステップと、を備えることを特徴とする。

本発明のプログラムは、起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能な情報処理装置において実行可能なプログラムであって、前記情報処理装置を、前記記憶装置に格納された前記処理要求の数を取得する取得手段と、前記処理要求の数に関して、複数の範囲に分ける閾値を記憶する閾値記憶手段と、前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示手段、として機能させることを特徴とする。

本発明によれば、処理サーバ数を制御可能なシステムにおいて、負荷状況に応じて適切なタイミングで処理サーバ数を変更制御することができるようになる。

本発明の実施形態であるメッセージ処理システムのシステム構成の一例を示すブロック図である。 本発明の実施形態であるメッセージ処理システムの情報処理装置に適用可能なハードウェア構成の一例を示すブロック図である。 本発明の実施形態であるメッセージ処理システムの機能構成の一例を示すブロック図である。 本発明の実施形態であるメッセージ処理システムのメッセージ送信手順の一例を示すフローチャートである。 本発明の実施形態であるメッセージ処理システムのメッセージ処理の一例を示すフローチャートである。 本発明の実施形態であるメッセージ処理システムのオートスケーリング処理の一例を示すフローチャートである。 本発明の実施形態であるメッセージ処理システムにて使用するテーブルの一例を示すデータ構成図である。 本発明の実施形態であるメッセージ処理システムのオートスケーリング設定画面の画面イメージ。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。 本発明の実施形態であるメッセージ処理システムのキュー滞留数監視画面の表示例を示す画面イメージ。

以下、図面を参照して、本発明の実施形態を詳細に説明する。

図１は、本発明のメッセージ処理システムの構成の一例を示すシステム構成図である。

クライアント１０１は、スマートデバイスやデスクトップなどのパーソナルコンピュータやＷｅｂアプリケーションサーバを想定し、利用者へ画面を表示したり、利用者からの操作を受け付けたり、バックエンドに処理要求を送信したりする。なお、Ｗｅｂアプリケーションサーバの場合、同一もしくは異なるクラウド上に配置することも可能である。

メッセージキューサーバ１０２は、クライアント１０１から送信されたメッセージをキューに入れて管理するサーバである。なお、メッセージキューサーバ１０２として、ＡＷＳ（登録商標；Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（登録商標））のＳＱＳ（登録商標；Ａｍａｚｏｎ Ｓｉｍｐｌｅ Ｑｕｅｕｅ Ｓｅｒｖｉｃｅ（登録商標））のような、クラウド事業者が提供するメッセージキューサービスを利用することも可能である。

負荷監視サーバ１０３は、メッセージキューサーバ１０２のキュー滞留数を監視し、必要に応じてスケールアウト／スケールインを実行することで、システム全体のメッセージ処理能力を調整する。

バックエンドサーバ１０４は、メッセージに関する処理を実行する物理サーバであり、バックエンドサーバ１０４が保有するＣＰＵ、メモリ等のリソースを分割して複数の仮想サーバ１０５に割り当てることにより、それぞれの仮想サーバ１０５に並列して処理を実行させることが可能となる。

仮想サーバ１０５は、バックエンドサーバ１０４の上で仮想的に起動されるサーバ群である。本実施形態においては、それぞれの仮想サーバ１０５がメッセージに関する処理を分担し、並列してメッセージを処理する。仮想サーバ１０５を１台起動すると、バックエンドサーバ１０４のリソースの一部を固定的に占有するため、必要最小限の仮想サーバ数を決めることが重要である。また、クラウド事業者が提供するサーバを利用する場合には、起動する仮想サーバ数に応じて課金されるため、仮想サーバ数の削減は運用コストの削減につながる。しかし仮想サーバ数を減らし過ぎると十分な処理性能が得られず、最悪の場合、システム全体のダウンにつながる危険性もあり、過不足のない適正な仮想サーバ数の決定が必須である

ネットワーク１０６は、各サーバおよびクライアントを通信可能に接続する。同一企業内であればＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）にて、企業間やクラウド事業者のサーバと接続する場合はインターネットにて実現される。

以下、図２を参照して、図１に示したメッセージキューサーバ１０２と負荷監視サーバ１０３、バックエンドサーバ１０４、仮想サーバ１０５（バックエンドサーバ１０４の一部）に適用可能な情報処理装置のハードウェア構成について説明する。

２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２０７には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２０７からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

２０５はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク）等の外部メモリ２０７へのアクセスを制御する。

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

本発明を実現するための後述する各種プログラムは、外部メモリ２０７に記録されており、必要に応じてＲＡＭ２０２にロードされることにより、ＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２０７に格納されており、これらについての詳細な説明も後述する。

以下、図３を参照して、メッセージ処理システム１００における機能構成の一例について説明する。

図３は、図１に示したクライアント１０１とメッセージキューサーバ１０２、負荷監視サーバ１０３、バックエンドサーバ１０４、仮想サーバ１０５の機能構成の一例を示すブロック図である。

クライアント１０１は、クライアントアプリケーション３０１を有する。

クライアントアプリケーション３０１は、利用者から処理要求を受け付け、処理内容に応じたメッセージを作成して、メッセージキューサーバ１０２のメッセージキュー３０２に送信する。

メッセージキューサーバ１０２は、メッセージキュー３０２を有する。

メッセージキュー３０２は、クライアント１０１のクライアントアプリケーション３０１からメッセージを受信し、外部メモリに蓄積し、仮想サーバ１０５のサーバアプリケーション３０６に対してメッセージを順次供給し、仮想サーバ１０５のサーバアプリケーション３０６からの要求に従いメッセージを削除する。

負荷監視サーバ１０３は、負荷監視部３０３、サーバ数制御部３０４を持つ。

負荷監視部３０３は、メッセージキューサーバ１０２のメッセージキュー３０２にて処理待ち状態で滞留しているメッセージ数（キュー滞留数）を定期的または不定期に取得することにより、メッセージ処理における負荷状況を監視する。なお、本実施例ではキュー滞留数を取得しているが、メッセージキュー３０２に蓄積される処理が必要なメッセージ数を取得して負荷状況として監視してもよい。

サーバ数制御部３０４は、負荷監視部３０３により取得した負荷状況に基づいてスケールアウトおよびスケールインの実行を決定し、バックエンドサーバ１０４のサーバ仮想化部３０５にスケールアウトおよびスケールインの実行を指示する。

バックエンドサーバ１０４は、サーバ仮想化部３０５を持つ。

サーバ仮想化部３０５は、バックエンドサーバ１０４が保有するＣＰＵ、メモリ等のリソースを分割し、仮想サーバ１０５に割り当てる。負荷監視サーバ１０３のサーバ数制御部３０４からスケールアウトの実行指示があった場合は、新たな仮想サーバ１０５を起動しリソースを割り当て、一方、スケールインの実行指示があった場合は、削減する仮想サーバを決定し、当該仮想サーバに割り当てられていたリソースを解放する。

仮想サーバ１０５はサーバアプリケーション３０６を持つ。

サーバアプリケーション３０６は、メッセージキューサーバ１０２のメッセージキュー３０２から未処理の最も古いメッセージを取得し、メッセージに応じた処理を実行し、処理が終了すればメッセージキュー３０２に対して当該メッセージの削除要求を送信する。１つのメッセージの処理が終了すると、再びメッセージキュー３０２から未処理の最古のメッセージを取得し処理を実行する。複数の仮想サーバ１０５が起動している場合には、それぞれの仮想サーバ１０５が並列して自律的にメッセージキュー３０２からメッセージを取得して処理を実行し、メッセージキュー３０２にメッセージがなくなるまで繰り返す。

以下、図４から図６のフローチャートを参照して、本実施形態のメッセージ処理システム１００における各処理フローについて説明する。

図４は、本実施形態のメッセージ処理システム１００のメッセージ送信処理の一例を示すフローチャートである。

ステップＳ４０１では、利用者から処理要求を受け付けたクライアントアプリケーション３０１が、処理要求を表す文字列と処理完了時の利用者通知先（メールアドレス）を含むメッセージを作成して、作成したメッセージをメッセージキュー３０２に送信する。その後、利用者に対して、処理要求の受付完了を示す画面を表示する。

ステップＳ４０２では、メッセージキュー３０２が、クライアントアプリケーション３０１からのメッセージを受信する。そして、メッセージを管理するため、受信したメッセージに一意に識別可能なＩＤを付与する。

ステップＳ４０３では、ステップＳ４０２で受信したメッセージを、メッセージキューサーバ１０２上のメモリやディスク、またはクラウド上の別のストレージに保管する。メッセージの保管形式としては、例えば、後述する図７のメッセージキューテーブルにメッセージＩＤとメッセージ文字列、処理完了時の利用者通知先を保管する。なお、メッセージキューテーブルのレコードは処理待ちメッセージを表し、レコード数はキューの滞留数（処理待ちメッセージ数）を表す。

図５は、本実施形態のメッセージ処理システム１００におけるメッセージ処理の一例を示すフローチャートである。

ステップＳ５０１では、サーバアプリケーション３０６が、利用者からの処理要求に対するバックエンド処理を実行するため、メッセージキュー３０２からメッセージを取り出す。

ステップＳ５０２では、ステップＳ５０１で取り出したメッセージに関する処理を実行する。処理を完了したら、要求元の利用者に処理が完了したことをメールで通知する。

ステップＳ５０３では、ステップＳ５０２で処理を完了したメッセージを削除するため、該メッセージのＩＤを、メッセージキュー３０２に送信する。

ステップＳ５０４は、メッセージキュー３０２が、受信したメッセージＩＤに該当するメッセージを、メッセージキューテーブルから削除する。

図６は、本実施形態のメッセージ処理システム１００におけるオートスケーリング処理の一例を示すフローチャートである。

ステップＳ６０１では、負荷監視部３０３が、現在のキュー滞留数として、メッセージキュー３０２が管理するメッセージキューテーブルのレコード数（メッセージ数）を取得する。取得したメッセージ数は、後述する図７のキュー滞留数履歴テーブルに、取得した時刻と共に登録する。キュー滞留数履歴テーブルにある情報を用いて、後述するキュー滞留数推移画面を描画することができる。

ステップＳ６０２では、まずスケールアウトする負荷状況か否かを判定するために、ステップＳ６０１で取得したメッセージ数とスケールアウト第一閾値とを比較する。スケールアウト第一閾値は、キュー滞留数がスケールアウト要否検査領域にあるか否かを判定する閾値である。スケールアウト要否検査領域とは、比較的高い位置にあるキュー滞留数に対して、処理能力を増強するスケールアウト要否を検査する領域である。つまり、スケールアウト要否検査領域は状況によってスケールアウトしてもよいスケールアウト可能領域を示す。スケールアウト第一閾値を上回らない場合は、スケールアウト要否検査領域に入らないので、スケールアウト要否を判定せず、次のステップＳ６０６に移動する。

スケールアウト第一閾値を上回る場合は、ステップＳ６０３でさらにスケールアウト第二閾値と比較する。スケールアウト第二閾値は、キュー滞留数がシステムの許容範囲を超えたスケールアウト実行領域にあるか否かを表す閾値である。利用者への処理完了通知の著しい遅延を防止するため、スケールアウト実行領域に入ると、条件を問わず即時スケールアウトを実行する（ステップＳ６０５）。つまり、スケールアウト実行領域は、即時スケールアウトする必要のあるスケールアウト必須領域を示す。一方、スケールアウト第二閾値を上回らない場合は、条件によってスケールアウトするか否か判定するスケールアウト要否検査領域にあることが確定し、ステップＳ６０４でスケールアウト要否を検査する。

ステップＳ６０４では、メッセージ増加数（傾き）が所定の値を上回る場合は、スケールアウトを実行する（ステップＳ６０５）。所定の値は、後述する図８のオートスケーリング設定画面から設定することが可能である。本実施形態の例としては、１分あたりのメッセージ増加数が１０を上回るとスケールアウトを実行する。所定の値については、他に、仮想サーバ１台による１分あたりのメッセージ処理数（平均数）を設定することも考えられる。また、メッセージ増加数（傾き）だけでなく、仮想サーバのＣＰＵやメモリ等の各種負荷状況を勘案しても良い。

ステップＳ６０６では、スケールインする負荷状況か否かを判定するために、ステップＳ６０１で取得したメッセージ数とスケールイン第一閾値とを比較する。スケールイン第一閾値は、キュー滞留数がスケールイン要否検査領域にあるか否かを判定する閾値である。スケールイン要否検査領域とは、比較的低い位置にあるキュー滞留数に対して、コストを削減するためのスケールイン要否を検査する領域である。つまり、スケールイン要否検査領域は状況によってスケールインしてもよいスケールイン可能領域を示す。スケールイン第一閾値を上回らない場合は、スケールイン要否検査領域に入らないので、スケールイン要否を判定せず、オートスケーリング処理を終了する。

スケールイン第一閾値を下回る場合は、ステップＳ６０７でさらにスケールイン第二閾値と比較する。スケールイン第二閾値は、キュー滞留数がスケールイン実行領域にあるか否かを表す閾値である。スケールイン実行領域に入ると、コスト削減のため、条件を問わず即時スケールインを実施する（ステップＳ６０９）。つまり、スケールイン実行領域は、即時スケールインする必要のあるスケールイン必須領域を示す。一方、スケールイン第二閾値を下回らない場合は、条件によってスケールインするか否か判定するスケールイン要否検査領域にあることが確定し、ステップＳ６０８でスケールイン要否を検査する。

ステップＳ６０８では、メッセージ減少数（傾き）が所定の値を上回る場合は、スケールインを実行する（ステップＳ６０９）。所定の値は、後述する図８のオートスケーリング設定画面から設定することが可能である。本実施形態の例としては、１分あたりのメッセージ減少数が１０を上回るとスケールインを実行する。所定の値については、他に、仮想サーバ１台による１分あたりのメッセージ処理数（平均数）を設定することも考えられる。また、メッセージ減少数（傾き）だけでなく、仮想サーバのＣＰＵやメモリ等の各種負荷状況を勘案しても良い。

図７は、本実施形態のメッセージ処理システム１００におけるメッセージキューテーブルと閾値テーブル、キュー滞留数履歴テーブルの一例を示すデータ構成図である。

図７（ａ）にメッセージキューテーブルのデータ構成の一例を示す。

メッセージキューテーブルは、メッセージＩＤとメッセージ本体、利用者通知先（メールアドレス）等の情報から構成される。メッセージＩＤは、メッセージを識別するための識別子である。メッセージ本体は、クライアントアプリケーション３０１がバックエンドで処理を実行するサーバアプリケーション３０６に、処理要求内容を伝達するための文字列である。利用者通知先は、メッセージに関わる処理が完了した後に通知する利用者のメールアドレスである。

図７（ｂ）に閾値テーブルのデータ構成の一例を示す。

閾値テーブルは、設定項目と閾値等の情報から構成される。設定項目は、スケールアウトやスケールインに関わる各種設定項目名である。閾値は、スケールアウトやスケールインに関わる各種閾値の現在の設定値である。後述する図８のオートスケーリング設定画面から設定することが可能である。

図７（ｃ）にキュー滞留数履歴テーブルのデータ構成の一例を示す。

キュー滞留数履歴テーブルは、メッセージ数と時刻等の情報から構成される。メッセージ数は、メッセージキュー３０２のメッセージ数である。時刻は、メッセージ数を取得した時刻である。

図８は、本実施形態のメッセージ処理システム１００におけるオートスケーリング設定画面を示す。

スケールアウト設定として、スケールアウト第一閾値（メッセージ数）８０１とスケールアウト第一閾値を上回った際にスケールアウトするメッセージ増加数（１分あたりのメッセージ増加数）８０２、スケールアウト第二閾値（メッセージ数）８０３を設定する。

スケールイン設定として、スケールイン第一閾値（メッセージ数）８０４とスケールイン第一閾値を上回った際にスケールインするメッセージ増加数（１分あたりのメッセージ増加数）８０５、スケールイン第二閾値（メッセージ数）８０６を設定する。

設定内容を確定する場合は、設定完了ボタン８０７を押下することにより、図７（ｂ）の閾値テーブルに設定値が記録される。設定内容をキャンセルする場合は、キャンセルボタン８０８を押下することにより、図７（ｂ）の閾値テーブルに設定値が記録されることなくオートスケーリング設定画面を表示終了する。

以下、図９から図１４を参照して、本実施形態のメッセージ処理システム１００によるキュー滞留数の推移イメージを示す。キュー滞留数の推移状況は、負荷監視サーバ１０３に実装可能なキュー滞留数監視画面にて確認することができる。キュー滞留数監視画面は、図９に示すように、横軸に時間、縦軸にキュー滞留数を取り、キュー滞留数の時間変化を曲線または折れ線で表示する。またキュー滞留数監視画面には、図９に示すように、図８のオートスケーリング設定画面にて設定した項目を画面上に表示する。スケールアウト第一閾値８０１、スケールアウト第二閾値８０３、スケールイン第一閾値８０４、スケールイン第二閾値８０６はそれぞれの設定値に従って実線の直線９０１、９０３、９０４、９０６で表示される。スケールアウトするメッセージ増加数８０２、スケールインするメッセージ減少数８０５はそれぞれの設定値（傾き）に従って破線の矢印９０２、９０５で表示される。以下同様である。

図９は、本実施形態のメッセージ処理システム１００において、スケールアウト第一閾値を上回りスケールアウトを実行したときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

状況９０８では、スケールアウト第一閾値８０１を上回り、スケールアウトするメッセージ増加数８０２を上回ったためスケールアウトを実行指示している。スケールアウト実行指示後は、実際にスケールアウトが完了するまでしばらく時間が経過した後、システム処理能力が向上したため、キュー滞留数が低下している。

図１０は、本実施形態のメッセージ処理システム１００において、スケールアウト第一閾値を上回るがスケールアウトを実行しなかったときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

推移状況１００１では、スケールアウト第一閾値を上回るが、スケールアウトするメッセージ増加数８０２を下回っていたためスケールアウトを実行していない。キュー滞留数は、スケールアウトを実施しないため、大きく変化せずに推移している。

図１１は、本実施形態のメッセージ処理システム１００において、スケールアウト第二閾値を上回りスケールアウトを実行したときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

状況１１０１では、スケールアウト第二閾値８０３を上回ったため、条件を問わずスケールアウトを実行指示している。スケールアウト実行指示後は、実際にスケールアウトが完了するまでしばらく時間が経過した後、システム処理能力が向上したため、キュー滞留数が低下している。

図１２は、本実施形態のメッセージ処理システム１００において、スケールイン第一閾値を下回りスケールインを実行したときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

状況１２０１では、スケールイン第一閾値８０４を下回り、スケールインするメッセージ減少数８０５を上回ったためスケールインを実行指示している。スケールイン実行指示後は、実際にスケールインが完了するまでしばらく時間が経過した後、システム処理能力が低下したため、キュー滞留数が上昇している。

図１３は、本実施形態のメッセージ処理システム１００において、スケールイン第一閾値を下回るがスケールインを実行しなかったときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

推移状況１３０１では、スケールイン第一閾値を下回るが、スケールインするメッセージ減少数を下回っていたためスケールインを実行していない。キュー滞留数は、スケールインを実施しないため、大きな変化せずに推移している。

図１４は、本実施形態のメッセージ処理システム１００において、スケールイン第二閾値を下回りスケールインを実行したときのキュー滞留数推移の一例を表すキュー滞留数監視画面の画面イメージである。

状況１４０１では、スケールイン第二閾値を下回ったため、条件を問わずスケールインを実行指示している。スケールイン実行指示後は、実際にスケールインが完了するまでしばらく時間が経過した後、システム処理能力が低下したため、キュー滞留数が上昇している。

上記の通り、本実施形態のメッセージ処理システム１００において、キュー滞留数の状況、つまり負荷状況に応じて適切なタイミングでスケールアウトおよびスケールインを実行することができ、負荷過多による性能低下や障害の事前予防、および、リソースの無駄な使用によるコスト削減を実現することができる。

なお、本実施例では物理サーバ上で起動される仮想サーバを処理主体（処理サーバ）としてその起動数を制御しているが、複数の物理サーバが存在し、その起動数を制御可能な場合には、物理サーバを処理主体（処理サーバ）としてその起動数を制御するようにしてもよい。つまり、スケールアウトは物理サーバの起動数を増加させること、スケールインは物理サーバの起動数を減少させることになる。

以上、各実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、各処理方法をコンピュータが実行可能（読み取り可能）なプログラムであり、本発明の記憶媒体は、各処理方法をコンピュータが実行可能なプログラムが記憶されている。

なお、本発明におけるプログラムは、各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読取り実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

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

１００ メッセージ処理システム
１０１ クライアント
１０２ メッセージキューサーバ
１０３ 負荷監視サーバ
１０４ バックエンドサーバ
１０５ 仮想サーバ
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ メモリコントローラ
２０６ 通信Ｉ／Ｆコントローラ
２０７ 外部メモリ

Claims (9)

1. 起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能な情報処理装置であって、
   前記記憶装置に格納された前記処理要求の数を取得する取得手段と、
   前記処理要求の数に関して、複数の範囲に分ける閾値を記憶する閾値記憶手段と、
   前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示手段と、
   を備えることを特徴とする情報処理装置。
2. 前記閾値記憶手段は、前記処理要求の数に関する第１の閾値と、更に、前記処理要求の数の時間的増加に関する閾値とを記憶し、
   前記指示手段は、前記取得された前記処理要求の数が前記第１の閾値で分けられる範囲にある場合、前記処理要求の時間的増加数が前記時間的増加に関する閾値以上であれば、前記処理サーバの起動数の増加を指示する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記閾値記憶手段は、前記処理要求の数に関する第２の閾値を記憶し、
   前記指示手段は、前記取得された前記処理要求の数が前記第２の閾値で分けられる範囲にある場合、前記処理サーバの起動数の増加を指示する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記閾値記憶手段は、前記処理要求の数に関する第３の閾値と、更に、前記処理要求の数の時間的減少に関する閾値とを記憶し、
   前記指示手段は、前記取得された前記処理要求の数が前記第３の閾値で分けられる範囲にある場合、前記処理要求の時間的減少数が前記時間的減少に関する閾値以上であれば、前記処理サーバの起動数の減少を指示する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記閾値記憶手段は、前記処理要求の数に関する第４の閾値を記憶し、
   前記指示手段は、前記取得された前記処理要求の数が前記第４の閾値で分けられる範囲にある場合、前記処理サーバの起動数の減少を指示する
   ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記記憶装置に格納された前記処理要求の数の時間的変化を表示装置に表示させる表示制御手段
   を備えることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記表示制御手段は、前記閾値記憶手段に記憶されたそれぞれの閾値を認識可能に表示させる
   ことを特徴とする請求項６に記載の情報処理装置。
8. 起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能であり、前記処理要求の数に関する閾値を記憶する閾値記憶手段を備える情報処理装置の制御方法であって、
   取得手段が、前記記憶装置に格納された前記処理要求の数を取得する取得ステップと、
   指示手段が、前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示ステップと、
   を備えることを特徴とする情報処理装置の制御方法。
9. 起動数の増減制御が可能な複数の処理サーバと、前記処理サーバにて処理される処理要求を記憶する記憶装置とにネットワークを介して通信可能な情報処理装置において実行可能なプログラムであって、
   前記情報処理装置を、
   前記記憶装置に格納された前記処理要求の数を取得する取得手段と、
   前記処理要求の数に関して、複数の範囲に分ける閾値を記憶する閾値記憶手段と、
   前記取得された前記処理要求の数が、前記閾値にて分けられる第１の範囲にある場合は、前記処理要求の増減状況に応じて前記処理サーバの起動数の増減を指示し、一方、前記閾値にて分けられる第２の範囲にある場合は、前記処理要求の増減状況に関わらず前記処理サーバの起動数の増減を指示する指示手段、
   として機能させることを特徴とするプログラム。
   

Images