JP7098280B2 - 情報処理システム、および制御方法 - Google Patents

Description

本発明は、キューに登録されたメッセージに基づく処理を実行する情報処理システム、および制御方法に関する。

クラウドサービス基盤を利用して構築され、顧客にサービスを提供している情報処理システムがある。また、非同期で実行する処理や定期的に実行する処理を、キューを用いた仕組みで実現している情報処理システムがある。クラウドサービス基盤を利用して構築された情報処理システムでは、すべての顧客について実行する定期処理がある。例えば、顧客のデータの定期集計処理などである。定期集計処理は、サービスが管理する顧客数の増加に伴い、処理対象のデータが増加し、処理に要する時間が増加する。

特許文献１には、キューに登録されたメッセージ数に応じて、メッセージに対する処理を実行するサーバーの数を増減する技術が開示されている。これによれば、システムへの処理要求数に応じてクラウド資源（サーバー）を増減することで、クラウド資源を適正に利用でき、コストが削減できる。

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

前述した集計処理のような処理では、処理を実行するサーバーがデータベースにクエリーを発行することで処理を実行する。顧客のデータを、データベースの顧客ごとの専用の記憶領域であるテナントで管理しているシステムにおいては、処理対象のデータに対応するテナントごとに処理が行われることが一般的である。したがって、処理対象のデータに対応するテナントの数に比例して、処理時間が長くなる。このような場合、処理を実行するサーバーの数の増加に伴い、データベースへのクエリー発行数も増加し、データベースの負荷が高くなる。ここで、データベースは、処理を実行するサーバーとは異なり、動的に（システムを停止させずに）数を増加することや、性能を上げることが困難である。したがって、定期集計のような処理においては、処理対象のデータに対応するテナントの数に応じて、処理を実行するサーバーの数を増加させるだけでは、処理に要する時間が長くかかるという課題を解決できない。

本発明は、複数のデータの処理において、処理対象のデータに対応するテナントごとに処理を実行する場合と比較して、処理時間を短くするための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、複数顧客のデータを、データベースの顧客ごとの専用の記憶領域である複数テナントを用いて管理する管理手段と、処理対象のデータの処理のためのリクエストを受信する受信手段と、前記受信したリクエストに対応する処理対象のデータが、前記複数テナントにわたった一括処理がされないデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される１テナントへのアクセスが必要となる第１処理を実行するための第１メッセージをキューに登録し、前記受信したリクエストに対応する処理対象のデータが、前記複数テナントのうちの予め決められた２以上のテナントにわたった一括処理がされるデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される前記２以上のテナントそれぞれへのアクセスが必要となる第２処理を実行するための１つの第２メッセージを前記キューに登録する登録手段と、前記キューに登録されたメッセージを取得する取得手段と、前記取得したメッセージが前記第１メッセージである場合、当該第１メッセージに基づき、前記データベースの前記１テナントへのアクセスが必要となる前記第１処理を実行し、前記取得したメッセージが前記第２メッセージである場合、当該第２メッセージに基づき、前記データベースの前記２以上のテナントそれぞれへのアクセスが必要となる前記第２処理を実行する実行手段と、を有することを特徴とする。

本発明によれば、複数のデータの処理において、処理対象のデータに対応するテナントごとに処理を実行する場合と比較して、処理時間を短くすることができる。

本発明の実施形態におけるシステムの全体構成の一例を示す図 情報処理装置のハードウェア構成の一例を示す図 集計指示サーバー１０５の機能構成の一例を示す図 データロードサーバー１０７の機能構成の一例を示す図 データ集計サーバー１０９の機能構成の一例を示す図 集計指示処理の手順例を示すフローチャート データロード処理の手順例を示すフローチャート リトライメッセージ登録処理の手順例を示すフローチャート データ集計処理の手順例を示すフローチャート 実施例２におけるデータロード処理の手順例を示すフローチャート 実施例２におけるリトライメッセージ登録処理の手順例を示すフローチャート

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

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

図１において、１０１は情報処理システムである。情報処理システム１０１は、クラウドサービス基盤を利用して構築され、顧客にサービスを提供するシステムである。クラウドサービスでは、クラウドサービスベンダが、ネットワークを介して、仮想マシンやキュー、ストレージなどのコンピューターリソースをクラウドサービス利用者に提供する。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。

