Patent Description:
There is a widely known service which enables an unspecified large number of users to use arithmetic operation resources by paying fees. <CIT> discloses a computer implementation method including: receiving a definition of a task, wherein the definition includes a necessary deadline time of day and the necessary deadline time of day includes a user designated deadline for the completion of execution of the task; deciding an estimated time period for completing the execution of the task with respect to each of a plurality of computing resources; selecting one or more computing resources among the computing resources on the basis of an estimated cost for completing the execution of the task with respect to each of the plurality of computing resources; and starting the execution of the task at a time of day which is scheduled and set by using the selected one or more computing resources, wherein the scheduled and set time of day is earlier than the necessary deadline time of day by at least the estimated time period.

<CIT> discloses methods and systems for optimization of task execution.

The invention described in <CIT> cannot execute data processing by a designated date and time in consideration of forced stoppage.

Optional embodiments of the invention are defined in the dependent claims.

An arithmetic operation method is an arithmetic operation method executed by a computer for performing arithmetic operations of a plurality of subtasks by using an arithmetic operation system equipped with an inexpensive execution unit for which a usage fee is inexpensive, but which may possibly be forcibly stopped, and an expensive execution unit for which a usage fee is expensive, but which will never be forcibly stopped, wherein the arithmetic operation method includes: a simultaneous execution quantity calculation step of calculating a simultaneous execution quantity of the subtasks at each time of day on the basis of resources used by each of the subtasks and available resources at each time of day; an inexpensive remaining quantity calculation step of creating an inexpensive executability table indicating an inexpensive remaining quantity that is a quantity of tasks which may be executed by the inexpensive execution unit at each time of day on the basis of a completion date and time when the arithmetic operations of the plurality of subtasks should be completed, and the simultaneous execution quantity; and an execution instruction step of causing each of the subtasks to be executed by either the inexpensive execution unit or the expensive execution unit with reference to the inexpensive executability table.

An arithmetic operation instruction system is an arithmetic operation instruction system for performing arithmetic operations of a plurality of subtasks by using an arithmetic operation system equipped with an inexpensive execution unit for which a usage fee is inexpensive, but which may possibly be forcibly stopped, and an expensive execution unit for which a usage fee is expensive, but which will never be forcibly stopped, wherein the arithmetic operation instruction system includes: a simultaneous execution quantity calculation unit that calculates a simultaneous execution quantity of the subtasks at each time of day on the basis of resources used by each of the subtasks and available resources at each time of day; an inexpensive remaining quantity calculation unit that creates an inexpensive executability table indicating an inexpensive remaining quantity that is a quantity of tasks which may be executed by the inexpensive execution unit at each time of day on the basis of a completion date and time when the arithmetic operations of the plurality of subtasks should be completed, and the simultaneous execution quantity; and an execution instruction unit that causes each of the subtasks to be executed by either the inexpensive execution unit or the expensive execution unit with reference to the inexpensive executability table.

According to the present invention, the data processing can be executed no later than the designated date and time in consideration of forced stoppage of a task(s).

<FIG> is an overall configuration diagram of a container execution management system <NUM>. The container execution management system <NUM> includes a public cloud <NUM> and an on-premises data center <NUM> and they are coupled together via a connection line <NUM>. Arithmetic operations in the public cloud <NUM> and the on-premises data center <NUM> are executed by a CPU which is a central processing unit by decompressing programs stored in a ROM which is a read-only storage device onto a RAM which is a readable/writable storage device and executing the programs. However, at least one of the arithmetic operations describe later may be implemented by an FPGA (Field Programmable Gate Array) which is a rewritable logical circuit, or an ASIC (Application Specific Integrated Circuit) which is an application specific integrated circuit, instead of a combination of the CPU, the ROM, and the RAM. Furthermore, these arithmetic operations may be implemented by a different combination of configurations, for example, a combination of the CPU, the ROM, the RAM, and the FPGA instead of the combination of the CPU, the ROM, and the RAM.

The public cloud <NUM> includes one or a plurality of data centers and has enormous arithmetic operation resources. The public cloud <NUM> is used by an unspecified large number of companies and organizations and they pay a usage fee to an administrator (hereinafter referred to as a "service provider") of the public cloud <NUM> according to the usage.

