Management device, method, and program

Abstract

To provide a technology that realizes favorable resource distribution on a cloud in a multi-tenant type service.SOLUTION: A management device that receives a call of data processing from a user to execute data processing by means of a resource in a multi-tenant type service that executes data processing by means of the resource shared by a plurality of users on a cloud, receives data processing when there is no other user who has a call of data processing among a plurality of users sharing the resource during burst time if a count value reaches an upper limit, receives data processing when there is other user who has a call of data processing among the plurality of users sharing the resource and if data based on data processing of the user does not reach predetermined data size, and receives data processing after waiting predetermined recovery time if the data based on data processing of the user reaches the data size.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to a technology for providing a multi-tenant service on the cloud.

Background Art

[0002] There are service providers that provide applications in a multi-tenant manner using cloud resources. Some clouds utilize blockchain technology.

[0003] Service providers are required to fairly and efficiently allocate resources such as virtual processors and virtual memories to multiple service users. Generally, service providers cap the upper limit of available resources for each of multiple service users and allocate resources at a fixed rate. Patent Document 1 discloses a technique for resource allocation in an on-demand service environment by means of an auction using resource currency values. Patent Document 2 also discloses a technique that enables efficient use of resources by providing tokens for each of the normal mode and the burst mode and lending surplus resources by means of the burst mode.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] Blockchain technology has various unique properties. Data written by a certain service user to the cloud is shared on the blockchain network by other service users. Service users who contribute to information sharing provide the resources allocated to themselves for the benefit of other companies. Due to the contributions of such service users, other service users will benefit. Also, in blockchain, data is blocked into blocks of a predetermined size and written to the cloud. Therefore, if it frequently occurs to add and write small-sized data to a block, the processing performance will decline.

[0006] So far, no method has been proposed to realize suitable resource allocation considering such properties of blockchain.

[0007] One object of the present disclosure is to provide a technology for realizing suitable resource allocation on the cloud in a multi-tenant type service.

Means for Solving the Problem

[0008] A management device according to one aspect of the present disclosure is a management device that receives a call for data processing from a user and executes data processing with resources in a multi-tenant type service that executes data processing of a plurality of users with resources shared by the plurality of users on the cloud. When the count value reaches the upper limit value, in burst mode, if there is no other user with a call for data processing among the plurality of users sharing the resources during the burst time, it accepts the data processing. If there is another user with a call for data processing among the plurality of users sharing the resources, and the data by the user's data processing has not reached a predetermined data size, it accepts the data processing. If the data by the user's data processing has reached the data size, it waits for a predetermined recovery time and then accepts the data processing.

Effect of the Invention

[0009] According to one aspect of the present disclosure, suitable resource allocation on the cloud can be realized in a multi-tenant service.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Modes for Carrying Out the Invention

[0011] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0012] FIG. 1 is a block diagram showing the configuration of a multi-tenant service system.

[0013] The multi-tenant service system is a system that provides multi-tenant services. The multi-tenant service is configured to store user data by means of a blockchain. Also, the multi-tenant service is constructed by application programs that are executed by calling an API (Application Programming Interface). The application programs are executed by resources 12 including a virtual processing device 13 and a storage device 14 on cloud 11. The resources 12 are shared by a plurality of users A16A, user B16B, and user C16C who have entered into a usage contract for the multi-tenant service. Hereinafter, the plurality of users A16A, user B16B, and user C16C may be collectively referred to as user 16. Note that the user 16 referred to here may be an organization such as a company or an individual.

[0014] The multi-tenant service system is provided with a management device 15 that receives an API call from user 16 and causes the resources 12 to execute the process called by the API.

[0015] Figure 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 the present embodiment, a configuration is shown in which a common management device 15 is arranged for a plurality of users 16, but the physical configuration and the logical configuration are not limited to this. The management device 15 may be provided for each user 16 and may be constituted by a plurality of gateway devices that receive API calls from the user 16, and may be realized by the plurality of gateway devices cooperating with each other. In that case as well, the gateway devices can be constructed on the cloud 11. Also, in the present 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 be constructed by a computer such as a server device that physically includes a processor and a memory and executes a software program by the processor.

[0016] The user management unit 21 manages users 16 who use the multi-tenant type service. As shown in FIG. 2, the user management unit 21 includes a contract plan reception unit 22, a limit determination unit 23, and a priority determination unit 24.

[0017] The contract plan reception unit 22 presents contract plans with various fees to the user 16 who intends to conclude a usage contract for the multi-tenant type service, and determines the contract plan to be used according to the wishes of the user 16.

