(57)【要約】【課題】  従来Ｗｅｂシステムを構築する場合、過去のサーバ性能測定値や、システムエンジニア（ＳＥ）の経験に基づき、各層に適当な数と思われるサーバ台数を配置していた。そのシステムに最適なサーバ台数を配置することは、ノウハウと時間を要する、非常に煩わしいものであった。【解決手段】  クライアントからのリクエスト統計を取る必要リソース量算出部３とリクエスト分布テーブル４とリクエスト種別カウント部５、各サーバの処理能力を表す限界値テーブル６、各サーバの負荷情報を収集・保持する負荷分布テーブル７と負荷情報収集部８、収集したデータに基づいてサーバ構成を決定する構成決定部９とリソース割当部１０とプログラム配付設定部１１とリソース管理テーブル１２で構成する構成制御システム１により、最適なサーバ台数を配置可能とする。【選択図】  図１
2006343899.tif 000002
【特許請求の範囲】
【請求項１】
リクエスト種別の統計をカウントするリクエスト種別カウント部、各サーバの負荷情報を収集する負荷情報収集部、各層（Ｗｅｂ層、アプリケーション層、データベース層）におけるサーバ一台当たりの処理能力限界値を記録する限界値テーブル、必要リソース量を算出する必要リソース量算出部、負荷情報と必要リソース量からサーバ構成を決定する構成決定部、構成に従ってリソースを割り当てるリソース割当部、サーバに対して必要なプログラムを配付するプログラム配付設定部を備えることを特徴として、システムの構成を制御することができるＷｅｂシステム。
【請求項２】
請求項１のＷｅｂシステムにおいて、リクエスト種別ごとにリクエスト数をカウントし、統計情報を蓄える手段を含むことを特徴とするＷｅｂシステム。
【請求項３】
請求項１のＷｅｂシステムにおいて、各層のサーバの処理能力限界値を算出・保持する手段を含むことを特徴とするＷｅｂシステム。
【請求項４】
請求項１のＷｅｂシステムにおいて、前記リクエスト種別統計と負荷情報、限界値から、必要リソース量を算出し、それに従ってシステム構成を決定し、リソースを割り当てる手段を含むことを特徴とするＷｅｂシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂシステムの構成制御方法およびそのシステムに関する。
【背景技術】
【０００２】
Ｗｅｂサーバ、アプリケーションサーバ（ＡＰサーバ）、データベースサーバ（ＤＢサーバ）からなる典型的な３階層Ｗｅｂシステムをモデルとして想定する。
【０００３】
従来Ｗｅｂシステムを構築する場合、過去のサーバ性能測定値や、システムエンジニア（ＳＥ）の経験に基づき、各層に適当な数と思われるサーバ台数を配置していた。そのシステムに最適なサーバ台数を配置することは、ノウハウと時間を要する、非常に煩わしいものであった。
【０００４】
また、システムに対して動的にサーバ追加等の構成制御する場合も、特開２００３−２８１００７号公報に記載のように、ある時点でのサーバ負荷値で判断されるため、対症療法的な手法であった。
【０００５】
【特許文献１】特開２００３−２８１００７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
Ｗｅｂシステムごとに、実行するアプリケーションの種類も違えば、採用するサーバの機種も異なる。また、利用ユーザ数やリクエスト頻度、リクエスト種別もまちまちである。このため、上記従来技術においては、そのＷｅｂシステムに最適なサーバ構成を実現することは、ノウハウと時間を要するものであった。
【０００７】
また各層のサーバにおけるリクエスト処理可能数の限界値を求めることは一般的には難しいため、通常では、リクエスト数が増え、サーバ処理能力が不足した場合になって初めて、手動または自動でサーバを増設するという対症療法的な方法であった。
【０００８】
本発明の目的は、従来の対症療法的なサーバ配置ではなく、リクエスト分布とサーバ処理能力を把握し、根拠に基づいた最適なサーバ配置を自動的に実現することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、従来のＷｅｂシステムに対して「構成制御システム」を追加したものである。これは、Ｗｅｂシステムのリクエスト種別や負荷を監視し、その監視データに基づいて、Ｗｅｂシステムのサーバ構成を制御するものである。
【発明の効果】
【００１０】
本発明によれば、Ｗｅｂシステムへのサーバ配置構成において、根拠に基づいた、適切な数のサーバ構成を実現することができる。
【００１１】
本発明の他の態様では、サーバ毎の限界値データを取得できるため、別のＷｅｂシステムを構築する場合にもそのデータを活かすことができる点が挙げられる。
【００１２】
本発明のさらに他の態様では、リクエスト種別の過去からの統計データを蓄積するため、そのデータを分析することにより、将来のサーバ負荷の予測データとして利用でき、プロアクティブなＷｅｂシステム構成制御が実現できる点が挙げられる。
【発明を実施するための最良の形態】
【００１３】
まず、本発明の前提となる考え方について図面を用いて解説する。
【００１４】
図２は、クライアント２０、ロードバランサ２１、Ｗｅｂサーバ２２、ＡＰサーバ２３、ＤＢサーバ２４からなる一般的なＷｅｂ３階層システムをモデル化して表している。クライアント２０から来るリクエスト２５、２６、２７はロードバランサ２１を通り、サーバで処理され、クライアント２０に結果が返信される。通常、各サーバは、リクエスト処理量および負荷に応じて複数台多重化して設置される。多重化するサーバの処理能力は各層内でほぼ均等なものとする。
【００１５】
クライアントのリクエスト種類によって、処理するサーバの階層が異なる。ここでは例として、３種類のリクエストを示している。ログイン画面表示リクエスト２５は、Ｗｅｂサーバ２２のみで処理され、クライアントに結果が返信される。ログイン処理リクエスト２６および商品検索処理リクエスト２７は、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバそれぞれの機能が連鎖して処理を実行し、結果をクライアントに返信するということを表している。
【００１６】
このモデルにおいて、各層のサーバには、１台当たりのリクエスト処理可能数が存在する。ここでは「限界値」と呼ぶこととする。図３中の表３１は、特定リクエストのみを実行した場合かつ他の層のサーバにボトルネックがない場合の、その層のサーバ１台当たりの限界値を示している。例えば、「ログイン処理」については、ＷｅｂおよびＤＢ層のサーバ処理能力が十分に余裕あり、かつ「ログイン処理」のみを多数実行した場合、ＡＰサーバ１台あたり４０件／秒の処理が可能なことを表している。限界値を求める方法については後述する。
【００１７】
このように、各層のサーバ限界値が判明している場合、リクエストが分布表３２の通りであれば、各層のサーバ最適配置台数を計算式３３により算出することができる。
【００１８】
図４を用いて限界値を求める方法の一例について述べる。始めに、Ｗｅｂサーバ１台、ＡＰサーバ１台、ＤＢサーバ１台の構成で開始する（システム構成４１）。クライアントからは、ある特定のリクエストを送信し、徐々にその件数（件／秒）を増やしていく。ある時点でいずれかのサーバが処理能力限界値に達する。この例ではＡＰサーバが処理能力限界値に達したとすると、ＡＰサーバの限界値が判明する。次に、ＡＰサーバを１台追加し（システム構成４２）、さらにリクエストを増やしていく。再度、ＡＰサーバが処理能力限界値に達すると、ＡＰサーバの限界値は既に判明しているから、さらにＡＰサーバを１台追加し（システム構成４３）、リクエスト数を増やし続ける。ある時点で今度はＷｅｂサーバが処理能力限界値に達すると、ここでＷｅｂサーバの限界値を記録する。Ｗｅｂサーバを１台追加し、リクエスト数をさらに増やし続ける（状態４４）。ある時点でＤＢサーバが処理能力限界値に達し、ここでＤＢサーバの限界値を記録する。
【００１９】
これにより、特定リクエストに対するＷｅｂサーバ、ＡＰサーバ、ＤＢサーバの限界値を測定することができる。
【００２０】
この手順をリクエスト種別ごとに繰り返すことにより、リクエスト種別毎のサーバ限界値を全て求めることができる。
【００２１】
次に、上記方式を採用した、Ｗｅｂシステムの構成を制御する本発明の実施例を図面に基づいて詳細に説明する。図１は、本発明に置けるＷｅｂシステムの構成管理の機構を示すものである。本システムは、構成制御システム１と業務システム２で構成する。構成制御システム１は、必要リソース量算出部３、リクエスト分布テーブル４、リクエスト種別カウント部５、限界値テーブル６、負荷分布テーブル７、負荷情報収集部８、構成決定部９、リソース割当部１０、プログラム配付設定部１１、リソース管理テーブル１２で構成する。構成制御システム１は、１台の計算機に割り当ててもよいし、ネットワークで接続された複数の計算機に割り当ててもよい。業務システム２は、負荷分散装置１４、Ｗｅｂサーバ１５、ＡＰサーバ１６、ＤＢサーバ１７からなり、クライアント１３からのリクエストを受け付け、処理を実行して、結果をクライアントに返信する。各サーバ上には、負荷情報などを構成制御システム１へ通知、およびプログラム配付を受け付けるエージェント１８が稼働する。
【００２２】
リクエスト種別カウント部５では、業務システム２が受け付けるリクエストの種別および件数（件／秒）を計測し、リクエスト分布テーブル４に記録する。リクエスト分布テーブル４のテーブル構造の一例が、図５である。リクエスト種別毎に、総件数および特定期間の平均リクエスト数などを記録していく。
【００２３】
負荷情報収集部８では、業務システム２の各サーバの負荷情報を収集し、負荷分布テーブル７に記録する。負荷情報とは、ＣＰＵ使用率などを指す。負荷分布テーブル７のテーブル構造の一例が図６である。サーバ毎に、時系列の負荷情報を格納している。
【００２４】
限界値テーブル６は、リクエスト種別ごとに、各層（Ｗｅｂ、ＡＰ、ＤＢ）のサーバの処理能力限界値を格納している。テーブル構造の一例が、図７である。前述したように、各サーバの各種リクエストに対する処理能力を示している。
【００２５】
必要リソース量算出部３は、リクエスト分布テーブル４のリクエスト数現在値と限界値テーブル６の限界値を比較分析し、リクエスト数増減から判断した適切な必要リソース量を構成決定部に対して通知する。
【００２６】
図９は、構成決定部９の動きを示す。構成決定部９は、始めに必要リソース算出部３からリクエスト数に基づくサーバ追加要否の通知を受ける（ステップ９１）。追加が必要であれば、リソース割当部１０に増設の指示を出す（ステップ９２、９５）。
【００２７】
構成決定部９は、限界値テーブル６の限界値を修正する機能も持つ。例えば、業務プログラムの修正や追加等により、メモリ・ＣＰＵ使用量が増加すると、リクエストあたりのサーバ負荷が増え、これまで処理可能なリクエスト数限界値ではサーバ性能を越えてしまう場合がある。このとき、必要リソース量算出部３は、処理可能なリクエスト数はこれまでの限界値から、正常と判断し、その旨を構成決定部９に伝えるが（ステップ９１、９２）、構成決定部９は負荷分布テーブル７の値が高いため、限界値テーブル６を修正する（ステップ９３、９４）。
【００２８】
修正アルゴリズムの一例としては、リクエスト種別ごとの負荷量の比にしたがって、限界値テーブルを減算する方法がある。リクエストＡの現在値が３００件／秒、限界値が１０００件／秒、リクエストＢの現在値が２１００件／秒、限界値が３０００件／秒とすると、負荷量の比は３００／１０００：２１００／３０００  ＝０．３：０．７。リクエストＡ、Ｂの限界値の合計４０００件／秒の１％を補正量に定めると、４０件／秒の３：７の比、すなわち、リクエストＡ、Ｂの限界値をそれぞれ１２件／秒、２８件／秒減算する。
【００２９】
本修正後、必要リソース算出部３は、修正された限界値テーブル６を参照することになる。従って、システムの長期運用でサーバ性能が徐々に変化していくような場合でも、Ｗｅｂシステムの構成が制御できる。
【００３０】
リソース割当部１０は、リソース管理テーブル１２を確認し、空きリソースがあれば新たにサーバリソースを追加する。プログラム配付設定部１１は、新規に増設されたサーバに対して必要なプログラムを配付して、サーバを起動することにより、業務システム２にサーバを追加する。
【図面の簡単な説明】
【００３１】
【図１】本発明における一実施例である。Ｗｅｂシステムの構成制御システムの全体構成を示すものである。
【図２】Ｗｅｂ３階層システムをモデル化して説明したものである。
【図３】図２のモデルにおいて、限界値およびリクエスト分布から、サーバの最適構成台数を算出する式を説明したものである。
【図４】限界値を求める方法の一例を説明したものである。
【図５】リクエスト分布テーブルの一例である。
【図６】負荷分布テーブルの一例である。
【図７】限界値テーブルの一例である。
【図８】リソース管理テーブルの一例である。
【図９】構成決定部の動きを示すフローチャートである。
【符号の説明】
【００３２】
１…構成制御システム、２…業務システム、３…必要リソース量算出部、４…リクエスト分布テーブル、５…リクエスト種別カウント部、６…限界値テーブル、７…負荷分布テーブル、８…負荷情報収集部、９…構成決定部、１０…リソース割当部、１１…プログラム配付設定部、１２…リソース管理テーブル、１３…計算機（クライアント）、１４…負荷分散装置、１５…計算機（Ｗｅｂサーバ）、１６…計算機（ＡＰサーバ）、１７…計算機（ＤＢサーバ）、１８…エージェント。
【図１】
2006343899.tif 000003
【図２】
2006343899.tif 000004
【図３】
2006343899.tif 000005
【図４】
2006343899.tif 000006
【図５】
2006343899.tif 000007
【図６】
2006343899.tif 000008
【図７】
2006343899.tif 000009
【図８】
2006343899.tif 000010
【図９】
2006343899.tif 000011