JP2016143162A - データ処理システムおよびサーバ - Google Patents

Abstract

【課題】単一ノードで動作するアプリケーションを非改造で（または改造するための工数を削減し）、同一の実行環境を持つ複数のノード上で並列実行させること。【解決手段】端末群とネットワークを介して通信可能なデータ処理システムは、相互通信可能な複数のサーバを有し、複数のサーバの各々は、端末群のうち担当範囲の端末からの要求に応じたデータ処理を実行可能なデータ処理部と、担当範囲と担当範囲の端末にアクセス可能なサーバとを関連付けたマスタ情報を他のデータストアとの相互通信により共有化するデータストアと、各マスタ情報にアクセス可能であり、かつ、各データ処理部を制御してデータ処理を実行可能な分散処理部と、を有し、分散処理部は、自マスタ情報にアクセスし、自マスタ情報で担当範囲に関連付けられているサーバが自サーバであるか否かを解析し、分散処理部がデータ処理部を制御できる資格ありと決定する。【選択図】図１

Description

本発明は、データ処理を実行するデータ処理システムおよびサーバに関する。

アプリケーションを高信頼化する手法として、特許文献１、２の方法に示されるような、同一の実行環境をもつ複数のノードで処理を多重化（冗長化）する方法が提案されている。特許文献１（要約、［００１７］、［００１８］）の耐障害システムは、構成要素の故障は避けられないという観点から、同一の実行環境を持つ複数のノード上で、プログラムを並列実行させることで、プログラムレベルでの耐障害性を持たせるシステムである。特許文献１の耐障害システムは、環境情報（プロセッサや、プロセス、メモリ、ディスク等の使用状態、入出力インタフェースやネットワークの状態、電源供給の有無、各デバイスの温度など）の比較によって異常ノードを検出する。

特許文献２（［０００８］、［００１９］）のクラスタ構成データベースは、分散構成データベースで、構成データベースの一貫性コピーがクラスタの各アクティブノードで保持される。クラスタの各ノードは構成データベースのそれ自体のコピーを保持し、構成データベースの動作はいずれのノードからでも行うことができる。構成データベースの更新は、ロックステップの方法で各ノードに自動的に伝達される。いずれかのノードでエラーが発生すると、構成データベースは、クラスタの各ノードの一貫性データを確保するために再構成プロトコルを使う。クラスタ構成データベースは、ノード間の一貫性データを確実なものにするために２つのレベルの一貫性フレームワークを使う。構成データベースの各ローカル・コピーは、独自の一貫性記録を使って一意に構成データベースの各コピーを識別し、スタンプする。構成データベースの各ローカル・コピーの一貫性は、その一貫性記録で検証される。さらに、クラスタ構成データベースは、２相コミットプロトコルを使い、構成データベースの更新コピーがノード間で一貫性のあることを保証する。

特許文献３（［０００８］、［００１０］）のＰａｘｏｓアルゴリズムは、与えられたステップに対してどのコマンドが実行されるべきかを判定するための１つのメカニズムである。Ｐａｘｏｓアルゴリズムは、スピリットブレイン等のデータの一貫性の問題を解決し、前述の２相コミットプロトコルよりも処理量が少ないことを特徴とする。

特開２００４−３５５２３３号公報 特表２００１−５１８６６３号公報 特開２００５−１９６７６３号公報

近年、さまざまな分野のミッションクリティカルシステムにおいて、多くの障害事例が報告されており、ミッションクリティカルシステムのさらなる高信頼化が求められている。高信頼システムを実現する方法として、システムを構成する（単一ノードで動作する）アプリケーションのデータおよび処理の冗長化が考えられる。しかしながら、特許文献１、２を適用するには、以下の課題があった。

特許文献１は、処理のインプットが同じであることを前提としているため並列実行の結果が同じになるが、インプットとして複数のノードにあるデータを利用する場合は結果が必ずしも同じになるとは限らない。一般的に、データに関する高信頼化手法として、データを複製して、複数サーバで保持する高信頼化する方式が広く採用されている（分散ファイルシステム、分散キーバリューストア、データグリッド、分散ＲＤＢ等）。

このような分散型のデータストアでは、各データストアに格納されているデータが同じであること、即ちデータの一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）を保証することが課題となっている。たとえば、ネットワーク障害によりデータストアが複数グループに分断され、そのグループが別々に動作してしまうこと、いわゆるスピリットブレインの状態が生じると、データの一貫性が保持できない。したがって、特許文献１により、アプリケーションのデータの冗長化を含んだ高信頼化はできない。

特許文献２は、ＲＤＢアプリケーション専用の一貫性制御部がデータの一貫性を実現しているため、さまざまなアプリケーションに容易に適用することができない。仮に、あるアプリケーションを冗長化するために、そのアプリケーションを改修した場合、改修作業により信頼性低下リスクが発生する。さらに、スピリットブレイン等のデータの一貫性の問題を解決するには、特許文献３に示したような処理を行う必要があり、開発工数増大にもつながる。

本発明は、単一ノードで動作するアプリケーションを非改造で（または改造するための工数を削減し）、同一の実行環境を持つ複数のノード上で並列実行させることを目的とする。

本願において開示される発明の一側面となるデータ処理システムは、端末群とネットワークを介して通信可能なデータ処理システムであって、前記データ処理システムは、相互通信可能な複数のサーバを有し、前記複数のサーバの各々は、前記端末群のうち担当範囲の端末からの要求に応じたデータ処理を実行可能なデータ処理部と、前記担当範囲と前記担当範囲の端末とアクセス可能なサーバとを関連付けたマスタ情報を保持し、他のデータストアとの相互通信により前記マスタ情報を共有化するデータストアと、前記各サーバの前記データストア内の前記マスタ情報にアクセス可能であり、かつ、前記各データ処理部を制御して、前記データ処理を実行可能な分散処理部と、を有し、前記分散処理部は、自サーバ内の前記データストアに格納されている前記マスタ情報にアクセスし、当該マスタ情報で前記担当範囲に関連付けられているサーバが前記自サーバであるか否かを解析し、解析結果に基づいて前記分散処理部が前記データ処理部を制御できる資格ありと決定することを特徴とする。

本発明の代表的な実施の形態によれば、単一ノードで動作するアプリケーションを非改造で（または改造するための工数を削減し）同一の実行環境を持つ複数のノード上で並列実行させることができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本実施例にかかるネットワークシステムのシステム構成例を示すブロック図である。 管理テーブルの記憶内容例を示す説明図である。 サーバ群の論理的な接続関係を示す説明図である。 サーバのハードウェア構成例を示すブロック図である。 記憶デバイスの記憶内容例を示す説明図である。 マスタ情報の記憶内容例を示す説明図である。 アプリケーション同期情報の記憶内容例を示す説明図である。 サーバ群の内部のシーケンス例を示す説明図である。 図８に示したマスタ情報解析処理（ステップＳ８０４）の詳細な処理手順例を示すフローチャートである。 図８に示した昇格処理（ステップＳ８０５）の詳細な処理手順例を示すフローチャートである。 アプリケーションの障害発生時におけるネットワークシステムでのシーケンス例１を示す説明図である。 アプリケーションの障害発生時におけるネットワークシステムでのシーケンス例２を示す説明図である。 サーバ群の論理構成を示す説明図である。 図１３に示した論理構成におけるマスタ情報の例を示す説明図である。 アプリケーション同期情報の例を示す説明図である。 サーバに障害が発生した場合の図１３に示した論理構成の変更例を示す説明図である。 サーバに障害が発生した場合の図１５に示したアプリケーション同期情報の変更例を示す説明図である。

