(57)【要約】【課題】ネットワーク上で証券の売買注文サービスを提供する証券システムのトラフィックを監視する。【解決手段】データ取得部１２は、ネットワークを介した証券の売買注文サービスを提供する証券システム１００におけるトラフィック量を複数の日にわたって取得する。データ作成部１６は、証券システム１００において第１の時刻に測定したトラフィック量と、第１の時刻より後の第２の時刻に測定したトラフィック量との間の関係を表すデータを作成する。トラフィック量推定部２２は、特定の日の第１の時刻に測定したトラフィック量と前記データとを使用して、第２の時刻におけるトラフィック量を推定する。対策実行部３０は、推定されたトラフィック量と所定のしきい値とを比較して、証券システムにおいて推定されたトラフィック量を処理するためのリソースが不足すると予測されたとき、所定の対策プロセスを実行する。【選択図】図２
2007265245.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介した証券の売買注文サービスを提供する証券システムにおけるトラフィック量を複数の日にわたって取得するデータ取得部と、
前記証券システムにおいて第１の時刻に測定したトラフィック量と、該第１の時刻より後の第２の時刻に測定したトラフィック量との間の関係を表す推定用データを作成するデータ作成部と、
特定の日の第１の時刻に測定したトラフィック量と前記推定用データとを使用して、第２の時刻におけるトラフィック量を推定するトラフィック量推定部と、
推定されたトラフィック量と所定のしきい値とを比較して、前記証券システムにおいて推定されたトラフィック量を処理するためのリソースが不足すると予測されたとき、所定の対策プロセスを実行する対策実行部と、
を備えることを特徴とする証券システムのトラフィック監視装置。
【請求項２】
前記データ作成部は、第１の時刻のトラフィック量に乗じて第２の時刻のトラフィック量を算出するための比例係数を前記推定用データとして作成することを特徴とする請求項１に記載のトラフィック監視装置。
【請求項３】
前記データ作成部は、第１の時刻のトラフィック量から第２の時刻のトラフィック量をベイズ推定にしたがって求めるための確率を前記推定用データとして作成することを特徴とする請求項１に記載のトラフィック監視装置。
【請求項４】
前記トラフィック量推定部は、複数の推定用データを使用して第２の時刻におけるトラフィック量を推定し、そのうちの一つを出力することを特徴とする請求項１に記載のトラフィック監視装置。
【請求項５】
前記データ作成部は、トラフィック量を予測する日の曜日または日付に応じた複数の推定用データを作成することを特徴とする請求項１ないし４のいずれかに記載のトラフィック監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上で証券の売買注文サービスを提供する証券システムのトラフィックを監視する技術に関する。
【背景技術】
【０００２】
ユーザがウェブブラウザ等を使用してインターネット経由でウェブシステムに送信するサービス要求は、年々飛躍的に増大している。近年では、トラフィック量の増加にシステムの増強が追いつかず、システムダウンするようなケースも頻発している。そこで、ウェブシステムの性能を監視しトラフィックあふれの発生を事前に予測するとともに、トラフィックあふれが発生したときにそれを素早く検知して的確な対策を実施できるウェブシステムの性能監視技術が求められている。そのような技術として、例えば特許文献１には、ＷＷＷサイトのサイトアクセスの変動を定期的に予測することによってサイトの性能を予測し、定められた性能を維持できるか否かを判断するＷＷＷサイトの性能監視装置が開示されている。
【特許文献１】特開２００２−２６８９２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ネットワーク上で証券の売買注文サービスを提供する証券システムは、証券取引所の開場時間に合わせてトラフィック量が大きく変化するという特性を持つ。したがって、通常のウェブシステムに合わせて構築されたモデルを用いても、トラフィック量の正確な予測が困難であるという問題がある。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、証券システムにおけるトラフィック量を推定するトラフィック監視装置を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、証券システムのトラフィック監視装置である。この装置は、ネットワークを介した証券の売買注文サービスを提供する証券システムにおけるトラフィック量を複数の日にわたって取得するデータ取得部と、証券システムにおいて第１の時刻に測定したトラフィック量と、該第１の時刻より後の第２の時刻に測定したトラフィック量との間の関係を表す推定用データを作成するデータ作成部と、特定の日の第１の時刻に測定したトラフィック量と推定用データとを使用して、第２の時刻におけるトラフィック量を推定するトラフィック量推定部と、推定されたトラフィック量と所定のしきい値とを比較して、証券システムにおいて推定されたトラフィック量を処理するためのリソースが不足すると予測されたとき、所定の対策プロセスを実行する対策実行部と、を備える。
【０００６】
この態様によると、過去のトラフィック量の統計から得られる推定用データと第１の時刻のトラフィック量とから、将来の時点である第２の時刻におけるトラフィック量を推定できるため、証券システムのリソースが不足する場合の対策を早期に開始することができる。
【０００７】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、証券システムにおけるトラフィック量を過去のデータに基づいて推定することができる。
【発明を実施するための最良の形態】
【０００９】
本発明の一実施形態は、ネットワーク上で証券の売買注文サービスや売買に関する情報提供サービスなどを提供する証券システムにおけるトラフィックを監視するトラフィック監視装置である。以下、本実施形態について詳細に説明する。
【００１０】
図１は、本実施形態にかかるトラフィック監視装置の監視対象である証券システム１００の構成を示す。証券システム１００は、証券会社に設置され、顧客からの証券の売買注文を受け付けたり、証券注文に役立つ様々な情報を提供するシステムである。
【００１１】
証券システム１００は、プレゼンテーションレイヤ１１０とビジネスロジックレイヤ１２０を含む。プレゼンテーションレイヤ１１０は、主にクライアント端末から入力されるデータを受け付けてビジネスロジックレイヤ１２０に渡したり、またはビジネスロジックレイヤ１２０から提供されるデータをウェブページに加工してクライアント端末に提供する役割を有する。ビジネスロジックレイヤ１２０は、証券の売買注文や情報の提供などの実際の処理を担当する役割を有する。
【００１２】
プレゼンテーションレイヤ１１０は、複数のウェブサーバを含む。本実施形態では、証券システム１００に対するアクセスチャネル毎に、ウェブページの処理を実行するサーバのグループが準備されている。図１では、ウェブ経由の一般顧客、コールセンター、支店からそれぞれのクライアント端末８２ａ〜８２ｃを使用して証券システム１００にアクセスする場合を想定している。したがって、プレゼンテーションレイヤ１１０には、一般顧客からのアクセスに対する処理を担当する一般用ウェブサーバ１０２と、コールセンターからのアクセスに対する処理を担当するコールセンター用ウェブサーバ１０４と、支店からのアクセスに対する処理を担当する支店用ウェブサーバ１０６とを備える。さらに、通常は休止している予備のウェブサーバ１０８を準備しておいてもよい。ウェブサーバ１０２〜１０８は、複数のサーバで構成されてもよい。各ウェブサーバ１０２〜１０８は、上記の機能の他、クライアント端末からの要求に応じてプログラムを実行しその結果を送信する動的ページの生成機能やトランザクション管理機能などを実装している。
【００１３】
ビジネスロジックレイヤ１２０には、アクセスチャネル毎ではなく、所定のアプリケーションを専用に実行するサーバのグループが準備されている。本実施形態では、現在および過去の株価や出来高、会社情報などの証券売買の際に必要となる情報をクライアント端末に提供するアプリケーションを実行する情報提供アプリケーションサーバ１２２、株や投資信託などの売買注文を受け付けるアプリケーションを実行する注文処理アプリケーションサーバ１２４、ユーザのログインやログアウト、顧客情報などを管理するアプリケーションを実行する事務処理アプリケーションサーバ１２６を備えているものとする。これ以外にも、例えば、外部の新聞社のサイトなどと連携して経済ニュースを提供する外部連携アプリケーションサーバや、顧客毎に取引残高の報告書などを提供する報告書アプリケーションサーバなどを備えていてもよい。アプリケーションサーバ１２２〜１２６は、複数のサーバで構成されてもよい。各アプリケーションサーバ１２２〜１２６は、上記の業務処理の機能の他、一般のアプリケーションサーバが有している機能、例えば、データベースへの接続機能、複数の処理を連結するトランザクション管理機能なども実装している。
【００１４】
各アプリケーションサーバ１２２〜１２６では、複数のクライアント端末に対するサービス１３０〜１４０が同時に実行される。例えば、情報提供アプリケーションサーバ１２２では、一般顧客に対して株価情報を提供するサービスＡ１３０と、コールセンターに対して株価情報を提供するサービスＢ１３２が同時に実行されてもよい。注文処理アプリケーションサーバ１２４では、コールセンターからの株式売買注文を処理するサービスＣ１３４と、店舗からの投資信託売買注文を処理するサービスＤ１３６が同時に実行されてもよい。
【００１５】
一般顧客、コールセンターや支店の担当員は、それぞれのクライアント端末８２ａ〜８２ｃからウェブブラウザなどのソフトウェアを使用し、インターネット等のネットワーク８０を介して証券システム１００にアクセスする。コールセンターや支店に備えられるクライアント端末８２ｂ、８２ｃは、証券システム１００と専用線８４によって接続されていてもよい。
【００１６】
クライアント端末８２ａ〜８２ｃから証券システム１００にアクセスすると、プレゼンテーションレイヤ１１０のアクセスチャネルに応じたウェブサーバ１０２〜１０６によって作成されたウェブページが、クライアント端末８２ａ〜８２ｃに送信される。クライアント端末８２ａ〜８２ｃは、送信されたウェブページをディスプレイに表示する。ユーザがウェブページ上でログイン、情報の閲覧、売買注文などの操作を実行すると、その情報がウェブサーバ１０２〜１０６を介してビジネスロジックレイヤ１２０のアプリケーションサーバ１２２〜１２６に渡される。各アプリケーションサーバ１２２〜１２６による処理の結果は、ウェブサーバ１０２〜１０６によってウェブページに加工され、そのデータがクライアント端末８２ａ〜８２ｃに送信される。こうしてユーザは、ウェブページに表示される種々の情報を参照したり、またはウェブページを通じて証券の売買注文をすることができる。
【００１７】
上述したような証券システムでは、アクセス数の増大によりシステム内のトラフィック量が処理能力を越えると、正常なサービスを提供できなくなる。このような事態は顧客に迷惑をかけるため、証券システムにおける将来のトラフィック量を推定して、証券システムの処理能力を越えそうな場合には早期に適切な対策が取られることが望ましい。そこで、本実施形態では、過去のトラフィック量の統計データと当日のある時点のトラフィック量とから、それ以降のトラフィック量を推定するトラフィック監視装置を設けた。
【００１８】
図２は、トラフィック監視装置１０の構成を示す機能ブロック図である。これらの構成は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１９】
データ取得部１２は、監視対象の証券システム１００におけるトラフィック量を複数の日にわたって、例えば３ヶ月分取得する。データ取得部１２は、所定の時間間隔、例えば１０分毎にトラフィック量を測定し、測定時刻とトラフィック量とを対応づけてデータ作成部１６に渡す。本明細書において「トラフィック量」とは、証券システム１００におけるトランザクション件数、ページビュー数、アプリケーション呼出し件数のいずれであってもよい。
【００２０】
データ作成部１６は、データ取得部１２で測定されたトラフィック量を蓄積し、複数日分のデータを用いて、第１の時刻（例えば、６時）に測定したトラフィック量と、第２の時刻（例えば、９時）に測定したトラフィック量との間の関係を表す推定用データを作成する。作成された推定用データは、データ格納部１８に格納される。
【００２１】
データ作成部１６は、曜日や特定の日付などに応じて別々の推定用データを作成することが好ましい。推定用データの詳細な作成手順については後述する。
なお、推定用データは、上述の６時と９時との間の関係に限られず、任意の時刻について作成することができる。第２の時刻は、証券システム１００におけるトラフィック量がピークになる時間帯に設定されることが好ましいが、それ以外の時刻でもよい。また、推定用データは、日々測定されるトラフィック量を反映させて、毎日更新されることが好ましい。
【００２２】
データ格納部１８は、データ作成部１６で作成された推定用データを格納する。図２の例では、平日におけるトラフィック量を推定するための「平日データ」２４、休日におけるトラフィック量を推定するための「休日データ」２６、休み明けの日のトラフィック量を推定するための「休み明けデータ」２８が格納されている。
【００２３】
トラフィック量推定部２２は、特定の日、通常は当日の第１の時刻に測定したトラフィック量を使用して、第２の時刻のトラフィック量を推定する。まず、第１の時刻に測定されたトラフィック量をデータ取得部１２から受け取る。トラフィック量推定部２２は、当日の曜日または日付を内蔵するカレンダーから取得し、対応する推定用データをデータ格納部１８から取り出す。そして、推定用データに第１の時刻のトラフィック量を適用して、第２の時刻の推定トラフィック量を算出する。推定トラフィック量は、対策実行部３０に送られる。この手順についてはさらに後述する。
【００２４】
対策実行部３０は、第２の時刻における推定トラフィック量と所定のしきい値とを比較して、第２の時刻において、証券システム１００が推定トラフィック量を処理するためのリソースが不足するか否かを判定する。例えば、証券システム１００の帯域、処理能力、メモリ空き容量などが、推定トラフィック量を適切な時間内で安定的な処理をするために十分であるか否かを判定する。
そして、対策実行部３０は、リソースが不足すると判定したとき、リソース不足による証券システム１００の停止または性能の低下を回避するための所定の対策プロセスを実行する。対策実行部３０は、リソース割り当て部３２と、ログイン制限部３４と、サービス停止部３６と、エラー通知部３８とを含む。
【００２５】
リソース割り当て部３２は、予め余分に準備されているサーバをリソースが不足すると予測されたアプリケーションまたはサービスに分配する。より具体的な例を述べると、例えば、リソース割り当て部３２は、予備のウェブサーバ１０８に対して、リソース不足が予測されるウェブサーバまたはアプリケーションサーバにおける処理の一部を分担するように指令する。
【００２６】
または、リソース割り当て部３２は、証券システム１００内の未使用のサーバまたはワークスペースを、リソースが不足すると予測されたアプリケーションまたはサービスに分配するようにしてもよい。この場合、データ取得部１２は、証券システム１００内で未使用のリソースを予め検出しておく必要がある。このように、リソース割り当て部３２によって、システム内のリソースを動的に運用することができる。
【００２７】
ログイン制限部３４は、証券システム１００においてリソースが不足すると判定された場合に、証券システム１００へのログインを制限させる。具体的には、ログイン制限部３４は、事務処理アプリケーションサーバ１２６に対して、一定数以上のログインを受け付けないように指令する。
【００２８】
サービス停止部３６は、証券システム１００においてリソースが不足すると判定された場合に、特定のアプリケーションまたはサービス以外のアプリケーションまたはサービスの提供を停止させる。この特定のアプリケーションまたはサービスは、システムにおいて最も重要な基幹業務を実施するものであることが好ましい。証券システム１００であれば、注文処理アプリケーションサーバ１２４における売買注文サービスが最も重要であるから、情報提供アプリケーションサーバ１２２における情報の提供サービスや、または事務処理アプリケーションサーバ１２６による顧客情報の更新などのサービスを停止させることが好ましい。このように一部のサービスを停止することによって、基幹となるサービスを維持しつつ、障害の発生によるシステム全体のダウンを回避することができる。
【００２９】
サービス停止部３６は、証券システム１００においてリソースが不足すると判定された場合、ウェブサーバのうち特定のアクセスチャネルに対応するものだけを停止するようにしてもよい。例えば、一般用ウェブサーバ１０２を停止させて、コールセンター用ウェブサーバ１０４と支店用ウェブサーバ１０６はそのまま維持してもよい。この場合、一般用ウェブサーバ１０２のリソースを、コールセンター用ウェブサーバ１０４や支店用ウェブサーバ１０６に割り当てるようにリソース割り当て部３２に指示してもよい。
【００３０】
エラー通知部３８は、証券システム１００においてリソースが不足すると判定された場合、システム管理者などに対してリソース不足が予測されている旨のｅメールを発信する。これによって、システム管理者はトラフィック増大によるリソース不足が実際に発生する前に、必要な人員を集めるなどの対策を迅速に立てることができる。エラー通知部３８は、「混み合っているためしばらくの間接続をお控えください」などのユーザに対する通知を表示するウェブページを準備しておくように、ウェブサーバ１０２〜１０６に指示してもよい。
【００３１】
続いて、本実施形態におけるトラフィック量の推定方法について説明する。
図３は、証券システムにおける平日のトラフィック量の時間的推移を表すグラフである。グラフ中の３本の線は、それぞれ別の日に測定したトラフィック量を表している。図示するように、測定日によってトラフィック量の総数は大きく変わるが、グラフの形状は互いに似通っていることがわかる。特に、証券システムの負荷が最も大きくなるのは、前場が開いた直後の朝９時である。そこで、本願発明者は、トラフィック量の推移を過去の相当期間にわたってデータとして蓄積しておけば、朝の６時に測定したトラフィック量を用いて、トラフィック量がピークに達する９時のトラフィック量を推定できることに想到した。
【００３２】
また、証券システムにおけるトラフィック量には、一般的に以下のような傾向が見られる。
１．平日と土曜日、日曜日とでは、トラフィック量が大きく異なる。
２．一週間の間でも曜日毎の傾向がある。
３．休み明け（通常は月曜日、月曜日が祝日であれば火曜日）の朝６時のトラフィック量は、他の平日に比べると少ない。
【００３３】
そこで、本実施形態では、トラフィック量の推定用データとして、「平日データ」「休日データ」「休み明けデータ」を設け、６時のトラフィック量と９時のトラフィック量との関係を表すデータを過去の測定結果から作成するようにした。これによって、トラフィック量を推定する日、通常は当日の朝６時のトラフィック量を測定した時点で、トラフィック量がピークに達する９時のトラフィック量を推定することができる。
【００３４】
なお、推定用データは、上述の分類に限られない。休日用データの代わりに、土曜日データと日曜日データを別々に作成してもよいし、他にも曜日毎のデータを作成してもよい。また、月末用のデータや、注目すべき各種の経済統計データが発表される日の推定用データを作成してもよい。
【００３５】
さらに、６時と９時以外の時刻の推定用データを作成してもよいことは言うまでもない。例えば、７時や８時のトラフィック量と９時のトラフィック量との関係を表す推定用データを別に作成してもよい。また、９時のトラフィック量と後場が引ける１５時のトラフィック量との関係を表す推定用データを作成してもよい。このように、第１の時刻と第２の時刻の組合せは任意である。
【００３６】
次に、推定用データの作成手順について述べる。
【００３７】
第１の方法は、第１の時刻のトラフィック量に乗じて第２の時刻のトラフィック量を算出するための比例係数を求めておくものである。データ作成部１６は、過去の測定結果から、平日、休日、休み明けの日それぞれについて、６時に測定したトラフィック量ｔ６と９時に測定したトラフィック量ｔ９とを取り出し、比例係数ｃ＝ｔ９／ｔ６を計算する。平日、休日、休み明けの日それぞれについて、所定の日数（例えば、３０日）分のｃの平均ｃａを計算し、これを平日データ、休日データ、休み明けデータとしてデータ格納部１８に格納する。
トラフィック量推定部２２は、６時に測定したトラフィック量にｃａを乗じることで、９時のトラフィック量を推定する。
【００３８】
第２の方法は、周知のベイズ推定を用いる方法である。
データ作成部１６は、過去の測定結果から、平日、休日、休み明けの日それぞれについて、６時に測定したトラフィック量と９時に測定したトラフィック量とを取り出す。これらのトラフィック量を、それぞれいくつかの段階、例えば１０段階に分ける。ここでは、６時のトラフィック量についての段階をｘｉ（但し、ｉ＝１，２，...，１０）、９時のトラフィック量についての段階をｙｊ（但し、ｊ＝１，２，...，１０）と表記する。なお、段階は１０段階よりさらに細かくした方が推定の精度は高くなる。
【００３９】
続いて、データ作成部１６は、平日、休日、および休み明けの日それぞれについて、（１）９時にｙｉのときに６時にｘｉである条件付き確率Ｐ(ｘｉ｜ｙｉ)と、（２）６時にｘｉである確率Ｐ(ｘｉ)と、（３）９時にｙｉである確率Ｐ(ｙｊ)とを計算する。平日、休日、休み明けの日それぞれについて計算されたＰ(ｘｉ｜ｙｉ)、Ｐ(ｘｉ)、Ｐ(ｙｊ)を、平日データ、休日データ、休み明けデータとしてデータ格納部１８に格納する。
【００４０】
トラフィック量推定部２２は、以下の式にしたがって、６時に測定したトラフィック量を含む段階ｘｋについて９時に値ｙｊとなる確率を、１０段階全て（ｊ＝１，２，...，１０）についてそれぞれ算出する。
Ｐ(ｙｊ｜ｘｋ)＝｛Ｐ(ｙｊ)・Ｐ(ｘｋ｜ｙｊ)｝／Ｐ(ｘｋ)
なお、ベイズ推定は周知の技術であるから、これ以上詳細な説明は省略する。
【００４１】
上式により、段階ｙｊについての確率分布が求められる。トラフィック量推定部２２は、この確率分布の分散を計算し、分散が所定のしきい値より大きい場合、つまりばらつきが大きい場合は、最も確率の高い段階ｙｊの中央値を９時の推定トラフィック量とする。また、分散が所定のしきい値以下の場合、つまりばらつきが小さい場合は、確率が０でない段階ｙｊのうち最も大きい段階ｙｊの中央値を９時の推定トラフィック量とする。
【００４２】
第３の方法は、偏差値を用いる方法である。
データ作成部１６は、過去の測定結果から、平日、休日、休み明けの日それぞれについて、６時に測定したトラフィック量の集合と、９時に測定したトラフィック量の集合とを取り出す。データ作成部１６は、それぞれの集合を母集団として、標準偏差σ６とσ９を算出する。平日、休日、休み明けの日それぞれについて計算されたσ６、σ９を、平日データ、休日データ、休み明けデータとしてデータ格納部１８に格納する。
【００４３】
トラフィック量推定部２２は、σ６を使用して、６時に測定したトラフィック量ｘの偏差値Ｔを求める。そして、９時に測定したトラフィック量の集合のなかから、偏差値がＴと同じになるトラフィック量ｙを求め、これを９時の推定トラフィック量とする。
【００４４】
第４の方法は、クラスタリングを用いる方法である。
データ作成部１６は、過去の測定結果を使用して、平日、休日、休み明けの日それぞれについて、６時に測定したトラフィック量と９時に測定したトラフィック量とを取り出す。６時のトラフィック量と９時のトラフィック量との相関について周知のクラスタ分析を実行し、各クラスタ内での相関関係を表す近似式を求める。平日、休日、休み明けの日それぞれについて求められたクラスタおよび近似式を、平日データ、休日データ、休み明けデータとしてデータ格納部１８に格納する。
【００４５】
トラフィック量推定部２２は、６時に測定したトラフィック量ｘの属するクラスタを決定し、そのクラスタでの近似式に６時のトラフィック量ｘを代入して、９時の推定トラフィック量ｙを求める。
【００４６】
なお、トラフィック量推定部２２は、上述した複数の推定方法にしたがった推定用データを使用して９時のトラフィック量をそれぞれ推定し、それらのうちのいずれか一つを推定トラフィック量として出力してもよいし、それらの最大値、最小値、または平均値を推定トラフィック量として出力してもよい。また、これら以外の既知の推定方法を利用することも可能である。
【００４７】
図４は、本実施形態にかかるトラフィック量推定プロセスのフローチャートである。まず、トラフィック量推定部２２は、データ格納部１８から、当日の日付、曜日に応じた推定用データを取り出す（Ｓ１０）。続いて、データ取得部１２から６時に測定されたトラフィック量を受け取り（Ｓ１２）、推定用データにトラフィック量を入力して、９時の推定トラフィック量を算出する（Ｓ１４）。対策実行部３０は、算出された推定トラフィック量としきい値とを比較して、証券システム１００のリソースが十分か否かを判定する（Ｓ１６）。リソースが十分であれば（Ｓ１６のＹ）、そのまま証券システム１００の監視を継続する（Ｓ２０）。リソースが不足すれば（Ｓ１６のＮ）、対策実行部３０は所定の対策プロセスを実行（Ｓ１８）した後、証券システム１００の監視を継続する（Ｓ２０）。
【００４８】
ここでプロセスを終了してもよいが、さらにトラフィック量推定部２２は、データ取得部１２から８時に測定したトラフィック量を受け取り、予め作成されている８時用の推定用データから９時の推定トラフィック量を算出してもよい（Ｓ２２）。一般に、現在の時刻が推定する時刻に近づくほど推定の精度も上がるため、２回目の推定をすることでより９時の推定トラフィック量の確実さを高めることができる。対策実行部３０は、算出された推定トラフィック量としきい値とを比較して、証券システム１００のリソースが十分か否かを判定する（Ｓ２４）。リソースが十分であれば（Ｓ２４のＹ）、このプロセスを終了する。リソースが不足すれば（Ｓ２４のＮ）、対策実行部３０は所定の対策プロセスを実行する（Ｓ２６）。
【００４９】
この場合、Ｓ１８とＳ２６でそれぞれ採用される対策プロセスは異なることが好ましい。トラフィック量がピークとなる９時に近づくほど、とりうるべき対策の選択肢が限られてくるからである。したがって、時間のかかる対策はＳ１８の方で採用することが好ましい。一例として、６時での推定トラフィック量に基づくＳ１８では、推定トラフィック量と比較すべきしきい値を低めに設定しておき、システム管理者に警告を発して早期にサポート体制が整えられるようにしておく。その一方、８時での推定トラフィック量に基づくＳ２６では、本来のしきい値でリソースの不足を判定して、リソースが十分であれば警告を解除するなどといった応用が考えられる。
【００５０】
図５は、証券システム１００のウェブサーバ、アプリケーションサーバのハードウェア構成を示す。各サーバは、プログラムにしたがって各種処理を実行するＣＰＵ７０と、一時的にデータやプログラムを記憶するメモリ７２と、ハードディスクドライブ、ＤＶＤディスクドライブなどの記憶装置７４と、ネットワークに接続し各種の入出力処理を実行するネットワークインタフェース７６と、これらを相互接続するバス７８と、を少なくとも含む。サーバは、必要に応じて、キーボードやマウス等の入力装置、ディスプレイなどの出力装置を有していてもよい。なお、一つのサーバが二つ以上のネットワークインタフェース７６を有していてもよい。
【００５１】
各サーバは、一枚の基板にコンピュータとして動作するために必要な要素、つまりＣＰＵ、メモリ、ハードディスク、バスなどが搭載されたブレードサーバであることが好ましく、ウェブサーバ１０２〜１０８やアプリケーションサーバ１２２〜１２６は、このブレードサーバが筐体に複数差し込まれているような構成をとることが好ましいが、他の形態であってもよい。
【００５２】
各サーバは、ルータ（図示せず）を介してネットワークストレージ（図示せず）と通信可能に構成されている。アプリケーションの実行に必要なマスタテーブルやデータベース等はネットワークストレージに格納されており、必要に応じてネットワークストレージから各サーバに送信可能となっている。ネットワークストレージは一般にはハードディスク装置であり、通常、複数のディスクを集めてＲＡＩＤを構成しているが、磁気テープ装置であってもよい。
【００５３】
以上説明したように、本実施形態によれば、過去のトラフィック量の統計データから、第１の時刻と第２の時刻におけるトラフィック量の関係を定める推定用データを作成しておき、トラフィック量を推定したい日の第１の時刻のトラフィック量を推定用データに入力することによって、第２の時刻のトラフィック量を推定できるようにした。これによって、トラフィック量の増大を予測できるため、証券システムのリソースが不足する場合の対策を早期に開始することができる。また、推定用データを曜日や日付毎に作成するようにしたので、トラフィック量をより正確に推定することができる。
【００５４】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例がありうること、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５５】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００５６】
実施の形態と同様の手順を用いて、後場のトラフィック量を推定することもできる。この場合、対策実行部３０は、後場のトラフィック量が所定のしきい値より小さかった場合に、証券システム内のオンライン処理用のサーバをバッチ処理用のサーバに転用したり、証券システム以外の他のシステムに一部のリソースを割り当てたりしてもよい。または、システム管理者に対し、証券システムを構成する各種サーバの一部の入れ替え作業を提案してもよい。
【００５７】
実施の形態では、証券システムの全体について推定用データを作成したが、推定用データは、プレゼンテーションレイヤやビジネスロジックレイヤについてそれぞれ作成してもよいし、ウェブサーバやアプリケーション毎に作成してもよい。
【００５８】
実施の形態では、ある特定の日におけるトラフィック量の推定について述べたが、より長期的なトラフィック量の予測に本発明を適用することもできる。例えば、ある一日のトラフィック量と、その一週間後や一ヶ月後の一日のトラフィック量との関係を表す推定用データを作成しておくことで、一週間先や一ヶ月先のトラフィック量を推定することができる。これによって、例えば、月末のトラフィック量を推定してサーバの割り当て台数を増強する、一週間先の休日のトラフィック量を推定して必要なサーバ台数を見積もり、不要なサーバについてはシステムから切り離して検査したり動作試験に用いるなどの計画を立てるといった利用方法が考えられる。
【図面の簡単な説明】
【００５９】
【図１】本実施形態にかかるトラフィック監視装置の監視対象である証券システムの構成を示す図である。
【図２】トラフィック監視装置の構成を示す機能ブロック図である。
【図３】証券システムにおける平日のトラフィック量の時間的推移を表すグラフである。
【図４】トラフィック量推定プロセスのフローチャートである。
【図５】証券システムのウェブサーバ、アプリケーションサーバのハードウェア構成を示す図である。
【符号の説明】
【００６０】
１０  トラフィック監視装置、  １２  データ取得部、  １６  データ作成部、  １８  データ格納部、  ２２  トラフィック量推定部、  ２４  平日データ、  ２６  休日データ、  ２８  休み明けデータ、  ３０  対策実行部、  ８２  クライアント端末、  １００  証券システム。
【図１】
2007265245.tif 000003
【図２】
2007265245.tif 000004
【図３】
2007265245.tif 000005
【図４】
2007265245.tif 000006
【図５】
2007265245.tif 000007