Quantitative measurement calculation method and business model for cloud service level agreement (SLA)

Abstract

To provide a technique that can promote quality improvement in the cloud service industry by starting a cloud measurement certification server via the Internet as a third party other than SaaS or PaaS business operators and users, and measuring and certifying actual results of SLA quantitative evaluation items and the amount used for SaaS and PaaS that are subject to measurement certification.SOLUTION: In a quantitative measurement calculation method for cloud service level agreement, a cloud measurement certification server is started via the Internet by a third party other than a SaaS or PaaS business operator and a user, performs synchronous or asynchronous communication with SaaS or PaaS that is subject to measurement certification, records a reception date and time from the SaaS or PaaS and accumulates it in an access log, and performs calculation for a service level agreement (SLA) quantitative evaluation item.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a method and business model for calculating quantitative measurements of cloud service level agreements (SLAs). [Background technology]

[0002] In the world of cloud computing, there are two usage patterns: SaaS (Software as a Service) and PaaS (Platform as a Service). SaaS is a cloud service that provides application software mainly to end users via a network, while PaaS refers to a cloud service that provides the application software execution environment, server software, and development middleware mainly to developers. The trend of providing and using cloud services via the Internet instead of software that was previously provided as a packaged product is accelerating.

[0003] In addition, with the spread of cloud services, there are many cases where disclosure or contract of service level agreements (SLA) is required, and the performance results of the evaluation items listed in particular form the basis for charging.

[0004] In recent years, RESTful API, which is one of the types of program calling conventions (APIs) for using web systems from outside according to the design principle called REST (short for REpresentational State Transfer), has increasingly become the de facto standard for calling interfaces in web systems using HTTP (Hyper Text Transfer Protocol).Furthermore, data linking to the cloud world can be easily achieved using JSON (JavaScript Object Notation) and XML (Extensible Markup Language), which are general-purpose data exchange formats.

[0005] In addition, the history of access via the RESTful API can be saved in the database access log with the reception date and time with microsecond accuracy, allowing for strict time series analysis and calculation of elapsed time.The following Non-Patent Documents 1 and 2 are examples of prior art documents related to this invention. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Ministry of Economy, Trade and Industry "SLA Guidelines for SaaS" January 21, 2008 [Non-Patent Document 2] Japan Electronics and Information Technology Industries Association, "SLA Guidelines for Private IT Systems - Supplement: SaaS Compatible Edition," January 2008 Summary of the Invention [Problem to be solved by the invention]

[0007] Currently, SaaS or PaaS SLA content is often implicitly applied by users. SLA quantitative evaluation items and usage results are self-reported by cloud service providers, and the quantitative measurement and calculation method for the SaaS or PaaS faced by users is unclear.

[0008] Additionally, service disruptions can occur due to the operational status of IaaS (Infrastructure as a Service), and when a user experiences a temporary inability to use SaaS or PaaS, it can be difficult to determine whether the cause is the SaaS or PaaS, or the IaaS.

[0009] Therefore, the purpose of this document is to promote quality improvement in the cloud service industry by launching a server (hereinafter referred to as "cloud measurement certification server" or "measurement certification server") that sets up a cloud measurement certification program via the Internet in a neutral position as a third party other than SaaS or PaaS providers and users, and using this server to measure, calculate and certify the SLA quantitative evaluation items and actual usage results of the SaaS and PaaS that are the subject of measurement certification (hereinafter referred to as "target SaaS and PaaS"). [Means for solving the problem]

[0010] In order to achieve the above objectives, we will target SaaS or PaaS providers and users, and build a business model that uses a cloud measurement certification server to measure, calculate, and certify the actual results of SLA quantitative evaluation items and usage from a neutral standpoint. In addition, potential users will be able to check the SLA achievement results of the target SaaS or PaaS. Figure 9 is an image of the business model.

[0011] The invention of this embodiment is a quantitative measurement calculation method for cloud service quality assurance, in which a cloud measurement certification server is launched via the Internet by a third party other than the SaaS or PaaS operator and the user, performs synchronous or asynchronous communication with the SaaS or PaaS that is the subject of measurement certification, records the date and time of reception from the SaaS or PaaS and accumulates it in an access log, and performs calculations for quantitative evaluation items of the service level assurance (SLA).

