JP6181216B2 - 通信制御装置、通信制御方法、プログラムおよび通信システム - Google Patents

Description

本発明の実施形態は、通信制御装置、通信制御方法、プログラムおよび通信システムに関する。

分散データベース管理システムの可用性を高める技術として、例えば透過的なフェイルオーバー処理が知られている。透過的なフェイルオーバー処理では、アプリケーションからの要求の処理途中に分散サーバまたは分散サーバとの接続経路に異常が発生したとしても、アプリケーションの接続先が他の分散サーバに自動的に切り替えられる。

フェイルオーバー処理の実現方法は、対象とする分散データベースのデータモデルや操作内容によって異なる。例えばトランザクション制御を行わない分散キーバリューストアでは、適宜選択した分散サーバから正常応答が得られるまで登録要求を繰り返し発行することでフェイルオーバー処理が実現できる。トランザクション制御を行う分散データベースでは、３相コミットのような分散プロトコルに基づく透過的フェイルオーバー処理が知られている。

特表２００９−５０５２２３号公報

しかしながら、例えば、両者の構造を持ち合わせる大量のデータを一つのアプリケーションで扱う場合、開発コストまたは応答性能を犠牲にする必要があった。例えば二つの異なるタイプの分散データベースを利用する方法、または、データ構造を大幅に見直し巨大なバリューとして一貫性を必要とするデータセットを一まとめに扱うことで分散キーバリューストアのみを利用する方法では、構成が複雑になり開発コストが増加する。トランザクション制御を行う分散データベースのみを利用する方法では、応答性能が犠牲となる。

実施形態の通信制御装置は、決定部と、要求部と、記憶制御部と、回復部と、を備える。決定部は、要求されたデータ操作と、データ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、データ操作の状態を示す状態情報を記憶する第１の操作方法、および、状態情報を記憶しない第２の操作方法のいずれかを、データ操作の方法として決定する。要求部は、データ操作をサーバ装置に要求する。記憶制御部は、第１の操作方法が決定された場合、データ操作の実行時に状態情報を記憶部に記憶する。回復部は、データ操作の実行時に障害が発生した場合、決定部により決定された操作方法に応じた回復方法により、発生した障害を回復する。

図１は、本実施形態にかかる通信システムの構成例を示すブロック図である。 図２は、本実施形態の通信制御装置および分散サーバの機能構成例を示すブロック図である。 図３は、本実施形態におけるデータ操作処理の一例を示すフローチャートである。 図４は、本実施形態のスキーマ特定処理の一例を示すフローチャートである。 図５は、本実施形態のステートレス操作判定処理の一例を示すフローチャートである。 図６は、本実施形態の障害回復処理の一例を示すフローチャートである。 図７は、本実施形態のスキーマ検証処理の一例を示すフローチャートである。 図８は、本実施形態にかかる装置のハードウェア構成例を示す説明図である。

以下に添付図面を参照して、この発明にかかる通信制御装置の好適な実施形態を詳細に説明する。

上記のように、フェイルオーバー処理の実現方法は、対象とする分散データベースのデータモデルなどによって異なる。トランザクション制御を行わない分散キーバリューストアのフェイルオーバー処理についてさらに説明する。キーとバリューの組からなるレコードをクライアントより登録する場合を想定する。

この場合、トランザクションの開始や終了といった、個々のレコード操作の系列を識別するための情報は、分散サーバには記録されない。そのため、登録要求に対する成功応答を待っている間に要求先の分散サーバとの接続が解消されると、再び同一の分散サーバに接続して問い合わせたとしても、登録操作自体が完了したのかどうかをクライアントから調べることはできない。一方、データベース内のキーはユニークにレコードを特定できる性質を持つ。従ってクライアントにおける透過的なフェイルオーバー処理は、レコードの登録操作の反映状況にかかわらず、適切な分散サーバを随時選択し、分散サーバからの正常応答が得られるまでレコードの登録要求を繰り返し発行するだけで実現できる。

次にトランザクション制御を行う分散データベースのフェイルオーバー処理について説明する。トランザクション制御を行う分散データベースでは、３相コミットのような分散プロトコルに基づき透過的フェイルオーバー処理を行うことで、レコードをユニークに特定できないようなデータに対する操作についても、一貫性が保証される。しかし、分散キーバリューストアとは異なり、一貫性を保証するために複雑な処理を行う必要がある。例えば、３相コミットに基づく分散システムでトランザクションを確定させるためには、関係する分散サーバの一部に障害が発生してもレコードの反映状況に差異が出ないよう、他の分散サーバでの登録を待機する準備状態などに遷移してからトランザクションの確定が進められる。これらの状態遷移のためには、レコード登録のための通信以外にも何回か通信を行う必要がある。従って、ユニーク性の判定処理が通信の応答待ち時間と比べて無視できると仮定した場合、分散キーバリューストアでも管理可能なデータを登録しようとすると、トランザクション制御のために通信回数が増える分だけ応答時間が長くなる。特に、個々のデータ操作要求のたびにトランザクションを確定させるコミット設定が有効となっている場合は、応答時間の差異が顕著になる。

