JP6280237B2 - 計算機システム及びデータ処理方法 - Google Patents

Description

本発明は、概して、処理要求のデータの処理に関する。

処理要求のデータの処理に関し、例えば特許文献１に開示の装置が知られている。特許文献１に開示の装置は、トランザクションを所定のブロック毎に分割して処理する。

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

ところで、ビッグデータ等のデータの処理のための分散システムが知られている。分散システムは、一般に、複数の物理計算機（例えば物理サーバ）を有する。

分散システムは、複数の処理要求を処理するが、処理（処理要求）の優先順位（例えば処理に要する時間の制約）が同じとは限らない。例えば、オンライン処理とバッチ処理がある。オンライン処理は、レイテンシ性能の求められる処理であり、例えば、オンラインで受けた処理要求（例えばデータＩ／Ｏ要求）の処理である。一方、バッチ処理は、比較的長い処理時間が許容される処理であり、例えば、複数データに対する纏まった処理を一括して実行するような処理（具体的には、例えば、物理計算機の追加又は削除によるデータマイグレーション、物理計算機内のデータの集計、又は、複数データの消去）である。従って、一般的に、オンライン処理はバッチ処理よりも優先順位が高い。

安定したオンライン処理性能を維持する方法として、特許文献１のトランザクション分割技術に基づきバッチ処理を分割して行う方法が考えられる。

しかし、特許文献１は、単一の装置でのトランザクション分割を開示しているものの、複数の物理計算機の各々でのデータ処理を開示も示唆もしていない。２以上の物理計算機においてデータの一貫性を保つことが必要な環境において、２以上の物理計算機の各々が独立してバッチ処理を分割して行うと、データの一貫性を必ずしも保てない。

この種の問題は、オンライン処理とバッチ処理以外の優先順位の異なる複数の処理についても存在し得る。また、この種の問題は、複数の物理計算機で構成された分散システムに限らず、複数のプロセスの各々が処理要求のデータを処理する他種のシステムにも存在し得る。

計算機システムが、処理要求を実行する複数のプロセスと、制御部と、全順序配信部とを備える。制御部は、第一の処理要求より優先順位の低い第二の処理要求の実行を決定したとき、予め定められた分割サイズに従い第二の処理要求を基に分割第二処理要求を作成する。全順序配信部は、１以上の第二の処理要求に対応した１以上の分割第二処理要求と１以上の第一の処理要求とのうちの少なくとも１つを含んだ１以上の処理要求の実行順序を決定し、複数のプロセスに、それぞれ、決定された実行順序で１以上の処理要求を実行させる。

「プロセス」は、物理計算機でもよいし、仮想計算機でもよいし、物理計算機又は仮想計算機内のプロセッサでもよいし、プロセッサにより実行されるプログラムでもよい。

制御部及び全順序配信部は、複数のプロセスのうちの少なくとも１つの各々に含まれていてもよいし（例えば、全てのプロセスの各々が、制御部及び全順序配信部を有していてよいし）、複数のプロセス以外（例えば、複数のプロセス以外のプロセス）に存在してもよい。

「分割サイズ」は、ユーザ（例えば管理者）から指定されたサイズでもよいし、分割前に所定の情報を基に算出されたサイズでもよい。

複数のプロセスの各々で、１以上の第二の処理要求に対応した２以上の分割第二処理要求と２以上の第一の処理要求とを含んだ複数の処理要求が、同じ実行順序で実行される。これにより、複数のプロセスで同じ結果が得られ、故に、データの一貫性が保証される。

実施形態に係る情報システムの構成を示す。 第一サーバ計算機及び第二サーバ計算機において行われる処理の概要を示す。 比較例と実施形態との比較の概要の一例を示す。 比較例と実施形態との比較の具体例を示す。 データストアの構成を示す。 分割バッチ要求の構成を示す。 分割バッチ履歴テーブルの構成を示す。 バッチ管理テーブルの構成を示す。 バッチ実行中画面の一例である。 バッチ実行結果画面の一例である。 要求制御部の動作のフローチャートである。 分割部の動作のフローチャートである。 全順序配信部の動作のフローチャートである。 分割サイズ決定の第一の観点を示す。 分割サイズ決定の第二の観点を示す。 バッチ終了時刻が入力された場合に行われる処理の一例を示す。

以下、プロセスとしてサーバ計算機（物理計算機の一例）を例に取り、一実施形態を説明する。

なお、以下の説明では、「ｋｋｋテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「ｋｋｋテーブル」のうちの少なくとも１つを「ｋｋｋ情報」と呼ぶことができる。各テーブルの構成は一例であり、２以上のテーブルが１つのテーブルにまとめられたり、１つのテーブルが複数のテーブルに分割されたりしてもよい。

また、以下の説明では、「ｋｋｋ部」の表現にて処理部（機能）を説明することがあるが、処理部は、コンピュータプログラムがプロセッサ（例えばＣＰＵ（Central Processing Unit）によって実行されることで実現されてもよいし、ハードウェア回路（例えばＦＰＧＡ（Field Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））によって実現されてもよい。プログラムがプロセッサによって処理部が実現される場合、定められた処理が、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェイスデバイス（例えば通信ポート）等を用いながら行われるため、処理部はプロセッサの少なくとも一部とされてもよい。処理部を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースからプロセッサにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記憶メディアであってもよい。各処理部の説明は一例であり、複数の処理部が１つの処理部にまとめられたり、１つの処理部が複数の処理部に分割されたりしてもよい。

図１は、実施形態に係る情報システムの構成を示す。

情報システム１００は、計算機システムの一例であるサーバシステム１０１と、サーバシステム１０１に通信ネットワーク１７１を介して接続されたクライアントシステム１０３と、サーバシステム１０１の管理システム１１２とを有する。

クライアントシステム１０３は、複数（又は１つ）のクライアント計算機１１３である。本実施形態では、クライアント計算機１１３は、物理計算機であるが、仮想計算機であってもよい。クライアント計算機１１３は、アプリケーション１８１と、データ送受信部１８３とを有する。アプリケーション１８１が、データ送受信部１８３を介して、サーバシステム１０１に処理要求をオンラインで送信する。以下、オンラインで送信された処理要求を、「オンライン要求」と言う。サーバシステム１０１は、オンライン要求を処理し、処理結果（例えば、ライト処理の結果、又は、リード処理の結果（例えば、リード処理に従い読み出されたデータを含む））を、オンライン要求の応答としてクライアント計算機１１３に返す。

管理システム１１２は、１以上の計算機で構成されたシステムであり、例えば、管理計算機、又は、管理計算機と管理計算機から出力された表示用情報が表す情報を表示する表示用計算機との組合せである。すなわち、管理システム１１２は、少なくとも１つの計算機が表示デバイスを有し、サーバシステム１０１からの情報を表示デバイスに表示する。

サーバシステム１０１は、複数のサーバ計算機１１１で構成されている。本実施形態では、サーバシステム１０１は、分散key-valueストア（分散ＫＶＳ）でありＰａｘｏｓアルゴリズムに従い処理を行う分散合意システムである。サーバシステム１０１は、そのような分散システムに代えて、他種の分散システムでもよいし、他種の計算機システムでもよい。

