JP4189379B2 - アプリケーション運用制御方法およびシステム - Google Patents

Description

本発明は、複数サーバ上で稼動するアプリケーションの運用を制御する方法およびシステムに関するものである。

近年、グリッド・コンピューティング技術への注目が高まっている。グリッド・コンピューティング技術は、複数のサーバ間での分散処理を行うことにより一台の高性能サーバと同等以上の大量の処理を行うようにするものであり、その大きな利点の一つとしてはスケーラビリティの高さが挙げられる。つまり、サーバの台数が必要に応じて増減可能ということである。従来、このようなグリッド・コンピューティング技術を用いることにより、グリッド化されたサーバ群への負荷状況に応じて、動的にサーバを追加する技術が知られている（例えば、特許文献１参照）。
特開２００３−１２４９７６号公報（段落００２６，００３２〜００３８、図６，１５１６）

しかし、特許文献１に記載の技術では、サーバの負荷に応じてアプリケーションが使用するサーバを動的に追加する場合に、あるサーバの負荷が増大したことを検知してから、アプリケーションが使用するサーバを追加するようになっているため、各サーバの負荷を軽減するまでの間は、高負荷状態のサーバ上で稼動するアプリケーションを安定に稼動させることができないという不都合があった。そのため、あるサーバが高負荷になってから、当該サーバの負荷を軽減するまでの時間を短縮し、サーバの高負荷状態をできるだけ短縮することが求められる。

ところで、その短縮要求を満たす方法として、例えば、グリッド化されたサーバ群上で複数のアプリケーションが稼動している状況において、サーバ群上で稼動する全てのアプリケーションを、追加するサーバに事前に配備しておくことで、特定のアプリケーションが高負荷になってから、サーバを追加し、特定のアプリケーションにかかる負荷を低減するまでの時間を短縮する方法が考えられる。しかし、全てのアプリケーションを事前に配備しておくと、サーバの持つ計算機資源を非常に多く使ってしまうことになるため、必要最小限の計算機資源を利用して、前述した負荷を低減するまでの時間短縮を実現する方法が望まれている。その実現方法の一つとして、全てのアプリケーションを事前に配備するのではなく、高負荷になると予想されるアプリケーションのみを事前に配備しておく方法が考えられるが、そのようなアプリケーションを正確に予想するためにはいくつか考慮すべき点がある。

特に、同一サーバ上で複数のアプリケーションが稼動することを想定した場合には、各アプリケーション間の相互作用によって負荷変動パターンが異なるので、この点も考慮して、アプリケーションにかかる負荷の変動を予測しなければならない。例えば、２つのアプリケーションが、両方ともディスクへのＩ／Ｏ（Input Output）を頻繁に行う性質のものである場合、各アプリケーションの相互作用により、Ｉ／Ｏバスが競合するため、応答時間が悪化することが考えられる。

そこで、本発明は、前記した状況下において、サーバ群の無駄な計算機資源の利用を抑えつつ、特定のアプリケーションに集中した負荷を円滑に低減することをその目的とする。

前記目的を達成するために本発明では、クライアントからのアプリケーションへの要求に従って複数のサーバ間で負荷分散制御を行うアプリケーション運用制御システムにおけるアプリケーション運用制御方法であって、
前記アプリケーション運用制御システムに用いられる運用制御装置は、前記アプリケーションを記憶する記憶装置と、前記アプリケーションの配備を制御する処理装置とを備え、
前記処理装置は、
前記複数のサーバのうちの所定のサーバに配備または事前配備されている特定のアプリケーションに対して、テスト用のリクエストを送信させる負荷テストを実行し、前記負荷テストで不合格となった場合、当該アプリケーションに対するテスト用のリクエストの送信を停止させて負荷テストを停止し、当該アプリケーションを記憶装置から読み出して、前記複数のサーバのうちの他のサーバに事前配備し、稼動待機中とする負荷テストステップと、
前記負荷テストステップを実行中の前記所定のサーバ以外のサーバから負荷増大通知を受け付けたとき、前記事前配備した稼動待機中のアプリケーションを、前記事前配備したサーバ上で稼動させる稼動ステップと、
を実行するようにした。
これによって、アプリケーションの稼動状況を変更することが可能となる。

本発明によると、サーバ群の無駄な計算機資源の利用を抑えつつ、特定のアプリケーションに集中した負荷を円滑に低減することができる。

以下、本発明の第１実施形態から第３実施形態までについて図面を参照して説明する。
[第１実施形態]
図１は、クライアントサーバシステムの全体構成図である。このクライアントサーバシステムは、クライアント群とサーバ群とを備えている。クライント群には、クライアントＡ（１０１Ａ）、クライアントＢ（１０１Ｂ）およびクライアントＣ（１０１Ｃ）が含まれ、サーバ群には、サーバＡ（１０４Ａ）、サーバＢ（１０４Ｂ）およびサーバＣ（１０４Ｃ）が含まれている。
さらに、このクライアントサーバシステムは、負荷分散装置１０３と、運用制御装置１０５とを備えている。負荷分散装置１０３は、ネットワーク１(１０２)を介して、前記したクラインアト群に接続され、またネットワーク２（１０６）を介して、前記したサーバ群および運用管理装置１０５に接続されている（簡潔に記載）。以下にこれらを詳述する。なお、図１では、クライアント群およびサーバ群は、それぞれ３台としたが、何台でも構わない。また、ネットワーク１やネットワーク２は、別々のネットワークとしたが、同一のネットワークとしても構わない。

クライアント群は、サーバＡ，Ｂ，Ｃ上で稼動するアプリケーションにリクエストを発行しながら、所定の業務を行う装置群である。

負荷分散装置１０３は、クライアント群からのリクエストが特定のサーバに集中し、そのサーバが高負荷にならないように他のサーバへ前記リクエストを振り分ける装置である。図１に示すように、負荷分散装置１０３は、リクエスト分配先設定プログラム１６１、リクエスト分配先情報管理テーブル１６２および負荷分散プログラム１６３を具備している。リクエスト分配先設定プログラム１６１は、ネットワーク２経由でテーブルの設定変更要求を受け付けるものである。

負荷分散プログラム１６３は、サーバＡ，Ｂ，Ｃへリクエストの分配を行う機能がある。また、この負荷分散プログラム１６３は、後記するリクエスト分配先情報管理テーブル１６２の情報を元に、ネットワーク１を介して、所定のクライアントから受信するリクエストを、サーバＡ〜Ｃ上で稼動する適切なアプリケーションへ振り分ける機能がある。なお、前記した負荷分散プログラム１６３の機能は公知の技術であるため、詳細は省略する。

リクエスト分配先情報管理テーブル１６２には、図２に示すように、アプリケーションＩＤと配備先ＩＰアドレスとが格納されている。アプリケーションＩＤとは、アプリケーションを識別するための識別情報であり、配備先ＩＰアドレスとは、配備先のサーバＡ〜ＣのＩＰアドレスである。つまり、リクエスト分配先情報管理テーブル１６２には、サーバＡ，Ｂ，Ｃ上に配備されているアプリケーションに所定のクライアントからのリクエストを分配するための情報が管理されている。

図１に戻って、サーバＡ〜Ｃのサーバ群について説明する。ここでは、主としてサーバＡについて説明する。
サーバＡには、アプリケーション実行プログラム１５１Ａ、アプリケーション監視プログラム１５２Ａ、サーバ性能情報収集プログラム１５３Ａおよび閾値テーブル１５４Ａを具備している。アプリケーション実行プログラム１５１Ａは、運用制御装置１０５から送られたアプリケーションのインストールおよび起動を行う機能がある。

アプリケーション監視プログラム１５２Ａは、サーバＡ上で稼動中のアプリケーションの負荷の監視を行ったり、監視中の負荷があらかじめ設定された閾値を超えた場合に運用制御装置１０５へ負荷増大通知を行ったりする機能がある。
サーバ性能情報収集プログラム１５３Ａは、ＣＰＵ（Central Processing Unit）利用率を取得するための要求に応じて、サーバＡのＣＰＵ利用率をサーバＡのＯＳ（Operating System）に依頼して取得し、取得したＣＰＵ利用率を要求元へ返送する機能がある。

閾値テーブル１５４Ａには、図３に示すように、アプリケーションＩＤと、そのアプリケーションの負荷許容上限値を表す閾値とが格納されている。ここにいう閾値としては、次のようなアプリケーションのレスポンスタイムを用いることとする。すなわち、図１に示したアプリケーション監視プログラム１５２Ａが送信したリクエストを所定のアプリケーションが受信した後、そのアプリケーションがそのリクエストに応じた処理を終了してアプリケーション監視プログラム１５２Ａへそのレスポンスを返すまでの時間である。このようにすると、前記したレスポンスタイムに着目して、アプリケーションの負荷状況を把握することが可能となる。

本実施形態では、アプリケーションの負荷許容上限値を表す閾値としてレスポンスタイムを用いることとするが、アプリケーションの負荷状況を把握することができるのであれば、これに限られない。例えば、アプリケーションへの単位時間当たりのリクエスト数や、アプリケーションへのコネクション数を図３の閾値に用いてもよい。この場合、アプリケーションの負荷状況に着目して図３の閾値を設定することができる。
また、サーバＡのＣＰＵ使用率やメモリ使用率、コマンドへの応答時間を図３の閾値に用いてもよい。この場合、アプリケーションが稼動するサーバの負荷状況に着目して図３の閾値を設定することができる。なお、前記したアプリケーションへの単位時間当たりのリクエスト数や、ＣＰＵ使用率などを組み合わせて適用するようにしてもよい。

なお、サーバＢ，ＣもサーバＡと同様の構成になっている。すなわち、サーバＢは、アプリケーション実行プログラム１５１Ｂ、アプリケーション監視プログラム１５２Ｂ、サーバ性能情報収集プログラム１５３Ｂおよび閾値テーブル１５４Ｂを具備する。また、サーバＣも，アプリケーション実行プログラム１５１Ｃ、アプリケーション監視プログラム１５２Ｃ、サーバ性能情報収集プログラム１５３Ｃおよび閾値テーブル１５４Ｃを具備している。

次に、運用制御装置１０５について説明する。この運用制御装置１０５は、各サーバＡ，Ｂ，Ｃ上で稼動するアプリケーションへの負荷テストを実施し、必要に応じ、各サーバＡ，Ｂ，Ｃへのアプリケーションの配備や、負荷分散装置１０３の設定変更を行う。これを具体的に説明する。

図４は、運用制御装置の構成を示す図である。図４において、運用制御装置１０５は、通信制御装置４３１、中央演算装置（処理装置：ＣＰＵ）４３２、ディスプレイ４３３、キーボード４３４、ＣＤ−ＲＯＭドライブ装置４３５、１次記憶装置４００、２次記憶装置４２０、およびシステムバス４３６から構成されている。以下、これらを詳述する。

通信制御装置４３１は、ネットワーク２を介して、負荷分散装置１０３およびサーバ群と各種データやコマンドを交換するために使用されるものである。ＣＰＵ４３２は、後記する各種プログラムを実行する。ディスプレイ４３３は、アプリケーションの実行状況等を表示するためのものである。キーボード４３４は、オペレータがアプリケーション登録処理の実行等を指示するコマンドを入力するためのものである。
ＣＤ−ＲＯＭ（Compact Disk - Read Only Memory）ドライブ（記憶装置）４３５は、ＣＤ−ＲＯＭ媒体からアプリケーションのインストール時に必要なファイルを読み込むためのものである。システムバス４３６は、通信制御装置４３１、ＣＰＵ４３２、ディスプレイ４３３、キーボード４３４、ＣＤ−ＲＯＭドライブ装置４３５、１次記憶装置４００および２次記憶装置４２０のそれぞれの間で各種データを伝送させるものである。

