JP5646442B2 - 分析装置および分析方法 - Google Patents

Description

本発明は、金融商品業務システムを分析するための分析装置および分析方法に関する。

ユーザがインターネットを介して株式売買や外貨取引を行えるオンラインサービスが普及している。その手軽さや手数料の低さから、オンラインサービスのユーザ数は年々増大している。ユーザ数の増大に伴い、オンラインサービスを提供する証券業務システムへの負荷も大きくなってきている。オンラインサービスでは取引の即時性が特に重要視されることから、過負荷によるシステムダウンをできる限り回避しなければならない。

そこで本出願人は特許文献１および特許文献２において、証券業務システムへの負荷を予測する技術を提案している。このように予測された負荷に基づき、システムのキャパシティが予測された負荷を十分上回るようにするための処理が行われることが望ましい。本出願人は特許文献３および特許文献４において、そのような処理の例を提案している。

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

オンラインサービスの多様化、高機能化に伴い、それを支える証券業務システムのサーバ構成もより複雑となってきている。すなわち証券業務システムでは、多種多様なサーバが有機的に結合され、その上でやはり多種多様なサービスが実現されるようになってきている。これは、証券業務システムだけでなく金融商品業務システム一般にも当てはまる。このような金融商品業務システムのサーバ構成の複雑化により適応した分析技術の登場が望まれている。

本発明はこうした課題に鑑みてなされたものであり、その目的は、金融商品業務システムのサーバ構成の複雑化に適応できる分析技術の提供にある。

本発明のある態様は分析装置に関する。この分析装置は、処理能力の異なる複数のサーバを有する金融商品業務システムを分析するための分析装置であって、複数のサーバによって処理されるリクエストの件数の予測値である総予測件数と、複数のサーバを処理能力で複数のクラスに分類したときの各クラスに属するサーバの数と、を取得するパラメータ取得部と、パラメータ取得部によって取得された総予測件数および複数のサーバの総数に基づいて、各サーバによって処理されるリクエストの件数の予測値であるサーバ単位予測件数を演算するサーバ単位予測件数演算部と、処理能力のクラスごとに、サーバによって処理されたリクエストの件数とサーバの処理余力の度合いとの相関関係を保持する相関保持部と、処理能力のクラスごとに、相関保持部によって保持される相関関係をサーバ単位予測件数演算部によって演算されたサーバ単位予測件数に適用することによって、サーバの処理余力の度合いの予測値を演算する負荷予測部と、を備える。

この態様によると、総予測件数と各クラスに属するサーバの数とを分析装置に入力することにより、クラスごとにサーバの処理余力の度合いの予測値を得ることができる。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、金融商品業務システムのサーバ構成の複雑化に適応できる分析技術を提供できる。

サーバ構成の移り変わりの一例を示す説明図である。 実施の形態に係る分析装置の分析対象となる証券業務システムの構成を示す模式図である。 実施の形態に係る分析装置およびそれに接続された部材の機能および構成を示すブロック図である。 パラメータ入力要求画面の代表画面図である。 図３のシナリオ保持部の一例を示すデータ構造図である。 図３の相関保持部の一例を示すデータ構造図である。 相関演算入力画面の代表画面図である。 図３の履歴保持部の一例を示すデータ構造図である。 相関演算結果画面の代表画面図である。 シナリオ別結果表示画面の代表画面図である。 面切り離し機能を説明するための模式図である。 レスポンスタイム表示画面の代表画面図である。 図３の分析装置における一連の処理を示すフローチャートである。 提示部によってディスプレイに表示されてもよい予測結果画面の代表画面図である。 別の履歴保持部の一例を示すデータ構造図である。

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。

実施の形態に係る分析装置の分析対象である証券業務システムは、処理能力の異なる複数のサーバを有する。サーバの処理能力は、サーバがリクエストを処理するスピードに応じた値によって示されてもよく、例えば通常稼動時にリクエスト１件を処理するのに必要な時間によって示されてもよい。あるいはまた、サーバの処理能力は、サーバのハードウエア構成やサーバの公称の性能値から導かれてもよい。

証券業務システムにおいてサーバの処理能力が異なる理由としては、例えばスケールアウト構成の場合は、サーバの購入時期の違いが挙げられる。前回の購入から今回の購入までの間に新型のサーバの提供が開始された場合などは、新旧サーバが混在することとなる。あるいはまた、証券業務システム２００の管理者がコストやパフォーマンスを考慮してサーバ購入先のベンダを変更した場合も、少なくとも移行期においては異なるベンダによる異なる処理能力のサーバが混在することとなる。

本実施の形態では、証券業務システムに含まれる複数のサーバを処理能力で複数のクラスに分類する。同一ベンダの同一機種のサーバをひとつのクラスに分類してもよい。同一ベンダの新旧機種のサーバをそれぞれ別のクラスに分類してもよい。異なるベンダのサーバをそれぞれ別のクラスに分類してもよい。

