JP7692766B2 - Management device, method, and program - Google Patents

Description

This disclosure relates to technology for providing multi-tenant services on the cloud.

There are service providers that use cloud resources to provide applications in a multi-tenant format. Some cloud services use blockchain technology.

Service providers are required to distribute virtual processor and virtual memory resources fairly and efficiently among multiple service users. Typically, service providers cap the upper limit of resources available to each of multiple service users and distribute the resources at a fixed ratio. Patent Document 1 discloses a technology for allocating resources in an on-demand service environment by an auction using resource currency values. Patent Document 2 discloses a technology that enables efficient use of resources by providing tokens for both normal mode and burst mode and accommodating surplus resources in burst mode.

Special table 2015-535975 publication JP 2018-77852 A

Blockchain technology has a variety of unique properties. Data written to the cloud by a service user is shared by other service users on the blockchain network. Service users who contribute to information sharing provide their assigned resources to other companies. Other service users benefit from the contributions of such service users. In addition, in blockchain, data is broken down into blocks of a specified size and written to the cloud. Therefore, if small amounts of data are frequently written to blocks, processing performance decreases.

To date, no method has been proposed to achieve optimal resource distribution while taking into account these characteristics of blockchain.

One objective of this disclosure is to provide technology that realizes optimal resource distribution on the cloud in a multi-tenant service.

A management device according to one aspect of the present disclosure is a management device that accepts data processing calls from users and executes data processing using resources in a multitenant service that executes data processing for multiple users using resources shared by multiple users on a cloud, and accepts data processing calls from users in a burst mode if the count value reaches an upper limit value and there are no other users with data processing calls among the multiple users sharing the resources during the burst time, accepts data processing if there are other users with data processing calls among the multiple users sharing the resources and the data resulting from the user's data processing has not reached a predetermined data size, and waits for a predetermined recovery time and then accepts data processing if the data resulting from the user's data processing has reached the data size.

According to one aspect of the present disclosure, it is possible to realize optimal resource distribution on the cloud in a multi-tenant service.

FIG. 1 is a block diagram showing a configuration of a multi-tenant service system. FIG. 2 is a block diagram of a management device. 13 is a flowchart of a user management process. FIG. 13 is a diagram showing a list of contract plans. FIG. 13 illustrates a user table. FIG. 13 is a diagram showing a priority order table. 13 is a flowchart of an API receiving process. FIG. 13 is a flowchart of a priority order process. 13 is a flowchart of an API call reception process.

The following describes an embodiment of the present invention with reference to the drawings.

Figure 1 is a block diagram showing the configuration of a multi-tenant service system.

The multitenant service system is a system that provides multitenant services. The multitenant service is configured to store user data using a blockchain. The multitenant service is constructed by an application program that is executed by calling an API (application programming interface). The application program is executed by resources 12 including a virtual processing device 13 and a storage device 14 on the cloud 11. The resources 12 are shared by multiple users A 16A, B 16B, and C 16C who have signed a contract to use the multitenant service. Hereinafter, the multiple users A 16A, B 16B, and C 16C may be collectively referred to as users 16. Note that the user 16 here may be an organization such as a company, or an individual.

The multi-tenant service system is provided with a management device 15 that receives API calls from users 16 and causes resources 12 to execute the processing called by the API.

2 is a block diagram of the management device. The management device 15 has a user management unit 21 and an API control unit 25. In this embodiment, a configuration in which a common management device 15 is arranged for multiple users 16 is shown, but the physical configuration and logical configuration are not limited to this. The management device 15 may be provided for each user 16 and configured with multiple gateway devices that accept API calls from the users 16, and may be realized by the multiple gateway devices cooperating with each other. In this case, the gateway device can also be constructed on the cloud 11. In this embodiment, the management device 15 is illustrated as being constructed on the cloud 11, but is not limited to this example. The management device 15 may also be constructed by a computer such as a server device that physically has a processor and memory and executes a software program using the processor.

The user management unit 21 manages users 16 who use the multi-tenant service. As shown in FIG. 2, the user management unit 21 has a contract plan acceptance unit 22, an upper limit determination unit 23, and a priority determination unit 24.

