JP2018120374A - 情報処理システム、及び制御方法 - Google Patents

Abstract

【課題】 複数のアプリケーションが配置される仮想マシンで異常が検知された際に、システムに影響を与えることなく、その仮想マシンを削除可能とするための仕組みを提供する。【解決手段】 複数のアプリケーションが配置される仮想マシンと、前記仮想マシンを管理する管理サーバーとを含む情報処理システムであって、前記仮想マシンに配置される各アプリケーションは、前記情報処理システムで管理される設定に基づき、メッセージを格納する格納領域からメッセージを取得し、前記管理サーバーは、前記設定を、前記各アプリケーションによるメッセージの取得を停止させるための設定に変更する。前記アプリケーションいずれかの異常が検知された場合、前記各アプリケーションは、前記変更された設定に基づきメッセージの取得を停止し、かつ、前記変更前に取得したメッセージに基づく処理を完了させる。【選択図】 図１

Description

本発明は、キューから取得したメッセージに基づく処理を実行する情報処理システム、及び制御方法に関する。

近年、インターネット上にあるサーバーで動作する各種アプリケーションを利用することができるサービスとして、クラウドサービスがある。ＩａａＳやＰａａＳなどのクラウドサービスでは、クラウドサービスベンダーが、ネットワークを介して、仮想マシンやストレージなどのリソースをシステム管理者に提供する。仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、分割されたそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピューターである。システム管理者は、クラウドサービスベンダーによって提供される仮想マシンやストレージなどのリソースを用いて、独自のサービスを提供するためのシステムを構築することができる。

クラウドサービスを用いて構築されるシステムは、データを並列的に処理するためにメッセージキュー（以降、キューと呼ぶ）が利用されることがある。キューには、処理対象のデータに対応するメッセージが格納される。このメッセージを処理する機能を備える仮想マシンは、キューに格納されるメッセージを取得し、メッセージに記述された処理内容に従って処理を実行する。このように、複数の仮想マシンが、キューから取得したメッセージを処理することで、データの並列処理が可能となる。

上述したシステムを運用するためには、仮想マシンにおいて異常が発生した際、システムの運用に影響を与えないようにその仮想マシンを削除することが求められる。特許文献１に記載の実行システムでは、ジョブ実行サーバーが、１つのジョブ実行コマンドに対応する複数のプロセスの処理を順次実行する。ジョブ実行サーバー内のプロセス実行部がプロセスの処理を開始してから一定時間経過後にもなお処理完了の応答がなければ、ジョブ実行サーバーは、プロセスの処理が異常であると判断し、プロセス実行部による処理を終了させる。その後、プロセス実行サーバーは消滅することとなる。

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

上述したキューを利用したシステムでは、キューからメッセージを取得して、そのメッセージに基づく処理を実行するアプリケーションが少なくとも１つ、仮想マシンに配置される。ここで、複数のアプリケーションが配置される仮想マシンにおいて１つのアプリケーションで異常が発生した際に、そのアプリケーションを停止させたとしても、他のアプリケーションが更にメッセージを取得してしまう。すると、他のアプリケーションが取得したメッセージを処理している最中は、その仮想マシンを削除することができないといった問題が発生する。仮に、他のアプリケーションが処理をしている最中の仮想マシンを削除した場合、メッセージに基づく処理が中断されてしまい、システムに影響を与えるおそれがある。

本発明は、複数のアプリケーションが配置される仮想マシンで異常が検知された際に、システムに影響を与えることなく、その仮想マシンを削除可能とするための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、複数のアプリケーションが配置される仮想マシンと、前記仮想マシンを管理する管理サーバーとを含む情報処理システムであって、前記仮想マシンに配置される各アプリケーションは、前記情報処理システムで管理される設定に基づき、メッセージを格納する格納領域からメッセージを取得し、前記管理サーバーは、前記情報処理システム内で管理される設定を、前記仮想マシンに配置される各アプリケーションによるメッセージの取得を停止させるための設定に変更する設定手段を有し、前記仮想マシンに配置されるアプリケーションいずれかの異常が検知された場合、前記各アプリケーションは、前記設定手段により変更された設定に基づきメッセージの取得を停止し、かつ、前記設定手段による変更前に取得したメッセージに基づく処理を完了させることを特徴とする。

本発明によれば、複数のアプリケーションが配置される仮想マシンで異常が検知された際に、システムに影響を与えることなく、その仮想マシンを削除可能とすることができる。

本発明の実施形態におけるシステムの全体構成を示す模式図 情報処理装置の内部構成の一例を示す図 本発明の実施形態におけるサーバーの機能構成の一例を示す図 メッセージ実行処理の手順例を示すフローチャート メッセージ実行アプリケーション３１０のログファイルの一例を示す図 ログ監視処理の手順例を示すフローチャート 異常通知受信処理の手順例を示すフローチャート 実施例２におけるシステムの全体構成を示す模式図 実施例２におけるサーバーの機能構成の一例を示す図 実施例２おけるログ監視処理の手順例を示すフローチャート 実施例３におけるサーバーの機能構成の一例を示す図 実施例３におけるメッセージ実行処理の手順例を示すフローチャート 実施例３における異常通知受信処理の手順例を示すフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

（実施例１）
＜システム構成＞
図１は、本発明の実施形態におけるシステムの全体構成を示す模式図である。

図１において、情報処理システム１０１は、クラウドサービスベンダーによって提供される仮想マシンやストレージなどのリソースを用いて構築される。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、分割されたそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピューターである。情報処理システム１０１は、Ｗｅｂサーバー１０３、スケジューラー１０４、メッセージ登録サーバー１０５、キュー１０６、メッセージ実行サーバー１０７を含む。さらに、情報処理システム１０１は、システム管理サーバー１０８、オートスケール管理サーバー１０９を含む。

情報端末１０２は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などであり、情報処理システム１０１が提供するサービスを利用するユーザーが使用する端末である。ユーザーは、情報処理システム１０１が提供するＷｅｂページを通して、情報処理システム１０１に処理の実行指示をする。

Ｗｅｂサーバー１０３は、ユーザーがサービスを利用するためのＷｅｂページを提供する、１台以上の仮想マシンである。Ｗｅｂサーバー１０３は、Ｗｅｂページを通してユーザーからの処理の実行指示を受信する。そして、指示された処理を実行するためのメッセージの登録要求を、メッセージ登録サーバー１０５に送信する。

スケジューラー１０４は、定期処理の実行指示をする。定期処理とは、情報処理システム内で管理するデータの定期集計処理などである。スケジューラー１０４は、予め設定された定期処理の実行時刻になると、定期処理を実行するためのメッセージをキュー１０６に送信する。

メッセージ登録サーバー１０５は、メッセージを作成してキュー１０６に登録する、１台以上の仮想マシンである。メッセージ登録サーバー１０５は、Ｗｅｂサーバー１０３からメッセージ登録要求を受信すると、メッセージを作成し、作成したメッセージをキュー１０６に登録する。

