JP2018063672A - メッセージ実行サーバー、制御方法、およびプログラム - Google Patents

Abstract

【課題】 メッセージ実行サーバーの長時間の占有を防止し、キュー内のメッセージの処理の登録順をある程度維持しつつ均等に実行していくための仕組みを提供することを目的とする。
【解決手段】 本発明は、メッセージ登録サーバーによりキューに登録されたメッセージに基づく処理を実行するメッセージ実行サーバーであって、メッセージをキューから取得する取得手段と、前記取得手段が取得したメッセージに基づく処理を実行する実行手段と、前記取得したメッセージに基づく処理を前記実行手段が実行してから所定時間が経過した際に中断された該メッセージに基づく残りの処理についてのメッセージを前記キューに登録する登録手段と、を有し、前記登録手段により登録されるメッセージに対しては、前記登録されるメッセージを前記キューから取得不可とする期間を示す遅延時間が設定されることを特徴とする。
【選択図】 図１

Description

本発明は、キューのメッセージに基づく処理を実行するメッセージ実行サーバー、制御方法、およびプログラムに関する。

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

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

特許文献１には、キューに格納されているメッセージの数に応じて、メッセージに基づく処理を実行するインスタンスの数が増減するように制御するための仕組みが開示されている。

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

上述したようなキューを利用したシステムにおいて、１つのメッセージの処理に要する時間は、メッセージの処理内容などによって異なる場合がある。そのため、メッセージ実行サーバー（インスタンス）が、処理時間の長いメッセージの処理のために長時間を占有され、キューに登録される他のメッセージの処理の開始が遅れてしまう場合がある。

上述した特許文献１の仕組みによって、キューに格納されているメッセージの数が規定値以上である場合に、メッセージに基づく処理を実行するインスタンスの数が増える。しかしながら、それらインスタンスが取得した各メッセージの処理に長時間かかる場合、結局、その他のメッセージの処理の開始が遅れてしまう。

ここで、登録されるメッセージの要求元となるサービス利用者のそれぞれに対しては、均等にクラウドサービスのリソースが割り当てられる状態にしておくことが望ましい。

そこで、本発明は、このようなインスタンスの長時間の占有を防止し、キュー内のメッセージの処理の登録順をある程度維持しつつ均等に実行していくための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、メッセージ登録サーバーによりキューに登録されたメッセージに基づく処理を実行するメッセージ実行サーバーであって、メッセージをキューから取得する取得手段と、前記取得手段が取得したメッセージに基づく処理を実行する実行手段と、前記取得したメッセージに基づく処理を前記実行手段が実行してから所定時間が経過した際に中断された該メッセージに基づく残りの処理についてのメッセージを前記キューに登録する登録手段と、を有し、前記登録手段により登録されるメッセージに対しては、前記登録されるメッセージを前記キューから取得不可とする期間を示す遅延時間が設定されることを特徴とする。

本発明によれば、メッセージ実行サーバーの長時間の占有を防止し、キュー内のメッセージの処理の登録順をある程度維持しつつ均等に実行していくことが可能となる。

本発明の実施形態におけるシステムの全体構成例を示す図 情報処理装置の内部構成の一例を示す図 メッセージ登録サーバー１０５の機能構成の一例を示す図 メッセージ実行サーバー１０７の機能構成の一例を示す図 分割設定テーブルの一例を示す図 メッセージ管理テーブルの一例を示す図 キューに登録するメッセージの一例を示す図 メッセージ登録処理の手順例を示すフローチャート メッセージ実行処理の手順例を示すフローチャート 実施例２におけるメッセージ実行サーバー１０７の機能構成の一例を示す図 中断設定テーブルの一例を示す図 実施例２におけるメッセージ管理テーブルの一例を示す図 実施例２におけるメッセージ登録処理の手順例を示すフローチャート 実施例２におけるメッセージ実行処理の手順例を示すフローチャート 優先キューと通常キューの構成を示す模式図

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

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

図１において、情報処理システム１０１は、クラウドサービスで提供されるプラットフォームやリソースを利用して構築されるシステムである。クラウドサービスは、リソースとして、例えばインターネット上のデータセンターに存在するサーバーコンピューター上で動作する複数の仮想マシンやストレージなどを提供する。Ｗｅｂサーバー１０３、スケジューラー１０４、メッセージ登録サーバー１０５、キュー１０６、メッセージ実行サーバー１０７、データストア１０８を含む。情報端末１０２、Ｗｅｂサーバー１０３、スケジューラー１０４、メッセージ登録サーバー１０５、キュー１０６、メッセージ実行サーバー１０７、データストア１０８は、インターネットなどの既知の技術により相互にアクセス可能に接続されている。

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

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

スケジューラー１０４は、メッセージ登録サーバー１０５に対して定期処理の実行指示をする。定期処理とは、情報処理システム内で管理するデータの定期集計処理や、定期削除処理などである。スケジューラー１０４は、予め設定された定期処理の実行時刻になると、定期処理を実行するためのメッセージの登録要求を、メッセージ登録サーバー１０５に送信する。

メッセージ登録サーバー１０５は、メッセージを作成してキューに登録する。メッセージ登録サーバー１０５は、Ｗｅｂサーバー１０３またはスケジューラー１０４からメッセージ登録要求を受信すると、メッセージを作成し、作成したメッセージをキュー１０６に登録する。

キュー１０６は、メッセージ登録サーバー１０５により登録されたメッセージを格納する。