[0012] In addition, the measurement calculation of SLA availability and reliability quantitative evaluation items includes a step in which, in the case of asynchronous communication, the availability and reliability count registration API of the cloud measurement certification server is called by the SaaS or PaaS and the reception date and time is accumulated, and in the case of synchronous communication, the availability and reliability count program of the cloud measurement certification server calls the SaaS or PaaS and accumulates the reception date and time of the response, a step of calculating the chronological elapsed time using the reception date and time accumulated in the access log, a step of comparing with a predetermined measurement time standard interval to determine whether or not there is a failure and calculating the failure interval and recovery time, and a step of obtaining the actual results of the availability and reliability quantitative evaluation items.

[0013] In addition, the measurement calculation of the SLA performance standard quantitative evaluation items includes a step of calling the performance standard timing registration API of the cloud measurement certification server via asynchronous communication at the start and end of the SaaS or PaaS performance measurement target process and accumulating the reception date and time, a step of calculating the elapsed time of the target process based on the start and end reception dates and times accumulated by the performance standard timing confirmation API of the cloud measurement certification server, and a step of acquiring the actual results of the performance standard quantitative evaluation items. Effect of the Invention

[0014] According to the present invention, the cloud metric certification server can prevent the problem of SLA performance reports that are biased toward either the business operator or the user from a third-party perspective.

[0015] In addition, the date and time of receipt from the target SaaS or PaaS is stored in a database, making it possible to fairly measure and calculate SLA quantitative evaluation items and usage, and by providing proof to the provider and user of the target SaaS or PaaS, it is possible to confirm whether the target SaaS or PaaS is being implemented appropriately.

[0016] In addition, by transmitting and receiving data to and from the target SaaS or PaaS on a regular or irregular basis, the operating status of the service will be monitored, and prompt notification to the operator will lead to improved service quality.

[0017] In addition, for prospective users who have conducted advance research on the target SaaS or PaaS, the performance results of the SLA quantitative evaluation items disclosed by the measurement certification server can be useful for bid evaluation or adoption.

[0018] In addition, it is possible to select between passive and active communication methods and change the measurement time base interval, allowing a variety of means to minimize the impact on the performance of the target SaaS or PaaS and adjust the measurement evaluation accuracy of SLA availability and reliability quantitative evaluation items. [Brief description of the drawings]

[0019] [Figure 1] FIG. 2 is a diagram illustrating the configuration of a cloud metric verification server according to the present invention. [Diagram 2] This is an explanatory diagram of the measurement certification operation flow of SLA quantitative evaluation items. [Diagram 3] FIG. 1 is an explanatory diagram of the measurement certification operation flow for SaaS / PaaS usage. [Figure 4] This is a flow diagram of passive measurement of SLA availability and reliability quantitative evaluation items. [Diagram 5] This is a proactive measurement flow diagram of SLA availability and reliability quantitative evaluation items. [Figure 6] This is an explanatory diagram of a calculation example of SLA availability and reliability quantitative evaluation items. [Figure 7] FIG. 1 is a measurement flow diagram of SLA performance standard quantitative evaluation items. [Figure 8] FIG. 1 is an explanatory diagram of a calculation example of SLA performance standard quantitative evaluation items. [Figure 9] FIG. 1 is a diagram illustrating a business model of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] In the present invention, the server for metrological certification of SLA quantitative evaluation items and usage amounts constructs the environments of an application server and a database server, develops relevant counting / timing measurement registration and result confirmation programs, publishes them to the Internet using a general-purpose registration / result confirmation RESTful API, and installs them as a cloud service so that they can be called from other SaaS / PaaS. Figure 1 is a configuration explanatory diagram of the server for metrological certification.

[0021] First, the server for metrological certification records the reception date and time from the target SaaS or PaaS regularly or irregularly, and acquires the actual operation status of the target SaaS or PaaS.

[0022] There are two means for the measurement method. One is a passive method in which the counting / timing registration API of the server for metrological certification published on the Internet is called from the target SaaS or PaaS.

[0023] The other is an active method in which the counting program of the server for metrological certification calls the target SaaS or PaaS via the Internet and receives a response.