キュー１０６は、メッセージ登録サーバー１０５によって登録されたメッセージを格納する格納領域である。キュー１０６は、メッセージが登録された際に遅延時間が経過するまでメッセージを不可視状態にする。さらに、キュー１０６は、メッセージが取得された際に不可視時間が経過するまでメッセージを不可視状態にする。

メッセージ実行サーバー１０７は、キュー１０６に登録されたメッセージを取得し、メッセージで指示された処理を実行する、１台以上の仮想マシンである。メッセージ実行サーバー１０７は、後述するメッセージ実行アプリケーション３１０が複数配置される。ここで、メッセージ実行サーバー１０７は、後述するオートスケール管理サーバー１０９においてオートスケールの対象となっており、ＣＰＵの使用率やキュー１０６に格納されているメッセージの数などに応じ、台数を増減するように構成される。

ここで、本実施例では、情報処理システムが実行する処理の種類ごとにキュー１０６が用意されるものとする。例えば、データの集計処理を実行するためのメッセージを登録するキュー１０６と、メール送信を実行するためのメッセージを登録するキュー１０６は、別のキューとする。なお、処理の種類ごとに適当な単位でメッセージをグループ化して一つのキューを使用するように構成しても良い。

システム管理サーバー１０８は、情報処理システム１０１の状況に応じて、システム管理者へのメール通知や、仮想マシンの削除などの各種処理を実行する。また、システム管理サーバー１０８は、システム管理者の指示に基づき情報処理システム１０１のメンテナンス等を行う。

オートスケール管理サーバー１０９は、情報処理システム１０１におけるオートスケール対象の仮想マシンの数を管理する。ここで、オートスケールとは、仮想マシンの処理負荷などに応じて、仮想マシンの台数や仮想マシンに対するＣＰＵなどの割り当てを自動で調整する機能のことを指す。オートスケール管理サーバー１０９は、システム管理者が設定した条件に合致する場合に、オートスケール対象となる仮想マシンの数を増減させる。例えば、オートスケール管理サーバー１０９は、Ｗｅｂサーバー１０３にリクエストを転送するロードバランサ（不図示）が受け付けるリクエストの量に応じて、Ｗｅｂサーバー１０３の台数を調整する。オートスケール管理サーバー１０９は、メッセージ登録サーバー１０５の台数も同様に調整する。また、オートスケール管理サーバー１０９は、ＣＰＵの使用率やキュー１０６に格納されているメッセージの数などに応じて、メッセージ実行サーバー１０７の台数を調整する。また、オートスケール管理サーバー１０９は、オートスケール対象となる仮想マシンの最少の起動台数などを管理する。仮想マシンが削除された場合など、オートスケール管理サーバー１０９は、新たな仮想マシンを起動させて、最少の起動台数を保つようにする。

ここで、Ｗｅｂサーバー１０３で異常が発生した場合、そのＷｅｂサーバー１０３をオートスケールの対象から除外することで、そのＷｅｂサーバー１０３に対してロードバランサ（不図示）はリクエストを転送しないようになる。結果として、そのＷｅｂサーバー１０３はリクエストを受け付けなくなるため、Ｗｅｂサーバー１０３の削除や、Ｗｅｂサーバー１０３で発生した異常の原因調査などを行うことができる。一方で、メッセージ実行サーバー１０７で異常が発生した場合、そのメッセージ実行サーバー１０７をオートスケールの対象から除外したとしても、そのメッセージ実行サーバー１０７はキュー１０６からメッセージを取得して処理をしてしまう。したがって、メッセージ実行サーバー１０７の削除や、メッセージ実行サーバー１０７で発生した異常の原因調査などを行うための工夫が必要となる。

なお、図１に示した情報端末１０２乃至オートスケール管理サーバー１０９の各部は、インターネットなどの既知の技術により相互に通信可能に接続されている。

＜情報処理装置の内部構成＞
図２は、情報処理装置の内部構成の一例を示す図である。本実施例における情報処理装置としては、情報端末１０２や、情報処理システム１０１内の各構成としての機能をもつ仮想マシンが動作するサーバーコンピュータなどが該当する。

情報処理装置は、記憶装置であるハードディスクドライブ（ＨＤＤ）２１０に記憶されたソフトウェアを実行するＣＰＵ２０１を備える。ＣＰＵ２０１はシステムバス２０４に接続される各ハードウェアを総括的に制御する。

メモリー２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。ネットワークインターフェースカード（ＮＩＣ）２０３は、ネットワークを介して、他のノードと双方向にデータをやりとりする。

キーボードコントローラー２０５は、ＰＣに備えられたキーボード２０６からの指示入力を制御する。なお、情報処理装置の役割によっては、キーボードコントローラー２０５、キーボード２０６がない構成でも良い。

ディスプレイコントローラー２０７は、例えば液晶ディスプレイなどで構成される表示モジュール２０８の表示を制御する。なお、情報処理装置の役割によっては、ディスプレイコントローラー２０７、表示モジュール２０８がない構成でも良い。ディスクコントローラー２０９は、大容量記憶装置であるハードディスクドライブ（ＨＤＤ）２１０を制御する。

＜メッセージ実行サーバーの機能構成＞
図３（Ａ）は、メッセージ実行サーバー１０７の機能構成の一例を示す図である。メッセージ実行サーバー１０７では、監視エージェントアプリケーション３００と複数のメッセージ実行アプリケーション３１０が動作する。複数のメッセージ実行アプリケーション３１０は、それぞれ処理するメッセージの種類が異なり別のキュー１０６からメッセージを取得して実行する。例えば、あるメッセージ実行アプリケーション３１０はデータの集計処理を行い、別のメッセージ実行アプリケーション３１０はメール送信を行う。これらの各アプリケーションの機能は、メッセージ実行サーバー１０７が構築されるサーバーコンピュータのＨＤＤ２１０に記憶されているプログラムを、ＣＰＵ２０１がメモリー２０２に読み出して実行することによって実現される。

ここで、メッセージ実行サーバー１０７に、１つのメッセージ実行アプリケーション３１０が配置される場合を考える。そのメッセージ実行アプリケーション３１０で異常が発生した際に、そのアプリケーションを停止させれば、その仮想マシンが更にメッセージを取得することはないため、その仮想マシンを削除することができる。一方、メッセージ実行サーバー１０７に、複数のメッセージ実行アプリケーション３１０が配置されている場合を考える。その一部のメッセージ実行アプリケーション３１０で異常が発生する場合、異常が発生したアプリケーションのみを停止させたとしても、他のアプリケーションがメッセージを取得してしまう。そのため、他のアプリケーションがメッセージを処理している最中には、情報処理システム１０１に影響を与えずにその仮想マシンを削除することが不可能となる。そこで、この課題を解決するために、複数のアプリケーションが配置される仮想マシンで異常が検知された際に、複数のアプリケーションいずれも更にメッセージを取得することを防ぐための仕組みを、後述する図４、図６、図７などを用いて説明する。