＜システム構成＞
図１は、本実施例にかかるネットワークシステム１００のシステム構成例を示すブロック図である。ネットワークシステム１００は、１以上の端末１０１と、ロードバランサ１０３およびサーバ群ＳＶｓと、がネットワーク１０２を介して通信可能に接続されたシステムである。端末１０１は、サーバ群ＳＶｓのいずれかのサーバＳＶｉ（ｉは、１以上ｎ以下の整数。ｎは２以上の整数）にアクセスするコンピュータである。ネットワーク１０２は、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。有線でも無線でもよい。

ロードバランサ１０３は、端末１０１からのアクセスを分散していずれかのサーバＳＶｉに振り分ける。本実施例では、ロードバランサ１０３が、管理テーブル１０４を有し、端末１０１からのアクセスをいずれかのサーバＳＶｉに振り分ける例を示す。管理テーブル１０４は、通常時のアクセス振分け、またはいずれかのサーバＳＶｉに障害が発生した場合に、代替サーバに振り分けるためのテーブルである。管理テーブル１０４については後述する。他に、ロードバランサ１０３を配置せずに本実施例を実現する方法として、サーバＳＶｉ内のアプリケーションハブＡＨｉが管理テーブル１０４と振分け機能を備える方法や、ＤＮＳラウンドロビン（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ ｒｏｕｎｄ ｒｏｂｉｎ）を利用して、端末１０１からのアクセス先であるサーバＳＶｉを変更して分散する方法がある。

サーバ群ＳＶｓは、複数のサーバＳＶ１〜ＳＶｎにより構成されるデータ処理システムである。各サーバＳＶｉは相互に通信可能である。各サーバＳＶｉは各々、アプリケーションハブＡＨｉと、データストアＤＳｉと、アプリケーションＡＰｉと、を有する。サーバＳＶｉには他にもプログラムが存在するが、そのようなプログラムを除外する意図はない。

アプリケーションハブＡＨｉは、端末１０１からのメッセージを含むアクセスをアプリケーションＡＰ１〜ＡＰｎに分散する分散処理部である。データストアＤＳｉは、アプリケーションＡＰｉからのアクセスによりデータを書き込んだり、読み出したりする。データストアＤＳｉとしては、たとえば、一貫性保証型のキーバリューストア（ＫＶＳ）が採用される。したがって、データストアＤＳｉは、相互通信により内部に保持するデータを最新状態にし、一貫性を保証する。したがって、どのデータストアＤＳｉも同じデータを保存する。

なお、データストアＤＳｉは、アプリケーションハブＡＨｉやアプリケーションＡＰｉからアクセス可能であれば、サーバＳＶｉの外部に存在してもよい。

アプリケーションＡＰｉは、データストアＤＳｉにアクセスして、所定のデータ処理を実行するデータ処理部であり、データ（メッセージ）の入出力を備えるソフトウェアであれば適用可能である。アプリケーションＡＰｉとしては、たとえば、不図示のＲＤＢ（リレーショナルデータベース）、メールボックス、オンラインストレージシステム、ユーザ情報の管理サーバ等の制御プログラムが挙げられる。なお、アプリケーションＡＰ１〜ＡＰｎは、同種のプログラムであれば、バージョンが異なっていてもよいし、互換性を持つ異なるプログラムを複数いれてもよい（例えば、データベースのように共通のアクセスプロトコル（ＳＱＬ）をもつアプリケーションであって、プログラム自体は別の場合でもよい。）。これらは、アプリケーションのバージョンアップ時の不具合抽出や、アプリケーションを変更する際の過渡期の不具合抽出に利用することができる。

これにより、端末１０１からのメッセージ（たとえば、ＳＱＬ文）に含まれるデータは、アプリケーションハブＡＨｉを介して複数のデータストアＤＳｉに書き込まれるため、アプリケーションＡＰ１〜ＡＰｎを非改造のままデータをｎ重化することができる。

＜管理テーブル１０４＞
図２は、管理テーブル１０４の記憶内容例を示す説明図である。管理テーブル１０４は、図１に示したように、ロードバランサ１０３が有する。管理テーブル１０４は、担当範囲フィールド２０１と、宛先フィールド２０２と、代行フィールド２０３と、を有し、各フィールド２０１〜２０３の値によりエントリを構成する。なお、管理テーブル１０４の記憶内容は、事前に設定されてもよいし、アプリケーションハブＡＨｉにより動的に変更されてもよい。

担当範囲フィールド２０１は、担当範囲を格納する領域である。担当範囲とは、端末１０１からのメッセージを分散させる単位（パーティション）である。ハッシュテーブルによりメッセージが分散される場合、たとえば、送信元アドレスの末尾２文字のハッシュ値が担当範囲となる。このような担当範囲をパーティションと称す。したがって、管理テーブル１０４は、パーティションの個数（ｍ個。ｍは１以上の整数。）分のエントリを有する。

宛先フィールド２０２は、担当範囲であるパーティションＰＴｊ（ｊは１以上、ｍ以下の整数）の宛先となるサーバＳＶｊを格納する領域である。代行フィールド２０３は、宛先となるサーバＳＶｊが障害により動作しない場合にサーバＳＶｊに代わってメッセージを受け取るサーバである。ここでは、一例として、宛先サーバＳＶｊの代行サーバを（ｊ＋１）番目のサーバＳＶ（ｊ＋１）とする。なお、図では省略しているが、複数台の障害に備えて、代行フィールド２０３に複数のサーバとその代行順序を記述することができる。宛先サーバや代行サーバの番号が末尾番号ｎ（サーバＳＶｉの総数）に到達した場合はラウンドロビンでｊ＝１に戻るものとする。

＜サーバ群ＳＶｓの論理的な接続関係＞
図３は、サーバ群ＳＶｓの論理的な接続関係を示す説明図である。図３に示すように、アプリケーションハブＡＨｉは、データストアＤＳ１〜ＤＳｎにアクセス可能であり、また、アプリケーションＡＰ１〜ＡＰｎにもアクセス可能である。

＜サーバＳＶｉのハードウェア構成例＞
図４は、サーバＳＶｉのハードウェア構成例を示すブロック図である。サーバＳＶｉは、プロセッサ４０１と、記憶デバイス４０２と、入力デバイス４０３と、出力デバイス４０４と、通信インターフェース（通信ＩＦ４０５）と、を有する。プロセッサ４０１、記憶デバイス４０２、入力デバイス４０３、出力デバイス４０４、および通信ＩＦ４０５は、バス４０６により接続される。プロセッサ４０１は、サーバＳＶｉを制御する。記憶デバイス４０２は、プロセッサ４０１の作業エリアとなる。また、記憶デバイス４０２は、各種プログラムやデータを記憶する非一時的なまたは一時的な記録媒体である。記憶デバイス４０２としては、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリがある。また、記憶デバイスの一部には、データストアＤＳｉが含まれる。

入力デバイス４０３は、データを入力する。入力デバイス４０３としては、たとえば、キーボード、マウス、タッチパネル、テンキー、スキャナがある。出力デバイス４０４は、データを出力する。出力デバイス４０４としては、たとえば、ディスプレイ、プリンタがある。通信ＩＦ４０５は、ネットワーク１０２と接続し、データを送受信する。