従って、高い応答性能を要求されるデータベースアプリケーションを構築する場合、扱うデータ構造や想定されるデータ操作の種別に応じて最適なデータベースを選択する必要が生じる。例えば、センサーデータのように値同士の一貫性が比較的重視されないデータのみを大量に扱う場合、スケール性能の期待できる分散キーバリューストアが適している。また、センサーの一覧や属性情報など値同士の一貫性が重要となるデータを扱う場合、トランザクション制御を行う分散データベースが適している。

また上記のように、両者の構造を持ち合わせる大量のデータを一つのアプリケーションで扱う場合、データベース構造等が複雑になり開発コストが増大する、または、応答性能が低下する問題を解消できることが望ましい。

本実施形態は、操作対象のテーブルのスキーマ（構造）などに基づき、適用すべきデータ操作の方法（操作方法）を切り替える。そして、例えば障害の回復のためにデータ操作の状態を管理する必要がある操作方法を適用することが決定された場合は、データ操作の状態を示す情報（状態情報）を記憶する制御などが、データ操作時に実行される。

操作対象のテーブルのスキーマは、例えば分散データベースのクライアントに記憶される。スキーマは、対象レコードのユニーク性などレコード間およびテーブル間の制約情報を含む。例えばクライアントは、スキーマごとに定まる制約情報に基づき、可用性と一貫性とを維持する上で必要最低限となる、より通信回数の少ない操作方法を選択する。

クライアントと分散データベースを管理するサーバ（分散サーバ）は、必要に応じて、操作系列を記憶する機能を有する。操作系列とは、関連する１以上のデータ操作を示す情報である。例えば１つのトランザクションに含まれる１以上のデータ操作を識別する情報が操作系列の一例である。また操作系列は、上記のデータ操作の状態を示す状態情報の一例である。

クライアントは、障害を検知すると、選択された操作方法に応じた障害回復方法により、障害からの回復処理を実行する。回復処理の具体例について以下に説明する。

主キーを持つテーブルにおいて、ＳＱＬの「INSERT OR REPLACE」文を要求し、または、キーバリューストアのＰＵＴ命令に相当するレコード置き換えを要求し、変更内容を確定させる単独のトランザクションを実行する例を考える。このような例では、接続経路または接続先の分散サーバに障害が発生した場合、再度接続を確立した上で、改めて同じ要求を送信すればよい。このようなスキーマのテーブルに対する操作においては、何度繰り返し実行してもテーブルの内容が同一になることが期待できるためである。分散サーバ上では、トランザクションの実行状態を記憶しておく必要がなく、事前および事後のトランザクション制御命令を送信する必要もない。従って、実行状態の制御を伴わないステートレス操作のみによってデータ操作を実現できる。

次に、主キーを持たないテーブルに対する「INSERT」文からなる単独のトランザクションを実行する例を考える。このような例では、障害が発生した場合、再接続後に単に同じ要求を再試行すると、二重登録の発生など意図しない結果が得られる可能性がある。これは、スキーマ定義上、テーブルの内容だけでは、目的のレコードを改めて登録する必要性があるかどうかを判別できないためである。判別を可能とするためには、登録操作の系列を識別できるようにする必要がある。例えば、クライアントと分散サーバとの間で、操作系列の識別情報を事前に共有するための通信や操作系列を管理するための操作を行う。これにより、クライアントは登録操作の系列を識別できるようになる。すなわち、実行状態の制御を伴うステートフル操作によってデータ操作が実現可能となる。ただし、主キーを持つテーブルに対する操作と比べて、実行状態の管理や識別情報に関する事前の通信といった処理が加わる分だけ応答性能に影響が生じうる。

主キーを持つか否かなどの特性を判別し、最適な操作方法に切り替えるためには、スキーマを入手して記憶し、操作命令を解析する機能が必要となる。本実施形態では、操作命令を解析した結果とスキーマとの組み合わせに基づいてステートレス性の有無を判別し、適切な操作方法を選択する。これにより、実行状態の管理コストおよび通信回数を削減することが可能となる。

図１は、本実施形態にかかる通信システムの構成例を示すブロック図である。図１に示すように、本実施形態の通信システムは、端末４００ａ、４００ｂ、４００ｃ、４００ｄと、アプリケーションサーバ３００ａ、３００ｂと、通信制御装置１００ａ、１００ｂ、１００ｃと、分散サーバ２００ａ、２００ｂ、２００ｃと、を含む。

