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

Abstract

【課題】 メッセージの処理が失敗であった場合に、キューに格納されている、このメッセージに関連するメッセージの処理を完了させずにキューから削除するための仕組みを提供することを目的とする。
【解決手段】 情報処理システムに含まれる、１以上の仮想マシンのそれぞれは、複数のメッセージが格納されているキューから取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた処理エラーを示すステータスがストレージに保存されていた場合に、該メッセージの内容で指定されるデータの処理を完了させずに、前記キューから該メッセージを削除するための指示を行うことを特徴とする。
【選択図】 図６

Description

本発明は、メッセージキューを利用したデータ処理の技術に関する。

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

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

ここで、前述のクラウドサービスを用いて構築されるシステムにおいて、ある期間内に生成される複数のデータを処理し、一つのファイルにまとめる場合がある。この時、このような複数のデータのそれぞれに対応するメッセージがキューに格納されて、複数の仮想マシンによってそれら一連のメッセージが並列的に処理されることとなる。ここで、その一連のメッセージの処理においては、対応するすべてのメッセージの処理が成功することが必要となる場合がある。１つでもメッセージの処理でエラーが発生すると、生成されるファイルの中にデータの間違いや欠損が生じるからである。

特許文献１には、複数のデータベースに対するデータベースの更新処理において、１つのグローバルトランザクションを実現するための方法が記載されている。具体的には、データベースへの更新要求がキュー要素として、処理待ちキューに格納される。その後、キューに格納されるデータベース更新要求が順次処理され、そのうち１つでもデータベース更新要求の処理に失敗した場合は、成功した更新処理を含めた全ての更新処理の結果を取り消すようにする。

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

上述したような一連のメッセージの処理においては、すべてのメッセージの処理に成功する必要がある。一連のメッセージのうち一つでも処理に失敗した際には、当該一連のメッセージの処理エラーとして扱われるため、残りのメッセージは処理される必要がなくなる。つまり、一連のメッセージのうちの残りのメッセージを処理することは、リソースの無駄使いとなる。

そこで、一連のメッセージのうち処理されていない残りのメッセージを削除するために、キューに格納されているメッセージを全て削除するという方法が考えられる。しかしながら、一連のメッセージとそれ以外のメッセージが同一のキューの中に混在して格納されている場合があるため、キューに格納されているメッセージを全て削除すると、それ以外のメッセージも削除してしまうおそれがある。

そこで本発明は、メッセージの処理が失敗であった場合に、キューに格納されている、このメッセージに関連するメッセージの処理を完了させずにキューから削除するための仕組みを提供することを目的とする。

上記課題を解決するために、本発明の情報処理システムは、処理対象となるメッセージが格納されるキューからメッセージを取得し、該取得されたメッセージに基づく処理を実行する１以上の仮想マシンと、該仮想マシンによるデータの保存が可能なストレージとを備える情報処理システムであって、前記１以上の仮想マシンのそれぞれは、複数のメッセージが格納されている前記キューから、メッセージを取得する取得手段と、前記取得されたメッセージの内容で指定されるデータの処理を実行する実行手段と、前記実行手段により実行された前記処理が失敗であった場合に、前記取得されたメッセージの識別情報と関連付けて、処理エラーを示すステータスを前記ストレージに保存する保存手段と、前記取得されたメッセージを前記キューから削除する指示を行う指示手段と、を有し、前記指示手段は、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていた場合に、該メッセージについての前記実行手段による前記処理を完了させずに、前記キューから該メッセージを削除するための指示を行うことを特徴とする。

本発明によれば、メッセージの処理が失敗であった場合に、キューに格納されている、このメッセージに関連するメッセージの処理を完了させずにキューから削除することができる。

本発明の実施形態に係るシステム構成例を示す図である。 情報処理装置のハードウェア構成例を示す図である。 情報処理システムのソフトウェア機能の一例を示す図である。 メッセージの一例を示す図 指示サーバー１０４による処理の流れの例を示すフローチャートである。 処理サーバー１０６による処理の流れの例を示すフローチャートである。 実施例２におけるメッセージの一例を示す図である。 実施例２における指示サーバー１０４による処理の流れの例を示すフローチャートである。 実施例２における処理サーバー１０６による処理の流れの例を示すフローチャートである。

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

（実施例１）
図１は、本発明の実施形態に係るシステム構成例を示す図である。

