JP2021182314A - 判定方法、および判定プログラム - Google Patents

判定方法、および判定プログラム Download PDF

Info

Publication number
JP2021182314A
JP2021182314A JP2020088069A JP2020088069A JP2021182314A JP 2021182314 A JP2021182314 A JP 2021182314A JP 2020088069 A JP2020088069 A JP 2020088069A JP 2020088069 A JP2020088069 A JP 2020088069A JP 2021182314 A JP2021182314 A JP 2021182314A
Authority
JP
Japan
Prior art keywords
service
usage
resource
usage amount
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2020088069A
Other languages
English (en)
Inventor
裕志 藤田
Hiroshi Fujita
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020088069A priority Critical patent/JP2021182314A/ja
Priority to EP21164860.5A priority patent/EP3913557A1/en
Priority to US17/220,487 priority patent/US20210365350A1/en
Publication of JP2021182314A publication Critical patent/JP2021182314A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G06F11/3075—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved in order to maintain consistency among the monitored data, e.g. ensuring that the monitored data belong to the same timeframe, to the same system or component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06395—Quality analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • Educational Administration (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Software Systems (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computer Hardware Design (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】将来的にサービスの品質が悪化することを把握可能にすること。
【解決手段】サービス品質モデル化部は、範囲１４１１のいくつかのインフラリソースの使用量に基づいて、インフラリソース推定モデルを生成する。サービス品質モデル化部は、範囲１４２１のいくつかのサービスの利用量に基づいて、サービス利用量推定モデルを生成する。サービス品質モデル化部は、サービス品質推定モデルを生成する。サービス品質予測部は、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを用いて、将来的なサービスの品質値を取得する。インフラ制御部は、将来のサービスの品質値に基づいて、アラームを出力する。
【選択図】図１４

Description

本発明は、判定方法、および判定プログラムに関する。
従来、システムに含まれる１以上のリソースを用いてサービスが提供されることがある。ここで、サービスを管理し、サービスの品質が悪化したことを検出するサービス管理者が存在する。また、システムを管理し、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するシステム管理者が存在する。
先行技術としては、例えば、複数のネットワーク機器の負荷と、サービスの品質との対応関係を学習し、学習した対応関係に基づいて、サービスの品質が、所定の制御変更基準値以上となるように、各ネットワーク機器の制御内容を決定するものがある。
特開２０１２−１０００１０号公報
しかしながら、従来技術では、システム管理者は、サービスの品質が悪化した後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。例えば、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。
１つの側面では、本発明は、将来的にサービスの品質が悪化することを把握可能にすることを目的とする。
１つの実施態様によれば、１以上の時点における所定のサービスに関わるリソースの使用量を取得し、１以上の時点における前記サービスの利用量を取得し、少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、入力された１以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第１のモデルを用いて、取得した１以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、入力された１以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第２のモデルを用いて、取得した１以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する判定方法、および判定プログラムが提案される。
一態様によれば、将来的にサービスの品質が悪化することを把握可能にすることが可能になる。
図１は、実施の形態にかかる判定方法の一実施例を示す説明図である。 図２は、業務処理システム２００の一例を示す説明図である。 図３は、判定装置１００のハードウェア構成例を示すブロック図である。 図４は、稼働テーブル４００の記憶内容の一例を示す説明図である。 図５は、日単位テーブル５００の記憶内容の一例を示す説明図である。 図６は、ベクトルテーブル６００の記憶内容の一例を示す説明図である。 図７は、成分テーブル７００の記憶内容の一例を示す説明図である。 図８は、重みテーブル８００の記憶内容の一例を示す説明図である。 図９は、サービス利用量テーブル９００の記憶内容の一例を示す説明図である。 図１０は、サービス品質テーブル１０００の記憶内容の一例を示す説明図である。 図１１は、管理者側装置２０２のハードウェア構成例を示すブロック図である。 図１２は、判定装置１００の機能的構成例を示すブロック図である。 図１３は、判定装置１００の具体的な機能的構成例を示すブロック図である。 図１４は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その１）である。 図１５は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その２）である。 図１６は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その３）である。 図１７は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その４）である。 図１８は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その５）である。 図１９は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その６）である。 図２０は、判定装置１００がアラームの出力要否を判定する一例を示す説明図（その７）である。 図２１は、判定装置１００が重み係数を算出する一例を示す説明図（その１）である。 図２２は、判定装置１００が重み係数を算出する一例を示す説明図（その２）である。 図２３は、判定装置１００が重み係数を算出する一例を示す説明図（その３）である。 図２４は、判定装置１００が重み係数を算出する一例を示す説明図（その４）である。 図２５は、判定装置１００が重み係数を算出する一例を示す説明図（その５）である。 図２６は、全体処理手順の一例を示すフローチャートである。 図２７は、モデル生成処理手順の一例を示すフローチャートである。 図２８は、解析処理手順の一例を示すフローチャートである。
以下に、図面を参照して、本発明にかかる判定方法、および判定プログラムの実施の形態を詳細に説明する。
（実施の形態にかかる判定方法の一実施例）
図１は、実施の形態にかかる判定方法の一実施例を示す説明図である。判定装置１００は、将来的にサービスの品質が悪化することを把握可能にするためのコンピュータである。サービスは、例えば、１以上の機器によって形成される所定の業務処理システムに含まれる１以上のリソースを利用して提供される。サービスは、複数存在してもよい。
ここで、業務処理システムは、例えば、ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システムである。機器は、例えば、ＩＣＴ機器である。機器は、具体的には、サーバである。リソースは、例えば、ＣＰＵ、メモリ、および、通信帯域などである。サービスは、例えば、１以上の機器における１以上のプロセスの実行によって実現される。
業務処理システムに対して、サービスを管理し、サービスの品質が悪化したことを検出するサービス管理者が存在する。また、業務処理システムに対して、業務処理システムを管理し、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するシステム管理者が存在する。サービス管理者と、システム管理者とは、同一の者であってもよいし、異なる者であってもよい。
しかしながら、従来では、システム管理者は、サービスの品質が悪化した後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。このため、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の増大化を招き、サービスの利便性の低下を招くことになるという問題がある。また、サービス管理者は、サービスの品質が悪化したことに関し、サービス利用者に応対する作業を実施することがあり、サービス管理者にかかる作業負担の増大化を招くことになるという問題がある。
具体的には、システム管理者が、サービス管理者とは異なる者である場合、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、いずれかのリソースに対処するという作業を開始するきっかけを得ることができない。このため、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するという作業を開始することができない。
また、システム管理者が、サービスの品質が悪化した原因であるリソースを特定するにあたり、サービスの稼働状況のデータと、リソースの使用状況のデータとを照合することが考えられる。システム管理者は、例えば、サービス管理者から、サービスの稼働状況のデータを取得する。そして、システム管理者は、例えば、サービスの稼働状況のデータと、リソースの使用状況のデータとを照合し、サービスごとのリソースの使用状況を特定し、サービスの品質が悪化した原因であるリソースを特定することになる。このため、システム管理者にかかる作業負担の増大化を招くという問題がある。
従って、システム管理者が、将来的にサービスの品質が悪化し得ることを把握可能にすれば、サービスの利便性の低下を抑制し、サービス管理者にかかる作業負担の増加を抑制し、システム管理者にかかる作業負担の増加を抑制することができると考えられる。
そこで、本実施の形態では、将来的にサービスの品質が悪化することを把握可能にすることができる判定方法について説明する。
図１の例では、判定装置１００は、第１のモデル１０１を有する。第１のモデル１０１は、入力された１以上の時点におけるリソースの使用量から予測される将来のいずれかの時点におけるリソースの使用量を出力するモデルである。リソースの使用量は、例えば、物理マシンのＣＰＵ使用率、物理マシンの空きメモリ量、物理マシンのネットワーク速度、仮想マシンのＣＰＵ使用率、仮想マシンの空きメモリ量、仮想マシンのネットワーク速度などの少なくともいずれかである。
また、図１の例では、判定装置１００は、第２のモデル１０２を有する。第２のモデル１０２は、入力された１以上の時点におけるサービスの利用量から予測される将来のいずれかの時点におけるサービスの利用量を出力するモデルである。サービスの利用量は、例えば、単位時間あたりのサービスの稼働率である。サービスの利用量は、具体的には、単位時間あたりのサービスへのアクセス回数である。
（１−１）判定装置１００は、１以上の時点におけるサービスに関わるリソースの使用量を取得する。サービスに関わるリソースは、例えば、サービスを実現する際に利用されるリソースである。
（１−２）判定装置１００は、１以上の時点におけるサービスの利用量を取得する。取得したサービスの利用量に係る時点は、例えば、取得したリソースの使用量に係る時点と同一の時点であってもよい。サービスの利用量に係る時点は、いつのサービスの利用量であるかを示す。サービスの利用量に係る時点は、例えば、サービスの利用量を取得した時点、または、サービスの利用量を計測した時点である。リソースの使用量に係る時点は、いつのリソースの使用量であるかを示す。リソースの使用量に係る時点は、例えば、リソースの使用量を取得した時点、または、リソースの使用量を計測した時点である。また、取得したサービスの利用量に係る時点は、例えば、取得したリソースの使用量に係る時点とは異なる時点であってもよい。
（１−３）判定装置１００は、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。サービスの品質値は、例えば、品質が良いほど、値が大きくなる指標値である。サービスの品質値は、例えば、リクエストへの遅延時間、単位時間あたりのスループット、単位時間当たりのパケットロス率などに基づいて算出される。サービスの品質値は、具体的には、リクエストへの遅延時間が小さいほど、値が大きくなるよう算出される。
リソースの使用量とサービスの利用量とに対応付けられた、取得したサービスの品質値に係る時点は、例えば、取得したリソースの使用量に係る時点、または、取得したサービスの利用量に係る時点と同一の時点であってもよい。サービスの品質値に係る時点は、いつのサービスの品質値であるかを示す。サービスの品質値に係る時点は、例えば、サービスの品質値を取得した時点、または、サービスの品質値を計測した時点である。また、リソースの使用量とサービスの利用量とに対応付けられた、取得したサービスの品質値に係る時点は、例えば、取得したリソースの使用量に係る時点、または、取得したサービスの利用量に係る時点とは異なる時点であってもよい。
（１−４）判定装置１００は、第１のモデル１０１を用いて、取得した１以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定する。判定装置１００は、例えば、第１のモデル１０１に、取得した１以上の時点におけるリソースの使用量を入力することにより、将来のいずれかの時点におけるリソースの使用量を特定する。
（１−５）判定装置１００は、第２のモデル１０２を用いて、取得した１以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定する。判定装置１００は、例えば、第２のモデル１０２に、取得した１以上の時点におけるサービスの利用量を入力することにより、将来のいずれかの時点におけるサービスの利用量を特定する。
特定したサービスの利用量に係る時点は、例えば、特定したリソースの使用量に係る時点と同一の時点であってもよい。特定したサービスの利用量に係る時点は、例えば、特定したリソースの使用量に係る時点とは異なるが、特定したリソースの使用量に係る時点と対応する時点であってもよい。ある時点に対応する時点とは、例えば、当該時点との差分が一定時間以下である時点である。
（１−６）判定装置１００は、取得したサービスの品質値と特定したリソースの使用量と特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定する。判定装置１００は、例えば、取得したサービスの品質値のうち、特定したリソースの使用量に類似する使用量と、特定したサービスの利用量に類似する利用量との組み合わせに対応付けられた品質値があれば、将来のいずれかの時点における品質値として特定する。
そして、判定装置１００は、例えば、特定した品質値が閾値未満であり、サービスの品質が一定未満であると判断されれば、サービスに関するアラームを出力すると判定する。一方で、判定装置１００は、例えば、特定した品質値が閾値以上であり、サービスの品質が一定以上であると判断されれば、サービスに関するアラームを出力しないと判定する。
これにより、判定装置１００は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。このため、システム管理者は、サービスの品質が悪化する前に、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処する作業を開始することができる。
結果として、システム管理者は、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の低減化を図ることができる。また、システム管理者は、サービスの品質が悪化することを防止することができる場合がある。そして、システム管理者は、サービスの利便性の低下を防止または抑制することができる。また、システム管理者は、サービス管理者にかかる作業負担の低減化を図ることができる。また、判定装置１００は、システム管理者にかかる作業負担の低減化を図ることができる。
（業務処理システム２００の一例）
次に、図２を用いて、図１に示した判定装置１００を適用した、業務処理システム２００の一例について説明する。
図２は、業務処理システム２００の一例を示す説明図である。図２において、業務処理システム２００は、判定装置１００と、１以上の業務処理装置２０１と、１以上の管理者側装置２０２とを含む。
業務処理システム２００において、判定装置１００と業務処理装置２０１とは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、および、インターネットなどである。また、業務処理システム２００において、判定装置１００と管理者側装置２０２とは、有線または無線のネットワーク２１０を介して接続される。
判定装置１００は、将来的にサービスの品質が悪化することを把握可能に出力する。判定装置１００は、例えば、将来的にサービスの品質が悪化すると判断される場合、サービスに関わるアラームを出力する。出力先は、例えば、管理者側装置２０２である。
判定装置１００は、具体的には、図４〜図１０に後述する各種テーブルを有する。判定装置１００は、具体的には、業務処理装置２０１と通信し、全体の稼働データを取得する。判定装置１００は、より具体的には、所定のタイミングで、業務処理装置２０１が有するリソースの使用状況を表す指標値を収集し、収集した指標値を纏めた全体の稼働データを生成する。指標値は、例えば、リソースの使用量である。全体の稼働データは、例えば、図４に後述する稼働テーブル４００を用いて記憶される。
判定装置１００は、具体的には、全体の稼働データを所定の時間間隔ごとに分割する。所定の時間間隔は、例えば、１日である。１日ごとに分割された日単位稼働データは、例えば、図５に後述する日単位テーブル５００を用いて記憶される。判定装置１００は、具体的には、１日ごとに分割された日単位稼働データをベクトル化し、１日ごとのベクトルを生成する。各日のベクトルは、例えば、図６に後述するベクトルテーブル６００を用いて記憶される。
判定装置１００は、具体的には、各日のベクトルを列として含む稼働データ行列を生成する。判定装置１００は、具体的には、基底数に基づいて、生成した稼働データ行列に対して非負値行列因子分解を実施し、基底行列および重み行列を生成する。基底行列は、例えば、図７に後述する成分テーブル７００を用いて記憶される。重み行列は、例えば、図８に後述する重みテーブル８００を用いて記憶される。重み行列を形成する重み係数は、サービスの利用状況を示す指標値に対応する。非負値行列因子分解については、例えば、下記参考文献１を参照することができる。
参考文献１ ： Ｈｏｙｅｒ， Ｐａｔｒｉｋ Ｏ． “Ｎｏｎ−ｎｅｇａｔｉｖｅ ｍａｔｒｉｘ ｆａｃｔｏｒｉｚａｔｉｏｎ ｗｉｔｈ ｓｐａｒｓｅｎｅｓｓ ｃｏｎｓｔｒａｉｎｔｓ．” Ｊｏｕｒｎａｌ ｏｆ ｍａｃｈｉｎｅ ｌｅａｒｎｉｎｇ ｒｅｓｅａｒｃｈ ５．Ｎｏｖ （２００４）： １４５７−１４６９．
判定装置１００は、具体的には、業務処理装置２０１と通信し、サービス単位の利用状況を示す指標値を収集してもよい。指標値は、例えば、サービスの利用量である。サービス単位の利用状況を示す指標値は、例えば、図９に後述するサービス利用量テーブル９００を用いて記憶される。判定装置１００は、具体的には、業務処理装置２０１と通信し、サービス単位の品質を示す指標値を収集する。指標値は、例えば、サービスの品質値である。サービス単位の品質を示す指標値は、例えば、図１０に後述するサービス品質テーブル１０００を用いて記憶される。
判定装置１００は、具体的には、図８に後述する重みテーブル８００と、図９に後述するサービス利用量テーブル９００と、図１０に後述するサービス品質テーブル１０００とに基づいて、将来的なサービスの品質値を推定する。判定装置１００は、具体的には、図４に後述する稼働テーブル４００と、図９に後述するサービス利用量テーブル９００と、図１０に後述するサービス品質テーブル１０００とに基づいて、将来的なサービスの品質値を推定してもよい。
判定装置１００は、具体的には、将来的なサービスの品質値が閾値未満になる期間があるか否かを判定する。判定装置１００は、具体的には、将来的なサービスの品質値が閾値未満になる期間があれば、将来的にサービスの品質が悪化すると判断し、サービスに関わるアラームを出力する。判定装置１００は、例えば、サーバ、または、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。
業務処理装置２０１は、業務処理を実行し、サービスを実現するためのコンピュータである。例えば、業務処理装置２０１を集めたサービス実行基盤２２０により、サービスを形成する業務処理が分担されることにより、サービスが実現される。業務処理装置２０１は、例えば、サービスを形成する１以上のプロセスのいずれかを実行する。また、業務処理装置２０１は、１以上のリソースを有し、それぞれのリソースの使用状況を表す指標値を定期的に計測して記憶し、判定装置１００に送信する。また、業務処理装置２０１は、サービスの利用状況を表す指標値を定期的に計測して記憶し、判定装置１００に送信する。業務処理装置２０１は、例えば、サーバ、または、ＰＣなどである。
管理者側装置２０２は、システム管理者によって用いられるコンピュータである。管理者側装置２０２は、サービスに関するアラームを、判定装置１００から受信する。管理者側装置２０２は、受信したアラームを出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、外部装置への送信、または、記憶領域への記憶などである。管理者側装置２０２は、例えば、ＰＣ、タブレット端末、または、スマートフォンなどである。
ここでは、業務処理システム２００が、判定装置１００を１つ含む場合について説明したが、これに限らない。例えば、業務処理システム２００が、判定装置１００を複数含む場合があってもよい。そして、複数の判定装置１００が協働して、上述した処理を実現する場合があってもよい。
また、ここでは、判定装置１００が、業務処理装置２０１とは異なる装置である場合について説明したが、これに限らない。例えば、判定装置１００が、いずれかの業務処理装置２０１と一体である場合があってもよい。また、ここでは、判定装置１００が、管理者側装置２０２とは異なる装置である場合について説明したが、これに限らない。例えば、判定装置１００が、管理者側装置２０２と一体である場合があってもよい。
（判定装置１００のハードウェア構成例）
次に、図３を用いて、判定装置１００のハードウェア構成例について説明する。
図３は、判定装置１００のハードウェア構成例を示すブロック図である。図３において、判定装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、記録媒体Ｉ／Ｆ３０４と、記録媒体３０５とを有する。また、各構成部は、バス３００によってそれぞれ接続される。
ここで、ＣＰＵ３０１は、判定装置１００の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。
ネットワークＩ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ３０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ３０３は、例えば、モデムやＬＡＮアダプタなどである。
記録媒体Ｉ／Ｆ３０４は、ＣＰＵ３０１の制御に従って記録媒体３０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ３０４は、例えば、ディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポートなどである。記録媒体３０５は、記録媒体Ｉ／Ｆ３０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体３０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体３０５は、判定装置１００から着脱可能であってもよい。
判定装置１００は、上述した構成部の他、例えば、キーボード、マウス、ディスプレイ、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、判定装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を複数有していてもよい。また、判定装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を有していなくてもよい。
（稼働テーブル４００の記憶内容）
次に、図４を用いて、稼働テーブル４００の記憶内容の一例について説明する。稼働テーブル４００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図４は、稼働テーブル４００の記憶内容の一例を示す説明図である。図４に示すように、稼働テーブル４００は、サーバ名と、日付時刻と、１以上のリソースとのフィールドを有する。稼働テーブル４００は、各フィールドに情報を設定することにより、レコード４００−ａが記憶される。ａは、任意の整数である。
サーバ名のフィールドには、業務処理装置２０１を識別する識別情報としてサーバ名が設定される。日付時刻のフィールドには、業務処理装置２０１でリソースの使用状況を表す指標値が計測された日付と時刻との組み合わせが設定される。リソースのフィールドには、リソースの使用状況を表す指標値が設定される。指標値は、例えば、リソースの使用量である。
リソースのフィールドは、例えば、ＣＰＵ使用率［％］のフィールドと、ディスクＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）［ＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）］のフィールドとなどである。ＣＰＵ使用率［％］のフィールドには、業務処理装置２０１でのＣＰＵ１１０１（図１１に後述）の使用状況を表す指標値であるＣＰＵ使用率［％］が設定される。ディスクＩＯ［ＩＯＰＳ］のフィールドには、業務処理装置２０１での記録媒体１１０５（図１１に後述）の使用状況を表す指標値であるディスクＩＯ［ＩＯＰＳ］が設定される。
（日単位テーブル５００の記憶内容）
次に、図５を用いて、日単位テーブル５００の記憶内容の一例について説明する。日単位テーブル５００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図５は、日単位テーブル５００の記憶内容の一例を示す説明図である。図５に示すように、日単位テーブル５００は、サーバ名と、日付時刻と、１以上のリソースとのフィールドを有する。日単位テーブル５００は、各フィールドに情報を設定することにより、レコード５００−ｂが記憶される。ｂは、任意の整数である。
日単位テーブル５００のレコードは、図４に示した稼働テーブル４００のレコードから抽出された、１日分のレコードである。このため、日単位テーブル５００のそれぞれのフィールドには、図４に示した稼働テーブル４００のそれぞれのフィールドと同様の情報が設定される。また、日単位テーブル５００の日付時刻のフィールドには、同日の日付と時刻との組み合わせが設定される。
（ベクトルテーブル６００の記憶内容）
次に、図６を用いて、ベクトルテーブル６００の記憶内容の一例について説明する。ベクトルテーブル６００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図６は、ベクトルテーブル６００の記憶内容の一例を示す説明図である。図６に示すように、ベクトルテーブル６００は、日ごとの稼働データのフィールドを有する。ベクトルテーブル６００は、各フィールドに情報を設定することにより、レコード６００−ｃが記憶される。ｃは、任意の整数である。
日ごとの稼働データのフィールドには、全体の稼働データから日ごとに分割された日単位稼働データをベクトル化して得られたベクトルの要素が設定される。日単位稼働データをベクトル化して得られたベクトルの要素は、日単位稼働データが示す１以上のリソースのそれぞれの使用状況を表す１または複数の指標値のそれぞれである。
（成分テーブル７００の記憶内容）
次に、図７を用いて、成分テーブル７００の記憶内容の一例について説明する。成分テーブル７００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図７は、成分テーブル７００の記憶内容の一例を示す説明図である。図７に示すように、成分テーブル７００は、１以上の成分のフィールドを有する。成分テーブル７００は、各フィールドに情報を設定することにより、レコード７００−ｄが記憶される。ｄは、任意の整数である。
成分のフィールドには、稼働データ行列に対して非負値行列因子分解を実施して得られた基底行列に含まれる基底ベクトルが示すリソースごとの成分データが設定される。成分データは、リソースに関する成分値の集合である。成分のフィールドには、例えば、稼働データ行列に対して非負値行列因子分解を実施して得られた基底行列に含まれる基底ベクトルが示す１または複数の成分値のそれぞれが設定される。
（重みテーブル８００の記憶内容）
次に、図８を用いて、重みテーブル８００の記憶内容の一例について説明する。重みテーブル８００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図８は、重みテーブル８００の記憶内容の一例を示す説明図である。図８に示すように、重みテーブル８００は、成分ＩＤと、日付と、重み係数とのフィールドを有する。重みテーブル８００は、各フィールドに情報を設定することにより、レコード８００−ｅが記憶される。ｅは、任意の整数である。
成分ＩＤのフィールドには、稼働データ行列に対して非負値行列因子分解を実施して得られた重み行列に含まれる重みベクトルの要素である重み係数の係り先である、リソースごとの成分データを示す基底ベクトルを識別するための成分ＩＤが設定される。成分データは、リソースに関する成分値の集合である。成分ＩＤは、基底ベクトルが示すリソースごとの成分データが設定された成分テーブル７００の成分フィールドの列番号である。
日付のフィールドには、重みベクトルの要素である重み係数が示す重みが、いつのサービスの利用量に対応するかを識別するための日付が設定される。重み係数のフィールドには、重みベクトルの要素である重み係数が設定される。重み係数は、サービスの重みとして、サービスの利用量に対応する係数を示す。
（サービス利用量テーブル９００の記憶内容）
次に、図９を用いて、サービス利用量テーブル９００の記憶内容の一例について説明する。サービス利用量テーブル９００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図９は、サービス利用量テーブル９００の記憶内容の一例を示す説明図である。図９に示すように、サービス利用量テーブル９００は、サービス名と、日付時刻と、サービス利用量とのフィールドを有する。サービス利用量テーブル９００は、各フィールドに情報を設定することにより、レコード９００−ｆが記憶される。ｆは、任意の整数である。
サービス名のフィールドには、サービスを識別する識別情報としてサービス名が設定される。日付時刻のフィールドには、サービスの利用状況を表す指標値が計測された日付と時刻との組み合わせが設定される。サービス利用量のフィールドには、サービスの利用状況を表す指標値が設定される。指標値は、例えば、サービスの利用量である。
（サービス品質テーブル１０００の記憶内容）
次に、図１０を用いて、サービス品質テーブル１０００の記憶内容の一例について説明する。サービス品質テーブル１０００は、例えば、図３に示した判定装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。
図１０は、サービス品質テーブル１０００の記憶内容の一例を示す説明図である。図１０に示すように、サービス品質テーブル１０００は、サービス名と、日付時刻と、サービス品質とのフィールドを有する。サービス品質テーブル１０００は、各フィールドに情報を設定することにより、レコード１０００−ｇが記憶される。ｇは、任意の整数である。
サービス名のフィールドには、サービスを識別する識別情報としてサービス名が設定される。日付時刻のフィールドには、サービスの品質を表す指標値が計測された日付と時刻との組み合わせが設定される。サービス品質のフィールドには、サービスの品質を表す指標値が設定される。指標値は、例えば、リクエスト応答時間［ｍｓ］が小さいほど、値が大きくなり、サービスの良さを示す値である。
（業務処理装置２０１のハードウェア構成例）
業務処理装置２０１のハードウェア構成例は、図３に示した、判定装置１００のハードウェア構成例と同様であるため、説明を省略する。
（管理者側装置２０２のハードウェア構成例）
次に、図１１を用いて、図２に示した業務処理システム２００に含まれる管理者側装置２０２のハードウェア構成例について説明する。
図１１は、管理者側装置２０２のハードウェア構成例を示すブロック図である。図１１において、管理者側装置２０２は、ＣＰＵ１１０１と、メモリ１１０２と、ネットワークＩ／Ｆ１１０３と、記録媒体Ｉ／Ｆ１１０４と、記録媒体１１０５と、ディスプレイ１１０６と、入力装置１１０７とを有する。また、各構成部は、バス１１００によってそれぞれ接続される。
ここで、ＣＰＵ１１０１は、管理者側装置２０２の全体の制御を司る。メモリ１１０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ１１０１のワークエリアとして使用される。メモリ１１０２に記憶されるプログラムは、ＣＰＵ１１０１にロードされることで、コーディングされている処理をＣＰＵ１１０１に実行させる。
ネットワークＩ／Ｆ１１０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ１１０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ１１０３は、例えば、モデムやＬＡＮアダプタなどである。
記録媒体Ｉ／Ｆ１１０４は、ＣＰＵ１１０１の制御に従って記録媒体１１０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ１１０４は、例えば、ディスクドライブ、ＳＳＤ、ＵＳＢポートなどである。記録媒体１１０５は、記録媒体Ｉ／Ｆ１１０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体１１０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体１１０５は、管理者側装置２０２から着脱可能であってもよい。
ディスプレイ１１０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ１１０６は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。入力装置１１０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置１１０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。
管理者側装置２０２は、上述した構成部の他、例えば、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、管理者側装置２０２は、記録媒体Ｉ／Ｆ１１０４や記録媒体１１０５を複数有していてもよい。また、管理者側装置２０２は、記録媒体Ｉ／Ｆ１１０４や記録媒体１１０５を有していなくてもよい。
（判定装置１００の機能的構成例）
次に、図１２を用いて、判定装置１００の機能的構成例について説明する。
図１２は、判定装置１００の機能的構成例を示すブロック図である。判定装置１００は、記憶部１２００と、取得部１２０１と、生成部１２０２と、第１の特定部１２０３と、第２の特定部１２０４と、判定部１２０５と、出力部１２０６とを含む。
記憶部１２００は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域によって実現される。以下では、記憶部１２００が、判定装置１００に含まれる場合について説明するが、これに限らない。例えば、記憶部１２００が、判定装置１００とは異なる装置に含まれ、記憶部１２００の記憶内容が判定装置１００から参照可能である場合があってもよい。
取得部１２０１〜出力部１２０６は、制御部の一例として機能する。取得部１２０１〜出力部１２０６は、具体的には、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、ネットワークＩ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶される。
記憶部１２００は、各機能部の処理において参照され、または更新される各種情報を記憶する。記憶部１２００は、少なくともいずれかの時点における、サービスに関わるリソースの使用量を記憶する。リソースの使用量は、ＣＰＵの使用量、メモリの使用量、または、通信帯域の使用量である。記憶部１２００は、具体的には、図４に示した稼働テーブル４００を記憶する。
記憶部１２００は、少なくともいずれかの時点における、サービスの利用量を記憶する。サービスの利用量は、サービスのアクセス数である。記憶部１２００は、具体的には、図９に示したサービス利用量テーブル９００を記憶する。記憶部１２００は、少なくともいずれかの時点における、サービスの品質値を記憶する。サービスの品質値は、リクエストに対するサービスの応答時間である。記憶部１２００は、具体的には、図１０に示したサービス品質テーブル１０００を記憶する。
記憶部１２００は、第１のモデルを記憶する。第１のモデルは、入力された１以上の時点におけるリソースの使用量から予測される将来のいずれかの時点におけるリソースの使用量を出力するモデルである。第１のモデルは、例えば、生成部１２０２によって生成される。第１のモデルは、例えば、取得部１２０１によって取得されてもよい。
記憶部１２００は、第２のモデルを記憶する。第２のモデルは、入力された１以上の時点におけるサービスの利用量から予測される将来のいずれかの時点におけるサービスの利用量を出力するモデルである。第２のモデルは、例えば、生成部１２０２によって生成される。第２のモデルは、例えば、取得部１２０１によって取得されてもよい。
記憶部１２００は、第３のモデルを記憶する。第３のモデルは、入力されたリソースの使用量とサービスの利用量とに対応するサービスの品質値を出力するモデルである。第３のモデルは、例えば、生成部１２０２によって生成される。第３のモデルは、例えば、取得部１２０１によって取得されてもよい。
取得部１２０１は、各機能部の処理に用いられる各種情報を取得する。取得部１２０１は、取得した各種情報を、記憶部１２００に記憶し、または、各機能部に出力する。また、取得部１２０１は、記憶部１２００に記憶しておいた各種情報を、各機能部に出力してもよい。取得部１２０１は、例えば、利用者の操作入力に基づき、各種情報を取得する。取得部１２０１は、例えば、判定装置１００とは異なる装置から、各種情報を受信してもよい。
取得部１２０１は、いずれかの機能部の処理を開始する開始トリガーを受け付けてもよい。開始トリガーは、例えば、利用者による所定の操作入力があったことである。開始トリガーは、例えば、他のコンピュータから、所定の情報を受信したことであってもよい。開始トリガーは、例えば、いずれかの機能部が所定の情報を出力したことであってもよい。
取得部１２０１は、リソースの使用量と、サービスの利用量と、サービスの品質値とを取得したことを、生成部１２０２の処理を開始する開始トリガーとして受け付けてもよい。取得部１２０１は、リソースの使用量と、サービスの利用量と、サービスの品質値とを取得したことを、第１の特定部１２０３と、第２の特定部１２０４と、判定部１２０５との処理を開始する開始トリガーとして受け付けてもよい。
取得部１２０１は、サービスに関わるリソースの使用量を取得する。取得部１２０１は、例えば、生成部１２０２によって用いられる、複数の時点におけるリソースの使用量を取得する。取得部１２０１は、具体的には、複数の時点におけるリソースの使用量を、業務処理装置２０１から収集することにより取得する。
取得部１２０１は、例えば、第１の特定部１２０３によって用いられる、１以上の時点におけるリソースの使用量を取得する。取得部１２０１は、具体的には、１以上の時点におけるリソースの使用量を、業務処理装置２０１から収集することにより取得する。生成部１２０２によって用いられる、複数の時点におけるリソースの使用量が、第１の特定部１２０３によって用いられる、１以上の時点におけるリソースの使用量を包含していてもよい。
取得部１２０１は、サービスの利用量を取得する。取得部１２０１は、例えば、生成部１２０２によって用いられる、複数の時点におけるサービスの利用量を取得する。取得部１２０１は、具体的には、複数の時点におけるサービスの利用量を、業務処理装置２０１から収集することにより取得する。
取得部１２０１は、例えば、第１の特定部１２０３によって用いられる、１以上の時点におけるサービスの利用量を取得する。生成部１２０２によって用いられる、複数の時点におけるサービスの利用量が、第１の特定部１２０３によって用いられる、１以上の時点におけるサービスの利用量を包含していてもよい。取得部１２０１は、具体的には、リソースの使用量を解析した結果得られるサービスの利用量を取得してもよい。解析する手法の具体例については、例えば、図２１〜図２５を用いて後述する。
取得部１２０１は、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。取得部１２０１は、例えば、生成部１２０２、第２の特定部１２０４、または、判定部１２０５によって用いられる、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。取得部１２０１は、具体的には、過去のいずれかの時点における、特定したリソースの使用量に類似するリソースの使用量と、特定したサービスの利用量に類似するサービスの利用量とに対応付けられた、サービスの品質値を取得する。
取得部１２０１は、第１のモデルを取得してもよい。取得部１２０１は、例えば、利用者の操作入力に基づき、第１のモデルを取得する。取得部１２０１は、第２のモデルを取得してもよい。取得部１２０１は、例えば、利用者の操作入力に基づき、第２のモデルを取得する。取得部１２０１は、第３のモデルを取得してもよい。取得部１２０１は、例えば、利用者の操作入力に基づき、第３のモデルを取得する。
生成部１２０２は、取得した複数の時点におけるリソースの使用量に基づいて、第１のモデルを生成する。生成部１２０２は、例えば、取得した複数の時点におけるリソースの使用量に基づいて、自己回帰モデル（例えば、ＡＲ，ＡＲＭＡ，ＡＲＩＭＡ，ＳＡＲＩＭＡなど）を用いて、第１のモデルを生成する。第１のモデルを生成する具体例については、例えば、図１４〜図１７を用いて後述する。
生成部１２０２は、取得した複数の時点におけるサービスの利用量に基づいて、第２のモデルを生成する。生成部１２０２は、例えば、取得した複数の時点におけるリソースの使用量に基づいて、自己回帰モデル（例えば、ＡＲ，ＡＲＭＡ，ＡＲＩＭＡ，ＳＡＲＩＭＡなど）を用いて、第２のモデルを生成する。第２のモデルを生成する具体例については、例えば、図１４〜図１７を用いて後述する。
生成部１２０２は、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、第３のモデルを生成する。生成部１２０２は、例えば、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、ベクトル自己回帰モデル（例えば、ＶＡＲ）を用いて、第３のモデルを生成する。第３のモデルを生成する具体例については、例えば、図１４〜図１７を用いて後述する。
第１の特定部１２０３は、第１のモデルを用いて、取得した１以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定する。第１の特定部１２０３は、第１のモデルに、取得した１以上の時点におけるリソースの使用量を入力することにより、将来のいずれかの時点におけるリソースの使用量を特定する。
第１の特定部１２０３は、第２のモデルを用いて、取得した１以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定する。第１の特定部１２０３は、例えば、第２のモデルに、取得した１以上の時点におけるサービスの利用量を入力することにより、将来のいずれかの時点におけるサービスの利用量を特定する。
第２の特定部１２０４は、第３のモデルを用いて、特定したリソースの使用量と特定したサービスの利用量とから予測される、サービスの品質値を特定する。第２の特定部１２０４は、例えば、第３のモデルに、特定したリソースの使用量と特定したサービスの利用量とを入力することにより、サービスの品質値を特定する。これにより、第２の特定部１２０４は、将来のいずれかの時点におけるサービスの品質値を特定することができる。
判定部１２０５は、取得したサービスの品質値と、特定したリソースの使用量と、特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定する。判定部１２０５は、例えば、取得したサービスの品質値のうち、特定したリソースの使用量に類似する使用量と、特定したサービスの利用量に類似する利用量とに対応付けられた品質値があれば、当該品質値を取得する。類似とは、値が近いことである。類似とは、例えば、値の差分が閾値以下であることである。
そして、判定部１２０５は、例えば、取得した品質値が閾値未満である場合、サービスに関するアラームを出力すると判定する。アラームは、例えば、サービスの品質値が小さくなる原因を示す情報を含む。一方で、判定部１２０５は、例えば、取得した品質値が閾値以上である場合、サービスに関するアラームを出力しないと判定する。
判定部１２０５は、第２の特定部１２０４が特定したサービスの品質値に基づいて、サービスに関するアラームを出力するか否かを判定する。判定部１２０５は、例えば、第２の特定部１２０４が特定したサービスの品質値が閾値未満である場合、サービスに関するアラームを出力すると判定する。アラームは、例えば、サービスの品質値が小さくなる原因を示す情報を含む。一方で、判定部１２０５は、例えば、第２の特定部１２０４が特定したサービスの品質値が閾値以上である場合、サービスに関するアラームを出力しないと判定する。
出力部１２０６は、いずれかの機能部の処理結果を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークＩ／Ｆ３０３による外部装置への送信、または、メモリ３０２や記録媒体３０５などの記憶領域への記憶である。これにより、出力部１２０６は、いずれかの機能部の処理結果を利用者に通知可能にし、判定装置１００の利便性の向上を図ることができる。
出力部１２０６は、アラームを出力すると判定した場合、アラームを出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークＩ／Ｆ３０３による外部装置への送信、または、メモリ３０２や記録媒体３０５などの記憶領域への記憶である。出力部１２０６は、例えば、アラームを、管理者側装置２０２に送信する。これにより、出力部１２０６は、システム管理者が、アラームを把握可能にし、将来的にサービスの品質が悪化するおそれがあることを把握可能にすることができる。
（判定装置１００の具体的な機能的構成例）
次に、図１３を用いて、判定装置１００の具体的な機能的構成例について説明する。
図１３は、判定装置１００の具体的な機能的構成例を示すブロック図である。判定装置１００は、業務処理装置２０１により形成される、仮想環境および物理環境を監視している。仮想環境および物理環境において、サービスが実現されている。
判定装置１００は、サービス判定部１３０１と、サービス性能監視部１３０２と、インフラ監視部１３０３と、サービス品質モデル化部１３０４と、サービス品質予測部１３０５と、インフラ制御部１３０６とを含む。
サービス判定部１３０１は、図１４に後述するように、業務処理装置２０１と通信し、サービスの利用量を取得する。サービス判定部１３０１は、例えば、稼働中のサービスを判定し、稼働中のサービスの利用量を取得する。利用量は、例えば、単位時間あたりのサービス稼働率である。サービス判定部１３０１は、図２１〜図２５に後述するように、稼働中のサービスの利用量として、重み係数を算出する場合があってもよい。
サービス性能監視部１３０２は、図１４に後述するように、業務処理装置２０１と通信し、サービスの品質値を取得する。サービス性能監視部１３０２は、具体的には、サービスが、ｗｅｂサービスであれば、サービスの品質値として、リクエストへの遅延時間に基づく、サービスの良さを示す指標値を取得する。サービス性能監視部１３０２は、具体的には、サービスが、ファイルサーバサービスであれば、サービスの品質値として、スループットに基づく、サービスの良さを示す指標値を取得する。サービス性能監視部１３０２は、具体的には、サービスが、ファイルサーバサービスであれば、サービスの品質値として、パケットロス率に基づく、サービスの良さを示す指標値を取得する。
インフラ監視部１３０３は、図１４に後述するように、業務処理装置２０１と通信し、インフラリソースの使用量を取得する。サービス品質モデル化部１３０４は、図１４〜図１７に後述するように、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを生成する。サービス品質予測部１３０５は、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを用いて、将来的なサービスの品質値を取得する。
インフラ制御部１３０６は、将来のサービスの品質値に基づいて、アラームを出力する。この際、インフラ制御部１３０６は、将来のサービスの品質値の低下の原因と判断されるインフラリソースを特定し、特定したインフラリソースに関する情報を、アラームに含めてもよい。インフラ制御部１３０６は、例えば、ＪＩＴモデリングを用いて、将来のサービスの品質値の低下の原因と判断されるインフラリソースを特定する。ＪＩＴモデリングについては、例えば、下記参考文献２、および、下記参考文献３などを参照することができる。
参考文献２ ： Ｓｔｅｎｍａｎ， Ａ．， Ｇｕｓｔａｆｓｓｏｎ， Ｆ． ａｎｄ Ｌｊｕｎｇ， Ｌ．： “Ｊｕｓｔ Ｉｎ Ｔｉｍｅ Ｍｏｄｅｌｓ Ｆｏｒ Ｄｙｎａｍｉｃａｌ Ｓｙｓｔｅｍｓ”， ｉｎ Ｐｒｏｃ． ３５ｔｈ Ｃｏｎｆ． Ｄｅｃｉｓｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ， Ｄｅｃ． １１１５／１１２０ （１９９６）
参考文献３ ： 牛田俊，木村英紀： “Ｊｕｓｔ−Ｉｎ−Ｔｉｍｅモデリング技術を用いた非線形システムの同定と制御”， 計測と制御， Ｖｏｌ．４４， Ｎｏ．２， １０２／１０６ （２００５）
（判定装置１００がアラームの出力要否を判定する一例）
次に、図１４〜図２０を用いて、判定装置１００がアラームの出力要否を判定する一例について説明する。
図１４〜図２０は、判定装置１００がアラームの出力要否を判定する一例を示す説明図である。図１４において、サービス判定部１３０１は、業務処理装置２０１と通信し、稼働中のサービスを判定し、稼働中のサービスの利用量を取得する。利用量は、例えば、単位時間あたりのサービス稼働率である。図１４の例では、サービス判定部１３０１は、グラフ１４２０における点線丸印に示すような、複数の時点のそれぞれの時点のサービスの利用量を取得する。
サービス判定部１３０１は、図２１〜図２５に後述するように、稼働中のサービスの利用量として、重み係数を算出する場合があってもよい。ここで、業務処理システム２００におけるサービスの性質としては、例えば、以下の２つの性質が考えられる。
例えば、サービスの利用量が、分、時間、日、週、または、月などの所定の時間間隔で周期的な変化傾向を示すという第１の性質が考えられる。また、例えば、１以上のサービスのそれぞれの利用量に基づき、１以上のリソースのそれぞれの使用状況が決定するという第２の性質が考えられる。
上記性質によれば、異なるリソースのそれぞれの使用状況を表す指標値の時間変化を示す時系列データの中で、同じサービスに対応する成分データは、所定の時間間隔での周期的な変化傾向が互いに類似するような成分データになることが考えられる。また、上記性質によれば、１以上のリソースのそれぞれの使用状況を表す指標値が、１以上のサービスのそれぞれの利用量に比例するという負荷モデルが考えられる。このため、サービス判定部１３０１は、上記負荷モデルを利用すれば、所定の時間間隔での、サービスごとの利用量に関わる情報を取得可能になる。
サービス性能監視部１３０２は、業務処理装置２０１と通信し、サービスの品質値を取得する。図１４の例では、サービス性能監視部１３０２は、グラフ１４３０における点線丸印に示すような、複数の時点のそれぞれの時点のサービスの品質値を取得する。インフラ監視部１３０３は、業務処理装置２０１と通信し、インフラリソースの使用量を取得する。図１４の例では、インフラ監視部１３０３は、グラフ１４１０における点線丸印に示すような、複数の時点のそれぞれの時点のインフラリソースの使用量を取得する。
サービス品質モデル化部１３０４は、インフラリソース推定モデルを生成する。インフラリソース推定モデルは、時系列推定モデルである。図１４の例では、インフラリソース推定モデルは、グラフ１４１０の実線に示すような、時系列推定モデルである。サービス品質モデル化部１３０４は、例えば、範囲１４１１のいくつかのインフラリソースの使用量に基づいて、インフラリソース推定モデルを生成する。
同様に、サービス品質モデル化部１３０４は、サービス利用量推定モデルを生成する。サービス利用量推定モデルは、時系列推定モデルである。図１４の例では、サービス利用量推定モデルは、グラフ１４２０の実線に示すような、時系列推定モデルである。サービス品質モデル化部１３０４は、例えば、範囲１４２１のいくつかのサービスの利用量に基づいて、サービス利用量推定モデルを生成する。
サービス品質モデル化部１３０４は、サービス品質推定モデルを生成する。図１４の例では、サービス品質推定モデルは、時点１４３１のインフラリソースの使用量とサービスの利用量とに基づいて、品質値１４３２を推定可能にする推定モデルである。サービス品質推定モデルは、例えば、関数ｆ（インフラリソースの使用量、サービスの利用量）である。ここで、図１５の説明に移行し、サービス品質モデル化部１３０４が、インフラリソース推定モデルを生成する具体例について説明する。
図１５において、サービス品質モデル化部１３０４は、図４に示した稼働テーブル４００を参照して、サービスに関わるインフラリソースの使用量を取得し、表１５００に設定する。そして、サービス品質モデル化部１３０４は、複数時系列データ間の相互影響をモデル化するベクトル自己回帰モデル（ＶＡＲ）を用いて、下記式（１）で規定される、インフラリソース推定モデルを生成する。
ｙt＝ｃ＋φ1ｙt-1＋・・・＋φpｙt-p＋εt，εi,t〜Ｎ（０，σi 2） ・・・（１）
上記式（１）において、ｙt∈Ｒn×1は、時点ｔにおけるｎ個の変数（インフラリソースの使用量）を並べたベクトルである。ｃ∈Ｒn×1は、定数ベクトルである。φi∈Ｒn×nは、係数行列である。εt∈Ｒn×1は、誤差ベクトルである。
サービス品質モデル化部１３０４は、例えば、表１５００の要素を、それぞれ、ｔ，ｙ1,t，ｙ2,t，ｙ3,t，ｙ4,t，・・・として利用し、上記式（１）のパラメータｐ，ｃ，φi，σiを算出する。これにより、サービス品質モデル化部１３０４は、サービス利用量推定モデルを生成することができる。ここで、図１６の説明に移行し、サービス品質モデル化部１３０４が、サービス利用量推定モデルを生成する具体例について説明する。
図１６において、サービス品質モデル化部１３０４は、図９に示したサービス利用量テーブル９００を参照して、サービスの利用量を取得し、表１６００に設定する。そして、サービス品質モデル化部１３０４は、自己回帰モデル（ＡＲ，ＡＲＭＡ，ＡＲＩＭＡ，ＳＡＲＩＭＡなど）を用いて、下記式（２）で規定される、サービス利用量推定モデルを生成する。
ｙt＝ｃ＋Σi=1 p（φiｙt-i）＋εt＋Σj=1 q（θjεt-jεt〜Ｎ（０，σ2）） ・・・（２）
上記式（２）において、ｙtは、時点ｔにおける変数（サービスの利用量）である。ｃは、定数である。φiは、ｉ次の自己回帰係数である。θiは、ｉ次の移動平均係数である。サービス品質モデル化部１３０４は、例えば、表１６００の要素を、それぞれ、ｔ，ｙtとして利用し、上記式（２）のパラメータｐ，ｑ，ｃ，φi，θi，σを算出する。これにより、サービス品質モデル化部１３０４は、サービス利用量推定モデルを生成することができる。ここで、図１７の説明に移行し、サービス品質モデル化部１３０４が、サービス品質推定モデルを生成する具体例について説明する。
図１７において、サービス品質モデル化部１３０４は、図４に示した稼働テーブル４００と、図９に示したサービス利用量テーブル９００と、図１０に示したサービス品質テーブル１０００とを参照して、表１７００を生成する。そして、サービス品質モデル化部１３０４は、ＪＩＴモデリング（局所回帰モデル）を用いて、下記式（３）で規定される、サービス品質推定モデルを生成する。
ｙ＾＝ｂ＋Σm=1 M（ａmｘn） ・・・（３）
上記式（３）において、ｙ＾は、サービスの品質値の予測値である。ｂは、定数である。ａmは、係数である。ｘmは、入力データである。入力データは、インフラリソースの使用量と、サービスの利用量とである。Ｍは、入力データの数であり、インフラリソースの数＋１である。サービス品質モデル化部１３０４は、例えば、表１７００の要素を、入力データとして利用し、上記式（３）のパラメータｂ，ａmを算出する。これにより、サービス品質モデル化部１３０４は、サービス品質推定モデルを生成することができる。次に、図１８の説明に移行する。
図１８において、サービス品質予測部１３０５は、インフラリソース推定モデルを用いて、現時点以降の範囲１８００のそれぞれの時点における、将来のインフラリソースの使用量を推定する。サービス品質予測部１３０５は、サービス利用量推定モデルを用いて、現時点以降の範囲１８００のそれぞれの時点における、将来のサービスの利用量を推定する。
サービス品質予測部１３０５は、サービス品質推定モデルを用いて、範囲１８００のそれぞれの時点における、将来のインフラリソースの使用量と、将来のサービスの利用量との組み合わせに対応する、将来のサービスの品質値の予測値を算出する。図１８の例では、予測値は、太線丸印で示される。サービス品質予測部１３０５が、将来のサービスの品質値の予測値を算出する詳細については、図１９および図２０を用いて後述する。
インフラ制御部１３０６は、将来のサービスの品質値の予測値に基づいて、アラームの出力要否を判定する。インフラ制御部１３０６は、例えば、将来のサービスの品質値の予測値に基づいて、将来のサービスの品質値の予測値が閾値未満となる期間があるか否かを判定する。インフラ制御部１３０６は、将来のサービスの品質値の予測値が閾値未満となる期間がある場合、アラームを出力すると判定し、アラームを出力する。一方で、インフラ制御部１３０６は、将来のサービスの品質値の予測値が閾値未満となる期間がない場合、アラームを出力しないと判定する。次に、図１９の説明に移行する。
図１９に示すように、サービス品質予測部１３０５は、具体的には、インフラリソース推定モデルに、表１９００のインフラリソースの使用量の情報１９１０を入力することにより、将来のインフラリソースの使用量の情報１９１１を取得する。また、サービス品質予測部１３０５は、具体的には、サービス利用量推定モデルに、表１９００のサービスの利用量の情報１９２０を入力することにより、将来のサービスの利用量の情報１９２１を取得する。
サービス品質予測部１３０５は、具体的には、サービス品質推定モデルに、将来の時点「２０１９−０１−０１ ００：０３：００」における、インフラリソースの使用量と、サービスの利用量との情報１９３１を入力する。これにより、サービス品質予測部１３０５は、同じ時点「２０１９−０１−０１ ００：０３：００」における、サービスの品質値の予測値１９４１を取得する。
同様に、サービス品質予測部１３０５は、具体的には、サービス品質推定モデルに、将来の時点「２０１９−０１−０１ ００：０３：３０」における、インフラリソースの使用量と、サービスの利用量との情報１９３２を入力する。これにより、サービス品質予測部１３０５は、同じ時点「２０１９−０１−０１ ００：０３：３０」における、サービスの品質値の予測値１９４２を取得する。
同様に、サービス品質予測部１３０５は、具体的には、サービス品質推定モデルに、将来の時点「２０１９−０１−０１ ００：０４：００」における、インフラリソースの使用量と、サービスの利用量との情報１９３３を入力する。これにより、サービス品質予測部１３０５は、同じ時点「２０１９−０１−０１ ００：０４：００」における、サービスの品質値の予測値１９４３を取得する。
これにより、判定装置１００は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。このため、システム管理者は、サービスの品質が悪化する前に、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処する作業を開始することができる。
結果として、システム管理者は、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の低減化を図ることができる。また、システム管理者は、サービスの品質が悪化することを防止することができる場合がある。そして、システム管理者は、サービスの利便性の低下を防止または抑制することができる。また、システム管理者は、サービス管理者にかかる作業負担の低減化を図ることができる。また、判定装置１００は、システム管理者にかかる作業負担の低減化を図ることができる。
ここでは、サービス品質予測部１３０５が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定する前に、サービス品質推定モデルが生成される場合について説明したが、これに限らない。例えば、サービス品質予測部１３０５が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定した後に、サービス品質推定モデルが生成される場合があってもよい。
ここで、図２０の説明に移行し、サービス品質予測部１３０５が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定した後に、サービス品質推定モデルが生成される場合について説明する。
図２０において、サービス品質予測部１３０５が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定済みであるとする。この場合、サービス品質モデル化部１３０４は、サービス品質推定モデルを生成するにあたり、推定された将来のインフラリソースの使用量に類似する使用量と、推定された将来のサービスの利用量に類似する利用量とを利用するようにする。
サービス品質モデル化部１３０４は、具体的には、上述した表１７００の中から、推定された将来のインフラリソースの使用量に類似する使用量と、推定された将来のサービスの利用量に類似する利用量と、サービスの品質値とを対応付けたレコードを抽出する。そして、サービス品質モデル化部１３０４は、具体的には、抽出したレコードに基づいて、サービス品質推定モデルを生成する。
ここで、図２０のグラフ２０００のデータ軸上に、推定された将来のインフラリソースの使用量と、推定された将来のサービスの利用量との組み合わせに対応するデータ２００１を示す。サービス品質モデル化部１３０４は、座標２００２〜２００４に対応する、データ２００１の近傍に存在する入力データを含むレコードを用いて、直線２０１０に近似されるようなサービス品質推定モデルを生成することができる。
これにより、サービス品質モデル化部１３０４は、データ２００１の近傍における、インフラリソースの使用量と、サービスの利用量と、サービスの品質値との関係性を、比較的精度よく表す、局所的なサービス品質推定モデルを生成することができる。このため、サービス品質モデル化部１３０４は、サービスの品質値の予測値を精度よく取得可能にすることができる。
（判定装置１００が重み係数を算出する一例）
次に、図２１〜図２５を用いて、判定装置１００が重み係数を算出する一例について説明する。
図２１〜図２５は、判定装置１００が重み係数を算出する一例を示す説明図である。図２１〜図２５の例では、業務処理システム２００に、業務処理装置２０１として、サーバＡＰ０１およびサーバＤＢ０１が含まれる場合について説明する。
リソースの指標値は、ＣＰＵ使用率やディスクＩＯである。指標値は、０〜１の間で正規化される。指標値のサンプリング間隔は、例えば、１時間である。１日のサンプリング数は、２４になる。サービス判定部１３０１は、２０１８／１／１〜２０１８／３／３１までの９０日分に対応する稼働データを取得し、稼働テーブル４００に記憶する。ここで、図２１の説明に移行し、稼働データにおけるリソースごとの指標値の変化傾向について説明する。稼働データは、曜日ごとに周期性を有する。
図２１において、サービス判定部１３０１は、稼働テーブル４００に記憶された稼働データを、１日単位に分解し、日単位稼働データを生成する。サービス判定部１３０１は、例えば、日付「２０１８０１０１」の日単位稼働データ、および、日付「２０１８０１０２」の日単位稼働データなどを生成し、日単位テーブル５００を用いて記憶する。次に、図２２の説明に移行する。
図２２において、サービス判定部１３０１は、日単位稼働データをベクトル化する。サービス判定部１３０１は、例えば、日単位テーブル５００に記憶された日単位稼働データが示す１または複数の指標値を、所定の規則に従って、要素として並べてベクトル化し、ベクトルテーブル６００を用いて記憶する。
日付「２０１８０１０１」の日単位稼働データは、例えば、ベクトルｘ1としてベクトルテーブル６００に記憶される。日付「２０１８０１０２」の日単位稼働データは、例えば、ベクトルｘ2としてベクトルテーブル６００に記憶される。ベクトルの次元は、９６次元になる。次に、図２３の説明に移行する。
図２３において、サービス判定部１３０１は、ベクトルテーブル６００を参照し、９０日の各日に対応するベクトルｘ1，ｘ2，・・・，ｘ90を列とした稼働データ行列Ｘ＝（ｘ1，ｘ2，・・・，ｘ90）を生成する。稼働データ行列Ｘは、９６×９０の行列である。サービス判定部１３０１は、下記式（４）を利用し、稼働データ行列Ｘに対して非負値行列因子分解を実施し、基底行列Ｕと重み行列Ａとを生成する。
サービス判定部１３０１は、例えば、下記式（４）を最小化する重みＡと基底Ｕを推定することになる。｜｜ｚ｜｜FROは、フロベニウスノルムである。α｜｜Ａ｜｜1およびβ｜｜Ｕ｜｜1の項が、Ｓｐａｒｓｅｎｅｓｓ Ｃｏｎｓｔｒａｉｎｔｓである。下記式（４）のα＝β＝０．０１とする。
（Ａ*，Ｕ*）＝ａｒｇｍｉｎA,U（１／２｜｜Ｘ−ＵＡ｜｜FRO 2）＋α｜｜Ａ｜｜1＋β｜｜Ｕ｜｜1 ・・・（４）
この際、サービス判定部１３０１は、基底数＝３を予め設定済みであり、基底行列Ｕ＝（ｕ1，ｕ2，ｕ3）と規定する。基底行列Ｕは、９６×３の行列である。また、サービス判定部１３０１は、重み行列Ａ＝（ａ1，ａ2，ａ3）＝（ａij）と規定する。重み行列Ａは、３×９０の行列である。
結果として、サービス判定部１３０１は、グラフ２３０１〜２３０３に示すような基底ベクトルｕ1，ｕ2，ｕ3を含む基底行列Ｕを生成する。また、サービス判定部１３０１は、グラフ２３１１〜２３１３に示すような重みベクトルａ1，ａ2，ａ3を含む重み行列Ａを生成する。重みベクトルａ1＝（ａ1,1，・・・，ａ1,90）である。重みベクトルａ2＝（ａ2,1，・・・，ａ2,90）である。重みベクトルａ3＝（ａ3,1，・・・，ａ3,90）である。
ここでは、基底数が予め設定済みである場合について説明したが、これに限らない。例えば、基底数として、稼働データ行列を形成するベクトルの次元数を用いる場合があってもよい。この場合、上記式（４）のα｜｜Ａ｜｜1およびβ｜｜Ｕ｜｜1の項により、業務処理単位の成分データとして好ましくない基底ベクトルにかかる重み係数が０になる傾向がある。このため、サービス判定部１３０１は、重み係数の和が０になる重みベクトルａiに対応する基底ベクトルｕiを除外することにより、精度よく基底行列Ｕを生成可能である。次に、図２４の説明に移行する。
図２４において、サービス判定部１３０１は、生成した基底行列の基底ベクトルを、成分テーブル７００を用いて記憶する。基底ベクトルの次元は、稼働データ行列を形成するベクトルと同様に、９６次元になる。次に、図２５の説明に移行する。
図２５において、サービス判定部１３０１は、生成した重み行列の重みベクトルを、重みテーブル８００を用いて記憶する。重みベクトルの次元は、日数に対応し、９０次元になる。これにより、サービス判定部１３０１は、サービスの利用量に対応する重み係数を取得することができる。このため、サービス判定部１３０１は、サービスごとに利用量を直接計測することが難しい状況にも、アラームの出力要否を判定可能にすることができる。
ここでは、判定装置１００が、日ごとの重み係数を算出する場合について説明したが、これに限らない。例えば、サービス判定部１３０１は、他の所定間隔単位の重み係数を算出する場合があってもよい。具体的には、サービス判定部１３０１は、３０分単位の重み係数を算出する場合があってもよい。
（全体処理手順）
次に、図２６を用いて、判定装置１００が実行する、全体処理手順の一例について説明する。全体処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。
図２６は、全体処理手順の一例を示すフローチャートである。判定装置１００は、稼働中のサービスを特定する（ステップＳ２６０１）。次に、判定装置１００は、稼働中のサービスの品質値を収集する（ステップＳ２６０２）。そして、判定装置１００は、稼働中のサービスの利用量を収集する（ステップＳ２６０３）。
次に、判定装置１００は、インフラリソースの稼働データを収集する（ステップＳ２６０４）。そして、判定装置１００は、インフラ使用量時系列モデルと、サービス利用量時系列モデルと、サービス品質値推定モデルとを生成する（ステップＳ２６０５）。
次に、判定装置１００は、将来のサービスの品質値を予測する（ステップＳ２６０６）。判定装置１００は、例えば、インフラ使用量時系列モデルと、サービス利用量時系列モデルとを用いて、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定する。判定装置１００は、例えば、サービス品質値推定モデルを用いて、推定した将来のインフラリソースの使用量と、推定した将来のサービスの利用量との組み合わせに対応する、将来のサービスの品質値を推定する。
そして、判定装置１００は、将来のサービスの品質値＜閾値であるか否かを判定する（ステップＳ２６０７）。ここで、将来のサービスの品質値＜閾値ではない場合（ステップＳ２６０７：Ｎｏ）、判定装置１００は、全体処理を終了する。一方で、将来のサービスの品質値＜閾値である場合（ステップＳ２６０７：Ｙｅｓ）、判定装置１００は、ステップＳ２６０８の処理に移行する。
ステップＳ２６０８では、判定装置１００は、将来のサービスの品質値の低下の原因となるインフラリソースを出力する（ステップＳ２６０８）。そして、判定装置１００は、全体処理を終了する。これにより、判定装置１００は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
ここで、判定装置１００は、ステップＳ２６０５の処理として、具体的には、図２７に後述するモデル生成処理を実行してもよい。また、判定装置１００は、ステップＳ２６０６〜Ｓ２６０８の処理として、具体的には、図２８に後述する解析処理を実行してもよい。
（モデル生成処理手順）
次に、図２７を用いて、判定装置１００が実行する、モデル生成処理手順の一例について説明する。モデル生成処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。
図２７は、モデル生成処理手順の一例を示すフローチャートである。判定装置１００は、稼働中の各サービスに関わるインフラリソースを特定する（ステップＳ２７０１）。そして、判定装置１００は、インフラリソースの稼働データのうち、特定したインフラリソースの使用量に基づいて、インフラ使用量時系列モデルを生成する（ステップＳ２７０２）。
次に、判定装置１００は、サービスの利用量に基づいて、サービス利用量時系列モデルを生成する（ステップＳ２７０３）。そして、判定装置１００は、特定したインフラリソースの使用量と、サービスの利用量と、サービスの品質値とに基づいて、サービス品質値推定モデルを生成する（ステップＳ２７０４）。その後、判定装置１００は、モデル生成処理を終了する。これにより、判定装置１００は、各種モデルを生成することができる。
（解析処理手順）
次に、図２８を用いて、判定装置１００が実行する、解析処理手順の一例について説明する。解析処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。
図２８は、解析処理手順の一例を示すフローチャートである。図２８において、判定装置１００は、サービスの品質値を予測する（ステップＳ２８０１）。次に、判定装置１００は、サービスの品質値が閾値より小さくなる時期を特定する（ステップＳ２８０２）。
そして、判定装置１００は、サービスの品質値が閾値より小さくなる時期があるか否かを判定する（ステップＳ２８０３）。ここで、サービスの品質値が閾値より小さくなる時期がない場合（ステップＳ２８０３：Ｎｏ）、判定装置１００は、解析処理を終了する。一方で、サービスの品質値が閾値より小さくなる時期がある場合（ステップＳ２８０３：Ｙｅｓ）、判定装置１００は、ステップＳ２８０４の処理に移行する。
ステップＳ２８０４では、判定装置１００は、サービスの品質値が閾値より小さくなる時期と、サービスに関わるインフラリソースとを対応付けて出力する（ステップＳ２８０４）。そして、判定装置１００は、解析処理を終了する。これにより、判定装置１００は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
以上説明したように、判定装置１００によれば、１以上の時点における所定のサービスに関わるリソースの使用量を取得することができる。判定装置１００によれば、１以上の時点におけるサービスの利用量を取得することができる。判定装置１００によれば、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得することができる。判定装置１００によれば、第１のモデルを用いて、取得した１以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定することができる。判定装置１００によれば、第２のモデルを用いて、取得した１以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定することができる。判定装置１００によれば、取得したサービスの品質値と特定したリソースの使用量と特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定することができる。これにより、判定装置１００は、将来的にサービスの品質が悪化するのか否かに基づいて、アラームを出力するか否かを判定することができる。
判定装置１００によれば、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、第３のモデルを生成することができる。判定装置１００によれば、生成した第３のモデルを用いて、特定したリソースの使用量と特定したサービスの利用量とから予測される、サービスの品質値を特定することができる。判定装置１００によれば、特定したサービスの品質値に基づいて、サービスに関するアラームを出力するか否かを判定することができる。これにより、判定装置１００は、将来の品質値を精度よく推定することができ、将来的にサービスの品質が悪化するのか否かを精度よく判定することができる。
判定装置１００によれば、過去のいずれかの時点における、特定したリソースの使用量に類似するリソースの使用量と、特定したサービスの利用量に類似するサービスの利用量とに対応付けられた、サービスの品質値を取得することができる。これにより、判定装置１００は、将来の品質値を精度よく推定可能な第３のモデルを生成することができる。
判定装置１００によれば、複数の時点におけるリソースの使用量を取得することができる。判定装置１００によれば、複数の時点におけるサービスの利用量を取得することができる。判定装置１００によれば、取得した複数の時点におけるリソースの使用量に基づいて、第１のモデルを生成することができる。判定装置１００によれば、取得した複数の時点におけるサービスの利用量に基づいて、第２のモデルを生成することができる。これにより、判定装置１００は、システム管理者が、第１のモデルと第２のモデルとを用意せずに済ませることができ、システム管理者にかかる作業負担の低減化を図ることができる。
判定装置１００によれば、特定したサービスの品質値が閾値未満である場合、サービスに関するアラームを出力すると判定することができる。これにより、判定装置１００は、閾値判定により、将来的にサービスの品質が悪化するのか否かを判定しやすくすることができる。
判定装置１００によれば、アラームに、サービスの品質値が小さくなる原因を示す情報を含めることができる。これにより、判定装置１００は、システム管理者が、サービスの品質値が小さくなる原因に対処しやすくすることができ、システム管理者にかかる作業負担の低減化を図ることができる。
判定装置１００によれば、アラームを出力すると判定した場合、アラームを出力することができる。これにより、判定装置１００は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
なお、本実施の形態で説明した判定方法は、予め用意されたプログラムをＰＣやワークステーションなどのコンピュータで実行することにより実現することができる。本実施の形態で説明した判定プログラムは、コンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。記録媒体は、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などである。また、本実施の形態で説明した判定プログラムは、インターネットなどのネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
（付記１）１以上の時点における所定のサービスに関わるリソースの使用量を取得し、
１以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された１以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第１のモデルを用いて、取得した１以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された１以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第２のモデルを用いて、取得した１以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータが実行することを特徴とする判定方法。
（付記２）取得した前記過去のいずれかの時点における前記サービスの品質値に基づいて、入力された前記リソースの使用量と前記サービスの利用量とに対応する前記サービスの品質値を出力する第３のモデルを生成し、
生成した前記第３のモデルを用いて、特定した前記リソースの使用量と特定した前記サービスの利用量とから予測される、前記サービスの品質値を特定する、処理を前記コンピュータが実行し、
前記判定する処理は、
特定した前記サービスの品質値に基づいて、前記サービスに関するアラームを出力するか否かを判定する、ことを特徴とする付記１に記載の判定方法。
（付記３）前記サービスの品質値を取得する処理は、
過去のいずれかの時点における、特定した前記リソースの使用量に類似する前記リソースの使用量と、特定した前記サービスの利用量に類似する前記サービスの利用量とに対応付けられた、前記サービスの品質値を取得する、ことを特徴とする付記１または２に記載の判定方法。
（付記４）複数の時点における前記リソースの使用量を取得し、
複数の時点における前記サービスの利用量を取得し、
取得した複数の時点における前記リソースの使用量に基づいて、前記第１のモデルを生成し、
取得した複数の時点における前記サービスの利用量に基づいて、前記第２のモデルを生成する、処理を前記コンピュータが実行することを特徴とする付記１〜３のいずれか一つに記載の判定方法。
（付記５）前記判定する処理は、特定した前記サービスの品質値が閾値未満である場合、前記サービスに関するアラームを出力すると判定する、ことを特徴とする付記１〜４のいずれか一つに記載の判定方法。
（付記６）前記アラームは、前記サービスの品質値が小さくなる原因を示す情報を含む、ことを特徴とする付記１〜５のいずれか一つに記載の判定方法。
（付記７）前記アラームを出力すると判定した場合、前記アラームを出力する、処理を前記コンピュータが実行することを特徴とする付記１〜６のいずれか一つに記載の判定方法。
（付記８）１以上の時点における所定のサービスに関わるリソースの使用量を取得し、
１以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された１以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第１のモデルを用いて、取得した１以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された１以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第２のモデルを用いて、取得した１以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータに実行させることを特徴とする判定プログラム。
１００ 判定装置
１０１，１０２ モデル
２００ 業務処理システム
２０１ 業務処理装置
２０２ 管理者側装置
２１０ ネットワーク
２２０ サービス実行基盤
３００，１１００ バス
３０１，１１０１ ＣＰＵ
３０２，１１０２ メモリ
３０３，１１０３ ネットワークＩ／Ｆ
３０４，１１０４ 記録媒体Ｉ／Ｆ
３０５，１１０５ 記録媒体
４００ 稼働テーブル
５００ 日単位テーブル
６００ ベクトルテーブル
７００ 成分テーブル
８００ 重みテーブル
９００ サービス利用量テーブル
１０００ サービス品質テーブル
１１０６ ディスプレイ
１１０７ 入力装置
１２００ 記憶部
１２０１ 取得部
１２０２ 生成部
１２０３ 第１の特定部
１２０４ 第２の特定部
１２０５ 判定部
１２０６ 出力部
１３０１ サービス判定部
１３０２ サービス性能監視部
１３０３ インフラ監視部
１３０４ サービス品質モデル化部
１３０５ サービス品質予測部
１３０６ インフラ制御部
１４１０，１４２０，１４３０，２０００，２３０１〜２３０３，２３１１〜２３１３ グラフ
１４１１，１４２１，１８００ 範囲
１４３１ 時点
１４３２ 品質値
１５００，１６００，１７００，１９００ 表
１９１０，１９１１，１９２０，１９２１，１９３１〜１９３３ 情報
１９４１〜１９４３ 予測値
２００１ データ
２００２〜２００４ 座標
２０１０ 直線

Claims (7)

  1. １以上の時点における所定のサービスに関わるリソースの使用量を取得し、
    １以上の時点における前記サービスの利用量を取得し、
    少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
    入力された１以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第１のモデルを用いて、取得した１以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
    入力された１以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第２のモデルを用いて、取得した１以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
    取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
    処理をコンピュータが実行することを特徴とする判定方法。
  2. 取得した前記過去のいずれかの時点における前記サービスの品質値に基づいて、入力された前記リソースの使用量と前記サービスの利用量とに対応する前記サービスの品質値を出力する第３のモデルを生成し、
    生成した前記第３のモデルを用いて、特定した前記リソースの使用量と特定した前記サービスの利用量とから予測される、前記サービスの品質値を特定する、処理を前記コンピュータが実行し、
    前記判定する処理は、
    特定した前記サービスの品質値に基づいて、前記サービスに関するアラームを出力するか否かを判定する、ことを特徴とする請求項１に記載の判定方法。
  3. 前記サービスの品質値を取得する処理は、
    過去のいずれかの時点における、特定した前記リソースの使用量に類似する前記リソースの使用量と、特定した前記サービスの利用量に類似する前記サービスの利用量とに対応付けられた、前記サービスの品質値を取得する、ことを特徴とする請求項１または２に記載の判定方法。
  4. 複数の時点における前記リソースの使用量を取得し、
    複数の時点における前記サービスの利用量を取得し、
    取得した複数の時点における前記リソースの使用量に基づいて、前記第１のモデルを生成し、
    取得した複数の時点における前記サービスの利用量に基づいて、前記第２のモデルを生成する、処理を前記コンピュータが実行することを特徴とする請求項１〜３のいずれか一つに記載の判定方法。
  5. 前記判定する処理は、特定した前記サービスの品質値が閾値未満である場合、前記サービスに関するアラームを出力すると判定する、ことを特徴とする請求項１〜４のいずれか一つに記載の判定方法。
  6. 前記アラームは、前記サービスの品質値が小さくなる原因を示す情報を含む、ことを特徴とする請求項１〜５のいずれか一つに記載の判定方法。
  7. １以上の時点における所定のサービスに関わるリソースの使用量を取得し、
    １以上の時点における前記サービスの利用量を取得し、
    少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
    入力された１以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第１のモデルを用いて、取得した１以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
    入力された１以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第２のモデルを用いて、取得した１以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
    取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
    処理をコンピュータに実行させることを特徴とする判定プログラム。
JP2020088069A 2020-05-20 2020-05-20 判定方法、および判定プログラム Pending JP2021182314A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2020088069A JP2021182314A (ja) 2020-05-20 2020-05-20 判定方法、および判定プログラム
EP21164860.5A EP3913557A1 (en) 2020-05-20 2021-03-25 Future quality of service determination method and determination program
US17/220,487 US20210365350A1 (en) 2020-05-20 2021-04-01 Determination method and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020088069A JP2021182314A (ja) 2020-05-20 2020-05-20 判定方法、および判定プログラム

Publications (1)

Publication Number Publication Date
JP2021182314A true JP2021182314A (ja) 2021-11-25

Family

ID=75223158

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020088069A Pending JP2021182314A (ja) 2020-05-20 2020-05-20 判定方法、および判定プログラム

Country Status (3)

Country Link
US (1) US20210365350A1 (ja)
EP (1) EP3913557A1 (ja)
JP (1) JP2021182314A (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109905271B (zh) * 2018-05-18 2021-01-12 华为技术有限公司 一种预测方法、训练方法、装置及计算机存储介质
US11775936B1 (en) * 2020-05-27 2023-10-03 Amazon Technologies, Inc. Forecasting long duration floating holidays in online traffic
US11782798B2 (en) * 2022-02-11 2023-10-10 Dell Products, L.P. Method and apparatus for predicting and exploiting aperiodic backup time windows on a storage system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4872945B2 (ja) * 2008-02-25 2012-02-08 日本電気株式会社 運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラム
JP2012100010A (ja) 2010-11-01 2012-05-24 Oki Electric Ind Co Ltd ネットワーク監視装置、ネットワーク監視システム、ネットワーク監視方法、及びプログラム
WO2016084327A1 (ja) * 2014-11-27 2016-06-02 日本電気株式会社 資源予測装置、資源予測方法、資源予測プログラムおよび分散処理システム
US10031785B2 (en) * 2015-04-10 2018-07-24 International Business Machines Corporation Predictive computing resource allocation for distributed environments
US10929792B2 (en) * 2016-03-17 2021-02-23 International Business Machines Corporation Hybrid cloud operation planning and optimization
JP7103134B2 (ja) * 2018-10-04 2022-07-20 富士通株式会社 出力プログラム、および出力方法

Also Published As

Publication number Publication date
US20210365350A1 (en) 2021-11-25
EP3913557A1 (en) 2021-11-24

Similar Documents

Publication Publication Date Title
US11614969B2 (en) Compression techniques for encoding stack trace information
JP2021182314A (ja) 判定方法、および判定プログラム
Gmach et al. Capacity management and demand prediction for next generation data centers
JP6571914B2 (ja) 情報の複数のドメインを組合せることによる仕事の実施データ内の異常の検知
US11775412B2 (en) Machine learning models applied to interaction data for facilitating modifications to online environments
KR20060061759A (ko) 트랜잭션 기반 성능 모델을 자동 검증 및 캘리브레이션하기위한 컴퓨터 구현 방법
JP6891611B2 (ja) 管理装置、情報処理システムの制御方法、および管理装置の管理プログラム
CN112990583B (zh) 一种数据预测模型的入模特征确定方法及设备
Inoue et al. Bivariate change-point modeling for software reliability assessment with uncertainty of testing-environment factor
CN112132384A (zh) 工作效率评估方法、装置、存储介质及计算机设备
CN111291936B (zh) 产品生命周期预估模型生成方法、装置及电子设备
Epifani et al. Change-point detection for black-box services
CN109711849B (zh) 以太坊地址画像生成方法、装置、电子设备及存储介质
Wang et al. Concept drift-based runtime reliability anomaly detection for edge services adaptation
Zhang et al. Real-time performance prediction for cloud components
KR20220006580A (ko) 방문 예측
WO2009086326A1 (en) Evaluating and predicting computer system performance using kneepoint analysis
JPWO2021192191A5 (ja) 異常アクセス予測システム、異常アクセス予測方法および異常アクセス予測プログラム
US20220129318A1 (en) Quota Request Resolution On Computing Platform
US20220277008A1 (en) Supporting database queries using unsupervised vector embedding approaches over unseen data
JP2003525497A (ja) システムのモデリング方法及びシステムのモデリング装置
JP2022067897A (ja) 情報処理方法、および情報処理プログラム
US9977721B2 (en) Evaluating and predicting computer system performance using kneepoint analysis
CN113971119A (zh) 基于无监督模型的用户行为异常分析评估方法及系统
Murtojarvi et al. Determining the proper number and price of software licenses