[0024] Then, the server for metrological certification accumulates the reception date and time from the target SaaS or PaaS in the access log of the database as the operation information of the target SaaS or PaaS, calculates the actual results of the availability / reliability, performance criteria quantitative evaluation items and usage amounts based on it, outputs them in a general-purpose data exchange format JSON or XML format, displays them on a computer display, or outputs an electronic media file.

[0025] Also, the business model operation of the present invention includes metrological certification of SLA quantitative evaluation items and usage amounts. <Operation flow of metrological certification of SLA quantitative evaluation items> Figure 2 is an explanatory diagram of the operation flow of metrological certification of SLA quantitative evaluation items. Each process in Figure 2 will be described by the following (1) to (9).

[0026] (1) Disclosure of SLA indicators means that a SaaS / PaaS provider presents to users evaluation item indicators such as the service uptime, mean time to recovery, online response time, and batch processing time of the SaaS / PaaS being metered, and the user enters into a contract based on those indicators.

[0027] (2) Service maintenance refers to the maintenance work performed by a SaaS / PaaS provider of the SaaS / PaaS subject to metering, such as initial setup, program upgrades, data replacement, data backups, failure recovery, and daily monitoring.

[0028] (3) “Service use” refers to a process in which a metered SaaS / PaaS user performs search, input, download, upload, print, etc., in the relevant service.

[0029] (4) The access record indicates that synchronous or asynchronous communication is performed between the measurement target SaaS / PaaS and the measurement certification server's SLA availability / reliability counting registration API / performance standard timing registration API or availability / reliability counting program, and that the measurement certification server records the date and time of reception from the measurement target SaaS / PaaS.

[0030] (5) Access log storage indicates that the SLA availability / reliability counting registration API / performance standard timing registration API or the availability / reliability counting program of the measurement certification server accumulates the reception date and time from the measurement target SaaS / PaaS and stores it in the database as an access log.

[0031] (6) Obtaining measurement certification means that the measurement target SaaS / PaaS provider calls the SLA availability / reliability count confirmation API / performance standard timing confirmation API of the measurement certification server to calculate and obtain the performance results of the corresponding SLA quantitative evaluation items and displays them on a computer display screen or outputs them to an electronic media file.

[0032] (7) Obtaining access logs indicates that the SLA availability and reliability count confirmation API / performance standard timing confirmation API of the measurement certification server obtains the time-series reception date and time from the access logs stored in the database.

[0033] (8) SLA performance report refers to the reporting of the performance results of the measurement certification obtained by the measurement subject SaaS / PaaS provider in (6) above to the user in the form of an electronic media file or paper printout.

[0034] (9) SLA performance confirmation refers to a process in which a user of the measurement target SaaS / PaaS calls the SLA availability / reliability count confirmation API / performance standard timing confirmation API of the measurement certification server to calculate and obtain the performance results of the corresponding SLA quantitative evaluation items and display them on a computer display screen or output them to an electronic media file. <Operation flow for measurement certification of usage amount> Figure 3 is a diagram explaining the flow of the measurement certification operation of the amount of usage. Each process in Figure 3 will be explained in the following (1) to (9).

[0035] (1) Issuance of a usage license indicates that a SaaS / PaaS provider issues a usage license for the metered SaaS / PaaS to a user, thereby establishing a corresponding cloud service usage contract.

[0036] (2) Service maintenance refers to the maintenance work performed by a SaaS / PaaS provider of the SaaS / PaaS subject to metering, such as initial setup, program upgrades, data replacement, data backups, failure recovery, and daily monitoring.

[0037] (3) “Service use” refers to a process in which a metered SaaS / PaaS user performs search, input, download, upload, print, etc., in the relevant service.

[0038] (4) The access record indicates that each time a user uses the SaaS / PaaS to be measured, the SaaS / PaaS to be measured calls the usage counting registration API of the metering certification server, and the metering certification server records the reception date and time from the SaaS / PaaS to be measured.

[0039] (5) The access log storage indicates that the usage counting registration API of the metering certification server accumulates the reception date and time from the SaaS / PaaS to be measured and stores it in the database as an access log.