本システムでは、情報処理システム１０１、および外部システム１０３が、インターネット１０２を介して接続されている。また、情報処理システム１０１には、指示サーバー１０４、キュー１０５、処理サーバー１０６、ストレージ１０７が存在し、それぞれがネットワークを介して接続されている。本実施例では、外部システム１０３から取得したデータに対して処理を加え、ストレージ１０７に処理結果を保存する場合を例示するが、処理対象のデータは、あらかじめストレージ１０７に保存されていてもよい。その場合、データの取得対象がストレージ１０７に代わる。

指示サーバー１０４は、処理サーバー１０６による処理の対象となるメッセージをキュー１０５に格納する機能を備える仮想マシンである。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、分割されたそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピューターである。指示サーバー１０４は、設定されたスケジュールに従って一定時間のみ起動してもよいし、常時起動していてもよい。

処理サーバー１０６は、キュー１０５からメッセージを取得して、取得したメッセージに基づく処理を実行する機能を備える１以上の仮想マシンである。キュー１０５に格納されているメッセージの数に基づく自動的なリソース量の調整が実行されて、処理サーバー１０６は追加または削除される。処理サーバー１０６に対する調整の内容および調整が実行される条件は、システム管理者によって予め設定される。

ここでのリソース量の調整とは、具体的には、仮想マシンの台数を増やすスケールアウト、および、仮想マシンの台数を減らすスケールインを指す。なお、リソース量の調整は、仮想マシンに対するハードウェア資源の割り当てを増やすスケールアップ、および、仮想マシンに対するハードウェア資源の割り当てを減らすスケールダウンであってもよい。ハードウェア資源は、ＣＰＵやメモリ、ストレージなどである。

また、処理サーバー１０６による処理の具体的な内容としては、処理対象のデータのフォーマット変換処理や、データの圧縮または解凍の処理などがあげられる。各サーバーやキュー間の通信は、ＨＴＴＰや、ＨＴＴＰＳ、ＳＯＡＰなどのプロトコロルに従うものとする。

図２は、情報処理装置のハードウェアの構成例を示す図である。本実施例における情報処理装置としては、情報処理システム１０１を構築するためのデータセンター上に存在するサーバコンピューター、および外部システム１０３の機能を備えるコンピューターなどがある。

ＣＰＵ２０１は、ＲＯＭ２０３内のプログラム用ＲＯＭに記憶されたプログラムや、外部メモリ２１０からＲＡＭ２０２にロードされたＯＳ（オペレーティングシステム）やアプリケーション等のプログラムを実行する。すなわち、ＣＰＵ２０１が、読み取り可能な記憶媒体に格納された該プログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。ＲＡＭ２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリア等として機能する。

キーボードコントローラ２０４は、キーボード２０８や図示しないポインティングデバイス（マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。ディスプレイコントローラ２０５は、ディスプレイ２０９の表示を制御する。ディスクコントローラ２０６は、各種データを記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）等の外部メモリ２１０へのデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０７はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

図３は、実施例１、２における情報処理システム１０１の各機能を示す機能ブロック図である。なお、基準値計算部３０４および処理時間測定部３２８は、実施例２に関する処理部であるため、本実施例での説明を省略する。

まず、指示サーバー１０４についての説明を行う。指示サーバー１０４は、キューにデータ処理のメッセージを格納する。データ処理の例としては、データのフォーマット変換処理などが挙げられる。データリスト取得部３０２は、外部システム１０３にリクエストを発行して、処理対象のデータの一覧を取得する。メッセージ格納部３０１は、データリスト取得部３０２が取得した一覧に含まれる各々のデータを、一つのメッセージとして、キュー１０５のリクエスト受信部３１１に送信する。メッセージの内容に関する説明は、図４を用いて後述する。処理状態確認部３０３は、後述するストレージ１０７にキュー１０５に保存されているメッセージが存在するか否かを確認し、存在しない場合には、後述するストレージ１０７に、処理エラーを示すステータスが存在するか否かを確認する。ステータスが存在する場合には、処理状態確認部３０３は、一連のメッセージについての処理が失敗であると判断する。

なお、キュー１０５に格納されるメッセージは、キューから取得されるだけではキューから削除されたことはならない。キューから取得されたメッセージは、他の処理サーバーから取得されないように一時的に不可視状態となる。その後、一般的には、処理サーバーによるメッセージの処理が完了した後、キューに対して該メッセージを削除するための指示が行われる。なお、処理サーバーがキューからメッセージを削除した後の一定時間の間に、キューに対して該メッセージの削除指示が行われない場合には、該メッセージは不可視状態が解除され、いずれの処理サーバーによっても取得可能な状態となる。