図５は、記憶デバイス４０２の記憶内容例を示す説明図である。記憶デバイス４０２は、プログラム格納領域５０１とデータ領域５０２とを含む。プログラム格納領域５０１には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）５１１と、アプリケーションハブプログラム５１２と、データストアプログラム５１３と、アプリケーションプログラム５１４と、が格納される。

アプリケーションハブプログラム５１２は、プロセッサ４０１により実行されることで、アプリケーションハブＡＨｉとして機能する。データストアプログラム５１３は、プロセッサ４０１により実行されることで、データストアＤＳｉを制御する。アプリケーションプログラム５１４は、プロセッサ４０１により実行されることで、アプリケーションＡＰｉとして機能する。

なお、本明細書の説明で、アプリケーションハブＡＨｉ、データストアＤＳｉ、およびアプリケーションＡＰｉの各処理については、便宜的にアプリケーションハブＡＨｉ、データストアＤＳｉ、およびアプリケーションＡＰｉを主語にして説明するが、実際には、上述したように、アプリケーションハブプログラム５１２、データストアプログラム５１３、およびアプリケーションプログラム５１４をプロセッサ４０１に実行させることで、アプリケーションハブＡＨｉ、データストアＤＳｉ、およびアプリケーションＡＰｉの各処理が実行されることになる。

データ領域５０２には、データストアＤＳｉとアプリケーション同期情報ＳＹＣとが格納される。データストアＤＳｉには、マスタ情報Ｍと履歴情報Ｈが格納される。

マスタ情報Ｍは、各パーティションＰＴｊについての管理情報である。マスタ情報Ｍは、そのサーバＳＶｉが担当するパーティションＰＴｊについての管理情報を保持する。また、データストアＤＳｉは相互通信により一貫性を保証するため、マスタ情報Ｍはネットワークシステム１００内で共有され、そのサーバＳＶｉが担当しないパーティションＰＴｊについての管理情報も保持する。

履歴情報Ｈは、端末１０１からのメッセージの集合である。具体的には、メッセージの宛先のサーバＳＶｋに障害が発生した場合に、当該障害が発生してから復旧するまでの間に到達した当該サーバＳＶｋを宛先とするメッセージの集合である。復旧した場合、アプリケーションハブＡＨｉは、復旧したサーバＳＶｋに履歴情報Ｈｉ内のメッセージをトランザクションＩＤの古い順に送信する。これにより、復旧後も早期に一貫性を保証することができる。マスタ情報Ｍおよび履歴情報Ｈは、データストアプログラム５１３により制御される。

アプリケーション同期情報ＳＹＣは、アプリケーションハブＡＨｉが担当するパーティションＰＴｊについて、アプリケーションＡＰｉ間の同期状態を管理する情報である。アプリケーション同期情報ＳＹＣは、アプリケーションハブプログラム５１２により制御される。

＜マスタ情報Ｍ＞
図６は、マスタ情報Ｍの記憶内容例を示す説明図である。マスタ情報Ｍは、担当範囲フィールド６０１と、格納場所フィールド６０２と、対象アプリケーションセットフィールド６０３と、同期情報フィールド６０４と、を有し、各フィールド６０１〜６０４の値によりエントリを構成する。なお、パーティションＰＴｊのエントリをマスタ情報Ｍｊと称す。アプリケーションハブＡＨｉは、マスタ情報Ｍｊにアクセスし、自分の担当するパーティションＰＴｊを決定する。

担当範囲フィールド６０１は、担当範囲を格納する領域である。格納場所フィールド６０２は、当該エントリであるマスタ情報Ｍｊの格納場所を規定する領域であり、正常時フィールド６２１と障害時フィールド６２２とを有する。正常時フィールド６２１は、正常時におけるマスタ情報Ｍｊの格納場所（担当）であるサーバＳＶｊの識別情報を格納する領域である。障害時フィールド６２２は、障害発生時におけるマスタ情報Ｍｊの格納場所であるサーバＳＶｊの識別情報を格納する領域であり、複数台の障害に備えて、複数のサーバＳＶとその代行順序を記述することができる。

格納場所フィールド６０２は、マスタ情報Ｍｊの格納場所であると同時にアプリケーションハブＡＨｉの担当するパーティションＰＴｊを決定する。アプリケーションハブＡＨｉは、マスタ情報Ｍｊ内に、自分のいるサーバＳＶｉに対応するパーティションＰＴｊがあれば、自分の担当分として処理する。逆に、アプリケーションハブＡＨｉが、自分の担当しているパーティションＰＴｊのマスタ情報Ｍｊにアクセスするには、自サーバＳＶｊ内のマスタ情報用の格納領域にアクセスすればよい。正常時は、マスタ情報Ｍｊの各項目に変更を加えることができるのはアプリケーションハブＡＨｉだけである。

たとえば、パーティションＰＴｊを担当するサーバＳＶｊが正常時には、サーバＳＶｊに存在するマスタ情報Ｍｊが利用される。一方、パーティションＰＴｊを担当するサーバＳＶｊに障害が発生した時には、サーバＳＶ（ｊ＋１）に存在するマスタ情報Ｍ（ｊ＋１）が利用される。

本実施例では、正常時フィールド６２１との障害時フィールド６２２の対応関係は、データストアＤＳ（一貫性保証型ＫＶＳ）により決定されている。たとえばデータストアＤＳｊが保持するマスタ情報Ｍｊの複製は、データストアＤＳｊ＋１、ＤＳｊ＋２により保持される。データストアＤＳｊの障害時には、データストアＤＳｊ＋１が保持する複製であるマスタ情報Ｍｊが利用される。これにより、データストア処理が継続される。このとき、アプリケーションハブＡＨｉは、自分のサーバＳＶｊ内にマスタ情報Ｍｊがあるか否かで自分の担当を判断できるため、格納場所フィールド６０２を保持しないで、データストアＤＳｊの機能だけでも本実施例を実施することが可能である。

対象アプリケーションセットフィールド６０３は、対象アプリケーションセットを格納する領域である。対象アプリケーションセットとは、パーティションＰＴｊを担当するアプリケーションハブＡＨｉが、パーティションＰＴｊからのメッセージを分散するアプリケーションの組み合わせである。たとえば、パーティションＰＴｊの場合、対象アプリケーションセットは、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊである。アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊは、パーティションＰＴｊについてのアプリケーションＡＰ１〜ＡＰｎのプロセスまたはスレッドである。

同期情報フィールド６０４は、対象アプリケーションセットの同期情報を規定する領域であり、状態フィールド６４１と、開始時刻フィールド６４２と、最終マスタ情報取得要求時刻フィールド６４３と、トランザクションＩＤフィールド６４４と、を有する。正常時において、マスタ情報Ｍｊの同期情報フィールド６０４を制御するのは、対応するアプリケーションハブＡＨｉである。

状態フィールド６４１は、対象アプリケーションセットにより実行されるサービスの状態を、アプリケーションハブＡＨｉが格納する領域である。すなわち、状態フィールド６４１の値は、対象アプリケーションセットの使用状態を示す。開始時刻フィールド６４２は、サービスの開始時刻を格納する領域である。たとえば、アプリケーションハブＡＨｉがパーティションＰＴｊから最初に受信したメッセージの受信時刻である。最終マスタ情報取得要求時刻フィールド６４３は、最終マスタ情報取得要求時刻を格納する領域である。最終マスタ情報取得要求時刻は、マスタ情報取得要求を最後に取得した時刻である。