The contract plan reception unit 22 presents various contract plans with different fees to the user 16 who wishes to sign a contract to use the multi-tenant service, and determines the contract plan to be used based on the user 16's wishes.

The upper limit determination unit 23 determines the upper limit of the number of API calls that can be accepted per unit time according to the desires of the user 16. Hereinafter, the upper limit of the number of API calls that can be accepted per unit time may be referred to as the API upper limit. The API upper limit may be determined according to the contract plan.

The API upper limit is not an absolute upper limit, and in burst mode, API calls can be accepted beyond the API upper limit. The upper limit determination unit 23 determines a burst time, which is the time during which API calls can be accepted beyond the API upper limit. The burst time may be a unit time distributed according to the ratio of the API upper limit of each user 16 to the total API upper limit of all users 16 sharing the resource 12. Hereinafter, the ratio of each user's API upper limit to the total API upper limit of all users may be referred to as the API upper limit ratio.

The priority determination unit 24 determines the priority of each user 16 in the processing of API calls. The priority may be determined in descending order of the ratio of each user's API upper limit value to the total API upper limit value of all users.

The API control unit 25 controls the execution of processes by calling APIs by the user 16. As shown in FIG. 2, the API control unit 25 has a queue registration unit 26, a database queue 27, a queue retrieval unit 28, and an API execution reception unit 29. Hereinafter, database may be abbreviated as DB.

The queue registration unit 26 receives an API call from the user 16 and registers it in the DB queue 27.

The DB queue 27 is a queue that manages API calls received from each user 16.

The queue extraction unit 28 extracts the API call from the DB queue 27 according to the decision of the API execution reception unit 29.

The API execution reception unit 29 measures the number of API calls that have been accepted by the user 16 per unit time as a count value, and accepts the API call if the count value has not reached the API upper limit value, and controls the acceptance of API calls from the user 16 based on the burst time in burst mode if the count value has reached the API upper limit value. The detailed processing will be described later.

Figure 3 is a flowchart of the user management process. The user management process is executed by the contract plan acceptance unit 22, upper limit determination unit 23, and priority determination unit 24 of the user management unit 21.

In step 101, the contract plan acceptance unit 22 presents a number of predefined contract plans to the user 16 and prompts the user to select one.

Figure 4 shows a list of contract plans.

There are four types of contract plans: "Pine," "Bamboo," "Plum," and "Cheap." "Pine" has a monthly fee of 100,000 yen and an API upper limit of 100 times per second. "Bamboo" has a monthly fee of 50,000 yen and an API upper limit of 40 times per second. "Plum" has a monthly fee of 30,000 yen and an API upper limit of 20 times per second. "Cheap" has a monthly fee of 10,000 yen and an API upper limit of 0 times per second. The response type to API calls is best effort for all contract plans. User 16 selects the contract plan to use from these contract plans.

In step 102, the contract plan acceptance unit 22 determines the contract plan that each user 16 will use based on the selection of each user 16.

In step 103, the upper limit determination unit 23 determines the API upper limit value for each user 16 based on the contract plan of each user 16, and accordingly determines the API upper limit value ratio for that user 16.

In step 104, the user management unit 21 creates a user table that manages all users 16 who share resources 12 in the multitenant service.

Figure 5 is a diagram showing the user table. In the user table, the user name, API upper limit, API upper limit ratio, and API actual ratio of each user are registered. A user with the user name "Hitachi" has subscribed to the contract plan "Matsu" shown in Figure 4. A user with the user name "Ikeda" has subscribed to the contract plan "Take" shown in Figure 4. A user with the user name "Totsuka" has subscribed to the contract plan "Ume" shown in Figure 4. A user with the user name "Yoshida" has subscribed to the contract plan "Cheap" shown in Figure 4.

As described above, the API upper limit ratio is the ratio of each user's API upper limit to the total API upper limit of all users. For example, in FIG. 5, the API upper limit ratio of a user with the user name "Hitachi" is calculated using formula (1).

API upper limit rate (Hitachi) = 100 times / (100 + 60 + 40) = 50% ... (1)

