JP2014052680A - プロセス数制御プログラム、プロセス数制御方法、および情報処理装置 - Google Patents

Abstract

【課題】プロセス数変動について負荷の急激な変化に対する追随性を向上して、リソースを有効に活用する。
【解決手段】情報処理装置１は、サービス要求の受付に先立ち、所要数（２以上のＮ個）のプロセス３をあらかじめ起動する。情報処理装置１は、第１のプログラム４からプロセス３を起動する。第１のプログラム４は、異なるサービス要求に対応する複数種類のプログラムに共通の実行基盤となるプロセス３を起動するプログラムである。プロセス３は、記憶領域５の割当を受けて、記憶領域５にサービスに応じたプログラム（第２のプログラム６）を展開可能にし、展開したプログラムの展開を解除可能にしている。情報処理装置１は、第２のプログラム６を展開しているプロセス３の負荷を監視して、負荷量に応じて制御対象プロセス数の増減を制御する。
【選択図】図１

Description

本発明は、プロセス数制御プログラム、プロセス数制御方法、および情報処理装置に関する。

クライアントからのサービス要求が高負荷の場合、アプリケーションのプロセス多重度を調整することで、サービス要求に応えるサーバシステムがある。このようなサーバシステムは、サービス要求に対するレスポンス時間や、あらかじめ見積もった時間あたりのサービス要求数から、アプリケーションのプロセス多重度を調整する。

アプリケーションのプロセス多重度の調整は、システム管理者により手動でおこなうことができる。また、サービス要求の負荷状態を監視して自動でプロセス多重度の調整をおこなうことができるサーバシステムの提案もある。

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

しかしながら、プロセス多重度の調整は、サービス要求の負荷ピークに合わせておこなう必要があるものの、負荷ピークの適切な見積りは困難である。
また、プロセス多重度の調整は、プロセスの起動と停止にかかるコストが高く、負荷の急激な変化に対して追随が困難である。

このように、プロセス多重度の調整は、負荷ピークの見積りの困難さと、負荷の急激な変化に対する追随の困難さとから、未だ多くの時間でリソースを無駄に消費している。
１つの側面では、本発明は、負荷の急激な変化に対する追随性を向上して、リソースを有効に活用可能なプロセス数制御プログラム、プロセス数制御方法、および情報処理装置を提供することを目的とする。

上記目的を達成するために、アプリケーションプロセスの多重度を動的に制御するプロセス数制御プログラム、およびプロセス数制御方法が提供される。プロセス数制御プログラム、およびプロセス数制御方法は、以下に示すような処理をコンピュータに実行させる。コンピュータは、第１のプログラムからＮ（２以上）個のプロセスを起動し、Ｎ個のプロセスのうちの１のプロセスに対応する記憶領域への第２のプログラムの展開と、記憶領域への第２のプログラムの展開の解除とにより、第２のプログラムを展開したプロセスの数の変動をＮ個の範囲内で第２のプログラムを展開したプロセスの負荷に応じて制御する。

また、上記目的を達成するために、以下に示すような、情報処理装置が提供される。情報処理装置は、制御部を備える。制御部は、第１のプログラムからＮ（２以上）個のプロセスを起動し、Ｎ個のプロセスのうちの１のプロセスに対応する記憶領域への第２のプログラムの展開と、記憶領域への第２のプログラムの展開の解除とにより、第２のプログラムを展開したプロセスの数の変動をＮ個の範囲内で第２のプログラムを展開したプロセスの負荷に応じて制御する。

１態様によれば、プロセス数制御プログラム、プロセス数制御方法、および情報処理装置において、負荷の急激な変化に対する追随性を向上して、リソースを有効に活用できる。

第１の実施形態の情報処理装置の構成例を示す図である。 第２の実施形態のアプリケーションサーバとクライアント端末の接続例を示す図である。 第２の実施形態のアプリケーションサーバの構成例を示す図である。 第２の実施形態の業務アプリの入れ替え前の配置例を示す図である。 第２の実施形態の業務アプリの入れ替え後の配置例を示す図である。 第２の実施形態のアプリケーションサーバのハードウェア構成例を示す図である。 第２の実施形態の第１プロセス管理処理のフローチャートである。 第２の実施形態の設定テーブルの一例である。 第２の実施形態のプロセス管理テーブルの一例である。 第２の実施形態の第１返却処理のフローチャートである。 第２の実施形態の第１配備処理のフローチャートである。 第３の実施形態の第２プロセス管理処理のフローチャートである。 第３の実施形態の設定テーブルの一例である。 第３の実施形態の第２返却処理のフローチャートである。 第３の実施形態の第２配備処理のフローチャートである。

以下、実施の形態を図面を参照して詳細に説明する。
［第１の実施形態］
まず、第１の実施形態の情報処理装置について図１を用いて説明する。図１は、第１の実施形態の情報処理装置の構成例を示す図である。

情報処理装置１は、クライアント端末からのサービス要求に応じてサービス応答をおこなう。情報処理装置１は、サービスに応じたプログラムの実行によりサービス応答をおこなう。また、情報処理装置１は、複数のサービス要求に対応するため、プログラムの実行単位となるプロセス３を複数起動する。

情報処理装置１は、第１のプログラム４からプロセス３を起動する。第１のプログラム４は、異なるサービス要求に対応する複数種類のプログラムに共通の実行基盤となるプロセス３を起動するプログラムである。たとえば、第１のプログラム４は、所要のリソースの割当、所要のライブラリのマッピングなどをおこない、プロセス３を起動する。図１に示す例では、情報処理装置１は、第１のプログラム４から、Ｎ個のプロセス３（プロセス３１，３２，３３，…，３Ｎ）を起動する。

このように、情報処理装置１は、サービス要求の受付に先立ち、所要数（２以上のＮ個）のプロセス３をあらかじめ起動する。たとえば、所要数は、あらかじめ設定した数、情報処理装置１が利用可能な資源量に応じて決定される数などがある。したがって、情報処理装置１は、第１のプログラム４によるプロセス３の起動にかかる処理コストを、クライアント端末からのサービス要求前に負担する。

プロセス３は、記憶領域５の割当を受けて、記憶領域５にサービスに応じたプログラム（第２のプログラム６）を展開可能にしている。たとえば、プロセス３１，３２は、記憶領域５に第２のプログラム６ａを展開する。また、プロセス３は、記憶領域５に展開したプログラムの展開を解除可能にしている。たとえば、プロセス３３は、記憶領域５に展開していた第２のプログラム６ｂの展開を解除する。