端末４００ａ、４００ｂは、ネットワーク５１０ａを介してアプリケーションサーバ３００ａに接続される。端末４００ｃ、４００ｄは、ネットワーク５１０ｂを介してアプリケーションサーバ３００ｂに接続される。通信制御装置１００ａ、１００ｂ、１００ｃは、ネットワーク５２０を介して分散サーバ２００ａ、２００ｂ、２００ｃに接続される。

ネットワーク５１０ａ、５１０ｂは、例えばＷＡＮ（Wide Area Network）である。ネットワーク５２０は、例えばＬＡＮ（Local Area Network）である。ネットワーク構成はこれらに限られるものではなく、従来から用いられているあらゆるネットワーク構成を適用できる。例えば、ネットワーク５１０ａ、５１０ｂは１つのネットワークに統合されていてもよいし、３以上のネットワークに分割されていてもよい。

端末４００ａ、４００ｂ、４００ｃ、４００ｄは、同様の構成を備えるため、区別する必要がない場合は単に端末４００という場合がある。同様に、アプリケーションサーバ３００ａ、３００ｂは単にアプリケーションサーバ３００、通信制御装置１００ａ、１００ｂ、１００ｃは単に通信制御装置１００、分散サーバ２００ａ、２００ｂ、２００ｃは単に分散サーバ２００という場合がある。各装置（端末４００、アプリケーションサーバ３００、通信制御装置１００、分散サーバ２００）は図示した個数に限られず、任意の個数でよい。

端末４００は、ユーザが利用するパーソナルコンピュータなどの装置である。アプリケーションサーバ３００は、端末４００を介して利用されるアプリケーションなどを提供するサーバ装置である。

通信制御装置１００は、アプリケーションサーバ３００と分散サーバ２００との間の通信を制御する。例えば通信制御装置１００は、アプリケーションサーバ３００で動作するアプリケーションなどからの要求に応じて、分散サーバ２００に記憶されているデータを操作する処理を制御する。通信制御装置１００は、アプリケーションサーバ３００に組み込まれたクライアントモジュール（JDBC（Java（登録商標） Database Connectivity)ドライバ、ODBC（Open Database Connectivity）ドライバ、データベースドライバなどのプログラム）として構成してもよいし、アプリケーションサーバ３００とは独立の機器またはこの機器で動作するプログラムとして構成してもよい。

分散サーバ２００は、データを分散して記憶するサーバ装置である。複数の分散サーバ２００により分散データベース管理システムが構成される。例えば同一のデータが、複数の分散サーバ２００で多重に記憶される。分散サーバ２００が管理するデータベースは、主キーを持つテーブルと、主キーを持たないテーブルとを共に含みうる。主キーの有無などのスキーマの判定は、テーブルごとに実行される。

ユーザが端末４００よりアプリケーションサーバ３００で稼働するアプリケーションを使用すると、必要に応じてデータベースに対して参照または変更の操作要求が発生する。操作要求は、通信制御装置１００を通じて伝達され、いずれかの分散サーバ２００に格納されたデータに対して操作が行われる。

図２は、本実施形態の通信制御装置１００および分散サーバ２００の機能構成例を示すブロック図である。図２に示すように、通信制御装置１００は、決定部１０１、検知・回復部１０２、要求部１０３、記憶制御部１０４、および、記憶部１１０を備える。

記憶部１１０は、通信制御装置１００で実行される各種処理で用いられるデータを記憶する。例えば記憶部１１０は、データ操作の状態を示す状態情報（操作系列）を記憶する。操作系列は、上記のように通信制御装置１００の記憶部１１０と、分散サーバ２００の記憶部２１０（後述）とで共通に記憶される。

図２の例では、操作系列は、操作系列を識別する情報（「系列ａ」、「系列ｂ」）と、実行済みの最終の操作を識別する情報（「操作ａ１」、「操作ｂ２」）とを含む。操作系列のデータ構造はこれに限られるものではなく、操作系列ごとに、現在のデータ操作の状態を特定できる情報であればどのようなデータ構造であってもよい。

記憶制御部１０４は、記憶部１１０に対するデータの書き込み、および、記憶部１１０からのデータの読み出しを制御する。例えば記憶制御部１０４は、ステートフル操作を行う操作方法が決定された場合、データ操作時に操作系列を記憶部１１０に記憶する処理を制御する。

決定部１０１は、要求されたデータ操作と、このデータ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、データ操作の方法を決定する。例えば決定部１０１は、データ操作の状態を示す状態情報（操作系列など）を記憶する操作方法（第１の操作方法）、および、状態情報を記憶しない操作方法（第２の操作方法）のいずれかを決定する。状態情報を記憶する操作方法は、例えば、実行状態の制御を伴うステートフル操作に相当する。状態情報を記憶しない操作方法は、例えば、実行状態の制御を伴わないステートレス操作に相当する。従って、決定部１０１は、要求されたデータ操作が、ステートレス性を有するか否かを判別する、と解釈することもできる。