監視エージェントアプリケーション３００は、ログ監視部３０１と通知部３０２で構成される。ログ監視部３０１は、システム管理サーバー１０８から、後述する表Ｂからログ監視条件を取得し、そのログ監視条件に合致するかログを監視するモジュールである。すなわち、ログ監視部３０１は、メッセージ実行アプリケーション３１０の異常の有無を監視する。通知部３０２は、ログ監視部３０１からの要求に応じて、システム管理サーバー１０８に通知を行うモジュールである。

メッセージ実行アプリケーション３１０は、メッセージ取得部３１１、メッセージ実行部３１２、メッセージ削除部３１３、オートスケール確認部３１４で構成される。メッセージ取得部３１１は、キュー１０６に登録されたメッセージを取得するモジュールである。メッセージ実行部３１２は、メッセージ取得後に、メッセージで指示された処理を実行するモジュールである。メッセージ削除部３１３は、メッセージの処理実行後に、実行したメッセージをキュー１０６から削除するモジュールである。オートスケール確認部３１４は、メッセージ実行アプリケーション３１０が動作しているメッセージ実行サーバー１０７がオートスケール設定に紐づいているかを確認するモジュールである。メッセージ実行処理の詳細については、後述する図４を用いて説明する。

＜システム管理サーバーの機能構成＞
図３（Ｂ）は、システム管理サーバー１０８の機能構成の一例を示す図である。システム管理サーバー１０８では、監視サーバーアプリケーション３２０が動作する。監視サーバーアプリケーション３２０の機能は、システム管理サーバー１０８が構築されるサーバーコンピュータのＨＤＤ２１０に記憶されているプログラムを、ＣＰＵ２０１がメモリー２０２に読み出して実行することによって実現される。

監視サーバーアプリケーション３２０は、サーバー管理部３２１、処理実行部３２２で構成される。サーバー管理部３２１は、メッセージ実行サーバー１０７が正常に動作しているかを管理するモジュールである。メッセージ実行サーバー１０７に異常が発生した場合、サーバー管理部３２１は、処理実行部３２２に異常が発生したメッセージ実行サーバー１０７をオートスケールの対象から外すなどの処理を指示する。処理実行部３２２は、サーバー管理部３２１からの指示を受けて、オートスケール管理サーバー１０９に対して、異常が発生したメッセージ実行サーバー１０７をオートスケールの対象から外す要求を行う等の各種処理を行うモジュールである。データ格納部３２３は、表Ａから表Ｄを用いて後述するテーブルを管理するモジュールである。

＜オートスケール管理サーバーの機能構成＞
図３（Ｃ）は、オートスケール管理サーバー１０９の機能構成の一例を示す図である。オートスケール管理サーバー１０９では、オートスケール管理アプリケーション３５０が動作する。オートスケール管理アプリケーション３５０の機能は、オートスケール管理サーバー１０９が構築されるサーバーコンピュータのＨＤＤ２１０に記憶されているプログラムをＣＰＵ２０１がメモリー２０２に読み出して実行することで実現される。

オートスケール管理アプリケーション３５０は、リソース監視部３５１、オートスケール管理部３５２、オートスケール実行部３５３で構成される。リソース監視部３５１は、オートスケール対象の各サーバーの状態を監視するモジュールである。リソース監視部３５１は表Ｅで後述するリソース監視条件に基づいて、各サーバーを監視する。リソース監視条件に合致した場合、オートスケール管理部３５２に通知する。オートスケール管理部３５２は、オートスケールの対象を管理するモジュールである。

オートスケール管理部３５２は、表Ｆを用いて後述するオートスケール設定に基づいてオートスケール対象の各サーバーの数を管理する。オートスケール管理部３５２は、オートスケール対象のサーバーが落ちてしまったような場合にはオートスケール設定のサーバーの数を保つように、新たなサーバーを起動するようにオートスケール実行部３５３に指示する。オートスケール実行部３５３は、オートスケール管理部３５２の指示を受けて、サーバーを起動したり、削除したりするモジュールである。データ格納部３５４は、表Ｅおよび表Ｆを用いて後述するテーブルを管理するモジュールである。

＜システム管理サーバーが管理するテーブル＞
表１から表４はシステム管理サーバー１０８が管理するテーブルの一例であり、システム管理サーバー１０８のデータ格納部３２３に保存する。

表Ａは、サーバー管理テーブルである。本テーブルは、表Ｆを用いて後述するオートスケール設定を一意に識別するためのスケールＩＤを格納するカラムを備える。本テーブルは、メッセージ実行サーバー１０７を一意に識別するためのサーバーＩＤを格納するカラムを備える。本テーブルは、サーバーＩＤで識別されるメッセージ実行サーバー１０７上で動作するアプリケーションのアプリケーション名を格納するカラムを備える。アプリケーションの処理は、データ集計の処理、メール送信の処理、ファイルエクスポートの処理などである。本テーブルは、アプリケーションのログの出力状況を示すログ状況を格納するカラムを備える。サーバー管理テーブルにより、どのオートスケール設定に紐づいたどのメッセージ実行サーバー１０７のどのアプリケーションのログが正常に出力されているのか、停止しているのかがわかる。

表Ｂは、ログ監視条件テーブルである。本テーブルは、監視エージェントアプリケーション３００を一意に識別するためのエージェントＩＤを格納するカラムを備える。本テーブルは、監視エージェントアプリケーション３００が監視するアプリケーション名を格納するカラムを備える。本テーブルは、監視エージェントアプリケーション３００が監視すべきログファイルパスを格納するカラムを備える。本テーブルは、ログファイルの更新がどの程度行われていなかった場合に、監視エージェントアプリケーション３００が異常と判断するかを示す更新停止時間を格納するカラムを備える。

表Ｃは、処理管理テーブルである。本テーブルは、オートスケール設定を一意に識別するためのスケールＩＤを格納するカラムを備える。本テーブルは、システム管理サーバー１０８の監視サーバーアプリケーション３２０が実行する処理を格納するカラムを備える。本テーブルは、実行する処理がメール通知だった場合に通知先を示すメールアドレスを格納するカラム備える。処理管理テーブルでは、スケールＩＤで示されるオートスケール設定に紐づくメッセージ実行サーバー１０７で稼働するアプリケーションのログが停止した場合に実行する処理が何であるかを管理する。システム管理サーバー１０８の監視サーバーアプリケーション３２０の本処理については、図７を用いて後述する。