次に、キュー１０５についての説明を行う。リクエスト受信部３１１は、キュー内に保持されるメッセージに関するリクエストを受信し実行する。例えば、メッセージ格納部３０１から発行されたリクエストを受信した場合は、メッセージ保存部３１２に、メッセージを保存する。また、後述するメッセージ取得部３２１からメッセージ取得に関するリクエストを受信した場合には、メッセージ保存部３１２に保存されるメッセージを返却する。さらに、後述するメッセージ削除部３２４からメッセージ削除に関するリクエストを受信した場合には、指定されたメッセージを削除する。メッセージ保存部３１２は、受信したメッセージを、例えばファイルやデータベースなどの永続的な媒体に保存する。

さらに、処理サーバー１０６についての説明を行う。メッセージ取得部３２１は、キュー１０５からメッセージを取得する。データ取得部３２２は、メッセージ取得部３２１が取得したメッセージに記載されたデータの取得先からデータを取得する。データ処理部３２３は、取得したデータに対して何らかの処理を行い、処理結果のデータを、データ保存部３２６を介して、ストレージ１０７に保存する。ステータス保存部３２５は、データ処理部３２３の処理が失敗した場合に、ストレージ１０７に処理エラーを示すステータスをメッセージの識別情報と関連付けて保存する。処理失敗の例としては、例えば、ファイルのフォーマット変換処理において、フォーマット異常により変換できない場合や、ファイルの保存時にエラーが発生した場合などが挙げられる。なお、この時、保存先のパスの一部に、後述する図４で示すメッセージに含まれるメッセージの識別情報を含める。ステータス確認部３２７は、データ処理部３２３による処理の前に、前述したステータス保存部３２５が、ステータスが存在するか否かを確認する。確認の結果、ステータスが存在する、つまり処理が失敗した場合には、メッセージで示されるデータの処理が行われずに、メッセージ削除部３２４の処理に移る。

指示サーバー１０４、キュー１０５、処理サーバー１０６の組は、複数存在しても構わない。例えば、データの取得元となる外部システムごとに、各サービスに対応するための指示サーバー１０４、キュー１０５、処理サーバー１０６の組が用意される。なお、処理サーバー１０６は、いずれのサービスについての処理も実行可能な機能を備える。

ストレージ１０７についての説明を行う。リクエスト受信部３３１は、データ保存部３２６や、ステータス保存部３２５、ステータス確認部３２７からのリクエストを受信し、データの保存や、存在の有無の確認などを実行する。実際のデータは、データ保存部３３２に保存されており、データ保存部３３２は、ファイルシステムや、データベースなどの永続的な媒体に構成される。

最後に、外部システム１０３の説明を行う。リクエスト受信部３４１は、情報処理システム１０１からのリクエストを受信し、データリスト送信部３４２や、データ送信部３４３を介して、データの一覧やデータを、返送する。実際のデータは、データ保存部３４４に保存されており、データ保存部３３２は、ファイルシステムや、データベースなどの永続的な媒体に構成される。なお、本実施例では、メッセージに記載されるデータの保存先から処理対象のデータが取得されるが、処理対象のデータがメッセージに含まれていてもよい。

次に、図４を用いて、キュー１０５に保存されるメッセージの例について説明する。メッセージは、図に示すように４つの項目から構成される。ｆｉｌｅｐａｔｈ４０１は、データが保存されるパスを表し、ｇｕｉｄ４０２は、一連のデータを表すキーを示す。このキーは、互いに関連する一連のメッセージに対して付与される識別子である。処理に失敗した場合には、失敗したデータに対応するｇｕｉｄが同じメッセージのすべてを削除する必要がある。なお、各メッセージにそれぞれの識別子が付与され、一連のメッセージとなるメッセージの識別子をストレージ１０７で管理するようにしてもよい。処理パターン４０３は、取得したデータに対して実施する処理のパターンを表し、Ｓｔｏｒｅｐａｔｈ４０４は、処理結果のデータを保存するパスを表す。ｆｉｌｅｐａｔｈ４０１は、前述したデータリスト取得部３０２が外部システム１０３から取得したデータの一覧を用いて設定する。ｇｕｉｄ４０２は、データリスト取得部３０２が、処理対象のデータの一覧を取得した際に、動的に発行する。処理パターン４０３は、１つのキューの中に、異なるデータ処理方法で処理を行わなければならないデータが存在する可能性があるため、本項目を用いて、実施すべき処理を識別するためのＩＤを、処理サーバー１０６に伝える。処理サーバー１０６のデータ処理部３２３は、本値に応じて処理を変更する。最後に、データ保存部３２６が、Ｓｔｏｒｅｐａｔｈ４０４に処理結果のデータを送信することで、ストレージ１０７へのデータの保存が完了する。