情報処理システム１０１は、Ｗｅｂサーバー１０３、スケジューラー１０４、集計指示サーバー１０５、データロードキュー１０６、データロードサーバー１０７を含む。さらに、情報処理システム１０１は、データ集計キュー１０８、データ集計サーバー１０９、ファイルサーバー１１０、データベース１１１も含む。情報処理システム１０１に含まれるこれらの要素は、クラウドサービスベンダによって提供されるコンピューターリソースとしての仮想マシンやキュー、ストレージを用いて、それぞれの機能が実現される。

ここで、情報処理システム１０１において、顧客の情報はそれぞれ、データベース１１１内の専用の記憶領域であるテナントで管理される。ユーザーが管理システムで管理される情報にアクセスする場合には、自分の所属する顧客のテナントで保持されているデータにしかアクセスできず、他のテナントへのアクセスを制限される。

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

Ｗｅｂサーバー１０３は、ユーザーがサービスを利用するためのＷｅｂページを提供する。Ｗｅｂサーバー１０３は、Ｗｅｂページを通してユーザーからの処理の実行要求を受信する。実行要求された処理が集計処理の場合、Ｗｅｂサーバー１０３はユーザーの所属する顧客の集計要求を集計指示サーバー１０５に送信する。なお、Ｗｅｂサーバー１０３は複数存在しても良い。

スケジューラー１０４は、定期処理の実行要求をする。定期処理とは定期間隔で実行する処理を示す。スケジューラー１０４は、予め設定された定期処理の実行時刻になると、定期処理を実行するための実行要求を行う。定期集計処理の場合、スケジューラー１０４は定期集計要求を集計指示サーバー１０５に送信する。なお、定期集計処理とは、情報処理システムで管理している全ての顧客を対象とする処理である。

集計指示サーバー１０５は、集計処理を実行するためのメッセージを作成してデータロードキュー１０６に登録する。集計指示サーバー１０５は、Ｗｅｂサーバー１０３またはスケジューラー１０４から集計要求を受信すると、処理対象の顧客（複数指定も可）のデータを含むデータロード要求メッセージを作成し、データロードキュー１０６に登録する。なお、集計指示サーバー１０５は複数存在しても良い。

データロードキュー１０６は、登録されたデータロード要求メッセージを管理する。データロードキュー１０６は、メッセージが取得された際に所定時間が経過するまでメッセージを不可視状態にする（以下、この所定時間を不可視時間と呼ぶ）。

データロードキュー１０６に格納されるメッセージは、キューから取得されるだけではキューから削除されたことはならない。キューから取得されたメッセージは、他の処理サーバーから取得されないように一時的に不可視状態となる。その後、データロードサーバー１０７によるメッセージの処理が完了した後、キューに対して該メッセージを削除するための指示が行われる。

不可視状態により、あるデータロードサーバーがメッセージを処理している際に、他のデータロードサーバーが同一のメッセージを取得して、そのメッセージに基づく処理を実行しないように制御できる。また、データロードサーバー１０７がキューからメッセージを削除した後の一定時間の間に、キューに対して該メッセージの削除指示が行われない場合には、該メッセージは不可視状態が解除され、いずれのデータロードサーバーによっても取得可能な状態となる。なお、キューに対して設定する不可視時間は、メッセージの処理に要する時間や処理失敗時のリトライ間隔を考慮し、各処理で適切な値を設定する。

データロードサーバー１０７は、データロードキュー１０６に登録されたメッセージを取得し、データロード処理を実行する。データロード処理とは、集計処理で使用するデータを、集計処理で使用するデータベースにロードする処理を示す。つまり、データロード処理は、データロードキューから取得したメッセージに基づき、処理対象のデータに対応するテナントを参照するためにデータベースへアクセスする処理を指す。ここで、処理対象が複数のデータである場合には、複数のデータに対応する、それぞれ異なるテナントを参照するためにデータベースへのアクセスが必要となる。データロード処理を、複数のテナントへの一括処理とも呼ぶ。データロード処理後、後続処理であるデータ集計処理を実行するため、データロードサーバー１０７は処理対象の顧客の情報を含むデータ集計要求メッセージを作成し、データ集計キュー１０８に登録する。なお、データロードサーバー１０７は複数存在しても良い。また、データロードサーバー１０７は、データロードキュー１０６に格納されるメッセージの数またはデータロードサーバー１０７の処理負荷に基づき、自動で台数が調整されるものとする。

データ集計キュー１０８は、登録されたデータ集計要求メッセージを管理する。

データ集計サーバー１０９は、データ集計キュー１０８に登録されたメッセージを取得し、データ集計処理を実行する。なお、データ集計サーバー１０９は複数存在しても良い。また、データ集計サーバー１０９は、データ集計キュー１０８に格納されるメッセージの数またはデータ集計サーバー１０９の処理負荷に基づき、自動で台数が調整されるものとする。