The actual API ratio is the ratio of the number of times an API was called by a particular user 16 to the total number of times an API was called by all users 16. When the user table is created, no numerical value is entered into the actual API ratio.

Returning to FIG. 3, in step 105, the priority determination unit 24 calculates the burst time for each user 16.

As described above, the burst time is a unit time distributed according to the ratio of the API upper limit value of each user 16 to the total API upper limit values of all users 16 (i.e., the API upper limit value ratio). For example, in FIG. 5, the burst time of a user with the user name "Hitachi" is calculated by formula (2).

Burst time (Hitachi) = 1 second x (API upper limit rate (Hitachi)) = 0.2 seconds ... (2)

In step 106, the priority determination unit 24 determines the priority for applying burst mode to each user 16 and creates a priority table indicating the priority in processing API calls for each user 16.

As described above, the priority determination unit 24 assigns priority to each user 16 in descending order of API upper limit value ratio.

Figure 6 shows a priority table. The priority table records a numerical value indicating a priority and the user name of the user corresponding to that priority. For example, the priority of a user with the user name "Hitachi" is "1," and the priority of a user with the user name "Ikeda" is "2."

Figure 7 is a flowchart of the API reception process. The API reception process is executed by the queue registration unit 26.

In step 201, the queue registration unit 26 acquires the API call received from the user 16, and in step 202, acquires the time at which the API call was received. Hereinafter, the time at which the API call was received may be referred to as the reception time.

In step 203, the queue registration unit 26 registers the API call and its management information in the database and DB queue 27.

In step 204, the queue registration unit 26 sends a signal indicating that a new API call has been registered in the DB queue 27.

Figure 8 is a diagram showing the database. In the database, an identifier, a user name, a process name, a reception time, and a start time are recorded for each API call. The identifier is identification information for individually identifying an API call. The user name is information indicating the user 16 who sent the API call. The process name is the process name indicating the process that is called and executed by the API call. The reception time is the time that the API call was received. The start time is the time that the process by the API call is started. When the API call is registered in the database, the start time is not recorded.

In the DB queue 27, the API calls received from each user 16 are recorded in the order in which they were received. The configuration of the DB queue 27 is not particularly limited, but is configured to be able to identify the order in which the API calls were received for each user 16. For example, the DB queue 27 may be configured with an individual queue for each user 16. Also, for example, the DB queue 27 may be configured to double as a database, be shared by multiple users 16, record each API together with information (e.g., user name) that identifies the user 16 who sent it, and be able to extract the API call of the desired user 16. In the example of FIG. 8, if the user with the user name "Hitachi" is the processing target, the API call with identifier 1003 may be extracted before the API call with identifier 1001.

Figure 9 is a flowchart of the priority order process. The priority order process is a process for determining which users should be given priority in applying burst mode. The priority order process is executed by the user management unit 21.

In step 301, the user management unit 21 advances the current pointer in the priority table by one when a predetermined condition is met. The predetermined condition includes the expiration of the burst time of the current priority user and the end of the API invocation of the current priority user.

In step 302, the user management unit 21 identifies the new priority target user to which the current pointer in the priority table points.

In step 303, the user management unit 21 applies burst mode preferentially to the new priority user.

Figure 10 is a flowchart of the API call reception process. The API call reception process is executed for the user 16 to which the signal is being sent, with priority being given to the priority target user. In this example, the user 16 to be processed is user A. The API call reception process is executed by the API execution reception unit 29 of the API control unit 25.

The API execution reception unit 29 measures the number of API calls that have been accepted for each user 16, including user A, per unit time. Hereinafter, the number of API calls that have been accepted may be referred to as the number of API calls.

When an API call is made (step 401), the API execution reception unit 29 determines in step 402 whether the number of API calls made by user A has reached the upper limit for user A. If the number of API calls made by user A has not reached the upper limit for user A, the API execution reception unit 29 accepts the API call made by user A in step 403, and adds 1 to the number of API calls made by user A in step 404. When the API call is accepted, the called process is executed by the resource 12 of the cloud 11.