[0040] (6) The usage amount acquisition indicates that the operator of the SaaS / PaaS to be measured calls the usage counting confirmation API of the metering certification server to calculate and obtain the actual result of the usage amount, and displays it on the computer display screen or outputs it to an electronic media file.

[0041] (7) The access log acquisition indicates that the usage counting confirmation API of the metering certification server obtains the reception date and time from the access log stored in the database.

[0042] (8) The usage amount report indicates that the operator of the SaaS / PaaS to be measured reports the actual result of the usage amount obtained in (6) above to the user in the form of an electronic media file or paper print.

[0043] (9) The usage amount confirmation indicates that the user of the SaaS / PaaS to be measured calls the usage counting confirmation API of the metering certification server by himself / herself to calculate and obtain the actual result of the usage amount, and displays it on the computer display screen or outputs it to an electronic media file.

[0044] The metering process of the SLA availability / reliability quantitative evaluation items has an asynchronous passive type and a synchronous active type, and the metering process of the SLA performance standard quantitative evaluation items and the usage amount is of the asynchronous passive type. They are described below respectively. <Passive Processing of SLA Availability / Reliability Quantitative Evaluation Item Metering> Figure 4 is a diagram showing the passive measurement flow of the SLA availability / reliability quantitative items in an embodiment of the present invention.

[0045] First, in the target SaaS / PaaS, there are both irregular and regular cases in the asynchronous communication that sends data to the metrology certification server of the present invention without waiting for a response. The irregular case is the case where the SLA availability / reliability counting registration API of the metrology certification server of the present invention is called by the operation of the target SaaS / PaaS user or random processing. The regular case is the case where it automatically sends data at a fixed transmission time interval (<a defined metrology time reference interval) within the target SaaS / PaaS and calls the same counting registration API of the present invention.

[0046] Next, when an access from the target SaaS / PaaS arrives at the SLA availability / reliability counting registration API of the present invention, the counting registration program inside the API can confirm the activity of the target SaaS / PaaS, record the reception date and time, and accumulate it in the access log database in chronological order.

[0047] Also, in the SLA availability / reliability counting confirmation API of the present invention, the analysis calculation program inside the API calculates the elapsed time in chronological order of the accumulated access reception date and time and compares it with a predefined metrology time reference interval to determine whether it is within the metrology time reference interval. If it is within the metrology time reference interval, it is regarded as an available service time zone, and if it exceeds, it is regarded as a failure time zone. Adjust the metrology time reference interval, set the service time zone, and exclude the planned stop time and holidays as needed, and calculate the availability / reliability quantitative evaluation items such as the failure interval and recovery time. Example 1 shows a specific calculation method. <Active Processing of SLA Availability / Reliability Quantitative Evaluation Item Metrology> FIG. 5 is a diagram showing an active measurement flow of SLA availability / reliability quantitative items in an embodiment of the present invention.

[0048] First, there are both non-periodic and regular cases of synchronous communication in which the measurement certification server of the present invention sends to the target SaaS / PaaS and receives a response. The non-periodic case is a case in which the SLA availability / reliability counting program of the measurement certification server of the present invention randomly or manually calls the alive monitoring API of the target SaaS / PaaS. The regular case is a case in which the counting program of the present invention automatically sends at a fixed transmission time interval (<predetermined measurement time standard interval) and calls the alive monitoring API of the target SaaS / PaaS.

[0049] Next, when the target SaaS / PaaS receives access from the measurement certification server of the present invention, the alive monitoring API responds to the source.

[0050] Next, in the SLA availability / reliability counting program of the measurement certification server of the present invention, an internal counting registration program receives a response from the alive monitoring API of the target SaaS / PaaS, confirms the activity of the target SaaS / PaaS, records the date and time of receipt, and accumulates it in a chronological order in the access log database.

[0051] Furthermore, in the SLA availability / reliability count confirmation API of the present invention, the analysis calculation program inside the API calculates the time series elapsed time of the accumulated access reception date and time, and compares it with a predetermined measurement time reference interval to determine whether it is within the measurement time reference interval. If it is within the measurement time reference interval, it is determined to be an available service time slot, and if it exceeds the measurement time reference interval, it is determined to be a failure time slot. If necessary, the measurement time reference interval is adjusted, a service time slot is set, and planned downtime and holidays are excluded to calculate the availability / reliability quantitative evaluation items of failure interval and recovery time. Example 1 shows a specific calculation method. EXAMPLES