このとき、情報処理装置１は、複数種類のプログラムに共通の実行基盤としてプロセス３を起動しているため、第２のプログラム６の展開と解除にかかる処理コストを軽減可能にしている。したがって、情報処理装置１は、記憶領域５に第２のプログラム６を展開するプロセス３の数（制御対象プロセス数）を、小さなコストで制御可能にしている。

情報処理装置１は、第２のプログラム６を展開しているプロセス３を複数にして、サービス要求を同時に処理できるプロセス多重度を設定する。時間あたりのクライアント端末からのサービス要求は、一定でなく変動するため、情報処理装置１は、第２のプログラム６を展開しているプロセス３の多重度を動的に制御する。

情報処理装置１は、第２のプログラム６を展開しているプロセス３の負荷を監視して、負荷量に応じて制御対象プロセス数の増減を制御する。制御対象プロセス数は、あらかじめ起動したプロセス３の数であるＮ個の範囲内で制御可能である。情報処理装置１は、たとえば、第２のプログラム６を展開しているプロセス３のうち、サービス要求にかかる処理を実行中のプロセス３の数あるいは割合などに応じて、第２のプログラム６を展開しているプロセス３にかかる負荷を検出することができる。

したがって、情報処理装置１は、第２のプログラム６を展開しているプロセス３の負荷変動に対する多重度制御の追随性を向上することができ、さらに、負荷軽減によるリソースの有効活用を図ることができる。

［第２の実施形態］
次に、第２の実施形態のアプリケーションサーバとクライアント端末の接続について図２を用いて説明する。図２は、第２の実施形態のアプリケーションサーバとクライアント端末の接続例を示す図である。

アプリケーションサーバ１０は、ネットワーク１１を介して複数のクライアント端末１２と接続する。アプリケーションサーバ１０は、たとえば、クライアント端末１２からのリクエスト（サービス要求）に応じてレスポンス（サービス応答）をおこなう。

次に、第２の実施形態のアプリケーションサーバの構成について図３を用いて説明する。図３は、第２の実施形態のアプリケーションサーバの構成例を示す図である。
アプリケーションサーバ１０は、クライアント端末１２からのサービス要求に応じてサービス応答をおこなう。アプリケーションサーバ１０は、クライアント端末１２に対して業務Ａにかかるサービスと、業務Ｂにかかるサービスとを提供する。業務Ａにかかるサービスは、業務アプリＡ１７が実行する処理により提供され、業務Ｂにかかるサービスは、業務アプリＢ２０が実行する処理により提供される。

アプリケーションサーバ１０は、実行単位となる業務アプリＡ１７、業務アプリＢ２０により、クライアント端末１２からのサービス要求に対する処理を実行する。アプリケーションサーバ１０は、複数のクライアント端末１２からのサービス要求を同時に処理するため、業務アプリＡ１７、業務アプリＢ２０を複数配備する。

業務アプリＡ１７は、あらかじめ起動されたプロセスであるアプリ実行基盤１５に対応するメモリに業務アプリケーションＡ（プログラム）１８が展開されている。業務アプリＢ２０は、アプリ実行基盤１５に割り当てられているメモリに業務アプリケーションＢ（プログラム）１９が展開されている。

アプリ実行基盤１５は、所要のリソースを確保した起動状態のプロセスである。アプリ実行基盤１５は、所要数が起動され、プール１４にプールされた状態（プール状態）としてマネージャ１３に管理される。アプリ実行基盤１５は、アプリケーションサーバで保持するロジック（フレームワーク、ライブラリのモジュールなどの汎用部分を含む）を用いて、業務アプリ（業務アプリＡ１７、業務アプリＢ２０）の実行環境基盤を構築する。アプリ実行基盤１５は、たとえば、Ｊａｖａ（登録商標） ＶＭ（ヴァーチャルマシン）により実現する。

業務アプリケーション（業務アプリケーションＡ１８、業務アプリケーションＢ１９）は、アプリ実行基盤１５に割り当てられているメモリに展開される業務アプリに固有のプログラムである。

アプリケーションサーバ１０は、業務アプリのプロセス多重度を制御するマネージャ１３を備える。マネージャ１３は、共有メモリ１６を備える。マネージャ１３は、すべての業務アプリのプロセス同時処理数の最大数のアプリ実行基盤１５を起動して、起動したアプリ実行基盤１５をプール１４で管理する。プール１４は、業務アプリケーションをメモリ上に展開していないアプリ実行基盤１５の数を管理する変数である。

マネージャ１３は、プール状態のアプリ実行基盤１５に割り当てられているメモリに、業務アプリケーションを展開して、業務アプリを配備する。マネージャ１３は、クライアント端末１２からアプリケーションサーバ１０へのサービス要求の数の変動に対応するため、変動に対して余裕のある多重度を業務アプリに設定する。

業務アプリは、クライアント端末１２からのサービス要求を受け付けると、マネージャ１３に負荷報告をおこなう。業務アプリは、サービス要求を処理中である旨の情報を共有メモリ１６の所定の記憶領域に記録することで、マネージャ１３への負荷報告とする。

マネージャ１３は、共有メモリ１６の所定の記憶領域から情報を読み出して、業務アプリの負荷を監視する。マネージャ１３は、業務アプリの負荷を監視して、業務アプリの多重度を制御する。マネージャ１３は、業務アプリの多重度の余裕が過小であることを検出した場合、プール状態のアプリ実行基盤１５に割り当てられているメモリに、業務アプリケーションを展開して、業務アプリを配備する。また、マネージャ１３は、業務アプリの多重度の余裕が過大であることを検出した場合、アプリ実行基盤１５に割り当てられているメモリに展開されている業務アプリケーションの展開を解除して、業務アプリの配備を解除する。マネージャ１３は、業務アプリの配備を解除したアプリ実行基盤１５をプール状態とする。なお、マネージャ１３は、ＡＰＩ（Application Program Interface）により業務アプリの入替（配備と解除）をおこなうことができる。

たとえば、マネージャ１３は、業務アプリＡ１７および業務アプリＢ２０の負荷を監視する。マネージャ１３は、多重度「７」の業務アプリＡ１７のうち、使用中が業務アプリＡ１７ａの１つ、不使用中が業務アプリＡ１７ｂ，１７ｃの６つであることから、所定の基準にしたがい業務アプリＡ１７の多重度の余裕が過大であると判定する。マネージャ１３は、不使用中の業務アプリＡ１７ｃの配備を解除して、業務アプリケーションＡ１８の展開を解除したアプリ実行基盤１５をプール状態とする。

