JP6962142B2 - Programs and information processing equipment - Google Patents

Description

The present invention relates to a program and an information processing device.

In Patent Document 1, when the operating status of the job processing device is monitored, a scale-out is instructed to increase the number of tasks when processing a specified number of jobs, and then it is confirmed that the throughput is not improved. Discloses a technique for instructing scale-in to delete a task.

Japanese Unexamined Patent Publication No. 2014-149690

In the technique of Patent Document 1, in either case of scale-out or scale-in, no action is taken until after the requested process (job) has been executed.
Therefore, an object of the present invention is to take measures for early termination of the processing before the requested processing is executed.

The program according to claim 1 of the present invention includes a generator that generates functional information indicating the function when the computer receives a request for processing executed by the function started on the virtual machine, and the generated function. A temporary storage unit that temporarily stores information, a specific unit that specifies a function that is expected to execute the process based on the request for the process, and a first unit that activates the specified function on a virtual machine. A second activation unit that activates the activation unit and the function indicated by the function information read from the temporary storage unit on the virtual machine, and if the function has already been activated by the first activation unit, the relevant function is applicable. It is characterized in that it functions as a second activation unit that does not activate the function.

In the program according to claim 2 of the present invention, in the configuration according to claim 1, when the function is activated by the first activation unit or the second activation unit of the computer, the function performs the processing. It is characterized in that it functions as a virtual machine starter for starting a virtual machine having resources used for execution.

The program according to claim 3 of the present invention is a virtual machine stop unit that stops a virtual machine in which a function that does not execute the process is activated in the configuration according to claim 1 or 2. When the function is a function indicated by the function information stored in the temporary storage unit, it is characterized by functioning as a virtual machine stop unit that does not stop the function.

In the program according to claim 4 of the present invention, in the configuration according to claim 3, the function that does not execute the process in the virtual machine stop unit executes the process based on another request. The virtual machine is not stopped when it is specified by the specific unit as a function expected to be.

In the configuration according to any one of claims 1 to 4, the program according to claim 5 of the present invention is activated from the parameter of the requested process or the history of the request for the process. It is characterized in that a function that is represented to have a higher possibility of being executed than other functions is specified as a function that is expected to be executed.

In the program according to claim 6 of the present invention, in the configuration according to any one of claims 1 to 5, the first activation unit performs the function as the time required for activating the specified function is shorter. It is characterized by delaying the activation time.

The program according to claim 7 of the present invention has the configuration according to any one of claims 1 to 6, and the first activation unit is specified as the amount of functional information stored in the temporary storage unit increases. It is characterized in that the timing for activating the said function is delayed.

The program according to claim 8 of the present invention has a plurality of types of the functions in the configuration according to any one of claims 1 to 7, and the first activation unit has the same type. The smaller the number of activated functions is, the earlier the time to activate the specified function is characterized.

In the program according to claim 9 of the present invention, in the configuration according to any one of claims 1 to 8, the processes are sequentially executed by a plurality of functions, and the first activation unit is the function of the function. The earlier the order is, the earlier the time to activate the specified function is.

The program according to claim 10 of the present invention has a plurality of types of the functions in the configuration according to any one of claims 1 to 9, and the first activation unit has the specified function. The feature is that the more times the same type of function is activated, the earlier the specified function is activated.

The program according to claim 11 of the present invention calculates the time required for the computer to be executed by the function indicated by the stored functional information in the configuration according to any one of claims 1 to 10. The first activation unit functions as a calculation unit, and the longer the time calculated for the function information accumulated before the function information indicating the specified function, the longer the function is performed on the virtual machine. It is characterized by delaying the activation time.

In the configuration according to any one of claims 6 to 11, the program according to claim 12 of the present invention causes the computer to function as a function stop unit for stopping the function for which the process has been completed. 1 When the function on the virtual machine is stopped after completing the process, the activation unit starts the specified function on the virtual machine and does not control the function to change the timing. It is characterized by that.

The program according to claim 13 of the present invention has a plurality of types of the functions in the configuration according to any one of claims 1 to 12, and the first activation unit has the specified function. When the same type of function exists in a state where the process is not executed, the specified function is not activated, and the computer is used, and the first activation unit does not activate the function. It is characterized in that it functions as an execution control unit that controls a function existing in the state and executes the requested process.

The information processing device according to claim 14 of the present invention includes a generation unit that generates functional information indicating the function when receiving a request for processing executed by a function started on the virtual machine, and the generated functional information. A temporary storage unit that temporarily stores A second activation unit that activates a unit and a function indicated by the function information read from the temporary storage unit on a virtual machine, and if the function has already been activated by the first activation unit, the function is activated. It is characterized by including a second activation unit that does not activate.

According to the inventions of claims 1 and 14, measures can be taken for early termination of the processing before the requested processing is executed.
According to the second aspect of the present invention, the amount of resources required when starting a virtual machine can be reduced as compared with the case where a virtual machine having resources required for a plurality of functions is started in advance.
According to the third aspect of the present invention, it is possible to accelerate the start of a process different from the process that the function was expected to execute, as compared with the case where the function activated by the first activation unit is stopped. can.
According to the invention of claim 4, the start of the process based on a request different from the request is accelerated as compared with the case where the function activated due to the expected execution of the requested process is stopped. can do.
According to the invention of claim 5, it is possible to specify the function without the information defining the function.
According to the invention of claim 6, the time when the activated function can execute the process can be approached as compared with the case where the activation time is made uniform.
According to the inventions of claims 7 and 11, it is possible to shorten the period during which the virtual machine is started even though the function is not executing the process, as compared with the case where the start time is uniform. ..
According to the invention of claim 8, it is possible to reduce the delay in processing even if the number of activated functions of the same type is small, as compared with the case where the activation timing is uniform.
According to the inventions of claims 9 and 10, the influence of the delay in the processing due to the specified function on the subsequent processing can be reduced as compared with the case where the activation timing is made uniform.
According to the invention of claim 12, the possibility of early termination of the process can be increased as compared with the case where the activation time of the specified function is delayed.
According to the invention of claim 13, the possibility of early termination of processing can be increased as compared with the case where the virtual machine and the function are not reused.

