WO2020059532A1

WO2020059532A1 - ネットワークサービスシステム、イベントログ記録装置、イベントログ管理方法、及びプログラム

Info

Publication number: WO2020059532A1
Application number: PCT/JP2019/035104
Authority: WO
Inventors: 太一川幡; 篤谷口; 勇貴南; 暢間野
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 2018-09-20
Filing date: 2019-09-06
Publication date: 2020-03-26
Anticipated expiration: 2021-03-20
Also published as: JP2020048102A

Abstract

通信障害による送受信データの欠落を復元することができるネットワークサービスシステム、イベントログ記録装置、イベントログ管理方法、及びプログラムを提供することを目的とする。本発明に係るネットワークサービスシステムは、クライアント側イベントログ記録装置およびサーバ側イベントログ記録装置のそれぞれが、イベントが発生する度に、当該イベントのユニークな状態情報を生成し、生成した状態情報を相手側のイベントログ記録装置に送信するとともに当該イベントと対応付けてデータベースに記録し、相手側のイベントログ記録装置から受信した状態情報が自身の生成した状態情報と異なる場合には、両者の状態情報が一致する時点まで遡って、データベースに記録されたイベントを再送する。

Description

ネットワークサービスシステム、イベントログ記録装置、イベントログ管理方法、及びプログラム

　本開示は、マイクロサービスアーキテクチャを採用するネットワークサービスシステム、当該システムが備えるクライアント側イベントログ記録装置とサーバ側イベントログ記録装置、当該システムが行うイベントログ管理方法、及び当該記録装置を実現するプログラムに関する。

　図１のように、ネットワークサービスＡを複数の小さなサービス部品（Ｂ_１、Ｂ_２、・・・Ｃ）に分けることで、サービスの信頼性、可用性、スケーラビリティ及び開発効率を向上させる「マイクロサービス・アーキテクチャ」が普及しつつある。

　また、サービスを「データ読み込み部」と「データ書き込み部」に分離することで、サービスのドメインを明確化する「命令・問い合わせ責任分離（ＣＱＲＳ）」設計パターンも普及している（例えば、非特許文献１を参照。）。

Ｍａｒｔｉｎ　Ｆｏｗｌｅｒ，　"ＣＱＲＳ"，　ｈｔｔｐｓ：／／ｍａｒｔｉｎｆｏｗｌｅｒ．ｃｏｍ／ｂｌｉｋｉ／ＣＱＲＳ．ｈｔｍｌ（２０１８年８月３１日検索）

　サービスを効率よく、迅速に開発するためには、自分でサービスに必要なすべての部品を開発するのではなく、一部のサービスについては他社サービスに依存するのが良い。しかし、実時間でサービスを提供するためには、一部を他社のサービスに依存するのは以下に説明する課題がある。

　サービスが多様化・複雑化し、その実現のために、複数の特定用途の専門サービスの連携が重要になると、以下のような課題が発生する。

（信頼性の課題）
　サービスの構築にあたり、自前で全てを開発するのではなく、多数の既存サービスを組み合わせると、サービスの信頼性もまた、組み合わせるサービスの数が多いほど低下する。たとえば稼働率９９％の既存サービスを１０個組み合わせ、それら全ての積が提供サービスの稼働率になる場合は、稼働率は９０％程度まで低減してしまう。

　この問題への対処方法として、サービスへの要求と応答を全て、イベント化して双方でログを取り、サービス間連携において何らかの矛盾が発生した場合は、その前後で双方のログを照らし合わせることで、矛盾が発生した箇所を突き止める手法がある（イベント・ソーシング）。しかしこの手法は、サービスの提供側と利用側の双方で、ストレージの負担の大きなＡＰＩを共通化する必要があるため、異なる組織間の手法として適用しにくいという課題がある。

　また、サーバの処理能力が、物理リソースを超えた場合、スケーリング・サービス移動により、サーバ・クライアント間の通信が一時、途絶したり、再ルーティングが必要になることがある。その場合、サーバへの通信路が一旦途絶し、サービスがその間、中断してしまうという課題がある。

（実時間性の課題）
　クライアントに提供するサービスの構成部品に外部のサービスを利用すると、ユーザに対して時間的な品質を担保するのが困難になるという課題がある。サービス提供にかかる時間は、一般に、ネットワークの遅延時間、計算機資源における処理時間の総計となるが、サービス連携によりそれらの一部がサービス提供者では制御できなくなるためである。また、一般のネットワークサービスでは、クライアントの位置は不定のため、まず、クライアント側からサービス側に対して「要求」を行い、それに対してサービスが「応答」を行う。そのため、通信が往復する時間がかかる。

　この問題の対処方法として、一般ユーザに近い場所にサービスを配置する手法が考えられるが（参考：エッジコンピューティング）、この手法は、あくまでもフロントサービスの配置手法であり、複数のサービスが連携する場合は、連携するサービス全てを移動することは一般に困難である。また、クライアントが体感するサービスの速度は、必ずしもクライアントとサーバ側フロント間で律速されるとは限らない。たとえば株式売買における指値取引のようなシステムでは、リアルタイム性はクライアント・サービス間ではなく、サービス・サービス間で求められる（参考・エージェント指向システム）。

（ソフトウェア更新に伴う課題）
　更新されないソフトウェアは時間経過に伴い可用性が低下する。複数の異なるサービスを連携させる場合、サーバ（サービス提供側）とクライアント（サービス要求側）のどちらにおいても、ソフトウェアのバージョンの更新が非同期に行われる。バージョン更新に伴い、データベースなどのスキーマが変更し、従来は重要視されておらず通信後は捨てられていたようなデータがあらためて必要になる場合、過去の通信ログなどを使って、データベースを再度作り直す必要性が生じるという課題がある。

（他の課題）
　サービス連携におけるサーバ（サービス提供側）やクライアント（サービス要求側）ともに、スケーリングや移動などによってデータが失われる場合がある。また、サーバ・クライアント間のネットワークも、一時的な通信オーバーフローや故障等により、データを転送できなくなる場合がある。その場合、データの不達の責任は、サーバ・クライアント・ネットワークの３者のどれにあるのか、客観的に証明することは困難で、サーバが提供するサービスの対価を支払う責任の有無の判断が困難になるという課題もある。また、データの不整合を修正する通信を行うと、他のリアルタイム性の高い通信がブロックされる問題がある。

