JP5708078B2 - 検証装置、検証方法および検証プログラム - Google Patents

Description

本発明は、検証装置、検証方法および検証プログラムに関する。

Ｗｅｂサーバ、ＤＢ（Data Base）サーバ、クライアント装置などの装置を有するシステムでは、各装置に対して、パッチ適用、ファームウェア更新、ウィルス定義更新などの更新作業が実施されている。このような更新作業では、更新前と更新後とで異なる動作を実行しないか、すなわち、機能面または性能面で退化がないかが懸念される。

このことから、従来では、サービスを提供している実動環境の装置に更新作業を実施する前に、検証用に準備した検証環境の装置で事前検証を行っている。一例を挙げると、装置間で送受信されるデータの送信間隔と同じタイミングでデータ送信を実行し、障害発生の再現テストを実施できる電文収録装置が開示されている。この電文収録装置は、検証に関係のないデータ送受信については短い電文間隔で高速送信して、効率的にシミュレーションを実行する。

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

しかしながら、従来の技術では、事前検証を容易に実施することができないという問題があった。

例えば、複数装置が多階層に連携して動作するシステムなどでは、事前検証するための検証用システムとして、実動機と同じ装置構成の別システムを用意するなど、検証のために準備に時間やコストがかかる。

一例を挙げると、Ｗｅｂサーバ、ＤＢサーバ、クライアント装置のうちＷｅｂサーバに対して事前作業を行う場合であっても、ＤＢサーバとクライアント装置を用意し、実動環境のシステムを同じシステムを構築した上で、事前検証を実行する。このように、事前検証のために用意する装置費用もかかり、また、検証用のシステムを構築する場所や時間もかかることから、事前検証を簡単に実行できない。

１つの側面では、事前検証を容易に実行できる検証装置、検証方法および検証プログラムを提供することを目的とする。

第１の案では、検証装置は、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部を有する。検証装置は、検証対象の第１の情報処理装置から他の第２の情報処理装置へ送信されたデータを受信する受信部を有する。検証装置は、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第１の情報処理装置に応答する応答部を有する。

事前検証を容易に実行できる。

図１は、実施例１に係るシステムの全体構成の例を示す図である。 図２は、実施例２に係る事前検証装置の構成を示すブロック図である。 図３は、実施例２に係る実動キャプチャデータＤＢに記憶される情報の例を示す図である。 図４は、検証データＤＢに記憶される情報の例を示す図である。 図５は、実施例２に係る事前検証を説明する図である。 図６は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。 図７は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。 図８は、実施例３に係るシステムの全体構成の例を示す図である。 図９は、実施例３に係る実動キャプチャデータＤＢに記憶される情報の例を示す図である。 図１０は、実施例３に係る事前検証を説明する図である。 図１１は、対応表生成例を示す図である。 図１２は、対応表生成例を示す図である。 図１３は、対応表生成例を示す図である。 図１４は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に、本願の開示する検証装置、検証方法および検証プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るシステムの全体構成の例を示す図である。図１に示すように、このシステムは、事前検証装置１０が実動環境と検証環境との各々に接続されている。実動環境は、クライアントに対してＷｅｂサービス等の各種サービスを提供するシステムである。検証環境は、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するためのシステムである。

実動環境は、実動ＡＰ（Application）サーバ１ａと実動ＤＢ（Data Base）サーバ１ｂとクライアント端末１ｃとスイッチ１ｄとを有し、検証環境とは別のネットワークで形成される。実動ＡＰサーバ１ａは、クライアント端末１ｃから要求を受信して、実動ＤＢサーバ１ｂへのトランザクションを実行するサーバであり、ＨＴＭＬ文書などを蓄積してＷｅｂサービスを提供するＷｅｂアプリケーションサーバとしての機能を有していてもよい。

例えば、実動ＡＰサーバ１ａは、クライアント端末１ｃから受信した要求に対応したアプリケーションを実行して、実動ＤＢサーバ１ｂへリクエストを送信する。そして、実動ＡＰサーバ１ａは、当該リクエストに対するレスポンスを実動ＤＢサーバ１ｂから受信して、クライアント端末１ｃに送信する。

実動ＤＢサーバ１ｂは、データベースを有し、実動ＡＰサーバ１ａから受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動ＡＰサーバ１ａに送信する。なお、実動ＤＢサーバ１ｂが有するデータベースは、関係データベース、オブジェクトデータベース、ＫＶＳ（キーバリューストア）など様々なデータベースを利用できる。

クライアント端末１ｃは、Ｗｅｂブラウザ等を用いて実動ＡＰサーバ１ａにアクセスして各サービスを利用するコンピュータであり、例えば実動ＡＰサーバ１ａを介して実動ＤＢサーバ１ｂが保持するデータベースを更新したりする。

スイッチ１ｄは、実動ＡＰサーバ１ａ、実動ＤＢサーバ１ｂ、クライアント端末１ｃの各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ１ｄとしては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ１ｄは、ポートミラーリングを実行しており、実動ＡＰサーバ１ａ、実動ＤＢサーバ１ｂ、クライアント端末１ｃの各々から受信したデータを事前検証装置１０に送信する。

検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置１０に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、ＡＰサーバだけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、事前検証装置１０は、ＡＰサーバと同様の機能を有する検証ＡＰサーバに対して検証を実行する。