トランザクションＩＤフィールド６４４は、対象アプリケーションセットのアプリケーションごとのトランザクションＩＤを格納する領域である。トランザクションＩＤは、各メッセージに含まれる連続的な固有のＩＤである。トランザクションＩＤは、送信順にインクリメントされる。トランザクションＩＤは、端末からの要求（メッセージ）の順序を特定する情報である。パーティションＰＴｊにおいて、対象アプリケーションセットであるアプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊの各トランザクションＩＤの値ＴＩＤｊが同一の値であれば、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊは同期していることになる。一方、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊの各トランザクションＩＤの値ＴＩＤｊの少なくとも１つでも他のトランザクションＩＤの値ＴＩＤｊと異なる場合、同期していないことになる。データストアＤＳｉは、最終マスタ情報取得要求時刻のタイミングで、図７のトランザクションＩＤフィールド７０５からトランザクションＩＤを取得して、トランザクションＩＤフィールド６４４に格納する。

＜アプリケーション同期情報ＳＹＣｊ＞
図７は、アプリケーション同期情報ＳＹＣｊの記憶内容例を示す説明図である。アプリケーション同期情報ＳＹＣｊは、アプリケーションハブＡＨｉが保持する、アプリケーションハブＡＨｉ内の詳細な同期情報である。アプリケーション同期情報ＳＹＣｊは、アプリケーションハブＡＨｉが、担当するパーティションＰＴｊの対象アプリケーションセットであるアプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊにおいて、コネクションの有無とトランザクションＩＤおよび同期状態とを管理する情報である。

アプリケーション同期情報ＳＹＣｊは、担当範囲フィールド７０１と、格納場所フィールド７０２と、対象アプリケーションセットフィールド７０３と、コネクション情報フィールド７０４と、トランザクションＩＤフィールド７０５と、を有し、各フィールド７０１〜７０５の値によりエントリを構成する。

担当範囲フィールド７０１、格納場所フィールド７０２（正常時のみ）、対象アプリケーションセットフィールド７０３、および、トランザクションＩＤフィールド７０５については、マスタ情報Ｍのフィールド６０１〜６０３、６４４と同一であるため、説明を省略する。

コネクション情報フィールド７０４は、コネクション情報を格納する領域である。コネクション情報は、アプリケーションハブＡＨｉが、対象アプリケーションセットのアプリケーションＡＰｉに対してコネクションを張るときに生成される情報であり、たとえば、アプリケーションハブＡＨｉが、当該アプリケーションＡＰｉと通信するチャネルを一意に特定するチャネル番号である。たとえば、アプリケーションハブＡＨｉは、担当範囲ＰＴｊのメッセージをアプリケーションＡＰ１−ｊに接続する時点で、コネクション情報Ｃ１−ｊであるチャネルＩＤをコネクション情報フィールド７０４に格納する。アプリケーションハブＡＨｉは、データ一貫性保証するためのメッセージの送信順序保証を、コネクション情報フィールド７０４により実現する。

なお、トランザクションＩＤフィールド７０５の値は、アプリケーションハブＡＨｉから各アプリケーションＡＰｉにメッセージが送信される都度、当該メッセージに含まれるトランザクションＩＤに更新される。したがって、正常時は、同期しているため、どのトランザクションＩＤも同じ値となる。一方、あるサーバＳＶｋ（ｋ≠ｉ）に障害が発生した場合には、アプリケーションハブＡＨｉは、当該サーバＳＶｋ内のアプリケーションＡＰｋ−ｊと通信できなくなるため、アプリケーションＡＰｋ−ｊのトランザクションＩＤだけ更新されなくなる。

同期状態７０６は、対象アプリケーションセットの同期ができているか否かの状態、および同期できていない場合のエラー要因を格納する領域である。アプリケーションハブＡＨｊは、これらのアプリケーション同期情報ＳＹＣｊを元に、マスタ情報Ｍｊを更新する。負荷状態７０７は、対象アプリケーションセット毎の直近の平均応答時間、応答待ちの要求数、期間のアクセス頻度を格納する領域である。

＜シーケンス例＞
図８は、サーバ群ＳＶｓの内部のシーケンス例を示す説明図である。ステップＳ８０１からステップＳ８０４は、アプリケーションハブＡＨｉがマスタ情報Ｍを定期的に取得解析することにより、担当すべきパーティションＰＴのマスタに昇格させるか否かを確認するシーケンス例である。ステップＳ８０５は、アプリケーションハブＡＨｉが担当すべきパーティションＰＴのマスタに昇格するシーケンス例である。

ステップＳ８０１：データストアＤＳ１〜ＤＳｎは、データ一貫性保証のため、各データストアＤＳ１〜ＤＳｎを監視する相互通信を行う。ステップＳ８０１は、たとえば、定期的に実行される。ステップＳ８０１では、マスタ情報Ｍ１〜Ｍｎの一部の情報を含めることにより、各データストアＤＳ１〜ＤＳｎが同期できているかを厳密に管理することが可能である。

ステップＳ８０２：アプリケーションハブＡＨｉは、自サーバＳＶｉ内のデータストアＤＳｉにマスタ情報取得要求を送信する。ステップＳ８０２も、たとえば、定期的に実行される。マスタ情報取得要求は、データストアＤＳｉからマスタ情報Ｍｉを取得するための情報である。

ステップＳ８０３：データストアＤＳｉは、ステップＳ８０２の応答をアプリケーションハブＡＨｉに返す。

ステップＳ８０４：アプリケーションハブＡＨｉは、マスタ情報取得要求の応答（ステップＳ８０３）を受信すると、マスタ情報解析処理を実行する。詳細については図９で後述する。

ステップＳ８０５：アプリケーションハブＡＨｉは、マスタ情報解析処理（ステップＳ８０４）の結果により、昇格処理を実行する。昇格処理（ステップＳ８０５）とは、担当範囲のパーティションＰＴｊのマスタになる、すなわち、アプリケーションハブＡＨｉがアプリケーションを実行可能な状態にする処理である。アプリケーションハブＡＨｉは、昇格処理（ステップＳ８０５）によりマスタに昇格すると、アプリケーション同期情報ＳＹＣｊを生成する。

昇格処理（ステップＳ８０５）では、アプリケーションハブＡＨｉは、他のアプリケーションハブから更新されないようにマスタ情報Ｍｉを昇格中状態に更新し（ステップＳ８５０）、対象アプリケーションセットのアプリケーションＡＰｋの同期状態を確認し（ステップＳ８５１）、同期状態でなければ同期化要求を、履歴情報を持つデータストアに送信する（ステップＳ８５２）。

次にデータストアＤＳｉは、履歴情報をアプリケーションＡＰｉに送信する（ステップＳ８５３）。ここで、データストアＤＳｉは、履歴情報を送信する処理において、シェルプログラム等のデータストアＤＳｉと異なるプログラムを利用する。データストアＤＳｉは、履歴情報からデータを取得し、取得したデータをアプリケーションＡＰｉに送信してもよい。