　前記課題を解決するために、本発明は、通信障害による送受信データの欠落を復元することができるネットワークサービスシステム、イベントログ記録装置、イベントログ管理方法、及びプログラムを提供することを目的とする。

　上記目的を達成するために、本発明に係るネットワークサービスシステムは、連携する各サービスの中間にアダプタを挿入し、当該アダプタでサーバ側とクライアント側で通信ログを記録することとした。

　具体的には、本発明に係るネットワークサービスシステムは、２つの通信装置の間で通信イベントを送受するネットワークサービスシステムであって、
　前記２つの通信装置の各々に接続され、前記２つの通信装置の間の通信を中継する２つのイベントログ記録装置を備え、
　前記イベントログ記録装置は、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算部と、
　前記イベントと前記状態演算部が生成した状態情報を相手側のイベントログ記録装置に送信するとともに、前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する送受信部と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶部と、
　前記送受信部が前記相手イベントと前記相手状態情報を受信したときに、前記状態演算部に前記相手イベントのユニークな状態情報を生成させ、当該状態情報と前記相手状態情報とが異なる場合、前記記憶部に記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記送受信部に再送させる制御部と、
を有することを特徴とする。

　ここで、本発明に係るイベントログ装置は、２つの通信装置の間で通信イベントを送受するネットワークサービスシステムにおいて、前記２つの通信装置毎に接続され、前記２つの通信装置の間の通信を中継するイベントログ記録装置であって、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算部と、
　前記イベントと前記状態演算部が生成した状態情報を相手側のイベントログ記録装置に送信するとともに、前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する送受信部と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶部と、
　前記送受信部が前記相手イベントと前記相手状態情報を受信したときに、前記状態演算部に前記相手イベントのユニークな状態情報を生成させ、当該状態情報と前記相手状態情報とが異なる場合、前記記憶部に記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記送受信部に再送させる制御部と、
を有することを特徴とする。

　つまり、本発明に係るイベントログ管理方法は、２つの通信装置の間で通信イベントを送受するネットワークサービスシステムのイベントログ管理方法であって、
　前記２つの通信装置の各々に接続され、前記２つの通信装置の間の通信を中継する２つのイベントログ記録装置をプラットフォームに形成する接続手順と、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算手順と、
　前記イベントと前記状態演算手順で生成した状態情報を相手側のイベントログ記録装置に送信する送信手順と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶手順と、
　前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する受信手順と、
　前記受信手順で前記相手イベントと前記相手状態情報を受信したときに、前記相手イベントのユニークな状態情報を生成し、当該状態情報と前記相手状態情報とが異なる場合、前記記憶手順で記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記相手側のイベントログ記録装置へ再送する再送手順と、
を行うことを特徴とする。

　本ネットワークサービスシステムは、クライアント側イベントログ記録装置およびサーバ側イベントログ記録装置のそれぞれが、イベント（クライアント装置からサーバ装置へ送信される「要求（コマンド）」、および該「要求」に対してサーバ装置からクライアント装置へ送信される「応答」）が発生する度に、当該イベントのユニークな状態情報を生成し、生成した状態情報を相手側のイベントログ記録装置に送信するとともに当該イベントと対応付けてデータベースに記録し、相手側のイベントログ記録装置から受信した状態情報が自身の生成した状態情報と異なる場合には、両者の状態情報が一致する時点まで遡って、データベースに記録されたイベントを再送する。

　従って、本発明は、通信障害による送受信データの欠落を復元することができるネットワークサービスシステム、イベントログ記録装置、及びイベントログ管理方法を提供することができる。

　本発明に係るネットワークサービスシステムは、前記２つの通信装置の間の通信遅延時間を計測する計測装置をさらに備え、
　前記２つの通信装置のうちの一方の通信装置は、前記イベントに指定された最大応答時間から前記計測装置が計測した往復の通信遅延時間を差し引いた応答期限を前記２つの通信装置のうちの他方の通信装置に通知し、
　前記他方の通信装置は、前記イベントに対して時間が短くレベルの低い処理から時間が長くレベルの高い処理までの複数の処理を生成し、前記複数の処理の中から前記応答期限内で最もレベルの高い処理を前記イベントに対する応答のイベントとして前記一方の通信装置へ返信することを特徴とする。
　本ネットワークサービスシステムは、サーバ装置がクライアント装置に対して、指定された時間以内に最大の品質の応答を返すことができる。

　本発明に係るネットワークサービスシステムの前記記憶部は、前記送受信部が受信した、前記イベントに応答する相手イベントと相手状態情報も前記イベントに対応付けて記録しており、前記２つの通信装置は、自身が変更された場合、自身に接続する前記イベントログ記録装置の前記記憶部が記録する前記相手イベントを受け取り、データベースを再構築することを特徴とする。本ネットワークサービスシステムは、通信装置のデータベースを構築するのに必要な通信ログを、アダプタのイベントログ記録装置が保持している。このため、本ネットワークサービスシステムは、クライアント装置やサーバ装置のソフトウェアのバージョン更新時にこれらのログからデータベースを再構築することができる。

　本発明は、前記イベントログ記録装置としてコンピュータを機能させるためのプログラムである。本発明に係るイベントログ記録装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

　本発明は、通信障害による送受信データの欠落を復元することができるネットワークサービスシステム、イベントログ記録装置、イベントログ管理方法、及びプログラムを提供することができる。

マイクロサービス・アーキテクチャを説明する図である。本発明に係るネットワークサービスシステムを説明する図である。本発明に係るネットワークサービスシステムにおいて要求送信時の動作を説明する図である。本発明に係るネットワークサービスシステムにおいて応答返信時の動作を説明する図である。本発明に係るネットワークサービスシステムにおいてクライアント側とサーバ側とでイベントログが一致しないときの動作を説明する図である。本発明に係るネットワークサービスシステムにおいて、遅延時間を考慮したサービス連携を行うときの動作を説明する図である。本発明に係るネットワークサービスシステムにおいて、クライアント装置でデータベースを再構築するときの動作を説明する図である。本発明に係るクライアント側イベントログ記録装置を説明する図である。本発明に係るサーバ側イベントログ記録装置を説明する図である。本発明に係るイベントログ管理方法を説明する図である。本発明に係るクライアント側イベントログ記録装置の動作を説明する図である。本発明に係るサーバ側イベントログ記録装置の動作を説明する図である。

　添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