決定部１０１は、まず、アプリケーションサーバ３００、分散サーバ２００、および、決定部１０１の内部のキャッシュ、などから得られる情報を参照し、操作対象のテーブルに対応するスキーマを求める。そして決定部１０１は、求めたスキーマ、および、アプリケーションサーバ３００から要求されたデータ操作を参照し、ステートレス性の有無を判別する。

決定部１０１は、データ操作のトランザクションの種類、操作対象のテーブルの主キーの有無、および、データ操作の種類などに応じて異なる操作方法を決定する。例えば決定部１０１は、データ操作が単独のトランザクションである場合にステートレス操作と判定する。単独のトランザクションとは、例えば、１以上のレコードに対する操作であって、アトミック性（原子性）を有する操作である。アトミック性とは、操作がすべて実行されるか、または、すべて実行されないことを保証する性質である。

データ操作が単独のトランザクションでない場合、決定部１０１は、操作対象のテーブルが主キーを持つかを判定してもよい。例えば、操作対象のテーブルが主キーを持つ場合に、ステートレス操作と判定してもよい。上記のように、主キーを持つテーブルの場合は、同一の操作を繰り返し実行してもテーブルの内容が同一になるためである。

操作対象のテーブルが主キーを持たない場合、決定部１０１は、さらにデータ操作の種類を判定してもよい。例えば、データ操作が新規レコードの挿入操作であるか否かを判定し、新規レコードの挿入操作でない場合に、ステートレス操作と判定してもよい。

新規レコードの挿入操作以外の操作は、例えば、既存レコードに対しての参照、更新、または削除操作である。これらの操作は、処理回数によらずに処理結果が同一となる操作（べき等性を有する操作）である。従って、例えば障害発生時に同じデータ操作を繰り返してもデータの不整合は生じない。このため、これらの操作をステートレス操作と判定しても問題は生じない。

決定部１０１は、データ操作により操作されるデータが複数のテーブルに記憶される場合、複数のテーブルそれぞれについてデータ操作の方法を決定する。決定部１０１は、判別結果を、検知・回復部１０２、要求部１０３、および、記憶制御部１０４に提供する。

検知・回復部１０２は、障害の検知を行い、回復に必要な手続きを決定する。また検知・回復部１０２は、障害が検知された場合の回復処理を実行する。検知・回復部１０２は、決定部１０１により決定された操作方法に応じた回復方法により、発生した障害を回復する回復部として機能する。検知・回復部１０２は、例えば、要求部１０３を通じて、分散サーバ２００に対するデータ操作要求中の障害を検知する。また検知・回復部１０２は、決定部１０１より決定された操作方法（ステートレス性の有無）、および、記憶部１１０に記憶されている操作系列の状態に基づき、回復処理（要求の再試行など）に必要な手続きを決定する。

要求部１０３は、分散サーバ２００に対するデータ操作の要求を発行する。要求部１０３は、操作要求を発行するにあたり、決定部１０１より求まるスキーマの識別情報を操作要求に付与する。また要求部１０３は、決定部１０１よりステートフル操作であると決定された場合は、記憶部１１０に記憶されている操作系列を操作要求に付与する。

一方、分散サーバ２００は、データ操作部２０１、検証部２０２、判定部２０３、および、記憶部２１０を備える。

記憶部２１０は、分散サーバ２００で実行される各種処理で用いられるデータを記憶する。例えば記憶部２１０は、データ操作の状態を示す状態情報（操作系列）を記憶する。

判定部２０３は、通信制御装置１００から要求されたデータ操作の状態と、記憶部２１０に記憶された状態情報が示す状態とが整合するか否かを判定する。すなわち判定部２０３は、通信制御装置１００からの操作要求において期待される直近の操作と、実際に受付済みの操作とを照合するための機能部である。例えば通信制御装置１００との接続障害が発生した場合、既に実行済みの登録操作要求が再度発行されることがある。この場合、判定部２０３は、要求された登録操作の状態と、記憶された状態情報が示す状態とが整合しないと判定する。

データ操作部２０１は、通信制御装置１００から要求されたデータ操作を実行する。例えばデータ操作部２０１は、判定部２０３により整合すると判定された場合、要求されたデータ操作を実行する。不整合などが生じた場合に、要求されたデータ操作の実行を省略することで、二重登録などのデータ不整合を回避することが可能となる。

検証部２０２は、通信制御装置１００から送信された、データ操作により操作されるデータを記憶するテーブルのスキーマが正しいか否かを検証する。すなわち検証部２０２は、通信制御装置１００から要求されたデータ操作で期待されるスキーマと、操作対象のデータが実際に格納されているテーブルのスキーマとが同一であることを検証する。