Diagram showing the overall configuration of the task service providing system according to the embodiment Diagram showing the hardware configuration of the server device Diagram showing the functional configuration realized by the cloud system 4 The figure which shows an example of the information which the task definition part 102 stores. Diagram showing an example of TISC definition information Diagram showing an example of request parameter information Diagram showing an example of historical information The figure which shows an example of the operation procedure of the cloud system 4 in task processing The figure which shows an example of the operation procedure of the cloud system 4 in scale-in processing Diagram showing an example of startup time table Diagram showing another example of the startup time table Diagram showing another example of the startup time table Diagram showing another example of the startup time table Diagram showing another example of the startup time table Diagram showing another example of the startup time table

[1] Example FIG. 1 shows the overall configuration of the task service providing system 1 according to the embodiment. The task service providing system 1 is a system for providing a task service to a user. In the task service providing system 1, a task completed by executing a series of predefined processes is called a task. For example, the work of reading receipts and receipts and storing them in the expense reimbursement system is called an expense reimbursement task.

A service that executes a task based on a request from a user is called a task service. In addition, executing a task means executing the processing included in the task in detail, that is, executing a series of processing defined to complete the task, and requesting the execution of the task means that the task is executed. It means requesting the included processing (synonymous with requesting the execution of the processing).

The task service providing system 1 includes a communication line 2, a user terminal 3, and a cloud system 4. The communication line 2 includes, for example, the Internet, a mobile communication network, a telephone line, and the like, and mediates communication between devices connected to the own line. The user terminal 3 and the cloud system 4 are connected to the communication line 2.

The user terminal 3 is a terminal used by a user who uses the task service providing system 1. The user terminal 3 is, for example, an image forming apparatus installed in a store, and has a copy function, a scan function, and the like. Although only one user terminal 3 is shown in FIG. 1, it is assumed that a plurality of user terminals 3 are used. The user terminal 3 requests the cloud system 4 to execute a task (specifically, execution of a process included in the task) by a user operation, receives the execution result of the requested task, and responds to, for example, the execution result. Display the screen.

The cloud system 4 includes a plurality of server devices 10 each of which realizes a virtual machine called an instance. The cloud service provider that provides the cloud system 4 is different from the task service provider that provides the task service. In the cloud system 4, each instance is charged according to the amount of resources used by the instance and the usage time.

Therefore, in the cloud system 4, auto-scaling is performed to increase or decrease the number of instances as needed. In this embodiment, the processes included in the task are executed on the instances, and the instances are autoscaled. For example, you can reduce the charge by stopping (scale-in) an instance that is not executing processing, or use the resources (CPU (Central Processing Unit), memory, etc.) of the instance that is executing processing. When exceeds the threshold, a new instance is started (scaled out) to suppress the processing delay.

FIG. 2 shows the hardware configuration of the server device 10. The server device 10 is a computer including a CPU 11, a RAM (Random Access Memory) 12, a ROM (Read Only Memory) 13, a communication unit 14, and a storage 15. The CPU 11 controls the operation of each part by executing a program stored in the ROM 13 or the storage 15 using the RAM 12 which is a memory as a work area. The communication unit 14 has a communication circuit or the like, and communicates with an external device via the communication line 2. The storage 15 is a storage means such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), and a flash memory, and stores data and programs used by the CPU 11 for control.

The functions described below are realized by each CPU 11 of the plurality of server devices 10 included in the cloud system 4 executing a program to control each unit.
FIG. 3 shows a functional configuration realized by the cloud system 4. The cloud system 4 includes a task service unit 101, a task definition unit 102, a queue 103, a plug-in management unit 104, a plug-in execution unit 105, a task request information management unit 111, and a task definition information storage unit 112. A request parameter information storage unit 113, a history information storage unit 114, and an autoscale management unit 115 are provided.

The user terminal 3 is operated by the user to generate request data requesting execution of a task and transmit it to the cloud system 4. The request data is a task definition ID (Identification) that identifies the task definition used in the task to be executed, the document if it is a task for processing a document (for example, image data obtained by scanning a manuscript), and the task to be executed. It is data which shows the content of processing (parameters used in processing, etc.).

First, the functional configuration related to the execution of the requested task will be described. The task service unit 101 receives the request data transmitted from the user terminal 3, reads necessary information from the task definition unit 102 based on the request data, and generates a message for executing the requested task. ..

In this embodiment, a function called a plug-in is used to execute the task. The plug-in is started by reading a program, data, parameters, etc. and expanding it on the memory, and when the start is completed, the process becomes ready to be executed. In the task service providing system 1, a plug-in corresponding to each process included in the task (processing such as rectangular image extraction, document division, and OCR (Optical Character Recognition)) is prepared. That is, one plug-in executes one corresponding process.

The message includes a command to call each plug-in as information for starting each plug-in that executes each process included in the task. The task definition unit 102 associates the task definition ID of each task with the plug-in ID of each plug-in that executes each process included in the task, the call command of those plug-ins, and the execution of each plug-in. It remembers the order of processing to be performed.

FIG. 4 shows an example of the information stored in the task definition unit 102. In the example of FIG. 4, the task definition unit 102 has a task definition ID of "TASK01" and a plug-in ID of "PLUG13" (expense settlement data transmission), "PLUG01" (rectangular image extraction), and "PLUG08" (document division). , And their calling commands, and the order of their processing. Further, the task definition ID "TASK02" is associated with the plug-in IDs "PLUG02" (OCR) and "PLUG11" (conversion), their calling commands, and the order of their processing.

The task service unit 101 reads the calling commands in the order of the processing order associated with the task definition ID indicated by the above request data, and generates a message including the calling commands and the processing contents indicated by the request data. do. For example, if the request data indicates a task definition ID of "TASK01", the task service unit 101 is a call command of "PLUG01" (rectangular image extraction) in which the processing order associated with "TASK01" is "1". Generate a message containing.

