WO2020045269A1 - システム、情報処理方法、及びプログラム - Google Patents

システム、情報処理方法、及びプログラム Download PDF

Info

Publication number
WO2020045269A1
WO2020045269A1 PCT/JP2019/032996 JP2019032996W WO2020045269A1 WO 2020045269 A1 WO2020045269 A1 WO 2020045269A1 JP 2019032996 W JP2019032996 W JP 2019032996W WO 2020045269 A1 WO2020045269 A1 WO 2020045269A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
object storage
execution
unit
data
Prior art date
Application number
PCT/JP2019/032996
Other languages
English (en)
French (fr)
Inventor
光央 戀川
Original Assignee
ｔｏｎｏｉ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ｔｏｎｏｉ株式会社 filed Critical ｔｏｎｏｉ株式会社
Priority to US17/270,182 priority Critical patent/US11379202B2/en
Priority to JP2020539410A priority patent/JPWO2020045269A1/ja
Publication of WO2020045269A1 publication Critical patent/WO2020045269A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/451—Code distribution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/47—Retargetable compilers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Definitions

  • the present invention relates to a system, an information processing method, and a program.
  • the present invention relates to a system, an information processing method, and a program capable of directly executing arithmetic logic on various storages.
  • a load balancing system that includes a plurality of computers and distributes a job to a plurality of computers and executes the job, a storage accessed by the plurality of computers to execute the job, and a computer with a low load among the plurality of computers.
  • a first management device for executing a job a second management device for receiving a plurality of jobs, queuing the plurality of received jobs, and sequentially storing the queued jobs in a first job queue;
  • a third management device that sequentially retrieves jobs from the job queue of the storage device and executes processing for data necessary for executing the jobs retrieved by the computer to the storage device;
  • a second job queue for sequentially storing the jobs as waiting jobs to be executed by the first management device, wherein the first management device Removed from the queue a plurality of jobs in sequence, load distribution system for executing the job taken out in the computer is known (for example, see Patent Document 1.).
  • load distribution system described in Patent Literature 1 it is possible to reduce the processing time for executing a job by making the most of the computing function.
  • the data processing efficiency is reduced depending on the data division size of the processing target. For example, in a conventional load balancing system, data is supplied from the storage to the processor of the computer, and the job is executed.Therefore, when using data divided into several kilobytes, large continuous data of several gigabytes or more is used. Then, the data processing efficiency is greatly reduced.
  • an object of the present invention is to provide a system and an information processing method capable of directly executing data processing on various types of storage in order to prevent a reduction in data processing efficiency when using a large amount of continuous data of several gigabytes or more. And programs.
  • the present invention comprises a user application stored in an object storage and having a predetermined arithmetic logic in a source code, and causing at least one of a plurality of heterogeneous devices to execute the arithmetic logic.
  • System for performing predetermined processing on predetermined data by using a source acquisition unit for acquiring a source code and a predetermined API (Application ⁇ Programming ⁇ Interface) to specify an arithmetic logic from the source code.
  • a correspondence table creation unit that creates a processor correspondence table that associates the path to the execution image in the designated processor stored in the image storage with the designated processor and stores the image in the object storage.
  • a system provided with a correspondence determination unit that stores, in the object storage, a correspondence relationship in which the calculation logic supplied by the calculation logic supply unit is associated with a storage path of a processor correspondence table stored in the object storage. .
  • data processing is directly executed on various types of storage in order to prevent a reduction in data processing efficiency when using a large amount of continuous data of several gigabytes or more.
  • FIG. 1 is a schematic diagram of an architecture of a system according to an embodiment. It is a functional configuration block diagram of a system according to the present embodiment.
  • FIG. 3 is a schematic diagram of a configuration of a user application, a processor correspondence table, and a correspondence relationship according to the embodiment.
  • FIG. 4 is a flowchart of a process in the system according to the embodiment.
  • FIG. 4 is a flowchart of a process in the system according to the embodiment.
  • FIG. 4 is a flowchart of a process in the system according to the embodiment.
  • (A) is a schematic diagram of a conventional calculation of Apache @ Spark
  • (b) is a schematic diagram of a calculation in a system according to another example of the present embodiment.
  • the present inventor changed his mind and came to think that the data supply direction (that is, the routine or job supply direction) was reversed.
  • a data processing efficiency can be improved by supplying a routine or a job from a user application to a predetermined computer, supplying the routine or the job from the computer to a storage, and directly processing the routine or the job on the storage.
  • the system according to the present invention has a configuration in which an execution code of a routine for handling data in a user application is supplied to an IO controller on a storage, and data processing is directly executed on the storage. This is a system in which distributed processing is performed simultaneously on both the edge and the edge where the routine is executed.
  • the intermediate code is used.
  • the execution code for the predetermined data processing can be generated in the cloud (the execution code can be stored in the cloud).
  • a job routine for storage) can be extracted from a user application on the cloud, and data processing can be directly executed on the storage.
  • the arithmetic logic can be executed by one device because the machine language differs depending on the type of the device. Even if it can be executed on other devices, it is not always possible. Therefore, conventionally, virtual hardware is defined, and the arithmetic logic is compiled into an intermediate code to be executed by the virtual hardware so that the arithmetic logic operates on a heterogeneous device. That is, the processors of various heterogeneous devices implement a virtual machine that implements virtual hardware, read intermediate code by the virtual machine, and execute arithmetic logic.
  • the processing speed is reduced by the amount of passing through the virtual machine. Therefore, in the conventional method, the processing speed is increased by using a specific compiler (for example, a Just-in-time (JIT) compiler) that converts all of the intermediate code into machine language for the processor before executing the arithmetic logic. Is faster.
  • a specific compiler for example, a Just-in-time (JIT) compiler
  • JIT Just-in-time
  • the arithmetic logic when using a user application having predetermined arithmetic logic in the source code, the arithmetic logic is held in the cloud as the source code, and the processor of a plurality of devices is used.
  • an execution image is created in advance by compiling arithmetic logic for a plurality of devices, the created execution image is saved in the cloud, and the execution image stored when an execution instruction of the arithmetic logic is given. Can be downloaded to the device and executed.
  • the system 1 according to the present embodiment in which the data supply direction is reversed from the conventional format, includes the user application stored in the object storage and having the predetermined arithmetic logic in the source code, This is a system that allows at least one of a plurality of devices to execute arithmetic logic and perform predetermined processing on predetermined data. Then, the system 1 according to the present embodiment creates an execution image by holding the operation logic as it is in the source code and compiling the operation logic for the plurality of devices in each of the processors of the plurality of devices. The execution image is stored in the object storage, and when the arithmetic logic is called by one of the plurality of devices, the execution image created for the one device is supplied from the object storage to the one device. This is a system to be executed (hereinafter, may be referred to as an “execution image supply system”).
  • the arithmetic processing can be executed directly on the storage, so that the data processing efficiency is greatly improved as compared with the conventional technology. Can be done. Further, according to the system 1, the processing speed is greatly improved because the processing does not pass through the virtual machine. Further, according to the system 1 according to the present embodiment, for example, since the overhead in Java (registered trademark) or the like can be eliminated, the processing speed can be further improved, and the functions of the hardware are fully utilized. You can also.
  • FIG. 1 shows an example of an outline of a system architecture according to an embodiment of the present invention.
  • FIG. 2 shows an example of an outline of a functional configuration of the system according to the embodiment of the present invention.
  • a system 1 includes a proxy system 2, a stub system 3, and a system 1 stored in an object storage 400 (specifically, a proxy system 2).
  • a user application 600 that is called by a user, and allows at least one of a plurality of heterogeneous devices 5 to execute arithmetic logic and perform predetermined processing on predetermined data.
  • the user application 600 has a predetermined arithmetic logic in a source code.
  • the devices 5 are, for example, various storage devices, recording devices (that is, storages), and IO controllers that control peripheral devices by connecting them to a control unit or a processor.
  • Examples of the user application 600 include applications that perform various processes, such as various utility applications, various calculation applications, still image and moving image image processing applications, and programming applications.
  • the proxy-side system 2 has a control unit 50, and has a function of measuring or estimating the amount of memory consumed in the stub-side system 3 (consumption memory measurement / estimation function) and a plurality of heterogeneous functions.
  • a function conversion processing function of storing an execution image obtained by supplying a predetermined arithmetic logic to each processor of each device and compiling the same in the object storage 400 or GPGPU @ SaaS410, and an execution image of any one of the plurality of devices.
  • the user application 600 read by the proxy-side system 2 is subjected to processing such as specification of an arithmetic logic by a predetermined Application / Programming / Interface (API) 100.
  • the system 1 can also convert the arithmetic logic into a format that can be executed by the control unit 50 by using languages such as SYCL and OpenCL.
  • the object storage 400 and GPGPU @ SaaS 410 are Public @ PaaS4.
  • the stub-side system 3 has a function of receiving information from the proxy-side system 2 (reception processing function), a function of managing storage (storage function), and a function of preparing an environment in which arithmetic logic is executed (memory management). Function) and a function (URI management function) of managing Uniform ⁇ Resource ⁇ Identifier (URI).
  • the stub-side system 3 executes the operation logic based on the information received from the proxy-side system 2 (for example, a device such as ARM @ Mali, FPGA, Xeon @ Phi, nVidia @ GPU, etc. Information is received from the stub-side system 3 via the stub-side system).
  • the stub-side system 3 uses OpenCL, Ceph, RADOS, and the like based on the execution image received by the reception processing function to execute processing based on arithmetic logic in the execution destination device. Is executed.
  • An example of an execution destination device is an SSD.
  • the SSD is controlled by the SSD @ Controller 20.
  • the SSD can supply a calculation result or the like to a logical device based on NVM @ Express (NVMe30).
  • the proxy system 2 and the stub system 3 can exchange data with each other, for example, by using distributed storage software (Ceph12).
  • a plurality of routines operate by passing a physical address called a pointer and sharing or using data on a Dynamic Random Access Memory (DRAM) between the plurality of routines. . Therefore, it is necessary to transfer data in the lower layer of the memory hierarchy, such as Solid State Drive (SSD), once to the DRAM.
  • SSD Solid State Drive
  • the conventional method cannot secure a sufficient transfer speed, and the data transfer to the DRAM is a bottleneck in data processing.
  • the system 1 includes a control unit 50 and a storage unit (for example, a DRAM, an SSD, or the like) that stores data at an address indicated by a data position (for example, a physical address, an address of various storage units, or an IO controller number). , And an object storage 400).
  • a storage unit for example, a DRAM, an SSD, or the like
  • data position for example, a physical address, an address of various storage units, or an IO controller number.
  • a URI in which a predetermined scheme and a resource in a format defined for each scheme after a predetermined delimiter (for example, “:” (colon)) are used is used.
  • a predetermined delimiter for example, “:” (colon)
  • the position of the data that can be processed by the control unit 50 is “extended” by changing or replacing the pointer indicating the data position inside the computer from the physical address to the URI.
  • the URI is used instead of the data position.
  • the pointer is a tag used when the computer program transfers the position of data to be processed between routines.
  • Control unit 50 The control unit 50 controls various data processing in the proxy system 2 of the system 1.
  • the control unit 50 acts on the storage unit to transfer and process data stored in the storage unit and control a predetermined application (for example, the user application 600).
  • the control unit 50 includes, for example, a logic circuit of a Central Processing Unit (CPU).
  • CPU Central Processing Unit
  • the control unit 50 controls and activates a predetermined application specified by the scheme associated with the URI. Then, the control unit 50 passes the URI resource to the application. Subsequently, the application controls the data specified by the URI and stored in the storage unit, using the URI as the data position based on the resource. Note that the control unit 50 can also control and activate a plurality of applications based on the scheme associated with the URI.
  • the URI is an identifier indicating a resource in a predetermined format.
  • a resource for enabling access by the control unit 50 or an application can be indicated in consideration of a case where target data does not exist in the system 1.
  • the URI is described, for example, in the format of “scheme /// resource”, and the resource is described in a format defined for each scheme.
  • resources include, for example, “disk number, directory, file, and seek where target data exists”, “DRAM memory address where target data exists”, “response when target data does not exist, Retry, callback ”and the like.
  • the storage unit is provided so as to store predetermined data at a data position in a predetermined format.
  • various storage media can be used as long as the storage unit has a function of storing various data.
  • a register a cache, a dynamic random access memory (DRAM), a video memory, a solid state drive (SSD), and a hard disk
  • An optical recording medium such as a drive (HDD), a tape drive, a compact disc (CD) and a digital versatile disc (DVD), a magneto-optical recording medium, and a magnetic recording medium.
  • the storage unit may be a storage unit on the cloud, and may be an object storage that has no restriction on the storage of the data size and the number of data, is suitable for storing large-capacity data, and stores data in object units. Different data positions are assigned to these storage units.
  • a data position is specified by using a physical address.
  • a data position is specified by a register name or a number.
  • a data position is specified by an address counted from the beginning along the permutation.
  • a data position is specified by an address counted from the beginning along a permutation.
  • the designation of the data position is physically different from the cache.
  • the system 1 includes a storage unit in which data is specified by a URI. Then, the control unit 50 activates an application corresponding to the scheme associated with the URI, and the resource of the URI is passed to the activated application. The application then converts the URI to a data location based on the passed resource. This allows direct and unified control of the storage unit by the control unit 50, regardless of the type of storage unit.
  • a conventional CPU directly controls registers, caches, and even DRAMs. Further, the conventional CPU cannot directly control the storage unit below the SSD in the memory hierarchy. Since the transfer speed in the path for transferring data from the DRAM to the SSD is lower than the transfer speed in the storage unit above the DRAM in the memory hierarchy, no matter how fast the data transfer or the like in the DRAM or higher, the transfer from the DRAM to the SSD can be performed. Data transfer becomes a bottleneck in terms of transfer speed. This is because a conventional computer uses a different format for each storage unit and specifies a data position by a physical address.
  • the system 1 uses URIs as pointers instead of physical addresses. Therefore, the SSD or the like as a lower storage unit can be directly controlled by the control unit 50 from the DRAM.
  • the range accessible by the instruction of the control unit 50 is a register, a cache, a DRAM, and an IO controller of an IO channel. And so on. Then, the control unit 50 controls the values such as the data position held in the IO controller of the register, the cache, the DRAM, and the IO channel, and the numerical value held in the IO controller is rewritten by the control unit 50.
  • the storage unit such as the SSD, HDD, and tape drive from the IO controller is directly controlled by the control unit 50.
  • the DRAM can be handled not as a data transfer destination / shared location but as a cache having a larger capacity than the cache, so that the data processing speed in the system 1 can be greatly improved.
  • control unit 50 refers to, for example, a URI of predetermined data stored in the object storage 400 and activates an application specified by the scheme associated with the URI.
  • the control unit 50 passes the resource after the URI delimiter to the application.
  • the application uses the URI as a data location instead of the physical address based on the resource, and accesses the data stored in the storage specified by the URI.
  • access to the SSD or the like using the URI can be centrally managed by the control unit 50.
  • the SSD control routine For example, if the application started by the control unit 50 is the SSD control routine, the SSD control routine generates the physical address of the SSD controller device and the physical address of the SSD memory space on the SSD controller based on the resources. Thereby, the control unit 50 can control the SSD.
  • the application can also specify data stored in each of the plurality of storage units based on the URI. That is, the application is controlled by the control unit 50, and uses the URI to uniformly handle each of the plurality of data stored in the plurality of storage units at the positions and addresses designated by the different physical addresses. You can also. Thereby, according to the system 1 according to the present embodiment, the designation of the data position among the plurality of storage units can be extended by the URI, and as a result, it can be handled uniformly.
  • the system 1 As shown in FIG. 2, the system 1 according to the present embodiment generally includes a proxy-side system 2 and a stub-side system 3.
  • the system 1 stores predetermined information in an object storage 400 outside the system 1.
  • the system 1 can cause the predetermined device 5 to execute the predetermined processing. That is, the system 1 includes a user application stored in the object storage 400 and having a predetermined operation logic in a source code.
  • the system 1 causes at least one of a plurality of heterogeneous devices 5 to execute the operation logic and execute a predetermined operation logic. This is a system that can perform predetermined processing on data.
  • the device 5 has one or more processors 500 that control the operation of the device 5.
  • the proxy system 2 is a system that performs a predetermined process on a predetermined user application before compiling the same with a generally used compiler.
  • the proxy system 2 includes a source acquisition unit 200 that acquires a source code, an operation logic identification unit 202 that identifies an operation logic in the source code, a device management unit 204 that manages one or more devices 5, and an operation logic.
  • a storage integrated management unit 206 that executes processing related to data access by the CPU, an operation logic supply unit 208 that supplies operation logic to one or more devices 5, a path to an execution image, and a processor 500 on which the execution image is executed.
  • a correspondence table creation unit 210 that creates a processor correspondence table that associates the processor correspondence table, a correspondence relationship determination unit 212 that determines a correspondence relationship that associates a storage path of the processor correspondence table with an operation logic that uses the processor correspondence table, Execution context creation unit 214 for creating the execution context
  • a transmission processing unit 216 supplies the predetermined information to the stub side system 3, and a control unit 50 for controlling the operation of each configuration of the proxy-side system 2.
  • the source acquisition unit 200 acquires the source code of a predetermined application (for example, the user application 600).
  • the predetermined application is stored in the object storage 400
  • the source obtaining unit 200 obtains the source code of the predetermined application from the object storage 400. That is, the source code is stored in the object storage 400, that is, the cloud, and the source acquisition unit 200 acquires the source code from the cloud.
  • the application has an arithmetic logic in the source code.
  • the source acquisition unit 200 reads the source code of a predetermined application, and supplies the read source code to the arithmetic logic specifying unit 202.
  • the arithmetic logic specifying unit 202 calls a predetermined API (Application Programming Interface), and the API specifies the arithmetic logic from the source code.
  • the operation logic is preferably used for distributed processing.
  • the device management unit 204 checks whether the processor 500 specified based on the source code is an available processor that can be used in the system 1. That is, the device management unit 204 confirms whether or not the processor 500 specified by the source code is a processor that has been supported in the system 1. The device management unit 204 supplies the confirmation result to the arithmetic logic supply unit 208.
  • the storage integrated management unit 206 confirms whether or not there is an access to other data except predetermined data from the operation logic specified by the operation logic specifying unit 202. For example, the storage integrated management unit 206 checks whether or not an invalid URI syntax exists in the specified operation logic. Further, the storage integrated management unit 206 can confirm whether or not the access right to the data to be accessed exists in the system 1. In this case, the storage integrated management unit 206 permits only the data to which the access right exists in the system 1 from the arithmetic logic to access the data.
  • the device management unit 204 uses the processor 500 specified based on the source code that can be used in the system 1. Perform a check to see if it is a possible processor.
  • FIG. 3 shows an example of an outline of a configuration of a user application, a processor correspondence table, and a correspondence relationship according to the present embodiment.
  • the user application 600 is configured to have a source code including one or more operation logics (for example, operation logic a, operation logic b, and the like).
  • the source code can also include data to be accessed by the arithmetic logic, and information specifying or specifying the device 5 or the processor 500 on which the arithmetic logic is executed.
  • the operation logic supply unit 208 supplies the operation logic to the compiler of the processor 500 specified based on the source code. More specifically, when the device management unit 204 confirms the existence of an available processor (that is, when the specified processor 500 is confirmed to be an available processor), the arithmetic logic supply unit 208 Supply arithmetic logic in source code to available processor.
  • a plurality of processors 500 may be specified based on the source code. That is, a plurality of devices 5 may be specified based on the source code.
  • the arithmetic logic supply unit 208 supplies arithmetic logic to each of the compilers of the plurality of designated processors.
  • the processor 500 supplied with the operation logic compiles the received operation logic by using a compiler included in the processor 500. Compilation by the compiler of the processor 500 is executed on the cloud. Then, the processor 500 stores the compiled result in the object storage 400 as an execution image.
  • each of the plurality of processors compiles the received arithmetic logic and stores each execution image as a result of the compilation in the object storage 400.
  • a conventionally known compiler can be used as the compiler of the processor.
  • the execution image can be created by using, for example, Kernel @ Image of OpenCL.
  • Correspondence table creation unit 210 When the object storage 400 stores, as an execution image, the result compiled by the compiler of the processor 500 specified based on the source code, the correspondence table creation unit 210 stores the specified data stored in the object storage 400. A processor correspondence table 610 that associates a path to an execution image in the processor 500 with the specified processor is created.
  • the processor correspondence table 610 includes, for each operation logic, one or more processors and a path to an execution image that is a result compiled by a compiler of each processor.
  • the object storage 400 stores data relating to this table as a processor correspondence table 610.
  • the path A to the execution image compiled and created by the compiler of the processor A is associated with the processor A to which the arithmetic logic a is supplied (processor B, processor C, and processor B). ... and so on.).
  • the correspondence table creation unit 210 stores the created processor correspondence table in the object storage 400.
  • the processor correspondence table 610 may be a separate table for each operation logic or may be the same table.
  • the correspondence determination unit 212 associates the operation logic supplied by the operation logic supply unit 208 with the storage path of the processor correspondence table stored in the object storage 400 and corresponding to the operation logic.
  • the correspondence 620 indicates that the operation logic has a storage path to the processor correspondence table 610 that stores a path to an execution image created in the processor to which the operation logic has been supplied. It is a table associated with each other.
  • the storage path A to the processor correspondence table is associated with the arithmetic logic a (the same applies to other arithmetic logics such as the arithmetic logic b).
  • the execution context creating unit 214 creates an execution context to be executed in the operation logic.
  • the object storage 400 stores device information on a plurality of heterogeneous devices in advance.
  • the device information is, for example, information on the position and type of the device, the type of the processor 500, and the like.
  • the user application 600 specifies data to be accessed by the calculation logic of the user application 600 and specifies a device on which the calculation logic is executed.
  • the execution context creating unit 214 creates an execution context based on the specified data.
  • the storage integrated management unit 206 determines whether the system 1 has the access right to the specified data, that is, the data requested to be accessed. Is confirmed, and if there is an access right, the designation of the data is permitted.
  • the device management unit 204 acquires device information on the device specified by the user application 600 from the object storage 400 and specifies the target processor on which the data processing is executed.
  • the execution context creating unit 214 refers to the processor correspondence table and the correspondence stored in the object storage 400, and executes the execution image associated with the target processor in the processor correspondence table associated with the operation logic. The path to to the execution context. As a result, the execution context creating unit 214 creates an execution context to be provided to the outside.
  • Transmission processing unit 216 When the user application 600 instructs the execution of the arithmetic logic, the transmission processing unit 216 writes the execution context in which the path has been written to the storage queue in order to supply the execution context to the outside (that is, the stub-side system 3). The transmission processing unit 216 supplies the execution context to the stub-side system 3 via the storage queue.
  • the stub-side system 3 causes a predetermined device 5 to execute a predetermined process based on the execution context supplied from the proxy-side system 2. Note that the result of the executed processing can be stored in the object storage 400.
  • the stub-side system 3 includes a reception processing unit 300 that receives predetermined information from the proxy-side system 2, a memory management unit 302 that manages a physical memory, an execution image acquisition unit 304 that acquires an execution image, and an arithmetic logic. It has an operation logic execution unit 306 to be executed, a result storage execution unit 308 that stores the result of the operation logic in the object storage 400, a URI management unit 310 that manages URIs, and a storage function management unit 312 that manages storage functions. .
  • the reception processing unit 300 receives the execution context in which the path is written from the transmission processing unit 216. Further, the reception processing unit 300 decodes the received execution context.
  • the memory management unit 302 prepares an execution environment such as a physical memory in which the arithmetic logic is executed based on the device information in the execution context decoded by the reception processing unit 300.
  • Executiution image acquisition unit 304 acquires an execution image from the object storage 400 based on the path to the execution image in the execution context decrypted by the reception processing unit 300. That is, the execution image acquisition unit 304 downloads the execution image specified by the decrypted execution context from the object storage 400.
  • the arithmetic logic execution unit 306 sets data specified in the execution context decrypted by the reception processing unit 300 as an argument. Then, the operation logic execution unit 306 executes the operation logic using the execution image in the execution environment prepared by the memory management unit 302.
  • the result storage execution unit 308 stores the result of execution of the operation logic in the operation logic execution unit 306 in the object storage 400.
  • the result stored in the object storage 400 can be used for various purposes such as outputting from a predetermined output device and reusing it for other information processing.
  • the URI management unit 310 sorts, for the result of execution of the operation logic in the operation logic execution unit 306, an access destination of a device that requires the result.
  • the storage function management unit 312 controls and manages storage of information in the object storage 400 and / or local storage (for example, a predetermined storage unit (not shown) included in the system 1), calculation of information, and the like.
  • the storage function management unit 312 controls the result storage execution unit 308 to store the result of the execution of the operation logic in the object storage 400.
  • FIG. 4 shows a flow of processing that enables the system 1 to support a plurality of types of processors.
  • 5 shows a flow of processing in the proxy system 2 when executing a user application
  • FIG. 6 shows a flow of processing in the stub side system 3 when executing a user application.
  • the user application may be referred to as “user application”
  • the source code may be referred to as “source”.
  • Step 10 registration of a user application is started in the proxy system 2 (Step 10; hereinafter, the step is referred to as “S”).
  • the source acquisition unit 200 acquires the source code of the user application 600 stored in the object storage 400 (S12), and reads the source code into the system 1 (S14). Subsequently, the system 1 calls an API used in the system 1, and specifies an arithmetic logic for performing distributed processing using the API based on the read source code (S16).
  • the storage integrated management unit 206 confirms whether or not there is an access to other data other than the predetermined data from the specified arithmetic logic using a pointer based on the URI (S18).
  • the storage integrated management unit 206 determines that access to other data exists (Yes in S18), it executes an error process (S42). For example, the storage integrated management unit 206 stops execution of the processing of the system 1.
  • the storage integration management unit 206 supplies information indicating that access to other data does not exist to the device management unit 204.
  • the control unit 205 causes the device management unit 204 to continue executing the process.
  • the device management unit 204 determines that the processor specified based on the source code is an available processor that can be used in the system 1. It is confirmed whether or not there is (S20). That is, the device management unit 204 confirms whether a processor correspondence table and a correspondence have already been created for the specified processor. If the device management unit 204 determines that the processor correspondence table and the correspondence have not been created, the device management unit 204 determines that the designated processor is not usable (No in S20), and executes an error process (S42). Error handling may be similar to the above. On the other hand, when the device management unit 204 determines that the processor correspondence table and the correspondence have been created (Yes in S20), the device management unit 204 causes the calculation logic supply unit 208 to execute the transmission of the calculation logic to the designated processor (S22). ).
  • the processor 500 having received the operation logic causes its own compiler to compile the received operation logic (S24).
  • the arithmetic logic supply unit 208 supplies arithmetic logic to each of the plurality of processors. Then, in this case, each of the plurality of processors compiles the received operation logic using the respective compiler.
  • Each of the one or more processors sets the compiled result as an execution image (S26). Then, each of the one or a plurality of processors supplies the execution image to the object storage 400 and stores the execution image in the object storage 400 (S28).
  • the correspondence table creation unit 210 receives a path from the object storage 400 to each execution image for each of one or more processors (S30), creates a processor correspondence table, and stores the path to the execution image in the processor correspondence table. Is written (S32). That is, the correspondence table creation unit 210 creates a processor correspondence table in which a processor is associated with a path indicating a storage position in the object storage 400 of the execution image created by the processor.
  • the user application 600 can have a plurality of arithmetic logics.
  • S18 to S32 are executed for each of a plurality of operation logics, and a processor correspondence table is created. Therefore, when there are a plurality of operation logics, the processor correspondence table is created for each of the plurality of operation logics.
  • the correspondence determination unit 212 creates a correspondence in which the operation logic supplied by the operation logic supply unit 208 is associated with the storage path to the processor correspondence table stored in the object storage 400 (S34).
  • the information on the correspondence is supplied to the object storage 400 together with the processor correspondence table (S36).
  • the object storage 400 stores the processor correspondence table and the correspondence (S38).
  • the user application 600 is compiled by a conventionally known compiler (S40).
  • FIG. 5 execution of the user application 600 having a predetermined function is started (S50).
  • the user application 600 requests the proxy system 2 to specify data to be accessed by the operation logic included in its own source code.
  • the storage integrated management unit 206 checks whether the user application 600 has the access right to the requested data (S52). When the integrated storage management unit 206 determines that the user application 600 has an access right, the user application 600 specifies data to be accessed by the arithmetic logic (S54). On the other hand, when the storage integrated management unit 206 determines that there is no access right to the requested data, the storage integration management unit 206 denies access to the data and ends the processing.
  • the execution context creation unit 214 creates an execution context for the operation logic by using the specified data (S56).
  • the execution context creating unit 214 notifies the user application 600 of information indicating that the execution context has been created (S58).
  • the user application 600 specifies a device that executes the arithmetic logic (S60).
  • the device management unit 204 acquires information (device information) on the device specified by the user application 600 from the object storage 400 (S62). Then, the device management unit 204 specifies a target processor that is a target processor on which data processing is executed based on the device information (S64).
  • the device management unit 204 supplies information indicating that the target processor has been specified to the user application 600 (S66).
  • the execution context creating unit 214 refers to the processor correspondence table and the correspondence stored in the object storage 400 (S68), and is associated with the target processor in the processor correspondence table associated with the operation logic. The path to the execution image is written in the execution context (S70).
  • the user application 600 supplies an execution instruction of the arithmetic logic to the proxy-side system 2 (S72).
  • the control unit 50 of the proxy side system 2 writes the execution context in the storage queue in order to supply the execution context in which the path is written to the stub side system 3 (S74).
  • the execution context creation unit 214 can also include execution environment information that specifies an environment in which the arithmetic logic is executed, in the execution context.
  • the transmission processing unit 216 supplies various information in the storage queue to the stub-side system 3 (S76).
  • the reception processing unit 300 receives the execution context from the transmission processing unit 216 of the proxy system 2 (S80).
  • the reception processing unit 300 decodes the received execution context (S82).
  • the memory management unit 302 prepares an execution environment such as a physical memory in which the arithmetic logic is executed based on the device information and / or the execution environment information in the execution context decoded by the reception processing unit 300 (S84). ).
  • the execution image obtaining unit 304 downloads the execution image stored in the object storage 400 based on the path to the execution image in the decrypted execution context (S88).
  • the arithmetic logic execution unit 306 sets the data specified in the decrypted execution context as an argument (S88), and executes the arithmetic logic using the execution image downloaded in the execution environment (S90). Then, the URI management unit 310 executes a URI management process for allocating the data access destination (S92). Further, the storage function management unit 312 uses the function of the result storage execution unit 308 (S94), and stores the execution result of the arithmetic logic in the object storage 400 (S96). This execution result is referenced from inside and outside the system 1 as necessary. When the system 1 has a local storage, the storage function management unit 312 can also store the execution result in the local storage (not shown).
  • the operation logic can be held as the source code, and the execution image previously compiled for the device 5 by the processor 500 of the device 5 can be stored in the object storage 400. That is, an execution image adapted to each of the processors of the plurality of different devices can be stored in the object storage 400 in advance. Then, in the system 1, when the arithmetic logic is called in accordance with the operation of the user application 600, an execution image suitable for the processor 500 of the device 5 specified by the user application 600 is downloaded from the object storage 400 and executed. .
  • the execution image is supplied to the proxy system 2 by the user application 600, and the proxy system 2 supplies the execution image to the storage via the stub side system 3, and the execution image is stored in the storage.
  • the system 1 according to the present embodiment can improve the data processing efficiency even when, for example, large-volume data that is difficult to be divided into small-volume data by Low Context handled by artificial intelligence (AI) is handled. It can be greatly improved.
  • AI artificial intelligence
  • Low Context Data or BLOB Binary
  • BLOB Binary
  • Large ⁇ Object can be processed efficiently. Note that it is difficult to divide a file in Low Context Data, and it is necessary to support Scale Up in order to increase the size of one process. Therefore, in the conventional method, the processing speed is limited by the memory bandwidth, so that the data processing efficiency is reduced. appear.
  • the stub-side system 3 can execute a predetermined process only by downloading the execution image from the object storage 400, and can reduce the size of the execution image. Can be reduced. Further, since the system 1 creates an execution image using the compiler of each of a plurality of processors, even if a new processor is developed, a new processor It becomes easy to deal with.
  • the processing speed can be improved without the overhead of the intermediate code and the virtual machine as in the conventional Java (registered trademark), and the processing speed can be improved. It is possible to fully utilize the functions of the hardware.
  • the source code of the user application 600 can be stored in the object storage 400, that is, the cloud, and the source code can be compiled as it is in the cloud, the source code is substantially saved. Since the source code is simply compiled into an executable image without leaking to the outside and without requiring complicated processing such as intermediate code, information security is also excellent.
  • the DRAM may be used as a cache having a larger capacity than the cache. it can. That is, in the system 1, it is not always necessary to transfer all the data used for the data processing to the DRAM, but only a part required for the data processing of the data stored in the storage unit below the memory hierarchy such as the SSD. Can be processed by accessing (partial access), and when reading predetermined data from a storage unit below the memory hierarchy such as an SSD, processing (stream processing, etc.) incorporating operations required for data processing can be performed. it can.
  • the pointer is different for each storage unit.
  • the same data can be indicated by the same pointer by using the URI. Since the data in all storage units can be managed in a unified manner, even if the data volume increases with respect to the transfer speed, incorporate high-speed data processing technologies such as partial access and stream processing into various applications. Thus, data processing at higher speed than conventional address management can be realized. That is, according to the system 1 according to the present embodiment, it is possible to reduce unnecessary data transfer, standardize the data transfer routine, and extend the data transfer routine.
  • each unit of the system 1 may be realized by hardware or may be realized by software. Further, it may be realized by a combination of hardware and software.
  • the program may be installed in a computer constituting the system 1 from a computer-readable medium or a storage device connected to a network.
  • a program installed on a computer and causing the computer to function as the system 1 according to the present embodiment works on a CPU or the like to cause the computer to function as the system 1.
  • the information processing described in the program is read by the computer, and functions as a specific means in which the software and the hardware resources of the system 1 cooperate. By realizing information processing according to the purpose of use of the computer in the present embodiment by these specific means, it is possible to configure a unique system 1 according to the purpose of use.
  • the system 1 includes a data unit having a CPU, a ROM, a RAM, a communication interface, and the like, an input unit such as a keyboard, a touch panel, and a microphone, an output unit such as a display and a speaker, and a storage unit such as a memory and an HDD.
  • the information processing apparatus may be realized by activating software or a program that defines the operation of each unit of the system 1.
  • the program for the system 1 can be provided to the system 1 via a communication network such as the Internet or a recording medium such as a magnetic recording medium or an optical recording medium.
  • the program for the system 1 stored in the system 1 is executed by a CPU or the like.
  • the recording medium storing the program may be a non-transitory recording medium such as a CD-ROM or a DVD.
  • a system according to another example of the present embodiment can be used for a distributed processing system that spans a CPU, a GPU, and an FPGA for handling large-capacity data without being restricted by a communication band.
  • the present inventor studied the distributed processing between the Xeon and the IoT embedded processor (Rapsberry @ Pi3) in the cloud without restriction on the communication band for the remote area at the time of developing the speech to text compatible intercom. , The knowledge of how to transfer and use OpenCL @ Kernel files. Based on this knowledge, it has been found that a system according to another example of the present embodiment can be constructed.
  • In Storage Processing which performs processing without moving data as much as possible from the data source, can be considered.
  • OpenCL OpenCL @ Kernel @ Image is created in advance in accordance with a device existing in the system, and a device in which data exists at the time of data access. Is adopted to transfer and execute Kernel @ Image corresponding to.
  • OpenCL 1.2 The language used can be, for example, OpenCL 1.2, which is rich in the target processor.
  • Azure Xeon and Rapberry ⁇ Pi3 ⁇ VideoCore IV
  • OpenCL 1.2 is preferable.
  • the process may be passed from the cloud to Rapsberry @ Pi3 using Docker.
  • Docker it may be time-consuming to transfer Docker @ Image in a remote communication environment. Therefore, it is preferable to adopt a method of transferring only the Kernel of OpenCL. This is because the method of transferring only the kernel of OpenCL is effective in many cases of large-capacity data processing.
  • FIG. 7A is a schematic diagram of a conventional calculation of Apache @ Spark
  • FIG. 7B is a schematic diagram of a calculation in a system according to another example of the present embodiment.
  • file reading is started at 1-a, and aggregation (Aggregation) and sorting (Sort) of a plurality of inodes occur at 1-c. Subsequently, conversion (Encode) to the object storage format is performed in 1-d.
  • FIG. 7B the process is passed to the virtual processor in the cloud at 2-a, and OpenCL ⁇ Kernel ⁇ Image is transferred at 2-ax. 3-a. .
  • the data is processed without performing Aggregation, Sort, and Encode in e, and only the result is returned to the cloud in 4-c.
  • Table 1 shows the estimated time in each step of the process in FIG.
  • Legacy indicates the estimated time in the conventional method
  • Proposal is the estimated time in the system according to another example of the present embodiment.
  • Hybrid is when 100 files of 10M are exchanged between a data center in North America and Japan
  • Public is when the same number of files are executed under the same LAN.
  • Issue-finish is the actual processing time.
  • the conventional method takes 13 seconds in the worst case, whereas the system according to another example of the present embodiment is expected to be completed in 260 msec.
  • Most of the processing time depends on the 1-d data transfer, and if there is no data transfer, the conventional method is advantageous by 130 msec and by the absence of OpenCL ⁇ Kernel ⁇ Image transfer.
  • a system according to another example of the present embodiment is considered to be advantageous in many cases.
  • Table 2 shows a comparison (however, an estimate) of (processing time of the conventional method) / (processing time of the system according to another example of the present embodiment) in data size ⁇ transfer speed.
  • OpenMCCA maps a Heterogeneous Memory such as NVDIMM to a virtual memory space to enable uniform access.
  • NVDIMM Heterogeneous Memory
  • a single memory space is not used, and a device name in which a file actually exists is acquired in a name space of an existing storage, and processing is transferred to the device name.
  • a scale-up type open MCCA is considered to be a scale-out type in a system according to another example of the present embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Hardware Redundancy (AREA)