The on-premises data center <NUM> is a data center retained by a company which owns an IT system. Arithmetic operation resources of the on-premises data center <NUM> are more limited than those of the public cloud <NUM>. The on-premises data center <NUM> may be a data center of a data center business entity which provides a collocation service. A user of the on-premises data center <NUM> (hereinafter referred to as an "operator") cannot take data outside due to, for example, safety reasons. In this embodiment, arithmetic processing which uses the arithmetic operation resources of the public cloud <NUM> while keeping the data at the on-premises data center <NUM> (hereinafter referred to as a "task").

Moreover, in this embodiment, a part(s) obtained by segmentalizing a task is called a "subtask(s). " Processing loads of subtasks are substantially the dame and every one of the subtasks requires substantially the same processing time. There is no dependency relation between the subtasks and their sequential execution order is arbitrary; and there is no problem even if a starting sequential order is different from a terminating sequential order.

The public cloud <NUM> includes an inexpensive execution unit <NUM>, containers <NUM>, an expensive execution unit <NUM>, a DB server <NUM>, a task management unit <NUM>, a scale control unit <NUM>, and a public monitoring unit <NUM>. Each of the inexpensive execution unit <NUM>, the expensive execution unit <NUM>, the DB server <NUM>, the task management unit <NUM>, the scale control unit <NUM>, and the public monitoring unit <NUM> may be implemented by an independent arithmetic operation apparatus, one or a plurality of them may be implemented by the same arithmetic operation apparatus, or one configuration may be implemented by a plurality of arithmetic operation apparatuses. The container <NUM> is electronic data including a program which the operator wishes to execute processing, and is executed by the inexpensive execution unit <NUM> or the expensive execution unit <NUM>. In the following explanation, the inexpensive execution unit <NUM> and the expensive execution unit <NUM> will be hereinafter also collectively referred to as an "arithmetic operation system" and the task management unit <NUM> will be also referred to as an "arithmetic operation instruction system.

Some configurations of the public cloud <NUM> manage information. For example, the scale control unit <NUM> manages DB information <NUM>. Management of information in this embodiment means to perform at least either reading or writing of the information. Areas in which these pieces of the information are stored are not particularly limited; however, such areas are illustrated as inside the configuration for managing the information in <FIG> for the sake of convenience.

The inexpensive execution unit <NUM> is a service for causing a container(s) <NUM> to operate. The inexpensive execution unit <NUM> may sometimes forcibly stop a container which is being executed for the service provider's convenience, but its usage fee is inexpensive. The inexpensive execution unit <NUM> has a low quality of service quality assurance (SLA: Service Level Agreement), so that it can be also called a low SLA. The expensive execution unit <NUM> is a service for causing a container(s) <NUM> to operate. The expensive execution unit <NUM> will never forcibly stop a container which is being executed, but its usage fee is expensive. The expensive execution unit <NUM> has a high quality of service quality assurance, so that it can be also called a high SLA.

The differences between the inexpensive execution unit <NUM> and the expensive execution unit <NUM> are the usage fee and whether the forced stoppage is possible or not and there is no difference in their performance. Specifically speaking, when the inexpensive execution unit <NUM> is used to execute a subtask and the subtask is not forcibly stopped, and when the expensive execution unit <NUM> is used to execute the same subtask, the time required to complete the execution is the same in both the above-described cases. Incidentally, in the following explanation, a subtask executed by using the inexpensive execution unit <NUM> will be hereinafter sometimes referred to as an "inexpensive subtask" for the sake of convenience and a subtask executed by using the expensive execution unit <NUM> will be hereinafter sometimes referred to as an "expensive subtask" for the sake of convenience.

The inexpensive execution unit <NUM> and the expensive execution unit <NUM> respectively exist in plurality and each of them executes subtasks obtained by segmentalizing a task. Incidentally, each of the inexpensive execution unit <NUM> and the expensive execution unit <NUM> may be provided as a service for executing arithmetic operations and a cluster(s) for executing the arithmetic operations may be provided. The DB server <NUM> is a database which accumulates data of the container(s) <NUM>. As the processing of the container(s) <NUM> increases, the load on the DB server <NUM> increases.

The task management unit <NUM>: judges whether a container <NUM> should be executed by the inexpensive execution unit <NUM> or the expensive execution unit <NUM>; and issues an instruction to execute the container <NUM>. Information managed by the task management unit <NUM> will be explained later. The scale control unit <NUM> increases/decrease necessary resources for the DB server <NUM>. The public monitoring unit <NUM> monitors operations of the public cloud <NUM>, specially speaking, operation information of the DB server <NUM> and the connection line <NUM>. The public monitoring unit <NUM> manages DB operation information <NUM> and connection line operation information <NUM>. The scale control unit <NUM> manages DB information <NUM> which is information about the DB server <NUM>. The DB information <NUM> will be explained later.