各サーバ計算機１１１は、ネットワークＩ／Ｆ（通信インターフェースデバイス）１２２、主記憶デバイス１２４、補助記憶デバイス１２３、それらに接続されたプロセッサ１２１を有する。主記憶デバイス１２４及び補助記憶デバイス１２３が、記憶資源の一例である。以下、複数のサーバ計算機１１１のうちの任意の１つのサーバ計算機１１１を「第一サーバ計算機１１１Ａ」と言い、第一サーバ計算機１１１Ａを例に取る。そして、第一サーバ計算機１１１Ａとの間でデータの一貫性を保つべき１以上の他の計算機を、それぞれ、「第二サーバ計算機１１１Ｂ」と言う。第二サーバ計算機１１１Ｂは、例えば、第一サーバ計算機１１１Ａが保存するkey-value（キーとそれに属する値）セットと同一のkey-valueセット（第一サーバ計算機１１１Ａが保存するkey-valueの複製）を保存する計算機である。なお、各サーバ計算機１１１は、第一サーバ計算機１１１Ａになることもあれば第二サーバ計算機１１１Ｂになることもあり得る。

ネットワークＩ／Ｆ１２２は、通信ネットワーク１７１を介してクライアントシステム１０３（クライアント計算機１１３）からオンライン要求を受信する。補助記憶デバイス１２３は、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）のような不揮発性の記憶デバイスである。補助記憶デバイス１２３は、例えば、データストア（複数のkey-value）を有する。プロセッサ１２１は、主記憶デバイス１２４にロードされたコンピュータプログラムを実行することにより処理部を実現する。処理部として、例えば、制御部１３２（要求制御部１５１及び分割部１５２を含む）、モニタ部１３１、全順序配信部１３３、入力部１３４及び出力部１３５がある。また、主記憶デバイス１２４は、分割履歴テーブル１４１及びバッチ管理テーブル１４２（後述）を記憶する。分割履歴テーブル１４１及びバッチ管理テーブル１４２は、いずれかの処理部に含まれていてもよい。

要求制御部１５１は、オンライン要求及びバッチ要求を受け付ける。オンライン要求は、第一の処理要求の一例であり、クライアント計算機１１３からネットワークＩ／Ｆ１２２を介して受信された処理要求（例えばデータの入出力（Ｉ／Ｏ）要求）である。バッチ要求は、第一の処理要求より優先順位の低い第二の処理要求の一例であり、バッチで処理されるデータの処理要求である。本実施形態は、オンライン処理性能の低下を軽減するために、オンライン要求がバッチ要求より優先される。以下、オンライン要求の処理対象のデータを、「オンラインデータ」と言い、１つのオンライン要求の処理（１つのオンライン要求に対応したオンラインデータの処理）を「オンライン処理」と言う。また、以下、バッチ要求の処理対象のデータを「バッチデータ」と言い、バッチデータの処理を「バッチ処理」と言う。オンライン要求のソースは、クライアント計算機１１３のようなネットワーク上のノード（サーバシステム１０１と通信可能な計算機）でよく、バッチ要求のソースは、クライアント計算機１１３、サーバシステム１０１の管理計算機（図示せず）、サーバ計算機１１１内部のプログラム等でよい。要求制御部１５１は、オンライン要求を受けた場合、そのオンライン要求を全順序配信部１３３に送る。要求制御部１５１は、バッチ要求を受け付けた場合、分割部１５２に分割バッチ要求の作成を依頼する。要求制御部１５１は、その依頼に応答して作成された分割バッチ要求を、全順序配信部１３３に送る。なお、要求制御部１５１は、バッチ要求の分割を必ずしも分割部１５２に依頼しないでもよい。

分割部１５２は、モニタ部１３１からのモニタ結果情報を基にバッチの分割サイズを決定する。分割部１５２は、要求制御部１５１からの依頼に応答して、決定した分割サイズに従いバッチ要求を基に分割バッチ要求を作成する。１つの分割バッチ要求は、１つのバッチ要求の処理対象のバッチデータを構成する分割データ（バッチデータ部分）に対応している。分割データのサイズは、例えば、分割サイズと同じサイズである。分割サイズは、１つのバッチ要求につき固定であってもよいし可変であってもよい。分割サイズの決定（変更）は、要求制御部１５１からの分割依頼の都度に行われてもよいし、要求制御部１５１からの分割依頼無しに（例えば定期的に）行われてもよい。分割部１５２は、分割バッチ要求が作成される都度に分割バッチ要求を要求制御部１５１へ送る。なお、分割部１５２は、必ずしもバッチ要求を分割しないでもよい。

モニタ部１３１は、処理要求の実行及びサーバ負荷状況等を監視する。モニタ部１３１は、モニタ結果を示す情報であるモニタ結果情報を出力する。モニタ結果情報は、例えば、処理要求毎の進捗を示す情報と、サーバ負荷状況を示す情報とを含んでよい。処理要求毎の進捗は、例えば、処理要求毎のステータス（未実行、実行中、完了等）、処理要求毎の開始時刻及び終了時刻を含んでよい。サーバ負荷状況は、例えば、少なくとも第一サーバ計算機１１１Ａの負荷状況（例えば、第一サーバ計算機１１１Ａ（及び第二サーバ計算機１１１Ｂ）のリソース使用率（例えばプロセッサ使用率））を含む。このようなモニタ結果情報又はそれの蓄積から、空き時間、オンライン処理所要時間、オンライン処理間隔等の検出又は算出が可能である。モニタ結果情報は、主記憶デバイス１２４及び補助記憶デバイス１２３の少なくとも１つを含む記憶資源に蓄積されてよい。なお、「空き時間」は、オンライン処理が行われていない期間、具体的には、例えば、オンライン処理間隔又は許容レイテンシ時間とオンライン処理所要時間との差分である。「オンライン処理所要時間」は、１つのオンライン処理（１つのオンライン要求の処理）にかかる時間である。「オンライン処理間隔」は、Ｎ番目（Ｎは１以上の整数）のオンライン処理の開始から（Ｎ＋１）番目のオンライン処理の開始までの時間である。「許容レイテンシ時間」は、オンライン処理所要時間の許容値である。モニタ結果情報の出力先は、少なくとも１つの処理部であってもよいし、少なくとも１つの処理部が参照可能な記憶資源（例えば主記憶デバイス１２４又は補助記憶デバイス１２３）でもよい。