Abstract

異種混在の複数のデバイスを用いた場合であっても、中間コード等を用いずに情報処理の速度を向上させることができるシステム、情報処理方法、及びプログラムを提供する。システム１は、ソースコードを取得するソース取得部２００と、所定のＡＰＩを用い、演算ロジックをソースコード中から特定する演算ロジック特定部２０２と、ソースコードに基づいて指定されるプロセッサーのコンパイラに演算ロジックを供給する演算ロジック供給部２０８と、オブジェクトストレージ４００が、指定されるプロセッサーのコンパイラによってコンパイルされた結果を実行イメージとして格納し、オブジェクトストレージ４００に格納されている指定されるプロセッサーにおける実行イメージへのパスと、指定されるプロセッサーとを対応付けたプロセッサー対応表を作成してオブジェクトストレージ４００に格納する対応表作成部２１０と、演算ロジック供給部２０２が供給した演算ロジックと、オブジェクトストレージ４００に格納されているプロセッサー対応表の保存パスとを対応付けた対応関係をオブジェクトストレージ４００に格納する対応関係決定部２１２とを備える。

Description

システム、情報処理方法、及びプログラム
　本発明は、システム、情報処理方法、及びプログラムに関する。特に、本発明は、演算ロジックを各種ストレージ上で直接実行させることができるシステム、情報処理方法、及びプログラムに関する。
　従来、複数の計算機を備え、ジョブを複数の計算機に分散して実行させる負荷分散システムにおいて、複数の計算機がジョブを実行するためにアクセスするストレージと、複数の計算機のうち、負荷が少ない計算機にジョブを実行させる、第１の管理装置と、複数のジョブを受付け、当該受付けた複数のジョブをキューイングして、第１のジョブキューに順番に格納する、第２の管理装置と、第１のジョブキューのジョブを順番に取り出し、計算機が取り出したジョブを実行するのに必要なデータに対する処理をストレージ装置に対して実行する第３の管理装置と、処理が終了した複数のジョブを、計算機によって実行されることを待つ実行待ちジョブとして順番に格納する、第２のジョブキューとを備え、第１の管理装置は、第２のジョブキューから複数のジョブを順番に取り出し、当該取り出したジョブを計算機に実行させる負荷分散システムが知られている（例えば、特許文献１参照。）。特許文献１に記載の負荷分散システムによれば、計算機能力を最大限に使用してジョブを実行するための処理時間を短縮することができる。
特開２００８－１５８８８号公報
　特許文献１に記載のような従来の負荷分散システムにおいては、処理対象のデータ分割サイズによってはデータ処理効率が低下する。例えば、従来の負荷分散システムにおいては、ストレージからコンピューターのプロセッサーにデータを供給し、ジョブを実行させるので、数キロバイト程度に分割されたデータを用いる場合はともかく、数ギガバイト以上の連続した大容量データではデータ処理効率は大幅に低下する。
　したがって、本発明の目的は、数ギガバイト以上の連続した大容量データを用いた場合においてデータ処理効率を低下させないために、各種ストレージ上で直接、データ処理を実行させることができるシステム、情報処理方法、及びプログラムを提供することにある。
　本発明は、上記目的を達成するため、オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、ソースコードを取得するソース取得部と、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を用い、演算ロジックをソースコード中から特定する演算ロジック特定部と、ソースコードに基づいて指定されるプロセッサーのコンパイラに演算ロジックを供給する演算ロジック供給部と、オブジェクトストレージが、指定されるプロセッサーのコンパイラによってコンパイルされた結果を実行イメージとして格納し、オブジェクトストレージに格納されている指定されるプロセッサーにおける実行イメージへのパスと、指定されるプロセッサーとを対応付けたプロセッサー対応表を作成してオブジェクトストレージに格納する対応表作成部と、演算ロジック供給部が供給した演算ロジックと、オブジェクトストレージに格納されているプロセッサー対応表の保存パスとを対応付けた対応関係をオブジェクトストレージに格納する対応関係決定部とを備えるシステムが提供される。
　本発明に係るシステム、情報処理方法、及びプログラムによれば、数ギガバイト以上の連続した大容量データを用いた場合においてデータ処理効率を低下させないために、各種ストレージ上で直接、データ処理を実行させることができるシステム、情報処理方法、及びプログラムを提供できる。
本実施形態に係るシステムのアーキテクチャの概要図である。 本実施形態に係るシステムの機能構成ブロック図である。 本実施形態に係るユーザーアプリケーション、プロセッサー対応表、及び対応関係の構成の概要図である。 本実施形態に係るシステムにおける処理のフロー図である。 本実施形態に係るシステムにおける処理のフロー図である。 本実施形態に係るシステムにおける処理のフロー図である。 （ａ）は従来のＡｐａｃｈｅ　Ｓｐａｒｋの演算の概要図であり、（ｂ）は本実施形態の他の例に係るシステムにおける演算の概要図である。
［実施の形態］
＜システム１の概要＞
　従来の負荷分散システムにおいては、１つ以上のストレージからデータを読み込み、複数のプロセッサーを用いて分散処理する。つまり、所定のストレージから所定のコンピューターのプロセッサーにデータを供給し、ジョブを実行させる。したがって、数キロバイト程度の小容量データを扱う場合（例えば、ビックデータを扱う場合）においては従来の負荷分散システムであってもデータ処理効率は低下しにくい。しかしながら、数ギガバイト以上の連続した大容量データを扱う場合、従来の負荷分散システムではデータ処理効率が大幅に低下する。すなわち、従来の負荷分散システム（例えば、特開２００８－１５８８８号公報記載のシステム等）においては、ストレージから所定のコンピューターがデータを読み込み、このコンピューターが読み込んだデータを更に他のコンピューターが連続して読み込むことでジョブを実行していくので、大容量データを扱う場合のデータ処理効率は大幅に低下する。
　そこで、本発明者は発想を転換し、データの供給方向（すなわち、ルーチン若しくはジョブの供給方向）を逆にすることに想到した。例えば、ユーザーアプリケーションから所定のコンピューターにルーチン若しくはジョブを供給し、当該コンピューターからストレージにルーチン若しくはジョブを供給して当該ストレージ上でルーチン若しくはジョブを直接処理することでデータ処理効率の向上を実現できることに想到した。すなわち、本発明に係るシステムは、ユーザーアプリケーション内のデータを扱うルーチンの実行コードをストレージ上のＩＯコントローラーに供給し、ストレージ上でデータ処理を直接実行するという構成であり、ユーザーアプリケーションが動作するクラウドとルーチンが実行されるエッジとの双方で同時に分散処理されるシステムである。
　従来はエッジで扱われる異種混在の様々なデバイスに対応するため従来の仮想ハードウエア等で用いる中間コードを生成する必要があったが、本発明者が想到した構成によれば、中間コードを用いることを必ずしも要せず、所定のデータ処理用の実行コードをクラウドで生成することができるので（なお、実行コードはクラウドにおいて保存可能である。）、中間コードより処理効率の高い実行コード（すなわち、ストレージ用のジョブ・ルーチン）をクラウド上のユーザーアプリケーションより切り出して、ストレージ上でデータ処理を直接、実行することができる。
　なお、複数のデバイス（なお、デバイスにはストレージを含む）のプロセッサーのそれぞれに所定の演算ロジックを実行させる場合、当該デバイスの種類により機械語が異なるので、当該演算ロジックが一のデバイスで実行できたとしても他のデバイスで実行できるとは限らない。そのため、従来は、仮想ハードウエアを定義し、仮想ハードウエアで実行される中間コードに演算ロジックをコンパイルすることで異種混在のデバイスでこの演算ロジックが動作するようにしている。つまり、異種混在の様々なデバイスのプロセッサーは、仮想ハードウエアを実現するバーチャルマシンを実装し、バーチャルマシンで中間コードを読み込こんで演算ロジックを実行する。
　しかし、係る方式においてはバーチャルマシンを経由する分、処理速度が低下する。そのため、従来の方式においては、演算ロジックを実行する前に中間コードのすべてをプロセッサー向けの機械語に変換する特定のコンパイラ（例えば、Ｊｕｓｔ－ｉｎ－ｔｉｍｅ（ＪＩＴ）コンパイラ）を用いることで処理速度を高速化している。但し、係る方式であっても、中間コードを必須とするため、高速化には限界がある。
　一方、本発明者が想到した構成によれば、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを用いる場合に、演算ロジックをソースコードのままクラウドで保持し、複数のデバイスのプロセッサーのそれぞれにおいて、複数のデバイス用に演算ロジックをコンパイルすることで実行イメージを予め作成し、作成した実行イメージをクラウドに保存して、演算ロジックの実行指示がなされたときにこの保存してある実行イメージをデバイスにダウンロードして実行させることもできる。
　よって、従来の形式とはデータの供給方向を逆にした本実施形態に係るシステム１は、オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。そして、本実施形態に係るシステム１は、演算ロジックをソースコードのまま保持し、複数のデバイスのプロセッサーのそれぞれにおいて、複数のデバイス用に演算ロジックをコンパイルすることで実行イメージを作成し、作成した実行イメージをオブジェクトストレージに格納しておき、演算ロジックが複数のデバイスのうちの一のデバイスに呼び出された場合、一のデバイス用に作成された実行イメージをオブジェクトストレージから一のデバイスに供給して実行させるシステム（以下、「実行イメージ供給システム」と称する場合がある。）である。
　本実施形態に係るシステム１によれば、数ギガバイトの連続した大容量データを用いる場合であっても、ストレージ上で直接、演算処理を実行できるので、データ処理効率を従来技術よりも大幅に向上させることができる。また、システム１によれば、バーチャルマシンを経由しないので処理速度が大幅に向上する。更に、本実施形態に係るシステム１によれば、例えば、Ｊａｖａ（登録商標）等におけるオーバーヘッドをなくすことができることから処理速度を更に向上させることができ、また、ハードウエアの機能を完全に活用することもできる。
＜システム１の詳細＞
　図１は、本発明の実施の形態に係るシステムのアーキテクチャの概要の一例を示す。また、図２は、本発明の実施の形態に係るシステムの機能構成の概要の一例を示す。
［システム１のアーキテクチャの概要］
　図１及び図２に示すように、本実施形態に係るシステム１は、プロキシ側システム２と、スタブ側システム３と、オブジェクトストレージ４００に格納されシステム１（具体的には、プロキシ側システム２）に呼び出されるユーザーアプリケーション６００とを備え、異種混在の複数のデバイス５の少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。ユーザーアプリケーション６００は、予め定められた演算ロジックをソースコード中に有する。
　なお、図２では説明を簡略化するためデバイス５は１つのみ図示しているが、デバイス５は複数存在していてもよく、複数のデバイス５はそれぞれ、異なる機械語で動作するデバイスであってよい。デバイス５は、例えば、各種の格納装置や記録装置（すなわち、ストレージ）、周辺装置を制御部やプロセッサーに接続して制御するＩＯコントローラー等である。また、ユーザーアプリケーション６００としては、様々な処理を実行するアプリケーションが挙げられ、例えば、各種のユーティリティアプリケーション、各種の計算用アプリケーション、静止画や動画の画像処理アプリケーション、プログラミング用アプリケーション等が挙げられる。
　図１に示すように、プロキシ側システム２は、制御部５０を有し、スタブ側システム３において消費されるメモリ量を測定若しくは推定する機能（消費メモリ測定・推定機能）と、異種混在の複数のデバイスそれぞれのプロセッサーに所定の演算ロジックを供給してコンパイルさせて得られる実行イメージをオブジェクトストレージ４００やＧＰＧＰＵ　ＳａａＳ４１０に格納させる機能（変換処理機能）と、複数のデバイスのうちいずれのデバイスについて実行イメージを既に作成しているか否かを管理する機能（デバイス管理機能）と、スタブ側システム３にキュー１０等を用いて所定の情報を供給する機能（送信処理機能）と、演算ロジックからオブジェクトストレージ４００等の格納部へのデータアクセスに不正な構文が存在するか否かを確認する機能（ストレージ統合管理機能）とを有する。プロキシ側システム２に読み込まれたユーザーアプリケーション６００は、所定のＡｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）１００によって演算ロジックの特定等の処理が施される。そして、システム１は、ＳＹＣＬ及びＯｐｅｎＣＬ等の言語を用い、演算ロジックを、制御部５０によって実行できる形式に変換することもできる。なお、オブジェクトストレージ４００及びＧＰＧＰＵ　ＳａａＳ４１０は、Ｐｕｂｌｉｃ　ＰａａＳ４である。
　また、スタブ側システム３は、プロキシ側システム２からの情報を受け取る機能（受信処理機能）と、ストレージを管理する機能（ストレージ機能）と、演算ロジックが実行される環境を準備する機能（メモリ管理機能）と、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を管理する機能（ＵＲＩ管理機能）とを有する。スタブ側システム３は、プロキシ側システム２から受け取った情報に基づいて、演算ロジックを実行先（例えば、ＡＲＭ　Ｍａｌｉ、ＦＰＧＡ、Ｘｅｏｎ　Ｐｈｉ、ｎＶｉｄｉａ　ＧＰＵ等のデバイス。なお、ｎＶｉｄｉａ　ＧＰＵ１６は、専用バス１４を介してスタブ側システム３から情報を受け取る。）で実行させる。例えば、スタブ側システム３は、メモリ管理機能が準備した実行環境において、受信処理機能において受信した実行イメージに基づいてＯｐｅｎＣＬ、Ｃｅｐｈ及びＲＡＤＯＳ等を利用して実行先のデバイスで演算ロジックに基づいた処理を実行させる。実行先のデバイスとしては、例えば、ＳＳＤが挙げられ、ＳＳＤはＳＳＤ　Ｃｏｎｔｒｏｌｌｅｒ２０に制御される。また、ＳＳＤからＮＶＭ　Ｅｘｐｒｅｓｓ（ＮＶＭｅ３０）に基づいた論理デバイスに演算結果等を供給することもできる。なお、プロキシ側システム２とスタブ側システム３とは、例えば、分散ストレージソフトウエア（Ｃｅｐｈ１２）によって互いにデータのやり取りを実行できる。
［システム１で用いられるデータの指定方法の概要］
　まず、本実施形態に係るシステム１においては、データの指定方法として特定の指定方法を採用することが好ましい。
　すなわち、従来のコンピュータープログラムは、複数のルーチンがポインタと呼ばれる物理アドレスを受け渡し、Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ（ＤＲＡＭ）上のデータを複数のルーチン間で共有して利用したり、加工したりして動作する。そのため、Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ（ＳＳＤ）等のメモリヒエラルキー下層のデータを一度、ＤＲＡＭに転送することを要する。ここで、ＤＲＡＭとＳＳＤとの間で扱うデータ量が増大すると、従来の方式では十分な転送速度を確保できず、ＤＲＡＭへのデータ転送がデータ処理のボトルネックとなっている。
　そこで、システム１においては、上記ボトルネックを解消する観点から、物理アドレスでの管理ではなく、Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）での管理を用いることが好ましい。すなわち、システム１は、制御部５０と、データ位置（例えば、物理アドレスや各種の格納部の番地、ＩＯコントローラーの番号等）で示される番地にデータを格納する格納部（例えば、ＤＲＡＭやＳＳＤ等、及びオブジェクトストレージ４００等）とを備える。
　システム１では、データへアクセスするポインタとして、所定のスキームと所定の区切り（例えば、「：」（コロン）等）の後にスキーム毎に定義された書式によるリソースとが対応付けられているＵＲＩを用いる。つまり、本実施形態に係るシステム１においては、コンピューター内部のデータ位置を指し示すポインタを物理アドレスからＵＲＩに変更若しくは置換して用いることで、制御部５０が処理できるデータの位置を「拡張」する。換言すれば、システム１においては、データ位置の代わりにＵＲＩを用いる。なお、ポインタは、コンピュータープログラムが、ルーチン間で処理するデータの位置を受け渡す場合に用いる付票である。
（制御部５０）
　制御部５０は、システム１のプロキシ側システム２における各種のデータ処理等を制御する。制御部５０は格納部に働きかけて、格納部に格納されているデータの転送、処理等、及び所定のアプリケーション（例えば、ユーザーアプリケーション６００）の制御を実行する。制御部５０は、例えば、Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ（ＣＰＵ）の論理回路を有して構成される。
　制御部５０は、ＵＲＩに対応付けられているスキームによって指定される所定のアプリケーションを制御して起動させる。そして、制御部５０は、ＵＲＩのリソースをアプリケーションに渡す。続いて、アプリケーションは、リソースに基づいてＵＲＩをデータ位置として用い、ＵＲＩで指定されて格納部に格納されるデータを制御する。なお、制御部５０は、ＵＲＩに対応付けられているスキームに基づいて、複数のアプリケーションを制御して起動させることもできる。
　なお、ＵＲＩは、予め定められた一定の書式によってリソース（資源）を指し示す識別子である。本実施形態に係るＵＲＩにおいては、目的とするデータがシステム１内に存在しない場合をも考慮し、制御部５０若しくはアプリケーションによるアクセスを可能にするためのリソースをも指し示すことができるものとする。また、ＵＲＩが指し示すリソースに制御部５０やアプリケーションがアクセスすることができるようにすることを目的として、ＵＲＩを、実際の格納部における物理アドレスに変換することを要するので、同一の物理アドレスを複数のＵＲＩが指し示すこともあるものとする。なお、ＵＲＩの物理アドレスへの変換若しくは置換は、ＵＲＩに対応付けられているスキームが指定するアプリケーションが実行する。
　また、ＵＲＩは、例えば、「スキーム：／／リソース」の形式で記述され、リソースは、スキーム毎に定義された書式で記述される。そして、リソースの例としては、例えば、「目的のデータが存在するディスク番号、ディレクトリ、ファイル、シーク」、「目的のデータが存在するＤＲＡＭメモリアドレス」、「目的のデータが存在しない場合の対応、リトライ、コールバック」等が挙げられる。
（格納部）
　格納部は、所定の形式のデータ位置に所定のデータを格納可能に設けられる。格納部は、各種のデータを格納する機能を有する限り様々な記憶媒体を用いることができ、例えば、レジスタ、キャッシュ、Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ（ＤＲＡＭ）、ビデオメモリ、Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ（ＳＳＤ）、Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ（ＨＤＤ）、テープドライブ、Ｃｏｍｐａｃｔ　Ｄｉｓｃ（ＣＤ）やＤｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ（ＤＶＤ）等の光学記録媒体、光磁気記憶媒体、及び磁気記録媒体等である。格納部は、クラウド上の格納部であってもよく、データサイズやデータ数の保存制限がなく、大容量データの保存に適し、オブジェクト単位でデータを保存するオブジェクトストレージであってもよい。これらの格納部には、互いに異なる形式のデータ位置が割り当てられている。
　一例として、レジスタ、キャッシュ、ＤＲＡＭにおいては、データ位置は物理アドレスを用いて指定される。具体的に、レジスタにおいては、レジスタ名若しくは番号でデータ位置が指定される。キャッシュにおいては、先頭から順列に沿って数えたアドレスによってデータ位置が指定される。ＤＲＡＭにおいても、先頭から順列に沿って数えたアドレスでデータ位置が指定される。ただし、ＤＲＡＭにおいては、データ位置の指定は物理的にキャッシュとは異なる。
［システム１のデータ指定方法の詳細］
　本実施形態に係るシステム１は、ＵＲＩによってデータが指定される格納部を備える。そして、制御部５０がＵＲＩに対応付けられているスキームに応じたアプリケーションを起動させ、起動されたアプリケーションに当該ＵＲＩのリソースが渡される。そして、アプリケーションは、渡されたリソースに基づいてＵＲＩをデータ位置に変換する。これにより、格納部がどのような種類の格納部であっても、制御部５０による格納部の直接的、統一的な制御を可能とする。
　例えば、従来のＣＰＵではレジスタ、キャッシュ、及びＤＲＡＭまでを直接、制御する。そして、従来のＣＰＵは、メモリヒエラルキーにおけるＳＳＤ以下の格納部を直接制御することができない。ＤＲＡＭからＳＳＤにデータを転送する経路における転送速度がメモリヒエラルキーにおけるＤＲＡＭ以上の格納部における転送速度より低速であることから、ＤＲＡＭ以上におけるデータ転送等がいかに高速であっても、ＤＲＡＭからＳＳＤへのデータ転送が転送速度の観点からボトルネックになる。これは、従来のコンピューターでは格納部毎に異なる形式を用い、データ位置を物理アドレスで指定していることに起因する。
　一方、本実施形態に係るシステム１は、物理アドレスの代わりにＵＲＩをポインタとして用いる。そのため、ＤＲＡＭから下層の格納部であるＳＳＤ等を制御部５０によって直接、制御することができる。具体的に、本実施形態に係る制御部５０において、制御部５０が各格納部にアクセスする場合、制御部５０の命令によってアクセス可能な範囲は、レジスタ、キャッシュ、ＤＲＡＭ、及びＩＯチャネルのＩＯコントローラー等である。そして、制御部５０が、レジスタ、キャッシュ、ＤＲＡＭ、及びＩＯチャネルのＩＯコントローラーに保持されているデータ位置等の数値を制御し、ＩＯコントローラーに保持されている数値が制御部５０によって書き換えられることにより、ＩＯコントローラーから先のＳＳＤ、ＨＤＤ、及びテープドライブ等の格納部が制御部５０によって直接制御される。
　その結果、例えば、ＤＲＡＭをデータの転送先・共有場所としてではなく、キャッシュより容量が大きなキャッシュとして扱えるので、システム１におけるデータ処理速度を大幅に向上させることができる。
　より具体的には、制御部５０は、例えばオブジェクトストレージ４００に格納されている所定のデータのＵＲＩを参照し、ＵＲＩに対応付けられているスキームが指定するアプリケーションを起動する。制御部５０は、アプリケーションにＵＲＩの区切りの後ろのリソースを渡す。アプリケーションは、リソースに基づいて、物理アドレスの代わりにＵＲＩをデータ位置として用い、ＵＲＩで指定されている格納部に格納されているデータにアクセスする。これにより、ＵＲＩを用いてＳＳＤ等へのアクセスを、制御部５０により一元管理できる。
　例えば、制御部５０によって起動されるアプリケーションがＳＳＤ制御ルーチンであれば、ＳＳＤ制御ルーチンがリソースに基づいてＳＳＤコントローラー機器の物理アドレスや、ＳＳＤコントローラー上のＳＳＤメモリ空間の物理アドレスを生成する。これにより制御部５０が、ＳＳＤを制御することができる。
　なお、アプリケーションは、複数の格納部のそれぞれに格納されるデータをＵＲＩに基づいて指定することもできる。すなわち、アプリケーションは、制御部５０に制御され、複数の格納部にそれぞれ異なる形式の物理アドレスで指定された位置・番地に格納されている複数のデータそれぞれを、ＵＲＩを用いることで統一的に取り扱うこともできる。これにより、本実施形態に係るシステム１によれば、複数の格納部間でのデータ位置の指定をＵＲＩで拡張し、その結果、統一的に扱うことができる。
　以下においては、本実施形態に係るシステム１である実行イメージ供給システムに好適な構成を中心に説明する。
　図２に示すように、本実施形態に係るシステム１は、概略、プロキシ側システム２と、スタブ側システム３とを備える。システム１は、システム１外にあるオブジェクトストレージ４００に所定の情報を格納する。そして、システム１は、所定のデバイス５に所定の処理を実行させることができる。すなわち、システム１は、オブジェクトストレージ４００に格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイス５の少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。なお、デバイス５は、デバイス５の動作を制御する１つ以上のプロセッサー５００を有する。
［プロキシ側システム２］
　プロキシ側システム２は、所定のユーザーアプリケーションを一般的に用いられているコンパイラでコンパイルする前に、所定の処理を当該所定のユーザーアプリケーションに施すシステムである。
　プロキシ側システム２は、ソースコードを取得するソース取得部２００と、ソースコード中の演算ロジックを特定する演算ロジック特定部２０２と、１つ以上のデバイス５を管理するデバイス管理部２０４と、演算ロジックによるデータアクセスに関する処理を実行するストレージ統合管理部２０６と、１つ以上のデバイス５に演算ロジックを供給する演算ロジック供給部２０８と、実行イメージへのパスと当該実行イメージが実行されるプロセッサー５００とを対応付けたプロセッサー対応表を作成する対応表作成部２１０と、プロセッサー対応表の保存パスと当該プロセッサー対応表を用いる演算ロジックとを対応付けた対応関係を決定する対応関係決定部２１２と、実行用コンテキストを作成する実行用コンテキスト作成部２１４と、スタブ側システム３に所定の情報を供給する送信処理部２１６と、プロキシ側システム２の各構成の動作を制御する制御部５０とを有する。
（ソース取得部２００）
　ソース取得部２００は、所定のアプリケーション（例えば、ユーザーアプリケーション６００）のソースコードを取得する。ここで、所定のアプリケーションはオブジェクトストレージ４００に格納されており、ソース取得部２００は、オブジェクトストレージ４００から所定のアプリケーションのソースコードを取得する。すなわち、オブジェクトストレージ４００、すなわちクラウドに当該ソースコードは格納されており、ソース取得部２００は、クラウドからソースコードを取得することになる。なお、アプリケーションは、ソースコード中に演算ロジックを有している。ソース取得部２００は、所定のアプリケーションのソースコードを読み込み、読み込んだソースコードを演算ロジック特定部２０２に供給する。
（演算ロジック特定部２０２）
　演算ロジック特定部２０２は、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を呼び出し、ＡＰＩが、ソースコード中から演算ロジックを特定する。本実施形態において演算ロジックは、分散処理に用いられることが好ましい。
（デバイス管理部２０４）
　デバイス管理部２０４は、ソースコードに基づいて指定されるプロセッサー５００が、システム１において用いることができる使用可能プロセッサーであるか否かを確認する。すなわち、デバイス管理部２０４は、ソースコードによって指定されるプロセッサー５００が、システム１において対応済みのプロセッサーであるか否かを確認する。デバイス管理部２０４は、確認結果を演算ロジック供給部２０８に供給する。
（ストレージ統合管理部２０６）
　ストレージ統合管理部２０６は、演算ロジック特定部２０２が特定した演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かを確認する。例えば、ストレージ統合管理部２０６は、特定された演算ロジックにおいて、不正なＵＲＩ構文が存在するか否かを確認する。また、ストレージ統合管理部２０６は、アクセスするデータへのアクセス権がシステム１に存在するか否かを確認することができる。この場合、ストレージ統合管理部２０６は、システム１にアクセス権が存在するデータのみ、演算ロジックから当該データへのアクセスを許可する。
　ここで、デバイス管理部２０４は、ストレージ統合管理部２０６において他のデータへのアクセスが存在しないと判断された場合に、ソースコードに基づいて指定されるプロセッサー５００がシステム１において用いることができる使用可能プロセッサーであるか否かの確認を実行する。
（演算ロジック供給部２０８）
　図３は、本実施形態に係るユーザーアプリケーション、プロセッサー対応表、及び対応関係の構成の概要の一例を示す。
　図３（ａ）に示すように、ユーザーアプリケーション６００は、１つ以上の演算ロジック（例えば、演算ロジックａ、演算ロジックｂ・・・等）を含むソースコードを有して構成されている。ソースコードには、演算ロジックがアクセスするデータ、演算ロジックが実行されるデバイス５やプロセッサー５００等を特定若しくは指定する情報も含むことができる。
　演算ロジック供給部２０８は、ソースコードに基づいて指定されるプロセッサー５００のコンパイラに演算ロジックを供給する。より具体的に、演算ロジック供給部２０８は、デバイス管理部２０４が使用可能プロセッサーの存在を確認した場合（すなわち、指定されたプロセッサー５００が使用可能プロセッサーであると確認した場合）、ユーザーアプリケーション６００のソースコード中の演算ロジックを使用可能プロセッサーに供給する。ここで、ソースコードに基づいて指定されるプロセッサー５００は複数であってもよい。すなわち、ソースコードに基づいて指定されるデバイス５が複数であってもよい。この場合、演算ロジック供給部２０８は、複数の指定されたプロセッサーのコンパイラのそれぞれに、演算ロジックを供給する。
　演算ロジックが供給されたプロセッサー５００は、プロセッサー５００が有するコンパイラを用い、受け取った演算ロジックをコンパイルする。プロセッサー５００のコンパイラによるコンパイルは、クラウド上で実行される。そして、プロセッサー５００は、コンパイルした結果を実行イメージとしてオブジェクトストレージ４００に格納する。演算ロジックが供給されるプロセッサーが複数である場合は、複数のプロセッサーのそれぞれが、受け取った演算ロジックをコンパイルし、コンパイルした結果である実行イメージそれぞれをオブジェクトストレージ４００に格納する。なお、プロセッサーのコンパイラは従来公知のコンパイラを用いることができる。また、実行イメージは、例えば、ＯｐｅｎＣＬのＫｅｒｎｅｌ　Ｉｍａｇｅを利用することで作成できる。
（対応表作成部２１０）
　対応表作成部２１０は、オブジェクトストレージ４００が、ソースコードに基づいて指定されるプロセッサー５００のコンパイラによってコンパイルされた結果を実行イメージとして格納した場合に、オブジェクトストレージ４００に格納されている当該指定されるプロセッサー５００における実行イメージへのパスと、当該指定されるプロセッサーとを対応付けたプロセッサー対応表６１０を作成する。
　ユーザーアプリケーション６００は複数の演算ロジックを有することができるので、演算ロジックごとにプロセッサーと当該プロセッサー用の実行イメージのパスとが対応付けられる。具体的に、図３（ｂ）に示すように、プロセッサー対応表６１０は、演算ロジックごとに、１つ以上のプロセッサーのそれぞれと、各プロセッサーのコンパイラによってコンパイルされた結果である実行イメージへのパスとを対応付けた表であり、オブジェクトストレージ４００は、この表に関するデータをプロセッサー対応表６１０として格納する。図３（ｂ）の例では、演算ロジックａが供給されたプロセッサーＡに、プロセッサーＡのコンパイラでコンパイルされて作成された実行イメージへのパスａが対応付けられている（プロセッサーＢ、プロセッサーＣ、・・・等も同様である。）。対応表作成部２１０は、作成したプロセッサー対応表をオブジェクトストレージ４００に格納する。なお、プロセッサー対応表６１０は、演算ロジックごとに別々の表であっても、同一の表であってもよい。
（対応関係決定部２１２）
　対応関係決定部２１２は、演算ロジック供給部２０８が供給した演算ロジックと、オブジェクトストレージ４００に格納され、当該演算ロジックに対応するプロセッサー対応表の保存パスとを対応付けた対応関係６２０をオブジェクトストレージ４００に格納する。図３（ｃ）に示すように、対応関係６２０は、演算ロジックに、当該演算ロジックが供給されたプロセッサーにおいて作成された実行イメージへのパスを格納しているプロセッサー対応表６１０への保存パスを対応付けた表である。図３（ｃ）の例では、演算ロジックａにプロセッサー対応表への保存パスＡが対応付けられている（演算ロジックｂ等の他の演算ロジックについても同様である。）。
（実行用コンテキスト作成部２１４）
　実行用コンテキスト作成部２１４は、演算ロジックにおいて実行される実行用コンテキストを作成する。具体的には、オブジェクトストレージ４００が、異種混在の複数のデバイスに関するデバイス情報を予め格納する。デバイス情報は、例えば、デバイスの位置、種類、プロセッサー５００の種類等に関する情報である。そして、ユーザーアプリケーション６００は、ユーザーアプリケーション６００の実行が開始された場合、ユーザーアプリケーション６００の演算ロジックがアクセスするデータを指定すると共に、演算ロジックが実行されるデバイスを指定する。そして、実行用コンテキスト作成部２１４は、指定されたデータに基づいて実行用コンテキストを作成する。
　より具体的には、まず、ユーザーアプリケーション６００がデータを指定する場合に、ストレージ統合管理部２０６は、指定されたデータ、すなわち、アクセスが要求されたデータへのアクセス権がシステム１にあるか否かを確認し、アクセス権がある場合に、当該データの指定を許可する。
　そして、デバイス管理部２０４は、ユーザーアプリケーション６００が指定したデバイスに関するデバイス情報をオブジェクトストレージ４００から取得してデータ処理が実行される対象プロセッサーを特定する。続いて、実行用コンテキスト作成部２１４は、オブジェクトストレージ４００に格納されているプロセッサー対応表及び対応関係を参照し、演算ロジックに対応付けられたプロセッサー対応表における対象プロセッサーに対応付けられている実行イメージへのパスを実行用コンテキストに書き込む。これにより、実行用コンテキスト作成部２１４は、外部に提供する実行用コンテキストを作成する。
（送信処理部２１６）
　送信処理部２１６は、ユーザーアプリケーション６００が演算ロジックの実行を指示した場合、パスが書き込まれた実行用コンテキストを外部（すなわち、スタブ側システム３）に供給するためにストレージキューに書き込む。送信処理部２１６は、ストレージキューを介して実行用コンテキストをスタブ側システム３に供給する。
［スタブ側システム３］
　スタブ側システム３は、プロキシ側システム２から供給される実行用コンテキストに基づいて、所定のデバイス５に所定の処理を実行させる。なお、実行された処理の結果はオブジェクトストレージ４００に格納することができる。
　スタブ側システム３は、プロキシ側システム２から所定の情報を受け取る受信処理部３００と、物理的なメモリを管理するメモリ管理部３０２と、実行イメージを取得する実行イメージ取得部３０４と、演算ロジックを実行する演算ロジック実行部３０６と、演算ロジックの結果をオブジェクトストレージ４００に格納させる結果格納実行部３０８と、ＵＲＩを管理するＵＲＩ管理部３１０と、ストレージ機能を管理するストレージ機能管理部３１２とを有する。
（受信処理部３００）
　受信処理部３００は、送信処理部２１６からパスが書き込まれた実行用コンテキストを受信する。また、受信処理部３００は、受信した実行用コンテキストを解読する。
（メモリ管理部３０２）
　メモリ管理部３０２は、受信処理部３００において解読された実行用コンテキスト内のデバイス情報に基づいて、演算ロジックが実行される物理メモリ等の実行環境を準備する。
（実行イメージ取得部３０４）
　実行イメージ取得部３０４は、受信処理部３００において解読された実行用コンテキスト内の実行イメージへのパスに基づいて、オブジェクトストレージ４００から実行イメージを取得する。すなわち、実行イメージ取得部３０４は、解読された実行用コンテキストによって指定される実行イメージを、オブジェクトストレージ４００からダウンロードする。
（演算ロジック実行部３０６）
　演算ロジック実行部３０６は、受信処理部３００において解読された実行用コンテキスト内で指定されるデータを引数として設定する。そして、演算ロジック実行部３０６は、メモリ管理部３０２が準備した実行環境において実行イメージを用いて演算ロジックを実行する。
（結果格納実行部３０８）
　結果格納実行部３０８は、演算ロジック実行部３０６において演算ロジックが実行された結果をオブジェクトストレージ４００に格納する。オブジェクトストレージ４００に格納された当該結果は、所定の出力装置から出力することや、他の情報処理に再利用すること等、様々な用途に用いることができる。
（ＵＲＩ管理部３１０）
　ＵＲＩ管理部３１０は、演算ロジック実行部３０６において演算ロジックが実行された結果について、当該結果を必要とするデバイスのアクセス先を振り分ける。
（ストレージ機能管理部３１２）
　ストレージ機能管理部３１２は、オブジェクトストレージ４００、及び／又はローカルストレージ（例えば、システム１が備える所定の格納部（図示しない））への情報の格納や情報の演算等を制御・管理する。例えば、ストレージ機能管理部３１２は、結果格納実行部３０８を制御して、演算ロジックが実行された結果をオブジェクトストレージ４００に格納する。
［システム１における処理の流れ］
　図４～図６はそれぞれ、本実施の形態に係るシステムにおける処理の流れの概要の一例を示す。具体的に、図４は、システム１による複数種類のプロセッサーへの対応を可能にする処理の流れを示す。また、図５は、ユーザーアプリケーションを実行する場合におけるプロキシ側システム２における処理の流れを示し、図６は、ユーザーアプリケーションを実行する場合におけるスタブ側システム３における処理の流れを示す。なお、図４～図６において、ユーザーアプリケーションを「ユーザーアプリ」と表記する場合があり、ソースコードを「ソース」と表記する場合がある。
　まず、図４を参照する。初めに、プロキシ側システム２においてユーザーアプリの登録が開始される（ステップ１０。以下、ステップを「Ｓ」と表す。）。ソース取得部２００は、オブジェクトストレージ４００に格納されているユーザーアプリケーション６００のソースコードを取得し（Ｓ１２）、ソースコードをシステム１に読み込む（Ｓ１４）。続いて、システム１は、システム１において用いられるＡＰＩを呼び出し、ＡＰＩを用いて分散処理する演算ロジックを、読み込まれたソースコードに基づいて特定する（Ｓ１６）。
　次に、ストレージ統合管理部２０６は、特定された演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かについて、ＵＲＩに基づくポインタを用いて確認する（Ｓ１８）。ストレージ統合管理部２０６は、他のデータへのアクセスが存在すると判断した場合（Ｓ１８のＹｅｓ）、エラー処理を実行する（Ｓ４２）。例えば、ストレージ統合管理部２０６は、システム１の処理の実行を停止する。一方、ストレージ統合管理部２０６は、他のデータへのアクセスが存在しないと判断した場合（Ｓ１８のＮｏ）、他のデータへのアクセスが存在しない旨を示す情報をデバイス管理部２０４に供給するか、若しくはデバイス管理部２０４に処理の実行を継続させる。
　デバイス管理部２０４は、ストレージ統合管理部２０６において他のデータへのアクセスが存在しないと判断された場合に、ソースコードに基づいて指定されたプロセッサーが、システム１において用いることができる使用可能プロセッサーであるか否かを確認する（Ｓ２０）。すなわち、デバイス管理部２０４は、指定されたプロセッサーについて、既にプロセッサー対応表及び対応関係を作成したか否かを確認する。デバイス管理部２０４は、プロセッサー対応表及び対応関係が作成されていないと判断した場合、指定されたプロセッサーが使用可能でないと判断し（Ｓ２０のＮｏ）、エラー処理を実行する（Ｓ４２）。エラー処理は上記と同様であってよい。一方、デバイス管理部２０４は、プロセッサー対応表及び対応関係が作成されていると判断した場合（Ｓ２０のＹｅｓ）、演算ロジック供給部２０８に指定されたプロセッサーへの演算ロジックの送信を実行させる（Ｓ２２）。
　演算ロジックを受信したプロセッサー５００は、受け取った演算ロジックのコンパイルを自身のコンパイラに実行させる（Ｓ２４）。演算ロジック供給部２０８は、指定されたプロセッサーが複数存在する場合、複数のプロセッサーのそれぞれに演算ロジックを供給する。そして、この場合、複数のプロセッサーのそれぞれが、それぞれのコンパイラを用いて受け取った演算ロジックのコンパイルを実行する。一つ若しくは複数のプロセッサーのそれぞれは、コンパイルした結果を実行イメージとする（Ｓ２６）。そして、一つ若しくは複数のプロセッサーのそれぞれは、実行イメージをオブジェクトストレージ４００に供給してオブジェクトストレージ４００に格納させる（Ｓ２８）。
　そして、対応表作成部２１０は、オブジェクトストレージ４００から各実行イメージへのパスを一つ若しくは複数のプロセッサーごとに受け取り（Ｓ３０）、プロセッサー対応表を作成して、プロセッサー対応表に実行イメージへのパスを書き込む（Ｓ３２）。すなわち、対応表作成部２１０は、プロセッサーと当該プロセッサーにおいて作成された実行イメージのオブジェクトストレージ４００における格納位置を示すパスとを対応付けたプロセッサー対応表を作成する。
　ここで、ユーザーアプリケーション６００は複数の演算ロジックを有することができる。この場合、本実施形態に係るシステム１においては、複数の演算ロジックごとにＳ１８～Ｓ３２を実行し、プロセッサー対応表を作成する。したがって、複数の演算ロジックが存在する場合、プロセッサー対応表は複数の演算ロジックごとに作成される。
　続いて、対応関係決定部２１２は、演算ロジック供給部２０８が供給した演算ロジックと、オブジェクトストレージ４００に格納されているプロセッサー対応表への保存パスとを対応付けた対応関係を作成し（Ｓ３４）、この対応関係に関する情報をプロセッサー対応表と共にオブジェクトストレージ４００に供給する（Ｓ３６）。オブジェクトストレージ４００は、プロセッサー対応表及び対応関係を格納する（Ｓ３８）。そして、ユーザーアプリケーション６００は、従来公知のコンパイラでコンパイルされる（Ｓ４０）。
　次に、図５を参照する。まず、所定の機能を有するユーザーアプリケーション６００の実行が開始される（Ｓ５０）。ユーザーアプリケーション６００は、自身のソースコードに含まれる演算ロジックがアクセスするデータの指定をプロキシ側システム２に要求する。ストレージ統合管理部２０６は、要求されたデータに対するアクセス権がユーザーアプリケーション６００にあるか否かを確認する（Ｓ５２）。ストレージ統合管理部２０６がユーザーアプリケーション６００にアクセス権があると判断した場合、ユーザーアプリケーション６００は、演算ロジックがアクセスするデータを指定する（Ｓ５４）。一方、ストレージ統合管理部２０６は、要求されたデータに対するアクセス権がないと判断した場合、データへのアクセスを拒否して処理を終了する。
　実行用コンテキスト作成部２１４は、指定されたデータを利用し、演算ロジックの実行用コンテキストを作成する（Ｓ５６）。実行用コンテキスト作成部２１４は、実行用コンテキストを作成した場合、実行用コンテキストを作成したことを示す情報をユーザーアプリケーション６００に通知する（Ｓ５８）。ユーザーアプリケーション６００は、この通知に応じ、演算ロジックを実行するデバイスを指定する（Ｓ６０）。デバイス管理部２０４は、ユーザーアプリケーション６００が指定したデバイスに関する情報（デバイス情報）をオブジェクトストレージ４００から取得する（Ｓ６２）。そして、デバイス管理部２０４は、デバイス情報に基づいてデータ処理が実行される対象のプロセッサーである対象プロセッサーを特定する（Ｓ６４）。
　デバイス管理部２０４は、対象プロセッサーを特定したことを示す情報をユーザーアプリケーション６００に供給する（Ｓ６６）。また、実行用コンテキスト作成部２１４は、オブジェクトストレージ４００に格納されているプロセッサー対応表及び対応関係を参照し（Ｓ６８）、演算ロジックに対応付けられたプロセッサー対応表における対象プロセッサーに対応付けられている実行イメージへのパスを実行用コンテキストに書き込む（Ｓ７０）。
　ユーザーアプリケーション６００は、対象プロセッサーを特定したことを示す情報を取得した後、演算ロジックの実行命令をプロキシ側システム２に供給する（Ｓ７２）。プロキシ側システム２の制御部５０は、当該情報を受け取った後、パスが書き込まれた実行用コンテキストをスタブ側システム３に供給するためにストレージキューに当該実行用コンテキストを書き込む（Ｓ７４）。なお、実行用コンテキスト作成部２１４は、実行用コンテキストに、演算ロジックが実行される環境を指定する実行環境情報を含ませることもできる。そして、送信処理部２１６は、ストレージキュー内の各種情報をスタブ側システム３に供給する（Ｓ７６）。
　続いて図６を参照する。受信処理部３００は、プロキシ側システム２の送信処理部２１６から実行用コンテキストを受信する（Ｓ８０）。受信処理部３００は、受信した実行用コンテキストを解読する（Ｓ８２）。メモリ管理部３０２は、受信処理部３００によって解読された実行用コンテキスト内のデバイス情報、及び／又は実行環境情報等に基づいて、演算ロジックが実行される物理メモリ等の実行環境を準備する（Ｓ８４）。そして、実行イメージ取得部３０４は、解読された実行用コンテキスト内の実行イメージへのパスに基づいて、オブジェクトストレージ４００に格納されている実行イメージをダウンロードする（Ｓ８８）。
　そして、演算ロジック実行部３０６は、解読された実行用コンテキスト内で指定されるデータを引数として設定し（Ｓ８８）、実行環境においてダウンロードした実行イメージを用いて演算ロジックを実行する（Ｓ９０）。そして、ＵＲＩ管理部３１０は、データのアクセス先を振り分けるＵＲＩ管理処理を実行する（Ｓ９２）。また、ストレージ機能管理部３１２は、結果格納実行部３０８の機能を用い（Ｓ９４）、演算ロジックの実行結果をオブジェクトストレージ４００に格納する（Ｓ９６）。この実行結果は、システム１の内外から必要に応じ、参照される。ストレージ機能管理部３１２は、システム１がローカルストレージを備えている場合、当該ローカルストレージ（図示しない）に実行結果を格納することもできる。
（実施の形態の効果）
　本実施形態に係るシステム１においては、演算ロジックをソースコードのまま保持し、デバイス５のプロセッサー５００において予め当該デバイス５用にコンパイルした実行イメージをオブジェクトストレージ４００に格納することができる。すなわち、複数の互いに異なるデバイスのプロセッサーのそれぞれに合わせた実行イメージを、オブジェクトストレージ４００に予め格納することができる。そして、システム１においては、演算ロジックがユーザーアプリケーション６００の動作に応じて呼び出されると、当該ユーザーアプリケーション６００が指定するデバイス５のプロセッサー５００に適した実行イメージがオブジェクトストレージ４００からダウンロードされて実行される。すなわち、本実施形態に係るシステム１においては、ユーザーアプリケーション６００によってプロキシ側システム２に実行イメージが供給され、プロキシ側システム２がスタブ側システム３を介してストレージに当該実行イメージを供給し、ストレージ上でデータ処理を直接実行させることができる。これにより、本実施形態に係るシステム１は、例えば、人工知能（ＡＩ）が扱うＬｏｗ　Ｃｏｎｔｅｘｔで小容量のデータに分割することが困難な大容量データを扱う場合であっても、データ処理効率を大幅に向上させることができる。
　したがって、本実施形態に係るシステム１によれば、例えば、従来の負荷分散システムでは処理が困難である防犯カメラの動画像や録音した環境音当等処理する場合に用いるＬｏｗ　Ｃｏｎｔｅｘｔ　ＤａｔａやＢＬＯＢ（Ｂｉｎａｒｙ　Ｌａｒｇｅ　Ｏｂｊｅｃｔ）を効率よく処理できる。なお、Ｌｏｗ　Ｃｏｎｔｅｘｔ　Ｄａｔａはファイル分割が困難であり、１つの処理を大型化するＳｃａｌｅ　Ｕｐ対応が要求されるので、従来の方式ではメモリ帯域により処理速度に制限がかかることによるデータ処理効率の低下が発生する。
　本実施形態に係るシステム１においては、スタブ側システム３はオブジェクトストレージ４００から実行イメージをダウンロードするだけで所定の処理を実行でき、実行イメージのサイズを小さくすることができるので、データ転送量を大幅に低減することができる。更に、システム１は、複数のプロセッサーそれぞれのコンパイラを用いて実行イメージを作成するので、移植の手間がかかる従来のＪａｖａ（登録商標）等と比べ、新たなプロセッサーが開発されても、新たなプロセッサーへの対応が容易になる。
　また、本実施の形態に係るシステム１においては、従来のＪａｖａ（登録商標）のような中間コードのオーバーヘッドやバーチャルマシンを要さず、処理速度を向上させることができ、異種混在の複数デバイスへの対応が可能で、ハードウエアの機能を完全に活用することができる。
　更に、本実施形態に係るシステム１においては、オブジェクトストレージ４００、すなわち、クラウドにユーザーアプリケーション６００のソースコードを格納し、そのソースコードをそのままクラウド中でコンパイルすることができるので、実質的にソースコードが外部に漏洩することがなく、かつ、中間コード等の複雑な処理を必要とせずにソースコードを実行イメージにコンパイルするだけなので、情報セキュリティについても優れている。
　また、本実施の形態に係るシステム１においては、複数のルーチンで受け渡されるポインタとして、ＵＲＩをデータ位置（物理アドレス）の代わりに用いたので、ＤＲＡＭをキャッシュより容量の大きなキャッシュとして用いることができる。すなわち、システム１においては、データ処理に用いるデータのすべてをＤＲＡＭに転送することを必ずしも要さず、ＳＳＤ等のメモリヒエラルキーの下層の格納部に格納されているデータのデータ処理に要する一部だけにアクセスして処理ができ（部分アクセス）、また、ＳＳＤ等のメモリヒエラルキーの下層の格納部から所定のデータを読み取る場合において、データ処理に要する演算を組み込む処理（ストリーム処理等）をすることができる。
　したがって、従来の物理アドレスによる管理では格納部毎にポインタが異なるのに対し、本実施形態に係るシステム１によれば、ＵＲＩを用いることで同一のポインタで同一のデータを指し示すことができることから、すべての格納部のデータを統一的に管理できるので、データ量が転送速度に対して増大した場合であっても、部分アクセスやストリーム処理等のデータ処理の高速化技術を様々なアプリケーションに組み込むことで、従来のアドレス管理よりも高速化したデータ処理を実現することができる。すなわち、本実施形態に係るシステム１によれば、無駄なデータ転送の削減、データ転送ルーチンの共通化、及びデータ転送ルーチンへの拡張を実現することができる。
　以上の説明において、システム１の各部は、ハードウエアにより実現されてもよく、ソフトウエアにより実現されてもよい。また、ハードウエアとソフトウエアとの組み合わせにより実現されてもよい。プログラムは、コンピューター読み取り可能な媒体又はネットワークに接続された記憶装置から、システム１を構成するコンピューターにインストールされてもよい。
　コンピューターにインストールされ、コンピューターを本実施形態に係るシステム１として機能させるプログラムは、ＣＰＵ等に働きかけて、コンピューターをシステム１として機能させる。プログラムに記述された情報処理は、コンピューターに読込まれることにより、ソフトウエアとシステム１のハードウエア資源とが協働した具体的手段として機能する。そして、これらの具体的手段によって、本実施形態におけるコンピューターの使用目的に応じた情報の処理を実現することにより、使用目的に応じた特有のシステム１を構成できる。
　また、システム１は、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信インターフェース等を有するデータユニットと、キーボード、タッチパネル、マイク等の入力ユニットと、ディスプレイ、スピーカ等の出力ユニットと、メモリ、ＨＤＤ等の記憶ユニットとを備える構成の情報処理装置において、システム１の各部の動作を規定したソフトウエア又はプログラムを起動することにより実現してもよい。
　システム１用のプログラムは、インターネット等の通信ネットワーク、又は磁気記録媒体、光学記録媒体等の記録媒体を介してシステム１に提供し得る。そして、システム１に格納されたシステム１用のプログラムは、ＣＰＵ等により実行される。プログラムを格納している記録媒体は、ＣＤ－ＲＯＭやＤＶＤ等の非一過性の記録媒体であってもよい。
［実施の形態の他の例］
　本実施形態の他の例に係るシステムは、通信帯域の制限を受けずに大容量データを扱うためのＣＰＵ、ＧＰＵ、及びＦＰＧＡをまたがった分散処理のシステムに用いることができる。
　具体的に、本発明者は、Ｓｐｅｅｃｈ　Ｔｏ　Ｔｅｘｔ対応インターホン開発時に、僻地対応のため通信帯域の制限を受けずにクラウド内のＸｅｏｎとＩｏＴの組み込みプロセッサー（Ｒａｐｓｂｅｒｒｙ　Ｐｉ３）とにおける分散処理を検討したところ、ＯｐｅｎＣＬ　Ｋｅｒｎｅｌファイルを転送して利用する方法について知見を得た。この知見に基づいて、本実施形態の他の例に係るシステムを構築できることを見出した。
　まず、係るシステムの背景を説明する。すなわち、記憶装置における速度を上下、容量を左右とするメモリヒエラルキーは、ムーアの法則に従って鼓型に変形し、中央部の転送速度が不足することが知られている。半導体プロセスが進化することにより、メモリヒエラルキーの上下はより高くなり（つまり、速度が速くなり）、底辺はより広くなる（つまり、容量が増加する。）ためである。ただし、転送速度の進化を表すギルダーの法則はムーアの法則より遅く、１０年で相対速度が１／１０となる。そのため、慢性的な転送速度不足が発生している。
　ここで、転送速度対策としては、データの発生源から極力データを移動させずに処理を行うＩｎ　Ｓｔｏｒａｇｅ　Ｐｒｏｃｅｓｓｉｎｇが考えられる。しかし、多種プロセッサーに対応したデータ処理指向のプラットフォームが存在せず、コンテナ技術等を利用して独自に開発する必要がある。
　そこで、本実施形態の他の例に係るシステムにおいては、データアクセスに関するプログラムをＯｐｅｎＣＬで記述し、システムに存在する機器に合わせて事前にＯｐｅｎＣＬ　Ｋｅｒｎｅｌ　Ｉｍａｇｅを作成し、データアクセス時にテータが存在する機器に対応するＫｅｒｎｅｌ　Ｉｍａｇｅを転送して実行する形態を採用する。
　使用言語は、例えば、対象となるプロセッサー対応が豊富であるＯｐｅｎＣＬ　１．２を採用できる。なお、開発対象としてＡｚｕｒｅのＸｅｏｎとＲａｐｓｂｅｒｒｙ　Ｐｉ３　（ＶｉｄｅｏＣｏｒｅ　ＩＶ）を用いる場合、ＯｐｅｎＣＬ　１．２が好ましい。また、Ｄｏｃｋｅｒを利用してクラウドからＲａｐｓｂｅｒｒｙ　Ｐｉ３に処理を渡してもよい。ただし、Ｄｏｃｋｅｒを利用する場合、僻地の通信環境ではＤｏｃｋｅｒ　Ｉｍａｇｅの転送に時間がかかる場合があることから、ＯｐｅｎＣＬのＫｅｒｎｅｌだけを転送させる手法を採用することが好ましい。ＯｐｅｎＣＬのＫｅｒｎｅｌだけを転送させる手法によれば、大容量データ処理の多くのケースで有効であるためである。
　具体的に、Ａｌｌ　Ｆｌａｓｈ　Ａｒｒａｙ等の高速ストレージでは、大容量データは複数のｉｎｏｄｅに分割されて保存されている。ファイルの読み出し時には、ｉｎｏｄｅが集約（Ａｇｇｒｅｇａｔｉｏｎ）され、整列（Ｓｏｒｔ）され、ファイル転送可能な形式に変換（Ｅｎｃｏｄｅ）される。仮にＯｐｅｎＣＬ　Ｋｅｒｎｅｌ　Ｉｍａｇｅをストレージ機器自身のプロセッサーで動作させれば、上記の三つの処理を経由せずに直接ｉｎｏｄｅを操作可能となり、系全体の実行効率を上昇させることができる。
　図７（ａ）は、従来のＡｐａｃｈｅ　Ｓｐａｒｋの演算の概要図であり、図７（ｂ）は、本実施形態の他の例に係るシステムにおける演算の概要図である。
　従来の方法では１－ａでファイル読み取りが開始され、１－ｃで複数ｉｎｏｄｅの集約（Ａｇｇｒｅｇａｔｉｏｎ）と整列（Ｓｏｒｔ）とが発生する。続いて１－ｄでオブジェクトストレージ形式への変換（Ｅｎｃｏｄｅ）がなされる。一方、図７（ｂ）においては、クラウド内の仮想プロセッサーに２－ａで処理が渡され、ＯｐｅｎＣＬ　Ｋｅｒｎｅｌ　Ｉｍａｇｅが２－ａ－ｘで転送される。３－ａ．．ｅにてＡｇｇｒｅｇａｔｉｏｎ、Ｓｏｒｔ、Ｅｎｃｏｄｅをせずにデータ処理され、４－ｃで結果のみがクラウドに戻される。
　表１は、図７における処理の各ステップにおける見積もり時間を示す。
Figure JPOXMLDOC01-appb-T000001
　Ｌｅｇａｃｙが従来手法における見積もり時間を示し、Ｐｒｏｐｏｓａｌが本実施形態の他の例に係るシステムにおける見積もり時間である。１０Ｍのファイルを１００個、北米のデータセンターと日本国内とでやり取りした場合がＨｙｂｒｉｄであり、同ファイル数を同一ＬＡＮ配下で実行した場合がＰｕｂｌｉｃである。Ｉｓｓｕｅ－ｆｉｎｉｓｈが実際の処理時間である。従来手法が最悪ケースで１３秒かかっているのに対し、本実施形態の他の例に係るシステムにおいては、２６０ｍｓｅｃで完了する見込みとなる。処理時間のほとんどは１－ｄのデータ転送にかかっており、仮にデータ転送がないとすると、従来手法は１３０ｍｓｅｃとＯｐｅｎＣＬ　Ｋｅｒｎｅｌ　Ｉｍａｇｅ転送がない分だけ有利となる。しかし、現実にはデータ転送が存在するため、本実施形態の他の例に係るシステムの方が多くの場合に有利と考えられる。
　以下、本実施形態の他の例に係るシステムの実験例を示す。
　実情ではクラウド内では高性能ＧＰＵが用いられ、エッジでは一般的なプロセッサーが使われると考えられる。そこで、以下の環境にて実験した。
Ｍｉｃｒｏｓｏｆｔ　Ａｚｕｒｅ
クラウド内ＧＰＧＰＵ：ｎＶｉｄｉａ　Ｔｅｓｌａ　Ｋ８０（５．６１Ｔｆｌｏｐｓ）
エッジプロセッサー：Ｉｎｔｅｌ　Ｓｋｙｌａｋｅ　５３０（０．４４Ｔｆｌｏｐｓ）
　表２には、データサイズ×転送速度における（従来手法の処理時間）／（本実施形態の他の例に係るシステムの処理時間）の比較（ただし、見積もり）を示す。
Figure JPOXMLDOC01-appb-T000002
　１０Ｍのファイル×１００を３．５Ｇｂｐｓの帯域環境で処理したところ、従来手法における場合の処理では３０．４９秒かかり、本実施形態の他の例に係るシステムにおける処理では３．５６秒かかった。すなわち、本実施形態の他の例に係るシステムにおいては従来手法より８．５６倍、高速化した。これは、理論値の９．２７倍には届かなかったが十分な高速化である。
　なお、ＯｐｅｎＣＬ自体にはデータアクセスの手法が存在せず、ホストアプリケーションが読み取ったデータを共有メモリにて引き渡し処理をするため、本実施形態の他の例に係るシステムを用いる場合、ホストアプリケーションをプログラムごとに改編することが好ましい。上記実験ではホストアプリケーションをデータごとに組み替えて対応した。
　また、ＧＰＵのメモリ空間を拡張するためにＰａｇｅ　Ｆａｕｌｔ時に仮想メモリを読み込む技術が存在し、係る技術はＧＰＵメモリを拡張している。ここで、本実施形態の他の例に係るシステムにおいては読み込み先に処理を振り分けているので、係る技術と共存可能と考えられる。
　また、ＯｐｅｎＭＣＣＡというＮＶＤＩＭＭ等のＨｅｔｅｒｏｇｅｎｅｏｕｓ　Ｍｅｍｏｒｙを仮想メモリ空間にマップして統一的にアクセスを可能にする技術が存在する。本実施形態の他の例に係るシステムにおいては単一のメモリ空間を用いず、既存のストレージの名前空間上で、実際にファイルが存在するデバイス名を取得し、そこに処理を転送するものであり、スケールアップ型のＯｐｅｎＭＣＣＡに対し、本実施形態の他の例に係るシステムにおいてはスケールアウト型と考えられる。
　以上、本発明の実施の形態を説明したが、上記に記載した実施の形態は特許請求の範囲に係る発明を限定するものではない。また、実施の形態の中で説明した特徴の組合せの全てが発明の課題を解決するための手段に必須であるとは限らない点に留意すべきである。更に、上記した実施形態の技術的要素は、単独で適用されてもよいし、プログラム部品とハードウエア部品とのような複数の部分に分割されて適用されるようにすることもできる。
　１　システム
　２　プロキシ側システム
　３　スタブ側システム
　４　Ｐｕｂｌｉｃ　ＰａａＳ
　５　デバイス
　１０　キュー
　１２　Ｃｅｐｈ（セフ）
　１４　専用バス
　１６　ｎＶｉｄｉａ　ＧＰＵ
　２０　ＳＳＤ　Ｃｏｎｔｒｏｌｌｅｒ
　３０　ＮＶＭｅ
　５０　制御部
　１００　ＡＰＩ
　２００　ソース取得部
　２０２　演算ロジック特定部
　２０４　デバイス管理部
　２０６　ストレージ統合管理部
　２０８　演算ロジック供給部
　２１０　対応表作成部
　２１２　対応関係決定部
　２１４　実行用コンテキスト作成部
　２１６　送信処理部
　３００　受信処理部
　３０２　メモリ管理部
　３０４　実行イメージ取得部
　３０６　演算ロジック実行部
　３０８　結果格納実行部
　３１０　ＵＲＩ管理部
　３１２　ストレージ機能管理部
　４００　オブジェクトストレージ
　４１０　ＧＰＧＰＵ　ＳａａＳ
　５００　プロセッサー
　６００　ユーザーアプリケーション
　６１０　プロセッサー対応表
　６２０　対応関係

