WO2024134922A1 - データ処理装置、プログラム、及びコンピュータ可読記憶媒体 - Google Patents

データ処理装置、プログラム、及びコンピュータ可読記憶媒体 Download PDF

Info

Publication number
WO2024134922A1
WO2024134922A1 PCT/JP2023/019142 JP2023019142W WO2024134922A1 WO 2024134922 A1 WO2024134922 A1 WO 2024134922A1 JP 2023019142 W JP2023019142 W JP 2023019142W WO 2024134922 A1 WO2024134922 A1 WO 2024134922A1
Authority
WO
WIPO (PCT)
Prior art keywords
microservice
storage
data
destination
persistence
Prior art date
Application number
PCT/JP2023/019142
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
Priority claimed from JP2022207104A external-priority patent/JP2024090917A/ja
Application filed by 東芝テック株式会社 filed Critical 東芝テック株式会社
Publication of WO2024134922A1 publication Critical patent/WO2024134922A1/ja

Links

Images

Definitions

  • Embodiments of the present invention relate to a data processing device, a program for causing a computer to function as the data processing device, and a computer-readable storage medium on which the program is recorded.
  • a container is a mechanism that creates a virtual area on the OS (Operating System) and runs and operates applications and their execution environment within it. Furthermore, microservices are provided as a collection of applications within this container. A microservice provided by an application within this container cannot be directly accessed from another application running on the OS other than this microservice.
  • OS Operating System
  • container management tools such as Docker (trademark) provide a data persistence function that saves data stored in virtual volumes in containers to hardware storage or external storage.
  • the destination for data persistence is set when the container management tool deploys (installs) the application in the container, and the information is managed only by the settings at the time of deployment.
  • Another known operational form is to run microservices on an edge device, which is an on-premise data processing device, to provide various services.
  • the designated destination for data persistence is the storage within that edge device. In this way, if the designated destination for data persistence is the storage within the edge device, there is a possibility that the data in the designated destination for persistence will be lost due to storage failure in the edge device, etc. For this reason, it is necessary to back up the data stored in the designated destination for persistence.
  • the destination for data persistence is specified when the microservice (container) is deployed.
  • the control application that controls the edge device cannot know the destination for data persistence. This makes it difficult for the control application to correctly back up the data that the microservice generates and saves in the destination for data persistence.
  • the control application cannot recover data for the microservice from the backed up data because it does not know the destination for data persistence of the container.
  • the problem that the embodiments of the present invention aim to solve is to provide a data processing device and a program therefor that are capable of determining the persistence destination of data generated by a microservice.
  • FIG. 1 is a diagram showing the overall configuration of a data processing system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing a main circuit configuration of an edge device as an embodiment of a data processing device.
  • FIG. 3 is a schematic diagram showing the main data structure of a microservice information table stored in the main memory of the edge device.
  • FIG. 4 is a schematic diagram showing the main software configuration of the edge device.
  • FIG. 5 is a flowchart showing the main information processing steps of the control module of the edge device.
  • FIG. 6 is a flowchart showing the procedure of the microservice deployment process.
  • FIG. 7 is a schematic diagram illustrating an example of the relationship between each software configuration and each storage in an edge device in a microservice deployment process.
  • FIG. 1 is a diagram showing the overall configuration of a data processing system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing a main circuit configuration of an edge device as an embodiment of a data processing device.
  • FIG. 3
  • FIG. 8 is a schematic diagram illustrating an example of the contents of a microservice package input to an edge device.
  • FIG. 9 is a flowchart showing the procedure of the backup process.
  • FIG. 10 is a schematic diagram showing an example of the relationship between each software configuration and each storage in an edge device in a backup process.
  • FIG. 11 is a flowchart showing the procedure of the recovery process.
  • FIG. 12 is a schematic diagram showing an example of the relationship between each software configuration and each storage in an edge device in a recovery process.
  • the data processing device includes an acquisition unit, a storage unit, and an installation control unit.
  • the acquisition unit acquires storage destination information indicating a storage destination in a first storage device to be used for storing data generated by the microservice when installing the microservice.
  • the storage unit saves the storage destination information acquired by the acquisition unit.
  • the installation control unit installs the microservice for which the storage destination information has been acquired.
  • FIG. 1 is an overall configuration diagram of a data processing system according to one embodiment of the present invention.
  • a data processing device according to one embodiment of the present invention is provided as an on-premise edge device 1 at a site B or the like.
  • the edge device 1 is connected to a plurality of IoT (Internet of Things) devices 2 and data storage 3 via a LAN (Local Area Network) 4 within the site B.
  • the edge device 1 is also configured to be able to communicate with a cloud 5, and can download programs and data from a cloud server 51 or cloud storage 52 on the cloud 5, and upload data to the cloud server 51 or cloud storage 52.
  • the edge device 1 is connected to the cloud 5 via a LAN 4 in FIG. 1, it may of course be configured to be directly connected to the cloud 5.
  • the IoT device 2 can be a sensor that detects the operation of machines in the factory, and the data storage 3 can accumulate data acquired by the IoT device 2.
  • the edge device 1 can analyze and process the data acquired by the IoT device 2 and upload it to a cloud server 51 or cloud storage 52 operated by the head office or a data sales service company.
  • base B is a store such as a supermarket
  • the IoT device 2 can be a POS (Point of Sales) terminal in the store
  • the data storage 3 can store a product master that describes the product code, unit price, etc.
  • the edge device 1 can calculate sales using the product code acquired by the IoT device 2 and the product master stored in the data storage 3, analyze and process the sales, and upload it to a cloud server 51 or cloud storage 52 operated by the head office, etc.
  • FIG. 2 is a block diagram showing the main circuit configuration of the edge device 1.
  • the edge device 1 is configured such that a processor 11 is connected to a main memory 12, an auxiliary storage device 13, an input unit 14, an output unit 15, and a communication unit 16.
  • the edge device 1 constitutes a computer by the processor 11, the main memory 12, and the auxiliary storage device 13.
  • the processor 11 corresponds to the central part of the computer.
  • the processor 11 controls each part to realize various functions of the edge device 1 according to the OS and application programs.
  • the processor 11 is, for example, a CPU (Central Processing Unit).
  • the processor 11 may be a processing circuit such as a GPU (Graphics Processing Unit), an Application Specific Integrated Circuit (ASIC), a programmable logic device (for example, a Simple Programmable Logic Device (SPLD), a Complex Programmable Logic Device (CPLD), or a Field Programmable Gate Array (FPGA)).
  • the processor 11 is not limited to being configured as a single processing circuit, and may be configured as the processor 11 by combining multiple processing circuits.
  • the main memory 12 corresponds to the main storage portion of the computer.
  • the main memory 12 includes a non-volatile memory area and a volatile memory area.
  • the main memory 12 stores the OS, application programs, microservices which are containerized application programs, etc.
  • the main memory 12 may store data required for the processor 11 to execute processes for controlling each part in a non-volatile or volatile memory area.
  • the main memory 12 uses a part of the non-volatile memory area as an area for creating a microservice information table 121.
  • This microservice information table 121 stores information about microservices deployed (installed) in the main memory 12, and details thereof will be described later.
  • the main memory 12 also uses the volatile memory area as a work area where data is appropriately rewritten by the processor.
  • the non-volatile memory area is ROM (Read Only Memory).
  • the volatile memory area is RAM (Random Access Memory).
  • the auxiliary storage device 13 corresponds to the auxiliary storage portion of the computer.
  • an EEPROM registered trademark
  • a HDD Hard Disk Drive
  • SSD Solid State Drive
  • the auxiliary storage device 13 stores data used by the processor 11 in performing various processes and data created by the processes in the processor 11.
  • the auxiliary storage device 13 may also store the above-mentioned applications.
  • This auxiliary storage device 13 is configured with a persistence destination storage 131, a backup storage 132, etc.
  • the persistence destination storage 131 is a first storage device that stores data generated by a microservice in order to persist the data.
  • the backup storage 132 is a second storage device that copies and stores the data stored in the persistence destination storage 131 in order to back up the data.
  • the persistence destination storage 131 and the backup storage 132 are configured as physically different storage devices, for example, different physical drives. Alternatively, one can be configured as an SSD and the other as an HDD.
  • the input unit 14 is a user interface such as a keyboard, a touch panel, or a pointing device such as a mouse. Furthermore, the input unit 14 may include a reading device that reads out a microservice package from a computer-readable storage medium such as a disk medium or a memory medium on which a microservice package used for deploying the microservice, as described below, is recorded. Furthermore, the output unit 15 is a user interface such as a display or an output device such as a printer. Note that the edge device 1 does not need to have at least one of the input unit 14 and the output unit 15.
  • the communication unit 16 transmits and/or receives data between each unit connected via the LAN 4.
  • the communication unit 16 also communicates with the cloud 5, downloading application programs, microservice packages, data, etc. from the cloud server 51 and cloud storage 52, and uploading data.
  • FIG. 3 is a schematic diagram showing the main data structure of the microservice information table 121 stored in the main memory 12.
  • the microservice information table 121 stores a microservice ID, persistence destination information, and backup destination information for each microservice deployed to the edge device 1.
  • the microservice ID is unique identification information for identifying a microservice.
  • the persistence destination information is the designated persistence destination path of the persistence destination storage 131 used to store data generated by the microservice.
  • the backup destination information is the storage destination path of the backup storage 132 for backing up that data.
  • FIG. 4 is a schematic diagram showing the main software configuration of the edge device 1.
  • each application is containerized using container technology, and hardware resources are managed by a container management tool.
  • the software configuration shown in FIG. 4 is realized by the processor 11 executing a program stored in the main memory 12 of the edge device 1.
  • an OS 171 is installed in the edge device 1. Furthermore, a container management tool 172 that runs on the OS 171 is installed in the edge device 1.
  • the container management tool 172 includes a container engine, such as Docker, that builds a container environment and runs applications in the container environment, and an orchestration tool, such as Kubernetes (trademark) or k3s, that manages the hardware resources of the container environment.
  • the container engine forms a logical container area by virtualizing hardware resources, etc.
  • the application is configured integrally with the middleware and part of the OS (libraries, settings, file system, etc.) used for operation in the container environment.
  • the containerized application runs in the container area.
  • the OS configured in this container can be of a different type from the OS 171 of the edge device.
  • Such an integral configuration of an application with middleware and part of the OS is called containerization, and a containerized application is sometimes simply called a container.
  • container environment is built by introducing a container engine, and containerizing an application makes it possible to run a container in the container environment.
  • the orchestration tool manages the hardware resources virtualized by the container engine.
  • the orchestration tool builds a logical area called a cluster as an environment in which containerized applications are executed.
  • One or more nodes which are the execution environment for the applications, are provided in the cluster.
  • one or more containers are managed in units called pods.
  • a pod is made up of one or more containers 174.
  • microservices When developing applications using containers, a method called microservices is generally used in which an application is implemented by breaking it down into smaller functions.
  • the orchestration tool is used, the microservices are distributed and deployed in each pod.
  • the microservice 173 is managed as a collection of one or more containers 174.
  • Containerized applications are managed in units of pods.
  • the container management tool 172 causes the microservice 173 to store a data file that records the generated processed data in the persistence destination storage 131.
  • the orchestration tool can not only configure a cluster using the hardware resources of a single edge device 1 in this way, but can also configure one or more clusters using the hardware resources of two or more different devices.
  • the edge device 1 has a control module 175 as an application that runs on the OS 171.
  • This control module 175 controls the deployment of the microservices 173 and the backup and recovery of persisted data.
  • FIG. 5 is a flow chart showing the main information processing steps of the control module 175.
  • the processor 11 of the edge device 1 functions as this control module 175 by executing a data processing program installed in the main memory 12.
  • the control module 175 determines whether or not to deploy, i.e., install, the microservice.
  • the control module 175 can make this determination based on, for example, the presence or absence of a deployment instruction (deployment command) from the input unit 14 by the operator of the edge device 1.
  • the control module 175 can make this determination based on whether or not a deployment instruction has been received via the communication unit 16 from the cloud server 51 on the cloud 5 or a control terminal (not shown).
  • the control module 175 executes a microservice deployment process in Act 2.
  • This microservice deployment process is a process for obtaining a designated destination for data persistence of the microservice 173 and for causing the container management tool 172 to deploy the microservice 173.
  • This microservice deployment process will be described in detail below with reference to Figs. 6 to 8.
  • Fig. 6 is a flow chart showing the procedure of this microservice deployment process.
  • Fig. 7 is a schematic diagram showing an example of the relationship between each software configuration and each storage in the edge device 1 in this microservice deployment process.
  • Fig. 8 is a schematic diagram showing an example of the contents of the microservice package 18.
  • the control module 175 first extracts the data persistence destination of the microservice in Act 21. Specifically, the control module 175 extracts the path of the persistence destination storage 131, which is the designated destination for persisting the data of the microservice, from the microservice package 18 of the microservice to be deployed.
  • the microservice package 18 can be input from the input unit 14 together with a deployment instruction. Alternatively, the control module 175 may download this microservice package 18 from the cloud server 51 or cloud storage 52 via the communication unit 16 based on the address on the cloud 5 indicated in the deployment instruction.
  • the microservice package 18 includes a configuration file 182 in addition to a container image object 181 that is the source of each container 174 in the microservice 173.
  • the configuration file 182 is a text file that describes, in YAML format, the definitions of the containers, networks, volumes, restart policies, etc. used by the microservice.
  • This configuration file 182 also describes the definition of the destination path for data persistence.
  • a folder called "/tmp/storage" in the persistence destination storage 131 is defined as the destination path (Store Path).
  • the container management tool 172 deploys a microservice from this microservice package 18, it extracts this destination path from the configuration file 182 and manages it as the persistence destination.
  • control module 175 extracts the designated destination path for data persistence from the configuration file 182 of this microservice package 18 in Act 21 before the container management tool 172. In this way, the control module 175 functions as an acquisition unit.
  • the control module 175 saves the extracted destination path for data persistence as Act 22. Specifically, the control module 175 associates the extracted destination path for data persistence with a unique microservice ID that identifies the microservice, and stores it as persistence destination information in the microservice information table 121. In this way, the microservice information table 121 functions as a storage unit.
  • control module 175 calls the container management tool 172 as Act 23. That is, the control module 175 passes the input microservice package 18 to the container management tool 172.
  • the container management tool 172 that receives the microservice package 18 through this microservice deployment process deploys (installs) the microservice 173 from the microservice package 18. Therefore, the control module 175 functions as an installation control unit.
  • control module 175 ends this microservice deployment process. Once this microservice deployment process is completed, the control module 175 returns to the above Act 1.
  • the container management tool 172 persists the data generated by the microservice 173, it writes the data to the "/tmp/storage" folder of the destination storage 131.
  • the control module 175 determines whether or not to back up the persisted data in Act 3.
  • the control module 175 can determine this based on, for example, the presence or absence of a backup instruction (backup command) from the input unit 14 by the operator of the edge device 1.
  • the control module 175 can determine this based on whether or not a backup instruction has been received from the cloud server 51 on the cloud 5 or a control terminal (not shown) via the communication unit 16.
  • the control module 175 can determine this based on whether or not it is the time for performing a daily backup. In this way, the backup may be performed irregularly or periodically.
  • a backup process is a process for backing up data stored in a specified destination path of the persistence destination storage 131, which is the persistence destination of the data of the microservice 173, to the backup storage 132.
  • This backup process will be described in detail below with reference to Figs. 9 and 10.
  • Fig. 9 is a flow chart showing the procedure of this backup process.
  • Fig. 10 is a schematic diagram showing an example of the relationship between each software configuration and each storage in the edge device 1 during this backup process.
  • the control module 175 first reads out the designated data persistence path of the microservice 173 to be backed up in Act 41. Specifically, the control module 175 reads out the designated data persistence path that is stored as persistence destination information in the microservice information table 121 and associated with the microservice ID corresponding to the target microservice.
  • control module 175 determines a backup destination in Act 42. Specifically, the control module 175 determines a backup destination folder to be used in the backup storage 132 as the designated backup destination path. This designated backup destination path may correspond to the read designated destination path, may be generated based on the microservice ID, or may be an arbitrary path independent of these. Then, the control module 175 saves the determined backup destination in Act 43. Specifically, the control module 175 associates the designated backup destination path determined in Act 42 with the microservice ID corresponding to the target microservice in the microservice information table 121, and stores it as backup destination information.
  • control module 175 copies the persisted data to the backup destination in Act 44. Specifically, the control module 175 copies the data written to the designated destination path of the data persistence destination of the persistence destination storage 131 to the designated backup destination path of the backup storage 132. Note that the persistence destination storage 131 at the time of backup is also referred to as the pre-exchange persistence destination storage 131-1 below. In this way, the control module 175 functions as a backup unit.
  • control module 175 ends this backup process. Once this backup process is completed, the control module 175 returns to Act 1 above.
  • the control module 175 determines whether or not to recover the backup data in Act 5.
  • the control module 175 can determine this based on, for example, the presence or absence of a recovery instruction (recovery command) from the input unit 14 by the operator of the edge device 1.
  • the recovery instruction is input by the operator, for example, when the hardware of the persistence destination storage 131 is replaced with a new one due to a failure of the persistence destination storage 131 or the like.
  • the control module 175 can determine this based on whether or not a recovery instruction is received via the communication unit 16 from the cloud server 51 on the cloud 5 or a control terminal (not shown).
  • a recovery process in Act 6 This recovery process is a process for recovering data backed up in the backup storage 132 to the destination of data persistence specified by the microservice 173 in the destination storage 131. This backup process will be described in detail below with reference to Figs. 11 and 12.
  • Fig. 11 is a flow chart showing the procedure of the recovery process in Act 6.
  • Fig. 12 is a schematic diagram showing an example of the relationship between each software configuration and each storage in the edge device 1 in this recovery process.
  • control module 175 first reads out the designated data persistence path of one microservice 173 to be recovered in Act 61. Specifically, the control module 175 reads out the designated data persistence path that is associated with one microservice ID and stored as persistence destination information from the microservice information table 121.
  • the control module 175 reads out the backup destination of the data of the microservice 173 to be recovered. Specifically, the control module 175 reads out, from the microservice information table 121, the designated backup path of the backup storage 132, which is stored as backup destination information in association with the microservice ID from which the designated data persistence path was read out.
  • the control module 175 copies the backup data to the persistence destination. Specifically, the control module 175 copies the data backed up in the specified backup destination path to the path of the persistence destination storage 131 indicated by the specified data persistence destination path.
  • the copy destination persistence destination storage 131 is the new replaced hardware, and is not the pre-replacement persistence destination storage 131-1.
  • this replaced persistence destination storage 131 is also referred to as the post-replacement persistence destination storage 131-2. In this way, the control module 175 functions as a recovery unit.
  • the control module 175 determines whether there is any unrecovered data. Specifically, the control module 175 determines whether there is any microservice ID stored in the microservice information table 121 that has not yet been used as a recovery target. If it is determined that there is unrecovered data, the control module 175 returns to the above Act 61.
  • control module 175 If it is determined in Act 64 that there is no unrecovered data, the control module 175 notifies the container management tool 172 of the end of recovery in Act 65.
  • control module 175 ends this recovery process. Once this recovery process is completed, the control module 175 returns to Act 1 above.
  • the container management tool 172 Upon receiving the recovery notification from this recovery process, the container management tool 172 starts the microservice 173. When the container management tool 172 needs data previously generated by the microservice 173, it can read the data from the post-replacement persistence destination storage 131-2, and when the container management tool 172 needs to persist data generated by the microservice 173, it can write the data to the post-replacement persistence destination storage 131-2.
  • the control module 175 realized by the control application that controls the data processing device acquires a designated destination path, which is storage destination information indicating the storage destination in the persistence destination storage 131 used to store data generated by the microservice when deploying (installing) a microservice, saves this in the microservice information table 121, and causes the container management tool 172 to deploy the microservice.
  • the control module 175 is able to grasp the persistence destination of the data generated by the microservice.
  • control module 175 backs up the data generated by the microservice 173 stored in the persistence destination storage 131 to the backup storage 132, which is hardware that is physically different from the persistence destination storage 131, based on the designated destination path for data persistence of the microservice 173 stored in the microservice information table 121, and stores the designated backup destination path of the backup storage 132 in the microservice information table 121. This makes it possible to back up the data generated by the microservice 173.
  • the control module 175 recovers the data backed up in the backup storage 132 to the post-replacement persistence destination storage 131-2 based on the designated backup destination path of the backup storage 132 stored in the microservice information table 121 and the designated data persistence destination path in the pre-replacement persistence destination storage 131-1. Therefore, the backed up data generated by the microservice 173 can be restored to the post-replacement persistence destination storage 131-2 and can be continuously used by the microservice 173.
  • control module 175 extracts the designated destination path for data persistence of the microservice from the microservice package 18, which is the file from which the microservice is installed. Therefore, the control module 175 can easily obtain the designated destination path.
  • the data processing device is an edge device 1 that includes a persistence destination storage 131 and communicates with the cloud 5. Therefore, even if storage within the edge device 1 is specified as the persistence destination of the data of a microservice, the control module 175 can grasp the persistence destination of the data generated by the microservice, and can back up and recover the data. Therefore, in a system involving a container 174 that runs on an on-premise edge device 1, the backup process of the edge device 1 makes it possible to recover data even if the persistence destination storage 131, which is the storage specified for persistence, is damaged.
  • the backup destination of the persisted data may be an external storage rather than the backup storage 132 in the edge device 1.
  • the backup destination may be the same on-premise data storage 3 as the edge device 1, or may be the cloud storage 52 on the cloud 5 with which the edge device 1 communicates.
  • the steps and contents of the flow chart shown in the embodiment are merely examples.
  • the steps and contents can be changed as appropriate as long as similar results can be obtained.
  • the order of Act 41, Act 42, and Act 43 may be reversed, or they may be performed in parallel.
  • the order of the processes may be changed or multiple processes may be performed in parallel, as long as there is no discrepancy with the preceding or subsequent processes.
  • the above-mentioned data processing device is as follows. (1) An acquisition unit that acquires storage destination information indicating a storage destination in a first storage device used to store data generated by the microservice when the microservice is installed; a storage unit for storing the storage destination information acquired by the acquisition unit; an installation control unit that installs the microservice that has acquired the storage destination information; A data processing device comprising: (2) a backup unit that backs up the data generated by the microservice and stored in the first storage device to a second storage device that is physically different from the first storage device, based on the storage destination information stored in the storage unit; The data processing device according to (1) further comprising: (3) a recovery unit that recovers the data stored in the second storage device to the first storage device based on the storage destination information stored in the storage unit; The data processing device according to (2) further comprising: (4) The acquisition unit extracts the storage destination information from a file from which the microservice is installed.
  • a data processing device according to any one of (1) to (3).
  • the data processing device further includes the first storage device and is an edge device that communicates with a cloud.
  • a data processing device according to any one of (1) to (4).
  • the computers that run microservices When installing the microservice A function of acquiring storage destination information indicating a storage destination in a first storage device used to store data generated by the microservice; A function of storing the acquired storage destination information in a memory; A function for installing the microservice; A computer-readable storage medium storing a program for realizing the above.
  • a data processing device comprising: a memory in which a microservice is to be installed; a processor that operates the microservice installed in the memory; and a first storage device used to store data generated by the microservice,
  • the processor When installing the microservice in the memory, acquiring storage destination information indicating a storage destination in the first storage device; storing the acquired storage destination information in the memory; Installing the microservice in the memory; A data processing device that performs the above.
  • the program according to this embodiment may be transferred in a state where it is stored in an electronic device, or in a state where it is not stored in an electronic device. In the latter case, the program may be transferred via a network, or in a state where it is stored in a storage medium.
  • the storage medium is a non-transitory tangible medium.
  • the storage medium is a computer-readable medium.
  • the storage medium may be in any form, such as a CD-ROM or memory card, as long as it is capable of storing a program and is computer-readable.

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