［発明概要］
　図２は、本実施形態のネットワークサービスシステムを説明する図である。
　前述した「信頼性」、「実時間性」、「継続的ソフトウェア更新」、その他の諸問題を解決するために、本発明では、連携する各サービスの中間にアダプタ５０を挿入する。
　本発明は、アダプタ５０において、サーバ側とクライアント側の双方で通信ログを記録し、その状態を表現するプラットフォーム５１である。

　ネットワークサービス４０においてサービスを連携する際、依頼する側を「クライアント側（サービス中心部分）２１」、受託する側を「サーバ側（受託部分）２２」とする。アダプタ５０は、クライアント側に密結合する「サーバ送信部品３１」、クライアント側とサーバ側との間の通信イベントを記録する「クライアント側イベントログＤＢ３３」と「サーバ側イベントログＤＢ３４」、およびサーバ側に密結合する「クライアント受信部品３２」から構成される。

　そして、上記の諸問題を解決するため、本実施形態のネットワークサービスシステムは、クライアント側（中心部分）がサーバ側（受託部分）と接続する手順、クライアント側がサーバ側にコマンドを要求する手順、クライアント側がサーバ側にクエリを要求する手順、通信に障害が発生した際に、イベントログＤＢから通信を復元する手順、通信の実時間性を保証する手順、及びソフトウェアの更新時におけるデータベースの再構築手順を行う。

［構成の説明］
　本実施形態のネットワークシステムは、ユーザの要求に対してサービスを提供するネットワークサービスシステムであって、
　前記サービスを提供するクライアント装置２１と、
　クライアント装置２１の要求により前記サービスの一部の処理を受託し、前記要求に対する応答を行うサーバ装置２２と、
　クライアント装置２１とサーバ装置２２のそれぞれに配置され、クライアント装置２１とサーバ装置２２との間の通信を中継する２つのイベントログ記録装置が形成されるプラットフォーム５１と、
を備える。

（端末とネットワークサービス）
　端末１０は、ユーザがネットワークを利用する際に操作するデバイスであり、サービス画面などを表示するプログラムを搭載することができる。
　ネットワークサービス４０は、端末１０からの要求に対してサービスを提供する。サービスは一般には、スケーラビリティを確保するため、クラウド上に複数の仮想ネットワーク機能（ＶＮＦ，　Ｖｉｒｔｕａｌ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）の集合体として構成される。

（ネットワークサービスのクライアント側（中心部分））
　クライアント装置２１がネットワークサービスのクライアント側（中心部分）である。
　クライアント装置２１は、端末１０からの要求に対してサービスを提供する。当該サービスは、マイクロサービス・アーキテクチャで提供されることを前提とする。クライアント装置２１は、メイン部品２３とサーバ送信部品３１を有する。
　クライアント側（中心部分）のメイン部品２３群は、メイン部分における、ネットワークサービスの中核となるビジネスロジックが実装されているＶＮＦ部品群である。使用計算機資源量に応じて、スケーリングをしても良い。
　クライアント側（中心部分）のサーバ送信部品３１は、メイン部分２３が、外部委託部分に要求を行う際に仲介するＶＮＦ部品である。サーバ送信部品３１は、サーバ側への要求ないし応答の送受信にクライアント側イベントログＤＢ３３を経由させる。また、サーバ送信部品３１は、要求をクライアント側イベントログＤＢ３３に送信する際に、そのタイムスタンプや状態情報を受け取ることができる。

（ネットワークサービスのサーバ側（受託部分））
　サーバ装置２２がネットワークサービスのサーバ側（受託部分）である。サーバ装置２２は、ネットワークサービスのうち、サービスの中核でなく、サービス提供者からサービスの一部が委託される。通常、サーバ装置２２は、クラウド上に複数の仮想ネットワーク機能（ＶＮＦ）の集合体として構成される。サーバ装置２２は、メイン部品２４とクライアント受信部品３２を有する。
　サーバ側（受託部分）のメイン部分２４群は、受託部分のうち、委託されたサービス事業者が提供するサービスのビジネスロジックの中核部分のＶＮＦ部品群である。
　サーバ側（受託部分）のクライアント受信部品３２は、サーバ側が、要求を受け付ける際に、その前段階を仲介するアダプタとなるＶＮＦ部品である。

（プラットフォーム）
　プラットフォーム５１は、クライアント側およびサーバ側におけるイベントログを記録する２つのデータベースを備え、そのデータベースの整合性を維持する機能、通信障害を記録する機能、データベース間で同期する機能、及びクライアント側からの問い合わせを処理する機能を提供する。前記２つのデータベースは、クライアント側イベントログデータベース３３とサーバ側イベントログデータベース３４である。

　図８は、クライアント側イベントログデータベース３３を説明する構成図である。クライアント側イベントログデータベース３３は、
　クライアント装置２１からサーバ装置２２へ送信される前記要求が発生する度に、前記要求についてのユニークな状態情報を生成する第１状態演算部８３と、
　前記２つのイベントログ記録装置のうちサーバ装置２２用のサーバ側イベントログ記録装置３４へ、前記要求及び第１状態演算部８３が生成した状態情報を送信する第１送受信部８２と、
　前記要求と対応付けて第１状態演算部８３が生成した状態情報を記録する第１記憶部８４と、
　第１送受信部８２が送信した状態情報とサーバ側イベントログ記録装置３４で計算した状態情報が不一致であった時点から第１記憶部８４が記録する状態情報とサーバ側イベントログ記録装置３４が記録する状態情報とが一致する時点までの、第１記憶部８４が記録する前記要求及び状態情報をサーバ側イベントログ記録装置３４へ再送させる第１制御部８１と、
を有する。

　クライアント側イベントログデータベース３３は、ネットワーク上のクライアント装置２１に近い位置に設置され、クライアント装置２１のサーバ送信部品３１と接続する。クライアント側イベントログデータベース３３は、サーバ送信部品３１からサーバ側への要求（「コマンド」）をイベントログとして保持し、サーバ側イベントログＤＢ３４へ転送する。また、クライアント側イベントログデータベース３３は、サーバ側イベントログＤＢ３４から受信した応答をイベントログとして記録し、サーバ送信部品３１へ転送する。
　クライアント側イベントログデータベース３３が記憶する内容は、クライアント側（中心部分）のサーバ送信部品３１が、イベント受信時刻やログ状態等をキーに取得することができ、履歴の分析やクライアント装置２１のデータベースの再構築等に利用できる。