メッセージ実行サーバー１０７は、キューに登録されたメッセージを取得し、メッセージで指示された処理を実行する。メッセージ実行サーバー１０７は、一つのキューに対して一台以上存在する。ここで、メッセージ実行サーバー１０７は、キューに登録されたメッセージ数の増減に応じ、台数を増減するように構成しても良い。以降の説明において、このメッセージ実行サーバーの台数を増減するための設定をオートスケール設定と呼ぶ。

データストア１０８は、情報処理システム１０１が管理する各種データを格納する。

ここで、キュー１０６の仕組みについて説明する。キューに格納されるメッセージは、キューから取得されるだけではキューから削除されたことにはならない。メッセージ実行サーバーによるメッセージの処理が完了した後、キューに対してそのメッセージの削除指示が行われてから、そのメッセージが削除されることとなる。

また、キューの機能として、キューに登録されたメッセージを、メッセージ実行サーバー１０７が取得してから第１の所定時間が経過するまでの間、他のメッセージ実行サーバーがキュー内のそのメッセージを取得できない状態にする機能がある。このメッセージの状態のことを不可視状態と呼ぶ。また、この第１の所定時間を不可視時間と呼ぶ。この機能により、複数のメッセージ実行サーバーが、同一メッセージを取得して処理を実行することがないように制御できる。なお、メッセージが取得された後、不可視時間が経過すると、キュー内でそのメッセージの状態が可視状態に戻る。例えば、メッセージ実行サーバーがメッセージの処理に失敗して、その後そのメッセージの不可視時間が経過して可視状態となった場合、いずれかのメッセージ実行サーバー１０７がそのメッセージを取得して処理をリトライできる。

また、キューの別の機能として、キューにメッセージが登録されてから第２の所定時間が経過するまでの間、キュー内でその登録されたメッセージを不可視状態にする機能がある。この第２の所定時間を、遅延時間と呼ぶ。この機能により、キューに登録されたメッセージを不可視状態とする期間を設定できる。キューの仕様上、メッセージの先入れ先出しが必ずしも保証されているわけではない。そのため、キューに登録された順でのメッセージ取得が実現されない場合がある。例えば、後段のメッセージに遅延時間を設定することで、確実に登録順を維持するといったことが可能である。

さらに、不可視時間および遅延時間は、キューまたは個々のメッセージに対して設定することができる。不可視時間および遅延時間が、キューに対して設定された場合、その数値がデフォルト値として使用される。キューに対して設定する不可視時間は、メッセージの処理に要する時間や処理失敗時のリトライ間隔を考慮し、各処理で適切な値を設定する必要がある。また、本実施例において、キューに対して設定する遅延時間（デフォルト値）は、０とする。つまり、メッセージに対して不可視時間および遅延時間を設定せずにキューに登録した場合、キューに対して設定した不可視時間および遅延時間がメッセージに適用される。一方、メッセージに対して不可視時間および遅延時間を設定してキューに登録した場合、メッセージに対して設定した不可視時間および遅延時間が優先される。なお、不可視時間は、メッセージをキューに登録後に更新することもできる。キューに登録されたメッセージの不可視時間を更新した場合、更新時点から更新後の値が適用される。例えば、不可視時間が６０秒に設定されているメッセージを取得してから２０秒経過後に、不可視時間を６０秒で更新すると、メッセージは更新時点から６０秒後に可視状態になる。

本実施例では、情報処理システムが実行する処理種類別に一つのキュー１０６がある例を示す。例えば、データの集計処理を実行するためのメッセージを登録するキューと、データの削除処理を実行するためのメッセージを登録するキューは、別のキューとする。さらに、メッセージ登録サーバー１０５は、一つのキューに対して一台存在する。そのため、Ｗｅｂサーバー１０３およびスケジューラー１０４は、メッセージ登録要求送信先のメッセージ登録サーバーを処理に応じて判断する。つまり、本実施例では、情報処理システムが実行する処理種類別に、メッセージ登録サーバー１０５とキュー１０６とメッセージ実行サーバー１０７との組み合わせが、複数存在する例を示す。処理種類を適当な単位でグループ化して一つのキューを使用するように構成しても良い。また、メッセージ登録サーバー１０５を適当な単位で集約するように構成しても良い。

＜情報処理装置の内部構成＞
図２は、情報端末１０２や、情報処理システム１０１が構築されるデータセンター上のサーバーコンピューターなどの情報処理装置の内部構成の一例を示す図である。

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

メモリー２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。

ネットワークインターフェースカード（ＮＩＣ）２０３は、ネットワークを介して、他のノードと双方向にデータをやりとりする。

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

ディスプレイコントローラー２０７は、例えば液晶ディスプレイなどで構成される表示モジュール２０８の表示を制御する。なお、情報処理装置の役割によっては、ディスプレイコントローラー２０７、表示モジュール２０８がない構成でも良い。

ディスクコントローラー２０９は、大容量記憶装置であるハードディスクドライブ（ＨＤＤ）２１０を制御する。

＜メッセージ登録サーバーの機能構成＞
図３は、メッセージ登録サーバー１０５の機能構成の一例を示す図である。

要求受信部３０１は、Ｗｅｂサーバー１０３またはスケジューラー１０４からメッセージ登録要求を受信する。登録部３０２は、メッセージ登録要求受信後に、要求された処理のメッセージを作成し、キュー１０６にメッセージを登録する。メッセージ登録処理の詳細については後述する。

＜メッセージ実行サーバーの機能構成＞
図４は、メッセージ実行サーバー１０７の機能構成の一例を示す図である。