ここでは、一例として、実動ＡＰサーバ１ａを検証することとするので、検証環境は検証ＡＰサーバ２ａを有するものとする。検証ＡＰサーバ２ａは、実動ＡＰサーバ１ａと同様の機能を実装した検証対象のサーバであり、事前検証装置１０と接続される。この検証ＡＰサーバ２ａには、検証ＡＰサーバ２ａが直接通信する検証対象外の装置である、実動ＤＢサーバ１ｂとクライアント端末１ｃ各々のアドレスとして、事前検証装置１０のＩＰ（Internet Protocol）アドレスを設定しておく。

検証ＡＰサーバ２ａは、実動環境の実動ＡＰサーバ１ａが処理する実トランザクションと同様のトランザクションを実行して、データを事前検証装置１０に送信する。また、検証ＡＰサーバ２ａは、事前検証装置１０からパケットを受信した場合に、当該データに対応する応答データを事前検証装置１０に送信する。

事前検証装置１０は、保持部１０ａと受信部１０ｂと応答部１０ｃとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証ＡＰサーバ２ａの動作や性能を検証するサーバである。

保持部１０ａは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部１０ａは、スイッチ１ｄのポートミラーリングによって受信したデータを保持する。

受信部１０ｂは、検証対象である検証ＡＰサーバ２ａから他の装置である実動環境の他装置へ送信されたデータを受信する。応答部１０ｃは、受信部１０ｂによって受信されたデータの応答として実動システムで送信されたデータを保持部１０ａが保持するキャプチャデータから特定し、特定したデータを検証対象の検証ＡＰサーバ２ａに応答する。

このように、事前検証装置１０は、実動環境で使用されたトランザクションによって発生したデータや、データの送受信シーケンスを記憶することで、検証対象サーバ以外のサーバ動作を擬似的に動作することができる。したがって、事前検証を実施するのに際して、実動環境と同じ環境を用意することなく、検証対象装置だけを準備すれば事前検証を実行することができる。したがって、事前検証を容易に実行できる。

次に、図１に事前検証装置の具体的な構成等を実施例２として説明する。なお、実動ＡＰサーバ１ａや検証ＡＰサーバ２ａは、一般的なＡＰサーバと同様の機能を有し、実動ＤＢサーバ１ｂは、一般的なＤＢサーバと同様の機能を有し、クライアント端末は、一般的なコンピュータと同様の機能を有するので、詳細な説明は省略する。ここでは、事前検証装置の構成、処理の流れ、効果等について説明する。

［事前検証装置の構成］
図２は、実施例２に係る事前検証装置の構成を示すブロック図である。図２に示すように、事前検証装置１０は、通信インタフェース１１、実動キャプチャデータＤＢ１２、検証データＤＢ１３、検証結果ＤＢ１４、制御部１５を有する。

通信インタフェース１１は、少なくとも１つのポートを有し、事前検証装置１０と検証ＡＰサーバ２ａとの間の通信を制御する。また、通信インタフェース１１は、事前検証装置１０とスイッチ１ｄとの間の通信も制御する。

この通信インタフェースの各ポートには、実動環境で使用するＩＰ（Internet Protocol）アドレスと、検証対象外装置のＩＰアドレスが設定される。図１の場合、通信インタフェースの第１ポートには、実動環境用のＩＰアドレスが設定される。そして、通信インタフェースの第２ポートには、実動ＤＢサーバ１ｂ宛として使用されるＩＰアドレスが設定される。さらに、通信インタフェースの第３ポートには、クライアント端末１ｃ宛として使用されるＩＰアドレスが設定される。

実動キャプチャデータＤＢ１２は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持する。すなわち、実動キャプチャデータＤＢ１２は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。実動キャプチャデータＤＢ１２には、後述するパケットキャプチャ部１６によって、１日や１週間など所定間隔でキャプチャされたキャプチャデータが格納される。

図３は、実施例２に係る実動キャプチャデータＤＢに記憶される情報の例を示す図である。図３に示すように、実動キャプチャデータＤＢ１２は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。

ここで記憶される「シーケンシャル番号」は、パケットキャプチャリングされた順番を示し、「送信元」は、キャプチャされたパケットの送信元を示す。「送信先」は、キャプチャされたパケットの送信先を示し、「パケット」は、キャプチャされたパケットの情報を示す。なお、実動キャプチャデータ１２は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。

図３の例の場合、１番目に、クライアント端末１ｃから実動ＡＰサーバ１ａに送信されたＨＴＴＰ Ｒｅｑがキャプチャされ、２番目に、実動ＡＰサーバ１ａから実動ＤＢサーバ１ｂに送信されたＳＱＬ Ｒｅｑがキャプチャされたことを示す。さらに、３番目に、実動ＤＢサーバ１ｂから実動ＡＰサーバ１ａに送信されたＳＱＬ Ｒｅｓがキャプチャされたことを示し、４番目に、実動ＡＰサーバ１ａからクライアント端末１ｃに送信されたＨＴＴＰ Ｒｅｓがキャプチャされたことを示す。なお、Ｒｅｑは、Ｒｅｑｕｅｓｔの略であり、Ｒｅｓは、Ｒｅｓｐｏｎｓｅの略である。

検証データＤＢ１３は、後述する検証実施部１７が検証を実施して得られた検証データであり、検証実施部１７が検証環境で送受信されるパケットをキャプチャしたデータを記憶する。ここで記憶される情報は検証実施部１７によって格納される。図４は、検証データＤＢに記憶される情報の例を示す図である。図４に示すように、検証データＤＢ１３は、「検証対象装置、シーケンシャル番号、送信パケット、受信パケット」を対応付けて記憶する。