The on-premises data center <NUM> includes a shared storage <NUM>, a resource allocation control unit <NUM>, and a private monitoring unit <NUM>. Each of the shared storage <NUM>, the resource allocation control unit <NUM>, and the private monitoring unit <NUM> may be implemented by an independent arithmetic operation apparatus, one or a plurality of them may be implemented by the same arithmetic operation apparatus, or one configuration may be implemented by a plurality of arithmetic operation apparatuses. Furthermore, other programs which are not illustrated in the drawing also operate in the on-premises data center <NUM> and share arithmetic operation resources. In other words, the arithmetic operation resources are limited in the on-premises data center <NUM>.

The shared storage <NUM> includes a port <NUM>, a CPU <NUM>, and a drive <NUM>. Strictly speaking, the shared storage <NUM> is implemented by using the port <NUM>, the CPU <NUM>, and the drive <NUM> which are resources for the on-premises data center <NUM>. The shared storage <NUM> stores data used for the arithmetic operation(s) by the container(s) <NUM>, provides the data in response to requests from the container(s) <NUM> of the public cloud <NUM>, and stores the received data. The port <NUM> is a port which is coupled to the connection line <NUM> and transmits and receives the data. The CPU <NUM> is a CPU for processing a data read/write command(s) received from the DB server <NUM>. The drive <NUM> is a drive which accumulates the data.

Specifically speaking, the shared storage <NUM> is not merely a storage medium, but increases resources for realizing high-speed data reading/writing as necessary. However, since other programs are also operating as described earlier, it is desired that a minimum necessary amount of the port <NUM>, the CPU <NUM>, and the drive <NUM> which are used by the shared storage <NUM> should be provided.

The resource allocation control unit <NUM> controls an allocated amount of the port <NUM>, the CPU <NUM>, and the drive <NUM> to the shared storage <NUM>. The resource allocation control unit <NUM> manages storage information <NUM>. The private monitoring unit <NUM> monitors the on-premises data center <NUM>; and specifically speaking, the private monitoring unit <NUM> manages operation information of the shared storage <NUM> and the connection line <NUM>. The private monitoring unit <NUM> manages storage resource operation information <NUM>.

<FIG> is a diagram illustrating information managed by the task management unit <NUM>. The task management unit <NUM> manages task information <NUM>, subtask information <NUM>, task usage resource information <NUM>, container execution environment information <NUM>, maximum parallelism degree information <NUM>, and an inexpensive executability table <NUM>. These pieces of information will be explained with reference to <FIG>.

<FIG> is a diagram illustrating an example of the task information <NUM>. The task information <NUM> stores information about tasks. The task information <NUM> is configured of a plurality of records; and each record includes a task ID <NUM>, a starting date and time <NUM>, a completion date and time <NUM>, a container image <NUM>, an environment variable name <NUM>, an environment variable value <NUM>, the number of vCPUs <NUM>, and a memory capacity <NUM>.

The task ID <NUM> is an identifier for identifying the relevant task. The starting date and time <NUM> indicate a date and time to start the task. The completion date and time <NUM> indicate a date and time when the task should be completed. The container image <NUM> indicates a registration location, that is, a storage location of a container image for executing the task.

The environment variable name <NUM> indicates the name of an argument given to the container. The environment variable value <NUM> indicates a list of parameters for the subtask. In the example illustrated in <FIG>, the environment variable value <NUM> displays parameters separated with a comma and subtasks as many as the number of elements are created. The number of vCPUs <NUM> indicates the number of vCPUs to be allocated to the container. The memory capacity <NUM> indicates a memory capacity to be allocated to the container. The operator registers the relevant task to the task management unit <NUM> by updating the task information <NUM>.

<FIG> is a diagram illustrating an example of the subtask information <NUM>. The subtask information <NUM> stores information about subtasks constituting a task. Once a task is registered in the task information <NUM> by the operator, the task management unit <NUM> updates the subtask information <NUM> based on the information registered in the task information. The subtask information <NUM> is configured of a plurality of records; and each record includes a task ID <NUM>, a subtask ID <NUM>, an environment variable name <NUM>, an environment variable value <NUM>, a status <NUM>, and a container ID <NUM>.