ここで、１次記憶装置４００および２次記憶装置４２０の記憶内容について説明する。まず、１次記憶装置４００について説明する。１次記憶装置４００には、イベント受信プログラム４０１、負荷分散制御プログラム４０２、運用制御プログラム４０３、アプリケーション配備プログラム４０４、アプリケーション事前配備制御プログラム４０５、リクエスト分配制御プログラム４０６、負荷テスト実行プログラム４０７、およびシステムプログラム４０８が格納されている。そして、１次記憶装置４００には、ワークエリア４０９が保持され、このワークエリア４０９には、負荷テスト対象サーバ情報４１０、負荷テスト不合格アプリケーション情報４１１および負荷テスト強制終了フラグ４１２が確保されるようになっている。

ここで、まず、前記した各プログラム４０１〜４０８の機能について順を追って説明する。イベント受信プログラム４０１は、各サーバＡ，Ｂ，Ｃ上で稼動するアプリケーションからのイベントメッセージを監視し、負荷増大通知を受信すると、その時の状況に応じて負荷分散制御プログラム４０２の起動、もしくは事前配備が必要であることをアプリケーション事前配備制御プログラム４０５に伝える。
負荷分散制御プログラム４０２は、アプリケーションの配備状況に応じて、アプリケーション配備プログラム４０４の起動や、リクエスト分配制御プログラム４０６を用いて負荷分散装置１０３の設定を変更することで、アプリケーションの負荷分散制御を行う。

運用制御プログラム４０３は、オペレータのアプリケーション新規配備要求によって起動し、アプリケーション配備プログラム４０４、アプリケーション事前配備制御プログラム４０５およびリクエスト分配制御プログラム４０６を用いて、サーバＡ，Ｂ，Ｃへアプリケーションの新規配備の指示、サーバＡ，Ｂ，Ｃ上に配備されているアプリケーションへのリクエスト制御、負荷テスト、および事前配備の指示を行い、アプリケーションの運用を制御する。

アプリケーション配備プログラム４０４は、配備対象となるアプリケーションのアプリケーションＩＤを入力として起動し、そのアプリケーションの配備先のサーバを選択して当該アプリケーションの配備を行う。
アプリケーション事前配備制御プログラム４０５は、サーバを一意に識別するサーバＩＤを入力として起動し、そのサーバＩＤに対応するサーバについての負荷テストを、負荷テスト実行プログラム４０７を用いて実施する。そして、このプログラム４０５は、負荷テスト結果に応じて、アプリケーション配備プログラム４０４を用いてアプリケーションの事前配備を行う。
リクエスト分配制御プログラム４０６は、リクエストの分配を開始したいアプリケーションのアプリケーションＩＤ、およびアプリケーションが配備されているサーバのサーバＩＤを入力として起動する。そして、このプログラム４０６は、負荷分散装置１０３の設定を変更して、入力されたアプリケーションＩＤに対応するアプリケーションについて、クライアントＡ，Ｂ，Ｃからのリクエストの分配を開始する。

負荷テスト実行プログラム４０７は、負荷テスト対象のアプリケーションのアプリケーションＩＤ、および、負荷テスト対象のアプリケーションが配備されているサーバのサーバＩＤを入力として起動する。そして、このプログラム４０７は、あらかじめ設定されている時間が経過するまで、あるいは強制的に終了させられるまでの間、前記した負荷テスト対象のアプリケーションにリクエストを発行し続けて負荷をかける。
システムプログラム４０８は、ディスプレイ４３３等を含む周辺装置との間のデータの入出力等、運用制御装置１０５上のプログラムを実行するための基本機能を提供する。

続いて、ワークエリア４０９に確保される前記した各情報４１０〜４１２について説明する。負荷テスト対象サーバ情報４１０には、負荷テスト対象となっているサーバのサーバＩＤや、負荷テスト実施中であるか否かを示す情報が含まれる。
具体的には、負荷テスト対象サーバ情報４１０は、サーバＩＤが書き込まれている状態と、何も書き込まれていない状態（ＮＵＬＬ文字等が書き込まれている状態など）をとる。サーバＩＤが書き込まれている場合には、そのサーバＩＤに対応するサーバの負荷テストが実施中であることを表し、何も書き込まれていない場合は、どのサーバでも負荷テストが実施されていないことを表している。

負荷テスト不合格アプリケーション情報４１１には、次のような場合に、負荷テストが不合格になったアプリケーションに関する情報が含まれる。具体的にはアプリケーションＩＤである。前記した場合というのは、負荷テスト中に、イベント受信プログラム４０１が負荷テスト対象のサーバから負荷増大通知を受信した場合である。つまり、所定のサーバから負荷増大通知を受信したか否かがこれに示される。
負荷テスト強制終了フラグ４１２は、アプリケーション事前配備制御プログラム４０５が、負荷テスト実行プログラム４０７に、負荷テストの終了指示を伝えるために用いられる。なお、ワークエリア４０９には、前記した各情報４１０〜４１２のほか、プログラム実行時にアクセスするデータや一時的に保持するデータが確保される。

次に、２次記憶装置４２０の記憶内容について説明する。２次記憶装置４２０には、アプリケーション配備状態テーブル４２１、サーバＩＰアドレス管理テーブル４２２、負荷テスト設定情報テーブル４２３、およびアプリケーション格納場所管理テーブル４２４が格納される。以下に、これらのテーブル４２１〜４２４について詳述する。

アプリケーション配備状態テーブル４２１は、サーバＡ〜Ｃ上に配備されているアプリケーションの状態を管理するためのテーブルである。具体的には、このアプリケーション配備状態テーブル４２１は、アプリケーションＩＤ、配備先サーバＩＤ、アプリケーションの状態、およびアプリケーションの配備時間を保持する。このアプリケーション配備状態テーブル４２１は、サーバのアプリケーションが新しく配備されたり、または削除されたりした場合に更新される。あるいは、サーバ上に配備されているアプリケーションがクライアントからのリクエストの受付開始、または受付終了した場合に更新される。

アプリケーション配備状態テーブル４２１の構成例を図５に示す。図５に示すテーブル４２１には、アプリケーションＩＤ、配備先サーバＩＤ、アプリケーションの状態およびアプリケーション配備時間が格納されている。ここにいうアプリケーションの状態には、「稼動中」や「待機中」、「強制配備中」、「削除済」の種類がある。つまり、サーバ上のアプリケーションの状態が管理されている。
「稼動中」は、アプリケーションが起動し、かつクライアントからのリクエストを受け付けている配備済みの状態を表す。「待機中」は、アプリケーションが最適なサーバに事前配備されている状態を表す。
「強制配備中」は、あるアプリケーションについて最適なサーバが存在しない場合に、強制的に、いずれかのサーバに事前配備した状態を表す。ここにいう事前配備された状態とは、アプリケーションが起動しているが、クライアントＡ〜Ｃからのリクエストを受け付けていない状態を表す。
「削除済」は、以前にアプリケーションが配備されたが、そのアプリケーションが削除された状態を表す。

次に、図４に示したサーバＩＰアドレス管理テーブル４２２の構成例を図６に示す。図６に示すテーブル４２２には、サーバのサーバＩＤおよびそのサーバのＩＰアドレスが格納されている。

次に、図４に示した負荷テスト設定情報テーブル４２３の構成例を図７に示す。図７に示すテーブル４２３には、アプリケーションのＩＤ、アプリケーションの負荷の閾値（本実施形態ではアプリケーションのレスポンスタイムの許容上限値、例えば５．０秒）、負荷テスト用ＵＲＬ（Uniform Resource Locator）、リクエスト送信頻度（例えば、１００件／分）、および負荷テスト最大継続時間（例えば、５．０分）が格納されている。ここにいう負荷テスト用ＵＲＬとは、図４に示した負荷テスト実行プログラム４０７が負荷テストを行う際に用いるＵＲＬである。

例えば、負荷テスト対象アプリケーションの通常運用時に使用するＵＲＬや、負荷テスト用に特別に準備したＵＲＬをこれに用いてもよい。なお、負荷テスト用ＵＲＬとして、負荷テスト用に特別に準備したＵＲＬを用いる場合、次のようなプログラムを導入するようにしてもよい。すなわち、あるＵＲＬへのリクエストに対し、前記負荷テスト対象アプリケーションの典型的な処理（例えば、（１）ユーザ認証処理、（２）商品一覧を表示する処理、（３）購入手続き処理、（４）商品販売完了画面の表示処理、といった一連の処理）を自動的に実施してレスポンスを返すプログラムである。これにより実運用に近い状況での負荷テストを実施することが可能となる。
なお、図７に示した負荷テスト用ＵＲＬ（雛形）には、実際には、負荷テスト用ＵＲＬのサーバアドレス以外の情報を保持している。

なお、前記した負荷テスト設定情報テーブル４２３は、アプリケーション登録時にオペレータの操作によって更新される。

次に、アプリケーション格納場所管理テーブル４２４の構成例を図８に示す。図８に示すテーブル４２４には、アプリケーションＩＤおよびそのアプリケーションのインストールに関するデータ格納場所が格納されている。データ格納場所というのは、例えば、アプリケーションのインストール時に必要なアーカイブファイルやインストールプログラムの格納場所の意味である。

なお、本実施形態では、ＣＤ−ＲＯＭドライブ装置４３５からアプリケーションのインストール時に必要となるアーカイブファイルなどのファイルを読み込む構成としたが、フロッピー（登録商標）ディスクドライブ、ＭＯ（Magneto-Optical disk）ドライブ、ＤＶＤ（Digital Versatile Disk）ドライブ等、他の外部記憶装置を用いて読み込むこともできる。また、外部コンピュータからネットワーク１を介して配信されたアプリケーションを読み込む構成とすることもできる。

また、本実施形態では、アプリケーション監視プログラム１５２Ａが能動的にアプリケーションの負荷が閾値を超えた事を運用制御装置１０５に通知する方法について説明するが、運用制御装置１０５からの問い合わせに応じて、通知する方法でも構わない。また、本実施形態では、アプリケーション監視プログラム１５２Ａ〜Ｃは、サーバ上に存在する構成としたが、負荷分散装置１０３、または運用制御装置１０５上に存在しても構わない。

次に、前記した運用制御装置１０５での事前準備に関する処理について説明する。
オペレータの指示に従い、図４に示した運用制御装置１０５のＣＰＵ４３２は、事前準備として、まず、運用制御装置１０５に接続されている全てのサーバＡ，Ｂ，ＣにサーバＩＤを割当て、これらサーバＩＤと、それぞれのＩＰアドレスを、２次記憶装置４２０のサーバＩＰアドレス管理テーブル４２２に書き込む。次に、ＣＰＵ４３２は、各サーバＡ，Ｂ，Ｃの図示しない記憶領域上に、当該割り当てた各サーバＩＤを格納させる。これにより、ネットワーク２上に接続されている各サーバＡ，Ｂ，Ｃが、自己のサーバＩＤを参照することが可能となる。

次に、オペレータの指示に従い、ＣＰＵ４３２は、イベント受信プログラム４０１を起動する。また、ＣＰＵ４３２は、配備対象アプリケーションの情報を、図８のアプリケーション格納場所管理テーブル４２４と、図７の負荷テスト設定情報テーブル４２３に設定する。
次に、ＣＰＵ４３２は、配備対象のアプリケーションのアプリケーションＩＤを入力値として運用制御プログラム４０３を起動する。

次に、図４に示したアプリケーション格納場所管理テーブル４２４の設定手順について説明する。まず、オペレータが、ＣＤ−ＲＯＭ媒体をＣＤ−ＲＯＭドライブ装置４３５に挿入すると、ＣＰＵ４３２は、ＣＤ−ＲＯＭ媒体に格納されているアプリケーションのインストール時に必要なファイルを、ＣＤ−ＲＯＭドライブ装置４３５によりＣＤ−ＲＯＭ媒体から読み出して２次記憶装置４２０に格納する。
そして、ＣＰＵ４３２は、アプリケーションについて、一意に識別するアプリケーションＩＤを割当て、アプリケーション格納場所管理テーブル４２４上のアプリケーションＩＤのカラムに当該割り当てたアプリケーションＩＤと、データ格納場所のカラムにアプリケーションのインストール時に必要なファイルの格納場所とを書き込む。