上記のように、通信制御装置１００は、スキーマによって通信手順（操作方法）を切り替える。一方、通信制御装置１００が常に最新のスキーマに基づき操作要求を発行するとは限らない。このため、分散サーバ２００上で随時スキーマを検証する必要がある。なお検証部２０２は、スキーマの全部ではなく、スキーマを縮約したハッシュ表現や、スキーマの変更履歴と対応する連番（バージョン情報など）を比較してもよい。これにより、検証処理を、より効率的に実現可能となる。また、一度定義したテーブルのスキーマが変更されないデータベースなどを用いる場合は、分散サーバ２００が検証部２０２を備えないように、すなわち、スキーマの検証を省略するように構成してもよい。

判定部２０３による照合に必要な操作系列は、通信制御装置１００と分散サーバ２００との双方で対称的に記憶する必要がある。一連のデータ操作の手順に関する記録を相互に独立して管理できる、操作系列の構成単位を以下ではセッションと呼ぶ。セッションは、少なくとも通信制御装置１００と、操作対象のデータを記憶する分散サーバ２００との組ごとに別途記憶する必要がある。分散サーバ２００がマスタスレーブ構成の一部を構成する場合、マスタとスレーブとの間では、操作したレコードの内容だけではなくセッションも複製する必要がある。また、シャーディング、すなわち、データベースまたはテーブルをいくつかの分散サーバに分割配置する場合は、さらに分割単位でセッションを記憶する必要がある。

１つのセッションに１つの操作系列を含むように構成してもよいし、１つのセッションに複数の操作系列を含むように構成してもよい。例えば図２の例では、「系列ａ」、「系列ｂ」をそれぞれ別のセッションの識別情報と対応づけて記憶してもよいし、「系列ａ」、「系列ｂ」を１つのセッションの識別情報と対応づけて記憶してもよい。

通信制御装置１００との接続が途切れたまま規定の時間を大幅に超過したセッションは、破棄してもよい。ただし、通信制御装置１００において接続障害が発生した後、既定の時間を超過した場合は、セッションを必要とする操作要求の再試行は中断しなければならない。これは、操作系列を記憶するセッションがなければ、操作系列の照合が行えず、二重登録などのデータ不整合が生じる可能性があるためである。

操作系列の照合は、データ操作の種類によっては省略可能である。例えば同一のステートレス操作の繰り返しはデータ不整合の要因とはならないため、操作系列を照合する必要がない。従って、照合に必要なセッションの構築および破棄や、操作内容の記憶も必要ない。

なお、通信制御装置１００および分散サーバ２００の各部（決定部１０１、検知・回復部１０２、要求部１０３、記憶制御部１０４、データ操作部２０１、検証部２０２、判定部２０３）は、例えば、ＣＰＵ（Central Processing Unit）などの処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Integrated Circuit）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。

また、記憶部１１０および記憶部２１０は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

次に、このように構成された本実施形態にかかる通信システムによるデータ操作処理について図３を用いて説明する。図３は、本実施形態におけるデータ操作処理の一例を示すフローチャートである。

アプリケーションサーバ３００よりデータ操作の要求を受け取ると、決定部１０１は、データ操作の対象となるデータを記憶するテーブルのスキーマを特定する（ステップＳ１０１）。スキーマ特定処理の詳細は後述する。次に決定部１０１は、特定したスキーマと、要求されたデータ操作とを参照して、データ操作がステートレス操作であるか否かを判定する（ステップＳ１０２）。ステートレス操作判定処理の詳細は後述する。

決定部１０１は、判定結果がステートレス操作であることを示すか否かを判断する（ステップＳ１０３）。ステートレス操作でない、すなわち、ステートフル操作である場合（ステップＳ１０３：Ｎｏ）、要求部１０３は、分散サーバ２００および記憶制御部１０４に対して、操作系列を記憶するためにセッションの準備を要求する（ステップＳ１０４）。例えば要求部１０３は、要求に応じて分散サーバ２００の判定部２０３によって生成されたセッションの識別情報を受け取り、記憶制御部１０４を介して記憶部１１０に格納する。

要求部１０３は、アプリケーションサーバ３００から要求されたデータ操作の実行を、分散サーバ２００に要求する（ステップＳ１０５）。このとき、要求部１０３は、現在のセッションに対応する操作系列の情報を併せて分散サーバ２００に送信する。操作系列の情報は、分散サーバ２００の判定部２０３が状態の整合性を判定するときに利用される。

分散サーバ２００から正常応答を確認できた場合、要求部１０３は、セッションを破棄する（ステップＳ１０６）。なお、ステートフル操作の前後で行うセッションの生成および破棄は、通信回数の削減のために、複数のステートフル操作の間で省略してもよい。すなわち、１つのセッションを、複数の操作系列で共通に用いるように構成してもよい。