大規模災害には、サーバや電源等周辺設備の物理的な破損などにより、各クラスに属するサーバの稼動台数は変動しうる。また、サーバに使用されているハードディスクドライブなどのコンポーネントには寿命があるので、平時においても突発的に稼働台数が変動することがある。また、そのような寿命や、ベンダからの保守期限切れを見越してサーバを入れ替える場合やシステムキャパシティ増強のためにサーバを追加する場合にも、稼働台数は変動しうる。すなわち、各クラスに属するサーバの稼働台数は固定的なものではなく、時間の経過と共に変動する傾向にある。
なお、サーバの稼働台数は、リクエストを処理可能な稼動状態にあるサーバの数である。

図１は、サーバ構成の移り変わりの一例を示す説明図である。大規模災害によって全体的に稼動台数が減少した後、大規模災害前とは異なる構成で復旧し、その後構成変更されたことが示されている。

証券業務システムを安定的に稼動させるためには、各クラスに属するサーバの稼働台数の起こりうる変動を把握すると共に、そのような変動により証券業務システムのキャパシティがどのように変化するかを迅速に把握できると便利である。そして、稼働台数の変動により証券業務システムのキャパシティが足りなくなると予測される場合は、サーバを増強したり、サービスを閉塞させたりといった対策を取ることを検討してもよい。

本実施の形態に係る分析装置は、各クラスに属するサーバの稼働台数と、証券業務システムに含まれる複数のサーバによって単位時間当たり、例えば１日の間に処理されるリクエストの件数の予測値である総予測件数と、の入力を受ける。分析装置は、クラスごとに、１つのサーバによって１日の間に処理されるリクエストの件数（以下、処理件数と称す）とサーバの処理余力の度合いすなわちサーバのＣＰＵ使用率との相関関係を保持しておく。分析装置は、入力された総予測件数から処理件数の予測値を演算し、演算された処理件数を相関関係に当てはめることによってサーバのＣＰＵ使用率を演算する。分析装置は、演算されたクラス別のＣＰＵ使用率および平均のＣＰＵ使用率を管理者に提示する。これにより、管理者は、入力した稼働台数・総予測件数のもとでの証券業務システム全体のキャパシティを、迅速かつ的確に把握することができる。

（証券業務システム２００）
図２は、本実施の形態に係る分析装置の分析対象となる証券業務システム２００の構成を示す模式図である。証券業務システム２００は、証券会社に設置され、顧客などのユーザからの証券の売買注文を受け付けたり、証券注文に役立つ様々な情報を提供するシステムである。

証券業務システム２００は、プレゼンテーションレイヤ２１０とビジネスロジックレイヤ２２０とデータベースレイヤ２３０とを含む。プレゼンテーションレイヤ２１０は、主にクライアント端末２０２、２０４、２０６から入力されるデータを受け付けてビジネスロジックレイヤ２２０に渡したり、またはビジネスロジックレイヤ２２０から提供されるデータをウェブページに加工してクライアント端末２０２、２０４、２０６に提供する役割を有する。ビジネスロジックレイヤ２２０は、証券の売買注文や情報の提供などの実際の処理を担当する役割を有する。

プレゼンテーションレイヤ２１０は、複数のウェブサーバ２１２、２１４、２１６、２１８を含む。本実施の形態では、証券業務システム２００に対するアクセスチャネル毎に、ウェブページの処理を実行するサーバのグループが準備されている。図２では、ウェブ経由の一般顧客、コールセンタ、支店からそれぞれのクライアント端末２０２、２０４、２０６を使用して証券業務システム２００にアクセスする場合を想定している。したがって、プレゼンテーションレイヤ２１０は、一般顧客からのアクセスに対する処理を担当する一般用ウェブサーバ２１２と、コールセンタからのアクセスに対する処理を担当するコールセンタ用ウェブサーバ２１４と、支店からのアクセスに対する処理を担当する支店用ウェブサーバ２１６と、を備える。さらに、通常は休止している予備の予備ウェブサーバ２１８を準備しておいてもよい。各ウェブサーバ２１２、２１４、２１６、２１８は、複数のサーバで構成されてもよい。各ウェブサーバ２１２、２１４、２１６、２１８は、上記の機能の他、クライアント端末２０２、２０４、２０６からの要求に応じてプログラムを実行しその結果を送信する動的ページの生成機能やトランザクション管理機能などを実装している。

ビジネスロジックレイヤ２２０には、アクセスチャネル毎ではなく、所定のアプリケーションを専用に実行するサーバのグループが準備されている。ビジネスロジックレイヤ２２０は、現在および過去の株価や出来高、会社情報などの証券売買の際に必要となる情報をクライアント端末２０２、２０４、２０６に提供するアプリケーションを実行する情報提供アプリケーションサーバ２２２、株や投資信託などの売買注文を受け付けるアプリケーションを実行する注文処理アプリケーションサーバ２２４、ユーザのログインやログアウト、顧客情報などを管理するアプリケーションを実行する事務処理アプリケーションサーバ２２６を備える。これ以外にも、例えば、外部の新聞社のサイトなどと連携して経済ニュースを提供する外部連携アプリケーションサーバや、顧客毎に取引残高の報告書などを提供する報告書アプリケーションサーバなどを備えていてもよい。各アプリケーションサーバ２２２、２２４、２２６は、複数のサーバで構成されてもよい。各アプリケーションサーバ２２２、２２４、２２６は、上記の業務処理の機能の他、一般のアプリケーションサーバが有している機能、例えば、データベースレイヤ２３０のデータベースへの接続機能、複数の処理を連結するトランザクション管理機能なども実装している。