If it is determined in step 402 that the number of API calls by user A has reached the upper limit for user A, then in step 405, the API execution receiving unit 29 determines whether or not only API calls by user A have been made within the burst time. If only API calls by user A have been made within the burst time, then in step 406, the API execution receiving unit 29 receives the API call by user A and proceeds to step 404.

If it is determined in step 405 that only the API call by user A is not being performed within the burst time, then in step 407, the API execution receiving unit 29 determines whether the total amount of data generated by the processing of the API call by user A and not yet written to the blockchain has reached the size of a block in the blockchain. The size of a block in the blockchain may be referred to as the block size hereinafter. If the total amount of data generated by the processing of the API call by user A and not yet written to the blockchain has not reached the block size, the API execution receiving unit 29 proceeds to step 406. In step 406, the API call by user A is accepted, and the data generated by the called processing is written to the block together with the data that has not yet been written to the blockchain.

If the total amount of data generated by the processing of the API call by user A and not yet written to the blockchain has reached the block size, the API execution receiving unit 29 temporarily suspends the acceptance of API calls for a predetermined recovery time in step 408, then resumes and proceeds to step 403. The recovery time is a system parameter indicating the time to wait for the acceptance of API calls that exceed the API upper limit, and is determined in advance by the API execution receiving unit 29.

In this embodiment, API processing is performed in burst mode exceeding the upper limit on the number of APIs, up to a burst time according to the API upper limit and fee linked to each user's contract plan, and data is controlled so that it is written to the blockchain block as collectively as possible. API calls that exceed the API upper limit are accepted up to the burst time determined according to the API upper limit, providing a sense of fairness to users. In addition, data is written to the blockchain in block sizes, reducing the number of write processes that occur.

The present embodiment described above includes the following items. However, the items included in the present embodiment are not limited to those listed below.

(Item 1)
1. A multitenant service that executes data processing for a plurality of users using resources shared by the plurality of users on a cloud, comprising: a management device that receives a call for data processing from the plurality of users and executes the data processing using the resources, the management device comprising:
a user management unit that pre-sets, for each user, an upper limit on the number of calls to data processing per unit time and a burst time that is a time during which calls to data processing can be accepted in excess of the upper limit;
a data processing control unit that measures the number of accepted calls for data processing by the user per unit time as a count value, accepts the data processing if the count value has not reached the upper limit value, and controls acceptance of the calls for data processing from the user based on the burst time if the count value has reached the upper limit value;
having
The data processing control unit
If the count value has reached the upper limit, the burst mode is set, and during the burst time,
If there is no other user among the multiple users sharing the resource who has a call for data processing, the data processing is accepted;
Among the multiple users sharing the resource, if there is another user with a data processing call,
If the data resulting from the data processing by the user has not reached a predetermined data size, the data processing is accepted;
If the data resulting from the data processing by the user has reached the data size, the data processing is accepted after waiting for a predetermined recovery time.
Management device.

According to this, if the data processing count value has reached the upper limit, and there are no other users for whom data processing calls are being accepted within the burst time, the data processing is accepted; even if there are other users for whom data processing calls are being accepted within the burst time, the data processing is accepted if the data resulting from the user's data processing has not reached a predetermined data size. This makes it possible to realize optimal resource distribution on the cloud in a multi-tenant service.

(Item 2)
The multi-tenant service is a service that stores data of the multiple users using a blockchain,
The data size is determined based on a size of a block of the blockchain;
The data processing control unit compiles data generated by causing the resource to execute the data processing into the block and records the data in the block chain.
2. The management device according to item 1.

This makes it possible to realize optimal resource distribution on the cloud, taking into account the characteristics of the blockchain. Since data is written to the blockchain in blocks of a specified size, the number of writes and the number of pieces of data written can be reduced by aggregating small data into blocks.

(Item 3)
The data processing is processing by an application programming interface.
2. The management device according to item 1.

This allows resources on the cloud to be optimally distributed on an API call basis.