[0018] The limit determination unit 23 determines the upper limit value of the number of API calls acceptable per unit time according to the wishes of the user 16. Hereinafter, the upper limit value of the number of API calls acceptable per unit time may be referred to as the API upper limit value. The API upper limit value may be determined according to the contract plan.

[0019] The API upper limit value is not an absolute upper limit value, and in burst mode, API calls can be accepted even if the API upper limit value is exceeded. The limit determination unit 23 determines the burst time, which is the time during which API calls can be accepted even if the API upper limit value is exceeded. The burst time may be a time obtained by allocating unit time according to the ratio of the API upper limit value of each user 16 to the total API upper limit value of all users 16 sharing the resource 12. Hereinafter, the ratio of the API upper limit value of each user to the total API upper limit value of all users may be referred to as the API upper limit ratio.

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

[0021] The API control unit 25 controls the execution of processing by API calls made by the user 16. As shown in FIG. 2, the API control unit 25 includes a queue registration unit 26, a database queue 27, a queue extraction unit 28, and an API execution reception unit 29. Hereinafter, the database may be abbreviated as DB.

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

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

[0024] The queue extraction unit 28 extracts an API call from the DB queue 27 according to the decision of the API execution acceptance unit 29.

[0025] The API execution acceptance unit 29 measures, as a count value, the number of accepted API calls by the user 16 per unit time. If the count value has not reached the API upper limit value, it accepts the API call. If the count value has reached the API upper limit value, as burst mode, it controls the acceptance of API calls from the user 16 based on the burst time. The detailed processing will be described later.

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

[0027] In step 101, the contract plan acceptance unit 22 presents a plurality of predetermined contract plans to the user 16 and prompts for selection.

[0028] Figure 4 is a diagram showing a list of contract plans.

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

[0030] In step 102, the contract plan reception unit 22 determines the contract plan used by each user 16 based on the selection of each user 16.

[0031] 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 the user 16.

[0032] In step 104, the user management unit 21 creates a user table that manages all users 16 who share the resource 12 in the multi-tenant type service.

[0033] FIG. 5 is a diagram showing the user table. In the user table, the user name, API upper limit value, API upper limit value ratio, and API actual ratio of each user are registered. The user with the user name "Hitachi" has contracted the contract plan "Pine" shown in FIG. 4. The user with the user name "Ikeda" has contracted the contract plan "Bamboo" shown in FIG. 4. The user with the user name "Totsuka" has contracted the contract plan "Plum" shown in FIG. 4. The user with the user name "Yoshida" has contracted the contract plan "Budget" shown in FIG. 4.

[0034] As described above, the API upper limit value ratio is the ratio of the API upper limit value of each user to the total of the API upper limit values of all users. For example, in FIG. 5, the API upper limit value ratio of the user with the user name "Hitachi" is calculated by the formula (1).

[0035] API upper limit value ratio (Hitachi) = 100 times / (100 + 60 + 40) = 50% …(1)

[0036] The API actual ratio is the ratio of the number of times the API is called by the user 16 to the total number of times the API is called by all users 16. At the stage when the user table is created, no numerical value is entered in the API actual ratio.

[0037] Returning to FIG. 3, at step 105, the priority determination unit 24 calculates the burst time of each user 16.

[0038] As described above, the burst time is the time obtained by allocating unit time according to the ratio of the API upper limit value of each user 16 to the total of the API upper limit values of all users 16 (that is, the API upper limit value ratio). For example, in FIG. 5, the burst time of the user whose user name is "Hitachi" is calculated by Equation (2).

[0039] Burst time (Hitachi) = 1 second × (API upper limit value ratio (Hitachi)) = 0.2 seconds... (2)

[0040] At step 106, the priority determination unit 24 determines the priority for applying the burst mode of each user 16, and creates a priority table indicating the priority in the processing for the API call of each user 16.

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

[0042] FIG. 6 is a diagram showing the priority table. In the priority table, a numerical value indicating the priority and the user name of the user corresponding to the priority are recorded. For example, the priority of the user whose user name is "Hitachi" is "1", and the priority of the user whose user name is "Ikeda" is "2".

[0043] FIG. 7 is a flowchart of the API reception process. The API reception process is executed by the queue registration unit 26.

[0044] At step 201, the queue registration unit 26 acquires the API call received from the user 16, and at step 202, acquires the time when the API call is received. Hereinafter, the time when the API call is received may be referred to as the reception time.

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