取得部４０１は、キューに登録されたメッセージを取得する。実行部４０２は、メッセージ取得後に、メッセージで指示される処理を実行する。削除部４０３は、メッセージ実行後に、実行したメッセージをキューから削除するための指示を行う。メッセージ実行処理の詳細については後述する。

＜分割設定テーブル＞
図５は、図１で示したデータストア１０８が保持し、メッセージ登録処理で使用する分割設定情報の構成の一例を示す、分割設定テーブルの図である。本実施例では、メッセージ登録サーバー１０５が、要求された処理を所定の単位で分割してメッセージを作成しキューに登録する。分割設定とは、情報処理システムが実行する各種非同期処理や定期実行処理を、どのように分割するかを示す設定である。

例えば、メッセージに基づく処理がデータをシステム内のデータベースに登録するという処理である場合、メッセージ１つあたりの処理時間は登録対象のデータの数に依存する。したがって、分割後のメッセージ１つあたりの処理時間がおおよそ同程度となるように、メッセージ１つあたりの処理対象のデータ数を定める必要がある。

図５において、５０１の列は処理ＩＤであり、情報処理システムが実行する各種非同期処理や定期実行処理をシステム内で一意に識別するＩＤを示す。

５０２の列は分割単位情報、５０３の列は一処理あたりのデータ数情報であり、処理を所定の単位で分割するために使用する。例えば、要求された処理が、ログデータのインポート処理（Ｉｍｐｏｒｔ Ｄａｔａ）で対象ログ数が５０００件の場合、ログ数（分割単位）が１０００件（一処理あたりのデータ数）ごとに処理を５分割する。また、要求された処理が、ログデータのエクスポート処理（Ｅｘｐｏｒｔ Ｄａｔａ）で対象日数が６月１日から６月２５日の場合、日数（分割単位）が１０日（一処理あたりのデータ数）ごとに処理を３分割する。キューに対して設定された不可視時間（デフォルト値）や、オートスケール設定を考慮すると、キューの各メッセージの処理時間は同等になっている方が良い。そのため、分割単位情報５０２および一処理あたりのデータ数情報５０３は、各メッセージの処理時間が同等になるように設定する。

５０４の列は単位遅延時間であり、分割した各メッセージに対して設定する遅延時間を計算するために使用する単位時間である。遅延時間の計算方法の詳細については後述する。ここで、情報処理システムがバックエンドで実行するのみで、処理に時間がかかってもユーザーに影響がない処理については、単位時間を０に設定しておく。詳細は後述するが、これによりメッセージに設定する遅延時間も０になり、遅延時間を設定したことによって発生する可能性のある無駄時間を無くすことができる。

＜メッセージ管理テーブル＞
図６は、図１で示したデータストア１０８が保持し、メッセージ登録処理およびメッセージ実行処理で使用するメッセージ管理情報の構成の一例を示す、メッセージ管理テーブルの図である。メッセージ管理テーブルでは、各メッセージに関する情報を管理する。利用するキューが分散キューのような場合、キューの性質上、複数のメッセージ実行サーバーが同一メッセージを取得することが起こり得る。複数のメッセージ実行サーバーが同一メッセージを取得した場合であっても同一処理を実行しないようにするため、メッセージ情報としてメッセージの状態を管理する。

図６において、６０１の列はテナントＩＤである。テナントＩＤとは、テナントをシステム内で一意に識別するＩＤである。本テーブルでは、該当行のメッセージ管理情報がどのテナントのメッセージ管理情報かを示す。本実施例の情報処理システム１０１では、システムを利用する顧客のデータを、顧客ごとの専用領域であるテナントの単位で管理する。情報処理システムは、複数の顧客から要求を受信して、受信した要求に対応するメッセージを処理する。そのため、例えば、顧客Ａから要求を受信した後に、顧客Ｂから要求を受信した場合であって、顧客Ａからの要求に対応するメッセージの処理に長時間かかる場合は、顧客Ｂは情報処理システムからの応答を長時間にわたって待たなければならないおそれがある。特に、システムからの応答を待っている顧客Ｂは、処理時間の短い要求をしたにもかかわらず、理由が分からないまま長時間待たされてしまうことになりかねない。したがって、本実施例では、顧客Ａの要求に対応するメッセージの処理に、顧客Ｂの要求に対応するメッセージの処理を割り込ませることを可能とする仕組みを説明する。

６０２の列は処理ＩＤであり、該当行のメッセージ管理情報がどの処理のメッセージ管理情報かを示す。

６０３の列はメッセージＩＤであり、メッセージを各テナントの各種処理内で一意に識別するＩＤを示す。

６０４の列は状態情報であり、メッセージの状態を示す。本例では状態として「処理待ち」「処理中」「処理完了」の３つがある。「処理待ち」は、メッセージがキューに登録されてから、キューから取得されて処理が開始されるまでの間の状態を示す。「処理中」は、処理が開始されてから、処理が完了するまでの間の状態を示す。「処理完了」は、処理が完了している状態を示す。状態情報６０４は、メッセージ登録処理にて登録され、メッセージ実行処理にて更新される。メッセージ実行処理では、メッセージを取得後、処理の実行前にメッセージの状態を確認し、メッセージの状態が「処理待ち」の場合のみ処理を実行するように制御する。これにより、複数のメッセージ実行サーバーが同一メッセージを取得した場合であっても同一処理を実行しないようにできる。