表Ｄは、メッセージ管理テーブルである。本テーブルは、オートスケール設定を一意に識別するためのスケールＩＤを格納するカラムを備える。本テーブルは、メッセージ実行サーバー１０７などのサーバーを一意に識別するためのサーバーＩＤを格納するカラムを備える。本テーブルは、ログの出力が停止したアプリケーション名を格納するカラムを備える。本テーブルは、ログの出力が停止した時に処理していたメッセージの識別情報であるメッセージＩＤを格納するカラムを備える。メッセージ管理テーブルにより、どのメッセージを処理しているときにログの出力が停止したのかがわかる。

＜オートスケール管理サーバーが管理するテーブル＞
表５、表６はオートスケール管理サーバー１０９が管理するテーブルの一例であり、オートスケール管理サーバー１０９のデータ格納部３５４に保存する。

表Ｅはリソース監視条件テーブルである。リソース監視条件テーブルは、オートスケール管理アプリケーション３５０のリソース監視部３５１が監視するリソースや監視した結果を格納する。本テーブルは、リソース監視条件を一意に識別するための監視条件ＩＤを格納するカラムを備える。本テーブルは、オートスケール設定を一意に識別するためのスケールＩＤを格納するカラムを備える。本テーブルは、監視する項目を示す監視項目を格納するカラムを備える。本テーブルは、オートスケール実行が必要な測定値であるか示す測定値の閾値を格納するカラムを備える。本テーブルは、監視した結果、測定値の閾値を超えた状態が連続して何回測定されたかを示す継続回数を格納するカラムを備える。本テーブルは、継続回数が何回に達した場合にオートスケールを行うかを示す回数の閾値を格納するカラムを備える。例えば、最初のレコードはスケールＩＤが「Ａ００１」であるオートスケール設定に紐づくサーバーのＣＰＵ使用率を監視すること示している。そして、最初のレコードは、定期的に監視した結果、ＣＰＵ使用率が８０パーセントを超える状態が３回継続して測定された場合にスケールアウトすることを示している。また、最初のレコードは、現在継続して測定値の閾値を超えて測定された回数は１回であることを示している。

表Ｆは、オートスケール設定管理テーブルである。オートスケール設定管理テーブルは、１つのレコードが１つのオートスケール設定を表している。本テーブルでは、オートスケール管理アプリケーション３５０のオートスケール管理部３５２が管理するサーバーの数などが示される。オートスケール設定管理テーブルは、オートスケール設定を一意に識別するためのスケールＩＤを格納するカラムを備える。本テーブルは、オートスケール設定に紐づくサーバーが最低何台起動していないといけないかを示す最少台数を格納するカラムを備える。本テーブルは、オートスケール設定に紐づくサーバーが現在何台必要かを示すカラムを備える。本テーブルは、現在起動しているサーバーのサーバーＩＤを示す起動サーバーを格納するカラムを備える。起動サーバーのカラムに格納されているサーバーがオートスケール対象となる。本テーブルは、オートスケール設定に紐づくサーバーが多くても何台までかを示す最多台数を格納するカラムを備える。前述した表Ｅのリソース監視条件テーブルで示された条件に合致すると必要台数が増減する。これにより、オートスケール管理部３５２がサーバーの削除や新たなサーバーを起動する。そのため、起動サーバーのカラムに格納されるサーバーＩＤの数も増減する。

＜メッセージ実行処理＞
図４は、メッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０が実行するメッセージ実行処理の手順例を示すフローチャートである。本処理は、メッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０がキュー１０６に登録されているメッセージを確認し、取得可能なメッセージがある際に実行される処理である。

Ｓ４０１で、オートスケール確認部３１４は、オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０からメッセージ実行サーバー１０７が紐づいているオートスケール設定を取得し、Ｓ４０２に遷移する。

Ｓ４０２で、オートスケール確認部３１４は、Ｓ４０１で取得したオートスケール設定を確認して、メッセージ実行アプリケーション３１０が動作するメッセージ実行サーバー１０７がオートスケール設定に紐づいているかを判断する。オートスケール設定に紐づいている場合はＳ４０３に遷移する。オートスケール設定に紐づいていない場合は、メッセージ実行サーバー１０７が要停止状態であると判断されて、メッセージ取得部３１１がキュー１０６からメッセージを取得することなく、本フローチャートの処理を終了する。処理を終了するとログが出力されなくなる。すると、監視エージェントアプリケーション３００によりログが停止していると判断され、システム管理サーバー１０８の監視サーバーアプリケーション３２０により、メッセージ実行アプリケーション３１０の処理が停止したことが伝わる。これらのシステム管理サーバー１０８の監視サーバーアプリケーション３２０の処理については、後述する図７を用いて説明する。

Ｓ４０３で、メッセージ取得部３１１は、キュー１０６からメッセージを取得する旨をログに出力してＳ４０４に遷移する。Ｓ４０４でメッセージ取得部３１１は、キュー１０６からメッセージを１つ取得して、Ｓ４０５に遷移する。Ｓ４０５でメッセージ取得部３１１は、Ｓ４０４でメッセージが取得できたかを確認する。メッセージを取得できた場合は、Ｓ４０６に遷移する。メッセージが取得できなかった場合は、Ｓ４０１に遷移する。

なお、本実施例ではメッセージを取得する前に、必ずＳ４０１、Ｓ４０２の処理を実行しているが、オートスケール管理サーバー１０９の負荷を考慮して、メッセージの取得が規定回数行われる毎に、Ｓ４０１、Ｓ４０２の処理を実行するようにしてもよい。また、同様に本実施例ではメッセージを取得する前に、Ｓ４０３で必ずログを出力しているが、ログファイルのサイズを考慮してメッセージの取得が規定回数行われる毎に、Ｓ４０３の処理を実行するようにしてもよい。

Ｓ４０６で、メッセージ実行部３１２は、取得したメッセージの識別情報を含めた、メッセージの処理開始を示すログを出力し、Ｓ４０７に遷移する。尚、出力したログについては、後述する図５を用いて説明する。

Ｓ４０７で、メッセージ実行部３１２は、Ｓ４０４で取得したメッセージで指示された処理を実行してＳ４０８に遷移する。メッセージ実行部３１２は、メッセージの処理実行中にも定期的にログを出力する。尚、前述したようにメッセージ実行サーバー１０７では複数のメッセージ実行アプリケーション３１０が動作する。そのためＳ４０７で実行される処理は異なる。例えば、あるメッセージ実行アプリケーション３１０はデータの集計処理を行い、別のメッセージ実行アプリケーション３１０はメール送信を行う。尚、本実施例では、メッセージ取得前に、メッセージ実行サーバー１０７がオートスケール設定に紐づいているかを確認している。さらに、Ｓ４０７のメッセージの処理の実行中にも定期的にＳ４０１、Ｓ４０２の処理を行うようにし、オートスケール設定に紐づいていない場合には処理の中断、メッセージの再登録を行い、処理を終了するように構成してもよい。このようにすることで、データ集計など時間がかかる処理を実行していたとしても、すぐにメッセージ実行サーバー１０７が要停止状態であることを確認でき、より早くメッセージ実行サーバー１０７を停止状態にすることができる。