　図９は、サーバ側イベントログデータベース３４を説明する構成図である。サーバ側イベントログデータベース３４は、
　前記要求に対してサーバ装置２２からクライアント装置２１へ送信される前記応答が発生する度に、前記応答についてのユニークな状態情報を生成する第２状態演算部９３と、
　前記２つのイベントログ記録装置のうちクライアント装置２１用のクライアント側イベントログ記録装置３３へ前記応答及び第２状態演算部９３が生成した状態情報を送信する第２送受信部９２と、
　前記応答と対応付けて第２状態演算部９３が生成した状態情報を記録する第２記憶部９４と、
　第２制御部９１と、
を有しており、
　第２送受信部９２は、クライアント側イベントログ記録装置３３からの前記要求及び状態情報を受信し、サーバ装置２２へ前記要求を引き渡し、
　第２状態演算部９３は、第２送受信部０２が前記要求を受信する度に、前記要求についてのユニークな状態情報を生成し、
　第２記憶部９４は、前記要求と対応付けて第２状態演算部９３が生成した状態情報を記録し、
　第２制御部９１は、第２送受信部９２が受信した状態情報と第２状態演算部９３が演算した状態情報とが異なる場合、第２記憶部９４が記録する前記要求と対応付けた状態情報とクライアント側イベントログ記録装置３３が記録する前記要求と対応付けた状態情報とを照合することを特徴とする。

　サーバ側イベントログデータベース３４は、ネットワーク上のサーバ装置２２に近い位置に、接続されるクライアント装置２１に設置され、サーバ装置２２のクライアント受信部品３２と接続される。サーバ側イベントログデータベース３４は、クライント側イベントログＤＢ３３からサーバ側への要求（「コマンド」）をイベントログとして保持し、クライアント受信部品３２へ転送する。また、サーバ側イベントログデータベース３４は、クライアント受信部品３１から受信した応答をイベントログとして記録し、クライアント側イベントログＤＢ３３へ転送する。

　ここで、クライアント装置２１とサーバ装置２２に形成されるＶＮＦの各部品について説明する。
　サーバ側メイン部品２４は、クライアント側に提供するサービスを設計する際に、サーバ側が受信する要求を、クエリ（問い合わせ）とコマンド（命令）２パターンに分けて設計する。「クエリ」は、サーバへの状態の問い合わせを行う。「コマンド」は、サーバ側に状態の変更を要請する。
　サーバ側クライアント受信部品３２は、プラットフォーム５１からの接続要求に応じ、プラットフォーム５１のサーバ側イベントログデータベース３４に接続する機能を有する。また、サーバ側クライアント受信部品３２は、クライアント側サーバ送信部品３１との間でネットワークの通信に要する時間を計測する機能も有する。
　クライアント側メイン部品２３もまた、サーバへの要求を、「クエリ」と「コマンド」の２パターンに分けて設計する。
　クライアント側サーバ送信部品３１は、メイン部分２３から、サーバ側に接続する代わりに、プラットフォーム５１に接続し、プラットフォーム５１に対して、クライアント側にクライアント側イベントログデータベース３３の構築を、サーバ側にサーバ側イベントログデータベース３４の構築を要求する機能を有する。

　図１０を用いて、本実施形態のネットワークサービスシステムの動作であるイベントログ管理方法について説明する。本イベントログ管理方法は、
　クライアント装置２１の要請でプラットフォーム５１に２つのイベントログ記録装置を形成し、前記２つのイベントログ記録装置を介してクライアント装置２１とサーバ装置２２とを接続する接続手順Ｓ０１と、
　前記２つのイベントログ記録装置のうちクライアント装置２１用のクライアント側イベントログ記録装置３３が、クライアント装置２１からサーバ装置２２へ送信される前記要求が発生する度に、前記要求についてのユニークな状態情報を生成する第１状態演算手順Ｓ０２と、
　クライアント側イベントログ記録装置３３が、前記２つのイベントログ記録装置のうちサーバ装置２２用のサーバ側イベントログ記録装置３４へ、前記要求及び第１状態演算手順Ｓ０２で生成した状態情報を送信する第１送信手順Ｓ０３と、
　クライアント側イベントログ記録装置３３が、前記要求と対応付けて第１状態演算手順Ｓ０２で生成した状態情報を記録する第１記憶手順Ｓ０４と、
　サーバ側イベントログ記録装置３４が、クライアント側イベントログ記録装置３３からの前記要求及び状態情報を受信し、サーバ装置２２へ前記要求を引き渡す送達手順Ｓ０５と、
　サーバ側イベントログ記録装置３４が、前記要求に対してサーバ装置２２からクライアント装置２１へ送信される前記応答が発生する度に、前記応答についてのユニークな状態情報を生成する第２状態演算手順Ｓ０６と、
　サーバ側イベントログ記録装置３４が、クライアント側イベントログ記録装置３３へ前記応答及び第２状態演算手順Ｓ０６で生成した状態情報を送信する第２送信手順Ｓ０７と、
　サーバ側イベントログ記録装置３４が、前記応答と対応付けて第２状態演算手順Ｓ０６で生成した状態情報を記録する第２記憶手順Ｓ０８と、
　サーバ側イベントログ記録装置３４が、クライアント側イベントログ記録装置３３から前記要求を受信する度に、前記要求についてのユニークな状態情報を生成する第３状態演算手順Ｓ０９と、
　クライアント側イベントログ記録装置３３から受信した状態情報と第３状態演算手順Ｓ０９で演算した状態情報とが異なる場合、クライアント側イベントログ記録装置３３とサーバ側イベントログ記録装置３４が、両者が記録する状態情報を照合し、両者が記録する状態情報が一致する状態一致時点を検索する照合手順Ｓ１０と、
　前記照合手順で検索した前記状態一致時点から、前記クライアント側イベントログ記録装置から受信した状態情報と前記第３状態演算手順で演算した状態情報とが異なっている時点までの、前記第１記憶手順で記録する前記要求を、前記クライアント側イベントログ記録装置がサーバ側イベントログ記録装置３４へ再送する再送手順Ｓ１１と、
を行うことを特徴とする。