[0052] The API for verifying the SLA availability and reliability of the server for metric verification of the present invention calculates the monthly performance results of the quantitative evaluation items of the SLA availability and reliability in the following manner. Figure 6 shows a calculation example of the time between failures, the recovery time, and the availability rate.

[0053] failureCount Number of failures: Counts the number of times per month that the chronological elapsed time of the reception date and time exceeds a predetermined measurement time reference interval. maxTimeToRepair Maximum recovery time (unit: minutes): Obtains the monthly maximum value for cases in which the chronological elapsed time of the reception date and time exceeds the predetermined measurement time reference interval. minTimeToRepair Minimum recovery time (unit: minutes): Obtains the monthly minimum value for cases in which the chronological elapsed time of the reception date and time exceeds the predetermined measurement time reference interval. meanTimeToRepair Mean time to repair (unit: minutes): Obtains the monthly average value for cases in which the chronological elapsed time of the reception date and time exceeds the predetermined measurement time reference interval. totalTimeToRepair Total recovery time (unit: minutes): Obtains the monthly total value of cases in which the chronological elapsed time of the reception date and time exceeds the predetermined measurement time reference interval. meanTimeBetweenFailures Mean time between failures (unit: minutes): Obtains the monthly average value for the time period (available service time period) during which the time series elapsed time of the reception date and time does not exceed the predetermined measurement time reference interval. totalTimeBetweenFailuresTotal time between failures (unit: minutes): Obtains the monthly total value for the time period (available service time period) during which the chronological elapsed time of the reception date and time does not exceed the predetermined measurement time reference interval. monthlyOperationRateMonthly operation rate (unit: %): total time between failures ÷ (total time between failures + total recovery time)

[0054] Below is a sample return value (JSON format) from the SLA availability and reliability count confirmation API, showing the actual availability and reliability item values ​​for November 2020. { "days": 30, "failureCount": 23, "maxTimeToRepair": 1440, "meanTimeBetweenFailures": 756, "meanTimeToRepair": 1122, "minTimeToRepair": 106, "month": 11, "monthlyOperationRate": 40.24926712965278, "totalTimeBetweenFailures": 17388, "totalTimeToRepair": 25812, "year": 2020 } <Processing of SLA Performance Standard Quantitative Item Measurement> FIG. 7 is a diagram showing a measurement flow of SLA performance standard quantitative items in an embodiment of the present invention. Note that it is passive.

[0055] First, in the target SaaS / PaaS, the communication to the metrology certification server of the present invention is asynchronous and irregular communication without waiting for a response. The SLA performance standard timing registration API of the metrology certification server of the present invention is called at the start and end positions of the measurement target process of the target SaaS / PaaS by the operation of the target SaaS / PaaS user.

[0056] Next, when an access from the target SaaS / PaaS arrives at the SLA performance standard timing registration API of the metrology certification server of the present invention, the timing registration program inside the API records the identification code (key) of the measurement target process of the target SaaS / PaaS and the reception date and time, and accumulates them in the access log database in time series.

[0057] Also, in the SLA performance standard timing confirmation API of the present invention, the analysis calculation program inside the API calculates the elapsed time based on the reception date and time of the start and end of the measurement target process of the target SaaS / PaaS accumulated, uses it as the processing time, and calculates and statistically analyzes evaluation items such as the response time from it. Example 2 shows a specific calculation method. [Example 2] The SLA performance standard timing confirmation API of the metrology certification server of the present invention calculates the monthly actual result of the SLA performance standard quantitative evaluation item by the following method. Note that FIG. 8 is an example calculation of the processing time.

[0058] count process count: Counts the number of times the target process is executed per month. firstTimeFirst date and time: Gets the date and time when the first execution of the target process starts in the month. lastTime: Gets the last execution date and time of the target process in this month. avgSec Average processing time (unit: seconds): Obtains the monthly average processing time of the target process. maxSec Maximum processing time (unit: seconds): Obtains the maximum monthly processing time for the target process. minSec Shortest processing time (unit: seconds): Gets the shortest processing time for the target process in a month. sumSecTotal monthly processing time (unit: seconds): Obtains the total monthly processing time for the target process. * Processing time (elapsed time) = End date and time - Start date and time