アプリケーションハブＡＨｉは、アプリケーションＡＰｉの同期完了を確認し（ステップＳ８５４）、マスタ情報Ｍｉを昇格中状態からサービス中に更新する（ステップＳ８５５）。なお、上記昇格処理では各ステップに正常応答を示す（ＡＣＫ）が送信されているが、図では割愛している。また、アプリケーションＡＰｉが新規に起動したサーバＳＶｉ内のアプリケーションであれば、履歴情報の送信は行わない。なお、昇格処理（ステップＳ８０５）の詳細については、図１０で後述する。

図９は、図８に示したマスタ情報解析処理（ステップＳ８０４）の詳細な処理手順例を示すフローチャートである。アプリケーションハブＡＨｉは、取得したマスタ情報Ｍｉ内の正常時フィールド６２１に自分のサーバＳＶｉの識別情報があるか解析する（ステップＳ９０１）。自サーバＳＶｉの識別情報が記述されたマスタ情報Ｍｉがない場合（ステップＳ９０１：Ｎｏ）、アプリケーションハブＡＨｉは、マスタ情報解析処理（ステップＳ８０４）を終了する。

一方、マスタ情報Ｍｉ内に自分のサーバＳＶｉが記述されたマスタ情報Ｍｉがある場合（ステップＳ９０１：Ｙｅｓ）、アプリケーションハブＡＨｉは、マスタ情報Ｍｉの状態６４１を参照して、昇格すべきサービス状態であるか否かを判定する（ステップＳ９０２）。具体的には、サーバＳＶｉの識別情報が正常時フィールド６２１に記述されていて、かつマスタ情報Ｍｉの状態フィールド６４１が代行中である場合（代行中から正常に昇格すべき場合）、サーバＳＶｉが正常時フィールド６２１または障害時フィールド６２２に記述されていて、サービス停止状態の場合（サービス停止中から復旧すべき場合、または新規に起動したサーバのサービスを開始する場合）である。昇格すべきサービス状態である場合（ステップＳ９０２：Ｙｅｓ）、ステップＳ９０４に進む。

一方、昇格すべきサービス状態でなかった場合でも（ステップＳ９０２：Ｎｏ）、状態フィールド６４１がサービス中で正常状態であっても更新されていない場合がある。したがって、アプリケーションハブＡＨｉは、最終マスタ情報取得要求時刻から規定時間経過しているかを判定する（ステップＳ９０３）。最終マスタ情報取得要求時刻から規定時間経過していた場合（ステップＳ９０３：Ｙｅｓ）、障害が発生している可能性が高いため、ステップＳ９０４に進む。最終マスタ情報取得要求時刻から規定時間経過していない場合（ステップＳ９０３：Ｎｏ）、正常稼働している状態であるのでマスタ情報解析処理（ステップＳ８０４）を終了する。

ステップＳ９０４では、アプリケーションハブＡＨｉは、昇格処理を実行することを決定して（昇格処理のフローチャートは図１０で説明する）、マスタ情報解析処理（ステップＳ８０４）を終了する。

図１０は、図８に示した昇格処理（ステップＳ８０５）の詳細な処理手順例を示すフローチャートである。アプリケーションハブＡＨｉは、他のアプリケーションハブから更新されないようにマスタ情報Ｍｉを昇格中状態に更新し（ステップＳ１００１）、対象アプリケーションセットの各アプリケーションＡＰｉの同期状態を確認する（ステップＳ１００２）。同期状態の確認とは、マスタ情報Ｍｉの対象アプリケーションセットの各アプリケーションのトランザクションＩＤの同一性を確認する処理である。

アプリケーションＡＰｉが同期状態であれば（ステップＳ１００３：Ｙｅｓ）、アプリケーションハブＡＨｉは、マスタ昇格するためにマスタ情報Ｍｉの状態フィールド６４１をサービス中に変更し、当範囲のパーティションからのメッセージの受付を開始するマスタ昇格処理を行う（ステップＳ１００４）。

一方、同期状態でなければ（ステップＳ１００３：Ｎｏ）、アプリケーションハブＡＨｉは、同期化要求を、履歴情報を持つデータストアＤＳｉに送信する（ステップＳ１０１１）。このとき、同期化要求を受信したデータストアＤＳｉは、履歴情報をアプリケーションＡＰｉに送信する。履歴情報は、障害中に蓄積されたメッセージである。アプリケーションハブＡＨｉは、当該メッセージを、同期状態でないアプリケーションＡＰｉに送信することで、アプリケーション同期情報ＳＹＣｊにおける復旧したアプリケーションのトランザクションＩＤフィールド７０５を更新する。

次に、アプリケーションハブＡＨｉは、アプリケーションＡＰｉへ同期完了確認を送信して、同期状態を判定する（ステップＳ１０１２）。具体的には、アプリケーションハブＡＨｉは、対象アプリケーションセットの全アプリケーションが同一のトランザクションＩＤとなるのを確認する。同期状態であれば（ステップＳ１０１２：Ｙｅｓ）、マスタ昇格処理を行う（ステップＳ１００４）。一方、同期状態でない場合、即ち同期化要求に失敗した場合は（ステップＳ１０１２：Ｎｏ）、アプリケーションハブＡＨｉは、マスタ昇格処理を中止し（ステップＳ１０１３）、マスタ情報Ｍｉの状態フィールド６４１の昇格中を元の状態に戻して、昇格処理を終了する。また、同期状態でない場合（ステップＳ１０１２：Ｎｏ）、同期化要求（Ｓ１０１１）をリトライしてもよい。

＜障害発生時のシーケンス＞
つぎに、障害発生時のシーケンス例について説明する。端末１０１から送信されるメッセージには、データを更新するメッセージと、データを取得するメッセージがある。アプリケーションが、たとえば、ＲＤＢの制御プログラムである場合、データを更新するメッセージには、ＲＤＢへの更新対象のデータが含まれる。一方、データを取得するメッセージには、データが含まれない。

以下の図１１および図１２では、正常に動作しているサーバＳＶｉのアプリケーションハブの処理を中心に、サーバＳＶｋで障害が発生した場合のシーケンスを説明する。本例では、サーバＳＶｉはサーバＳＶｋの代行サーバとする。以降メッセ―ジの種類別にシーケンスを説明する。

図１１は、アプリケーションの障害発生時におけるネットワークシステム１００でのシーケンス例１を示す説明図である。図１１は、データを更新するメッセージが端末１０１から送信された場合のシーケンス例である。

ステップＳ１１０１：端末１０１は、ロードバランサ１０３を介して、担当になったアプリケーションハブＡＨｉにメッセージを送信する。

ステップＳ１１０２：アプリケーションハブＡＨｉは、メッセージ（ステップＳ１１０１）を受信すると、メッセージ判別処理を実行する。メッセージ判別処理（ステップＳ１１０２）は、上述したメッセージの種類（更新または取得）を判別する処理である。図１２では、更新と判別されたものとする。なお、アプリケーションハブＡＨｉは、受信したメッセージについてメッセージ変換をおこなってもよい。具体的には、たとえば、アプリケーションハブは、メッセージのヘッダに、アプリケーションハブＡＨｉの識別情報を挿入する。これにより、中継したアプリケーションハブをメッセージから特定することができる。

ステップＳ１１０３：アプリケーションハブＡＨｉは、対象アプリケーションセットのアプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊにメッセージを送信する。