Claims (13)

  1. 　オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、
    　前記ソースコードを取得するソース取得部と、
    　所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定部と、
    　前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給部と、
    　前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成部と、
    　前記演算ロジック供給部が供給した前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定部と
    を備えるシステム。
  2. 　前記ソースコードに基づいて指定されるプロセッサーが、前記システムにおいて用いることができる使用可能プロセッサーであるか否かを確認するデバイス管理部、
    を更に備え、
    　前記演算ロジック供給部が、前記デバイス管理部が前記使用可能プロセッサーの存在を確認した場合、前記演算ロジックを前記使用可能プロセッサーに供給する請求項１に記載のシステム。
  3. 　特定した前記演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かを確認するストレージ統合管理部
    を更に備え、
    　前記デバイス管理部が、前記ストレージ統合管理部において前記アクセスが存在しないと判断した場合に、前記ソースコードに基づいて指定されるプロセッサーが、前記システムにおいて用いることができる使用可能プロセッサーであるか否かを確認する請求項１又は２に記載のシステム。
  4. 　前記ソースコードに基づいて複数のプロセッサーが指定され、
    　前記演算ロジック供給部が、複数の前記指定されたプロセッサーのコンパイラのそれぞれに前記演算ロジックを供給する請求項１～３のいずれか１項に記載のシステム。
  5. 　前記システムが、制御部
    を更に備え、
    　前記オブジェクトストレージが、前記所定のデータのデータ位置に基づいて前記所定のデータを格納し、
    　前記システムが、前記所定のデータへアクセスするポインタとして、所定のスキームと所定の区切りの後に前記スキーム毎に定義された書式によるリソースとが対応付けられているＵｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を前記データ位置の代わりに用い、
    　前記制御部が、前記ＵＲＩに対応付けられている前記スキームが指定するアプリケーションを制御して起動させ、前記ＵＲＩの前記リソースを前記アプリケーションに渡し、
    　前記アプリケーションが、前記リソースに基づいて前記ＵＲＩを前記データ位置として用い、前記ＵＲＩで指定されて前記オブジェクトストレージに格納されるデータを制御する請求項１～４のいずれか１項に記載のシステム。
  6. 　前記オブジェクトストレージが、前記異種混在の複数のデバイスに関するデバイス情報を格納し、
    　前記ユーザーアプリケーションが、前記ユーザーアプリケーションの実行が開始された場合、前記ユーザーアプリケーションの前記演算ロジックがアクセスするデータを指定し、かつ、前記演算ロジックが実行されるデバイスを指定し、
    　前記指定されたデータに基づいて、前記演算ロジックにおいて実行される実行用コンテキストを作成する実行用コンテキスト作成部
    を更に備え、
    　前記デバイス管理部が、前記ユーザーアプリケーションが指定した前記デバイスに関する前記デバイス情報を前記オブジェクトストレージから取得してデータ処理が実行される対象プロセッサーを特定し、
    　前記実行用コンテキスト作成部が、前記プロセッサー対応表及び前記対応関係を参照し、前記演算ロジックに対応付けられた前記プロセッサー対応表における前記対象プロセッサーに対応付けられている前記実行イメージへの前記パスを前記実行用コンテキストに書き込む請求項１～５のいずれか１項に記載のシステム。
  7. 　前記ユーザーアプリケーションが前記演算ロジックの実行を指示した場合、前記パスが書き込まれた前記実行用コンテキストを外部に供給するためにストレージキューに書き込む送信処理部
    を更に備える請求項６に記載のシステム。
  8. 　前記送信処理部から前記パスが書き込まれた前記実行用コンテキストを受信し、当該実行用コンテキストを解読する受信処理部と、
    　解読された実行用コンテキスト内の前記デバイス情報に基づいて、前記演算ロジックが実行される実行環境を準備するメモリ管理部と、
    　解読された実行用コンテキスト内の前記実行イメージへの前記パスに基づいて、前記オブジェクトストレージから前記実行イメージを取得する実行イメージ取得部と、
    　解読された実行用コンテキスト内で指定される前記データを引数として設定し、前記実行環境において前記実行イメージを用いて前記演算ロジックを実行する演算ロジック実行部と
    を更に備える請求項７に記載のシステム。
  9. 　前記演算ロジック実行部において前記演算ロジックが実行された結果を前記オブジェクトストレージに格納する結果格納実行部
    を更に有する請求項８に記載のシステム。
  10. 　前記演算ロジックが、分散処理に用いられる請求項１～９のいずれか１項に記載のシステム。
  11. 　オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、
    　前記演算ロジックをソースコードのまま保持し、
    　前記複数のデバイスのプロセッサーのそれぞれにおいて、前記複数のデバイス用に前記演算ロジックをコンパイルすることで実行イメージを作成し、
    　前記実行イメージを前記オブジェクトストレージに格納し、
    　前記演算ロジックが前記複数のデバイスのうちの一のデバイスに呼び出された場合、前記一のデバイス用に作成された前記実行イメージを前記オブジェクトストレージから前記一のデバイスに供給するシステム。
  12. 　オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムにおける情報処理方法であって、
    　前記ソースコードを取得するソース取得段階と、
    　所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定段階と、
    　前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給段階と、
    　前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成段階と、
    　前記演算ロジック供給段階において供給された前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定段階と
    を備える情報処理方法。
  13. 　オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステム用のプログラムであって、
    　コンピューターに、
    　前記ソースコードを取得するソース取得機能と、
    　所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定機能と、
    　前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給機能と、
    　前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成機能と、
    　前記演算ロジック供給機能において供給された前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定機能と
    を実現させるプログラム。
