(57)【要約】【課題】、顧客間でのサービスの提供の公平性を担保しつつ、メッセージを効率よく処理する。【解決手段】１以上のメッセージを管理するキュー１０６と、キュー１０６からメッセージを取得して処理を実行する複数の実行サーバ１０７を含む情報処理システム１０１であって、キュー１０６に登録された各メッセージについて、識別ＩＤと、メッセージの処理の同時実行を制御するための情報である分散ＩＤと、処理状況を示すステータスと、をテーブルで管理する第１管理手段と、１以上の実行サーバ１０７で並行して処理を実行してもよいメッセージの上限数を分散ＩＤごとに管理する第２管理手段と、を有し、実行サーバ１０７は、キュー１０６から取得したメッセージについて、上限数に達していない分散ＩＤを持つメッセージであれば、該メッセージの処理を実行し、上限数に達している分散ＩＤを持つメッセージであれば、該メッセージをキュー１０６に対して戻す。【選択図】図１
2018120508.tif 000002
【特許請求の範囲】
【請求項１】
１以上のメッセージを管理するキューと、キューからメッセージを取得して処理を実行する複数の処理装置を含むシステムであって、
キューに登録された各メッセージについて、メッセージを一意に識別する識別情報と、メッセージの処理の同時実行を制御するための情報である分散識別情報と、処理状況を示すステータスと、をテーブルで管理する第１管理手段と、
１以上の処理装置で並行して処理を実行してもよいメッセージの上限数を、分散識別情報ごとに、管理する第２管理手段と、を有し、
前記処理装置は、
前記キューに対して要求して取得されたメッセージについて、前記上限数に達していない分散識別情報を持つメッセージであれば、該メッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該メッセージについて処理を実行し、
前記キューに対して要求して取得されたメッセージについて、前記上限数に達している分散識別情報を持つメッセージであれば、該メッセージを前記キューに対して戻すことを特徴とするシステム。
【請求項２】
前記処理装置は、前記キューに対して１度に複数のメッセージを要求し、取得された複数のメッセージの中から、前記上限数に達していない分散識別情報を持つメッセージを１つ決定し、該決定されたメッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該決定されたメッセージについて処理を実行し、さらに、該決定されたメッセージ以外のメッセージを前記キューに対して戻すことを特徴とする請求項１に記載のシステム。
【請求項３】
前記キューからメッセージを取得しようとする処理装置は、自装置以外の前記システムに含まれる稼働中の処理装置で処理が可能なメッセージの数が、前記キューに登録されたメッセージに対応する各分散識別情報の上限数の総和より大きい場合、前記キューに対して要求して取得されたメッセージの分散識別情報の上限数に関わらず、当該取得されたメッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該メッセージについて処理を実行することを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記キューからメッセージを取得しようとする処理装置は、さらに、自装置が前記システムで実行されるスケールアウトにより追加された処理装置であった場合、前記キューに対して要求して取得されたメッセージの分散識別情報の上限数に関わらず、当該取得されたメッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該メッセージについて処理を実行することを特徴とする請求項３に記載のシステム。
【請求項５】
前記第２管理手段は、さらに、分散識別情報ごとの上限数に基づくメッセージの処理の制限を除外するか否かの除外設定情報を管理し、
前記キューからメッセージを取得しようとする処理装置は、さらに、前記除外設定情報において前記上限数の制限を除外する設定がされていると判定した場合、前記キューに対して要求して取得されたメッセージの分散識別情報の上限数に関わらず、当該取得されたメッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該メッセージについて処理を実行することを特徴とする請求項３または４に記載のシステム。
【請求項６】
前記分散識別情報は、前記メッセージの送信元に応じて設定されることを特徴とする請求項１乃至５のいずれか１項に記載のシステム。
【請求項７】
前記処理装置は仮想マシンで実現されることを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
【請求項８】
１以上のメッセージを管理するキューと、キューからメッセージを取得して処理を実行する複数の処理装置を含むシステムの制御方法であって、
キューに登録された各メッセージについて、メッセージを一意に識別する識別情報と、メッセージの処理の同時実行を制御するための情報である分散識別情報と、処理状況を示すステータスと、をテーブルで管理する第１管理工程と、
１以上の処理装置で並行して処理を実行してもよいメッセージの上限数を、分散識別情報ごとに管理する第２管理工程と、
前記キューに対してメッセージを要求して取得する取得工程と、
前記取得工程において取得したメッセージについて、前記上限数に達していない分散識別情報を持つメッセージであるか否か判定する判定工程と、
前記判定工程において、前記上限数に達していない分散識別情報を持つメッセージであると判定された場合に、
該メッセージの識別情報に基づき前記テーブルのステータスを実行中に更新する更新工程と、
該メッセージについて処理を実行する実行工程と、
前記判定工程において、前記上限数に達している分散識別情報を持つメッセージであると判定された場合に、
該メッセージを前記キューに対して戻す返却工程と、を有することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キューのメッセージ処理の制御を実現する情報処理システムに関する。
【背景技術】
【０００２】
クラウドサービス基盤を利用して構築され、１つのシステムで複数の顧客にサービスを提供している情報処理システムがある。その中で、非同期で実行する処理や定期的に実行する処理を、キューを用いた仕組みで実現している情報処理システムがある。
キューを利用する情報処理システムでは、１つのメッセージを処理するために要する時間が、メッセージによって大きく異なる場合がある。例えば、１ヶ月分のデータを出力する処理の場合、顧客が１ヶ月間で登録したデータ数に比例して処理時間が長くなるようなことがある。このような場合、メッセージ毎に処理する時間が同じになるように、予め１つのメッセージを複数のメッセージに分割してキューに登録し、複数のサーバで分散処理するという方法がある。これにより、分散処理をすることで元の１つのメッセージの処理時間を短縮できるとともに、メッセージの処理時間が予想されるためサーバの稼働監視やサーバの増強判断が容易になる。
【０００３】
また、特許文献１には、複数のメッセージを管理するキューを利用する情報処理システムにおいて、緊急度の高いメッセージを検知すると、緊急度の低いメッセージに対する処理の割り当てを制限し、緊急度の高いメッセージに処理を割り当てる技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−３３０７９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、１つの大きなメッセージが多数のメッセージに分割されると、複数のサーバが、分割された多数のメッセージの処理に専有されてしまう。また、テナント単位でデータを管理して複数テナントでコンピューターリソースを共有して提供するシステムでは、データが大きい特定顧客や利用頻度が多い特定の利用者の処理が、関係のない別の顧客の処理時間に影響を与えてしまう恐れがある。
複数テナントでコンピューターリソースを共有して提供する情報処理システムの場合、特許文献１のように顧客や利用者に対して緊急度を定めることは難しく、公平にコンピューターリソースを提供する仕組みが必要となる。
【０００６】
本発明は、顧客間でのサービスの提供の公平性を担保しつつ、メッセージを効率よく処理できるシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のシステムは、１以上のメッセージを管理するキューと、キューからメッセージを取得して処理を実行する複数の処理装置を含むシステムであって、キューに登録された各メッセージについて、メッセージを一意に識別する識別情報と、メッセージの処理の同時実行を制御するための情報である分散識別情報と、処理状況を示すステータスと、をテーブルで管理する第１管理手段と、１以上の処理装置で並行して処理を実行してもよいメッセージの上限数を、分散識別情報ごとに、管理する第２管理手段と、を有し、前記処理装置は、前記キューに対して要求して取得されたメッセージについて、前記上限数に達していない分散識別情報を持つメッセージであれば、該メッセージの識別情報に基づき前記テーブルのステータスを実行中に更新し、該メッセージについて処理を実行し、前記キューに対して要求して取得されたメッセージについて、前記上限数に達している分散識別情報を持つメッセージであれば、該メッセージを前記キューに対して戻す。
【発明の効果】
【０００８】
本発明によれば、顧客間でのサービスの提供の公平性を担保しつつ、メッセージを効率よく処理できるシステムを提供することができる。
【図面の簡単な説明】
【０００９】
【図１】システムの全体構成を示す模式図である。
【図２】情報処理装置の内部構成の一例を示すブロック図である。
【図３】メッセージ登録サーバの機能構成の一例を示すブロック図である。
【図４】メッセージ実行サーバの機能構成の一例を示すブロック図である。
【図５】オートスケール管理サーバの機能構成の一例を示すブロック図である。
【図６】キューに登録するメッセージの一例を示す図である。
【図７】メッセージ登録処理を示すフローチャートである。
【図８】メッセージ実行処理を示すフローチャートである。
【図９】メッセージ実行処理を示すフローチャートである。
【図１０】実施例２におけるメッセージ実行処理を示すフローチャートである。
【図１１】実施例２におけるメッセージ実行処理を示すフローチャートである。
【発明を実施するための形態】
【００１０】
（実施例１）
図１は、システムの全体構成を示す模式図である。
情報処理システム１０１は、Ｗｅｂサーバ１０３、スケジューラー１０４、メッセージ登録サーバ（以下、登録サーバという）１０５、キュー１０６、メッセージ実行サーバ（以下、実行サーバという）１０７を含む。情報処理システム１０１は、さらに、データストア１０８、オートスケール管理サーバ（以下、管理サーバという）１０９を含む。情報端末１０２、Ｗｅｂサーバ１０３、スケジューラー１０４、登録サーバ１０５、キュー１０６、実行サーバ１０７、データストア１０８、管理サーバ１０９は、インターネットなどの既知の技術により相互に通信可能に接続されている。
【００１１】
情報端末１０２は、情報処理システム１０１が提供するサービスを利用するユーザが使用する端末であり、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などの情報端末である。ユーザは、情報処理システム１０１が提供するＷｅｂページを通して、情報処理システム１０１に処理の実行指示をする。
Ｗｅｂサーバ１０３は、ユーザがサービスを利用するためのＷｅｂページを提供する。Ｗｅｂサーバ１０３は、Ｗｅｂページを通してユーザからの処理の実行指示を受信する。そして、指示された処理を実行するためのメッセージの登録要求を、登録サーバ１０５に送信する。
【００１２】
スケジューラー１０４は、定期処理の実行指示をする。定期処理とは、情報処理システム内で管理するデータの定期集計処理や、定期削除処理などである。スケジューラー１０４は、予め設定された定期処理の実行時刻になると、定期処理を実行するためのメッセージの登録要求を、登録サーバ１０５に送信する。
登録サーバ１０５は、メッセージを作成してキューに登録する。登録サーバ１０５は、Ｗｅｂサーバ１０３またはスケジューラー１０４からメッセージ登録要求を受信すると、メッセージを作成し、作成したメッセージをキュー１０６に登録する。
【００１３】
キュー１０６は、登録されたメッセージを管理する。キューは、メッセージの登録、取得の他に、キューの中の未処理のメッセージ数、実行中のメッセージ数を取得するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を持つ。
実行サーバ１０７は、キューに登録されたメッセージを取得し、メッセージで指示された処理を実行する処理装置である。実行サーバ１０７は、一つのキューに対して一台以上存在する。
【００１４】
データストア１０８は、情報処理システムが管理する各種データを格納する。
管理サーバ１０９は、キュー１０６に登録されたメッセージの増減を監視し、予め設定された条件に該当する場合に実行サーバ１０７の台数を増減するオートスケールを行う。オートスケールは、一般的にサーバの負荷に応じて自動的にクラウドサーバーの台数を増減させる機能であり、本実施例では、特定の条件に応じて自動的に実行サーバの台数を増減させる機能である。以下、台数を増やすことをスケールアウト、台数を減らすことをスケールインと呼ぶ。
【００１５】
本実施例では、情報処理システムが実行する所定の処理毎に、すなわち、処理の種類別に、キュー１０６と実行サーバ１０７との組み合わせが、複数存在する例を示す。例えば、データの出力処理を実行するための１つのキューと複数の実行サーバ１０７の組み合わせと、データの集計処理を実行するための１つのキューと複数の実行サーバ１０７の組み合わせは、別とする。さらに、登録サーバ１０５は、複数のキューに対して１台存在し、処理の種類毎にＡＰＩを持つ。したがって、Ｗｅｂサーバ１０３およびスケジューラー１０４は、処理の種類毎に登録サーバ１０５のＡＰＩを判断してメッセージ登録要求を送信する。登録サーバ１０５は、適当な処理単位で複数に分割されてもよい。
【００１６】
図２は、情報端末１０２、Ｗｅｂサーバ１０３、スケジューラー１０４、登録サーバ１０５、キュー１０６、実行サーバ１０７、データストア１０８、管理サーバ１０９を構成する情報処理装置のハードウェア構成の一例を示すブロック図である。なお、登録サーバ１０５や実行サーバ１０７、管理サーバ１０９などは、図２に示すような構成をもつサーバ装置を含むデータセンターにより提供されたリソースを利用した仮想マシンにより実現されてもよい。
【００１７】
情報処理装置は、記憶装置であるハードディスクドライブ（ＨＤＤ）２１０に記憶されたソフトウェアを実行するＣＰＵ２０１を備える。ＣＰＵ２０１は、システムバス２０４に接続される各ハードウェアを総括的に制御する。
メモリー２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。
ＮＩＣ２０３はネットワークインターフェースカードであり、ネットワークを介して、他のノードと双方向にデータをやりとりする。
【００１８】
キーボードコントローラー２０５は、ＰＣに備えられたキーボード２０６からの指示入力を制御する。なお、情報処理装置の役割によっては、キーボードコントローラー２０５、キーボード２０６がない構成でも良い。
ディスプレイコントローラー２０７は、例えば液晶ディスプレイなどで構成される表示モジュール２０８の表示を制御する。なお、情報処理装置の役割によっては、ディスプレイコントローラー２０７、表示モジュール２０８がない構成でも良い。
ディスクコントローラー２０９は、大容量記憶装置であるハードディスクドライブ２１０を制御する。
【００１９】
図３は、登録サーバ１０５の機能構成の一例を示すブロック図である。
要求受信部３０１は、Ｗｅｂサーバ１０３またはスケジューラー１０４からメッセージ登録要求を受信する。メッセージ登録部３０２は、メッセージ登録要求受信後に、要求された処理のメッセージを作成し、キュー１０６にメッセージを登録する。メッセージ登録処理の詳細については後述する。
【００２０】
図４は、実行サーバ１０７の機能構成の一例を示すブロック図である。
メッセージ取得部４０１は、キューに登録されたメッセージを取得する。メッセージ実行部４０２は、メッセージ取得後に、メッセージで指示された処理を実行する。メッセージ削除部４０３は、メッセージ実行後に、実行したメッセージをキューから削除する。メッセージ再登録部４０４は、キューからメッセージ取得後に、処理を実行しなかったメッセージをキューに再登録する。同時実行制御部４０５は、キューに登録されたメッセージと、実行サーバ１０７の台数から、どのメッセージを実行するかを制御する。オートスケール情報取得部４０６は、管理サーバ１０９から実行サーバ１０７のオートスケール情報を取得する。メッセージ実行処理の詳細については後述する。
【００２１】
図５は、管理サーバ１０９の機能構成の一例を示すブロック図である。
オートスケール条件管理部５０１は、実行サーバ１０７をスケールアウト、またはスケールインする条件を管理する。例えば本実施例では、下記のようなオートスケール条件で実行サーバ１０７の台数を増減させる。
・キューの未処理メッセージ数が５分以上１０個以上ならメッセージ実行サーバを７
・キューの未処理メッセージ数が５分以上１５個以上ならメッセージ実行サーバを１０
・キューの未処理メッセージ数が５分以上１０個未満ならメッセージ実行サーバを５
・キューの未処理メッセージ数が５分以上１５個未満ならメッセージ実行サーバを７
【００２２】
稼働監視部５０２は、キュー１０６のメッセージ数や、実行サーバ１０７の台数や稼動状態を監視する。オートスケール実行部５０３は、稼働監視部５０２から取得した情報が、オートスケール条件管理部５０１で管理するオートスケール条件に該当する場合に、実行サーバ１０７に対してオートスケールを実行する。オートスケール情報管理部５０４は、オートスケールの設定と現在の状態を管理する。オートスケール情報管理部５０４で管理する情報については後述する。
オートスケール条件を上記に限定しないことは、当業者には明白であろう。また本実施例では実行サーバ１０７に対してオートスケールを管理しているが、これに限定するものではない。例えばＷｅｂサーバ１０３や登録サーバ１０５に対しても、それぞれ別のオートスケール条件でオートスケールを管理しても良い。
【００２３】
表１は、データストア１０８が保持し、メッセージ登録処理で使用する分割設定情報の構成を示す、メッセージの分割設定テーブルの一例である。本実施例では、登録サーバ１０５が、要求された処理を所定の単位で分割してメッセージを作成し、キューに登録する。分割設定とは、情報処理システムが実行する各種非同期処理や定期実行処理を、どのように分割するかを示す設定である。
【表１】
2018120508.tif 000003
【００２４】
処理ＩＤの列は、情報処理システムが実行する各種非同期処理や定期実行処理などの処理の種類を、システム内で一意に識別するＩＤを格納する。例えば、Ｅｘｐｏｒｔ  Ｄａｔａは、出力処理を行うことを示す処理ＩＤである。
分散ＩＤの列は、実行サーバ１０７が同時実行を制御するための識別情報を格納する。例えば、登録サーバ１０５が処理ＩＤ：“Ｅｘｐｏｒｔ  Ｄａｔａ”のメッセージ登録要求を受けた場合、分散ＩＤに処理対象の顧客ＩＤを設定したメッセージを作成し、キューに登録する。詳細は後述するが、本実施例では、同一の分散ＩＤに対して割り当てる実行サーバ１０７のサーバ台数を制御する。すなわち、分散ＩＤに基づいて、実行サーバ１０７が同時に並行して処理を実行する分散ＩＤが同じメッセージの数を管理する。分散ＩＤは、各種非同期処理や定期実行処理によって、処理対象の顧客ＩＤを指定するか、処理を依頼したユーザＩＤを指定するか、もしくは別の識別子を指定するかを、本テーブルで定義する。顧客ＩＤにより、実行サーバ１０７の台数制御の対象を指定できる。
【００２５】
分割単位の列、１メッセージあたりのデータ数の列は、処理を所定の単位で分割するために使用する情報を格納する。例えば、要求された処理が、データのエクスポート処理（Ｅｘｐｏｒｔ  Ｄａｔａ）で対象データ数が５００，０００件の場合、データ数（分割単位）が１００，０００件（１メッセージあたりのデータ数）ごとにメッセージを５分割する。このとき、分割した各メッセージに同じ顧客ＩＤ（分散ＩＤ）を設定する。
【００２６】
表２は、データストア１０８が保持し、メッセージ登録処理およびメッセージ実行処理で使用するメッセージ管理情報の構成を示す、メッセージ管理テーブルの一例である。メッセージ管理テーブルでは、各メッセージに関する情報を管理する。メッセージ管理テーブルには、少なくとも、メッセージＩＤと、分散ＩＤと、処理状況を示すステータスが含まれ、データストア１０８で管理される（第１管理手段）。本実施例のメッセージ管理テーブルには、さらに、処理ＩＤ、制限動作についての情報も含まれる。利用するキューが分散キューのような場合、実行サーバ１０７からキューの中のメッセージの状態を任意に検索して取得することが難しいため、データストア１０８で管理する。利用するキューによって、キューの中で同様の管理ができる場合、必ずしもデータストア１０８で管理をする必要はない。
【表２】
2018120508.tif 000004
【００２７】
メッセージＩＤの列には、キューの中のメッセージを一意に識別する情報を格納する。メッセージＩＤは、登録サーバ１０５がキューにメッセージを登録した際に、キューにより発行される。本実施例では説明のために連番の数値にしているが、メッセージＩＤに順序性は必要なく、一意性があればＩＤ形式は限定しない。
処理ＩＤの列には、該当行のメッセージ管理情報が、どの種類の処理のメッセージ管理情報かを示す。
分散ＩＤの列には、登録サーバ１０５によって指定された、メッセージの処理の同時実行を制御するための分散識別情報を格納する。表１において、処理ＩＤがＥｘｐｏｒｔ  Ｄａｔａの分散ＩＤには「顧客ＩＤ」が登録されている。そのため、処理ＩＤがＥｘｐｏｒｔ  Ｄａｔａである表２メッセージの分散ＩＤには、メッセージの送信元からの顧客情報に基づき、顧客ＩＤに応じた分散識別情報が登録される。表２では、分散ＩＤに、顧客ごとにＴｅｎａｎｔＡ〜ＴｅｎａｎｔＣが登録されている。
【００２８】
状態の列には、メッセージの状態を格納する。本例では状態として「処理待ち」「処理中」「処理完了」の３つがある。「処理待ち」は、メッセージがキューに登録されてから、キューから取得されて処理が開始されるまでの間の状態を示す。「処理中」は、処理が開始されてから、処理が完了するまでの間の状態を示す。「処理完了」は、処理が完了している状態を示す。状態は、メッセージ登録処理にて登録され、メッセージ実行処理にて更新される。
【００２９】
制限動作の列は、実行サーバ１０７が、当該メッセージに対して後述する同時実行数の制限動作で実行しているか否かを格納する。本実施例では、「Ｔｒｕｅ」「Ｆａｌｓｅ」の２つがある。「Ｔｒｕｅ」は、メッセージ実行サーバが同時実行数の制限動作で実行していることを表し、「Ｆａｌｓｅ」は同時実行数の制限を解除して実行していることを表す。制限動作の解除については、図８のＳ８０２〜Ｓ８０４においてその詳細を説明する。
【００３０】
表３は、データストア１０８が保持し、メッセージ実行処理で使用する同時実行数情報の構成を示す、同時実行管理テーブルの一例である。
【表３】
2018120508.tif 000005
【００３１】
処理ＩＤの列には、情報処理システムが実行する各種非同期処理や定期実行処理などの処理の種類をシステム内で一意に識別するＩＤを格納する。
同時実行数の列には、分散ＩＤが同じメッセージに対して、メッセージ実行サーバが同時に、すなわち、並行して処理を実行してもよい上限数を格納する。したがって、データストア１０８は、同じ分散ＩＤのメッセージを、並行して処理を実行してもよい同時実行の上限数を管理する（第２管理手段）。例えば、処理ＩＤがＥｘｐｏｒｔ  Ｄａｔａの場合、実行サーバ１０７は分散ＩＤが同じメッセージに対して、最大で２台まで同時実行する。表２のメッセージ管理状態の場合、状態の列より、メッセージＩＤ＝００２と００３が同時実行されて、分散ＩＤ＝TenantAのメッセージは同時実行数の２に達している。そこで実行サーバ１０７は、分散ＩＤ＝TenantAのメッセージ（メッセージＩＤ＝００４と００５）は処理せず、分散ＩＤが異なるメッセージ（メッセージＩＤ＝００６〜００８）を処理対象の候補とする。
【００３２】
表４は、データストア１０８が保持し、管理サーバ１０９で使用するオートスケール情報の構成を示す、オートスケール管理テーブルの一例である。
【表４】
2018120508.tif 000006
【００３３】
オートスケールＩＤの列は、オートスケール情報を一意に識別する情報を格納する。
紐付け対象の列は、該当行のオートスケール情報を、何のサーバ群に紐付けるかを格納する。例えば、オートスケールＩＤ＝300ff5ccの行は、Ｅｘｐｏｒｔ  Ｄａｔａを実行するメッセージ実行サーバ群に紐付いている。
最小数の列は、紐付け対象のサーバ群の最小のサーバ台数を格納し、最大数の列は、紐付け対象のサーバ群の最大のサーバ台数を格納する。
【００３４】
希望数の列は、その種類の処理を行うことが可能な、現在起動している稼働中のサーバ台数を格納する。オートスケール実行部５０３は、紐付け対象のサーバ群が、希望数と同じ台数になるようにオートスケールを実行する。例えば、オートスケールＩＤ＝300ff5ccの行では、４台から１０台の間でオートスケール条件に応じて希望数を変更し、オートスケール実行部５０３が、Ｅｘｐｏｒｔ  Ｄａｔａ実行サーバ群の台数を希望数と同じになるように制御する。逆に言うと、オートスケール管理情報の希望数を参照することで、処理を実行可能な現在のサーバ群の台数を確認できる。
【００３５】
図６は、キューに登録するメッセージの一例を示す図である。メッセージには、実行サーバ１０７が処理内容を判断できる情報を含める。本実施例のメッセージは、メッセージＩＤ６０１、分散ＩＤ６０２、処理ＩＤ６０３、対象データ６０４を含む。対象データ６０４は、該当メッセージが処理対象とするデータ数を示す。
【００３６】
図７は、登録サーバ１０５が実行するメッセージ登録処理の手順例を示すフローチャートである。本処理は、登録サーバ１０５の要求受信部３０１が、Ｗｅｂサーバ１０３またはスケジューラー１０４からメッセージ登録要求を受信した際に実行する処理である。登録サーバ１０５の機能構成の各構成要素は、図２に示した情報処理装置のＣＰＵ２０１、メモリー２０２、ハードディスクドライブ２１０などからなる。フローチャートで示す手順は、各構成要素のメモリー２０２、ハードディスクドライブ２１０のいずれかの記憶手段に記憶され、ＣＰＵ２０１により実行される。
【００３７】
メッセージ登録処理を開始するとＳ７０１で、メッセージ登録部３０２は、要求された処理に該当する分割設定を取得する。取得する分割設定は、例えば表１に示される情報である。
続いてＳ７０２で、メッセージ登録部３０２は、Ｓ７０１で取得した分割設定、すなわち、分散ＩＤ情報、分割設定の分割単位情報、１メッセージあたりのデータ数情報に基づき、処理を分割してメッセージを作成する。
【００３８】
続いてＳ７０３で、メッセージ登録部３０２は、Ｓ７０２で作成したメッセージをキュー１０６に登録する。キュー１０６に複数メッセージを一括登録するＡＰＩがある場合は、分割された複数のメッセージを一括して登録して、登録処理を高速化してもよい。
続いてＳ７０４で、メッセージ登録部３０２は、作成したメッセージのメッセージ管理情報を、Ｓ７０３でキュー１０６に発行されたメッセージＩＤと共に、メッセージ管理テーブルに登録する。メッセージ管理テーブルは、例えば、表２で示されるテーブルである。ここで、登録するメッセージ管理情報の状態情報は、処理待ちとする。
【００３９】
上記のように、メッセージ登録の処理において、メッセージを分割した場合も、複数回登録要求を受信した場合も、分割設定で指定された分散ＩＤを各メッセージに設定する。実行サーバ１０７が分散ＩＤに対して同時実行数を制御することで、特定顧客の大きな処理が多数のメッセージに分割された場合や、特定の利用者が高頻度で処理要求した場合も、実行サーバ１０７が同時実行数以上、専有されるのを抑制することができる。
【００４０】
図８及び図９は、実行サーバ１０７が実行するメッセージ実行処理の手順例を示すフローチャートである。本処理は、実行サーバ１０７がキュー１０６に登録されているメッセージを確認し、取得可能なメッセージがある際に実行する処理である。本処理では、メッセージ実行サーバは、通常時はＳ８０５〜Ｓ８０９で後述するように、分散ＩＤが同じメッセージに対して同時に処理を実行する数を制御する。これにより、特定の処理要求に対して、実行サーバが専有されることを防ぎ、他のメッセージを処理することができる。一方で、キューに特定のメッセージが存在し、且つメッセージ実行サーバが余剰している状況で、同時実行数の制限により処理をしない状態を作ってしまうと、逆にメッセージの処理の効率を下げてしまう。そこで、Ｓ８０２〜Ｓ８０４で後述するように、メッセージ実行サーバが余剰している状態かを判定し、余剰していると判定された場合は同時実行数の制限を除外して、任意のメッセージを処理する。これにより、メッセージ実行サーバが余剰している場合は、特定のメッセージであっても処理をすることで、メッセージの処理効率を上げることができる。
【００４１】
実行サーバ１０７の機能構成の各構成要素は、図２に示した情報処理装置のＣＰＵ２０１、メモリー２０２、ハードディスクドライブ２１０などからなる。なお、フローチャートで示す手順が、各構成要素のメモリー２０２、ハードディスクドライブ２１０のいずれかの記憶手段に記憶され、ＣＰＵ２０１により実行される。
【００４２】
メッセージ実行処理を開始すると、Ｓ８０１で、オートスケール情報取得部４０６は、管理サーバ１０９から、実行サーバ１０７に紐付けられたオートスケール管理情報を取得する。取得するオートスケール管理情報は、例えば、表４のオートスケール管理テーブルに登録されている情報である。
【００４３】
続いてＳ８０２で、同時実行制御部４０５は、Ｓ８０１で取得したオートスケール管理情報から、現在、実行サーバ１０７がスケールアウトされた状態であるか否か、すなわち、スケールアウトにより追加された実行サーバがあるかを判定する。具体的には、取得したオートスケール管理情報で、希望数が最小数より大きい場合は、スケールアウトされた状態と判定する。スケールアウト状態と判定した場合はＳ８０３に進み、スケールアウト状態ではないと判定した場合はＳ８０５に進む。図５で述べたように、一般にオートスケールの条件は、キューのメッセージ数など、同時実行制御とは関係がない。その為、後述する表７の例のように、特定の顧客のメッセージが大量に登録された場合にもオートスケールの条件に合致し、実行サーバの台数が増えてしまう。Ｓ８０２の判定により、スケールアウトされたときに実行サーバが非効率に余剰していないかを判断することができる。
【００４４】
続いてＳ８０３で、同時実行制御部４０５は、余剰している実行サーバ１０７が存在するかを判定する。処理の同時実行が可能な上限数の処理を行ってもなお、メッセージを取得して処理を行える稼働中の実行サーバ１０７が存在する場合に、余剰している実行サーバ１０７が存在すると判定する。言い換えると、キューからメッセージを取得しようとする処理装置は、キューに登録されたメッセージに対応する複数の分散ＩＤごとの上限数の総和に対応する数のメッセージを自装置以外の稼働中の実行サーバ１０７で処理可能な場合、余剰している実行サーバ１０７であると判定される。実行サーバ１０７が余剰している場合はＳ８０４に進み、余剰していないと判定した場合はＳ８０５に進む。
【００４５】
以下、Ｓ８０３の判定処理の具体的な方法を、表５、表６を用いて例示する。また、このときの実行サーバ１０７の台数は５台で、同時実行数は２とする。
最初に、同時実行制御部４０５は、以下の３つの値を取得、算出する。
１.［実行サーバの台数］：オートスケール管理情報の希望数
２.［処理完了していない分散ＩＤ］：メッセージ管理テーブルの状態情報が処理中、または処理待ちのメッセージに対応する分散ＩＤ
３.［分散ＩＤごとの同時実行可能数］：２.の各分散ＩＤに対応する同時実行管理テーブルの同時実行数。但し、状態情報が処理中、または処理待ちのメッセージが同時実行数未満のときは、そのメッセージ数。
次に、同時実行制御部４０５は、取得、算出した値に基づいて、実行サーバが余剰しているか判定する。具体的には、「［実行サーバの台数］＞Σ［分散ＩＤごとの同時実行可能数］」が成立する時に、実行サーバ１０７が余剰していると判定する。
【００４６】
表５は、メッセージ実行サーバが余剰していない状態である。例えば表５の状態の場合、３つの値はそれぞれ以下となる。
１.［実行サーバの台数］：５
２.［処理完了していない分散ＩＤ］：TenantA、TenantB、TenantC
３.［分散ＩＤごとの同時実行可能数］：TenantAは２、TenantBは２、TenantCは１
【表５】
2018120508.tif 000007
【００４７】
表５の状態では、実行サーバの台数＝５、分散ＩＤごとの同時実行可能数の総和＝２＋２＋１＝５となる。このとき、「［実行サーバの台数］＞Σ［分散ＩＤごとの同時実行可能数］」の関係を満たさないため、同時実行制御部４０５は、実行サーバ１０７は余剰していないと判定する。つまり、同時実行数の制限の中で、メッセージＩＤ＝１０７、ないし１０８を処理すべきである。
【００４８】
表６は、メッセージ実行サーバが余剰している状態である。例えば表６の状態の場合、３つの値はそれぞれ以下となる。
１.［実行サーバの台数］：５
２.［処理完了していない分散ＩＤ］：TenantA、TenantC
３.［分散ＩＤごとの同時実行可能数］：TenantAは２、TenantCは１
【表６】
2018120508.tif 000008
【００４９】
表６の状態では、実行サーバの台数＝５、分散ＩＤごとの同時実行可能数の総和＝２＋１＝３となる。このとき、「［実行サーバの台数］＞Σ［分散ＩＤごとの同時実行可能数］」の関係を満たすため、同時実行制御部４０５は、実行サーバ１０７は余剰していると判定する。つまり、実行サーバ１０７の４台目と５台目は、同時実行数の制限のために処理を行えないで余剰している状態となっている。
また、上記の余剰の判定では、１台の実行サーバで処理可能なメッセージ数を１として計算した。しかしながら、各実行サーバは複数のメッセージを取得して同時に処理するよう設計することも可能である。つまり、「［各実行サーバの１度に処理可能なメッセージ数］×［実行サーバの台数］＞Σ［分散ＩＤごとの同時実行可能数］」といった条件を用いて、余剰の判定を行ってもよい。
なお、上記の余剰を判定するための式は実行サーバ１０７の余剰を判定するための一例であり、それらの式のみに限定されるものではない。
【００５０】
実行サーバ１０７の余剰があると、キューに登録されているメッセージの処理の効率を下げてしまう。そこで、実行サーバ１０７が余剰状態の場合のみ、同時実行数の制限を除外する。例えば、表６のメッセージＩＤが２０４、ないし２０５のメッセージを処理の対象とする。一方で、Ｓ８０３で余剰と判断された実行サーバ１０７が、すべて特定のメッセージを処理してしまうと、新たに分散ＩＤが異なる別のメッセージが登録された時に、そのメッセージに対する処理の開始が遅れてしまう。
【００５１】
そこで続いてＳ８０４で、同時実行制御部４０５は、自装置が、すなわち本処理を実行するメッセージ実行サーバ１０７が、スケールアウトによって増えた（追加された）サーバであるかを判定する。スケールアウトによって増えたサーバであると判定した場合は、Ｓ８１０に進む。一方で、スケールアウトで増えたサーバではないと判定した場合は、Ｓ８０５に進む。
【００５２】
以下、Ｓ８０４の判定処理の具体的な方法を、表７を用いて例示する。このときのメッセージ実行サーバの台数は、スケールアウトにより４から７台に増えており、同時実行数は２とする。表７は、スケールアウトされたメッセージ実行サーバが存在する状態である。
【表７】
2018120508.tif 000009
【００５３】
最初に、同時実行制御部４０５は、以下の２つの値を導出する。
Ａ.［実行サーバの余剰数］：オートスケール管理情報の希望数から、メッセージ管理テーブルの処理中のメッセージ数を減算した値
Ｂ.［実行サーバ数の待機数］：オートスケール管理情報の最小数から、メッセージ管理テーブルの制限動作で処理中のメッセージ数を減算した値
続いて、同時実行制御部４０５は、「［メッセージ実行サーバの余剰数］＞［メッセージ実行サーバ数の待機数］」が成立する時に、スケールアウトされたメッセージ実行サーバであると判定する。
【００５４】
例えば表７の状態の場合、２つの値はそれぞれ以下となる。
Ａ.［実行サーバの余剰数］：３（希望数:７−処理中: ４）
Ｂ.［実行サーバ数の待機数］：２（最小数:４−制限動作で処理中: ２）
この場合、「（［実行サーバの余剰数］：３）＞（［実行サーバ数の待機数］：２）」の関係を満たすため、同時実行制御部４０５は、余剰サーバがスケールアウトによって増えた実行サーバ１０７であると判定する。
一方で、仮にメッセージＩＤが４０５のメッセージが、制限情報がＦＡＬＳＥで処理中だった場合、［実行サーバの余剰数］は２となり、上記の式を満たさない。この場合は、余剰サーバがスケールアウトされていない実行サーバ１０７と判定する。余剰サーバである２台の実行サーバ１０７は待機状態になり、分散ＩＤがTeantA以外のメッセージが登録された際に、すぐに処理を開始することができる。なお、上記の式はメッセージ実行サーバがスケールアウトで増えたサーバか否かを判定するための一例であり、これに限定されるものではない。
Ｓ８０４の判定により、同時実行数の制限を除外して処理する場合も、オートスケール管理情報の最小数の実行サーバ１０７は、新たな別のメッセージを処理するために待機させておくことができ、特定メッセージへ処理が偏ることを防ぐことができる。
【００５５】
Ｓ８０２〜Ｓ８０４の判定処理で、同時実行制御部４０５が、同時実行数の制限を除外して動作すると判定した場合、Ｓ８１０でメッセージ取得部４０１は、キューから任意のメッセージを１つ取得する。同時実行数の制限を除外するため、分散ＩＤや同時実行数に配慮することなく、任意のメッセージを取得する。
【００５６】
続いてＳ８０５〜Ｓ８０９で、実行サーバ１０７の同時実行数の制限処理について説明する。
まずＳ８０５で、メッセージ取得部４０１はキューから１度に複数のメッセージを取得する。キューの仕様によって変わるが、本実施例では例えば１０個のメッセージを一括取得する。複数のメッセージを取得する理由は、以降のＳ８０６〜Ｓ８０９の処理を１つのメッセージずつ繰り返すよりも効率的で、処理を高速化できるためである。
【００５７】
続いてＳ８０６で、同時実行制御部４０５は、取得した複数のメッセージの中から分散ＩＤが同時実行数未満のメッセージを１つ決定するために、取得した複数のメッセージの分散ＩＤと、メッセージ管理テーブルの情報を比較する。
続いてＳ８０７で、同時実行制御部４０５は、分散ＩＤが同時実行数未満のメッセージが存在するかを判定し、存在する場合はＳ８０９に進み、存在しない場合はＳ８０８に進む。
【００５８】
続いてＳ８０８で、同時実行制御部４０５はキューの中に別のメッセージが存在するかを判定する。具体的な判定方法の例として、Ｓ８０５で１０個のメッセージを取得要求して、１０個未満がキューから取得された場合に、別のメッセージは存在しないと判定する。別のメッセージが存在すると判定した場合は、Ｓ８０５に進み、Ｓ８０５以降の処理を繰り返す。一方で、別のメッセージが存在しないと判定した場合は、処理を終了し、一定の待機時間を経た後に、Ｓ８０１から処理を始める。
【００５９】
続いてＳ８０９で、決定した分散ＩＤが同時実行数未満の１つのメッセージ以外のメッセージを、キューに再登録する。複数のメッセージを一括して再登録することで、再登録処理を効率化してもよい。Ｓ８０５〜Ｓ８０９の処理は、キューから同時実行数未満のメッセージを取得する方法の一例であり、これに限定されるものではない。例えば、検索条件に合致するメッセージを返却できるキューの場合、予めメッセージ管理テーブルから処理対象のメッセージを選定し、キューに検索条件として指定して取得することで、選定処理を効率化してもよい。
【００６０】
Ｓ８１１で、メッセージ実行部４０２はＳ８１０、またはＳ８０６で選定されたメッセージについて、メッセージ管理テーブルの状態情報を、処理待ちから処理中に変更する。
続いてＳ８１２で、メッセージ実行部４０２は、メッセージで指示された処理を実行する。
そして、Ｓ８１２の処理が終了すると、Ｓ８１３で、メッセージ実行部４０２は、メッセージ管理テーブルのメッセージの状態情報を処理完了に変更する。
続いてＳ８１４で、メッセージ削除部４０３は、Ｓ８１２で実行したメッセージをキューから削除し、Ｓ８０１に戻り別のメッセージを処理する。
【００６１】
以上説明したように、本実施例では、分散ＩＤが同じメッセージに対して同時に処理を実行する数を制御する。そのため、特定の顧客からの処理要求に対して、実行サーバが専有されることを防ぎ、他のメッセージを処理することができる。これにより、各顧客へのサービスの提供に不公平さがでるのを抑制することができる。
【００６２】
（実施例２）
実施例１では、スケールアウト状態を条件に、余剰しているメッセージ実行サーバが同時実行制御の除外することで、キューのメッセージ処理を効率化した。一方で、運用や設計の理由から、オートスケールでメッセージ実行サーバの台数を増減していない場合もある。実施例２では、オートスケールで台数を増減していない場合に、キューのメッセージ処理を効率化する方法を示す。なお、以下では実施例１との差分について説明する。
【００６３】
表８は、実施例２におけるオートスケール情報の構成の一例を示す、オートスケール管理テーブルである。
【表８】
2018120508.tif 000010
実施例２のようにオートスケールによって台数を増減しない場合も、表８のように最小数、最大数、希望数を同じ値に設定したオートスケール情報を設定する。これにより、もしメッセージ実行サーバが何らかの原因でクラッシュした場合に、管理サーバ１０９の稼働監視部５０２が検知して、オートスケール実行部５０３が別のメッセージ実行サーバを起動して、希望数を保つことができる。
【００６４】
表９は、実施例２における同時実行管理テーブルの構成の一例を示す、同時実行管理テーブルである。
【表９】
2018120508.tif 000011
処理ＩＤ、同時実行数の列は、実施例１で示した通りである。
【００６５】
除外設定の列には、実行サーバ１０７が余剰している状態の時に、同時実行数の制限を除外して実行するかの除外設定情報を格納する。例えば、定常的に要求される処理の場合は、除外設定をＯＦＦにすることで、メッセージ実行サーバが一時的に余剰していても、近いうちに登録される新しいメッセージに備えることができる。一方で、散発的に要求される処理の場合は、除外設定をＯＮにすることで、余剰したメッセージ実行サーバを同時実行数の制限を除外して、メッセージを効率的に処理することができる。
【００６６】
図１０及び図１１は、実施例２における実行サーバ１０７が実行するメッセージ実行処理の手順例を示すフローチャートである。実行サーバ１０７の機能構成の各構成要素は、図２に示した情報処理装置のＣＰＵ２０１、メモリー２０２、ハードディスクドライブ２１０などからなる。フローチャートで示す手順が、各構成要素のメモリー２０２、ハードディスクドライブ２１０のいずれかの記憶手段に記憶され、ＣＰＵ２０１により実行される。
【００６７】
Ｓ９０１で、同時実行制御部４０５は、同時実行管理テーブルから除外設定が設定されているかを判定する。除外設定がＯＮの場合はＳ８０１へ進み、ＯＦＦの場合はＳ８０５へと進む。メッセージ実行処理を行う実行サーバ１０７が、処理ＩＤがＥｘｐｏｒｔ  Ｄａｔａのサーバである場合、表９を例にすると、除外設定がＯＮになっているため、Ｓ８０１に進む。一方、処理ＩＤがＩｍｐｏｒｔ  Ｄａｔａのサーバである場合、表９を例にすると、除外設定がＯＦＦになっているため、Ｓ８０５に進む。
図１０及び図１１に記載のＳ８０１〜Ｓ８１４については、実施例１で述べた通りである。実施例１と比較して、オートスケールで台数を増減していない本実施例では、スケールアウトを同時実行数の除外条件にしていないため、Ｓ８０２やＳ８０４のスケールアウトに関する判定がない。なお、Ｓ９０１の除外設定に関する判定を行う本実施例をオートスケールで台数を増減する情報処理システムに適用してもよく、この場合は、スケールアウトに関するＳ８０２やＳ８０４の判定を行うようにしてもよい。
【００６８】
実施例２で述べたように、オートスケールでメッセージ実行サーバを増減していない場合も、メッセージに対してメッセージ実行サーバが余剰している場合は、同時実行数の制限を除外して効率的にメッセージを処理することができる。また、処理ごとに除外設定を設定することで、メッセージ実行サーバの余剰時の動作を、処理の特徴に応じて変えることができる。
【００６９】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００７０】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
2018120508.tif 000012
【図２】
2018120508.tif 000013
【図３】
2018120508.tif 000014
【図４】
2018120508.tif 000015
【図５】
2018120508.tif 000016
【図６】
2018120508.tif 000017
【図７】
2018120508.tif 000018
【図８】
2018120508.tif 000019
【図９】
2018120508.tif 000020
【図１０】
2018120508.tif 000021
【図１１】
2018120508.tif 000022