トラフィック情報管理サーバ及びトラフィック情報管理方法
【課題】複数台の実行制御サーバを並列に実行したとしてもシステム全体でリクエストを監視することができ、サービスコンポーネントへのリクエスト処理量を向上することができる。
【解決手段】トラフィック情報管理サーバ１０は、実行制御サーバ１，２，３から収集したトラフィック情報を集計するトラフィック集計機能部１２と、集計したトラフィック情報に基づいて閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント監視機能部１４と、集計したトラフィック情報に基づいて特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部１５と、閉塞状態にするサービスコンポーネント又は一時利用不可能にするユーザをプロファイルサーバ９に通知するリアクション機能部１６と、を備える。
【解決手段】トラフィック情報管理サーバ１０は、実行制御サーバ１，２，３から収集したトラフィック情報を集計するトラフィック集計機能部１２と、集計したトラフィック情報に基づいて閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント監視機能部１４と、集計したトラフィック情報に基づいて特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部１５と、閉塞状態にするサービスコンポーネント又は一時利用不可能にするユーザをプロファイルサーバ９に通知するリアクション機能部１６と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トラフィック情報管理サーバ及びトラフィック情報管理方法に関する。
【背景技術】
【０００２】
現在、ウェブサービス等のサービスコンポーネントを連携利用することで、新たなサービスを容易に実現する試みがある。
非特許文献１に記載された技術では、電話サービスとウェブサービスとを連携するシステムにおいて、実行制御サーバがユーザ認証やトラフィック制御などの共通処理を一括して行っている。
また、非特許文献２に記載された技術では、サービスコンポーネントに対するリクエストを処理する複数台のサーバをクラスタ化している。
【非特許文献１】山登庸次、大西浩行、中野雄介、“電話−ウェブ連携を促進する実行制御機能の検討”電子情報通信学会２００８年総合大会講演論文集、B-19-10、Mar.2008.
【非特許文献２】“Oracle Communications Services Gatekeeper”、［online］、Oracle、［２００８年１１月０４日検索］、インターネット〈URL:http://www.oracle.com/industries/communications/oracle-communications-services-gatekeeper.html〉
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、非特許文献１では、１台の実行制御サーバ単体での運用を想定しているため、実行制御サーバを複数台用いた場合には、ユーザからサービスコンポーネントへのリクエストをシステム全体で監視することができない、という問題がある。
例えば、あるユーザａがサービスコンポーネントＡを１日に使用できる回数が１００回と設定されていたときに、ユーザａが実行制御サーバ１で３０回、実行制御サーバ２で８０回、実行制御サーバ３で６０回サービスコンポーネントＡを使用した場合であっても、１日の使用制限回数１００回を超えているユーザとしてユーザａを検出することはできなかった。
また、非特許文献２では、全てのデータをサーバ間で通信して同期を取っているため、その通信コストからクラスタ化しても性能向上する効果が少ない、という問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、複数台の実行制御サーバを並列に実行したとしてもシステム全体でリクエストを監視することができ、サービスコンポーネントへのリクエスト処理量を向上することができるトラフィック情報管理サーバ及びトラフィック情報管理方法を提供することにある。
【課題を解決するための手段】
【０００４】
本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するトラフィック収集機能部と、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するトラフィック集計機能部と、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント利用不能率監視機能部と、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部と、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するサービスコンポーネント閉塞機能部と、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するユーザ閉塞機能部と、を備えることを特徴とするトラフィック情報管理サーバである。
【０００５】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記サービスコンポーネント利用不能率監視機能部により抽出されたサービスコンポーネントを閉塞状態にしたことを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第１のアラーム通知機能部と、前記ユーザ監視機能部により抽出されたユーザを前記特定のサービスコンポーネントに対して一時利用不可能にしたことを当該ユーザの端末に通知する第２のアラーム通知機能部と、を備えることを特徴とする。
【０００６】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記トラフィック情報は、サービスコンポーネントからの応答時間の状況を表す応答時間情報を含み、前記サービスコンポーネント情報は、サービスコンポーネントへのリクエストを一律に一定の時間遅延させるフロー制御を行うか否かを表すフロー制御フラグを含み、前記トラフィック集計機能部により集計された前記応答時間情報に基づいて、フロー制御を行うサービスコンポーネントを抽出する応答遅延監視機能部と、前記応答遅延監視機能部により抽出されたサービスコンポーネントに対応する前記フロー制御フラグの更新要求を外部に送信するフロー規制機能部と、を備えることを特徴とする。
【０００７】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記応答遅延監視機能部により抽出されたサービスコンポーネントへのリクエストを一律に一定の時間遅延させていることを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第３のアラーム通知機能部を備えることを特徴とする。
【０００８】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数に基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【０００９】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数と当該リクエストに対するエラーの数とに基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【００１０】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの平均サイズに基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【００１１】
また、本発明の一態様は、前トラフィック収集機能部が、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するステップと、トラフィック集計機能部が、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するステップと、サービスコンポーネント利用不能率監視機能部が、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するステップと、ユーザ監視機能部が、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するステップと、サービスコンポーネント閉塞機能部が、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するステップと、ユーザ閉塞機能部が、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するステップと、を有することを特徴とするトラフィック情報管理方法である。
【発明の効果】
【００１２】
本発明によれば、トラフィック情報管理サーバが、複数の実行制御サーバからトラフィック情報を収集して集計して閉塞状態にするサービスコンポーネント及び特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出しているため、実行制御サーバが複数台並列して処理を行ってもシステム全体としてトラフィック情報の整合性を保つことができる。
また、実行制御サーバが複数台並列してサービスコンポーネントへのリクエスト処理を行っているため、単位時間におけるサービスコンポーネントへのリクエスト処理量を向上することができる。
また、各サービスコンポーネントにおける共通処理を一括して実行制御サーバが行っているため、サービス事業者側のサービスコンポーネント以外の機能（非機能要件）実装にかかる投資及び経費費用を軽減することができる。
また、実行制御サーバ１，２，３は、閉塞状態にあるサービスコンポーネントへのリクエストを遮断することにより、障害が発生したサービスコンポーネントサーバの影響が他のサービスコンポーネントへの波及を防ぐことができる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
図１は、本発明の一実施形態によるサービスコンポーネント管理システムの構成を示すブロック図である。
サービスコンポーネント管理システムは、実行制御サーバクラスタ４と、トラフィック情報管理サーバ１０と、プロファイルサーバ９と、トラフィック情報データベース１７と、サービスリクエスタ端末５，６，７と、複数のサービスコンポーネントサーバ１８と、を含んで構成される。
サービスリクエスタ端末５，６，７と実行制御サーバクラスタ４及び、実行制御サーバクラスタ４とサービスコンポーネントサーバ１８とは、ネットワーク８を介してメッセージの送受信を行う。ネットワーク８は、電話交換等の通信ネットワーク、或いはインターネット等の情報ネットワーク、或いはサービス制御層とパケット転送層とを有するＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）、或いは移動体ネットワーク等からなるネットワークである。
【００１４】
サービスコンポーネントサーバ１８は、サービスリクエスタ端末５，６，７に複数のサービスコンポーネントを提供するサーバ装置である。サービスコンポーネントとは、サービス事業者提供するウェブサービスや電話サービスなどのサービスである。
サービスリクエスタ端末５，６，７は、複数のサービスコンポーネントが連携してなるサービスを利用するユーザ（リクエスタ）が使用する端末である。
【００１５】
トラフィック情報データベース１７は、トラフィック情報の集計結果を記憶保持するデータベースであり、サービスコンポーネントテーブルと、オペレーションテーブルと、オペレーション−ユーザテーブルと、ユーザテーブルとを保持している。トラフィック情報とは、サービスコンポーネントテーブルと、オペレーションテーブルと、オペレーション−ユーザテーブルと、ユーザテーブルにおける各項目をトラフィック情報生成時間毎に集計した情報である。また、オペレーション−ユーザテーブル及びユーザテーブルの各項目が、特定のユーザから特定のサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報である。また、サービスコンポーネントテーブルの各項目が、特定のサービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報である。また、オペレーションテーブルの各項目が、特定のサービスコンポーネントからの応答時間の状況を表す応答時間情報である。
【００１６】
プロファイルサーバ９は、ユーザ情報とサービスコンポーネント情報とを保持するサーバ装置であり、サービスコンポーネント情報テーブルと、サービスコンポーネント閾値情報テーブルと、オペレーション閾値情報テーブルを保持している。
【００１７】
実行制御サーバクラスタ４は、実行制御サーバ１，２，３群である。
実行制御サーバ１，２，３は、各サービスコンポーネントの共通処理を行うサーバ装置である。各サービスコンポーネントの共通処理とは、ユーザ認証や各サービスコンポーネントに応じたトラフィック制御などであり、サービスリクエスタ端末５，６，７から受信したサービスコンポーネントへのリクエストをサービスコンポーネントサーバ１８に転送する。また、実行制御サーバ１，２，３は、トラフィック情報生成時間（例えば毎時００分からの３分周期）毎にトラフィック情報を生成してトラフィック情報管理サーバ１０に送信する。なお、サービスリクエスタ５，６，７からのリクエストは図示しないロードバランサーにより、ラウンドロビンアルゴリズムや実行制御サーバ１，２，３のＣＰＵ（中央演算装置）使用率に応じて実行制御サーバ１，２，３に振り分けられる。
【００１８】
トラフィック情報管理サーバ１０は、各サービスコンポーネントへの負荷状況を監視するサービスコンポーネント品質監視制御を行うサーバ装置である。トラフィック情報管理サーバ１０の機能構成は後述する。
【００１９】
図２は、本実施形態におけるサービスコンポーネントテーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネントテーブルは、年月日と、時と、サービスＩＤと、リクエスト数と、エラー数の各項目の列を有している。時は、時間を示しており、例えば、時「１０」は、１０時００分から１０時５９分までを表す。サービスＩＤは、サービスコンポーネントを識別する識別情報である。リクエスト数は、サービスコンポーネント宛に送信されたリクエストの数である。エラー数は、サービスリクエスト宛に送信されたリクエストに対するエラーの数であり、認証ＮＧと、認可ＮＧと、応答タイムアウトの各項目を有している。認証ＮＧは、ユーザ認証されなかった場合のエラーである。認可ＮＧは、例えばユーザにサービスコンポーネントの使用権限がない場合のエラーである。応答タイムアウトは、リクエストに対するレスポンスが一定時間内に返されなかった場合のエラーである。
【００２０】
図３は、本実施形態におけるオペレーションテーブルのデータ構造とデータ例を示す概略図である。オペレーションテーブルは、年月日と、時と、サービスＩＤと、オペレーション名と、レスポンス数と、応答時間合計の各項目の列を有している。オペレーション名は、サービスコンポーネントのオペレーション（例えば、電話サービスの場合、発呼、着信等）の名称である。レスポンス数は、リクエストに対するレスポンスの数である。応答時間合計は、実行制御サーバ１，２，３がリクエストを送信してからレスポンスを受信するまでの応答時間の合計値であり、単位はミリ秒（ｍｓ）である。
【００２１】
図４は、本実施形態におけるオペレーション−ユーザテーブルのデータ構造とデータ例を示す概略図である。オペレーション−ユーザテーブルは、年月日と、時と、サービスＩＤと、オペレーション名と、ユーザＩＤと、リクエスト数の各項目の列を有している。ユーザＩＤは、ユーザを識別するための識別情報である。
【００２２】
図５は、本実施形態におけるユーザテーブルのデータ構造とデータ例を示す概略図である。ユーザテーブルは、年月日と、時と、ユーザＩＤと、リクエスト数と、エラー数の各項目の列を有している。
【００２３】
図６は、本実施形態におけるサービスコンポーネント情報テーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネント情報テーブルは、サービスコンポーネント情報として、サービスＩＤと、フロー規制フラグと、閉塞フラグ（サービスコンポーネント閉塞フラグ）と、ブラックリストの各項目の列を有している。フロー規制フラグは、そのサービスコンポーネントにフロー制御があるか否かを示すフラグであり、フロー規制フラグ「１」はフロー規制があることを表し、フロー規制フラグ「０」はフロー規制がないことを表す。閉塞フラグは、サービスコンポーネントが閉塞状態（利用できない状態）にあるか否かを示すフラグであり、閉塞フラグ「１」は閉塞状態であることを表し、閉塞フラグ「０」は閉塞状態ではないことを表す。ブラックリストは、サービスコンポーネントを一時利用不可能になっているユーザのユーザＩＤの一覧である。
【００２４】
図７は、本実施形態におけるサービスコンポーネント閾値情報テーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネント閾値情報テーブルは、サービスＩＤと、サービス利用不能率閾値と、エラー閾値と、サイズ閾値との各項目の列を有している。サービス利用不能率閾値は、サービスが利用不能になる率に関する閾値である。エラー閾値は、エラーの割合に関する閾値である。サイズ閾値は、リクエストのサイズに関する閾値である。
【００２５】
図８は、本実施形態におけるオペレーション閾値情報テーブルのデータ構造とデータ例を示す概略図である。オペレーション閾値情報テーブルは、サービスＩＤと、オペレーション名と、レート閾値と、平均応答時間閾値との各項目の列を有している。オペレーション名は、サービスコンポーネントのオペレーション（例えば、電話サービスの場合、発呼、着信等）の名称である。レート閾値は、１ユーザがレート監視周期（例えば１日）にサービスコンポーネントに送信可能なリクエスト数の閾値である。平均応答時間閾値は、リクエストに対する平均応答時間に関する閾値である。
【００２６】
図９は、本実施形態におけるトラフィック情報管理サーバ１０の機能構成を示すブロック図である。
トラフィック情報管理サーバ１０は、複数の実行制御サーバ１，２，３からトラフィック情報を収集して集計を行い、全てのトラフィック情報を集約することで、サービスコンポーネント品質監視制御を行う。これにより、システム全体の整合を取ることができ、かつ、サービスコンポーネント品質監視制御の不整合を防ぐことができる。トラフィック情報管理サーバ１０は、トラフィック収集機能部１１と、トラフィック集計機能部１２と、監視実行制御機能部１３と、サービスコンポーネント監視機能部１４と、ユーザ監視機能部１５と、リアクション機能部１６と、タイマ（Ｔｉｍｅｒ）２３と、を含んで構成される。監視実行制御機能部１３と、サービスコンポーネント監視機能部１４と、ユーザ監視機能部１５と、リアクション機能部１６とにおける処理がサービスコンポーネント監視制御である。
【００２７】
トラフィック収集機能部１１は、実行制御サーバ１，２，３からトラフィック情報をポーリングにてトラフィック情報生成時間（例えば３分）毎に収集し、トラフィック集計機能部１２に出力する。
トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する。具体的には、トラフィック集計機能部１２は、サービスコンポーネント毎にリクエスト数とエラー数とをカウントする。また、トラフィック集計機能部１２は、オペレーション毎にレスポンス数と応答時間合計とをカウントする。また、トラフィック集計機能部１２は、オペレーションとユーザの組毎にリクエスト数をカウントする。また、トラフィック集計機能部１２は、ユーザ毎にリクエスト数とエラー数とリクエストメッセージ合計とをカウントする。そして、トラフィック集計機能部１２は、トラフィック情報が生成された年月日時とともにカウントした値をトラフィック情報データベース１７に送信して記憶させる。
【００２８】
監視実行制御機能部１３は、一定時間或いは一定周期でサービスコンポーネント監視機能部１４とユーザ監視機能部１５とに独立に処理を行わせる機能である。また、サービスコンポーネント監視機能部１４及びユーザ監視機能部１５における処理がサービスコンポーネント監視制御である。具体的には、監視実行制御機能部１３は、サービスコンポーネント監視周期（例えば１時間）毎にサービスコンポーネント監視機能部１４のサービスコンポーネント利用不能率機能部２４及び応答遅延監視機能部２５に処理を行わせる。また、監視実行制御機能部１３は、ユーザ監視周期（例えば３分）毎にユーザ監視機能部１５のレート監視機能部２６とエラー率監視機能部２７とメッセージサイズ監視機能部２８とに処理を行わせる。
タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期及びユーザ監視周期を通知する。
【００２９】
サービスコンポーネント監視機能部１４は、閉塞状態にするサービスコンポーネント又はフロー規制状態にするサービスコンポーネントを抽出する機能であり、サービスコンポーネント利用不能率監視機能部２４と応答遅延監視機能部２５とを有している。
【００３０】
サービスコンポーネント利用不能率監視機能部２４は、サービスコンポーネントのレスポンス数が許容範囲か否かを監視する機能であり、各サービスコンポーネントに対して以下の処理を実行する。まず。サービスコンポーネント利用不能率機能部２４は、プロファイルサーバ９からサービスコンポーネントに対応するサービス利用不能率閾値を取得し、トラフィック情報データベース１７のサービスコンポーネントテーブルからサービスコンポーネント利用不能率監視周期（例えば１時間）におけるこのサービスコンポーネントのリクエスト数と応答タイムアウトのエラー数とを取得する。そして、サービスコンポーネント利用不能率機能部２４は、取得したリクエスト数に対するエラー数の割合（エラー率）がサービス利用不能率閾値を超えているか否かを判定する。エラー率がサービス利用不能率閾値より大きい場合に、このサービスコンポーネントを閉塞状態にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３１】
応答遅延監視機能部２５は、各サービスコンポーネントのオペレーションに対して以下の処理を実行する。まず、応答遅延監視機能部２５は、プロファイルサーバ９からオペレーションに対応する平均応答時間閾値を取得し、トラフィック情報データベース１７のオペレーションテーブルから応答遅延監視周期（例えば１時間）におけるオペレーションの応答時間合計及びレスポンス数を取得する。そして、応答遅延監視機能部２５は、応答時間合計をレスポンス数で除算した値（平均応答時間）が平均応答時間閾値より大きいか否かを判定する。平均応答時間が平均応答時間閾値より大きい場合に、応答遅延監視機能部２５は、このサービスコンポーネントをフロー規制状態にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３２】
ユーザ監視機能部１５は、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出する機能であり、レート監視機能部２６とエラー率監視機能部２７とメッセージサイズ監視機能部２８とを有している。
【００３３】
レート監視機能部２６は、あるユーザのサービスコンポーネントへのリクエスト数が利用制限回数を越えていないか否かを監視する機能であり、ユーザとオペレーションの組毎に以下の処理を行う。レート監視機能部２６は、プロファイルサーバ９からオペレーションに対するレート閾値を取得し、各ユーザからそのオペレーションへのレート監視周期（例えば本日の０時から２４時まで）におけるリクエスト数をトラフィック情報データベース１７のオペレーション−ユーザテーブルから取得する。次に、レート監視機能部２６は、リクエスト数がレート閾値より大きいユーザを抽出する。そして、レート監視機能部２６は、リクエスト数がレート閾値より大きいユーザをそのオペレーションのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３４】
エラー率監視機能部２７は、ユーザがサービスコンポーネントを不正に使用していないか否かをチェックする機能であり、ユーザとサービスコンポーネントの組ごとに以下の処理を行う。エラー率監視機能部２７は、プロファイルサーバ９からサービスコンポーネントに対するエラー閾値を取得し、トラフィック情報データベース１７のユーザテーブルから各ユーザのエラー率監視周期（例えば本日の０時から２４時まで）におけるリクエスト数及びエラー数を取得する。次に、エラー率監視機能部２７は、リクエスト数に対するエラー数の割合（エラー率）がエラー閾値より大きいユーザを抽出する。そして、エラー率監視機能部２７は、エラー率がエラー閾値より大きいユーザをそのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３５】
メッセージサイズ監視機能部２８は、ユーザからサービスコンポーネントへのリクエストのメッセージサイズが大きすぎないか否かをチェックする機能であり、ユーザとサービスコンポーネントの組ごとに以下の処理を行う。メッセージサイズ監視機能部２８は、プロファイルサーバ９からサービスコンポーネントに対するサイズ閾値を取得し、トラフィック情報データベース１７のユーザテーブルから各ユーザのメッセージサイズ監視周期（例えば本日の０時から２４時まで）におけるリクエスト数とリクエストメッセージサイズ合計を取得する。次に、メッセージサイズ監視機能部２８は、リクエストメッセージサイズ合計をリクエスト数で除算した値（平均リクエストメッセージサイズ）がサイズ閾値より大きいユーザを抽出する。そして、メッセージサイズ監視機能部２８は、平均リクエストメッセージサイズがサイズ閾値より大きいユーザをそのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３６】
リアクション機能部１６は、アラーム通知機能部２９と、サービスコンポーネント閉塞機能部３０と、フロー規制機能部３１と、ユーザ閉塞機能部３２とを有している。
【００３７】
アラーム通知機能部２９は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４から閉塞状態にするサービスコンポーネントが通知されると、サービス事業者及びシステム保守運用者の端末に、サービスコンポーネントに障害が起こっているためサービスコンポーネントに対するリクエスト転送を停止した旨をメールにて通知する。システム保守運用者とは、サービスコンポーネント管理システムの保守運用者である。なお、サービス事業者及びシステム保守運用者のメールアドレスは、プロファイルサーバ９が保持している。また、アラーム通知機能部２９は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４からフロー規制状態にするサービスコンポーネントが通知されると、サービス事業者及びシステム保守運用者の端末に、サービスコンポーネントサーバ１８が輻輳状態にあるため、サービスコンポーネントに対するリクエストを一律に一定の時間遅延させる旨をメールにて通知する。また、アラーム通知機能部２９は、あるサービスコンポーネントに対して一時利用不可能にするユーザが通知されると、そのユーザのサービスリクエスタ端末５とシステム保守運用者の端末に対して警告メールを送信する。
【００３８】
サービスコンポーネント閉塞機能部３０は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４から閉塞状態にするサービスコンポーネントが通知されると、そのサービスコンポーネントに閉塞フラグを立てる指示をプロファイルサーバ９に送信する。サービスコンポーネントに閉塞フラグを立てる指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントの閉塞フラグを立てる（つまり「１」にする）とともに、実行制御サーバ１，２，３に当該閉塞フラグを立てた旨を通知する。実行制御サーバ１，２，３は、閉塞フラグが立っているサービスコンポーネントへのリクエストを遮断する（つまり、リクエストをサービスコンポーネントサーバ１８に対して転送しない）。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントに対応する閉塞フラグをサービスコンポーネント情報テーブルから取得し、閉塞フラグが立っている（つまり、「１」である）か否かを判定する。そして、実行制御サーバ１，２，３は、閉塞フラグが立っている場合には、リクエストを遮断し、サービスリクエスタ端末５にエラーを返信する。これにより、障害が発生したサービスコンポーネントサーバ１８の影響が他のサービスコンポーネントサーバ１８に波及することを防ぐことができる。
【００３９】
フロー規制機能部３１は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４からフロー規制状態にするサービスコンポーネントが通知されると、そのサービスコンポーネントレーションに対するフロー規制フラグを立てる指示をプロファイルサーバ９に送信する。サービスコンポーネントにフロー規制フラグを立てる指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのフロー制御フラグを立てる（つまり「１」にする）とともに、実行制御サーバ１，２，３に当該フロー制御フラグを立てた旨を通知する。実行制御サーバ１，２，３は、フロー制御フラグが立っているサービスコンポーネントへのリクエストを一律に一定の時間遅延させる。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントに対応するフロー制御フラグをサービスコンポーネント情報テーブルから取得し、フロー規制フラグが立っている（つまり「１」である）場合には、リクエストを一律に一定の時間遅延させてから、サービスコンポーネントサーバ１８に転送する。これにより、サービスコンポーネントへ過剰な数のリクエストが送信されることを防ぐことができる。
【００４０】
ユーザ閉塞機能部３２は、監視実行制御機能部１３を介してユーザ監視機能部１５からあるサービスコンポーネントに対して一時利用不可能にするユーザが通知されると、そのサービスコンポーネントのブラックリストにそのユーザを追加する指示をプロファイルサーバ９に送信する。サービスコンポーネントのブラックリストにユーザを追加する指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのブラックリストにそのユーザのユーザＩＤを追加するとともに、実行制御サーバ１，２，３に当該ブラックリストに当該ユーザが追加された旨を通知する。実行制御サーバ１，２，３は、サービスコンポーネントのブラックリストに登録されているユーザからのリクエストを遮断する。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントのブラックリストをサービスコンポーネント情報テーブルから取得し、リクエストユーザＩＤがブラックリストに登録されている否かを判定する。そして、実行制御サーバ１，２，３は、ユーザＩＤがブラックリストに登録されている場合には、リクエストを遮断し、サービスリクエスタ端末５にエラーを返信する。
【００４１】
次に、図１０から１２を参照して、上述したトラフィック情報管理サーバ１０の動作を説明する。図１０は、レート監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信するとともに（ステップＳ４）、監視実行制御機能部１３にトラフィック情報データベース１７を更新した旨を通知する（ステップＳ５）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ６）。
【００４２】
一方、監視実行制御機能部１３は、レート監視機能部２６を起動する（ステップＳ７）。レート監視機能部２６は、プロファイルサーバ９のオペレーション閾値テーブルから各オペレーションのレート閾値を取得し（ステップＳ８）、トラフィック情報データベース１７のオペレーション−ユーザテーブルからレート監視周期におけるリクエスト数を取得する（ステップＳ９）。そして、レート監視機能部２６は、各オペレーションのレート閾値とそのオペレーションと各ユーザの組に対するリクエスト数を比較し、リクエスト数がレート閾値より大きいユーザとオペレーションの組を抽出する（ステップＳ１０）。そして、レート監視機能部２６は、抽出したユーザをそのオペレーションのサービスコンポーネントに対して一時利用不可能にするユーザとして監視実行制御機能部１３に通知する（ステップＳ１１）。
【００４３】
監視実行制御機能部１３は、ユーザ閉塞機能部３２及びアラーム通知機能部２９にリアクションを発動する（ステップＳ１２）。ユーザ閉塞機能部３２は、サービスコンポーネントに対して一時利用不可能にするユーザをそのサービスコンポーネントのブラックリストに追加する指示をプロファイルサーバ３２へ送信する（ステップＳ１３）。プロファイルサーバ３２は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのブラックリストにそのユーザのユーザＩＤを追加するとともに、当該ブラックリストに当該ユーザを追加したことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、ブラックリストに登録されているユーザからのリクエストを遮断する。
【００４４】
一方、アラーム通知機能部２９は、レート監視機能部２６により抽出されたユーザのサービスリクエスタ端末５及びシステム運用者の端末等に、リクエスト利用制限回数が超過し、超過した１日はサービスコンポーネントを利用できない旨をメール等で通知する（ステップＳ１４）。
【００４５】
図１１は、サービスコンポーネント利用不能率監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ２１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ２２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ２３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信する（ステップＳ２４）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ２５）。
【００４６】
一方、タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期であることを通知する（ステップＳ２６）。監視実行制御機能部１３は、サービスコンポーネント利用不能率監視機能部２４を起動する（ステップＳ２７）。サービスコンポーネント利用不能率監視機能部２４は、プロファイルサーバ９のサービスコンポーネント閾値テーブルから各サービスコンポーネントのサービス利用不能率閾値を取得し（ステップＳ２８）、トラフィック情報データベース１７のサービスコンポーネントテーブルからサービスコンポーネント利用不能率監視周期におけるリクエスト数とエラー数を取得する（ステップＳ２９）。そして、サービスコンポーネント利用不能率監視機能部２４は、各サービスコンポーネントのリクエスト数に対するエラー数の割合（エラー率）とそのサービスコンポーネントのサービス利用不能率閾値とを比較し、エラー率がサービス利用不能率閾値より大きいサービスコンポーネントを抽出する（ステップＳ３０）。そして、サービスコンポーネント利用不能率監視機能部２４は、抽出したサービスコンポーネントを監視実行制御機能部１３に通知する（ステップＳ３１）。
【００４７】
監視実行制御機能部１３は、サービスコンポーネント閉塞機能部３０及びアラーム通知機能部２９にリアクションを発動する（ステップＳ３２）。サービスコンポーネント閉塞機能部３０は、サービスコンポーネント利用不能率監視機能部２４により抽出されたサービスコンポーネントに対応する閉塞フラグを立てる指示をプロファイルサーバ３２へ送信する（ステップＳ３３）。プロファイルサーバ３２は、通知されたサービスＩＤに対応するサービスコンポーネント情報テーブルの閉塞フラグを「１」に更新するとともに、閉塞フラグを「１」にしたことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、閉塞フラグが「１」であるサービスコンポーネントへのリクエストを遮断する。
【００４８】
一方、アラーム通知機能部２９は、サービスコンポーネント利用不能率監視機能部２４により抽出されたサービスコンポーネントのサービスコンポーネントサーバ１８及びシステム運用者の端末等に、サービスコンポーネントサーバ１８に障害がおきているために、サービスコンポーネントへのリクエスト転送を停止したことをメール等で通知する（ステップＳ３４）。
【００４９】
図１２は、応答遅延監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ４１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ４２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ４３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信する（ステップＳ４４）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ４５）。
【００５０】
一方、タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期であることを通知する（ステップＳ４６）。監視実行制御機能部１３は、応答遅延監視機能部２５を起動する（ステップＳ４７）。応答遅延監視機能部２５は、プロファイルサーバ９のオペレーション閾値情報テーブルから各オペレーションの平均応答時間閾値を取得し（ステップＳ４８）、トラフィック情報データベース１７のオペレーションテーブルから応答遅延監視周期におけるレスポンス数と応答時間合計を取得する（ステップＳ４９）。そして、応答遅延監視機能部２５は、各オペレーションの応答時間合計をレスポンス数で除算した値（平均応答時間）とそのオペレーションの平均応答時間閾値とを比較し、平均応答時間が平均応答時間閾値より大きいオペレーションのサービスコンポーネントを抽出する（ステップＳ５０）。そして、応答遅延監視機能部２５は、抽出したサービスコンポーネントを監視実行制御機能部１３に通知する（ステップＳ５１）。
【００５１】
監視実行制御機能部１３は、フロー規制機能部３１及びアラーム通知機能部２９にリアクションを発動する（ステップＳ５２）。フロー規制機能部３１は、応答遅延監視機能部２５により抽出されたサービスコンポーネントに対応するフロー制御フラグを立てる指示をプロファイルサーバ３２へ送信する（ステップＳ５３）。プロファイルサーバ３２は、通知されたサービスＩＤに対応するサービスコンポーネント情報テーブルのフロー制御フラグを「１」に更新するとともに、フロー制御フラグを「１」にしたことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、フロー制御フラグが「１」であるサービスコンポーネントへのリクエストを一律に一定時間遅延させてから転送する。これにより、サービスコンポーネントサーバ１８が輻輳状態である時にサービスコンポーネントへのリクエストを送信することを防ぐことができる。
【００５２】
一方、アラーム通知機能部２９は、応答遅延監視機能部２５により抽出されたサービスコンポーネントのサービスコンポーネントサーバ１８及びシステム運用者の端末等に、サービスコンポーネントサーバ１８が輻輳状態であると思われるため、リクエスト転送のフロー制御を行ったことをメール等で通知する（ステップＳ５４）。
【００５３】
このように、本実施形態によれば、トラフィック情報管理サーバ１０が、複数の実行制御サーバ１，２，３からトラフィック情報を収集して集計して、各サービスコンポーネント品質監視制御を行っているため、実行制御サーバ１，２，３が複数台並列して処理を行ってもシステム全体としてトラフィック情報の整合性を保つことができる。これにより、サービスコンポーネントへのリクエストに対して信頼性の高いサービス品質監視制御を行うことができる。
また、実行制御サーバ１，２，３が複数台並列してサービスコンポーネントへのリクエスト処理を行っているため、単位時間におけるサービスコンポーネントへのリクエスト処理量を向上することができる。
また、各サービスコンポーネントにおける共通処理を一括して実行制御サーバ１，２，３が行っているため、サービス事業者側のサービスコンポーネント以外の機能（非機能要件）実装にかかる投資及び経費費用を軽減することができる。
また、実行制御サーバ１，２，３は、閉塞状態にあるサービスコンポーネントへのリクエストを遮断することにより、障害が発生したサービスコンポーネントサーバの影響が他のサービスコンポーネントへの波及を防ぐことができる。
【００５４】
また、図９に示すトラフィック情報管理サーバの機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、サービスコンポーネント品質監視制御処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００５５】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００５６】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
例えば、本実施形態では３台の実行制御サーバを用いているが、２台以上であればよい。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施形態によるサービスコンポーネント管理システムの構成を示すブロック図である。
【図２】本実施形態におけるサービスコンポーネントテーブルのデータ構造とデータ例を示す概略図である。
【図３】本実施形態におけるオペレーションテーブルのデータ構造とデータ例を示す概略図である。
【図４】本実施形態におけるオペレーション−ユーザテーブルのデータ構造とデータ例を示す概略図である。
【図５】本実施形態におけるユーザテーブルのデータ構造とデータ例を示す概略図である。
【図６】本実施形態におけるサービスコンポーネント情報テーブルのデータ構造とデータ例を示す概略図である。
【図７】本実施形態におけるサービスコンポーネント閾値情報テーブルのデータ構造とデータ例を示す概略図である。
【図８】本実施形態におけるオペレーション閾値情報テーブルのデータ構造とデータ例を示す概略図である。
【図９】本実施形態におけるトラフィック情報管理サーバの機能構成を示すブロック図である。
【図１０】本実施形態におけるレート監視処理の手順を示すシーケンス図である。
【図１１】本実施形態におけるサービスコンポーネント利用不能率監視処理の手順を示すシーケンス図である。
【図１２】本実施形態における応答遅延監視処理の手順を示すシーケンス図である。
【符号の説明】
【００５８】
１，２，３…実行制御サーバ ４…実行制御サーバクラスタ ５，６，７…サービスリクエスタ端末 ８…ネットワーク ９…プロファイルサーバ １０…トラフィック情報管理サーバ １１…トラフィック収集機能部 １２…トラフィック集計機能部 １３…監視実行制御機能部 １４…サービスコンポーネント監視機能部 １５…ユーザ監視機能部 １６…リアクション機能部 ２３…タイマー ２４…サービスコンポーネント利用不能率監視機能部 ２５…応答遅延監視機能部 ２６…レート監視機能部 ２７…エラー率監視機能部 ２８…メッセージサイズ監視機能部
【技術分野】
【０００１】
本発明は、トラフィック情報管理サーバ及びトラフィック情報管理方法に関する。
【背景技術】
【０００２】
現在、ウェブサービス等のサービスコンポーネントを連携利用することで、新たなサービスを容易に実現する試みがある。
非特許文献１に記載された技術では、電話サービスとウェブサービスとを連携するシステムにおいて、実行制御サーバがユーザ認証やトラフィック制御などの共通処理を一括して行っている。
また、非特許文献２に記載された技術では、サービスコンポーネントに対するリクエストを処理する複数台のサーバをクラスタ化している。
【非特許文献１】山登庸次、大西浩行、中野雄介、“電話−ウェブ連携を促進する実行制御機能の検討”電子情報通信学会２００８年総合大会講演論文集、B-19-10、Mar.2008.
【非特許文献２】“Oracle Communications Services Gatekeeper”、［online］、Oracle、［２００８年１１月０４日検索］、インターネット〈URL:http://www.oracle.com/industries/communications/oracle-communications-services-gatekeeper.html〉
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、非特許文献１では、１台の実行制御サーバ単体での運用を想定しているため、実行制御サーバを複数台用いた場合には、ユーザからサービスコンポーネントへのリクエストをシステム全体で監視することができない、という問題がある。
例えば、あるユーザａがサービスコンポーネントＡを１日に使用できる回数が１００回と設定されていたときに、ユーザａが実行制御サーバ１で３０回、実行制御サーバ２で８０回、実行制御サーバ３で６０回サービスコンポーネントＡを使用した場合であっても、１日の使用制限回数１００回を超えているユーザとしてユーザａを検出することはできなかった。
また、非特許文献２では、全てのデータをサーバ間で通信して同期を取っているため、その通信コストからクラスタ化しても性能向上する効果が少ない、という問題がある。
本発明は上記の点に鑑みてなされたものであり、その目的は、複数台の実行制御サーバを並列に実行したとしてもシステム全体でリクエストを監視することができ、サービスコンポーネントへのリクエスト処理量を向上することができるトラフィック情報管理サーバ及びトラフィック情報管理方法を提供することにある。
【課題を解決するための手段】
【０００４】
本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するトラフィック収集機能部と、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するトラフィック集計機能部と、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント利用不能率監視機能部と、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部と、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するサービスコンポーネント閉塞機能部と、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するユーザ閉塞機能部と、を備えることを特徴とするトラフィック情報管理サーバである。
【０００５】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記サービスコンポーネント利用不能率監視機能部により抽出されたサービスコンポーネントを閉塞状態にしたことを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第１のアラーム通知機能部と、前記ユーザ監視機能部により抽出されたユーザを前記特定のサービスコンポーネントに対して一時利用不可能にしたことを当該ユーザの端末に通知する第２のアラーム通知機能部と、を備えることを特徴とする。
【０００６】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記トラフィック情報は、サービスコンポーネントからの応答時間の状況を表す応答時間情報を含み、前記サービスコンポーネント情報は、サービスコンポーネントへのリクエストを一律に一定の時間遅延させるフロー制御を行うか否かを表すフロー制御フラグを含み、前記トラフィック集計機能部により集計された前記応答時間情報に基づいて、フロー制御を行うサービスコンポーネントを抽出する応答遅延監視機能部と、前記応答遅延監視機能部により抽出されたサービスコンポーネントに対応する前記フロー制御フラグの更新要求を外部に送信するフロー規制機能部と、を備えることを特徴とする。
【０００７】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記応答遅延監視機能部により抽出されたサービスコンポーネントへのリクエストを一律に一定の時間遅延させていることを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第３のアラーム通知機能部を備えることを特徴とする。
【０００８】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数に基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【０００９】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数と当該リクエストに対するエラーの数とに基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【００１０】
また、本発明の一態様は、上記のトラフィック情報管理サーバにおいて、前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの平均サイズに基づいて、一時利用不可能にするユーザを抽出することを特徴とする。
【００１１】
また、本発明の一態様は、前トラフィック収集機能部が、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するステップと、トラフィック集計機能部が、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するステップと、サービスコンポーネント利用不能率監視機能部が、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するステップと、ユーザ監視機能部が、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するステップと、サービスコンポーネント閉塞機能部が、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するステップと、ユーザ閉塞機能部が、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するステップと、を有することを特徴とするトラフィック情報管理方法である。
【発明の効果】
【００１２】
本発明によれば、トラフィック情報管理サーバが、複数の実行制御サーバからトラフィック情報を収集して集計して閉塞状態にするサービスコンポーネント及び特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出しているため、実行制御サーバが複数台並列して処理を行ってもシステム全体としてトラフィック情報の整合性を保つことができる。
また、実行制御サーバが複数台並列してサービスコンポーネントへのリクエスト処理を行っているため、単位時間におけるサービスコンポーネントへのリクエスト処理量を向上することができる。
また、各サービスコンポーネントにおける共通処理を一括して実行制御サーバが行っているため、サービス事業者側のサービスコンポーネント以外の機能（非機能要件）実装にかかる投資及び経費費用を軽減することができる。
また、実行制御サーバ１，２，３は、閉塞状態にあるサービスコンポーネントへのリクエストを遮断することにより、障害が発生したサービスコンポーネントサーバの影響が他のサービスコンポーネントへの波及を防ぐことができる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
図１は、本発明の一実施形態によるサービスコンポーネント管理システムの構成を示すブロック図である。
サービスコンポーネント管理システムは、実行制御サーバクラスタ４と、トラフィック情報管理サーバ１０と、プロファイルサーバ９と、トラフィック情報データベース１７と、サービスリクエスタ端末５，６，７と、複数のサービスコンポーネントサーバ１８と、を含んで構成される。
サービスリクエスタ端末５，６，７と実行制御サーバクラスタ４及び、実行制御サーバクラスタ４とサービスコンポーネントサーバ１８とは、ネットワーク８を介してメッセージの送受信を行う。ネットワーク８は、電話交換等の通信ネットワーク、或いはインターネット等の情報ネットワーク、或いはサービス制御層とパケット転送層とを有するＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）、或いは移動体ネットワーク等からなるネットワークである。
【００１４】
サービスコンポーネントサーバ１８は、サービスリクエスタ端末５，６，７に複数のサービスコンポーネントを提供するサーバ装置である。サービスコンポーネントとは、サービス事業者提供するウェブサービスや電話サービスなどのサービスである。
サービスリクエスタ端末５，６，７は、複数のサービスコンポーネントが連携してなるサービスを利用するユーザ（リクエスタ）が使用する端末である。
【００１５】
トラフィック情報データベース１７は、トラフィック情報の集計結果を記憶保持するデータベースであり、サービスコンポーネントテーブルと、オペレーションテーブルと、オペレーション−ユーザテーブルと、ユーザテーブルとを保持している。トラフィック情報とは、サービスコンポーネントテーブルと、オペレーションテーブルと、オペレーション−ユーザテーブルと、ユーザテーブルにおける各項目をトラフィック情報生成時間毎に集計した情報である。また、オペレーション−ユーザテーブル及びユーザテーブルの各項目が、特定のユーザから特定のサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報である。また、サービスコンポーネントテーブルの各項目が、特定のサービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報である。また、オペレーションテーブルの各項目が、特定のサービスコンポーネントからの応答時間の状況を表す応答時間情報である。
【００１６】
プロファイルサーバ９は、ユーザ情報とサービスコンポーネント情報とを保持するサーバ装置であり、サービスコンポーネント情報テーブルと、サービスコンポーネント閾値情報テーブルと、オペレーション閾値情報テーブルを保持している。
【００１７】
実行制御サーバクラスタ４は、実行制御サーバ１，２，３群である。
実行制御サーバ１，２，３は、各サービスコンポーネントの共通処理を行うサーバ装置である。各サービスコンポーネントの共通処理とは、ユーザ認証や各サービスコンポーネントに応じたトラフィック制御などであり、サービスリクエスタ端末５，６，７から受信したサービスコンポーネントへのリクエストをサービスコンポーネントサーバ１８に転送する。また、実行制御サーバ１，２，３は、トラフィック情報生成時間（例えば毎時００分からの３分周期）毎にトラフィック情報を生成してトラフィック情報管理サーバ１０に送信する。なお、サービスリクエスタ５，６，７からのリクエストは図示しないロードバランサーにより、ラウンドロビンアルゴリズムや実行制御サーバ１，２，３のＣＰＵ（中央演算装置）使用率に応じて実行制御サーバ１，２，３に振り分けられる。
【００１８】
トラフィック情報管理サーバ１０は、各サービスコンポーネントへの負荷状況を監視するサービスコンポーネント品質監視制御を行うサーバ装置である。トラフィック情報管理サーバ１０の機能構成は後述する。
【００１９】
図２は、本実施形態におけるサービスコンポーネントテーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネントテーブルは、年月日と、時と、サービスＩＤと、リクエスト数と、エラー数の各項目の列を有している。時は、時間を示しており、例えば、時「１０」は、１０時００分から１０時５９分までを表す。サービスＩＤは、サービスコンポーネントを識別する識別情報である。リクエスト数は、サービスコンポーネント宛に送信されたリクエストの数である。エラー数は、サービスリクエスト宛に送信されたリクエストに対するエラーの数であり、認証ＮＧと、認可ＮＧと、応答タイムアウトの各項目を有している。認証ＮＧは、ユーザ認証されなかった場合のエラーである。認可ＮＧは、例えばユーザにサービスコンポーネントの使用権限がない場合のエラーである。応答タイムアウトは、リクエストに対するレスポンスが一定時間内に返されなかった場合のエラーである。
【００２０】
図３は、本実施形態におけるオペレーションテーブルのデータ構造とデータ例を示す概略図である。オペレーションテーブルは、年月日と、時と、サービスＩＤと、オペレーション名と、レスポンス数と、応答時間合計の各項目の列を有している。オペレーション名は、サービスコンポーネントのオペレーション（例えば、電話サービスの場合、発呼、着信等）の名称である。レスポンス数は、リクエストに対するレスポンスの数である。応答時間合計は、実行制御サーバ１，２，３がリクエストを送信してからレスポンスを受信するまでの応答時間の合計値であり、単位はミリ秒（ｍｓ）である。
【００２１】
図４は、本実施形態におけるオペレーション−ユーザテーブルのデータ構造とデータ例を示す概略図である。オペレーション−ユーザテーブルは、年月日と、時と、サービスＩＤと、オペレーション名と、ユーザＩＤと、リクエスト数の各項目の列を有している。ユーザＩＤは、ユーザを識別するための識別情報である。
【００２２】
図５は、本実施形態におけるユーザテーブルのデータ構造とデータ例を示す概略図である。ユーザテーブルは、年月日と、時と、ユーザＩＤと、リクエスト数と、エラー数の各項目の列を有している。
【００２３】
図６は、本実施形態におけるサービスコンポーネント情報テーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネント情報テーブルは、サービスコンポーネント情報として、サービスＩＤと、フロー規制フラグと、閉塞フラグ（サービスコンポーネント閉塞フラグ）と、ブラックリストの各項目の列を有している。フロー規制フラグは、そのサービスコンポーネントにフロー制御があるか否かを示すフラグであり、フロー規制フラグ「１」はフロー規制があることを表し、フロー規制フラグ「０」はフロー規制がないことを表す。閉塞フラグは、サービスコンポーネントが閉塞状態（利用できない状態）にあるか否かを示すフラグであり、閉塞フラグ「１」は閉塞状態であることを表し、閉塞フラグ「０」は閉塞状態ではないことを表す。ブラックリストは、サービスコンポーネントを一時利用不可能になっているユーザのユーザＩＤの一覧である。
【００２４】
図７は、本実施形態におけるサービスコンポーネント閾値情報テーブルのデータ構造とデータ例を示す概略図である。サービスコンポーネント閾値情報テーブルは、サービスＩＤと、サービス利用不能率閾値と、エラー閾値と、サイズ閾値との各項目の列を有している。サービス利用不能率閾値は、サービスが利用不能になる率に関する閾値である。エラー閾値は、エラーの割合に関する閾値である。サイズ閾値は、リクエストのサイズに関する閾値である。
【００２５】
図８は、本実施形態におけるオペレーション閾値情報テーブルのデータ構造とデータ例を示す概略図である。オペレーション閾値情報テーブルは、サービスＩＤと、オペレーション名と、レート閾値と、平均応答時間閾値との各項目の列を有している。オペレーション名は、サービスコンポーネントのオペレーション（例えば、電話サービスの場合、発呼、着信等）の名称である。レート閾値は、１ユーザがレート監視周期（例えば１日）にサービスコンポーネントに送信可能なリクエスト数の閾値である。平均応答時間閾値は、リクエストに対する平均応答時間に関する閾値である。
【００２６】
図９は、本実施形態におけるトラフィック情報管理サーバ１０の機能構成を示すブロック図である。
トラフィック情報管理サーバ１０は、複数の実行制御サーバ１，２，３からトラフィック情報を収集して集計を行い、全てのトラフィック情報を集約することで、サービスコンポーネント品質監視制御を行う。これにより、システム全体の整合を取ることができ、かつ、サービスコンポーネント品質監視制御の不整合を防ぐことができる。トラフィック情報管理サーバ１０は、トラフィック収集機能部１１と、トラフィック集計機能部１２と、監視実行制御機能部１３と、サービスコンポーネント監視機能部１４と、ユーザ監視機能部１５と、リアクション機能部１６と、タイマ（Ｔｉｍｅｒ）２３と、を含んで構成される。監視実行制御機能部１３と、サービスコンポーネント監視機能部１４と、ユーザ監視機能部１５と、リアクション機能部１６とにおける処理がサービスコンポーネント監視制御である。
【００２７】
トラフィック収集機能部１１は、実行制御サーバ１，２，３からトラフィック情報をポーリングにてトラフィック情報生成時間（例えば３分）毎に収集し、トラフィック集計機能部１２に出力する。
トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する。具体的には、トラフィック集計機能部１２は、サービスコンポーネント毎にリクエスト数とエラー数とをカウントする。また、トラフィック集計機能部１２は、オペレーション毎にレスポンス数と応答時間合計とをカウントする。また、トラフィック集計機能部１２は、オペレーションとユーザの組毎にリクエスト数をカウントする。また、トラフィック集計機能部１２は、ユーザ毎にリクエスト数とエラー数とリクエストメッセージ合計とをカウントする。そして、トラフィック集計機能部１２は、トラフィック情報が生成された年月日時とともにカウントした値をトラフィック情報データベース１７に送信して記憶させる。
【００２８】
監視実行制御機能部１３は、一定時間或いは一定周期でサービスコンポーネント監視機能部１４とユーザ監視機能部１５とに独立に処理を行わせる機能である。また、サービスコンポーネント監視機能部１４及びユーザ監視機能部１５における処理がサービスコンポーネント監視制御である。具体的には、監視実行制御機能部１３は、サービスコンポーネント監視周期（例えば１時間）毎にサービスコンポーネント監視機能部１４のサービスコンポーネント利用不能率機能部２４及び応答遅延監視機能部２５に処理を行わせる。また、監視実行制御機能部１３は、ユーザ監視周期（例えば３分）毎にユーザ監視機能部１５のレート監視機能部２６とエラー率監視機能部２７とメッセージサイズ監視機能部２８とに処理を行わせる。
タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期及びユーザ監視周期を通知する。
【００２９】
サービスコンポーネント監視機能部１４は、閉塞状態にするサービスコンポーネント又はフロー規制状態にするサービスコンポーネントを抽出する機能であり、サービスコンポーネント利用不能率監視機能部２４と応答遅延監視機能部２５とを有している。
【００３０】
サービスコンポーネント利用不能率監視機能部２４は、サービスコンポーネントのレスポンス数が許容範囲か否かを監視する機能であり、各サービスコンポーネントに対して以下の処理を実行する。まず。サービスコンポーネント利用不能率機能部２４は、プロファイルサーバ９からサービスコンポーネントに対応するサービス利用不能率閾値を取得し、トラフィック情報データベース１７のサービスコンポーネントテーブルからサービスコンポーネント利用不能率監視周期（例えば１時間）におけるこのサービスコンポーネントのリクエスト数と応答タイムアウトのエラー数とを取得する。そして、サービスコンポーネント利用不能率機能部２４は、取得したリクエスト数に対するエラー数の割合（エラー率）がサービス利用不能率閾値を超えているか否かを判定する。エラー率がサービス利用不能率閾値より大きい場合に、このサービスコンポーネントを閉塞状態にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３１】
応答遅延監視機能部２５は、各サービスコンポーネントのオペレーションに対して以下の処理を実行する。まず、応答遅延監視機能部２５は、プロファイルサーバ９からオペレーションに対応する平均応答時間閾値を取得し、トラフィック情報データベース１７のオペレーションテーブルから応答遅延監視周期（例えば１時間）におけるオペレーションの応答時間合計及びレスポンス数を取得する。そして、応答遅延監視機能部２５は、応答時間合計をレスポンス数で除算した値（平均応答時間）が平均応答時間閾値より大きいか否かを判定する。平均応答時間が平均応答時間閾値より大きい場合に、応答遅延監視機能部２５は、このサービスコンポーネントをフロー規制状態にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３２】
ユーザ監視機能部１５は、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出する機能であり、レート監視機能部２６とエラー率監視機能部２７とメッセージサイズ監視機能部２８とを有している。
【００３３】
レート監視機能部２６は、あるユーザのサービスコンポーネントへのリクエスト数が利用制限回数を越えていないか否かを監視する機能であり、ユーザとオペレーションの組毎に以下の処理を行う。レート監視機能部２６は、プロファイルサーバ９からオペレーションに対するレート閾値を取得し、各ユーザからそのオペレーションへのレート監視周期（例えば本日の０時から２４時まで）におけるリクエスト数をトラフィック情報データベース１７のオペレーション−ユーザテーブルから取得する。次に、レート監視機能部２６は、リクエスト数がレート閾値より大きいユーザを抽出する。そして、レート監視機能部２６は、リクエスト数がレート閾値より大きいユーザをそのオペレーションのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３４】
エラー率監視機能部２７は、ユーザがサービスコンポーネントを不正に使用していないか否かをチェックする機能であり、ユーザとサービスコンポーネントの組ごとに以下の処理を行う。エラー率監視機能部２７は、プロファイルサーバ９からサービスコンポーネントに対するエラー閾値を取得し、トラフィック情報データベース１７のユーザテーブルから各ユーザのエラー率監視周期（例えば本日の０時から２４時まで）におけるリクエスト数及びエラー数を取得する。次に、エラー率監視機能部２７は、リクエスト数に対するエラー数の割合（エラー率）がエラー閾値より大きいユーザを抽出する。そして、エラー率監視機能部２７は、エラー率がエラー閾値より大きいユーザをそのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３５】
メッセージサイズ監視機能部２８は、ユーザからサービスコンポーネントへのリクエストのメッセージサイズが大きすぎないか否かをチェックする機能であり、ユーザとサービスコンポーネントの組ごとに以下の処理を行う。メッセージサイズ監視機能部２８は、プロファイルサーバ９からサービスコンポーネントに対するサイズ閾値を取得し、トラフィック情報データベース１７のユーザテーブルから各ユーザのメッセージサイズ監視周期（例えば本日の０時から２４時まで）におけるリクエスト数とリクエストメッセージサイズ合計を取得する。次に、メッセージサイズ監視機能部２８は、リクエストメッセージサイズ合計をリクエスト数で除算した値（平均リクエストメッセージサイズ）がサイズ閾値より大きいユーザを抽出する。そして、メッセージサイズ監視機能部２８は、平均リクエストメッセージサイズがサイズ閾値より大きいユーザをそのサービスコンポーネントに対して一時利用不可能にすると判定し、監視実行制御機能部１３を介してリアクション機能部１６にその旨を通知する。
【００３６】
リアクション機能部１６は、アラーム通知機能部２９と、サービスコンポーネント閉塞機能部３０と、フロー規制機能部３１と、ユーザ閉塞機能部３２とを有している。
【００３７】
アラーム通知機能部２９は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４から閉塞状態にするサービスコンポーネントが通知されると、サービス事業者及びシステム保守運用者の端末に、サービスコンポーネントに障害が起こっているためサービスコンポーネントに対するリクエスト転送を停止した旨をメールにて通知する。システム保守運用者とは、サービスコンポーネント管理システムの保守運用者である。なお、サービス事業者及びシステム保守運用者のメールアドレスは、プロファイルサーバ９が保持している。また、アラーム通知機能部２９は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４からフロー規制状態にするサービスコンポーネントが通知されると、サービス事業者及びシステム保守運用者の端末に、サービスコンポーネントサーバ１８が輻輳状態にあるため、サービスコンポーネントに対するリクエストを一律に一定の時間遅延させる旨をメールにて通知する。また、アラーム通知機能部２９は、あるサービスコンポーネントに対して一時利用不可能にするユーザが通知されると、そのユーザのサービスリクエスタ端末５とシステム保守運用者の端末に対して警告メールを送信する。
【００３８】
サービスコンポーネント閉塞機能部３０は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４から閉塞状態にするサービスコンポーネントが通知されると、そのサービスコンポーネントに閉塞フラグを立てる指示をプロファイルサーバ９に送信する。サービスコンポーネントに閉塞フラグを立てる指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントの閉塞フラグを立てる（つまり「１」にする）とともに、実行制御サーバ１，２，３に当該閉塞フラグを立てた旨を通知する。実行制御サーバ１，２，３は、閉塞フラグが立っているサービスコンポーネントへのリクエストを遮断する（つまり、リクエストをサービスコンポーネントサーバ１８に対して転送しない）。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントに対応する閉塞フラグをサービスコンポーネント情報テーブルから取得し、閉塞フラグが立っている（つまり、「１」である）か否かを判定する。そして、実行制御サーバ１，２，３は、閉塞フラグが立っている場合には、リクエストを遮断し、サービスリクエスタ端末５にエラーを返信する。これにより、障害が発生したサービスコンポーネントサーバ１８の影響が他のサービスコンポーネントサーバ１８に波及することを防ぐことができる。
【００３９】
フロー規制機能部３１は、監視実行制御機能部１３を介してサービスコンポーネント監視機能部１４からフロー規制状態にするサービスコンポーネントが通知されると、そのサービスコンポーネントレーションに対するフロー規制フラグを立てる指示をプロファイルサーバ９に送信する。サービスコンポーネントにフロー規制フラグを立てる指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのフロー制御フラグを立てる（つまり「１」にする）とともに、実行制御サーバ１，２，３に当該フロー制御フラグを立てた旨を通知する。実行制御サーバ１，２，３は、フロー制御フラグが立っているサービスコンポーネントへのリクエストを一律に一定の時間遅延させる。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントに対応するフロー制御フラグをサービスコンポーネント情報テーブルから取得し、フロー規制フラグが立っている（つまり「１」である）場合には、リクエストを一律に一定の時間遅延させてから、サービスコンポーネントサーバ１８に転送する。これにより、サービスコンポーネントへ過剰な数のリクエストが送信されることを防ぐことができる。
【００４０】
ユーザ閉塞機能部３２は、監視実行制御機能部１３を介してユーザ監視機能部１５からあるサービスコンポーネントに対して一時利用不可能にするユーザが通知されると、そのサービスコンポーネントのブラックリストにそのユーザを追加する指示をプロファイルサーバ９に送信する。サービスコンポーネントのブラックリストにユーザを追加する指示を受信すると、プロファイルサーバ９は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのブラックリストにそのユーザのユーザＩＤを追加するとともに、実行制御サーバ１，２，３に当該ブラックリストに当該ユーザが追加された旨を通知する。実行制御サーバ１，２，３は、サービスコンポーネントのブラックリストに登録されているユーザからのリクエストを遮断する。具体的には、実行制御サーバ１，２，３は、サービスリクエスタ端末５からサービスコンポーネントへのリクエストを受信すると、リクエスト先のサービスコンポーネントのブラックリストをサービスコンポーネント情報テーブルから取得し、リクエストユーザＩＤがブラックリストに登録されている否かを判定する。そして、実行制御サーバ１，２，３は、ユーザＩＤがブラックリストに登録されている場合には、リクエストを遮断し、サービスリクエスタ端末５にエラーを返信する。
【００４１】
次に、図１０から１２を参照して、上述したトラフィック情報管理サーバ１０の動作を説明する。図１０は、レート監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信するとともに（ステップＳ４）、監視実行制御機能部１３にトラフィック情報データベース１７を更新した旨を通知する（ステップＳ５）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ６）。
【００４２】
一方、監視実行制御機能部１３は、レート監視機能部２６を起動する（ステップＳ７）。レート監視機能部２６は、プロファイルサーバ９のオペレーション閾値テーブルから各オペレーションのレート閾値を取得し（ステップＳ８）、トラフィック情報データベース１７のオペレーション−ユーザテーブルからレート監視周期におけるリクエスト数を取得する（ステップＳ９）。そして、レート監視機能部２６は、各オペレーションのレート閾値とそのオペレーションと各ユーザの組に対するリクエスト数を比較し、リクエスト数がレート閾値より大きいユーザとオペレーションの組を抽出する（ステップＳ１０）。そして、レート監視機能部２６は、抽出したユーザをそのオペレーションのサービスコンポーネントに対して一時利用不可能にするユーザとして監視実行制御機能部１３に通知する（ステップＳ１１）。
【００４３】
監視実行制御機能部１３は、ユーザ閉塞機能部３２及びアラーム通知機能部２９にリアクションを発動する（ステップＳ１２）。ユーザ閉塞機能部３２は、サービスコンポーネントに対して一時利用不可能にするユーザをそのサービスコンポーネントのブラックリストに追加する指示をプロファイルサーバ３２へ送信する（ステップＳ１３）。プロファイルサーバ３２は、サービスコンポーネント情報テーブルにおけるそのサービスコンポーネントのブラックリストにそのユーザのユーザＩＤを追加するとともに、当該ブラックリストに当該ユーザを追加したことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、ブラックリストに登録されているユーザからのリクエストを遮断する。
【００４４】
一方、アラーム通知機能部２９は、レート監視機能部２６により抽出されたユーザのサービスリクエスタ端末５及びシステム運用者の端末等に、リクエスト利用制限回数が超過し、超過した１日はサービスコンポーネントを利用できない旨をメール等で通知する（ステップＳ１４）。
【００４５】
図１１は、サービスコンポーネント利用不能率監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ２１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ２２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ２３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信する（ステップＳ２４）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ２５）。
【００４６】
一方、タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期であることを通知する（ステップＳ２６）。監視実行制御機能部１３は、サービスコンポーネント利用不能率監視機能部２４を起動する（ステップＳ２７）。サービスコンポーネント利用不能率監視機能部２４は、プロファイルサーバ９のサービスコンポーネント閾値テーブルから各サービスコンポーネントのサービス利用不能率閾値を取得し（ステップＳ２８）、トラフィック情報データベース１７のサービスコンポーネントテーブルからサービスコンポーネント利用不能率監視周期におけるリクエスト数とエラー数を取得する（ステップＳ２９）。そして、サービスコンポーネント利用不能率監視機能部２４は、各サービスコンポーネントのリクエスト数に対するエラー数の割合（エラー率）とそのサービスコンポーネントのサービス利用不能率閾値とを比較し、エラー率がサービス利用不能率閾値より大きいサービスコンポーネントを抽出する（ステップＳ３０）。そして、サービスコンポーネント利用不能率監視機能部２４は、抽出したサービスコンポーネントを監視実行制御機能部１３に通知する（ステップＳ３１）。
【００４７】
監視実行制御機能部１３は、サービスコンポーネント閉塞機能部３０及びアラーム通知機能部２９にリアクションを発動する（ステップＳ３２）。サービスコンポーネント閉塞機能部３０は、サービスコンポーネント利用不能率監視機能部２４により抽出されたサービスコンポーネントに対応する閉塞フラグを立てる指示をプロファイルサーバ３２へ送信する（ステップＳ３３）。プロファイルサーバ３２は、通知されたサービスＩＤに対応するサービスコンポーネント情報テーブルの閉塞フラグを「１」に更新するとともに、閉塞フラグを「１」にしたことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、閉塞フラグが「１」であるサービスコンポーネントへのリクエストを遮断する。
【００４８】
一方、アラーム通知機能部２９は、サービスコンポーネント利用不能率監視機能部２４により抽出されたサービスコンポーネントのサービスコンポーネントサーバ１８及びシステム運用者の端末等に、サービスコンポーネントサーバ１８に障害がおきているために、サービスコンポーネントへのリクエスト転送を停止したことをメール等で通知する（ステップＳ３４）。
【００４９】
図１２は、応答遅延監視処理の手順を示すシーケンス図である。
まず、トラフィック情報管理サーバ１０のトラフィック収集機能部１１が、トラフィック情報生成時間毎に実行制御サーバ１、実行制御サーバ２、実行制御サーバ３の順にトラフィック情報を収集する（ステップＳ４１）。そして、トラフィック収集機能部１１は、収集した複数のトラフィック情報をトラフィック集計機能部１２へ出力する（ステップＳ４２）。トラフィック集計機能部１２は、入力された複数のトラフィック情報を集計する（ステップＳ４３）。そして、集計結果であるカウント値をトラフィック情報が生成された年月日時とともにトラフィック情報データベース１７へ送信する（ステップＳ４４）。トラフィック情報データベース１７は、受信したカウンタ値を保存する（ステップＳ４５）。
【００５０】
一方、タイマー２３は、監視実行制御機能部１３にサービスコンポーネント監視周期であることを通知する（ステップＳ４６）。監視実行制御機能部１３は、応答遅延監視機能部２５を起動する（ステップＳ４７）。応答遅延監視機能部２５は、プロファイルサーバ９のオペレーション閾値情報テーブルから各オペレーションの平均応答時間閾値を取得し（ステップＳ４８）、トラフィック情報データベース１７のオペレーションテーブルから応答遅延監視周期におけるレスポンス数と応答時間合計を取得する（ステップＳ４９）。そして、応答遅延監視機能部２５は、各オペレーションの応答時間合計をレスポンス数で除算した値（平均応答時間）とそのオペレーションの平均応答時間閾値とを比較し、平均応答時間が平均応答時間閾値より大きいオペレーションのサービスコンポーネントを抽出する（ステップＳ５０）。そして、応答遅延監視機能部２５は、抽出したサービスコンポーネントを監視実行制御機能部１３に通知する（ステップＳ５１）。
【００５１】
監視実行制御機能部１３は、フロー規制機能部３１及びアラーム通知機能部２９にリアクションを発動する（ステップＳ５２）。フロー規制機能部３１は、応答遅延監視機能部２５により抽出されたサービスコンポーネントに対応するフロー制御フラグを立てる指示をプロファイルサーバ３２へ送信する（ステップＳ５３）。プロファイルサーバ３２は、通知されたサービスＩＤに対応するサービスコンポーネント情報テーブルのフロー制御フラグを「１」に更新するとともに、フロー制御フラグを「１」にしたことを実行制御サーバ１，２，３に通知する。実行制御サーバ１，２，３は、フロー制御フラグが「１」であるサービスコンポーネントへのリクエストを一律に一定時間遅延させてから転送する。これにより、サービスコンポーネントサーバ１８が輻輳状態である時にサービスコンポーネントへのリクエストを送信することを防ぐことができる。
【００５２】
一方、アラーム通知機能部２９は、応答遅延監視機能部２５により抽出されたサービスコンポーネントのサービスコンポーネントサーバ１８及びシステム運用者の端末等に、サービスコンポーネントサーバ１８が輻輳状態であると思われるため、リクエスト転送のフロー制御を行ったことをメール等で通知する（ステップＳ５４）。
【００５３】
このように、本実施形態によれば、トラフィック情報管理サーバ１０が、複数の実行制御サーバ１，２，３からトラフィック情報を収集して集計して、各サービスコンポーネント品質監視制御を行っているため、実行制御サーバ１，２，３が複数台並列して処理を行ってもシステム全体としてトラフィック情報の整合性を保つことができる。これにより、サービスコンポーネントへのリクエストに対して信頼性の高いサービス品質監視制御を行うことができる。
また、実行制御サーバ１，２，３が複数台並列してサービスコンポーネントへのリクエスト処理を行っているため、単位時間におけるサービスコンポーネントへのリクエスト処理量を向上することができる。
また、各サービスコンポーネントにおける共通処理を一括して実行制御サーバ１，２，３が行っているため、サービス事業者側のサービスコンポーネント以外の機能（非機能要件）実装にかかる投資及び経費費用を軽減することができる。
また、実行制御サーバ１，２，３は、閉塞状態にあるサービスコンポーネントへのリクエストを遮断することにより、障害が発生したサービスコンポーネントサーバの影響が他のサービスコンポーネントへの波及を防ぐことができる。
【００５４】
また、図９に示すトラフィック情報管理サーバの機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、サービスコンポーネント品質監視制御処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００５５】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００５６】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
例えば、本実施形態では３台の実行制御サーバを用いているが、２台以上であればよい。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施形態によるサービスコンポーネント管理システムの構成を示すブロック図である。
【図２】本実施形態におけるサービスコンポーネントテーブルのデータ構造とデータ例を示す概略図である。
【図３】本実施形態におけるオペレーションテーブルのデータ構造とデータ例を示す概略図である。
【図４】本実施形態におけるオペレーション−ユーザテーブルのデータ構造とデータ例を示す概略図である。
【図５】本実施形態におけるユーザテーブルのデータ構造とデータ例を示す概略図である。
【図６】本実施形態におけるサービスコンポーネント情報テーブルのデータ構造とデータ例を示す概略図である。
【図７】本実施形態におけるサービスコンポーネント閾値情報テーブルのデータ構造とデータ例を示す概略図である。
【図８】本実施形態におけるオペレーション閾値情報テーブルのデータ構造とデータ例を示す概略図である。
【図９】本実施形態におけるトラフィック情報管理サーバの機能構成を示すブロック図である。
【図１０】本実施形態におけるレート監視処理の手順を示すシーケンス図である。
【図１１】本実施形態におけるサービスコンポーネント利用不能率監視処理の手順を示すシーケンス図である。
【図１２】本実施形態における応答遅延監視処理の手順を示すシーケンス図である。
【符号の説明】
【００５８】
１，２，３…実行制御サーバ ４…実行制御サーバクラスタ ５，６，７…サービスリクエスタ端末 ８…ネットワーク ９…プロファイルサーバ １０…トラフィック情報管理サーバ １１…トラフィック収集機能部 １２…トラフィック集計機能部 １３…監視実行制御機能部 １４…サービスコンポーネント監視機能部 １５…ユーザ監視機能部 １６…リアクション機能部 ２３…タイマー ２４…サービスコンポーネント利用不能率監視機能部 ２５…応答遅延監視機能部 ２６…レート監視機能部 ２７…エラー率監視機能部 ２８…メッセージサイズ監視機能部
【特許請求の範囲】
【請求項１】
実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するトラフィック収集機能部と、
前記トラフィック収集機能部により受信された前記トラフィック情報を集計するトラフィック集計機能部と、
前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント利用不能率監視機能部と、
前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部と、
前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するサービスコンポーネント閉塞機能部と、
前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するユーザ閉塞機能部と、
を備えることを特徴とするトラフィック情報管理サーバ。
【請求項２】
前記サービスコンポーネント利用不能率監視機能部により抽出されたサービスコンポーネントを閉塞状態にしたことを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第１のアラーム通知機能部と、
前記ユーザ監視機能部により抽出されたユーザを前記特定のサービスコンポーネントに対して一時利用不可能にしたことを当該ユーザの端末に通知する第２のアラーム通知機能部と、
を備えることを特徴とする請求項１に記載のトラフィック情報管理サーバ。
【請求項３】
前記トラフィック情報は、サービスコンポーネントからの応答時間の状況を表す応答時間情報を含み、
前記サービスコンポーネント情報は、サービスコンポーネントへのリクエストを一律に一定の時間遅延させるフロー制御を行うか否かを表すフロー制御フラグを含み、
前記トラフィック集計機能部により集計された前記応答時間情報に基づいて、フロー制御を行うサービスコンポーネントを抽出する応答遅延監視機能部と、
前記応答遅延監視機能部により抽出されたサービスコンポーネントに対応する前記フロー制御フラグの更新要求を外部に送信するフロー規制機能部と、
を備えることを特徴とする請求項１又は２に記載のトラフィック情報管理サーバ。
【請求項４】
前記応答遅延監視機能部により抽出されたサービスコンポーネントへのリクエストを一律に一定の時間遅延させていることを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第３のアラーム通知機能部を備えることを特徴とする請求項３に記載のトラフィック情報管理サーバ。
【請求項５】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数に基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項６】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数と当該リクエストに対するエラーの数とに基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項７】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの平均サイズに基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項８】
トラフィック収集機能部が、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するステップと、
トラフィック集計機能部が、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するステップと、
サービスコンポーネント利用不能率監視機能部が、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するステップと、
ユーザ監視機能部が、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するステップと、
サービスコンポーネント閉塞機能部が、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するステップと、
ユーザ閉塞機能部が、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するステップと、
を有することを特徴とするトラフィック情報管理方法。
【請求項１】
実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するトラフィック収集機能部と、
前記トラフィック収集機能部により受信された前記トラフィック情報を集計するトラフィック集計機能部と、
前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するサービスコンポーネント利用不能率監視機能部と、
前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するユーザ監視機能部と、
前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するサービスコンポーネント閉塞機能部と、
前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するユーザ閉塞機能部と、
を備えることを特徴とするトラフィック情報管理サーバ。
【請求項２】
前記サービスコンポーネント利用不能率監視機能部により抽出されたサービスコンポーネントを閉塞状態にしたことを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第１のアラーム通知機能部と、
前記ユーザ監視機能部により抽出されたユーザを前記特定のサービスコンポーネントに対して一時利用不可能にしたことを当該ユーザの端末に通知する第２のアラーム通知機能部と、
を備えることを特徴とする請求項１に記載のトラフィック情報管理サーバ。
【請求項３】
前記トラフィック情報は、サービスコンポーネントからの応答時間の状況を表す応答時間情報を含み、
前記サービスコンポーネント情報は、サービスコンポーネントへのリクエストを一律に一定の時間遅延させるフロー制御を行うか否かを表すフロー制御フラグを含み、
前記トラフィック集計機能部により集計された前記応答時間情報に基づいて、フロー制御を行うサービスコンポーネントを抽出する応答遅延監視機能部と、
前記応答遅延監視機能部により抽出されたサービスコンポーネントに対応する前記フロー制御フラグの更新要求を外部に送信するフロー規制機能部と、
を備えることを特徴とする請求項１又は２に記載のトラフィック情報管理サーバ。
【請求項４】
前記応答遅延監視機能部により抽出されたサービスコンポーネントへのリクエストを一律に一定の時間遅延させていることを当該サービスコンポーネントを提供するサービスコンポーネントサーバに通知する第３のアラーム通知機能部を備えることを特徴とする請求項３に記載のトラフィック情報管理サーバ。
【請求項５】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数に基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項６】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの数と当該リクエストに対するエラーの数とに基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項７】
前記ユーザ監視機能部は、特定のユーザから前記特定のサービスコンポーネントに送信されたリクエストの平均サイズに基づいて、一時利用不可能にするユーザを抽出することを特徴とする請求項１から４いずれか１項に記載のトラフィック情報管理サーバ。
【請求項８】
トラフィック収集機能部が、実行制御サーバから、ユーザからのサービスコンポーネントへのリクエストの状況を表すユーザ別統計情報と前記サービスコンポーネントのエラー状況を表すサービスコンポーネント別エラー率情報とを含むトラフィック情報を受信するステップと、
トラフィック集計機能部が、前記トラフィック収集機能部により受信された前記トラフィック情報を集計するステップと、
サービスコンポーネント利用不能率監視機能部が、前記トラフィック集計機能部により集計された前記サービスコンポーネント別エラー率情報に基づいて、閉塞状態にするサービスコンポーネントを抽出するステップと、
ユーザ監視機能部が、前記トラフィック集計機能部により集計された前記ユーザ別統計情報に基づいて、特定のサービスコンポーネントに対して一時利用不可能にするユーザを抽出するステップと、
サービスコンポーネント閉塞機能部が、前記サービスコンポーネント利用不能率監視部により抽出された前記サービスコンポーネントに対し、前記サービスコンポーネントが閉塞状態であるか否かを表すサービスコンポーネント閉塞フラグの更新要求を外部に送信するステップと、
ユーザ閉塞機能部が、前記ユーザ監視機能部により抽出されたユーザを、前記特定のサービスコンポーネントに対して一時利用不可能になっているユーザの一覧であるブラックリストに追加する更新要求を外部に送信するステップと、
を有することを特徴とするトラフィック情報管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−１２２９５５（Ｐ２０１０−１２２９５５Ａ）
【公開日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願番号】特願２００８−２９６６８３（Ｐ２００８−２９６６８３）
【出願日】平成２０年１１月２０日（２００８．１１．２０）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願日】平成２０年１１月２０日（２００８．１１．２０）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]