データベースレイヤ２３０には、ビジネスロジックレイヤ２２０から参照されたり更新されたりするデータベース（database、ＤＢ）が準備されている。データベースレイヤ２３０は、ビジネスロジックレイヤ２２０の各サーバの主たるデータベースとなるメインＤＢ２３２と、主に参照目的で設けられた情報系ＤＢ２３４と、を備える。

各アプリケーションサーバ２２２、２２４、２２６では、複数のクライアント端末に対するサービス２４２、２４４、２４６、２４８、２５０、２５２が同時に実行される。例えば、情報提供アプリケーションサーバ２２２では、一般顧客に対して株価情報を提供するサービスＡ２４２と、コールセンタに対して株価情報を提供するサービスＢ２４４が同時に実行されてもよい。注文処理アプリケーションサーバ２２４では、コールセンタからの株式売買注文を処理するサービスＣ２４６と、店舗からの投資信託売買注文を処理するサービスＤ２４８が同時に実行されてもよい。

一般顧客、コールセンタや支店の担当員は、それぞれのクライアント端末２０２、２０４、２０６からウェブブラウザなどのソフトウェアを使用し、インターネット等のネットワーク２０８を介して証券業務システム２００にアクセスする。コールセンタや支店に備えられるクライアント端末２０４、２０６は、証券業務システム２００と専用線２０９によって接続されていてもよい。

クライアント端末２０２、２０４、２０６から証券業務システム２００にアクセスすると、プレゼンテーションレイヤ２１０のアクセスチャネルに応じたウェブサーバ２１２、２１４、２１６によって作成されたウェブページが、クライアント端末２０２、２０４、２０６に送信される。クライアント端末２０２、２０４、２０６は、送信されたウェブページをディスプレイに表示する。ユーザがウェブページ上でログイン、情報の閲覧、売買注文などの操作を実行すると、その情報がウェブサーバ２１２、２１４、２１６を介してビジネスロジックレイヤ２２０のアプリケーションサーバ２２２、２２４、２２６に渡される。各アプリケーションサーバ２２２、２２４、２２６による処理の結果は、ウェブサーバ２１２、２１４、２１６によってウェブページに加工され、そのデータがクライアント端末２０２、２０４、２０６に送信される。こうしてユーザは、ウェブページに表示される種々の情報を参照したり、またはウェブページを通じて証券の売買注文をすることができる。

上述したような証券業務システムでは、アクセス数の増大によりシステム内のサーバに負荷がかかりすぎると、正常なサービスを提供できなくなる虞がある。このような事態は顧客に迷惑をかけるため、証券業務システム内のサーバの使用の度合いを予測し、その予測に基づいて計画的にシステムの改修、増強等を行うことが望ましい。そこで本実施の形態に係る分析装置は、証券業務システム２００のサーバ構成、特にビジネスロジックレイヤ２２０のサーバ構成に応じてキャパシティがどのように変わるかの予測を可能とする。

図３は、本実施の形態に係る分析装置１００およびそれに接続された部材の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

分析装置１００は証券業務システム２００の内部に設けられてもよく、外部に設けられてもよい。本実施の形態では、分析装置１００は証券業務システム２００の外部に設けられており、分析装置１００と証券業務システム２００とはネットワーク２０８を介して接続される。分析装置１００は証券業務システム２００から各サーバの稼働履歴やアプリケーションの使用頻度の情報をネットワーク２０８を介して取得する。分析装置１００はマウスやキーボードなどの入力装置１０２およびディスプレイ１０４と接続される。証券業務システム２００の管理者は、分析装置１００を使用して証券業務システム２００のパフォーマンスを分析したり、証券業務システム２００への負荷を予測したりする。

分析装置１００は、パラメータ取得部１１０と、サーバ単位予測件数取得部１１２と、負荷予測部１１４と、相関関係取得部１１６と、提示部１１８と、相関保持部１２０と、履歴保持部１２２と、シナリオ保持部１３０と、を含む。

パラメータ取得部１１０は、総予測件数と各クラスに属するサーバの稼動台数とを取得する。特にパラメータ取得部１１０は、ビジネスロジックレイヤ２２０によって１日の間に処理されるリクエストの件数の予測値を、総予測件数として取得する。またパラメータ取得部１１０は、ビジネスロジックレイヤ２２０に含まれるサーバについて、各クラスに属するサーバの稼働台数を取得する。これらの情報の取得の際、パラメータ取得部１１０は、管理者にパラメータの入力を要求するパラメータ入力要求画面３００をディスプレイ１０４に表示させる。