ここで記憶される「検証対象装置」は、検証が実施された装置の名称やＩＰアドレスなどであり、「シーケンシャル番号」は、検証によってパケットが送受信された順番である。「送信パケット」は、検証の際に送信されたパケットの情報であり、「受信パケット」は、検証で受信されたパケットの情報である。図４の例の場合、ＡＰサーバに対して実行した検証では、１番目にＨＴＴＰ Ｒｅｑが送信され、２番目にＳＱＬ Ｒｅｑが受信され、３番目にＳＱＬ Ｒｅｓが送信され、４番目にＨＴＴＰ Ｒｅｓが受信されたことを示す。

検証結果ＤＢ１４は、後述する検証実施部１７によって得られた検証結果を記憶する。例えば、検証結果ＤＢ１４は、検証された日時を示す「検証日時」、検証された装置を示す「検証対象装置」、正常または異常など検証結果を示す「検証結果」を対応付けて記憶する。

制御部１５は、パケットキャプチャ部１６と検証実施部１７とを有し、パケットキャプチャや検証試験を実施する。なお、制御部１５は、ＣＰＵ（Central Processing Unit）などの電子回路やＦＰＧＡ（Field-Programmable Gate Array）などの集積回路等である。

パケットキャプチャ部１６は、スイッチ１ｄを介して、実動環境で実際に送受信されたパケットをキャプチャして、実動キャプチャデータＤＢ１２に格納する。例えば、クライアント端末１ｃが、実動ＡＰサーバ１ａにアクセスしてアプリケーションを実行し、実動ＡＰサーバ１ａが、アプリケーションの実行によって実動ＤＢサーバ１ｂに対してＤＢアクセスを実行したとする。

この場合、はじめに、パケットキャプチャ部１６は、クライアント端末１ｃから実動ＡＰサーバ１ａへのＤＢ処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部１６は、実動ＡＰサーバ１ａから実動ＤＢサーバ１ｂへ送信されたＤＢリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部１６は、実動ＤＢサーバ１ｂから実動ＡＰサーバ１ａへ送信されたＤＢレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部１６は、実動ＡＰサーバ１ａからクライアント端末１ｃへ送信されたＤＢ処理要求に対する応答を示すパケットをキャプチャする。

つまり、パケットキャプチャ部１６は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、実動キャプチャデータ１２に格納する。なお、パケットキャプチャ部１６は、キャプチャしたパケットそのものを実動キャプチャデータＤＢ１２に格納してもよい。

検証実施部１７は、クライアント擬似動作部１７ａとサーバ擬似動作部１７ｂと結果解析部１７ｃとを有し、これらによって検証対象装置に検証を実行する。クライアント擬似動作部１７ａは、実動キャプチャデータＤＢ１２に保持されるキャプチャデータに、検証対象の装置を宛先とする送信待ちのパケットが存在する場合に、当該パケットを検証対象の装置に送信する。

例えば、クライアント擬似動作部１７ａは、システム管理者等によって検証開始が指示されると、実動キャプチャデータＤＢ１２を参照する。そして、クライアント擬似動作部１７ａは、検証処理がクライアント端末からのパケット送信である場合には、実動キャプチャデータＤＢ１２にしたがって、該当するパケットを生成して検証対象装置に送信する。

一例を挙げると、クライアント擬似動作部１７ａは、図３に示した実動キャプチャデータＤＢ１２を参照し、シーケンシャル番号＝１の処理がクライアント端末１ｃから実動ＡＰサーバ１ａへのパケット送信であることを特定する。この結果、クライアント擬似動作部１７ａは、特定したパケットであるＨＴＴＰ Ｒｅｑを検証ＡＰサーバ２ａに送信する。つまり、クライアント擬似動作部１７ａは、検証ＡＰサーバ２ａに実トランザクションと同様の処理を実行させるために、クライアント端末１ｃの動作を擬似的に実行する。また、クライアント擬似動作部１７ａは、送信したパケット（ＨＴＴＰ Ｒｅｑ）にシーケンシャル番号＝１を割り与えて、これらを対応付けて検証データＤＢ１３に格納する。

サーバ擬似動作部１７ｂは、検証対象の装置から検証対象外の装置へ送信されたパケットを受信する。そして、サーバ擬似動作部１７ｂは、受信されたパケットの応答として実動システムで送信されたパケットを実動キャプチャデータＤＢ１２が保持するキャプチャデータから特定し、特定したパケットを検証対象の装置に応答する。

例えば、サーバ擬似動作部１７ｂは、クライアント擬似動作部１７ａからＨＴＴＰ Ｒｅｑを受信した検証ＡＰサーバ２ａが実トランザクションと同様のトランザクションを実行して、実動ＤＢサーバ１ｂに送信したＳＱＬ Ｒｅｑを受信する。続いて、サーバ擬似動作部１７ｂは、実動キャプチャデータＤＢ１２を参照し、ＳＱＬ Ｒｅｑの次に、実動ＤＢサーバ１ｂから実動ＡＰサーバ１ａにＳＱＬ Ｒｅｓが送信されていることを特定する。そして、サーバ擬似動作部１７ｂは、ＳＱＬ Ｒｅｓを検証ＡＰサーバ２ａに送信する。

このように、事前検証装置１０と検証ＡＰサーバ２ａとの２台で、実動環境と同様のトランザクションで同様の処理を実行する。つまり、事前検証装置１０は、検証環境に存在しない実動ＤＢサーバ１ｂの動作を擬似的に実行する。また、サーバ擬似動作部１７ｂは、受信したパケット（ＳＱＬ Ｒｅｑ）にシーケンシャル番号＝２を割り与えて検証データＤＢ１３に格納する。同様に、サーバ擬似動作部１７ｂは、送信したパケット（ＳＱＬ Ｒｅｓ）にシーケンシャル番号＝３を割り与えて検証データＤＢ１３に格納する。