全順序配信部１３３は、要求制御部１５１からの複数の処理要求（１以上のバッチ要求に対応した２以上の分割バッチ要求と、２以上のオンライン要求とを含む）の実行順序を決定する。例えば、全順序配信部１３３は、例えばＦＩＦＯ（First-In First-Out）形式のキューを管理しており、全順序配信部１３３が要求制御部１５１からの処理要求（例えばオンライン要求又は分割バッチ要求）を受信した順番通りにキューに投入することで、複数の処理要求の実行順序が決まってよい。或いは、全順序配信部１３３は、要求制御部１５１からの処理要求を所定数又は一定期間蓄積し、蓄積されている複数の処理要求の実行順序を、後述のポリシ（例えばバッチ要求の終了時刻）及びモニタ結果情報のうちの少なくとも一部を基に決定してよい。これにより、ポリシを満たすような実行順序を決定することができる。全順序配信部１３３は、制御部１３２（例えば要求制御部１５１）と第二サーバ計算機１１１Ｂとに、決定した実行順序で複数の処理要求を実行させる。具体的には、例えば、全順序配信部１３３は、Ｐａｘｏｓアルゴリズムに従い、複数の処理要求とそれの実行順序とを表す情報を含んだ提案を、第二サーバ計算機１１１Ｂに送信する。全順序配信部１３３は、一定数以上の第二サーバ計算機１１１Ｂから、送信した提案に対して合意を受けた場合に、複数の処理要求を決定した実行順序で実行することを制御部１３２（要求制御部１５１）及び第二サーバ計算機１１１Ｂに指示する。なお、全順序配信部１３３は、提案を受けた場合には、その提案に合意するか否かを判定し、合意か否かを、提案の送信元に回答するようになっている。また、全順序配信部１３３は、提案に記述の実行順序で複数の処理要求を実行する指示を提案の送信元から受けた場合には、その複数の処理要求をその実行順序通りに制御部１３２（要求制御部１５１）に実行させるようになっている。

入力部１３４は、ポリシを含む情報の入力を受ける。ポリシは、バッチ処理及びオンライン処理要求のうちの少なくとも１つについての処理性能に関わる目標値（例えばバッチ要求の終了時刻）を含む。ポリシを含む情報は、例えば、管理者から管理システム１１２経由で入力され、記憶資源（主記憶デバイス１２４及び補助記憶デバイス１２３の少なくとも１つ）に格納されてよい。

出力部１３５は、モニタ部１３１からのモニタ結果情報（例えば制御部１３２を介して受けたモニタ結果情報）の少なくとも一部を表す情報を出力する。また、出力部１３５（又は制御部１３２）は、モニタ結果情報の少なくとも一部を基に、バッチ処理の現在の進捗、バッチ処理の今後の進捗、オンライン処理の遅延時間等を算出する。出力部１３５は、算出された情報を出力する。出力部１３５は、例えば、情報を管理システム１１２に出力し、管理システム１１２により、その情報が表示されてよい。

制御部１３２（要求制御部１５１及び分割部１５２）、モニタ部１３１、全順序配信部１３３、入力部１３４及び出力部１３５のうちの少なくとも１つは、複数のサーバ計算機１１１の各々に含まれることに代えて、サーバシステム１０１に含まれる第三のサーバ計算機（複数のサーバ計算機１１１以外のサーバ計算機であり複数のサーバ計算機１１１に接続されたサーバ計算機）のみに含まれてもよい。第三のサーバ計算機の全順序配信部１３３が、２以上のサーバ計算機１１１の各々に、決定した順序でオンライン要求のデータ及びバッチ要求の分割されたデータを送信してよい。

図２は、第一サーバ計算機１１１Ａ及び第二サーバ計算機１１１Ｂにおいて行われる処理の概要を示す。以下、混同を避けるため、以下の説明において、第一サーバ計算機１１１Ａの要素には、参照符号の末尾に「Ａ」を付し、第二サーバ計算機１１１Ｂの要素には、参照符号の末尾に「Ｂ」を付すことがある。なお、第一サーバ計算機１１１Ａと第二サーバ計算機１１１Ｂのどちらも、オンライン要求及びバッチ要求を受け付けてもよいが、以下の説明では、第一サーバ計算機１１１Ａが、オンライン要求及びバッチ要求を受け付けるサーバ計算機でよい。第一サーバ計算機１１１Ａに障害が発生した場合に２以上の第二サーバ計算機１１１Ｂのうちのいずれかが第一サーバ計算機１１１Ａになってもよい。

第一サーバ計算機１１１Ａにおいて、要求制御部１５１Ａが、複数の処理要求（２以上のオンライン要求及び２以上の分割バッチ要求を含む）の各々を実行しているとする。また、モニタ部１３１Ａが、その複数の処理要求の実行状況を監視しモニタ結果情報を出力しているとする。また、入力部１３４Ａを介してポリシが入力済みであるとする。このような環境において、出力部１３５Ａは、バッチ処理の実行中又はバッチ処理の完了後等に、管理者から表示要求を受け付ける。出力部１３５Ａ（又は制御部１３２Ａ）は、表示要求を受けた場合に、モニタ結果情報を基に、その表示要求における指定に従う内容（例えば、バッチ処理の進捗状況、オンライン処理の遅延時間等）を算出し、出力部１３５Ａが、算出された内容を表示する。

さて、第一サーバ計算機１１１Ａにおいて、要求制御部１５１Ａが、新たにオンライン要求を受信したとする。要求制御部１５１Ａは、受信したオンライン要求を全順序配信部１３３Ａに送る。そのオンライン要求は、例えばキューに蓄積される。この段階では、そのオンライン要求は未実行の状態である。

また、第一サーバ計算機１１１Ａにおいて、要求制御部１５１Ａが、新たにバッチ要求を受信したとする。要求制御部１５１Ａは、そのバッチ要求の実行を決定する。例えば、要求制御部１５１Ａは、モニタ部１３１Ａからのモニタ結果情報が、いずれのオンライン要求も実行されていない（いずれのオンライン処理も実行されていない）ことを示す場合に、そのバッチ要求の実行を決定する。要求制御部１５１Ａは、バッチ要求の実行を決定したとき、そのバッチ要求の分割を分割部１５２Ａに依頼する。分割部１５２Ａは、その分割依頼に応答して、分割サイズに従いバッチ要求を基に分割バッチ要求を作成し、作成した分割バッチ要求を要求制御部１５１Ａに送る。要求制御部１５１Ａは、バッチ要求の分割が未だ途中であれば（受けた分割バッチ要求が１つのバッチ要求から作成された最後の分割バッチ要求で無ければ）、分割依頼を分割部１５２Ａに出すことで分割バッチ要求が新たに作成されるようにする。分割サイズは、ポリシ及びモニタ結果情報（具体的には、例えば、分割の依頼を受けたときのポリシ及びモニタ結果情報）のうちの少なくとも一部に基づいて分割部１５２Ａにより決定され、その決定された分割サイズに従って分割バッチ要求が作成されてよい。要求制御部１５１Ａは、分割バッチ要求が得られる都度に分割バッチ要求を全順序配信部１３３Ａに送る。送られた分割バッチ要求は、例えばキューに蓄積される。この段階では、その分割バッチ要求は、未実行の状態である。

第一サーバ計算機１１１Ａにおいて、全順序配信部１３３Ａが、蓄積されている複数の処理要求（２以上のオンライン要求と２以上の分割バッチ要求を含む）の実行順序を決定する。その複数の処理要求の各々は、未実行状態の処理要求である。全順序配信部１３３Ａは、ポリシ（例えばバッチ要求終了時刻等の目標値）及びモニタ結果情報のうちの少なくとも一部を基に、ポリシが守られるような実行順序を決定することができる。全順序配信部１３３Ａは、処理対象の複数の処理要求に関する情報（例えば複数の処理要求それ自体）と決定した実行順序とを含んだ提案を、第二サーバ計算機１１１Ｂに送信する。第二サーバ計算機１１１Ｂにおいて、全順序配信部１３３Ｂが、提案を受信し、提案に合意するか否かを所定の情報に基づいて決定し、決定した回答（合意又は拒絶）を、提案の送信元（第一サーバ計算機１１１Ａにおける全順序配信部１３３Ａ）に返す。