以下、図５を用いて、指示サーバー１０４による処理の流れについて説明する。

Ｓ５０１では、データリスト取得部３０２は、外部システム１０３から、処理対象のデータの一覧を取得する。

Ｓ５０２では、メッセージ格納部３０１は、図４で説明したｇｕｉｄを生成する。

Ｓ５０３では、メッセージ格納部３０１は、Ｓ５０１で取得したデータの一覧のそれぞれと、Ｓ５０２で生成したｇｕｉｄ、およびデータの保存先や処理パターンなどの情報を、図４にて説明したメッセージのような形に整形し、リクエスト受信部３１１に送信する。

Ｓ５０４では、処理状態確認部３０３は、キュー１０５に、メッセージが存在するか否かを確認し、存在する場合には、再度Ｓ５０４に遷移する。

Ｓ５０５では、処理状態確認部３０３は、ストレージ１０７に保存されたステータスが存在するか否かを確認し、存在する場合には、Ｓ５０６に遷移し、存在しない場合には終了する。

Ｓ５０６では、処理状態確認部３０３は、処理失敗を表すアラートを上げ、終了する。アラートはメールでも、ログでも手段は問わない。

次に、図６（ａ）、図６（ｂ）を用いて、処理サーバー１０６による処理の流れについて説明する。

Ｓ６０１では、メッセージ取得部３２１は、キュー１０５からメッセージを取得する。メッセージが取得できない場合は、指示サーバーが登録したメッセージの全てが処理されたものとみなし、終了する。メッセージが取得できた場合には、Ｓ６０２に遷移する。

Ｓ６０２では、ステータス確認部３２７は、メッセージに含まれるＧＵＩＤに関連付けられたステータスがストレージ１０７に保存されているか否かを確認する。ステータスが存在しない場合には、処理が失敗していないと判定され、Ｓ６０３に遷移する。ステータスが存在する場合には、Ｓ６０４に遷移する。

Ｓ６０３では、データに対して処理が実施される。詳細は、図６（ｂ）にて説明する。
Ｓ６０４では、メッセージ削除部３２４が、処理に完了したメッセージをキュー１０５から削除するよう指示する。

次に、図６（ｂ）を用いて、データの処理に関するフローの説明をする。

Ｓ６２１では、データ取得部３２２が、Ｓ６０１で取得したメッセージに記載されたｆｉｌｅｐａｔｈから、データを取得する。

Ｓ６２２では、データ処理部３２３が、Ｓ６２１で取得したデータに対して、Ｓ６０１で取得したメッセージに記載された処理パターンに応じて処理を実施する。処理の過程で、エラーが発生した場合には、Ｓ６２３に遷移し、処理が成功した場合にはＳ６２４に遷移する。

Ｓ６２３では、ステータス保存部３２５は、ストレージ１０７に、ステータスを保存する。この時、メッセージに含まれるＧＵＩＤをファイルパスに含める。

Ｓ６２４では、処理されたデータがストレージ１０７に保存される。

図６（ａ）、（ｂ）に示すフローに従って処理を進めることで、処理の失敗時に、キューからのメッセージを並列で削除することが可能となり、キューのメッセージがなくなることで、自動で処理サーバーがスケールインする。

以上説明したように本実施例では、メッセージの処理が失敗であった場合に、ストレージにこのメッセージの識別情報と関連付けて処理エラーを示すステータスを保存する。その後のメッセージの処理において、このメッセージと関連するメッセージについては処理を完了させずにキューから削除する。これによって、仮想マシンは、キューに格納されている他のメッセージを早く処理でき、リソースの有効活用につながる。また、リソースの利用時間に基づいて利用料金が定められることが一般的なクラウドサービスにおいて、リソースの有効活用やそれに従う上述したスケールインなどにより、クラウドサービスの利用料金の節約にもつながる場合がある。