Ｓ４０８で、メッセージ実行部３１２は、メッセージの処理終了を示すログを出力し、Ｓ４０９に遷移する。Ｓ４０９で、メッセージ削除部３１３は、キュー１０６からＳ４０４で取得したメッセージを削除して、Ｓ４０１に遷移する。

＜メッセージ実行アプリケーションのログ＞
図５は、メッセージ実行アプリケーション３１０のログファイルの一例を示した図である。ログファイル５００は、データ集計のメッセージを処理するメッセージ実行アプリケーション３１０が出力したログである。

ログ５０１、および、ログ５０２は、上述した図４で示すフローチャート中のＳ４０３の処理で出力されたログである。ログ５０３は、Ｓ４０６の処理で出力されたログである。メッセージＩＤが「１０００００３」であるメッセージの処理を開始したことを示している。ログ５０４は、Ｓ４０７のメッセージの処理実行中に出力されるログを示している。ログ５０５は、Ｓ４０８の処理で出力されたログであり、メッセージの処理が終了したことを示している。尚、本実施例ではログ５０５にメッセージＩＤを出力していないが、ログ５０５にメッセージＩＤを出力するように構成してもよい。メッセージの処理中にデッドロックのようなことが発生してしまった場合は、ログ５０３が出力された後にログ５０５が出力されないため、ログ５０３に含まれるメッセージＩＤを基に、処理中に問題の発生したメッセージを特定できる。

＜ログ監視処理＞
図６は、メッセージ実行サーバー１０７の監視エージェントアプリケーション３００が実行するログ監視処理の手順例を示すフローチャートである。本処理は、メッセージ実行サーバー１０７の監視エージェントアプリケーション３００が、ログ監視条件に従ってログの監視を実行する処理である。

Ｓ６０１で、ログ監視部３０１は、監視エージェントアプリケーション３００のログ監視条件を、システム管理サーバー１０８の監視サーバーアプリケーション３２０から取得して、Ｓ６０２に遷移する。システム管理サーバー１０８の監視サーバーアプリケーション３２０は、ログ監視部３０１のリクエストに含まれるエージェントＩＤを基に表Ｂで説明したログ監視条件テーブルからログ監視条件を取得して返却する。

Ｓ６０２で、ログ監視部３０１は、取得した監視条件が監視の終了を示しているかを判断する。監視の終了である場合は、処理を終了する。監視の終了でない場合はＳ６０３に遷移する。

Ｓ６０３は、繰り返しの処理開始を表しており、Ｓ６０７が繰り返しの処理終了を表している。Ｓ６０７の処理に移ったときに、取得したログ監視条件の数だけＳ６０４からＳ６０６の処理を実行していた場合は、Ｓ６０１に遷移する。

Ｓ６０４で、ログ監視部３０１は、現在日時と、ログ監視条件に含まれるログファイルパスにあるログファイルの更新日時の差分がログ監視条件に含まれる基準時間（所定時間）を超えていないかを判断する。所定時間を超えている場合は、異常が発生したと判断して、Ｓ６０５に遷移する。所定時間内である場合は、Ｓ６０７に遷移する。

Ｓ６０５で、ログ監視部３０１は、ログファイルから処理が完了していないメッセージのメッセージＩＤを取得してＳ６０６に遷移する。処理が完了していないメッセージは、先に説明したようにログ５０３が出力され、ログ５０５が出力されないことで判断する。

Ｓ６０６で、通知部３０２は、システム管理サーバー１０８の監視サーバーアプリケーション３２０に、Ｓ６０４で異常を検知したメッセージ実行アプリケーション３１０に異常が発生したことを通知して、Ｓ６０７に遷移する。尚、Ｓ６０６での通知にはＳ６０５で取得したメッセージＩＤを含める。

＜異常通知受信処理＞
図７は、システム管理サーバー１０８の監視サーバーアプリケーション３２０が実行する異常通知受信処理の手順例を示すフローチャートである。本処理は、Ｓ６０６で処理されたメッセージ実行サーバー１０７の監視エージェントアプリケーション３００の通知を監視サーバーアプリケーション３２０が受信したときに実行する処理である。

Ｓ７０１で、サーバー管理部３２１は、サーバー管理テーブル（表Ａ）のログ状況のカラムを「停止」に変更してＳ７０２に遷移する。尚、停止に変更するのは、異常を通知した監視エージェントアプリケーション３００が動作するメッセージ実行サーバー１０７のログの更新が停止したアプリケーションのレコードである。

Ｓ７０２で、サーバー管理部３２１は、サーバー管理テーブルを確認し、通知を受信したメッセージ実行サーバー１０７で動作するメッセージ実行アプリケーション３１０の中で最初にログが停止したアプリケーションであるかを判断する。最初にログが停止したメッセージ実行アプリケーション３１０であった場合は、Ｓ７０３に遷移する。最初にログが停止したメッセージ実行アプリケーション３１０でなかった場合は、Ｓ７０８に遷移する。

Ｓ７０３で、処理実行部３２２は、ログの出力が停止したメッセージ実行アプリケーション３１０が動作するメッセージ実行サーバー１０７に紐づいたオートスケール設定の最少台数と必要台数を１台追加してＳ７０４に遷移する。具体的には、処理実行部３２２は、オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０にオートスケール設定の最少台数と必要台数を１台追加するリクエストを行う。オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０から完了のレスポンスを受信してＳ７０４に遷移する。

Ｓ７０４で、処理実行部３２２は、ログの出力が停止したメッセージ実行アプリケーション３１０が動作するメッセージ実行サーバー１０７をオートスケール対象から外してＳ７０５に遷移する。具体的には、処理実行部３２２は、オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０にメッセージ実行サーバー１０７のサーバーＩＤを含めてオートスケールの対象から外すリクエストを行う。尚、このリクエストには最少台数を１台減らすリクエストも含める。オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０から完了のレスポンスを受信してＳ７０５に遷移する。

Ｓ７０４の処理でログの出力が停止したメッセージ実行アプリケーション３１０が動作するメッセージ実行サーバー１０７をオートスケール対象から外す前に、Ｓ７０３においてオートスケール設定を変更してメッセージ実行サーバー１０７を１台追加した。オートスケールの対象からメッセージ実行サーバー１０７が外れた場合、オートスケール管理サーバー１０９のオートスケール管理アプリケーション３５０は最少台数を保つためにメッセージ実行サーバー１０７を新たに起動する。しかし、起動が完了するまでにはある程度時間がかかるため、その間稼働中の情報処理システム１０１は１台少ない状態でメッセージを処理することとなる。そのため、Ｓ７０３の処理で予め１台増やしておくことで稼働中の情報処理システム１０１に影響を与えずに済むようになる。尚、本実施例では必ずＳ７０３の処理を行っているが、例えば、キュー１０６のメッセージ数を確認して、メッセージが閾値以上の場合にだけＳ７０３の処理を実行するように構成してもよい。