第一サーバ計算機１１１Ａにおいて、全順序配信部１３３Ａが、一定数以上の第二サーバ計算機１１１Ｂから合意を受けた場合、合意された提案通りの処理を実行すること（処理対象の複数の処理要求を決定された実行順序通りに実行すること）を、第一サーバ計算機１１１Ａ内の制御部１３２（要求制御部１５１）と第二サーバ計算機１１１Ｂとに指示する。その指示に応答して、第一サーバ計算機１１１Ａでは、要求制御部１５１Ａが、複数の処理要求を決定された実行順序通りに実行する。また、その指示に応答して、第二サーバ計算機１１１Ｂでは、全順序配信部１３３Ｂが、複数の処理要求を決定された実行順序通りに実行することを要求制御部１５１Ｂに指示し、要求制御部１５１Ｂが、その複数の処理要求をその実行順序通りに実行する。

これにより、複数のサーバ計算機１１１（第一サーバ計算機１１１Ａ及び１以上の第二サーバ計算機１１１Ｂ）において同一順序で同一の複数の処理要求が実行される。結果として、複数のサーバ計算機１１１においてデータの一貫性が保証される。

図３は、分割サイズ及び実行順序が第一及び第二サーバ計算機１１１Ａ及１１１Ｂの各々において独立している比較例と、分割サイズ及び実行順序が第一及び第二サーバ計算機１１１Ａ及び１１１Ｂにおいて同一であることが保証される本実施形態との比較の概要の一例を示す。図４は、分割サイズが第一及び第二サーバ計算機１１１Ａ及び１１１Ｂの各々において独立している比較例と、分割サイズが第一及び第二サーバ計算機１１１Ａ及び１１１Ｂにおいて同一であることが保証される本実施形態との比較の具体例を示す。図３及び図４から分かるように、第一及び第二サーバ計算機１１１Ａ及び１１１Ｂの各々が独立してバッチ要求を任意の分割サイズに基づき分割したり処理要求の実行順序を決定したりすると、サーバ計算機１１１Ａ及び１１１Ｂ間でデータの一貫性が崩れる。本実施形態によれば、第一及び第二サーバ計算機１１１Ａ及び１１１Ｂの各々の全順序配信部１３３Ａ及び１１３Ｂにより、同一の複数の処理要求が同一実行順序で実行されることになるので、データの一貫性が保証される。

以上のように、本実施形態では、全順序配信部１３３が複数のサーバ計算機１１１の各々に設けられることで、処理要求がシリアルに処理されることになる。このため、オンライン処理とバッチ処理が並列に実行されることが無い。また、２以上の処理要求の処理結果が処理要求の実行順序に依存しない結果であるとしても、複数の処理要求のうちの２以上が並列に実行されることが無い。複数の処理要求はシリアルに（順次に）実行される。このような構成が前提となっているため、後述するように、分割サイズ、及び、分割バッチ要求の実行タイミング、のうちの少なくとも１つが適切であることが望ましい。

以下、第一サーバ計算機１１１Ａを例に取り、本実施形態をより詳細に説明する。

図５は、データストアの構成を示す。

データストア５０１は、複数のkey-valueの蓄積である。このようなデータストアは、サーバ計算機１１１の主記憶デバイス１２４及び補助記憶デバイス１２３のうちの少なくとも一方に設けられるが（例えば、データストア５０１の全部又は一部が主記憶デバイス１２４に設けられ残りが補助記憶デバイス１２３に設けられるが）、サーバ計算機１１１がアクセス可能な外部ストレージ装置に設けられてもよい。サーバ計算機１１１毎にデータストアが存在する。

図６は、分割バッチ要求の構成を示す。

分割バッチ要求は、分割ＩＤ６０１、バッチＩＤ６０２、分割サイズ６０３及びシーケンス番号６０４を含む。分割ＩＤ６０１は、分割バッチ要求のＩＤである。バッチＩＤ６０２は、分割バッチ要求のソースとしてのバッチ要求のＩＤである。分割サイズ６０３は、そのバッチ要求の分割の基になった分割サイズである。シーケンス番号６０４は、この分割バッチ要求の実行順番を表す番号である。

分割バッチ要求が作成されたときは、実行順序が決まっていないのでシーケンス番号６０４は分割バッチ要求に記述されない（例えばＮｕｌｌ）。全順序配信部１３３により実行順序が決められた場合に、シーケンス番号６０４（分割バッチ要求の実行順番）が、例えば全順序配信部１３３（又は制御部１３２）により分割バッチ要求に記述される。なお、全順序配信部１３３から要求制御部１５１へのオンライン要求にも、決定された実行順序に従うシーケンス番号が記述されてよい。

図７は、分割履歴テーブル１４１の構成を示す。

分割履歴テーブル１４１は、バッチ要求の分割の履歴に関する情報を有する。分割履歴テーブル１４１は、例えば分割部１５２が有してもよい。分割履歴テーブル１４１は、バッチ要求毎にレコードを有し、各レコードが、バッチＩＤ７０１、バッチ格納先７０２、分割サイズ７０３、想定分割数７０４、平均実行時間７０５及び平均実行間隔７０６を記憶する。

バッチＩＤ７０１は、バッチ要求のＩＤである。バッチ格納先７０２は、バッチデータの格納先領域の情報（例えばアドレス）である。分割サイズ７０３は、バッチ要求の分割のための分割サイズである。想定分割数７０４は、対応するバッチ要求を基に現在の分割サイズ（登録されている分割サイズ７０３）に従い今後得られると予測される分割バッチ要求の数である。平均実行時間７０５は、１つの分割バッチ要求に対応した分割バッチ処理（バッチ処理部分）にかかった時間の平均値である。平均実行間隔７０６は、分割バッチ処理間隔（分割バッチ処理の開始から次の分割バッチ処理の開始までの時間）の平均値である。

なお、バッチＩＤ７０１、バッチ格納先７０２、分割サイズ７０３、想定分割数７０４、平均実行時間７０５及び平均実行間隔７０６のうち少なくとも想定分割数７０４は分割履歴テーブル１４１に無くてもよい。

図８は、バッチ管理テーブル１４２の構成を示す。

バッチ管理テーブル１４２は、バッチ処理に関する情報を有する。バッチ管理テーブル１４２は、例えば要求制御部１５１が有してよい。バッチ管理テーブル１４２は、バッチ要求毎にレコードを有し、各レコードが、バッチＩＤ８０１、バッチ名８０２、開始時刻８０３、終了時刻８０４、位置８０５、総数８０６及び分割数８０７を記憶する。