ファイルサーバー１１０は、情報処理システムが管理する各種データファイルを格納する。

データベース１１１は、情報処理システムが管理する各種データを格納する。データベース１１１は、顧客のデータを、顧客ごとの専用の記憶領域であるテナントを用いて管理している。また、データベース１１１は、クエリーを受信してクエリーの結果を返信する。

以上説明した１０２乃至１１１の各部は、インターネットなどの既知の技術により相互に通信可能に接続されている。

＜情報処理装置の内部構成＞
図２は、情報処理装置のハードウェア構成の一例を示す図である。本実施例における情報処理装置としては、情報端末１０２や、情報処理システム１０１を実現するためのデータセンター上に存在するサーバーコンピューターなどが該当する。

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

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

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

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

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

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

なお、以降で説明する各機能は、情報処理システム１０１が構築されるサーバーコンピューターのＨＤＤ２１０に記憶されているプログラムを、ＣＰＵ２０１がメモリー２０２に読み出して実行することによって実現される。

＜集計指示サーバーの機能構成＞
図３は、集計指示サーバー１０５の機能構成の一例を示す図である。

３０１は集計要求受信部であり、Ｗｅｂサーバー１０３またはスケジューラー１０４から集計要求を受信する。３０２は集計指示実行部であり、集計要求受信後に、集計指示処理を実行し、データロード要求のためのメッセージを作成する。３０３はメッセージ登録部であり、作成したメッセージをデータロードキュー１０６に登録する。集計指示処理の詳細については後述する。

＜データロードサーバーの機能構成＞
図４は、データロードサーバー１０７の機能構成の一例を示す図である。

４０１はメッセージ取得部であり、データロードキュー１０６に登録されたメッセージを取得する。４０２はデータロード実行部であり、メッセージ取得後に、データロード処理を実行する。また、データロード実行部４０２は、データロード処理後にデータ集計要求メッセージを作成する。さらに、データロード実行部４０２は、図８を用いて後述するリトライ用のメッセージを作成して、データロードキュー１０６に登録する。４０３はメッセージ登録部であり、作成したメッセージをデータ集計キュー１０８に登録する。４０４はメッセージ削除部であり、処理実行後に、実行したメッセージをデータロードキュー１０６から削除する。データロード処理の詳細については後述する。

＜データ集計サーバーの機能構成＞
図５は、データ集計サーバー１０９の機能構成の一例を示す図である。

５０１はメッセージ取得部であり、データ集計キュー１０８に登録されたメッセージを取得する。５０２はデータ集計実行部であり、メッセージ取得後に、データ集計処理を実行する。５０３はメッセージ削除部であり、処理実行後に、実行したメッセージをデータ集計キュー１０８から削除する。データ集計処理の詳細については後述する。

＜集計指示処理＞
図６は、集計指示サーバー１０５が実行する集計指示処理の手順例を示すフローチャートである。Ｗｅｂサーバー１０３またはスケジューラー１０４から集計要求を受信した際に、本処理が開始する。本処理では、受信した集計要求をもとに、集計処理を実行するためのメッセージ（データロード要求メッセージ）を作成してキューに登録する。データロード処理とは、集計処理で使用するデータを、集計処理で使用するデータベースにロードする処理である。データロード処理は、顧客ごとに処理するよりも、複数の顧客を一括処理する方が、効率が良い処理である。さらに、データロード処理では、顧客ごとの設定に依存しないため、対象の全ての顧客に対して一括処理を行うことができる。そのため、本処理では、受信した集計要求をもとに、複数顧客を一括処理するか否かを判断する。そして、複数顧客を一括処理すると判断した場合は、一括処理可能な顧客をグループ化し、顧客グループごとの処理要求メッセージを作成する。これにより、データロード処理は複数顧客を一括処理することになり、処理時間の顧客数への依存度を減らすことができる。

集計指示を開始するとＳ６０１で、集計指示実行部３０２は、受信した集計要求をもとに、処理対象のデータが所定の条件を満たすか否かに基づいて、複数顧客を一括処理するか否かを判定する。本実施例では、受信した集計要求での処理対象のデータが所定の条件を満たすとして、定期的な集計要求での処理対象となるデータである場合は一括処理すると判定する。ここで、集計指示実行部３０２が、複数顧客を一括処理すると判定した場合はＳ６０２に進む。一方、集計指示実行部３０２が、複数顧客を一括処理しない、つまり顧客ごとに処理すると判定した場合はＳ６０６に進む。