結果解析部１７ｃは、クライアント擬似動作部１７ａやサーバ擬似動作部１７ｂによって実行された検証結果を解析する。そして、結果解析部１７ｃは、検証結果をディスプレイ等に表示させたり、メールで管理者等に送信したりする。

例えば、結果解析部１７ｃは、実動キャプチャデータＤＢ１２に記憶されている情報と検証結果ＤＢ１４に記憶されている情報とを比較して、一致している場合には、検証処理に異常がないと判定する。一方、結果解析部１７ｃは、実動キャプチャデータＤＢ１２に記憶されている情報と検証結果ＤＢ１４に記憶されている情報とが一致していない場合には、検証処理に異常があると判定する。この場合、結果解析部１７ｃは、一致していない箇所を特定し、特定した箇所を管理者に通知したりする。

［事前検証の具体例］
次に、事前検証装置１０の検証実施部１７が実行する事前検証について説明する。図５は、実施例２に係る事前検証を説明する図である。ここで実行される各処理は、例えばシステム管理者から検証開始を指示された場合に、処理を開始する。

図５に示すように、事前検証装置１０の通信インタフェースには、実動ＤＢサーバ１ｂ宛として使用されるＩＰアドレスと、クライアント端末１ｃ宛として使用されるＩＰアドレスが設定されている。検証ＡＰサーバ２ａには、検証ＡＰサーバ２ａが直接通信する検証対象外の装置である、実動ＤＢサーバ１ｂとクライアント端末１ｃの各々のアドレスとして、事前検証装置１０のＩＰアドレスが設定されている。

つまり、検証ＡＰサーバ２ａは、実動ＤＢサーバ１ｂ宛のパケットおよびクライアント端末１ｃ宛のパケットを事前検証装置１０に送信する。また、検証ＡＰサーバ２ａは、実動ＤＢサーバ１ｂを送信元とするパケットおよびクライアント端末１ｃを送信元とするパケットを事前検証装置１０から受信する。

このような状態において、クライアント擬似動作部１７ｃは、実動キャプチャデータＤＢ１２に記憶される情報にしたがってクライアント端末１ｃの動作を擬似し、ＨＴＴＰ Ｒｅｑを検証ＡＰサーバ２ａに送信する。続いて、サーバ擬似動作部１７ｂは、検証ＡＰサーバ２ａからＳＱＬ Ｒｅｑを受信した場合、実動キャプチャデータＤＢ１２に記憶される情報にしたがって実動ＤＢサーバ１ｂを擬似し、ＳＱＬ Ｒｅｓを検証ＡＰサーバ２ａに応答する。

その後、サーバ擬似動作部１７ｂは、検証ＡＰサーバ２ａからＨＴＴＰ Ｒｅｓが送信されると、実動キャプチャデータＤＢ１２に記憶される情報にしたがってクライアント動作１ｃを擬似し、ＨＴＴＰ Ｒｅｓを受信する。このようにして、事前検証装置１０は、実動環境が取得したパケットキャプチャデータにしたがって検証対象外装置の動作を擬似的に動作させることで、検証処理を実行する。

［処理の流れ］
次に、図６と図７を用いて、図１に示したシステムで実行される処理の流れについて説明する。ここでは、事前検証装置１０が実行するクライアント擬似動作とサーバ擬似動作のそれぞれについて説明する。

（クライアント擬似動作）
図６は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。図６に示すように、クライアント擬似動作部１７ａは、実動キャプチャデータＤＢ１２を参照し、全データの処理が終了したか否かを判定する（Ｓ１０１）。

そして、クライアント擬似動作部１７ａは、全データの処理が終了していないと判定した場合（Ｓ１０１否定）、実動キャプチャデータＤＢ１２に送信待ちのデータが存在するか否かを判定する（Ｓ１０２）。

その後、クライアント擬似動作部１７ａは、送信待ちのデータが存在すると判定した場合には（Ｓ１０２肯定）、クライアント端末の動作を擬似的に実行して、検証対象装置に対してパケットを送信する（Ｓ１０３）。つまり、クライアント擬似動作部１７ａは、検証環境に、実動環境と同様のトランザクションを発生させる。

そして、クライアント擬似動作部１７ａは、検証対象装置に対してパケットを送信したことで、実動キャプチャデータＤＢ１２の全データに対して処理を実行した場合には（Ｓ１０１肯定）、処理を終了する。なお、Ｓ１０２において、クライアント擬似動作部１７ａは、実動キャプチャデータＤＢ１２に送信待ちのデータが存在しないと判定した場合には（Ｓ１０２否定）、Ｓ１０１以降の処理を繰り返す。

（サーバ擬似動作）
図７は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。図７に示すように、サーバ擬似動作部１７ｂは、実動キャプチャデータＤＢ１２を参照し、全データの処理が終了したか否かを判定する（Ｓ２０１）。

そして、サーバ擬似動作部１７ｂは、全データの処理が終了していないと判定した場合（Ｓ２０１否定）、Ｓ２０２以降の処理を実行する。すなわち、サーバ擬似動作部１７ｂは、検証対象装置からパケットを受信した場合（Ｓ２０２肯定）、実動キャプチャデータＤＢ１２を参照し、受信したパケットの応答パケットを抽出する（Ｓ２０３）。

