JP2021182314A - 判定方法、および判定プログラム - Google Patents
判定方法、および判定プログラム Download PDFInfo
- 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
Links
- 238000000034 method Methods 0.000 title claims description 62
- 238000012545 processing Methods 0.000 claims description 79
- 239000013598 vector Substances 0.000 description 48
- 239000011159 matrix material Substances 0.000 description 39
- 238000010586 diagram Methods 0.000 description 38
- 230000006866 deterioration Effects 0.000 description 19
- 238000012544 monitoring process Methods 0.000 description 13
- 238000004458 analytical method Methods 0.000 description 9
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 241001123248 Arma Species 0.000 description 3
- 241000728173 Sarima Species 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- YHXISWVBGDMDLQ-UHFFFAOYSA-N moclobemide Chemical compound C1=CC(Cl)=CC=C1C(=O)NCCN1CCOCC1 YHXISWVBGDMDLQ-UHFFFAOYSA-N 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 230000002542 deteriorative effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000005183 dynamical system Methods 0.000 description 1
- 238000005401 electroluminescence Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
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)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- General Engineering & Computer Science (AREA)
- Marketing (AREA)
- Educational Administration (AREA)
- Development Economics (AREA)
- Operations Research (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Game Theory and Decision Science (AREA)
- Software Systems (AREA)
- Bioinformatics & Computational Biology (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Evolutionary Biology (AREA)
- Probability & Statistics with Applications (AREA)
- Computer Hardware Design (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Life Sciences & Earth Sciences (AREA)
- Debugging And Monitoring (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】将来的にサービスの品質が悪化することを把握可能にすること。
【解決手段】サービス品質モデル化部は、範囲1411のいくつかのインフラリソースの使用量に基づいて、インフラリソース推定モデルを生成する。サービス品質モデル化部は、範囲1421のいくつかのサービスの利用量に基づいて、サービス利用量推定モデルを生成する。サービス品質モデル化部は、サービス品質推定モデルを生成する。サービス品質予測部は、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを用いて、将来的なサービスの品質値を取得する。インフラ制御部は、将来のサービスの品質値に基づいて、アラームを出力する。
【選択図】図14
【解決手段】サービス品質モデル化部は、範囲1411のいくつかのインフラリソースの使用量に基づいて、インフラリソース推定モデルを生成する。サービス品質モデル化部は、範囲1421のいくつかのサービスの利用量に基づいて、サービス利用量推定モデルを生成する。サービス品質モデル化部は、サービス品質推定モデルを生成する。サービス品質予測部は、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを用いて、将来的なサービスの品質値を取得する。インフラ制御部は、将来のサービスの品質値に基づいて、アラームを出力する。
【選択図】図14
Description
本発明は、判定方法、および判定プログラムに関する。
従来、システムに含まれる1以上のリソースを用いてサービスが提供されることがある。ここで、サービスを管理し、サービスの品質が悪化したことを検出するサービス管理者が存在する。また、システムを管理し、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するシステム管理者が存在する。
先行技術としては、例えば、複数のネットワーク機器の負荷と、サービスの品質との対応関係を学習し、学習した対応関係に基づいて、サービスの品質が、所定の制御変更基準値以上となるように、各ネットワーク機器の制御内容を決定するものがある。
しかしながら、従来技術では、システム管理者は、サービスの品質が悪化した後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。例えば、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。
1つの側面では、本発明は、将来的にサービスの品質が悪化することを把握可能にすることを目的とする。
1つの実施態様によれば、1以上の時点における所定のサービスに関わるリソースの使用量を取得し、1以上の時点における前記サービスの利用量を取得し、少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する判定方法、および判定プログラムが提案される。
一態様によれば、将来的にサービスの品質が悪化することを把握可能にすることが可能になる。
以下に、図面を参照して、本発明にかかる判定方法、および判定プログラムの実施の形態を詳細に説明する。
(実施の形態にかかる判定方法の一実施例)
図1は、実施の形態にかかる判定方法の一実施例を示す説明図である。判定装置100は、将来的にサービスの品質が悪化することを把握可能にするためのコンピュータである。サービスは、例えば、1以上の機器によって形成される所定の業務処理システムに含まれる1以上のリソースを利用して提供される。サービスは、複数存在してもよい。
図1は、実施の形態にかかる判定方法の一実施例を示す説明図である。判定装置100は、将来的にサービスの品質が悪化することを把握可能にするためのコンピュータである。サービスは、例えば、1以上の機器によって形成される所定の業務処理システムに含まれる1以上のリソースを利用して提供される。サービスは、複数存在してもよい。
ここで、業務処理システムは、例えば、ICT(Information and Communication Technology)システムである。機器は、例えば、ICT機器である。機器は、具体的には、サーバである。リソースは、例えば、CPU、メモリ、および、通信帯域などである。サービスは、例えば、1以上の機器における1以上のプロセスの実行によって実現される。
業務処理システムに対して、サービスを管理し、サービスの品質が悪化したことを検出するサービス管理者が存在する。また、業務処理システムに対して、業務処理システムを管理し、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するシステム管理者が存在する。サービス管理者と、システム管理者とは、同一の者であってもよいし、異なる者であってもよい。
しかしながら、従来では、システム管理者は、サービスの品質が悪化した後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処することができない。このため、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の増大化を招き、サービスの利便性の低下を招くことになるという問題がある。また、サービス管理者は、サービスの品質が悪化したことに関し、サービス利用者に応対する作業を実施することがあり、サービス管理者にかかる作業負担の増大化を招くことになるという問題がある。
具体的には、システム管理者が、サービス管理者とは異なる者である場合、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、いずれかのリソースに対処するという作業を開始するきっかけを得ることができない。このため、システム管理者は、サービスの品質が悪化したことを、サービス管理者から連絡された後でなければ、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処するという作業を開始することができない。
また、システム管理者が、サービスの品質が悪化した原因であるリソースを特定するにあたり、サービスの稼働状況のデータと、リソースの使用状況のデータとを照合することが考えられる。システム管理者は、例えば、サービス管理者から、サービスの稼働状況のデータを取得する。そして、システム管理者は、例えば、サービスの稼働状況のデータと、リソースの使用状況のデータとを照合し、サービスごとのリソースの使用状況を特定し、サービスの品質が悪化した原因であるリソースを特定することになる。このため、システム管理者にかかる作業負担の増大化を招くという問題がある。
従って、システム管理者が、将来的にサービスの品質が悪化し得ることを把握可能にすれば、サービスの利便性の低下を抑制し、サービス管理者にかかる作業負担の増加を抑制し、システム管理者にかかる作業負担の増加を抑制することができると考えられる。
そこで、本実施の形態では、将来的にサービスの品質が悪化することを把握可能にすることができる判定方法について説明する。
図1の例では、判定装置100は、第1のモデル101を有する。第1のモデル101は、入力された1以上の時点におけるリソースの使用量から予測される将来のいずれかの時点におけるリソースの使用量を出力するモデルである。リソースの使用量は、例えば、物理マシンのCPU使用率、物理マシンの空きメモリ量、物理マシンのネットワーク速度、仮想マシンのCPU使用率、仮想マシンの空きメモリ量、仮想マシンのネットワーク速度などの少なくともいずれかである。
また、図1の例では、判定装置100は、第2のモデル102を有する。第2のモデル102は、入力された1以上の時点におけるサービスの利用量から予測される将来のいずれかの時点におけるサービスの利用量を出力するモデルである。サービスの利用量は、例えば、単位時間あたりのサービスの稼働率である。サービスの利用量は、具体的には、単位時間あたりのサービスへのアクセス回数である。
(1−1)判定装置100は、1以上の時点におけるサービスに関わるリソースの使用量を取得する。サービスに関わるリソースは、例えば、サービスを実現する際に利用されるリソースである。
(1−2)判定装置100は、1以上の時点におけるサービスの利用量を取得する。取得したサービスの利用量に係る時点は、例えば、取得したリソースの使用量に係る時点と同一の時点であってもよい。サービスの利用量に係る時点は、いつのサービスの利用量であるかを示す。サービスの利用量に係る時点は、例えば、サービスの利用量を取得した時点、または、サービスの利用量を計測した時点である。リソースの使用量に係る時点は、いつのリソースの使用量であるかを示す。リソースの使用量に係る時点は、例えば、リソースの使用量を取得した時点、または、リソースの使用量を計測した時点である。また、取得したサービスの利用量に係る時点は、例えば、取得したリソースの使用量に係る時点とは異なる時点であってもよい。
(1−3)判定装置100は、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。サービスの品質値は、例えば、品質が良いほど、値が大きくなる指標値である。サービスの品質値は、例えば、リクエストへの遅延時間、単位時間あたりのスループット、単位時間当たりのパケットロス率などに基づいて算出される。サービスの品質値は、具体的には、リクエストへの遅延時間が小さいほど、値が大きくなるよう算出される。
リソースの使用量とサービスの利用量とに対応付けられた、取得したサービスの品質値に係る時点は、例えば、取得したリソースの使用量に係る時点、または、取得したサービスの利用量に係る時点と同一の時点であってもよい。サービスの品質値に係る時点は、いつのサービスの品質値であるかを示す。サービスの品質値に係る時点は、例えば、サービスの品質値を取得した時点、または、サービスの品質値を計測した時点である。また、リソースの使用量とサービスの利用量とに対応付けられた、取得したサービスの品質値に係る時点は、例えば、取得したリソースの使用量に係る時点、または、取得したサービスの利用量に係る時点とは異なる時点であってもよい。
(1−4)判定装置100は、第1のモデル101を用いて、取得した1以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定する。判定装置100は、例えば、第1のモデル101に、取得した1以上の時点におけるリソースの使用量を入力することにより、将来のいずれかの時点におけるリソースの使用量を特定する。
(1−5)判定装置100は、第2のモデル102を用いて、取得した1以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定する。判定装置100は、例えば、第2のモデル102に、取得した1以上の時点におけるサービスの利用量を入力することにより、将来のいずれかの時点におけるサービスの利用量を特定する。
特定したサービスの利用量に係る時点は、例えば、特定したリソースの使用量に係る時点と同一の時点であってもよい。特定したサービスの利用量に係る時点は、例えば、特定したリソースの使用量に係る時点とは異なるが、特定したリソースの使用量に係る時点と対応する時点であってもよい。ある時点に対応する時点とは、例えば、当該時点との差分が一定時間以下である時点である。
(1−6)判定装置100は、取得したサービスの品質値と特定したリソースの使用量と特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定する。判定装置100は、例えば、取得したサービスの品質値のうち、特定したリソースの使用量に類似する使用量と、特定したサービスの利用量に類似する利用量との組み合わせに対応付けられた品質値があれば、将来のいずれかの時点における品質値として特定する。
そして、判定装置100は、例えば、特定した品質値が閾値未満であり、サービスの品質が一定未満であると判断されれば、サービスに関するアラームを出力すると判定する。一方で、判定装置100は、例えば、特定した品質値が閾値以上であり、サービスの品質が一定以上であると判断されれば、サービスに関するアラームを出力しないと判定する。
これにより、判定装置100は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。このため、システム管理者は、サービスの品質が悪化する前に、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処する作業を開始することができる。
結果として、システム管理者は、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の低減化を図ることができる。また、システム管理者は、サービスの品質が悪化することを防止することができる場合がある。そして、システム管理者は、サービスの利便性の低下を防止または抑制することができる。また、システム管理者は、サービス管理者にかかる作業負担の低減化を図ることができる。また、判定装置100は、システム管理者にかかる作業負担の低減化を図ることができる。
(業務処理システム200の一例)
次に、図2を用いて、図1に示した判定装置100を適用した、業務処理システム200の一例について説明する。
次に、図2を用いて、図1に示した判定装置100を適用した、業務処理システム200の一例について説明する。
図2は、業務処理システム200の一例を示す説明図である。図2において、業務処理システム200は、判定装置100と、1以上の業務処理装置201と、1以上の管理者側装置202とを含む。
業務処理システム200において、判定装置100と業務処理装置201とは、有線または無線のネットワーク210を介して接続される。ネットワーク210は、例えば、LAN(Local Area Network)、WAN(Wide Area Network)、および、インターネットなどである。また、業務処理システム200において、判定装置100と管理者側装置202とは、有線または無線のネットワーク210を介して接続される。
判定装置100は、将来的にサービスの品質が悪化することを把握可能に出力する。判定装置100は、例えば、将来的にサービスの品質が悪化すると判断される場合、サービスに関わるアラームを出力する。出力先は、例えば、管理者側装置202である。
判定装置100は、具体的には、図4〜図10に後述する各種テーブルを有する。判定装置100は、具体的には、業務処理装置201と通信し、全体の稼働データを取得する。判定装置100は、より具体的には、所定のタイミングで、業務処理装置201が有するリソースの使用状況を表す指標値を収集し、収集した指標値を纏めた全体の稼働データを生成する。指標値は、例えば、リソースの使用量である。全体の稼働データは、例えば、図4に後述する稼働テーブル400を用いて記憶される。
判定装置100は、具体的には、全体の稼働データを所定の時間間隔ごとに分割する。所定の時間間隔は、例えば、1日である。1日ごとに分割された日単位稼働データは、例えば、図5に後述する日単位テーブル500を用いて記憶される。判定装置100は、具体的には、1日ごとに分割された日単位稼働データをベクトル化し、1日ごとのベクトルを生成する。各日のベクトルは、例えば、図6に後述するベクトルテーブル600を用いて記憶される。
判定装置100は、具体的には、各日のベクトルを列として含む稼働データ行列を生成する。判定装置100は、具体的には、基底数に基づいて、生成した稼働データ行列に対して非負値行列因子分解を実施し、基底行列および重み行列を生成する。基底行列は、例えば、図7に後述する成分テーブル700を用いて記憶される。重み行列は、例えば、図8に後述する重みテーブル800を用いて記憶される。重み行列を形成する重み係数は、サービスの利用状況を示す指標値に対応する。非負値行列因子分解については、例えば、下記参考文献1を参照することができる。
参考文献1 : Hoyer, Patrik O. “Non−negative matrix factorization with sparseness constraints.” Journal of machine learning research 5.Nov (2004): 1457−1469.
判定装置100は、具体的には、業務処理装置201と通信し、サービス単位の利用状況を示す指標値を収集してもよい。指標値は、例えば、サービスの利用量である。サービス単位の利用状況を示す指標値は、例えば、図9に後述するサービス利用量テーブル900を用いて記憶される。判定装置100は、具体的には、業務処理装置201と通信し、サービス単位の品質を示す指標値を収集する。指標値は、例えば、サービスの品質値である。サービス単位の品質を示す指標値は、例えば、図10に後述するサービス品質テーブル1000を用いて記憶される。
判定装置100は、具体的には、図8に後述する重みテーブル800と、図9に後述するサービス利用量テーブル900と、図10に後述するサービス品質テーブル1000とに基づいて、将来的なサービスの品質値を推定する。判定装置100は、具体的には、図4に後述する稼働テーブル400と、図9に後述するサービス利用量テーブル900と、図10に後述するサービス品質テーブル1000とに基づいて、将来的なサービスの品質値を推定してもよい。
判定装置100は、具体的には、将来的なサービスの品質値が閾値未満になる期間があるか否かを判定する。判定装置100は、具体的には、将来的なサービスの品質値が閾値未満になる期間があれば、将来的にサービスの品質が悪化すると判断し、サービスに関わるアラームを出力する。判定装置100は、例えば、サーバ、または、PC(Personal Computer)などである。
業務処理装置201は、業務処理を実行し、サービスを実現するためのコンピュータである。例えば、業務処理装置201を集めたサービス実行基盤220により、サービスを形成する業務処理が分担されることにより、サービスが実現される。業務処理装置201は、例えば、サービスを形成する1以上のプロセスのいずれかを実行する。また、業務処理装置201は、1以上のリソースを有し、それぞれのリソースの使用状況を表す指標値を定期的に計測して記憶し、判定装置100に送信する。また、業務処理装置201は、サービスの利用状況を表す指標値を定期的に計測して記憶し、判定装置100に送信する。業務処理装置201は、例えば、サーバ、または、PCなどである。
管理者側装置202は、システム管理者によって用いられるコンピュータである。管理者側装置202は、サービスに関するアラームを、判定装置100から受信する。管理者側装置202は、受信したアラームを出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、外部装置への送信、または、記憶領域への記憶などである。管理者側装置202は、例えば、PC、タブレット端末、または、スマートフォンなどである。
ここでは、業務処理システム200が、判定装置100を1つ含む場合について説明したが、これに限らない。例えば、業務処理システム200が、判定装置100を複数含む場合があってもよい。そして、複数の判定装置100が協働して、上述した処理を実現する場合があってもよい。
また、ここでは、判定装置100が、業務処理装置201とは異なる装置である場合について説明したが、これに限らない。例えば、判定装置100が、いずれかの業務処理装置201と一体である場合があってもよい。また、ここでは、判定装置100が、管理者側装置202とは異なる装置である場合について説明したが、これに限らない。例えば、判定装置100が、管理者側装置202と一体である場合があってもよい。
(判定装置100のハードウェア構成例)
次に、図3を用いて、判定装置100のハードウェア構成例について説明する。
次に、図3を用いて、判定装置100のハードウェア構成例について説明する。
図3は、判定装置100のハードウェア構成例を示すブロック図である。図3において、判定装置100は、CPU(Central Processing Unit)301と、メモリ302と、ネットワークI/F(Interface)303と、記録媒体I/F304と、記録媒体305とを有する。また、各構成部は、バス300によってそれぞれ接続される。
ここで、CPU301は、判定装置100の全体の制御を司る。メモリ302は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)およびフラッシュROMなどを有する。具体的には、例えば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU301のワークエリアとして使用される。メモリ302に記憶されるプログラムは、CPU301にロードされることで、コーディングされている処理をCPU301に実行させる。
ネットワークI/F303は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して他のコンピュータに接続される。そして、ネットワークI/F303は、ネットワーク210と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークI/F303は、例えば、モデムやLANアダプタなどである。
記録媒体I/F304は、CPU301の制御に従って記録媒体305に対するデータのリード/ライトを制御する。記録媒体I/F304は、例えば、ディスクドライブ、SSD(Solid State Drive)、USB(Universal Serial Bus)ポートなどである。記録媒体305は、記録媒体I/F304の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体305は、例えば、ディスク、半導体メモリ、USBメモリなどである。記録媒体305は、判定装置100から着脱可能であってもよい。
判定装置100は、上述した構成部の他、例えば、キーボード、マウス、ディスプレイ、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、判定装置100は、記録媒体I/F304や記録媒体305を複数有していてもよい。また、判定装置100は、記録媒体I/F304や記録媒体305を有していなくてもよい。
(稼働テーブル400の記憶内容)
次に、図4を用いて、稼働テーブル400の記憶内容の一例について説明する。稼働テーブル400は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図4を用いて、稼働テーブル400の記憶内容の一例について説明する。稼働テーブル400は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図4は、稼働テーブル400の記憶内容の一例を示す説明図である。図4に示すように、稼働テーブル400は、サーバ名と、日付時刻と、1以上のリソースとのフィールドを有する。稼働テーブル400は、各フィールドに情報を設定することにより、レコード400−aが記憶される。aは、任意の整数である。
サーバ名のフィールドには、業務処理装置201を識別する識別情報としてサーバ名が設定される。日付時刻のフィールドには、業務処理装置201でリソースの使用状況を表す指標値が計測された日付と時刻との組み合わせが設定される。リソースのフィールドには、リソースの使用状況を表す指標値が設定される。指標値は、例えば、リソースの使用量である。
リソースのフィールドは、例えば、CPU使用率[%]のフィールドと、ディスクIO(Input/Output)[IOPS(Input/Output Per Second)]のフィールドとなどである。CPU使用率[%]のフィールドには、業務処理装置201でのCPU1101(図11に後述)の使用状況を表す指標値であるCPU使用率[%]が設定される。ディスクIO[IOPS]のフィールドには、業務処理装置201での記録媒体1105(図11に後述)の使用状況を表す指標値であるディスクIO[IOPS]が設定される。
(日単位テーブル500の記憶内容)
次に、図5を用いて、日単位テーブル500の記憶内容の一例について説明する。日単位テーブル500は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図5を用いて、日単位テーブル500の記憶内容の一例について説明する。日単位テーブル500は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図5は、日単位テーブル500の記憶内容の一例を示す説明図である。図5に示すように、日単位テーブル500は、サーバ名と、日付時刻と、1以上のリソースとのフィールドを有する。日単位テーブル500は、各フィールドに情報を設定することにより、レコード500−bが記憶される。bは、任意の整数である。
日単位テーブル500のレコードは、図4に示した稼働テーブル400のレコードから抽出された、1日分のレコードである。このため、日単位テーブル500のそれぞれのフィールドには、図4に示した稼働テーブル400のそれぞれのフィールドと同様の情報が設定される。また、日単位テーブル500の日付時刻のフィールドには、同日の日付と時刻との組み合わせが設定される。
(ベクトルテーブル600の記憶内容)
次に、図6を用いて、ベクトルテーブル600の記憶内容の一例について説明する。ベクトルテーブル600は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図6を用いて、ベクトルテーブル600の記憶内容の一例について説明する。ベクトルテーブル600は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図6は、ベクトルテーブル600の記憶内容の一例を示す説明図である。図6に示すように、ベクトルテーブル600は、日ごとの稼働データのフィールドを有する。ベクトルテーブル600は、各フィールドに情報を設定することにより、レコード600−cが記憶される。cは、任意の整数である。
日ごとの稼働データのフィールドには、全体の稼働データから日ごとに分割された日単位稼働データをベクトル化して得られたベクトルの要素が設定される。日単位稼働データをベクトル化して得られたベクトルの要素は、日単位稼働データが示す1以上のリソースのそれぞれの使用状況を表す1または複数の指標値のそれぞれである。
(成分テーブル700の記憶内容)
次に、図7を用いて、成分テーブル700の記憶内容の一例について説明する。成分テーブル700は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図7を用いて、成分テーブル700の記憶内容の一例について説明する。成分テーブル700は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図7は、成分テーブル700の記憶内容の一例を示す説明図である。図7に示すように、成分テーブル700は、1以上の成分のフィールドを有する。成分テーブル700は、各フィールドに情報を設定することにより、レコード700−dが記憶される。dは、任意の整数である。
成分のフィールドには、稼働データ行列に対して非負値行列因子分解を実施して得られた基底行列に含まれる基底ベクトルが示すリソースごとの成分データが設定される。成分データは、リソースに関する成分値の集合である。成分のフィールドには、例えば、稼働データ行列に対して非負値行列因子分解を実施して得られた基底行列に含まれる基底ベクトルが示す1または複数の成分値のそれぞれが設定される。
(重みテーブル800の記憶内容)
次に、図8を用いて、重みテーブル800の記憶内容の一例について説明する。重みテーブル800は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図8を用いて、重みテーブル800の記憶内容の一例について説明する。重みテーブル800は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図8は、重みテーブル800の記憶内容の一例を示す説明図である。図8に示すように、重みテーブル800は、成分IDと、日付と、重み係数とのフィールドを有する。重みテーブル800は、各フィールドに情報を設定することにより、レコード800−eが記憶される。eは、任意の整数である。
成分IDのフィールドには、稼働データ行列に対して非負値行列因子分解を実施して得られた重み行列に含まれる重みベクトルの要素である重み係数の係り先である、リソースごとの成分データを示す基底ベクトルを識別するための成分IDが設定される。成分データは、リソースに関する成分値の集合である。成分IDは、基底ベクトルが示すリソースごとの成分データが設定された成分テーブル700の成分フィールドの列番号である。
日付のフィールドには、重みベクトルの要素である重み係数が示す重みが、いつのサービスの利用量に対応するかを識別するための日付が設定される。重み係数のフィールドには、重みベクトルの要素である重み係数が設定される。重み係数は、サービスの重みとして、サービスの利用量に対応する係数を示す。
(サービス利用量テーブル900の記憶内容)
次に、図9を用いて、サービス利用量テーブル900の記憶内容の一例について説明する。サービス利用量テーブル900は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図9を用いて、サービス利用量テーブル900の記憶内容の一例について説明する。サービス利用量テーブル900は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図9は、サービス利用量テーブル900の記憶内容の一例を示す説明図である。図9に示すように、サービス利用量テーブル900は、サービス名と、日付時刻と、サービス利用量とのフィールドを有する。サービス利用量テーブル900は、各フィールドに情報を設定することにより、レコード900−fが記憶される。fは、任意の整数である。
サービス名のフィールドには、サービスを識別する識別情報としてサービス名が設定される。日付時刻のフィールドには、サービスの利用状況を表す指標値が計測された日付と時刻との組み合わせが設定される。サービス利用量のフィールドには、サービスの利用状況を表す指標値が設定される。指標値は、例えば、サービスの利用量である。
(サービス品質テーブル1000の記憶内容)
次に、図10を用いて、サービス品質テーブル1000の記憶内容の一例について説明する。サービス品質テーブル1000は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
次に、図10を用いて、サービス品質テーブル1000の記憶内容の一例について説明する。サービス品質テーブル1000は、例えば、図3に示した判定装置100のメモリ302や記録媒体305などの記憶領域により実現される。
図10は、サービス品質テーブル1000の記憶内容の一例を示す説明図である。図10に示すように、サービス品質テーブル1000は、サービス名と、日付時刻と、サービス品質とのフィールドを有する。サービス品質テーブル1000は、各フィールドに情報を設定することにより、レコード1000−gが記憶される。gは、任意の整数である。
サービス名のフィールドには、サービスを識別する識別情報としてサービス名が設定される。日付時刻のフィールドには、サービスの品質を表す指標値が計測された日付と時刻との組み合わせが設定される。サービス品質のフィールドには、サービスの品質を表す指標値が設定される。指標値は、例えば、リクエスト応答時間[ms]が小さいほど、値が大きくなり、サービスの良さを示す値である。
(業務処理装置201のハードウェア構成例)
業務処理装置201のハードウェア構成例は、図3に示した、判定装置100のハードウェア構成例と同様であるため、説明を省略する。
業務処理装置201のハードウェア構成例は、図3に示した、判定装置100のハードウェア構成例と同様であるため、説明を省略する。
(管理者側装置202のハードウェア構成例)
次に、図11を用いて、図2に示した業務処理システム200に含まれる管理者側装置202のハードウェア構成例について説明する。
次に、図11を用いて、図2に示した業務処理システム200に含まれる管理者側装置202のハードウェア構成例について説明する。
図11は、管理者側装置202のハードウェア構成例を示すブロック図である。図11において、管理者側装置202は、CPU1101と、メモリ1102と、ネットワークI/F1103と、記録媒体I/F1104と、記録媒体1105と、ディスプレイ1106と、入力装置1107とを有する。また、各構成部は、バス1100によってそれぞれ接続される。
ここで、CPU1101は、管理者側装置202の全体の制御を司る。メモリ1102は、例えば、ROM、RAMおよびフラッシュROMなどを有する。具体的には、例えば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU1101のワークエリアとして使用される。メモリ1102に記憶されるプログラムは、CPU1101にロードされることで、コーディングされている処理をCPU1101に実行させる。
ネットワークI/F1103は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して他のコンピュータに接続される。そして、ネットワークI/F1103は、ネットワーク210と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークI/F1103は、例えば、モデムやLANアダプタなどである。
記録媒体I/F1104は、CPU1101の制御に従って記録媒体1105に対するデータのリード/ライトを制御する。記録媒体I/F1104は、例えば、ディスクドライブ、SSD、USBポートなどである。記録媒体1105は、記録媒体I/F1104の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体1105は、例えば、ディスク、半導体メモリ、USBメモリなどである。記録媒体1105は、管理者側装置202から着脱可能であってもよい。
ディスプレイ1106は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ1106は、例えば、CRT(Cathode Ray Tube)、液晶ディスプレイ、有機EL(Electroluminescence)ディスプレイなどである。入力装置1107は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置1107は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。
管理者側装置202は、上述した構成部の他、例えば、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、管理者側装置202は、記録媒体I/F1104や記録媒体1105を複数有していてもよい。また、管理者側装置202は、記録媒体I/F1104や記録媒体1105を有していなくてもよい。
(判定装置100の機能的構成例)
次に、図12を用いて、判定装置100の機能的構成例について説明する。
次に、図12を用いて、判定装置100の機能的構成例について説明する。
図12は、判定装置100の機能的構成例を示すブロック図である。判定装置100は、記憶部1200と、取得部1201と、生成部1202と、第1の特定部1203と、第2の特定部1204と、判定部1205と、出力部1206とを含む。
記憶部1200は、例えば、図3に示したメモリ302や記録媒体305などの記憶領域によって実現される。以下では、記憶部1200が、判定装置100に含まれる場合について説明するが、これに限らない。例えば、記憶部1200が、判定装置100とは異なる装置に含まれ、記憶部1200の記憶内容が判定装置100から参照可能である場合があってもよい。
取得部1201〜出力部1206は、制御部の一例として機能する。取得部1201〜出力部1206は、具体的には、例えば、図3に示したメモリ302や記録媒体305などの記憶領域に記憶されたプログラムをCPU301に実行させることにより、または、ネットワークI/F303により、その機能を実現する。各機能部の処理結果は、例えば、図3に示したメモリ302や記録媒体305などの記憶領域に記憶される。
記憶部1200は、各機能部の処理において参照され、または更新される各種情報を記憶する。記憶部1200は、少なくともいずれかの時点における、サービスに関わるリソースの使用量を記憶する。リソースの使用量は、CPUの使用量、メモリの使用量、または、通信帯域の使用量である。記憶部1200は、具体的には、図4に示した稼働テーブル400を記憶する。
記憶部1200は、少なくともいずれかの時点における、サービスの利用量を記憶する。サービスの利用量は、サービスのアクセス数である。記憶部1200は、具体的には、図9に示したサービス利用量テーブル900を記憶する。記憶部1200は、少なくともいずれかの時点における、サービスの品質値を記憶する。サービスの品質値は、リクエストに対するサービスの応答時間である。記憶部1200は、具体的には、図10に示したサービス品質テーブル1000を記憶する。
記憶部1200は、第1のモデルを記憶する。第1のモデルは、入力された1以上の時点におけるリソースの使用量から予測される将来のいずれかの時点におけるリソースの使用量を出力するモデルである。第1のモデルは、例えば、生成部1202によって生成される。第1のモデルは、例えば、取得部1201によって取得されてもよい。
記憶部1200は、第2のモデルを記憶する。第2のモデルは、入力された1以上の時点におけるサービスの利用量から予測される将来のいずれかの時点におけるサービスの利用量を出力するモデルである。第2のモデルは、例えば、生成部1202によって生成される。第2のモデルは、例えば、取得部1201によって取得されてもよい。
記憶部1200は、第3のモデルを記憶する。第3のモデルは、入力されたリソースの使用量とサービスの利用量とに対応するサービスの品質値を出力するモデルである。第3のモデルは、例えば、生成部1202によって生成される。第3のモデルは、例えば、取得部1201によって取得されてもよい。
取得部1201は、各機能部の処理に用いられる各種情報を取得する。取得部1201は、取得した各種情報を、記憶部1200に記憶し、または、各機能部に出力する。また、取得部1201は、記憶部1200に記憶しておいた各種情報を、各機能部に出力してもよい。取得部1201は、例えば、利用者の操作入力に基づき、各種情報を取得する。取得部1201は、例えば、判定装置100とは異なる装置から、各種情報を受信してもよい。
取得部1201は、いずれかの機能部の処理を開始する開始トリガーを受け付けてもよい。開始トリガーは、例えば、利用者による所定の操作入力があったことである。開始トリガーは、例えば、他のコンピュータから、所定の情報を受信したことであってもよい。開始トリガーは、例えば、いずれかの機能部が所定の情報を出力したことであってもよい。
取得部1201は、リソースの使用量と、サービスの利用量と、サービスの品質値とを取得したことを、生成部1202の処理を開始する開始トリガーとして受け付けてもよい。取得部1201は、リソースの使用量と、サービスの利用量と、サービスの品質値とを取得したことを、第1の特定部1203と、第2の特定部1204と、判定部1205との処理を開始する開始トリガーとして受け付けてもよい。
取得部1201は、サービスに関わるリソースの使用量を取得する。取得部1201は、例えば、生成部1202によって用いられる、複数の時点におけるリソースの使用量を取得する。取得部1201は、具体的には、複数の時点におけるリソースの使用量を、業務処理装置201から収集することにより取得する。
取得部1201は、例えば、第1の特定部1203によって用いられる、1以上の時点におけるリソースの使用量を取得する。取得部1201は、具体的には、1以上の時点におけるリソースの使用量を、業務処理装置201から収集することにより取得する。生成部1202によって用いられる、複数の時点におけるリソースの使用量が、第1の特定部1203によって用いられる、1以上の時点におけるリソースの使用量を包含していてもよい。
取得部1201は、サービスの利用量を取得する。取得部1201は、例えば、生成部1202によって用いられる、複数の時点におけるサービスの利用量を取得する。取得部1201は、具体的には、複数の時点におけるサービスの利用量を、業務処理装置201から収集することにより取得する。
取得部1201は、例えば、第1の特定部1203によって用いられる、1以上の時点におけるサービスの利用量を取得する。生成部1202によって用いられる、複数の時点におけるサービスの利用量が、第1の特定部1203によって用いられる、1以上の時点におけるサービスの利用量を包含していてもよい。取得部1201は、具体的には、リソースの使用量を解析した結果得られるサービスの利用量を取得してもよい。解析する手法の具体例については、例えば、図21〜図25を用いて後述する。
取得部1201は、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。取得部1201は、例えば、生成部1202、第2の特定部1204、または、判定部1205によって用いられる、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得する。取得部1201は、具体的には、過去のいずれかの時点における、特定したリソースの使用量に類似するリソースの使用量と、特定したサービスの利用量に類似するサービスの利用量とに対応付けられた、サービスの品質値を取得する。
取得部1201は、第1のモデルを取得してもよい。取得部1201は、例えば、利用者の操作入力に基づき、第1のモデルを取得する。取得部1201は、第2のモデルを取得してもよい。取得部1201は、例えば、利用者の操作入力に基づき、第2のモデルを取得する。取得部1201は、第3のモデルを取得してもよい。取得部1201は、例えば、利用者の操作入力に基づき、第3のモデルを取得する。
生成部1202は、取得した複数の時点におけるリソースの使用量に基づいて、第1のモデルを生成する。生成部1202は、例えば、取得した複数の時点におけるリソースの使用量に基づいて、自己回帰モデル(例えば、AR,ARMA,ARIMA,SARIMAなど)を用いて、第1のモデルを生成する。第1のモデルを生成する具体例については、例えば、図14〜図17を用いて後述する。
生成部1202は、取得した複数の時点におけるサービスの利用量に基づいて、第2のモデルを生成する。生成部1202は、例えば、取得した複数の時点におけるリソースの使用量に基づいて、自己回帰モデル(例えば、AR,ARMA,ARIMA,SARIMAなど)を用いて、第2のモデルを生成する。第2のモデルを生成する具体例については、例えば、図14〜図17を用いて後述する。
生成部1202は、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、第3のモデルを生成する。生成部1202は、例えば、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、ベクトル自己回帰モデル(例えば、VAR)を用いて、第3のモデルを生成する。第3のモデルを生成する具体例については、例えば、図14〜図17を用いて後述する。
第1の特定部1203は、第1のモデルを用いて、取得した1以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定する。第1の特定部1203は、第1のモデルに、取得した1以上の時点におけるリソースの使用量を入力することにより、将来のいずれかの時点におけるリソースの使用量を特定する。
第1の特定部1203は、第2のモデルを用いて、取得した1以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定する。第1の特定部1203は、例えば、第2のモデルに、取得した1以上の時点におけるサービスの利用量を入力することにより、将来のいずれかの時点におけるサービスの利用量を特定する。
第2の特定部1204は、第3のモデルを用いて、特定したリソースの使用量と特定したサービスの利用量とから予測される、サービスの品質値を特定する。第2の特定部1204は、例えば、第3のモデルに、特定したリソースの使用量と特定したサービスの利用量とを入力することにより、サービスの品質値を特定する。これにより、第2の特定部1204は、将来のいずれかの時点におけるサービスの品質値を特定することができる。
判定部1205は、取得したサービスの品質値と、特定したリソースの使用量と、特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定する。判定部1205は、例えば、取得したサービスの品質値のうち、特定したリソースの使用量に類似する使用量と、特定したサービスの利用量に類似する利用量とに対応付けられた品質値があれば、当該品質値を取得する。類似とは、値が近いことである。類似とは、例えば、値の差分が閾値以下であることである。
そして、判定部1205は、例えば、取得した品質値が閾値未満である場合、サービスに関するアラームを出力すると判定する。アラームは、例えば、サービスの品質値が小さくなる原因を示す情報を含む。一方で、判定部1205は、例えば、取得した品質値が閾値以上である場合、サービスに関するアラームを出力しないと判定する。
判定部1205は、第2の特定部1204が特定したサービスの品質値に基づいて、サービスに関するアラームを出力するか否かを判定する。判定部1205は、例えば、第2の特定部1204が特定したサービスの品質値が閾値未満である場合、サービスに関するアラームを出力すると判定する。アラームは、例えば、サービスの品質値が小さくなる原因を示す情報を含む。一方で、判定部1205は、例えば、第2の特定部1204が特定したサービスの品質値が閾値以上である場合、サービスに関するアラームを出力しないと判定する。
出力部1206は、いずれかの機能部の処理結果を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークI/F303による外部装置への送信、または、メモリ302や記録媒体305などの記憶領域への記憶である。これにより、出力部1206は、いずれかの機能部の処理結果を利用者に通知可能にし、判定装置100の利便性の向上を図ることができる。
出力部1206は、アラームを出力すると判定した場合、アラームを出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークI/F303による外部装置への送信、または、メモリ302や記録媒体305などの記憶領域への記憶である。出力部1206は、例えば、アラームを、管理者側装置202に送信する。これにより、出力部1206は、システム管理者が、アラームを把握可能にし、将来的にサービスの品質が悪化するおそれがあることを把握可能にすることができる。
(判定装置100の具体的な機能的構成例)
次に、図13を用いて、判定装置100の具体的な機能的構成例について説明する。
次に、図13を用いて、判定装置100の具体的な機能的構成例について説明する。
図13は、判定装置100の具体的な機能的構成例を示すブロック図である。判定装置100は、業務処理装置201により形成される、仮想環境および物理環境を監視している。仮想環境および物理環境において、サービスが実現されている。
判定装置100は、サービス判定部1301と、サービス性能監視部1302と、インフラ監視部1303と、サービス品質モデル化部1304と、サービス品質予測部1305と、インフラ制御部1306とを含む。
サービス判定部1301は、図14に後述するように、業務処理装置201と通信し、サービスの利用量を取得する。サービス判定部1301は、例えば、稼働中のサービスを判定し、稼働中のサービスの利用量を取得する。利用量は、例えば、単位時間あたりのサービス稼働率である。サービス判定部1301は、図21〜図25に後述するように、稼働中のサービスの利用量として、重み係数を算出する場合があってもよい。
サービス性能監視部1302は、図14に後述するように、業務処理装置201と通信し、サービスの品質値を取得する。サービス性能監視部1302は、具体的には、サービスが、webサービスであれば、サービスの品質値として、リクエストへの遅延時間に基づく、サービスの良さを示す指標値を取得する。サービス性能監視部1302は、具体的には、サービスが、ファイルサーバサービスであれば、サービスの品質値として、スループットに基づく、サービスの良さを示す指標値を取得する。サービス性能監視部1302は、具体的には、サービスが、ファイルサーバサービスであれば、サービスの品質値として、パケットロス率に基づく、サービスの良さを示す指標値を取得する。
インフラ監視部1303は、図14に後述するように、業務処理装置201と通信し、インフラリソースの使用量を取得する。サービス品質モデル化部1304は、図14〜図17に後述するように、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを生成する。サービス品質予測部1305は、インフラリソース推定モデルと、サービス利用量推定モデルと、サービス品質推定モデルとを用いて、将来的なサービスの品質値を取得する。
インフラ制御部1306は、将来のサービスの品質値に基づいて、アラームを出力する。この際、インフラ制御部1306は、将来のサービスの品質値の低下の原因と判断されるインフラリソースを特定し、特定したインフラリソースに関する情報を、アラームに含めてもよい。インフラ制御部1306は、例えば、JITモデリングを用いて、将来のサービスの品質値の低下の原因と判断されるインフラリソースを特定する。JITモデリングについては、例えば、下記参考文献2、および、下記参考文献3などを参照することができる。
参考文献2 : Stenman, A., Gustafsson, F. and Ljung, L.: “Just In Time Models For Dynamical Systems”, in Proc. 35th Conf. Decision and Control, Dec. 1115/1120 (1996)
参考文献3 : 牛田俊,木村英紀: “Just−In−Timeモデリング技術を用いた非線形システムの同定と制御”, 計測と制御, Vol.44, No.2, 102/106 (2005)
(判定装置100がアラームの出力要否を判定する一例)
次に、図14〜図20を用いて、判定装置100がアラームの出力要否を判定する一例について説明する。
次に、図14〜図20を用いて、判定装置100がアラームの出力要否を判定する一例について説明する。
図14〜図20は、判定装置100がアラームの出力要否を判定する一例を示す説明図である。図14において、サービス判定部1301は、業務処理装置201と通信し、稼働中のサービスを判定し、稼働中のサービスの利用量を取得する。利用量は、例えば、単位時間あたりのサービス稼働率である。図14の例では、サービス判定部1301は、グラフ1420における点線丸印に示すような、複数の時点のそれぞれの時点のサービスの利用量を取得する。
サービス判定部1301は、図21〜図25に後述するように、稼働中のサービスの利用量として、重み係数を算出する場合があってもよい。ここで、業務処理システム200におけるサービスの性質としては、例えば、以下の2つの性質が考えられる。
例えば、サービスの利用量が、分、時間、日、週、または、月などの所定の時間間隔で周期的な変化傾向を示すという第1の性質が考えられる。また、例えば、1以上のサービスのそれぞれの利用量に基づき、1以上のリソースのそれぞれの使用状況が決定するという第2の性質が考えられる。
上記性質によれば、異なるリソースのそれぞれの使用状況を表す指標値の時間変化を示す時系列データの中で、同じサービスに対応する成分データは、所定の時間間隔での周期的な変化傾向が互いに類似するような成分データになることが考えられる。また、上記性質によれば、1以上のリソースのそれぞれの使用状況を表す指標値が、1以上のサービスのそれぞれの利用量に比例するという負荷モデルが考えられる。このため、サービス判定部1301は、上記負荷モデルを利用すれば、所定の時間間隔での、サービスごとの利用量に関わる情報を取得可能になる。
サービス性能監視部1302は、業務処理装置201と通信し、サービスの品質値を取得する。図14の例では、サービス性能監視部1302は、グラフ1430における点線丸印に示すような、複数の時点のそれぞれの時点のサービスの品質値を取得する。インフラ監視部1303は、業務処理装置201と通信し、インフラリソースの使用量を取得する。図14の例では、インフラ監視部1303は、グラフ1410における点線丸印に示すような、複数の時点のそれぞれの時点のインフラリソースの使用量を取得する。
サービス品質モデル化部1304は、インフラリソース推定モデルを生成する。インフラリソース推定モデルは、時系列推定モデルである。図14の例では、インフラリソース推定モデルは、グラフ1410の実線に示すような、時系列推定モデルである。サービス品質モデル化部1304は、例えば、範囲1411のいくつかのインフラリソースの使用量に基づいて、インフラリソース推定モデルを生成する。
同様に、サービス品質モデル化部1304は、サービス利用量推定モデルを生成する。サービス利用量推定モデルは、時系列推定モデルである。図14の例では、サービス利用量推定モデルは、グラフ1420の実線に示すような、時系列推定モデルである。サービス品質モデル化部1304は、例えば、範囲1421のいくつかのサービスの利用量に基づいて、サービス利用量推定モデルを生成する。
サービス品質モデル化部1304は、サービス品質推定モデルを生成する。図14の例では、サービス品質推定モデルは、時点1431のインフラリソースの使用量とサービスの利用量とに基づいて、品質値1432を推定可能にする推定モデルである。サービス品質推定モデルは、例えば、関数f(インフラリソースの使用量、サービスの利用量)である。ここで、図15の説明に移行し、サービス品質モデル化部1304が、インフラリソース推定モデルを生成する具体例について説明する。
図15において、サービス品質モデル化部1304は、図4に示した稼働テーブル400を参照して、サービスに関わるインフラリソースの使用量を取得し、表1500に設定する。そして、サービス品質モデル化部1304は、複数時系列データ間の相互影響をモデル化するベクトル自己回帰モデル(VAR)を用いて、下記式(1)で規定される、インフラリソース推定モデルを生成する。
yt=c+φ1yt-1+・・・+φpyt-p+εt,εi,t〜N(0,σi 2) ・・・(1)
上記式(1)において、yt∈Rn×1は、時点tにおけるn個の変数(インフラリソースの使用量)を並べたベクトルである。c∈Rn×1は、定数ベクトルである。φi∈Rn×nは、係数行列である。εt∈Rn×1は、誤差ベクトルである。
サービス品質モデル化部1304は、例えば、表1500の要素を、それぞれ、t,y1,t,y2,t,y3,t,y4,t,・・・として利用し、上記式(1)のパラメータp,c,φi,σiを算出する。これにより、サービス品質モデル化部1304は、サービス利用量推定モデルを生成することができる。ここで、図16の説明に移行し、サービス品質モデル化部1304が、サービス利用量推定モデルを生成する具体例について説明する。
図16において、サービス品質モデル化部1304は、図9に示したサービス利用量テーブル900を参照して、サービスの利用量を取得し、表1600に設定する。そして、サービス品質モデル化部1304は、自己回帰モデル(AR,ARMA,ARIMA,SARIMAなど)を用いて、下記式(2)で規定される、サービス利用量推定モデルを生成する。
yt=c+Σi=1 p(φiyt-i)+εt+Σj=1 q(θjεt-jεt〜N(0,σ2)) ・・・(2)
上記式(2)において、ytは、時点tにおける変数(サービスの利用量)である。cは、定数である。φiは、i次の自己回帰係数である。θiは、i次の移動平均係数である。サービス品質モデル化部1304は、例えば、表1600の要素を、それぞれ、t,ytとして利用し、上記式(2)のパラメータp,q,c,φi,θi,σを算出する。これにより、サービス品質モデル化部1304は、サービス利用量推定モデルを生成することができる。ここで、図17の説明に移行し、サービス品質モデル化部1304が、サービス品質推定モデルを生成する具体例について説明する。
図17において、サービス品質モデル化部1304は、図4に示した稼働テーブル400と、図9に示したサービス利用量テーブル900と、図10に示したサービス品質テーブル1000とを参照して、表1700を生成する。そして、サービス品質モデル化部1304は、JITモデリング(局所回帰モデル)を用いて、下記式(3)で規定される、サービス品質推定モデルを生成する。
y^=b+Σm=1 M(amxn) ・・・(3)
上記式(3)において、y^は、サービスの品質値の予測値である。bは、定数である。amは、係数である。xmは、入力データである。入力データは、インフラリソースの使用量と、サービスの利用量とである。Mは、入力データの数であり、インフラリソースの数+1である。サービス品質モデル化部1304は、例えば、表1700の要素を、入力データとして利用し、上記式(3)のパラメータb,amを算出する。これにより、サービス品質モデル化部1304は、サービス品質推定モデルを生成することができる。次に、図18の説明に移行する。
図18において、サービス品質予測部1305は、インフラリソース推定モデルを用いて、現時点以降の範囲1800のそれぞれの時点における、将来のインフラリソースの使用量を推定する。サービス品質予測部1305は、サービス利用量推定モデルを用いて、現時点以降の範囲1800のそれぞれの時点における、将来のサービスの利用量を推定する。
サービス品質予測部1305は、サービス品質推定モデルを用いて、範囲1800のそれぞれの時点における、将来のインフラリソースの使用量と、将来のサービスの利用量との組み合わせに対応する、将来のサービスの品質値の予測値を算出する。図18の例では、予測値は、太線丸印で示される。サービス品質予測部1305が、将来のサービスの品質値の予測値を算出する詳細については、図19および図20を用いて後述する。
インフラ制御部1306は、将来のサービスの品質値の予測値に基づいて、アラームの出力要否を判定する。インフラ制御部1306は、例えば、将来のサービスの品質値の予測値に基づいて、将来のサービスの品質値の予測値が閾値未満となる期間があるか否かを判定する。インフラ制御部1306は、将来のサービスの品質値の予測値が閾値未満となる期間がある場合、アラームを出力すると判定し、アラームを出力する。一方で、インフラ制御部1306は、将来のサービスの品質値の予測値が閾値未満となる期間がない場合、アラームを出力しないと判定する。次に、図19の説明に移行する。
図19に示すように、サービス品質予測部1305は、具体的には、インフラリソース推定モデルに、表1900のインフラリソースの使用量の情報1910を入力することにより、将来のインフラリソースの使用量の情報1911を取得する。また、サービス品質予測部1305は、具体的には、サービス利用量推定モデルに、表1900のサービスの利用量の情報1920を入力することにより、将来のサービスの利用量の情報1921を取得する。
サービス品質予測部1305は、具体的には、サービス品質推定モデルに、将来の時点「2019−01−01 00:03:00」における、インフラリソースの使用量と、サービスの利用量との情報1931を入力する。これにより、サービス品質予測部1305は、同じ時点「2019−01−01 00:03:00」における、サービスの品質値の予測値1941を取得する。
同様に、サービス品質予測部1305は、具体的には、サービス品質推定モデルに、将来の時点「2019−01−01 00:03:30」における、インフラリソースの使用量と、サービスの利用量との情報1932を入力する。これにより、サービス品質予測部1305は、同じ時点「2019−01−01 00:03:30」における、サービスの品質値の予測値1942を取得する。
同様に、サービス品質予測部1305は、具体的には、サービス品質推定モデルに、将来の時点「2019−01−01 00:04:00」における、インフラリソースの使用量と、サービスの利用量との情報1933を入力する。これにより、サービス品質予測部1305は、同じ時点「2019−01−01 00:04:00」における、サービスの品質値の予測値1943を取得する。
これにより、判定装置100は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。このため、システム管理者は、サービスの品質が悪化する前に、サービスの品質が悪化した原因であるいずれかのリソースを特定し、特定したリソースに対処する作業を開始することができる。
結果として、システム管理者は、サービスの品質が悪化してから、サービスの品質が回復するまでにかかる所要時間の低減化を図ることができる。また、システム管理者は、サービスの品質が悪化することを防止することができる場合がある。そして、システム管理者は、サービスの利便性の低下を防止または抑制することができる。また、システム管理者は、サービス管理者にかかる作業負担の低減化を図ることができる。また、判定装置100は、システム管理者にかかる作業負担の低減化を図ることができる。
ここでは、サービス品質予測部1305が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定する前に、サービス品質推定モデルが生成される場合について説明したが、これに限らない。例えば、サービス品質予測部1305が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定した後に、サービス品質推定モデルが生成される場合があってもよい。
ここで、図20の説明に移行し、サービス品質予測部1305が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定した後に、サービス品質推定モデルが生成される場合について説明する。
図20において、サービス品質予測部1305が、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定済みであるとする。この場合、サービス品質モデル化部1304は、サービス品質推定モデルを生成するにあたり、推定された将来のインフラリソースの使用量に類似する使用量と、推定された将来のサービスの利用量に類似する利用量とを利用するようにする。
サービス品質モデル化部1304は、具体的には、上述した表1700の中から、推定された将来のインフラリソースの使用量に類似する使用量と、推定された将来のサービスの利用量に類似する利用量と、サービスの品質値とを対応付けたレコードを抽出する。そして、サービス品質モデル化部1304は、具体的には、抽出したレコードに基づいて、サービス品質推定モデルを生成する。
ここで、図20のグラフ2000のデータ軸上に、推定された将来のインフラリソースの使用量と、推定された将来のサービスの利用量との組み合わせに対応するデータ2001を示す。サービス品質モデル化部1304は、座標2002〜2004に対応する、データ2001の近傍に存在する入力データを含むレコードを用いて、直線2010に近似されるようなサービス品質推定モデルを生成することができる。
これにより、サービス品質モデル化部1304は、データ2001の近傍における、インフラリソースの使用量と、サービスの利用量と、サービスの品質値との関係性を、比較的精度よく表す、局所的なサービス品質推定モデルを生成することができる。このため、サービス品質モデル化部1304は、サービスの品質値の予測値を精度よく取得可能にすることができる。
(判定装置100が重み係数を算出する一例)
次に、図21〜図25を用いて、判定装置100が重み係数を算出する一例について説明する。
次に、図21〜図25を用いて、判定装置100が重み係数を算出する一例について説明する。
図21〜図25は、判定装置100が重み係数を算出する一例を示す説明図である。図21〜図25の例では、業務処理システム200に、業務処理装置201として、サーバAP01およびサーバDB01が含まれる場合について説明する。
リソースの指標値は、CPU使用率やディスクIOである。指標値は、0〜1の間で正規化される。指標値のサンプリング間隔は、例えば、1時間である。1日のサンプリング数は、24になる。サービス判定部1301は、2018/1/1〜2018/3/31までの90日分に対応する稼働データを取得し、稼働テーブル400に記憶する。ここで、図21の説明に移行し、稼働データにおけるリソースごとの指標値の変化傾向について説明する。稼働データは、曜日ごとに周期性を有する。
図21において、サービス判定部1301は、稼働テーブル400に記憶された稼働データを、1日単位に分解し、日単位稼働データを生成する。サービス判定部1301は、例えば、日付「20180101」の日単位稼働データ、および、日付「20180102」の日単位稼働データなどを生成し、日単位テーブル500を用いて記憶する。次に、図22の説明に移行する。
図22において、サービス判定部1301は、日単位稼働データをベクトル化する。サービス判定部1301は、例えば、日単位テーブル500に記憶された日単位稼働データが示す1または複数の指標値を、所定の規則に従って、要素として並べてベクトル化し、ベクトルテーブル600を用いて記憶する。
日付「20180101」の日単位稼働データは、例えば、ベクトルx1としてベクトルテーブル600に記憶される。日付「20180102」の日単位稼働データは、例えば、ベクトルx2としてベクトルテーブル600に記憶される。ベクトルの次元は、96次元になる。次に、図23の説明に移行する。
図23において、サービス判定部1301は、ベクトルテーブル600を参照し、90日の各日に対応するベクトルx1,x2,・・・,x90を列とした稼働データ行列X=(x1,x2,・・・,x90)を生成する。稼働データ行列Xは、96×90の行列である。サービス判定部1301は、下記式(4)を利用し、稼働データ行列Xに対して非負値行列因子分解を実施し、基底行列Uと重み行列Aとを生成する。
サービス判定部1301は、例えば、下記式(4)を最小化する重みAと基底Uを推定することになる。||z||FROは、フロベニウスノルムである。α||A||1およびβ||U||1の項が、Sparseness Constraintsである。下記式(4)のα=β=0.01とする。
(A*,U*)=argminA,U(1/2||X−UA||FRO 2)+α||A||1+β||U||1 ・・・(4)
この際、サービス判定部1301は、基底数=3を予め設定済みであり、基底行列U=(u1,u2,u3)と規定する。基底行列Uは、96×3の行列である。また、サービス判定部1301は、重み行列A=(a1,a2,a3)=(aij)と規定する。重み行列Aは、3×90の行列である。
結果として、サービス判定部1301は、グラフ2301〜2303に示すような基底ベクトルu1,u2,u3を含む基底行列Uを生成する。また、サービス判定部1301は、グラフ2311〜2313に示すような重みベクトルa1,a2,a3を含む重み行列Aを生成する。重みベクトルa1=(a1,1,・・・,a1,90)である。重みベクトルa2=(a2,1,・・・,a2,90)である。重みベクトルa3=(a3,1,・・・,a3,90)である。
ここでは、基底数が予め設定済みである場合について説明したが、これに限らない。例えば、基底数として、稼働データ行列を形成するベクトルの次元数を用いる場合があってもよい。この場合、上記式(4)のα||A||1およびβ||U||1の項により、業務処理単位の成分データとして好ましくない基底ベクトルにかかる重み係数が0になる傾向がある。このため、サービス判定部1301は、重み係数の和が0になる重みベクトルaiに対応する基底ベクトルuiを除外することにより、精度よく基底行列Uを生成可能である。次に、図24の説明に移行する。
図24において、サービス判定部1301は、生成した基底行列の基底ベクトルを、成分テーブル700を用いて記憶する。基底ベクトルの次元は、稼働データ行列を形成するベクトルと同様に、96次元になる。次に、図25の説明に移行する。
図25において、サービス判定部1301は、生成した重み行列の重みベクトルを、重みテーブル800を用いて記憶する。重みベクトルの次元は、日数に対応し、90次元になる。これにより、サービス判定部1301は、サービスの利用量に対応する重み係数を取得することができる。このため、サービス判定部1301は、サービスごとに利用量を直接計測することが難しい状況にも、アラームの出力要否を判定可能にすることができる。
ここでは、判定装置100が、日ごとの重み係数を算出する場合について説明したが、これに限らない。例えば、サービス判定部1301は、他の所定間隔単位の重み係数を算出する場合があってもよい。具体的には、サービス判定部1301は、30分単位の重み係数を算出する場合があってもよい。
(全体処理手順)
次に、図26を用いて、判定装置100が実行する、全体処理手順の一例について説明する。全体処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
次に、図26を用いて、判定装置100が実行する、全体処理手順の一例について説明する。全体処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
図26は、全体処理手順の一例を示すフローチャートである。判定装置100は、稼働中のサービスを特定する(ステップS2601)。次に、判定装置100は、稼働中のサービスの品質値を収集する(ステップS2602)。そして、判定装置100は、稼働中のサービスの利用量を収集する(ステップS2603)。
次に、判定装置100は、インフラリソースの稼働データを収集する(ステップS2604)。そして、判定装置100は、インフラ使用量時系列モデルと、サービス利用量時系列モデルと、サービス品質値推定モデルとを生成する(ステップS2605)。
次に、判定装置100は、将来のサービスの品質値を予測する(ステップS2606)。判定装置100は、例えば、インフラ使用量時系列モデルと、サービス利用量時系列モデルとを用いて、将来のインフラリソースの使用量と、将来のサービスの利用量とを推定する。判定装置100は、例えば、サービス品質値推定モデルを用いて、推定した将来のインフラリソースの使用量と、推定した将来のサービスの利用量との組み合わせに対応する、将来のサービスの品質値を推定する。
そして、判定装置100は、将来のサービスの品質値<閾値であるか否かを判定する(ステップS2607)。ここで、将来のサービスの品質値<閾値ではない場合(ステップS2607:No)、判定装置100は、全体処理を終了する。一方で、将来のサービスの品質値<閾値である場合(ステップS2607:Yes)、判定装置100は、ステップS2608の処理に移行する。
ステップS2608では、判定装置100は、将来のサービスの品質値の低下の原因となるインフラリソースを出力する(ステップS2608)。そして、判定装置100は、全体処理を終了する。これにより、判定装置100は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
ここで、判定装置100は、ステップS2605の処理として、具体的には、図27に後述するモデル生成処理を実行してもよい。また、判定装置100は、ステップS2606〜S2608の処理として、具体的には、図28に後述する解析処理を実行してもよい。
(モデル生成処理手順)
次に、図27を用いて、判定装置100が実行する、モデル生成処理手順の一例について説明する。モデル生成処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
次に、図27を用いて、判定装置100が実行する、モデル生成処理手順の一例について説明する。モデル生成処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
図27は、モデル生成処理手順の一例を示すフローチャートである。判定装置100は、稼働中の各サービスに関わるインフラリソースを特定する(ステップS2701)。そして、判定装置100は、インフラリソースの稼働データのうち、特定したインフラリソースの使用量に基づいて、インフラ使用量時系列モデルを生成する(ステップS2702)。
次に、判定装置100は、サービスの利用量に基づいて、サービス利用量時系列モデルを生成する(ステップS2703)。そして、判定装置100は、特定したインフラリソースの使用量と、サービスの利用量と、サービスの品質値とに基づいて、サービス品質値推定モデルを生成する(ステップS2704)。その後、判定装置100は、モデル生成処理を終了する。これにより、判定装置100は、各種モデルを生成することができる。
(解析処理手順)
次に、図28を用いて、判定装置100が実行する、解析処理手順の一例について説明する。解析処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
次に、図28を用いて、判定装置100が実行する、解析処理手順の一例について説明する。解析処理は、例えば、図3に示したCPU301と、メモリ302や記録媒体305などの記憶領域と、ネットワークI/F303とによって実現される。
図28は、解析処理手順の一例を示すフローチャートである。図28において、判定装置100は、サービスの品質値を予測する(ステップS2801)。次に、判定装置100は、サービスの品質値が閾値より小さくなる時期を特定する(ステップS2802)。
そして、判定装置100は、サービスの品質値が閾値より小さくなる時期があるか否かを判定する(ステップS2803)。ここで、サービスの品質値が閾値より小さくなる時期がない場合(ステップS2803:No)、判定装置100は、解析処理を終了する。一方で、サービスの品質値が閾値より小さくなる時期がある場合(ステップS2803:Yes)、判定装置100は、ステップS2804の処理に移行する。
ステップS2804では、判定装置100は、サービスの品質値が閾値より小さくなる時期と、サービスに関わるインフラリソースとを対応付けて出力する(ステップS2804)。そして、判定装置100は、解析処理を終了する。これにより、判定装置100は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
以上説明したように、判定装置100によれば、1以上の時点における所定のサービスに関わるリソースの使用量を取得することができる。判定装置100によれば、1以上の時点におけるサービスの利用量を取得することができる。判定装置100によれば、少なくとも過去のいずれかの時点における、リソースの使用量とサービスの利用量とに対応付けられたサービスの品質値を取得することができる。判定装置100によれば、第1のモデルを用いて、取得した1以上の時点におけるリソースの使用量から予測される、将来のいずれかの時点におけるリソースの使用量を特定することができる。判定装置100によれば、第2のモデルを用いて、取得した1以上の時点におけるサービスの利用量から予測される、将来のいずれかの時点におけるサービスの利用量を特定することができる。判定装置100によれば、取得したサービスの品質値と特定したリソースの使用量と特定したサービスの利用量とに基づいて、サービスに関するアラームを出力するか否かを判定することができる。これにより、判定装置100は、将来的にサービスの品質が悪化するのか否かに基づいて、アラームを出力するか否かを判定することができる。
判定装置100によれば、取得した過去のいずれかの時点におけるサービスの品質値に基づいて、第3のモデルを生成することができる。判定装置100によれば、生成した第3のモデルを用いて、特定したリソースの使用量と特定したサービスの利用量とから予測される、サービスの品質値を特定することができる。判定装置100によれば、特定したサービスの品質値に基づいて、サービスに関するアラームを出力するか否かを判定することができる。これにより、判定装置100は、将来の品質値を精度よく推定することができ、将来的にサービスの品質が悪化するのか否かを精度よく判定することができる。
判定装置100によれば、過去のいずれかの時点における、特定したリソースの使用量に類似するリソースの使用量と、特定したサービスの利用量に類似するサービスの利用量とに対応付けられた、サービスの品質値を取得することができる。これにより、判定装置100は、将来の品質値を精度よく推定可能な第3のモデルを生成することができる。
判定装置100によれば、複数の時点におけるリソースの使用量を取得することができる。判定装置100によれば、複数の時点におけるサービスの利用量を取得することができる。判定装置100によれば、取得した複数の時点におけるリソースの使用量に基づいて、第1のモデルを生成することができる。判定装置100によれば、取得した複数の時点におけるサービスの利用量に基づいて、第2のモデルを生成することができる。これにより、判定装置100は、システム管理者が、第1のモデルと第2のモデルとを用意せずに済ませることができ、システム管理者にかかる作業負担の低減化を図ることができる。
判定装置100によれば、特定したサービスの品質値が閾値未満である場合、サービスに関するアラームを出力すると判定することができる。これにより、判定装置100は、閾値判定により、将来的にサービスの品質が悪化するのか否かを判定しやすくすることができる。
判定装置100によれば、アラームに、サービスの品質値が小さくなる原因を示す情報を含めることができる。これにより、判定装置100は、システム管理者が、サービスの品質値が小さくなる原因に対処しやすくすることができ、システム管理者にかかる作業負担の低減化を図ることができる。
判定装置100によれば、アラームを出力すると判定した場合、アラームを出力することができる。これにより、判定装置100は、システム管理者が、将来的にサービスの品質が悪化するのか否かを把握可能にすることができる。
なお、本実施の形態で説明した判定方法は、予め用意されたプログラムをPCやワークステーションなどのコンピュータで実行することにより実現することができる。本実施の形態で説明した判定プログラムは、コンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。記録媒体は、ハードディスク、フレキシブルディスク、CD(Compact Disc)−ROM、MO(Magneto Optical disc)、DVD(Digital Versatile Disc)などである。また、本実施の形態で説明した判定プログラムは、インターネットなどのネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)1以上の時点における所定のサービスに関わるリソースの使用量を取得し、
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータが実行することを特徴とする判定方法。
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータが実行することを特徴とする判定方法。
(付記2)取得した前記過去のいずれかの時点における前記サービスの品質値に基づいて、入力された前記リソースの使用量と前記サービスの利用量とに対応する前記サービスの品質値を出力する第3のモデルを生成し、
生成した前記第3のモデルを用いて、特定した前記リソースの使用量と特定した前記サービスの利用量とから予測される、前記サービスの品質値を特定する、処理を前記コンピュータが実行し、
前記判定する処理は、
特定した前記サービスの品質値に基づいて、前記サービスに関するアラームを出力するか否かを判定する、ことを特徴とする付記1に記載の判定方法。
生成した前記第3のモデルを用いて、特定した前記リソースの使用量と特定した前記サービスの利用量とから予測される、前記サービスの品質値を特定する、処理を前記コンピュータが実行し、
前記判定する処理は、
特定した前記サービスの品質値に基づいて、前記サービスに関するアラームを出力するか否かを判定する、ことを特徴とする付記1に記載の判定方法。
(付記3)前記サービスの品質値を取得する処理は、
過去のいずれかの時点における、特定した前記リソースの使用量に類似する前記リソースの使用量と、特定した前記サービスの利用量に類似する前記サービスの利用量とに対応付けられた、前記サービスの品質値を取得する、ことを特徴とする付記1または2に記載の判定方法。
過去のいずれかの時点における、特定した前記リソースの使用量に類似する前記リソースの使用量と、特定した前記サービスの利用量に類似する前記サービスの利用量とに対応付けられた、前記サービスの品質値を取得する、ことを特徴とする付記1または2に記載の判定方法。
(付記4)複数の時点における前記リソースの使用量を取得し、
複数の時点における前記サービスの利用量を取得し、
取得した複数の時点における前記リソースの使用量に基づいて、前記第1のモデルを生成し、
取得した複数の時点における前記サービスの利用量に基づいて、前記第2のモデルを生成する、処理を前記コンピュータが実行することを特徴とする付記1〜3のいずれか一つに記載の判定方法。
複数の時点における前記サービスの利用量を取得し、
取得した複数の時点における前記リソースの使用量に基づいて、前記第1のモデルを生成し、
取得した複数の時点における前記サービスの利用量に基づいて、前記第2のモデルを生成する、処理を前記コンピュータが実行することを特徴とする付記1〜3のいずれか一つに記載の判定方法。
(付記5)前記判定する処理は、特定した前記サービスの品質値が閾値未満である場合、前記サービスに関するアラームを出力すると判定する、ことを特徴とする付記1〜4のいずれか一つに記載の判定方法。
(付記6)前記アラームは、前記サービスの品質値が小さくなる原因を示す情報を含む、ことを特徴とする付記1〜5のいずれか一つに記載の判定方法。
(付記7)前記アラームを出力すると判定した場合、前記アラームを出力する、処理を前記コンピュータが実行することを特徴とする付記1〜6のいずれか一つに記載の判定方法。
(付記8)1以上の時点における所定のサービスに関わるリソースの使用量を取得し、
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータに実行させることを特徴とする判定プログラム。
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータに実行させることを特徴とする判定プログラム。
100 判定装置
101,102 モデル
200 業務処理システム
201 業務処理装置
202 管理者側装置
210 ネットワーク
220 サービス実行基盤
300,1100 バス
301,1101 CPU
302,1102 メモリ
303,1103 ネットワークI/F
304,1104 記録媒体I/F
305,1105 記録媒体
400 稼働テーブル
500 日単位テーブル
600 ベクトルテーブル
700 成分テーブル
800 重みテーブル
900 サービス利用量テーブル
1000 サービス品質テーブル
1106 ディスプレイ
1107 入力装置
1200 記憶部
1201 取得部
1202 生成部
1203 第1の特定部
1204 第2の特定部
1205 判定部
1206 出力部
1301 サービス判定部
1302 サービス性能監視部
1303 インフラ監視部
1304 サービス品質モデル化部
1305 サービス品質予測部
1306 インフラ制御部
1410,1420,1430,2000,2301〜2303,2311〜2313 グラフ
1411,1421,1800 範囲
1431 時点
1432 品質値
1500,1600,1700,1900 表
1910,1911,1920,1921,1931〜1933 情報
1941〜1943 予測値
2001 データ
2002〜2004 座標
2010 直線
101,102 モデル
200 業務処理システム
201 業務処理装置
202 管理者側装置
210 ネットワーク
220 サービス実行基盤
300,1100 バス
301,1101 CPU
302,1102 メモリ
303,1103 ネットワークI/F
304,1104 記録媒体I/F
305,1105 記録媒体
400 稼働テーブル
500 日単位テーブル
600 ベクトルテーブル
700 成分テーブル
800 重みテーブル
900 サービス利用量テーブル
1000 サービス品質テーブル
1106 ディスプレイ
1107 入力装置
1200 記憶部
1201 取得部
1202 生成部
1203 第1の特定部
1204 第2の特定部
1205 判定部
1206 出力部
1301 サービス判定部
1302 サービス性能監視部
1303 インフラ監視部
1304 サービス品質モデル化部
1305 サービス品質予測部
1306 インフラ制御部
1410,1420,1430,2000,2301〜2303,2311〜2313 グラフ
1411,1421,1800 範囲
1431 時点
1432 品質値
1500,1600,1700,1900 表
1910,1911,1920,1921,1931〜1933 情報
1941〜1943 予測値
2001 データ
2002〜2004 座標
2010 直線
Claims (7)
- 1以上の時点における所定のサービスに関わるリソースの使用量を取得し、
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータが実行することを特徴とする判定方法。 - 取得した前記過去のいずれかの時点における前記サービスの品質値に基づいて、入力された前記リソースの使用量と前記サービスの利用量とに対応する前記サービスの品質値を出力する第3のモデルを生成し、
生成した前記第3のモデルを用いて、特定した前記リソースの使用量と特定した前記サービスの利用量とから予測される、前記サービスの品質値を特定する、処理を前記コンピュータが実行し、
前記判定する処理は、
特定した前記サービスの品質値に基づいて、前記サービスに関するアラームを出力するか否かを判定する、ことを特徴とする請求項1に記載の判定方法。 - 前記サービスの品質値を取得する処理は、
過去のいずれかの時点における、特定した前記リソースの使用量に類似する前記リソースの使用量と、特定した前記サービスの利用量に類似する前記サービスの利用量とに対応付けられた、前記サービスの品質値を取得する、ことを特徴とする請求項1または2に記載の判定方法。 - 複数の時点における前記リソースの使用量を取得し、
複数の時点における前記サービスの利用量を取得し、
取得した複数の時点における前記リソースの使用量に基づいて、前記第1のモデルを生成し、
取得した複数の時点における前記サービスの利用量に基づいて、前記第2のモデルを生成する、処理を前記コンピュータが実行することを特徴とする請求項1〜3のいずれか一つに記載の判定方法。 - 前記判定する処理は、特定した前記サービスの品質値が閾値未満である場合、前記サービスに関するアラームを出力すると判定する、ことを特徴とする請求項1〜4のいずれか一つに記載の判定方法。
- 前記アラームは、前記サービスの品質値が小さくなる原因を示す情報を含む、ことを特徴とする請求項1〜5のいずれか一つに記載の判定方法。
- 1以上の時点における所定のサービスに関わるリソースの使用量を取得し、
1以上の時点における前記サービスの利用量を取得し、
少なくとも過去のいずれかの時点における、前記リソースの使用量と前記サービスの利用量とに対応付けられた前記サービスの品質値を取得し、
入力された1以上の時点における前記リソースの使用量から予測される将来のいずれかの時点における前記リソースの使用量を出力する第1のモデルを用いて、取得した1以上の時点における前記リソースの使用量から予測される、将来のいずれかの時点における前記リソースの使用量を特定し、
入力された1以上の時点における前記サービスの利用量から予測される将来のいずれかの時点における前記サービスの利用量を出力する第2のモデルを用いて、取得した1以上の時点における前記サービスの利用量から予測される、前記将来のいずれかの時点における前記サービスの利用量を特定し、
取得した前記サービスの品質値と特定した前記リソースの使用量と特定した前記サービスの利用量とに基づいて、前記サービスに関するアラームを出力するか否かを判定する、
処理をコンピュータに実行させることを特徴とする判定プログラム。
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)
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)
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 | ネットワーク監視装置、ネットワーク監視システム、ネットワーク監視方法、及びプログラム |
JPWO2016084327A1 (ja) * | 2014-11-27 | 2017-09-14 | 日本電気株式会社 | 資源予測装置、資源予測方法、資源予測プログラムおよび分散処理システム |
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 | 富士通株式会社 | 出力プログラム、および出力方法 |
-
2020
- 2020-05-20 JP JP2020088069A patent/JP2021182314A/ja active Pending
-
2021
- 2021-03-25 EP EP21164860.5A patent/EP3913557A1/en not_active Withdrawn
- 2021-04-01 US US17/220,487 patent/US20210365350A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
EP3913557A1 (en) | 2021-11-24 |
US20210365350A1 (en) | 2021-11-25 |
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) | 管理装置、情報処理システムの制御方法、および管理装置の管理プログラム | |
Inoue et al. | Bivariate change-point modeling for software reliability assessment with uncertainty of testing-environment factor | |
CN112132384A (zh) | 工作效率评估方法、装置、存储介质及计算机设备 | |
CN111291936B (zh) | 产品生命周期预估模型生成方法、装置及电子设备 | |
JP2023029604A (ja) | 特許情報処理装置、特許情報処理方法、およびプログラム | |
Epifani et al. | Change-point detection for black-box services | |
CN109711849B (zh) | 以太坊地址画像生成方法、装置、电子设备及存储介质 | |
JPWO2021192191A5 (ja) | 異常アクセス予測システム、異常アクセス予測方法および異常アクセス予測プログラム | |
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) | 방문 예측 | |
US11741099B2 (en) | Supporting database queries using unsupervised vector embedding approaches over unseen data | |
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 | |
WO2023112203A1 (ja) | 情報処理装置、情報処理方法、およびプログラム | |
RU2781247C1 (ru) | Способ автоматического оповещения о запрошенных ресурсах сети | |
US20240184598A1 (en) | Real-time event status via an enhanced graphical user interface |