ステップＳ１１０４：アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊはそれぞれ、アプリケーションハブＡＨｉにメッセージの受信完了を示すＡＣＫを返す。ただし、アプリケーションＡＰｋ−ｊでは障害が発生しているため、アプリケーションＡＰｋ−ｊは、メッセージを受信できない。

ステップＳ１１０５：アプリケーションハブＡＨｉは、同期判定処理を実行する。同期判定処理（ステップＳ１１０５）は、タイムアウトになるまでに、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊの中の少なくとも１つからＡＣＫの内容を解析し、アプリケーションが正常に処理を完了した状態であるか判定する処理である。また、同期判定処理（ステップＳ１１０５）は、どのアプリケーションが同期できなかったか、すなわち、どのアプリケーションで障害が発生したかを判定する。本例の場合、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊのうちアプリケーションＡＰｋのみからＡＣＫが返ってこない。そして、アプリケーションハブＡＨｉは、上記処理結果をアプリケーション同期情報ＳＹＣｊに記憶する。

ステップＳ１１０６：アプリケーションハブＡＨｉは、同期判定処理（ステップＳ１１０５）で正常状態であると判定された場合に、メッセージが処理されたことを示すＡＣＫを端末１０１に返す。なお、ＡＣＫには、どのアプリケーションで障害が発生したかを示す情報を含めてもよい。ＡＣＫは、ロードバランサ１０３を経由するため、ロードバランサ１０３は、ＡＣＫの中身を確認することにより、どのアプリケーションで障害が発生したかをＡＣＫから特定することができる。

ステップＳ１１０７：アプリケーションハブＡＨｉは、障害の発生したアプリケーションＡＰｋの代行先であるデータストアＤＳｉを判定する。代行先のデータストアＤＳｉは、ロードバランサ１０３と同じルール（管理テーブル１０４を参照）で決定されているため、アプリケーションは代行先のデータストアＤＳｉを判定することができる。

ステップＳ１１０８：アプリケーションハブＡＨｉは、アプリケーションＡＰｋ−ｊが用いているデータストアＤＳｋの代行先であるデータストアＤＳｉにメッセージを送信する。ここで、送信されるメッセージは、２種類ある。

１つは、アプリケーションハブＡＨｉの送信先である対象アプリケーションセットに含まれており、サーバＳＶｋの障害によりアプリケーションハブＡＨｉと通信できなくなったアプリケーションＡＰｋ−ｊ宛の現在進行中のメッセージである。

もう１つは、本来障害が発生していなければ、アプリケーションハブＡＨｋからアプリケーションＡＰｋ−ｊに送信されていた過去のメッセージである。当該メッセージは、代行により、データストアＤＳｉに送信される。

ステップＳ１１０９：データストアＤＳｉは、送信されてきたメッセージ（ステップＳ１１０８）を履歴情報として格納する。

ステップＳ１１１０：データストアＤＳｉは、履歴情報を格納したことを示すＡＣＫをアプリケーションハブＡＨｉに返す。

図１２は、アプリケーションの障害発生時におけるネットワークシステム１００でのシーケンス例２を示す説明図である。図１２は、データを取得するメッセージが端末１０１から送信された場合のシーケンス例である。図１１と同一処理については同一ステップ番号を付す。

ステップＳ１１０１：端末１０１は、ロードバランサ１０３を介して、担当になったアプリケーションハブＡＨｉにメッセージを送信する。

ステップＳ１１０２：アプリケーションハブＡＨｉは、メッセージ（ステップＳ１１０１）を受信すると、メッセージ判別処理を実行する。メッセージ判別処理（ステップＳ１１０２）は、上述したメッセージの種類（更新または取得）を判別する処理である。図１２では、取得と判別されたものとする。なお、アプリケーションハブＡＨｉは、受信したメッセージについてメッセージ変換をおこなってもよい。具体的には、たとえば、アプリケーションハブＡＨｉは、メッセージのヘッダに、アプリケーションハブＡＨｉの識別情報を挿入する。これにより、中継したアプリケーションハブＡＨｉをメッセージから特定することができる。

ステップＳ１２０３：アプリケーションハブＡＨｉは、転送先を選択する。メッセージの種類が、データを取得するメッセージである場合、アプリケーションハブＡＨｉは、対象アプリケーションセットのすべてのアプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊにメッセージを送信する必要はない。したがって、アプリケーションハブＡＨｉは、対象アプリケーションセットの中から、アプリケーション同期情報ＳＹＣｊで同期状態にあり、かつ、障害が発生したアプリケーションＡＰｋ−ｊ以外の残余のアプリケーションのいずれかを選択すればよい。また、この場合、アプリケーションＡＰ１−ｊ〜ＡＰｎ−ｊ（ＡＰｋ−ｊ除く）のうち、アプリケーション同期情報ＳＹＣｊで負荷が最も軽いアプリケーションＡＰｋ−ｊを選択してもよい。

ステップＳ１２０５：転送先のアプリケーションＡＰｉ−ｊは、メッセージ（ステップＳ１３０４）を受けると、制御対象のＲＤＢにアクセスしてデータを取得し、取得したデータをアプリケーションハブＡＨｉに返す。

ステップＳ１２０６：アプリケーションハブＡＨｉは、アプリケーションＡＰｉ−ｊからのデータを端末１０１に返す。

＜メッセージ更新処理の具体例＞
つぎに、メッセージ更新処理の具体例について、図１３〜図１７を用いて説明する。ここでは、サーバＳＶｉの台数をｎ＝３台とし、担当範囲となるパーティションＰＴｊの数をｍ＝４とする。

図１３は、サーバ群ＳＶｓの論理構成を示す説明図である。図１４は、図１３に示した論理構成におけるマスタ情報Ｍの例を示す説明図である。サーバＳＶ１は、パーティションＰＴ１、ＰＴ４を担当し、マスタ情報Ｍ１、Ｍ４を用いる。サーバＳＶ２は、パーティションＰＴ２を担当し、マスタ情報Ｍ２を用いる。サーバＳＶ３は、パーティションＰＴ３を担当し、マスタ情報Ｍ３を用いるものとする。また、データストアＤＳｉはデータの耐障害性を実現するために、複製したデータを保持するが、ここでは、サーバの２重障害に備え、３台のサーバＳＶ１〜ＳＶ３でデータを３多重で保持する。

また、各データストアＤＳ１〜ＤＳ３には、便宜的に担当のパーティションＰＴｊに対応するマスタ情報Ｍｉしかないが、実際には、一貫性が保持されるため、各データストアＤＳ１〜ＤＳ３には、全マスタ情報Ｍ１〜Ｍ４をまとめたマスタ情報Ｍが存在する。また、データストアＤＳｉはデータを３多重保持するため、マスタ情報の複製を他の２台のデータストアＤＳが保持する。図１３では、マスタ情報Ｍ１、Ｍ４の複製をデータストアＤＳ２、ＤＳ３が保持する。

アプリケーションハブＡＨ１は、対象アプリケーションセットＡＰＳ１，ＡＰＳ４と通信可能である。アプリケーションハブＡＨ２は、対象アプリケーションセットＡＰＳ２と通信可能である。アプリケーションハブＡＨ３は、対象アプリケーションセットＡＰＳ３と通信可能である。