続いて、サーバ擬似動作部１７ｂは、抽出した応答パケットを検証対象装置に送信する（Ｓ２０４）。その後、サーバ擬似動作部１７ｂは、Ｓ２０１以降の処理を繰り返す。なお、Ｓ２０２において、サーバ擬似動作部１７ｂは、検証対象装置からパケットを受信するまでは、Ｓ２０１とＳ２０２を繰り返す。また、サーバ擬似動作部１７ｂは、全データの処理が終了したと判定した場合（Ｓ２０１肯定）、処理を終了する。

［実施例２による効果］
実施例２に係る事前検証装置１０を用いることで、検証環境として、検証対象外の装置等を準備しなくても、検証対象装置を準備することで事前検証を実施できる。したがって、事前検証の環境構築の費用や人為的労力を従来に比べて大幅に軽減できる。

例えば、ＤＢサーバが検証対象外の場合、従来では、実動環境と検証環境においてのＤＢ同期を行っていたが、事前検証装置１０を用いることで、同期を行わずとも検証を実施できる。また、図１に示した実動環境以外の他システムで動作する外部サーバが存在する場合、従来は、検証対象の外部サーバとして、検証に用いるスタブ動作をするサーバおよびロジックを準備していた。これに対して、事前検証装置１０は、実動環境の実キャプチャデータを用いるので、外部サーバとして筐体やアプリケーションを実装しなくても、実動環境の各装置の検証を容易に実施できる。

ところで、実施例２では、ＡＰサーバとＤＢサーバの２階層を有する実動環境のサーバを検証する例について説明したが、これに限定されるものではない。例えば、事前検証装置は、２階層以外の階層であっても同様に検証を実施することができる。そこで、実施例３では、一例として、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバの３階層を有する実動環境におけるＷｅｂサーバに対して検証を実行する例について説明する。

［全体構成］
図８は、実施例３に係るシステムの全体構成の例を示す図である。図８は、実施例１と同様、事前検証装置１０と検証環境とが接続されるとともに、事前検証装置１０と実動環境とが接続されている。この検証Ｗｅｂサーバ２ｂには、検証Ｗｅｂサーバ２ｂが直接通信する検証対象外の装置である、実動ＡＰサーバ１ａと実動ＤＢサーバ１ｂとクライアント端末１ｃの各々のアドレスとして、事前検証装置１０のＩＰアドレスを設定しておく。

実動環境は、実施例２等で説明した装置に加えて実動Ｗｅｂサーバ１ｅを有し、検証環境とは別のネットワークで形成される。実動Ｗｅｂサーバ１ｅは、ＨＴＭＬ文書や画像などの情報を蓄積しておき、クライアント端末１ｃや実動ＡＰサーバ１ａからの要求に応じて、画像等を表示させたＷｅｂページを応答する。

検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置１０に接続する環境である。実施例３では、検証対象装置として検証Ｗｅｂサーバ２ｂが事前検証装置１０と接続されている。

事前検証装置１０は、実施例２等と同様、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証ＡＰサーバ２ａの動作や性能を検証するサーバである。この事前検証装置１０は、実動環境における各装置がトランザクションを実行したことで発生したパケットをキャプチャリングする。そして、事前検証装置１０は、キャプチャリングしたデータを使用して、検証Ｗｅｂサーバ２ｂを検証する。

［検証処理］
図８に示した事前検証装置１０は、図２と同様の構成を有するが、実施例２とは実動環境内の装置が異なることから、実動キャプチャデータＤＢ１２が記憶する内容が異なる。図９は、実施例３に係る実動キャプチャデータＤＢに記憶される情報の例を示す図である。図９に示すように、実施例３に係る実動キャプチャデータＤＢ１２は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。なお、ここで記憶される各情報は、実施例２と同様なので、詳細な説明は省略する。

実施例３に係る実動キャプチャデータと実施例２で説明した実動キャプチャデータとが異なる点は、実施例３に係る実動キャプチャデータは、実動Ｗｅｂサーバのパケットをキャプチャしている点である。具体的に、図９を用いて説明する。図９の例では、１番目に、クライアント端末１ｃから実動Ｗｅｂサーバ１ｅに送信されたＨＴＴＰ Ｒｅｑがキャプチャされたことを示す。２番目に、実動Ｗｅｂサーバ１ｅから実動ＡＰサーバ１ａに送信されたＩＩＯＰ（Internet Inter−ORB Protocol） Ｒｅｑがキャプチャされたことを示す。

さらに、３番目に、実動ＡＰサーバ１ａから実動ＤＢサーバ１ｂに送信されたＳＱＬ Ｒｅｑがキャプチャされたことを示し、４番目に、実動ＤＢサーバ１ｂから実動ＡＰサーバ１ａに送信されたＳＱＬ Ｒｅｓがキャプチャされたことを示す。５番目に、実動ＡＰサーバ１ａから実動Ｗｅｂサーバ１ｅに送信されたＩＩＯＰ Ｒｅｓがキャプチャされ、６番目に、実動Ｗｅｂサーバ１ｅからクライアント端末１ｃに送信されたＨＴＴＰ Ｒｅｓがキャプチャされたことを示す。

次に、上述したＤＢを有する事前検証装置１０が検証Ｗｅｂサーバ２ｂに検証を実行する例について説明する。図１０は、実施例３に係る事前検証を説明する図である。図１０に示すように、事前検証装置１０のクライアント擬似動作部１７ａは、クライアント端末１ｃから実動Ｗｅｂサーバ１ｅへのＨＴＴＰ Ｒｅｑが送信待ちになると、実動キャプチャデータＤＢ１２を参照する。すると、クライアント擬似動作部１７ａは、実動キャプチャデータＤＢ１２に記憶される「シーケンシャル番号＝１」にしたがって、検証Ｗｅｂサーバ２ｂにＨＴＴＰ Ｒｅｑを送信する。