図４は、パラメータ入力要求画面３００の代表画面図である。パラメータ入力要求画面３００は、総予測件数に関するシナリオの選択をプルダウン形式で受け付けるトラフィックシナリオ選択領域３０２と、サーバ構成に関するシナリオの選択をプルダウン形式で受け付けるサーバ構成シナリオ選択領域３０４と、証券業務システム２００における負荷分散アルゴリズムの選択をプルダウン形式で受け付ける負荷分散手法選択領域３０６と、トラフィックシナリオ選択領域３０２に示されるシナリオに対応する総予測件数を表示する総予測件数表示領域３０８と、サーバ構成シナリオ選択領域３０４に表示されるシナリオに対応するサーバ構成を表示するサーバ構成表示領域３１０と、を有する。

図５は、シナリオ保持部１３０の一例を示すデータ構造図である。シナリオ保持部１３０はシナリオと値とを対応付けて保持する。シナリオ保持部１３０に登録されるシナリオは、総予測件数（トラフィック）に関するシナリオとサーバ構成に関するシナリオとを含む。値は、総予測件数に関するシナリオについては総予測件数の値であり、サーバ構成に関するシナリオについては各クラスに属するサーバの稼働台数である。管理者は予めシナリオ保持部１３０にシナリオに関する情報を登録しておく。

管理者がトラフィックシナリオ選択領域３０２のプルダウンボタンを押し下げると、パラメータ取得部１１０はシナリオ保持部１３０に保持される総予測件数に関するシナリオの一覧を表示させる。管理者は表示された一覧の中から所望のシナリオを選択する。パラメータ取得部１１０は、選択されたシナリオに対応する総予測件数の値をシナリオ保持部１３０から抽出し、総予測件数表示領域３０８に表示させる。サーバ構成シナリオ選択領域３０４、サーバ構成表示領域３１０についても同様である。

なお、トラフィックシナリオ選択領域３０２、サーバ構成シナリオ選択領域３０４のそれぞれにおいて「任意入力」を選択することも可能であり、この場合、総予測件数表示領域３０８は管理者による総予測件数の入力を受け付け、サーバ構成表示領域３１０は管理者によるサーバ構成の入力を受け付ける。

管理者が負荷分散手法選択領域３０６のプルダウンボタンを押し下げると、パラメータ取得部１１０は選択可能な負荷分散アルゴリズムの一覧を表示させる。そのような一覧は、例えば順番にサーバが選択されるラウンドロビン方式と、処理件数が最小のサーバを選択する最小接続方式と、１番早く応答しているサーバを選択する最速方式と、を含む。一覧は、他の公知の負荷分散方式を含んでもよい。管理者は表示された一覧の中から所望のアルゴリズムを選択する。

図３に戻り、パラメータ取得部１１０は、管理者によってパラメータ入力要求画面３００のＯＫボタン３１２が押し下げられた場合にトラフィックシナリオ選択領域３０２で選択されているシナリオに対応する総予測件数をシナリオ保持部１３０を参照して取得する総予測件数取得部１２４と、サーバ構成シナリオ選択領域３０４で選択されているシナリオに対応するサーバ構成をシナリオ保持部１３０を参照して取得するサーバ構成取得部１２６と、負荷分散手法選択領域３０６で選択されている負荷分散アルゴリズムを取得する負荷分散アルゴリズム取得部１２８と、を含む。トラフィックシナリオ選択領域３０２またはサーバ構成シナリオ選択領域３０４が「任意入力」となっている場合は、対応する取得部１２４、１２６は対応する表示領域３０８、３１０に入力された値を取得する。

サーバ単位予測件数取得部１１２は、パラメータ取得部１１０によって取得された総予測件数およびビジネスロジックレイヤ２２０のサーバの総数に基づいて、ビジネスロジックレイヤ２２０の各サーバの処理件数の予測値であるサーバ単位予測件数を演算する。この演算の際、サーバ単位予測件数取得部１１２は、負荷分散アルゴリズム取得部１２８によって取得された負荷分散アルゴリズムを使用する。サーバ単位予測件数取得部１１２は分配比率決定部１３２と予測件数導出部１３４とを含む。

分配比率決定部１３２は、負荷分散アルゴリズム取得部１２８によって取得された負荷分散アルゴリズムに基づいて、総予測件数をビジネスロジックレイヤ２２０の各サーバに割り当てる比率を決定する。特に分配比率決定部１３２は、負荷分散アルゴリズムに対応する比率を決定する。例えば、取得された負荷分散アルゴリズムがラウンドロビンである場合、比率はサーバによらずに一定となる。すなわち、全てのサーバに同じ件数が割り当てられる。また、取得された負荷分散アルゴリズムが、サーバの処理能力が高いほど高確率で選択されるものである場合、比率は、より高い処理能力のクラスに属するサーバほど高くなる。

予測件数導出部１３４は、分配比率決定部１３２によって決定された比率に基づいて、クラスごとにサーバ単位予測件数を演算する。例えば負荷分散アルゴリズムがラウンドロビンであり比率が一定の場合、予測件数導出部１３４は総予測件数をビジネスロジックレイヤ２２０のサーバの総数で除した値を全てのクラスについてのサーバ単位予測件数とする。すなわち、総予測件数が２３１００（件）であり、サーバの総数が２３１（台）である場合、予測件数導出部１３４はサーバ単位予測件数として１００（件／台）を導出する。この値はクラスによらない値である。