In this way, when the task service unit 101 receives the request for the process executed by the plug-in (request for executing the process) from the user terminal 3, the task service unit 101 generates a message indicating the plug-in. The message generated in this way is information indicating a function called a plug-in called by a calling command, and is an example of "functional information" of the present invention. Further, the task service unit 101 that generates the message is an example of the "generation unit" of the present invention. The task service unit 101 supplies the generated message to the queue 103.

The queue 103 stores the supplied message and handles it as a queue (first-in first-out data). That is, the queue 103 is a function for temporarily storing messages generated by the task service unit 101, and is an example of the "temporary storage unit" of the present invention. The plug-in management unit 104 reads the message stored in the queue 103, and instructs the plug-in execution unit 105 to start the plug-in by using the call command included in the message.

Upon receiving this instruction, the plug-in execution unit 105 activates the instructed plug-in except in a specific case (details will be described later). Specifically, the plug-in execution unit 105 first starts an instance (virtual machine) for starting the plug-in, and then starts the plug-in instructed on the started instance. The plug-in management unit 104 and the plug-in execution unit 105 function as an example of the "virtual machine startup unit" of the present invention when starting an instance, and the "second startup unit" of the present invention when starting a plug-in. It functions as an example.

In this embodiment, when the plug-in execution unit 105 starts a plug-in on an instance, it prevents other plug-ins from starting on the instance. That is, the plug-in execution unit 105 executes only one plug-in on one instance. In the example of FIG. 3, the plug-in execution unit 105 corresponds to the document processing plug-ins 51-1, 51-2, 53-1, the external connection plug-in 52, and the storage registration plug-in 53, respectively. It is running on the launched instance.

The document processing plug-in performs processing on documents such as rectangular image extraction, OCR, document division and conversion. The external connection plug-in connects to an external service such as the business-type cloud service 5. The storage registration plug-in registers data in an external storage such as the storage type cloud service 6 and the in-house system 7.

When the plug-in is started, the plug-in management unit 104 instructs the plug-in execution unit 105 to execute the process according to the contents included in the message. Upon receiving this instruction, the plug-in execution unit 105 executes the process according to the instructed content. When the plug-in execution unit 105 completes this process, the plug-in execution unit 105 notifies the plug-in management unit 104 of the process result. The plug-in management unit 104 notifies the task service unit 101 of the notified processing result.

Upon receiving the notification of the completion of processing, the task service unit 101 reads the calling command of the plug-in whose processing order is next, and generates a message including the calling command and the processing content indicated by the request data. In this way, the plug-ins are started in order and the processing is executed, so that the task is executed.

Next, the functional configuration related to autoscale will be described. As described above, in the cloud system 4, the instance is autoscaled, and only one plug-in is executed on one instance. That is, when an instance is autoscaled, the plugins launched on that instance are also autoscaled (if the instance is scaled out and incremented, the plugins are scaled out by the same number and the instance is scaled in). If it is reduced, the number of plugins will be reduced by the same amount).

The autoscale management unit 115 repeatedly monitors the plug-in execution unit 105 at predetermined time intervals to grasp the execution status of the plug-in. The autoscale management unit 115 grasps, for example, whether or not there is a process being executed by the plug-in and the resource usage rate by the plug-in when the process is being executed. The autoscale management unit 115 gives the plug-in execution unit 105 a scale-out instruction for newly starting the plug-in and a scale-in instruction for stopping the plug-in according to the grasped execution status.

For example, when a plurality of OCR plug-ins are started and there is a plug-in that has not executed processing for a certain period of time (this is referred to as "non-processing plug-in"), the autoscale management unit 115 indicates the OCR. Instructs the plug-in execution unit 105 to stop (scale in) the plug-in and the corresponding instance of. Further, the autoscale management unit 115 newly starts (scales out) the conversion plug-in and the instance when, for example, the conversion plug-in is converting a large amount of documents and the resource usage rate exceeds the threshold value. ) Is instructed to the plug-in execution unit 105. In this case, the plug-in execution unit 105 instructs the newly started plug-in to share the document and execute the process, and distributes the load of the process.

Further, the autoscale management unit 115 performs autoscale based on information different from the execution status of the plug-in. Upon receiving the request data, the task service unit 101 supplies the request data to the task request information management unit 111 in parallel with the generation of the message or before the message is generated.

The task request information management unit 111 manages information regarding a task execution request indicated by the supplied request data, that is, a processing request included in the task. The task request information management unit 111 stores, for example, the supplied request data in the history information storage unit 114 together with the current date and time information as a history of task execution requests.

Further, when the request data is supplied, the task request information management unit 111 is a plug-in that is expected to execute the process based on the request of the process indicated by the request data (hereinafter referred to as "probable plug-in"). To identify. The task request information management unit 111 is an example of the "specific unit" of the present invention. The task request information management unit 111 identifies the plug-in by using, for example, a first identification method based on the information stored in the task definition information storage unit 112.

The task definition information storage unit 112 stores a part of the information related to the task definition stored in the task definition unit 102 as the task definition information.
FIG. 5 shows an example of TISC definition information. In the example of FIG. 5, the task definition information storage unit 112 stores the information associated with the task definition ID and the plug-in ID as the task definition information.

The task request information management unit 111 reads the plug-in ID associated with the task definition ID indicated by the supplied request data in the task definition information, and identifies the plug-in indicated by the read plug-in ID as a prospective plug-in. do. For example, if the task definition ID indicated by the request data is "TASK02", the task request information management unit 111 has the OCR and conversion plugs indicated by "PLUG02" and "PLUG11" associated with "TASK02" in FIG. Identify the inn as a prospective plugin.

In addition, the task request information management unit 111 identifies the plug-in by using a second identification method based on the information stored in the request parameter information storage unit 113. The request parameter information storage unit 113 stores information in which the parameters used for the processing request and the plug-in ID are associated with each other as request parameter information.

FIG. 6 shows an example of request parameter information. In the example of FIG. 6A, the request parameter information storage unit 113 stores information in which a parameter indicating the media type "MIMETYPE" and the plug-in ID are associated with each other as request parameter information. For example, "application / mspowerpoint" and "application / msword" are associated with "PLUG11" (conversion), and "application / vnd.fujixerox.docuworks" is associated with "PLUG02" (OCR).