続いてＳ６０２で、集計指示実行部３０２は、システムで管理する全ての顧客を、一括処理可能な単位でグループ分けする。なお、処理対象の顧客は、システムで管理する全顧客のうちの一部であっても良い。例えば、顧客によってデータが格納されているデータベーススキーマやテーブルが異なるような場合は、同一のスキーマやテーブルにデータが格納されている顧客を同一のグループにする。

続いてＳ６０３で、集計指示実行部３０２は、Ｓ６０２で作成した顧客グループの内、Ｓ６０３～Ｓ６０５のフローを未処理の顧客グループについて、一顧客グループずつ処理を繰り返す。

続いてＳ６０４で、集計指示実行部３０２は、処理中の顧客グループのデータロード要求メッセージを作成する。本処理では、一括処理が可能な複数顧客の一括処理を要求するための一つのメッセージを作成する。本処理で作成するデータロード要求メッセージの一例（ＪＳＯＮ形式）を以下に示す。例では、一括処理可能な複数顧客の情報を、顧客ＩＤの配列で指定している。顧客ＩＤとは、顧客をシステム内で一意に識別するＩＤである。
｛
“ｃｕｓｔｏｍｅｒｓ”： ［
“１００”，
“１１０”，
“１２０”
］
｝

続いてＳ６０５で、集計指示実行部３０２は、Ｓ６０３～Ｓ６０５の処理を行っていない顧客グループがあるか否かを判定する。ここで、集計指示実行部３０２が、Ｓ６０３～Ｓ６０５の処理を行っていない顧客グループがあると判定した場合はＳ６０３に戻り処理を繰り返す。一方、集計指示実行部３０２が、Ｓ６０３～Ｓ６０５の処理を行っていない顧客グループがないと判定した場合はＳ６０７に進む。

一方Ｓ６０６で、集計指示実行部３０２は、受信した集計要求の顧客のデータロード要求メッセージを作成する。本処理では、一つのメッセージで一顧客の処理を要求するメッセージを作成する。

続いてＳ６０７で、メッセージ登録部３０３は、Ｓ６０４またはＳ６０６で作成したメッセージをデータロードキュー１０６に登録し、本処理を終了する。

＜データロード処理＞
図７は、データロードサーバー１０７が実行するデータロード処理の手順例を示すフローチャートである。本処理は、データロードサーバー１０７がデータロードキュー１０６に登録されているメッセージを確認し、取得可能なメッセージがある際に実行する処理である。データロード処理とは、集計処理で使用するデータを、集計処理で使用するデータベースにロードする処理である。データロード処理は、顧客ごとに処理するよりも、複数顧客を一括処理する方が、効率が良い処理である。さらに、データロード処理は、顧客ごとの設定に依存しない、つまりすべての顧客で同一の処理である。そのため、本処理内のデータロードを実行する処理は、顧客ごとではなく複数顧客を一括処理する。これにより、処理時間の顧客数への依存度を減らすことができる。さらに、データロード処理後に後続処理であるデータ集計処理を実行するため、データロードサーバー１０７は、データ集計要求メッセージを作成し、データ集計キュー１０８に登録する。データ集計処理は、データロード処理とは異なり、顧客ごとの設定に依存する、そのため、データ集計要求メッセージは、顧客ごとに作成する。

データロード処理を開始するとＳ７０１で、メッセージ取得部４０１は、取得可能なメッセージをデータロードキュー１０６から１つ取得する。

続いてＳ７０２で、データロード実行部４０２は、Ｓ７０１で取得したメッセージで指定されている処理対象の顧客の内、Ｓ７０２～Ｓ７０４のフローを未処理の顧客について、一顧客ずつ処理を繰り返す。ここでの処理は、Ｓ７０５で後述する複数顧客についてのデータロード処理の実行前に行われる処理である。

続いてＳ７０３で、データロード実行部４０２は、処理中の顧客それぞれの集計状態を「実行中」に変更する。ここで表Ａは、データベース１１１が保持し、データロード処理およびデータ集計処理で使用する集計状態情報の構成の一例を示す、集計状態テーブルである。本テーブルは、該当レコードがどの顧客の集計状態情報かを示す顧客ＩＤカラムを備える。さらに本テーブルは、顧客の集計状態を示す状態カラムを備える。本例では状態として「実行中」と「未実行」の２つがある。「実行中」は、集計に関する処理が開始されてから、完了するまでの間の状態を示す。「未実行」は、集計に関する処理が実行されていない状態を示す。本処理では、処理中の顧客の集計状態が「未実行」の場合のみ「実行中」に変更される。処理中の顧客の集計状態が「実行中」の場合は、処理中の顧客の処理が失敗したと判定する。これにより、複数のサーバーが同一顧客の処理を同時に実行しないように制御できる。なお、集計状態が「実行中」の顧客について、顧客の処理が失敗した判定された後、一定時間経過した後には、「未実行」に戻すものとする。これにより、その後の顧客の処理がリトライ可能となる。