続いて、サーバ擬似動作部１７ｂは、実動キャプチャデータＤＢ１２に記憶される「シーケンシャル番号＝２」と同様の処理として、検証Ｗｅｂサーバ２ｂからＩＩＯＰ Ｒｅｑを受信する。すると、サーバ擬似動作部１７ｂは実動キャプチャデータＤＢ１２に記憶される「シーケンシャル番号＝５」にしたがって、実動Ｗｅｂサーバ２ｂにＩＩＯＰ Ｒｅｓを送信する。

ここで、サーバ擬似動作部１７ｂは、実動キャプチャデータＤＢ１２に記憶される「シーケンシャル番号＝３と４」についてはパケット送信を実行しない。つまり、サーバ擬似動作部１７ｂは、実動ＡＰサーバ１ａから実動ＤＢサーバ１ｂへのＳＱＬ Ｒｅｑ送信と、実動ＤＢサーバ１ｂから実動ＡＰサーバ１ａへのＳＱＬ Ｒｅｓ受信を実行しない。このサーバ擬似動作部１７ｂは、検証対象の検証Ｗｅｂサーバ２ｂに直接関わりがない処理については、暗に実動システムと同様の処理が内部でなされたとして、パケット送受信しない。

その後、結果解析部１７ｃは、サーバ擬似動作部１７ｂが検証Ｗｅｂサーバ２ｂからクライアント端末１ｃへのＨＴＴＰ Ｒｅｓを受信すると、検証環境での機能および性能解析検証を行い、検証試験結果を表示する。なお、結果解析部１７ｃが実行する処理は、実施例２と同様なので、詳細な説明は省略する。

［実施例３による効果］
このように、実施例３によれば、事前検証装置１０は、実キャプチャデータにおいて、検証対象である装置が直接通信しない検証対象外の装置と関係する通信については、キャプチャデータで採取されていても、利用しないで検証を進めることができる。なお、事前検証装置１０は、検証対象装置が関係する通信だけを実動環境でキャプチャし、検証対象装置が関係しない通信については、キャプチャしないようにすることもできる。このようにすることで、メモリやＤＢの容量増加も防止できる。

ところで、実施例１から実施例３では、事前検証装置１０は、実動環境で取得したキャプチャデータを用いて検証を実行する例について説明したが、これに限定されるものではない。例えば、事前検証装置１０は、実動環境で取得したキャプチャデータから、送受信されるパケットの対応表を生成し、この対応表を用いて検証を実行することもできる。そこで、実施例３では、事前検証装置１０が生成する対応表の生成について説明する。

（具体例１）
図１１は、対応表生成例を示す図である。図１１の左図に示すように、事前検証装置１０のパケットキャプチャ部１６は、実動ＡＰサーバと実動ＤＢサーバとの通信をキャプチャすることで、要求ａ、要求ｂ、応答ｃ、応答ｄが送受信されたことを特定する。ところが、パケットキャプチャ部１６は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。

そこで、パケットキャプチャ部１６は、実動ＡＰサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動ＡＰサーバと実動ＤＢサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部１６は、両方のキャプチャデータを時間順に並べる。つまり、図１１の中央図に示すように、パケットキャプチャ部１６は、クライアント１から要求を受信した実動ＡＰサーバが要求ａを実動ＤＢサーバに送信し、クライアント２から要求を受信した実動ＡＰサーバが要求ｂを実動ＤＢサーバに送信したと特定できる。さらに、図１１の中央図に示すように、パケットキャプチャ部１６は、実動ＤＢサーバから応答ｃを受信した実動ＡＰサーバが応答をクライアント２に送信し、実動ＤＢサーバから応答ｄを受信した実動ＡＰサーバが応答をクライアント１に送信したと特定できる。

この結果、パケットキャプチャ部１６は、図１１の右図に示すように、「要求、応答」として「要求ａ、応答ｄ」と「要求ｂ、応答ｃ」と対応付けて記憶することができる。その後、クライアント擬似動作部１７ｂやサーバ擬似動作部１７ｃは、この対応表を用いて検証を実行する。

例えば、実動ＡＰサーバを検証する場合、クライアント擬似動作部１７ｂは、クライアント端末の動作を擬似して、要求を検証ＡＰサーバに送信する。そして、サーバ擬似動作部１７ｃは、検証ＡＰサーバから要求ａを受信すると、要求ａに対応する応答ｄを対応表から特定し、実動ＤＢサーバの動作を擬似して応答ｄを実動ＡＰサーバに応答する。その後、サーバ擬似動作部１７ｃは、応答ｄに対応する応答を実動ＡＰサーバから受信する。

そして、結果解析部１７は、検証対象装置と事前検証装置１０との間で対応表通りにパケットを送受信できた場合に、検証対象装置が正常動作していると判定する。一方、結果解析部１７は、検証対象装置と事前検証装置１０との間で対応表通りにパケットを送受信できなかった場合に、検証対象装置が異常動作していると判定する。

（具体例２）
図１２は、対応表生成例を示す図である。図１２の左図に示すように、事前検証装置１０のパケットキャプチャ部１６は、実動ＡＰサーバと実動ＤＢサーバとの通信をキャプチャすることで、要求ａ、要求ｂ、応答ｃ、応答ｄが送受信されたことを特定する。ところが、パケットキャプチャ部１６は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。