The task request information management unit 111 reads the plug-in ID associated with the processing parameters indicated by the supplied request data in the request parameter information, and identifies the plug-in indicated by the read plug-in ID as a prospective plug-in. do. For example, if the MIMETYPE indicated by the request data is "application / msword", the task request information management unit 111 uses the conversion plug-in indicated by "PLUG 11" associated with it in FIG. 6A as a prospective plug-in. Identify.

Further, the task request information management unit 111 identifies the plug-in by using a third identification method based on the information stored in the history information storage unit 114. The history information storage unit 114 stores information in which the history of the requested processing and the plug-in ID are associated with each other as history information.
FIG. 7 shows an example of history information. In the example of FIG. 7, the history information storage unit 114 sets the plug-in ID of the processing requested in the past in the request time zone (for example, morning, noon, evening, night time zone) including the date and time when the request is transmitted. ), A terminal ID (requesting terminal ID) that identifies the user terminal 3 that has transmitted the request, and a user ID (requesting user ID) that identifies the user who performed the operation of the request. The information is stored as history information.

The request terminal ID and the request user ID are IDs registered in the task service providing system 1, and when a user inputs his / her own user ID into the user terminal 3 when using the task service, the user terminal 3 causes the user ID. And the terminal ID of the own terminal are added to the request data. The task request information management unit 111 reads out, if there is a plug-in ID associated with the terminal ID and user ID indicated by the supplied request data, and the time zone including the supplied time in the history information. The plug-in indicated by the read plug-in ID is specified as a prospective plug-in.

When the task request information management unit 111 reads out a plurality of plug-in IDs, the task request information management unit 111 identifies, for example, the plug-in indicated by the one associated with the largest number of histories as a prospective plug-in. If the task request information management unit 111 does not have a plug-in ID associated with all three types of history, the task request information management unit 111 reads out the plug-in ID associated with the two types of history and has three types of history. Identify potential plugins as in the case. Alternatively, the prospective plug-in may be specified by reading the plug-in ID associated with one type of history.

The task request information management unit 111 is activated by the task definition ID, parameters, or request history of the process requested from the user terminal 3 by using any of the first, second, and third specific methods described above. Identify plugins that are more likely to be available than other plugins as potential plugins. When the first specific method is used, the task definition information that has the same association as the task definition stored in the task definition unit 102 is used, so that the specified prospect plug-in always executes the requested process. Will be done.

On the other hand, since the prospective plug-in is a plug-in that is expected to execute the requested processing, for example, the prospective plug-in specified by the second and third specific methods may execute the requested processing. Although expensive, the prospective plugin may not be the plugin that performs the requested processing. However, when the task definition information is not available, the prospective plug-in can be specified by the second and third identification methods. The task request information management unit 111 supplies the plug-in ID of the prospective plug-in thus identified to the autoscale management unit 115.

The autoscale management unit 115 instructs the plug-in execution unit 105 to start the instance having the resources used by the specified prospective plug-in to execute the process, and the prospective plug-in is installed on the instance started by the instruction. Is instructed to start the plug-in execution unit 105. The plug-in execution unit 105 starts the instance and the prospective plug-in based on these instructions.

The autoscale management unit 115 and the plug-in execution unit 105 function as an example of the "virtual machine startup unit" of the present invention when starting an instance, and the "first startup unit" of the present invention when starting a plug-in. It functions as an example. By starting an instance that has the necessary resources for each time the plug-in is started in this way, for example, when the instance is started, compared to the case where the instance that has the necessary resources for multiple plug-ins is started in advance. Less resources are needed.

The method in which the task request information management unit 111 identifies the prospective plug-in and the autoscale management unit 115 and the plug-in execution unit 105 activate the prospective plug-in is referred to as a first activation method. On the other hand, the task service unit 101 generates a message, the queue 103 accumulates the message, the plug-in management unit 104 reads the message, instructs the plug-in to start, and the plug-in execution unit 105 instructs the plug-in to start. The method of starting is called the second starting method.

Further, the autoscale management unit 115 and the plug-in execution unit 105 that activate the plug-in (probable plug-in) by the first activation method are referred to as "first activation unit 55", and the plug-in is activated by the second activation method. The plug-in management unit 104 and the plug-in execution unit 105 are referred to as "second activation unit 45".

In the second activation method, there is a period of waiting for the message to be read from the queue 103, so that the time required for the plug-in to be activated is longer than in the first activation method. Therefore, if the plug-in started by the second starting method and the plug-in started by the first starting method (probable plug-in) match, it is not necessary to start the plug-in by the second starting method. However, when it is started, the number of instances will be excessive and the charge will be excessive.

Therefore, the plug-in management unit 104 is in the case where the plug-in indicated by the message read from the queue 103 (hereinafter referred to as "message plug-in") has already been started by the first starting method (that is, the message plug-in and the prospective plug-in). If the message is the same as), the plug-in execution unit 105 is instructed not to instruct the message plug-in to be started, but to have the started prospective plug-in execute the process with the contents included in the message.

In this way, in the second activation unit 45 (plug-in management unit 104 and plug-in execution unit 105), the message plug-in is a prospective plug-in, and the first activation unit 55 (autoscale management unit 115 and plug-in execution unit 105). If it has already been started by, it works so as not to start the message plugin. As a result, it is possible to prevent the second activation unit 45 from activating the plug-in that does not execute the process and using extra resources.

As mentioned above, the message plug-in (plug-in that executes the requested processing) and the prospective plug-in do not always match. If they do not match, that is, if the message plugin is not launched by the first launcher 55 (that is, if the first launcher 55 launches another plugin as a prospective plugin), the second launcher 45 activates the message plug-in.