続いてＳ７０４で、データロード実行部４０２は、Ｓ７０２～Ｓ７０４の処理を行っていない顧客があるか否かを判定する。ここで、データロード実行部４０２が、Ｓ７０２～Ｓ７０４の処理を行っていない顧客があると判定した場合はＳ７０２に戻り処理を繰り返す。一方、データロード実行部４０２が、Ｓ７０２～Ｓ７０４の処理を行っていない顧客がないと判定した場合はＳ７０５に進む。

続いてＳ７０５で、データロード実行部４０２は、Ｓ７０１で取得したメッセージで指定された処理対象の複数顧客について、データロード処理を一括実行する。具体的には、ファイルサーバー１１０が格納する集計対象のデータファイルを、データベース１１１にロードする処理である。このとき、ロード対象データファイルは、例えば、前回の定期的な集計処理後に追加や更新された差分である。そのため、ロード対象データファイルを示す設定として、前回の定期的な集計処理が行われた日時（すべての顧客で同一）を指定する。つまり、本処理は顧客ごとの設定に依存しない処理である。

続いてＳ７０６で、データロード実行部４０２は、Ｓ７０１で取得したメッセージで指定されている処理対象の顧客の内、Ｓ７０６～Ｓ７１０のフローを未処理の顧客について、一顧客ずつ処理を繰り返す。

続いてＳ７０７で、データロード実行部４０２は、処理中の顧客の集計状態を未実行に変更する。

続いてＳ７０８で、データロード実行部４０２は、処理中の顧客のデータ集計要求メッセージを作成する。なお、本処理は、処理中の顧客がＳ７０３の処理で失敗した場合、またはＳ７０５の処理が失敗した場合は実行されない。

続いてＳ７０９で、メッセージ登録部４０３は、Ｓ７０８で作成したメッセージをデータ集計キュー１０８に登録する。なお、本処理は、処理中の顧客がＳ７０３の処理で失敗した場合、またはＳ７０５の処理が失敗した場合は実行しない。

続いてＳ７１０で、データロード実行部４０２は、Ｓ７０６～Ｓ７１０の処理を行っていない顧客があるか否かを判定する。ここで、データロード実行部４０２が、Ｓ７０６～Ｓ７１０の処理を行っていない顧客があると判定した場合はＳ７０６に戻り処理を繰り返す。一方、データロード実行部４０２は、Ｓ７０６～Ｓ７１０の処理を行っていない顧客がないと判定した場合はＳ７１１に進む。

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

続いてＳ７１２で、データロード実行部４０２は、Ｓ７０３、Ｓ７０５、Ｓ７０８、Ｓ７０９の処理がすべて成功したか否かを判定する。ここで、データロード実行部４０２は、処理がすべて成功したと判定した場合は、Ｓ７０１に戻り別のメッセージを処理する。一方、データロード実行部４０２は、処理のいずれかが失敗したと判定した場合はＳ７１３に進む。

続いてＳ７１３で、データロード実行部４０２は、リトライ用のメッセージをデータロードキュー１０６に登録し、Ｓ７０１に戻り別のメッセージを処理する。リトライメッセージ登録処理の詳細については後述する。

なお、処理対象の顧客それぞれについての前処理（Ｓ７０３）で失敗した場合には、一括処理（Ｓ７０５）が行われなくても良い。一方、処理対象の顧客それぞれについての前処理（Ｓ７０３）で成功した後に一括処理（Ｓ７０５）で失敗した場合には、処理対象の顧客それぞれについての後処理（Ｓ７０７～Ｓ７０９）は行われるものとする。

＜リトライメッセージ登録処理＞
図８は、図７に示したＳ７１３で実行するリトライメッセージ登録処理の詳細手順例を示すフローチャートである。リトライメッセージ登録処理とは、データロード処理のいずれかが失敗した場合に、リトライするためのメッセージをデータロードキューに登録する処理である。データロード処理には、顧客ごとに行われる個別処理と、複数顧客の一括処理がある。顧客ごとの処理が失敗した場合は、失敗した顧客のみリトライする方が効率的である。また、複数顧客の一括処理が失敗した場合は、処理対象のすべての顧客についてリトライする必要がある。そのため、本処理では、顧客ごとの処理で失敗したか、複数顧客の一括処理で失敗したかにもとづき、リトライ方法を変更する。これにより、複数顧客の一括処理が含まれる処理について、効率良くリトライできる。