ステップＳ１０３でステートレス操作であると判定された場合（ステップＳ１０３：Ｙｅｓ）、要求部１０３は、アプリケーションサーバ３００から要求されたデータ操作の実行を、操作系列の情報を付随させずに、分散サーバ２００に要求する（ステップＳ１０７）。

次に、ステップＳ１０１のスキーマ特定処理について説明する。図４は、本実施形態のスキーマ特定処理の一例を示すフローチャートである。

スキーマは、例えば分散サーバ２００に問い合わせることにより特定できる。またスキーマは、アプリケーションサーバ３００から送信される情報（データ操作の要求など）を参照して特定することもできる。例えば、Ｏ／Ｒ（Object／Relational）マッピングを伴い静的にスキーマを仮定しているアプリケーションが用いられる場合、決定部１０１は、操作対象のデータのクラスの構造などから、スキーマを特定することができる。例えば、Ｊａｖａ（登録商標）などのようにリフレクション機能を利用できる場合は、クラスを構成するメソッド、フィールドの名前や型、および、アノテーションなどの定義を参照することにより、該当するクラスに対応するテーブルのスキーマを特定することができる。

決定部１０１は、Ｏ／Ｒマッピングを利用する場合のように、データ操作の要求元（アプリケーションサーバ３００など）からスキーマが指定されているか否かを判定する（ステップＳ２０１）。スキーマが指定されている場合（ステップＳ２０１：Ｙｅｓ）、決定部１０１は、指定されるスキーマをそのまま受け取り選択する（ステップＳ２０６）。

一方、スキーマの指定がない場合（ステップＳ２０１：Ｎｏ）、決定部１０１は、スキーマを示す情報（スキーマ情報）が、記憶部１１０などに事前に記憶（キャッシュ）されているか否かを判定する（ステップＳ２０２）。決定部１０１は、例えば分散サーバ２００に対して、テーブルのスキーマを問い合わせたときに、テーブルを識別する情報（テーブル名等）と、問い合わせの結果得られたスキーマ情報とを対応づけて記憶部１１０などに記憶しておく。これにより、本ステップでは、事前に記憶された情報を参照して、操作対象のテーブルのスキーマを特定することができる。

スキーマ情報がキャッシュ済みの場合（ステップＳ２０２：Ｙｅｓ）、決定部１０１は、キャッシュ済みのスキーマを選択する（ステップＳ２０５）。スキーマのキャッシュが見つからなかった場合（ステップＳ２０２：Ｎｏ）、決定部１０１は、分散サーバ２００に対して、最新のスキーマを問い合わせる（ステップＳ２０３）。決定部１０１は、問い合わせの結果得られた情報を記憶部１１０などの所定の記憶装置に登録し（ステップＳ２０４）、得られたスキーマを選択する（ステップＳ２０５）。

次に、ステップＳ１０２のステートレス操作判定処理について説明する。図５は、本実施形態のステートレス操作判定処理の一例を示すフローチャートである。

決定部１０１は、要求されたデータ操作が単独のトランザクションであるか否かを判定する（ステップＳ３０１）。データ操作が単独のトランザクションではない場合（ステップＳ３０１：Ｎｏ）、決定部１０１は、ステートフル操作であると判定する（ステップＳ３０４）。要求されたデータ操作が単独のトランザクションである場合（ステップＳ３０１：Ｙｅｓ）、決定部１０１は、さらに、操作対象のテーブルに主キーが存在するか否かを判定する（ステップＳ３０２）。決定部１０１は、例えば、スキーマ特定処理で特定したスキーマを参照することにより、テーブルに主キーが存在するか否かを判定する。

主キーが存在する場合（ステップＳ３０２：Ｙｅｓ）、決定部１０１は、ステートレス操作であると判定する（ステップＳ３０５）。主キーが存在しない場合（ステップＳ３０２：Ｎｏ）、決定部１０１は、さらに、要求されたデータ操作が、新規レコードの挿入操作であるか否かを判定する（ステップＳ３０３）。上記のように決定部１０１は、新規レコードの挿入操作であるかの代わりに、データ操作が処理回数によらずに処理結果が同一となる操作（べき等性を有する操作）であるかを判定してもよい。

データ操作が新規レコードの挿入操作でない場合（ステップＳ３０３：Ｎｏ）、決定部１０１は、ステートレス操作であると判定する（ステップＳ３０５）。新規レコードの挿入操作であった場合（ステップＳ３０３：Ｙｅｓ）、決定部１０１は、ステートフル操作であると判定する（ステップＳ３０４）。

なお、ステップＳ３０１〜ステップＳ３０３の実行順序は上記に限られるものではなく、任意の順序で実行することができる。