＜メッセージ＞
図７は、キュー１０６に登録されるメッセージの一例を示す図である。メッセージには、メッセージ実行サーバー１０７が処理内容を判断できる情報が含まれる。本例のメッセージは、テナントＩＤ７０１、処理ＩＤ７０２、メッセージＩＤ７０３、対象データ７０４を含む。対象データ７０４は、該当メッセージが処理対象とするデータを示す。テナントＩＤは、要求の送信元の顧客を示すテナントの識別子である。

＜メッセージ登録処理＞
図８は、メッセージ登録サーバー１０５が実行するメッセージ登録処理の手順例を示すフローチャートである。本処理は、Ｗｅｂサーバー１０３またはスケジューラー１０４からメッセージ登録要求を受信した際に実行する処理である。本処理では、処理を指示するメッセージを分割し、各メッセージに異なる遅延時間を設定する。これにより、特定のメッセージに対する処理が、メッセージ実行サーバーを占有することを防ぎ、メッセージを効率良く処理できるようにする。さらに、メッセージを所定単位で分割することにより、キューに登録されたメッセージ数の増減によるオートスケールも、より適切に行える。

図８のフローチャートで示す処理は、メッセージ登録サーバー１０５として機能する仮想マシンが動作するサーバーコンピューターのＣＰＵ２０１が、メモリー２０２やＨＤＤ２１０などに記録されたプログラムを読み出して実行することにより実現される。なお、以降のフローチャートで示す処理についても、同様に、該当する機能の仮想マシンが動作するサーバーコンピューターのＣＰＵ２０１によって実行されるものとする。

メッセージ登録処理を開始すると、Ｓ８０１で、登録部３０２は、要求された処理に対応する分割設定を取得する。

続いてＳ８０２で、登録部３０２は、Ｓ８０１で取得した分割設定の分割単位情報５０２、一処理あたりのデータ数情報５０３にもとづき、処理を分割してメッセージを作成する。

続いてＳ８０３で、登録部３０２は、０をＮに代入する。Ｎは分割して作成したメッセージをキューに一つ登録する度にインクリメントする変数である。

続いてＳ８０４で、登録部３０２は、Ｓ８０２で分割して作成したメッセージの内、Ｓ８０４〜Ｓ８１１のフローを未処理のメッセージについて、一メッセージずつ処理を繰り返す。

続いてＳ８０５で、登録部３０２は、処理中のメッセージのメッセージ管理情報を登録する。ここで、登録するメッセージ管理情報の状態情報６０４は処理待ちとする。

続いてＳ８０６で、登録部３０２は、処理中のメッセージに設定する遅延時間を計算する。ここで、メッセージを複数に分割した場合、分割後のメッセージそれぞれの遅延時間は異なる値になるように計算する。本実施例では、単位遅延時間５０４に、現在のＮの値を乗算した値を遅延時間とする。例えば処理を５分割した場合、１つ目の処理のメッセージの遅延時間は０分、２つ目は５分、３つ目は１０分、４つ目は１５分、５つ目は２０分となるように計算する。これらのメッセージをキューに登録すると、５つのメッセージは５分間隔で１つずつ可視状態（取得可能な状態）になる。ここで、５分割した処理をテナントＡの処理とする。テナントＡの５分割した処理のメッセージを登録した３分後に、テナントＢの処理のメッセージが登録されたとする。ここで、テナントＢの処理は、１つのメッセージであるため、遅延時間は０分と設定されたとする。このとき、テナントＡの２つ目のメッセージは、遅延時間を５分と設定しているため不可視状態（取得不可能な状態）である。そのため、メッセージ実行サーバーは、テナントＢのメッセージを先に取得する。つまり、テナントＡの処理の完了を待たずに、テナントＢの処理を実行することができる。このように、処理を指示するメッセージを分割し、各メッセージに異なる遅延時間を設定することにより、特定のメッセージに対する処理が、メッセージ実行サーバーを占有することがなくなり、メッセージを効率良く処理できる。なお、分割したメッセージの処理される順番を考慮して、各メッセージの遅延時間を設定してもよい。

続いてＳ８０７で、登録部３０２は、Ｓ８０６で計算した遅延時間を補正する。補正方法として、メッセージ実行サーバーのオートスケール設定にもとづき、遅延時間を補正することが考えられる。メッセージ実行サーバーの台数を増やすことが可能な場合は、遅延時間をより小さい値に補正する。遅延時間が小さい値になると、取得可能なメッセージ数は増えやすくなる。取得可能なメッセージ数に応じて、メッセージ実行サーバーの台数が増えることになり、処理が効率化される。一方、メッセージ実行サーバーの台数を増やすことが不可能な場合は、遅延時間をより大きい値に補正する。遅延時間が大きい値になると、取得可能なメッセージ数は増えにくくなり、別のメッセージが取得されやすくなる。別の補正方法として、メッセージ管理情報にもとづき、遅延時間を補正することが考えられる。同一テナントの同一処理が処理待ちまたは実行中の場合には、その数に応じて遅延時間に所定時間を加算して補正する。同一テナントの同一処理が多いほど、遅延時間が大きい値になり、別テナントのメッセージが取得されやすくなる。なお、本遅延時間を補正する処理は省略しても構わない。

続いてＳ８０８で、登録部３０２は、Ｓ８０６およびＳ８０７で計算した遅延時間を処理中のメッセージに設定する。

続いてＳ８０９で、登録部３０２は、処理中メッセージをキューに登録する。

続いてＳ８０９で、登録部３０２は、Ｎに１を足した値をＮに代入する。つまりＮの値をインクリメントする。