The task ID <NUM> is an identifier for identifying the relevant task and is information of the same type as the task ID <NUM> in <FIG>. The subtask ID <NUM> indicates an identifier of the relevant subtask. The environment variable name <NUM> and the environment variable value <NUM> indicate an argument to be given to a container executed in the subtask. The status <NUM> indicates the status of the subtask. The container ID <NUM> is an identifier of a container used when the status <NUM> is "being executed. " The task management unit <NUM> updates the status <NUM> of the relevant subtask when the status of the subtask is converted.

<FIG> is a diagram illustrating an example of the task usage resource information <NUM>. The task usage resource information <NUM> stores information of resources used by the relevant task. The task usage resource information <NUM> is updated by the operator. The task usage resource information <NUM> is configured of a plurality of records; and each record includes a task ID <NUM>, a DB ID <NUM>, a storage ID <NUM>, and a storage resource ID <NUM>.

The task ID <NUM> is an identifier for identifying the relevant task and is information of the same type as the task ID <NUM> in <FIG>. The DB ID <NUM> indicates an identifier of a database used by the container, which is executed in the task, to store data. The storage ID <NUM> is an identifier of a storage unit which stores the data of the database. The storage resource ID <NUM> indicates an identifier of a resource for the storage unit used to store the data of the database. The resource ID is, for example, the ID of the port <NUM>, the CPU <NUM>, or the drive <NUM>.

<FIG> is a diagram illustrating an example of the container execution environment information <NUM>. The container execution environment information <NUM> stores information about the environment to execute the relevant container. The container execution environment information <NUM> is configured of a plurality of records; and each record includes a container ID <NUM>, a type <NUM>, and a container execution environment name <NUM>.

The container ID <NUM> indicates an identifier of the relevant container execution environment and is information of the same type as the container ID <NUM> in <FIG>. The type <NUM> indicates which one of the inexpensive execution unit <NUM> and the expensive execution unit <NUM> the container execution environment is. However, referring to <FIG>, the inexpensive execution unit <NUM> is described as "inexpensive" and the expensive execution unit <NUM> is described as "expensive. " The container execution environment name <NUM> indicates the name of the environment where the container is to be executed.

<FIG> is a diagram illustrating an example of the maximum parallelism degree information <NUM>. The maximum parallelism degree information <NUM> stores a maximum parallelism degree, that is, information about the number of subtasks which can be executed simultaneously with respect to each task and at each time of day. The maximum parallelism degree information <NUM> is created by the task management unit <NUM>. The maximum parallelism degree information <NUM> is configured of a plurality of records; and each record includes a task ID <NUM>, a date and time <NUM>, and a maximum parallelism degree <NUM>. The task ID <NUM> is an identifier for identifying the relevant task and is information of the same type as the task ID <NUM> in <FIG>. The first record in <FIG> shows that regarding "task <NUM>," the maximum of "<NUM>" subtasks can be executed simultaneously at "<NUM> o'clock on December <NUM>, <NUM>.

<FIG> is a diagram illustrating an example of the inexpensive executability table <NUM>. The inexpensive executability table <NUM> is updated by the task management unit <NUM>. The inexpensive executability table <NUM> stores conditions under which the inexpensive execution unit <NUM> can be used, with respect to each task and at each time of day. The inexpensive executability table <NUM> is configured of a plurality of records; and each record includes a task ID <NUM>, an inexpensive remaining quantity <NUM>, and a date and time <NUM>. The task ID <NUM> is an identifier for identifying the relevant task and is information of the same type as the task ID <NUM> in <FIG>. The inexpensive remaining quantity <NUM> is the number of subtasks which can use the inexpensive execution unit <NUM> at and after the relevant time of day. In other words, if any uncompleted task(s) exists/exist as many as or more than the number indicated at the relevant time of day, the expensive execution unit <NUM> will be used.

The first record in <FIG> shows that "task <NUM>" cannot use the inexpensive execution unit <NUM> at and after "<NUM>:<NUM> on December <NUM>, <NUM>. " The second record in <FIG> shows that regarding "task <NUM>," the number of subtasks which can use the inexpensive execution unit <NUM> at and after "<NUM>:<NUM> on December <NUM>, <NUM>" is "<NUM>. " Specifically speaking, by integrating the first to third records indicated in <FIG>, it is shown that regarding "task <NUM>" on "December <NUM>, <NUM>," "<NUM>" subtasks can use the inexpensive execution unit <NUM> from <NUM> o'clock to <NUM> o'clock, "<NUM>" subtasks can use the inexpensive execution unit <NUM> from <NUM> o'clock to <NUM> o'clock, and the inexpensive execution unit <NUM> cannot be used and all the subtasks use the expensive execution unit <NUM> after <NUM> o'clock.