サーバＳＶ１は、パーティションＰＴ１からのメッセージＭＳＧ１−１，２−１，３−１についての更新処理と、パーティションＰＴ４からのメッセージＭＳＧ１−４，２−４，３−４についての更新処理と、をおこなう。サーバＳＶ２は、パーティションＰＴ２からのメッセージＭＳＧ１−２，２−２，３−２についての更新処理をおこなう。サーバＳＶ３は、パーティションＰＴ２からのメッセージＭＳＧ１−３，２−３，３−３についての更新処理をおこなう。なお、メッセージの符号ＭＳＧｉ−ｊは、アプリケーションＡＰｉ−ｊ宛のメッセージである。

各アプリケーションセットＡＰＳ１〜ＡＰＳ４内のアプリケーションＡＰ１−１，ＡＰ２−１，ＡＰ３−１，ＡＰ１−２，ＡＰ２−２，ＡＰ３−２，ＡＰ１−３，ＡＰ２−３，ＡＰ３−３，ＡＰ１−４，ＡＰ２−４，ＡＰ３−４は、いずれも同一機能を実現する同種のアプリケーションである。

図１５は、アプリケーション同期情報の例を示す説明図である。アプリケーションハブＡＨ１は、アプリケーション同期情報ＳＹＣ１、ＳＹＣ４を保持し、アプリケーションハブＡＨ２は、アプリケーション同期情報ＳＹＣ２を保持し、アプリケーションハブＡＨ３は、アプリケーション同期情報ＳＹＣ３を保持する。

図１６は、サーバＳＶ１に障害が発生した場合の図１３に示した論理構成の変更例を示す説明図である。網掛け箇所がサーバＳＶ１に属する構成である。ここでは、サーバＳＶ１の代行サーバをサーバＳＶ２とする。

サーバＳＶ１は、障害発生によりメッセージの処理が不可能となる。このとき、データストアＤＳ２は、データストアＤＳ２内の複製データであるマスタ情報Ｍ１を用いて、データストアＤＳ１の処理を継続する。

サーバＳＶ３では、アプリケーションハブＡＨ３は、アプリケーションＡＰ１−３にアクセスすることができない。したがって、サーバＳＶ３では、アプリケーションハブＡＨ３は、メッセージＭＳＧ２−３およびメッセージＭＳＧ３−３についてはこれまで通りアプリケーションＡＰ２−３およびＡＰ３−３にアクセスする。一方、メッセージＭＳＧ１−３については、アプリケーションハブＡＨ３は、履歴情報Ｈ１−３としてデータストアＤＳ２に格納する。

サーバＳＶ２では、アプリケーションハブＡＨ２は、アプリケーションＡＰ１−２にアクセスすることができない。したがって、サーバＳＶ２では、アプリケーションハブＡＨ２は、メッセージＭＳＧ２−２およびメッセージＭＳＧ３−２についてはこれまで通りアプリケーションＡＰ２−２およびＡＰ３−２にアクセスする。一方、メッセージＭＳＧ１−２については、アプリケーションハブＡＨ２は、履歴情報Ｈ１−２としてデータストアＤＳ２に格納する。

また、アプリケーションハブＡＨ２は、サーバＳＶ１のデータストアＤＳ１で利用されていたマスタ情報Ｍ１、Ｍ４がサーバＳＶ２内に移動したことにより、マスタ情報Ｍ１、Ｍ４にアクセスして昇格処理を行い、アプリケーションハブＡＨ１の代行（パーティションＰＴ１、ＰＴ４）の処理を行う。同時にアプリケーションハブＡＨ２は、マスタ情報Ｍ２も継続して処理している。アプリケーションハブＡＨ２は、サーバＳＶ１に割り振られていたメッセージＭＳＧ２−１，ＭＳＧ３−１を受信して、サーバＳＶ１のアプリケーションハブＡＨ１がアクセスしていたアプリケーションＡＰ２−１，ＡＰ３−１にアクセスする。同様に、アプリケーションハブＡＨ２は、サーバＳＶ１に割り振られていたメッセージＭＳＧ２−４，ＭＳＧ３−４を受信して、サーバＳＶ１のアプリケーションハブＡＨ１がアクセスしていたアプリケーションＡＰ２−４，ＡＰ３−４にアクセスする。

また、サーバＳＶ２では、アプリケーションハブＡＨ２は、アプリケーションＡＰ１−１，ＡＰ１−４にアクセスできない。したがって、アプリケーションハブＡＨ２は、サーバＳＶ１に割り振られていたメッセージＭＳＧ１−１，ＭＳＧ１−４を受信して、履歴情報Ｈ１−１、Ｈ１−４としてデータストアＤＳ２に格納する。この状態から復旧すると、論理構成は、図１６の状態から図１３の状態となる。このとき、データストアＤＳ２内のマスタ情報Ｍ１、Ｍ４のうち、データストアＤＳ２からデータストアＤＳ１へ差分データがコピーされ、データストアＤＳ１内のマスタ情報Ｍ１、Ｍ４が元に戻る。次にアプリケーションハブＡＨ１は、データストアＤＳ１内のマスタ情報Ｍ１、Ｍ４にアクセスし、昇格処理を行う。

図１７は、サーバＳＶ１に障害が発生した場合の図１５に示したアプリケーション同期情報の変更例を示す説明図である。サーバＳＶ１に障害があり、アプリケーション同期情報ＳＹＣ１，ＳＹＣ４は利用不可であるため省略する。なお、網掛け箇所は、サーバＳＶ１のアプリケーションについてのエントリである。

アプリケーション同期情報ＳＹＣ２は、マスタ情報Ｍ１、Ｍ４を参照して、パーティションＰＴ１，ＰＴ４のエントリを生成する。なお、マスタ情報Ｍ１、Ｍ４にはコネクション情報がないため、アプリケーションハブＡＨ２は新規に生成してもよい。

障害発生中では、各パーティションにおいて、網掛け箇所とそうでない箇所でトランザクションＩＤの値が異なる。たとえば、アプリケーション同期情報ＳＹＣ２のパーティションＰＴ２では、アプリケーションＡＰ１−２のトランザクションＩＤの値と、アプリケーションＡＰ２−２，ＡＰ３−２のトランザクションＩＤの値とは、異なる。この状態から復旧すると、アプリケーション同期情報は、図１７の状態から図１５の状態になる。

このように、本実施例によれば、アプリケーションハブＡＨｉは、自サーバＳＶｉ内のデータストアＤＳｉに格納されているマスタ情報Ｍにアクセスし、当該マスタ情報ＭにおいてアプリケーションハブＡＨｉが担当する担当範囲に関連付けられているサーバが自サーバＳＶｉであるか否かを判定する。自サーバＳＶｉであると判定された場合、アプリケーションハブＡＨｉは、アプリケーションハブＡＨｉが各サーバＳＶ１〜ＳＶｎに分散されたアプリケーションを実行する資格があるマスタに昇格することを決定する。これにより、マスタに昇格したアプリケーションハブＡＨｉは、単一サーバで動作するアプリケーションを非改造で（または改造するための工数を削減して）、同一の実行環境を持つ複数のサーバ上で並列実行させることができる。

また、本実施例によれば、障害が発生したサーバＳＶｋのアプリケーションＡＰｋ−ｊにメッセージを配信する他のサーバＳＶｉでは、アプリケーションハブＡＨｉが、当該メッセージを履歴情報としてデータストアＤＳｉに格納する。これにより、サーバＳＶｋが復旧するまでの間のメッセージを蓄積することができる。したがって、アプリケーションを非改造で障害発生時に当該アプリケーション宛のメッセージを復旧まで退避させることができる。