負荷予測部１１４は、処理能力のクラスごとに、相関保持部１２０によって保持される相関関係を、サーバ単位予測件数取得部１１２によって取得されたサーバ単位予測件数に適用することによって、サーバのＣＰＵ使用率の予測値を演算する。負荷予測部１１４は、相関関係抽出部１３６と、相関関係適用部１３８と、平均演算部１４０と、を含む。

相関関係抽出部１３６は、未だＣＰＵ使用率演算の対象となっていないクラスのなかから演算対象とするクラス（以下、演算対象クラスと称す）を選択する。相関関係抽出部１３６は、選択された演算対象クラスに対応する相関関係を相関保持部１２０から抽出する。特に相関関係は、クラスごとに、処理件数と、ＣＰＵ使用率の基準値（例えば分間ごとに平均されたＣＰＵ使用率（以下、分間ＣＰＵ使用率と称す）の１日のなかでの最大値（以下、分間最大ＣＰＵ使用率と称す））と、を関係付ける関係式である。

相関関係適用部１３８は、相関関係抽出部１３６によって抽出された関係式に、演算対象クラスのサーバ単位予測件数を代入する。相関関係適用部１３８は、そのように代入して得られる値を、演算対象クラスのサーバのＣＰＵ使用率の予測値として取得する。このように取得されるＣＰＵ使用率の予測値は、分間最大ＣＰＵ使用率に対応する。分間最大ＣＰＵ使用率は１日のなかでの最大値なので、管理者がこの予測値を参照してキャパシティを判断する場合、より安全サイドに立った判断が可能となる。
また、一般に証券業務システム２００では時間ごとのトラフィックのボラティリティが高い。加えて、僅かな間でもＣＰＵ使用率が過大となると、サーバの性能や運用に悪影響が出かねない。すなわち、証券業務システム２００のキャパシティ予測の観点からは、比較的長い期間に亘って平均されたＣＰＵ使用率、例えば１日の平均ＣＰＵ使用率に対応する予測値よりも、比較的短い期間におけるＣＰＵ使用率に対応する予測値を採用してボラティリティの高さに対応するほうが好ましい。そこで、本実施の形態では分間最大ＣＰＵ使用率に対応する予測値を採用することにより、１日のうちでもＣＰＵ使用率が最大となるタイミングに合わせてキャパシティを確保することが可能となる。

図６は、相関保持部１２０の一例を示すデータ構造図である。相関保持部１２０は、処理能力のクラスごとに処理件数と分間最大ＣＰＵ使用率との相関関係を保持する。特に相関保持部１２０は、処理能力のクラスごとに、サーバの分間最大ＣＰＵ使用率を、そのサーバの処理件数の一次式で近似した場合の切片と傾きとを保持する。

例えば、演算対象クラスを「クラスＡ」とし、「クラスＡ」のサーバ単位予測件数を２５００件とすると、相関関係適用部１３８は、
−８＋０．０２×２５００
を演算し、値４２（％）を得る。相関関係適用部１３８は、この値４２（％）を、「クラスＡ」のサーバのＣＰＵ使用率の予測値として取得する。

図３に戻り、平均演算部１４０は、相関関係適用部１３８によって演算されたサーバのＣＰＵ使用率の予測値を処理能力のクラスに亘って平均することにより、平均ＣＰＵ使用率を演算する。例えば、「クラスＡ」、「クラスＢ」、「クラスＣ」の予測値がそれぞれ４２（％）、２３（％）、１６（％）であり、「クラスＡ」、「クラスＢ」、「クラスＣ」に属するサーバの数がそれぞれ２０（台）、１０（台）、５（台）である場合、平均演算部１４０は平均ＣＰＵ使用率として
（４２×２０＋２３×１０＋１６×５）／（２０＋１０＋５）≒３３（％）
を得る。

相関関係取得部１１６は、処理能力のクラスごとに、処理件数と分間最大ＣＰＵ使用率との相関関係を取得し、相関保持部１２０に登録する。管理者は、別途決定した相関関係を入力装置１０２を介して相関関係取得部１１６に入力してもよい。あるいはまた、管理者は、証券業務システム２００の稼動履歴から相関関係を導出することを支援する相関関係取得部１１６の以下の機能を使用して相関関係を導出してもよい。相関関係取得部１１６は、演算対象期間取得部１４２と、クラス指定受付部１４４と、履歴抽出部１４６と、相関関係演算部１４８と、相関関係登録部１５０と、を含む。相関関係取得部１１６は相関演算入力画面３１４をディスプレイ１０４に表示させる。

図７は、相関演算入力画面３１４の代表画面図である。相関演算入力画面３１４は、ビジネスロジックレイヤ２２０に含まれるサーバの選択をプルダウン形式で受け付けるサーバ選択領域３１６と、演算対象期間が入力される演算対象期間入力領域３１８と、ＯＫボタン３２０と、サーバ選択領域３１６で選択されたサーバが属するクラスが表示されるクラス表示領域３２２と、を有する。