続いてＳ８０４で、登録部３０２は、Ｓ８０４〜Ｓ８１１の処理を行っていないメッセージがあるか否かを判定する。ここで、登録部３０２が、Ｓ８０４〜Ｓ８１１の処理を行っていないメッセージがあると判定した場合はＳ８０４に戻り処理を繰り返す。一方、登録部３０２が、Ｓ８０４〜Ｓ８１１の処理を行っていないメッセージがないと判定した場合は、本処理を終了する。

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

メッセージ実行処理を開始するとＳ９０１で、取得部４０１は、取得可能なメッセージをキューから１つ取得する。

続いてＳ９０２で、実行部４０２は、Ｓ９０１で取得したメッセージの管理情報を取得する。

続いてＳ９０３で、実行部４０２は、Ｓ９０１で取得した状態情報６０４が処理待ちであるか否かを判定する。ここで、実行部４０２が、状態情報６０４が処理待ちであると判定した場合はＳ９０４に進む。一方、実行部４０２が、状態情報６０４が処理待ちではない、つまり処理中か処理完了だと判定した場合は、処理を実行する必要がないと判断し、Ｓ９０１に戻り別のメッセージを処理する。

続いてＳ９０４で、実行部４０２は、Ｓ９０１で取得したメッセージの状態情報６０４を処理中に変更する。

続いてＳ９０５で、実行部４０２は、Ｓ９０１で取得したメッセージで指示された処理を実行する。

続いてＳ９０６で、実行部４０２は、Ｓ９０１で取得したメッセージの状態情報６０４を処理完了に変更する。

続いてＳ９０７で、削除部４０３は、Ｓ９０１で取得したメッセージをキューから削除し、Ｓ９０１に戻り別のメッセージを取得して処理する。

本実施例では、メッセージ登録サーバーは、処理時間の長い処理をキューにメッセージ登録する際に、その処理を分割して複数のメッセージを作成し、さらに、それぞれのメッセージに異なる遅延時間を設定した。ただし、本実施例で説明した仕組みを採用するためには、メッセージ実行サーバーの処理負荷がおおよそ均一となるように、メッセージを分割する必要がある。本実施例により、処理時間の長い処理のためにメッセージ実行サーバーが占有されることがなくなるため、他のメッセージの割込みが可能となる。

（実施例２）
実施例２では、本件の課題を解決するための別の実施例について説明する。

実施例１では、キューにメッセージを登録する処理を工夫することによって、課題を解決する方法を示した。実施例２では、キューからメッセージを取得して実行する処理を工夫することによって、課題を解決する方法を示す。

実施例１に示した方法では、要求された処理を分割する必要があった。しかし、処理によっては、分割できない処理も存在する。また、分割できても、分割した処理の実行順序制御や、分割した処理の実行排他制御が必要で、分割したことによって複雑になる処理も存在する。実施例２では、分割できない処理が存在しても、特定のキューメッセージの処理がサーバーを占有することなく、キューメッセージを効率良く処理できる仕組みについて説明する。

なお、以下では実施例１との差分について説明する。

＜メッセージ実行サーバーの機能構成＞
図１０は、実施例２におけるメッセージ実行サーバー１０７の機能構成の一例を示す図である。本機能構成は、実施例１の図４で示した機能構成を拡張したものである。

４０１〜４０３は、実施例１で示した通りである。１００１は登録部であり、取得部４０１が取得したメッセージと同じメッセージをキューに再登録したり、メッセージに基づく処理が中断された場合には残りの処理のみについてのメッセージをキューに登録したりする。

＜分割設定テーブル＞
実施例２では、実施例１の図５で示した分割設定情報が無い構成でも良い。

＜中断設定テーブル＞
図１１は、図１に示したデータストア１０８が保持し、メッセージ実行処理で使用する中断設定情報の構成の一例を示す、中断設定テーブルの図である。本実施例では、メッセージ実行サーバー１０７が、メッセージの処理の実行を開始後、所定時間が経過しても処理が完了しなかった場合、処理を中断する。中断設定では、情報処理システムが実行する各処理が、メッセージの処理の実行を開始してから中断するまでの時間を管理する。

図１１において、１１０１の列は処理ＩＤであり、情報処理システムが実行する各種非同期処理や定期実行処理をシステム内で一意に識別するＩＤを示す。

１１０２の列は中断時間であり、該当行の処理が、メッセージの処理の実行を開始してから中断するまでの時間を示す。中断時間は、不可視時間よりも小さい値とするのが望ましく、メッセージの処理に要する時間や、特定メッセージがサーバーを占有してしまっても問題のない時間を考慮し適切な値を設定する。

＜メッセージ管理テーブル＞
図１２は、実施例２におけるメッセージ管理情報の構成の一例を示す、メッセージ管理テーブルの図である。本構成は、実施例１の図６で示した構成を拡張したものである。

６０１〜６０４は、実施例１で示した通りである。１２０１の列は進捗状況情報であり、該当行のメッセージの処理の進捗状況を示す。進捗状況１２０１は、メッセージ実行処理によって更新される。

＜メッセージ登録処理＞
図１３は、実施例２におけるメッセージ登録サーバー１０５が実行するメッセージ登録処理の手順例を示すフローチャートである。本処理は、実施例１の図８で示したメッセージ登録処理から、処理の分割および遅延時間の設定に関する処理を除いたものである。

メッセージ登録処理を開始するとＳ１３０１で、登録部３０２は、要求された処理についてメッセージを作成する。