（実施例１の応用例）
ストレージ１０７に前述したステータスが存在する場合に、指示サーバー１０４、または、いずれかの処理サーバーが、キュー１０５に格納された複数のメッセージから、該ステータスに対応する一連の複数メッセージを選択的に削除するようにしてもよい。このような場合には、指示サーバー１０４は定期的に、処理サーバーは１つのメッセージをキュー１０５から取得した際に、ストレージ１０７にステータスが存在するかを確認する。

（実施例２）
本発明に係る第２の実施形態について説明する。以下構成に関しては実施例１と異なる点を中心に説明する。

一般的なクラウドサービスでは、リソースの利用に関する単位時間に基づいて、特定のクラウドサービス利用者により、仮想マシンなどのリソースが占有される。さらに、その単位時間に基づいて、リソースの利用に対する従量課金の金額が定められる。例えば、単位時間が１時間である場合には、１分使用した場合も５９分使用した場合も同様に、１時間分の利用料金が発生する。本実施例では、仮想マシンが追加されてから経過した時間を管理して、メッセージの処理に失敗した場合にその経過時間に基づいて仮想マシンの処理を切り替えるようにする。これにより、リソースの有効活用ができる。

本実施例におけるシステムのソフトウェア機能として図３に示すように、指示サーバー１０４には、基準値計算部３０４が追加され、処理サーバー１０６には処理時間測定部３２８が追加される。処理サーバー１０６は、処理時間測定部３２８で自身が起動してからの経過時間を管理する。基準値計算部３０４が、処理対象のデータの数等を鑑み、基準値を決定する。この基準値は、キューへ格納されるメッセージに含まれ、後述する処理時間測定部３２８にて利用される。例えば、１つのメッセージの削除に０．１秒、総メッセージ数が１００００個であった場合、総メッセージの削除に１０００秒（約１７分）かかることになる。ここで、リソースの利用に関する単位時間が６０分の場合、（１７×α）／６０で計算される値を基準値として定める。αはバッファ用の係数として、例えば、１．５などの、定数でかまわない。処理時間測定部３２８で管理される処理サーバーの追加されてからの経過時間をリソースの利用に関する単位時間で割った値の小数部分で示される０以上１未満の値が、前述した基準値を超えているか否かが判定される。例えば、リソースの占有時間の単位時間が６０分だとし、追加されてから経過した時間が６５分だとすると、６５／６０＝１．０８であるため、小数点以下の値は、０．０８となる。基準値を、０．５とすると、基準値を超えていないと判定される。基準値を超えていない場合には、リソースの無駄が発生することになるため、処理サーバー１０６は、キューからのメッセージ削除ではなく別の処理を実行する。

上述したように、経過時間および単位時間から求められる値と基準値とを比較した結果に基づく所定の条件を満たす場合に、仮想マシンに別の処理を実施させるようにする。処理時間測定部３２８により基準値を超えていると判定された場合には、メッセージ取得部３２１が取得済みのメッセージに含まれる別のキューのアドレスから、メッセージ取得部３２１がメッセージを取得する。本実施例におけるメッセージの例を、図７を用いて後述する。

また、データ処理部３２３は、特定の処理のみ可能なわけではなく、複数のキューから取得したメッセージに含まれる処理パターンに応じて処理が可能なモジュールが動作するものとする。その後データ処理部３２３が、メッセージ取得部３２１が別のキューから取得したメッセージに記載された情報に従って処理を実施する。処理を実施した後、再度元のキューからメッセージを取得し、処理時間測定部３２８により管理される起動してからの経過時間に基づいて、基準値を超えているか否かが判定される。このような処理を繰り返し、基準値を超えたタイミングで、元のキューからのメッセージ削除処理を実施し始める。このようにすることで、リソースの占有時間の単位時間を最大限有効に活用することが可能となる。

次に、図７を用いて、本実施例における、キューに格納されるメッセージ例について説明する。図４で説明したメッセージに加えて、基準値７０１、および別のキューのアドレス７０２が追加される。基準値７０１は、前述したとおり、基準値計算部３０４が求めた値が設定される。処理サーバー１０６は、一連のメッセージのいずれかの処理に失敗していることが確認された場合には、別のキューのアドレス７０２から、メッセージを取得する。なお、別のキューから取得されるメッセージも、図７にて説明したフォーマットと同じであり、処理パターン４０３や、Ｓｔｏｒｅｐａｔｈ４０４等、各項目に設定される値が異なるだけである。