演算対象期間取得部１４２は、管理者によって相関演算入力画面３１４のＯＫボタン３２０が押し下げられた場合に演算対象期間入力領域３１８に入力されている演算対象期間を取得する。クラス指定受付部１４４は、ＯＫボタン３２０が押し下げられた場合にサーバ選択領域３１６で選択されているサーバが属するクラスを演算対象のクラスとして取得する。

図８は、履歴保持部１２２の一例を示すデータ構造図である。履歴保持部１２２は、過去の処理件数と分間最大ＣＰＵ使用率とが対応付られた履歴データを保持する。履歴保持部１２２は、履歴データが取得された取得時刻と、ビジネスロジックレイヤ２２０に含まれるサーバを特定するサーバＩＤと、サーバＩＤによって特定されるサーバが属するクラスを特定するクラスＩＤと、サーバＩＤによって特定されるサーバの処理件数と、サーバＩＤによって特定されるサーバの分間最大ＣＰＵ使用率と、を対応付けて保持する。

図３に戻り、履歴抽出部１４６は、演算対象のクラスに属するサーバについての演算対象期間内の履歴データを履歴保持部１２２から抽出する。
相関関係演算部１４８は、所定の統計的アルゴリズムに基づき、履歴抽出部１４６によって抽出された履歴データから相関関係を導出する。例えば相関関係演算部１４８は、履歴データに含まれる所定のサーバの分間最大ＣＰＵ使用率をそのサーバの処理件数の一次式で近似し、最小二乗法により切片と傾きとを決定する。相関関係演算部１４８は、相関関係の演算結果を示す相関演算結果画面３２４をディスプレイ１０４に表示させる。

図９は、相関演算結果画面３２４の代表画面図である。相関演算結果画面３２４は、横軸を処理件数、縦軸を分間最大ＣＰＵ使用率として履歴データの分布を示す。相関演算結果画面３２４は、最小二乗法を適用することにより得られた切片と傾きとを有する一次式に対応する実線３２６、３２８を示す。

なお、図９では、「乙社製２０１１年版サーバ１」と「丙社製２０１０年版サーバ１」とが同等の性能を有していることが示される。図８にも示されるように、本実施の形態では、それらのサーバは同じ「クラスＣ」に属するよう設定される。このように、本実施の形態では、ひとつのクラスに同一ベンダの同一機種のサーバだけでなく、異なるベンダの異なる機種のサーバが属してもよい。

図３に戻り、相関関係演算部１４８は、決定された切片と傾きとを処理能力のクラスごとに平均し、平均切片と平均傾きとを導出する。一般に、リクエストをラウンドロビンで処理していても、ＧＣ（Garbage Collection）処理の発生などにより、サーバごとにＣＰＵ使用率がブレることが多い。そこで、切片や傾きをクラスごとに平均することにより、そのようなブレによる影響を抑えることができる。
相関関係登録部１５０は、処理能力のクラスごとに、相関関係演算部１４８によって決定された平均切片と平均傾きとを相関保持部１２０に登録する。

提示部１１８は、負荷予測部１１４による予測結果を管理者に提示する。提示部１１８は、シナリオ別結果生成部１５２と、レスポンスタイム結果生成部１５４と、を含む。
シナリオ別結果生成部１５２は、サーバ構成に関するシナリオごと、および、総予測件数に関するシナリオごと、の予測結果を負荷予測部１１４から取得し、シナリオ別の予測結果を表示するシナリオ別結果表示画面３３０をディスプレイ１０４に表示させる。

図１０は、シナリオ別結果表示画面３３０の代表画面図である。シナリオ別結果表示画面３３０は、サーバ構成に関するシナリオおよび総予測件数に関するシナリオに対応して得られる各クラスのＣＰＵ使用率の予測値を表形式で示す。またシナリオ別結果表示画面３３０は、証券業務システム２００に備わっている片面稼動（面切り離し）機能やフェイルオーバ機能や全台稼動機能などのいくつかの機能について、得られた予測値の範囲で利用可能か否かをも示す。管理者はシナリオ別結果表示画面３３０を参照することによって、想定される各種サーバ構成や総予測件数のもとでの証券業務システム２００のキャパシティを迅速かつ的確に把握することができる。

図１１は、面切り離し機能を説明するための模式図である。面切り離し機能は、プレゼンテーションレイヤ２１０およびビジネスロジックレイヤ２２０のサーバをＡ面とＢ面とに分離しておき、ネットワーク障害時やアプリケーションの緊急リリース時にそれらのうちの一方のみでリクエストを処理する機能である。また、ビジネスロジックレイヤ２２０特有の機構が障害となった場合、例えば片面のイニシャルコンテキストサーバ２６０が全て動作不能となった場合や片面の専用サーバ２６２が正副共に動作不能となった場合にも面切り離し機能が使用される。

図２に戻り、レスポンスタイム結果生成部１５４は、負荷予測部１１４によって演算されたＣＰＵ使用率の予測値に対応するレスポンスタイムを示すレスポンスタイム表示画面３３２をディスプレイ１０４に表示させる。レスポンスタイムは、証券業務システム２００に実装されているアプリケーションがリクエストを受け付けてから応答を返すまでにかかる時間である。