In that case, the plug-in management unit 104 instructs the started message plug-in to execute the process with the contents included in the message. As a result, the launched prospective plug-in will not execute any processing. In this case, the autoscale management unit 115 knows that the plug-in is a plug-in that has not been processed for a certain period of time (a plug-in that is not being processed), so it determines that it is a target for scale-in and plugs it in. Stop at the in-execution unit 105. The autoscale management unit 115 is an example of the "virtual machine stop unit" of the present invention.

However, the autoscale management unit 115 does not stop the plug-in in the following cases. The autoscale management unit 115 monitors the queue 103, and as described above, another prospective plug-in (probable plug-in that does not match the message plug-in) that is determined to be the target of scale-in is accumulated in the queue 103. If it is the plug-in indicated by the message, do not stop the prospective plug-in.

By doing so, even if the prospective plug-in identified as a plug-in that is expected to perform the requested processing does not perform the processing according to the request, the launched prospective plug-in will perform other processing. It will be. As a result, compared to the case where the prospective plug-in that does not execute the requested processing is stopped, the processing different from the processing that the prospective plug-in was expected to execute (the plug indicated by the message accumulated in the queue 103). The start of the process executed by the inn will be accelerated.

When the second activation unit 45 reads another message described above from the queue 103, the plug-in indicated by the message is already activated by the first activation unit 55 as a prospective plug-in for another process. Therefore, it works so as not to start the plug-in. As a result, it is possible to prevent the second activation unit 45 from activating the plug-in that does not execute the process and consuming extra resources.

Further, in the auto scale management unit 115, as described above, the prospective plug-in determined to be the target of scale-in (the prospective plug-in that is not executing the process) is again requested by the task request information management unit 111 based on another request. If it is identified as a prospective plugin, the prospective plugin will not be stopped. In this case, the start of the processing expected to be executed by the prospective plug-in based on another request is accelerated as compared with the case where the prospective plug-in that does not execute the requested processing is stopped.

Based on the above configuration, the cloud system 4 performs task processing that activates a plug-in and executes processing included in the task.
FIG. 8 shows an example of the operation procedure of the cloud system 4 in the task processing. This operation procedure is started when the user terminal 3 transmits the request data requesting the execution of the task to the cloud system 4.

First, the cloud system 4 (task service unit 101) receives a request for executing a task (step S10). After that, the cloud system 4 performs the first operation from steps S11 to S13 and the second operation from steps S21 to S23 in parallel. First, the cloud system 4 (task service unit 101 and task definition unit 102) generates a message indicating a plug-in that executes the process included in the requested task (step S11). Next, the cloud system 4 (queue 103) accumulates the generated messages (step S12). Subsequently, the cloud system 4 (plug-in management unit 104) reads the accumulated messages (step S13). This is the first operation.

At the same time, the cloud system 4 (task request information management unit 111, task definition information storage unit 112, request parameter information storage unit 113 or history information storage unit 114) provides a prospective plug-in based on the received request. Identify (step S21). Next, the cloud system 4 (autoscale management unit 115 and plug-in execution unit 105) launches an instance (step S22), and launches the identified prospective plug-in on the instance (step S23). This is the second operation.

The cloud system 4 (plug-in management unit 104) determines whether or not the message plug-in indicated by the message read in the first operation matches the prospective plug-in started in the second operation (step S31). .. If the cloud system 4 (plug-in management unit 104 and plug-in execution unit 105) determines in step S31 that they do not match (NO), it starts an instance (step S32) and starts a message plug-in on that instance. Then (step S33), the process is executed according to the content indicated by the message (step S34).

If the cloud system 4 (plug-in management unit 104 and plug-in execution unit 105) determines that they match (YES) in step S31, the activated probable plug-in executes processing according to the content indicated by the message (the plug-in management unit 104 and the plug-in execution unit 105). Step S34). Then, the cloud system 4 determines whether or not the task has been completed (step S35), and if it determines that the task has not been completed (NO), returns to steps S11 and S21 to perform an operation and completes (YES). If it is determined, this operation procedure is terminated.

Further, the cloud system 4 performs a scale-in process for stopping an instance that has not executed the process based on the above configuration.
FIG. 9 shows an example of the operation procedure of the cloud system 4 in the scale-in processing. This operation procedure is repeated, for example, at fixed time intervals. First, the cloud system 4 (autoscale management unit 115) grasps the execution status of the processing by the plug-in (step S41), and determines whether or not there is a non-processing plug-in that has not executed the processing (step S41). Step S42).

If the cloud system 4 (autoscale management unit 115) determines in step S42 that there is no non-processing plug-in (NO), it returns to step S41 and operates, and there is a non-processing plug-in (YES). If it is determined, it is determined whether or not a message indicating the non-processing plug-in is accumulated in the queue 103 (step S43). If it is determined that the accumulation (YES) is made in step S43, the cloud system 4 (plug-in management unit 104 and plug-in execution unit 105) does not stop the non-processing plug-in, and the non-processing plug-in. The process of the content indicated by the message is executed at the inn (step S47).

If the cloud system 4 (autoscale management unit 115) determines that the plug-in has not been accumulated (NO) in step S43, it determines whether or not the non-processing plug-in has been identified as a prospective plug-in (step S44). If it is determined that the plug-in is not specified (NO), the non-processing plug-in is stopped (step S45), and the process returns to step S41 to perform the operation.

If it is determined (YES) specified in step S44, the cloud system 4 (plug-in management unit 104 and plug-in execution unit 105) has a message plug-in and a prospective plug-in (that is, a plug-in that is not being processed). It is determined whether or not they match (step S46), and if it is determined that they match (YES), the prospective plug-in is not started and the non-processing plug-in is not stopped. The plug-in executes the processing of the content indicated by the message (step S47). If the cloud system 4 (autoscale management unit 115) determines in step S46 that they do not match (NO), the cloud system 4 proceeds to step S45 to stop the non-processing plug-in (step S45), and returns to step S41 to operate. I do.

In the cloud system 4, by performing auto-scaling, scale-out is performed according to the execution status after the processing is executed to reduce the load for each instance and to end the processing early. In this method, if the process is not started, scale-out is performed and the early termination of the process is not dealt with. On the other hand, in this embodiment, by starting the prospective plug-in as described above, measures are taken for early termination of the processing before the requested processing is executed, so it depends on the execution status. The process will be completed even faster than when only scale-out is performed.