[0046] 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.

[0047] FIG. 8 is a diagram showing a database. In the database, for each API call, an identifier, a user name, a process name, a reception time, and a start time are recorded. The identifier is identification information for individually identifying the API call. The user name is information indicating the user 16 who sent the API call. The process name is a process name indicating the process called and executed by the API call. The reception time is the reception time of the API call. The start time is the time when the process by the API call starts. At the stage when the API call is registered in the database, the start time is not recorded.

[0048] In the DB queue 27, the API calls received from each user 16 are recorded in the order in which they are received. The configuration of the DB queue 27 is not particularly limited, but it is configured to be able to specify the order in which API calls are received for each user 16. For example, the DB queue 27 may be composed of individual queues for each user 16. Also, for example, the DB queue 27 may be used in common with the database, provided commonly for a plurality of users 16, and recorded together with information (for example, user name) that can identify the user 16 who sent each API, and may be configured to be able to extract the API calls of a 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 the identifier 1003 may be extracted before the API call with the identifier 1001.

[0049] FIG. 9 is a flowchart of priority processing. The priority processing is a process for determining a user to whom the burst mode is preferentially applied. The priority processing is executed by the user management unit 21.

[0050] In step 301, when a predetermined condition is satisfied, the user management unit 21 advances the current pointer of the priority table by one. The predetermined conditions include that the burst time of the current priority target user has expired and that there are no more API calls for the current priority target user.

[0051] In step 302, the user management unit 21 identifies the new priority target user pointed to by the current pointer of the priority table.

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

[0053] FIG. 10 is a flowchart of the API call reception process. The API call reception process prioritizes the priority target users and is executed for the user 16 for whom a signal has been sent. Here, the user 16 to be processed is referred to as user A. The API call reception process is executed by the API execution reception unit 29 of the API control unit 25.

[0054] The API execution reception unit 29 measures the number of received API calls for each user 16 including user A every unit time. Hereinafter, the number of received API calls may be referred to as the API call count.

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

[0056] In the determination of step 402, if the number of API calls made by user A has reached the upper limit value of user A, the API execution reception unit 29 determines, in step 405, whether only the API calls made by user A are being performed within the burst time. If only the API calls made by user A are being performed within the burst time, the API execution reception unit 29 accepts the API calls made by user A in step 406 and proceeds to step 404.

[0057] In the determination of step 405, if not only the API calls made by user A are being performed within the burst time, the API execution reception unit 29 determines, in step 407, whether the total amount of data generated by the processing of the API calls made by user A and not yet written to the blockchain has reached the size of the blockchain block. The size of the blockchain block may be referred to as the block size below. If the total amount of data generated by the processing of the API calls made by user A and not yet written to the blockchain has not reached the block size, the API execution reception unit 29 proceeds to step 406. In step 406, the API calls made by user A are accepted, and the data generated by the called processing is written to the block together with the data not yet written to the blockchain.

[0058] If the total amount of data generated by the processing of the API calls made by user A and not yet written to the blockchain has reached the block size, the API execution reception unit 29 suspends the acceptance of API calls for a predetermined recovery time and then resumes, and proceeds to step 403. The recovery time is a system parameter indicating the time to suspend and wait for the acceptance of API calls exceeding the API upper limit value, and the API execution reception unit 29 determines this in advance.

[0059] In this embodiment, until the burst time according to the API upper limit value and the fee linked to the contract plan of each user, the API processes in burst mode exceeding the upper limit value of the number of APIs are performed, and control is performed so that data writing is performed in a lump sum to the blocks of the blockchain as much as possible. Since the call of the API exceeding the API upper limit value is accepted until the burst time determined according to the API upper limit value, a sense of fairness is given to the user. In addition, since data is written to the blockchain in block sizes, the number of occurrences of the write process can be reduced.

[0060] The present embodiment described above includes the following matters. However, the matters included in the present embodiment are not limited to those shown below.

[0061] (Matter 1) In a multi-tenant type service that executes data processing of a plurality of users by resources shared by the plurality of users on the cloud, a management device that receives a call for data processing from the user and executes the data processing by the resources, A user management unit that presets, for each user, an upper limit value of the number of calls for data processing per unit time and a burst time that is a time during which calls for data processing can be received exceeding the upper limit value, The number of accepted calls for data processing by the user per unit time is measured as a count value, and if the count value has not reached the upper limit value, the data processing is accepted, and if the count value has reached the upper limit value, based on the burst time, a data processing control unit that controls the acceptance of calls for data processing from the user, having The data processing control unit If the count value has reached the upper limit value, as burst mode, during the burst time If there is no other user with a call for data processing among the plurality of users sharing the resources, the data processing is accepted, Among the multiple users who share the resource, if there are other users with data processing calls, if the data resulting from the data processing of the user has not reached a predetermined data size, accept the data processing, if the data resulting from the data processing of the user has reached the data size, wait for a predetermined recovery time and then accept the data processing. Management device.