図１２は、レスポンスタイム表示画面３３２の代表画面図である。レスポンスタイム表示画面３３２は、横軸を「クラスＡ」に属するサーバのＣＰＵ使用率、縦軸を一般ユーザトップページ表示アプリケーションのレスポンスタイムおよび規定タイム超過件数、としてデータの分布を示す。これらのデータ点は履歴保持部１２２や証券業務システム２００から取得されてもよい。規定タイム超過件数は、一般ユーザトップページ表示アプリケーションがリクエストを受けてから規定タイム内に応答できず、エラーとなったリクエストの件数である。レスポンスタイム表示画面３３２は、負荷予測部１１４によって演算された、「クラスＡ」に属するサーバのＣＰＵ使用率の予測値（７３％）を破線３３４で示し、その予測値に対応するレスポンスタイム（３２００ｍｓ）および規定タイム超過件数（４００件）を数値で表示する。管理者は、レスポンスタイム表示画面３３２を参照することによって、得られたＣＰＵ使用率の予測値の意味するところを迅速かつ的確に把握することができる。

上述の実施の形態において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。

以上の構成による分析装置１００の動作を説明する。
図１３は、分析装置１００における一連の処理を示すフローチャートである。パラメータ取得部１１０は、総予測件数およびサーバ構成を管理者から取得する（Ｓ４０２）。サーバ単位予測件数取得部１１２は、サーバ単位予測件数を演算する（Ｓ４０４）。負荷予測部１１４は、ＣＰＵ使用率の予測値が演算されていないクラスがあるか否かを判定する（Ｓ４０６）。演算されていないクラスが存在する場合（Ｓ４０６のＹ）、負荷予測部１１４はそのようなクラスのなかから演算対象クラスを選択する（Ｓ４０８）。負荷予測部１１４は、演算対象クラスに対応する相関関係を相関保持部１２０から抽出する（Ｓ４１０）。負荷予測部１１４は、抽出された相関関係を、演算対象クラスのサーバ単位予測件数に適用することにより、演算対象クラスのサーバのＣＰＵ使用率の予測値を得る（Ｓ４１２）。そして処理はステップＳ４０６に戻る。全てのクラスについてＣＰＵ使用率の予測値が演算された場合（Ｓ４０６のＮ）、提示部１１８は予測結果を管理者に提示する（Ｓ４１４）。

本実施の形態に係る分析装置１００によると、証券業務システム２００のサーバ構成と総予測件数とが入力として与えられた場合に、処理能力のクラスごとに予測されるＣＰＵ使用率を迅速かつ正確に把握することができる。その結果、様々な処理能力のサーバが混在する証券業務システム２００について、サーバ構成の変化による証券業務システム２００のキャパシティの変化を迅速かつ正確に把握することができる。分析装置１００を使用することにより、管理者は、例えば大規模災害時に想定される縮小されたサーバ構成で、混雑日にキャパシティがどのようになるかを把握することができる。そしてもしキャパシティが足りなくなるのであれば、予め予備のサーバを追加したり、混雑日にサービスを閉塞させる等の対策を施すことができる。

また、証券業務システム２００にサーバを追加する際、一般にはコスト低減のために多くのベンダのなかからコストパフォーマンスのよいベンダを選んで、そこからサーバを購入することが多い。したがって、証券業務システム２００のサーバはマルチベンダ構成となることが多いが、分析装置１００はそのようなマルチベンダ構成の証券業務システム２００を分析するのにより適している。

以上、実施の形態に係る分析装置１００の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施の形態では、分析装置１００は証券業務システム２００を分析する場合について説明したが、これに限られず、例えば分析装置は銀行の業務システムなどの他の金融商品業務システムを分析してもよい。なお、証券業務システム２００はその性質上スケールアウト構成となることが多い。例えば、証券会社立ち上げ時には少数のサーバを利用し、利用者数の増加と共にサーバを増やしていく場合がそうである。したがって、分析装置１００を使用して証券業務システム２００のキャパシティを分析することのメリットは比較的大きい。

実施の形態では、提示部１１８はシナリオ別結果表示画面３３０やレスポンスタイム表示画面３３２をディスプレイ１０４に表示させる場合について説明したが、これに限られない。図１４は、提示部１１８によってディスプレイ１０４に表示されてもよい予測結果画面３５０の代表画面図である。予測結果画面３５０は処理能力のクラスごとにＣＰＵ使用率の予測結果を表示する。また予測結果画面３５０はＣＰＵ使用率の予測値の平均を表示する。

実施の形態では、相関関係取得部１１６は、管理者が証券業務システム２００の稼動履歴から相関関係を導出することを支援する場合について説明したが、これに限られず、相関関係取得部が自動的に稼動履歴を分析してそのような相関関係を導出してもよい。