一方、マネージャ１３は、多重度「３」の業務アプリＢ２０のうち、使用中が業務アプリＢ２０ａの３つすべてであることから、所定の基準にしたがい業務アプリＢ２０の多重度の余裕が過小であると判定する。マネージャ１３は、プール状態のアプリ実行基盤１５のうち３つのプール状態を解除し、各アプリ実行基盤１５に割り当てられているメモリに業務アプリケーションＢ１９を展開して、業務アプリＢ２０ｂを配備する。

これにより、マネージャ１３は、業務アプリＡ１７および業務アプリＢ２０の多重度を適正な範囲に制御することができる。また、マネージャ１３は、起動状態のアプリ実行基盤１５に対する業務アプリケーションの展開により業務アプリを配備することができるので、配備にかかるコストを低減できる。また、マネージャ１３は、起動状態のアプリ実行基盤１５に対する業務アプリケーションの展開の解除と、アプリ実行基盤１５をプール状態にすることにより業務アプリの配備を解除することができるので、配備解除にかかるコストを低減できる。

したがって、アプリケーションサーバ１０は、業務アプリの配備と配備解除にかかるコストを低減しているため、業務アプリの負荷変動に対する高い即応性を有する。また、アプリケーションサーバ１０は、業務アプリケーションの迅速な入れ替えが可能であることから、複数種類の業務アプリの負荷変動に対しても高い即応性を有する。

また、アプリケーションサーバ１０は、管理者の作業によらずに業務アプリの配備と配備解除をおこなうことができるため、迅速に業務アプリの多重度を制御することができる。

次に、第２の実施形態の業務アプリの入れ替えについて図４、図５を用いて説明する。図４は、第２の実施形態の業務アプリの入れ替え前の配置例を示す図である。アプリケーションサーバ１０は、５つの業務アプリＡ１７と、２つの業務アプリＢ２０を配備している。業務アプリＡ１７は、４つが使用中（クライアント端末１２からのサービス要求を処理中）であり、１つが未使用中である。業務アプリＢ２０は、１つが使用中であり、１つが未使用中である。したがって、アプリケーションサーバ１０は、業務アプリＡ１７と業務アプリＢ２０は、１つずつが新たなサービス要求を受け付け可能である。

ここで、アプリケーションサーバ１０は、業務アプリＡ１７と業務アプリＢ２０の負荷に変動が生じた場合に、業務アプリの入れ替えをおこなう。たとえば、業務アプリＡ１７の負荷が急減し、業務アプリＢ２０の負荷が急増した場合に、アプリケーションサーバ１０は、図５に示すような業務アプリの入れ替えをおこなう。図５は、第２の実施形態の業務アプリの入れ替え後の配置例を示す図である。

業務アプリＡ１７は、１つが使用中であり、１つが未使用中である。業務アプリＢ２０は、５つすべてが使用中である。このように、アプリケーションサーバ１０は、クライアント端末１２からのサービス要求に応じて、業務アプリＡ１７の多重度を減らし、業務アプリＢ２０の多重度を増大させる。

なお、アプリ実行基盤１５が７つの場合を示したが、アプリケーションサーバ１０は、プール状態のアプリ実行基盤１５がある場合は、業務アプリＢ２０の多重度をさらに増大させることができる。

アプリケーションサーバ１０は、業務アプリＡ１７の多重度を減らし、業務アプリＢ２０の多重度を増大させる際に、アプリ実行基盤１５を起動状態のままにして、業務アプリケーションＡ１８を業務アプリケーションＢ１９に変更することができる。したがって、アプリケーションサーバ１０は、プロセスの停止と起動にかかる処理時間、ＣＰＵの処理負荷を削減することができ、業務アプリＡ１７の配備解除にかかるコスト、業務アプリＢ２０の配備にかかるコストを低減できる。

次に、第２の実施形態のアプリケーションサーバ１０のハードウェア構成について図６を用いて説明する。図６は、第２の実施形態のアプリケーションサーバのハードウェア構成例を示す図である。アプリケーションサーバ１０は、コンピュータ１００、およびコンピュータ１００に接続する入出力装置（周辺機器）を含んで構成される。

コンピュータ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、たとえばＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、コンピュータ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しをおこなう。ＨＤＤ１０３は、コンピュータ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１１０が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令にしたがって、画像をモニタ１１０の画面に表示させる。モニタ１１０としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード１１１とマウス１１２とが接続されている。入力インタフェース１０５は、キーボード１１１やマウス１１２から送られてくる信号をプロセッサ１０１に送信する。なお、マウス１１２は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１１３に記録されたデータの読み取りを行う。光ディスク１１３は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１１３には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、コンピュータ１００に周辺機器を接続するための通信インタフェースである。たとえば、機器接続インタフェース１０７には、メモリ装置１１４やメモリリーダライタ１１５を接続することができる。メモリ装置１１４は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ１１５は、メモリカード１１６へのデータの書き込み、またはメモリカード１１６からのデータの読み出しを行う装置である。メモリカード１１６は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク１１に接続されている。ネットワークインタフェース１０８は、ネットワーク１１を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施形態のコンピュータ１００の処理機能を実現することができる。なお、第１の実施形態に示した情報処理装置１および第２の実施形態に示すクライアント端末１２も、図６に示したコンピュータ１００と同様のハードウェアにより実現することができる。

コンピュータ１００は、たとえば、コンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施形態の処理機能を実現する。コンピュータ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。たとえば、コンピュータ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。また、コンピュータ１００に実行させるプログラムを、光ディスク１１３、メモリ装置１１４、メモリカード１１６などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、たとえば、プロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、第２の実施形態のマネージャ１３が実行する第１プロセス管理処理について図７を用いて説明する。図７は、第２の実施形態の第１プロセス管理処理のフローチャートである。

第１プロセス管理処理は、アプリケーションサーバ１０が配備する業務アプリの多重度を制御する処理である。第１プロセス管理処理は、アプリケーションサーバ１０の起動により実行される。