(Item 4)
The user management unit
generating a priority order table indicating a priority order in data processing for each of the users in accordance with a ratio of the upper limit value of each of the users to a total of the upper limit values of the plurality of users;
a current pointer indicating a priority target user who is to be given priority in accepting the data processing in the priority order table;
causing the data processing control unit to apply the burst mode with priority to the priority target user;
when the burst time expires or when the prioritized user no longer has a data processing call, advance the current pointer to the next user in the priority table;
2. The management device according to item 1.

This allows for a process to distribute resources according to priorities based on a given upper limit percentage.

(Item 5)
the upper limit is determined by a contract plan of the multi-tenant service used by the user,
the user management unit sets a burst time for each of the users in accordance with a ratio of the upper limit value for each of the users to a sum of the upper limit values for the multiple users.
2. The management device according to item 1.

This allows data processing in burst mode that exceeds the upper limit to be accepted for a burst time that corresponds to the percentage of the upper limit determined by the contract plan, providing a sense of fairness to users.

(Item 6)
The data processing control unit
enqueueing the user's data processing invocation in a per-user invocation queue;
If the count value does not reach the upper limit value, the data process is dequeued from the call queue and accepted;
If the count value reaches the upper limit value,
If there is no other user among the plurality of users who is accepting a call for data processing within the burst time, dequeue the data processing from the call queue and accept it;
If there is another user among the plurality of users who is accepting a data processing call within the burst time,
If the data resulting from the data processing by the user has not reached the data size, dequeue and accept the data processing from the queue;
If the data resulting from the data processing of the user reaches the data size, the acceptance of calls for the data processing is stopped.
2. The management device according to item 1.

In this way, data processing is managed and processed using queues, making it possible to allocate resources appropriately for data processing even when real-time processing is not possible.

(Item 7)
The data processing control unit
A recovery time is previously determined as a time during which the acceptance of a call for data processing that has exceeded the upper limit is stopped and the device waits for the call,
if the count value has reached the upper limit value, and among the multiple users sharing the resource, there is another user who is accepting calls for data processing within the burst time, and data from the data processing of the user has reached the data size, then the acceptance of the calls for data processing is stopped for the recovery time.
2. The management device according to item 1.

This allows resource distribution processing to be carried out with appropriate recovery time.

(Item 8)
the management device is configured with a plurality of gateways provided for each user and receiving data processing calls from the users;
The gateway is constructed on the cloud.
2. The management device according to item 1.

The above-described embodiments of the present invention are merely illustrative examples of the present invention, and are not intended to limit the scope of the present invention to these embodiments. Those skilled in the art may implement the present invention in various other forms without departing from the scope of the present invention.

Reference Signs List 11: Cloud, 12: Resource, 13: Processing device, 14: Storage device, 15: Management device, 16A: User A, 16B: User B, 16C: User C, 16: User, 21: User management unit, 22: Contract plan reception unit, 23: Upper limit determination unit, 24: Priority determination unit, 25: API control unit, 26: Queue registration unit, 27: Database queue, 28: Queue retrieval unit, 29: API execution reception unit

Claims (10)