For example, if there is no subtask which is being executed and "<NUM>" subtasks remain at "<NUM> o'clock on December <NUM>, <NUM>", the following processing will be executed. Specifically speaking, "<NUM>" subtasks will be executed by the inexpensive execution unit <NUM> and the remaining "<NUM>" subtask will be executed by the expensive execution unit <NUM>.

<FIG> is a diagram illustrating an example of the DB information <NUM> managed by the scale control unit <NUM>. The DB information <NUM> stores information of the relevant database which operates on the DB server <NUM>. The DB information <NUM> is configured of a plurality of records; and each record includes a DB ID <NUM>, a connection destination <NUM>, and the number of vCPUs <NUM>. The DB ID <NUM> indicates an identifier of the relevant database and is information of the same type as the DB ID <NUM> in <FIG>. The connection destination <NUM> indicates information of a connection destination for connecting to the database. The number of vCPUs <NUM> indicates the number of virtual CPUs used by the database.

<FIG> is a diagram illustrating an example of the DB operation information <NUM> managed by the public monitoring unit <NUM>. The DB operation information <NUM> stores information of an operation status of the database which operates in the DB server <NUM>. The public monitoring unit <NUM> adds a new record to the DB operation information <NUM>, for example, every time a specified amount of time has elapsed. The DB operation information <NUM> is configured of a plurality of records; and each record includes a DB ID <NUM>, a date and time <NUM>, and an average CPU utilization rate <NUM>. The first record in <FIG> shows that the average CPU utilization rate of "DB0" was "<NUM>%" at "<NUM>:<NUM> on December <NUM>, <NUM>.

<FIG> is a diagram illustrating an example of the connection line operation information <NUM> managed by the public monitoring unit <NUM>. The connection line operation information <NUM> indicates an operation status of the connection line <NUM>. For example, every time a specified time period has elapsed, the public monitoring unit <NUM> adds a new record to the connection line operation information <NUM>. The connection line operation information <NUM> is configured of a plurality of records; and each record includes a connection line ID <NUM>, a date and time <NUM>, a transmitted amount <NUM>, and a received amount <NUM>. The transmitted amount <NUM> and the received amount <NUM> may be a specific communication speed or a ratio relative to a maximum value. The first record in <FIG> shows that regarding communication of "line <NUM>" at "<NUM>:<NUM> on December <NUM>, <NUM>," the transmitted amount was "<NUM>%" and the received amount was "<NUM>%.

<FIG> is a diagram illustrating an example of the storage information <NUM> managed by the resource allocation control unit <NUM>. The storage information <NUM> indicates information of the shared storage <NUM> which stores data retained by a database operating in the DB server <NUM>. The storage information <NUM> is configured of a plurality of records; and each record includes a storage ID <NUM> and a connection destination <NUM>. The storage ID <NUM> is an identifier of a storage unit which stores the data of the database and is information of the same type as the storage ID <NUM>.

<FIG> is a diagram illustrating an example of storage resource operation information <NUM> managed by the resource allocation control unit <NUM>. The storage resource operation information <NUM> indicates chronological operation rates of the storage resources. The storage resource operation information <NUM> is configured of a plurality of records; and each record includes a storage ID <NUM>, a resource ID <NUM>, a date and time <NUM>, and an operation rate <NUM>. The storage ID <NUM> is an identifier of a storage unit which stores data of a database, and is information of the same type of the storage ID <NUM>. The resource ID <NUM> is an identifier of the relevant storage resource and is information of the same type as the storage resource ID <NUM>. The operation rate <NUM> is information indicating an operation status of the resource and indicates, for example, a current load rate relative to the maximum load.

<FIG> is a diagram for explaining a method for deciding a container execution service. The operator defines processing which they want to execute, as a task. The task designates a container image to be executed. The task is configured of one or more subtasks. There is no dependency relation between subtasks and their sequential execution order is arbitrary as explained earlier. Furthermore, there would be no problem even if the sequential order of executing the subtasks were different from the sequential order of terminating them. An argument to be delivered to the container is defined in a subtask. The subtask is processed by executing the container together with the argument.

Regarding a graph <NUM>, its horizontal axis represents the passage of time; and specifically speaking, time passes from the left to the right of the graph <NUM>. Also, a long-dashed short-dashed line <NUM> indicated on the right side of the graph <NUM> indicates the completion date and time <NUM> which is the time of day when the entire task should be terminated. The vertical axis of the graph <NUM> represents subtask types; and specifically speaking, subtask <NUM> to subtask <NUM> are indicated in the sequential order downwards from the top of the graph <NUM>. Moreover, values of the maximum parallelism degree <NUM> of the maximum parallelism degree information <NUM> are indicated at the bottom of the graph <NUM>. An average subtask execution time <NUM> indicates an average value of the execution time of the subtasks in the past.