そこで、パケットキャプチャ部１６は、実動ＡＰサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動ＡＰサーバと実動ＤＢサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部１６は、両方のキャプチャデータを時間順に並べる。つまり、図１２の中央図に示すように、パケットキャプチャ部１６は、クライアント１から要求を受信した実動ＡＰサーバが要求ａを実動ＤＢサーバに送信し、クライアント２から要求を受信した実動ＡＰサーバが要求ｂを実動ＤＢサーバに送信したと特定できる。さらに、図１２の中央図に示すように、パケットキャプチャ部１６は、実動ＤＢサーバから応答ｃを受信した実動ＡＰサーバが応答をクライアント１に送信し、実動ＤＢサーバから応答ｄを受信した実動ＡＰサーバが応答をクライアント２に送信したと特定できる。

この結果、パケットキャプチャ部１６は、図１２の右図に示すように、「要求、応答」として「要求ａ、応答ｃ」と「要求ｂ、応答ｄ」と対応付けて記憶することができる。その後、クライアント擬似動作部１７ｂやサーバ擬似動作部１７ｃは、この対応表を用いて検証を実行する。

（具体例３）
図１３は、対応表生成例を示す図である。図１３の左上図に示すように、事前検証装置１０のパケットキャプチャ部１６は、実動ＡＰサーバと実動ＤＢサーバとの通信をキャプチャすることで、要求ａ、要求ｂ、応答ｃ、応答ｄが送受信されたことを特定する。ところが、パケットキャプチャ部１６は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。

そこで、パケットキャプチャ部１６は、クライアント端末と実動ＡＰサーバと実動ＤＢサーバとの間で、１多重で処理が実行されたときのシーケンスを利用する。つまり、パケットキャプチャ部１６は、図１３の左上図とは別にパケットキャプチャした情報として、図１３の左下図に示すようなクライアント端末から実動ＡＰサーバに要求が送信されて、実動ＡＰサーバから実動ＤＢサーバに要求ａが送信された情報を取得する。さらに、パケットキャプチャ部１６は、実動ＤＢサーバから応答ｄが実動ＡＰサーバに送信されて、実動ＡＰサーバがクライアント端末に応答を返信した情報を取得する。

そして、パケットキャプチャ部１６は、図１３の左下図に示したパケットキャプチャ情報から「要求ａ」と「応答ｄ」とが対応していることを特定する。パケットキャプチャ部１６は、この結果を図１３の左上図と組み合わせて「要求ａ」と「応答ｄ」とを除外することで、「要求ｂ」と「応答ｃ」とが対応することを特定する。

この結果、パケットキャプチャ部１６は、図１３の右図に示すように、「要求、応答」として「要求ａ、応答ｄ」と「要求ｂ、応答ｃ」と対応付けて記憶することができる。その後、クライアント擬似動作部１７ｂやサーバ擬似動作部１７ｃは、この対応表を用いて検証を実行する。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（検証対象）
例えば、上述した実施例では、ＡＰサーバやＷｅｂサーバを検証する例について説明したが、これに限定されるものではなく、実動環境で動作する様々な装置を検証対象とすることができる。また、事前検証装置は、実動環境に流れる全てのパケットをキャプチャリングようにしてもよく、検証対象装置に関連するパケットだけをキャプチャリングするようにしてもよい。

また、実施例１等では、事前検証装置１０は、検証対象の装置から検証対象外の装置へのパケットを受信して、検証対象外の装置の動作を擬似する例について説明したが、これに限定されるものではない。例えば、事前検証装置１０は、実動環境のパケットをキャプチャリングしておくことで、検証対象の装置から検証対象の他の装置へのパケットを受信して、検証対象の他の装置の動作を擬似することもできる。この場合、例えば、検証対象の装置には、検証対象の装置が直接通信する検証対象の他の装置のアドレスとして、事前検証装置１０のＩＰアドレスを設定しておくことで、事前検証装置１０は、検証対象の装置から検証対象の他の装置へのパケットを受信できる。

（検証環境）
例えば、上述した実施例では、実動環境と検証環境とを別のネットワークで構築する例について説明したが、これに限定されるものではない。例えば、実動環境を用いて検証することもできる。その場合、図１のスイッチ１ｄに対して、事前検証装置と検証対象装置とが接続されるようにスイッチング情報の設定変更をしてもよく、事前検証装置と検証対象装置を実動環境上で直接接続するように、一時的にネットワークを変更してもよい。

（インタフェース）
例えば、実施例２に係る事前検証装置１０では、通信インタフェース１１の第２ポートに実動ＤＢサーバ１ｂと同じＩＰアドレスを設定し、第３ポートには、クライアント端末１ｃと同じＩＰアドレスを設定することで、通信を区別する例について説明した。ところが、通信の区別はこれに限定されるものではない。例えば、通信インタフェースそのものを複数用意してもよく、通信メッセージの特性から通信を区別することもできる。

通信メッセージの特性から通信を区別する一例を挙げると、例えば、ＨＴＴＰ通信の場合にはクライアント端末の通信と判定し、ＳＱＬ通信の場合にはＤＢサーバの通信と区別することができる。なお、上述した実施例で説明した各要求や応答はあくまで例示であり、これに限定されるものではない。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図３、図９等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
図１４は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１４に示すように、コンピュータ１００は、ＣＰＵ１０１、メモリ１０２、ＩＦ（Interface）１０３、Ｄｉｓｋ１０４を備えている。また、各構成部はバス１００ａによってそれぞれ接続されている。ここで、ＣＰＵ１０１は、コンピュータ１００の全体の制御を司る。メモリ１０２は、ＣＰＵ１０１のワークエリアとして使用され、本メモリ内で検証試験プログラム１０２ａが動作する。この検証試験プログラム１０２ａが実行されることで、図２に示した各制御部と同様の処理を動作する検証試験プロセスが実行される。また、Ｄｉｓｋ１０４には、実動キャプチャデータ１０４ａが記憶される。