［クライアント側（中心部分）がサーバ側（受託部分）と接続する手順］
　まず、接続手順Ｓ０１を説明する。
　クライアント側メイン部品２３は、サーバ側メイン部品２４と接続する際に、サーバ送信部品３１を経由し、プラットフォーム５１に対してクライアント側イベントログＤＢ３３およびサーバ側イベントログＤＢ３４の構築を要請する。
　プラットフォーム５１が２つのイベントログデータベースの構築を完了した後、クライアント側メイン部品２３は、サーバ側メイン部品２４と接続する際に、サーバ送信部品３１を経由し、プラットフォーム５１に対して、クライアント側イベントログＤＢ３３およびサーバ側イベントログＤＢ３４との間の接続を要請する。
　当該接続が確立すると、プラットフォーム５１は、クライアント装置２１とサーバ装置２２との間で行われるすべての通信のログを記録する。

［クライアント側がサーバ側にコマンドを送信する手順］
　図３も用いて本手順を説明する。クライアント側メイン部品２３がサーバ側に「コマンド」を送信する場合、当該「コマンド」はイベントとして、サーバ送信部品３１、クライアント側イベントログＤＢ３３、サーバ側イベントログＤＢ３４、及びクライアント受信部品３２を経由する（図２及び図３のＰ１、Ｐ１_１、Ｐ１_２、Ｐ１_３、Ｐ１_４）。

　その際、クライアント側イベントログＤＢ３３は、要求イベントを第１記憶部８４に記録し（第１記憶手順Ｓ０４）、また第１状態演算部８３が状態を表現するユニークな「状態情報」を算出して（第１状態演算手順Ｓ０２）第１記憶部８４に記録する（第１記憶手順Ｓ０４）。そして、第１送受信部８２がその状態情報をサーバ側イベントログＤＢ３４に送信する（第１送信手順Ｓ０３、図２のＰ１_２要求）。第１状態演算部８３は、例えば、過去のハッシュ値に、新たなイベント（コマンド）のハッシュ値を加算して状態情報を作成する。

　また、サーバ送信部品３１は、複数あるメイン部品２３のいずれから送られた要求が、送信ログのいずれと対応するかを記録してもよい。さらに、クライアント側イベントログＤＢ３３は、送信時刻や算出した状態（例：ハッシュ値）をサーバ送信部品３１へ返信する機能を有しても良い（図３のＰ１ｘ）。本機能は、クライアント側のメイン部品２３がスケールアウト等によって複数存在している場合に、サーバ送信部品３１は要求と応答とのマッチングを行い、複数のメイン部品２３のうち、いずれのメイン部品２３に応答を送信するかを決定するのに利用できる。

　サーバ側イベントログＤＢ３４は、受信した要求イベントを第２記憶部９４に記録し、クライアント受信部品３２へ送信する。そして、クライアント受信部品３２は、当該要求イベントを宛先のサーバ側メイン部品２４に引き渡す（送達手順Ｓ０５）。ここで、サーバ側イベントログＤＢ３４は、当該要求イベントについての状態を表現するユニークな「状態情報」を算出する（第３状態演算手順Ｓ０９）。なお、第３状態演算手順Ｓ０９については後述する。

　図４も用いて本手順を説明する。サーバ側メイン部品２４は、「コマンド」を受信した結果、クライアント側に通知すべき何らかの状態の変更が生じた場合は、その結果を「応答」として、クライアント受信部品３２、サーバ側イベントログＤＢ３４、クライアント側イベントログＤＢ３３、クライアント側サーバ送信部品３１を経由して返信する（図２及び図４のＰ２、Ｐ２_１、Ｐ２_２、Ｐ２_３、Ｐ２_４）。メイン部品２３がスケールアウトにより複数ある場合、サーバ送信部品３１は、受信した応答Ｐ２_３に付随する「要求ログ状態」と、対応するメイン部品２３とのテーブルによって、応答を適切なメイン部品２３に配送しても良い。

　その際、サーバ側イベントログＤＢ３４は、応答イベントを第２記憶部９４に記録し、その状態を表現するユニークな「状態情報」を算出し（第２状態演算手順Ｓ０６）、その時点における新しい「状態」を第２記憶部９４に記録する（第２記憶手順Ｓ０８）。サーバ側イベントログＤＢ３４は、その状態も含めて、応答をクライアント側イベントログＤＢ３３に送信する（第２送信手順Ｓ０７、図２のＰ２_２応答）。

［クライアント側がサーバ側にクエリを送信する手順］
　本システムは、端末１０またはクライアント側メイン部品２３が「クエリ」を要求するときも、前述した「コマンド」の送信と同様にサーバ送信部品３１、クライアント側イベントログＤＢ３３、サーバ側イベントログＤＢ３４、及びクライアント受信部品３２を経由してサーバ側のメイン部品２４に「クエリ」を送達する（図２及び図３のＰ１、Ｐ１_１、Ｐ１_２、Ｐ１_３、Ｐ１_４）。そして、本システムは、当該クエリに対してサーバ側のメイン部品２４からの「回答」を、クライアント受信部品３２、サーバ側イベントログＤＢ３４、クライアント側イベントログＤＢ３３、クライアント側サーバ送信部品３１を経由して返信する（図２及び図４のＰ２、Ｐ２_１、Ｐ２_２、Ｐ２_３、Ｐ２_４）。
　クエリの場合も、サーバ側イベントログＤＢ３３及びクライアント側イベントログＤＢ３４は、クエリやその回答を記録する。

　ただし、図２のＰ１_１にて、サーバ送信部品３１からクライアント側イベントログＤＢ３３にクエリが届いた際、クライアント側イベントログＤＢ３３は、当該クエリの内容がすでに記憶している「応答イベント」から得られる内容であるならば、それを返す。本システムは、クライアント側メイン部品２３からのクエリに対してクライアント側イベントログＤＢ３３内にて要求を見つけることができるために、サーバ側までの通信を省けて高速化を実現できる。

［通信に障害が発生した際にイベントログＤＢから通信を復元する手順］
　図５及び図１０を用いて前述した第３状態演算手順Ｓ０９から再送手順Ｓ１１について詳説する。
　サーバ側イベントログＤＢ３４の第２制御部９１は、第２送受信部９２が要求イベントＰ１_２とともにクライアント側イベントログＤＢ３３が算出した状態（例えばハッシュ値）も受信したときに、当該状態と第２状態演算部９３が計算する状態（例えばハッシュ値）とを比較する。