次に、図４に示した負荷テスト設定情報テーブル４２３の設定手順について説明する。まず、オペレータの入力に従って、ＣＰＵ４３２は、負荷テスト設定情報テーブル４２３に、前記アプリケーションＩＤ、そのアプリケーションＩＤのアプリケーションについて許容される負荷の上限（最大レスポンスタイム)を示す閾値、負荷テスト用ＵＲＬ（雛形）、リクエスト送信頻度、および負荷テスト最大継続時間を書き込む。
次に、オペレータの指示に従いＣＰＵ４３２は、あるサーバに、前記のアプリケーションを新規配備するため、そのアプリケーションＩＤを入力として運用制御プログラム４０３を起動する。

[処理手順]
次に、前記した各プログラム４０１〜４０８等の処理手順について説明する。なお、各プログラムは、図４に示したＣＰＵ４３２が順次読み出して実行するものとする。
まず、図４に示した運用制御プログラム４０３の処理手順を図９に示すフローチャートに従って説明する。ここでは、運用制御プログラム４０３は、新規に運用を開始するアプリケーションのアプリケーションＩＤ（例えば「Ｄ」）を入力値として起動することとする。

ステップ９０１では、前記入力値とされたアプリケーションＩＤを入力値として渡してアプリケーション配備プログラム４０４を起動する。その戻り値として、運用対象のアプリケーションＩＤのアプリケーションを新規に配備したサーバのサーバＩＤ（例えば「Ａ」）を取得する。これにより、運用対象のアプリケーションが適切なサーバ（例えばサーバＡ）に配備される。
ステップ９０２では、ステップ９０１でアプリケーション配備プログラム４０４の戻り値（サーバＩＤ）がＮＵＬＬであるか否かを判断し、ＮＵＬＬでない場合（Ｙｅｓ）にはステップ９０３に進み、ＮＵＬＬである場合（Ｎｏ）には本プログラムを終了する。

ステップ９０３では、図４に示したリクエスト分配制御プログラム４０６に、入力値として指定されたアプリケーションＩＤ、およびステップ９０１で取得したサーバＩＤを渡して、リクエスト分配制御プログラム４０６を起動する。これにより、ステップ９０１で新規に配備したアプリケーションへのリクエストの分配が開始される。
ステップ９０４では、図４に示したアプリケーション事前配備制御プログラム４０５に、ステップ９０１で取得したサーバＩＤを渡して、アプリケーション事前配備制御プログラム４０５を起動する。これにより、アプリケーションの新規配備先サーバ（例えばサーバＡ）の負荷テストを実施し、負荷テストの結果が不合格のときに、そのアプリケーションについての事前配備が他のサーバに行なわれる。アプリケーション事前配備制御プログラム４０５による処理が終了すると、本プログラムの処理が終了する。

次に、図４に示したアプリケーション配備プログラム４０４の処理手順を図１０Ａ〜Ｃに示すフローチャートに従って説明する。アプリケーション配備プログラム４０４は、配備対象のアプリケーションのアプリケーションＩＤ（例えば「Ｄ」）を入力値として起動する。
図１０Ａのステップ１００１では、ＣＰＵ４３２が、本プログラムを実行して、配備対象のアプリケーションＩＤのアプリケーションが既に配備されている、または以前に配備されたが削除された全てのサーバのサーバＩＤ（例えば「Ａ」）を取得する。具体的には、ＣＰＵ４３２は、図４に示したアプリケーション配備状態テーブル４２１から、アプリケーションＩＤのカラムの値が、本プログラムへの入力値として指定されたアプリケーションＩＤと一致するレコードを検索し、検索にヒットした全てのレコードにおける配備先サーバのカラムの値であるサーバＩＤ群を取得する。

ステップ１００２では、ＣＰＵ４３２は、ネットワーク２に接続されている全てのサーバのサーバＩＤ（例えば「Ａ」〜「Ｃ」）を取得する。具体的には、ＣＰＵ４３２は、図４に示したサーバＩＰアドレス管理テーブル４２２から、全てのサーバＩＤを取得する。
ステップ１００３では、ＣＰＵ４３２は、ステップ１００２で取得したサーバＩＤ群の中から、ステップ１００１で取得したサーバＩＤと一致しないサーバＩＤのみを取得する。つまり、ＣＰＵ４３２は、全ての配備先候補のサーバのサーバＩＤを取得する。
また、取得したサーバＩＤ群を図４に示したワークエリア４０９に保存する。

ステップ１００４では、ＣＰＵ４３２は、ステップ１００３で図４に示したワークエリア４０９に保存したデータが存在するか否か、すなわち配備対象のアプリケーションの配備先候補サーバが存在するか否かを判断し、存在する場合（Ｙｅｓ）にはステップ１００５に進み、存在しない場合（Ｎｏ）にはステップ１０１１（図１０Ｂ参照）に進む。
ステップ１００５では、ＣＰＵ４３２は、ステップ１００３で取得したサーバＩＤ群の中から、任意に一つのサーバＩＤ（例えば「Ｂ」）を選択する。

ステップ１００６では、選択されたサーバＩＤに対応するサーバのＩＰアドレスを取得する。具体的には、ＣＰＵ４３２は、図４に示したサーバＩＰアドレス管理テーブル４２２（図６参照）から、サーバＩＤのカラムの値がステップ１００５で選択したサーバＩＤと一致するレコードを検索し、検索にヒットしたレコードのＩＰアドレスのカラムの値を取得する。
ステップ１００７では、ＣＰＵ４３２は、ステップ１００５で選択されたサーバＩＤに対応するサーバのＣＰＵ利用率を取得する。具体的には、ＣＰＵ４３２は、まず、ステップ１００６で取得したＩＰアドレスに該当するサーバ上のサーバ性能情報収集プログラム１５３Ｂへサーバ性能情報取得要求を発行してＣＰＵ利用率を受け取る。また、ＣＰＵ４３２は、取得したＣＰＵ利用率を、そのサーバＩＤと対応付けてワークエリア４０９に保存した後、ステップ１００３で取得したサーバＩＤ群から、ＣＰＵ利用率を取得したサーバのサーバＩＤを削除する。

ステップ１００８では、ＣＰＵ４３２は、ステップ１００３でワークエリア４０９上に保存したデータが残っているか否かに基づき、全ての配備先候補のサーバのＣＰＵ利用率を取得したか否かを判断する。具体的には、サーバＩＤが残っていない場合、すなわち全ての配備先候補サーバのＣＰＵ利用率を取得した場合（１００８のＹｅｓ）、ＣＰＵ４３２は、ステップ１０１０に進む。他方、サーバＩＤが残っている場合、すなわち配備先候補サーバＣのＣＰＵ利用率を全て取得していない場合（１００８のＮｏ）、ＣＰＵ４３２は、ステップ１００９に進む。
ステップ１００９では、ＣＰＵ４３２は、配備先候補のサーバの中から、ＣＰＵ利用率を取得していないサーバのサーバＩＤ（例えば「Ｃ」）を選択する。具体的には、ＣＰＵ４３２は、ステップ１００３でワークエリア４０９上に保存したサーバＩＤ群の中で、残っているサーバＩＤ群の中から任意に一つを選択し、ステップ１００６に戻る。

図１０Ｃのステップ１０１０では、ＣＰＵ４３２は、配備対象のアプリケーションＩＤのアプリケーションの配備先を決定する。具体的には、ＣＰＵ４３２は、ステップ１００７で保存したサーバＩＤのサーバのＣＰＵ利用率の中で最も低い値のものを選択し、その選択したＣＰＵ利用率に対応するサーバＩＤをワークエリア４０９に保存する。
なお、このステップ１０１０の次に、ステップ１０２１へ進むことになるが、例えば、図１０Ａのステップ１００４において、配備先候補のサーバが存在しない場合（１００４のＮｏ）、図１０Ｂのステップ１０１１に進むので、以下に、このステップ１０１１以降の処理について説明する。

図１０Ｂのステップ１０１１では、ＣＰＵ４３２は、全ての強制配備先候補のサーバ
のサーバＩＤを取得する。具体的には、ＣＰＵ４３２は、まず、図４に示したアプリケーション配備状態テーブル４２１（図５参照）から、アプリケーションＩＤのカラムの値が、本プログラムの入力値として指定されたアプリケーションＩＤと一致し、かつそのアプリケーションＩＤのアプリケーションの状態のカラムの値が、「削除済」であるレコードを検索する。そして、ＣＰＵ４３２は、その検索にヒットした全てのレコードにおける配備先サーバＩＤのカラムの値を取得する。そして、その取得した値をワークエリア４０９に保存する。

ステップ１０１２では、ＣＰＵ４３２は、ステップ１０１１により、ワークエリア４０９に保存したデータが存在するか否か、すなわち配備対象のアプリケーションＩＤのアプリケーションについての強制配備先候補となるサーバが存在するか否かを判断し、存在する場合（１０１２のＹｅｓ）には、ステップ１０１３に進む。他方、存在しない場合（１０１２のＮｏ）には、ＣＰＵ４３２は、ステップ１０２０に進む。

ステップ１０１３では、ＣＰＵ４３２は、強制配備先候補のサーバＩＤのサーバの中から、任意のサーバを選択する。具体的には、ＣＰＵ４３２は、ステップ１０１１で取得したサーバＩＤ群の中から、任意に一つのサーバＩＤを選択する。
ステップ１０１４では、ＣＰＵ４３２は、任意に選択されたサーバＩＤのサーバのＩＰアドレスを取得する。具体的には、ＣＰＵ４３２は、図４に示したサーバＩＰアドレス管理テーブル４２２（図６参照）から、サーバＩＤのカラムの値がステップ１０１３で取得したサーバＩＤと一致するレコードを検索し、検索でヒットしたレコードのＩＰアドレスのカラムの値を取得する。

ステップ１０１５では、ＣＰＵ４３２は、１０１３で任意に選択されたサーバＩＤのサーバのＣＰＵ利用率を取得する。具体的には、ＣＰＵ４３２は、まず、ステップ１０１４で取得したＩＰアドレスに該当するサーバＢ上のサーバ性能情報収集プログラム１５３Ｂに、サーバ性能情報取得要求を発行する。そして、ＣＰＵ４３２は、ＣＰＵ利用率を受け取る。また、前記取得したＣＰＵ利用率を、サーバＩＤと対応付けてワークエリア４０９に保存した後、ステップ１０１１で取得したサーバＩＤ群から、前記ＣＰＵ利用率を取得したサーバのサーバＩＤを削除する。

ステップ１０１６では、ステップ１０１１で、ワークエリア４０９上に保存したサーバＩＤが残っているか否かに基づいて、全ての強制配備先候補のサーバＩＤのサーバのＣＰＵ利用率を取得したか否かを判断する。そして、それが残っている場合、すなわち全ての強制配備先候補サーバのＣＰＵ利用率を取得していない場合（１０１６のＮｏ）はステップ１０１７に進む。他方、それが残っていない場合、すなわち全ての強制配備先候補サーバのＣＰＵ利用率を取得している場合（１０１６のＹｅｓ）には、ＣＰＵ４３２は、ステップ１０１８に進む。

ステップ１０１７では、ＣＰＵ４３２は、強制配備先候補のサーバのサーバＩＤの中から、まだＣＰＵ利用率を取得していないサーバのサーバＩＤを選択する。具体的には、ＣＰＵ４３２は、ステップ１０１１でワークエリア４０９上に保存したサーバＩＤ群の中で、まだ残っているサーバＩＤを任意に一つ選択し、ステップ１０１４に戻る。
ステップ１０１８では、ＣＰＵ４３２は、配備対象のアプリケーションＩＤのアプリケーションについて、強制配備先を決定する。具体的には、ＣＰＵ４３２は、ステップ１０１５で保存したサーバのＣＰＵ利用率の中で最も低い値を選択し、その選択したＣＰＵ利用率に対応するサーバＩＤをワークエリア４０９に保存する。