販促効果をより向上するのに有効な表示を情報端末で行えるようにする。データ処理装置は、取得部と、保存部と、インストール制御部と、を備える。取得部は、マイクロサービスをインストールする際に、マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得する。保存部は、取得部が取得した記憶先情報を保存する。インストール制御部は、記憶先情報を取得したマイクロサービスをインストールする。

Description

データ処理装置、プログラム、及びコンピュータ可読記憶媒体
　本発明の実施形態は、データ処理装置、コンピュータを当該データ処理装置として機能させるためのプログラム、及びそのプログラムを記録したコンピュータ可読記憶媒体に関する。
　近年、仮想化技術としてコンテナ技術が知られている。
　コンテナとは、１つの仮想的な領域をＯＳ（Operating System）上に設けて、アプリケーションとその実行環境を、その中で実行・動作させる仕組みとなる。また、このコンテナ内のアプリケーションの集合としてマイクロサービスが提供される。このマイクロサービスとは別の、ＯＳ上で動作している別アプリケーションからは、このコンテナ内のアプリケーションによるマイクロサービスへ直接アクセスすることはできない。
　マイクロサービスのコンテナ内のアプリケーションは、仮想ボリューム内つまりメモリ上にデータを保存しているため、マイクロサービス内のコンテナが削除されると、保存されていたデータも一緒に削除される。そこで、Ｄｏｃｋｅｒ（商標）等のコンテナ管理ツールは、コンテナ内の仮想ボリュームに保存しているデータを、ハードウェア上のストレージや外部ストレージへ保存する、データ永続化機能を提供している。このとき、データ永続化の指定先は、コンテナ管理ツールがコンテナ内のアプリケーションをデプロイ（インストール）するときに設定され、このデプロイ時の設定のみで管理される情報となっている。
　また、マイクロサービスを、オンプレミスのデータ処理装置であるエッジデバイス上で動作させて、各種のサービスを提供する運用形態も知られている。オンプレミスのエッジデバイス上で、マイクロサービスを動作させる場合、データ永続化の指定先は、そのエッジデバイス内のストレージが指定される。このように、エッジデバイス内のストレージをデータ永続化の指定先とすると、エッジデバイスのストレージ故障等により、永続化の指定先のデータが消失する可能性が有る。そのため、永続化の指定先に記憶されたデータのバックアップが求められる。
　データ永続化の指定先は、マイクロサービス（コンテナ）がデプロイされるときに指定される。そのため、エッジデバイスを制御する制御アプリケーションは、永続化の指定先を把握することができない。そのため、制御アプリケーションが、マイクロサービスが生成して永続化の指定先に保存したデータを正しくバックアップすることは困難である。また、永続化の指定先のデータを含めたストレージの全データを、別のストレージにバックアップしていたとしても、制御アプリケーションは、コンテナのデータ永続化の指定先がわからないため、バックアップしたデータからマイクロサービスのためのデータ復旧を行うことはできない。
日本国特開２０２２－９１３０１号公報
　本発明の実施形態が解決しようとする課題は、マイクロサービスが生成したデータの永続化先を把握することが可能なデータ処理装置及びそのプログラムを提供しようとするものである。
図１は、本発明の一実施形態におけるデータ処理システムの全体構成図である。 図２は、データ処理装置の一実施形態としてのエッジデバイスの要部回路構成を示すブロック図である。 図３は、エッジデバイスにおけるメインメモリに保存されるマイクロサービス情報テーブルの主要なデータ構造を示す模式図である。 図４は、エッジデバイスにおける主要なソフトウェア構成を示す模式図である。 図５は、エッジデバイスの制御モジュールの主要な情報処理の手順を示す流れ図である。 図６は、マイクロサービスデプロイ処理の手順を示す流れ図である。 図７は、マイクロサービスデプロイ処理でのエッジデバイスにおける各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。 図８は、エッジデバイスに入力されるマイクロサービスパッケージの内容の一例を示す模式図である。 図９は、バックアップ処理の手順を示す流れ図である。 図１０は、バックアップ処理でのエッジデバイスにおける各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。 図１１は、リカバリ処理の手順を示す流れ図である。 図１２は、リカバリ処理でのエッジデバイスにおける各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。
実施形態
　一実施形態において、データ処理装置は、取得部と、保存部と、インストール制御部と、を備える。取得部は、マイクロサービスをインストールする際に、マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得する。保存部は、取得部が取得した記憶先情報を保存する。インストール制御部は、記憶先情報を取得したマイクロサービスをインストールする。
　以下、データ処理装置の実施形態について、図面を用いて説明する。
　図１は、本発明の一実施形態におけるデータ処理システムの全体構成図である。本発明の一実施形態に係るデータ処理装置は、拠点Ｂ等のオンプレミスのエッジデバイス１として提供される。エッジデバイス１は、複数のＩｏＴ（Internet of Things）デバイス２及びデータストレージ３に、拠点Ｂ内のＬＡＮ（Local Area Network）４を介して接続されている。また、エッジデバイス１は、クラウド５と通信可能に構成され、クラウド５上のクラウドサーバ５１やクラウドストレージ５２からプログラムやデータをダウンロードしたり、クラウドサーバ５１やクラウドストレージ５２にデータをアップロードしたりすることができる。なお、図１では、エッジデバイス１は、ＬＡＮ４を介してクラウド５と接続されるものとしているが、直接クラウド５に接続されるように構成しても良いことは勿論である。
　例えば、拠点Ｂが工場であれば、ＩｏＴデバイス２は工場内の機械の動作を検知するセンサであることができ、データストレージ３は、ＩｏＴデバイス２が取得したデータを蓄積することができる。この場合、エッジデバイス１は、ＩｏＴデバイス２が取得したデータを解析したり加工したりして、本社やデータ販売サービス会社等が運用するクラウドサーバ５１やクラウドストレージ５２にアップロードすることができる。また、拠点Ｂがスーパーマーケット等の店舗であれば、ＩｏＴデバイス２は店舗内のＰＯＳ（Point of Sales）端末であることができ、データストレージ３は、商品のコードや単価等を記載した商品マスタ等を記憶することができる。この場合、エッジデバイス１は、ＩｏＴデバイス２が取得した商品コードとデータストレージ３に記憶された商品マスタとにより売上を演算したり、その売上を解析したり加工したりして、本社等が運用するクラウドサーバ５１やクラウドストレージ５２にアップロードすることができる。
　図２は、エッジデバイス１の要部回路構成を示すブロック図である。エッジデバイス１は、プロセッサ１１に、メインメモリ１２、補助記憶デバイス１３、入力部１４、出力部１５及び通信部１６が接続される構成となっている。エッジデバイス１は、プロセッサ１１、メインメモリ１２及び補助記憶デバイス１３によってコンピュータを構成する。
　プロセッサ１１は、上記コンピュータの中枢部分に相当する。プロセッサ１１は、ＯＳやアプリケーションプログラムに従って、エッジデバイス１としての各種の機能を実現するべく各部を制御する。プロセッサ１１は、例えばＣＰＵ（Central Processing Unit）である。プロセッサ１１は、ＧＰＵ（Graphics Processing Unit）、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ））、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Simple Programmable Logic Device：ＳＰＬＤ）、複合プログラマブル論理デバイス（Complex Programmable Logic Device：ＣＰＬＤ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ））等の処理回路であって良い。プロセッサ１１は、単一の処理回路として構成される場合に限らず、複数の処理回路を組み合わせてプロセッサ１１として構成しても良い。
　メインメモリ１２は、上記コンピュータの主記憶部分に相当する。メインメモリ１２は、不揮発性のメモリ領域と揮発性のメモリ領域とを含む。メインメモリ１２は、不揮発性のメモリ領域ではＯＳ、アプリケーションプログラム、コンテナ化されたアプリケーションプログラムであるマイクロサービス、等を記憶する。メインメモリ１２は、プロセッサ１１が各部を制御するための処理を実行する上で必要なデータを不揮発性又は揮発性のメモリ領域で記憶する場合も有る。メインメモリ１２は、不揮発性のメモリ領域の一部を、マイクロサービス情報テーブル１２１の作成領域としている。このマイクロサービス情報テーブル１２１は、メインメモリ１２にデプロイ（インストール）されたマイクロサービスに関する情報を記憶するものであり、その詳細については後述する。また、メインメモリ１２は、揮発性のメモリ領域を、プロセッサによってデータが適宜書き換えられるワークエリアとして使用する。例えば不揮発性のメモリ領域はＲＯＭ（Read Only Memory）である。揮発性のメモリ領域はＲＡＭ（Random Access Memory）である。
　補助記憶デバイス１３は、上記コンピュータの補助記憶部分に相当する。例えばＥＥＰＲＯＭ（登録商標）（Electric Erasable Programmable Read-Only Memory）、ＨＤＤ（Hard Disk Drive）、或いはＳＳＤ（Solid State Drive）等が補助記憶デバイス１３として使用される。補助記憶デバイス１３は、プロセッサ１１が各種の処理を行う上で使用するデータや、プロセッサ１１での処理によって作成されたデータを保存する。補助記憶デバイス１３は、上記のアプリケーションを記憶する場合も有る。この補助記憶デバイス１３には、永続化先ストレージ１３１、バックアップストレージ１３２等が構成される。永続化先ストレージ１３１は、マイクロサービスが生成したデータを永続化するために、当該データを記憶する第１の記憶装置である。バックアップストレージ１３２は、永続化先ストレージ１３１に記憶されたデータのバックアップのために、そのデータをコピーして記憶する第２の記憶装置である。永続化先ストレージ１３１とバックアップストレージ１３２とは、互いに物理的に異なる記憶デバイス、例えば異なる物理ドライブに構成される。或いは、一方がＳＳＤに構成され、他方がＨＤＤに構成されることができる。
　入力部１４は、キーボード、タッチパネル、マウス等のポインティングデバイス、等のユーザインタフェースである。更に、入力部１４は、後述するようなマイクロサービスのデプロイに使用するマイクロサービスパッケージを記録したディスク媒体やメモリ媒体等のコンピュータ可読記憶媒体からマイクロサービスパッケージを読み出す読み取り装置を含んでも良い。また、出力部１５は、ディスプレイ等のユーザインタフェースやプリンタ等の出力装置である。なお、エッジデバイス１は、これら入力部１４及び出力部１５の少なくとも一方を有さなくても良い。
　通信部１６は、ＬＡＮ４を介して接続される各部との間でデータの送信及び／又は受信を行う。また、通信部１６は、クラウド５と通信を行い、クラウドサーバ５１やクラウドストレージ５２からアプリケーションプログラム、マイクロサービスパッケージ、データ、等をダウンロードしたり、データをアップロードしたりする。
　図３は、メインメモリ１２に保存されるマイクロサービス情報テーブル１２１の主要なデータ構造を示す模式図である。マイクロサービス情報テーブル１２１は、エッジデバイス１にデプロイされたマイクロサービス毎に、マイクロサービスＩＤ、永続化先情報及びバックアップ先情報を記憶する。マイクロサービスＩＤは、マイクロサービスを識別するための一意の識別情報である。永続化先情報は、そのマイクロサービスが生成したデータを記憶するために使用する永続化先ストレージ１３１の永続化の指定先パスである。バックアップ先情報は、そのデータをバックアップするためのバックアップストレージ１３２の記憶先パスである。
　図４は、エッジデバイス１における主要なソフトウェア構成を示す模式図である。本実施形態においては、コンテナ技術により、それぞれのアプリケーションがコンテナ化されると共に、コンテナ管理ツールによりハードウェアリソースの管理がされている。図４に示すソフトウェア構成は、エッジデバイス１のメインメモリ１２に記憶されたプログラムをプロセッサ１１が実行することで実現されている。
　図４に示されるように、エッジデバイス１には、ＯＳ１７１がインストールされている。更に、エッジデバイス１には、ＯＳ１７１上で動作するコンテナ管理ツール１７２がインストールされている。コンテナ管理ツール１７２は、Ｄｃｋｅｒ等の、コンテナ環境の構築及びコンテナ環境におけるアプリケーションの実行を行うコンテナエンジンや、Ｋｕｂｅｒｎｅｔｅｓ（商標）やｋ３ｓ等の、コンテナ環境のハードウェアリソースを管理するオーケストレーションツールを含む。
　コンテナエンジンは、ハードウェアリソース等を仮想化することで論理的なコンテナ領域を形成する。そして、アプリケーションは、コンテナ環境での動作に用いるミドルウェア及びＯＳの一部（ライブラリ、設定、ファイルシステム、等）と一体的に構成されている。その結果、コンテナ化されたアプリケーションは、コンテナ領域で動作する。なお、このコンテナに構成されるＯＳは、エッジデバイスのＯＳ１７１とは異なる種類のものであることができる。このようなアプリケーションとミドルウェア及びＯＳの一部とを一体的に構成することを、コンテナ化と称し、また、コンテナ化されたアプリケーションを、単にコンテナと称することも有る。このように、コンテナエンジンを導入することでコンテナ環境が構築され、アプリケーションをコンテナ化することで、コンテナ環境においてコンテナの実行が可能となる。
　オーケストレーションツールは、コンテナエンジンによって仮想化されたハードウェアリソースを管理する。詳細には、オーケストレーションツールは、コンテナ化されたアプリケーションが実行される環境として、クラスタと称される論理領域を構築する。クラスタには、アプリケーションの実行環境であるノードが１以上設けられる。ノードにおいては、１以上のコンテナが、ポッドという単位で管理される。ポッドは、１以上のコンテナ１７４により構成される。コンテナを用いてアプリケーションを開発する場合、一般的に、アプリケーションを機能毎に細分化して実装するマイクロサービスと称される手法が用いられる。オーケストレーションツールを用いると、マイクロサービスが各ポッドに分散して配置される。
　よって、このようにコンテナ管理ツール１７２が導入された環境においては、図４に示すように、マイクロサービス１７３は、１以上のコンテナ１７４の集合として管理されることとなる。コンテナ化されたアプリケーションはポッドの単位で管理される。コンテナ管理ツール１７２は、マイクロサービス１７３が定められた処理を終える毎に、マイクロサービス１７３に、生成した処理済データを記録するデータファイルを永続化先ストレージ１３１に記憶させる。
　なお、オーケストレーションツールは、このように１つのエッジデバイス１のハードウェアリソースを用いてクラスタを構成するだけでなく、２以上の異なるデバイスのハードウェアリソースを用いて１以上のクラスタを構成することもできる。
　そして更に、本実施形態では、エッジデバイス１は、ＯＳ１７１上で動作するアプリケーションとして、制御モジュール１７５を有する。この制御モジュール１７５は、マイクロサービス１７３のデプロイ、永続化されたデータのバックアップ及びリカバリを制御する。
　以下、この制御モジュール１７５の動作を中心にして、エッジデバイス１の動作を説明する。
　図５は、制御モジュール１７５の主要な情報処理の手順を示す流れ図である。エッジデバイス１のプロセッサ１１は、メインメモリ１２にインストールされたデータ処理プログラムを実行することで、この制御モジュール１７５として機能する。
　先ず、制御モジュール１７５は、Ａｃｔ１として、マイクロサービスをデプロイ即ちインストールするか否か判断する。制御モジュール１７５は、例えば、エッジデバイス１の操作者による入力部１４からのデプロイ指示（デプロイコマンド）の有無により、これを判断することができる。或いは、制御モジュール１７５は、通信部１６により、クラウド５上のクラウドサーバ５１や図示しない制御端末から、デプロイ指示を受信したか否かにより、これを判断することができる。
　マイクロサービスをデプロイすると判断すると、制御モジュール１７５は、Ａｃｔ２として、マイクロサービスデプロイ処理を実行する。このマイクロサービスデプロイ処理は、マイクロサービス１７３のデータ永続化の指定先を取得すると共に、コンテナ管理ツール１７２にマイクロサービス１７３をデプロイさせる処理である。以下、図６乃至図８を参照して、このマイクロサービスデプロイ処理を詳細に説明する。ここで、図６は、このマイクロサービスデプロイ処理の手順を示す流れ図である。また、図７は、このマイクロサービスデプロイ処理でのエッジデバイス１における各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。そして、図８は、マイクロサービスパッケージ１８の内容の一例を示す模式図である。
　（１）このマイクロサービスデプロイ処理においては、制御モジュール１７５は、先ず、Ａｃｔ２１として、そのマイクロサービスのデータ永続化先を抽出する。具体的には、制御モジュール１７５は、デプロイするべきマイクロサービスのマイクロサービスパッケージ１８から、そのマイクロサービスのデータを永続化する指定先である永続化先ストレージ１３１のパスを抽出する。マイクロサービスパッケージ１８は、デプロイ指示と共に、入力部１４から入力されることができる。或いは、制御モジュール１７５が、デプロイ指示で示されるクラウド５上のアドレスに基づいて、通信部１６によりクラウドサーバ５１又はクラウドストレージ５２から、このマイクロサービスパッケージ１８をダウンロードするようにしても良い。
　図８に示すように、マイクロサービスパッケージ１８は、マイクロサービス１７３における各コンテナ１７４の元となるコンテナイメージオブジェクト１８１に加えて、設定ファイル１８２を含む。設定ファイル１８２は、そのマイクロサービスが使用するコンテナ、ネットワーク、ボリューム、再起動ポリシー、等のそれぞれの定義をＹＡＭＬ形式で記載したテキストファイルである。この設定ファイル１８２には、データ永続化の指定先パスの定義も記載されている。図８の例では、指定先パス（Store Path）として、永続化先ストレージ１３１における「/tmp/storage」というフォルダが定義されている。コンテナ管理ツール１７２は、このマイクロサービスパッケージ１８からマイクロサービスをデプロイする際に、設定ファイル１８２からこの指定先パスを抽出して、永続化先として管理する。
　本実施形態では、制御モジュール１７５は、コンテナ管理ツール１７２よりも前に、Ａｃｔ２１において、このマイクロサービスパッケージ１８の設定ファイル１８２からデータ永続化の指定先パスを抽出する。このように、制御モジュール１７５は、取得部として機能する。
　（２）そして、制御モジュール１７５は、Ａｃｔ２２として、その抽出したデータ永続化の指定先パスを保存する。具体的には、制御モジュール１７５は、その抽出したデータ永続化の指定先パスを、マイクロサービス情報テーブル１２１に、そのマイクロサービスを特定する一意のマイクロサービスＩＤと紐付けて、永続化先情報として記憶させる。このように、マイクロサービス情報テーブル１２１は、保存部として機能する。
　（３）その後、制御モジュール１７５は、Ａｃｔ２３として、コンテナ管理ツール１７２をコールする。即ち、制御モジュール１７５は、入力されたマイクロサービスパッケージ１８をコンテナ管理ツール１７２に渡す。
　（４）なお、このマイクロサービスデプロイ処理によりマイクロサービスパッケージ１８を受けたコンテナ管理ツール１７２は、そのマイクロサービスパッケージ１８よりマイクロサービス１７３をデプロイ（インストール）することとなる。よって、制御モジュール１７５は、インストール制御部として機能する。
　そして、制御モジュール１７５は、このマイクロサービスデプロイ処理を終了する。このマイクロサービスデプロイ処理が終了したならば、制御モジュール１７５は、上記Ａｃｔ１に戻る。
　（５）そして、コンテナ管理ツール１７２は、マイクロサービス１７３が生成したデータを永続化する際には、そのデータを、永続化先ストレージ１３１の「/tmp/storage」フォルダに書き込む。
　図５の説明に戻る。　
　上記Ａｃｔ１においてマイクロサービスをデプロイしないと判断すると、制御モジュール１７５は、Ａｃｔ３として、永続化されたデータをバックアップするか否か判断する。制御モジュール１７５は、例えば、エッジデバイス１の操作者による入力部１４からのバックアップ指示（バックアップコマンド）の有無により、これを判断することができる。或いは、制御モジュール１７５は、通信部１６により、クラウド５上のクラウドサーバ５１や図示しない制御端末から、バックアップ指示を受信したか否かにより、これを判断することができる。また、制御モジュール１７５は、毎日の決められたバックアップ実行時間となったか否かにより、これを判断することができる。このように、バックアップは不定期に実施しても良いし、定期的に実施するものであっても構わない。
　永続化されたデータをバックアップすると判断すると、制御モジュール１７５は、Ａｃｔ４として、バックアップ処理を実行する。このバックアップ処理は、マイクロサービス１７３のデータの永続化先である永続化先ストレージ１３１の指定先パスに記憶されているデータをバックアップストレージ１３２にバックアップする処理である。以下、図９及び図１０を参照して、このバックアップ処理を詳細に説明する。ここで、図９は、このバックアップ処理の手順を示す流れ図である。また、図１０は、このバックアップ処理でのエッジデバイス１における各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。
　（１）このバックアップ処理においては、制御モジュール１７５は、先ず、Ａｃｔ４１として、バックアップ対象のマイクロサービス１７３のデータ永続化の指定先パスを読み出す。具体的には、制御モジュール１７５は、マイクロサービス情報テーブル１２１において、対象のマイクロサービスに対応するマイクロサービスＩＤに紐付けて永続化先情報として記憶されているデータ永続化の指定先パスを読み出す。
　（２）また、制御モジュール１７５は、Ａｃｔ４２として、バックアップ先を決定する。具体的には、制御モジュール１７５は、バックアップの指定先パスとして、バックアップストレージ１３２において使用するバックアップ先フォルダを決定する。このバックアップの指定先パスは、読み出した指定先パスに対応させても良いし、マイクロサービスＩＤに基づいて生成しても良いし、それらに依存しない任意のパスとしても良い。そして、制御モジュール１７５は、Ａｃｔ４３として、その決定したバックアップ先を保存する。具体的には、制御モジュール１７５は、マイクロサービス情報テーブル１２１の対象のマイクロサービスに対応するマイクロサービスＩＤに紐付けて、Ａｃｔ４２で決定したバックアップの指定先パスをバックアップ先情報として記憶させる。
　（３）その後、制御モジュール１７５は、Ａｃｔ４４として、永続化されたデータをバックアップ先にコピーする。具体的には、制御モジュール１７５は、永続化先ストレージ１３１のデータの永続化先の指定先パスに書き込まれているデータを、バックアップストレージ１３２のバックアップの指定先パスにコピーする。なお、このバックアップ時点の永続化先ストレージ１３１を、以下では、交換前永続化先ストレージ１３１－１とも称する。このように、制御モジュール１７５は、バックアップ部として機能する。
　そして、制御モジュール１７５は、このバックアップ処理を終了する。このバックアップ処理が終了したならば、制御モジュール１７５は、上記Ａｃｔ１に戻る。
　図５の説明に戻る。　
　上記Ａｃｔ３において永続化されたデータをバックアップしないと判断すると、制御モジュール１７５は、Ａｃｔ５として、バックアップデータのリカバリをするか否か判断する。制御モジュール１７５は、例えば、エッジデバイス１の操作者による入力部１４からのリカバリ指示（リカバリコマンド）の有無により、これを判断することができる。リカバリ指示は、例えば、永続化先ストレージ１３１の故障等により、永続化先ストレージ１３１のハードウェアを新しいものに交換したとき、操作者によって入力される。或いは、制御モジュール１７５は、通信部１６により、クラウド５上のクラウドサーバ５１や図示しない制御端末から、リカバリ指示を受信したか否かにより、これを判断することができる。
　バックアップデータのリカバリをすると判断すると、制御モジュール１７５は、Ａｃｔ６として、リカバリ処理を実行する。このリカバリ処理は、バックアップストレージ１３２にバックアップしてあるデータを、永続化先ストレージ１３１の、マイクロサービス１７３のデータ永続化の指定先にリカバリする処理である。以下、図１１及び図１２を参照して、このバックアップ処理を詳細に説明する。ここで、図１１は、このＡｃｔ６のリカバリ処理の手順を示す流れ図である。また、図１２は、このリカバリ処理でのエッジデバイス１における各ソフトウェア構成と各ストレージとの関係の一例を示す模式図である。
　このリカバリ処理においては、制御モジュール１７５は、先ず、Ａｃｔ６１として、１つのリカバリ対象のマイクロサービス１７３のデータ永続化の指定先パスを読み出す。具体的には、制御モジュール１７５は、マイクロサービス情報テーブル１２１から、１つのマイクロサービスＩＤに紐付けて永続化先情報として記憶されているデータ永続化の指定先パスを読み出す。
　（２）更に、制御モジュール１７５は、Ａｃｔ６２として、リカバリ対象のマイクロサービス１７３のデータのバックアップ先を読み出す。具体的には、制御モジュール１７５は、マイクロサービス情報テーブル１２１から、データ永続化の指定先パスを読み出したマイクロサービスＩＤに紐付けてバックアップ先情報として記憶されている、バックアップストレージ１３２のバックアップの指定先パスを読み出す。
　（３）そして、制御モジュール１７５は、Ａｃｔ６３として、バックアップデータを永続化先にコピーする。具体的には、制御モジュール１７５は、バックアップの指定先パスにバックアップされているデータを、データ永続化の指定先パスで示される永続化先ストレージ１３１のパスにコピーする。この場合のコピー先の永続化先ストレージ１３１は、交換された新しいハードウェアであり、交換前永続化先ストレージ１３１－１ではない。以下では、この交換された永続化先ストレージ１３１を交換後永続化先ストレージ１３１－２とも称する。このように、制御モジュール１７５は、リカバリ部として機能する。
　その後、制御モジュール１７５は、Ａｃｔ６４として、未リカバリのデータが有るか否か判断する。具体的には、制御モジュール１７５は、マイクロサービス情報テーブル１２１に記憶されているマイクロサービスＩＤの内、未だリカバリ対象として使用していないものが有るか否かを判断する。未リカバリのデータが有ると判断すると、制御モジュール１７５は、上記Ａｃｔ６１に戻る。
　（４）上記Ａｃｔ６４において未リカバリのデータが無いと判断すると、制御モジュール１７５は、Ａｃｔ６５として、コンテナ管理ツール１７２にリカバリ終了を通知する。
　そして、制御モジュール１７５は、このリカバリ処理を終了する。このリカバリ処理が終了したならば、制御モジュール１７５は、上記Ａｃｔ１に戻る。
　（５）なお、このリカバリ処理によりリカバリ通知を受けたコンテナ管理ツール１７２は、マイクロサービス１７３を開始することとなる。そして、コンテナ管理ツール１７２は、マイクロサービス１７３が過去に生成したデータを必要とする際には、そのデータを交換後永続化先ストレージ１３１－２から読み出し、また、マイクロサービス１７３が生成したデータを永続化する際には、そのデータを交換後永続化先ストレージ１３１－２に書き込むことができる。
　以上詳述したように、本実施形態によれば、データ処理装置を制御する制御アプリケーションにより実現される制御モジュール１７５は、マイクロサービスをデプロイ（インストール）する際に、マイクロサービスが生成したデータを記憶するために使用する永続化先ストレージ１３１における記憶先を示す記憶先情報である指定先パスを取得し、それをマイクロサービス情報テーブル１２１に保存しておくと共に、コンテナ管理ツール１７２にそのマイクロサービスをデプロイさせる。よって、制御モジュール１７５は、マイクロサービスが生成したデータの永続化先を把握することが可能となる。
　そして、本実施形態によれば、制御モジュール１７５は、マイクロサービス情報テーブル１２１に保存されたマイクロサービス１７３のデータ永続化の指定先パスに基づいて、永続化先ストレージ１３１に記憶されているマイクロサービス１７３が生成したデータを、永続化先ストレージ１３１とは物理的に異なるハードウェアであるバックアップストレージ１３２にバックアップすると共に、そのバックアップストレージ１３２のバックアップの指定先パスをマイクロサービス情報テーブル１２１に保存しておく。よって、マイクロサービス１７３が生成したデータをバックアップしておくことが可能となる。
　その後に、バックアップストレージ１３２へのバックアップがされたデータを記憶している永続化先ストレージ１３１である交換前永続化先ストレージ１３１－１が故障して、新しい永続化先ストレージ１３１である交換後永続化先ストレージ１３１－２に交換されると、本実施形態によれば、制御モジュール１７５は、マイクロサービス情報テーブル１２１に保存されたバックアップストレージ１３２のバックアップの指定先パスと交換前永続化先ストレージ１３１－１におけるデータ永続化の指定先パスとに基づいて、バックアップストレージ１３２にバックアップしてあるデータを、交換後永続化先ストレージ１３１－２にリカバリする。よって、バックアップしておいたマイクロサービス１７３が生成したデータを交換後永続化先ストレージ１３１－２に復旧させ、マイクロサービス１７３に引き続き利用させることが可能となる。
　なお、本実施形態によれば、制御モジュール１７５は、マイクロサービスのインストール元のファイルであるマイクロサービスパッケージ１８から、マイクロサービスのデータ永続化の指定先パスを抽出する。よって、制御モジュール１７５は、容易に指定先パスを取得することができる。
　また、本実施形態に係るデータ処理装置は、永続化先ストレージ１３１を備え、クラウド５と通信を行うエッジデバイス１である。よって、エッジデバイス１内のストレージがマイクロサービスのデータの永続化先に指定されていても、制御モジュール１７５は、マイクロサービスが生成したデータの永続化先を把握することが可能となり、そのデータのバックアップ及びリカバリを行い得るようになる。従って、オンプレミスのエッジデバイス１上で動作するコンテナ１７４を伴うシステムにおいて、エッジデバイス１のバックアップ処理によって、永続化の指定先のストレージである永続化先ストレージ１３１が破損してもデータの復旧を行うことが可能となる。
　以上、一実施形態について説明したが、本発明はこれに限定されるものではない。
　例えば、永続化されたデータのバックアップ先は、エッジデバイス１内のバックアップストレージ１３２ではなくて、外部ストレージであっても良い。例えば、バックアップ先は、エッジデバイス１と同一オンプレミスのデータストレージ３としても良いし、エッジデバイス１が通信するクラウド５上のクラウドストレージ５２としても良い。
　また、実施形態に示した流れ図の手順及びその内容は一例である。同様な結果を得ることが可能であればその手順及び内容は適宜変更することができる。例えば、Ａｃｔ４１とＡｃｔ４２及びＡｃｔ４３とは、その順序が逆であっても良いし、並行して行っても良い。このように、先行の又は後続する処理と齟齬が生じない限り、処理の順序を変更したり、複数の処理を並行して行ったりしても良い。
　上記したデータ処理装置は、以下の通りである。
（１）
　マイクロサービスをインストールする際に、前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得する取得部と、
　前記取得部が取得した前記記憶先情報を保存する保存部と、
　前記記憶先情報を取得した前記マイクロサービスをインストールするインストール制御部と、
　を具備する、データ処理装置。
（２）
　前記保存部に保存された前記記憶先情報に基づいて、前記第１の記憶装置に記憶されている前記マイクロサービスが生成したデータを、前記第１の記憶装置とは物理的に異なる第２の記憶装置にバックアップするバックアップ部、
　を更に具備する、（１）に記載のデータ処理装置。
（３）
　前記保存部に保存された前記記憶先情報に基づいて、前記第２の記憶装置に記憶されているデータを、前記第１の記憶装置にリカバリするリカバリ部、
　を更に具備する、（２）に記載のデータ処理装置。
（４）
　前記取得部は、前記マイクロサービスのインストール元のファイルから前記記憶先情報を抽出する、
　（１）乃至（３）の何れか一つに記載のデータ処理装置。
（５）
　前記データ処理装置は、前記第１の記憶装置を更に具備し、クラウドと通信を行うエッジデバイスである、
　（１）乃至（４）の何れか一つに記載のデータ処理装置。
（６）
　マイクロサービスを動作させるコンピュータに、
　　前記マイクロサービスをインストールする際に、
　　　前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得させる機能と、
　　　取得された前記記憶先情報をメモリに保存させる機能と、
　　　前記マイクロサービスをインストールさせる機能と、
を実現させるためのプログラム。
（７）
　マイクロサービスを動作させるコンピュータに、
　　前記マイクロサービスをインストールする際に、
　　　前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得させる機能と、
　　　取得された前記記憶先情報をメモリに保存させる機能と、
　　　前記マイクロサービスをインストールさせる機能と、
を実現させるためのプログラムを記憶したコンピュータ可読記憶媒体。
（８）
　マイクロサービスがインストールされるべきメモリと、前記メモリにインストールされた前記マイクロサービスを動作させるプロセッサと、前記マイクロサービスが生成したデータを記憶するために使用する第１の記憶装置と、を備えるデータ処理装置であって、
　前記プロセッサは、
　　前記メモリに前記マイクロサービスをインストールする際に、
　　　前記第１の記憶装置における記憶先を示す記憶先情報を取得し、
　　　取得された前記記憶先情報を前記メモリに保存し、
　　　前記マイクロサービスを前記メモリにインストールする、
ことを実行する、データ処理装置。
　本実施形態に係るプログラムは、電子機器に記憶された状態で譲渡されて良いし、電子機器に記憶されていない状態で譲渡されても良い。後者の場合は、プログラムは、ネットワークを介して譲渡されて良いし、記憶媒体に記憶された状態で譲渡されても良い。記憶媒体は、非一時的な有形の媒体である。記憶媒体は、コンピュータ可読媒体である。記憶媒体は、ＣＤ－ＲＯＭ、メモリカード等のプログラムを記憶可能かつコンピュータで読取可能な媒体であれば良く、その形態は問わない。
　なお、実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (7)

  1. 　マイクロサービスをインストールする際に、前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得する取得部と、
    　前記取得部が取得した前記記憶先情報を保存する保存部と、
    　前記記憶先情報を取得した前記マイクロサービスをインストールするインストール制御部と、
    　を具備する、データ処理装置。
  2. 　前記保存部に保存された前記記憶先情報に基づいて、前記第１の記憶装置に記憶されている前記マイクロサービスが生成したデータを、前記第１の記憶装置とは物理的に異なる第２の記憶装置にバックアップするバックアップ部、
    　を更に具備する、請求項１に記載のデータ処理装置。
  3. 　前記保存部に保存された前記記憶先情報に基づいて、前記第２の記憶装置に記憶されているデータを、前記第１の記憶装置にリカバリするリカバリ部、
    　を更に具備する、請求項２に記載のデータ処理装置。
  4. 　前記取得部は、前記マイクロサービスのインストール元のファイルから前記記憶先情報を抽出する、
    　請求項１に記載のデータ処理装置。
  5. 　前記データ処理装置は、前記第１の記憶装置を更に具備し、クラウドと通信を行うエッジデバイスである、
    　請求項１乃至４の何れか１項に記載のデータ処理装置。
  6. 　マイクロサービスを動作させるコンピュータに、
    　　前記マイクロサービスをインストールする際に、
    　　　前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得させる機能と、
    　　　取得された前記記憶先情報をメモリに保存させる機能と、
    　　　前記マイクロサービスをインストールさせる機能と、
    を実現させるためのプログラム。
  7. 　マイクロサービスを動作させるコンピュータに、
    　　前記マイクロサービスをインストールする際に、
    　　　前記マイクロサービスが生成したデータを記憶するために使用する、第１の記憶装置における記憶先を示す記憶先情報を取得させる機能と、
    　　　取得された前記記憶先情報をメモリに保存させる機能と、
    　　　前記マイクロサービスをインストールさせる機能と、
    を実現させるためのプログラムを記憶したコンピュータ可読記憶媒体。