バッチＩＤ８０１は、バッチ要求のＩＤである。バッチ名８０２は、バッチ要求の表示名である。開始時刻８０３は、バッチ要求の実行開始時刻（最初の分割バッチ要求の実行開始時刻）を表す。終了時刻８０４は、バッチ要求の実行終了時刻（最後の分割バッチ要求の実行終了時刻）を表す。位置８０５は、バッチデータを構成するデータ（例えばバッチデータのうちの１つのデータ＝１つのkey-value）のうち処理されたデータの数を表す。総数８０６は、バッチデータを構成するデータの数を表す。分割数８０７は、バッチ要求を基に得られた分割バッチ要求の数を表す。

以上のような分割履歴テーブル１４１及びバッチ管理テーブル１４２のうちの少なくとも１つを基に、処理の効率化が期待できる。

例えば、バッチ要求について一度決定された分割サイズが、分割履歴テーブル１４１に分割サイズ７０３として登録される。分割部１５２は、そのバッチ要求を基に新たに分割バッチ要求を作成する際は、その登録されている分割サイズ７０３に従い分割バッチ要求を作成する。これにより、分割バッチ要求の作成の都度に、分割サイズ７０３を決定する（例えばモニタ結果情報を新たに参照する）必要が無い。

具体的には、例えば、分割履歴テーブル１４１に登録される分割サイズ７０３は、効果のある期間（効率的にバッチ処理を実行できる時間）において決定された分割サイズである。例えば、効果の無い期間（非効率的にバッチ処理を実行した時間）において決定され分割履歴テーブル１４１に登録された分割サイズ７０３は、効果のある期間において決定された分割サイズに更新される。なお、「効果のある期間」とは、オンライン処理への悪影響が無い期間、例えば、平均レイテンシ時間が所定時間未満であり、且つ、オンライン遅延率が所定率未満の期間である。一方、「効果の無い期間」とは、オンライン処理への悪影響がある期間、例えば、平均レイテンシ時間が所定時間以上である、又は、オンライン遅延率が所定率以上である期間である。

或いは、例えば、１つのバッチ要求について一旦決定され分割履歴テーブル１４１に登録された分割サイズ７０３は、そのバッチ要求について少なくとも一定期間は変更されない。

また、例えば、バッチ要求についての平均実行時間７０５を基に、出力部１３５又は他の処理部（例えば制御部１３２）により、例えば下記計算式に従い、バッチ予測終了時刻を算出することができる。
残りのバッチ処理時間（例えば秒）＝想定分割数７０４×(平均実行時間７０５＋ 平均実行間隔７０６)
バッチ予測終了時刻＝現在時刻＋残りのバッチ処理時間

なお、想定分割数７０４は、例えば、下記計算式に従い、出力部１３５又は他の処理部（例えば制御部１３２）により算出することができる。
想定分割数７０４＝（総数８０６−位置８０５）／分割サイズ７０３

次に、出力部１３５により表示される画面の例を、図９及び図１０を参照して説明する。

図９は、バッチ実行中画面の一例である。

バッチ実行中画面９００は、実行中のバッチ要求についての画面であり、実行中のバッチ要求毎の情報を有する。例えば、バッチ実行中画面９００は、バッチ要求毎に、バッチ名９１１、バッチ処理進捗グラフ９１２、進捗９１３、開始時刻９１４、経過時間９１５及び予測終了時刻９１６を有する。バッチ名９１１は、バッチ名８０２と同じである。バッチ処理進捗グラフ９１２及び進捗９１３は、位置８０５及び総数８０６に基づき表示される。開始時刻９１４は、開始時刻８０３と同じである。経過時間９１５は、開始時刻８０３と現在時刻とに基づき表示される。予測終了時刻９１６は、上記バッチ予測終了時刻の計算式に従い算出された値である。

バッチ実行中画面９００の表示の目的は、例えば下記のうちの少なくとも１つである。
（Ｘ）：バッチ処理キャンセル。管理者が、バッチ処理をキャンセルするか否かを判定できるようにする。
（Ｙ）：分割サイズ変更。管理者が、分割サイズ７０３を変更すべきか否かを判定できるようにする。

（Ｘ）（バッチ処理キャンセル）について言えば、例えば次の通りである。管理者又はいずれかの処理部が、現在時刻から予測終了時刻までの時間が所定時間以上に長く進捗が所定率未満であれば、バッチ処理のキャンセル要求を出してよい。キャンセル要求は、キャンセル対象のバッチ要求のバッチＩＤを含んでよい。キャンセル要求が出た場合、バッチ処理が中断されバッチ実行前の初期状態に戻されることになる。具体的には、例えば下記の通りである。
（１）制御部１３２（要求制御部１５１）が、分割バッチ要求に従いデータストア５０１を更新する場合、更新前のデータストア５０１と更新後のデータストア５０１との差分を管理するようになっている。例えば、制御部１３２は、新たなバッチ要求について最初の分割バッチ要求を実行する場合、更新前のデータストア５０１のスナップショットを確保しておく。これにより、バッチ処理がキャンセルされた場合、バッチ要求に従う更新対象のデータストア５０１を、確保されているスナップショットを基に更新前のデータストア５０１に戻すことができる。
（２）制御部１３２（要求制御部１５１）が、キャンセル対象のバッチ要求に対応した分割バッチ要求を記憶資源（例えば主記憶デバイス１２４）から破棄する。
（３）制御部１３２（要求制御部１５１）が、キャンセル要求を、第二サーバ計算機１１１Ｂに転送する。転送先の第二サーバ計算機１１１Ｂにおいて、制御部１３２Ｂ（例えば要求制御部１５１Ｂ）が、キャンセル対象のバッチ要求に対応した分割バッチ要求を記憶資源（例えば主記憶デバイス１２４Ｂ）から破棄し、且つ、バッチ要求に従う更新対象のデータストア５０１Ｂを、確保されているスナップショットを基に更新前のデータストア５０１Ｂに戻す。

なお、出力部１３５は、（Ａ）バッチ処理のキャンセル処理を開始可能な時刻と、（Ｂ）バッチ処理のキャンセル処理に対する予測終了時刻とを算出してよい。出力部１３５は、（Ａ）及び（Ｂ）の少なくとも１つを、例えば、（ａ）データストアを更新前のデータストアに戻すまでにかかる時間と、（ｂ）１つのバッチ要求に対応した総数８０６と、位置８０５のうちの少なくとも１つに基づき算出してよい。出力部１３５は、算出された時刻を、バッチ実行中画面９００に表示してよい。これにより、管理者にとって、バッチ処理をキャンセルするか否かを判定し易くなることが期待できる。

また、（Ｙ）（分割サイズ変更）について言えば、例えば次の通りである。管理者が、変更後の分割サイズとバッチＩＤとを指定した分割サイズ設定要求を出し、制御部１３２（例えば分割部１５２）が、その要求を入力部１３４を介して受信し、その要求で指定されている分割サイズを、その要求が含むバッチＩＤに対応した分割サイズ７０３に上書きしてよい。なお、出力部１３５は、バッチ要求毎に、現在の分割サイズ７０３をバッチ実行中画面９００に表示してよい。管理者は、その分割サイズを参考に、変更後の分割サイズを決定できる。

図１０は、バッチ実行結果画面の一例である。