リトライメッセージ登録処理を開始するとＳ８０１で、データロード実行部４０２は、複数顧客の一括処理（Ｓ７０５）が失敗したか否かを判定する。ここで、データロード実行部４０２が、複数顧客の一括処理が失敗したと判定した場合はＳ８０２に進む。一方、データロード実行部４０２が、複数顧客の一括処理は失敗していない、つまり、複数顧客の一括処理は成功しており且つ顧客ごとに行われる個別処理（Ｓ７０３、Ｓ７０８、Ｓ７０９）が失敗したと判定した場合はＳ８０３に進む。

続いてＳ８０２で、データロード実行部４０２は、Ｓ７０１で取得したメッセージをリトライ用のメッセージとして、データロードキュー１０６に登録し、本処理を終了する。複数顧客の一括処理で失敗した場合は、処理対象のすべての顧客についてリトライが必要である。そのため、処理対象のすべての顧客の処理を要求するメッセージ（Ｓ７０１で取得したメッセージ）をリトライ用のメッセージとする。

一方Ｓ８０３で、データロード実行部４０２は、顧客ごとの処理が失敗した顧客のみの処理を要求するメッセージを作成する。つまり、顧客ごとの処理が失敗した複数顧客の一括処理を要求する一つのメッセージを作成する。

続いてＳ８０４で、データロード実行部４０２は、Ｓ８０３で作成したメッセージをリトライ用のメッセージとして、データロードキュー１０６に登録し、本処理を終了する。

なお、複数顧客の一括処理および顧客ごとの処理のいずれも失敗した場合は、Ｓ８０１でＹｅｓに進み、Ｓ８０２の処理が行われる。

＜データ集計処理＞
図９は、データ集計実行部５０２が実行するデータ集計処理の手順例を示すフローチャートである。本処理は、データ集計サーバー１０９がデータ集計キュー１０８に登録されているメッセージを確認し、取得可能なメッセージがある際に実行する処理である。本処理では、集計クエリーをデータベース１１１に送信し、返信されたクエリー結果を集計結果として保存する。例えば、顧客の締め日の設定をもとに、データを月単位で集計する。そのため、データ集計処理は、データロード処理とは異なり、顧客ごとの設定に依存する処理である。よって、データ集計処理は、複数顧客を一括処理できず、顧客ごとに処理する必要がある。

データ集計処理を開始するとＳ９０１で、メッセージ取得部５０１は、取得可能なメッセージをデータ集計キュー１０８から１つ取得する。

続いてＳ９０２で、データ集計実行部５０２は、顧客の集計状態を実行中に変更する。本処理では、顧客の集計状態が「未実行」の場合のみ「実行中」に変更する。顧客の集計状態が「実行中」の場合は、対象顧客の処理が失敗したと判定する。

続いてＳ９０３で、データ集計実行部５０２は、顧客のデータ集計処理を実行する。続いてＳ９０４で、データ集計実行部５０２は、顧客の集計状態を未実行に変更する。続いてＳ９０５で、メッセージ削除部５０３は、Ｓ９０１で取得したメッセージをデータ集計キュー１０８から削除する。

続いてＳ９０６で、データ集計実行部５０２は、Ｓ９０２、Ｓ９０３の処理がすべて成功したか否かを判定する。ここで、データ集計実行部５０２が、処理がすべて成功したと判定した場合は、Ｓ９０１に戻り別のメッセージを処理する。一方、データ集計実行部５０２が、処理のいずれかが失敗したと判定した場合はＳ９０７に進む。

続いてＳ９０７で、データ集計実行部５０２は、Ｓ９０１で取得したメッセージをリトライ用のメッセージとして、データ集計キュー１０８に登録し、本処理を終了する。

本実施例では、集計指示サーバー１０５が、複数顧客を一括処理するためのメッセージを作成してデータロードキュー１０６に登録し、データロードサーバー１０７がそのメッセージに基づく一括処理を行った。本実施例によれば、複数顧客の処理において一括処理を行うことで、顧客ごとに処理を行う場合と比べて、処理時間を短縮することが可能となる。

（実施例２）
実施例１のメッセージをキューから取得して実行する処理では、処理の成功・失敗に関わらず、取得したメッセージをキューから削除し、リトライが必要な場合にリトライ用のメッセージをキューに再登録するリトライ方法を示した。本実施例では、不可視時間経過後にメッセージが可視状態になるというキューの特性を使用した、別のリトライ方法を示す。なお、以下では実施例１との差分について説明する。