ステップ１０１９では、ＣＰＵ４３２は、アプリケーション配備状態テーブル４２１のアプリケーション配備状態を「強制配備中」にする。具体的には、ＣＰＵ４３２は、まず、図４に示したアプリケーション配備状態テーブル４２１（図５参照）上のアプリケーションＩＤのカラムの値、および強制配備先サーバＩＤのカラムの値が、それぞれ本プログラムへの入力値として指定されたアプリケーションＩＤ、およびステップ１０１８で保存したサーバＩＤと一致するレコードを検索する。そして、ＣＰＵ４３２は、その検索にヒットしたレコードにおけるアプリケーションの状態のカラムの値を「強制配備中」に更新する。

ステップ１０２０では、ＣＰＵ４３２は、図４に示したディスプレイ４３３上に、配備対象のアプリケーションを配備可能なサーバが存在しない旨のメッセージを表示してオペレータに通知し、本プログラムを終了する。このとき、本プログラムの戻り値としてＮＵＬＬを返す。

次に、図１０Ｃのステップ１０２１では、ＣＰＵ４３２は、配備対象のアプリケーションインストール用ファイルのデータ格納場所を取得する。具体的には、ＣＰＵ４３２は、まず、図４に示したアプリケーション格納場所管理テーブル４２４（図８参照）から、アプリケーションＩＤのカラムの値が、本プログラムへの入力値として指定されたアプリケーションＩＤと一致するレコードを検索する。そして、ＣＰＵ４３２は、その検索にヒットしたレコードのデータ格納場所を取得する。
ステップ１０２２では、ＣＰＵ４３２は、閾値を取得する。具体的には、ＣＰＵ４３２は、まず、図４に示した負荷テスト設定情報テーブル４２３（図７参照）から、アプリケーションＩＤのカラムの値が、本プログラムへの入力値として指定されたアプリケーションＩＤと一致するレコードを検索する。そして、ＣＰＵ４３２は、その検索にヒットしたレコードの閾値のカラムの値を取得する。

ステップ１０２３では、ＣＰＵ４３２は、配備先または強制配備先のサーバのＩＰアドレスを取得する。具体的には、ＣＰＵ４３２は、まず、図４に示したサーバＩＰアドレス管理テーブル４２２（図６参照）から、サーバＩＤのカラムの値が、ステップ１０１０、もしくはステップ１０１８でワークエリア４０９に保存したサーバＩＤと一致するレコードを検索する。そして、ＣＰＵ４３２は、その検索にヒットしたレコードのサーバＩＰアドレスのカラムの値を取得する。
ステップ１０２４では、ＣＰＵ４３２は、配備先または強制配備先のサーバＩＤのサーバにアプリケーションの配備要求を発行する。具体的には、ＣＰＵ４３２は、ステップ１０２３で取得したＩＰアドレスに該当するサーバＩＤのサーバ上で稼動するアプリケーション実行プログラム１５１Ｂへ、当該アプリケーションの配備要求または強制配備要求を発行する。

ステップ１０２５では、ＣＰＵ４３２は、配備対象（強制配備も含む）のアプリケーションのアプリケーションＩＤと、インストール用ファイルと、負荷の閾値とを送信する。この送信は、ステップ１０２３で取得したＩＰアドレスに該当するサーバ上で稼動するアプリケーション実行プログラム１５１Ｂに行う。具体的には、本プログラムへの入力値として指定されたアプリケーションＩＤ、ステップ１０２１で取得したデータの格納場所に保存されているアーカイブファイル・インストールプログラム、アプリケーションの起動や停止の手順が書かれているアプリケーション起動・停止手順ファイル、ステップ１０２２で選択した閾値を送信する。

ステップ１０２６では、ＣＰＵ４３２は、図４に示したアプリケーション配備状態テーブル４２１上のアプリケーションＩＤのカラムの値、および配備先サーバＩＤのカラムの値が、それぞれ本プログラムへの入力値として指定されたアプリケーションＩＤ、およびステップ１０１０、もしくはステップ１０１８でワークエリア４０９に保存したサーバＩＤと一致するレコードが存在するか否かを判断する。そして、前記のレコードが存在する場合（１０２６のＹｅｓ）には、ステップ１０１０、もしくはステップ１０１８でワークエリア４０９に保存したサーバＩＤを戻り値として、本プログラムの呼び出し元に返し、本プログラムを終了する。他方、前記レコードが存在しない場合（１０２６のＮｏ）には、ステップ１０２７に進む。

ステップ１０２７では、ＣＰＵ４３２は、配備対象のアプリケーションＩＤのレコードを追加する。具体的には、ＣＰＵ４３２は、アプリケーションＩＤ、および配備先サーバＩＤのカラムの値が、それぞれ本プログラムへの入力値として指定されたアプリケーションＩＤ、およびステップ１０１０、もしくはステップ１０１８でワークエリア４０９に保存したサーバＩＤであるレコードを追加する。

ステップ１０２８では、ＣＰＵ４３２は、配備対象のアプリケーションのレコードを更新する。具体的には、ＣＰＵ４３２は、ステップ１０２７で、アプリケーション配備状態テーブル４２１へ追加したレコードのアプリケーションの状態のカラムの値を「待機中」にする。また、ＣＰＵ４３２は、ステップ１０１０、もしくはステップ１０１８でワークエリア４０９に保存したサーバＩＤを戻り値として、本プログラムの呼び出し元に返し、本プログラムを終了する。

次に、図１に示したサーバＡ上のサーバ性能情報収集プログラム１５３Ａの処理手順を図１１を示すフローチャートに従って説明する。ここでは、図１に示したサーバＡに実装されているＣＰＵが動作を行うが、サーバＢ，Ｃ上のサーバ性能情報収集プログラム１５３Ｂ，１５３Ｃも同様である。

ステップ１１０１では、サーバ性能情報収集要求を受け付けたか否かを判断し、受け付けていない場合（Ｎｏ）は、ステップ１１０１を繰り返し、受け付けた場合（Ｙｅｓ）は、ステップ１１０２に進む。
ステップ１１０２では、サーバＡのＣＰＵ利用率（性能情報）を、当該サーバ上のＯＳに収集を依頼し、その結果を取得する。
ステップ１１０３では、ステップ１１０２で取得したＣＰＵ利用率（性能情報）を、運用制御装置１０５上のアプリケーション配備プログラム４０４へ返送する。

次に、図１に示したサーバＡ上のアプリケーション実行プログラム１５１Ａの処理手順を図１２に示すフローチャートに従って説明する。なお、サーバＢ，Ｃ上のアプリケーション実行プログラム１５１Ｂ，１５１Ｃについても同様である。
ステップ１２０１では、クライアント群や図１に示した運用制御装置１０５からのリクエストを監視すると共に、運用制御装置１０５からコマンドを受信して、そのコマンドがアプリケーションの配備要求の場合（１２０１の配備要求）にはステップ１２０２に進む。他方、そのコマンドがアプリケーションの削除要求の場合（１２０１の削除要求）には、ステップ１２０９に進む。また、ステップ１２０１において、運用制御装置１０５から受信したコマンドが、配備要求や削除要求以外のその他のコマンドの場合（１２０１のその他）にはステップ１２０１を継続する。

ステップ１２０２では、アプリケーションの配備要求元のプログラムに対し、配備要求されたアプリケーションに関する情報、すなわちアプリケーションＩＤ、アプリケーションのインストールに必要なアーカイブファイル、インストールプログラム、アプリケーション起動・停止手順ファイル、および図３に示した閾値の送信を要求する。そして、それぞれの情報を受信している間は（１２０２のＮｏ）、図示しないローカルディスクに書き込み、他方、これらの情報の受信が終了した場合（１２０２のＹｅｓ）には、ステップ１２０３に進む。
ステップ１２０３では、ステップ１２０２で受信したアプリケーションのインストールに必要なアーカイブファイルなどを図示しないメモリ等の適切な場所に展開する。

ステップ１２０４では、ステップ１２０２で受信したインストールプログラムまたは、ＯＳ付属のインストールプログラムを実行し、ステップ１２０２で受信したアプリケーションのインストールを実施する。このようにして配備対象アプリケーションのインストールプログラムを実行する。
ステップ１２０５では、ステップ１２０２で受信した情報に含まれるアプリケーション起動・停止手順ファイルに書かれている手順に従い、図示しないアプリケーション起動プログラムを実行する。
ステップ１２０６では、閾値テーブル１５４Ａにレコードを追加し、アプリケーションＩＤのカラム、および閾値のカラムに、ステップ１２０２で受信したアプリケーションＩＤ、および閾値を書き込む。

ステップ１２０７では、アプリケーション監視プログラム１５２Ａへ、ステップ１２０２で受信したアプリケーションＩＤに該当するアプリケーションの稼動状況の監視を要求する。
ステップ１２０８では、図１に示した運用制御装置１０５上のアプリケーション配備プログラム４０４にアプリケーションの配備が完了したことを通知する。以上でアプリケーション実行プログラム１５１Ａにおけるアプリケーション配備要求を受けた場合の処理が終了し、ステップ１２０１へ戻る。
ステップ１２０９では、アプリケーション監視プログラム１５２Ａに対し、ステップ１２０１で受信したコマンドであるアプリケーション削除要求の引数として指定されたアプリケーションＩＤを渡して、アプリケーションの稼動状況の監視停止を要求する。

ステップ１２１０では、アプリケーション起動・停止手順ファイルに書かれている手順に従い、ステップ１２０１で受信したコマンドであるアプリケーション削除要求の引数として指定されたアプリケーションＩＤに該当するアプリケーション停止プログラムを実行する。つまり、削除対象のアプリケーションの実行を停止する。
ステップ１２１１では、アプリケーション起動・停止手順ファイルに書かれている手順に従い、ステップ１２０１で受信したコマンドであるアプリケーション削除要求の引数として指定されたアプリケーションＩＤに該当するアプリケーションのアンインストールプログラムを実行する。つまり、削除対象のアプリケーションのアンインストールを行う。

ステップ１２１２では、閾値テーブル１５４Ａから、アプリケーションＩＤのカラムの値が、ステップ１２０１で受信したコマンドであるアプリケーション削除要求の引数として指定されたアプリケーションＩＤと一致するレコードを検索し、検索にヒットしたレコードを削除する。
ステップ１２１３では、図１に示した運用制御装置１０５上の図４に示したアプリケーション事前配備制御プログラム４０５にアプリケーションの削除が完了したことを示すメッセージを通知する。以上でアプリケーション実行プログラム１５１Ａにおけるアプリケーション削除要求を受けた場合の処理が終了し、ステップ１２０１へ戻る。

なお、図１に示したアプリケーション監視プログラム１５２Ａは、図１に示したアプリケーション実行プログラム１５１Ａのアプリケーション監視要求に応じて、アプリケーションのレスポンスタイムを測定するためのＵＲＬに定期的にリクエストを投げる。そして、前記リクエストに対するレスポンスを受け取るまでの時間を計測する。
そして、前記計測された値、もしくは前記計測された値の数回分の平均値が、閾値テーブル１５４Ａ上の閾値を超えたか否かを定期的に判断し、閾値を超えた場合、運用制御装置１０５上の図１に示したイベント受信プログラム４０１へ、負荷増大通知と、負荷が閾値を超えたアプリケーションのアプリケーションＩＤ、および本プログラムが実行されているサーバＡのサーバＩＤを送信する。