PCT/JP2019/032996 2018-08-28 2019-08-23 システム、情報処理方法、及びプログラム WO2020045269A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/270,182 US11379202B2 (en) 2018-08-28 2019-08-23 System, information processing method, and program for directly executing arithmetic logic on various storages
JP2020539410A JPWO2020045269A1 (ja) 2018-08-28 2019-08-23 システム、情報処理方法、及びプログラム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2018-159325 2018-08-28
JP2018159325 2018-08-28
JP2019024419 2019-02-14
JP2019-024419 2019-02-14

Publications (1)

Publication Number Publication Date
WO2020045269A1 true WO2020045269A1 (ja) 2020-03-05

Family

ID=69644192

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/032996 WO2020045269A1 (ja) 2018-08-28 2019-08-23 システム、情報処理方法、及びプログラム

Country Status (4)

Country Link
US (1) US11379202B2 (ja)
JP (1) JPWO2020045269A1 (ja)
TW (1) TWI796515B (ja)
WO (1) WO2020045269A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI758778B (zh) * 2020-07-10 2022-03-21 鴻海精密工業股份有限公司 資料讀/寫處理方法、裝置及電腦可讀存儲介質

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000122871A (ja) * 1998-10-14 2000-04-28 Hitachi Ltd アプリケーション配布方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002297556A (ja) * 2001-03-29 2002-10-11 Fujitsu Ltd マルチプロセッサシステム，マルチプロセッサ制御方法，マルチプロセッサ制御プログラムおよび同プログラムを記録したコンピュータ読取可能な記録媒体
KR100518584B1 (ko) * 2003-07-12 2005-10-04 삼성전자주식회사 공유 라이브러리 시스템 및 상기 시스템 구축 방법
JP5434529B2 (ja) * 2009-11-30 2014-03-05 富士通株式会社 イメージファイル管理装置、イメージファイル管理プログラム、イメージファイル配信方法、情報処理装置及び展開プログラム
US8669990B2 (en) * 2009-12-31 2014-03-11 Intel Corporation Sharing resources between a CPU and GPU
WO2011115024A1 (ja) * 2010-03-15 2011-09-22 日本電気株式会社 情報処理装置、情報処理方法及び情報処理プログラム
TWI444824B (zh) * 2011-10-18 2014-07-11 Ind Tech Res Inst 虛擬機器記憶體的鑑識方法與電腦系統
JP2016162266A (ja) * 2015-03-03 2016-09-05 富士通株式会社 通信装置及びそのプロセッサ割当方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000122871A (ja) * 1998-10-14 2000-04-28 Hitachi Ltd アプリケーション配布方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI758778B (zh) * 2020-07-10 2022-03-21 鴻海精密工業股份有限公司 資料讀/寫處理方法、裝置及電腦可讀存儲介質