続いてＳ１３０２で、登録部３０２は、Ｓ１３０１で作成したメッセージについてメッセージ管理情報を登録する。ここで、登録するメッセージ管理情報の状態情報６０４は処理待ちとする。

続いてＳ１３０３で、登録部３０２は、Ｓ１３０１で作成したメッセージをキューに登録し、本処理を終了する。

＜メッセージ実行処理＞
図１４は、実施例２におけるメッセージ実行サーバー１０７が実行するメッセージ実行処理の手順例を示すフローチャートである。本処理は、実施例１の図９で示したメッセージ実行処理を拡張したものである。本処理では、メッセージの処理の実行を開始後、所定時間が経過しても処理が完了しなかった場合、処理を中断する。そして、中断時点での処理の進捗状況を記録し、キューにメッセージを再登録する。そして、キューから次のメッセージを取得し、次の処理を実行する。これにより、分割できない処理についても、特定のメッセージに対する処理が、メッセージ実行サーバーを占有することを防ぎ、メッセージを効率良く処理できるようにする。

Ｓ９０１〜Ｓ９０４は、実施例１で示した通りである。

Ｓ１４０１で、実行部４０２は、Ｓ９０１で取得したメッセージで指示された処理に該当する中断設定を取得する。

続いてＳ１４０２で、実行部４０２は、Ｓ９０１で取得したメッセージで指示された処理を実行する。ここで、実行部４０２は、図７に示したメッセージの内容およびＳ９０２で取得した進捗状況１２０１にもとづき、処理内容を判断し実行する。実行部４０２は、取得したメッセージのメッセージＩＤを用いて、進捗状況１２０１が記録されている場合は、前回実行時の続きから処理を実行すると判断する。さらに、実行部４０２は、メッセージで指示された処理を開始後、中断時間が経過した場合、または中断時間１１０２が経過する前に処理が完了した場合、Ｓ１４０３に進む。

続いてＳ１４０３で、実行部４０２は、Ｓ１４０２で実行した処理が完了したか否かを判定する。ここで、実行部４０２が、処理が完了したと判定した場合はＳ９０６に進む。一方、実行部４０２が、処理が完了していない（中断時間が経過したことで処理を中断した）と判定した場合はＳ１４０４に進む。

Ｓ９０６、Ｓ９０７は、実施例１で示した通りである。

Ｓ１４０４で、実行部４０２は、キューに取得可能なメッセージが存在するか否かを確認する。ここで、キューに取得可能なメッセージが存在する場合はＳ１４０５に進む。一方、キューに取得可能なメッセージが存在しない場合はＳ１４１０に進む。

続いてＳ１４０５で、実行部４０２は、Ｓ１４０２における処理の進捗状況を、メッセージ管理情報の進捗状況１２０１に記録する。

続いてＳ１４０６で、実行部４０２は、Ｓ９０１で取得したメッセージの状態情報６０４を処理待ちに変更する。

続いてＳ１４０７で、削除部４０３は、Ｓ９０１で取得したメッセージをキューから削除する。

続いてＳ１４０８で、登録部１００１は、Ｓ９０１で取得したメッセージに所定の遅延時間を設定する。利用するキューが分散キューのような場合、キューの性質上、キュー内のメッセージの順序性（先に登録したものが先に取得できる）は出来る限り維持されるが、保障はされないことが考え得る。キューがそのような性質の場合、メッセージに遅延時間を設定することで、遅延時間中に別メッセージを先に取得しやすくする。本処理で設定する遅延時間は、目的上１０秒程度にすれば十分であると考えられる。

続いてＳ１４０９で、登録部１００１は、Ｓ９０１で取得し、Ｓ１４０８で遅延時間を設定したメッセージをキューに登録し、Ｓ９０１に戻り別のメッセージを処理する。

一方Ｓ１４１０で、実行部４０２は、キュー内に存在するＳ９０１で取得したメッセージの不可視時間を更新し、Ｓ１４０２に戻り、現在のメッセージの処理を再開する。キュー内に取得可能なメッセージが無い（待ち状態になっている処理がない）場合は、現在の処理を中断して別メッセージを処理する必要はないため、現在のメッセージの処理を続行するように制御する。現在のメッセージの処理を続行する場合、一つのメッセージの処理時間が本来よりも長くなる。そのため、キュー内のメッセージの不可視時間が経過し可視状態（別サーバーが取得可能な状態）になってしまう可能性がある。よって、本処理で不可視時間を延ばすように更新する。不可視時間を更新する際の値としては、既存のメッセージに設定されている値と同じ値を使用することが考えられる。

なお、Ｓ１４０７において、削除部４０３は、Ｓ９０１で取得したメッセージをキュー１０６から削除するための指示をしなくてもよい。その後、キュー１０６またはそのメッセージに設定されている不可視時間が経過するまでの間、メッセージ実行サーバーは、他のメッセージを取得して処理できる可能性がある。そして、そのメッセージの不可視時間の経過後にそのメッセージは可視状態となり、メッセージ実行サーバーが、そのメッセージを取得し、進捗状況１２０１に基づいて処理を再開することができる。

また、実行部４０２によるメッセージの処理が中断された際には、実行部４０２は残りの処理について新たにメッセージを作成して、登録部１００１がそのメッセージをキューに登録してもよい。また、実行部４０２によるメッセージの処理が中断された際に、元のメッセージを分割して、登録部１００１がその分割後のメッセージをキューに登録してもよい。これらの場合には、実行部４０２は、必ずしもメッセージの処理の進捗状況をデータストア１０８に記録しなくてもよい。