　状態（例えばハッシュ値）が、クライアント側イベントログＤＢ３３が計算したものとサーバ側イベントログＤＢ３４で計算したもので異なる場合、この２ＤＢ間の通信に何らかの障害が発生し、過去のイベント受信に失敗したと考えられる。その場合、この２ＤＢは相互に第１記憶部８４と第２記憶部９４が記憶する通信ログを比較し、ハッシュ値が一致する時点までさかのぼって、要求イベントのどの段階で障害が発生したかを突き止める（照合手順Ｓ１０）。

　通信障害発生時点を突き止めた場合、イベントログの障害発生時点に遡り、クライアント側イベントログＤＢ３３はイベントの再送信を試みる（再送手順Ｓ１１）。その結果、双方の「状態」が一致し、かつ、通信障害によって欠落したイベントが復元する。そして、サーバ側イベントログＤＢ３４は欠落したイベントをクライアント受信部品３２に送信するため、通信の障害はメイン部品（２３、２４）からは可視化されずに整合性が維持される。

　本説明では、「要求イベント」について、ログＤＢからイベントを復元する方法を述べたが、「応答イベント」についても同様にイベントを復元できる。

［通信の実時間性を保証する手順］
　前述のように、クライアント側サーバ送信部品３１およびサーバ側クライアント受信部品３２は、その間の通信遅延時間、および端末１０からサーバ送信部品３１までの通信時間を測定する機能を有する。図６を用いて、本機能によりサーバ・クライアント間を実時間で通信する（制限された通信時間内で高品質な応答を返答する）方法を説明する。

　端末（利用者）にとって、満足度の高いサービスを提供する場合、「応答は早いが低品質な情報を提供するサービス」と「応答は遅いが高品質な情報を提供するサービス」のバランスが問題となる場合がある。
　また、ネットワークサービスにおけるメイン部分２３が、複数の受託部分に一部の業務を委託する場合、委託にかかる時間を最小化するため、複数の委託が依存関係にある場合はそれらを順番に要求し、依存関係にない場合はそれらを並列に要求し、全体にかかる時間を調整する場合がある。

　そこで、本システムは、前記２つの通信装置の間の通信遅延時間を計測する計測装置をさらに備え、
　前記２つの通信装置のうちの一方の通信装置は、前記イベントに指定された最大応答時間から前記計測装置が計測した往復の通信遅延時間を差し引いた応答期限を前記２つの通信装置のうちの他方の通信装置に通知し、
　前記他方の通信装置は、前記イベントに対して時間が短くレベルの低い処理から時間が長くレベルの高い処理までの複数の処理を生成し、前記複数の処理の中から前記応答期限内で最もレベルの高い処理を前記イベントに対する応答のイベントとして前記一方の通信装置へ返信する
ことを特徴とする。

　ここでは、サーバ装置２１がクライアント装置２２に対して、指定された時間以内に最大の品質の応答を返すための方法を説明する。
　サーバ送信部品３１は、クライアント受信部品３２との間の通信時間を測定する。メイン部品２３は、サーバ装置２２に対して依頼を行う際、その希望する最大応答時間を指定する。サーバ送信部品３１は、メイン部品２３から指定された時間から、測定してある前記通信時間である往復分のネットワーク遅延時間を差し引いた分を、応答で容認する最大時間として指定して、要求Ｐ１を行う。

　クライアント受信部品３２は、メイン部品２４に対して要求Ｐ１_４を行い、その結果、メイン部品２４は、クライアント受信部品３２に対して、まず「応答時間は短いが品質が低い応答」を行い、その後の処理の適当なタイミングで、応答時間を長くして「より品質の高い応答」を可能な限り複数送出する。なお、サーバ装置２２がさらに他の装置へ要求Ｐ１_４の一部を再委託するような場合（クライアント側として振る舞う場合）は、当該再委託の応答時間も自身の応答時間に加算されることになる。このため、サーバ装置２２は、再委託の応答時間が長い場合、あるいは把握できない場合、要求Ｐ１_４受信後すぐに暫定的にデフォルトの応答をしてもよい。

　クライアント受信部品３２は、メイン部品２４から次々と入力される応答Ｐ２のうち、クライアント装置２１との遅延時間を考慮した最適なタイミングで、その時点における最適な応答を選択し、応答Ｐ２_１としてサーバ側イベントログＤＢ３４へ出力する。この応答は、前述のようにクライアント側イベントログＤＢ３３、及びサーバ送信部品３１を介してメイン部品２３に送達される。

［ソフトウェアの更新時におけるデータベースの再構築方法］
　ネットワークサービスで使用するソフトウェアは、サービス提供以降、必要に応じて更新される場合がある。
　また、新機能を追加するためにソフトウェアを更新した結果、使用するデータベースの持つカラムの種類など、データベースのスキーマが根本からが変更されることがある。
　また、通常、ソフトウェアの更新はいきなり全て行うのではなく、まずシステムを２つまたはそれ以上に分散させ、その一部のみを更新ソフトウェアで問題なく動作するか確認し、十分な運用試験を経て問題がなければ残りを更新することがある。このような場合、２つの異なるデータベースのスキーマを持つサービスが同時に動く場合がある。

　このようにソフトウェアを更新するときには、通信装置が備えるデータベースを再構築する必要がある。そこで、本システムは、前記イベントログ記録装置の前記記憶部が、前記送受信部が受信した、前記イベントに応答する相手イベントと相手状態情報も前記イベントに対応付けて記録しており、
　前記２つの通信装置が、自身が変更された場合、自身に接続する前記イベントログ記録装置の前記記憶部が記録する前記相手イベントを受け取り、データベースを再構築することを特徴とする。

　通信装置が備えるデータベースを再構築する手法を図７を用いて説明する。図７は、クライアント装置２１側で説明しているが、サーバ装置２２側も同様である。
　本システムは、クライアント装置２１のデータベースを構築するのに必要な通信ログをクライアント側イベントログＤＢ３３が保持している。具体的には、クライアント側イベントログＤＢ３３は、サーバ装置２２への要求それぞれに対応するように、当該要求から算出された状態情報、サーバ装置２２からの応答（相手イベント）、及び当該応答から算出された状態情報（相手状態情報）を記録している。