バッチ実行結果画面１０００は、１つのバッチ要求についての画面であり、例えばバッチ要求の実行が終了したことを契機に表示される。例えば、バッチ実行結果画面１０００は、実行が完了したバッチ要求について、バッチ名１００１、開始時刻１００２、終了時刻１００３、トータル実行時間１００４、分割数１００５、平均レイテンシ時間１００６、オンライン遅延率１００７、効果のある期間１００８及び効果の無い期間１００９を有する。バッチ名１００１は、バッチ名８０２と同じである。開始時刻１００２及び終了時刻１００３は、開始時刻８０３及び終了時刻８０４と同じであり、トータル実行時間１００４は、開始時刻８０３及び終了時刻８０４との差分である。分割数１００５は、分割数８０７と同じである。平均レイテンシ時間１００６、オンライン遅延率１００７、効果のある期間１００８及び効果の無い期間１００９は、モニタ結果情報に基づきそれぞれ表示される。

管理者は、バッチ実行結果画面１０００を基に、次回以降のバッチ要求の実行開始タイミング（入力タイミング）を決定することができる。なお、効果のある期間１００８及び効果の無い期間１００９のうちの少なくとも１つについて、最も効果のある（最も効果の無い）期間だけが表示されてもよいし、効果のある（効果の無い）期間に該当する期間が所定数表示されてもよい。

以下、要求制御部１５１、分割部１５２及び全順序配信部１３３の各々の動作を説明する。

図１１は、要求制御部１５１の動作のフローチャートである。

要求制御部１５１は、処理要求を特定する（Ｓ１１０１）。Ｓ１１０１について、処理要求は、例えば、受信したオンライン要求、受信したバッチ要求、分割中のバッチ要求、及び、受信した分割バッチ要求のいずれかである。なお、複数種類の処理要求が存在する場合、要求制御部１５１は、オンライン要求を特定してから一定期間（例えばオンライン処理実行期間又は許容レイテンシ時間）のうちはオンライン要求を特定しないでもよい。

Ｓ１１０１で特定した処理要求の送信元が全順序配信部１３３であれば（Ｓ１１０２：ＹＥＳ）、要求制御部１５１は、特定した処理要求を実行する（Ｓ１１１１）。要求制御部１５１は、バッチ要求が完了したのであれば（Ｓ１１１２：ＹＥＳ）、そのバッチ要求についてバッチ実行結果画面を出力部１３５により表示させる（Ｓ１１１３）。

Ｓ１１０１で特定した処理要求の送信元が全順序配信部１３３でなければ（Ｓ１１０２：ＮＯ）、要求制御部１５１は、特定した処理要求がバッチ要求か否かを判定する（Ｓ１１０３）。

Ｓ１１０３の判定結果が否定であれば（Ｓ１１０３：ＮＯ）、つまり、特定した処理要求がオンライン要求であれば、要求制御部１５１は、オンライン要求を全順序配信部１３３に送る（Ｓ１１０４）。

Ｓ１１０３の判定結果が肯定であれば（Ｓ１１０３：ＹＥＳ）、要求制御部１５１は、バッチ処理実行可能か否かを判定する（Ｓ１１０５）。Ｓ１１０５の判定は、例えば、モニタ部１３１からのモニタ結果情報がいずれのオンライン処理も実行されていないことを示すか否か等でよい。Ｓ１１０５の判定結果が否定の場合（Ｓ１１０５：ＮＯ）、要求制御部１５１は、バッチ要求を一時保持して別の処理要求を受けられるよう一旦終了し、一定時間後等の所定のタイミングで、その一時保持したバッチ要求（分割中のバッチ要求）がＳ１１０１で特定されてよい。なお、Ｓ１１０５の判定が、モニタ部１３１からのモニタ結果情報がいずれのオンライン処理も実行されていないことを示すか否かの判定であり、この判定の結果が肯定の場合に、後述のように分割バッチ要求の作成が行われる。このため、サーバ計算機１１１の負荷が比較的低い場合に分割バッチ要求を作成するようにできる。

Ｓ１１０５の判定結果が肯定の場合（Ｓ１１０５：ＹＥＳ）、要求制御部１５１は、受信したバッチ要求の分割を分割部１５２に依頼する。（Ｓ１１０６）、その依頼は、バッチ要求のバッチＩＤを含んでよい。要求制御部１５１は、その依頼に応答して、そのバッチ要求を基に作成された分割バッチ要求を受け、その分割バッチ要求を全順序配信部１３３に送る（Ｓ１１０７）。

要求制御部１５１は、Ｓ１１０７で送った分割バッチ要求が、Ｓ１１０１で受けたバッチ要求についての最後の分割バッチ要求であれば（Ｓ１１０８：ＹＥＳ）、終了する。

一方、要求制御部１５１は、Ｓ１１０７で送った分割バッチ要求が、Ｓ１１０１で受けたバッチ要求についての最後の分割バッチ要求でなければ（Ｓ１１０８：ＮＯ）、Ｓ１１０５に戻る。Ｓ１１０５の判定結果が肯定の場合、同一のバッチ要求についてＳ１１０６及びＳ１１０７が行われる。Ｓ１１０５の判定結果が否定の場合（例えば、Ｓ１１０５〜Ｓ１１０８で構成されたループが一定回数繰り返された場合）、要求制御部１５１は、終了する。この場合、バッチ要求の分割途中であるため、要求制御部１５１は、バッチ要求を一時保持して、一定時間後等の所定のタイミングで、、その一時保持したバッチ要求（分割中のバッチ要求）がＳ１１０１で特定されてよい。どこからバッチ処理(分割バッチ要求の作成)を再開すべきかは、例えばバッチ管理テーブルの位置８０５などの情報を利用することで判断する。

図１２は、分割部１５２の動作のフローチャートである。

分割部１５２は、要求制御部１５１からの分割依頼内のバッチＩＤと、分割履歴テーブル１４１とを基に、その分割依頼対象のバッチ要求が初めて分割対象とされたバッチ要求であるか否かを判定する（Ｓ１２０１）。分割依頼内のバッチＩＤと同一のバッチＩＤ７０１が分割履歴テーブル１４１に無ければ、分割対象のバッチ要求は、初めて分割対象とされたバッチ要求である（Ｓ１２０１：ＹＥＳ）。この場合、分割部１５２は、分割依頼内のバッチＩＤを含んだレコードを分割履歴テーブル１４１（及びバッチ管理テーブル１４２）に追加する。

Ｓ１２０１：ＮＯ又はＳ１２０２の後、分割部１５２は、モニタ部１３１からのモニタ結果情報を参照し（Ｓ１２０３）、そのモニタ結果情報（及びポリシ）のうちの少なくとも一部を基に分割サイズを決定する（Ｓ１２０４）。Ｓ１２０４で決定された分割サイズが、分割履歴テーブル１４１に登録される。分割履歴テーブル１４１に既に分割サイズ７０３が登録されている場合、その分割サイズ７０３は、Ｓ１２０４で決定された分割サイズに変更される。なお、Ｓ１２０３及びＳ１２０４に代えて、分割履歴テーブル１４１に登録されている分割サイズ７０３が、使用する分割サイズとして決定されてもよい。

分割部１５２は、決定した分割サイズに従い、分割対象のバッチ要求を基に分割バッチ要求を作成する（Ｓ１２０５）。分割部１５２は、作成した分割バッチ要求を、要求制御部１５１へ送る（Ｓ１２０６）。