次に、図４に示したリクエスト分配制御プログラム４０６の処理手順を図１３に示すフローチャートに従って説明する。リクエスト分配制御プログラム４０６は、サーバ上に配備されているアプリケーションへ、クライアント（例えばクライアントＡ）からのリクエストの分配を開始するため、分配先アプリケーションのアプリケーションＩＤ（例えば「Ｄ」）、およびその分配先アプリケーションが配備されているサーバのサーバＩＤ（例えば「Ｂ」）を入力値として起動される。

ステップ１３０１では、分配先アプリケーションが配備されているサーバのＩＰアドレスを取得する。具体的には、図４に示したサーバＩＰアドレス管理テーブル４２２から、サーバＩＤのカラムの値が、本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索し、検索にヒットしたレコードのＩＰアドレスのカラムの値を取得する。

ステップ１３０２では、図１に示した負荷分散装置１０３上のリクエスト分配先設定プログラム１６１へ、負荷分散装置１０３の設定変更要求を発行し、当該コマンドの引数として、本プログラムへの入力値として指定されたアプリケーションＩＤと、ステップ１３０１で取得したサーバのＩＰアドレスを送信する。
ステップ１３０３では、図４に示したアプリケーション配備状態テーブル４２１上の、アプリケーションＩＤのカラムの値、および配備先サーバＩＤのカラムの値が、それぞれ本プログラムへの入力値として指定されたアプリケーションＩＤ、およびサーバＩＤであるレコードを検索し、検索にヒットしたレコードのアプリケーションの状態のカラムの値を「稼動中」に更新する。

次に、図１に示した負荷分散装置１０３のリクエスト分配先設定プログラム１６１の処理手順を、図１４に示したフローチャートに従って説明する。
ステップ１４０１では、負荷分散装置１０３の設定変更要求を受け付けたか否かを判断し、受け付けていない場合（Ｎｏ）は、それを受け付けるまでステップ１４０１を繰り返し、他方、それを受け付けた場合（Ｙｅｓ）はステップ１４０２に進む。
ステップ１４０２では、図１に示したリクエスト分配先情報管理テーブル１６２上の、アプリケーションＩＤのカラム、および配備先ＩＰアドレスのカラムに、それぞれ、ステップ１４０１で受信した、アプリケーションＩＤ、サーバのＩＰアドレスを書き込む。
ステップ１４０３では、負荷分散装置１０３の設定変更要求の要求元であるリクエスト分配制御プログラム４０６へ、設定変更完了メッセージを返送する。

次に、アプリケーション事前配備制御プログラム４０５の処理手順を図１５Ａおよび図１５Ｂに示すフローチャートに従って説明する。アプリケーション事前配備制御プログラム４０５は、負荷テスト対象サーバのサーバＩＤを入力値として起動される。また、本実施形態では、負荷テスト対象サーバ上で複数のアプリケーションが稼動する場合、全てのアプリケーションについて、配備時間の新しい順に負荷テストを実施する場合について説明するが、どのような順番で実施しても構わない。

ステップ１５０１では、負荷テスト対象のサーバに配備されている全てのアプリケーションＩＤを取得する。具体的には、アプリケーション配備状態テーブル４２１から、配備先サーバＩＤのカラムの値が、本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索する。そして、その検索にヒットした全てのレコードのアプリケーションＩＤのカラムの値、およびアプリケーション配備時間のカラムの値を取得する。また、そのアプリケーションＩＤの値と、そのアプリケーションＩＤに対応するアプリケーション配備時間の値とを対応付けてワークエリア４０９に保存する。

ステップ１５０２では、配備時間が最新のアプリケーションを選択する。具体的には、ステップ１５０１で図４に示したワークエリア４０９に保存したアプリケーション配備時間の値の中で最新の時刻を示している値に対応付けられているアプリケーションＩＤを取得し、これを選択する。この取得したアプリケーションＩＤのアプリケーションが、負荷テスト対象になる。

ステップ１５０３では、まず、図４に示したアプリケーション配備状態テーブル４２１から、アプリケーションＩＤのカラムの値、および配備先サーバＩＤのカラムの値が、ステップ１５０２で選択したアプリケーションのアプリケーションＩＤ、および本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードのアプリケーションの状態のカラムの値を取得する。次に、取得した値が「強制配備中」であるか否かを判断し、「強制配備中」であれば（１５０３のＹｅｓ）、ステップ１５１５に進み、他方、「強制配備中」でなければ（１５０３のＮｏ）、ステップ１５０４に進む。

ステップ１５０４では、ステップ１５０２で選択したアプリケーションのアプリケーションＩＤ、および本プログラムへの入力値として指定されたサーバＩＤを入力値として負荷テスト実行プログラム４０７を起動する。これにより、負荷テスト対象のアプリケーションの負荷テストが開始される。なお、負荷テストの結果は、不合格アプリケーション情報４１１に記憶される。
ステップ１５０５では、図４に示した負荷テスト対象サーバ情報４１０にデータが存在するか否かを判断し、データが存在しなければ（Ｎｏ）、負荷テストが終了していると判断し、図１５Ａのステップ１５０６，１５０７および図１５Ｂのステップ１５０８〜１５１４までの事前配備等の処理を行わず、図１５Ｂのステップ１５１５に進む。他方、負荷テスト対象サーバ情報４１０にデータが存在する場合（１５０５のＹｅｓ）には、ステップ１５０６に進む。

ステップ１５０６では、図４に示した負荷テスト不合格アプリケーション情報４１１にデータが存在するか否かを判断し、データが存在しない場合（Ｎｏ）にはステップ１５０５に戻る。他方、負荷テスト不合格アプリケーション情報４１１にデータが存在する場合（Ｙｅｓ）には、ステップ１５０７に進む。なお、不合格アプリケーション情報４１１に存在したデータは、不合格の結果を得たアプリケーションのアプリケーションＩＤのことであり、これは、負荷テスト実施中に入力値として指定されたサーバＩＤに該当するサーバから、イベント受信プログラム４０１へ負荷増大通知がきたときに、負荷テスト不合格アプリケーション情報４１１に記憶される。
ステップ１５０７では、図４に示した負荷テスト強制終了フラグ４１２をＯＮに更新する。これにより、負荷テスト実行プログラムに、負荷テスト終了の指示を伝える。

次に、図１５Ｂのステップ１５０８について説明する。このステップ１５０８では、図４に示したアプリケーション配備状態テーブル４２１上の、アプリケーションＩＤのカラムの値、および配備先サーバＩＤのカラムの値が、それぞれ図４に示した負荷テスト不合格アプリケーション情報４１１に書かれているアプリケーションＩＤ、および本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードのアプリケーションの状態のカラムの値が「待機中」であるか否かを判断する。つまり、負荷が閾値を超えたアプリケーションが事前配備のアプリケーションか否かを判断する。そして、その判断の結果、「待機中」でない場合（１５０８のＮｏ）には、ステップ１５１２に進み、「待機中」であった場合（１５０８のＹｅｓ）は、ステップ１５０９に進む。

ステップ１５０９では、図４に示したサーバＩＰアドレス管理テーブル４２２上のサーバＩＤのカラムの値が、本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索し、検索にヒットしたレコードのサーバＩＰアドレスのカラムの値を取得する。
ステップ１５１０では、ステップ１５０９で取得したＩＰアドレスに該当するサーバ上のアプリケーション実行プログラムに、アプリケーション削除要求と、当該コマンドの引数として、負荷テスト不合格アプリケーション情報４１１に書かれているアプリケーションＩＤとを送信する。このようにして、負荷が閾値を超えたアプリケーションの削除を要求する。

ステップ１５１１では、図４に示したアプリケーション配備状態テーブル４２１上の、アプリケーションＩＤのカラムの値、および配備先サーバＩＤのカラムの値が、それぞれ負荷テスト不合格アプリケーション情報４１１に書かれている負荷テストの結果が不合格であったことを示すアプリケーションＩＤ、および本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコード上のアプリケーションの状態の値を「削除済」に更新する。このようにして、負荷が閾値を超えたアプリケーションの状態を「削除済」に更新する。

ステップ１５１２では、図４に示した負荷テスト不合格アプリケーション情報４１１に書かれているアプリケーションＩＤを入力値として、図４に示したアプリケーション配備プログラム４０４を起動し、前記プログラムの戻り値としてサーバＩＤを取得する。これにより、負荷が閾値を超えたアプリケーションが事前配備される。また、前記戻り値は、図４に示した負荷テスト不合格アプリケーション情報４１１に書かれているアプリケーションＩＤに該当するアプリケーションについての事前配備先サーバのサーバＩＤである。

ステップ１５１３では、図４に示した負荷テスト不合格アプリケーション情報４１１からデータ、すなわちアプリケーションＩＤを削除する。
ステップ１５１４では、ステップ１５１２で起動したアプリケーション配備プログラムの入力値となったサーバＩＤを入力値として、図４に示したアプリケーション事前配備制御プログラム４０５を再帰的に呼び出す。これにより、事前配備先サーバの負荷テストを実施し、必要に応じた事前配備（強制配備を含む）と、事前配備に伴う負荷テストが繰り返し行われる。

ステップ１５１５では、ステップ１５０１でワークエリア４０９に保存した配備時間群を参照し、全てのアプリケーションに対する処理が終了したかどうかを判断する。具体的には、１５Ａのステップ１５０２において取得したアプリケーションＩＤに対応付けられているアプリケーション配備時間の次に新しい配備時間が対応付けられているアプリケーションＩＤが存在しないかどうかを判断する。
そして、対応付けられているアプリケーション配備時間が存在する場合（１５１５のＮｏ）は、ステップ１５１６に進み、他方、存在しない場合（１５１５のＹｅｓ）は、本プログラムを終了する。

ステップ１５１６では、図１５Ａのステップ１５０１でワークエリア４０９に保存した配備時間群の中で、ステップ１５０２で選択したアプリケーションＩＤのアプリケーション配備時間に対応付けられているアプリケーションの次に新しい配備時間に対応付けられているアプリケーションＩＤを取得し、ステップ１５０３に戻る。この取得したアプリケーションＩＤに該当するアプリケーションが、次の負荷テスト対象になる。

また、本実施形態では、このアプリケーション事前配備制御プログラム４０５の処理終了後、図４に示したアプリケーション配備状態テーブル４２１は更新されずに図４に示した運用制御プログラム４０３の処理が終了する。このため、次に、運用制御プログラム４０３が起動する際、図４に示したアプリケーション配備状態テーブル４２１上の、前回のアプリケーション事前配備制御プログラム４０５によるアプリケーションの削除履歴が引き継がれることになるが、アプリケーション事前配備制御プログラム４０５の処理終了ごとに、運用制御プログラム４０３によってアプリケーション配備状態テーブル４２１上の、アプリケーションの状態が「削除済」であるレコード全てを削除するようにしてもよい。

次に、図４に示した負荷テスト実行プログラム４０７の処理手順を図１６に示すフローチャートに従って説明する。負荷テスト実行プログラム４０７は、負荷テスト対象サーバのサーバＩＤ、および負荷テスト対象アプリケーションのアプリケーションＩＤを入力値として起動する。

ステップ１６０１では、図４に示した負荷テスト設定情報テーブル４２３(図７参照)から、アプリケーションＩＤのカラムの値が、本プログラムへの入力値として指定されたアプリケーションＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードの、負荷テスト用ＵＲＬ（雛形）のカラムの値、リクエスト送信頻度のカラムの値、および負荷テスト最大継続時間のカラムの値を取得する。
ステップ１６０２では、図４に示したサーバＩＰアドレス管理テーブル４２２（図６参照）から、サーバＩＤのカラムの値が、本プログラムへの入力値として指定されたサーバＩＤと一致するレコードを検索し、検索にヒットしたレコードのＩＰアドレスのカラムの値、すなわちテスト対象サーバのＩＰアドレスを取得する。