A stepped-shape reference numeral <NUM> indicated with a bold line in <FIG> is a subtask completion deadline <NUM> and indicates the respective subtask completion deadlines to complete the subtasks <NUM> to <NUM> in the sequential order. The subtask completion deadline <NUM> is calculated from the average subtask execution time <NUM> and the maximum parallelism degree <NUM>. For example, since the remaining amount of the subtasks needs to become zero at the time of day indicated as the reference numeral <NUM>, only the same number of subtasks as the maximum parallelism degree for the relevant time slot, for example, only "<NUM>" subtasks are permitted at the time of day earlier than the time of day indicated as the reference numeral <NUM> by as much as the average subtask execution time <NUM>. Then, at a time of day further earlier than that time of day by as much as the average subtask execution time <NUM>, only subtasks in the quantity which is a numerical value, for example, "<NUM>" are permitted, wherein such quantity is obtained by adding the number of the maximum parallelism degree for the relevant time slot to the above-mentioned numerical value, for example, "<NUM>.

Inexpensive unavailability <NUM> indicated with hatching in <FIG> indicates time slots when the inexpensive execution unit <NUM> cannot be used. An area indicated as the inexpensive unavailability <NUM> is calculated by using the average subtask execution time <NUM> and the subtask completion deadline <NUM>. Specifically speaking, the time of day obtained by subtracting twice the amount of time of the average subtask execution time <NUM> from the subtask completion deadline <NUM> is starting time of the inexpensive unavailability <NUM>.

A subtask surrounded with a narrow-line rectangle in <FIG> is an inexpensive subtask <NUM> executed by using the inexpensive execution unit <NUM>. A subtask surrounded with a bold-line rectangle in <FIG> is an expensive subtask <NUM> executed by using the expensive execution unit <NUM>. If the task management unit <NUM> cannot use the inexpensive service at the time point when starting to execute each subtask, it uses the expensive execution unit <NUM>. Otherwise, the task management unit <NUM> uses the inexpensive execution unit <NUM> to execute the container.

<FIG> is a flowchart illustrating task execution processing by the task management unit <NUM>. If the current time of day matches any one of the starting dates and times <NUM> of the task information <NUM>, the task management unit <NUM> starts the processing illustrated in <FIG>.

In step S201, the task management unit <NUM> performs a trial run of a subtask(s). Specifically speaking, the task management unit <NUM> firstly selects a predetermined number of a subtask(s) from subtasks registered in a started task on the basis of the subtask information <NUM>. Then, the task management unit <NUM> executes the subtask(s) with predetermined degree of parallelism with respect to a service whose type <NUM> is "inexpensive" on the basis of the container execution environment information <NUM>.

In the next step S202, the task management unit <NUM> acquires a trial run result of the subtask(s) executed in step S201. Specifically speaking, the task management unit <NUM> waits for the completion of the subtask(s) executed in step S201 and acquires the DB operation information <NUM> and the connection line operation information <NUM> from the public monitoring unit <NUM>. Furthermore, the task management unit <NUM> acquires the storage resource operation information <NUM> from the private monitoring unit <NUM>. The task management unit <NUM> records average time required to execute the subtask, compares the status before and after the execution of the subtask(s), and records each load amount on the DB server <NUM>, the connection line <NUM>, and the shared storage <NUM> with respect to one subtask.

In the subsequent step S203, the task management unit <NUM> calculates a future average CPU utilization rate from the average CPU utilization rates <NUM> in chronological order which are acquired in step S202.

In the subsequent step S204, the task management unit <NUM> calculates the maximum number of subtasks which do not reach a predetermined threshold value by adding the average CPU utilization rate per subtask, which was calculated in step S202, to the future average CPU utilization rate calculated in step S203. The task management unit <NUM> also performs calculations with respect to the transmitted amount <NUM>, the received amount <NUM>, and the operation rate <NUM> in the same manner. The task management unit <NUM> records, in the maximum parallelism degree information <NUM>, a minimum value of the quantity of subtasks among the average CPU utilization rate <NUM>, the transmitted amount <NUM>, the received amount <NUM>, and the operation rate <NUM> which have been calculated, as the maximum parallelism degree in chronological order.

