ウェブシステムの性能監視装置
【課題】ウェブシステムの性能を予測して将来の性能あふれを予防する。
【解決手段】データ取得部１２は、ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得する。モデル格納部１８は、ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納する。ファクタ入力部１４は、予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付ける。予測モデル作成部１６は、ファクタを利用してベースモデルを修正し予測モデルを作成する。性能あふれ予知部２２は、作成された予測モデルとパラメータとから、ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、性能予測値と所定のしきい値との比較によってウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する。
【解決手段】データ取得部１２は、ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得する。モデル格納部１８は、ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納する。ファクタ入力部１４は、予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付ける。予測モデル作成部１６は、ファクタを利用してベースモデルを修正し予測モデルを作成する。性能あふれ予知部２２は、作成された予測モデルとパラメータとから、ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、性能予測値と所定のしきい値との比較によってウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上で所定のサービスを提供するウェブシステムの性能を監視する技術に関する。
【背景技術】
【０００２】
ユーザがウェブブラウザ等を使用してインターネット経由でウェブシステムに送信するサービス要求は、年々飛躍的に増大している。近年では、トラフィック量の増加にシステムの増強が追いつかず、システムダウンするようなケースも頻発している。そこで、ウェブシステムの性能を監視し性能あふれの発生を事前に予測するとともに、性能あふれが発生したときにそれを素早く検知して的確な対策を実施できるウェブシステムの性能監視技術が求められている。そのような技術として、例えば特許文献１には、ＷＷＷサイトのサイトアクセスの変動を定期的に予測することによってサイトの性能を予測し、定められた性能を維持できるか否かを判断するＷＷＷサイトの性能監視装置が開示されている。
【特許文献１】特開２００２−２６８９２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ウェブシステムは通常、非常に多数のサーバから構成されており、提供されるサービスも多岐にわたっていることが多い。そのため、ウェブシステムの全体に対して単一のモデルを作成しても、システム全体としての性能しか把握できず、また性能あふれの発生箇所も特定できないため、適切なシステム増強や性能あふれ回避対策の実施が困難であるという問題がある。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、予測モデルを利用してウェブシステムの性能を予測するウェブシステムの性能監視装置を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、ウェブシステムの性能監視装置である。この装置は、ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得するデータ取得部と、ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納するモデル格納部と、予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付けるファクタ入力部と、ファクタを利用してベースモデルを修正し予測モデルを作成する予測モデル作成部と、作成された予測モデルとパラメータとから、ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、該性能予測値と所定のしきい値との比較によってウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する性能あふれ予知部と、性能あふれが予知されたとき、ウェブシステムの性能を回復させる所定の対策プロセスを実行する対策実行部と、を備える。
【０００６】
この態様によると、ウェブシステムの性能を予測するための予測モデルの精度に影響を及ぼすファクタを特定し、ファクタを反映させた予測モデルを作成するようにした。これによって、ウェブシステムの将来の特定時点における性能を高精度に予測することができる。したがって、性能あふれの発生を予知しそれを予防する対策を事前にとることができる。
【０００７】
ウェブシステムが異なるサービスを提供する複数のアプリケーションサーバを含み、各サービスが複数のアプリケーションの組合せで実現される場合、モデル格納部は、サービス、アプリケーション、およびサーバのそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、予測モデル作成部は、サービス、アプリケーション、およびサーバのそれぞれに対して予測モデルを作成し、性能あふれ予知部は、作成されたサービス、アプリケーション、およびサーバの予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めてもよい。
【０００８】
個々のアプリケーションや、アプリケーションの組合せで実現されるサービス、またはサーバ毎に予測モデルを作成することによって、ウェブシステム内のいずれのハードウェアまたはソフトウェアが性能のボトルネックとなるのか、およびウェブシステム内のいずれのハードウェアまたはソフトウェアが性能あふれの原因となりうるのかを容易に発見することができる。したがって、予測される性能あふれに対して適切な回避対策を立てることが可能になる。ウェブシステムが当該ウェブシステムへのアクセス経路毎にサービスを分担する複数のサーバを含む場合も同様である。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、ネットワーク上でサービスを提供するウェブシステムの予測モデルを作成して、ウェブシステムにおける将来の性能を予測することができる。
【発明を実施するための最良の形態】
【００１１】
本発明の一実施形態は、ネットワーク上でサービスを提供するウェブシステムの性能を監視する性能監視装置である。この性能監視装置は、ウェブシステムにかかる性能予測モデルを作成し、この予測モデルにウェブシステムから取得したパラメータを入力することによって、将来のウェブシステムの性能を予測する。
【００１２】
以下では、証券の売買注文を処理したり売買に関する情報を提供したりする証券システムの性能監視装置を例として、本実施形態について詳細に説明する。
【００１３】
図１は、本実施形態にかかる性能監視装置の監視対象である証券システム１００の構成を示す。証券システム１００は、証券会社に設置され、顧客からの証券の売買注文を受け付けたり、証券注文に役立つ様々な情報を提供するシステムである。
【００１４】
証券システム１００は、プレゼンテーションレイヤ１１０とビジネスロジックレイヤ１２０を含む。プレゼンテーションレイヤ１１０は、主にクライアント端末から入力されるデータを受け付けてビジネスロジックレイヤ１２０に渡したり、またはビジネスロジックレイヤ１２０から提供されるデータをウェブページに加工してクライアント端末に提供する役割を有する。ビジネスロジックレイヤ１２０は、証券の売買注文や情報の提供などの実際の処理を担当する役割を有する。
【００１５】
プレゼンテーションレイヤ１１０は、複数のウェブサーバを含む。本実施形態では、証券システム１００に対するアクセスチャネル毎に、ウェブページの処理を実行するサーバのグループが準備されている。図１では、ウェブ経由の一般顧客、コールセンター、支店からそれぞれのクライアント端末８２ａ〜８２ｃを使用して証券システム１００にアクセスする場合を想定している。したがって、プレゼンテーションレイヤ１１０には、一般顧客からのアクセスに対する処理を担当する一般用ウェブサーバ１０２と、コールセンターからのアクセスに対する処理を担当するコールセンター用ウェブサーバ１０４と、支店からのアクセスに対する処理を担当する支店用ウェブサーバ１０６とを備える。さらに、通常は休止している予備のウェブサーバ１０８を準備しておいてもよい。ウェブサーバ１０２〜１０８は、複数のサーバで構成されてもよい。各ウェブサーバ１０２〜１０８は、上記の機能の他、クライアント端末からの要求に応じてプログラムを実行しその結果を送信する動的ページの生成機能やトランザクション管理機能などを実装している。
【００１６】
ビジネスロジックレイヤ１２０には、アクセスチャネル毎ではなく、所定のサービスを専用に実行するサーバのグループが準備されている。本実施形態では、現在および過去の株価や出来高、会社情報などの証券売買の際に必要となる情報をクライアント端末に提供するサービスを実行する情報提供アプリケーションサーバ１２２、株や投資信託などの売買注文を受け付けるサービスを実行する注文処理アプリケーションサーバ１２４、ユーザのログインやログアウト、顧客情報などを管理するサービスを実行する事務処理アプリケーションサーバ１２６を備えているものとする。これ以外にも、例えば、外部の新聞社のサイトなどと連携して経済ニュースを提供する外部連携アプリケーションサーバや、顧客毎に取引残高の報告書などを提供する報告書アプリケーションサーバなどを備えていてもよい。アプリケーションサーバ１２２〜１２６は、複数のサーバで構成されてもよい。各アプリケーションサーバ１２２〜１２６は、上記の業務処理の機能の他、一般のアプリケーションサーバが有している機能、例えば、データベースへの接続機能、複数の処理を連結するトランザクション管理機能なども実装している。
【００１７】
各アプリケーションサーバ１２２〜１２６では、複数のクライアント端末に対するサービス１３０〜１４０が同時に実行される。例えば、情報提供アプリケーションサーバ１２２では、一般顧客に対して株価情報を提供するサービスＡ１３０と、コールセンターに対して株価情報を提供するサービスＢ１３２が同時に実行されてもよい。注文処理アプリケーションサーバ１２４では、コールセンターからの株式売買注文を処理するサービスＣ１３４と、店舗からの投資信託売買注文を処理するサービスＤ１３６が同時に実行されてもよい。
【００１８】
なお、本明細書では、個々の機能を実現するプログラムを「アプリケーション」と呼び、アプリケーションの組合せで実現されるものを「サービス」と呼ぶ。例えば、注文処理アプリケーションサーバ１２４で実行される「注文処理サービス」には、「注文規制銘柄チェック」「買い付け余力チェック」「顧客属性チェック」「注文処理」の各アプリケーションが含まれる。
【００１９】
一般顧客、コールセンターや支店の担当員は、それぞれのクライアント端末８２ａ〜８２ｃからウェブブラウザなどのソフトウェアを使用し、インターネット等のネットワーク８０を介して証券システム１００にアクセスする。コールセンターや支店に備えられるクライアント端末８２ｂ、８２ｃは、証券システム１００と専用線８４によって接続されていてもよい。
【００２０】
クライアント端末８２ａ〜８２ｄから証券システム１００にアクセスすると、プレゼンテーションレイヤ１１０のアクセスチャネルに応じたウェブサーバ１０２〜１０６によって作成されたウェブページが、クライアント端末８２ａ〜８２ｄに提供される。クライアント端末８２ａ〜８２ｄは、提供されたウェブページをディスプレイに表示する。ユーザがウェブページ上でログイン、情報の閲覧、売買注文などの操作を実行すると、その情報がウェブサーバ１０２〜１０６を介してビジネスロジックレイヤ１２０のアプリケーションサーバ１２２〜１２６に渡される。各アプリケーションサーバ１２２〜１２６による処理の結果は、ウェブサーバ１０２〜１０６によってウェブページに加工され、そのデータがクライアント端末８２ａ〜８２ｄに送信される。こうしてユーザは、ウェブページに表示される種々の情報を参照したり、またはウェブページを通じて証券の売買注文をすることができる。
【００２１】
図２は、性能監視装置１０の構成を示す機能ブロック図である。これらの構成は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００２２】
データ取得部１２は、監視対象の証券システム１００から所定のパラメータを取得する。このパラメータは、ウェブシステムを構成するハードウェアの性能、実行中のアプリケーションにおける動作、提供しているサービスの利用状況などに関するものである。データ取得部１２は、パラメータの種類に応じて取得のタイミングを変更してもよい。具体的なパラメータの例、および取得タイミングの例は、図５を参照して後述する。
【００２３】
モデル格納部１８は、証券システム１００の性能を予測するための予測モデルのベースとなるベースモデルを格納する。このベースモデルを、刻々と変化する証券システム１００の利用状況に合わせて修正することによって、予測モデルが作成される。モデル格納部１８には、サーバ、アプリケーション、サービスに対して別々のベースモデルが準備されている。ベースモデルは、過去の証券システム１００の利用状況や動作状況、ハードウェア構成、実行するアプリケーションの種類、性能、将来のシステム利用予測などを考慮して、システム管理者によって予め作成され、モデル格納部１８に格納される。
【００２４】
ファクタ入力部１４は、予測モデルを修正するためのファクタの入力を受け付ける。本明細書において「ファクタ」とは、証券システムの予測モデルにおける予測の精度に影響を及ぼしうるデータのことをいう。ファクタは、システム管理者によりマニュアルで入力されるものもあれば、証券システム１００から自動で取得されるものもある。ファクタの例については、図４を参照して後述する。
【００２５】
予測モデル作成部１６は、モデル格納部１８からベースモデルを取り出し、ファクタ入力部１４から受け取ったファクタを用いてベースモデルを修正して、予測モデルを作成する。「予測モデル」とは、現時点のひとつまたは複数のパラメータを入力することにより、将来の特定時点における証券システム１００の性能を予測することができるモデルである。モデル格納部１８に格納されるベースモデルは、サーバ、アプリケーション、およびサービスに対して共通であるが、予測モデル作成部１６では、証券システム１００に含まれるサーバ、証券システム１００で実行されているアプリケーションや個々のサービス毎に別々の予測モデルが作成されることが好ましい。モデル格納部１８に格納されるベースモデルが、サーバ、アプリケーション、およびサービスのそれぞれについて別のモデルであってもよい。図１の例でいえば、ウェブサーバ１０２〜１０６、またはアプリケーションサーバ１２２〜１２６のそれぞれについて「リソース予測モデル」が、アプリケーションサーバ１２２〜１２６で実行されるサービス１３０〜１４０のそれぞれについて「サービス予測モデル」が、各サービスに含まれるアプリケーションについて「アプリケーション予測モデル」が作成される。
【００２６】
予測モデル作成部１６は、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルを作成するとき、それぞれ異なるファクタを利用してベースモデルを修正する。ファクタと修正すべき予測モデルの対応関係は予め定められている。
【００２７】
性能あふれ予知部２２は、データ取得部１２で取得されたパラメータを受け取る。また、性能あふれ予知部２２は、予測モデル作成部１６からリソース予測モデル２４、アプリケーション予測モデル２６、およびサービス予測モデル２８を受け取る。そして、作成された予測モデル２４〜２８にパラメータを入力して、証券システム１００の特定時点における性能を表すデータである性能予測値を算出する。性能予測値には、例えば、サービスの処理時間、ユーザからのリクエスト数、ターンアラウンドタイム、計算負荷、ストレージ空き容量などが含まれるが、これらに限定されるわけではない。性能予測値のうちのすべてまたは一部は、データ取得部１２で取得されるパラメータと同一のものであってよい。
【００２８】
なお、各予測モデル２４〜２８に入力されるべきパラメータは、予測モデル毎に予め定められている。また、各予測モデル２４〜２８で算出される性能予測値も、予測モデル毎に予め定められている。例えば、リソース予測モデル２４からは、上述の性能予測値のうち、計算負荷、ストレージ空き容量を求めることができる。
【００２９】
さらに、性能あふれ予知部２２は、算出された性能予測値と、性能予測値毎に定められたしきい値とを比較することによって、証券システム１００が将来の特定時点で所望の性能を維持できるか否かを判定する。本明細書では、証券システム１００が所望の性能を維持できなくなる状態を「性能あふれ」と呼ぶ。性能あふれの例には、トラフィックの増加によりサービスの処理時間やターンアラウンドタイムがしきい値より長くなること、ユーザからのリクエスト数がしきい値を越えること、計算負荷量がしきい値を越えること、ストレージ空き容量がしきい値未満となることなどがあるが、これらに限定されるわけではない。
【００３０】
対策実行部３０は、性能あふれ予知部２２によって将来の特定時点で性能あふれが発生すると判定されたとき、証券システム１００の性能あふれを回復させる所定の対策プロセスを実行する。対策実行部３０は、リソース割り当て部３２と、ログイン制限部３４と、サービス停止部３６と、エラー通知部３８とを含む。
【００３１】
リソース割り当て部３２は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、予め余分に準備されているサーバをリソースが不足すると予測されたアプリケーションまたはサービスに分配する。より具体的な例を述べると、例えば、性能あふれ予知部２２において、ウェブサーバ１０２〜１０６のいずれかのリソース予測モデルにおいて、性能予測値である計算負荷がしきい値を上回ったり、ストレージ空き容量がしきい値を下回ったりすると予測されたとする。この場合、リソース割り当て部３２は、予備のウェブサーバ１０８に対して、性能あふれが予測されたウェブサーバにおける処理の一部を分担するように指令する。
【００３２】
または、リソース割り当て部３２は、証券システム１００内の未使用のサーバまたはワークスペースを、リソースが不足すると予測されたアプリケーションまたはサービスに分配するようにしてもよい。この場合、データ取得部１２は、証券システム１００内で未使用のリソースを予め検出しておく必要がある。このように、リソース割り当て部３２によって、システム内のリソースを動的に運用することができる。
【００３３】
ログイン制限部３４は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、証券システム１００へのログインを制限させる。具体的には、ログイン制限部３４は、事務処理アプリケーションサーバ１２６に対して、一定数以上のログインを受け付けないように指令する。
【００３４】
サービス停止部３６は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、特定のアプリケーションまたはサービス以外のアプリケーションまたはサービスの提供を停止させる。この特定のアプリケーションまたはサービスは、システムにおいて最も重要な基幹業務を実施するものであることが好ましい。証券システム１００であれば、注文処理アプリケーションサーバ１２４における売買注文サービスが最も重要であるから、情報提供アプリケーションサーバ１２２における情報の提供サービスや、または事務処理アプリケーションサーバ１２６による顧客情報の更新などのサービスを停止させることが好ましい。このように一部のサービスを停止することによって、基幹となるサービスを維持しつつ、性能あふれによるシステム全体のダウンを回避することができる。
【００３５】
サービス停止部３６は、証券システム１００においてリソースが不足すると判定された場合、ウェブサーバのうち特定のアクセスチャネルに対応するものだけを停止するようにしてもよい。例えば、一般用ウェブサーバ１０２を停止させて、コールセンター用ウェブサーバ１０４と支店用ウェブサーバ１０６はそのまま維持してもよい。この場合、一般用ウェブサーバ１０２のリソースを、コールセンター用ウェブサーバ１０４や支店用ウェブサーバ１０６に割り当てるようにリソース割り当て部３２に指示してもよい。
【００３６】
エラー通知部３８は、性能あふれ予知部２２によって証券システム１００に性能あふれが発生すると判定された場合、システム管理者などに対して性能あふれが予知されている旨のｅメールを発信する。これによって、システム管理者は性能あふれが実際に発生する前に迅速に対策を立てることができる。エラー通知部３８は、「しばらくの間接続をお控えください」などのユーザに対する依頼をウェブページに表示するように、ウェブサーバ１０２〜１０６に指示してもよい。
【００３７】
対策実行部３０は、証券システム１００に実際に性能あふれが発生した場合の復旧手順や、将来的なトラフィックの増加が見込まれる場合のシステムの増強手順を策定して、システム管理者に提示する機能を有していてもよい。
【００３８】
システム診断部４０は、証券システム１００の性能を定期的に検査して、所望の性能が出ているか否かを診断する。例えば、アプリケーション毎の処理速度やターンアラウンドタイムを測定し、所定のしきい値や前回の測定結果と比較する。所望の性能が出ていない場合、アプリケーションやデータベースの設計の見直しなどのシステムの改善策を策定してシステム担当者に提示する。
システム診断部４０は、証券システム１００における実際の性能と、性能あふれ予知部２２における予測モデルを用いて算出された性能とを比較し、実際の値と予測値との誤差を小さくするように、予測モデルを補正する機能を有していてもよい。
【００３９】
性能あふれ検知部２０は、証券システム１００の動作をリアルタイムで監視する。例えば、各サーバの処理負荷やトラフィック量を監視し、所定のしきい値を越えると、システム管理者に対して警告を発する。性能あふれ検知部２０により性能あふれが検知されると、対策実行部３０は、性能あふれが予知されたときと同様の対策プロセスを実行する。
【００４０】
次に、図３のフローチャートを参照して、予測モデル作成部１６における予測モデルの作成プロセスを説明する。
まず、予測モデル作成部１６は、モデル格納部１８から、サーバ、アプリケーション、およびサービス毎に準備されているベースモデルを読み出す（Ｓ１０）。続いて、ファクタ入力部１４で入力されたファクタを受け取る（Ｓ１２）。さらに、予測モデル作成部１６は、証券システム１００内の各サーバのマシン単位およびグループ単位のハードウェア性能値を取得する（Ｓ１４）。このハードウェア性能値は、サーバおよびサーバグループが発揮すべき性能の目標値である。ハードウェア性能値は、システム管理者により予め入力されていてもよいし、証券システム１００の処理負荷が低い時間帯に自動で測定されてもよい。予測モデルは、各サーバが取得したハードウェア性能値のもとで動作すると仮定して作成される。マシン単位およびグループ単位でハードウェア性能値を取得するのは、複数台のサーバが連携して動作すると発揮される性能が単なる合計にならないことが多いためである。
【００４１】
予測モデル作成部１６は、取得したファクタおよびハードウェア性能値を用いてベースモデルを修正し、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルを作成する（Ｓ１６）。ファクタおよびハードウェア性能値によるベースモデルの修正方法としては、例えば、ベースモデルを構成する数式における比例係数の変更、特定の項の削除または追加などが考えられる。
【００４２】
最後に、予測モデル作成部１６は、各予測モデルについて、性能あふれと判定するためのしきい値を設定する（Ｓ１８）。このしきい値は、予測モデル毎に予め定められていてもよいし、ファクタに比例して変化するものでもよい。作成された予測モデルとしきい値とは、性能あふれ予知部２２に渡される。
【００４３】
このように、予測モデルをサーバ毎、アプリケーション毎、サービス毎に作成することによって、アプリケーションやサービス単位での性能予測と性能あふれ対策の実施が可能になる。
【００４４】
図４は、予測モデル作成の際に考慮されるファクタの一例を示す表である。表５０は、ファクタのタイプを表す列５２と、ファクタを表す列５４と、ファクタを考慮した修正の対象となる予測モデルを表す列５６とを含む。予測モデルは、あるファクタの影響を大きく受けるものからほとんど影響を受けないものまで様々である。そこで、ファクタ毎に、修正の対象となる予測モデルを定めておくことが好ましい。
【００４５】
ファクタのタイプには、定常的ファクタと、期間的ファクタと、突発的ファクタとがある。定常的ファクタは、証券システム１００の動作中、一定間隔で取得し続ける必要のあるファクタである。定常的ファクタには、契約口座数、注文件数、出来高、アクセスチャネル毎のログイン人数、リクエスト数などがある。このうち、「契約口座数」のファクタは、ユーザ情報の管理に関わる事務処理アプリケーションの性能に大きく影響を与えるので、事務処理アプリケーションの予測モデルが修正の対象となる。その他のファクタは、いずれも注文処理量に大きく影響を与えるので、注文処理アプリケーションが修正の対象となる。
【００４６】
期間的ファクタは、ある一定の期間（例えば、一ヶ月間）だけ考慮すればよいファクタである。期間的ファクタには、新サービスの提供、高速回線の提供、営業の実施などがある。これらは、いずれも提供の後一定の期間、トラフィック量の増大につながると考えられるので、その間だけ予測モデルの比例係数を上げるなどの修正が必要になる。期間的ファクタは、その性質上、システム管理者によりマニュアルで入力される必要がある。
【００４７】
突発的ファクタは、瞬間的（例えば、一日間）だけ考慮すればよいファクタである。突発的ファクタには、特定の事件の発生、システム障害の回復などがある。これらは、瞬間的にトラフィック量の増大につながると考えられるので、その間だけ予測モデルの比例係数を上げるなどの修正が必要になる。突発的ファクタも、システム管理者によりマニュアルで入力される必要がある。
【００４８】
このように、ファクタと、そのファクタを考慮した修正の対象となる予測モデルとを対応付けておくことで、予測モデルの適切な修正が可能になる。
【００４９】
図５は、予測モデルに入力されるパラメータの一例を示す表である。表６０は、パラメータが入力される予測モデルを表す列６２と、パラメータを表す列６４と、パラメータの取得タイミングを表す列６６とを含む。
サービス予測モデルに入力されるパラメータには、リクエスト数、ログイン数などがある。これらの取得タイミングは、例えば毎分である。
アプリケーション予測モデルに入力されるパラメータには、アプリケーションの呼出し回数、処理時間、ターンアラウンドタイム、ページビューなどがある。呼出し回数の取得タイミングは所定時刻であり、他のパラメータの取得タイミングは例えば毎時である。
リソース予測モデルに入力されるパラメータには、ＣＰＵ使用率、メモリ使用量、ストレージ空き容量などがある。これらの取得タイミングは、例えば毎分である。
【００５０】
図６は、性能あふれ予知部２２における性能あふれ予知プロセスのフローチャートである。
まず、性能あふれ予知部２２は、予測モデル作成部１６から、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルと、それぞれのしきい値とを受け取る（Ｓ３０）。続いて、各予測モデルに対応するパラメータを入力して、将来の特定時点における性能予測値を算出する（Ｓ３２）。性能あふれ予知部２２は、算出された性能予測値としきい値とを比較し（Ｓ３４）、証券システム１００に性能あふれの発生が予測されるか否かを判定する（Ｓ３６）。性能あふれの発生が予測されなければ（Ｓ３６のＮ）、プロセスを終了し、性能あふれの発生が予測されると（Ｓ３６のＹ）、対策実行部３０により性能あふれ回復プロセスが実行される（Ｓ３８）。
【００５１】
図７は、証券システム１００のウェブサーバ、アプリケーションサーバのハードウェア構成を示す。各サーバは、プログラムにしたがって各種処理を実行するＣＰＵ７０と、一時的にデータやプログラムを記憶するメモリ７２と、ハードディスクドライブ、ＤＶＤディスクドライブなどの記憶装置７４と、ネットワークに接続し各種の入出力処理を実行するネットワークインタフェース７６と、これらを相互接続するバス７８と、を少なくとも含む。サーバは、必要に応じて、キーボードやマウス等の入力装置、ディスプレイなどの出力装置を有していてもよい。なお、一つのサーバが二つ以上のネットワークインタフェース７６を有していてもよい。
【００５２】
各サーバは、一枚の基板にコンピュータとして動作するために必要な要素、つまりＣＰＵ、メモリ、ハードディスク、バスなどが搭載されたブレードサーバであることが好ましく、ウェブサーバ１０２〜１０８やアプリケーションサーバ１２２〜１２６は、このブレードサーバが筐体に複数差し込まれているような構成をとることが好ましいが、他の形態であってもよい。
【００５３】
各サーバは、ルータ（図示せず）を介してネットワークストレージ（図示せず）と通信可能に構成されている。アプリケーションの実行に必要なマスタテーブルやデータベース等はネットワークストレージに格納されており、必要に応じてネットワークストレージから各サーバに送信可能となっている。ネットワークストレージは一般にはハードディスク装置であり、通常、複数のディスクを集めてＲＡＩＤを構成しているが、磁気テープ装置であってもよい。
【００５４】
以上説明したように、本実施形態によれば、複数のサーバ、アプリケーション、サービス毎に、将来の特定時点での性能を予測するための予測モデルを作成するようにしたので、監視対象であるウェブシステム内のいずれのハードウェアまたはソフトウェアがシステム性能あふれの発生原因となりうるのかを容易に発見することができる。したがって、予測される性能あふれに応じて適切な回避対策を立てることが可能になる。
【００５５】
従来のウェブシステムの監視装置では、トラフィックの増加などによりシステムに与える影響を予測することが困難であり、そのためシステムの増強などの対策を迅速に実施することができなかった。これに対し、本実施形態の性能監視装置では、予測モデルの精度に影響を及ぼすファクタを特定し、これらファクタを予測モデルの作成に反映させるようにした。これによって、証券システムの将来の特定時点における性能を高精度に予測することができる。したがって、性能あふれが発生してから事後的に対応するのではなく、性能あふれの発生を予知し、それを予防する対策をとることができる。
【００５６】
また、サーバ、アプリケーション、サービス毎にベースモデルを準備し、それぞれの特性に合ったファクタを利用してベースモデルを修正し、予測モデルを作成するようにしたので、システム性能の予測の精度が向上する。
【００５７】
また、ファクタのタイプを複数に分けて、定常的なファクタについては定常的に取得してモデルに反映させるようにしたので、システムの利用状況の変化を迅速に予測モデルに反映させることができる。さらに、期間的ファクタ、突発的ファクタを設け、限られた期間だけ考慮すればよい要因も予測モデルに反映させるようにしたので、システム性能の予測の精度が向上する。
【００５８】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例がありうること、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５９】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６０】
実施形態では、サービスについて予測モデルを作成することを述べたが、複数のサービスの組合せである「サービスグループ」について予測モデルを作成してもよい。ここで、サービスグループは、業務フローを完結させる一連のサービスを含むものである。例えば、「株価コード入力サービス」「時価確認サービス」「購入単位、方法入力サービス」「注文受付サービス」のすべてを含むサービスグループが考えられる。
【００６１】
実施形態では、性能監視装置の監視対象として証券システムを例示したが、監視対象となるウェブシステムはこれに限定されない。
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施形態にかかる性能監視装置の監視対象である証券システムの構成を示す図である。
【図２】一実施形態の性能監視装置の機能ブロック図である。
【図３】モデル作成部における予測モデルの作成プロセスを示すフローチャートである。
【図４】予測モデル作成の際に考慮されるファクタの一例を示す図である。
【図５】予測モデルに入力されるパラメータの一例を示す図である。
【図６】性能あふれ予知部における性能あふれ予知プロセスのフローチャートである。
【図７】各サーバのハードウェア構成を示す図である。
【符号の説明】
【００６３】
１０ 性能監視装置、 １２ データ取得部、 １４ ファクタ入力部、 １６ 予測モデル作成部、 １８ モデル格納部、 ２０ 性能あふれ検知部、 ２２ 性能あふれ予知部、 ２４ リソース予測モデル、 ２６ アプリケーション予測モデル、 ２８ サービス予測モデル、 ３０ 対策実行部、 ３２ リソース割り当て部、 ３４ ログイン制限部、 ３６ サービス停止部、 ３８ エラー通知部、 ８０ ネットワーク、 ８２ａ〜ｄ クライアント端末、 １００ 証券システム、 １０２ 一般用ウェブサーバ、 １０４ コールセンター用ウェブサーバ、 １０６ 支店用ウェブサーバ、 １２２ 情報提供アプリケーションサーバ、 １２４ 注文処理アプリケーションサーバ、 １２６ 事務処理アプリケーションサーバ、 １３０〜１４０ サービス。
【技術分野】
【０００１】
本発明は、ネットワーク上で所定のサービスを提供するウェブシステムの性能を監視する技術に関する。
【背景技術】
【０００２】
ユーザがウェブブラウザ等を使用してインターネット経由でウェブシステムに送信するサービス要求は、年々飛躍的に増大している。近年では、トラフィック量の増加にシステムの増強が追いつかず、システムダウンするようなケースも頻発している。そこで、ウェブシステムの性能を監視し性能あふれの発生を事前に予測するとともに、性能あふれが発生したときにそれを素早く検知して的確な対策を実施できるウェブシステムの性能監視技術が求められている。そのような技術として、例えば特許文献１には、ＷＷＷサイトのサイトアクセスの変動を定期的に予測することによってサイトの性能を予測し、定められた性能を維持できるか否かを判断するＷＷＷサイトの性能監視装置が開示されている。
【特許文献１】特開２００２−２６８９２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ウェブシステムは通常、非常に多数のサーバから構成されており、提供されるサービスも多岐にわたっていることが多い。そのため、ウェブシステムの全体に対して単一のモデルを作成しても、システム全体としての性能しか把握できず、また性能あふれの発生箇所も特定できないため、適切なシステム増強や性能あふれ回避対策の実施が困難であるという問題がある。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、予測モデルを利用してウェブシステムの性能を予測するウェブシステムの性能監視装置を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、ウェブシステムの性能監視装置である。この装置は、ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得するデータ取得部と、ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納するモデル格納部と、予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付けるファクタ入力部と、ファクタを利用してベースモデルを修正し予測モデルを作成する予測モデル作成部と、作成された予測モデルとパラメータとから、ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、該性能予測値と所定のしきい値との比較によってウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する性能あふれ予知部と、性能あふれが予知されたとき、ウェブシステムの性能を回復させる所定の対策プロセスを実行する対策実行部と、を備える。
【０００６】
この態様によると、ウェブシステムの性能を予測するための予測モデルの精度に影響を及ぼすファクタを特定し、ファクタを反映させた予測モデルを作成するようにした。これによって、ウェブシステムの将来の特定時点における性能を高精度に予測することができる。したがって、性能あふれの発生を予知しそれを予防する対策を事前にとることができる。
【０００７】
ウェブシステムが異なるサービスを提供する複数のアプリケーションサーバを含み、各サービスが複数のアプリケーションの組合せで実現される場合、モデル格納部は、サービス、アプリケーション、およびサーバのそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、予測モデル作成部は、サービス、アプリケーション、およびサーバのそれぞれに対して予測モデルを作成し、性能あふれ予知部は、作成されたサービス、アプリケーション、およびサーバの予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めてもよい。
【０００８】
個々のアプリケーションや、アプリケーションの組合せで実現されるサービス、またはサーバ毎に予測モデルを作成することによって、ウェブシステム内のいずれのハードウェアまたはソフトウェアが性能のボトルネックとなるのか、およびウェブシステム内のいずれのハードウェアまたはソフトウェアが性能あふれの原因となりうるのかを容易に発見することができる。したがって、予測される性能あふれに対して適切な回避対策を立てることが可能になる。ウェブシステムが当該ウェブシステムへのアクセス経路毎にサービスを分担する複数のサーバを含む場合も同様である。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、ネットワーク上でサービスを提供するウェブシステムの予測モデルを作成して、ウェブシステムにおける将来の性能を予測することができる。
【発明を実施するための最良の形態】
【００１１】
本発明の一実施形態は、ネットワーク上でサービスを提供するウェブシステムの性能を監視する性能監視装置である。この性能監視装置は、ウェブシステムにかかる性能予測モデルを作成し、この予測モデルにウェブシステムから取得したパラメータを入力することによって、将来のウェブシステムの性能を予測する。
【００１２】
以下では、証券の売買注文を処理したり売買に関する情報を提供したりする証券システムの性能監視装置を例として、本実施形態について詳細に説明する。
【００１３】
図１は、本実施形態にかかる性能監視装置の監視対象である証券システム１００の構成を示す。証券システム１００は、証券会社に設置され、顧客からの証券の売買注文を受け付けたり、証券注文に役立つ様々な情報を提供するシステムである。
【００１４】
証券システム１００は、プレゼンテーションレイヤ１１０とビジネスロジックレイヤ１２０を含む。プレゼンテーションレイヤ１１０は、主にクライアント端末から入力されるデータを受け付けてビジネスロジックレイヤ１２０に渡したり、またはビジネスロジックレイヤ１２０から提供されるデータをウェブページに加工してクライアント端末に提供する役割を有する。ビジネスロジックレイヤ１２０は、証券の売買注文や情報の提供などの実際の処理を担当する役割を有する。
【００１５】
プレゼンテーションレイヤ１１０は、複数のウェブサーバを含む。本実施形態では、証券システム１００に対するアクセスチャネル毎に、ウェブページの処理を実行するサーバのグループが準備されている。図１では、ウェブ経由の一般顧客、コールセンター、支店からそれぞれのクライアント端末８２ａ〜８２ｃを使用して証券システム１００にアクセスする場合を想定している。したがって、プレゼンテーションレイヤ１１０には、一般顧客からのアクセスに対する処理を担当する一般用ウェブサーバ１０２と、コールセンターからのアクセスに対する処理を担当するコールセンター用ウェブサーバ１０４と、支店からのアクセスに対する処理を担当する支店用ウェブサーバ１０６とを備える。さらに、通常は休止している予備のウェブサーバ１０８を準備しておいてもよい。ウェブサーバ１０２〜１０８は、複数のサーバで構成されてもよい。各ウェブサーバ１０２〜１０８は、上記の機能の他、クライアント端末からの要求に応じてプログラムを実行しその結果を送信する動的ページの生成機能やトランザクション管理機能などを実装している。
【００１６】
ビジネスロジックレイヤ１２０には、アクセスチャネル毎ではなく、所定のサービスを専用に実行するサーバのグループが準備されている。本実施形態では、現在および過去の株価や出来高、会社情報などの証券売買の際に必要となる情報をクライアント端末に提供するサービスを実行する情報提供アプリケーションサーバ１２２、株や投資信託などの売買注文を受け付けるサービスを実行する注文処理アプリケーションサーバ１２４、ユーザのログインやログアウト、顧客情報などを管理するサービスを実行する事務処理アプリケーションサーバ１２６を備えているものとする。これ以外にも、例えば、外部の新聞社のサイトなどと連携して経済ニュースを提供する外部連携アプリケーションサーバや、顧客毎に取引残高の報告書などを提供する報告書アプリケーションサーバなどを備えていてもよい。アプリケーションサーバ１２２〜１２６は、複数のサーバで構成されてもよい。各アプリケーションサーバ１２２〜１２６は、上記の業務処理の機能の他、一般のアプリケーションサーバが有している機能、例えば、データベースへの接続機能、複数の処理を連結するトランザクション管理機能なども実装している。
【００１７】
各アプリケーションサーバ１２２〜１２６では、複数のクライアント端末に対するサービス１３０〜１４０が同時に実行される。例えば、情報提供アプリケーションサーバ１２２では、一般顧客に対して株価情報を提供するサービスＡ１３０と、コールセンターに対して株価情報を提供するサービスＢ１３２が同時に実行されてもよい。注文処理アプリケーションサーバ１２４では、コールセンターからの株式売買注文を処理するサービスＣ１３４と、店舗からの投資信託売買注文を処理するサービスＤ１３６が同時に実行されてもよい。
【００１８】
なお、本明細書では、個々の機能を実現するプログラムを「アプリケーション」と呼び、アプリケーションの組合せで実現されるものを「サービス」と呼ぶ。例えば、注文処理アプリケーションサーバ１２４で実行される「注文処理サービス」には、「注文規制銘柄チェック」「買い付け余力チェック」「顧客属性チェック」「注文処理」の各アプリケーションが含まれる。
【００１９】
一般顧客、コールセンターや支店の担当員は、それぞれのクライアント端末８２ａ〜８２ｃからウェブブラウザなどのソフトウェアを使用し、インターネット等のネットワーク８０を介して証券システム１００にアクセスする。コールセンターや支店に備えられるクライアント端末８２ｂ、８２ｃは、証券システム１００と専用線８４によって接続されていてもよい。
【００２０】
クライアント端末８２ａ〜８２ｄから証券システム１００にアクセスすると、プレゼンテーションレイヤ１１０のアクセスチャネルに応じたウェブサーバ１０２〜１０６によって作成されたウェブページが、クライアント端末８２ａ〜８２ｄに提供される。クライアント端末８２ａ〜８２ｄは、提供されたウェブページをディスプレイに表示する。ユーザがウェブページ上でログイン、情報の閲覧、売買注文などの操作を実行すると、その情報がウェブサーバ１０２〜１０６を介してビジネスロジックレイヤ１２０のアプリケーションサーバ１２２〜１２６に渡される。各アプリケーションサーバ１２２〜１２６による処理の結果は、ウェブサーバ１０２〜１０６によってウェブページに加工され、そのデータがクライアント端末８２ａ〜８２ｄに送信される。こうしてユーザは、ウェブページに表示される種々の情報を参照したり、またはウェブページを通じて証券の売買注文をすることができる。
【００２１】
図２は、性能監視装置１０の構成を示す機能ブロック図である。これらの構成は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００２２】
データ取得部１２は、監視対象の証券システム１００から所定のパラメータを取得する。このパラメータは、ウェブシステムを構成するハードウェアの性能、実行中のアプリケーションにおける動作、提供しているサービスの利用状況などに関するものである。データ取得部１２は、パラメータの種類に応じて取得のタイミングを変更してもよい。具体的なパラメータの例、および取得タイミングの例は、図５を参照して後述する。
【００２３】
モデル格納部１８は、証券システム１００の性能を予測するための予測モデルのベースとなるベースモデルを格納する。このベースモデルを、刻々と変化する証券システム１００の利用状況に合わせて修正することによって、予測モデルが作成される。モデル格納部１８には、サーバ、アプリケーション、サービスに対して別々のベースモデルが準備されている。ベースモデルは、過去の証券システム１００の利用状況や動作状況、ハードウェア構成、実行するアプリケーションの種類、性能、将来のシステム利用予測などを考慮して、システム管理者によって予め作成され、モデル格納部１８に格納される。
【００２４】
ファクタ入力部１４は、予測モデルを修正するためのファクタの入力を受け付ける。本明細書において「ファクタ」とは、証券システムの予測モデルにおける予測の精度に影響を及ぼしうるデータのことをいう。ファクタは、システム管理者によりマニュアルで入力されるものもあれば、証券システム１００から自動で取得されるものもある。ファクタの例については、図４を参照して後述する。
【００２５】
予測モデル作成部１６は、モデル格納部１８からベースモデルを取り出し、ファクタ入力部１４から受け取ったファクタを用いてベースモデルを修正して、予測モデルを作成する。「予測モデル」とは、現時点のひとつまたは複数のパラメータを入力することにより、将来の特定時点における証券システム１００の性能を予測することができるモデルである。モデル格納部１８に格納されるベースモデルは、サーバ、アプリケーション、およびサービスに対して共通であるが、予測モデル作成部１６では、証券システム１００に含まれるサーバ、証券システム１００で実行されているアプリケーションや個々のサービス毎に別々の予測モデルが作成されることが好ましい。モデル格納部１８に格納されるベースモデルが、サーバ、アプリケーション、およびサービスのそれぞれについて別のモデルであってもよい。図１の例でいえば、ウェブサーバ１０２〜１０６、またはアプリケーションサーバ１２２〜１２６のそれぞれについて「リソース予測モデル」が、アプリケーションサーバ１２２〜１２６で実行されるサービス１３０〜１４０のそれぞれについて「サービス予測モデル」が、各サービスに含まれるアプリケーションについて「アプリケーション予測モデル」が作成される。
【００２６】
予測モデル作成部１６は、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルを作成するとき、それぞれ異なるファクタを利用してベースモデルを修正する。ファクタと修正すべき予測モデルの対応関係は予め定められている。
【００２７】
性能あふれ予知部２２は、データ取得部１２で取得されたパラメータを受け取る。また、性能あふれ予知部２２は、予測モデル作成部１６からリソース予測モデル２４、アプリケーション予測モデル２６、およびサービス予測モデル２８を受け取る。そして、作成された予測モデル２４〜２８にパラメータを入力して、証券システム１００の特定時点における性能を表すデータである性能予測値を算出する。性能予測値には、例えば、サービスの処理時間、ユーザからのリクエスト数、ターンアラウンドタイム、計算負荷、ストレージ空き容量などが含まれるが、これらに限定されるわけではない。性能予測値のうちのすべてまたは一部は、データ取得部１２で取得されるパラメータと同一のものであってよい。
【００２８】
なお、各予測モデル２４〜２８に入力されるべきパラメータは、予測モデル毎に予め定められている。また、各予測モデル２４〜２８で算出される性能予測値も、予測モデル毎に予め定められている。例えば、リソース予測モデル２４からは、上述の性能予測値のうち、計算負荷、ストレージ空き容量を求めることができる。
【００２９】
さらに、性能あふれ予知部２２は、算出された性能予測値と、性能予測値毎に定められたしきい値とを比較することによって、証券システム１００が将来の特定時点で所望の性能を維持できるか否かを判定する。本明細書では、証券システム１００が所望の性能を維持できなくなる状態を「性能あふれ」と呼ぶ。性能あふれの例には、トラフィックの増加によりサービスの処理時間やターンアラウンドタイムがしきい値より長くなること、ユーザからのリクエスト数がしきい値を越えること、計算負荷量がしきい値を越えること、ストレージ空き容量がしきい値未満となることなどがあるが、これらに限定されるわけではない。
【００３０】
対策実行部３０は、性能あふれ予知部２２によって将来の特定時点で性能あふれが発生すると判定されたとき、証券システム１００の性能あふれを回復させる所定の対策プロセスを実行する。対策実行部３０は、リソース割り当て部３２と、ログイン制限部３４と、サービス停止部３６と、エラー通知部３８とを含む。
【００３１】
リソース割り当て部３２は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、予め余分に準備されているサーバをリソースが不足すると予測されたアプリケーションまたはサービスに分配する。より具体的な例を述べると、例えば、性能あふれ予知部２２において、ウェブサーバ１０２〜１０６のいずれかのリソース予測モデルにおいて、性能予測値である計算負荷がしきい値を上回ったり、ストレージ空き容量がしきい値を下回ったりすると予測されたとする。この場合、リソース割り当て部３２は、予備のウェブサーバ１０８に対して、性能あふれが予測されたウェブサーバにおける処理の一部を分担するように指令する。
【００３２】
または、リソース割り当て部３２は、証券システム１００内の未使用のサーバまたはワークスペースを、リソースが不足すると予測されたアプリケーションまたはサービスに分配するようにしてもよい。この場合、データ取得部１２は、証券システム１００内で未使用のリソースを予め検出しておく必要がある。このように、リソース割り当て部３２によって、システム内のリソースを動的に運用することができる。
【００３３】
ログイン制限部３４は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、証券システム１００へのログインを制限させる。具体的には、ログイン制限部３４は、事務処理アプリケーションサーバ１２６に対して、一定数以上のログインを受け付けないように指令する。
【００３４】
サービス停止部３６は、証券システム１００においてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると判定された場合に、特定のアプリケーションまたはサービス以外のアプリケーションまたはサービスの提供を停止させる。この特定のアプリケーションまたはサービスは、システムにおいて最も重要な基幹業務を実施するものであることが好ましい。証券システム１００であれば、注文処理アプリケーションサーバ１２４における売買注文サービスが最も重要であるから、情報提供アプリケーションサーバ１２２における情報の提供サービスや、または事務処理アプリケーションサーバ１２６による顧客情報の更新などのサービスを停止させることが好ましい。このように一部のサービスを停止することによって、基幹となるサービスを維持しつつ、性能あふれによるシステム全体のダウンを回避することができる。
【００３５】
サービス停止部３６は、証券システム１００においてリソースが不足すると判定された場合、ウェブサーバのうち特定のアクセスチャネルに対応するものだけを停止するようにしてもよい。例えば、一般用ウェブサーバ１０２を停止させて、コールセンター用ウェブサーバ１０４と支店用ウェブサーバ１０６はそのまま維持してもよい。この場合、一般用ウェブサーバ１０２のリソースを、コールセンター用ウェブサーバ１０４や支店用ウェブサーバ１０６に割り当てるようにリソース割り当て部３２に指示してもよい。
【００３６】
エラー通知部３８は、性能あふれ予知部２２によって証券システム１００に性能あふれが発生すると判定された場合、システム管理者などに対して性能あふれが予知されている旨のｅメールを発信する。これによって、システム管理者は性能あふれが実際に発生する前に迅速に対策を立てることができる。エラー通知部３８は、「しばらくの間接続をお控えください」などのユーザに対する依頼をウェブページに表示するように、ウェブサーバ１０２〜１０６に指示してもよい。
【００３７】
対策実行部３０は、証券システム１００に実際に性能あふれが発生した場合の復旧手順や、将来的なトラフィックの増加が見込まれる場合のシステムの増強手順を策定して、システム管理者に提示する機能を有していてもよい。
【００３８】
システム診断部４０は、証券システム１００の性能を定期的に検査して、所望の性能が出ているか否かを診断する。例えば、アプリケーション毎の処理速度やターンアラウンドタイムを測定し、所定のしきい値や前回の測定結果と比較する。所望の性能が出ていない場合、アプリケーションやデータベースの設計の見直しなどのシステムの改善策を策定してシステム担当者に提示する。
システム診断部４０は、証券システム１００における実際の性能と、性能あふれ予知部２２における予測モデルを用いて算出された性能とを比較し、実際の値と予測値との誤差を小さくするように、予測モデルを補正する機能を有していてもよい。
【００３９】
性能あふれ検知部２０は、証券システム１００の動作をリアルタイムで監視する。例えば、各サーバの処理負荷やトラフィック量を監視し、所定のしきい値を越えると、システム管理者に対して警告を発する。性能あふれ検知部２０により性能あふれが検知されると、対策実行部３０は、性能あふれが予知されたときと同様の対策プロセスを実行する。
【００４０】
次に、図３のフローチャートを参照して、予測モデル作成部１６における予測モデルの作成プロセスを説明する。
まず、予測モデル作成部１６は、モデル格納部１８から、サーバ、アプリケーション、およびサービス毎に準備されているベースモデルを読み出す（Ｓ１０）。続いて、ファクタ入力部１４で入力されたファクタを受け取る（Ｓ１２）。さらに、予測モデル作成部１６は、証券システム１００内の各サーバのマシン単位およびグループ単位のハードウェア性能値を取得する（Ｓ１４）。このハードウェア性能値は、サーバおよびサーバグループが発揮すべき性能の目標値である。ハードウェア性能値は、システム管理者により予め入力されていてもよいし、証券システム１００の処理負荷が低い時間帯に自動で測定されてもよい。予測モデルは、各サーバが取得したハードウェア性能値のもとで動作すると仮定して作成される。マシン単位およびグループ単位でハードウェア性能値を取得するのは、複数台のサーバが連携して動作すると発揮される性能が単なる合計にならないことが多いためである。
【００４１】
予測モデル作成部１６は、取得したファクタおよびハードウェア性能値を用いてベースモデルを修正し、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルを作成する（Ｓ１６）。ファクタおよびハードウェア性能値によるベースモデルの修正方法としては、例えば、ベースモデルを構成する数式における比例係数の変更、特定の項の削除または追加などが考えられる。
【００４２】
最後に、予測モデル作成部１６は、各予測モデルについて、性能あふれと判定するためのしきい値を設定する（Ｓ１８）。このしきい値は、予測モデル毎に予め定められていてもよいし、ファクタに比例して変化するものでもよい。作成された予測モデルとしきい値とは、性能あふれ予知部２２に渡される。
【００４３】
このように、予測モデルをサーバ毎、アプリケーション毎、サービス毎に作成することによって、アプリケーションやサービス単位での性能予測と性能あふれ対策の実施が可能になる。
【００４４】
図４は、予測モデル作成の際に考慮されるファクタの一例を示す表である。表５０は、ファクタのタイプを表す列５２と、ファクタを表す列５４と、ファクタを考慮した修正の対象となる予測モデルを表す列５６とを含む。予測モデルは、あるファクタの影響を大きく受けるものからほとんど影響を受けないものまで様々である。そこで、ファクタ毎に、修正の対象となる予測モデルを定めておくことが好ましい。
【００４５】
ファクタのタイプには、定常的ファクタと、期間的ファクタと、突発的ファクタとがある。定常的ファクタは、証券システム１００の動作中、一定間隔で取得し続ける必要のあるファクタである。定常的ファクタには、契約口座数、注文件数、出来高、アクセスチャネル毎のログイン人数、リクエスト数などがある。このうち、「契約口座数」のファクタは、ユーザ情報の管理に関わる事務処理アプリケーションの性能に大きく影響を与えるので、事務処理アプリケーションの予測モデルが修正の対象となる。その他のファクタは、いずれも注文処理量に大きく影響を与えるので、注文処理アプリケーションが修正の対象となる。
【００４６】
期間的ファクタは、ある一定の期間（例えば、一ヶ月間）だけ考慮すればよいファクタである。期間的ファクタには、新サービスの提供、高速回線の提供、営業の実施などがある。これらは、いずれも提供の後一定の期間、トラフィック量の増大につながると考えられるので、その間だけ予測モデルの比例係数を上げるなどの修正が必要になる。期間的ファクタは、その性質上、システム管理者によりマニュアルで入力される必要がある。
【００４７】
突発的ファクタは、瞬間的（例えば、一日間）だけ考慮すればよいファクタである。突発的ファクタには、特定の事件の発生、システム障害の回復などがある。これらは、瞬間的にトラフィック量の増大につながると考えられるので、その間だけ予測モデルの比例係数を上げるなどの修正が必要になる。突発的ファクタも、システム管理者によりマニュアルで入力される必要がある。
【００４８】
このように、ファクタと、そのファクタを考慮した修正の対象となる予測モデルとを対応付けておくことで、予測モデルの適切な修正が可能になる。
【００４９】
図５は、予測モデルに入力されるパラメータの一例を示す表である。表６０は、パラメータが入力される予測モデルを表す列６２と、パラメータを表す列６４と、パラメータの取得タイミングを表す列６６とを含む。
サービス予測モデルに入力されるパラメータには、リクエスト数、ログイン数などがある。これらの取得タイミングは、例えば毎分である。
アプリケーション予測モデルに入力されるパラメータには、アプリケーションの呼出し回数、処理時間、ターンアラウンドタイム、ページビューなどがある。呼出し回数の取得タイミングは所定時刻であり、他のパラメータの取得タイミングは例えば毎時である。
リソース予測モデルに入力されるパラメータには、ＣＰＵ使用率、メモリ使用量、ストレージ空き容量などがある。これらの取得タイミングは、例えば毎分である。
【００５０】
図６は、性能あふれ予知部２２における性能あふれ予知プロセスのフローチャートである。
まず、性能あふれ予知部２２は、予測モデル作成部１６から、リソース予測モデル、アプリケーション予測モデル、およびサービス予測モデルと、それぞれのしきい値とを受け取る（Ｓ３０）。続いて、各予測モデルに対応するパラメータを入力して、将来の特定時点における性能予測値を算出する（Ｓ３２）。性能あふれ予知部２２は、算出された性能予測値としきい値とを比較し（Ｓ３４）、証券システム１００に性能あふれの発生が予測されるか否かを判定する（Ｓ３６）。性能あふれの発生が予測されなければ（Ｓ３６のＮ）、プロセスを終了し、性能あふれの発生が予測されると（Ｓ３６のＹ）、対策実行部３０により性能あふれ回復プロセスが実行される（Ｓ３８）。
【００５１】
図７は、証券システム１００のウェブサーバ、アプリケーションサーバのハードウェア構成を示す。各サーバは、プログラムにしたがって各種処理を実行するＣＰＵ７０と、一時的にデータやプログラムを記憶するメモリ７２と、ハードディスクドライブ、ＤＶＤディスクドライブなどの記憶装置７４と、ネットワークに接続し各種の入出力処理を実行するネットワークインタフェース７６と、これらを相互接続するバス７８と、を少なくとも含む。サーバは、必要に応じて、キーボードやマウス等の入力装置、ディスプレイなどの出力装置を有していてもよい。なお、一つのサーバが二つ以上のネットワークインタフェース７６を有していてもよい。
【００５２】
各サーバは、一枚の基板にコンピュータとして動作するために必要な要素、つまりＣＰＵ、メモリ、ハードディスク、バスなどが搭載されたブレードサーバであることが好ましく、ウェブサーバ１０２〜１０８やアプリケーションサーバ１２２〜１２６は、このブレードサーバが筐体に複数差し込まれているような構成をとることが好ましいが、他の形態であってもよい。
【００５３】
各サーバは、ルータ（図示せず）を介してネットワークストレージ（図示せず）と通信可能に構成されている。アプリケーションの実行に必要なマスタテーブルやデータベース等はネットワークストレージに格納されており、必要に応じてネットワークストレージから各サーバに送信可能となっている。ネットワークストレージは一般にはハードディスク装置であり、通常、複数のディスクを集めてＲＡＩＤを構成しているが、磁気テープ装置であってもよい。
【００５４】
以上説明したように、本実施形態によれば、複数のサーバ、アプリケーション、サービス毎に、将来の特定時点での性能を予測するための予測モデルを作成するようにしたので、監視対象であるウェブシステム内のいずれのハードウェアまたはソフトウェアがシステム性能あふれの発生原因となりうるのかを容易に発見することができる。したがって、予測される性能あふれに応じて適切な回避対策を立てることが可能になる。
【００５５】
従来のウェブシステムの監視装置では、トラフィックの増加などによりシステムに与える影響を予測することが困難であり、そのためシステムの増強などの対策を迅速に実施することができなかった。これに対し、本実施形態の性能監視装置では、予測モデルの精度に影響を及ぼすファクタを特定し、これらファクタを予測モデルの作成に反映させるようにした。これによって、証券システムの将来の特定時点における性能を高精度に予測することができる。したがって、性能あふれが発生してから事後的に対応するのではなく、性能あふれの発生を予知し、それを予防する対策をとることができる。
【００５６】
また、サーバ、アプリケーション、サービス毎にベースモデルを準備し、それぞれの特性に合ったファクタを利用してベースモデルを修正し、予測モデルを作成するようにしたので、システム性能の予測の精度が向上する。
【００５７】
また、ファクタのタイプを複数に分けて、定常的なファクタについては定常的に取得してモデルに反映させるようにしたので、システムの利用状況の変化を迅速に予測モデルに反映させることができる。さらに、期間的ファクタ、突発的ファクタを設け、限られた期間だけ考慮すればよい要因も予測モデルに反映させるようにしたので、システム性能の予測の精度が向上する。
【００５８】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例がありうること、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５９】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６０】
実施形態では、サービスについて予測モデルを作成することを述べたが、複数のサービスの組合せである「サービスグループ」について予測モデルを作成してもよい。ここで、サービスグループは、業務フローを完結させる一連のサービスを含むものである。例えば、「株価コード入力サービス」「時価確認サービス」「購入単位、方法入力サービス」「注文受付サービス」のすべてを含むサービスグループが考えられる。
【００６１】
実施形態では、性能監視装置の監視対象として証券システムを例示したが、監視対象となるウェブシステムはこれに限定されない。
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施形態にかかる性能監視装置の監視対象である証券システムの構成を示す図である。
【図２】一実施形態の性能監視装置の機能ブロック図である。
【図３】モデル作成部における予測モデルの作成プロセスを示すフローチャートである。
【図４】予測モデル作成の際に考慮されるファクタの一例を示す図である。
【図５】予測モデルに入力されるパラメータの一例を示す図である。
【図６】性能あふれ予知部における性能あふれ予知プロセスのフローチャートである。
【図７】各サーバのハードウェア構成を示す図である。
【符号の説明】
【００６３】
１０ 性能監視装置、 １２ データ取得部、 １４ ファクタ入力部、 １６ 予測モデル作成部、 １８ モデル格納部、 ２０ 性能あふれ検知部、 ２２ 性能あふれ予知部、 ２４ リソース予測モデル、 ２６ アプリケーション予測モデル、 ２８ サービス予測モデル、 ３０ 対策実行部、 ３２ リソース割り当て部、 ３４ ログイン制限部、 ３６ サービス停止部、 ３８ エラー通知部、 ８０ ネットワーク、 ８２ａ〜ｄ クライアント端末、 １００ 証券システム、 １０２ 一般用ウェブサーバ、 １０４ コールセンター用ウェブサーバ、 １０６ 支店用ウェブサーバ、 １２２ 情報提供アプリケーションサーバ、 １２４ 注文処理アプリケーションサーバ、 １２６ 事務処理アプリケーションサーバ、 １３０〜１４０ サービス。
【特許請求の範囲】
【請求項１】
ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得するデータ取得部と、
前記ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納するモデル格納部と、
前記予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付けるファクタ入力部と、
前記ファクタを利用して前記ベースモデルを修正し予測モデルを作成する予測モデル作成部と、
作成された予測モデルと前記パラメータとから、前記ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、該性能予測値と所定のしきい値との比較によって前記ウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する性能あふれ予知部と、
性能あふれが予知されたとき、前記ウェブシステムの性能を回復させる所定の対策プロセスを実行する対策実行部と、
を備えることを特徴とするウェブシステムの性能監視装置。
【請求項２】
前記ウェブシステムが異なるサービスを提供する複数のアプリケーションサーバを含み、各サービスが複数のアプリケーションの組合せで実現される場合、
前記モデル格納部は、サービス、アプリケーション、およびサーバのそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、
前記予測モデル作成部は、サービス、アプリケーション、およびサーバのそれぞれに対して予測モデルを作成し、
前記性能あふれ予知部は、作成されたサービス、アプリケーション、およびサーバの予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めることを特徴とする請求項１に記載の性能監視装置。
【請求項３】
前記ウェブシステムが、当該ウェブシステムへのアクセス経路毎にサービスを分担する複数のサーバを含む場合、
前記モデル格納部は、前記複数のサーバそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、
前記予測モデル作成部は、前記複数のサーバのそれぞれに対して予測モデルを作成し、
前記性能あふれ予知部は、作成された予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めることを特徴とする請求項１に記載の性能監視装置。
【請求項４】
前記予測モデル作成部は、前記ファクタ入力部において入力されるファクタのタイプに応じて異なる予測モデルを修正することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項５】
前記データ取得部は、前記パラメータの種類に応じて取得のタイミングを変更することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項６】
前記性能あふれ予知部は、求めようとする性能予測値に応じて、予め対応が決められている前記パラメータと前記予測モデルとを使用することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項７】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、予め余分に準備されているサーバを前記ウェブシステム内でリソースが不足すると予測されたアプリケーションまたはサービスに分配するリソース割り当て部を備えることを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項８】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記データ取得部は、前記ウェブシステムにおいて未使用のリソースを検出し、
前記対策実行部は、検出された未使用のリソースを、前記ウェブシステム内でリソースが不足すると予測されたアプリケーションまたはサービスに分配するリソース割り当て部を備えることを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項９】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、前記ウェブシステムへのログインを制限させるログイン制限部を含むことを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項１０】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、前記ウェブシステムにおいて一部のアプリケーションまたはサービスの提供を維持するために、それ以外のアプリケーションまたはサービスの提供を停止させるサービス停止部を含むことを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項１】
ネットワーク上でサービスを提供する監視対象のウェブシステムから所定のパラメータを取得するデータ取得部と、
前記ウェブシステムの性能を予測するための予測モデルのベースとなるベースモデルを格納するモデル格納部と、
前記予測モデルを用いた予測結果に影響を与えるデータであるファクタの入力を受け付けるファクタ入力部と、
前記ファクタを利用して前記ベースモデルを修正し予測モデルを作成する予測モデル作成部と、
作成された予測モデルと前記パラメータとから、前記ウェブシステムの特定時点における性能を表すデータである性能予測値を求め、該性能予測値と所定のしきい値との比較によって前記ウェブシステムにおいて所定の性能を維持できなくなる性能あふれの発生を予知する性能あふれ予知部と、
性能あふれが予知されたとき、前記ウェブシステムの性能を回復させる所定の対策プロセスを実行する対策実行部と、
を備えることを特徴とするウェブシステムの性能監視装置。
【請求項２】
前記ウェブシステムが異なるサービスを提供する複数のアプリケーションサーバを含み、各サービスが複数のアプリケーションの組合せで実現される場合、
前記モデル格納部は、サービス、アプリケーション、およびサーバのそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、
前記予測モデル作成部は、サービス、アプリケーション、およびサーバのそれぞれに対して予測モデルを作成し、
前記性能あふれ予知部は、作成されたサービス、アプリケーション、およびサーバの予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めることを特徴とする請求項１に記載の性能監視装置。
【請求項３】
前記ウェブシステムが、当該ウェブシステムへのアクセス経路毎にサービスを分担する複数のサーバを含む場合、
前記モデル格納部は、前記複数のサーバそれぞれの性能を予測するための予測モデルのベースとなるベースモデルを格納し、
前記予測モデル作成部は、前記複数のサーバのそれぞれに対して予測モデルを作成し、
前記性能あふれ予知部は、作成された予測モデルを使用して、各予測モデルに予め対応付けられている性能予測値を求めることを特徴とする請求項１に記載の性能監視装置。
【請求項４】
前記予測モデル作成部は、前記ファクタ入力部において入力されるファクタのタイプに応じて異なる予測モデルを修正することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項５】
前記データ取得部は、前記パラメータの種類に応じて取得のタイミングを変更することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項６】
前記性能あふれ予知部は、求めようとする性能予測値に応じて、予め対応が決められている前記パラメータと前記予測モデルとを使用することを特徴とする請求項１ないし３のいずれかに記載の性能監視装置。
【請求項７】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、予め余分に準備されているサーバを前記ウェブシステム内でリソースが不足すると予測されたアプリケーションまたはサービスに分配するリソース割り当て部を備えることを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項８】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記データ取得部は、前記ウェブシステムにおいて未使用のリソースを検出し、
前記対策実行部は、検出された未使用のリソースを、前記ウェブシステム内でリソースが不足すると予測されたアプリケーションまたはサービスに分配するリソース割り当て部を備えることを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項９】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、前記ウェブシステムへのログインを制限させるログイン制限部を含むことを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【請求項１０】
前記性能あふれ予知部が、前記ウェブシステムにおいてアプリケーションまたはサービスを実行するリソースの不足のために性能あふれが発生すると予知した場合、
前記対策実行部は、前記ウェブシステムにおいて一部のアプリケーションまたはサービスの提供を維持するために、それ以外のアプリケーションまたはサービスの提供を停止させるサービス停止部を含むことを特徴とする請求項１ないし６のいずれかに記載の性能監視装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００７−２６５２４４（Ｐ２００７−２６５２４４Ａ）
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願番号】特願２００６−９１９６１（Ｐ２００６−９１９６１）
【出願日】平成１８年３月２９日（２００６．３．２９）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願日】平成１８年３月２９日（２００６．３．２９）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]