実施の形態では、相関関係取得部１１６がサーバごとに処理件数と分間最大ＣＰＵ使用率とを関係付ける切片および傾きを導出し、そのように導出された切片および傾きをクラスごとに平均する場合について説明したが、これに限られない。例えば、分析装置１００は、クラスごとに平均された分間ＣＰＵ使用率の履歴を保持する別の履歴保持部（図３では不図示）を備えてもよい。
図１５は、別の履歴保持部１６０の一例を示すデータ構造図である。別の履歴保持部１６０は、時刻と、クラスごとに、分間ＣＰＵ使用率をクラスに属するサーバに亘って平均して得られる平均値と、を対応付けて保持する。例えば、時刻「２０１１／１１／２８ ９：００」に対応する「クラスＡ」の値「３０％」は、時刻「２０１１／１１／２８ ９：００」における分間ＣＰＵ使用率を、「クラスＡ」に属するサーバ全てに亘って平均した値である。
相関関係取得部は、別の履歴保持部１６０を参照して、過去の日の各クラスの分間最大ＣＰＵ使用率を取得してもよい。相関関係取得部は、クラスごとに平均された処理件数と、クラスごとの分間最大ＣＰＵ使用率と、を関係付ける切片および傾きを導出し、それを相関保持部１２０に登録してもよい。
一般に、リクエストをラウンドロビンで処理していても、ＧＣ処理の発生などにより、サーバごとにＣＰＵ使用率がブレることが多い。そこで、分間ＣＰＵ使用率をクラスごとに平均することにより、そのようなブレによる影響を抑えることができる。

１００ 分析装置、 １１０ パラメータ取得部、 １１２ サーバ単位予測件数取得部、 １１４ 負荷予測部、 １１６ 相関関係取得部、 １１８ 提示部、 １２０ 相関保持部、 １２２ 履歴保持部、 ２００ 証券業務システム。

Claims (7)

1. 処理能力の異なる複数のサーバを有する金融商品業務システムを分析するための分析装置であって、
   複数のサーバによって処理されるリクエストの件数の予測値である総予測件数と、複数のサーバを処理能力で複数のクラスに分類したときの各クラスに属するサーバの数と、を取得するパラメータ取得部と、
   前記パラメータ取得部によって取得された総予測件数および複数のサーバの総数に基づいて、各サーバによって処理されるリクエストの件数の予測値であるサーバ単位予測件数を演算するサーバ単位予測件数演算部と、
   処理能力のクラスごとに、サーバによって処理されたリクエストの件数とサーバの処理余力の度合いとの相関関係を保持する相関保持部と、
   処理能力のクラスごとに、前記相関保持部によって保持される相関関係を前記サーバ単位予測件数演算部によって演算されたサーバ単位予測件数に適用することによって、サーバの処理余力の度合いの予測値を演算する負荷予測部と、を備えることを特徴とする分析装置。
2. 前記負荷予測部は、サーバの処理余力の度合いの予測値を処理能力のクラスに亘って平均することを特徴とする請求項１に記載の分析装置。
3. サーバによって処理されたリクエストの件数とサーバの処理余力の度合いとを対応付けて保持する履歴保持部をさらに備え、
   前記相関保持部によって保持される相関関係は、前記履歴保持部を参照して導出されることを特徴とする請求項１または２に記載の分析装置。
4. 前記サーバ単位予測件数演算部は、複数のサーバの間での所定の負荷分散アルゴリズムに基づいてサーバ単位予測件数を演算することを特徴とする請求項１から３のいずれかに記載の分析装置。
5. 前記金融商品業務システムは証券業務システムであることを特徴とする請求項１から４のいずれかに記載の分析装置。
6. 処理能力の異なる複数のサーバを有する金融商品業務システムを分析するための分析方法であって、
   複数のサーバによって処理されるリクエストの件数の予測値である総予測件数と、複数のサーバを処理能力で複数のクラスに分類したときの各クラスに属するサーバの数と、を取得するステップと、
   取得された総予測件数および複数のサーバの総数に基づいて、各サーバによって処理されるリクエストの件数の予測値であるサーバ単位予測件数を演算するステップと、
   処理能力のクラスごとに、サーバによって処理されたリクエストの件数とサーバの処理余力の度合いとの相関関係を相関保持部に保持するステップと、
   処理能力のクラスごとに、前記相関保持部によって保持される相関関係を演算されたサーバ単位予測件数に適用することによって、サーバの処理余力の度合いの予測値を演算するステップと、を含むことを特徴とする分析方法。
7. 処理能力の異なる複数のサーバを有する金融商品業務システムを分析する機能をコンピュータに実現させるコンピュータプログラムであって、
   複数のサーバによって処理されるリクエストの件数の予測値である総予測件数と、複数のサーバを処理能力で複数のクラスに分類したときの各クラスに属するサーバの数と、を取得する機能と、
   取得された総予測件数および複数のサーバの総数に基づいて、各サーバによって処理されるリクエストの件数の予測値であるサーバ単位予測件数を演算する機能と、
   処理能力のクラスごとに、サーバによって処理されたリクエストの件数とサーバの処理余力の度合いとの相関関係を相関保持部に保持する機能と、
   処理能力のクラスごとに、前記相関保持部によって保持される相関関係を演算されたサーバ単位予測件数に適用することによって、サーバの処理余力の度合いの予測値を演算する機能と、を前記コンピュータに実現させることを特徴とするコンピュータプログラム。

Images