［ステップＳ１１］マネージャ１３は、システム環境設定からプール状態とするアプリ実行基盤１５の数（プロセス数）を取得する。システム環境設定は、あらかじめ設定されるシステム環境の各種パラメータを保持する。たとえば、プール状態とするアプリ実行基盤１５の数は、「１０」である。なお、プール状態とするアプリ実行基盤１５の数は、アプリケーションサーバ１０の処理能力の他、アプリケーションサーバ１０を含むシステムの処理能力、発生するサービス要求の量や頻度に等に応じて設定できる。

［ステップＳ１２］マネージャ１３は、取得したプロセス数だけアプリ実行基盤１５を起動する。アプリ実行基盤１５の起動は、アプリケーションサーバ１０が所要のアプリ実行基盤起動プログラムを実行することによりおこなう。マネージャ１３は、起動したアプリ実行基盤１５をプール状態にして管理する。たとえば、マネージャ１３は、プロセス数「１０」を取得すると、アプリ実行基盤１５を１０だけ起動し、プール状態として管理する。

［ステップＳ１３］マネージャ１３は、設定テーブルから設定内容を取得する。ここで、設定テーブルについて図８を用いて説明する。図８は、第２の実施形態の設定テーブルの一例である。設定テーブル５０は、アプリケーションサーバ１０が配備するアプリケーション（業務アプリ）ごとの設定項目が記録されている。設定テーブル５０は、設定項目として、最小プロセス数、変動閾値、およびプロセス変動数があるが、これ以外の設定項目を設けてもよい。最小プロセス数は、業務アプリの配備数の最小値である。変動閾値は、未使用の業務アプリのプロセス数の上限値である。プロセス変動数は、プール状態のアプリ実行基盤１５の配備あるいは返却の単位となるプロセス数である。

アプリケーションサーバ１０は、業務アプリＡと、業務アプリＢを配備するので、設定テーブル５０は、業務アプリＡと、業務アプリＢについての設定項目が記録されている。
たとえば、マネージャ１３は、業務アプリＡについて、最小プロセス数「３」、変動閾値「２」、プロセス変動数「２」を取得し、業務アプリＢについて、最小プロセス数「３」、変動閾値「２」、プロセス変動数「１」を取得する。

［ステップＳ１４］マネージャ１３は、取得した設定内容にもとづいて業務アプリを配備する。設定テーブル５０にしたがえば、マネージャ１３は、プール状態の３つのアプリ実行基盤１５について、業務アプリケーションＡを展開し、さらに、プール状態の３つのアプリ実行基盤１５について、業務アプリケーションＢを展開して、３つの業務アプリＡと、３つの業務アプリＢを配備する。

［ステップＳ１５］マネージャ１３は、システム環境設定から業務アプリの負荷の監視間隔を取得する。たとえば、業務アプリの負荷の監視間隔は、５秒である。なお、業務アプリの負荷の監視間隔は、アプリケーションサーバ１０の処理能力の他、アプリケーションサーバ１０を含むシステムの処理能力、発生するサービス要求の量や頻度に等に応じて設定できる。

［ステップＳ１６］マネージャ１３は、システム環境設定から取得した監視間隔にしたがい監視タイミングを判定する。すなわち、マネージャ１３は、監視間隔５秒を取得している場合、５秒ごとに監視タイミングであると判定する。マネージャ１３は、監視タイミングであると判定した場合にステップＳ１７にすすみ、監視タイミングでないと判定した場合に監視タイミングを待ち受ける。

［ステップＳ１７］マネージャ１３は、プロセス管理テーブルから業務アプリごとのプロセス使用数を取得する。ここで、プロセス管理テーブルについて図９を用いて説明する。図９は、第２の実施形態のプロセス管理テーブルの一例である。

プロセス管理テーブル５１は、アプリ実行基盤１５ごとの使用状況が記録されている。プロセス管理テーブル５１は、記録項目として、アプリケーション（業務アプリ）、使用フラグがあるが、これ以外の記録項目を設けてもよい。アプリケーションは、アプリ実行基盤１５に割り当てられている業務アプリを特定可能な情報（たとえば、業務アプリＡ、業務アプリＢのような名称）である。

使用フラグは、アプリケーションの割り当てのあるアプリ実行基盤１５の使用状況を区別するフラグである。使用フラグ「１」は、アプリケーションの割り当てのあるアプリ実行基盤１５が使用中、すなわちクライアント端末１２からのサービス要求を受け付けて、サービス要求に応じた処理を実行中であることを示す。使用フラグ「０」は、アプリケーションの割り当てのあるアプリ実行基盤１５が不使用中、すなわちクライアント端末１２からのサービス要求を受け付けていない状態であることを示す。

たとえば、マネージャ１３は、プロセス管理テーブル５１によれば、業務アプリＡが７つあり、うち使用中が３つあることから、業務アプリＡのプロセス使用数「３」とプロセス未使用数「４」を取得する。また、マネージャ１３は、プロセス管理テーブル５１によれば、業務アプリＢが３つあり、うち使用中が３つあることから、業務アプリＢのプロセス使用数「３」とプロセス未使用数「０」を取得する。

なお、プロセスＩＤは、マネージャ１３が管理するアプリ実行基盤１５を一意に特定するための識別情報である。これにより、マネージャ１３は、複数あるアプリ実行基盤１５を各々区別して、アプリ実行基盤１５ごとの使用状況を把握できる。

プロセス管理テーブル５１は、共有メモリ１６に保持される。共有メモリ１６は、たとえば、ＲＡＭ１０２、あるいはＨＤＤ１０３上に設定され、マネージャ１３の他、業務アプリＡ、業務アプリＢからもアクセス可能になっている。業務アプリＡ、業務アプリＢは、クライアント端末１２からのサービス要求を受け付けて、対応する使用フラグに「１」を設定し、サービス応答をおこない、次のサービス要求を受け付け可能にして、対応する使用フラグに「０」を設定する。

［ステップＳ１８］マネージャ１３は、第１返却処理を実行する。マネージャ１３は、ステップＳ１３で取得した設定内容、およびステップＳ１７で取得したプロセス使用数とから、業務アプリごとに、必要に応じてアプリ実行基盤１５の返却をおこなう。第１返却処理の詳細は、図１０を用いて後で説明する。

［ステップＳ１９］マネージャ１３は、第１配備処理を実行する。マネージャ１３は、ステップＳ１３で取得した設定内容、およびステップＳ１７で取得したプロセス使用数とから、業務アプリごとに、必要に応じて業務アプリの配備をおこなう。マネージャ１３は、第１配備処理の実行後に、ステップＳ１６にすすむ。第１配備処理の詳細は、図１１を用いて後で説明する。