Ｓ７０５で、サーバー管理部３２１は、受信した通知に含まれるメッセージＩＤ等をメッセージ管理テーブルに格納してＳ７０６に遷移する。Ｓ７０６で、サーバー管理部３２１は、受信した通知に含まれるメッセージＩＤがメッセージ管理テーブルに複数含まれるかを判断する。メッセージＩＤが複数含まれる場合は、Ｓ７０７に遷移する。メッセージＩＤが複数含まれない場合はＳ７０８に遷移する。

Ｓ７０７で、処理実行部３２２は、受信した通知に含まれるメッセージＩＤのメッセージをキュー１０６から削除し、Ｓ７０８に遷移する。前述したようにメッセージの不可視時間が経過すると、他のメッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０が、同一メッセージをキュー１０６から取得できるようになる。デッドロックのような状態に陥る原因がメッセージの内容にあった場合、他のメッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０でもログの出力が停止し、繰り返し問題が発生し続けることになる。Ｓ７０７の処理でメッセージを削除することによって繰り返し問題が発生し続けることを回避することができる。

Ｓ７０８で、サーバー管理部３２１は、サーバー管理テーブル（表Ａ）を参照し、メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０のログの出力が停止したかを判断する。メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０のログの出力が停止した場合、メッセージ実行サーバー１０７が停止状態になったと判断して、Ｓ７０９に遷移する。すなわち、ここでは全てのメッセージ実行アプリケーション３１０が、メッセージの取得を停止し、かつ、Ｓ７０１での設定の変更前に取得したメッセージに基づく処理が完了していることが確認される。メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０のログの出力が停止していない場合は処理を終了する。

Ｓ７０９で、処理実行部３２２は、処理管理テーブル（表Ｃ）を参照して、所定の処理を実行して終了する。なお、Ｓ７０９では、所定の処理として複数の処理が実行されても良い。所定の処理は、処理管理テーブルにおいて、停止状態となったメッセージ実行サーバー１０７が紐づいていたオートスケール設定のスケールＩＤで特定される処理を実行する。

なお、Ｓ７０８で、サーバー管理部３２１は、異常が発生したアプリケーション以外のアプリケーションによる処理が完了したことを示すログを確認して、Ｓ７０９に遷移しても良い。

以上、本実施例では、システム管理サーバーは、メッセージ実行サーバーにおけるいずれかのメッセージ実行アプリケーションで異常が発生した場合に、そのメッセージ実行サーバーをオートスケールの対象から除外した。メッセージ実行サーバーは、オートスケールの対象から除外されたことを確認した際に、キューからメッセージを取得することを停止する。本実施例によれば、メッセージ実行サーバーがキューからメッセージを取得しなくなるため、メッセージ実行サーバーの削除や原因調査を行うことができる。

（実施例２）
実施例１においては、メッセージ実行サーバー１０７に監視エージェントアプリケーション３００を配置してログファイルの監視を行った。実施例２においては、メッセージ実行サーバー１０７に監視エージェントアプリケーション３００を配置しない例について記載する。実施例２においては、実施例１と異なる部分のみ説明する。

＜システム構成＞
図８は、実施例２におけるシステムの全体構成を示す模式図である。

図１と異なるのは、ストレージサービス８０１が追加されている点である。ストレージサービス８０１は、ファイルを管理するサービスである。ディレクトリの作成、削除、ファイルの登録、取得、削除などの機能を有する。ストレージサービス８０１は、本実施例ではメッセージ実行アプリケーション３１０のログファイルを格納する。ストレージサービス８０１に格納されるログファイルは、システム管理サーバー１０８やメッセージ実行サーバー１０７からアクセスが可能なように構成する。

＜メッセージ実行サーバーの機能構成＞
図９（Ａ）は、実施例２におけるメッセージ実行サーバー１０７の機能構成の一例を示す図である。図３（Ａ）と異なるのは監視エージェントアプリケーション３００がない点である。

＜システム管理サーバーの機能構成＞
図９（Ｂ）は、実施例２におけるシステム管理サーバー１０８の機能構成の一例を示す図である。図３（Ｂ）と異なるのはログ監視部９０１が追加となった点である。

ログ監視部９０１は、後述する表Ｇを用いて説明するログ監視条件テーブルからログ監視条件を取得し、そのログ監視条件に合致するかログを監視するモジュールである。

＜システム管理サーバーが管理するテーブル＞
システム管理サーバー１０８が管理するテーブルで実施例１と異なるのは、ログ監視条件テーブルである。

表Ｇは、実施例２におけるログ監視条件テーブルである。実施例１のログ監視テーブルである表Ｂと異なるのは、エージェントＩＤのカラムがサーバーＩＤのカラムに変更になっている点である。またログファイルパスに格納されるログのファイルパスが、ストレージサービス８０１となっている点が実施例１と異なる。システム管理サーバー１０８のログ監視部９０１は、本テーブルで指定されたストレージサービス８０１に格納されたメッセージ実行サーバー１０７の各メッセージ実行アプリケーション３１０のログファイルを監視する。尚、本実施例ではシステム管理サーバー１０８のログ監視部９０１は、メッセージ実行サーバー１０７に保存されたログファイルではなく、ストレージサービス８０１に格納されたログファイルを監視するように構成している。外部からメッセージ実行サーバー１０７に保存されたログファイルを監視するためには、メッセージ実行サーバー１０７にログインする等の処理が必要となる。これはシステム管理サーバー１０８が各メッセージ実行サーバー１０７のログイン情報を管理する必要があることを意味する。また、サービスを顧客に提供している稼働中のメッセージ実行サーバー１０７にログインしなければならない。そのため、本実施例ではシステム管理サーバー１０８及びメッセージ実行サーバー１０７のどちらもアクセス可能なストレージサービスにログファイルを格納するように構成している。

＜メッセージ実行処理＞
実施例２のメッセージ実行処理で実施例１と異なるのは、Ｓ４０３、Ｓ４０６、Ｓ４０７、Ｓ４０８でのログの出力先がストレージサービス８０１になっている点のみである。本実施例では、ログの出力先をストレージサービス８０１とするが、例えば、メッセージ実行サーバー１０７のログファイルにログを出力し、そのログファイルをストレージサービス８０１に同期するような構成でも良い。

＜ログ監視処理＞
図１０は、システム管理サーバー１０８の監視サーバーアプリケーション３２０が実行する実施例２おけるログ監視処理の手順例を示すフローチャートである。実施例１でログ監視処理は監視エージェントアプリケーション３００が実行していたが、実施例２ではシステム管理サーバー１０８の監視サーバーアプリケーション３２０が実行する。