＜優先キューが存在する場合＞
情報処理システムが実行する処理の中には、ユーザーおよびスケジューラーの両方からの指示で実行される処理がある。そのような処理について、スケジューラーからの実行指示の直後にユーザーからの実行指示があると、ユーザーから指示された処理は、スケジューラーから指示された定期処理の完了後に実行される。そのため、ユーザーが処理の完了まで待たされる時間は、スケジューラーの定期処理の時間帯か否かで大きく異なるという課題がある。本課題を解決するための仕組みとして、優先キューと通常キューという二つのキューを用いる方法がある。優先キューには、通常キューに登録されるメッセージに優先して処理すべきメッセージを登録可能である。

図１５は、図１に示した全体構成の１０５〜１０７の部分について、優先キューと通常キューを用いる仕組みにした場合の例を示す図である。メッセージ登録サーバー１０５は、Ｗｅｂサーバー１０３からメッセージ登録要求を受信すると、メッセージを作成し、作成したメッセージを優先キュー１５０１に登録する。一方、メッセージ登録サーバー１０５は、スケジューラー１０４からメッセージ登録要求を受信すると、メッセージを作成し、作成したメッセージを通常キュー１５０２に登録する。メッセージ実行サーバー１０７は、優先キュー１５０１および通常キュー１５０２に登録されたメッセージを取得し、メッセージで指示された処理を実行する。ここで、メッセージ実行サーバー１０７は、最初に優先キューからメッセージを取得する。そして、優先キューに取得可能なメッセージが存在しない場合に通常キューからメッセージを取得する。この仕組みにより、スケジューラーからの実行指示よりも、ユーザーからの実行指示を優先して処理できる。

優先キューと通常キューを用いる仕組みにした場合、図１４に示したＳ１４０４の判断では、優先キューのみを確認対象とする。つまり、実行部４０２は、優先キューに取得可能なメッセージが存在するか否かを確認する。ここで、優先キューに取得可能なメッセージが存在する場合はＳ１４０５に進む。一方、優先キューに取得可能なメッセージが存在しない場合はＳ１４１０に進む。これにより、ユーザーに影響のない状態では、処理を中断してメッセージを再登録する処理を行わず、メッセージを効率良く処理できる。

本実施例では、メッセージ実行サーバーが、メッセージの処理を中断して、そのメッセージの処理の進捗状況をデータストアに記録して、そのメッセージに遅延時間を設定してそのメッセージをキューに再登録した。本実施例によれば、処理時間の長いメッセージの処理を中断することができるため、他のメッセージの割り込みが可能となる。

（実施例３）
実施例３では、実施例１で示した方法と実施例２で示した方法とを組み合わせた方法を示す。

情報処理システムが実行する処理の中には、処理を分割はできるが、実行時期やユーザーの利用状況によって、分割した各処理の処理時間が大きく異なる場合がある。このような処理の場合は、実施例１だけでは、特定のメッセージの処理が、想定以上にサーバーを占有してしまう可能性がある。実施例３では、分割した各処理の処理時間が大きく異なる処理が存在しても、特定のキューメッセージの処理がサーバーを占有することなく、キューメッセージを効率良く処理できる仕組みについて説明する。

なお、以下では実施例１との差分について説明する。

＜メッセージ実行サーバーの機能構成＞
実施例２の図１０で示した機能構成と同じである。

＜中断設定テーブル＞
実施例２の図１１で示した構成と同じである。

＜メッセージ管理テーブル＞
実施例２の図１２で示した構成と同じである。

＜メッセージ実行処理＞
実施例２の図１４で示したフローチャートと同じである。本処理では、メッセージの処理の実行を開始後、所定時間が経過しても処理が完了しなかった場合、処理を中断する。そして、中断時点での処理の進捗状況を記録し、キューにメッセージを再登録する。そして、キューから次のメッセージを取得し、次の処理を実行する。これにより、分割した処理に長時間かかった場合でも、特定のメッセージに対する処理が、メッセージ実行サーバーを占有することなく、メッセージを効率良く処理できる。

本実施例によれば、分割した各処理の処理時間が大きく異なる処理が存在しても、特定のキューメッセージの処理がサーバーを占有することなく、キューメッセージを効率良く処理できる。

（実施例４）
実施例４では、実施例１から実施例３で示した各方法を、処理によって使い分ける仕組みについて説明する。処理によって各方法を使い分けることで、情報処理システムが実行する各種処理の特性に応じて、キューメッセージをより効率良く処理できる。

なお、以下では実施例３との差分について説明する。

＜分割設定テーブル＞
実施例４では、情報処理システムが実行する各種処理の内、分割して処理することに適する処理である場合は、当該処理についての分割設定を登録する。例えば、特に並列処理に適する処理について、本テーブルで分割設定を登録する。

＜中断設定テーブル＞
実施例４では、情報処理システムが実行する各種処理の内、メッセージ実行処理で所定時間経過後に処理を中断する処理について、本テーブルに中断設定を登録する。例えば、特に順序処理に適する処理、分割できない処理、または、分割した各処理の処理時間が大きく異なる処理について、本テーブルに分割設定を登録する。

＜メッセージ登録処理＞
実施例４では、分割設定テーブルに分割設定が登録されている処理については、図８で示したメッセージ登録処理を実行する。分割設定テーブルに分割設定が登録されていない処理については、図１３で示したメッセージ登録処理を実行する。

＜メッセージ実行処理＞
実施例４では、中断設定テーブルに中断設定が登録されている処理については、図１４で示したメッセージ実行処理を実行する。中断設定テーブルに中断設定が登録されていない処理については、図９で示したメッセージ実行処理を実行する。