Incidentally, in step S204, the task management unit <NUM> may consider the influence which, for example, other programs operating in the public cloud <NUM> or the on-premises data center <NUM> may have on the connection line <NUM>. For example, the task management unit <NUM> may calculate the maximum parallelism degree by referring to the operation status of the connection line <NUM> which was recorded in the connection line operation information <NUM> at the same time of day one day or one week before, and assuming that the transmitted amount <NUM>, the received amount <NUM>, and so on would change in the same manner on that day. The processing in this step S204 is also called a "simultaneous execution quantity calculation step.

In step S205, the task management unit <NUM> updates the inexpensive executability table <NUM> as described below and proceeds to step S206. Firstly, the task management unit <NUM> records, in the inexpensive executability table <NUM>, a time of day earlier than the completion date and time <NUM> by as much as twice the subtask execution time measured in step S202 (hereinafter referred to as a "first time of day"), and the quantity of remaining subtasks which is "<NUM>.

Next, the task management unit <NUM> records, in the inexpensive executability table <NUM>, a time of day which is further earlier than the above-mentioned time of day by as much as the subtask execution time (hereinafter referred to as a "second time of day"), and the maximum parallelism degree at the second time of day (hereinafter referred to as a "second remaining quantity"). Furthermore, the task management unit <NUM> records, in the inexpensive executability table <NUM>, a time of day earlier than the second time of day by as much as the subtask execution time (hereinafter referred to as a "third time of day"), and the sum of the second remaining quantity and the maximum parallelism degree at the third time of day (hereinafter referred to as a "third remaining quantity"). The task management unit <NUM> repeats this processing no later than the quantity of remaining subtasks becomes the quantity of subtasks described in the subtask information <NUM>. The processing in this step S205 is also called an "inexpensive remaining quantity calculation step.

In step S206, the task management unit <NUM> reads the maximum parallelism degree at the relevant time of day by referring to the maximum parallelism degree information <NUM> and subtracts the quantity of subtasks which are being executed from that value. The task management unit <NUM> decides the result of this subtraction as the quantity of subtasks which should be newly executed. Incidentally, steps S206 to S211 and particularly steps S208 to S210 are also called an "execution instruction step.

In the next step S207, if the maximum parallelism degree at the current time of day has changed as compared to that at the time of execution of a previous task, the task management unit <NUM> notifies the scale control unit <NUM> and the resource allocation control unit <NUM> of a changed amount of the load on the basis of the difference in the parallelism degree and the calculated load amount per subtask. After receiving the notice, the scale control unit <NUM> changes the number of vCPUs to be allocated to the DB server <NUM>. After receiving the notice, the resource allocation control unit <NUM> changes the resources to be allocated to the shared storage <NUM>.

In step S208, the task management unit <NUM> judges whether or not the total quantity of subtasks whose status <NUM> in the subtask information <NUM> is "being executed" and "unexecuted" is equal to or less than the inexpensive remaining quantity <NUM> at the relevant time of day in the inexpensive executability table <NUM>. If the task management unit <NUM> obtains an affirmative judgment in step S208, it proceeds to step S209; and if the task management unit <NUM> obtains a negative judgment in step S208, it proceeds to step S210.

In step S209, the task management unit <NUM>: has the inexpensive execution unit <NUM> execute all subtasks which are "unexecuted" within the limit of the number of executed subtasks; and proceeds to step S211. In step S210, the task management unit <NUM>: has the inexpensive execution unit <NUM> execute a subtask(s) in the quantity obtained by subtracting the quantity of tasks which are "being executed" from the inexpensive remaining quantity <NUM> within the limit of the number of executed subtasks; and has the expensive execution unit <NUM> execute the remaining subtask(s).

Specific examples of steps S206 and S208 to S210 will be explained. Firstly, premises will be explained. It is assumed that the maximum parallelism degree read from the maximum parallelism degree information <NUM> is "<NUM>," the quantity of subtasks which are being executed by the inexpensive execution unit <NUM> is "<NUM>," and the number of subtasks which are being executed by the expensive execution unit <NUM> is "<NUM>. " Furthermore, the following premises are set: the maximum parallelism degree at the relevant time of day is "<NUM>;" the inexpensive remaining quantity <NUM> at the relevant time of day is "<NUM>"; and the number of tasks whose status <NUM> in the subtask information <NUM> is "unexecuted" is "<NUM>.