ステップ１６０３では、ステップ１６０１で取得した負荷テスト用ＵＲＬ（雛形）と、ステップ１６０２で取得したＩＰアドレスとを用いて負荷テスト用ＵＲＬを取得する。
ステップ１６０４では、図４に示した負荷テスト対象サーバ情報４１０に本プログラムへの入力値であるサーバＩＤを書き込む。
ステップ１６０５では、負荷テストの開始時間である現在の時刻を取得し、次のステップ１６０６では、設定されたリクエスト送信頻度に合わせてリクエストを送信するために、現在の時間を取得する。この現在の時間は、リクエストを送信するためのタイミング計算用として利用される。

ステップ１６０７では、図４に示した負荷テスト強制終了フラグ４１２を参照して強制終了フラグがＯＮであるかＯＦＦであるかを判断し、負荷テスト強制終了フラグ４１２がＯＮであった場合は（ＯＮ）、ステップ１６１１に進む。他方、負荷テスト強制終了フラグ４１２がＯＦＦであった場合（１６０７のＯＦＦ）は、ステップ１６０８に進む。
ステップ１６０８では、ステップ１６０５で取得した負荷テスト開始時間から、ステップ１６０１で取得した負荷テスト最大継続時間を経過したかを判断し、経過していない場合（Ｎｏ）はステップ１６０９に進み、他方、経過している場合（１６０８のＹｅｓ）は、ステップ１６１２に進む。

ステップ１６０９では、ステップ１６０６で取得した時間と、ステップ１６０１で取得したリクエスト送信頻度をもとに、リクエストを送信すべき時間か否かの判断を繰り返し行う（Ｎｏ）。他方、その時間になった場合（１６０９のＹｅｓ）は、ステップ１６１０に進む。
ステップ１６１０では、ステップ１６０３で取得した負荷テスト用ＵＲＬにリクエストを送信し、ステップ１６０６に戻る。
ステップ１６１１では、図４に示した負荷テスト強制終了フラグ４１２をＯＦＦに更新する。
ステップ１６１２では、図４に示した負荷テスト対象サーバ情報４１０のデータを削除し、本プログラムの処理を終了する。

次に、イベント受信プログラム４０１の処理手順を図１７に示すフローチャートに従って説明する。イベント受信プログラム４０１は、オペレータの事前準備の際に起動する。
ステップ１７０１では、あるサーバから負荷増大通知を受信したか否かを判断し、受信していなければ（Ｎｏ）、受信するまで繰り返す。そして、負荷増大通知を受信したら（１７０１のＹｅｓ）、負荷増大通知とともに、送信されてきたサーバＩＤおよびアプリケーションＩＤをワークエリア４０９に保存し、ステップ１７０２に進む。ここでいうサーバＩＤは、負荷増大通知の通知元サーバのサーバＩＤであり、アプリケーションＩＤは、負荷が閾値を超えたことを検知されたアプリケーションのアプリケーションＩＤである。

ステップ１７０２では、図４に示した負荷テスト対象サーバ情報４１０を参照し、それにデータがあるか否か、すなわち負荷テストが実施されているサーバのサーバＩＤが存在するか否かを判断する。そして、その判断の結果、負荷テスト対象サーバ情報４１０にデータが存在しない場合（１７０２のＮｏ）は、ステップ１７０５に進み、他方、存在する場合（１７０２のＹｅｓ）は、ステップ１７０３に進む。
ステップ１７０３では、負荷テスト対象サーバ情報４１０に書かれているサーバＩＤと、ステップ１７０１でワークエリア４０９に保存したサーバＩＤとが一致するか否かを判断する。つまり、負荷増大通知を行ったサーバと、負荷テスト対象となっているサーバが同じであるか否かを判断する。そして、その判断の結果、一致する場合（１７０３のＹｅｓ）はステップ１７０４に進み、他方、一致しない場合（１７０３のＮｏ）は、ステップ１７０５に進む。

ステップ１７０４では、図４に示した負荷テスト不合格アプリケーション情報４１１に、ステップ１７０３で一致したアプリケーションＩＤ、すなわち、負荷が閾値を超えたアプリケーションのＩＤを書き込み、ステップ１７０１に戻る。
ステップ１７０５では、図４に示した負荷分散制御プログラム４０２に、ステップ１７０１でワークエリア４０９に保存したサーバＩＤ、およびアプリケーションＩＤを入力値として渡して、負荷分散制御プログラム４０２が起動し、ステップ１７０１に戻る。また、存在したアプリケーションＩＤを書き込み、ステップ１７０１に戻る。

次に、負荷分散制御プログラム４０２の処理手順を図１８に示すフローチャートに従って説明する。負荷分散制御プログラム４０２は、負荷増大通知元サーバのサーバＩＤ、および負荷が閾値を超えたアプリケーションのアプリケーションＩＤを入力値として起動する。

ステップ１８０１では、アプリケーションが事前配備されているか否かを判断する。具体的には、図４に示したアプリケーション配備状態テーブル４２１上のアプリケーションＩＤのカラムの値が、本プログラムへの入力値として指定されたアプリケーションＩＤと一致し、さらにアプリケーションの状態のカラムの値が、「待機中」であるレコードを検索する。そして、その検索にヒットするレコードが存在するか否か、すなわち負荷が閾値を超えたアプリケーションが、負荷増大通知元サーバ以外のサーバに事前配備されているか否かを判断する。
そして、その判断の結果、前記検索にヒットしたレコードが存在する場合、すなわち事前配備されている場合（１８０１のＹｅｓ）には、検索にヒットしたレコード上の配備先サーバＩＤのカラムの値を取得し、ステップ１８０２に進む。他方、存在しない場合、すなわち事前配備されていない場合（１８０１のＮｏ）は、ステップ１８０３に進む。

ステップ１８０２では、図４に示したリクエスト分配制御プログラム４０６に、ステップ１８０１で取得したサーバＩＤ、および本プログラムへの入力値として指定されアプリケーションＩＤを入力値として渡して、リクエスト分配制御プログラム４０６が起動し、本プログラムを終了する。
ステップ１８０３では、図４に示したアプリケーション配備プログラム４０４に、本プログラムへの入力値として指定されたアプリケーションＩＤを入力値として渡して、アプリケーション配備プログラム４０４が起動し、戻り値としてサーバＩＤを受け取る。これにより、負荷が閾値を超えたアプリケーションＩＤのアプリケーションを、そのアプリケーションが配備されていないサーバに配備する。

ステップ１８０４では、図４に示したリクエスト分配制御プログラム４０６に、本プログラムへの入力値として指定されたアプリケーションＩＤ、およびステップ１８０３で起動したアプリケーション配備プログラム４０４の戻り値であるサーバＩＤを入力値として渡して、リクエスト分配制御プログラム４０６が起動し、本プログラムを終了する。

次に、前記した運用制御装置１０５やサーバＡ〜Ｃにおけるアプリケーション分配制御の全体的な処理手順を説明する。ここでは、サーバＡ，Ｂ，Ｃ上でアプリケーションＡ，Ｂ，Ｃがそれぞれ稼動している状況において、新規なアプリケーションＤをサーバＡに配備する場合を例に説明する。なお、アプリケーションＡ〜Ｄは、アプリケーションＩＤがそれぞれＡ〜Ｄであることを示している。

まず、アプリケーションＤをサーバＡに新規に配備し、その後、そのアプリケーションＤへのリクエスト分配開始までの処理の流れを図１９Ａに基づいて説明する。
図４に示した運用制御プログラム４０３が、オペレータの操作により起動されると、図４に示したアプリケーション配備プログラム４０４が起動する。ここでは、図４に示したＣＰＵ４３２がアプリケーション配備プログラム４０４を読み出して実行するものとする。
アプリケーション配備プログラム４０４は、各サーバＡ〜ＣのＣＰＵ利用率を取得し、その時点で最もＣＰＵ利用率の低いサーバ(例えばサーバＡ)にアプリケーションＤを新規に配備する（同図（１））。そして、アプリケーション配備状態テーブル４２１に、アプリケーションＩＤのカラムの値がＤ、配備先サーバＩＤのカラムの値がＡであるレコードを追加する（同図（２））。このとき、追加したレコードのアプリケーションの状態のカラムの値を「待機中」にする。

次に、運用制御プログラム４０３は、リクエスト分配制御プログラム４０６を起動する。リクエスト分配制御プログラム４０６は、負荷分散装置１０３の設定を変更して、サーバＡ上に配備されたアプリケーションＤへのリクエスト分配を開始する（同図（３））。そして、アプリケーション配備状態テーブル４２１上の同図（２）で追加したレコードのアプリケーションの状態のカラムの値を「稼動中」に更新する（同図（４））。

次に、運用制御装置１０５のＣＰＵ４３２が、負荷テスト実行プログラム４０７を用いて負荷テストを実施し、事前配備を行う。この処理の流れを図１９Ｂに基づいて説明する。まず、運用制御プログラム４０３は、アプリケーションＤの新規配備先サーバＡを負荷テスト対象サーバに指定して、図４に示したアプリケーション事前配備制御プログラム４０５を起動する。

アプリケーション事前配備制御プログラム４０５は、アプリケーション配備状態テーブル４２１を参照し、サーバＡ上に配備されているアプリケーションの中で、最も配備時間が新しいアプリケーションＤを負荷テスト対象に指定し、負荷テスト実行プログラム４０７を起動する。そして、アプリケーションＤの負荷テストを開始する（同図（５））。負荷テスト実行プログラム４０７は、負荷テストを開始すると、図４に示した負荷テスト対象サーバ情報４１０に負荷テスト対象サーバＡのサーバＩＤ（「Ａ」）を書き込む。

図４に示したイベント受信プログラム４０１が、負荷テスト実施中であるサーバＡ上のアプリケーションＤの負荷増大通知を受信する（同図（６））。負荷テストの結果、アプリケーションＤの負荷（レスポンスタイム）は、予め設定された閾値を超えたものとする。そして、図４に示した負荷テスト不合格アプリケーション情報４１１に負荷が閾値を超えたアプリケーションのアプリケーションＩＤ（「Ａ」）を書き込む。

次に、アプリケーション事前配備制御プログラム４０５は、負荷テスト不合格アプリケーション情報４１１にデータが存在することを検知し、負荷テスト強制終了フラグ４１２をＯＮにし、負荷テストを終了させる。次に、アプリケーション事前配備制御プログラム４０５は、負荷テストに不合格であったアプリケーションＩＤのアプリケーションを、サーバＡ以外の他のサーバに事前配備するため、アプリケーション配備プログラム４０４を起動する。

アプリケーション配備プログラム４０４は、他のサーバのＣＰＵ利用率を取得し、その時点でＣＰＵ利用率の最も低いサーバＢに、アプリケーションＤを事前配備する（同図（７））。そして、アプリケーション配備状態テーブル４２１に、アプリケーションＩＤのカラムの値がＤ、配備先サーバＩＤのカラムの値がＢであるレコードを追加し、そのレコードのアプリケーションの状態のカラムの値を「待機中」とする（同図（８））。

事前配備終了後、アプリケーション事前配備制御プログラム４０５は、事前配備先サーバＢを負荷テスト対象サーバとしてアプリケーション事前配備制御プログラム４０５を再帰的に呼び出す。再帰的に呼び出されたアプリケーション事前配備制御プログラム４０５は、まず、サーバＢ上の事前配備アプリケーションＤの負荷テストを実施する（同図（９））。

そして、その負荷テストの結果、アプリケーションＤの負荷（レスポンスタイム）は、予め設定された閾値を超えなかったものとすると、イベント受信プログラム４０１は、前記の負荷テスト実施中に負荷増大通知を受信しないため、サーバＢ上のアプリケーションＤ以外のアプリケーションＢの負荷テストを実施する（同図（１０））。そして、この負荷テストの結果、例えば、アプリケーションＢの負荷（レスポンスタイム）が、予め設定された閾値を超えなかった場合、イベント受信プログラム４０１は、アプリケーションＢの負荷テスト実施中に負荷増大通知を受信しないため、再帰的に呼び出されたアプリケーション事前配備制御プログラム４０５は処理を終了する。そして、呼び出し元のアプリケーション事前配備制御プログラム４０５に戻る。

