[go: up one dir, main page]

WO2018131556A1 - リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体 - Google Patents

リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体 Download PDF

Info

Publication number
WO2018131556A1
WO2018131556A1 PCT/JP2018/000162 JP2018000162W WO2018131556A1 WO 2018131556 A1 WO2018131556 A1 WO 2018131556A1 JP 2018000162 W JP2018000162 W JP 2018000162W WO 2018131556 A1 WO2018131556 A1 WO 2018131556A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
resource
version
resource setting
request
Prior art date
Application number
PCT/JP2018/000162
Other languages
English (en)
French (fr)
Inventor
巧 藤原
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US16/475,497 priority Critical patent/US10891164B2/en
Priority to JP2018561355A priority patent/JP6798564B2/ja
Publication of WO2018131556A1 publication Critical patent/WO2018131556A1/ja

Links

Images

Classifications

    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • 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
    • 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

Definitions

  • the present invention relates to a resource setting control device, a resource setting control system, a resource setting control method, and a computer readable recording medium, and more particularly to resource setting control for performing resource allocation in a situation where multiple versions of a service are mixed in the system. .
  • Each service version is loosely coupled, but the basic functions provided are almost the same. For this reason, when there is a resource pool management function such as a thread for waiting for a request to a service or a DB (Data Base) connection, it is necessary to secure the resource with a service for each version.
  • a resource pool management function such as a thread for waiting for a request to a service or a DB (Data Base) connection
  • Patent Document 1 discloses a virtualization execution device that improves the convenience of a virtual environment of a server device. When determining the system configuration information, this apparatus recommends the same system configuration information as the past to users who have the same service usage history. In addition, this device expands the amount of resources by adding virtual machines and containers when resources are insufficient during service execution.
  • Patent Document 2 discloses a system that maintains the operation of an application in a sub-optimal grid environment.
  • the service availability management agent monitors the performance state of the resource node. When the performance state does not meet the specified operational requirements, the service availability management agent coordinates the use of the application's resource nodes.
  • the amount of resources required for each service depends on the number of versions that are running, the number of client devices that use each service, etc. It changes depending on the progress of the version transition of the user. For this reason, it is difficult to calculate an optimal setting from the situation of the entire system.
  • Patent Document 1 and Patent Document 2 described above all reallocate resources in response to a change in load between versions of a service used, that is, a user's progress in version migration. Rather, it does not solve the above problem.
  • An object of the present invention is to provide a resource setting control device or the like that solves the above-described problems and reviews resource allocation triggered by a change in load between versions of a service that is used in parallel with a service transition or the like.
  • the resource setting control apparatus includes: a) a group of service requests for requesting any service among a plurality of versions, the requested version, and a resource usage amount during execution of the service; A request history including information; and b) extracting a load pattern of the service request within a predetermined period from the request history in the operation information storage means for storing a reference pattern of the load of the service request; and Resource setting change judging means for updating the reference pattern when a change in a predetermined range or more is detected, and when detecting a change in the load pattern, for each version, the peak value of the resource usage and the version within the predetermined period
  • Resource setting changing means for determining and outputting a resource request amount based on the number of server devices to be provided.
  • the resource setting control method includes: a) a group of service requests for requesting any service among a plurality of versions, the requested version, and a resource usage amount during execution of the service; B) storing a request history including information; b) storing a reference pattern of the load of the service request; extracting the load pattern of the service request within a predetermined period from the request history; and a change within a predetermined range from the reference pattern
  • the reference pattern is updated, and when the change of the load pattern is detected, the resource request based on the peak value of the resource usage within the predetermined period and the number of server devices providing the version for each version Determine the amount and output.
  • a computer-readable recording medium includes: a) a group of service requests for requesting any one of a plurality of versions, the requested version, and a resource usage amount during execution of the service B) extracting a load pattern of the service request within a predetermined period from the request history in the operation information storage means for storing a reference pattern of the load of the service request; b) Resource setting change determination processing for updating the reference pattern when a change in a predetermined range or more is detected, and when detecting a change in the load pattern, for each version, the peak value of the resource usage within the predetermined period and the version Resource setting change process that determines and outputs the requested resource amount based on the number of server devices that provide When, stores the resource configuration control program for causing a computer to execute non-temporary.
  • the resource setting control apparatus can appropriately perform resource distribution between versions in a system that provides a plurality of versions of services in parallel in the process of transitioning between versions of services.
  • FIG. 1 is a diagram illustrating a configuration of a resource setting control system 400 according to the first embodiment.
  • FIG. 2 is a diagram illustrating an example of the version specifying rule stored in the version specifying rule storage unit 301.
  • FIG. 3 is a diagram illustrating an example of grouping rules stored in the grouping rule storage unit 302.
  • FIG. 4 is a diagram illustrating an example of workload information stored in the operation information storage unit 206.
  • FIG. 5 is a diagram illustrating an example of service operation status information for each version stored in the configuration information storage unit 207.
  • FIG. 6 is a diagram showing the configuration of the computer device 600.
  • FIG. 1 is a diagram illustrating a configuration of a resource setting control system 400 according to the first embodiment.
  • FIG. 2 is a diagram illustrating an example of the version specifying rule stored in the version specifying rule storage unit 301.
  • FIG. 3 is a diagram illustrating an example of grouping rules stored in the grouping rule storage unit 302.
  • FIG. 4 is a diagram
  • FIG. 7 is a flowchart showing operations until the REST server apparatus 100 receives a request and executes a service, and the request history is accumulated in the operation information storage unit 206 of the resource setting control apparatus 200.
  • FIG. 8 is a flowchart illustrating details of request analysis performed by the request analysis unit 101.
  • FIG. 9 is a flowchart of setting change determination processing by the resource setting change determination unit 205.
  • FIG. 10 is a flowchart of the resource setting value calculation processing for each version by the resource setting changing unit 204.
  • FIG. 11 is a diagram illustrating a configuration of a resource setting control system 400 according to the second embodiment.
  • FIG. 12 is a diagram illustrating a configuration of a resource setting control device 200 according to the third embodiment.
  • FIG. 1 is a diagram illustrating a configuration of a resource setting control system 400 according to the first embodiment.
  • the resource setting control system 400 includes a REST server device 100 and a resource setting control device 200 connected to each other via a communication network, and a service client device 300 connected to the REST server device 100.
  • a plurality of REST server devices 100 and service client devices 300 may exist.
  • the REST server device 100 provides a plurality of versions of service to the service client device 300.
  • the resource setting control device 200 determines resource allocation between versions.
  • the resources are, for example, a thread for waiting for a request to a service, a DB connection, a memory area, and a communication path that are managed in a pool.
  • the REST server device 100 includes a service execution unit 103, a request analysis unit 101, and a resource usage collection unit 102.
  • the REST server device 100 includes a version identification rule storage unit 301 and a grouping rule storage unit 302, or is shared with other devices.
  • the service execution unit 103 receives a service request (hereinafter abbreviated as a request) from the service client device 300, and executes a specified version of the service.
  • a service request hereinafter abbreviated as a request
  • requests from each service client device 300 are appropriately distributed to one of the REST server devices 100 by, for example, a load balancer (not shown).
  • the request analysis unit 101 analyzes a request to a service, specifies a version of a service to be used, and performs grouping of requests. At this time, the request analysis unit 101 refers to the version specifying rule storage unit 301 and the grouping rule storage unit 302.
  • the resource usage collection unit 102 collects the resource usage at the time of execution of the service so that the group can be identified in units of version, and transmits the group to the resource setting control device 200.
  • the resource setting control device 200 includes a workload information collection unit 201, a noise determination unit 202, a service configuration management unit 203, a resource setting change unit 204, and a resource setting change determination unit 205.
  • the resource setting control device 200 further includes an operation information storage unit 206 and a configuration information storage unit 207.
  • the workload information collection unit 201 receives the resource usage at the time of service execution from the resource usage collection unit 102 of each REST server device 100 and stores it in the operation information storage unit 206. Accumulate as an integrated record.
  • the service configuration management unit 203 uses the configuration information storage unit 207 to grasp the service operation status for each version in the entire resource setting control system 400.
  • the resource setting change determination unit 205 Based on the information accumulated in the operation information storage unit 206, the resource setting change determination unit 205 extracts the load pattern of requests generated and processed in the distributed environment, and based on the situation, the resource setting change resource version Check the necessity of distribution change. At this time, the noise determination unit 202 checks whether there is a long-term change in the load pattern from the noise information of the load pattern.
  • the resource setting change unit 204 calculates an appropriate setting value of the resource for each version from the service operation status for each version in the entire resource setting control system 400 and the resource usage status of the request group. Then, the resource setting change unit 204 transmits a resource allocation change instruction based on the calculated value to the REST server apparatus 100.
  • FIG. 2 is a diagram illustrating an example of the version identification rule stored in the version identification rule storage unit 301.
  • the request analysis unit 101 specifies the version of the requested service from the request information according to the version specification rule stored in the version specification rule storage unit 301.
  • the version identification rule specifies from which part of which information of the request the version information is extracted.
  • (A) in FIG. 2 is a setting example for version determination by URL (Uniform resource locator). This rule specifies that version information is to be extracted from the part following “rest /” indicated by “version” in the URL path of the request.
  • URL Uniform resource locator
  • (B) in FIG. 2 is a setting example for determining the version by the port number. This rule specifies that version information is extracted from the part following “// ⁇ host> /” indicated by “version” in the port number of the request.
  • FIG. 3 is a diagram illustrating an example of grouping rules stored in the grouping rule storage unit 302.
  • the request analysis unit 101 identifies the group identifier to which the request belongs according to the grouping rules stored in the grouping rule storage unit 302.
  • the grouping rule specifies from which part of which information of the request the group identifier is extracted.
  • FIG. 3 is a setting example in which grouping is performed by authentication Id (Identification). This rule specifies that a group identifier is extracted from the AUTH_ID field of the HTTP (Hyper Text Transfer Protocol) header key of the request.
  • HTTP Hyper Text Transfer Protocol
  • (B) of FIG. 3 is a setting example in which grouping is performed by a part of the authentication Id.
  • This rule specifies that the group identifier is extracted from the 0th to 5th bytes of the AUTH_ID field of the HTTP header key of the request.
  • substring is a function that specifies cutting of values.
  • (C) in FIG. 3 is a setting example for grouping by the type of the client application. This rule specifies that the group identifier is extracted from the parameter key CLIENT_TYPE of the request.
  • FIG. 4 is a diagram illustrating an example of workload information stored in the operation information storage unit 206.
  • the workload information is a history of requests received and processed by each REST server device 100.
  • This request history information is information collected by the request analysis unit 101 and the resource usage collection unit 102 of each REST server device 100.
  • Each request record in the history is, for example, the processing completion time, the version identification information of the requested service, the group identifier, and the type and usage of the resource required for processing the request.
  • FIG. 5 is a diagram illustrating an example of service operation status information for each version stored in the configuration information storage unit 207.
  • the service operation status information stores, for example, the identifier (machine A, machine B, etc.) of the REST server device 100 and the version number of the service provided on the REST server device 100 in association with each other.
  • the example of FIG. 5 indicates that version 1 indicated by V1 is being serviced on two REST server devices 100 of machines A and B.
  • the service execution unit 103, the request analysis unit 101, and the resource usage collection unit 102 of the REST server device 100 are configured by logic circuits.
  • the version specifying rule storage unit 301 and the grouping rule storage unit 302 are stored in a nonvolatile storage device such as a disk.
  • the REST server device 100 may be realized by the computer device 600.
  • FIG. 6 is a diagram showing the configuration of the computer device 600.
  • the computer device 600 includes a processor 610, a main storage unit 630, and an external storage device 620 that are connected to each other via a bus 640.
  • the processor 610 reads / writes data from / to the main storage unit 630 and the external storage device 620 via the bus 640. Further, the processor 610 executes a program 650 stored in the main storage unit 630. Note that the program 650 is initially stored in the external storage device 620, and the processor 610 may load the external storage device 620 from the external storage device 620 to the main storage unit 630 when the computer device 600 is initially set.
  • the main storage unit 630 is a semiconductor memory device.
  • the external storage device 620 is a storage device such as a disk device or a semiconductor storage device.
  • the processor 610 functions as the service execution unit 103, the request analysis unit 101, and the resource usage collection unit 102 by executing the program 650. That is, the processor 610 executes the program 650 to execute processing performed by the service execution unit 103, the request analysis unit 101, and the resource usage collection unit 102.
  • the external storage device 620 may be used as the version specifying rule storage unit 301 and the grouping rule storage unit 302.
  • the workload information collection unit 201, the noise determination unit 202, the service configuration management unit 203, the resource setting change unit 204, and the resource setting change determination unit 205 of the resource setting control device 200 are configured with logic circuits.
  • the operation information storage unit 206 and the configuration information storage unit 207 are stored in a nonvolatile storage device such as a disk.
  • the resource setting control device 200 may be realized by a computer device 600 shown in FIG.
  • the processor 610 functions as a workload information collection unit 201, a noise determination unit 202, a service configuration management unit 203, a resource setting change unit 204, and a resource setting change determination unit 205 by executing the program 650. That is, the processor 610 executes the program 650 to perform processing performed by the workload information collection unit 201, the noise determination unit 202, the service configuration management unit 203, the resource setting change unit 204, and the resource setting change determination unit 205. Execute.
  • the external storage device 620 may be used as the operation information storage unit 206 or the configuration information storage unit 207.
  • FIG. 7 is a flowchart showing operations until the REST server apparatus 100 receives a request and executes a service, and the request history is accumulated in the operation information storage unit 206 of the resource setting control apparatus 200.
  • the service client device 300 authenticates the client in order to execute the service (REST API) (S1).
  • the REST server device 100 authenticates the client and pays out the authenticated token to the service client device 300. Subsequent requests from the service client device 300 are given an authenticated token and sent to the REST server device 100.
  • the service execution unit 103 of the REST server apparatus 100 executes the service (S2).
  • the request analysis unit 101 analyzes the request, identifies the version of the service being called and extracts a group identifier for grouping from the request, and transmits the group identifier to the resource setting control device 200 ( S3).
  • FIG. 8 is a flowchart showing details of the request analysis performed by the request analysis unit 101 in S3 of FIG. 7B.
  • the request analysis unit 101 uses the version specification rule stored in the version specification rule storage unit 301 (S11), and specifies the version of the service request from the transmitted request information. And transmitted to the resource setting control device 200 (S12).
  • the version may be specified by the URL path.
  • the REST server apparatus 100 uses a path such as “http: // host / api / v1 / service” for the version 1 API and the “http: // host / api / v2” API for the version 2. Publish with a path like "/ service”. Then, the request analysis unit 101 uses version 1 API for http: // host / api / v1 /, version 2 API for http: // host / api / v2 / and information included in the path. Recognize the version.
  • the version specifying rule uses “URL path” to identify the version, and describes the location indicating the version in the character string of the URL path (see a in FIG. 2).
  • the request analysis unit 101 uses the grouping rules stored in the grouping rule storage unit 302 (S13) to extract the identifier of the group to which the request belongs from the transmitted request information, and the resource setting control device 200 (S14).
  • Requests are grouped in meaningful units. For example, when requests from users with the same Id are used as one group, the request analysis unit 101 extracts the user Id from the request as a group identifier. As another example, when a request is bundled for each company to which the user belongs, the request analysis unit 101 extracts a company code included in Id.
  • the administrator of the resource setting control system 400 first determines how to group requests in order to determine resource allocation between versions. Next, the administrator stores in advance the grouping rule storage unit 302 as the grouping rule from where the identification information of the group should be extracted (see FIG. 3).
  • the resource usage collection unit 102 acquires the resource usage used for executing the request from, for example, the service execution unit 103, and transmits it to the resource setting control device 200 ( S4).
  • the service execution unit 103 may monitor the resource usage during request execution and record it in the request, and the resource usage collection unit 102 may refer to the record.
  • the workload information collection unit 201 receives information sent from the request analysis unit 101 and the resource usage collection unit 102 (S5), and accumulates it as a request history in the operation information storage unit 206. (S6, see FIG. 4). At this time, the workload information collection unit 201 regards logout to logout as one workload, and records requests for each group according to time zones.
  • FIG. 9 is a flowchart of setting change determination processing by the resource setting change determination unit 205.
  • the resource setting change determination unit 205 is activated every predetermined period, and extracts a load pattern from the request history in the operation information storage unit 206 (S21). In many cases of steady operation, request transmission can be patterned in a certain cycle. The resource setting change determination unit 205 extracts this pattern every predetermined period from the request history.
  • This predetermined period is a unit period in which the request transmission timing tends to appear when the request is expressed in a certain time-series group, such as one day, one week, one month, etc. It is a long period.
  • the predetermined period is set to a day unit, and the resource setting change determination unit 205 extracts a load pattern for each time.
  • the predetermined period is set as a week unit, and the resource setting change determination unit 205 extracts the load pattern for each day of the week.
  • the predetermined period is set to one month, and the resource setting change judgment unit 205 sets the load for each week or day. Extract the pattern. -When the load is high / low in the first or last month, week or day of the quarter (three months), the predetermined period is set to quarterly, and the resource setting change judgment unit 205 Extract daily load patterns. -When the load is high / low in a specific month, week, or day in a half year or year, the predetermined period is set to a half year or year, and the load pattern for each month, week, or day is extracted.
  • the resource setting change determination unit 205 extracts the load pattern from the request history of the latest cycle, and then compares this pattern with the reference pattern. If there is a significant difference (“Yes” in S22), the resource setting change determination unit 205 determines the reference pattern. After updating (S23), the resource setting changing unit 204 is activated (S24). If not present (“No” in S22), the resource setting change determination unit 205 activates the noise determination unit 202 (S26).
  • the reference pattern is the latest load pattern established in the past cycle, and serves as a reference for determining a change in the load pattern extracted from the request history in the latest cycle.
  • the reference pattern is stored in, for example, the operation information storage unit 206, and the initial value is given by the administrator.
  • the noise determination unit 202 When activated, the noise determination unit 202 records the difference between the extracted load pattern and the reference pattern as noise (S26), compares it with the difference for several past cycles, and if the difference is steady ( In step S27, “Yes”), the resource setting change determination unit 205 is notified. In response to the notification, the resource setting change determining unit 205 updates the reference pattern (S23), and activates the resource setting changing unit 204 (S24). If the difference is not steady (“No” in S27), the resource setting change determination unit 205 and the noise determination unit 202 end the operation in this cycle.
  • the resource setting change determination unit 205 may execute pattern extraction, significance determination, and reference pattern change for each version, or may be executed across all versions. When executed for each version, if there is a significant difference in the load pattern of any version (“Yes” in S22), the resource setting change determination unit 205 updates the reference pattern for that version (S23), The resource setting changing unit 204 is activated (S24).
  • the difference between the resource setting change determining unit 205 a) the load pattern extracted from the request history, b) the threshold value used for determining the significant difference, and the noise determining unit 202 c) the difference from the recorded reference pattern For example, as follows.
  • Example 1 a) Difference in the request appearance rate of the most frequently requested version of each group from the reference pattern of the request appearance rate of the new most frequently requested version of each group (for example, the appearance rate of the most frequently requested version newly increased by 20% or more) And c) the most frequently requested version of each group in the current cycle
  • Example 2 a) Appearance timing of peak resource usage (time, day of the week, date, month), b) Amount of change in appearance timing (for example, a significant difference if the timing changes for two days or more), c) Peak resource usage in the current cycle Quantity appearance timing
  • Example 3 a) Resource usage distribution at each timing within a predetermined period, b) Sum of absolute values of difference in resource usage at each timing (for example, if the sum of differences in thread usage on each day is 50 or more, a significant difference is assumed) ), C) Resource usage distribution in the current cycle
  • Example 4 a) Appearance group, b) and c) None (group disappearance, new appearance is unconditionally determined to be a
  • the resource setting changing unit 204 activated in S24 calculates the peak value for each version (for example, the time period and usage amount) using time series data, and the entire system of all versions accumulated from these resource consumptions.
  • the resource usage status is calculated as time series data.
  • FIG. 10 is a flowchart of the calculation process of the resource setting value of each version by the resource setting changing unit 204.
  • the resource setting change unit 204 acquires the number of REST server devices 100 that provide each version of the service in the resource setting control system 400 from the service configuration management unit 203 (S31).
  • the resource setting change unit 204 calculates the peak resource usage for each version from the request history in the operation information storage unit 206, and divides it by the number of REST server devices 100 operating for each version to obtain a numerical value ( a) is calculated (S32). Further, the resource setting changing unit 204 calculates the resource consumption (b) of the group consuming the most resources at the peak time for each version (S33).
  • the resource setting changing unit 204 compares the information of (a) with the information of (b) for each version, and when (a) is large, (a) is set as the resource setting value. When (b) is larger, the resource setting changing unit 204 sets the value of (b) as the resource setting value (S34 to S36). This is because, when the value of (b) is large, it is considered that a high load is applied to a specific machine, and there is a possibility that the processing cannot be completely performed with the resource setting evenly allocated.
  • the resource setting change determination unit 205 distributes the resource setting value calculated by the above method to each REST server device 100 as a resource request amount (S25 in FIG. 9).
  • the service execution unit 103 receives this resource request amount and changes the resource amount of the resource pool of the specified version.
  • the resource setting control apparatus 200 can appropriately perform resource distribution between versions in a resource setting control system 400 that provides a plurality of versions of a service in parallel during a transition process between service versions. .
  • the reason is that the resource setting change determination unit 205 detects a change in load pattern (progress of migration) based on the request history, and the resource setting change unit 204 sets each version based on the resource usage for each version. This is because the amount of resources to be allocated is determined.
  • the resource setting control apparatus 200 can redistribute the resource settings between versions at an early timing when the service is transferred with a certain number of clients.
  • the reason is that when the load pattern fluctuates by a predetermined threshold value or more, the resource setting change determination unit 205 detects the fluctuation every predetermined cycle.
  • the resource setting control apparatus 200 can appropriately redistribute resource settings between versions even when a client gradually moves to service.
  • the noise determination unit 202 detects the fluctuation for each of a plurality of predetermined periods.
  • FIG. 11 is a diagram illustrating a configuration of a resource setting control system 400 according to the second embodiment.
  • the resource setting control device 200 and the REST server device 100 are separately provided. In the present embodiment, both are integrated. For example, all the components in the resource setting control device 200 according to the first embodiment are arranged on each REST server device 100. The change in arrangement may be reversed.
  • the REST server device 100 shares the operation information before recording in cooperation with each other.
  • the cooperative operation is realized by the workload information sharing unit 208, and the REST server device 100 shares the operation information storage unit 206.
  • Information sharing may be performed only by the REST server apparatus 100 in which the service of the same version as the requested version is operating. For this reason, the workload information sharing unit 208 obtains configuration information from the service configuration management unit 203 and determines a sharing range.
  • FIG. 12 is a diagram illustrating a configuration of a resource setting control device 200 according to the third embodiment.
  • the resource setting control device 200 includes a resource setting change determination unit 205, a resource setting change unit 204, and an operation information storage unit 206.
  • the resource setting control apparatus 200 may be connected to the operation information storage unit 206 at a remote location, for example, via a communication network.
  • the operation information storage unit 206 stores a request history including information on a group, a requested version, and a resource usage amount during service execution of a service request that requests one of a plurality of versions. These pieces of information are transmitted from the server device that provides the service in real time or periodically. When the processing cycle of the resource setting change determination unit 205 is long, manual data movement using a replaceable medium may be performed. Further, the operation information storage unit 206 stores a service request load reference pattern.
  • the resource setting change determination unit 205 extracts a load pattern of a service request within a predetermined period from the request history in the operation information storage unit 206, and updates the reference pattern when a change within a predetermined range from the reference pattern is detected.
  • the resource setting changing unit 204 determines the resource request amount for each version based on the peak value of the resource usage within a predetermined period and the number of server devices that provide the version. Output.
  • the output resource request amount is, for example, when the server device receives this resource request amount and changes the resource amount of the specified version.
  • the resource setting control apparatus 200 can appropriately perform resource distribution between versions in a resource setting control system 400 that provides a plurality of versions of a service in parallel during a transition process between service versions. .
  • the reason is that the resource setting change determination unit 205 detects a change in load pattern (progress of migration) based on the request history, and the resource setting change unit 204 sets each version based on the resource usage for each version. This is because the amount of resources to be allocated is determined.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するシステムにおいて、バージョン間のリソース分配を適切に行う。　ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求されたバージョン、およびサービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の要求履歴から、所定期間内のサービス要求の負荷パターンを抽出し、基準パターンとの所定範囲以上の変化を検出すると基準パターンを更新するリソース設定変更判断手段と、負荷パターンの変化検出時に、バージョン毎に、所定期間内のリソース使用量のピーク値とバージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備えるリソース設定制御装置。

Description

リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体
　本発明は、リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体、特に、システム内に複数バージョンのサービスが混在する状況における、リソース配分を行うリソース設定制御に関する。
　近年、クラウドの環境の整備や仮想化技術・コンテナ技術の発達に伴い、ＲＥＳＴ(Representational State Transfer)やＳＯＡＰ(Simple Object Access Protocol)などのＷｅｂサービスの活用が進んでいる。Ｗｅｂサービスでは、新たなバージョンのサービスがリリースされた後も、既存のバージョンのサービスがすぐに廃止されるわけではなく、複数のバージョンのサービスが同一マシン上に混在する状況が発生する。一般に、利用者が既存のバージョンのサービスから、新しいバージョンに移行するには、ある程度の時間が必要だからである。
　それぞれのバージョンのサービスは疎結合であるが、提供する基本機能はほぼ同じである。そのため、サービスへのリクエストの待ち受けスレッドやＤＢ（Data Base）コネクションなどのリソースのプール管理機能がある場合、バージョン毎のサービスでリソースの確保が必要となる。
　このとき、全てのバージョンが一律同じリソース量を必要とするわけではなく、メインで動くバージョンのサービスが有る一方、下位互換のために残ってはいるがほぼ使われないバージョンのサービスなども有る。バージョン毎にリソースを消費する量が異なるため、バージョン毎に適切なリソース割り当てを行うことが重要である。
　リソースの配分に関連して、下記のような技術が開示されている。
　特許文献１は、サーバ装置の仮想化環境の利便性を向上させる仮想化実行装置を開示する。この装置は、システム構成情報を決定するさい、同じサービスの利用履歴が或るユーザに対しては、過去と同じシステム構成情報を推奨する。また、この装置は、サービス実行時にリソースが不足した場合、仮想計算機やコンテナを追加して、リソース量を拡張する。
　特許文献２は、準最適なグリッド環境内でアプリケーションの動作を維持するシステムを開示する。このシステムにおいては、サービス可用性管理エージェントが、リソースノードのパフォーマンス状態を監視する。パフォーマンス状態が規定された動作要件を満たさないとき、サービス可用性管理エージェントはアプリケーションのリソースノードの使用を調整する。
特開２０１６-１１０２４８号公報 特表２００７-５１８１６９号公報
　複数のバージョンのサービスが同一マシン上に混在する状況において、それぞれのサービスがどの程度のリソース量を必要とするのかは、稼働しているバージョン数、それぞれのサービスを利用するクライアント装置数など、利用者のバージョン移行の進み具合により変化する。このため、システム全体の状況から最適な設定を算出することは難しい。
　マシン台数、サービスバージョン数、または、クライアント数が増えた場合、最適な設定値の算出には膨大な処理コストがかかるため、人間がリアルタイムで必要リソース量を算出するのは難しい。
　また、クライアントアプリが利用するＷｅｂサービスの新バージョンが追加されと、サービス提供を行うサーバ全体の負荷状況が変わるため、これらの契機に合わせて、サーバ全体のリソースの設定が最適化されるように見直しを行うべきである。しかし、クライアント/サーバ間は疎結合であり、クライアントが呼び出すＷｅｂサービスはクライアントの実装に依存するため、サーバ側でＷｅｂサービスの各バージョンの利用クライアント数を把握することは難しく、設定変更の適切な契機が把握できない。
　前述の特許文献１および特許文献２に開示された技術は、いずれも、使用されるサービスのバージョン間の負荷の変化、すなわち、利用者のバージョン移行の進行を契機としてリソースの再配分を行うものではなく、上記課題を解決しない。
　本発明は、上記課題を解決し、サービスの移行などに伴い並行して使用されるサービスのバージョン間の負荷の変化を契機としてリソースの配分を見直す、リソース設定制御装置等を提供することを目的とする。
　本発明の１実施の形態のリソース設定制御装置は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断手段と、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備える。
　本発明の１実施の形態のリソース設定制御方法は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを記憶し、前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新し、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する。
　本発明の１実施の形態のコンピュータ読み取り可能記録媒体は、ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断処理と、前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更処理と、をコンピュータに実行させるリソース設定制御プログラムを非一時的に格納する。
　本発明にかかるリソース設定制御装置は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するシステムにおいて、バージョン間のリソース分配を適切に行うことが出来る。
図１は、第１の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。 図２は、バージョン特定ルール記憶部３０１に格納されるバージョン特定ルールの例を示す図である。 図３は、グルーピングルール記憶部３０２に格納されるグルーピングルールの例を示す図である。 図４は、稼働情報記憶部２０６に格納されるワークロード情報の例を示す図である。 図５は、構成情報記憶部２０７に格納されるバージョン毎のサービス稼働状況情報の例を示す図である。 図６は、コンピュータ装置６００の構成を示す図である。 図７は、ＲＥＳＴサーバ装置１００がリクエストを受信してサービスを実行し、リクエストの履歴がリソース設定制御装置２００の稼働情報記憶部２０６に蓄積されるまでの動作を示すフローチャートである。 図８は、リクエスト解析部１０１が行うリクエスト解析の詳細を示すフローチャートである。 図９は、リソース設定変更判断部２０５による設定変更判断処理のフローチャートである。 図１０は、リソース設定変更部２０４による各バージョンのリソース設定値の計算処理のフローチャートである。 図１１は、第２の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。 図１２は、第３の実施の形態にかかるリソース設定制御装置２００の構成を示す図である。
　＜第１の実施の形態＞
　＜構成＞
　図１は、第１の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。リソース設定制御システム４００は、通信ネットワークで相互に接続されたＲＥＳＴサーバ装置１００とリソース設定制御装置２００、並びに、ＲＥＳＴサーバ装置１００に接続されたサービスクライアント装置３００を包含する。ＲＥＳＴサーバ装置１００とサービスクライアント装置３００は、複数台存在しても良い。
　ＲＥＳＴサーバ装置１００は、複数バージョンのサービスをサービスクライアント装置３００に対して提供する。リソース設定制御装置２００は、バージョン間のリソース配分を決定する。ここで、リソースは、例えば、プール管理されている、サービスへのリクエストの待ち受けスレッドやＤＢコネクション、メモリ領域、通信パスである。
　ＲＥＳＴサーバ装置１００は、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２を備えている。ＲＥＳＴサーバ装置１００は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２を備えている、または、他の装置と共有している。
　サービス実行部１０３は、サービスクライアント装置３００から、サービスリクエスト（以降、リクエストと略記する）を受信して、指定されたバージョンのサービスを実行する。ＲＥＳＴサーバ装置１００が複数存在するとき、各サービスクライアント装置３００のリクエストは、例えば、図示しないロードバランサにより、適宜、何れかのＲＥＳＴサーバ装置１００に振り分けられる。
　リクエスト解析部１０１は、サービスへのリクエストを解析し、利用サービスのバージョン特定および、リクエストのグルーピングを行う。この時、リクエスト解析部１０１は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２を参照する。
　リソース使用量採取部１０２は、サービスの実行時のリソース使用量をバージョン単位でグループを識別できるように採取して、リソース設定制御装置２００に送信する。
　リソース設定制御装置２００は、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５を備えている。リソース設定制御装置２００は、さらに、稼働情報記憶部２０６と構成情報記憶部２０７を備えている。
　ワークロード情報採取部２０１は、各々のＲＥＳＴサーバ装置１００のリソース使用量採取部１０２からサービスの実行時のリソース使用量を受信して、稼働情報記憶部２０６に格納し、リソース設定制御システム４００の統合された記録として蓄積する。
　サービス構成管理部２０３は、構成情報記憶部２０７を利用して、リソース設定制御システム４００全体でバージョン毎のサービス稼働状況を把握する。
　リソース設定変更判断部２０５は、稼働情報記憶部２０６に蓄積された情報を基に、分散環境で発生して処理されたリクエストの負荷パターンを抽出し、その状況に基づいて、バージョン間のリソースの配分変更の要否をチェックする。このとき、ノイズ判定部２０２は、負荷パターンのノイズ的な情報から、長期的な負荷パターンの変化の有無をチェックする。
　リソース設定変更部２０４は、リソース設定制御システム４００全体でのバージョン毎のサービス稼働状況とリクエストのグループのリソース使用状況から、バージョン毎のリソースの適切な設定値を算出する。そして、リソース設定変更部２０４は、算出値に基づくリソース配分変更指示を、ＲＥＳＴサーバ装置１００に送信する。
　図２は、バージョン特定ルール記憶部３０１に格納されるバージョン特定ルールの例を示す図である。リクエスト解析部１０１は、バージョン特定ルール記憶部３０１に格納されているバージョン特定ルールに従って、リクエストの情報から要求されているサービスのバージョンを特定する。バージョン特定ルールは、リクエストのどの情報のどの部分からバージョン情報を抽出するかを指定する。
　図２のａ）は、ＵＲＬ（Uniform Resource locator）でバージョン判定する設定例である。このルールは、リクエストのＵＲＬパスの”version”で示された、”rest/”に続く部分からバージョン情報を抽出することを指定している。
　図２のｂ）は、ポート番号でバージョン判定する設定例である。このルールは、リクエストのポート番号の”version”で示された、”//<host>/”に続く部分からバージョン情報を抽出することを指定している。
　図２のｃ）は、同様に、クエリパラメータでバージョン判定する設定例である。このルールは、”version=“に続く部分からバージョン情報を抽出することを指定している。
　図３は、グルーピングルール記憶部３０２に格納されるグルーピングルールの例を示す図である。リクエスト解析部１０１は、グルーピングルール記憶部３０２に格納されているグルーピングルールに従って、リクエストが属するグループ識別子を特定する。グルーピングルールは、リクエストのどの情報のどの部分からグループ識別子を抽出するかを指定する。
　図３のａ）は、認証Ｉｄ（Identification）でグルーピングする設定例である。このルールは、リクエストのＨＴＴＰ（Hyper Text Transfer Protocol）ヘッダキーのＡＵＴＨ＿ＩＤフィールドからグループ識別子を抽出することを指定している。
　図３のｂ）は、認証Ｉｄの一部でグルーピングする設定例である。このルールは、リクエストのＨＴＴＰヘッダキーのＡＵＴＨ＿ＩＤフィールドの０乃至５バイト目からグループ識別子を抽出することを指定している。なお、substringは、値の切り取りを指定する関数である。
　図３のｃ）は、クライアントアプリのTypeでグルーピングする設定例である。このルールは、リクエストのパラメータキーCLIENT_TYPEからグループ識別子を抽出することを指定している。
　図４は、稼働情報記憶部２０６に格納されるワークロード情報の例を示す図である。ワークロード情報は、各ＲＥＳＴサーバ装置１００が受信して処理したリクエストの履歴である。このリクエスト履歴情報は、各ＲＥＳＴサーバ装置１００のリクエスト解析部１０１と、リソース使用量採取部１０２が収集した情報である。履歴内の各リクエストレコードは、例えば、処理完了時刻、要求されたサービスのバージョン特定情報、グループ識別子、および、当該リクエストの処理に要したリソースの種類と使用量である。
　図５は、構成情報記憶部２０７に格納されるバージョン毎のサービス稼働状況情報の例を示す図である。サービス稼働状況情報は、例えば、ＲＥＳＴサーバ装置１００の識別子（マシンＡ、マシンＢ等）と、当該ＲＥＳＴサーバ装置１００上で提供されているサービスのバージョン番号を関連付けて格納している。図５の例は、Ｖ１で示されるバージョン１は、マシンＡとＢの２台のＲＥＳＴサーバ装置１００上でサービスされていることを示している。
　ここで、ＲＥＳＴサーバ装置１００のサービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２は、論理回路で構成される。バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２は、ディスク等の不揮発性の記憶装置に記憶される。
　ＲＥＳＴサーバ装置１００は、コンピュータ装置６００により実現されても良い。図６は、コンピュータ装置６００の構成を示す図である。コンピュータ装置６００は、バス６４０で相互に接続された、プロセッサ６１０、主記憶部６３０、および、外部記憶装置６２０を備える。プロセッサ６１０は、バス６４０を経由して、主記憶部６３０、および、外部記憶装置６２０に対してデータの読み書きを行う。また、プロセッサ６１０は、主記憶部６３０に格納されているプログラム６５０を実行する。なお、プログラム６５０は、当初外部記憶装置６２０に格納されており、コンピュータ装置６００の初期設定時に、プロセッサ６１０が外部記憶装置６２０から主記憶部６３０にロードしても良い。
　ここで、主記憶部６３０は半導体メモリ装置である。外部記憶装置６２０はディスク装置、または、半導体記憶装置等の記憶装置である。
　プロセッサ６１０は、プログラム６５０を実行することにより、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２として機能する。すなわち、プロセッサ６１０は、プログラム６５０を実行することにより、サービス実行部１０３、リクエスト解析部１０１、および、リソース使用量採取部１０２が行う処理を実行する。
　外部記憶装置６２０は、バージョン特定ルール記憶部３０１とグルーピングルール記憶部３０２として使用されても良い。
　さらに、リソース設定制御装置２００のワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５は、論理回路で構成される。稼働情報記憶部２０６と構成情報記憶部２０７は、ディスク等の不揮発性の記憶装置に記憶される。
　リソース設定制御装置２００は、図６に示されるコンピュータ装置６００により実現されても良い。
　プロセッサ６１０は、プログラム６５０を実行することにより、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５として機能する。すなわち、プロセッサ６１０は、プログラム６５０を実行することにより、ワークロード情報採取部２０１、ノイズ判定部２０２、サービス構成管理部２０３、リソース設定変更部２０４、および、リソース設定変更判断部２０５が行う処理を実行する。
　外部記憶装置６２０は、稼働情報記憶部２０６や構成情報記憶部２０７として使用されても良い。
　＜動作＞
　図７は、ＲＥＳＴサーバ装置１００がリクエストを受信してサービスを実行し、リクエストの履歴がリソース設定制御装置２００の稼働情報記憶部２０６に蓄積されるまでの動作を示すフローチャートである。
　まず、サービスクライアント装置３００は、サービス（ＲＥＳＴ ＡＰＩ）を実行するため、クライアントの認証を行う（Ｓ１）。ＲＥＳＴサーバ装置１００は、クライアントを認証し、認証済のトークンをサービスクライアント装置３００に払い出す。以降のサービスクライアント装置３００からのリクエストは、認証済のトークンを付与されて、ＲＥＳＴサーバ装置１００へ送付される。
　ＲＥＳＴサーバ装置１００のサービス実行部１０３は、リクエストを受け取るとサービスを実行する（Ｓ２）。サービス実行に際し、リクエスト解析部１０１は、リクエストを解析して、リクエストから、呼び出しているサービスのバージョンの特定、および、グルーピングを行うためのグループ識別子抽出を行い、リソース設定制御装置２００に送信する（Ｓ３）。
　図８は、図７ｂのＳ３において、リクエスト解析部１０１が行うリクエスト解析の詳細を示すフローチャートである。
　リクエスト解析部１０１は、先ず、バージョン特定ルール記憶部３０１に保存されたバージョン特定ルールを用いて（Ｓ１１）、送信されたリクエストの情報から、そのリクエストがどのバージョンのサービス要求であるかを特定し、リソース設定制御装置２００に送信する（Ｓ１２）。
　バージョンは、ＵＲＬパスによって指定されることがある。この場合、ＲＥＳＴサーバ装置１００は、例えば、バージョン１のＡＰＩを「http://host/api/v1/service」のようなパスで、バージョン２のＡＰＩを「http://host/api/v2/service」のようなパスで、公開する。そして、リクエスト解析部１０１は、http://host/api/v1/はバージョン１のＡＰＩ、http://host/api/v2/はバージョン２のＡＰＩと、パス内に含まれた情報を用いてバージョンを認識する。
　この場合、バージョン特定ルールは、バージョンの識別に「ＵＲＬパス」を利用することと、ＵＲＬパスの文字列の中でバージョンを示す場所を記載する（図２のａ）参照）。
　次に、リクエスト解析部１０１は、グルーピングルール記憶部３０２に保存されたグルーピングルールを用いて（Ｓ１３）、送信されたリクエストの情報から、そのリクエストが属するグループの識別子を抽出し、リソース設定制御装置２００に送信する（Ｓ１４）。
　リクエストは、意味のある単位でグルーピングされる。例えば、同一Ｉｄのユーザからきたリクエストを１つのグループとして利用する場合、リクエスト解析部１０１は、リクエスト内からユーザＩｄをグループ識別子として抽出する。別の例として、ユーザが属する会社毎にリクエストを束ねる場合は、リクエスト解析部１０１は、Ｉｄ内に含まれる会社コードを抽出する。
　リソース設定制御システム４００の管理者は、先ず、バージョン間のリソース配分決定の為に、リグエストをどのようにグルーピングするかを決定する。次に、管理者は、そのグループの識別情報をリクエストのどこから抽出すべきかを、グルーピングルールとして予めグルーピングルール記憶部３０２内に格納しておくのである（図３参照）。
　リクエスト解析（図７のＳ３）が終了すると、リソース使用量採取部１０２は、リクエストの実行に使用したリソース使用量を、例えば、サービス実行部１０３から取得し、リソース設定制御装置２００に送信する（Ｓ４）。具体的には、サービス実行部１０３が、リクエスト実行中にリソース使用量を監視してリクエストに記録し、リソース使用量採取部１０２が、その記録を参照すれば良い。
　リソース設定制御装置２００では、ワークロード情報採取部２０１が、リクエスト解析部１０１とリソース使用量採取部１０２から送られてきた情報を受信して（Ｓ５）、稼働情報記憶部２０６にリクエスト履歴として蓄積していく（Ｓ６、図４参照）。このとき、ワークロード情報採取部２０１は、ログインからログアウトを１つのワークロードと見なし、リクエストを時間帯別にグループ毎に記録していく。
　図９は、リソース設定変更判断部２０５による設定変更判断処理のフローチャートである。リソース設定変更判断部２０５は、所定の期間毎に起動され、稼働情報記憶部２０６のリクエスト履歴から負荷パターンを抽出する（Ｓ２１）。定常化された運用の多くの場合、ある一定の周期でリクエスト送信をパターン化することができる。リソース設定変更判断部２０５は、リクエストの履歴から、所定の期間ごとにこのパターンを抽出するのである。
　この所定期間は、１日、１週間、１か月など、リクエストをある時系列の固まりで意味づけしたときに、リクエストの送信タイミングに傾向が出てくる単位期間であり、例えば、以下のような期間である。
・１日の中で特定の時間のみ負荷が高く／低くなるときは、所定期間は日単位とし、リソース設定変更判断部２０５は、時間ごとの負荷のパターンを抽出する。
・１週間の中で特定の曜日のみ負荷が高く／低くなるときは、所定期間は１週間単位とし、リソース設定変更判断部２０５は、曜日ごとの負荷のパターンを抽出する。
・１ヶ月の中で、月初めや月終わりの週や日で負荷が高く／低くなるときは、所定期間は1か月単位とし、リソース設定変更判断部２０５は、週や日ごとの負荷のパターンを抽出する。
・四半期（３ヶ月）の中で、期の初めや終わりの月、週や日で負荷が高く／低くなるときは、所定期間は四半期単位とし、リソース設定変更判断部２０５は、月や週や日ごとの負荷のパターンを抽出する。
・半年や年の中で、特定の月や週や日で負荷が高く／低くなるときは、所定期間は、半年や年単位とし、月や週や日ごとの負荷のパターンを抽出する。
　リソース設定変更判断部２０５は、Ｓ２１で、最新周期のリクエスト履歴から負荷パターンを抽出した後に、このパターンを基準パターンと比較し、有意差が有れば（Ｓ２２で”Ｙｅｓ”）、基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。無ければ（Ｓ２２で”Ｎｏ”）、リソース設定変更判断部２０５は、ノイズ判定部２０２を起動する（Ｓ２６）。
　上記説明から明らかなように、基準パターンは、過去の周期で確立された最新の負荷パターンであり、最新周期のリクエスト履歴から抽出される負荷パターンの変化を判定する為の基準となるものである。基準パターンは、例えば、稼働情報記憶部２０６に格納されており、初期値は管理者により与えられる。
　起動されると、ノイズ判定部２０２は、抽出した負荷パターンと基準パターンと差異をノイズとして記録し（Ｓ２６）、過去の数周期分の差異との比較を行い、差異が定常的であれば（Ｓ２７で”Ｙｅｓ”）、リソース設定変更判断部２０５に通知する。リソース設定変更判断部２０５はその通知を受けて、基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。差異が定常的でなければ（Ｓ２７で”Ｎｏ”）、リソース設定変更判断部２０５およびノイズ判定部２０２は、この周期の動作を終了する。
　なお、リソース設定変更判断部２０５は、バージョン毎にパターンの抽出、有意判定、および、基準パターン変更を、バージョン毎に実行しても良いし、全バージョン横断的に実行しても良い。バージョン毎に実行した場合、リソース設定変更判断部２０５は、何れかのバージョンの負荷パターンに有意差が有れば（Ｓ２２で”Ｙｅｓ”）、当該バージョンの基準パターンを更新して（Ｓ２３）、リソース設定変更部２０４を起動する（Ｓ２４）。
　なお、ここで、リソース設定変更判断部２０５が、ａ）リクエスト履歴から抽出する負荷パターン、ｂ）有意差の判定に使用する閾値、ノイズ判定部２０２が、ｃ）記録する基準パターンとの差異は、例えば以下の通りである。
　例１：
　ａ）各グループの最頻度要求バージョン、ｂ）各グループの新最頻度要求バージョンの要求出現率の基準パターンとの差異（例えば、新たに最頻度要求バージョンとなったもの出現率が２０％以上増加していたら有意差とする）、ｃ）今周期の各グループの最頻度要求バージョン
　例２：
　ａ）ピークリソース使用量の出現タイミング（時間、曜日、日付、月）、ｂ）出現タイミングの変化量（例えば、２日以上タイミングが変化したら有意差とする）、ｃ）今周期のピークリソース使用量の出現タイミング
　例３：
　ａ）所定期間内の各タイミングにおけるリソース使用量分布、ｂ）各タイミングでのリソース使用量差異の絶対値の総和（例えば、各曜日のスレッド使用量の差の総和が５０以上なら有意差とする）、ｃ）今周期のリソース使用量分布
　例４：
　ａ）出現グループ、ｂ）およびｃ）無（グループの消滅、新規登場は、無条件に有意差と判定する）
　ノイズ判定部２０２は、記録する基準パターンとの差異が、所定数の周期の間、全く変化が無ければ、Ｓ２７で差異は定常的と判断しても良いし、或る範囲の変動を許容して定常的と判断しても良い。ノイズ判定部２０２は、基準パターンとの差異を、例えば、稼働情報記憶部２０６に記録する。
　Ｓ２４で起動されたリソース設定変更部２０４は、バージョン毎のピーク値(例えば、ピ時間帯と使用量)を、時系列データを用いて算出し、それらのリソース消費量から全バージョン累計のシステム全体のリソース使用状況を時系列データとして算出する。
　図１０は、リソース設定変更部２０４による各バージョンのリソース設定値の計算処理のフローチャートである。
　リソース設定変更部２０４は、サービス構成管理部２０３からリソース設定制御システム４００において、各バージョンのサービスを提供しているＲＥＳＴサーバ装置１００の台数を取得する（Ｓ３１）。
　次に、リソース設定変更部２０４は、稼働情報記憶部２０６のリクエスト履歴からバージョン毎のピーク時のリソース使用量を算出し、バージョン毎に稼働しているＲＥＳＴサーバ装置１００の台数で割って数値(ａ)を算出する（Ｓ３２）。また、リソース設定変更部２０４は、バージョン毎にピーク時に最もリソースを消費しているグループのリソース消費量（ｂ）を算出する（Ｓ３３）。
　リソース設定変更部２０４は、バージョンごとに、（ａ）の情報と（ｂ）の情報を比較し、（ａ）が大きい場合は（ａ）をリソース設定値とする。リソース設定変更部２０４は（ｂ）のほうが大きい場合、（ｂ）の値をリソースの設定値とする（Ｓ３４乃至Ｓ３６）。これは、（ｂ）の値が大きなときは、特定のマシンに高負荷がかかることが考えられ、均等に割り振ったリソース設定では、処理がさばききれなくなる恐れが有るからである。
　最後に、リソース設定変更判断部２０５は、上記の方法で算出したリソース設定値を各ＲＥＳＴサーバ装置１００にリソース要求量として配信する（図９のＳ２５）。
　各ＲＥＳＴサーバ装置１００では、例えば、サービス実行部１０３がこのリソース要求量を受信して、指定されたバージョンのリソースプールのリソース量を変更する。
　＜効果＞
　本実施の形態にかかるリソース設定制御装置２００は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するリソース設定制御システム４００において、バージョン間のリソース分配を適切に行うことが出来る。
　その理由は、リソース設定変更判断部２０５が、リクエスト履歴に基づいて負荷パターンの変化（移行の進展）を検知し、リソース設定変更部２０４が、バージョン毎のリソース使用量に基づいて、各バージョンに割当てられるリソース量を決定するからである。
　さらに、本実施の形態にかかるリソース設定制御装置２００は、クライアントが有る程度の数でサービス移行した時は、早いタイミングで、バージョン間のリソース設定の再配分を実施できる。
　その理由は、負荷パターンが所定閾値以上変動した場合は、リソース設定変更判断部２０５が、所定周期ごとに変動を検知するからである。
　さらに、本実施の形態にかかるリソース設定制御装置２００は、クライアントが少しずつサービス移行した場合でも、バージョン間のリソース設定の再配分を、適切に実施できる。
　その理由は、負荷パターンが所定閾値以内で変動した場合は、ノイズ判定部２０２が、複数の所定周期ごとに変動を検知するからである。
　＜第２の実施形態＞
　図１１は、第２の実施の形態にかかるリソース設定制御システム４００の構成を示す図である。第１の実施の形態にかかるリソース設定制御システム４００は、リソース設定制御装置２００とＲＥＳＴサーバ装置１００を別に設けているが、本実施の形態では両者を統合する。例えば、第１の実施の形態におけるリソース設定制御装置２００内の構成要素を全て各ＲＥＳＴサーバ装置１００上に配置する。配置の変更は、逆でも良い。
　ログインからログアウトまでの処理をまとめて稼働情報記憶部２０６に記録するため、ＲＥＳＴサーバ装置１００は、相互に協調して、記録前の稼働情報を共有する。協調動作はワークロード情報共有部２０８によって実現され、各ＲＥＳＴサーバ装置１００で稼働情報記憶部２０６を共有する。
　情報の共有は、リクエストを受けたバージョンと同じバージョンのサービスが動作しているＲＥＳＴサーバ装置１００のみでなされれば良い。このため、ワークロード情報共有部２０８は、サービス構成管理部２０３から構成情報を得て共有範囲を決定する。
　＜第３の実施形態＞
　図１２は、第３の実施の形態にかかるリソース設定制御装置２００の構成を示す図である。リソース設定制御装置２００は、リソース設定変更判断部２０５、リソース設定変更部２０４、および、稼働情報記憶部２０６を備える。リソース設定制御装置２００は、稼働情報記憶部２０６を備える代わりに、通信網を経由して、例えば遠隔地の稼働情報記憶部２０６に接続されていても良い。
　稼働情報記憶部２０６は、複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求されたバージョン、およびサービス実行中のリソース使用量の情報を含む要求履歴を格納している。これらの情報は、当該サービスを提供するサーバ装置からリアルタイムに、あるいは、定期的に一括して送信されてくる。リソース設定変更判断部２０５の処理周期が長い時は、可換媒体による人手によるデータ移動でも良い。さらに、稼働情報記憶部２０６は、サービス要求の負荷の基準パターンを格納する。
　リソース設定変更判断部２０５は、稼働情報記憶部２０６内の要求履歴から、所定期間内のサービス要求の負荷パターンを抽出し、基準パターンとの所定範囲以上の変化を検出すると基準パターンを更新する。
　負荷パターンの変化が検出された時に、リソース設定変更部２０４は、バージョン毎に、所定期間内のリソース使用量のピーク値とバージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する。
　出力されたリソース要求量は、例えば、サーバ装置がこのリソース要求量を受信して、指定されたバージョンのリソース量を変更する。
　本実施の形態にかかるリソース設定制御装置２００は、サービスのバージョン間の移行過程で複数バージョンのサービスを並行して提供するリソース設定制御システム４００において、バージョン間のリソース分配を適切に行うことが出来る。
　その理由は、リソース設定変更判断部２０５が、リクエスト履歴に基づいて負荷パターンの変化（移行の進展）を検知し、リソース設定変更部２０４が、バージョン毎のリソース使用量に基づいて、各バージョンに割当てられるリソース量を決定するからである。
　以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
　この出願は、２０１７年１月１２日に出願された日本出願特願２０１７－３０８３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１００　　ＲＥＳＴサーバ装置
　１０１　　リクエスト解析部
　１０２　　リソース使用量採取部
　１０３　　サービス実行部
　２００　　リソース設定制御装置
　２０１　　ワークロード情報採取部
　２０２　　ノイズ判定部
　２０３　　サービス構成管理部
　２０４　　リソース設定変更部
　２０５　　リソース設定変更判断部
　２０６　　稼働情報記憶部
　２０７　　構成情報記憶部
　２０８　　ワークロード情報共有部
　３００　　サービスクライアント装置
　３０１　　バージョン特定ルール記憶部
　３０２　　グルーピングルール記憶部
　４００　　リソース設定制御システム
　６００　　コンピュータ装置
　６１０　　プロセッサ
　６２０　　外部記憶装置
　６３０　　主記憶部
　６４０　　バス
　６５０　　プログラム

Claims (10)

  1. 　ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断手段と、
    　前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更手段と、を備えるリソース設定制御装置。
  2. 　前記グループは、前記サービス要求の送信元に基づいて構成されており、
    　前記リソース設定変更判断手段は、前記グループと、要求する前記バージョンの対応関係を前記負荷パターンとして抽出する、請求項１のリソース設定制御装置。
  3. 　前記所定期間は、日であり、前記リソース設定変更判断手段は、所定の時刻における前記サービス要求の負荷を前記負荷パターンとして抽出する、
    　前記所定期間は、週であり、前記リソース設定変更判断手段は、所定の曜日における前記サービス要求の負荷を前記負荷パターンとして抽出する、
    　前記所定期間は、月であり、前記リソース設定変更判断手段は、前記所定期間における所定の順番の日、若しくは週における前記サービス要求の負荷を前記負荷パターンとして抽出する、または、
    前記所定期間は、複数の月であり、前記リソース設定変更判断手段は、前記所定期間における所定の順番の日、週、若しくは月における前記サービス要求の負荷を前記負荷パターンとして抽出する、請求項１乃至請求項２のいずれか１項のリソース設定制御装置。
  4. 　前記負荷パターンと前記基準パターンとの差異をノイズとして記録し、複数の前記所定期間の前記ノイズに基づいて、前記基準パターンの更新要否を判定するノイズ判定手段を、さらに備える、請求項１乃至請求項３のいずれか１項のリソース設定制御装置。
  5. 　前記リソース設定変更手段は、前記バージョンごとに、ａ）前記所定期間内の前記リソース使用量のピーク値を前記バージョンの前記サービスを提供する前記サーバ装置数で除した値と、ｂ）前記バージョンを要求する前記グループの中の最大の前記リソース使用量との大きな方の値を前記リソース要求量に決定する、請求項１乃至請求項４のいずれか１項のリソース設定制御装置。
  6. 　前記サービス要求から要求された前記バージョンの前記サービスを実行するサービス実行手段と、
    　前記サービス要求から、前記グループと前記バージョンの情報を抽出して送信するリクエスト解析手段と、
    　前記サービス要求が前記サービスの実行中に使用した前記リソース使用量を採取して送信するリソース使用量採取手段と、を備える複数の前記サーバ装置、並びに、
    　前記稼働情報記憶手段と、
    　前記グループと前記バージョンの情報、および、前記使用リソース量を受信して前記稼働情報記憶手段に追記するワークロード情報採取手段を備える、請求項１乃至請求項５のいずれか１項のリソース設定制御装置と、を包含するリソース設定制御システム。
  7. 　前記リクエスト解析手段は、ａ）前記サービス要求から要求された前記サービスの前記バージョンの情報を抽出する第１のルールを格納するバージョン特定ルール記憶手段から前記第１のルールを、ｂ）前記サービス要求から前記グループの情報を抽出する第２のルールを格納するグルーピングルール記憶手段から前記第２のルールを、取得し、前記第１のルールと前記第２のルールを適用して、前記サービス要求から、前記グループと前記バージョンの情報を抽出する、請求項６のリソース設定制御システム。
  8. 　ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを記憶し、
    　前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新し、
    　前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力する、リソース設定制御方法。
  9. 　前記グループは、前記サービス要求の送信元に基づいて構成されており、
    　前記グループと、要求する前記バージョンの対応関係を前記負荷パターンとして抽出する、請求項８のリソース設定制御方法。
  10. 　ａ）複数バージョンの内の何れかのサービスを要求するサービス要求の、グループ、要求された前記バージョン、および前記サービス実行中のリソース使用量の情報を含む要求履歴と、ｂ）前記サービス要求の負荷の基準パターンを格納する稼働情報記憶手段内の前記要求履歴から、所定期間内の前記サービス要求の負荷パターンを抽出し、前記基準パターンとの所定範囲以上の変化を検出すると前記基準パターンを更新するリソース設定変更判断処理と、
    　前記負荷パターンの変化検出時に、前記バージョン毎に、前記所定期間内の前記リソース使用量のピーク値と前記バージョンを提供するサーバ装置数とに基づいてリソース要求量を決定して出力するリソース設定変更処理と、をコンピュータに実行させるリソース設定制御プログラムを格納するコンピュータ読み取り可能記録媒体。
PCT/JP2018/000162 2017-01-12 2018-01-09 リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体 WO2018131556A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/475,497 US10891164B2 (en) 2017-01-12 2018-01-09 Resource setting control device, resource setting control system, resource setting control method, and computer-readable recording medium
JP2018561355A JP6798564B2 (ja) 2017-01-12 2018-01-09 リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、リソース設定制御プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-003083 2017-01-12
JP2017003083 2017-01-12

Publications (1)

Publication Number Publication Date
WO2018131556A1 true WO2018131556A1 (ja) 2018-07-19

Family

ID=62839926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/000162 WO2018131556A1 (ja) 2017-01-12 2018-01-09 リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体

Country Status (3)

Country Link
US (1) US10891164B2 (ja)
JP (1) JP6798564B2 (ja)
WO (1) WO2018131556A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210103830A1 (en) * 2019-10-08 2021-04-08 At&T Intellectual Property I, L.P. Machine learning based clustering and patterning system and method for network traffic data and its application
CN113727366A (zh) * 2020-05-25 2021-11-30 索尼公司 电子设备、无线通信方法和计算机可读存储介质
US11782895B2 (en) 2020-09-07 2023-10-10 Mellanox Technologies, Ltd. Cuckoo hashing including accessing hash tables using affinity table
US11917042B2 (en) * 2021-08-15 2024-02-27 Mellanox Technologies, Ltd. Optimizing header-based action selection
US11929837B2 (en) 2022-02-23 2024-03-12 Mellanox Technologies, Ltd. Rule compilation schemes for fast packet classification
US11968285B2 (en) 2022-02-24 2024-04-23 Mellanox Technologies, Ltd. Efficient memory utilization for cartesian products of rules

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007518169A (ja) * 2004-01-14 2007-07-05 インターナショナル・ビジネス・マシーンズ・コーポレーション 準最適な最適とはいえないグリッド環境内におけるアプリケーションの動作の維持
JP2008310812A (ja) * 2007-06-12 2008-12-25 Ricoh Co Ltd 画像形成装置上の効率的なウェブ・サービス・アプリケーション・ステータス自己制御システム
JP2016110248A (ja) * 2014-12-03 2016-06-20 日本電信電話株式会社 仮想化実行装置、仮想化システム、および、リソース最適化方法
JP2017004235A (ja) * 2015-06-10 2017-01-05 富士ゼロックス株式会社 管理装置及びプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030018694A1 (en) * 2000-09-01 2003-01-23 Shuang Chen System, method, uses, products, program products, and business methods for distributed internet and distributed network services over multi-tiered networks
US10372926B1 (en) * 2015-12-21 2019-08-06 Amazon Technologies, Inc. Passive distribution of encryption keys for distributed data stores

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007518169A (ja) * 2004-01-14 2007-07-05 インターナショナル・ビジネス・マシーンズ・コーポレーション 準最適な最適とはいえないグリッド環境内におけるアプリケーションの動作の維持
JP2008310812A (ja) * 2007-06-12 2008-12-25 Ricoh Co Ltd 画像形成装置上の効率的なウェブ・サービス・アプリケーション・ステータス自己制御システム
JP2016110248A (ja) * 2014-12-03 2016-06-20 日本電信電話株式会社 仮想化実行装置、仮想化システム、および、リソース最適化方法
JP2017004235A (ja) * 2015-06-10 2017-01-05 富士ゼロックス株式会社 管理装置及びプログラム

Also Published As

Publication number Publication date
US20190340028A1 (en) 2019-11-07
JPWO2018131556A1 (ja) 2019-11-07
JP6798564B2 (ja) 2020-12-09
US10891164B2 (en) 2021-01-12

Similar Documents

Publication Publication Date Title
WO2018131556A1 (ja) リソース設定制御装置、リソース設定制御システム、リソース設定制御方法、および、コンピュータ読み取り可能記録媒体
US9794135B2 (en) Managed service for acquisition, storage and consumption of large-scale data streams
JP5614226B2 (ja) 仮想マシン制御装置、仮想マシン制御プログラムおよび仮想マシン制御方法
WO2012056596A1 (ja) 計算機システム及び処理制御方法
JP5664098B2 (ja) 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム
US11093296B2 (en) System, virtualization control apparatus, method for controlling a virtualization control apparatus, and program
CN103761146B (zh) 一种MapReduce动态设定slots数量的方法
CN109478147B (zh) 分布式计算系统中的自适应资源管理
US10178046B1 (en) Reducing quota access
US11190431B2 (en) Prioritized client-server communications based on server health
Konstantinou et al. Tiramola: elastic nosql provisioning through a cloud management platform
JP2016133964A (ja) 計算資源割当て方法およびシステム
EP3274859B1 (en) Cluster computing service assurance apparatus and method
JP2014509036A (ja) メトリックデータに動的にタグを付けるための方法およびシステム
CN111092921A (zh) 数据采集方法、装置及存储介质
CN109960579B (zh) 一种调整业务容器的方法及装置
US9349012B2 (en) Distributed processing system, distributed processing method and computer-readable recording medium
JPWO2017017774A1 (ja) ストレージ監視システムおよびその監視方法
JP2016506557A (ja) 異なる環境どうし間でのジョブ実行依頼のトランスペアレントなルーティング
JP6094272B2 (ja) 管理システム、管理方法、管理プログラム及び管理装置
KR20210107099A (ko) 비정상 이벤트에 대한 가상 머신의 처리 용량 증가
JP2018032245A (ja) 計算機システム及びリソース制御方法
JP7235296B2 (ja) セッション管理方法、セッション管理装置、プログラム
JP7567669B2 (ja) 情報処理システム
JP2019061450A (ja) 情報処理装置、情報処理システム及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18739315

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018561355

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18739315

Country of ref document: EP

Kind code of ref document: A1