Ｓ１００１で、ログ監視部９０１は、表Ｇで説明したログ監視条件テーブルからログ監視条件をすべて取得しＳ１００２に遷移する。実施例１では、各監視エージェントアプリケーション３００は、その監視エージェントアプリケーション３００が動作するメッセージ実行サーバー１０７のログ監視条件だけを監視していた。しかし、実施例２においては、システム管理サーバー１０８の監視サーバーアプリケーション３２０は、すべてのメッセージ実行サーバー１０７のログ監視条件を監視する。

Ｓ１００２で、ログ監視部９０１は、取得した監視条件が監視の終了を示しているかを判断する。監視の終了である場合は、処理を終了する。監視の終了でない場合はＳ１００３に遷移する。Ｓ１００３は、繰り返しの処理開始を表しており、Ｓ１００８が繰り返しの処理終了を表している。Ｓ１００８の処理に移ったときに、取得したログ監視条件の数だけＳ１００４からＳ１００７の処理を実行していた場合は、Ｓ１００１に遷移する。

Ｓ１００４で、ログ監視部９０１は、ストレージサービス８０１からログ監視条件に含まれるログファイルパスにあるログファイルを取得してＳ１００５に遷移する。Ｓ１００５で、ログ監視部９０１は、現在日時と、Ｓ１００４で取得したログファイルの更新日時の差分がログ監視条件に含まれる更新停止時間を超えていないかを判断する。更新停止時間を超えている場合は、異常が発生したと判断して、Ｓ１００６に遷移する。更新停止時間を超えていない場合は、Ｓ１００８に遷移する。

Ｓ１００６で、ログ監視部９０１は、ログファイルから処理が完了していないメッセージのメッセージＩＤを取得してＳ１００６に遷移する。処理が完了していないメッセージは、先に説明したようにログ５０３が出力され、ログ５０５が出力されないことで判断する。

Ｓ１００７で、図７を用いて説明した異常通知受信処理を実行してＳ１００８に遷移する。

以上、本実施例では、システム管理サーバー１０８は、ストレージサービス８０１に格納されたメッセージ実行サーバー１０７の各メッセージ実行アプリケーション３１０のログファイルを監視した。ログファイルの監視の結果に基づいて、システム管理サーバー１０８は、メッセージ実行アプリケーションの処理を停止することが可能となる。

（実施例３）
実施例１および実施例２において、メッセージ実行サーバー１０７が要停止状態であるかの判断を、オートスケールの対象になっているかで判断していた。実施例３においては、システム管理サーバー１０８から命令を送ることで要停止状態であると判断する例について記載する。実施例１および実施例２と同じ点については説明を省略する。

＜システム構成＞
実施例３におけるシステムの全体構成は実施例２と同じであり、図８で示す構成である。

＜メッセージ実行サーバーの機能構成＞
図１１（Ａ）は、実施例３におけるメッセージ実行サーバー１０７の機能構成の一例を示す図である。図３（Ａ）と異なるのはメッセージ実行アプリケーション３１０のオートスケール確認部３１４がなく、命令処理部１１０１が追加されている点である。

命令処理部１１０１は、ストレージサービス８０１に格納されている命令を定期的に取得して解析するモジュールである。

＜システム管理サーバーの機能構成＞
図１１（Ｂ）は、実施例３におけるシステム管理サーバー１０８の機能構成の一例を示す図である。図３（Ｂ）と異なるのは命令部１１２１が追加となった点である。

命令部１１２１は、メッセージ実行アプリケーション３１０の処理を停止する停止命令等をストレージサービス８０１に格納するモジュールである。また、定期的に命令の完了結果ファイルがあるかをストレージサービス８０１に確認して、命令の完了結果ファイルを取得する。

＜システム管理サーバーが管理するテーブル＞
システム管理サーバー１０８が管理するテーブルで実施例１と異なるのは、サーバー管理テーブルである。

表Ｈは、実施例３におけるサーバー管理テーブルである。実施例１のサーバー管理テーブルである表Ａと異なるのは、ログ状況のカラムが処理モードのカラムになっている点である。処理モードは、メッセージ実行アプリケーション３１０が動作する処理モードを表している。処理モードが、「実行」である場合は、正常にメッセージを処理していることを表している。処理モードが「停止」である場合は、システム管理サーバー１０８の監視サーバーアプリケーション３２０からの命令を受けて、メッセージの処理を停止していることを表している。処理モードが「異常」である場合は、デッドロックのようなことが発生した場合など、何らかの理由でメッセージの処理ができていないことを表している。

＜メッセージ実行処理＞
図１２は、メッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０が実行する実施例３におけるメッセージ実行処理の手順例を示すフローチャートである。

Ｓ１２０１で、命令処理部１１０１は、ストレージサービス８０１から命令を取得する旨をログに出力してＳ１２０２に遷移する。Ｓ１２０２で、命令処理部１１０１は、ストレージサービス８０１から命令を取得し、Ｓ１２０３に遷移する。

Ｓ１２０３で、命令処理部１１０１は、Ｓ１２０２で取得した命令があるかを確認する。命令がある場合はＳ１２０４に遷移する。命令がない場合は、Ｓ１２０１に戻り命令の監視を続ける。

Ｓ１２０４で、命令処理部１１０１は、命令の内容を確認する。処理モードを「実行」に変更する命令であった場合は、Ｓ１２０５に遷移する。処理モードを「停止」に変更する命令であった場合はＳ１２０６に遷移する。命令が処理の終了であった場合は、処理を終了する。

Ｓ１２０５で、命令処理部１１０１は、処理モードを「実行」に変更してＳ１２０７に遷移する。Ｓ１２０６で、命令処理部１１０１は、処理モードを「停止」に変更してＳ１２０７に遷移する。Ｓ１２０７で、命令処理部１１０１は、命令の完了結果ファイルをストレージサービス８０１に登録して、Ｓ１２０７に遷移する。

Ｓ１２０８で、メッセージ取得部３１１は現在の処理モードを確認する。現在の処理モードが「実行」である場合は、Ｓ４０３に遷移する。現在の処理モードが「停止」である場合は、Ｓ１２０１に遷移する。尚、Ｓ４０３からＳ４０９は図４を用いて説明した処理と同じため説明を省略する。

＜異常通知受信処理＞
図１３は、システム管理サーバー１０８の監視サーバーアプリケーション３２０が実行する実施例３における異常通知受信処理の手順例を示すフローチャートである。
Ｓ１３０１で、サーバー管理部３２１は、図Ｈで説明したサーバー管理テーブルの処理モードを「異常」で登録して、Ｓ７０３に遷移する。Ｓ７０３からＳ７０７の処理は図７を用いて説明した処理と同じであるため、説明を省略する。

Ｓ１３０２で、命令部１１２１は、メッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０の処理モードを「停止」に変更する命令をストレージサービス８０１に登録し、Ｓ１３０３に遷移する。