なお、共有メモリ１６は、業務アプリＡ、業務アプリＢからもアクセス可能であるとしたが、マネージャ１３による占有メモリであってもよい。その場合、業務アプリＡ、業務アプリＢは、マネージャ１３に対して、クライアント端末１２からのサービス要求の受付状況を通知する。マネージャ１３は、業務アプリＡ、業務アプリＢからの通知にもとづいて、プロセス管理テーブル５１を更新するようにしてもよい。

次に、第２の実施形態のマネージャ１３が実行する第１返却処理について図１０を用いて説明する。図１０は、第２の実施形態の第１返却処理のフローチャートである。
第１返却処理は、業務アプリごとに、必要に応じてアプリ実行基盤１５の返却をおこなう処理である。第１返却処理は、第１プロセス管理処理のステップＳ１８で実行される。

［ステップＳ２１］マネージャ１３は、設定テーブル５０から監視対象の業務アプリ（監視対象アプリ）を１つ特定する。たとえば、マネージャ１３は、設定テーブル５０に設定のある業務アプリＡと業務アプリＢのうち、いずれかを監視対象として特定する。

［ステップＳ２２］マネージャ１３は、監視対象の業務アプリについて、未使用プロセス数と変動閾値とを比較して、未使用プロセス数が変動閾値より大きいか否かを判定する。マネージャ１３は、未使用プロセス数が変動閾値より大きい場合にステップＳ２３にすすみ、未使用プロセス数が変動閾値より大きくない場合にステップＳ２５にすすむ。つまり、マネージャ１３は、未使用プロセス数が過大な場合に、アプリ実行基盤１５の返却をおこなう処理にすすむ。

［ステップＳ２３］マネージャ１３は、プロセス変動数だけ業務アプリの配備を解除する。
［ステップＳ２４］マネージャ１３は、業務アプリの配備を解除したアプリ実行基盤１５をプール状態とする（返却）。マネージャ１３は、業務アプリの配備を解除したアプリ実行基盤１５について、プロセス管理テーブル５１のアプリケーション配備の記録を消去する。

［ステップＳ２５］マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなったか否かを判定する。マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなっていない場合にステップＳ２１にすすみ、監視対象のすべての業務アプリについて、監視をおこなった場合に第１返却処理を終了する。

これにより、アプリケーションサーバ１０は、プロセス管理テーブル５１にあるような業務アプリの使用状況である場合、次のように動作する。マネージャ１３は、業務アプリＡについて、未使用プロセス数「４」が変動閾値「２」より大きいことから、変動数である２つのアプリ実行基盤１５の返却をおこなう。一方、マネージャ１３は、業務アプリＢについて、未使用プロセス数「０」が変動閾値「２」より大きくないことから、アプリ実行基盤１５の返却をおこなわない。

このようにして、アプリケーションサーバ１０は、監視対象のすべての業務アプリについて未使用プロセスが過大にならないように管理することができる。また、アプリケーションサーバ１０は、未使用プロセスの配備の解除を未使用プロセス自体の停止によらずに、アプリ実行基盤１５の返却によりおこなうことができるので、アプリ実行基盤１５の停止にかかるコストを低減できる。

次に、第２の実施形態のマネージャ１３が実行する第１配備処理について図１１を用いて説明する。図１１は、第２の実施形態の第１配備処理のフローチャートである。
第１配備処理は、業務アプリごとに、必要に応じてプール状態のアプリ実行基盤１５に業務アプリの配備をおこなう処理である。第１配備処理は、第１プロセス管理処理のステップＳ１９で実行される。

［ステップＳ３１］マネージャ１３は、設定テーブル５０から監視対象の業務アプリを１つ特定する。たとえば、マネージャ１３は、設定テーブル５０に設定のある業務アプリＡと業務アプリＢのうち、いずれかを監視対象として特定する。

［ステップＳ３２］マネージャ１３は、監視対象の業務アプリについて、プロセス使用率が１００％であるか否か、すなわち、未使用プロセス数が「０」であるか否かを判定する。マネージャ１３は、監視対象の業務アプリについて、未使用プロセス数が「０」である場合にステップＳ３３にすすみ、未使用プロセス数が「０」でない場合にステップＳ３５にすすむ。つまり、マネージャ１３は、未使用プロセス数が過小な場合に、業務アプリの配備をおこなう処理にすすむ。

［ステップＳ３３］マネージャ１３は、プール状態のアプリ実行基盤１５をプロセス変動数だけ業務アプリ配備対象とする。
［ステップＳ３４］マネージャ１３は、プール状態のアプリ実行基盤１５について、業務アプリを割り当てて配備する。マネージャ１３は、業務アプリを割り当てたアプリ実行基盤１５について、プロセス管理テーブル５１に割り当てた業務アプリを記録する。

［ステップＳ３５］マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなったか否かを判定する。マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなっていない場合にステップＳ３１にすすみ、監視対象のすべての業務アプリについて、監視をおこなった場合に第１配備処理を終了する。

これにより、アプリケーションサーバ１０は、プロセス管理テーブル５１にあるような業務アプリの使用状況である場合、次のように動作する。マネージャ１３は、業務アプリＡについて、未使用プロセス数が「４」であり、「０」でないことから、業務アプリＡの配備をおこなわない。また、プロセス管理テーブル５１にあるような業務アプリの使用状況のもと第１返却処理が実行された後であっても、マネージャ１３は、業務アプリＡについて、未使用プロセス数が「２」であり、「０」でないことから、アプリ実行基盤１５の配備をおこなわない。一方、マネージャ１３は、業務アプリＢについて、未使用プロセス数が「０」であることから、プロセス変動数「２」だけ業務アプリＢの配備をおこなう。

なお、マネージャ１３は、ステップＳ３２で、監視対象の業務アプリについて、プロセス使用率が１００％であるか否かを判定したが、あらかじめ設定する閾値を用いて未使用プロセス数の過小程度を判定するようにしてもよい。

このようにして、アプリケーションサーバ１０は、監視対象のすべての業務アプリについて未使用プロセスが過小にならないように管理することができる。また、アプリケーションサーバ１０は、業務アプリの配備をプロセス自体の起動によらずに、プール状態のアプリ実行基盤１５に割り当てられているメモリへのアプリケーションプログラムの展開によりおこなうことができるので、配備にかかるコストを低減できる。