次に、本実施形態における障害回復処理について説明する。図６は、本実施形態の障害回復処理の一例を示すフローチャートである。検知・回復部１０２は、分散サーバ２００からのハートビート応答の受け取りの失敗などにより、分散サーバ２００との接続異常を検知した場合に、障害回復処理を実行する。

検知・回復部１０２は、障害が発生した分散サーバ２００の代替となる分散サーバ２００（代替サーバ）との接続を試みる（ステップＳ４０１）。接続に成功した場合、操作内容の回復操作に移行する。検知・回復部１０２は、直前のデータ操作がステートレスであるか否かを判定する（ステップＳ４０２）。検知・回復部１０２は、例えば決定部１０１によるステートレス操作判定処理の結果を参照して、データ操作がステートレスであるか否かを判定する。

ステートレス操作である場合（ステップＳ４０２：Ｙｅｓ）、検知・回復部１０２は、直前のステートレス操作を再実行する（ステップＳ４０７）。直前のデータ操作がステートレス操作でない、すなわち、ステートフル操作である場合（ステップＳ４０２：Ｎｏ）、検知・回復部１０２は、セッションが喪失されたか否かを判定する（ステップＳ４０３）。検知・回復部１０２は、例えば分散サーバ２００に問い合わせることにより、該当するセッションが喪失されたかを判定する。

セッションが喪失された場合（ステップＳ４０３：Ｙｅｓ）、検知・回復部１０２は、再度セッションを準備し（ステップＳ４０４）、ステートフル操作を実行する（ステップＳ４０５）。セッションが喪失されていない場合（ステップＳ４０３：Ｎｏ）、検知・回復部１０２は、既存のセッションの状態を利用してステートフル操作を実行する（ステップＳ４０５）。なお、切断されたセッションの有効期限が設けられており、有効期限を超過した場合は、再度セッションを準備せず回復処理を中断する。ステートフル操作の完了を確認できた場合は、検知・回復部１０２は、セッションを破棄し（ステップＳ４０６）、障害回復処理を完了させる。

次に、分散サーバ２００の検証部２０２によるスキーマ検証処理について説明する。図７は、本実施形態のスキーマ検証処理の一例を示すフローチャートである。スキーマ検証処理は、通信制御装置１００の要求部１０３からデータ操作が要求されたとき（例えば図３のステップＳ１０５、ステップＳ１０７）に実行される。

検証部２０２は、通信制御装置１００からデータ操作が要求されるごとに、付随するスキーマ情報を受け取る（ステップＳ５０１）。検証部２０２は、例えば記憶部２１０などに記憶される最新のスキーマを参照する（ステップＳ５０２）。検証部２０２は、受け取ったスキーマ情報が示すスキーマと、最新のスキーマとが一致するか否かを判定する（ステップＳ５０３）。一致しない場合（ステップＳ５０３：Ｎｏ）、検証部２０２は、スキーマ異常であると判別する（ステップＳ５０５）。スキーマ異常となりうるのは、例えば、アプリケーションサーバ３００より与えられたスキーマに誤りがあるか、通信制御装置１００の稼働している間に意図せずスキーマが変更された場合などである。スキーマが一致すると判定した場合（ステップＳ５０３：Ｙｅｓ）、検証部２０２は、スキーマ正常であると判別する（ステップＳ５０４）。スキーマ正常であり、適宜行われる判定部２０３の照合の結果、必要であると判断された場合、データ操作部２０１は、要求されたデータ操作を実行する。

このように、本実施形態にかかる通信システムでは、データ操作の種類、および、操作対象のテーブルのスキーマに基づき、適用すべきデータ操作の方法（操作方法）を切り替える。これにより、例えば必要な場合にのみ、実行状態を制御するデータ操作が実行される。この結果、高可用性、応答時間の短縮、および、開発の容易性などを両立させることが可能となる。

次に、本実施形態にかかる各装置（端末、アプリケーションサーバ、通信制御装置、分散サーバ）のハードウェア構成について図８を用いて説明する。図８は、本実施形態にかかる装置のハードウェア構成例を示す説明図である。

本実施形態にかかる装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ（Random Access Memory）５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。

本実施形態にかかる装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。

本実施形態にかかる装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

さらに、本実施形態にかかる装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかる装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

本実施形態にかかる装置で実行されるプログラムは、コンピュータを上述した装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

５１ ＣＰＵ
５２ ＲＯＭ
５４ 通信Ｉ／Ｆ
６１ バス
１００ 通信制御装置
１０１ 決定部
１０２ 検知・回復部
１０３ 要求部
１０４ 記憶制御部
１１０ 記憶部
２００ 分散サーバ
２０１ データ操作部
２０２ 検証部
２０３ 判定部
２１０ 記憶部
３００ アプリケーションサーバ
４００ 端末
５１０、５２０ ネットワーク

Claims (11)

