検証装置、検証方法および検証プログラム
【課題】事前検証を容易に実行することを課題とする。
【解決手段】事前検証装置10は、保持部10aと受信部10bと応答部10cとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。保持部10aは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部10aは、スイッチ1dのポートミラーリングによって受信したデータを保持する。受信部10bは、検証対象である検証APサーバ2aから検証対象外である実動環境の他装置へ送信されたデータを受信する。応答部10cは、受信部10bによって受信されたデータの応答として実動システムで送信されたデータを保持部10aが保持するキャプチャデータから特定し、特定したデータを検証対象の検証APサーバ2aに応答する。
【解決手段】事前検証装置10は、保持部10aと受信部10bと応答部10cとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。保持部10aは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部10aは、スイッチ1dのポートミラーリングによって受信したデータを保持する。受信部10bは、検証対象である検証APサーバ2aから検証対象外である実動環境の他装置へ送信されたデータを受信する。応答部10cは、受信部10bによって受信されたデータの応答として実動システムで送信されたデータを保持部10aが保持するキャプチャデータから特定し、特定したデータを検証対象の検証APサーバ2aに応答する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、検証装置、検証方法および検証プログラムに関する。
【背景技術】
【0002】
Webサーバ、DB(Data Base)サーバ、クライアント装置などの装置を有するシステムでは、各装置に対して、パッチ適用、ファームウェア更新、ウィルス定義更新などの更新作業が実施されている。このような更新作業では、更新前と更新後とで異なる動作を実行しないか、すなわち、機能面または性能面で退化がないかが懸念される。
【0003】
このことから、従来では、サービスを提供している実動環境の装置に更新作業を実施する前に、検証用に準備した検証環境の装置で事前検証を行っている。一例を挙げると、装置間で送受信されるデータの送信間隔と同じタイミングでデータ送信を実行し、障害発生の再現テストを実施できる電文収録装置が開示されている。この電文収録装置は、検証に関係のないデータ送受信については短い電文間隔で高速送信して、効率的にシミュレーションを実行する。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2010−81194号公報
【特許文献2】特開2001−44993号公報
【特許文献3】特開2001−195270号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来の技術では、事前検証を容易に実施することができないという問題があった。
【0006】
例えば、複数装置が多階層に連携して動作するシステムなどでは、事前検証するための検証用システムとして、実動機と同じ装置構成の別システムを用意するなど、検証のために準備に時間やコストがかかる。
【0007】
一例を挙げると、Webサーバ、DBサーバ、クライアント装置のうちWebサーバに対して事前作業を行う場合であっても、DBサーバとクライアント装置を用意し、実動環境のシステムを同じシステムを構築した上で、事前検証を実行する。このように、事前検証のために用意する装置費用もかかり、また、検証用のシステムを構築する場所や時間もかかることから、事前検証を簡単に実行できない。
【0008】
1つの側面では、事前検証を容易に実行できる検証装置、検証方法および検証プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
第1の案では、検証装置は、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部を有する。検証装置は、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部を有する。検証装置は、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部を有する。
【発明の効果】
【0010】
事前検証を容易に実行できる。
【図面の簡単な説明】
【0011】
【図1】図1は、実施例1に係るシステムの全体構成の例を示す図である。
【図2】図2は、実施例2に係る事前検証装置の構成を示すブロック図である。
【図3】図3は、実施例2に係る実動キャプチャデータDBに記憶される情報の例を示す図である。
【図4】図4は、検証データDBに記憶される情報の例を示す図である。
【図5】図5は、実施例2に係る事前検証を説明する図である。
【図6】図6は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。
【図7】図7は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。
【図8】図8は、実施例3に係るシステムの全体構成の例を示す図である。
【図9】図9は、実施例3に係る実動キャプチャデータDBに記憶される情報の例を示す図である。
【図10】図10は、実施例3に係る事前検証を説明する図である。
【図11】図11は、対応表生成例を示す図である。
【図12】図12は、対応表生成例を示す図である。
【図13】図13は、対応表生成例を示す図である。
【図14】図14は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【0012】
以下に、本願の開示する検証装置、検証方法および検証プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例1】
【0013】
図1は、実施例1に係るシステムの全体構成の例を示す図である。図1に示すように、このシステムは、事前検証装置10が実動環境と検証環境との各々に接続されている。実動環境は、クライアントに対してWebサービス等の各種サービスを提供するシステムである。検証環境は、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するためのシステムである。
【0014】
実動環境は、実動AP(Application)サーバ1aと実動DB(Data Base)サーバ1bとクライアント端末1cとスイッチ1dとを有し、検証環境とは別のネットワークで形成される。実動APサーバ1aは、クライアント端末1cから要求を受信して、実動DBサーバ1bへのトランザクションを実行するサーバであり、HTML文書などを蓄積してWebサービスを提供するWebアプリケーションサーバとしての機能を有していてもよい。
【0015】
例えば、実動APサーバ1aは、クライアント端末1cから受信した要求に対応したアプリケーションを実行して、実動DBサーバ1bへリクエストを送信する。そして、実動APサーバ1aは、当該リクエストに対するレスポンスを実動DBサーバ1bから受信して、クライアント端末1cに送信する。
【0016】
実動DBサーバ1bは、データベースを有し、実動APサーバ1aから受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動APサーバ1aに送信する。なお、実動DBサーバ1bが有するデータベースは、関係データベース、オブジェクトデータベース、KVS(キーバリューストア)など様々なデータベースを利用できる。
【0017】
クライアント端末1cは、Webブラウザ等を用いて実動APサーバ1aにアクセスして各サービスを利用するコンピュータであり、例えば実動APサーバ1aを介して実動DBサーバ1bが保持するデータベースを更新したりする。
【0018】
スイッチ1dは、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ1dとしては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ1dは、ポートミラーリングを実行しており、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々から受信したデータを事前検証装置10に送信する。
【0019】
検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、APサーバだけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、事前検証装置10は、APサーバと同様の機能を有する検証APサーバに対して検証を実行する。
【0020】
ここでは、一例として、実動APサーバ1aを検証することとするので、検証環境は検証APサーバ2aを有するものとする。検証APサーバ2aは、実動APサーバ1aと同様の機能を実装した検証対象のサーバであり、事前検証装置10と接続される。この検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1c各々のアドレスとして、事前検証装置10のIP(Internet Protocol)アドレスを設定しておく。
【0021】
検証APサーバ2aは、実動環境の実動APサーバ1aが処理する実トランザクションと同様のトランザクションを実行して、データを事前検証装置10に送信する。また、検証APサーバ2aは、事前検証装置10からパケットを受信した場合に、当該データに対応する応答データを事前検証装置10に送信する。
【0022】
事前検証装置10は、保持部10aと受信部10bと応答部10cとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。
【0023】
保持部10aは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部10aは、スイッチ1dのポートミラーリングによって受信したデータを保持する。
【0024】
受信部10bは、検証対象である検証APサーバ2aから他の装置である実動環境の他装置へ送信されたデータを受信する。応答部10cは、受信部10bによって受信されたデータの応答として実動システムで送信されたデータを保持部10aが保持するキャプチャデータから特定し、特定したデータを検証対象の検証APサーバ2aに応答する。
【0025】
このように、事前検証装置10は、実動環境で使用されたトランザクションによって発生したデータや、データの送受信シーケンスを記憶することで、検証対象サーバ以外のサーバ動作を擬似的に動作することができる。したがって、事前検証を実施するのに際して、実動環境と同じ環境を用意することなく、検証対象装置だけを準備すれば事前検証を実行することができる。したがって、事前検証を容易に実行できる。
【実施例2】
【0026】
次に、図1に事前検証装置の具体的な構成等を実施例2として説明する。なお、実動APサーバ1aや検証APサーバ2aは、一般的なAPサーバと同様の機能を有し、実動DBサーバ1bは、一般的なDBサーバと同様の機能を有し、クライアント端末は、一般的なコンピュータと同様の機能を有するので、詳細な説明は省略する。ここでは、事前検証装置の構成、処理の流れ、効果等について説明する。
【0027】
[事前検証装置の構成]
図2は、実施例2に係る事前検証装置の構成を示すブロック図である。図2に示すように、事前検証装置10は、通信インタフェース11、実動キャプチャデータDB12、検証データDB13、検証結果DB14、制御部15を有する。
【0028】
通信インタフェース11は、少なくとも1つのポートを有し、事前検証装置10と検証APサーバ2aとの間の通信を制御する。また、通信インタフェース11は、事前検証装置10とスイッチ1dとの間の通信も制御する。
【0029】
この通信インタフェースの各ポートには、実動環境で使用するIP(Internet Protocol)アドレスと、検証対象外装置のIPアドレスが設定される。図1の場合、通信インタフェースの第1ポートには、実動環境用のIPアドレスが設定される。そして、通信インタフェースの第2ポートには、実動DBサーバ1b宛として使用されるIPアドレスが設定される。さらに、通信インタフェースの第3ポートには、クライアント端末1c宛として使用されるIPアドレスが設定される。
【0030】
実動キャプチャデータDB12は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持する。すなわち、実動キャプチャデータDB12は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。実動キャプチャデータDB12には、後述するパケットキャプチャ部16によって、1日や1週間など所定間隔でキャプチャされたキャプチャデータが格納される。
【0031】
図3は、実施例2に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図3に示すように、実動キャプチャデータDB12は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。
【0032】
ここで記憶される「シーケンシャル番号」は、パケットキャプチャリングされた順番を示し、「送信元」は、キャプチャされたパケットの送信元を示す。「送信先」は、キャプチャされたパケットの送信先を示し、「パケット」は、キャプチャされたパケットの情報を示す。なお、実動キャプチャデータ12は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。
【0033】
図3の例の場合、1番目に、クライアント端末1cから実動APサーバ1aに送信されたHTTP Reqがキャプチャされ、2番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQL Reqがキャプチャされたことを示す。さらに、3番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQL Resがキャプチャされたことを示し、4番目に、実動APサーバ1aからクライアント端末1cに送信されたHTTP Resがキャプチャされたことを示す。なお、Reqは、Requestの略であり、Resは、Responseの略である。
【0034】
検証データDB13は、後述する検証実施部17が検証を実施して得られた検証データであり、検証実施部17が検証環境で送受信されるパケットをキャプチャしたデータを記憶する。ここで記憶される情報は検証実施部17によって格納される。図4は、検証データDBに記憶される情報の例を示す図である。図4に示すように、検証データDB13は、「検証対象装置、シーケンシャル番号、送信パケット、受信パケット」を対応付けて記憶する。
【0035】
ここで記憶される「検証対象装置」は、検証が実施された装置の名称やIPアドレスなどであり、「シーケンシャル番号」は、検証によってパケットが送受信された順番である。「送信パケット」は、検証の際に送信されたパケットの情報であり、「受信パケット」は、検証で受信されたパケットの情報である。図4の例の場合、APサーバに対して実行した検証では、1番目にHTTP Reqが送信され、2番目にSQL Reqが受信され、3番目にSQL Resが送信され、4番目にHTTP Resが受信されたことを示す。
【0036】
検証結果DB14は、後述する検証実施部17によって得られた検証結果を記憶する。例えば、検証結果DB14は、検証された日時を示す「検証日時」、検証された装置を示す「検証対象装置」、正常または異常など検証結果を示す「検証結果」を対応付けて記憶する。
【0037】
制御部15は、パケットキャプチャ部16と検証実施部17とを有し、パケットキャプチャや検証試験を実施する。なお、制御部15は、CPU(Central Processing Unit)などの電子回路やFPGA(Field-Programmable Gate Array)などの集積回路等である。
【0038】
パケットキャプチャ部16は、スイッチ1dを介して、実動環境で実際に送受信されたパケットをキャプチャして、実動キャプチャデータDB12に格納する。例えば、クライアント端末1cが、実動APサーバ1aにアクセスしてアプリケーションを実行し、実動APサーバ1aが、アプリケーションの実行によって実動DBサーバ1bに対してDBアクセスを実行したとする。
【0039】
この場合、はじめに、パケットキャプチャ部16は、クライアント端末1cから実動APサーバ1aへのDB処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部16は、実動APサーバ1aから実動DBサーバ1bへ送信されたDBリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部16は、実動DBサーバ1bから実動APサーバ1aへ送信されたDBレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部16は、実動APサーバ1aからクライアント端末1cへ送信されたDB処理要求に対する応答を示すパケットをキャプチャする。
【0040】
つまり、パケットキャプチャ部16は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、実動キャプチャデータ12に格納する。なお、パケットキャプチャ部16は、キャプチャしたパケットそのものを実動キャプチャデータDB12に格納してもよい。
【0041】
検証実施部17は、クライアント擬似動作部17aとサーバ擬似動作部17bと結果解析部17cとを有し、これらによって検証対象装置に検証を実行する。クライアント擬似動作部17aは、実動キャプチャデータDB12に保持されるキャプチャデータに、検証対象の装置を宛先とする送信待ちのパケットが存在する場合に、当該パケットを検証対象の装置に送信する。
【0042】
例えば、クライアント擬似動作部17aは、システム管理者等によって検証開始が指示されると、実動キャプチャデータDB12を参照する。そして、クライアント擬似動作部17aは、検証処理がクライアント端末からのパケット送信である場合には、実動キャプチャデータDB12にしたがって、該当するパケットを生成して検証対象装置に送信する。
【0043】
一例を挙げると、クライアント擬似動作部17aは、図3に示した実動キャプチャデータDB12を参照し、シーケンシャル番号=1の処理がクライアント端末1cから実動APサーバ1aへのパケット送信であることを特定する。この結果、クライアント擬似動作部17aは、特定したパケットであるHTTP Reqを検証APサーバ2aに送信する。つまり、クライアント擬似動作部17aは、検証APサーバ2aに実トランザクションと同様の処理を実行させるために、クライアント端末1cの動作を擬似的に実行する。また、クライアント擬似動作部17aは、送信したパケット(HTTP Req)にシーケンシャル番号=1を割り与えて、これらを対応付けて検証データDB13に格納する。
【0044】
サーバ擬似動作部17bは、検証対象の装置から検証対象外の装置へ送信されたパケットを受信する。そして、サーバ擬似動作部17bは、受信されたパケットの応答として実動システムで送信されたパケットを実動キャプチャデータDB12が保持するキャプチャデータから特定し、特定したパケットを検証対象の装置に応答する。
【0045】
例えば、サーバ擬似動作部17bは、クライアント擬似動作部17aからHTTP Reqを受信した検証APサーバ2aが実トランザクションと同様のトランザクションを実行して、実動DBサーバ1bに送信したSQL Reqを受信する。続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、SQL Reqの次に、実動DBサーバ1bから実動APサーバ1aにSQL Resが送信されていることを特定する。そして、サーバ擬似動作部17bは、SQL Resを検証APサーバ2aに送信する。
【0046】
このように、事前検証装置10と検証APサーバ2aとの2台で、実動環境と同様のトランザクションで同様の処理を実行する。つまり、事前検証装置10は、検証環境に存在しない実動DBサーバ1bの動作を擬似的に実行する。また、サーバ擬似動作部17bは、受信したパケット(SQL Req)にシーケンシャル番号=2を割り与えて検証データDB13に格納する。同様に、サーバ擬似動作部17bは、送信したパケット(SQL Res)にシーケンシャル番号=3を割り与えて検証データDB13に格納する。
【0047】
結果解析部17cは、クライアント擬似動作部17aやサーバ擬似動作部17bによって実行された検証結果を解析する。そして、結果解析部17cは、検証結果をディスプレイ等に表示させたり、メールで管理者等に送信したりする。
【0048】
例えば、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とを比較して、一致している場合には、検証処理に異常がないと判定する。一方、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とが一致していない場合には、検証処理に異常があると判定する。この場合、結果解析部17cは、一致していない箇所を特定し、特定した箇所を管理者に通知したりする。
【0049】
[事前検証の具体例]
次に、事前検証装置10の検証実施部17が実行する事前検証について説明する。図5は、実施例2に係る事前検証を説明する図である。ここで実行される各処理は、例えばシステム管理者から検証開始を指示された場合に、処理を開始する。
【0050】
図5に示すように、事前検証装置10の通信インタフェースには、実動DBサーバ1b宛として使用されるIPアドレスと、クライアント端末1c宛として使用されるIPアドレスが設定されている。検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスが設定されている。
【0051】
つまり、検証APサーバ2aは、実動DBサーバ1b宛のパケットおよびクライアント端末1c宛のパケットを事前検証装置10に送信する。また、検証APサーバ2aは、実動DBサーバ1bを送信元とするパケットおよびクライアント端末1cを送信元とするパケットを事前検証装置10から受信する。
【0052】
このような状態において、クライアント擬似動作部17cは、実動キャプチャデータDB12に記憶される情報にしたがってクライアント端末1cの動作を擬似し、HTTP Reqを検証APサーバ2aに送信する。続いて、サーバ擬似動作部17bは、検証APサーバ2aからSQL Reqを受信した場合、実動キャプチャデータDB12に記憶される情報にしたがって実動DBサーバ1bを擬似し、SQL Resを検証APサーバ2aに応答する。
【0053】
その後、サーバ擬似動作部17bは、検証APサーバ2aからHTTP Resが送信されると、実動キャプチャデータDB12に記憶される情報にしたがってクライアント動作1cを擬似し、HTTP Resを受信する。このようにして、事前検証装置10は、実動環境が取得したパケットキャプチャデータにしたがって検証対象外装置の動作を擬似的に動作させることで、検証処理を実行する。
【0054】
[処理の流れ]
次に、図6と図7を用いて、図1に示したシステムで実行される処理の流れについて説明する。ここでは、事前検証装置10が実行するクライアント擬似動作とサーバ擬似動作のそれぞれについて説明する。
【0055】
(クライアント擬似動作)
図6は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。図6に示すように、クライアント擬似動作部17aは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定する(S101)。
【0056】
そして、クライアント擬似動作部17aは、全データの処理が終了していないと判定した場合(S101否定)、実動キャプチャデータDB12に送信待ちのデータが存在するか否かを判定する(S102)。
【0057】
その後、クライアント擬似動作部17aは、送信待ちのデータが存在すると判定した場合には(S102肯定)、クライアント端末の動作を擬似的に実行して、検証対象装置に対してパケットを送信する(S103)。つまり、クライアント擬似動作部17aは、検証環境に、実動環境と同様のトランザクションを発生させる。
【0058】
そして、クライアント擬似動作部17aは、検証対象装置に対してパケットを送信したことで、実動キャプチャデータDB12の全データに対して処理を実行した場合には(S101肯定)、処理を終了する。なお、S102において、クライアント擬似動作部17aは、実動キャプチャデータDB12に送信待ちのデータが存在しないと判定した場合には(S102否定)、S101以降の処理を繰り返す。
【0059】
(サーバ擬似動作)
図7は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。図7に示すように、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定する(S201)。
【0060】
そして、サーバ擬似動作部17bは、全データの処理が終了していないと判定した場合(S201否定)、S202以降の処理を実行する。すなわち、サーバ擬似動作部17bは、検証対象装置からパケットを受信した場合(S202肯定)、実動キャプチャデータDB12を参照し、受信したパケットの応答パケットを抽出する(S203)。
【0061】
続いて、サーバ擬似動作部17bは、抽出した応答パケットを検証対象装置に送信する(S204)。その後、サーバ擬似動作部17bは、S201以降の処理を繰り返す。なお、S202において、サーバ擬似動作部17bは、検証対象装置からパケットを受信するまでは、S201とS202を繰り返す。また、サーバ擬似動作部17bは、全データの処理が終了したと判定した場合(S201肯定)、処理を終了する。
【0062】
[実施例2による効果]
実施例2に係る事前検証装置10を用いることで、検証環境として、検証対象外の装置等を準備しなくても、検証対象装置を準備することで事前検証を実施できる。したがって、事前検証の環境構築の費用や人為的労力を従来に比べて大幅に軽減できる。
【0063】
例えば、DBサーバが検証対象外の場合、従来では、実動環境と検証環境においてのDB同期を行っていたが、事前検証装置10を用いることで、同期を行わずとも検証を実施できる。また、図1に示した実動環境以外の他システムで動作する外部サーバが存在する場合、従来は、検証対象の外部サーバとして、検証に用いるスタブ動作をするサーバおよびロジックを準備していた。これに対して、事前検証装置10は、実動環境の実キャプチャデータを用いるので、外部サーバとして筐体やアプリケーションを実装しなくても、実動環境の各装置の検証を容易に実施できる。
【実施例3】
【0064】
ところで、実施例2では、APサーバとDBサーバの2階層を有する実動環境のサーバを検証する例について説明したが、これに限定されるものではない。例えば、事前検証装置は、2階層以外の階層であっても同様に検証を実施することができる。そこで、実施例3では、一例として、Webサーバ、APサーバ、DBサーバの3階層を有する実動環境におけるWebサーバに対して検証を実行する例について説明する。
【0065】
[全体構成]
図8は、実施例3に係るシステムの全体構成の例を示す図である。図8は、実施例1と同様、事前検証装置10と検証環境とが接続されるとともに、事前検証装置10と実動環境とが接続されている。この検証Webサーバ2bには、検証Webサーバ2bが直接通信する検証対象外の装置である、実動APサーバ1aと実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスを設定しておく。
【0066】
実動環境は、実施例2等で説明した装置に加えて実動Webサーバ1eを有し、検証環境とは別のネットワークで形成される。実動Webサーバ1eは、HTML文書や画像などの情報を蓄積しておき、クライアント端末1cや実動APサーバ1aからの要求に応じて、画像等を表示させたWebページを応答する。
【0067】
検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。実施例3では、検証対象装置として検証Webサーバ2bが事前検証装置10と接続されている。
【0068】
事前検証装置10は、実施例2等と同様、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。この事前検証装置10は、実動環境における各装置がトランザクションを実行したことで発生したパケットをキャプチャリングする。そして、事前検証装置10は、キャプチャリングしたデータを使用して、検証Webサーバ2bを検証する。
【0069】
[検証処理]
図8に示した事前検証装置10は、図2と同様の構成を有するが、実施例2とは実動環境内の装置が異なることから、実動キャプチャデータDB12が記憶する内容が異なる。図9は、実施例3に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図9に示すように、実施例3に係る実動キャプチャデータDB12は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。なお、ここで記憶される各情報は、実施例2と同様なので、詳細な説明は省略する。
【0070】
実施例3に係る実動キャプチャデータと実施例2で説明した実動キャプチャデータとが異なる点は、実施例3に係る実動キャプチャデータは、実動Webサーバのパケットをキャプチャしている点である。具体的に、図9を用いて説明する。図9の例では、1番目に、クライアント端末1cから実動Webサーバ1eに送信されたHTTP Reqがキャプチャされたことを示す。2番目に、実動Webサーバ1eから実動APサーバ1aに送信されたIIOP(Internet Inter−ORB Protocol) Reqがキャプチャされたことを示す。
【0071】
さらに、3番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQL Reqがキャプチャされたことを示し、4番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQL Resがキャプチャされたことを示す。5番目に、実動APサーバ1aから実動Webサーバ1eに送信されたIIOP Resがキャプチャされ、6番目に、実動Webサーバ1eからクライアント端末1cに送信されたHTTP Resがキャプチャされたことを示す。
【0072】
次に、上述したDBを有する事前検証装置10が検証Webサーバ2bに検証を実行する例について説明する。図10は、実施例3に係る事前検証を説明する図である。図10に示すように、事前検証装置10のクライアント擬似動作部17aは、クライアント端末1cから実動Webサーバ1eへのHTTP Reqが送信待ちになると、実動キャプチャデータDB12を参照する。すると、クライアント擬似動作部17aは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=1」にしたがって、検証Webサーバ2bにHTTP Reqを送信する。
【0073】
続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=2」と同様の処理として、検証Webサーバ2bからIIOP Reqを受信する。すると、サーバ擬似動作部17bは実動キャプチャデータDB12に記憶される「シーケンシャル番号=5」にしたがって、実動Webサーバ2bにIIOP Resを送信する。
【0074】
ここで、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=3と4」についてはパケット送信を実行しない。つまり、サーバ擬似動作部17bは、実動APサーバ1aから実動DBサーバ1bへのSQL Req送信と、実動DBサーバ1bから実動APサーバ1aへのSQL Res受信を実行しない。このサーバ擬似動作部17bは、検証対象の検証Webサーバ2bに直接関わりがない処理については、暗に実動システムと同様の処理が内部でなされたとして、パケット送受信しない。
【0075】
その後、結果解析部17cは、サーバ擬似動作部17bが検証Webサーバ2bからクライアント端末1cへのHTTP Resを受信すると、検証環境での機能および性能解析検証を行い、検証試験結果を表示する。なお、結果解析部17cが実行する処理は、実施例2と同様なので、詳細な説明は省略する。
【0076】
[実施例3による効果]
このように、実施例3によれば、事前検証装置10は、実キャプチャデータにおいて、検証対象である装置が直接通信しない検証対象外の装置と関係する通信については、キャプチャデータで採取されていても、利用しないで検証を進めることができる。なお、事前検証装置10は、検証対象装置が関係する通信だけを実動環境でキャプチャし、検証対象装置が関係しない通信については、キャプチャしないようにすることもできる。このようにすることで、メモリやDBの容量増加も防止できる。
【実施例4】
【0077】
ところで、実施例1から実施例3では、事前検証装置10は、実動環境で取得したキャプチャデータを用いて検証を実行する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境で取得したキャプチャデータから、送受信されるパケットの対応表を生成し、この対応表を用いて検証を実行することもできる。そこで、実施例3では、事前検証装置10が生成する対応表の生成について説明する。
【0078】
(具体例1)
図11は、対応表生成例を示す図である。図11の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0079】
そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図11の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図11の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント2に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント1に送信したと特定できる。
【0080】
この結果、パケットキャプチャ部16は、図11の右図に示すように、「要求、応答」として「要求a、応答d」と「要求b、応答c」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【0081】
例えば、実動APサーバを検証する場合、クライアント擬似動作部17bは、クライアント端末の動作を擬似して、要求を検証APサーバに送信する。そして、サーバ擬似動作部17cは、検証APサーバから要求aを受信すると、要求aに対応する応答dを対応表から特定し、実動DBサーバの動作を擬似して応答dを実動APサーバに応答する。その後、サーバ擬似動作部17cは、応答dに対応する応答を実動APサーバから受信する。
【0082】
そして、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できた場合に、検証対象装置が正常動作していると判定する。一方、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できなかった場合に、検証対象装置が異常動作していると判定する。
【0083】
(具体例2)
図12は、対応表生成例を示す図である。図12の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0084】
そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図12の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図12の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント1に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント2に送信したと特定できる。
【0085】
この結果、パケットキャプチャ部16は、図12の右図に示すように、「要求、応答」として「要求a、応答c」と「要求b、応答d」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【0086】
(具体例3)
図13は、対応表生成例を示す図である。図13の左上図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0087】
そこで、パケットキャプチャ部16は、クライアント端末と実動APサーバと実動DBサーバとの間で、1多重で処理が実行されたときのシーケンスを利用する。つまり、パケットキャプチャ部16は、図13の左上図とは別にパケットキャプチャした情報として、図13の左下図に示すようなクライアント端末から実動APサーバに要求が送信されて、実動APサーバから実動DBサーバに要求aが送信された情報を取得する。さらに、パケットキャプチャ部16は、実動DBサーバから応答dが実動APサーバに送信されて、実動APサーバがクライアント端末に応答を返信した情報を取得する。
【0088】
そして、パケットキャプチャ部16は、図13の左下図に示したパケットキャプチャ情報から「要求a」と「応答d」とが対応していることを特定する。パケットキャプチャ部16は、この結果を図13の左上図と組み合わせて「要求a」と「応答d」とを除外することで、「要求b」と「応答c」とが対応することを特定する。
【0089】
この結果、パケットキャプチャ部16は、図13の右図に示すように、「要求、応答」として「要求a、応答d」と「要求b、応答c」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【実施例5】
【0090】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【0091】
(検証対象)
例えば、上述した実施例では、APサーバやWebサーバを検証する例について説明したが、これに限定されるものではなく、実動環境で動作する様々な装置を検証対象とすることができる。また、事前検証装置は、実動環境に流れる全てのパケットをキャプチャリングようにしてもよく、検証対象装置に関連するパケットだけをキャプチャリングするようにしてもよい。
【0092】
また、実施例1等では、事前検証装置10は、検証対象の装置から検証対象外の装置へのパケットを受信して、検証対象外の装置の動作を擬似する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境のパケットをキャプチャリングしておくことで、検証対象の装置から検証対象の他の装置へのパケットを受信して、検証対象の他の装置の動作を擬似することもできる。この場合、例えば、検証対象の装置には、検証対象の装置が直接通信する検証対象の他の装置のアドレスとして、事前検証装置10のIPアドレスを設定しておくことで、事前検証装置10は、検証対象の装置から検証対象の他の装置へのパケットを受信できる。
【0093】
(検証環境)
例えば、上述した実施例では、実動環境と検証環境とを別のネットワークで構築する例について説明したが、これに限定されるものではない。例えば、実動環境を用いて検証することもできる。その場合、図1のスイッチ1dに対して、事前検証装置と検証対象装置とが接続されるようにスイッチング情報の設定変更をしてもよく、事前検証装置と検証対象装置を実動環境上で直接接続するように、一時的にネットワークを変更してもよい。
【0094】
(インタフェース)
例えば、実施例2に係る事前検証装置10では、通信インタフェース11の第2ポートに実動DBサーバ1bと同じIPアドレスを設定し、第3ポートには、クライアント端末1cと同じIPアドレスを設定することで、通信を区別する例について説明した。ところが、通信の区別はこれに限定されるものではない。例えば、通信インタフェースそのものを複数用意してもよく、通信メッセージの特性から通信を区別することもできる。
【0095】
通信メッセージの特性から通信を区別する一例を挙げると、例えば、HTTP通信の場合にはクライアント端末の通信と判定し、SQL通信の場合にはDBサーバの通信と区別することができる。なお、上述した実施例で説明した各要求や応答はあくまで例示であり、これに限定されるものではない。
【0096】
(システム)
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図3、図9等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【0097】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0098】
(プログラム)
図14は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。図14に示すように、コンピュータ100は、CPU101、メモリ102、IF(Interface)103、Disk104を備えている。また、各構成部はバス100aによってそれぞれ接続されている。ここで、CPU101は、コンピュータ100の全体の制御を司る。メモリ102は、CPU101のワークエリアとして使用され、本メモリ内で検証試験プログラム102aが動作する。この検証試験プログラム102aが実行されることで、図2に示した各制御部と同様の処理を動作する検証試験プロセスが実行される。また、Disk104には、実動キャプチャデータ104aが記憶される。
【0099】
コンピュータ100の外部には、モニタ105として、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示し、マウス106により操作する。このモニタ105は、例えば、CRT(Cathode Ray Tube)、TFT(Thin Film Transistor)液晶ディスプレイ、プラズマディスプレイなどを採用することができる。IF103は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークに接続される。そして、IF103は、これらのネットワークを介して実動系システム、検証系システムを含む他の装置に接続される。また、IF103は、ネットワークと内部のインタフェースを司り、外部装置からのデータの入出力を制御する。IF103には、たとえばLANアダプタやモデムなどを採用することができる。
【符号の説明】
【0100】
10 事前検証装置
11 通信インタフェース
12 実動キャプチャデータDB
13 検証データDB
14 検証結果DB
15 制御部
16 パケットキャプチャ部
17 検証実施部
17a クライアント擬似動作部
17b サーバ擬似動作部
17c 結果解析部
【技術分野】
【0001】
本発明は、検証装置、検証方法および検証プログラムに関する。
【背景技術】
【0002】
Webサーバ、DB(Data Base)サーバ、クライアント装置などの装置を有するシステムでは、各装置に対して、パッチ適用、ファームウェア更新、ウィルス定義更新などの更新作業が実施されている。このような更新作業では、更新前と更新後とで異なる動作を実行しないか、すなわち、機能面または性能面で退化がないかが懸念される。
【0003】
このことから、従来では、サービスを提供している実動環境の装置に更新作業を実施する前に、検証用に準備した検証環境の装置で事前検証を行っている。一例を挙げると、装置間で送受信されるデータの送信間隔と同じタイミングでデータ送信を実行し、障害発生の再現テストを実施できる電文収録装置が開示されている。この電文収録装置は、検証に関係のないデータ送受信については短い電文間隔で高速送信して、効率的にシミュレーションを実行する。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2010−81194号公報
【特許文献2】特開2001−44993号公報
【特許文献3】特開2001−195270号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来の技術では、事前検証を容易に実施することができないという問題があった。
【0006】
例えば、複数装置が多階層に連携して動作するシステムなどでは、事前検証するための検証用システムとして、実動機と同じ装置構成の別システムを用意するなど、検証のために準備に時間やコストがかかる。
【0007】
一例を挙げると、Webサーバ、DBサーバ、クライアント装置のうちWebサーバに対して事前作業を行う場合であっても、DBサーバとクライアント装置を用意し、実動環境のシステムを同じシステムを構築した上で、事前検証を実行する。このように、事前検証のために用意する装置費用もかかり、また、検証用のシステムを構築する場所や時間もかかることから、事前検証を簡単に実行できない。
【0008】
1つの側面では、事前検証を容易に実行できる検証装置、検証方法および検証プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
第1の案では、検証装置は、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部を有する。検証装置は、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部を有する。検証装置は、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部を有する。
【発明の効果】
【0010】
事前検証を容易に実行できる。
【図面の簡単な説明】
【0011】
【図1】図1は、実施例1に係るシステムの全体構成の例を示す図である。
【図2】図2は、実施例2に係る事前検証装置の構成を示すブロック図である。
【図3】図3は、実施例2に係る実動キャプチャデータDBに記憶される情報の例を示す図である。
【図4】図4は、検証データDBに記憶される情報の例を示す図である。
【図5】図5は、実施例2に係る事前検証を説明する図である。
【図6】図6は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。
【図7】図7は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。
【図8】図8は、実施例3に係るシステムの全体構成の例を示す図である。
【図9】図9は、実施例3に係る実動キャプチャデータDBに記憶される情報の例を示す図である。
【図10】図10は、実施例3に係る事前検証を説明する図である。
【図11】図11は、対応表生成例を示す図である。
【図12】図12は、対応表生成例を示す図である。
【図13】図13は、対応表生成例を示す図である。
【図14】図14は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【0012】
以下に、本願の開示する検証装置、検証方法および検証プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例1】
【0013】
図1は、実施例1に係るシステムの全体構成の例を示す図である。図1に示すように、このシステムは、事前検証装置10が実動環境と検証環境との各々に接続されている。実動環境は、クライアントに対してWebサービス等の各種サービスを提供するシステムである。検証環境は、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するためのシステムである。
【0014】
実動環境は、実動AP(Application)サーバ1aと実動DB(Data Base)サーバ1bとクライアント端末1cとスイッチ1dとを有し、検証環境とは別のネットワークで形成される。実動APサーバ1aは、クライアント端末1cから要求を受信して、実動DBサーバ1bへのトランザクションを実行するサーバであり、HTML文書などを蓄積してWebサービスを提供するWebアプリケーションサーバとしての機能を有していてもよい。
【0015】
例えば、実動APサーバ1aは、クライアント端末1cから受信した要求に対応したアプリケーションを実行して、実動DBサーバ1bへリクエストを送信する。そして、実動APサーバ1aは、当該リクエストに対するレスポンスを実動DBサーバ1bから受信して、クライアント端末1cに送信する。
【0016】
実動DBサーバ1bは、データベースを有し、実動APサーバ1aから受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動APサーバ1aに送信する。なお、実動DBサーバ1bが有するデータベースは、関係データベース、オブジェクトデータベース、KVS(キーバリューストア)など様々なデータベースを利用できる。
【0017】
クライアント端末1cは、Webブラウザ等を用いて実動APサーバ1aにアクセスして各サービスを利用するコンピュータであり、例えば実動APサーバ1aを介して実動DBサーバ1bが保持するデータベースを更新したりする。
【0018】
スイッチ1dは、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ1dとしては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ1dは、ポートミラーリングを実行しており、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々から受信したデータを事前検証装置10に送信する。
【0019】
検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、APサーバだけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、事前検証装置10は、APサーバと同様の機能を有する検証APサーバに対して検証を実行する。
【0020】
ここでは、一例として、実動APサーバ1aを検証することとするので、検証環境は検証APサーバ2aを有するものとする。検証APサーバ2aは、実動APサーバ1aと同様の機能を実装した検証対象のサーバであり、事前検証装置10と接続される。この検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1c各々のアドレスとして、事前検証装置10のIP(Internet Protocol)アドレスを設定しておく。
【0021】
検証APサーバ2aは、実動環境の実動APサーバ1aが処理する実トランザクションと同様のトランザクションを実行して、データを事前検証装置10に送信する。また、検証APサーバ2aは、事前検証装置10からパケットを受信した場合に、当該データに対応する応答データを事前検証装置10に送信する。
【0022】
事前検証装置10は、保持部10aと受信部10bと応答部10cとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。
【0023】
保持部10aは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部10aは、スイッチ1dのポートミラーリングによって受信したデータを保持する。
【0024】
受信部10bは、検証対象である検証APサーバ2aから他の装置である実動環境の他装置へ送信されたデータを受信する。応答部10cは、受信部10bによって受信されたデータの応答として実動システムで送信されたデータを保持部10aが保持するキャプチャデータから特定し、特定したデータを検証対象の検証APサーバ2aに応答する。
【0025】
このように、事前検証装置10は、実動環境で使用されたトランザクションによって発生したデータや、データの送受信シーケンスを記憶することで、検証対象サーバ以外のサーバ動作を擬似的に動作することができる。したがって、事前検証を実施するのに際して、実動環境と同じ環境を用意することなく、検証対象装置だけを準備すれば事前検証を実行することができる。したがって、事前検証を容易に実行できる。
【実施例2】
【0026】
次に、図1に事前検証装置の具体的な構成等を実施例2として説明する。なお、実動APサーバ1aや検証APサーバ2aは、一般的なAPサーバと同様の機能を有し、実動DBサーバ1bは、一般的なDBサーバと同様の機能を有し、クライアント端末は、一般的なコンピュータと同様の機能を有するので、詳細な説明は省略する。ここでは、事前検証装置の構成、処理の流れ、効果等について説明する。
【0027】
[事前検証装置の構成]
図2は、実施例2に係る事前検証装置の構成を示すブロック図である。図2に示すように、事前検証装置10は、通信インタフェース11、実動キャプチャデータDB12、検証データDB13、検証結果DB14、制御部15を有する。
【0028】
通信インタフェース11は、少なくとも1つのポートを有し、事前検証装置10と検証APサーバ2aとの間の通信を制御する。また、通信インタフェース11は、事前検証装置10とスイッチ1dとの間の通信も制御する。
【0029】
この通信インタフェースの各ポートには、実動環境で使用するIP(Internet Protocol)アドレスと、検証対象外装置のIPアドレスが設定される。図1の場合、通信インタフェースの第1ポートには、実動環境用のIPアドレスが設定される。そして、通信インタフェースの第2ポートには、実動DBサーバ1b宛として使用されるIPアドレスが設定される。さらに、通信インタフェースの第3ポートには、クライアント端末1c宛として使用されるIPアドレスが設定される。
【0030】
実動キャプチャデータDB12は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持する。すなわち、実動キャプチャデータDB12は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。実動キャプチャデータDB12には、後述するパケットキャプチャ部16によって、1日や1週間など所定間隔でキャプチャされたキャプチャデータが格納される。
【0031】
図3は、実施例2に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図3に示すように、実動キャプチャデータDB12は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。
【0032】
ここで記憶される「シーケンシャル番号」は、パケットキャプチャリングされた順番を示し、「送信元」は、キャプチャされたパケットの送信元を示す。「送信先」は、キャプチャされたパケットの送信先を示し、「パケット」は、キャプチャされたパケットの情報を示す。なお、実動キャプチャデータ12は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。
【0033】
図3の例の場合、1番目に、クライアント端末1cから実動APサーバ1aに送信されたHTTP Reqがキャプチャされ、2番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQL Reqがキャプチャされたことを示す。さらに、3番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQL Resがキャプチャされたことを示し、4番目に、実動APサーバ1aからクライアント端末1cに送信されたHTTP Resがキャプチャされたことを示す。なお、Reqは、Requestの略であり、Resは、Responseの略である。
【0034】
検証データDB13は、後述する検証実施部17が検証を実施して得られた検証データであり、検証実施部17が検証環境で送受信されるパケットをキャプチャしたデータを記憶する。ここで記憶される情報は検証実施部17によって格納される。図4は、検証データDBに記憶される情報の例を示す図である。図4に示すように、検証データDB13は、「検証対象装置、シーケンシャル番号、送信パケット、受信パケット」を対応付けて記憶する。
【0035】
ここで記憶される「検証対象装置」は、検証が実施された装置の名称やIPアドレスなどであり、「シーケンシャル番号」は、検証によってパケットが送受信された順番である。「送信パケット」は、検証の際に送信されたパケットの情報であり、「受信パケット」は、検証で受信されたパケットの情報である。図4の例の場合、APサーバに対して実行した検証では、1番目にHTTP Reqが送信され、2番目にSQL Reqが受信され、3番目にSQL Resが送信され、4番目にHTTP Resが受信されたことを示す。
【0036】
検証結果DB14は、後述する検証実施部17によって得られた検証結果を記憶する。例えば、検証結果DB14は、検証された日時を示す「検証日時」、検証された装置を示す「検証対象装置」、正常または異常など検証結果を示す「検証結果」を対応付けて記憶する。
【0037】
制御部15は、パケットキャプチャ部16と検証実施部17とを有し、パケットキャプチャや検証試験を実施する。なお、制御部15は、CPU(Central Processing Unit)などの電子回路やFPGA(Field-Programmable Gate Array)などの集積回路等である。
【0038】
パケットキャプチャ部16は、スイッチ1dを介して、実動環境で実際に送受信されたパケットをキャプチャして、実動キャプチャデータDB12に格納する。例えば、クライアント端末1cが、実動APサーバ1aにアクセスしてアプリケーションを実行し、実動APサーバ1aが、アプリケーションの実行によって実動DBサーバ1bに対してDBアクセスを実行したとする。
【0039】
この場合、はじめに、パケットキャプチャ部16は、クライアント端末1cから実動APサーバ1aへのDB処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部16は、実動APサーバ1aから実動DBサーバ1bへ送信されたDBリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部16は、実動DBサーバ1bから実動APサーバ1aへ送信されたDBレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部16は、実動APサーバ1aからクライアント端末1cへ送信されたDB処理要求に対する応答を示すパケットをキャプチャする。
【0040】
つまり、パケットキャプチャ部16は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、実動キャプチャデータ12に格納する。なお、パケットキャプチャ部16は、キャプチャしたパケットそのものを実動キャプチャデータDB12に格納してもよい。
【0041】
検証実施部17は、クライアント擬似動作部17aとサーバ擬似動作部17bと結果解析部17cとを有し、これらによって検証対象装置に検証を実行する。クライアント擬似動作部17aは、実動キャプチャデータDB12に保持されるキャプチャデータに、検証対象の装置を宛先とする送信待ちのパケットが存在する場合に、当該パケットを検証対象の装置に送信する。
【0042】
例えば、クライアント擬似動作部17aは、システム管理者等によって検証開始が指示されると、実動キャプチャデータDB12を参照する。そして、クライアント擬似動作部17aは、検証処理がクライアント端末からのパケット送信である場合には、実動キャプチャデータDB12にしたがって、該当するパケットを生成して検証対象装置に送信する。
【0043】
一例を挙げると、クライアント擬似動作部17aは、図3に示した実動キャプチャデータDB12を参照し、シーケンシャル番号=1の処理がクライアント端末1cから実動APサーバ1aへのパケット送信であることを特定する。この結果、クライアント擬似動作部17aは、特定したパケットであるHTTP Reqを検証APサーバ2aに送信する。つまり、クライアント擬似動作部17aは、検証APサーバ2aに実トランザクションと同様の処理を実行させるために、クライアント端末1cの動作を擬似的に実行する。また、クライアント擬似動作部17aは、送信したパケット(HTTP Req)にシーケンシャル番号=1を割り与えて、これらを対応付けて検証データDB13に格納する。
【0044】
サーバ擬似動作部17bは、検証対象の装置から検証対象外の装置へ送信されたパケットを受信する。そして、サーバ擬似動作部17bは、受信されたパケットの応答として実動システムで送信されたパケットを実動キャプチャデータDB12が保持するキャプチャデータから特定し、特定したパケットを検証対象の装置に応答する。
【0045】
例えば、サーバ擬似動作部17bは、クライアント擬似動作部17aからHTTP Reqを受信した検証APサーバ2aが実トランザクションと同様のトランザクションを実行して、実動DBサーバ1bに送信したSQL Reqを受信する。続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、SQL Reqの次に、実動DBサーバ1bから実動APサーバ1aにSQL Resが送信されていることを特定する。そして、サーバ擬似動作部17bは、SQL Resを検証APサーバ2aに送信する。
【0046】
このように、事前検証装置10と検証APサーバ2aとの2台で、実動環境と同様のトランザクションで同様の処理を実行する。つまり、事前検証装置10は、検証環境に存在しない実動DBサーバ1bの動作を擬似的に実行する。また、サーバ擬似動作部17bは、受信したパケット(SQL Req)にシーケンシャル番号=2を割り与えて検証データDB13に格納する。同様に、サーバ擬似動作部17bは、送信したパケット(SQL Res)にシーケンシャル番号=3を割り与えて検証データDB13に格納する。
【0047】
結果解析部17cは、クライアント擬似動作部17aやサーバ擬似動作部17bによって実行された検証結果を解析する。そして、結果解析部17cは、検証結果をディスプレイ等に表示させたり、メールで管理者等に送信したりする。
【0048】
例えば、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とを比較して、一致している場合には、検証処理に異常がないと判定する。一方、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とが一致していない場合には、検証処理に異常があると判定する。この場合、結果解析部17cは、一致していない箇所を特定し、特定した箇所を管理者に通知したりする。
【0049】
[事前検証の具体例]
次に、事前検証装置10の検証実施部17が実行する事前検証について説明する。図5は、実施例2に係る事前検証を説明する図である。ここで実行される各処理は、例えばシステム管理者から検証開始を指示された場合に、処理を開始する。
【0050】
図5に示すように、事前検証装置10の通信インタフェースには、実動DBサーバ1b宛として使用されるIPアドレスと、クライアント端末1c宛として使用されるIPアドレスが設定されている。検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスが設定されている。
【0051】
つまり、検証APサーバ2aは、実動DBサーバ1b宛のパケットおよびクライアント端末1c宛のパケットを事前検証装置10に送信する。また、検証APサーバ2aは、実動DBサーバ1bを送信元とするパケットおよびクライアント端末1cを送信元とするパケットを事前検証装置10から受信する。
【0052】
このような状態において、クライアント擬似動作部17cは、実動キャプチャデータDB12に記憶される情報にしたがってクライアント端末1cの動作を擬似し、HTTP Reqを検証APサーバ2aに送信する。続いて、サーバ擬似動作部17bは、検証APサーバ2aからSQL Reqを受信した場合、実動キャプチャデータDB12に記憶される情報にしたがって実動DBサーバ1bを擬似し、SQL Resを検証APサーバ2aに応答する。
【0053】
その後、サーバ擬似動作部17bは、検証APサーバ2aからHTTP Resが送信されると、実動キャプチャデータDB12に記憶される情報にしたがってクライアント動作1cを擬似し、HTTP Resを受信する。このようにして、事前検証装置10は、実動環境が取得したパケットキャプチャデータにしたがって検証対象外装置の動作を擬似的に動作させることで、検証処理を実行する。
【0054】
[処理の流れ]
次に、図6と図7を用いて、図1に示したシステムで実行される処理の流れについて説明する。ここでは、事前検証装置10が実行するクライアント擬似動作とサーバ擬似動作のそれぞれについて説明する。
【0055】
(クライアント擬似動作)
図6は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。図6に示すように、クライアント擬似動作部17aは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定する(S101)。
【0056】
そして、クライアント擬似動作部17aは、全データの処理が終了していないと判定した場合(S101否定)、実動キャプチャデータDB12に送信待ちのデータが存在するか否かを判定する(S102)。
【0057】
その後、クライアント擬似動作部17aは、送信待ちのデータが存在すると判定した場合には(S102肯定)、クライアント端末の動作を擬似的に実行して、検証対象装置に対してパケットを送信する(S103)。つまり、クライアント擬似動作部17aは、検証環境に、実動環境と同様のトランザクションを発生させる。
【0058】
そして、クライアント擬似動作部17aは、検証対象装置に対してパケットを送信したことで、実動キャプチャデータDB12の全データに対して処理を実行した場合には(S101肯定)、処理を終了する。なお、S102において、クライアント擬似動作部17aは、実動キャプチャデータDB12に送信待ちのデータが存在しないと判定した場合には(S102否定)、S101以降の処理を繰り返す。
【0059】
(サーバ擬似動作)
図7は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。図7に示すように、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定する(S201)。
【0060】
そして、サーバ擬似動作部17bは、全データの処理が終了していないと判定した場合(S201否定)、S202以降の処理を実行する。すなわち、サーバ擬似動作部17bは、検証対象装置からパケットを受信した場合(S202肯定)、実動キャプチャデータDB12を参照し、受信したパケットの応答パケットを抽出する(S203)。
【0061】
続いて、サーバ擬似動作部17bは、抽出した応答パケットを検証対象装置に送信する(S204)。その後、サーバ擬似動作部17bは、S201以降の処理を繰り返す。なお、S202において、サーバ擬似動作部17bは、検証対象装置からパケットを受信するまでは、S201とS202を繰り返す。また、サーバ擬似動作部17bは、全データの処理が終了したと判定した場合(S201肯定)、処理を終了する。
【0062】
[実施例2による効果]
実施例2に係る事前検証装置10を用いることで、検証環境として、検証対象外の装置等を準備しなくても、検証対象装置を準備することで事前検証を実施できる。したがって、事前検証の環境構築の費用や人為的労力を従来に比べて大幅に軽減できる。
【0063】
例えば、DBサーバが検証対象外の場合、従来では、実動環境と検証環境においてのDB同期を行っていたが、事前検証装置10を用いることで、同期を行わずとも検証を実施できる。また、図1に示した実動環境以外の他システムで動作する外部サーバが存在する場合、従来は、検証対象の外部サーバとして、検証に用いるスタブ動作をするサーバおよびロジックを準備していた。これに対して、事前検証装置10は、実動環境の実キャプチャデータを用いるので、外部サーバとして筐体やアプリケーションを実装しなくても、実動環境の各装置の検証を容易に実施できる。
【実施例3】
【0064】
ところで、実施例2では、APサーバとDBサーバの2階層を有する実動環境のサーバを検証する例について説明したが、これに限定されるものではない。例えば、事前検証装置は、2階層以外の階層であっても同様に検証を実施することができる。そこで、実施例3では、一例として、Webサーバ、APサーバ、DBサーバの3階層を有する実動環境におけるWebサーバに対して検証を実行する例について説明する。
【0065】
[全体構成]
図8は、実施例3に係るシステムの全体構成の例を示す図である。図8は、実施例1と同様、事前検証装置10と検証環境とが接続されるとともに、事前検証装置10と実動環境とが接続されている。この検証Webサーバ2bには、検証Webサーバ2bが直接通信する検証対象外の装置である、実動APサーバ1aと実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスを設定しておく。
【0066】
実動環境は、実施例2等で説明した装置に加えて実動Webサーバ1eを有し、検証環境とは別のネットワークで形成される。実動Webサーバ1eは、HTML文書や画像などの情報を蓄積しておき、クライアント端末1cや実動APサーバ1aからの要求に応じて、画像等を表示させたWebページを応答する。
【0067】
検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。実施例3では、検証対象装置として検証Webサーバ2bが事前検証装置10と接続されている。
【0068】
事前検証装置10は、実施例2等と同様、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。この事前検証装置10は、実動環境における各装置がトランザクションを実行したことで発生したパケットをキャプチャリングする。そして、事前検証装置10は、キャプチャリングしたデータを使用して、検証Webサーバ2bを検証する。
【0069】
[検証処理]
図8に示した事前検証装置10は、図2と同様の構成を有するが、実施例2とは実動環境内の装置が異なることから、実動キャプチャデータDB12が記憶する内容が異なる。図9は、実施例3に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図9に示すように、実施例3に係る実動キャプチャデータDB12は、「シーケンシャル番号、送信元、送信先、パケット」を対応付けて記憶する。なお、ここで記憶される各情報は、実施例2と同様なので、詳細な説明は省略する。
【0070】
実施例3に係る実動キャプチャデータと実施例2で説明した実動キャプチャデータとが異なる点は、実施例3に係る実動キャプチャデータは、実動Webサーバのパケットをキャプチャしている点である。具体的に、図9を用いて説明する。図9の例では、1番目に、クライアント端末1cから実動Webサーバ1eに送信されたHTTP Reqがキャプチャされたことを示す。2番目に、実動Webサーバ1eから実動APサーバ1aに送信されたIIOP(Internet Inter−ORB Protocol) Reqがキャプチャされたことを示す。
【0071】
さらに、3番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQL Reqがキャプチャされたことを示し、4番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQL Resがキャプチャされたことを示す。5番目に、実動APサーバ1aから実動Webサーバ1eに送信されたIIOP Resがキャプチャされ、6番目に、実動Webサーバ1eからクライアント端末1cに送信されたHTTP Resがキャプチャされたことを示す。
【0072】
次に、上述したDBを有する事前検証装置10が検証Webサーバ2bに検証を実行する例について説明する。図10は、実施例3に係る事前検証を説明する図である。図10に示すように、事前検証装置10のクライアント擬似動作部17aは、クライアント端末1cから実動Webサーバ1eへのHTTP Reqが送信待ちになると、実動キャプチャデータDB12を参照する。すると、クライアント擬似動作部17aは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=1」にしたがって、検証Webサーバ2bにHTTP Reqを送信する。
【0073】
続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=2」と同様の処理として、検証Webサーバ2bからIIOP Reqを受信する。すると、サーバ擬似動作部17bは実動キャプチャデータDB12に記憶される「シーケンシャル番号=5」にしたがって、実動Webサーバ2bにIIOP Resを送信する。
【0074】
ここで、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶される「シーケンシャル番号=3と4」についてはパケット送信を実行しない。つまり、サーバ擬似動作部17bは、実動APサーバ1aから実動DBサーバ1bへのSQL Req送信と、実動DBサーバ1bから実動APサーバ1aへのSQL Res受信を実行しない。このサーバ擬似動作部17bは、検証対象の検証Webサーバ2bに直接関わりがない処理については、暗に実動システムと同様の処理が内部でなされたとして、パケット送受信しない。
【0075】
その後、結果解析部17cは、サーバ擬似動作部17bが検証Webサーバ2bからクライアント端末1cへのHTTP Resを受信すると、検証環境での機能および性能解析検証を行い、検証試験結果を表示する。なお、結果解析部17cが実行する処理は、実施例2と同様なので、詳細な説明は省略する。
【0076】
[実施例3による効果]
このように、実施例3によれば、事前検証装置10は、実キャプチャデータにおいて、検証対象である装置が直接通信しない検証対象外の装置と関係する通信については、キャプチャデータで採取されていても、利用しないで検証を進めることができる。なお、事前検証装置10は、検証対象装置が関係する通信だけを実動環境でキャプチャし、検証対象装置が関係しない通信については、キャプチャしないようにすることもできる。このようにすることで、メモリやDBの容量増加も防止できる。
【実施例4】
【0077】
ところで、実施例1から実施例3では、事前検証装置10は、実動環境で取得したキャプチャデータを用いて検証を実行する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境で取得したキャプチャデータから、送受信されるパケットの対応表を生成し、この対応表を用いて検証を実行することもできる。そこで、実施例3では、事前検証装置10が生成する対応表の生成について説明する。
【0078】
(具体例1)
図11は、対応表生成例を示す図である。図11の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0079】
そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図11の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図11の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント2に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント1に送信したと特定できる。
【0080】
この結果、パケットキャプチャ部16は、図11の右図に示すように、「要求、応答」として「要求a、応答d」と「要求b、応答c」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【0081】
例えば、実動APサーバを検証する場合、クライアント擬似動作部17bは、クライアント端末の動作を擬似して、要求を検証APサーバに送信する。そして、サーバ擬似動作部17cは、検証APサーバから要求aを受信すると、要求aに対応する応答dを対応表から特定し、実動DBサーバの動作を擬似して応答dを実動APサーバに応答する。その後、サーバ擬似動作部17cは、応答dに対応する応答を実動APサーバから受信する。
【0082】
そして、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できた場合に、検証対象装置が正常動作していると判定する。一方、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できなかった場合に、検証対象装置が異常動作していると判定する。
【0083】
(具体例2)
図12は、対応表生成例を示す図である。図12の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0084】
そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図12の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図12の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント1に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント2に送信したと特定できる。
【0085】
この結果、パケットキャプチャ部16は、図12の右図に示すように、「要求、応答」として「要求a、応答c」と「要求b、応答d」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【0086】
(具体例3)
図13は、対応表生成例を示す図である。図13の左上図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。
【0087】
そこで、パケットキャプチャ部16は、クライアント端末と実動APサーバと実動DBサーバとの間で、1多重で処理が実行されたときのシーケンスを利用する。つまり、パケットキャプチャ部16は、図13の左上図とは別にパケットキャプチャした情報として、図13の左下図に示すようなクライアント端末から実動APサーバに要求が送信されて、実動APサーバから実動DBサーバに要求aが送信された情報を取得する。さらに、パケットキャプチャ部16は、実動DBサーバから応答dが実動APサーバに送信されて、実動APサーバがクライアント端末に応答を返信した情報を取得する。
【0088】
そして、パケットキャプチャ部16は、図13の左下図に示したパケットキャプチャ情報から「要求a」と「応答d」とが対応していることを特定する。パケットキャプチャ部16は、この結果を図13の左上図と組み合わせて「要求a」と「応答d」とを除外することで、「要求b」と「応答c」とが対応することを特定する。
【0089】
この結果、パケットキャプチャ部16は、図13の右図に示すように、「要求、応答」として「要求a、応答d」と「要求b、応答c」と対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。
【実施例5】
【0090】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【0091】
(検証対象)
例えば、上述した実施例では、APサーバやWebサーバを検証する例について説明したが、これに限定されるものではなく、実動環境で動作する様々な装置を検証対象とすることができる。また、事前検証装置は、実動環境に流れる全てのパケットをキャプチャリングようにしてもよく、検証対象装置に関連するパケットだけをキャプチャリングするようにしてもよい。
【0092】
また、実施例1等では、事前検証装置10は、検証対象の装置から検証対象外の装置へのパケットを受信して、検証対象外の装置の動作を擬似する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境のパケットをキャプチャリングしておくことで、検証対象の装置から検証対象の他の装置へのパケットを受信して、検証対象の他の装置の動作を擬似することもできる。この場合、例えば、検証対象の装置には、検証対象の装置が直接通信する検証対象の他の装置のアドレスとして、事前検証装置10のIPアドレスを設定しておくことで、事前検証装置10は、検証対象の装置から検証対象の他の装置へのパケットを受信できる。
【0093】
(検証環境)
例えば、上述した実施例では、実動環境と検証環境とを別のネットワークで構築する例について説明したが、これに限定されるものではない。例えば、実動環境を用いて検証することもできる。その場合、図1のスイッチ1dに対して、事前検証装置と検証対象装置とが接続されるようにスイッチング情報の設定変更をしてもよく、事前検証装置と検証対象装置を実動環境上で直接接続するように、一時的にネットワークを変更してもよい。
【0094】
(インタフェース)
例えば、実施例2に係る事前検証装置10では、通信インタフェース11の第2ポートに実動DBサーバ1bと同じIPアドレスを設定し、第3ポートには、クライアント端末1cと同じIPアドレスを設定することで、通信を区別する例について説明した。ところが、通信の区別はこれに限定されるものではない。例えば、通信インタフェースそのものを複数用意してもよく、通信メッセージの特性から通信を区別することもできる。
【0095】
通信メッセージの特性から通信を区別する一例を挙げると、例えば、HTTP通信の場合にはクライアント端末の通信と判定し、SQL通信の場合にはDBサーバの通信と区別することができる。なお、上述した実施例で説明した各要求や応答はあくまで例示であり、これに限定されるものではない。
【0096】
(システム)
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図3、図9等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【0097】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0098】
(プログラム)
図14は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。図14に示すように、コンピュータ100は、CPU101、メモリ102、IF(Interface)103、Disk104を備えている。また、各構成部はバス100aによってそれぞれ接続されている。ここで、CPU101は、コンピュータ100の全体の制御を司る。メモリ102は、CPU101のワークエリアとして使用され、本メモリ内で検証試験プログラム102aが動作する。この検証試験プログラム102aが実行されることで、図2に示した各制御部と同様の処理を動作する検証試験プロセスが実行される。また、Disk104には、実動キャプチャデータ104aが記憶される。
【0099】
コンピュータ100の外部には、モニタ105として、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示し、マウス106により操作する。このモニタ105は、例えば、CRT(Cathode Ray Tube)、TFT(Thin Film Transistor)液晶ディスプレイ、プラズマディスプレイなどを採用することができる。IF103は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークに接続される。そして、IF103は、これらのネットワークを介して実動系システム、検証系システムを含む他の装置に接続される。また、IF103は、ネットワークと内部のインタフェースを司り、外部装置からのデータの入出力を制御する。IF103には、たとえばLANアダプタやモデムなどを採用することができる。
【符号の説明】
【0100】
10 事前検証装置
11 通信インタフェース
12 実動キャプチャデータDB
13 検証データDB
14 検証結果DB
15 制御部
16 パケットキャプチャ部
17 検証実施部
17a クライアント擬似動作部
17b サーバ擬似動作部
17c 結果解析部
【特許請求の範囲】
【請求項1】
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部と、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部と、
前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部と
を有することを特徴とする検証装置。
【請求項2】
前記保持部に保持されるキャプチャデータに、前記検証対象の第1の情報処理装置を宛先とする送信待ちのデータが存在する場合に、当該データを前記検証対象の第1の情報処理装置に送信する送信部をさらに有することを特徴とする請求項1に記載の検証装置。
【請求項3】
前記保持部に記憶されるキャプチャデータから、前記情報処理装置に処理を要求する際に送信された要求データと、当該要求データの応答として送信された応答データとの対応関係を生成する生成部をさらに有し、
前記応答部は、前記生成部によって生成された対応関係に基づいて、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを特定することを特徴とする請求項1または2に記載の検証装置。
【請求項4】
前記生成部は、前記保持部に記憶されるキャプチャデータのうち、前記情報処理装置が関連する処理が1多重で実行された際に取得されたキャプチャデータから、前記要求データと応答データとの対応関係を生成することを特徴とする請求項3に記載の検証装置。
【請求項5】
前記生成部は、第1の情報処理装置と第2の情報処理装置との間における前記対応関係を生成する場合に、第3の情報処理装置が前記第1の情報処理装置または第2の情報処理の少なくとも1つの装置に送信した要求データまたは前記第3の情報処理装置が前記第1の情報処理装置または第2の情報処理装置の少なくとも1つの装置から受信した応答データとを用いて、前記第1の情報処理装置と第2の情報処理装置との間における要求データと応答データとを特定することを特徴とする請求項3に記載の検証装置。
【請求項6】
コンピュータが、
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、
受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する
処理を実行することを特徴とする検証方法。
【請求項7】
コンピュータに、
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、
受信したデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する
処理を実行させることを特徴とする検証プログラム。
【請求項1】
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部と、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部と、
前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部と
を有することを特徴とする検証装置。
【請求項2】
前記保持部に保持されるキャプチャデータに、前記検証対象の第1の情報処理装置を宛先とする送信待ちのデータが存在する場合に、当該データを前記検証対象の第1の情報処理装置に送信する送信部をさらに有することを特徴とする請求項1に記載の検証装置。
【請求項3】
前記保持部に記憶されるキャプチャデータから、前記情報処理装置に処理を要求する際に送信された要求データと、当該要求データの応答として送信された応答データとの対応関係を生成する生成部をさらに有し、
前記応答部は、前記生成部によって生成された対応関係に基づいて、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを特定することを特徴とする請求項1または2に記載の検証装置。
【請求項4】
前記生成部は、前記保持部に記憶されるキャプチャデータのうち、前記情報処理装置が関連する処理が1多重で実行された際に取得されたキャプチャデータから、前記要求データと応答データとの対応関係を生成することを特徴とする請求項3に記載の検証装置。
【請求項5】
前記生成部は、第1の情報処理装置と第2の情報処理装置との間における前記対応関係を生成する場合に、第3の情報処理装置が前記第1の情報処理装置または第2の情報処理の少なくとも1つの装置に送信した要求データまたは前記第3の情報処理装置が前記第1の情報処理装置または第2の情報処理装置の少なくとも1つの装置から受信した応答データとを用いて、前記第1の情報処理装置と第2の情報処理装置との間における要求データと応答データとを特定することを特徴とする請求項3に記載の検証装置。
【請求項6】
コンピュータが、
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、
受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する
処理を実行することを特徴とする検証方法。
【請求項7】
コンピュータに、
複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、
検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、
受信したデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する
処理を実行させることを特徴とする検証プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【公開番号】特開2012−195699(P2012−195699A)
【公開日】平成24年10月11日(2012.10.11)
【国際特許分類】
【出願番号】特願2011−57266(P2011−57266)
【出願日】平成23年3月15日(2011.3.15)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成24年10月11日(2012.10.11)
【国際特許分類】
【出願日】平成23年3月15日(2011.3.15)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]