Also Published As

Publication number Publication date
TWI796515B (zh) 2023-03-21
TW202026862A (zh) 2020-07-16
JPWO2020045269A1 (ja) 2021-08-10
US20210326123A1 (en) 2021-10-21
US11379202B2 (en) 2022-07-05

Similar Documents

Publication Publication Date Title
US10893120B2 (en) Data caching and data-aware placement to accelerate machine learning applications
US11169930B2 (en) Fine grain data migration to or from borrowed memory
EP3230873B1 (en) Computing method and apparatus with persistent memory
US20100186011A1 (en) Methods and systems for implementing transcendent page caching
US11048447B2 (en) Providing direct data access between accelerators and storage in a computing environment, wherein the direct data access is independent of host CPU and the host CPU transfers object map identifying object of the data
US11954042B2 (en) Distributed computing based on memory as a service
CN111309649B (zh) 一种数据传输和任务处理方法、装置及设备
US10061701B2 (en) Sharing of class data among virtual machine applications running on guests in virtualized environment using memory management facility
US10802865B2 (en) Fast instantiation of virtual machines in distributed computing systems
WO2020242683A1 (en) Memory management unit (mmu) for accessing borrowed memory
WO2020045269A1 (ja) システム、情報処理方法、及びプログラム
Potluri et al. Exploring OpenSHMEM model to program GPU-based extreme-scale systems
US20220326986A1 (en) Scheduling workloads on partitioned resources of a host system in a container-orchestration system
US11003488B2 (en) Memory-fabric-based processor context switching system
US20200356538A1 (en) Container-based virtualization for testing database system
US7660939B2 (en) Operating system arrangement for flexible computer system design
US20230205532A1 (en) Offloading computation based on extended instruction set architecture
Chang et al. A virtualization approach to develop middleware for ubiquitous high performance computing

Legal Events

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

Ref document number: 19854014

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020539410

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19854014

Country of ref document: EP

Kind code of ref document: A1