呼び出し元のアプリケーション事前配備制御プログラム４０５は、サーバＡ上で、まだ負荷テストを実施しないで、かつアプリケーションの状態が「強制配備中」でないアプリケーションＡの負荷テストを実施する（同図（１１））。
この負荷テストの結果、例えば、アプリケーションＡの負荷（レスポンスタイム）が、予め設定された閾値を超えなかった場合、イベント受信プログラム４０１は、負荷テスト実施中に負荷増大通知を受信しないため、サーバＡ上の強制配備ではない全てのアプリケーションの負荷テストが終了する。そして、アプリケーション事前配備制御プログラム４０５が終了する。
このように、負荷テストに不合格となったアプリケーション(本例ではアプリケーションＤ)のみ事前配備が行われるため、無駄な計算機資源の使用を抑えながら、アプリケーションへの急激な負荷増大への対処の準備が可能となる。

次に、例えば、クライアントからのリクエストが集中したことにより、アプリケーションＤの負荷が閾値を超えた場合の処理の流れを図１９Ｃに基づいて説明する。ここでの「クライアント」とは、例えば、図１に示したクライアント群を指しており、以下同じ意味で用いる。
サーバＡ上で稼動中のアプリケーションＤに対するクライアントからのリクエストが集中した場合（同図（１２））、サーバＡ上のアプリケーションＤの負荷増大通知をイベント受信プログラム４０１が受信する（同図（１３））。イベント受信プログラム４０１は、負荷テストが終了して負荷テスト対象サーバ情報４１０にデータが存在しないため、すなわち、どのサーバでも負荷テストが実施されていないため、負荷増大通知元サーバのサーバＩＤ（「Ａ」）、および負荷が閾値を超えたアプリケーションのアプリケーションＩＤ（「Ｄ」）を入力として負荷分散制御プログラム４０２を起動する。

負荷分散制御プログラム４０２は、まず、アプリケーション配備状態テーブル４２１を参照し、アプリケーションＤがサーバＢに事前配備されていることを検出する（同図（１４））。次に、サーバＢ上に事前配備されているアプリケーションＤへのリクエスト分配を開始するため、図４に示したリクエスト分配制御プログラム４０６を起動する。リクエスト分配制御プログラム４０６は、負荷分散装置１０３の設定を変更してサーバＢ上のアプリケーションＤへのリクエストの分配を開始させる（同図（１５））。

そして、サーバＢ上のアプリケーションＤが稼動すると、アプリケーションＤへのリクエストが、２台のサーバＡ，Ｂ間で分散される（同図（１６））。そして、アプリケーション配備状態テーブル２１１上のアプリケーションＩＤのカラムの値がＤ、配備先サーバＩＤのカラムの値がＢであるレコード上のアプリケーションの状態を「待機中」から「稼動中」に更新する（同図（１７））。

このように、アプリケーションＤは事前配備済みであったため、アプリケーションの配備や起動等の処理に時間を要することなく、負荷分散装置１０３の設定変更のみで、アプリケーションＤへのリクエストを処理するサーバを追加することができる。

[第２実施形態]
本発明の第２実施形態について説明する。
図２０は、第２実施形態の運用制御装置１０５の構成を示すブロック図である。なお、第１実施形態と同一部分には同一符号を付して重複説明を省略する。
図２０では、運用制御プログラム２００１およびアプリケーション事前配備制御プログラム２００２が、第１実施形態の場合と処理手順が異なっている。また、テスト実施状況管理テーブル２００３および負荷テストスケジュール管理テーブル２００４が、第１実施形態の場合と異なり追加されている。その他の運用制御装置１０５を含む全体システムの構成は第１実施形態と同様である。

まず、テスト実施状況管理テーブル２００３の構成例を図２１に基づいて説明する。
テスト実施状況管理テーブル２００３には、サーバＩＤ、およびテスト実施状況が格納されている。テスト実施状況とは、負荷テストの実施の有無を指し、ここでは「テスト済み」と「テスト未実施」の２つの状態がある。「テスト済み」は、サーバＡ〜Ｃのテストが済んだ状態を表し、「テスト未実施」はサーバのテストが未実施であることを表す。このように構成することにより、運用管理装置１０５が管理しているサーバＡ〜Ｃの負荷テストの実施状況を管理することが可能となる。

次に、負荷テストスケジュール管理テーブル２００４の構成例を図２２に基づいて説明する。
負荷テストスケジュール管理テーブル２００４には、負荷テスト実施時刻が格納されている。負荷テスト実施時刻は、負荷テストを実施する時刻を指し、先頭レコードから時間順に格納されている。

次に、アプリケーション事前配備制御プログラム２００２の処理手順を図２３Ａおよび図２３Ｂに基づいて説明する。アプリケーション事前配備制御プログラム２００２は、負荷テスト対象のサーバのサーバＩＤを入力値として起動される。
このアプリケーション事前配備制御プログラム２００２の処理手順では、図１５Ａおよび図１５Ｂに示したステップ１５０１〜１５１６に、ステップ２３０１〜ステップ２３０４を追加した点が図１５Ａおよび図１５Ｂの場合と異なる。そこで以下では、ステップ２３０１〜２３０４について説明する。

図２３Ａのステップ２３０１では、アプリケーション配備状態テーブル４２１上のアプリケーションＩＤのカラムの値が、ステップ１５０２で選択したアプリケーションのアプリケーションＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードのうち、アプリケーションの状態のカラムの値が「待機中」であるレコードが存在するか否か、すなわち、他のサーバへ事前配備されているか否かを判断する。
そして、その判断の結果、前記レコードが存在し、他のサーバへ事前配備されている場合（２３０１のＹｅｓ）には、図２３Ｂのステップ１５１５に進む。他方、存在せず、他のサーバへ事前配備されていない場合（２３０１のＮｏ）には、ステップ１５０４に進む。これにより、ステップ１５０２で負荷テスト対象に選択したアプリケーションが、他のサーバへ事前配備されているか否かを判断し、その判断の結果、事前配備されているサーバが存在する場合は、前記アプリケーションについての負荷テストを実施しないことになる。

次に、図２３Ｂのステップ２３０２では、アプリケーション配備状態テーブル４２１（図５参照）上のアプリケーションＩＤのカラムの値が、負荷テスト不合格アプリケーション情報４１１に書かれているアプリケーションＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードのうち、アプリケーションの状態のカラムの値が「待機中」であるレコードが存在するか否かを判断する。
そして、その判断の結果、前記レコードが存在し、他のサーバへ事前配備されていると判断された場合（２３０２のＹｅｓ）には、ステップ２３０３に進む。他方、存在せず、事前配備されていないと判断された場合（２３０２のＮｏ）には、ステップ１５１２に進む。ここで、前記したレコードが存在する場合というのは、負荷テスト対象となっているアプリケーションの負荷テスト中に、当該サーバに配備されている負荷テスト対象アプリケーション以外のアプリケーションの負荷が閾値を超え、かつ当該アプリケーションが、当該アプリケーションが配備されているサーバ以外のサーバへ事前配備されている場合を意味する。このような場合、事前配備は行わない。

ステップ２３０３では、負荷テスト不合格アプリケーション情報４１１からデータを削除する。
ステップ２３０４では、テスト実施状況管理テーブル２００３上で、負荷テスト対象サーバのサーバＩＤのレコードのテスト実施状況のカラムの値を「テスト済み」に更新する。
ここで、オペレータが行う事前準備を説明する。オペレータは、第１実施形態における事前準備に加え、テスト実施状況管理テーブル２００３に、サーバＩＤのカラムに各サーバＩＤ、テスト実施状況のカラムの値を、全て「テスト未実施」に設定する。そして、負荷テストスケジュール管理テーブル２００４に負荷テストを実施する時刻を時間順に設定する。

次に、運用制御プログラム２００１の処理手順を図２４に基づいて説明する。運用制御プログラム２００１は、オペレータの操作により起動される。
ステップ２４０１では、負荷テストスケジュール管理テーブル２００４にレコードが存在するか否かを判断することにより、全てのスケジュールが終了したか否かを判断する。そして、レコードが存在し、全てのスケジュールが終了していないと判断された場合（２４０１のＮｏ）は、ステップ２４０２に進む。他方、レコードが存在せず、全てのスケジュールが終了していると判断された場合（２４０１のＹｅｓ）には、本プログラムを終了する。

ステップ２４０２では、負荷テストスケジュール管理テーブル２００４の先頭レコードの負荷テスト実施時刻のカラムの値を取得する。つまり、次に負荷テストを実施する時刻を取得する。
ステップ２４０３では、テスト実施状況管理テーブル２００３の先頭レコードのサーバＩＤのカラムの値を取得してそのサーバを選択し、ワークエリア４０９に保存する。
ステップ２４０４では、現在の時刻を取得し、それがステップ２４０２で取得した時刻と一致するか否かを判断することにより、負荷テスト実施時間になったか否かを判断する。そして、その判断の結果、双方の時刻が一致せず、負荷テスト実施時間になっていないと判断した場合（２４０４のＮｏ）は、ステップ２４０４を繰り返す。他方、双方の時刻が一致して、負荷テスト実施時間になったと判断した場合（２４０４のＹｅｓ）は、２００５に進む。

ステップ２４０５では、アプリケーション事前配備制御プログラム２００２に、ステップ２４０３でワークエリアに保存したサーバＩＤを入力値として渡して、アプリケーション事前配備制御プログラム２００２が起動する。アプリケーション事前配備制御プログラム２００２は、指定されたサーバＩＤに該当するサーバの負荷テストを実施して、テスト実施状況管理テーブル２００３上のテスト実施状況のカラムの値を「テスト済み」に更新する。ただし、負荷テストの結果に応じて事前配備を行い、サーバＡ〜Ｃのうち、事前配備先に選択されたサーバの負荷テストを実施するため、テスト実施状況管理テーブル２００３の二つ以上のレコードを更新する場合もある。

ステップ２４０６では、全てのサーバＡ〜Ｃの負荷テストが終了したか否かを判断する。具体的には、テスト実施状況管理テーブル２００３上のテスト実施状況のカラムの値が「テスト未実施」であるレコードを検索する。そして、その検索にヒットしたレコードが存在し、全てのサーバの負荷テストが終了していないと判断された場合（２４０６のＮｏ）は、ステップ２４０７に進む。他方、レコードが存在せず、全てのサーバの負荷テストが終了したと判断された場合（２４０７のＹｅｓ）には、ステップ２４０８に進む。

ステップ２４０７では、テスト実施状況管理テーブル２００３上のテスト実施状況のカラムの値が「テスト未実施」であるレコードを検索する。そして、その検索にヒットした全てのレコードの中から任意に一つを選択し、前記レコードのサーバＩＤのカラムの値を取得し、ステップ２４０３で保存したワークエリア４０９へ上書きしてステップ２４０５に戻る。

ステップ２４０８では、テスト実施状況管理テーブル２００３上の全てのテスト実施状況のカラムの値を初期化、すなわち「テスト未実施」に更新する。
ステップ２４０９では、負荷テストスケジュール管理テーブル２００４の先頭レコードを削除し、ステップ２４０１に戻る。
このように、スケジュールに従って負荷テストを行い、運用状況に合わせてアプリケーションを事前配備することも可能である。

[第３実施形態]
本発明の第３実施形態について説明する。
図２５は、第３実施形態の運用制御装置１０５の機能構成を示すブロック図である。なお、第１実施形態と同一部分には同一符号を付して重複説明を省略する。
図２５では、アプリケーション事前配備制御プログラム２５０１が、第１実施形態の場合と処理が異なっている。その他の運用制御装置１０５を含む全体システムの構成は第１実施形態と同様である。