　ここで、クライアント装置２１でソフトウェアの更新がされたことを想定する。クライアント装置２１には、ソフトウェア更新で新たなメイン部品２３が形成される。このメイン部品２３は、データベースを再構築するために、サーバ送信部品３１に対して再構築請求Ｐ３を行う。サーバ送信部品３１は、当該再構築請求Ｐ３を受けてクライアント側イベントログＤＢ３３に巻き戻し要求Ｐ３_１を送る。クライアント側イベントログＤＢ３３は、再構築請求Ｐ３で指定された時刻及び状態情報に対応する複数の応答イベントＰ４_１をまとめてサーバ送信部品３１に送信する。メイン部品２３は、サーバ送信部品３１から複数の応答イベントＰ４_２を受け取り、データベースを再構築する。

　これは、特にソフトウェアの更新前と、更新後のサービスを並列に動かす場合、および、ソフトウェアの更新に限らず、データベースを再構築したい場合の広範囲に亘って有効な方法である。なお、上記のようなクライアント側やサーバ側でデータベースの再構築が行われても、それぞれのイベントログＤＢがその間の要求や応答のイベント毎に状態情報（ハッシュ）を更新するので、データベースの再構築前後で矛盾の発生を抑えることができる。

［サービスのスケール時における要求と応答の適切な分配の実現］
　上述のように、２つのイベントログＤＢ（３３、３４）は、それぞれクライアント装置２１からの要求、およびサーバ装置２２からの応答に固有の状態（実施例：ハッシュ値）を割り当てる。この状態（実施例：ハッシュ値）が、適切な乱数値とみなされる場合、その任意数による剰余の取りうる値は等確率になると考えられる。

　このため、例えば、クライアント装置２１のメイン部分２３が複数にスケーリングした場合、サーバ装置２２からの１つの応答はいずれかのメイン部分２３に送達されることになる。ここで、サーバ送信部品３１が適切に実装されていれば送達先が確率的に等しくなるため、サーバ送信部品３１は応答を各メイン部分２３に均等に分配できる。

［クライアント側イベントログ記録装置の動作］
　図１１は、クライアント側イベントログ記録装置３３の動作をまとめたフローチャートである。
　第１送受信部８２は、信号が入力された時、どこからの信号かを判断する（ステップＳ１１２）。当該信号がクライアント装置２１からの信号である場合、その信号種別を判断する（ステップＳ１１３）。その信号種別が「要求」であれば、第１状態演算部８３が状態情報（要求）〔要求ログ状態、例えばハッシュ値〕を演算し（ステップＳ１１４）、第１記憶部８４が「要求」と対応付けて状態情報（要求）を記憶する（ステップＳ１１５）。また、「要求」と状態情報（要求）をサーバ側イベントログ記録装置３４へ送信する（ステップＳ１１６）。一方、その信号種別が「再構築請求（巻き戻し要求）」であれば、第１制御部８１は、指定された時刻ないし状態情報（要求）に対応する「応答」を第１記憶部８４から収集し（ステップＳ１１７）、クライアント装置２１へ送信する（ステップＳ１１８）。

　入力された信号がサーバ側イベントログ記録装置３４からの信号である場合、その信号種別を判断する（ステップＳ１２１）。その信号種別が「応答」であれば、第１状態演算部８３が状態情報（応答）〔応答ログ状態、例えばハッシュ値〕を演算し（ステップＳ１２２）、第１記憶部８４が「要求」と対応付けて「応答」と状態情報（応答）を記憶する（ステップＳ１２３）。また、「応答」をクライアント側イベントログ記録装置３３へ送信する（ステップＳ１２４）。一方、その信号種別が「照合」であれば、第１制御部８１は、照合作業（ステップＳ１２５）を開始する。照合作業（ステップＳ１２５）の具体的作業は、クライアント側イベントログ記録装置３３とサーバ側イベントログ記録装置３４が、連携して第１記憶部８４と第２記憶部９４が記憶する状態情報（要求）を突き合わせ、一致する時点（不一致が始まった時点）を検索する（サーバ側イベントログ記録装置３４ではステップＳ１４５）。第１制御部８１は、照合した結果、不一致であった「要求」及び状態情報（要求）をサーバ側イベントログ記録装置３４へ再送する（ステップＳ１２６）。

［サーバ側イベントログ記録装置の動作］
　図１２は、サーバ側イベントログ記録装置３４の動作をまとめたフローチャートである。
　第２送受信部９２は、信号が入力された時、どこからの信号かを判断する（ステップＳ１３２）。当該信号がサーバ装置２２からの信号である場合、その信号種別を判断する（ステップＳ１３３）。その信号種別が「応答」であれば、第２状態演算部９３が状態情報（応答）〔応答ログ状態、例えばハッシュ値〕を演算し（ステップＳ１３４）、第２記憶部９４が「要求」と対応付けて「応答」及び状態情報（応答）を記憶する（ステップＳ１３５）。また、「応答」と状態情報（応答）をクライアント側イベントログ記録装置３３へ送信する（ステップＳ１３６）。一方、その信号種別が「再構築請求（巻き戻し要求）」であれば、第２制御部９１は、指定された時刻ないし状態情報（応答）に対応する「要求」を第２記憶部９４から収集し（ステップＳ１３７）、クライアント装置２２へ送信する（ステップＳ１３８）。

　入力された信号がクライアント側イベントログ記録装置３３からの信号（「要求」及び状態情報（要求））である場合、第２状態演算部９３が状態情報（要求）〔要求ログ状態、例えばハッシュ値〕を演算し（ステップＳ１４１）、クライアント側イベントログ記録装置３３から送られてきたものと演算したものを比較する（ステップＳ１４２）。両者が一致していれば、第２記憶部９４が「要求」と対応付けて状態情報（要求）を記憶し（ステップＳ１４３）、「要求」をサーバ装置２２へ送信する（ステップＳ１４４）。一方、両者が不一致である場合、第２制御部９１は、クライアント側イベントログ記録装置３３に対して「照合」を要請する。照合作業（ステップＳ１４５）の具体的作業は、クライアント側イベントログ記録装置３３とサーバ側イベントログ記録装置３４が、連携して第１記憶部８４と第２記憶部９４が記憶する状態情報（要求）を突き合わせ、一致する時点（不一致が始まった時点）を検索する（クライアント側イベントログ記録装置３３ではステップＳ１２５）。照合作業の結果、クライアント側イベントログ記録装置３３から不一致であった「要求」及び状態情報（要求）が再送されてくるので、第２送受信部９２はこれを受信する（ステップＳ１４６）。そして、第２記憶部９４が「要求」と対応付けて再送された状態情報（要求）を記憶し（ステップＳ１４７）、再送された「要求」をサーバ装置２２へ送信する（ステップＳ１４８）。