[0062] According to this, if the count value of the data processing has reached the upper limit value and there are no other users who are accepting data processing calls within the burst time, accept the data processing. Even if there are other users who are accepting data processing calls within the burst time, if the data resulting from the user's data processing has not reached a predetermined data size, accept the data processing. As a result, it is possible to achieve suitable resource allocation on the cloud in a multi-tenant type service.

[0063] (Item 2) The multi-tenant type service is a service that stores the data of the multiple users by means of a blockchain, the data size is determined based on the size of the block of the blockchain, the data processing control unit collects the data generated by executing the data processing on the resource into the block and records it in the blockchain. The management device according to Item 1.

[0064] According to this, it is possible to achieve suitable resource allocation on the cloud in consideration of the nature of the blockchain. Since data writing in the blockchain is performed in units of blocks of a predetermined size, by collecting small data into blocks, the number of writing times and the number of data to be written can be reduced.

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

[0066] According to this, resources on the cloud can be suitably allocated in units of API calls.

[0067] (Item 4) The user management unit generates in advance a priority table indicating the priority order in the data processing of each user according to the ratio of the upper limit value of each user to the total of the upper limit values of the plurality of users, sets a current pointer indicating a priority target user that prioritizes acceptance of the data processing in the priority table, causes the data processing control unit to apply the burst mode preferentially to the priority target user, when the burst time has elapsed, or when there is no more call for data processing of the priority target user, advances the current pointer to the next user in the priority table. The management device according to item 1.

[0068] According to this, it is possible to realize a process of allocating resources according to the priority order based on the ratio of the given upper limit value.

[0069] (Item 5) The upper limit value is determined by the contract plan of the multi-tenant type service used by the user, the user management unit sets the burst time of each user according to the ratio of the upper limit value of each user to the total of the upper limit values of the plurality of users. The management device according to item 1.

[0070] According to this, since data processing in burst mode exceeding the upper limit value is accepted with a burst time according to the ratio of the upper limit value determined by the contract plan, a sense of fairness can be given to the user.

[0071] (Item 6) The data processing control unit enqueues the data processing calls made by the user into a call queue for each user, if the count value has not reached the upper limit value, dequeues and accepts the data processing from the call queue, if the count value has reached the upper limit value, if there is no other user among the plurality of users who has accepted the data processing call within the burst time, dequeues and accepts the data processing from the call queue, if there is another user among the plurality of users who has accepted the data processing call within the burst time, if the data by the user's data processing has not reached the data size, dequeues and accepts the data processing from the queue, if the data by the user's data processing has reached the data size, stops accepting the data processing call. The management device according to Item 1.

[0072] According to this, since the data processing is managed and processed by a queue, even when real-time processing is not possible, a suitable resource allocation for the data processing can be achieved.

[0073] (Item 7) The data processing control unit predetermines a recovery time, which is the time to stop accepting the data processing calls exceeding the upper limit value and wait, if the count value has reached the upper limit value, there is another user among the plurality of users sharing the resource who has accepted the data processing call within the burst time, and the data by the user's data processing has reached the data size, stops accepting the data processing call for the recovery time. The management device according to Item 1.

[0074] According to this, the process of resource allocation can be operated with an appropriate recovery time.

[0075] (Item 8) The management device is composed of a plurality of gateways provided for each user and accepting calls for data processing from the user. The gateway is constructed on the cloud. The management device according to Item 1.

[0076] In addition, the above-described embodiments of the present invention are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. A person skilled in the art can implement the present invention in various other modes without departing from the scope of the present invention.

Explanation of Signs

[0077] 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 value determination unit, 24... Priority determination unit, 25... API control unit, 26... Queue registration unit, 27... Database queue, 28... Queue extraction unit, 29... API execution reception unit

Claims

