(57)【要約】    【課題】  複数のサーバなどの装置が協調して動作するシステムに新たに追加された装置のリリース制御を行う。    【解決手段】  複数のサーバを有し、互いに電文を送受信しながら協調して動作する電文処理システムが稼動しているときに、新たに追加されたサーバのリリース管理をする管理サーバ１５は、追加されたサーバをリリースするための条件が登録されているリリース条件表１８２と、追加されたサーバの状態を示す情報が登録されているステータス表１８３と、リリース条件表１８２及びステータス表１８３を参照し、追加サーバがリリース可能な状態であり、且つ、追加サーバをリリースするための条件が満たされている場合は、追加装置をリリースするリリース管理部１８１とを備える。    【選択図】  図５
2006252159.tif 000002
【特許請求の範囲】
【請求項１】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システムが稼動しているときに、前記電文処理システムに追加された追加装置をリリースするための管理装置であって、
前記追加装置をリリースするための条件が登録されている条件記憶部と、
前記追加装置の状態を示す情報が記憶されている状態記憶部と、
前記条件記憶部及び前記状態記憶部を参照し、前記追加装置がリリース可能な状態であり、且つ、前記追加装置をリリースするための条件が満たされている場合は、前記追加装置をリリースするリリース制御部と、を備えることを特徴とする管理装置。
【請求項２】
前記追加装置の状態を照会し、前記状態記憶部を更新する手段と、
前記追加装置をリリースするための条件の入力を受け付ける入力手段とをさらに備えることを特徴とする請求項１記載の管理装置。
【請求項３】
前記複数の装置は、複数のグループにグループ分けされていて、
前記追加装置をリリースするための、グループ別のリリースコマンドを記憶した記憶手段をさらに備え、
前記リリース制御部は、前記追加装置が属するグループに応じたリリースコマンドを前記記憶手段から取得して、前記追加装置をリリースすることを特徴とする請求項１又は請求項２に記載の管理装置。
【請求項４】
前記追加装置のテストを実行するテスト手段と、
前記テスト手段によるテスト結果が正常である場合、前記追加装置の状態をリリース可能な状態にするステータス更新手段と、をさらに備えることを特徴とする請求項１乃至請求項３のいずれか一項に記載の管理装置。
【請求項５】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システムが稼動しているときに、前記電文処理システムに追加された追加装置をリリースするためのリリース制御方法であって、
前記追加装置をリリースするための条件を条件記憶部に登録するステップと、
前記追加装置の状態を示す情報を状態記憶部に登録するステップと、
前記条件記憶部及び前記状態記憶部を参照し、前記追加装置がリリース可能な状態であり、且つ、前記追加装置をリリースするための条件が満たされている場合は、前記追加装置をリリースするステップと、を有することを特徴とする方法。
【請求項６】
複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システムが稼動しているときに、前記電文処理システムに追加された追加装置をリリースするためのリリース制御のためのコンピュータプログラムであって、
前記追加装置をリリースするための条件を条件記憶部に登録するステップと、
前記追加装置の状態を示す情報を状態記憶部に登録するステップと、
前記条件記憶部及び前記状態記憶部を参照し、前記追加装置がリリース可能な状態であり、且つ、前記追加装置をリリースするための条件が満たされている場合は、前記追加装置をリリースするステップと、をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の装置が電文を送受信しながら協調して動作する電文処理システムに新たに追加された装置をリリースするための技術に関する。
【背景技術】
【０００２】
複数のサーバなどの装置が協調して動作する大規模コンピュータシステムに、新たにサーバを設置して、このサーバにプログラムのインストール、初期設定などを自動的に行うプロビジョニング技術が知られている（例えば特許文献１）。
【特許文献１】特開平２−２０１６５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、プロビジョニングによって自動的に追加されたサーバを実際に稼動させる（リリースする）ためには、以下のようなことを確認しなければならない。例えば、追加されたサーバが単独で正常に動作をするか否かや、追加されたサーバを経由したときにシステム全体として正常に動作するか否かなどをテストして確認する必要がある。これらは、従来、テスト実施者が作成したテストデータを流し、その結果をテスト実施者が確認しているため、網羅性に欠けるものであったり、見誤りがあったりして、完璧を期しがたいものであった。
【０００４】
さらには、プロビジョニングによって同時に複数のサーバが追加されると、従来はこれらを一括してリリースしていた。この結果、新たにリリースしたサーバのうちの複数で同時に不具合が発生すると、システム全体に与える影響が大きい。
【０００５】
そこで、本発明の目的は、複数のサーバなどの装置が協調して動作するシステムに新たに追加された装置をリリースするための制御に関する技術を提供することである。
【課題を解決するための手段】
【０００６】
本発明の一つの実施態様に従う管理装置は、複数の装置を有し、前記複数の装置が互いに電文を送受信しながら協調して動作する電文処理システムが稼動しているときに、前記電文処理システムに追加された追加装置をリリースするための管理装置であって、前記追加装置をリリースするための条件が登録されている条件記憶部と、前記追加装置の状態を示す情報が記憶されている状態記憶部と、前記条件記憶部及び前記状態記憶部を参照し、前記追加装置がリリース可能な状態であり、且つ、前記追加装置をリリースするための条件が満たされている場合は、前記追加装置をリリースするリリース制御部と、を備える。
【０００７】
好適な実施形態では、前記追加装置の状態を照会し、前記状態記憶部を更新する手段と、前記追加装置をリリースするための条件の入力を受け付ける入力手段とをさらに備える用にしてもよい。
【０００８】
好適な実施形態では、前記複数の装置は、複数のグループにグループ分けされていて、前記追加装置をリリースするための、グループ別のリリースコマンドを記憶した記憶手段をさらに備える。そして、前記リリース制御部は、前記追加装置が属するグループに応じたリリースコマンドを前記記憶手段から取得して、前記追加装置をリリースするようにしてもよい。
【０００９】
好適な実施形態では、前記追加装置のテストを実行するテスト手段と、前記テスト手段によるテスト結果が正常である場合、前記追加装置の状態をリリース可能な状態にするステータス更新手段と、をさらに備えるようにしてもよい。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の一実施形態に係るアプリケーションシステム及びその管理を行う管理装置（管理サーバ）について、図面を参照して説明する。
【００１１】
図１は、本実施形態に係るシステムの全体構成を示す図である。本システムは、所定の業務処理を実行するアプリケーションシステム１と、顧客が使用するクライアント２とがネットワーク９を介して接続されている。そして、アプリケーションシステム１には、このシステムを管理するための管理サーバ１５が接続されている。
【００１２】
アプリケーションシステム１は、クライアント２からのリクエストを振り分けて負荷分散をするロードバランサ１０と、クライアント２に対する入出力インタフェースを提供する複数のＰＬサーバ１１を含むＰＬサーバ群１１Ａと、様々な業務処理（ビジネスロジック、ＢＬ）を実行する複数のＢＬサーバ１２を含むＢＬサーバ群１２Ａ（第１のグループ）と、データベース１４の参照、更新などを行う複数のＤＢサーバ１３を含むＤＢサーバ群１３Ａ（第２のグループ）と、データベース（ＤＢ）１４とを備える。ＰＬサーバ１１が、クライアント２へ表示する画面の制御（プレゼンテーションロジック、ＰＬ）などのインタフェースを提供するインタフェース装置である。ＢＬサーバ１２（第１の装置）及びＤＢサーバ１３（第２の装置）が、アプリケーションシステム１の内部処理を実行する内部装置である。
【００１３】
クライアント２、各ＰＬサーバ１１、各ＢＬサーバ１２、各ＤＢサーバ１３および管理サーバ１５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等２，１１，１２，１３，１５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１４】
ＰＬサーバ群１１Ａの各ＰＬサーバ１１，ＢＬサーバ群１２Ａの各ＢＬサーバ１２及びＤＢサーバ群１３Ａの各ＤＢサーバ１３は、それぞれ共通の構成を備え、同じ処理を実行するようになっている（図２参照）。つまり、サーバ群１１Ａ，１２Ａ，１３Ａがそれぞれ複数のサーバにより多重化されている。これは、耐障害性及び処理性能を確保するためである。そして、各サーバ群１１Ａ，１２Ａ，１３Ａの中では、それぞれどのサーバに処理を実行させても、同じ処理が行われる。この結果、各ＰＬサーバ１１，各ＢＬサーバ１２及び各ＤＢサーバ１３を、それぞれ比較的安価なパーソナルコンピュータなどを用いて実現するとともに、ロードバランサ１０によって負荷分散することにより、本システム１は、高額の高速コンピュータを導入することなく、低コストでハイパフォーマンスを得ることができる。さらには、本システムは、処理するデータ量の増減に伴って、各サーバ１１，１２，１３の台数を容易に増減させることができ、これにより容易に処理能力を調整することができる。本実施形態では、管理サーバ１５が、アプリケーションシステム１の動作の正常性を確認し、新たに追加されたサーバ１１，１２，１３をテストするための処理を実行し、そのサーバをリリースするための処理を実行する。
【００１５】
なお、本システムにおけるＰＬサーバ１１の台数、ＢＬサーバ１２の台数、及びＤＢサーバ１３の台数は、同じ台数でもよいし、それぞれ異なる台数でもよい。
【００１６】
アプリケーションシステム１では、クライアント２からのリクエストがＰＬサーバ群１１Ａ、ＢＬサーバ群１２Ａ、及びＤＢサーバ群１３Ａの順に伝達され、このリクエストに対するリプライがＤＢサーバ群１３ＡからＢＬサーバ群１２Ａ、ＰＬサーバ群１１Ａへと伝達されて、クライアント２へ送信される。詳細に説明すれば、リクエスト及びリプライは、例えば以下のように伝達される。
【００１７】
ＰＬサーバ群１１Ａは、前段であるクライアント２からリクエスト電文２１（図２参照）を受け付けると、１台のＰＬサーバ１１が所定の処理を実行後、後段のＢＬサーバ群１２Ａに対するサーバ間リクエスト電文Ａ２３（図２参照）を生成して、出力する。
【００１８】
ＢＬサーバ群１２Ａは、前段のＰＬサーバ群１１Ａからサーバ間リクエスト電文Ａ２３を受け付けると、１台のＢＬサーバ１２が所定の処理を実行後、後段のＤＢサーバ群１３Ａに対するサーバ間リクエスト電文Ｂ２５（図２参照）を生成して、出力する。
【００１９】
ＤＢサーバ群１３Ａは、前段のＢＬサーバ群１２Ａからサーバ間リクエスト電文Ｂ２５を受け付けると、１台のＤＢサーバ１３がＤＢ１４に対する所定の処理を実行する。そして、前段のＢＬサーバ群１２Ａに対するサーバ間リプライ電文Ｂ３５（図２参照）を生成して、出力する。
【００２０】
ＢＬサーバ群１２Ａでは、１台のＢＬサーバ１２が後段のＤＢサーバ群１３Ａからのサーバ間リプライ電文Ｂ３５に基づいて、前段のＰＬサーバ群１１Ａに対するサーバ間リプライ電文Ａ３３（図２参照）を生成して、出力する。
【００２１】
ＰＬサーバ群１１Ａでは、１台のＰＬサーバ１１が後段のＢＬサーバ群１２Ａからのサーバ間リプライ電文Ａ３３に基づいて、前段のクライアント２に対するクライアントリプライ電文３１（図２参照）を生成して、出力する。
【００２２】
図２には、ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図を示す。
【００２３】
ＰＬサーバ１１は、ロードバランサ１０を介してクライアント２から送られてくるクライアントリクエスト電文２１を受信し、これをサーバ間リクエスト電文Ａ２３に変換していずれかのＢＬサーバ１２へ出力する。また、いずれかのＢＬサーバ１２からサーバ間リプライ電文Ａ３３を受信すると、これをクライアントリプライ電文３１に変換して、ロードバランサ１０を介してクライアント２へ送信する。
【００２４】
ＰＬサーバ１１は、同図（ａ）に示すように、電文識別子付与部１１１と、ＰＬ処理部１１３と、ステータス記憶部１１４と、電文記録部１１５と、ＰＬログ１１７とを備える。
【００２５】
電文識別子付与部１１１は、クライアントリクエスト電文２１を受信すると、これに電文識別子を付与する。電文識別子は、それぞれのＰＬサーバ１１が生成するユニークな数字または文字列等である。例えば、ＰＬサーバ１１に割り当てられているＩＰアドレスと、そのサーバ１１内でのカウンタ値（シリアル番号）とを組み合わせて、電文識別子を生成してもよい。
【００２６】
ＰＬ処理部１１３は、クライアントリクエスト電文２１及びサーバ間リプライ電文Ａ３３に従って、所定の処理を実行する。例えば、クライアントリクエスト電文２１に対しては、その電文に含まれるデータの整合性チェックなどを行い、サーバ間リクエスト電文Ａ２３を生成する。ここで、サーバ間リクエスト電文Ａ２３に、電文識別子付与部１１１によってクライアントリクエスト電文２１に付与された電文識別子が付与され、クライアントリクエスト電文２１とサーバ間リクエスト電文Ａ２３とが関連づけられる。また、サーバ間リプライ電文Ａ３３に対しては、クライアント２に表示される画面（Ｗｅｂページ）の合成を行い、それを含むクライアントリプライ電文３１を生成する。ここで、サーバ間リプライ電文Ａ３３に付与されている電文識別子が、クライアントリプライ電文３１には含まれない。しかし、電文記録部１１５がＰＬログ１１７に格納するクライアントリプライ電文３１のログデータには付与される。
【００２７】
ステータス記憶部１１４については後述する。
【００２８】
電文記録部１１５は、クライアントリクエスト電文２１を受信したとき、及びクライアントリプライ電文３１を出力するときに、それぞれの電文２１，３１の電文識別子を含む、各電文に関連する情報をＰＬログ１１７に格納する。
【００２９】
図３に、ＰＬログ１７のデータ構造の一例を示す。ＰＬログ１１７には、ＰＬサーバ１１がクライアント２に対して送受信した電文の送受信履歴が記憶されている。例えば、ＰＬログ１１７は、データ項目として、電文識別子５１と、送信サーバ名５２と、受信サーバ名５３と、電文内容５４とを有する。
【００３０】
図２（ｂ）には、ＢＬサーバ１２の構成を示す。ＢＬサーバ１２は、ＰＬサーバ１１から送られてくるサーバ間リクエスト電文Ａ２３を受信し、これをサーバ間リクエスト電文Ｂに変換して、いずれかのＤＢサーバ１３へ出力する。また、いずれかのＤＢサーバ１３からサーバ間リプライ電文Ｂ３５を受信すると、これをサーバ間リプライ電文Ａ３３に変換して、ＰＬサーバ１１へ送信する。なお、サーバ間リプライ電文Ａ３３の送信先は、サーバ間リクエスト電文Ａ２３の送信元のＰＬサーバ１１である。
【００３１】
ＢＬサーバ１２は、内部の構成として、ＢＬ処理部１２３と、ステータス記憶部１２４と、電文記録部１２５と、ＢＬログ１２７とを備える。
【００３２】
ＢＬ処理部１２３は、サーバ間リクエスト電文Ａ２３及びサーバ間リプライ電文Ｂ３５に従って、所定の処理を実行する。例えば、サーバ間リクエスト電文Ａ２３を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リクエスト電文Ｂ２５を生成する。ここで、サーバ間リクエスト電文Ｂ２５には、サーバ間リクエスト電文Ａ２３に付与されている電文識別子が付与され、サーバ間リクエスト電文Ａ２３とサーバ間リクエスト電文Ｂ２５とが関連づけられる。また、サーバ間リプライ電文Ｂ３５を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リプライ電文Ａ３３を生成する。この場合も同様に、サーバ間リプライ電文Ａ３３には、サーバ間リプライ電文Ｂ３５に付与されている電文識別子が付与され、サーバ間リプライ電文Ａ３３とサーバ間リプライ電文Ｂ３５とが関連づけられる。
【００３３】
ステータス記憶部１２４については後述する。
【００３４】
電文記録部１２５は、サーバ間リクエスト電文Ａ２３を受信したとき、及びサーバ間リプライ電文Ａ３３を出力するときに、それぞれの電文２３，３３の電文識別子を含む、各電文に関連する情報をＢＬログ１２７に格納する。
【００３５】
ＢＬログ１２７には、ＢＬサーバ１２がＰＬサーバ１１に対して送受信した電文の送受信履歴が記憶されている。ＢＬログ１２７のデータ構造は、ＰＬログ１１７と共通である。
【００３６】
図２（ｃ）には、ＤＢサーバ１３の構成を示す。ＤＢサーバ１３は、ＢＬサーバ１２から送られてくるサーバ間リクエスト電文Ｂ２５を受信し、これに基づいてＤＢ１４の参照、更新などのＤＢ処理を実行する。そして、この実行結果に基づいてサーバ間リプライ電文Ｂ３５を生成し、これをサーバ間リクエスト電文Ｂ２５の送信元のＢＬサーバ１２へ送信する。
【００３７】
ＤＢサーバ１３は、内部の構成として、ＤＢ処理部１３３と、ステータス記憶部１３４電文記録部１３５と、ＤＢログ１３７とを備える。
【００３８】
ＤＢ処理部１３３は、サーバ間リクエスト電文Ｂ２５を受信すると、その電文の内容に従ってＤＢ１４の参照、更新などの処理を実行する。そして、その処理結果に基づいてサーバ間リプライ電文Ｂ３５を生成する。ここで、サーバ間リプライ電文Ｂ３５には、サーバ間リクエスト電文Ｂ２５に付与されている電文識別子が付与され、サーバ間リプライ電文Ｂ３５とサーバ間リクエスト電文Ｂ２５とが関連づけられる。
【００３９】
ステータス記憶部１３４については後述する。
【００４０】
電文記録部１３５は、サーバ間リクエスト電文Ｂ２５を受信したとき、及びサーバ間リプライ電文Ｂ３５を出力するときに、それぞれの電文２５，３５の電文識別子を含む、各電文に関連する情報をＤＢログ１３７に格納する。
【００４１】
ＤＢログ１３７には、ＤＢサーバ１３がＢＬサーバ１２に対して送受信した電文の送受信履歴が記憶されている。ＤＢログ１３７のデータ構造は、ＰＬログ１１７及びＢＬログ１２７と共通である。
【００４２】
ここで、図４にそれぞれの電文フォーマットを示す。同図（ａ）に示すように、クライアントリクエスト電文２１は、ＨＴＭＬなどで記述されたクライアントリクエスト本文を含んでいる。同図（ｂ）に示すように、クライアントリプライ電文３１は、ＨＴＭＬなどで記述されたクライアントリプライ本文を含んでいる。同図（ｃ）に示すサーバ間リクエスト電文２３、２５には、それぞれのリクエスト内容を示すサーバ間リクエスト本文と、電文識別子とが含まれ、同様に同図（ｄ）に示すサーバ間リプライ電文３３、３５には、それぞれのリプライ内容を示すサーバ間リプライ本文と、電文識別子とが含まれる。
【００４３】
図５に、管理サーバ１５の構成図を示す。管理サーバ１５には、キーボードまたはポインティングデバイスなどの入力装置７と液晶ディスプレイなどの表示装置８が接続されている。そして、管理サーバ１５は、外部インタフェースとして、これらの入出力装置を制御する入出力装置制御部１５３と、アプリケーションシステム１とのインタフェースであるシステムインタフェース１５１とを有する。
【００４４】
管理サーバ１５は、各サーバ１１，１２，１３からログデータを収集し、その解析などを行う。さらに、管理サーバ１５は、プロビジョニングなどによりアプリケーションシステム１に自動的に配備されたサーバ１１，１２，１３に対し、テストデータの生成、テストの実行及びテスト結果の検証などの自動テスト処理を行う。さらに、管理サーバ１５は、プロビジョニングにより配備されたサーバ１１，１２，１３を実際に稼働させるリリース制御を行う。
【００４５】
これらの機能を実現するために、管理サーバ１５は、例えば、以下のような構成を備える。管理サーバ１５は、まず、主にログの処理に関する構成として、ログデータ収集部１６１と、収集したログを保存しておく収集ログ記憶部１６３と、収集したログデータを解析するログデータ解析部１６５とを備える。また、管理サーバ１５は、主に自動テストのための構成として、ユーザ登録部１７１と、登録情報記憶部１７２と、テストデータ生成部１７３と、テストデータ記憶部１７４と、テスト実行部１７５と、テスト結果記憶部１７６と、テスト結果処理部１７７と、ＤＢ設定変更部１７８とを備える。そして、主にリリース制御に関する構成として、リリース管理部１８１と、リリース条件表１８２と、ステータス表１８３とを備える。以下、各構成について詳細に説明する。
【００４６】
ログデータ収集部１６１は、システムインタフェース１５１を介して、アプリケーションシステム１の各サーバ１１，１２，１３がそれぞれ保持しているログデータを収集し、収集ログ記憶部１６３に格納する。
【００４７】
図６に収集ログ記憶部１６３に記憶されているログデータの一例を示す。収集ログ記憶部１６３のデータ項目は、ＰＬログ１１７、ＢＬログ１２７及びＤＢログ１３７と同一である。収集されたログデータには、クライアントリクエスト電文２１，クライアントリプライ電文３１，サーバ間リクエスト電文２３，２５及びサーバ間リプライ電文３３，３５のすべてのログが含まれているが、それらは互いに電文識別子５１により関連づけが可能である。例えば、図６のレコード１６３ａ〜ｆは、いずれも電文識別子５１が共通であるから、一つのクライアントリクエスト電文２１及びそれから派生した各電文のログであることがわかる。さらに、この例では、送信サーバ名５２及び受信サーバ名５３により、レコード１６３ａがクライアントリクエスト電文２１，レコード１６３ｂがサーバ間リクエスト電文Ａ２３，レコード１６３ｃがサーバ間リクエスト電文Ｂ２５，レコード１６３ｄがサーバ間リプライ電文Ｂ３５，レコード１６３ｅがサーバ間リプライ電文Ａ３３，及びレコード１６３ｆがクライアントリプライ電文３１であることがわかる。
【００４８】
なお、各リプライ電文３１，３３，３５は、各リクエスト電文２１，２３，２５が通ったＰＬサーバ、ＢＬサーバ及びＤＢサーバと同一のＰＬサーバ、ＢＬサーバ及びＤＢサーバを通るようになっている。つまり、同じ電文識別子を有する電文は、ＰＬサーバからＤＢサーバへ向かう昇り方向とＤＢサーバからＰＬサーバへ向かう下り方向とでは、同一のパスを通る。
【００４９】
ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを解析し、アプリケーションシステム１の動作の正常性の確認をする。例えば、ログデータ解析部１６５は、電文識別子５１をキーにして収集したログデータのレコードをソートし、あるいは、同一の電文識別子５１を有する複数のレコードを１グループとしてまとめる。さらに、ログデータ解析部１６５は、同一の電文識別子５１を有するレコード間で、電文内容５４の整合性チェックを行う。そして、これらの解析結果を、入出力装置制御部１５３が表示装置８に表示する。
【００５０】
図７は、ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例を示す図である。
【００５１】
図８は、ログデータ解析部１６５によって抽出された電文識別子「192.168.0.102-0845」のレコード群を示す。ログデータ解析部１６５は、このレコード群に対して、さらに、整合性チェックを行う。例えば、「送信サーバ名５２→受信サーバ名５３」のペアにおいて、「client→ＰＬ*」「ＰＬ*→ＢＬ*」「ＢＬ*→ＤＢ*」「ＤＢ*→ＢＬ*」「ＢＬ*→ＰＬ*」「ＰＬ*→client」のすべてが存在することを確認する。これにより、入力されたクライアントリクエスト電文２１が途中で消失せずに、最終的なクライアントリプライ電文３１を返しているか否かを確認できる。
【００５２】
さらに、昇り電文と降り電文では同一パスを経由するようになっているため、ログデータ解析部１６５は、ＰＬサーバ及びＢＬサーバのサーバ名が同一であるか否かをチェックする。また、電文内容５４において、特定のパラメータに同一の値が設定されているか（例えばkozaID=1234567）などをチェックする。これにより、入力されたクライアントリクエスト電文２１の内容が、その後生成される各電文に受け継がれているかを確認できる。
【００５３】
また、ログデータ解析部１６５は、予め登録されている電文確認表６０を参照し、同一電文識別子５１を有するレコード群が、この表６０に登録されているリクエスト電文とリプライ電文の対応パターンに合致するか否かを判定する。電文確認表６０は、予めユーザによって登録されて、登録情報記憶部１７２に格納されている。
【００５４】
図９に、電文確認表６０の一例を示す。電文確認表６０は、対象サーバ６１と、対象サーバ６１が受信するリクエスト電文内容６２と、対象サーバが出力するリプライ電文内容６３とが対応付けられている。一つのリクエスト電文６２に対して、生じ得るリプライ電文６３は複数存在することがある。図９の場合、ＰＬサーバに対するリクエスト電文内容６０１に対するリプライとしては、リプライ電文内容６１１〜６１３があり得ることを示している。また、ＢＬサーバが受信するリクエスト電文内容６０２に対するリプライとしては、リプライ電文内容６１４，６１５があり得ることを示している。さらに、ＤＢサーバのリクエスト電文内容６０３に対するリプライとしては、リプライ電文内容６１６，６１７があり得ることを示している。
【００５５】
そして、ログデータ解析部１６５は、同じ電文識別子５１を有するレコードの中から、ＰＬサーバが受信したクライアントリクエスト電文２１のレコード（つまり、送信サーバ５２がクライアント、受信サーバ５３がＰＬサーバであるレコード１６３ａ）と、クライアントリプライ電文３１のレコード（つまり、送信サーバ５２がＰＬサーバ、受信サーバ５３がクライアントであるレコード１６３ｆ）を抽出する。そして、ここで抽出したレコードのペアが、電文確認表６０のリクエスト電文内容６０１とリプライ電文内容６１１〜６１３のペアのいずれかに合致するかを判定する。
【００５６】
ログデータ解析部１６５は、ＢＬサーバに対するリクエスト及びリプライのペア、とＤＢサーバに対するリクエスト及びリプライのペアについても同様に抽出し、電文確認表６０に登録されているペアと合致するか否かを判定する。
【００５７】
これにより、各リクエスト電文に対し、予め定められている所定のリプライ電文が生成されているか否かを確認できる。
【００５８】
次に、再び図５を参照し、自動テスト処理に関する構成及び処理について説明する。
【００５９】
ユーザ登録部１７１は、入力装置７を用いてユーザが入力するユーザ設定情報の登録を受け付ける。ユーザ登録部１７１が受け付けたユーザ設定情報は、登録情報記憶部１７２及びリリース条件表１８２に登録される。
【００６０】
登録情報記憶部１７２には、ユーザが設定した情報が記憶されている。図５の場合、ユーザ設定情報として、既に説明した電文確認表６０と、テストデータに設定されるパラメータ値が記憶されているパラメータ表７０と、テンプレート８０と、ＤＢ設定表９０とが記憶されている。
【００６１】
図１０には、パラメータ表７０の一例を示す。すなわち、パラメータ表７０は、クライアントリクエスト電文２１に含まれるパラメータ７１と、それに設定される複数のパラメータ値７２とが対応付けて登録されている。
【００６２】
図１１には、テンプレート８０の例を示す。すなわち、同図（ａ）には、送受信サーバを特定する通信パターン８１ごとに、入力リクエスト電文８２とそれに対する生成リプライ電文８３とが対応付けられているテンプレートＡを示す。例えば、テスト対象サーバに入出力する電文を同図（ｃ）に示すようにＸ，Ｙ，Ｚ，Ｗとすれば、テンプレートＡでは、ＸとＷとの対応関係が示されている。また、同図（ｂ）には、送受信サーバを特定する通信パターン８５ごとに、あるサーバの前段に対する電文８４と後段に対する電文８６とが対応付けられているテンプレートＢを示す。例えば同図（ｃ）と対応させると、前段に対する電文８４がＸまたはＷであり、後段に対する電文８６がＹまたはＺであり、ＸとＹまたはＷとＺがそれぞれ対応付けられている。
【００６３】
図１２には、ＤＢ設定表９０の一例を示す。ＤＢ設定表９０には、同図（ａ）に示すデータ設定表９０１と同図（ｂ）に示すデータ戻し表９０２とがある。データ設定表９０１及びデータ戻し表９０２は、いずれも、値を設定する表名９１と、値を設定する条件９２と、値を設定する列名９３と、設定値９４とを、データ項目として有する。
【００６４】
テストを実行する場合、所定の条件下でテストを実行するために、ＤＢ１４の設定を一時的に変更したいときがある。このような場合のために、データ設定表９０１の設定値９４にはユーザが入力した値が記憶されている。また、ＤＢ１４の設定を一時的に変更してテストを実行した後は、その設定を元に戻す必要がある。そこで、データ戻し表９０２の表名９１、条件９２及び列名９３には、設定を変更する際の表名、条件及び列名が記憶されるとともに、設定値９４には、設定を変更する際に取得した変更前のＤＢ１４の値が記憶される。
【００６５】
テストデータ生成部１７３は、パラメータ表７０、テンプレート８０及び収集ログ記憶部１６３に格納されているログデータに基づいてテストデータを生成し、テストデータ記憶部１７４に格納する。例えば、テンプレート８０に含まれているパラメータに、パラメータ表７０に設定されているパラメータ値７２を優先させて設定し、パラメータ表７０にパラメータ値が設定されていないパラメータについては、ログデータから抽出して設定する。これにより、テスト実施者は、自らが着目するパラメータについてだけパラメータ値を登録しておけばよい。この場合、特に着目しないパラメータについてはログデータから自動設定される。従って、テンプレート８０内のすべてのパラメータに値が設定されるので、テストデータの不備によりテストが滞ってしまうようなことがない。
【００６６】
一方、パラメータ表７０にすべてのパラメータの値が設定されていれば、ログデータは不要である。また、パラメータ表７０がないとき、あるいはパラメータ表７０にはパラメータ値が何も設定されていないときは、ログデータからすべてのパラメータ値を取得してテストデータを生成してもよい。
【００６７】
本実施形態では、まず、テンプレートＡ、パラメータ表７０及びログデータに基づいて中間的なテストデータであるテストデータＡ（図１３参照）が生成される。そして、テストデータＡとテンプレートＢに基づいて最終的なテストデータであるテストデータＢ（図１４参照）が生成される。以下、具体的に説明する。
【００６８】
まず、図１１（ａ）のテンプレートＡは、各サーバに対するリクエスト電文（Ｘ）と各サーバから出力され得るリプライ電文（Ｗ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＡの各パラメータに図１０に示すパラメータ表７０に登録されている値を設定する。この例では、支店ＩＤ（sitenID）、口座ＩＤ（kozaID）、パスワード（passward）、口数（item_count）及び残高（zandaka）に、パラメータ表７０に登録されているそれぞれの値がセットされる。
【００６９】
この段階では、テンプレートＡにおけるパラメータitemには値がセットされていない。そこで、テストデータ生成部１７３は、パラメータitemに設定すべき値を、ログデータのいずれかのレコードから抽出してセットする。このようにして、図１３に示すテストデータＡが生成される。
【００７０】
図１３のテストデータＡは、サーバＡ４０１からサーバＢ４０２へのリクエスト電文（Ｘ）４０３及びそのリクエスト電文（Ｘ）４０３に対するサーバＢからサーバＡへのリプライ電文（Ｗ）４０４からなる。図１３の例では、テストデータ４３１及び４３２のリクエスト電文（Ｘ）４０３は共通であり、これに対するリプライ電文（Ｗ）４０４として異なるパターンがセットされたものである。
【００７１】
次に、図１１（ｂ）のテンプレートＢは、リクエスト電文（Ｘ）とそれにより生成される後段へのリクエスト電文（Ｙ）、及びリプライ電文（Ｗ）とそれが生成される前の後段からのリプライ電文（Ｚ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＢに図１３のテストパターンＡのリクエスト電文（Ｘ）４０３及びリプライ電文（Ｗ）４０４を適用し、それぞれに対応する電文Ｙ，Ｚを生成する。このとき、テストパターンＡにおいて既に設定されているパラメータは、それぞれ対応する電文Ｙ，Ｚに設定される。この処理により生成されたテストデータＢを図１４に示す。
【００７２】
図１４のテストデータＢは、テスト対象サーバ４１１に対するリクエスト電文（Ｘ）４１２と，これに対応するリプライ電文（Ｗ）４１３と、後段に対するリクエスト電文（Ｙ）４１４と、後段からのリプライ電文（Ｚ）４１５とがワンセットになっている。ここで、テストデータ４４１，４４２，４４３はいずれもリクエスト電文（Ｘ）４１２は共通である。これは、同じリクエスト電文（Ｘ）４１２を入力した場合でも、そこから派生する電文Ｙ，Ｚ，Ｗについては複数のパターンが生じ得るので、正常に動作する場合のすべてのパターンが用意されているからである。
【００７３】
テストデータ記憶部１７４には、上記のようにして生成されたテストデータＢが記憶される。
【００７４】
テスト実行部１７５は、テストデータ記憶部１７４からテストデータを取得してテストを実行し、そのテスト結果をテスト結果記憶部１７６に格納する。例えば、テスト実行部１７５は、テストデータ記憶部１７４からテストデータＢのテストデータを１つずつ読み出し、システムインタフェース１５１を介して、テスト対象サーバ４１１にリクエスト電文（Ｘ）４１２を入力する。テスト対象サーバ４１１は、リクエスト電文（Ｘ）４１２が入力されると、この電文４１２に基づいて所定の処理を実行する。その結果、テスト対象サーバ４１１から後段のサーバへリクエスト電文（Ｙ）が出力され、後段の各サーバもこれに従って動作する。そして、最終的にテスト対象サーバからリプライ電文（Ｗ）が出力される。ここで、テスト実行部１７５は、入力したリクエスト電文（Ｘ）４１２に基づく電文Ｙ，Ｚ，Ｗを、テスト対象サーバ及び後段のサーバのログファイルからそれぞれ取得して、これらを関連づけた形でテスト結果記憶部１７６に格納する。
【００７５】
テスト結果処理部１７７は、テスト結果記憶部１７６に記憶されているテスト結果の電文と、テストデータ記憶部１７４に記憶されているテストデータＢとを対比してテスト結果の解析などを行う。この解析結果は、表示装置８に出力される。
【００７６】
例えば、テスト結果処理部１７７は、入力されたリクエスト電文（Ｘ）及びこれに対するサーバの処理結果として得られた電文Ｙ，Ｚ，Ｗの組が、テストデータ記憶部１７４に記憶されているテストデータＢのいずれかと一致するか否かを判定する。いずれかと一致すれば、アプリケーションシステム１は正常に動作していると考えられる。一方、いずれとも一致しない場合は、テスト対象サーバまたはその後段のサーバに何らかの異常があると考えられる。これらの解析結果は、例えば表示装置８に一覧表示される。
【００７７】
これにより、テンプレート及び必要なパラメータを設定するだけで、網羅的なテストデータの生成、テストの実施及びその結果の解析を自動的に行うことができる。さらに、テスト実施者は、表示装置８にテストの解析結果が表示されるので、システムが正常であるかを直ちに知ることができる。
【００７８】
ＤＢ設定変更部１７８は、テストを実施するために、アプリケーションシステム１の動作環境の変更及びその復帰を行う。例えば、ＤＢ設定変更部１７８は、ＤＢ設定表９０を参照して、システムインタフェース１５１を介してＤＢ１４の内容を一時的に変更する。例えば、ＤＢ設定変更部１７８は、データ設定表９０１（図１２（ａ））に基づいてＤＢ１４を更新する。また、上記の設定変更をする際に、ＤＢ設定変更部１７８は、変更前の状態をデータ戻し表９０２（図１２（ｂ））に設定する。そして、テスト終了後に、データ戻し表９０２を参照して前の状態へ戻す。
【００７９】
例えば、図１２（ａ）に示すデータ設定表９０１の場合、ＤＢ設定変更部１７８は、表名９１に設定されている表から、条件９２を満たすレコードを抽出する。そして、そのレコードの列名９３に合致する列を設定値９４に設定されている値に変更する。これにより、テストを行うときのＤＢの設定を自在に変更することができる。
【００８０】
次に、リリース制御に関する構成及び処理について説明する。
【００８１】
リリース管理部１８１は、システムインタフェース１５１を介して、アプリケーションシステム１内の各サーバ１１，１２，１３のステータスを照会する。例えば、各サーバ内のステータス記憶部１１４、１２４，１３４に記憶されている各サーバのステータスを取得する。ここで取得した各サーバ１１，１２，１３のステータスは、ステータス表１８３に格納される。
【００８２】
ここで、各サーバ内のステータス記憶部１１４、１２４，１３４に格納されるステータス情報について説明する。
【００８３】
アプリケーションシステム１に新たに追加されたサーバの場合、ステータス記憶部にはプロビジョニングが終了した時点で「未テスト」というステータスが設定される。その後、上述したテストが実行されているときは、テスト実行部１７５によりステータスが「テスト中」に変更される。そして、表示装置８に表示されたテスト結果などにより、すべてのテストが正常終了したことが確認され、テスト実施者によりテスト完了を示す入力がなされると、そのサーバのステータス記憶部には、アプリケーションシステム１の一部として正式に稼働可能であることを示す「リリース可」というステータスが設定される。さらに、後述するように、リリース管理部１８１がリリースしたときは、リリースされたサーバ内のステータス記憶部には、「リリース済み」というステータスが設定される。
【００８４】
図１５には、ステータス表１８３の一例を示す。すなわち、ステータス表１８３には、サーバ名１８３１とステータス１８３２とが対応付けて登録されている。ステータス１８３２には、各サーバのステータス記憶部１１４、１２４，１３４から取得したステータスが格納される。
【００８５】
また、リリース管理部１８１は、ステータス表１８３のステータス１８３２が「リリース可」であるサーバについて、リリース条件表１８２に設定された条件が満たされているか否かを判定し、条件が満たされている場合にそのサーバをリリースする。ここで、サーバのリリースを実行するためには、リリース管理部１８１がリリース対象のサーバを指定して、所定のリリース処理コマンドを発行する。リリース処理コマンドは、例えば、リリース管理部１８１が有するコマンド表１８４を参照して取得する。
【００８６】
図１６には、コマンド表１８４の一例を示す。コマンド表１８４には、サーバ種別１８４１ごとにリリース処理コマンド１８４２が登録されている。リリース管理部１８１は、リリースするサーバの種別に応じて、リリース処理コマンドを取得して、実行する。
【００８７】
図１７には、リリース条件表１８２の一例を示す。すなわち、リリース条件表１８２には、リリース対象サーバ１８２１と依存サーバ１８２２とが対応付けて記憶されている。ここで、依存サーバ１８２２とは、リリース対象サーバ１８２１をリリースするためにはリリース済みでなければならないサーバである。つまり、リリース対象サーバ１８２１がリリース可能な状態であっても、依存サーバ１８２２がリリース済みでなければリリース対象サーバ１８２１をリリースすることができない。リリース条件表１８２は、システム管理者等によって予め設定される。
【００８８】
つぎに、上記のような構成を備えたシステムにおける種々の処理手順について、図１８〜図２０のフローチャートを用いて説明する。
【００８９】
まず、図１８には、ログの収集及び解析を行う場合の管理サーバ１５の処理手順を示す。
【００９０】
ログデータ収集部１６１がアプリケーションシステム１内の各サーバ１１，１２，１３から、それぞれに蓄積されているログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ１０１）。ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを、各レコードに含まれている電文識別子をキーにして分類し、電文識別子別に抽出する（Ｓ１０２）。ログデータ解析部１６５は、登録情報記憶部１７２に予め登録されている電文確認表６０を参照して、同じ電文識別子を有する電文間の整合性をチェックする（Ｓ１０３）。ここでは、例えば、リクエストに対するリプライが予め定められているパターンと一致するか否かを判定する。そして、その解析結果を表示装置８に表示出力する（Ｓ１０４）。
【００９１】
これにより、複数のサーバ間で電文を送受信して動作するアプリケーションシステム１において、各サーバ間で送受信される電文が正常であるか否かを自動的に確認することができる。さらに、各サーバ群でそれぞれ複数のサーバを有し、様々な経路で電文がやりとりされる場合であっても、すべての電文のやりとりをもれなくチェックすることができ、網羅性の高いテストを行うことができる。
【００９２】
次に、図１９には、テストデータの生成及びテストの実施を自動的に行う場合の管理サーバ１５の処理手順を示す。
【００９３】
テスト実施者が、テストデータの基となるテストパターンのテンプレート及びそのテンプレートにセットされるパラメータ値を登録する（Ｓ２０１）。ログデータ収集部１６１は、アプリケーションシステム１の各サーバ１１，１２，１３からログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ２０２）。
【００９４】
そして、テストデータ生成部１７３は、上述の処理で登録されたテンプレート及びパラメータ値と、ログデータとに基づいて、中間的なテストデータであるテストデータＡを生成する（Ｓ２０３）。このとき、テスト実施者が登録したパラメータ値をまず設定し、テスト実施者が設定していないパラメータについては、ログデータから取得した値を設定する。次に、テストデータ生成部１７３は、テストデータＡとテンプレートとを用いて、最終的なテストデータであるテストデータＢを生成する（Ｓ２０４）。
【００９５】
ここで、テストデータを流してテストを実施するに当たり、テスト環境であるＤＢ１４の設定を変更する必要がある場合には、ＤＢ設定変更部１７８が、予め登録されているＤＢ設定表９０を参照して設定変更を行う（Ｓ２０５，２０６）。
【００９６】
そして、テスト実行部１７５がテスト対象サーバにテストデータのリクエスト電文を入力して、アプリケーションシステム１を動作させて、テストを実施する（Ｓ２０７）。
【００９７】
テストの実施が終了すると、ステップＳ２０６でＤＢの設定変更を行っている場合は、その変更を元に戻し、変更前の状態に復帰させる（Ｓ２０８，２０９）。
【００９８】
テスト結果処理部１７７は、テスト結果記憶部１７６に格納されているテスト結果を、テストデータ記憶部１７４に記憶されているテストデータと比較して検証する（Ｓ２１０）。そして、検証結果が、表示装置８に表示される。
【００９９】
これにより、テスト実施者は、数多くのテストデータそのものを作成しなくても、テンプレートとしてテストしたいパターンを登録し、重要なパラメータ値を登録しておくことにより、テストデータが自動的に生成され、かつ、テスト及びその結果検証も自動的に行うことができる。さらに、パラメータ値の設定も、すべてのパラメータについて行う必要がない。つまり、テスト実施者が特に指定しないパラメータはログデータから抽出して自動的に補われるので、テスト実施者は、パラメータ値を網羅的に設定しなくてもテストデータを生成することができる。これにより、テスト実施者の負担が軽減される。
【０１００】
図２０には、管理サーバ１５が行うリリース制御の処理手順を示す。
【０１０１】
まず、システム管理者が、新規に追加されたサーバをリリースするためのリリース条件を登録する（Ｓ３０１）。登録されたリリース条件は、リリース条件表１８２に格納される。リリース管理部１８１は、リリース判定を行う対象のサーバから、そのサーバのステータスを取得し、ステータス管理表１８３に格納する（Ｓ３０２）。対象のサーバが複数ある場合は、すべての対象サーバから取得する。
【０１０２】
リリース管理部１８１は、ステータス管理表１８３を参照し、「リリース可」であるサーバの有無を判定する（Ｓ３０３）。そして、「リリース可」であるサーバがないときは、終了する（Ｓ３０３：Ｎｏ）。
【０１０３】
一方、「リリース可」であるサーバがあるときは（Ｓ３０３：Ｙｅｓ）、リリース管理部１８１は、リリース条件表１８２を参照し、そのサーバのリリース条件が満たされているか否かを判定する（Ｓ３０４）。そして、リリース条件が満たされていないときは、終了する（Ｓ３０４：Ｎｏ）。
【０１０４】
リリース条件が満たされているときは（Ｓ３０４：Ｙｅｓ）、リリース管理部１８１は、リリース対象サーバの種別に応じて、コマンド表１８４からリリースコマンドを取得し、それをリリース対象サーバへ送信して、リリースを実行する（Ｓ３０５，３０６）。
【０１０５】
ステップＳ３０３以降の処理を繰り返すことにより、リリース対象サーバが複数ある時は、順次リリース判定及びリリースを実施することができる。
【０１０６】
これにより、システム管理者が定めたリリース対象サーバごとのリリース条件に従って、サーバごとにリリース判定が行われる。
【０１０７】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【０１０８】
例えば、上述の実施形態では、アプリケーションシステム１がＰＬサーバ群１１Ａ，ＢＬサーバ群１２Ａ，及びＤＢサーバ群１３Ａの３層構造になっているが、２層、あるいは４層以上であってもよい。さらには、アプリケーションシステム１は、必ずしも層構造になっていなくてもよい。
【図面の簡単な説明】
【０１０９】
【図１】本実施形態に係るシステムの全体構成図。
【図２】ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図。
【図３】ＰＬログ１１７、ＢＬログ１２７、ＤＢログ１３７のデータ構造の一例。
【図４】各電文フォーマットの一例。
【図５】管理サーバ１５の構成図。
【図６】収集ログ記憶部１６３に記憶されているログデータの一例。
【図７】ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例。
【図８】電文識別子「192.168.0.102-0845」のレコード群。
【図９】電文確認表６０の一例。
【図１０】パラメータ表７０の一例。
【図１１】テンプレート８０の一例。
【図１２】ＤＢ設定表９０の一例。
【図１３】テストデータＡの一例。
【図１４】テストデータＢの一例。
【図１５】ステータス表１８３の一例。
【図１６】コマンド表１８４の一例。
【図１７】リリース条件表１８２の一例。
【図１８】ログの収集及び解析を行う場合の処理手順を示すフローチャート。
【図１９】テストデータの生成及びテストの実施を自動的に行う場合の処理手順を示すフローチャート。
【図２０】リリース制御の処理手順を示すフローチャート。
【符号の説明】
【０１１０】
１    アプリケーションシステム
２    クライアント
１０    ロードバランサ
１１    ＰＬサーバ
１２    ＢＬサーバ
１３    ＤＢサーバ
１４    ＤＢ
１５    管理サーバ
２１    クライアントリクエスト電文
２３，２５    サーバ間リクエスト電文
３１    クライアントリプライ電文
３３，３５    サーバ間リプライ電文
【図１】
2006252159.tif 000003
【図２】
2006252159.tif 000004
【図３】
2006252159.tif 000005
【図４】
2006252159.tif 000006
【図５】
2006252159.tif 000007
【図６】
2006252159.tif 000008
【図７】
2006252159.tif 000009
【図８】
2006252159.tif 000010
【図９】
2006252159.tif 000011
【図１０】
2006252159.tif 000012
【図１１】
2006252159.tif 000013
【図１２】
2006252159.tif 000014
【図１３】
2006252159.tif 000015
【図１４】
2006252159.tif 000016
【図１５】
2006252159.tif 000017
【図１６】
2006252159.tif 000018
【図１７】
2006252159.tif 000019
【図１８】
2006252159.tif 000020
【図１９】
2006252159.tif 000021
【図２０】
2006252159.tif 000022