[2] Modifications The above-mentioned examples are merely examples of the implementation of the present invention, and may be modified as follows. Further, the examples and the respective modifications may be carried out in combination as necessary.

[2-1] Activation Timing of Probable Plug-in In the embodiment, the first activation unit 55 (autoscale management unit 115 and plug-in execution unit 105) activates the prospective plug-in as soon as it is identified. Since the instance is newly started when the prospective plug-in is started, billing will be started in the cloud system 4. Therefore, the first activation unit 55 may delay the activation timing depending on the situation in order to shorten the billing period as much as possible.

For example, the shorter the time (startup time) required for starting the specified prospective plug-in, the later the first activation unit 55 activates the prospective plug-in. A plug-in is started by performing a startup process of reading related programs, data, parameters, etc. and storing them in a memory, and this startup process requires a certain time (startup time) that differs for each plug-in. The plug-in startup time is the time to start this startup process. In order to make the start-up time different according to the start-up time, the first start-up unit 55 uses, for example, a start-up time table in which the start-up time and the start-up time are associated with each other.

FIG. 10 shows an example of the start-up time table. In the example of FIG. 10, "specific time T1 + t3", "specific time T1 + t2", "specific time T1 + t1" (t1 <t2 <t3) are set to the start time of "less than A1", "A1 or more and less than A2", and "A2 or more". ) Is associated with each other. The specific time T1 is a time when the prospective plug-in is specified, and indicates, for example, a time when the plug-in ID of the prospective plug-in specified by the task request information management unit 111 is supplied.

The first activation unit 55 stores the activation time for each prospective plug-in, and when the plug-in ID of the prospective plug-in is supplied and the specific time T1 is fixed, the activation time is set to the activation time of the specified prospective plug-in. Wait until the startup time associated with the table before starting the prospective plug-in.

If the startup time is uniform, the shorter the startup time, the faster the instance will start, and the higher the instance usage fee will be. In the example of FIG. 10, the shorter the startup time, the later the startup time of the prospective plug-in, so the time when the startup is completed and the prospective plug-in can execute the process is closer than when the startup time is uniform. , The difference in the period during which each instance is started, that is, the difference in usage fee becomes small.

Further, the first activation unit 55 may delay the timing of activating the prospective plug-in as the number of messages stored in the queue 103 increases. The first activation unit 55 uses, for example, an activation time table in which the number of messages and the activation time are associated with each other in order to make the activation time different according to the number of messages.
FIG. 11 shows another example of the start-up time table. In the example of FIG. 11, the number of messages "less than B1", "B1 or more and less than B2", and "B2 or more" includes "specific time T1 + t1", "specific time T1 + t2", and "specific time T1 + t3" (t1 <t2 <t3). ) Is associated with each other.

When the plug-in ID of the prospective plug-in is supplied and the specific time T1 is determined, the first activation unit 55 counts the number of messages with reference to the queue 103, and associates the counted number of messages with the counted number of messages in the activation time table. Wait until the start time, and then start the prospective plug-in. In the example of FIG. 11, the more messages accumulated in the queue 103, the later the start time of the prospective plug-in is delayed. The time when it becomes possible and the time when the corresponding message is read and the execution of the process is started are close, especially when the number of accumulated messages is large, the plugin is not executing the process, but the instance Is running for a shorter period of time.

Further, the first activation unit 55 may activate the specified type of plug-in earlier as the number of the activated plug-ins is smaller than that of the common type. There are various types of plug-ins such as the above-mentioned rectangular image extraction, document division, OCR and conversion. The first activation unit 55 uses, for example, an activation time table in which the number of the same type of plug-ins and the activation time are associated with each other in order to make the activation time different according to the number of the same type of plug-ins that have been started.

FIG. 12 shows another example of the start-up time table. In the example of FIG. 12, the number of messages "less than C1", "more than C1 and less than C2", and "more than C2" are added to "specific time T1 + t1", "specific time T1 + t2", and "specific time T1 + t3" (t1 <t2 <t3). ) Is associated with each other. When the plug-in ID of the prospective plug-in is supplied and the specific time T1 is determined, the first activation unit 55 counts the number of activated plug-ins of the same type as the prospective plug-in, and the activation time is set to the counted number of plug-ins. Wait until the startup time associated with the table before starting the prospective plug-in.

In the cloud system 4, auto-scaling is performed according to the execution status of the plug-in in parallel with the activation of the prospective plug-in. Therefore, plug-ins of the same type as prospective plug-ins also increase due to scale-out and decrease due to scale-in. The smaller the number of plug-ins of the same type, the smaller the number of plug-ins that execute the corresponding processing when scaled in, and the processing tends to be delayed. In the example of FIG. 12, the smaller the number of plug-ins of the same type that have already been started, the earlier the start time of the expected plug-in and the number of plug-ins of the same type are increased earlier. , Even if the number of similar plug-ins that have been started is small, processing delays are less likely to occur.

Further, the first activation unit 55 may activate the specified plug-in earlier as the order of executing the processes included in the requested task is earlier. When a task contains multiple processes, the plurality of processes are executed in order by a plurality of plug-ins. For example, "TASK01" shown in FIG. 4 is executed in the order of "PLUG01" (rectangular image extraction), "PLUG08" (document division), and "PLUG13" (expense settlement data transmission). The first activation unit 55 uses, for example, an activation timing table in which the execution order of the processes and the activation timing are associated with each other in order to make the activation timing different according to the order in which the processes are executed.

FIG. 13 shows another example of the start-up time table. In the example of FIG. 13, "specific time T1 + t1", "specific time T1 + t2", "specific time T1 + t3" (t1 <t2) in the order of execution of the processes "1st", "2nd to 3rd", and "4th and later". The start-up times <t3) are associated with each other. In this example, when the task request information management unit 111 specifies the prospective plug-in, the execution order of the prospective plug-in is also specified.