次に、図８を用いて、基準値の計算処理も含めた、指示サーバー１０４による処理の流れの例について説明する。図５で説明したフローチャートにＳ８０１が追加されているため、Ｓ８０１の説明のみ行う。

Ｓ８０１では、基準値計算部３０４は、Ｓ５０１で取得したデータの一覧に含まれるデータの数や、キューに格納されるメッセージ１つあたりの削除時間、およびリソースの利用に関する単位時間などから、基準値を求める。基準値計算部３０４は、求めた基準値をメッセージに記載する。なお、基準値計算部３０４は、基準値を計算して求めるのではなく、データの数や、キューに格納されるメッセージ１つあたりの削除時間、およびリソースの利用に関する単位時間などと、上述した基準値とを対応付けて管理する表を参照してもよい。

最後に、図９（ａ）、図９（ｂ）を用いて、処理サーバー１０６による処理の流れの例について説明する。これらの処理は、起動中の１以上処理サーバー１０６のそれぞれで実施される処理である。なお、実施例２において追加された処理に関してのみ説明する。

Ｓ９０１では、処理時間測定部３２８は、処理サーバー１０６の起動時刻を取得し、処理サーバー１０６内に保持して管理する。

Ｓ９０２では、処理時間測定部３２８は、Ｓ９０１で取得した起動時刻から経過した時間などを基にして所定の条件を満たすか否かを判定する。所定の条件とは、経過時間および単位時間に基づき算出される値が、メッセージに含まれる基準値７０１以下であるという条件である。基準値以下である場合には、Ｓ９０３に遷移して、後述する別のキューのメッセージに基づくデータ処理が行われる。また基準値以下でない場合には、Ｓ６０４に遷移して、実施例１と同様にメッセージの削除処理が行われる。

Ｓ９０３では、処理サーバー１０６は、別のキューから取得したデータの処理を実施する。ここで実施される第２のデータ処理については、図９（ｂ）を用いて説明する。なお、対象となる別キューは、メッセージ内で指定された１以上のキューのいずれかである。処理サーバー１０６によるメッセージの取得先となるキューは、ランダムに決定されてもよいし、優先順位に従って決定されてもよい。

図９（ｂ）のＳ９２１では、メッセージ取得部３２１は、Ｓ６０１でメッセージを取得したキューとは異なる別のキューからメッセージを取得する。ここで、図７を用いて前述した７０２で示す別のキューのアドレスが用いられる。メッセージ取得部は、Ｓ６０１で取得したメッセージに含まれる別のキューのアドレスに基づいて、当該別のキューからメッセージを取得する。

Ｓ９２１でメッセージを取得できた場合にはＳ９２２に処理が進められ、Ｓ９２１でメッセージを取得できなかった場合には、図９（ｂ）のフローチャートの処理を終了して図９（ａ）のフローチャートに戻る。

Ｓ９２２では、ステータス確認部３２７は、Ｓ９２１で別のキューから取得したメッセージの識別情報と関連するステータスがストレージに保存されているかを確認する。

Ｓ９２３では、データ処理部３２３は、Ｓ９２１で取得したメッセージに基づく処理を実行する。このように、処理サーバー１０６は、別のキューに格納されるメッセージを処理することで、処理サーバー１０６の起動時間を有効活用することができる。

Ｓ９２４では、メッセージ削除部３２４は、Ｓ９２１でメッセージを取得したキューから該メッセージを削除するための指示を行う。

なお、Ｓ９２２でＹＥＳのときも、Ｓ９０２と同様の判断が行われる。ここで用いられる単位時間や基準値は、Ｓ９０２で用いられるものと同じである。各キューに対応する処理サーバーの経過時間を求めるためには、処理サーバー１０６が、処理エラーを示すステータスを書き込む際に、ステータスと共に自身の起動時刻（Ｓ９０１）をストレージ１０７に記録しておく。

また、Ｓ９０３の第２のデータ処理が行われた場合には、Ｓ６０１で取得されたメッセージ削除処理が行われない。

なお、別のキューのアドレスは、メッセージ取得部３２１が取得したメッセージに含まれずに、ストレージ１０７に保存されていてもよい。