また、サーバＳＶｋの復旧後は、データストアＤＳｉに退避させた履歴情報であるメッセージをアプリケーションＡＰｋ−ｊに配信することにより、アプリケーションＡＰｋ−ｊは、障害発生から復旧までの間に届いたメッセージを到着順で処理することができる。したがって、復旧後は、アプリケーションが制御するデータベースの一貫性を保持することができる。

また、障害発生時におけるメッセージの蓄積や復旧後の処理については、アプリケーションを改修せずに、アプリケーションを多重化（冗長化）することができるため、データ処理システム（サーバ群ＳＶｓ）の高信頼化を実現することができる。

また、障害が発生したサーバＳＶｋの代行サーバは、サーバＳＶｋの対象アプリケーションセットに属し、かつ、サーバＳＶｋ外の他のサーバＳＶｉにあるアプリケーションＡＰｉ−ｊ宛のメッセージを代行受信し、アプリケーションＡＰｉ−ｊに代行送信する。したがって、アプリケーションＡＰｉ−ｊ宛のメッセージについては、サービスを継続することができる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加、削除、または置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１００ ネットワークシステム
１０１ 端末
１０２ ネットワーク
１０３ ロードバランサ
１０４ 管理テーブル
ＡＨｉ アプリケーションハブ
ＡＰｉ アプリケーション
ＤＳｉ データストア
Ｈ 履歴情報
Ｍ マスタ情報
ＳＹＣ アプリケーション同期情報
ＳＶｉ サーバ
ＳＶｓ サーバ群（データ処理システム）

Claims (9)

1. 端末群とネットワークを介して通信可能なデータ処理システムであって、
   前記データ処理システムは、相互通信可能な複数のサーバを有し、
   前記複数のサーバの各々は、
   前記端末群のうち担当範囲の端末からの要求に応じたデータ処理を実行可能なデータ処理部と、
   前記担当範囲と前記担当範囲の端末にアクセス可能なサーバとを関連付けたマスタ情報を保持し、他のデータストアとの相互通信により前記マスタ情報を共有化するデータストアと、
   前記各サーバの前記データストア内の前記マスタ情報にアクセス可能であり、かつ、前記各データ処理部を制御して、前記データ処理を実行可能な分散処理部と、を有し、
   前記分散処理部は、
   自サーバ内の前記データストアに格納されている前記マスタ情報にアクセスし、当該マスタ情報で前記担当範囲に関連付けられているサーバが前記自サーバであるか否かを解析し、解析結果に基づいて前記分散処理部が前記データ処理部を制御できる資格ありと決定することを特徴とするデータ処理システム。
2. 前記分散処理部は、
   前記自サーバ内の前記データストアに格納されている前記マスタ情報にアクセスして、前記データ処理部の使用状態を示す情報を更新し、前記使用状態を示す情報に基づいて前記分散処理部が前記データ処理部を制御できる資格ありと決定することを特徴とする請求項１に記載のデータ処理システム。
3. 前記分散処理部は、
   前記使用状態を示す情報に基づいて前記分散処理部が前記データ処理部を制御できる資格がないと判定された場合、前記マスタ情報への最新のアクセスからの経過時間に基づいて前記分散処理部が前記データ処理部を制御できる資格ありと決定することを特徴とする請求項２に記載のデータ処理システム。
4. 前記分散処理部は、
   前記データ処理部を制御できる資格ありと決定された場合、前記データ処理部を制御可能に設定することを特徴とする請求項１に記載のデータ処理システム。
5. 端末群とネットワークを介して通信可能なデータ処理システムであって、
   前記データ処理システムは、相互通信可能な複数のサーバを有し、
   前記複数のサーバの各々は、
   前記端末群のうち担当範囲の端末からの要求に応じたデータ処理を実行するデータ処理部と、
   前記データ処理部に前記要求を送信し、前記複数のサーバのうち自サーバ以外の他のサーバ内の前記データ処理部に前記要求を配信し、前記要求の順序を特定する情報を保持する分散処理部と、
   前記担当範囲について前記要求の順序を特定する情報を前記分散処理部から取得して保持するマスタ情報を格納するデータストアと、を有し、
   前記データストアは、
   他の担当範囲の端末からの要求の順序を特定する情報を前記他のサーバのデータストアから取得して前記マスタ情報を格納し、
   前記分散処理部は、
   前記各データ処理部から前記要求に対する応答があった場合に前記要求の順序を特定する情報を更新し、前記複数のデータ処理部のうちいずれかのサーバのデータ処理部から前記要求に対する応答がなかった場合、前記いずれかのサーバのデータ処理部について前記要求の順序を特定する情報を更新せずに、前記要求を履歴情報として前記データストアに格納することを特徴とするデータ処理システム。
6. 前記分散処理部は、
   前記要求の種別が、データ更新またはデータ取得のいずれであるかを判別し、
   前記要求の種別が前記データ更新である場合、前記各データ処理部から前記要求に対する応答があった場合に前記要求の順序を特定する情報を更新し、前記複数のデータ処理部のうち前記いずれかのサーバのデータ処理部から前記要求に対する応答がなかった場合、前記いずれかのサーバのデータ処理部について前記要求の順序を特定する情報を更新せずに、前記要求を履歴情報として前記マスタ情報に格納することを特徴とする請求項５に記載のデータ処理システム。
7. 前記分散処理部は、
   前記要求の種別が前記データ取得である場合、前記要求の転送先を前記複数のデータ処理部のうち前記いずれかのサーバのデータ処理部以外の他のデータ処理部から選択し、選択した前記他のデータ処理部に前記要求を送信することを特徴とする請求項６に記載のデータ処理システム。
8. 前記複数のサーバの各々は、前記複数のサーバのうち代行元のサーバに障害が発生した場合の代行先に指定されており、
   前記分散処理部は、
   前記いずれかのサーバが前記代行元のサーバである場合、前記代行元のサーバの分散処理部が分散処理する要求のうち、前記代行元のサーバのデータ処理部に配信する要求については、前記履歴情報として前記データストアに格納し、前記代行元のサーバ以外の他のサーバのデータ処理部に配信する要求については、前記代行元のサーバ以外の他のサーバのデータ処理部に配信して当該要求の順序を特定する情報を保持することを特徴とする請求項５に記載のデータ処理システム。
9. 端末群とネットワークを介して通信可能なデータ処理システムを構成する相互通信可能な複数のサーバの中のサーバであって、
   前記端末群のうち担当範囲の端末からの要求に応じたデータ処理を実行可能なデータ処理部と、
   前記担当範囲と前記担当範囲の端末にアクセス可能なサーバとを関連付けたマスタ情報を保持し、他のデータストアとの相互通信により前記マスタ情報を共有化するデータストアと、
   前記各サーバの前記データストア内の前記マスタ情報にアクセス可能であり、かつ、前記各データ処理部を制御して、前記データ処理を実行可能な分散処理部と、を有し、
   前記分散処理部は、
   自サーバ内の前記データストアに格納されている前記マスタ情報にアクセスし、当該マスタ情報で前記担当範囲に関連付けられているサーバが前記自サーバであるか否かを解析し、解析結果に基づいて前記分散処理部が前記データ処理部を制御できる資格ありと決定することを特徴とするサーバ。

Images