Operations of the task management unit <NUM> in steps S206 and S208 to S210 in this case are as described below. Firstly, the task management unit <NUM> calculates the number of executed subtasks in S206 as "<NUM>" - "<NUM>" = "<NUM>. " Next, the task management unit <NUM>: obtains a negative judgment in S208 because the sum of "<NUM>" which is the number of "unexecuted" subtasks and "<NUM>" which is the number of a subtask that is "being executed" is larger than "<NUM>" which is the inexpensive remaining quantity <NUM>; and then proceeds to S210. Then, in S210, the task management unit <NUM>: has the inexpensive execution unit <NUM> execute "one" subtask whose number "<NUM>" is obtained by subtracting "<NUM>" which is the number of the subtask which is being executed, from "<NUM>" which is the inexpensive remaining quantity <NUM>; and has the expensive execution unit <NUM> execute the remaining "one" subtask. In this example, the number of executed subtasks is "<NUM>," so that the total of two subtasks can be executed in S210. The explanation will continue by referring back to <FIG>.

In step S211, the task management unit <NUM> updates the subtask information <NUM> with respect to three points described below and proceeds to step S212. The first point is that information of the subtask(s) the execution of which was started in step S209 or step S210 is reflected in the update. Specifically speaking, the task management unit <NUM> changes the status <NUM> of a target record of the relevant subtask to "being executed" and sets an identifier of a container execution environment, regarding which a trial is newly started, to the container ID <NUM>. The second point is that information of a subtask(s) which was already being executed, and the execution of which has newly been completed is reflected in the update. Specifically speaking, the task management unit <NUM> changes the status <NUM> of a target record of the relevant subtask to "completed" and deletes the container ID <NUM>. The third point is that information of a subtask(s) which was being executed by the inexpensive execution unit <NUM>, but was interrupted is reflected in the update. Specifically speaking, the task management unit <NUM> changes the status <NUM> of a target record of the relevant subtask to "unexecuted" and deletes the container ID <NUM>.

In step S212, the task management unit <NUM> judges whether or not the status <NUM> of all records of the subtask information <NUM> is "completed. " If the task management unit <NUM> determines that the status <NUM> of all the records is "completed," it terminates the processing illustrated in <FIG>; and if the status <NUM> of at least one record is not "completed," the processing returns to step S206.

According to the embodiment described above, the following operational advantages can be obtained.

The aforementioned embodiment is designed on the premise that the DB server <NUM>, the connection line <NUM>, and the shared storage <NUM> are not only used by the operator, but are shared with other users and the loads thereby change depending on the date and time. However, it may be designed on the premise that the loads on the DB server <NUM>, the connection line <NUM>, and the shared storage <NUM> by the other users do not change. Specifically speaking, the following cases may be included: a case where other users do not exist; and a case where the other users exist, but the resources of the DB server <NUM>, the connection line <NUM>, and the shared storage <NUM> which can be used by the operator are always limited to a constant value. In this case, the processing for the future load prediction as indicated in step S203 in <FIG> and the maximum parallelism degree calculation processing in step S204 are mitigated.

The aforementioned embodiment takes into consideration the load on the DB server <NUM> when calculating the maximum parallelism degree indicated in step S204 in <FIG>. However, the load on the DB server <NUM> may not be taken into consideration when calculating the maximum parallelism degree. For example, if the DB server <NUM> has sufficient resources, the calculation of the maximum parallelism degree can be simplified by not taking into consideration the load on the DB server <NUM> when calculating the maximum parallelism degree.

Claim 1:
An arithmetic operation method executed by a computer for performing arithmetic operations of a plurality of subtasks by using an arithmetic operation system equipped with an inexpensive execution unit (<NUM>) for which a usage fee is inexpensive, but which may possibly be forcibly stopped, and an expensive execution unit (<NUM>) for which a usage fee is expensive, but which will never be forcibly stopped,
the arithmetic operation method characterized by:
a simultaneous execution quantity calculation step of calculating a simultaneous execution quantity of the subtasks at each time of day on the basis of resources used by each of the subtasks and available resources at each time of day;
an inexpensive remaining quantity calculation step of creating an inexpensive executability table (<NUM>) indicating an inexpensive remaining quantity that is a quantity of tasks which may be executed by the inexpensive execution unit (<NUM>) at each time of day on the basis of a completion date and time when the arithmetic operations of the plurality of subtasks should be completed, and the simultaneous execution quantity; and
an execution instruction step of causing each of the subtasks to be executed by either the inexpensive execution unit (<NUM>) or the expensive execution unit (<NUM>) with reference to the inexpensive executability table (<NUM>).