コンピュータ１００の外部には、モニタ１０５として、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示し、マウス１０６により操作する。このモニタ１０５は、例えば、ＣＲＴ（Cathode Ray Tube）、ＴＦＴ（Thin Film Transistor）液晶ディスプレイ、プラズマディスプレイなどを採用することができる。ＩＦ１０３は、通信回線を通じてＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネットなどのネットワークに接続される。そして、ＩＦ１０３は、これらのネットワークを介して実動系システム、検証系システムを含む他の装置に接続される。また、ＩＦ１０３は、ネットワークと内部のインタフェースを司り、外部装置からのデータの入出力を制御する。ＩＦ１０３には、たとえばＬＡＮアダプタやモデムなどを採用することができる。

１０ 事前検証装置
１１ 通信インタフェース
１２ 実動キャプチャデータＤＢ
１３ 検証データＤＢ
１４ 検証結果ＤＢ
１５ 制御部
１６ パケットキャプチャ部
１７ 検証実施部
１７ａ クライアント擬似動作部
１７ｂ サーバ擬似動作部
１７ｃ 結果解析部

Claims (6)

1. 複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを、送受信された順で保持する保持部と、
   前記保持部に記憶されるキャプチャデータから、検証対象である第１の情報処理装置と非検証対象である第２の情報処理装置との間における、処理を要求する際に送信された要求データと当該要求データの応答として送信された応答データとの対応関係を生成する場合に、第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置に送信した要求データまたは前記第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置から受信した応答データとを用いて、前記第１の情報処理装置と前記第２の情報処理装置との間における要求データと応答データとを特定して、前記対応関係を生成する生成部と、
   前記第１の情報処理装置から前記第２の情報処理装置へ送信されたデータを受信する受信部と、
   前記受信部によって受信されたデータの応答として前記システムで送信されたデータを、前記保持部が保持するキャプチャデータのうち前記受信部によって受信されたデータ以降にキャプチャされたキャプチャデータの中から、前記生成部によって生成された対応関係に基づいて特定し、特定したデータを前記検証対象である第１の情報処理装置に応答する応答部と
   を有することを特徴とする検証装置。
2. 前記保持部に保持されるキャプチャデータに、前記検証対象の第１の情報処理装置を宛先とする送信待ちのデータが存在する場合に、当該データを前記検証対象の第１の情報処理装置に送信する送信部をさらに有することを特徴とする請求項１に記載の検証装置。
3. 前記生成部は、前記保持部に記憶されるキャプチャデータのうち、前記システム内で１つのトランザクションが実行されている際に取得されたキャプチャデータから、前記要求データと応答データとの対応関係を生成することを特徴とする請求項１に記載の検証装置。
4. アプリケーションサーバとデータベースサーバとを有するシステム内で、前記アプリケーションサーバと前記データベースサーバとの間で実行されたトランザクションによって発生したデータをキャプチャして得られたキャプチャデータを、発生した順で保持する保持部と、
   前記システムとは異なる環境において、検証対象であるアプリケーションサーバから非検証対象であるデータベースサーバへ送信されたデータを受信する受信部と、
   前記受信部によって受信されたデータ以降にキャプチャされた前記キャプチャデータの中から、受信されたデータの応答として、前記データベースサーバが前記アプリケーションサーバに送信するキャプチャデータを特定し、前記非検証対象であるデータベースサーバに代わって、特定した前記キャプチャデータを前記検証対象であるアプリケーションサーバに応答する応答部と
   を有することを特徴とする検証装置。
5. コンピュータが、
   複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを、送受信された順で保持部に保持し、
   保持されるキャプチャデータから、検証対象である第１の情報処理装置と非検証対象である第２の情報処理装置との間における、処理を要求する際に送信された要求データと当該要求データの応答として送信された応答データとの対応関係を生成する場合に、第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置に送信した要求データまたは前記第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置から受信した応答データとを用いて、前記第１の情報処理装置と前記第２の情報処理装置との間における要求データと応答データとを特定して、前記対応関係を生成し、
   前記第１の情報処理装置から前記第２の情報処理装置へ送信されたデータを受信し、
   受信されたデータの応答として前記システムで送信されたデータを、前記保持部が保持するキャプチャデータのうち受信されたデータ以降にキャプチャされたキャプチャデータの中から、生成された対応関係に基づいて特定し、特定したデータを前記検証対象である第１の情報処理装置に応答する
   処理を実行することを特徴とする検証方法。
6. コンピュータに、
   複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを、送受信された順で保持部に保持し、
   保持されるキャプチャデータから、検証対象である第１の情報処理装置と非検証対象である第２の情報処理装置との間における、処理を要求する際に送信された要求データと当該要求データの応答として送信された応答データとの対応関係を生成する場合に、第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置に送信した要求データまたは前記第３の情報処理装置が前記第１の情報処理装置または前記第２の情報処理装置の少なくとも１つの装置から受信した応答データとを用いて、前記第１の情報処理装置と前記第２の情報処理装置との間における要求データと応答データとを特定して、前記対応関係を生成し、
   前記第１の情報処理装置から前記第２の情報処理装置へ送信されたデータを受信し、
   受信したデータの応答として前記システムで送信されたデータを、前記保持部が保持するキャプチャデータのうち受信されたデータ以降にキャプチャされたキャプチャデータの中から、生成された対応関係に基づいて特定し、特定したデータを前記検証対象である第１の情報処理装置に応答する
   処理を実行させることを特徴とする検証プログラム。

Images