For example, the task definition information storage unit 112 stores the execution order as task definition information in association with the task definition ID, and the task request information management unit 111 associates the execution order with the task definition ID indicated by the request data in the task definition information. By reading out the plug-in ID and the execution order, the execution order of the prospective plug-in is specified, and the plug-in ID and the execution order of the specified probable plug-in are supplied to the autoscale management unit 115.

When the plug-in ID of the prospective plug-in is supplied and the specific time T1 is determined, the first start unit 55 (autoscale management unit 115 and the plug-in execution unit 105) associates them with the start time table in the order of execution supplied together. Wait until the start time that is set, and then start the prospective plug-in. The earlier the processing order is, the more plug-ins will be started later. Therefore, if there is a delay in starting the plug-in (delay due to a start error, etc.), the effect (the number of plug-ins that cause a delay) ) Becomes larger. In the example of FIG. 13, the earlier the expected plug-in in the execution order of the processing is, the earlier the startup time is. ..

Further, the first activation unit 55 may activate the prospective plug-in earlier as the number of activations of the plug-in of the same type as the specified prospective plug-in increases. The first activation unit 55 uses, for example, an activation time table in which the number of activations and the activation time are associated with each other in order to make the activation time different according to the number of activations.

FIG. 14 shows another example of the start-up time table. In the example of FIG. 14, the number of activations of "less than D1", "D1 or more and less than D2", and "D2 or more" includes "specific time T1 + t3", "specific time T1 + t2", and "specific time T1 + t1" (t1 <t2 <t3). ) Is associated with each other. In this example, the history information storage unit 114 supplies the plug-in ID of the plug-in activated from the plug-in execution unit 105, and stores the information associated with the plug-in ID and the number of activations as history information. do.

When the plug-in ID of the prospective plug-in is supplied and the specific time T1 is determined, the first start-up unit 55 sets the number of start-ups stored in the history information storage unit 114 in association with the plug-in ID in the start-up time table. Wait until the associated startup time before launching the prospective plugin. The more times a plug-in is started, the more processing is required. Therefore, if the start of the plug-in is delayed, the effect will be greater. In the example of FIG. 14, since the startup time of the prospective plug-in with a large number of startups is earlier, the influence of the processing delay by the prospective plug-in on the subsequent processing is smaller than that in the case where the startup time is uniform.

In addition, the first activation unit 55 has a time (processing time) required for the processing executed by the plug-in indicated by the message accumulated in the queue 103 before the message indicating the specified prospective plug-in as the message plug-in. The longer it is, the later the time to launch the prospective plugin may be. The first activation unit 55 uses, for example, an activation time table in which the processing time and the activation time are associated with each other in order to make the activation time different according to the processing time.

FIG. 15 shows another example of the start-up time table. In the example of FIG. 15, “specific time T1 + t1”, “specific time T1 + t2”, “specific time T1 + t3” (t1 <t2 <t3) are set to the processing times of “less than E1”, “E1 or more and less than E2”, and “E2 or more”. ) Is associated with each other. In this example, for example, the plug-in management unit 104 reads the message stored in the queue 103, and calculates the time (processing time) required for the processing based on the content of the processing indicated by the read message. The plug-in management unit 104 in this case is an example of the "calculation unit" of the present invention.

When the plug-in ID of the prospective plug-in is supplied and the specific time T1 is fixed, the first activation unit 55 sets the total processing time calculated for the messages accumulated before the message indicating the plug-in ID to the total time. Wait until the startup time associated with the startup time table before starting the prospective plug-in. The total processing time calculated in this way corresponds to the waiting time until the prospective plug-in is instructed to execute the processing. As compared to the case where the startup time is made uniform by delaying the startup time as the waiting time is longer, the instance is started even though the plug-in is not executing the process, as in the example of FIG. The period of state is shortened.

[2-2] Number of plug-ins to be started on the instance In the embodiment, the plug-in execution unit 105 executes only one plug-in on one instance, but the present invention is not limited to this, and the plug-in execution unit 105 is not limited to this. You may run multiple instances. In that case, even if there is one non-processing plug-in on the instance, the autoscale management unit 115 stops only the non-processing plug-in if another plug-in is executing processing, and other Do not stop plugins and instances of.

Then, the autoscale management unit 115 stops the non-processing plug-in and the instance only when all the plug-ins on the instance become non-processing plug-ins. In either case, the autoscale management unit 115 does not change in that the plug-in that has been processed is stopped. The autoscale management unit 115 is an example of the "function stop unit" of the present invention.

Further, when the plug-in is scaled out, the autoscale management unit 115 starts the plug-in on the instance if the resource for starting the plug-in is available. In this way, the autoscale management unit 115 controls the autoscale so that the number of instances does not increase as much as possible while leaving the plug-in that is executing the process.

[2-3] Plug-in-only autoscale In the embodiment, the plug-in execution unit 105 autoscales the plug-in and the instance at the same time (when the plug-in is started, the instance is also started and the plug-in is started. When it is stopped, the instance is also stopped), but it is not limited to this, and autoscale may be performed only for the plug-in as in the above-mentioned modification.

In the above-mentioned modification, a plurality of instances are executed on one instance, but when only one plug-in is executed on one instance as in the example, autoscale is applied only to the plug-in. You may go. In that case, if you stop only the plug-in, the instance in the state where the plug-in is not running will remain. The first activation unit 55 may launch the identified prospective plug-in on the instance when the plug-in on the instance has completed the process and is stopped.

It takes a certain amount of time to start an instance like a plug-in, but by reusing an already started instance as described above, it is not necessary to wait for the instance start time. When the first activation unit 55 activates the prospective plug-in by reusing the instance in this way, the first activation unit 55 controls the prospective plug-in to change the activation timing as described in the explanations of FIGS. 10 to 15. You do not have to do.

When reusing an instance, there is no cost for a new instance, so even if the startup time is delayed, the billing period will not be shortened. If this is the case, the first activation unit 55 immediately activates the specified prospective plug-in, which increases the possibility of early termination of the process as compared with the case where the activation time is delayed.