1. In a multi-tenant service that executes data processing of a plurality of users by resources shared by the plurality of users on the cloud, a management device that receives a data processing call from the user and causes the resources to execute the data processing, A user management unit that presets, for each user, an upper limit value of the number of data processing calls per unit time and a burst time that is a time during which data processing calls can be received beyond the upper limit value; A data processing control unit that measures, as a count value, the number of received data processing calls by the user per unit time, accepts the data processing if the count value has not reached the upper limit value, and controls acceptance of data processing calls 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 value, as burst mode, during the burst time, If there is no other user with a data processing call among the plurality of users sharing the resources, accept the data processing, If there is another user with a data processing call among the plurality of users sharing the resources, If the data by the user's data processing has not reached a predetermined data size, accept the data processing, If the data by the user's data processing has reached the data size, wait for a predetermined recovery time and then accept the data processing. Management device.

2. The multi-tenant service is a service that stores the data of the plurality of users by a blockchain, The data size is determined based on the size of a block of the blockchain, The data processing control unit collects the data generated by executing the data processing on the resource into the block and records it in the blockchain. The management device according to claim 1.

3. The data processing is processing by an application programming interface. The management device according to claim 1.

4. The user management unit generates in advance a priority table indicating the priority order in the data processing of each user according to the ratio of the upper limit value of each user to the total of the upper limit values of the plurality of users, sets a current pointer indicating a priority target user who gives priority to receiving the data processing in the priority table, causes the data processing control unit to apply the burst mode preferentially to the priority target user, when the burst time expires, or when there is no more call for the data processing of the priority target user, advances the current pointer to the next user in the priority table. The management device according to claim 1.

5. The upper limit value is determined by the contract plan of the multi-tenant type service used by the user, The user management unit sets the burst time of each user according to the ratio of the upper limit value of each user to the total of the upper limit values of the plurality of users. The management device according to claim 1.

6. The data processing control unit enqueues the call for data processing by the user into a call queue for each user, if the count value has not reached the upper limit value, dequeues the data processing from the call queue and accepts it, if the count value has reached the upper limit value, If there is no other user among the plurality of users who has received a call for data processing within the burst time, dequeue and accept the data processing from the call queue. If there is another user among the plurality of users who has received a call for data processing within the burst time, If the data by the user's data processing has not reached the data size, dequeue and accept the data processing from the queue. If the data by the user's data processing has reached the data size, stop accepting calls for data processing. The management device according to claim 1.

7. The data processing control unit Predetermines a recovery time, which is the waiting time for stopping and waiting for accepting calls for data processing exceeding the upper limit value. If the count value has reached the upper limit value, there is another user among the plurality of users sharing the resource who has received a call for data processing within the burst time, and the data by the user's data processing has reached the data size, stop accepting calls for data processing for the recovery time. The management device according to claim 1.

8. The management device is composed of a plurality of gateways provided for each user to receive calls for data processing from the user. The gateway is constructed on the cloud. The management device according to claim 1.

9. In a multi-tenant service that executes data processing of the plurality of users by a resource shared by a plurality of users on the cloud, a management method for receiving a call for data processing from the user and causing the resource to execute the data processing, A computer For each of the users, set in advance an upper limit value for the number of calls for data processing per unit time and a burst time, which is the time during which calls for data processing can be accepted exceeding the upper limit value. Measure, as a count value, the number of accepted calls for data processing by the user per unit time. If the count value has not reached the upper limit value, accept the data processing. If the count value has reached the upper limit value, then, in burst mode, during the burst time If there is no other user with a call for data processing among the plurality of users sharing the resource, accept the data processing. If there is another user with a call for data processing among the plurality of users sharing the resource If the data by the user's data processing has not reached a predetermined data size, accept the data processing. If the data by the user's data processing has reached the data size, wait for a predetermined recovery time and then accept the data processing. A management method for performing the above.

10. In a multi-tenant service that executes data processing of a plurality of users by a resource shared by the plurality of users on the cloud, a management program for accepting a call for data processing from the user and causing the resource to execute the data processing, On a computer, For each of the users, set in advance an upper limit value for the number of calls for data processing per unit time and a burst time, which is the time during which calls for data processing can be accepted exceeding the upper limit value. Measure, as a count value, the number of accepted calls for data processing by the user per unit time. If the count value has not reached the upper limit value, accept the data processing. If the count value has reached the upper limit value, then, in burst mode, during the burst time If there are no other users with data processing calls among the multiple users sharing the resource, accept the data processing. If there are other users with data processing calls among the multiple users sharing the resource, If the data resulting from the user's data processing has not reached a predetermined data size, accept the data processing. If the data resulting from the user's data processing has reached the data size, wait for a predetermined recovery time and then accept the data processing. A management program for causing this to be executed.

Images