このようなアプリケーションサーバ１０は、予期せぬ事態の発生など、見積もりが困難な負荷状況の変化に応じて、業務アプリごとのプロセス多重度を高速に変動させることができる。プロセス多重度の高速変動は、１つには、業務アプリごとのプロセス多重度の変動にかかるコストを低減したことにより監視間隔を小さくすることができることによる。

また、このようなアプリケーションサーバ１０は、システム管理者による業務（業務アプリ）ごとの応答目標時間の設定を不要として、システム管理者の負荷を軽減することができる。

また、このようなアプリケーションサーバ１０は、より正確なプロセス使用状況を用いてプロセス多重度の変動の是非を判定しているため、クライアント端末１２に対して処理遅延の少ない安定したサービスの提供をおこなうことができる。

また、このようなアプリケーションサーバ１０は、負荷のピークに合わせたプロセス多重度を設定することによるリソースの無駄を避けることができる。
なお、アプリケーションサーバ１０は、業務アプリごとに設定テーブル５０の設定内容をチューニングすることができるので、業務アプリの特性に応じた好適なプロセス多重度の制御をおこなうことができる。

なお、未使用プロセスを過大と判定する基準や未使用プロセスを過小と判定する基準は、業務アプリごとに設定されるものであってもよい。また、システム環境として設定される監視時間を、設定テーブル５０の設定内容としてもよく、業務アプリごとに監視時間を異ならせるものであってもよい。

［第３の実施形態］
次に、第３の実施形態のマネージャ１３が実行する第２プロセス管理処理について図１２を用いて説明する。図１２は、第３の実施形態の第２プロセス管理処理のフローチャートである。

第２プロセス管理処理は、アプリケーションサーバ１０が配備する業務アプリの多重度を制御する処理である。第２プロセス管理処理は、アプリケーションサーバ１０の起動により実行される。第２プロセス管理処理は、プロセス使用数の時系列の変化を監視する点で第１プロセス管理処理と異なる。

［ステップＳ４１］マネージャ１３は、システム環境設定からプール状態とするアプリ実行基盤１５の数（プロセス数）を取得する。
［ステップＳ４２］マネージャ１３は、取得したプロセス数だけアプリ実行基盤１５を起動する。マネージャ１３は、起動したアプリ実行基盤１５をプール状態にして管理する。

［ステップＳ４３］マネージャ１３は、設定テーブルから設定内容を取得する。ここで、設定テーブルについて図１３を用いて説明する。図１３は、第３の実施形態の設定テーブルの一例である。設定テーブル５２は、アプリケーションサーバ１０が配備するアプリケーション（業務アプリ）ごとの設定項目が記録されている。設定テーブル５２は、設定項目として、最小プロセス数、変動閾値、および前回のプロセス使用数があるが、これ以外の設定項目を設けてもよい。最小プロセス数は、業務アプリの配備数の最小値である。変動閾値は、未使用の業務アプリのプロセス数の上限値である。前回のプロセス使用数は、前回の監視タイミングで観測したアプリケーションごとのプロセス使用数である。

アプリケーションサーバ１０は、業務アプリＡと、業務アプリＢを配備するので、設定テーブル５２は、業務アプリＡと、業務アプリＢについての設定項目が記録されている。
たとえば、マネージャ１３は、業務アプリＡについて、最小プロセス数「３」、変動閾値「２」、前回のプロセス使用数「６」を取得し、業務アプリＢについて、最小プロセス数「３」、変動閾値「２」、前回のプロセス使用数「１」を取得する。

［ステップＳ４４］マネージャ１３は、取得した設定内容にもとづいて業務アプリを配備する。設定テーブル５０にしたがえば、マネージャ１３は、プール状態の３つのアプリ実行基盤１５について、業務アプリケーションＡを展開し、さらに、プール状態の３つのアプリ実行基盤１５について、業務アプリケーションＢを展開して、３つの業務アプリＡと、３つの業務アプリＢを配備する。

［ステップＳ４５］マネージャ１３は、システム環境設定から業務アプリの負荷の監視間隔を取得する。たとえば、業務アプリの負荷の監視間隔は、５秒である。
［ステップＳ４６］マネージャ１３は、システム環境設定から取得した監視間隔にしたがい監視タイミングを判定する。すなわち、マネージャ１３は、監視間隔５秒を取得している場合、５秒ごとに監視タイミングであると判定する。マネージャ１３は、監視タイミングであると判定した場合にステップＳ４７にすすみ、監視タイミングでないと判定した場合に監視タイミングを待ち受ける。

［ステップＳ４７］マネージャ１３は、設定テーブル５２から前回のプロセス使用数を取得する。
［ステップＳ４８］マネージャ１３は、プロセス管理テーブルから業務アプリごとのプロセス使用数を取得する。第３の実施形態のプロセス管理テーブルは、第２の実施形態のプロセス管理テーブルと同様であるため、図９に示したプロセス管理テーブル５１を用いて説明する。

たとえば、マネージャ１３は、プロセス管理テーブル５１によれば、業務アプリＡが７つあり、うち使用中が３つあることから、業務アプリＡのプロセス使用数「３」とプロセス未使用数「４」を取得する。また、マネージャ１３は、プロセス管理テーブル５１によれば、業務アプリＢが３つあり、うち使用中が３つあることから、業務アプリＢのプロセス使用数「３」とプロセス未使用数「０」を取得する。

［ステップＳ４９］マネージャ１３は、第２返却処理を実行する。マネージャ１３は、ステップＳ４３で取得した設定内容、ステップＳ４７で取得した前回のプロセス使用数、およびステップＳ４８で取得したプロセス使用数とから、業務アプリごとに、必要に応じてアプリ実行基盤１５を返却する。第２返却処理の詳細は、図１４を用いて後で説明する。

［ステップＳ５０］マネージャ１３は、第２配備処理を実行する。マネージャ１３は、ステップＳ４３で取得した設定内容、ステップＳ４７で取得した前回のプロセス使用数、およびステップＳ４８で取得したプロセス使用数とから、業務アプリの配備をおこなう。マネージャ１３は、業務アプリごとに、必要に応じて業務アプリの配備をおこなう。第２配備処理の詳細は、図１５を用いて後で説明する。

［ステップＳ５１］マネージャ１３は、設定テーブル５２の前回のプロセス使用数を、今回のプロセス使用数で更新する。マネージャ１３は、設定テーブル５２の前回のプロセス使用数の更新後に、ステップＳ４６にすすむ。