1. データを分散して記憶する複数のサーバ装置と接続される通信制御装置であって、
   要求されたデータ操作と、前記データ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、前記データ操作の状態を示す状態情報を記憶する第１の操作方法、および、前記状態情報を記憶しない第２の操作方法のいずれかを、前記データ操作の方法として決定する決定部と、
   前記データ操作を前記サーバ装置に要求する要求部と、
   前記第１の操作方法が決定された場合、前記データ操作の実行時に前記状態情報を記憶部に記憶する記憶制御部と、
   前記データ操作の実行時に障害が発生した場合、前記決定部により決定された操作方法に応じた回復方法により、発生した障害を回復する回復部と、
   を備える通信制御装置。
2. 前記回復部は、前記第１の操作方法が決定された場合、記憶された前記状態情報を用いて障害を回復し、前記第２の操作方法が決定された場合、前記状態情報を用いずに障害を回復する、
   請求項１に記載の通信制御装置。
3. 前記決定部は、前記テーブルが主キーを有するか否かに応じて異なる操作方法を決定する、
   請求項１に記載の通信制御装置。
4. 前記決定部は、前記データ操作で実行されるトランザクションの種類に応じて異なる操作方法を決定する、
   請求項１に記載の通信制御装置。
5. 前記決定部は、前記データ操作の種類に応じて異なる操作方法を決定する、
   請求項１に記載の通信制御装置。
6. 前記決定部は、前記データ操作により操作されるデータが複数のテーブルに記憶される場合、複数のテーブルそれぞれについて、要求されたデータ操作とテーブルのスキーマとに基づいて操作方法を決定する、
   請求項１に記載の通信制御装置。
7. データを分散して記憶する複数のサーバ装置と接続される通信制御装置で実行される通信制御方法であって、
   要求されたデータ操作と、前記データ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、前記データ操作の状態を示す状態情報を記憶する第１の操作方法、および、前記状態情報を記憶しない第２の操作方法のいずれかを、前記データ操作の方法として決定する決定ステップと、
   前記データ操作を前記サーバ装置に要求する要求ステップと、
   前記第１の操作方法が決定された場合、前記データ操作の実行時に前記状態情報を記憶部に記憶する記憶制御ステップと、
   前記データ操作の実行時に障害が発生した場合、前記決定ステップにより決定された操作方法に応じた回復方法により、発生した障害を回復する回復ステップと、
   を含む通信制御方法。
8. データを分散して記憶する複数のサーバ装置と接続されるコンピュータを、
   要求されたデータ操作と、前記データ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、前記データ操作の状態を示す状態情報を記憶する第１の操作方法、および、前記状態情報を記憶しない第２の操作方法のいずれかを、前記データ操作の方法として決定する決定部と、
   前記データ操作を前記サーバ装置に要求する要求部と、
   前記第１の操作方法が決定された場合、前記データ操作の実行時に前記状態情報を記憶部に記憶する記憶制御部と、
   前記データ操作の実行時に障害が発生した場合、前記決定部により決定された操作方法に応じた回復方法により、発生した障害を回復する回復部、
   として機能させるためのプログラム。
9. データを分散して記憶する複数のサーバ装置と、通信制御装置とを備える通信システムであって、
   前記通信制御装置は、
   要求されたデータ操作と、前記データ操作により操作されるデータを記憶するテーブルのスキーマとに基づいて、前記データ操作の状態を示す状態情報を記憶する第１の操作方法、および、前記状態情報を記憶しない第２の操作方法のいずれかを、前記データ操作の方法として決定する決定部と、
   前記データ操作を前記サーバ装置に要求する要求部と、
   前記第１の操作方法が決定された場合、前記データ操作の実行時に前記状態情報を記憶部に記憶する記憶制御部と、
   前記データ操作の実行時に障害が発生した場合、前記決定部により決定された操作方法に応じた回復方法により、発生した障害を回復する回復部と、を備え、
   前記サーバ装置のそれぞれは、
   前記状態情報を記憶する第２記憶部と、
   前記通信制御装置から要求されたデータ操作の状態と、前記第２記憶部に記憶された前記状態情報が示す状態とが整合するか否かを判定する判定部と、
   整合すると判定された場合、要求されたデータ操作を実行するデータ操作部と、を備える、
   通信システム。
10. 前記サーバ装置のそれぞれは、
    前記通信制御装置から送信された、前記データ操作により操作されるデータを記憶するテーブルのスキーマが正しいか否かを検証する検証部をさらに備える、
    請求項９に記載の通信システム。
11. 前記判定部は、要求されたデータ操作が、前記第１の操作方法が決定されたデータ操作である場合、要求されたデータ操作の状態と、前記第２記憶部に記憶された前記状態情報が示す状態とが整合するか否かを判定する、
    請求項９に記載の通信システム。

Images