＜データロード処理＞
図１０は、実施例２におけるデータロードサーバー１０７が実行するデータロード処理の手順例を示すフローチャートである。本処理は、実施例１の図７で示したデータロード処理を変更したものである。実施例２では、不可視時間経過後にメッセージが可視状態になるというキューの特性を使用した、別のリトライ方法を示す。そのため、処理の成功・失敗に関わらず、取得したメッセージをキューから削除していた処理（Ｓ７１１）以降を変更している。

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

Ｓ１００１で、データロード実行部４０２は、Ｓ７０３、Ｓ７０５、Ｓ７０８、Ｓ７０９の処理がすべて成功したか否かを判定する。ここで、データロード実行部４０２は、処理がすべて成功したと判定した場合はＳ１００２に進む。一方、データロード実行部４０２は、処理のいずれかが失敗したと判定した場合はＳ１００３に進む。

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

続いてＳ１００３で、データロード実行部４０２は、リトライ用のメッセージをデータロードキュー１０６に登録し、Ｓ７０１に戻り別のメッセージを処理する。実施例２におけるリトライメッセージ登録処理の詳細については後述する。

＜リトライメッセージ登録処理＞
図１１は、図１０に示したＳ１００３で実行する実施例２におけるリトライメッセージ登録処理の詳細手順例を示すフローチャートである。本処理は、実施例１の図８で示したリトライメッセージ登録処理を変更したものである。実施例２では、不可視時間経過後にメッセージが可視状態になるというキューの特性を使用した、別のリトライ方法を示す。

データロード処理における複数顧客の一括処理（Ｓ７０５）で失敗した場合は、データロードキューからそのメッセージを削除しないようにする。すると、不可視時間経過後にメッセージが可視状態になり、処理対象の複数顧客についての一括処理がリトライされる。

一方、データロード処理における顧客ごとの処理（Ｓ７０３、Ｓ７０７～Ｓ７０９）が失敗した場合は、失敗した顧客のみリトライする方が効率的である。よって、本処理では、顧客ごとの処理が失敗した場合は、メッセージをキューから削除し、失敗した顧客のみリトライする新規メッセージを作成して登録する。

リトライメッセージ登録処理を開始するとＳ１１０１で、データロード実行部４０２は、複数顧客の一括処理（Ｓ７０５）が失敗したか否かを判定する。ここで、データロード実行部４０２が、複数顧客の一括処理が失敗していない、つまり、顧客ごとの処理（Ｓ７０３．Ｓ７０７～Ｓ７０９）で失敗したと判定した場合には、Ｓ１１０２に進む。一方、データロード実行部４０２が、複数顧客の一括処理で失敗したと判定した場合は本処理を終了する。複数の一括処理が失敗した場合は、不可視時間経過後にメッセージが可視状態になることで、処理対象のすべての顧客についてリトライできる。

続いてＳ１１０２で、メッセージ削除部４０４は、Ｓ７０１で取得したメッセージをデータロードキュー１０６から削除する。続いてＳ１１０３で、データロード実行部４０２は、顧客ごとの処理が失敗した顧客のみの処理を要求するメッセージを作成する。つまり、顧客ごとの処理が失敗した複数顧客の一括処理を要求する一つのメッセージを作成する。

続いてＳ１１０４で、データロード実行部４０２は、Ｓ１１０３で作成したメッセージをリトライ用のメッセージとして、データロードキュー１０６に登録し、本処理を終了する。

本実施例では、複数顧客の一括処理で失敗した場合には、データロードキューからそのメッセージを削除しないようにした。これにより、不可視時間経過後にメッセージが可視状態になるというキューの特性を使用して、効率良くリトライできる。

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

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

１０１ 情報処理システム
１０５ 集計指示サーバー

Claims (13)

1. 複数顧客のデータを、データベースの顧客ごとの専用の記憶領域である複数テナントを用いて管理する管理手段と、
   処理対象のデータの処理のためのリクエストを受信する受信手段と、
   前記受信したリクエストに対応する処理対象のデータが、前記複数テナントにわたった一括処理がされないデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される１テナントへのアクセスが必要となる第１処理を実行するための第１メッセージをキューに登録し、前記受信したリクエストに対応する処理対象のデータが、前記複数テナントのうちの予め決められた２以上のテナントにわたった一括処理がされるデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される前記２以上のテナントそれぞれへのアクセスが必要となる第２処理を実行するための１つの第２メッセージを前記キューに登録する登録手段と、
   前記キューに登録されたメッセージを取得する取得手段と、
   前記取得したメッセージが前記第１メッセージである場合、当該第１メッセージに基づき、前記データベースの前記１テナントへのアクセスが必要となる前記第１処理を実行し、前記取得したメッセージが前記第２メッセージである場合、当該第２メッセージに基づき、前記データベースの前記２以上のテナントそれぞれへのアクセスが必要となる前記第２処理を実行する実行手段と、を有することを特徴とする情報処理システム。