［付記］
　以下は、本発明のネットワークサービスシステムの特徴をまとめたものである。
（１）課題
　異なるステークホルダー間のマイクロサービスを連携して構成するネットワークサービスでは、通信が何らかの理由で失敗した場合、その原因が送信者や受信者側（サービスのスケーリング等やソフト・ハードによる障害）にあるか、通信事業者にあるかを判断することが困難である。
　また、各マイクロサービスが、資源消費量に応じて柔軟にスケールイン・スケールアウトする際、要求送信後且つ応答受信前にスケーリングが行われると、要求と応答を正しくスケーリング後のサービスに返すことが困難（いずれのサービスに返せばよいか不明）となる。
　さらに、サービスのスケーリングや障害の回復がなされると、サービスを回復させる方法が不明である。
（２）解決手段
　本発明のネットワークサービスシステムは、「ネットワークサービス」を構成する「マイクロサービス」を、「サーバ側」と「クライアント側」に分け、且つ「サーバ側」と「クライアント側」の通信を「コマンド」と「クエリ」に分ける。さらに、本発明のネットワークサービスシステムは、「コマンド」に限ってログを記録する機構、「サーバ側」と「クライアント側」の通信の間に自動的に介入し、その間の通信をログとしてデータベースに保存し、各イベントログを記録する毎に状態情報を更新する機構、及び通信時間を計測する機構を具備する。
（３）効果
　上記解決手段により、本発明のネットワークサービスシステムは次の効果を得られ、上記課題を解決する。
　図５で説明したように、通信障害による送受信データ欠落を復元できる。
　図６で説明したように、サーバ装置とクライアント装置との間の実時間による通信を可能とする。
　図７で説明したように、ソフトウェアの更新や再起動時における通信装置のデータベースを再構築できる。
　マイクロサービスのスケール時における、要求及び応答のマッチングと均等な分散を可能とする。

１０：端末
２１：クライアント装置（クライアント側通信装置）
２２：サーバ装置（サーバ側通信装置）
２３：メイン部品
２４：メイン部品
３１：サーバ送信部品
３２：クライアント受信部品
３３：クライアント側イベントログ記録装置
３４：サーバ側イベントログ記録装置
４０：ネットワークサービス
５０：アダプタ
５１：プラットフォーム
５２：ネットワーク
８１：第１制御部
８２：第１送受信部
８３：第１状態演算部
８４：第１記憶部
９１：第２制御部
９２：第２送受信部
９３：第２状態演算部
９４：第２記憶部

Claims

　２つの通信装置の間で通信イベントを送受するネットワークサービスシステムであって、
　前記２つの通信装置の各々に接続され、前記２つの通信装置の間の通信を中継する２つのイベントログ記録装置を備え、
　前記イベントログ記録装置は、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算部と、
　前記イベントと前記状態演算部が生成した状態情報を相手側のイベントログ記録装置に送信するとともに、前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する送受信部と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶部と、
　前記送受信部が前記相手イベントと前記相手状態情報を受信したときに、前記状態演算部に前記相手イベントのユニークな状態情報を生成させ、当該状態情報と前記相手状態情報とが異なる場合、前記記憶部に記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記送受信部に再送させる制御部と、
を有することを特徴とするネットワークサービスシステム。
　前記２つの通信装置の間の通信遅延時間を計測する計測装置をさらに備え、
　前記２つの通信装置のうちの一方の通信装置は、前記イベントに指定された最大応答時間から前記計測装置が計測した往復の通信遅延時間を差し引いた応答期限を前記２つの通信装置のうちの他方の通信装置に通知し、
　前記他方の通信装置は、前記イベントに対して時間が短くレベルの低い処理から時間が長くレベルの高い処理までの複数の処理を生成し、前記複数の処理の中から前記応答期限内で最もレベルの高い処理を前記イベントに対する応答のイベントとして前記一方の通信装置へ返信する
ことを特徴とする請求項１に記載のネットワークサービスシステム。
　前記記憶部は、前記送受信部が受信した、前記イベントに応答する相手イベントと相手状態情報も前記イベントに対応付けて記録しており、
　前記２つの通信装置は、自身が変更された場合、自身に接続する前記イベントログ記録装置の前記記憶部が記録する前記相手イベントを受け取り、データベースを再構築することを特徴とする請求項１又は２に記載のネットワークサービスシステム。
　２つの通信装置の間で通信イベントを送受するネットワークサービスシステムにおいて、
　前記２つの通信装置毎に接続され、前記２つの通信装置の間の通信を中継するイベントログ記録装置であって、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算部と、
　前記イベントと前記状態演算部が生成した状態情報を相手側のイベントログ記録装置に送信するとともに、前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する送受信部と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶部と、
　前記送受信部が前記相手イベントと前記相手状態情報を受信したときに、前記状態演算部に前記相手イベントのユニークな状態情報を生成させ、当該状態情報と前記相手状態情報とが異なる場合、前記記憶部に記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記送受信部に再送させる制御部と、
を有することを特徴とするイベントログ記録装置。
　２つの通信装置の間で通信イベントを送受するネットワークサービスシステムのイベントログ管理方法であって、
　前記２つの通信装置の各々に接続され、前記２つの通信装置の間の通信を中継する２つのイベントログ記録装置をプラットフォームに形成する接続手順と、
　前記２つの通信装置のうち、接続している通信装置にイベントが発生する度に、前記イベントのユニークな状態情報を生成する状態演算手順と、
　前記イベントと前記状態演算手順で生成した状態情報を相手側のイベントログ記録装置に送信する送信手順と、
　前記状態演算部が生成した状態情報を前記イベントと対応付けて記録する記憶手順と、
　前記相手側のイベントログ記録装置からの相手イベントと相手状態情報を受信する受信手順と、
　前記受信手順で前記相手イベントと前記相手状態情報を受信したときに、前記相手イベントのユニークな状態情報を生成し、当該状態情報と前記相手状態情報とが異なる場合、前記記憶手順で記録する状態情報と前記相手側のイベントログ記録装置が記録する相手状態情報を照合して両者が一致する時点まで遡って、前記記憶部に記録されたイベントを前記相手側のイベントログ記録装置へ再送する再送手順と、
を行うことを特徴とするイベントログ管理方法。
　請求項４に記載のイベントログ記録装置としてコンピュータを機能させるためのプログラム。