図１３は、全順序配信部１３３の動作のフローチャートである。

全順序配信部１３３は、要求制御部１５１から処理要求（オンライン要求又は分割バッチ要求）を受信する（Ｓ１３０１）。全順序配信部１３３は、未実行の処理要求の数が所定数以上等の提案作成条件が満たされていない場合（Ｓ１３０２：ＮＯ）、終了する。

全順序配信部１３３は、提案作成条件が満たされている場合（Ｓ１３０２：ＹＥＳ）、提案を作成し、その提案を、第二サーバ計算機１１１Ｂに送信する。提案の作成とは、複数の処理要求の実行順序の決定である。ただし、全順序配信部１３３は、複数の処理要求に限らず一つの処理要求だけで提案を作成してもよい。例えば、全順序配信部１３３は、定期的に提案を作成するよう構成されていて、提案を作成するタイミングで処理要求が１つだけの場合は、その１つの処理要求についての提案を作成してよい。実行順序は、ポリシ及びモニタ結果情報の少なくとも一部に基づき決定されてよい。

全順序配信部１３３は、一定数以上の第二サーバ計算機１１１Ｂから合意を得らなかった場合（Ｓ１３０４：ＮＯ）、Ｓ１３０３に戻る。これにより、別の提案が作成され送信されることになる。

全順序配信部１３３は、一定数以上の第二サーバ計算機１１１Ｂから合意を得られた場合（Ｓ１３０４：ＹＥＳ）、Ｓ１３０３で作成した提案（処理対象の複数の処理要求を決定した実行順序通りに実行すること）を、第一サーバ計算機１１１Ａ内の要求制御部１５１Ａ、及び、第二サーバ計算機１１１Ｂの全順序配信部１３３Ｂに指示する。これにより、第一サーバ計算機１１１Ａでは、要求制御部１５１Ａが、複数の処理要求を決定された実行順序通りに実行する。第二サーバ計算機１１１Ｂでは、全順序配信部１３３Ｂが、複数の処理要求を決定された実行順序通りに実行することをその第二サーバ計算機１１１Ｂ内の要求制御部１５１Ｂに指示し、その要求制御部１５１Ｂが、その複数の処理要求をその実行順序通りに実行する。

以上が、要求制御部１５１、分割部１５２及び全順序配信部１３３の各々の動作である。

以下、分割部１５２による分割サイズ決定の幾つかの観点を説明する。

図１４は、分割サイズ決定の第一の観点を示す。

第一の観点によれば、特定オンライン処理間隔が特定オンライン処理所要時間よりも長い。特定オンライン処理間隔及び特定オンライン処理所要時間のうちの少なくとも１つが、例えば分割部１５２によりモニタ結果情報（又はその蓄積）から算出される。

「特定オンライン処理間隔」は、１以上のオンライン処理間隔に基づいて決定された値、例えば、１以上のオンライン処理間隔の平均値、最大値又は最小値である。本実施形態では、平均値が採用される。「オンライン処理間隔」は、Ｎ番目（Ｎは１以上の整数）のオンライン処理の開始から（Ｎ＋１）番目のオンライン処理の開始までの時間である。

「特定オンライン処理所要時間」は、１以上のオンライン処理所要時間に基づいて決定された値、例えば、１以上のオンライン処理所要時間の平均値、最大値又は最小値である。本実施形態では、平均値が採用される。「オンライン処理所要時間」は、１つのオンライン処理（１つのオンライン要求の処理）にかかる時間である。

第一の観点によれば、分割サイズは、平均オンライン処理所要時間から平均オンライン処理間隔を引いた値である。

図１５は、分割サイズ決定の第二の観点を示す。

第二の観点によれば、平均オンライン処理間隔（特定オンライン処理間隔の一例）が平均オンライン処理所要時間（特定オンライン処理所要時間の一例）以下である。「許容レイテンシ時間」は、平均オンライン処理所要時間の許容値である。許容レイテンシ時間は、例えば入力部１３４を介して管理者から入力された情報でよい。

第二の観点によれば、分割サイズは、許容レイテンシ時間から平均オンライン処理所要時間を引いた値である。

以上が、分割サイズ決定の幾つかの観点の説明である。いずれの観点においても、適切な分割サイズを決定することができる。いずれの観点においても、決定された分割サイズに従い作成された分割バッチ要求に対応したデータのサイズが、その分割サイズと同じサイズでよい。

なお、いずれの観点も、分割サイズ決定に代えて又は加えて、実行間隔の制御（変更）にも適用できる。「実行間隔」の「実行」は、（実行１）分割部１５２が分割バッチ要求を作成すること（言い換えれば、要求制御部１５１が分割依頼を分割部１５２に出すこと）、及び、
（実行２）全順序配信部１３３が実行順序を決定すること、のいずれでもよい。従って、「実行間隔の制御」とは、実行１のタイミング（間隔）の制御、及び、実行２のタイミング（間隔）の制御、のうちのいずれでもよい。実行間隔の制御について、例えば以下の具体例（Ａ）〜（Ｅ）がある。実行間隔の制御により、オンライン性能の低下を軽減できる。
（Ａ）入力部１３４経由等で指定された時間間隔（パラメタ）が、実行１の間隔又は実行２の間隔である。
（Ｂ）入力部１３４経由等で指定されたオンライン要求数（パラメタ）と同数のオンライン要求が実行されたタイミングが、実行１又は実行２のタイミングである。
（Ｃ）モニタ結果情報を基に特定されたオンライン処理負荷が閾値（許容レイテンシ時間など）未満である間における時点、又は、モニタ結果情報を基に特定されたオンライン遅延率が閾値未満である間における時点が、実行１又は実行２のタイミングである。
（Ｄ）モニタ結果情報を基に特定されるバッチ処理進捗状況と、入力部１３４経由等で指定された目標終了時刻（バッチ処理の目標終了時刻）とに基づいて制御部１３２又は全順序配信部１３３により決定された間隔（タイミング）が、実行１又は実行２の間隔である。
（Ｅ）バッチ処理が通信ネットワーク１７１経由のデータ転送を必要とする処理（例えばデータコピー処理）の場合、データ転送にはネットワーク負荷がかかる。このため、モニタ部１３１がネットワーク帯域使用量を監視する。モニタ結果情報を基に特定されたネットワーク帯域使用量が閾値未満である間における時点が、実行１又は実行２のタイミングである。

以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。

例えば、複数のプロセス（例えば仮想計算機）から構成された分散システムが物理計算機において構築されていて、その物理計算機内の記憶資源（例えばメモリ）に、複数のプロセスがそれぞれアクセスする複数のデータストアがあり（例えばいわゆるインメモリ）、プロセス間で複数の処理要求の実行順序が同一とされてよい。