1. A multitenant service that executes data processing for a plurality of users using resources shared by the plurality of users on a cloud, comprising: a management device that receives a call for data processing from the plurality of users and executes the data processing using the resources, the management device comprising:
a user management unit that pre-sets, for each user, an upper limit on the number of calls to data processing per unit time and a burst time that is a time during which calls to data processing can be accepted in excess of the upper limit;
a data processing control unit that measures the number of accepted calls for data processing by the user per unit time as a count value, accepts the data processing if the count value has not reached the upper limit value, and controls acceptance of the calls for data processing from the user based on the burst time if the count value has reached the upper limit value;
having
The data processing control unit
If the count value has reached the upper limit, the burst mode is set, and during the burst time,
If there is no other user among the multiple users sharing the resource who has a call for data processing, the data processing is accepted;
Among the multiple users sharing the resource, if there is another user with a data processing call,
If the data resulting from the data processing by the user has not reached a predetermined data size, the data processing is accepted;
If the data resulting from the data processing by the user has reached the data size, the data processing is accepted after waiting for a predetermined recovery time.
Management device. The multi-tenant service is a service that stores data of the multiple users using a blockchain,
The data size is determined based on a size of a block of the blockchain;
The data processing control unit compiles data generated by causing the resource to execute the data processing into the block and records the data in the block chain.
The management device according to claim 1 . The data processing is processing by an application programming interface.
The management device according to claim 1 . The user management unit
generating a priority order table indicating a priority order in data processing for each of the users in accordance with a ratio of the upper limit value of each of the users to a total of the upper limit values of the plurality of users;
a current pointer indicating a priority target user who is to be given priority in accepting the data processing in the priority order table;
causing the data processing control unit to apply the burst mode with priority to the priority target user;
when the burst time expires or when the prioritized user no longer has a data processing call, advance the current pointer to the next user in the priority table;
The management device according to claim 1 . the upper limit is determined by a contract plan of the multi-tenant service used by the user,
the user management unit sets a burst time for each of the users in accordance with a ratio of the upper limit value for each of the users to a sum of the upper limit values for the multiple users.
The management device according to claim 1 . The data processing control unit
enqueueing the user's data processing invocation in a per-user invocation queue;
If the count value does not reach the upper limit value, the data process is dequeued from the call queue and accepted;
If the count value reaches the upper limit value,
If there is no other user among the plurality of users who is accepting a call for data processing within the burst time, dequeue the data processing from the call queue and accept it;
If there is another user among the plurality of users who is accepting a data processing call within the burst time,
If the data resulting from the data processing by the user has not reached the data size, dequeue and accept the data processing from the queue;
If the data resulting from the data processing of the user reaches the data size, the acceptance of calls for the data processing is stopped.
The management device according to claim 1 . The data processing control unit
A recovery time is previously determined as a time during which the acceptance of a call for data processing that has exceeded the upper limit is stopped and the device waits for the call,
if the count value has reached the upper limit value, and among the multiple users sharing the resource, there is another user who is accepting calls for data processing within the burst time, and data from the data processing of the user has reached the data size, then the acceptance of the calls for data processing is stopped for the recovery time.
The management device according to claim 1 . the management device is configured with a plurality of gateways provided for each user and receiving data processing calls from the users;
The gateway is constructed on the cloud.
The management device according to claim 1 . 1. A management method for a multitenant service that executes data processing for a plurality of users using resources shared by the plurality of users on a cloud, the method comprising: receiving a call for data processing from the plurality of users and causing the resources to execute the data processing, the method comprising:
The computer
an upper limit value of the number of data processing calls per unit time and a burst time, which is a time during which data processing calls exceeding the upper limit value can be accepted, are set in advance for each user;
Counting the number of accepted calls for data processing by the user per unit time as a count value;
If the count value does not reach the upper limit value, the data processing is accepted;
If the count value has reached the upper limit, the burst mode is set, and during the burst time,
If there is no other user among the multiple users sharing the resource who has a call for data processing, the data processing is accepted;
Among the multiple users sharing the resource, if there is another user with a data processing call,
If the data resulting from the data processing by the user has not reached a predetermined data size, the data processing is accepted;
If the data resulting from the data processing by the user has reached the data size, the data processing is accepted after waiting for a predetermined recovery time.
A management method for carrying out this task. 1. A multitenant service that executes data processing for a plurality of users using resources shared by the plurality of users on a cloud, comprising: a management program that receives a call for data processing from the plurality of users and causes the resources to execute the data processing, the management program comprising:
On the computer,
an upper limit value of the number of data processing calls per unit time and a burst time, which is a time during which data processing calls exceeding the upper limit value can be accepted, are set in advance for each user;
Counting the number of accepted calls for data processing by the user per unit time as a count value;
If the count value does not reach the upper limit value, the data processing is accepted;
If the count value has reached the upper limit, the burst mode is set, and during the burst time,
If there is no other user among the multiple users sharing the resource who has a call for data processing, the data processing is accepted;
Among the multiple users sharing the resource, if there is another user with a data processing call,
If the data resulting from the data processing by the user has not reached a predetermined data size, the data processing is accepted;
If the data resulting from the data processing by the user has reached the data size, the data processing is accepted after waiting for a predetermined recovery time.
A management program for making this happen.

Images