次に、アプリケーション事前配備制御プログラム２５０１の処理手順を図２６Ａおよび図２６Ｂに基づいて説明する。アプリケーション事前配備制御プログラム２５０１の処理手順は、図１５Ａおよび図１５Ｂに示したステップ１５０１〜１５１６に、ステップ２６０１〜ステップ２６０４を追加した点が、図１５Ａおよび図１５Ｂと異なる。そこで以下に、ステップ２６０１〜２６０４を中心に説明する。
図２６Ａのステップ１５０５において、負荷テスト中に負荷テスト対象アプリケーションの負荷増大通知を受信しなかったため、負荷テスト対象サーバ情報４１０にデータが存在しなかった場合（１５０５のＮＯ）、ステップ２６０１に進む。

ステップ２６０１では、アプリケーション配備状態テーブル４２１上のアプリケーションＩＤのカラムの値が、ステップ１５０２で選択したアプリケーションのアプリケーションＩＤと一致し、さらにアプリケーションの状態のカラムの値が、「待機中」であるレコードが存在するか否かを判断する。つまり、他のサーバに事前配備されているかどうかを判断する。
そして、その判断の結果、他のサーバに事前配備されていると判断した場合（２６０１のＹｅｓ）には、前記レコードの配備先サーバＩＤのカラムの値を取得してステップ２６０２に進み、他方、事前配備されていないと判断した場合（２６０１のＮｏ）には、図２６Ｂのステップ１５１５に進む。

ステップ２６０２では、事前配備されているサーバのＩＰアドレスを取得する。具体的には、サーバＩＰアドレス管理テーブル４２２上のサーバＩＤのカラムの値が、ステップ２６０１で事前配備されていると判断されたサーバのサーバＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードのＩＰアドレスのカラムの値を取得する。

ステップ２６０３では、事前配備アプリケーションの削除を要求する。具体的には、ステップ２６０２で取得したＩＰアドレスに該当するサーバ上のアプリケーション実行プログラムに、アプリケーション削除要求コマンドと、当該コマンドの引数としてステップ１５０２で選択したアプリケーションのアプリケーションＩＤとを送信する。
ステップ２６０４では、アプリケーション配備状態テーブル４２１上の配備先サーバＩＤのカラムの値、およびアプリケーションＩＤのカラムの値が、それぞれステップ２２０１で取得したサーバＩＤ、およびステップ１５０２で選択したアプリケーションＩＤと一致するレコードを検索する。そして、その検索にヒットしたレコードを削除し、図２６Ｂのステップ１５１５に進む。

このように、事前配備されているアプリケーションを適宜削除することによって、計算機資源を有効に活用することができる。

なお、本発明は、前記した実施形態に限られない。例えば、本実施形態は、事前配備を行う否かの判断をするアプリケーションの負荷の閾値と、事前配備されているアプリケーションの削除を行うか否かを判断するアプリケーションの負荷の閾値とが同一である場合について説明したが、それぞれの閾値を異なる値に設定し（例えば、事前配備を行うか否かを判断する閾値はレスポンスタイム５．０秒とし、削除を行うか否かを判断するための閾値はレスポンスタイム６．０秒と設定する。）、適用するようにしてもよい。

また、ＣＰＵ利用率に基づいて、アプリケーションを配備するサーバを選択することとして説明したが、例えば、メモリの使用率やディスクＩＯの速度に基づいてサーバを選択してもよい。さらに、それらの異なる基準を組み合わせて、サーバを選択してもよい。

また、ネットワーク環境下にあるサーバにより負荷テストを行うことにより、新規配備または事前配備（強制配備を含む）を行う場合について説明したが、ネットワーク環境下にないコンピュータに負荷テストを行って、その結果、負荷が最も低いコンピュータにアプリケーションを新規配備または事前配備（強制配備を含む）するようにしてもよい。

さらに、運用制御装置１０５を含むシステム全体の構成およびデータ構成は、本発明の趣旨を逸脱しない限り、種々の変更が可能である。例えば、複数のコンピュータを用いて分散することにより、運用制御装置１０５を構築するようにしてもよい。また、運用制御装置１０５と負荷分散装置１０３とを１台のコンピュータで構築するようにしてもよい。

第１実施形態のクライアントサーバシステムの全体構成図である。 図１に示したリクエスト分配先情報管理テーブルの構成例を示す図である。 図１に示した閾値テーブルの構成例を示す図である。 図１に示した運用制御装置の構成を示すブロック図である。 図４に示したアプリケーション配備状態テーブルの構成例を示す図である。 図４に示したサーバＩＰアドレス管理テーブルの構成例を示す図である。 図４に示した負荷テスト設定情報テーブルの構成例を示す図である。 図４に示したアプリケーション格納場所管理テーブルの構成例を示す図である。 図４に示した運用制御プログラムの処理手順を示すフローチャートである。 図４に示したアプリケーション配備プログラムの処理手順を示すフローチャートである。 図４に示したアプリケーション配備プログラムの処理手順を示すフローチャートである。 図４に示したアプリケーション配備プログラムの処理手順を示すフローチャートである。 図１に示したサーバ性能情報収集プログラムの処理手順を示すフローチャートである。 図１に示したアプリケーション実行プログラムの処理手順を示すフローチャートである。 図４に示したリクエスト分配制御プログラムの処理手順を示すフローチャートである。 図１に示したリクエスト分配先設定プログラムの処理手順を示すフローチャートである。 図４に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。 図４に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。 図４に示した負荷テスト実行プログラムの処理手順を示すフローチャートである。 図４に示したイベント受信プログラムの処理手順を示すフローチャートである。 図４に示した負荷分散制御プログラムの処理手順を示すフローチャートである。 第１実施形態のアプリケーション分配制御の全体的な処理手順を示すフローチャートである。 第１実施形態のアプリケーション分配制御の全体的な処理手順を示すフローチャートである。 第１実施形態のアプリケーション分配制御の全体的な処理手順を示すフローチャートである。 第２実施形態の運用制御装置の構成を示すブロック図である。 図２０に示したテスト実施状況管理テーブルの構成例を示す図である。 図２０に示した負荷テストスケジュール管理テーブルの構成例を示す図である。 図２０に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。 図２０に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。 図２０に示した運用制御プログラムの処理手順を示すフローチャートである。 第３実施形態の運用制御装置の構成を示すブロック図である。 図２５に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。 図２５に示したアプリケーション事前配備制御プログラムの処理手順を示すフローチャートである。

符号の説明

１０１Ａ〜１０１Ｃ・・・クライアント、１０２・・・ネットワーク１、１０３・・・負荷分散装置、１０４Ａ〜１０４Ｃ・・・サーバ、１０５・・・運用制御装置、１０６・・・ネットワーク２、１５１Ａ〜１５１Ｃ・・・アプリケーション実行プログラム、１５２Ａ〜１５２Ｃ・・・アプリケーション監視プログラム、１５３Ａ〜１５３Ｃ・・・サーバ性能情報収集プログラム、１５４Ａ〜１５４Ｃ・・・閾値テーブル、１６１・・・リクエスト分配先設定プログラム、１６２・・・リクエスト分配先情報管理テーブル、１６３・・・負荷分散プログラム、４３１・・・通信制御装置、４３２・・・中央演算装置、４３３・・・ディスプレイ、４３４・・・キーボード、４３５・・・ＣＤ−ＲＯＭドライブ装置、４３６・・・システムバス、４００・・・１次記憶装置、４０１・・・イベント受信プログラム、４０２・・・負荷分散制御プログラム、４０３・・・運用制御プログラム、４０４・・・アプリケーション配備プログラム、４０５・・・アプリケーション事前配備制御プログラム、４０６・・・リクエスト分配制御プログラム、４０７・・・負荷テスト実行プログラム、４０８・・・システムプログラム、４０９・・・ワークエリア、４１０・・・負荷テスト対象サーバ情報、４１１・・・負荷テスト不合格アプリケーション情報、４１２・・・負荷テスト強制終了フラグ、４２１・・・アプリケーション配備状態テーブル、４２２・・・サーバＩＰアドレス管理テーブル、４２３・・・負荷テスト設定情報テーブル、４２４・・・アプリケーション格納場所管理テーブル

Claims (8)

1. クライアントからのアプリケーションへの要求に従って複数のサーバ間で負荷分散制御を行うアプリケーション運用制御システムにおけるアプリケーション運用制御方法であって、
   前記アプリケーション運用制御システムに用いられる運用制御装置は、前記アプリケーションを記憶する記憶装置と、前記アプリケーションの配備を制御する処理装置とを備え、
   前記処理装置は、
   前記複数のサーバのうちの所定のサーバに配備または事前配備されている特定のアプリケーションに対して、テスト用のリクエストを送信させる負荷テストを実行し、前記負荷テストで不合格となった場合、当該アプリケーションに対するテスト用のリクエストの送信を停止させて負荷テストを停止し、当該アプリケーションを記憶装置から読み出して、前記複数のサーバのうちの他のサーバに事前配備し、稼動待機中とする負荷テストステップと、
   前記負荷テストステップを実行中の前記所定のサーバ以外のサーバから負荷増大通知を受け付けたとき、前記事前配備した稼動待機中のアプリケーションを、前記事前配備したサーバ上で稼動させる稼動ステップと、
   を実行することを特徴とするアプリケーション運用制御方法。
2. 前記処理装置は、前記負荷テストで不合格となったアプリケーションを前記他のサーバに事前配備した後に、前記事前配備先のサーバに対して、前記負荷テストステップを再帰的に実行させること
   を特徴とする請求項１に記載のアプリケーション運用制御方法。
3. 前記処理装置は、前記負荷テストステップを実行する前記所定のサーバに配備または事前配備されている複数のアプリケーションについて、配備された時間が早いアプリケーションから順に、特定のアプリケーションとして負荷テストを実施すること
   を特徴とする請求項１または請求項２に記載のアプリケーション運用制御方法。
4. 前記処理装置は、前記負荷テストステップを実行する前記所定のサーバに対して、アプリケーションが配備または事前配備されたタイミングで、負荷テストを実施すること
   を特徴とする請求項３に記載のアプリケーション運用制御方法。
5. クライアントからのアプリケーションへの要求に従って複数のサーバ間で負荷分散制御を行うアプリケーション運用制御システムであって、
   前記アプリケーション運用制御システムに用いられる運用制御装置は、前記アプリケーションを記憶する記憶装置と、前記アプリケーションの配備を制御する処理装置とを備え、
   前記処理装置は、
   前記複数のサーバのうちの所定のサーバに配備または事前配備されている特定のアプリケーションに対して、テスト用のリクエストを送信させる負荷テストを実行し、前記負荷テストで不合格となった場合、当該アプリケーションに対するテスト用のリクエストの送信を停止させて負荷テストを停止し、当該アプリケーションを記憶装置から読み出して、前記複数のサーバのうちの他のサーバに事前配備し、稼動待機中とする負荷テストステップと、
   前記負荷テストステップを実行中の前記所定のサーバ以外のサーバから負荷増大通知を受け付けたとき、前記事前配備した稼動待機中のアプリケーションを、前記事前配備したサーバ上で稼動させる稼動ステップと、
   を実行することを特徴とするアプリケーション運用制御システム。
6. 前記処理装置は、前記負荷テストで不合格となったアプリケーションを前記他のサーバに事前配備した後に、前記事前配備先のサーバに対して、前記負荷テストステップを再帰的に実行させること
   を特徴とする請求項５に記載のアプリケーション運用制御システム。
7. 前記処理装置は、前記負荷テストステップを実行する前記所定のサーバに配備または事前配備されている複数のアプリケーションについて、配備された時間が早いアプリケーションから順に、特定のアプリケーションとして負荷テストを実施すること
   を特徴とする請求項５または請求項６に記載のアプリケーション運用制御システム。
8. 前記処理装置は、前記負荷テストステップを実行する前記所定のサーバに対して、アプリケーションが配備または事前配備されたタイミングで、負荷テストを実施すること
   を特徴とする請求項７に記載のアプリケーション運用制御システム。
   

Images