なお、共有メモリ１６は、業務アプリＡ、業務アプリＢからもアクセス可能であるとしたが、マネージャ１３による占有メモリであってもよい。その場合、業務アプリＡ、業務アプリＢは、マネージャ１３に対して、クライアント端末１２からのサービス要求の受付状況を通知する。マネージャ１３は、業務アプリＡ、業務アプリＢからの通知にもとづいて、プロセス管理テーブル５１を更新するようにしてもよい。

次に、第３の実施形態のマネージャ１３が実行する第２返却処理について図１４を用いて説明する。図１４は、第３の実施形態の第２返却処理のフローチャートである。
第２返却処理は、業務アプリごとに、必要に応じてアプリ実行基盤１５の返却をおこなう処理である。第２返却処理は、第２プロセス管理処理のステップＳ４９で実行される。

［ステップＳ６１］マネージャ１３は、設定テーブル５２から監視対象の業務アプリを１つ特定する。たとえば、マネージャ１３は、設定テーブル５２に設定のある業務アプリＡと業務アプリＢのうち、いずれかを監視対象として特定する。

［ステップＳ６２］マネージャ１３は、監視対象の業務アプリについて、未使用プロセス数と変動閾値とを比較して、未使用プロセス数が変動閾値より大きいか否かを判定する。マネージャ１３は、未使用プロセス数が変動閾値より大きい場合にステップＳ６３にすすみ、未使用プロセス数が変動閾値より大きくない場合にステップＳ６５にすすむ。つまり、マネージャ１３は、未使用プロセス数が過大な場合に、アプリ実行基盤１５の返却をおこなう処理にすすむ。

［ステップＳ６３］マネージャ１３は、前回のプロセス使用数から今回のプロセス使用数を差し引いた数だけ業務アプリの配備を解除する。
［ステップＳ６４］マネージャ１３は、業務アプリの配備を解除したアプリ実行基盤１５を返却する。マネージャ１３は、業務アプリの配備を解除したアプリ実行基盤１５について、プロセス管理テーブル５１のアプリケーション配備の記録を消去する。

［ステップＳ６５］マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなったか否かを判定する。マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなっていない場合にステップＳ６１にすすみ、監視対象のすべての業務アプリについて、監視をおこなった場合に第２返却処理を終了する。

これにより、アプリケーションサーバ１０は、プロセス管理テーブル５１にあるような業務アプリの使用状況である場合、次のように動作する。マネージャ１３は、業務アプリＡについて、未使用プロセス数「４」が変動閾値「２」より大きいことから、前回のプロセス使用数「６」と今回のプロセス使用数「４」の差である２つのアプリ実行基盤１５の返却をおこなう。一方、マネージャ１３は、業務アプリＢについて、未使用プロセス数「０」が変動閾値「２」より大きくないことから、アプリ実行基盤１５の返却をおこなわない。

このようにして、アプリケーションサーバ１０は、監視対象のすべての業務アプリについて未使用プロセスが過大にならないように管理することができる。また、アプリケーションサーバ１０は、未使用プロセスの配備の解除を未使用プロセス自体の停止によらずに、アプリ実行基盤１５の返却によりおこなうことができるので、返却にかかるコストを低減できる。

次に、第３の実施形態のマネージャ１３が実行する第２配備処理について図１５を用いて説明する。図１５は、第３の実施形態の第２配備処理のフローチャートである。
第２配備処理は、業務アプリごとに、必要に応じてプール状態のアプリ実行基盤１５に業務アプリの配備をおこなう処理である。第２配備処理は、第２プロセス管理処理のステップＳ５０で実行される。

［ステップＳ７１］マネージャ１３は、設定テーブル５２から監視対象の業務アプリを１つ特定する。たとえば、マネージャ１３は、設定テーブル５２に設定のある業務アプリＡと業務アプリＢのうち、いずれかを監視対象として特定する。

［ステップＳ７２］マネージャ１３は、監視対象の業務アプリについて、プロセス使用率が１００％であるか否か、すなわち、未使用プロセス数が「０」であるか否かを判定する。マネージャ１３は、監視対象の業務アプリについて、未使用プロセス数が「０」である場合にステップＳ７３にすすみ、未使用プロセス数が「０」でない場合にステップＳ７５にすすむ。つまり、マネージャ１３は、未使用プロセス数が過小な場合に、業務アプリの配備をおこなう処理にすすむ。

［ステップＳ７３］マネージャ１３は、前回のプロセス使用数から今回のプロセス使用数への増加数だけ、プール状態のアプリ実行基盤１５を業務アプリ配備対象とする。
［ステップＳ７４］マネージャ１３は、プール状態のアプリ実行基盤１５について、業務アプリを割り当てて配備する。マネージャ１３は、業務アプリを割り当てたアプリ実行基盤１５について、プロセス管理テーブル５１に割り当てた業務アプリを記録する。

［ステップＳ７５］マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなったか否かを判定する。マネージャ１３は、監視対象のすべての業務アプリについて、監視をおこなっていない場合にステップＳ７１にすすみ、監視対象のすべての業務アプリについて、監視をおこなった場合に第２配備処理を終了する。

これにより、アプリケーションサーバ１０は、プロセス管理テーブル５１にあるような業務アプリの使用状況である場合、次のように動作する。マネージャ１３は、業務アプリＡについて、未使用プロセス数が「４」であり、「０」でないことから、業務アプリＡの配備をおこなわない。また、プロセス管理テーブル５１にあるような業務アプリの使用状況のもと第２返却処理が実行された後であっても、マネージャ１３は、業務アプリＡについて、未使用プロセス数が「１」であり、「０」でないことから、業務アプリＡの配備をおこなわない。一方、マネージャ１３は、業務アプリＢについて、未使用プロセス数が「０」であることから、業務アプリＢの配備をおこなう。マネージャ１３は、業務アプリＢについて、前回のプロセス使用数「１」から今回のプロセス使用数「３」への増加数「２」だけ、業務アプリＢの配備をおこなう。

なお、マネージャ１３は、ステップＳ３２で、監視対象のアプリケーションについて、プロセス使用率が１００％であるか否かを判定したが、あらかじめ設定する閾値を用いて未使用プロセス数の過小程度を判定するようにしてもよい。

このようにして、アプリケーションサーバ１０は、監視対象のすべての業務アプリについて未使用プロセスが過小にならないように管理することができる。また、アプリケーションサーバ１０は、プロセスの配備をプロセス自体の起動によらずに、プール状態のアプリ実行基盤１５に割り当てられているメモリへのアプリケーションプログラムの展開によりおこなうことができるので、配備にかかるコストを低減できる。