Ｓ１３０３で、命令部１１２１は、ストレージサービス８０１からメッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０の命令の完了結果を取得し、Ｓ１３０４に遷移する。尚、Ｓ１３０２で、命令を登録してから、メッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０が命令を実行するのにはある程度時間がかかるため、Ｓ１３０２とＳ１３０３の間は一定期間ウェイトしてもよい。また、命令を登録するＳ１３０２までの処理と命令の完了結果を取得するＳ１３０３以降の処理を別のスレッドで実行するように構成してもよい。

Ｓ１３０４で、命令部１１２１は命令の完了結果が取得できたかを判断する。１つ以上取得できた場合は、Ｓ１３０５に遷移する。１つも取得できなかった場合は、Ｓ１３０３に遷移する。

Ｓ１３０５で、サーバー管理部３２１は、Ｓ１３０４で取得したメッセージ実行サーバー１０７のメッセージ実行アプリケーション３１０の完了結果を基に、表Ｈで説明したサーバー管理テーブルの処理モードを「停止」に変更してＳ１３０６に遷移する。
Ｓ１３０６で、サーバー管理部３２１は、表Ｈで説明したサーバー管理テーブルを参照して、メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０が「停止」か「異常」になっているかを確認する。メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０が「停止」か「異常」になっている場合は、メッセージ実行サーバー１０７は停止状態になったと判断して、Ｓ７０９に遷移する。メッセージ実行サーバー１０７のすべてのメッセージ実行アプリケーション３１０が「停止」か「異常」になっていない場合は、Ｓ１３０３に遷移する。尚、Ｓ７０９の処理は図７を用いて説明した処理と同じである為、説明を省略する。

実施例３では、実施例１と同じようにメッセージ実行サーバー１０７に監視エージェントアプリケーション３００を配置する構成とした。しかし、実施例２と同じようにメッセージ実行サーバー１０７に監視エージェントアプリケーション３００を配置せずにシステム管理サーバー１０８の監視サーバーアプリケーション３２０にログ監視部９０１を配置する構成にしてもよい。

以上、本実施例では、システム管理サーバーがストレージに格納した命令を、メッセージ実行サーバーが取得し、その後メッセージ実行アプリケーションによるキューからのメッセージの取得を停止した。本実施例によれば、システム管理サーバーの監視サーバーアプリケーションが明示的に命令を出すことで、メッセージ実行アプリケーションの処理を停止させることができる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１０１ 情報処理システム
１０７ メッセージ実行サーバー
１０８ システム管理サーバー
３１０ メッセージ実行アプリケーション
３１１ メッセージ取得部
３１２ メッセージ実行部
３２０ 監視サーバーアプリケーション
３２１ サーバー管理部
３２２ 処理実行部

Claims (9)

1. 複数のアプリケーションが配置される仮想マシンと、前記仮想マシンを管理する管理サーバーとを含む情報処理システムであって、
   前記仮想マシンに配置される各アプリケーションは、前記情報処理システムで管理される設定に基づき、メッセージを格納する格納領域からメッセージを取得し、
   前記管理サーバーは、
   前記情報処理システム内で管理される設定を、前記仮想マシンに配置される各アプリケーションによるメッセージの取得を停止させるための設定に変更する設定手段を有し、
   前記仮想マシンに配置されるアプリケーションいずれかの異常が検知された場合、前記各アプリケーションは、前記設定手段により変更された設定に基づきメッセージの取得を停止し、かつ、前記設定手段による変更前に取得したメッセージに基づく処理を完了させることを特徴とする情報処理システム。
2. 前記仮想マシンに配置される全てのアプリケーションが、前記設定手段により変更された設定に基づきメッセージの取得を停止し、かつ、前記設定手段による変更前に取得したメッセージに基づく処理を完了させた後、前記仮想マシンは削除されることを特徴とする請求項１に記載の情報処理システム。
3. 前記仮想マシン、および、前記管理サーバーのいずれかが、
   前記各アプリケーションの異常の有無を監視する監視手段を有することを特徴とする請求項１または２に記載の情報処理システム。
4. 前記仮想マシンは、前記各アプリケーションの異常の有無を監視する監視手段を有し、
   前記各アプリケーションは、
   前記取得したメッセージに基づく処理を実行し、
   前記メッセージに基づく処理の動作に関するログを出力し、
   前記監視手段は、所定時間内に前記アプリケーションによるログの出力がない場合に、前記管理サーバーに対して、前記アプリケーションの異常として通知を行うことを検知することを特徴とする請求項１または２に記載の情報処理システム。
5. 前記各アプリケーションは、前記取得したメッセージの識別情報を含めたログを出力することを特徴とする請求項４に記載の情報処理システム。
6. 前記各アプリケーションが実行する処理には、データ集計の処理、メール送信の処理、および、ファイルエクスポートの処理のうち少なくともいずれかが含まれることを特徴とする請求項４または５に記載の情報処理システム。
7. 前記情報処理システムでは、前記格納領域に格納されたメッセージによる処理負荷に応じて、前記格納領域に格納されたメッセージの処理を行う仮想マシンの台数の調整が行われるように各仮想マシンが管理され、
   前記アプリケーションが前記情報処理システムにおける前記調整の対象となる仮想マシンに配置されている場合に、該アプリケーションは前記格納領域からメッセージを取得し、
   前記設定手段は、前記仮想マシンに配置されるアプリケーションいずれかの異常が検知された場合に、前記各アプリケーションによるメッセージの取得を停止させるための設定として、当該仮想マシンを前記情報処理システムにおける前記調整の対象から外すことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記情報処理システムには、前記仮想マシンと前記管理サーバーとがアクセス可能なストレージサービスが更に含まれており、
   前記管理サーバーは、
   前記仮想マシンに配置されるアプリケーションいずれかの異常が検知された場合に、前記各アプリケーションによるメッセージの取得を停止させるための設定として、メッセージの取得を停止させる命令を前記ストレージサービスに格納する格納手段を有し、
   前記各アプリケーションは、前記ストレージサービスに前記命令が格納されていた場合、前記格納領域からのメッセージの取得を停止することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
9. 複数のアプリケーションが配置される仮想マシンと、前記仮想マシンを管理する管理サーバーとを含む情報処理システムの制御方法であって、
   前記仮想マシンに配置される各アプリケーションは、前記情報処理システムで管理される設定に基づき、メッセージを格納する格納領域からメッセージを取得し、
   前記管理サーバーは、
   前記情報処理システム内で管理される設定を、前記仮想マシンに配置される各アプリケーションによるメッセージの取得を停止させるための設定に変更する設定工程を有し、
   前記仮想マシンに配置されるアプリケーションいずれかの異常が検知された場合、前記各アプリケーションは、前記設定手段により変更された設定に基づきメッセージの取得を停止し、かつ、前記設定手段による変更前に取得したメッセージに基づく処理を完了させることを特徴とする制御方法。

Images