PCT/JP2023/019142 2022-12-23 2023-05-23 データ処理装置、プログラム、及びコンピュータ可読記憶媒体 WO2024134922A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022207104A JP2024090917A (ja) 2022-12-23 データ処理装置及びそのプログラム
JP2022-207104 2022-12-23

Publications (1)

Publication Number Publication Date
WO2024134922A1 true WO2024134922A1 (ja) 2024-06-27

Family

ID=91587951

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/019142 WO2024134922A1 (ja) 2022-12-23 2023-05-23 データ処理装置、プログラム、及びコンピュータ可読記憶媒体

Country Status (1)

Country Link
WO (1) WO2024134922A1 (ja)

Similar Documents

Publication Publication Date Title
US10394547B2 (en) Applying update to snapshots of virtual machine
US9665386B2 (en) Method for leveraging hypervisor functionality for maintaining application consistent snapshots in a virtualization environment
EP2840495B1 (en) Container-based processing method and apparatus
US8307363B2 (en) Virtual machine system, restarting method of virtual machine and system
EP2731013B1 (en) Backing up method, device, and system for virtual machine
US20150095597A1 (en) High performance intelligent virtual desktop infrastructure using volatile memory arrays
US20140047268A1 (en) Systems, Methods, and Computer Program Products for Instant Recovery of Image Level Backups
US20150331757A1 (en) One-click backup in a cloud-based disaster recovery system
US9069640B2 (en) Patch applying method for virtual machine, storage system adopting patch applying method, and computer system
US10795688B2 (en) System and method for performing an image-based update
WO2017183565A1 (ja) ネットワークシステム、パッチファイル適用方法、及び記録媒体
US11327850B2 (en) System and method for disaster recovery using application streaming
JP5728812B2 (ja) 分散型情報処理システム及び分散ストレージシステム
CN102591675A (zh) 使用共享存储块管理多软件镜像的方法和系统
JP4874908B2 (ja) 情報処理システム、および監視方法
US11803412B2 (en) Containerized application management system and management method
US9846621B1 (en) Disaster recovery—multiple restore options and automatic management of restored computing devices
JP2021174495A (ja) コンピュータシステムを動作可能状態に選択的に復元するシステムおよび方法
US10095616B2 (en) Garbage collection for virtual environments
EP2639698B1 (en) Backup control program, backup control method, and information processing device
CN113342365A (zh) 操作系统部署方法、装置、设备及计算机可读存储介质
WO2024134922A1 (ja) データ処理装置、プログラム、及びコンピュータ可読記憶媒体
US9665582B2 (en) Software, systems, and methods for enhanced replication within virtual machine environments
WO2023087622A1 (zh) 虚拟机引导的配置方法、装置、计算机设备和存储介质
US20140380089A1 (en) Method and apparatus for recovering failed disk in virtual machine