[2-4] Reuse of prospective plug-in In each of the above examples, the first activation unit 55 always newly starts the prospective plug-in, but by using the plug-in that has already been started, the prospective plug-in can be used. You may not start anew. Specifically, the first activation unit 55 is when a plug-in of the same type as the specified prospective plug-in exists in a state where processing has not been executed for a certain period of time (that is, when the above-mentioned non-processing plug-in exists). ) Does not launch the prospective plugin.

Then, when the first activation unit 55 does not activate the prospective plug-in in this way, the plug-in management unit 104 controls the above-mentioned non-processing plug-in and is used to identify the prospective plug-in. Execute the requested process. The plug-in management unit 104 in this case is an example of the "execution control unit" of the present invention.

In this modified example as well, the instance in which the non-processing plug-in is running is reused, so there is no cost for a new instance. Also, by reusing both the instance and the plug-in, the time required to stop and start both of them becomes unnecessary, so the possibility of early termination of processing is higher than when this reuse is not performed. Be done.

[2-5] Method for Realizing Each Function In each function shown in FIG. 3, two or more functions may be integrated, or one function may be divided into two or more functions. For example, the task service unit 101 supplies a reception unit that receives a request for execution of a task, a generation unit that generates a message based on the received request, and request data to the task request information management unit 111, and requests the contents of the request. It may be divided into a notification unit for notifying. Further, the autoscale management unit 115 may be divided into a first management unit that manages the autoscale of the instance and a second management unit that manages the autoscale of the plug-in.

Further, the task request information management unit 111, the task definition information storage unit 112, the request parameter information storage unit 113, and the history information storage unit 114 may be integrated as specific units for specifying the prospective plug-in. Further, a specific part for specifying the prospective plug-in may be provided separately from each part shown in FIG. In short, as long as the functions equivalent to the functions shown in FIG. 3 are realized in the entire task service providing system 1, the functions may be organized in any way.

[2-6] Category of Invention The present invention can be regarded as an information processing system called a cloud system 4 or a task service providing system 1 provided with the information processing device in addition to the information processing device called the server device 10. Further, the present invention can be regarded as an information processing method for realizing the processing performed by each device, and also as a program for operating a computer that controls each device. This program may be provided in the form of a recording medium such as an optical disk that stores it, or may be downloaded to a computer via a communication line such as the Internet, and installed and made available. May be provided.

1 ... Task service providing system, 3 ... User terminal, 4 ... Cloud system, 10 ... Server device, 101 ... Task service unit, 102 ... Task definition unit, 103 ... Queue, 104 ... Plug-in management unit, 105 ... Plug-in execution Unit, 111 ... Task request information management unit, 112 ... Task definition information storage unit, 113 ... Request parameter information storage unit, 114 ... History information storage unit, 115 ... Autoscale management unit.

Claims (14)

Computer,
A generator that generates function information indicating the function when it receives a request for processing executed by the function started on the virtual machine.
A temporary storage unit that temporarily stores the generated functional information,
A specific part that identifies a function that is expected to execute the process based on the request for the process, and
The first boot unit that launches the specified function on the virtual machine,
It is a second activation unit that activates the function indicated by the function information read from the temporary storage unit on the virtual machine, and if the function has already been activated by the first activation unit, the function is not activated. A program to function as the second startup unit. The computer functions as a virtual machine starter that starts a virtual machine having resources used when the function is started by the first starter or the second starter. The program according to claim 1. The computer is a virtual machine stop unit that stops a virtual machine in which a function that does not execute the process is activated, and is a function indicated by the function information in which the function is stored in the temporary storage unit. In this case, the program according to claim 1 or 2, which functions as a virtual machine stop unit that does not stop the function. The virtual machine stop unit does not stop the virtual machine when the function that does not execute the process is specified by the specific unit as a function that is expected to execute the process based on another request. The program according to claim 3. The specific unit is a function that is expected to execute a function that is more likely to be activated from the parameter of the requested process or the history of the request for the process than other functions. The program according to any one of claims 1 to 4 to be specified. The program according to any one of claims 1 to 5, wherein the first activation unit delays the activation time of the specified function as the time required to activate the function is shorter. The program according to any one of claims 1 to 6, wherein the first activation unit delays the activation time of the specified function as the amount of the function information stored in the temporary storage unit increases. There are multiple types of the above functions.
The program according to any one of claims 1 to 7, wherein the first activation unit activates a function of the specified type earlier as the number of functions having the same type and activated is smaller. .. The processing is executed in order by a plurality of functions,
The program according to any one of claims 1 to 8, wherein the first activation unit activates the specified function earlier as the order of the functions is earlier. There are multiple types of the above functions.
The program according to any one of claims 1 to 9, wherein the first activation unit activates the specified function earlier as the number of activations of the same type of function as the specified function increases. The computer is made to function as a calculation unit for calculating the time required for the processing executed by the function indicated by the accumulated function information.
The first activation unit is claimed to delay the timing of activating the function on the virtual machine as the time calculated for the function information accumulated before the function information indicating the specified function is longer. Item 5. The program according to any one of Items 1 to 10. The computer is made to function as a function stop unit for stopping the function for which the process has been completed.
When the function on the virtual machine is stopped after completing the process, the first activation unit activates the specified function on the virtual machine, and controls the function to change the timing. The program according to any one of claims 6 to 11. There are multiple types of the above functions.
When a function of the same type as the specified function exists in a state where the process is not executed, the first activation unit does not activate the specified function.
Claims 1 to 12 that cause the computer to function as an execution control unit that controls a function existing in the state and executes the requested process when the first activation unit does not activate the function. The program described in any one of the above. A generator that generates function information indicating the function when it receives a request for processing executed by the function started on the virtual machine.
A temporary storage unit that temporarily stores the generated functional information,
A specific part that identifies a function that is expected to execute the process based on the request for the process, and
The first boot unit that launches the specified function on the virtual machine,
It is a second activation unit that activates the function indicated by the function information read from the temporary storage unit on the virtual machine, and if the function has already been activated by the first activation unit, the function is not activated. An information processing device including a second activation unit.

Images