[0059] Below is a sample return value (JSON format) from the SLA performance criteria timing confirmation API, which shows the performance criteria item actual value for the target process [P_ABC1]. { "avgSec": 60.679, "count": 5, "firstTime": "2020-11-19 13:32:13.887", "lastTime": "2020-11-19 13:56:02.472", "maxSec": 116.792, "minSec": 29.122, "sumSec": 301.393, "userKey": "P_ABC1" } <Processing of usage amount measurement> First, in the target SaaS / PaaS, communication with the metric certification server of the present invention is asynchronous and non-periodic communication that does not wait for a response. The target SaaS / PaaS calls the usage count registration API of the metric certification server of the present invention at the corresponding position (e.g., user authentication) by the operation of the target SaaS / PaaS user.

[0060] Next, when access from the target SaaS / PaaS arrives at the usage counting registration API of the measurement certification server of the present invention, the counting registration program within the API records the authentication code, usage code, and date and time of receipt of the target SaaS / PaaS, and accumulates them in chronological order in the access log database.

[0061] In addition, the usage count confirmation API of the present invention counts the number of uses of each authentication code and purpose code for a certain period (e.g., week / month / quarter / year) based on the received date and time stored in the analysis and calculation program inside the API. Example 3 shows a specific calculation method. [Example 3] The measurement certification server of the present invention manages the usage licenses of the target SaaS / PaaS and issues authentication codes, and the usage count confirmation API further tallyes the number of accesses for a certain period of time (e.g. week / month / quarter / year) for each usage code based on the access log.

[0062] Below is a sample JSON return from the usage count confirmation API (JSON format) showing monthly usage. { "code": "2002-10002- CPl8rnBSAchnLJ0qQ0r2wAeK3CdJ", "entities": [ { "sumItem": "2020-10", "sumValue": 6549 }, { "sumItem": "2020-11", "sumValue": 7690 } ] } [Explanation of symbols]

[0063] 1100 Metering certification server 1101 SLA Availability and Reliability Count Registration API 1102 SLA Availability and Reliability Counting Program 1103 SLA performance benchmark timing registration API 1104 Usage Count Registration API 1105 Access Log Database 1106 SLA Availability and Reliability Count Check API 1107 SLA performance standard timing confirmation API 1108 Usage Count Confirmation API 1200 Target SaaS / PaaS 1300 Target SaaS / PaaS users 1400 Target SaaS / PaaS businesses 2100 Target SaaS / PaaS businesses 2200 Target SaaS / PaaS users 2300 Target SaaS / PaaS 2400 SLA availability and reliability counting registration API / performance standard timekeeping registration API or availability and reliability counting program for measurement certification server 2500 Metering Server Database 2600 API for checking SLA availability and reliability of measurement certification server / API for checking performance standard timing 3100 Target SaaS / PaaS businesses 3200 Target SaaS / PaaS users 3300 Target SaaS / PaaS 3400 API for registering usage count of the measurement certification server 3500 Metering Server Database 3600 API for verifying usage of the measurement server 4100 Target SaaS / PaaS 4101 Target SaaS / PaaS non-periodic transmission flow 4102 Transmission timing of the target SaaS / PaaS periodic transmission flow 4103 Transmission interval of the target SaaS / PaaS periodic transmission flow 4200 The measurement certification server of the present invention 4201 API for registration of SLA availability reliability factor of measurement certification server 4202 Access log storage database for the measurement certification server 4203 Measurement time base interval for measurement certification server 4204 API for verifying SLA availability and reliability of measurement server 5100 Target SaaS / PaaS 5101 Target SaaS / PaaS alive monitoring API 5200 The measurement certification server of the present invention 5201 SLA Availability Reliability Counting Program for Metering Proof Server 5202 SLA Availability Reliability Counting Program Periodic Transmission Flow Transmission Timing 5203 SLA Availability Reliability Counting Program Periodic Transmission Flow Transmission Interval 5204 SLA Availability Reliability Counting Program Non-Periodic Transmission Flow 5205 Access log storage database for the measurement certification server 5206 Measurement time base interval for measurement certification servers 5207 API for verifying SLA availability and reliability of measurement server 6101 Example of the date and time of receipt in the access log 6102 Example of time series of access logs 6103 Comparison of access log time series and measurement time base interval 6104 Example of available service time (failure interval) 6105 Service outage time period (restoration time) example 6200 Total Service Interrupt Time Example 6300 Total Service Recovery Time Example 6400 Service Availability Calculation Examples and Formulas 7100 Target SaaS / PaaS 7101 Target SaaS / PaaS performance measurement target process 7102 Performance measurement target process measurement started 7103 Performance measurement of the target process has ended. 7200 The measurement certification server of the present invention 7201 SLA performance benchmark timing registration API 7202 Database of the metrology certification server 7203 SLA performance standard timing confirmation API 8101 Performance measurement target processing key example 8102 Access log code example 8103 Example of start date and time of the process to be measured 8104 Example of end date and time of performance measurement target process 8105 Example of processing time for performance measurement target process (end date and time - start date and time) 8106 Example of the shortest processing time for the process subject to performance measurement 8107 Example of maximum processing time for performance measurement target process 8108 Example of average processing time for performance measurement target process 9100 The measurement certification server of the present invention 9200 Target SaaS / PaaS 9300 Target SaaS / PaaS businesses 9400 Target SaaS / PaaS users 9500 Potential users of the target SaaS / PaaS [Industrial Applicability]