以上説明したように、本実施例では、処理サーバー１０６の起動時間が所定の条件を満たす場合に、処理サーバー１０６は、別のキューからメッセージを取得して、その取得したメッセージに基づく処理を実行する。これによって、リソースの有効活用やそれに従う上述したスケールインなどにより、クラウドサービスの利用料金の節約にもつながる場合がある。

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

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

１０１ 情報処理システム
１０６ 処理サーバー
３２１ メッセージ取得部
３２３ データ処理部
３２４ メッセージ削除部
３２５ ステータス保存部

Claims (8)

1. 処理対象となるメッセージが格納されるキューからメッセージを取得し、該取得されたメッセージに基づく処理を実行する１以上の仮想マシンと、該仮想マシンによるデータの保存が可能なストレージとを備える情報処理システムであって、
   前記１以上の仮想マシンのそれぞれは、
   複数のメッセージが格納されている前記キューから、メッセージを取得する取得手段と、
   前記取得されたメッセージの内容で指定されるデータの処理を実行する実行手段と、
   前記実行手段により実行された前記処理が失敗であった場合に、前記取得されたメッセージの識別情報と関連付けて、処理エラーを示すステータスを前記ストレージに保存する保存手段と、
   前記取得されたメッセージを前記キューから削除する指示を行う指示手段と、を有し、
   前記指示手段は、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていた場合に、該メッセージについての前記実行手段による前記処理を完了させずに、前記キューから該メッセージを削除するための指示を行うことを特徴とする情報処理システム。
2. 前記実行手段は、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていなかった場合に、前記取得されたメッセージの内容で指定されるデータの処理を実行し、
   前記指示手段は、前記実行手段による前記処理が完了したことに応じて、前記キューから該メッセージを削除するための指示を行うことを特徴とする請求項１に記載の情報処理システム。
3. 前記仮想マシンは、前記キューに格納されているメッセージの数に基づいて追加または削除されることを特徴とする請求項１または２に記載の情報処理システム。
4. 前記１以上の仮想マシンのそれぞれは、自身が追加されてからの経過時間を管理する管理手段を更に有し、
   前記取得手段は、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていた場合であって、前記管理手段により管理される前記経過時間に基づいて所定の条件を満たすと判定された際に、前記取得されたメッセージが格納されていたキューとは異なる、前記情報処理システムが備える別のキューからメッセージを取得し、
   前記実行手段は、前記別のキューから取得されたメッセージに基づく処理を実行することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記管理手段は、前記仮想マシンが追加されてからの経過時間に対する従量課金の際に用いられる単位時間と、前記取得手段が前記別のキューからメッセージを取得するか否かを決定するための基準値とを更に管理し、
   前記取得手段は、前記経過時間および前記単位時間から求められる値と前記基準値とを比較した結果に基づき、前記取得手段により前記別のキューからメッセージを取得することが決定される際に、前記所定の条件を満たすと判定されることを特徴とする請求項４に記載の情報処理システム。
6. 前記取得手段は、前記取得されたメッセージで指定される別のキューの情報に基づいて、該別のキューからメッセージを取得することを特徴とする請求項４または５に記載の情報処理システム。
7. 前記指示手段は、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていた場合であって、前記管理手段により管理される前記経過時間に基づいて前記所定の条件を満たすと判定されなかった際に、前記取得されたメッセージが格納されるキューから該メッセージを削除するための指示を行うことを特徴とする請求項４乃至６のいずれか１項に記載の情報処理システム。
8. 処理対象となるメッセージが格納されるキューからメッセージを取得し、該取得されたメッセージに基づく処理を実行する１以上の仮想マシンと、該仮想マシンによるデータの保存が可能なストレージとを備える情報処理システムの制御方法であって、
   前記１以上の仮想マシンのそれぞれでは、
   複数のメッセージが格納されている前記キューから、メッセージを取得する取得工程と、
   前記取得されたメッセージの内容で指定されるデータの処理を実行する実行工程と、
   前記実行工程で実行された前記処理が失敗であった場合に、前記取得されたメッセージの識別情報と関連付けて、処理エラーを示すステータスを前記ストレージに保存する保存工程と、
   前記取得されたメッセージを前記キューから削除する指示を行う指示工程と、が実行され、
   前記指示工程では、前記取得されたメッセージに含まれる該メッセージの識別情報と関連付けられた前記ステータスが前記ストレージに保存されていた場合に、該メッセージについての前記実行工程での前記処理を完了させずに、前記キューから該メッセージを削除するための指示が行われることを特徴とする制御方法。

Images