また、例えば、図１６に例示する処理が行われてよい。すなわち、入力部１３４が、管理者からバッチＩＤ及びバッチ終了時刻（目標値）の指定を受け（Ｓ１６０１）、制御部１３２（例えば要求制御部１５１）が、指定されたバッチＩＤに対応したバッチ要求のバッチ処理を、入力されたバッチ終了時刻までに完了できるかどうかを判定する（Ｓ１６０２）。例えば、制御部１３２は、分割履歴テーブル１４１（例えば平均実行時間７０５、平均実行間隔７０６、分割サイズ７０３等）及びバッチ管理テーブル１４２（例えば、開始時刻８０３、位置８０５、総数８０６等）を基に、Ｓ１６０２の判定を行う。Ｓ１６０２の判定結果が否定の場合、制御部１３２又は出力部１３５が、分割履歴テーブル１４１（例えば平均実行時間７０５、平均実行間隔７０６、分割サイズ７０３等）及びバッチ管理テーブル１４２（例えば、開始時刻８０３、位置８０５、総数８０６等）を基に、Ｓ１６０１で指定されたバッチ要求のバッチ予測終了時刻を算出し、出力部１３５が、そのバッチ予測終了時刻を出力（例えば表示）する。これにより、管理者は、指定したバッチ終了時刻までにバッチ処理が終わらないとの判定結果の場合には、予測されたバッチ終了時刻を知ることができる。

１０１：サーバシステム（分散システム）

Claims (12)

1. それぞれ処理要求を実行する複数の計算機を備え、
   前記複数の計算機は、
   前記複数の計算機のうちのいずれかの計算機である第一計算機と、
   前記第一計算機との間でデータの一貫性を保つべき１以上の計算機である１以上の第二計算機と
   を含み、
   前記第一計算機は、
   第一の処理要求より優先順位の低い第二の処理要求の実行を決定したとき、予め定められた分割サイズに従い前記第二の処理要求を基に分割第二処理要求を作成し、
   １以上の第二の処理要求に対応した１以上の分割第二処理要求と１以上の第一の処理要求の実行順序を決定し、
   前記決定した実行順序を含む提案を前記１以上の第二計算機に送信し、
   一定数以上の前記第二計算機から前記提案に対する合意を受けた後、前記第一計算機と前記１以上の第二計算機との各々は、
   前記合意を受けた前記提案に含まれる前記実行順序で前記１以上の分割第二処理要求と前記１以上の第一の処理要求を実行する、
   計算機システム。
2. 前記第一計算機は、データ処理の実行状況を監視するようになっており、
   前記第一計算機は、監視結果を示すモニタ結果情報が、いずれの第一の処理要求も実行されていないことを示す場合に、前記第二の処理要求の実行を決定する、
   請求項１に記載の計算機システム。
3. 前記モニタ結果情報は、第一の処理要求のデータが実行される時間に関する情報である第一処理時間情報を含み、
   前記第一計算機は、前記第一処理時間情報に基づいて、前記分割サイズを変更する、
   請求項２に記載の計算機システム。
4. 前記モニタ結果情報は、第一の処理要求のデータが実行される時間に関する情報である第一処理時間情報を含み、
   前記第一処理時間情報に基づいて、分割第二処理要求を作成する間隔と実行順序を決定する間隔とのうちの少なくとも一方が変更される、
   請求項２に記載の計算機システム。
5. 前記第一計算機は、第一の処理要求の実行遅延に関する情報であり前記モニタ結果情報を基に算出された遅延情報を出力する、
   請求項３又は４に記載の計算機システム。
6. 前記モニタ結果情報は、第一の処理要求の実行状況に関する情報である第一処理状況情報を含み、
   前記第一計算機は、
   前記第二の処理要求の終了時刻に関する情報を受け付け、
   前記第一処理状況情報を基に、入力部が受けた終了時刻までに前記第二の処理要求を完了できるかどうかを判定し、
   前記第二の処理要求を前記終了時刻までに完了できないと判定した場合、前記第二の処理要求の予測終了時刻を出力する、
   請求項５に記載の計算機システム。
7. 前記第一の処理要求は、オンラインで受けた処理要求であり、
   前記第二の処理要求は、バッチで処理することの処理要求である、
   請求項１乃至６のうちのいずれか１項に記載の計算機システム。
8. 前記２以上の分割第二処理要求は、それぞれ、複数の空き時間において行われ、
   各空き時間は、第一の処理要求についてのデータ処理が行われていない時間である、
   請求項１乃至７のうちのいずれか１項に記載の計算機システム。
9. 特定第一処理間隔が特定第一処理所要時間よりも長い場合、前記各空き時間は、前記特定第一処理間隔と前記特定第一処理所要時間との差分であり、
   前記特定第一処理間隔が前記特定第一処理所要時間以下の場合、前記各空き時間は、許容レイテンシ時間と前記特定第一処理所要時間との差分であり、
   前記特定第一処理所要時間は、１以上の第一処理所要時間に基づいて決定された値であり、第一処理所要時間は、前記第一の処理要求の実行にかかる時間であり、
   前記特定第一処理間隔は、１以上の特定第一処理間隔に基づいて決定された値であり、第一処理間隔は、前記第一の処理要求についてのデータ処理の開始から次の第一の処理要求についてのデータ処理の開始までの時間であり、
   前記許容レイテンシ時間は、前記特定第一処理所要時間の許容値であり、
   前記第一計算機は、前記各空き時間に基づいて前記分割サイズを決定する、
   請求項８に記載の計算機システム。
10. 分割第二処理要求を作成する間隔と実行順序を決定する間隔とのうちの少なくとも一方が、データ処理の実行状況と指定されたパラメタとのうちの少なくとも１つに基づき変更される、
    請求項１乃至８のうちのいずれか１項に記載の計算機システム。
11. それぞれ処理要求を実行する複数の計算機のうちのいずれかの計算機である第一計算機が、第一の処理要求より優先順位の低い第二の処理要求の実行を決定したとき、予め定められた分割サイズに従い前記第二の処理要求を基に分割第二処理要求を作成し、
    前記第一計算機が、１以上の第二の処理要求に対応した１以上の分割第二処理要求と１以上の第一の処理要求との実行順序を決定し、
    前記第一計算機が、前記決定した実行順序を含む提案を、前記第一計算機との間でデータの一貫性を保つべき１以上の計算機である１以上の第二計算機に送信し、
    一定数以上の前記第二計算機から前記提案に対する合意を受けた後、前記第一計算機と前記１以上の第二計算機との各々が、前記合意を受けた前記提案に含まれる前記実行順序で前記１以上の分割第二処理要求と前記１以上の第一の処理要求を実行する、
    データ処理方法。
12. 外部の計算機に接続された計算機であって、
    第一の処理要求より優先順位の低い第二の処理要求の実行を決定したとき、予め定められた分割サイズに従い前記第二の処理要求を基に分割第二処理要求を作成する制御部と、
    １以上の第二の処理要求に対応した１以上の分割第二処理要求と１以上の第一の処理要求との実行順序を決定し、前記決定した実行順序を含む提案を、前記計算機との間でデータの一貫性を保つべき前記外部の計算機に送信し、一定数以上の前記外部の計算機から前記提案に対する合意を受けた後、前記制御部と前記外部の計算機に、それぞれ、前記合意を受けた前記提案に含まれる前記実行順序で前記１以上の分割第二処理要求と前記１以上の第一の処理要求を実行させる全順序配信部と
    を備える計算機。
    

Images