[0064] As the performance of cloud services improves, business and personal SaaS or PaaS become more and more popular, and there is a need for fair measurement evaluation in the cloud service industry, such as commodity measurement and environmental measurement.

[0065] In recent years, with the improvement of the IaaS environment, the measurement certification server of the present invention itself can provide stable and highly accurate services as a type of SaaS, and since this can also become a business model, many companies will enter the market and the quality of the cloud service measurement evaluation business will be further improved.

[0066] It is necessary to add a function for sending and receiving with the measurement certification server to the program side of the target SaaS or PaaS, but since the sending and receiving interface specifications follow the standard RESTful API, it becomes possible to access the measurement certification server of the present invention with very little work.

[0067] When the metric certification server of the present invention communicates passively, it does so asynchronously and there is no need to wait for a response, so the impact on the performance of the target SaaS or PaaS itself is negligible.

[0068] Service authentication can be maintained by distributing an authentication code or an access key to the target SaaS or PaaS.

[0069] Metering of SaaS or PaaS usage can be widely used by aggregating usage for a certain period (e.g. week / month / quarter / year) for each usage code in addition to the authentication code for the target license management.

Claims

[Claim 1] A quantitative measurement calculation method for cloud service quality assurance, comprising the steps of: a cloud metric certification server is started via the Internet by a third party other than a SaaS or PaaS operator and a user, performs synchronous or asynchronous communication with a SaaS or PaaS that is a subject of metric certification, records the date and time of reception from the SaaS or PaaS and accumulates the data in an access log, and performs calculations for quantitative evaluation items of a service quality assurance (SLA), The measurement calculation of SLA availability and reliability quantitative evaluation items is as follows: In the case of asynchronous communication, an availability / reliability count registration API of the cloud metric certification server is called by the SaaS or PaaS and stores a reception date and time; In the case of synchronous communication, an availability / reliability counting program of the cloud metric certification server calls the SaaS or PaaS and accumulates a reception date and time of a response; calculating a chronological elapsed time based on the reception date and time stored in the access log; A step of comparing the measurement time interval with a predetermined measurement time reference interval, determining whether or not there is a fault, and calculating the fault interval and the recovery time; acquiring performance results of availability and reliability quantitative evaluation items; The measurement calculation of SLA performance criteria quantitative evaluation items is as follows: a step of calling a performance standard time registration API of the cloud measurement certification server by asynchronous communication at the start and end of a performance measurement target process of the SaaS or PaaS and storing a reception date and time; Calculating an elapsed time of a target process based on the start and end reception dates and times accumulated from a performance standard timing confirmation API of the cloud metric certification server; A quantitative measurement calculation method for cloud service quality assurance, comprising: a step of acquiring performance results of performance-based quantitative evaluation items.

Images