2. 前記第２処理は、前記データベースの前記２以上のテナントそれぞれへのアクセスが必要となる一括処理であることを特徴とする請求項１に記載の情報処理システム。
3. 前記第１処理は、前記複数テナントにわたった一括処理ではなく、前記データベースの前記１テナントへのアクセスが必要となる処理であることを特徴とする請求項１または２に記載の情報処理システム。
4. 前記キューに登録されたメッセージの数または前記実行手段の処理負荷に基づき、前記実行手段の数が調整されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記キューに対して、前記取得したメッセージを削除するための指示を行う指示手段を更に有し、
   前記指示手段は、前記実行手段による処理が終了した後、前記取得したメッセージを削除するための指示を行い、
   前記指示に応じて、前記取得したメッセージが前記キューから削除されることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記実行手段は、前記２以上のテナントにわたった一括処理に失敗した場合、前記取得したメッセージを前記キューに登録することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
7. 前記実行手段は、前記取得したメッセージが前記第２メッセージである場合に、当該第２メッセージに基づき、前記２以上のテナントそれぞれへのアクセスが必要となる一括処理の実行前または実行後に、前記２以上のテナントそれぞれへの個別処理を行うことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記実行手段は、前記２以上のテナントへの一括処理に成功し、かつ、前記２以上のテナントそれぞれへの個別処理の少なくとも一部に失敗した場合、該失敗した個別処理のみを再び行うためのメッセージを作成し、該作成したメッセージを前記キューに登録することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 前記キューに対して、前記取得したメッセージを削除するための指示を行う指示手段を更に有し、
   前記指示手段は、前記２以上のテナントへの一括処理および前記２以上のテナントそれぞれへの個別処理のいずれも成功した場合に、前記キューに対して前記取得したメッセージを削除するための指示を行い、
   前記指示手段による前記指示に応じて、前記取得したメッセージが前記キューから削除されることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
10. 前記指示手段は、前記２以上のテナントへの一括処理に失敗した場合、前記キューに対して前記取得したメッセージを削除するための指示を行わず、
    前記取得したメッセージは、前記実行手段が該メッセージを取得してから一定時間経過した後に、前記実行手段により取得可能となることを特徴とする請求項９に記載の情報処理システム。
11. 前記第２処理の処理対象の複数のデータは、定期的な集計処理の対象となるデータであることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理システム。
12. 前記受信したリクエストに対応する処理対象のデータが前記複数テナントのうちの予め決められた２以上のテナントにわたった一括処理されるデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される前記２以上のテナントに対応する複数顧客をグループ化するグループ化手段を更に有し、
    前記登録手段は、前記グループ化された複数顧客に対応する前記２以上のテナントそれぞれへのアクセスが必要となる第２処理を実行するための前記第２メッセージを前記キューに登録することを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理システム。
13. 複数顧客のデータを、データベースの顧客ごとの専用の記憶領域である複数テナントを用いて管理する管理工程と、
    処理対象のデータの処理のためのリクエストを受信する受信工程と、
    前記受信したリクエストに対応する処理対象のデータが、前記複数テナントにわたった一括処理がされないデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される１テナントへのアクセスが必要となる第１処理を実行するための第１メッセージをキューに登録し、前記受信したリクエストに対応する処理対象のデータが、前記複数テナントのうちの予め決められた２以上のテナントにわたった一括処理がされるデータである場合、前記受信したリクエストに対応する処理対象のデータが管理される前記２以上のテナントそれぞれへのアクセスが必要となる第２処理を実行するための１つの第２メッセージを前記キューに登録する登録工程と、
    前記キューに登録されたメッセージを取得する取得工程と、
    前記取得したメッセージが前記第１メッセージである場合、当該第１メッセージに基づき、前記データベースの前記１テナントへのアクセスが必要となる前記第１処理を実行し、前記取得したメッセージが前記第２メッセージである場合、当該第２メッセージに基づき、前記データベースの前記２以上のテナントそれぞれへのアクセスが必要となる前記第２処理を実行する実行工程と、を有することを特徴とする情報処理システムの制御方法。

Images