本実施例によれば、処理によって各方法を使い分けることで、情報処理システムが実行する各種処理の特性に応じて、キューメッセージをより効率良く処理できる。

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

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

１０１ 情報処理システム
１０７ メッセージ実行サーバー
４０１ 取得部
４０２ 実行部

Claims (8)

1. メッセージ登録サーバーによりキューに登録されたメッセージに基づく処理を実行するメッセージ実行サーバーであって、
   メッセージをキューから取得する取得手段と、
   前記取得手段が取得したメッセージに基づく処理を実行する実行手段と、
   前記取得したメッセージに基づく処理を前記実行手段が実行してから所定時間が経過した際に中断された該メッセージに基づく残りの処理についてのメッセージを前記キューに登録する登録手段と、を有し、
   前記登録手段により登録されるメッセージに対しては、前記登録されるメッセージを前記キューから取得不可とする期間を示す遅延時間が設定されることを特徴とするメッセージ実行サーバー。
2. 前記取得手段は、前記登録手段により登録された前記残りの処理についてのメッセージに対して設定された遅延時間中に、該残りの処理についてのメッセージとは異なる別のメッセージを前記キューから取得し、
   前記実行手段は、前記取得手段により取得された、前記残りの処理についてのメッセージとは異なる別のメッセージに基づく処理を実行することを特徴とする請求項１に記載のメッセージ実行サーバー。
3. 前記実行手段は、前記取得したメッセージに基づく処理を中断した際に、前記取得したメッセージに基づく処理の進捗状況を前記取得したメッセージの識別子とともにデータストアに記録し、
   前記登録手段は、前記残りの処理についてのメッセージとして、当該中断されたメッセージを再び前記キューに登録し、
   前記実行手段は、前記取得手段が前記キューからメッセージを取得した際に、前記取得したメッセージの識別子を用いて、前記データストアに記録された該メッセージの進捗状況を確認し、確認された進捗状況に従い該メッセージに基づく残りの処理を実行することを特徴とする請求項１または２に記載のメッセージ実行サーバー。
4. 前記実行手段は、
   前記メッセージ実行サーバーがアクセス可能なデータストアで保持される設定に基づき、前記取得したメッセージに基づく処理を実行してから所定時間が経過した際に、前記取得したメッセージに基づく処理が完了していない場合であって、かつ、前記キューに取得可能なメッセージが残っている場合には、前記取得したメッセージに基づく処理を中断し、
   前記メッセージ実行サーバーがアクセス可能なデータストアで保持される設定に基づき、前記取得したメッセージに基づく処理を実行してから所定時間が経過した際に、前記取得したメッセージに基づく処理が完了していない場合であって、かつ、前記キューに取得可能なメッセージが残っていない場合には、前記取得したメッセージに基づく処理を続行することを特徴とする請求項１乃至３のいずれか１項に記載のメッセージ実行サーバー。
5. 前記キューには、通常キューと、該通常キューに登録されるメッセージに優先して処理すべきメッセージを登録可能な優先キューとが含まれ、
   前記実行手段は、
   前記メッセージ実行サーバーがアクセス可能なデータストアで保持される設定に基づき、前記取得したメッセージに基づく処理を実行してから所定時間が経過した際に、前記取得したメッセージに基づく処理が完了していない場合であって、かつ、前記優先キューに取得可能なメッセージが残っている場合には、前記取得したメッセージに基づく処理を中断し、
   前記メッセージ実行サーバーがアクセス可能なデータストアで保持される設定に基づき、前記取得したメッセージに基づく処理を実行してから所定時間が経過した際に、前記取得したメッセージに基づく処理が完了していない場合であって、かつ、前記優先キューに取得可能なメッセージが残っていない場合には、前記取得したメッセージに基づく処理を続行することを特徴とする請求項１乃至４のいずれか１項に記載のメッセージ実行サーバー。
6. 前記メッセージ登録サーバーおよび前記メッセージ実行サーバーを含む情報処理システムを利用する顧客のデータを、該顧客ごとの専用領域で管理しており、
   前記メッセージ登録サーバーは、前記実行手段により実行されるメッセージに対応する要求の送信元である第１の顧客とは異なる第２の顧客から、要求を受信し、
   前記登録手段は、前記第２の顧客から受信した要求に対応するメッセージを前記キューに登録し、
   前記取得手段は、前記第１の顧客から受信した要求に対応するメッセージの処理を中断した場合には、該中断した前記第１の顧客から受信した要求に対応するメッセージを再び取得する前に、前記第２の顧客から受信した要求に対応するメッセージを取得することを特徴とする請求項１乃至５のいずれか１項に記載のメッセージ実行サーバー。
7. メッセージ登録サーバーによりキューに登録されたメッセージに基づく処理を実行するメッセージ実行サーバーの制御方法であって、
   メッセージをキューから取得する取得工程と、
   前記取得工程で取得されたメッセージに基づく処理を実行する実行工程と、
   前記取得したメッセージに基づく処理が前記実行工程で実行されてから所定時間が経過した際に中断された該メッセージに基づく残りの処理についてのメッセージを前記キューに登録する登録工程と、を有し、
   前記登録工程で登録されるメッセージに対しては、前記登録されるメッセージを前記キューから取得不可とする期間を示す遅延時間が設定されることを特徴とする制御方法。
8. 請求項１乃至６のいずれか１項に記載の手段としてコンピューターを機能させるためのプログラム。

Images