このようなアプリケーションサーバ１０は、予期せぬ事態の発生など、見積もりが困難な負荷状況の変化に応じて、業務アプリごとのプロセス多重度を高速に変動させることができる。プロセス多重度の高速変動は、１つには、業務アプリごとのプロセス多重度の変動にかかるコストを低減したことにより監視間隔を小さくすることができることによる。

また、このようなアプリケーションサーバ１０は、システム管理者による業務（業務アプリ）ごとの応答目標時間の設定を不要として、システム管理者の負荷を軽減することができる。

また、このようなアプリケーションサーバ１０は、より正確なプロセス使用状況を用いてプロセス多重度の変動の是非を判定しているため、クライアント端末１２に対して処理遅延の少ない安定したサービスの提供をおこなうことができる。

また、このようなアプリケーションサーバ１０は、負荷のピークに合わせたプロセス多重度を設定することによるリソースの無駄を避けることができる。
なお、アプリケーションサーバ１０は、プロセス使用率あるいはプロセス使用数の変動の大きさに応じて、プロセス多重度の変動量の大きさを変更することができる。したがって、アプリケーションサーバ１０は、プロセス使用率あるいはプロセス使用数の変動が小さい場合には、プロセス多重度の制御にかかるコストを低減できる。また、アプリケーションサーバ１０は、プロセス使用率あるいはプロセス使用数の変動が大きい場合には、大きな変動に追随してプロセス多重度の制御をおこなうことができる。

なお、未使用プロセスを過大と判定する基準や未使用プロセスを過小と判定する基準は、業務アプリごとに設定されるものであってもよい。また、システム環境として設定される監視時間を、設定テーブル５０の設定内容としてもよく、業務アプリごとに監視時間を異ならせるものであってもよい。

なお、第２の実施形態および第３の実施形態において、業務アプリの一例として業務アプリＡと業務アプリＢの２つを挙げたが、３種類以上の業務アプリにおいてもアプリ実行基盤を共用することができる。また、すべての業務アプリが１種類のアプリ実行基盤を共用する一例を示したが、複数種類の業務アプリのグループごとに対応するアプリ実行基盤を共用するものであってもよい。たとえば、業務アプリＡと業務アプリＢは、アプリ実行基盤Ｃを共用し、業務アプリＤと業務アプリＥは、アプリ実行基盤Ｆを共用するものであってもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、情報処理装置１、アプリケーションサーバ１０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤなどの電子回路で実現することもできる。

１ 情報処理装置
２ 制御部
３，３１，３２，３３，３Ｎ プロセス
４ 第１のプログラム
５ 記憶領域
６，６ａ，６ｂ 第２のプログラム
１０ アプリケーションサーバ
１１ ネットワーク
１２ クライアント端末
１３ マネージャ
１４ プール
１５ アプリ実行基盤
１６ 共有メモリ
１７，１７ａ，１７ｂ，１７ｃ 業務アプリＡ
１８ 業務アプリケーションＡ
１９ 業務アプリケーションＢ
２０，２０ａ，２０ｂ 業務アプリＢ
５０，５２ 設定テーブル
５１ プロセス管理テーブル
１００ コンピュータ

Claims (9)

1. コンピュータに、
   第１のプログラムからＮ（２以上）個のプロセスを起動し、
   前記Ｎ個のプロセスのうちの１のプロセスに対応する記憶領域への第２のプログラムの展開と、前記記憶領域への前記第２のプログラムの展開の解除とにより、前記第２のプログラムを展開した前記プロセスの数の変動を前記Ｎ個の範囲内で前記第２のプログラムを展開した前記プロセスの負荷に応じて制御する、
   処理を実行させることを特徴とするプロセス数制御プログラム。
2. あらかじめ設定した設定数のプロセスを起動し、
   初期状態として前記第２のプログラムを展開した前記プロセスの数を、あらかじめ設定したプロセス多重度に制御することを特徴とする請求項１記載のプロセス数制御プログラム。
3. あらかじめ設定した変動数を増減単位にして、前記第２のプログラムを展開した前記プロセスの数の変動を制御することを特徴とする請求項２記載のプロセス数制御プログラム。
4. 前記第２のプログラムは、複数種類あり、
   前記変動数は、前記第２のプログラムの種類ごとに設定されることを特徴とする請求項３記載のプロセス数制御プログラム。
5. 前記負荷を所定のタイミングで監視し、
   前記負荷の監視結果と、前記監視結果の前回の監視タイミングの監視結果との比較にもとづいて決定される変動数を増減単位にして、前記第２のプログラムを展開した前記プロセスの数の変動を制御することを特徴とする請求項２記載のプロセス数制御プログラム。
6. 前記第２のプログラムを展開した前記プロセスの数を所定のタイミングで監視し、
   前記プロセスの数の監視結果と、前記監視結果の前回の監視タイミングの監視結果との差分にもとづいて決定される変動数を増減単位にして、前記第２のプログラムを展開した前記プロセスの数の変動を制御することを特徴とする請求項２記載のプロセス数制御プログラム。
7. 前記負荷を所定周期で監視し、前記所定周期で、前記第２のプログラムを展開した前記プロセスの数の変動を制御することを特徴とする請求項１乃至請求項６のいずれか１つに記載のプロセス変動プログラム。
8. コンピュータが、
   第１のプログラムからＮ（２以上）個のプロセスを起動し、
   前記Ｎ個のプロセスのうちの１のプロセスに対応する記憶領域への第２のプログラムの展開と、前記記憶領域への前記第２のプログラムの展開の解除とにより、前記第２のプログラムを展開した前記プロセスの数の変動を前記Ｎ個の範囲内で前記第２のプログラムを展開した前記プロセスの負荷に応じて制御する、
   ことを特徴とするプロセス数制御方法。
9. 第１のプログラムからＮ（２以上）個のプロセスを起動し、
   前記Ｎ個のプロセスのうちの１のプロセスに対応する記憶領域への第２のプログラムの展開と、前記記憶領域への前記第２のプログラムの展開の解除とにより、前記第２のプログラムを展開した前記プロセスの数の変動を前記Ｎ個の範囲内で前記第２のプログラムを展開した前記プロセスの負荷に応じて制御する、
   制御部を備えることを特徴とする情報処理装置。

Images