WO2023021731A1 - 計算機システム及び更新制御方法 - Google Patents
計算機システム及び更新制御方法 Download PDFInfo
- Publication number
- WO2023021731A1 WO2023021731A1 PCT/JP2022/006472 JP2022006472W WO2023021731A1 WO 2023021731 A1 WO2023021731 A1 WO 2023021731A1 JP 2022006472 W JP2022006472 W JP 2022006472W WO 2023021731 A1 WO2023021731 A1 WO 2023021731A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- request
- target
- cluster
- component
- components
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 38
- 238000012544 monitoring process Methods 0.000 claims abstract description 61
- 230000008569 process Effects 0.000 claims description 14
- 230000005540 biological transmission Effects 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 8
- 238000012545 processing Methods 0.000 description 23
- 238000010586 diagram Methods 0.000 description 17
- 230000005012 migration Effects 0.000 description 11
- 238000013508 migration Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 6
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 239000000284 extract Substances 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000005096 rolling process Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
Definitions
- the present invention relates to technology for upgrading components that make up a service.
- Container technology is one of the virtualization technologies that uses the resources of a single physical computer to run multiple applications, and is an execution environment for applications isolated on an OS (Operating System) that runs on a single physical computer. It is a technology that provides In this specification, an isolated application execution environment is referred to as a container. Containers have the characteristics of being lightweight and starting up quickly.
- OSS such as Kubernetes
- Versions of OSS are frequently released in a short period of time, so systems using OSS need to be able to handle version upgrades.
- Rolling deployment and blue-green deployment are known methods for upgrading systems.
- Rolling deployment is a method of sequentially upgrading system components.
- Blue-green deployment is a method of duplicating the environment of the current system, deploying upgraded components to the duplicated environment, and switching from the current environment to the new environment.
- Patent Literature 1 discloses a technique of equipment bond.
- Patent Literature 1 describes, "In a process processing device that determines the migration order of processes in a system that has a migration source server that operates a process and a migration destination server that is a migration destination of the process, based on the communication relationship between the processes Based on a group management table storing information on the determined group of processes and the groups in the group management table, a group for migration is determined, and a plurality of groups for migration belonging to the same group complete migration at consecutive timings. determining means for determining the migration order of the processes from the migration source server to the migration destination server.
- the present invention provides a system and method for achieving blue-green deployment that maintains stateful component consistency between two environments.
- a representative example of the invention disclosed in the present application is as follows. That is, a computer system connected to a base on which a plurality of components constituting a service operate, comprising at least a computer having an arithmetic device, a storage device connected to the arithmetic device, and a communication device connected to the arithmetic device
- the base includes at least one cluster composed of the plurality of components, and the computer system updates the versions of the plurality of components included in the target cluster.
- a new cluster accepting settings of a group composed of a plurality of target components, deploying the plurality of target components of different versions to the new cluster, and transferring the components other than the target components to the target deploying a sidecar that receives requests to be sent to a component to the target cluster and the new cluster; and deploying a request monitoring unit that instructs the sidecar to send the request received by the sidecar to the target component; and deploy to either one of the new clusters.
- FIG. 2 is a diagram illustrating an example of the functional configuration of the update support system of Example 1;
- FIG. 3 is a diagram illustrating an example of a hardware configuration of a computer that constitutes the update support system of Example 1;
- FIG. FIG. 2 is a diagram showing an example of the configuration of components of the target board of Example 1;
- FIG. 2 is a diagram showing an example of the configuration of components of the target board of Example 1;
- FIG. 10 is a sequence diagram illustrating a request processing procedure in the target board of the first embodiment;
- 4 is a diagram illustrating an example of the data structure of request history information in Example 1;
- FIG. 4 is a flowchart illustrating an example of processing executed by the update support system of the first embodiment;
- FIG. 5 is a diagram showing an example of an interface for inputting data to the update support system of Example 1;
- FIG. 5 is a diagram showing an example of an interface for inputting data to the update support system of Example 1;
- 7 is a flowchart illustrating an example of deploy processing executed by the update support system of the first embodiment;
- FIG. 4 is a diagram showing an example of an interface presented by the update support system of the first embodiment;
- FIG. 2 is a diagram showing an example of the configuration of components of the target board of Example 1;
- FIG. 1 is a diagram showing an example of the functional configuration of the update support system of the first embodiment.
- FIG. 2 is a diagram illustrating an example of a hardware configuration of a computer that constitutes the update support system of the first embodiment.
- the update support system 100 is composed of one or more computers 200.
- the computer 200 has an arithmetic device 201 , a storage device 202 , a network interface 203 and an input/output interface 204 . Each hardware element is connected to each other via an internal bus. Note that the computer 200 may not have the input/output interface 204 .
- the computer 200 may also have storage media such as HDDs (Hard Disk Drives) and SSDs (Solid State Drives).
- the computing device 201 is a processor or the like, and executes programs stored in the storage device 202 .
- Arithmetic device 201 operates as a functional unit (module) that implements a specific function by executing processing according to a program. In the following description, when processing is described with a functional unit as the subject, it means that the arithmetic unit 201 is executing a program that implements the functional unit.
- the storage device 202 is a storage device that stores programs executed by the arithmetic device 201 and information executed by the programs, and is, for example, a volatile or non-volatile memory.
- the storage device 202 is also used as a work area.
- a network interface 203 is an interface that communicates with an external device via a network.
- the network is WAN (Wide Area Network), LAN (Local Area Network), etc., and the connection method may be either wired or wireless.
- the input/output interface 204 is an interface that connects with an input device and an output device.
- the input device is a keyboard, mouse, touch panel, or the like
- the output device is a display or the like.
- the update support system 100 connects with the user terminal 102 directly or via the network, and also connects with the target infrastructure 101 directly or via the network.
- the target platform 101 is a platform that provides resources for realizing a group of services that provide arbitrary functions corresponding to requests.
- the target infrastructure 101 includes multiple computers. Note that the target infrastructure 101 may include a storage system, a network switch, and the like.
- a service consists of multiple components.
- Components are, for example, applications and databases.
- Components include stateful components and stateless components.
- a stateful component is a component that holds and manages data
- a stateless component is a component that holds no data.
- resources used to implement the components may be physical computers, virtual computers, or containers.
- a management platform such as Kubernetes that manages components is installed on the target platform 101 .
- the update support system 100 is a system that supports component version updates.
- the update support system 100 has an update process manager 110 , a monitor setting information manager 111 , a group setting manager 112 , a component dependence extractor 113 , a request monitor service deployer 114 and a sidecar deployer 115 .
- each functional unit included in the update support system 100 a plurality of functional units may be combined into one functional unit, or one functional unit may be divided into multiple functional units for each function.
- the user terminal 102 is a terminal operated by a user who uses the update support system 100 .
- 3A and 3B are diagrams showing an example of the configuration of the components of the target board 101 of the first embodiment.
- updating the version of a component will be described using the component configuration shown in FIG. 3A as an example.
- the target infrastructure 101 includes a load balancer 300, DNS service 301, reverse proxy 310-1, application A 311-1, application B 311-2, application C 311-3, and DB 312-1.
- Reverse proxy 310-1, application A 311-1, application B 311-2, application C 311-3, and DB 312-1 are managed as cluster 302-1.
- a cluster 302 corresponds to the environment in a blue-green deployment.
- the DNS service 301 manages IP addresses within the target infrastructure 101.
- the load balancer 300 distributes requests.
- the reverse proxy 310 relays communications between networks outside the cluster 302 and components within the cluster 302 .
- Application A 311-1, application B 311-2, application C 311-3, and DB 312-1 are components that implement services.
- the update support system 100 When updating the version of a component included in the cluster 302-1, the update support system 100 instructs the target base 101 to generate a new cluster 302-2, and deploys the component to the cluster 302-2. to direct. Specifically, the update support system 100 generates a deployment schedule for each component, and instructs deployment of the components to the new cluster 302-2 according to the schedule.
- components with strong dependencies are deployed in groups.
- the present invention features the deployment of groups containing stateful components and components with strong dependencies.
- a group 330-1 including a DB 312-1 and an application B 311 that directly accesses the DB 312-1 is set, and a new version of the component group corresponding to the component group included in the group 330-1. is deployed to cluster 302-2.
- cluster 302-2 the deployed components are managed as group 330-2.
- the DB 312 of each cluster 302 is set to be synchronized.
- the amount of communication between clusters 302 can be reduced, and the delay in responding to requests can be reduced.
- the update support system 100 deploys a sidecar 350 that receives requests for components that are included in the group 330 and that receive requests from outside the group 330 to each of the two clusters 302. to the group 330 of .
- sidecar 350-1 is deployed to group 330-1 to receive requests addressed to application B 311-3
- group 330-2 receives requests addressed to application B 311-4.
- sidecar 350-2 is deployed.
- the update support system 100 also deploys the request monitoring service 340 to the cluster 302-1.
- the request monitor service 340 controls the transmission timing of requests received by the sidecar 350 .
- the request monitoring service 340 also manages request history information 345 .
- FIG. 4 is a sequence diagram illustrating a request processing procedure in the target board 101 of the first embodiment.
- FIG. 5 is a diagram showing an example of the data structure of the request history information 345 according to the first embodiment.
- Application A 311-1 of cluster 302-1 requests the IP address of application B 311-4 of cluster 302-2 from DNS service 301 (step S101).
- the DNS service 301 responds to the application A 311-1 with the IP address of the application B 311-4 (step S102).
- Application A 311-1 transmits a request including the IP address of application B 311-4 (step S103).
- the request is received by sidecar 350-2 corresponding to application B 311-4 via reverse proxy 310-1 and load balancer 300.
- the sidecar 350-2 transmits the request information to the request monitoring service 340 (step S104).
- the sidecar 350-2 extracts the timestamp, the source of the request, the destination of the request, and the content of the request by analyzing the received request. Sidecar 350-2 also generates identification information for the request. Sidecar 350-2 transmits the extracted information and the identification information of the request to request monitoring service 340 as request information.
- the request monitoring service 340 Upon receiving the request information, the request monitoring service 340 updates the request history information 345 (step S105).
- the request history information 345 stores entries including time 501 , request ID 502 , request source 503 , request destination 504 , cluster ID 505 , data update flag 506 and synchronization status 507 . There is one entry for one request. Note that the fields included in the entry are not limited to those described above. Any of the fields described above may not be included, or other fields may be included.
- a time 501 is a field that stores the time stamp included in the request.
- a request ID 502 is a field that stores identification information for identifying a request. The identity of the request is provided by sidecar 350 .
- the request source 503 is a field that stores the identification information of the component that sent the request.
- a request destination 504 is a field that stores the identification information of the component that sent the request.
- the request source 503 and request destination 504 store the name of the component, the IP address, and the like.
- the cluster ID 505 is a field that stores identification information of the cluster 302 to which the request destination component belongs.
- a data update flag 506 is a field that stores a flag indicating whether or not the request involves updating data held by a stateful component. If the request involves updating data held by a stateful component, True is stored in the data update flag 506. If the request does not involve updating data held by a stateful component, False is stored in the data update flag 506. Stored.
- trigger requests that involve updating data held by stateful components are referred to as trigger requests.
- a synchronization status 507 is a field that stores a flag indicating whether synchronization of data held by stateful components in two clusters 302 has been completed. When data synchronization is completed, the synchronization status 507 stores True, and when data synchronization is not completed, the synchronization status 507 stores False.
- step S105 the following processing is executed.
- the request monitoring service 340 adds an entry to the request history information 345, and sets values to the time 501, request ID 502, request source 503, and request destination 504 of the added entry based on the request information. do.
- the request monitoring service 340 identifies the cluster 302 to which the sidecar 350 that has transmitted the request information belongs, and sets the identification information of the identified cluster 302 in the cluster ID 505 of the added entry.
- the request monitoring service 340 analyzes the request and determines whether or not the request is a trigger request. If the request is not a trigger request, the request monitor service 340 sets the data update flag 506 and sync status 507 of the added entry to False. If the request is a trigger request, the request monitor service 340 sets the data update flag 506 of the added entry to True and sets the synchronization status 507 of the added entry to False.
- step S105 The above is the description of the processing in step S105.
- the request monitoring service 340 monitors requests within the group 330 (step S106).
- the request monitoring service 340 creates and executes a monitoring process associated with the identification information of the trigger request.
- Request monitoring methods include packet capture and request tracing using a service mesh.
- information about requests to be monitored is set via the monitor setting information management unit 111 .
- the request monitoring service 340 updates the request history information 345 when it detects the completion of data synchronization for a certain trigger request as a result of monitoring the requests related to the trigger requests in the group 330 (step S107).
- the data update request sent from the application B 311-4 to the DB 312-2, the response to the data update request sent from the DB 312-2 to the application B 311-4, or the transmission completion of the trigger request sent from the sidecar 350-2 A notification is detected as completion of data synchronization for the trigger request.
- step S107 the following processing is executed.
- the request monitoring service 340 adds an entry to the request history information 345, and sets the time 501, request ID 502, request source 503, and request destination 504 of the added entry based on the detected request. set.
- the request monitoring service 340 sets the identification information of the cluster 302 including the group 330 in the cluster ID 505 of the added entry.
- the request monitor service 340 sets False to the data update flag 506 and synchronization status 507 of the added entry.
- the request monitoring service 340 refers to the request history information 345 and searches for an entry corresponding to a trigger request related to the detected request. For example, the request monitor service 340 retrieves entries based on the identification of the triggering request associated with the monitor process. The request monitor service 340 sets "True" to the synchronization status 507 of the retrieved entry.
- the request monitoring service 340 identifies an executable trigger request and transmits an instruction to transmit the identified trigger request to the sidecar 350-2 that received the trigger request (step S108). At this time, the transmission instruction includes the identification information of the trigger request.
- the request monitoring service 340 refers to the request history information 345 and identifies trigger requests with timestamps later than the timestamp of the trigger request whose completion of data synchronization was detected. The request monitoring service 340 selects the oldest trigger request from among the specified trigger requests, and transmits an instruction to send the trigger request to the sidecar 350-2 that received the selected trigger request.
- the request monitoring service 340 terminates request monitoring.
- the sidecar 350-2 When the sidecar 350-2 receives the transmission instruction from the request monitoring service 340, it transmits the trigger request to the application B 311-4, which is the transmission destination of the trigger request (step S109).
- the sidecar 350-2 identifies the trigger request to be transmitted based on the trigger request identification information included in the transmission instruction.
- the sidecar 350-2 sends the trigger request to the specified trigger request destination component.
- the sidecar 350-2 notifies the request monitoring service 340 of the transmission completion of the trigger request along with the transmission time and the identification information of the trigger request.
- the request monitoring service 340 adds an entry to the request history information 345 and sets values to the time 501 and request ID 502 of the added entry.
- the request monitoring service 340 sets the identification information of the sidecar 350-2 to the request source 503 of the added entry, sets the identification information of the application B 311-4 to the request destination 504, and sets the cluster 302-2 to the cluster ID 505. set the identification information for The request monitoring service 340 also sets the data update flag 506 and the synchronization status 507 of the added entry to False.
- the application B 311-4 When the application B 311-4 receives the trigger request, it executes a predetermined process, and based on the process result, transmits a data update request to the DB 312-2 (step S110).
- the update support system 100 deploys the request monitoring service 340 and the sidecar 350 on the target platform 101, thereby avoiding inconsistency of stateful component data between the clusters 302.
- FIG. 6 is a flowchart illustrating an example of processing executed by the update support system 100 of the first embodiment.
- 7 and 8 are diagrams showing an example of an interface for inputting data to the update support system 100 of the first embodiment.
- the update support system 100 When the update support system 100 receives access from the user terminal 102, it starts the processing described below.
- the update support system 100 extracts the dependencies of the components of the target base 101 (step S201).
- the component dependency extraction unit 113 extracts component dependencies using known distributed tracing or the like.
- the component dependence extraction unit 113 stores information indicating the dependence of the components in the work area.
- the information is, for example, a graph in which components are nodes and nodes that transmit and receive requests are connected by edges.
- the update support system 100 receives group setting information (step S202).
- the group setting management unit 112 presents the user terminal 102 with a user interface 700 as shown in FIG. A user refers to user interface 700 and selects multiple components to include in group 330 . In FIG. 7, the components circled in bold are selected for inclusion in group 330 .
- the group setting management unit 112 stores the information of the component specified by the operation on the user interface 700 as group setting information in the work area.
- the update support system 100 receives request monitoring setting information (step S203).
- the monitoring setting information management unit 111 presents the user terminal 102 with a user interface 800 as shown in FIG.
- the user inputs the information of the current cluster 302-1 and the new cluster 302-2, the information of the request to be monitored, etc. to the user interface 800.
- FIG. FIG. 8 shows an example of information described in YAML. Note that the numbers on the left represent line numbers.
- the monitoring setting information management unit 111 stores information input via the user interface 800 in the work area as request monitoring setting information.
- step S204 when the update support system 100 receives an instruction to deploy any component of the cluster 302-1 from the user terminal 102, it executes deployment processing (step S204).
- FIG. 9 is a flowchart illustrating an example of deploy processing executed by the update support system 100 of the first embodiment.
- Figure 9 explains the deployment process that is executed when a deployment instruction for a group containing stateful components is received. Since the deployment of each component and the deployment of a group containing only stateless components are well-known techniques, detailed description thereof will be omitted.
- the update support system 100 deploys the components included in the group 330-1 and the reverse proxy 310 to the new cluster 302-2 (step S301).
- the update processing management unit 110 adds, to the new cluster 302-2, application B 311-2 and DB 312-1 included in the group 330-1, application B 311-4 corresponding to the reverse proxy 310-1, Deploy DB 312-2 and reverse proxy 310-2.
- the update support system 100 deploys sidecars 350-1 and 350-2 to the current cluster 302-1 and new cluster 302-2 (step S302).
- the update processing management unit 110 outputs an instruction to deploy the sidecar 350 to the sidecar deploying unit 115 .
- the sidecar deploying unit 115 deploys the sidecar 350-1 to the current cluster 302-1 based on the information of the cluster 302 included in the request monitoring setting information received by the monitoring setting information managing unit 111, and deploys the sidecar 350-1 to the new cluster 302-1. 2 deploys sidecar 350-2.
- the update support system 100 creates the request monitoring service 340 and deploys the request monitoring service 340 to the current cluster 302-1 (step S303).
- the update processing management unit 110 outputs an instruction to deploy the request monitoring service 340 to the request monitoring service deploying unit 114 .
- the request monitoring service deploying unit 114 deploys the request monitoring service 340 in which the information of the request to be monitored is set based on the request monitoring setting information received by the monitoring setting information managing unit 111 and the group setting information received by the group setting managing unit 112. to generate Also, the request monitoring service deploying unit 114 deploys the request monitoring service 340 to the current cluster 302-1.
- the update support system 100 adds routing settings for the reverse proxy 310-2 of the new cluster 302-2 to the load balancer 300 (step S304).
- the update processing management unit 110 adds routing settings for the reverse proxy 310-2 of the new cluster 302-2 to the load balancer 300.
- the update support system 100 adds DNS records for the components of the new cluster 302-2 to the DNS service 301 (step S305). After that, the update support system 100 ends the process.
- the update processing management unit 110 adds the endpoint of the load balancer 300 that routes to the reverse proxy 310-2 of the new cluster 302-2 to the DNS service 301 as a DNS record.
- the update support system 100 can acquire a request transmission control log from the request monitoring service 340 and present it to the user terminal 102 .
- FIG. 10 is a diagram showing an example of an interface presented by the update support system 100 of the first embodiment.
- the user interface 1000 includes a component display field 1010 and a request log display field 1020.
- the component display column 1010 is a column for displaying the components of the current cluster 302-1 and the new cluster 302-2.
- the component display field 1010 is displayed based on the dependencies of the components extracted by the component dependency extracting unit 113 and the deployment results.
- the request log display column 1020 is a column for displaying the request log.
- the request log display field 1020 displays trigger requests received by the sidecar 350, trigger requests transmitted by the sidecar 350, requests indicating completion of data synchronization, and the like.
- the user can confirm the migration state of the component and the request flow. Also, it is possible to check whether the sidecar 350 is functioning properly.
- a sidecar 350 is set for each component, as shown in FIG.
- the request monitoring service 340 may be deployed to the new cluster 302-2.
- a request monitoring service 340 may also be deployed on each cluster 302 .
- the sidecar 350 may be allowed to access the request history information 345.
- the update support system 100 may include a functional unit that deploys the request history information 345 .
- the request history information 345 may be set in the new cluster 302-2.
- blue-green deployment that maintains stateful component consistency between two clusters 302 can be realized. Also, by deploying components in units of groups, delays in response to requests and increases in communication traffic in the cluster 302 can be suppressed.
- the present invention is not limited to the above-described embodiments, and includes various modifications. Further, for example, the above-described embodiments are detailed descriptions of the configurations for easy understanding of the present invention, and are not necessarily limited to those having all the described configurations. Moreover, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.
- each of the above configurations, functions, processing units, processing means, etc. may be realized in hardware, for example, by designing a part or all of them with an integrated circuit.
- the present invention can also be implemented by software program code that implements the functions of the embodiments.
- a computer is provided with a storage medium recording the program code, and a processor included in the computer reads the program code stored in the storage medium.
- the program code itself read from the storage medium implements the functions of the above-described embodiments, and the program code itself and the storage medium storing it constitute the present invention.
- Examples of storage media for supplying such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, A nonvolatile memory card, ROM, or the like is used.
- program code that implements the functions described in this embodiment can be implemented in a wide range of programs or script languages, such as assembler, C/C++, perl, Shell, PHP, Python, and Java.
- the program code of the software that implements the functions of the embodiment can be stored in storage means such as a hard disk or memory of a computer, or in a storage medium such as a CD-RW or CD-R.
- a processor provided in the computer may read and execute the program code stored in the storage means or the storage medium.
- control lines and information lines indicate those that are considered necessary for explanation, and not all the control lines and information lines are necessarily indicated on the product. All configurations may be interconnected.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
計算機システムは、サービスを構成する複数のコンポーネントが稼働する基盤と接続し、ターゲットクラスタに含まれる複数のコンポーネントのバージョンを更新する場合、複数のターゲットコンポーネントから構成されるグループの設定を受け付け、新規クラスタに、バージョンが異なる複数のターゲットコンポーネントをデプロイし、ターゲットコンポーネント以外のコンポーネントからターゲットコンポーネントへ送信されるリクエストを受け付けるサイドカーを、ターゲットクラスタ及び新規クラスタにデプロイし、サイドカーが受け付けたリクエストのターゲットコンポーネントへの送信を指示するリクエスト監視部を、いずれかのクラスタにデプロイする。
Description
本出願は、２０２１年８月１９日に出願された日本特許出願第２０２１－１３４００７号の優先権を主張し、その内容を参照することにより、本出願に取り込む。
本発明は、サービスを構成するコンポーネントのバージョンアップ技術に関する。
近年、複数のサービスを組み合わせて任意の機能を実現するシステム（マイクロサービス）の利用が広がっている。一般的に、サービスはコンテナ技術を用いて実現されている。コンテナ技術は、一つの物理計算機のリソースを利用して複数のアプリケーションを稼働させる仮想化技術の一つであり、一つの物理計算機で稼働するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上に隔離されたアプリケーションの実行環境を提供する技術である。本明細書では、隔離されたアプリケーションの実行環境をコンテナと記載する。コンテナは軽量かつ起動が高速という特徴を有する。
コンテナを管理するために、Ｋｕｂｅｒｎｅｔｅｓ等のＯＳＳの利用するケースが増大している。ＯＳＳは、バージョンのリリースが短い期間で頻繁に行われるため、ＯＳＳを利用したシステムではバージョンアップに対応する必要がある。
システムのバージョンアップの方式としては、ローリングデプロイメントと、ブルーグリーンデプロイメントとが知られている。ローリングデプロイメントは、システムのコンポーネントを順次バージョンアップする方式である。ブルーグリーンデプロイメントは、現行のシステムの環境を複製し、複製した環境にバージョンアップしたコンポーネントをデプロイし、現行の環境から新規の環境に切り替える方式である。
ブルーグリーンデプロイメントにおいて、システムを一度に切り替えると影響が大きいという課題がある。そこで、複製した環境にコンポーネントを徐々に追加し、現行の環境と並列に稼働させ、個々のコンポーネントの動作を検証する方法が望ましい。
しかし、上記の方法の場合、環境間のリクエストの送受信が発生するため、リクエストに対するレスポンスの遅延及び通信量の増大が問題となる。これに対して、特許文献１に機器債の技術が知られている。
特許文献１には、「プロセスを稼働させる移行元サーバと、プロセスの移行先である移行先サーバとを有するシステムにおけるプロセスの移行順序を決定するプロセス処理装置において、プロセス間の通信関係に基づいて決定されたプロセスのグループの情報を格納するグループ管理テーブルと、前記グループ管理テーブルにおけるグループに基づいて、移行用グループを決定し、同じグループに属する複数の移行用グループが連続したタイミングで移行を完了するように、前記移行元サーバから前記移行先サーバへのプロセスの移行順序を決定する決定手段とを備える。」ことが記載されている。
従来技術では、二つの環境間のデータを保持するステートフルなコンポーネントの整合性が考慮されていない。そのため、正しくサービスが稼働しない可能性がある。
本発明は、二つの環境間のステートフルなコンポーネントの整合性を保ったブルーグリーンデプロイメントを実現するシステム及び方法を提供する。
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、サービスを構成する複数のコンポーネントが稼働する基盤と接続する計算機システムであって、演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続される通信装置を有する計算機を少なくとも一つ含み、前記基盤は、前記複数のコンポーネントから構成されるクラスタを少なくとも一つ含み、前記計算機システムは、ターゲットクラスタに含まれる前記複数のコンポーネントのバージョンを更新する場合、前記ターゲットクラスタに含まれ、かつ、新規クラスタに移行する、複数のターゲットコンポーネントから構成されるグループの設定を受け付け、前記新規クラスタに、バージョンが異なる前記複数のターゲットコンポーネントをデプロイし、前記ターゲットコンポーネント以外の前記コンポーネントから前記ターゲットコンポーネントへ送信されるリクエストを受け付けるサイドカーを、前記ターゲットクラスタ及び前記新規クラスタにデプロイし、前記サイドカーが受け付けた前記リクエストの前記ターゲットコンポーネントへの送信を前記サイドカーに指示するリクエスト監視部を、前記ターゲットクラスタ及び前記新規クラスタのいずれか一方にデプロイする。
本発明によれば、二つのクラスタ（環境）間のステートフルなコンポーネントの整合性を保ったブルーグリーンデプロイメントを実現できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。
本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。
図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。
図１は、実施例１の更新支援システムの機能構成の一例を示す図である。図２は、実施例１の更新支援システムを構成する計算機のハードウェア構成の一例を示す図である。
更新支援システム１００は、一つ以上の計算機２００から構成される。計算機２００は、演算装置２０１、記憶装置２０２、ネットワークインタフェース２０３、及び入出力インタフェース２０４を有する。各ハードウェア要素は内部バスを介して互いに接続される。なお、計算機２００は、入出力インタフェース２０４を有していなくてもよい。また、計算機２００は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶媒体を有してもよい。
演算装置２０１は、プロセッサ等であり、記憶装置２０２に格納されるプログラムを実行する。演算装置２０１がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部（モジュール）として動作する。以下の説明では、機能部を主語に処理を説明する場合、演算装置２０１が当該機能部を実現するプログラムを実行していることを示す。
記憶装置２０２は、演算装置２０１が実行するプログラム及びプログラムが実行する情報を格納する記憶装置であり、例えば、揮発性又は不揮発性のメモリである。記憶装置２０２はワークエリアとしても用いられる。
ネットワークインタフェース２０３は、ネットワークを介して、外部装置と通信するインタフェースである。ここで、ネットワークは、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等であり、接続方式は、有線及び無線のいずれでもよい。
入出力インタフェース２０４は、入力装置及び出力装置と接続するインタフェースである。ここで、入力装置は、キーボード、マウス、及びタッチパネル等であり、出力装置は、ディスプレイ等である。
更新支援システム１００は、直接又はネットワークを介して、ユーザ端末１０２と接続し、また、直接又はネットワークを介して、対象基盤１０１と接続する。
対象基盤１０１は、リクエストに対応する任意の機能を提供するサービス群を実現するためのリソースを提供する基盤である。対象基盤１０１は複数の計算機を含む。なお、対象基盤１０１は、ストレージシステム及びネットワークスイッチ等を含んでもよい。
サービスは複数のコンポーネントから構成される。コンポーネントは、例えば、アプリケーション及びデータベース等である。コンポーネントには、ステートフルなコンポーネントと、ステートレスなコンポーネントとが存在する。ステートフルなコンポーネントは、データを保持及び管理するコンポーネントであり、ステートレスなコンポーネントは、データを保持しないコンポーネントである。
なお、コンポーネントを実現するためのリソースは、物理計算機、仮想計算機、及びコンテナのいずれでもよい。
対象基盤１０１には、コンポーネントを管理する、Ｋｕｂｅｒｎｅｔｅｓ等の管理プロットフォームがインストールされている。
更新支援システム１００は、コンポーネントのバージョンの更新を支援するシステムである。更新支援システム１００は、更新処理管理部１１０、監視設定情報管理部１１１、グループ設定管理部１１２、コンポーネント依存関係抽出部１１３、リクエスト監視サービスデプロイ部１１４、及びサイドカーデプロイ部１１５を有する。
なお、更新支援システム１００が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。
ユーザ端末１０２は、更新支援システム１００を利用するユーザが操作する端末である。
図３Ａ及び図３Ｂは、実施例１の対象基盤１０１のコンポーネントの構成の一例を示す図である。
本実施例では、図３Ａに示すようなコンポーネント構成を例に、コンポーネントのバージョンの更新について説明する。
対象基盤１０１は、ロードバランサ３００、ＤＮＳサービス３０１、リバースプロキシ３１０－１、アプリＡ３１１－１、アプリＢ３１１－２、アプリＣ３１１－３、及びＤＢ３１２－１を含む。リバースプロキシ３１０－１、アプリＡ３１１－１、アプリＢ３１１－２、アプリＣ３１１－３、及びＤＢ３１２－１は、クラスタ３０２－１として管理される。クラスタ３０２がブルーグリーンデプロイメントにおける環境に対応する。
以下の説明では、特定の構成を指していない場合、ハイフン以下の符号を省略して記載する。
ＤＮＳサービス３０１は、対象基盤１０１内のＩＰアドレスを管理する。ロードバランサ３００は、リクエストの振り分けを行う。
リバースプロキシ３１０は、クラスタ３０２の外のネットワークとクラスタ３０２内のコンポーネントとの間の通信を中継する。
アプリＡ３１１－１、アプリＢ３１１－２、アプリＣ３１１－３、及びＤＢ３１２－１は、サービスを実現するコンポーネントである。
更新支援システム１００は、クラスタ３０２－１に含まれるコンポーネントのバージョンを更新する場合、対象基盤１０１に対して新たなクラスタ３０２－２の生成を指示し、また、クラスタ３０２－２へのコンポーネントのデプロイを指示する。具体的には、更新支援システム１００は、コンポーネント単位のデプロイのスケジュールを生成し、スケジュールに沿って新たなクラスタ３０２－２へのコンポーネントのデプロイを指示する。
本実施例では、強い依存関係があるコンポーネントは、グループ単位でデプロイされる。後述するように、本発明は、ステートフルなコンポーネントと強い依存関係があるコンポーネントを含むグループのデプロイメントに特徴がある。図３Ａに示す例では、ＤＢ３１２－１と、ＤＢ３１２－１に直接アクセスするアプリＢ３１１とを含むグループ３３０－１が設定され、当該グループ３３０－１に含まれるコンポーネント群に対応する新たなバージョンのコンポーネント群が、クラスタ３０２－２にデプロイされる。クラスタ３０２－２において、デプロイされたコンポーネント群はグループ３３０－２として管理される。また、各クラスタ３０２のＤＢ３１２は同期するように設定される。
グループ単位でコンポーネントをデプロイすることによって、クラスタ３０２間の通信量を削減でき、また、リクエストに対するレスポンスの遅延を低減できる。
更新支援システム１００は、ステートフルなコンポーネントを含むグループ３３０のデプロイメントにおいて、グループ３３０に含まれ、かつ、グループ３３０の外からリクエストを受信するコンポーネントのリクエストを受信するサイドカー３５０を、二つのクラスタ３０２の各々のグループ３３０にデプロイする。図３Ｂに示す例では、グループ３３０－１には、アプリＢ３１１－３宛てのリクエストを受信するサイドカー３５０－１がデプロイされ、また、グループ３３０－２には、アプリＢ３１１－４宛てのリクエストを受信するサイドカー３５０－２がデプロイされる。
また、更新支援システム１００は、クラスタ３０２－１にリクエスト監視サービス３４０をデプロイする。リクエスト監視サービス３４０は、サイドカー３５０が受信したリクエストの送信タイミングを制御する。また、リクエスト監視サービス３４０は、リクエスト履歴情報３４５を管理する。
サイドカー３５０は、対応するコンポーネント宛てのリクエストを受信する。サイドカー３５０は、リクエストの受信をリクエスト監視サービス３４０に通知する。
ここで、図４を用いて、図３Ｂの状態におけるリクエストの処理手順を説明する。図４は、実施例１の対象基盤１０１におけるリクエストの処理手順を説明するシーケンス図である。図５は、実施例１のリクエスト履歴情報３４５のデータ構造の一例を示す図である。
クラスタ３０２－１のアプリＡ３１１－１は、ＤＮＳサービス３０１に、クラスタ３０２－２のアプリＢ３１１－４のＩＰアドレスを要求する（ステップＳ１０１）。
ＤＮＳサービス３０１は、アプリＡ３１１－１に、アプリＢ３１１－４のＩＰアドレスを応答する（ステップＳ１０２）。
アプリＡ３１１－１は、アプリＢ３１１－４のＩＰアドレスを含むリクエストを送信する（ステップＳ１０３）。当該リクエストは、リバースプロキシ３１０－１、ロードバランサ３００を経由して、アプリＢ３１１－４に対応するサイドカー３５０－２が受信する。
サイドカー３５０－２は、リクエスト監視サービス３４０に、リクエスト情報を送信する（ステップＳ１０４）。
具体的には、サイドカー３５０－２は、受信したリクエストを解析することによって、タイムスタンプ、リクエストの送信元、リクエストの送信先、及びリクエストの内容等を抽出する。また、サイドカー３５０－２は、リクエストの識別情報を生成する。サイドカー３５０－２は、抽出された情報及びリクエストの識別情報を、リクエスト情報としてリクエスト監視サービス３４０に送信する。
リクエスト監視サービス３４０は、リクエスト情報を受信した場合、リクエスト履歴情報３４５を更新する（ステップＳ１０５）。
まず、図５を用いてリクエスト履歴情報３４５について説明する。リクエスト履歴情報３４５は、時刻５０１、リクエストＩＤ５０２、リクエスト元５０３、リクエスト先５０４、クラスタＩＤ５０５、データ更新フラグ５０６、及び同期ステータス５０７を含むエントリを格納する。一つのリクエストに対して一つのエントリが存在する。なお、エントリに含まれるフィールドは前述したものに限定されない。前述したフィールドのいずれかを含まなくてもよいし、また、他のフィールドを含んでもよい。
時刻５０１は、リクエストに含まれるタイムスタンプを格納するフィールドである。
リクエストＩＤ５０２は、リクエストを識別するための識別情報を格納するフィールドである。リクエストの識別情報はサイドカー３５０によって付与される。
リクエスト元５０３は、リクエストの送信元のコンポーネントの識別情報を格納するフィールドである。リクエスト先５０４は、リクエストの送信元のコンポーネントの識別情報を格納するフィールドである。リクエスト元５０３及びリクエスト先５０４には、コンポーネントの名称、及びＩＰアドレス等が格納される。
クラスタＩＤ５０５は、リクエストの宛先のコンポーネントが所属するクラスタ３０２の識別情報を格納するフィールドである。
データ更新フラグ５０６は、ステートフルなコンポーネントが保持するデータの更新を伴うリクエストであるか否かを示すフラグを格納するフィールドである。ステートフルなコンポーネントが保持するデータの更新を伴うリクエストである場合、データ更新フラグ５０６にはＴｒｕｅが格納され、ステートフルなコンポーネントが保持するデータの更新を伴うリクエストでない場合、データ更新フラグ５０６にはＦａｌｓｅが格納される。
以下の説明では、ステートフルなコンポーネントが保持するデータの更新を伴うリクエストをトリガリクエストと記載する。
同期ステータス５０７は、二つのクラスタ３０２におけるステートフルなコンポーネントが保持するデータの同期が完了したか否かを示すフラグを格納するフィールドである。データの同期が完了した場合、同期ステータス５０７にはＴｒｕｅが格納され、データの同期が完了していない場合、同期ステータス５０７にはＦａｌｓｅが格納される。
以上が、リクエスト履歴情報３４５の説明である。図４の説明に戻る。
ステップＳ１０５では、以下のような処理が実行される。
（Ｓ１０５－１）リクエスト監視サービス３４０は、リクエスト履歴情報３４５にエントリを追加し、リクエスト情報に基づいて、追加されたエントリの時刻５０１、リクエストＩＤ５０２、リクエスト元５０３、及びリクエスト先５０４に値を設定する。
（Ｓ１０５－２）リクエスト監視サービス３４０は、リクエスト情報を送信したサイドカー３５０が所属するクラスタ３０２を特定し、追加されたエントリのクラスタＩＤ５０５に特定されたクラスタ３０２の識別情報を設定する。
（Ｓ１０５－３）リクエスト監視サービス３４０は、リクエストを解析し、当該リクエストがトリガリクエストであるか否かを判定する。リクエストがトリガリクエストでない場合、リクエスト監視サービス３４０は、追加されたエントリのデータ更新フラグ５０６及び同期ステータス５０７にＦａｌｓｅを設定する。リクエストがトリガリクエストである場合、リクエスト監視サービス３４０は、追加されたエントリのデータ更新フラグ５０６にＴｒｕｅを設定し、また、追加されたエントリの同期ステータス５０７にＦａｌｓｅを設定する。
以上がステップＳ１０５の処理の説明である。
リクエスト監視サービス３４０は、グループ３３０内のリクエストを監視する（ステップＳ１０６）。
例えば、リクエスト監視サービス３４０は、トリガリクエストの識別情報を対応付けた監視プロセスを生成し、実行する。リクエストの監視方法としては、パケットキャプチャ、及びサービスメッシュを用いたリクエストのトレーシング等が考えられる。後述するように、監視するリクエストに関する情報は監視設定情報管理部１１１を介して設定される。
リクエスト監視サービス３４０は、グループ３３０内のトリガリクエストに関連するリクエストの監視の結果、あるトリガリクエストに関するデータ同期の完了を検知した場合、リクエスト履歴情報３４５を更新する（ステップＳ１０７）。
例えば、アプリＢ３１１－４からＤＢ３１２－２に送信されたデータ更新リクエスト、ＤＢ３１２－２からアプリＢ３１１－４へ送信されたデータ更新リクエストに対する応答、又はサイドカー３５０－２から送信されたトリガリクエストの送信完了通知が、トリガリクエストに関するデータ同期の完了として検知される。
ステップＳ１０７では、以下のような処理が実行される。
（Ｓ１０７－１）リクエスト監視サービス３４０は、リクエスト履歴情報３４５にエントリを追加し、検知したリクエストに基づいて、追加されたエントリの時刻５０１、リクエストＩＤ５０２、リクエスト元５０３、及びリクエスト先５０４に値を設定する。リクエスト監視サービス３４０は、追加されたエントリのクラスタＩＤ５０５にグループ３３０が含まれるクラスタ３０２の識別情報を設定する。リクエスト監視サービス３４０は、追加されたエントリのデータ更新フラグ５０６及び同期ステータス５０７にＦａｌｓｅを設定する。
（Ｓ１０７－２）リクエスト監視サービス３４０は、リクエスト履歴情報３４５を参照し、検知されたリクエストに関連するトリガリクエストに対応するエントリを検索する。例えば、リクエスト監視サービス３４０は、監視プロセスに対応付けられるトリガリクエストの識別情報に基づいてエントリを検索する。リクエスト監視サービス３４０は、検索されたエントリの同期ステータス５０７に「Ｔｒｕｅ」を設定する。
以上がステップＳ１０７の処理の説明である。
リクエスト監視サービス３４０は、実行可能なトリガリクエストを特定し、特定されたトリガリクエストの送信指示を、当該トリガリクエストを受信したサイドカー３５０－２に送信する（ステップＳ１０８）。このとき、送信指示には、トリガリクエストの識別情報が含まれる。
具体的には、リクエスト監視サービス３４０は、リクエスト履歴情報３４５を参照し、データ同期の完了が検知されたトリガリクエストのタイムスタンプより後のタイムスタンプのトリガリクエストを特定する。リクエスト監視サービス３４０は、特定されたトリガリクエストの中から最も過去のトリガリクエストを選択し、選択されたトリガリクエストを受信したサイドカー３５０－２に、当該トリガリクエストの送信指示を送信する。
コンポーネントへ送信が可能なトリガリクエストが存在しない場合、リクエスト監視サービス３４０は、リクエストの監視を終了する。
サイドカー３５０－２は、リクエスト監視サービス３４０から送信指示を受信した場合、トリガリクエストを、当該トリガリクエストの送信先であるアプリＢ３１１－４に送信する（ステップＳ１０９）。
具体的には、サイドカー３５０－２は、送信指示に含まれるトリガリクエストの識別情報に基づいて、送信するトリガリクエストを特定する。サイドカー３５０－２は、特定されたトリガリクエストの送信先のコンポーネントに、当該トリガリクエストを送信する。
このとき、サイドカー３５０－２は、送信した時刻及びトリガリクエストの識別情報とともに、トリガリクエストの送信完了をリクエスト監視サービス３４０に通知する。リクエスト監視サービス３４０は、リクエスト履歴情報３４５にエントリを追加し、追加されたエントリの時刻５０１及びリクエストＩＤ５０２に値を設定する。リクエスト監視サービス３４０は、追加されたエントリのリクエスト元５０３にサイドカー３５０－２の識別情報を設定し、リクエスト先５０４にアプリＢ３１１－４の識別情報を設定し、また、クラスタＩＤ５０５にクラスタ３０２－２の識別情報を設定する。また、リクエスト監視サービス３４０は、追加されたエントリのデータ更新フラグ５０６及び同期ステータス５０７のＦａｌｓｅを設定する。
アプリＢ３１１－４は、トリガリクエストを受信した場合、所定の処理を実行し、処理結果に基づいて、ＤＢ３１２－２にデータ更新リクエストを送信する（ステップＳ１１０）。
このように、更新支援システム１００は、対象基盤１０１に、リクエスト監視サービス３４０及びサイドカー３５０をデプロイすることによって、クラスタ３０２間のステートフルなコンポーネントのデータの不整合を回避することができる。
図６は、実施例１の更新支援システム１００が実行する処理の一例を説明するフローチャートである。図７及び図８は、実施例１の更新支援システム１００にデータを入力するためのインタフェースの一例を示す図である。
更新支援システム１００は、ユーザ端末１０２からのアクセスを受け付けた場合、以下で説明する処理を開始する。
更新支援システム１００は、対象基盤１０１のコンポーネントの依存関係を抽出する（ステップＳ２０１）。
具体的には、コンポーネント依存関係抽出部１１３は、公知の分散トレーシング等を用いて、コンポーネントの依存関係を抽出する。コンポーネント依存関係抽出部１１３は、コンポーネントの依存関係を示す情報をワークエリアに格納する。当該情報は、例えば、コンポーネントをノードとし、リクエストを送受信するノードをエッジで接続したグラフである。
次に、更新支援システム１００は、グループ設定情報を受け付ける（ステップＳ２０２）。
具体的には、グループ設定管理部１１２は、コンポーネント依存関係抽出部１１３によって抽出された情報に基づいて、図７に示すようなユーザインタフェース７００をユーザ端末１０２に提示する。ユーザは、ユーザインタフェース７００を参照し、グループ３３０に含める複数のコンポーネントを選択する。図７では、太枠で囲まれたコンポーネントが、グループ３３０に含めるコンポーネントとして選択される。グループ設定管理部１１２は、ユーザインタフェース７００に対する操作によって指定されたコンポーネントの情報をグループ設定情報としてワークエリアに格納する。
次に、更新支援システム１００は、リクエスト監視設定情報を受け付ける（ステップＳ２０３）。
具体的には、監視設定情報管理部１１１は、図８に示すようなユーザインタフェース８００をユーザ端末１０２に提示する。ユーザは、ユーザインタフェース８００に、現行のクラスタ３０２－１及び新規のクラスタ３０２－２の情報、及び、監視するリクエストの情報等を入力する。図８では、ＹＡＭＬで記述された情報の一例を示す。なお、左の数字は行番号を表す。監視設定情報管理部１１１は、ユーザインタフェース８００を介して入力された情報を、リクエスト監視設定情報としてワークエリアに格納する。
次に、更新支援システム１００は、ユーザ端末１０２から、クラスタ３０２－１の任意のコンポーネントのデプロイ指示を受け付けた場合、デプロイ処理を実行する（ステップＳ２０４）。
図９は、実施例１の更新支援システム１００が実行するデプロイ処理の一例を説明するフローチャートである。
図９では、ステートフルなコンポーネントを含むグループのデプロイ指示を受け付けた場合に実行されるデプロイ処理について説明する。コンポーネント単位のデプロイメント及びステートレスなコンポーネントのみを含むグループのデプロイメントは、公知の技術であるため詳細な説明は省略する。
更新支援システム１００は、新規のクラスタ３０２－２に、グループ３３０－１に含まれるコンポーネント及びリバースプロキシ３１０をデプロイする（ステップＳ３０１）。
具体的には、更新処理管理部１１０が、新規のクラスタ３０２－２に、グループ３３０－１に含まれるアプリＢ３１１－２、ＤＢ３１２－１、及びリバースプロキシ３１０－１に対応するアプリＢ３１１－４、ＤＢ３１２－２、及びリバースプロキシ３１０－２をデプロイする。
次に、更新支援システム１００は、現行のクラスタ３０２－１及び新規のクラスタ３０２－２に、サイドカー３５０－１、３５０－２をデプロイする（ステップＳ３０２）。
具体的には、更新処理管理部１１０が、サイドカーデプロイ部１１５に、サイドカー３５０のデプロイ指示を出力する。サイドカーデプロイ部１１５は、監視設定情報管理部１１１が受け付けたリクエスト監視設定情報に含まれるクラスタ３０２の情報に基づいて、現行のクラスタ３０２－１にサイドカー３５０－１をデプロイし、新規のクラスタ３０２－２にサイドカー３５０－２をデプロイする。
次に、更新支援システム１００は、リクエスト監視サービス３４０を生成し、現行のクラスタ３０２－１にリクエスト監視サービス３４０をデプロイする（ステップＳ３０３）。
具体的には、更新処理管理部１１０が、リクエスト監視サービスデプロイ部１１４に、リクエスト監視サービス３４０のデプロイ指示を出力する。リクエスト監視サービスデプロイ部１１４は、監視設定情報管理部１１１が受け付けたリクエスト監視設定情報及びグループ設定管理部１１２が受け付けたグループ設定情報に基づいて、監視するリクエストの情報が設定されたリクエスト監視サービス３４０を生成する。また、リクエスト監視サービスデプロイ部１１４は、現行のクラスタ３０２－１に、リクエスト監視サービス３４０をデプロイする。
次に、更新支援システム１００は、ロードバランサ３００に、新規のクラスタ３０２－２のリバースプロキシ３１０－２のルーティング設定を追加する（ステップＳ３０４）。
具体的には、更新処理管理部１１０が、ロードバランサ３００に、新規のクラスタ３０２－２のリバースプロキシ３１０－２のルーティング設定を追加する。
次に、更新支援システム１００は、ＤＮＳサービス３０１に、新規のクラスタ３０２－２のコンポーネントのＤＮＳレコードを追加する（ステップＳ３０５）。その後、更新支援システム１００は処理を終了する。
具体的には、更新処理管理部１１０が、新規のクラスタ３０２－２のリバースプロキシ３１０－２にルーティングするロードバランサ３００のエンドポイントを、ＤＮＳレコードとしてＤＮＳサービス３０１に追加する。
更新支援システム１００は、リクエスト監視サービス３４０から、リクエストの送信制御のログを取得し、ユーザ端末１０２に提示できる。
図１０は、実施例１の更新支援システム１００が提示するインタフェースの一例を示す図である。
ユーザインタフェース１０００は、コンポーネント表示欄１０１０及びリクエストログ表示欄１０２０を含む。
コンポーネント表示欄１０１０は、現行のクラスタ３０２－１及び新規のクラスタ３０２－２のコンポーネントを表示する欄である。コンポーネント表示欄１０１０は、コンポーネント依存関係抽出部１１３によって抽出されたコンポーネントの依存関係及びデプロイ結果に基づいて表示される。
リクエストログ表示欄１０２０は、リクエストのログを表示する欄である。リクエストログ表示欄１０２０には、サイドカー３５０が受信したトリガリクエスト、サイドカー３５０が送信したトリガリクエスト、及びデータ同期の完了を示すリクエスト等が表示される。
ユーザは、ユーザインタフェース１０００を参照することによって、コンポーネントの移行状態及びリクエストの流れを確認できる。また、サイドカー３５０が正しく機能しているか否かを確認できる。
ステートフルなコンポーネントにアクセスするコンポーネントが二つ以上存在する場合、図１１に示すように、各コンポーネントについてサイドカー３５０が設定される。
（変形例１）リクエスト監視サービス３４０は、新規のクラスタ３０２－２にデプロイされてもよい。また、各クラスタ３０２にリクエスト監視サービス３４０がデプロイされてもよい。
（変形例２）サイドカー３５０がリクエスト履歴情報３４５にアクセスできるようにしてもよい。この場合、更新支援システム１００に、リクエスト履歴情報３４５をデプロイする機能部を含めてもよい。
（変形例３）リクエスト履歴情報３４５は、新規のクラスタ３０２－２に設定してもよい。
以上で説明したように、本発明によれば、二つのクラスタ３０２間のステートフルなコンポーネントの整合性を保ったブルーグリーンデプロイメントを実現できる。また、グループ単位でコンポーネントをデプロイすることによって、リクエストに対するレスポンツノ遅延及びクラスタ３０２の通信量の増加を抑えることができる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ等の広範囲のプログラム又はスクリプト言語で実装できる。
さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
Claims (10)
- サービスを構成する複数のコンポーネントが稼働する基盤と接続する計算機システムであって、
演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続される通信装置を有する計算機を少なくとも一つ含み、
前記基盤は、前記複数のコンポーネントから構成されるクラスタを少なくとも一つ含み、
前記計算機システムは、
ターゲットクラスタに含まれる前記複数のコンポーネントのバージョンを更新する場合、前記ターゲットクラスタに含まれ、かつ、新規クラスタに移行する、複数のターゲットコンポーネントから構成されるグループの設定を受け付け、
前記新規クラスタに、バージョンが異なる前記複数のターゲットコンポーネントをデプロイし、
前記ターゲットコンポーネント以外の前記コンポーネントから前記ターゲットコンポーネントへ送信されるリクエストを受け付けるサイドカーを、前記ターゲットクラスタ及び前記新規クラスタにデプロイし、
前記サイドカーが受け付けた前記リクエストの前記ターゲットコンポーネントへの送信を前記サイドカーに指示するリクエスト監視部を、前記ターゲットクラスタ及び前記新規クラスタのいずれか一方にデプロイすることを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記リクエスト監視部は、
前記ターゲットクラスタ及び前記新規クラスタの各々の前記グループに含まれる前記複数のターゲットコンポーネント間で送受信されるリクエストを監視し、
前記リクエストの監視結果及び前記サイドカーが受け付けた前記リクエストの実行状態に基づいて、前記サイドカーが受け付けた前記リクエストの送信タイミングを決定することを特徴とする計算機システム。 - 請求項２に記載の計算機システムであって、
前記複数のターゲットコンポーネントは、ステートフルな第１コンポーネント及び前記第１コンポーネントに前記リクエストを送信する第２コンポーネントの各々を少なくとも一つ含み、
前記計算機システムは、前記ターゲットクラスタの前記グループに含まれる前記第１コンポーネントと、前記新規クラスタの前記グループに含まれる前記第１コンポーネントとが、互いに状態を同期するように設定することを特徴とする計算機システム。 - 請求項２に記載の計算機システムであって、
前記ターゲットクラスタに含まれる前記コンポーネントの依存関係を示す情報を生成し、
前記ターゲットクラスタに含まれる前記複数のコンポーネントのバージョンの更新を指示するユーザに前記情報を提示し、前記グループの設定を受け付けるためのインタフェースを提供することを特徴とする計算機システム。 - 請求項２に記載の計算機システムであって、
前記サイドカーが受け付けた前記リクエストの受信結果及び前記リクエスト監視部による前記リクエストの監視結果を、リクエスト履歴として取得し、
前記リクエスト履歴を提示するインタフェースを提供することを特徴とする計算機システム。 - サービスを構成する複数のコンポーネントが稼働する基盤と接続する計算機システムが実行する更新制御方法であって、
前記計算機システムは、演算装置、前記演算装置に接続される記憶装置、及び前記演算装置に接続される通信装置を有する計算機を少なくとも一つ含み、
前記基盤は、前記複数のコンポーネントから構成されるクラスタを少なくとも一つ含み、
前記更新制御方法は、
前記少なくとも一つの計算機が、ターゲットクラスタに含まれる前記複数のコンポーネントのバージョンを更新する場合、前記ターゲットクラスタに含まれ、かつ、新規クラスタに移行する、複数のターゲットコンポーネントから構成されるグループの設定を受け付けるステップと、
前記少なくとも一つの計算機が、前記新規クラスタに、バージョンが異なる前記複数のターゲットコンポーネントをデプロイするステップと、
前記少なくとも一つの計算機が、前記ターゲットコンポーネント以外の前記コンポーネントから前記ターゲットコンポーネントへ送信されるリクエストを受け付けるサイドカーを、前記ターゲットクラスタ及び前記新規クラスタにデプロイするステップと、
前記少なくとも一つの計算機が、前記サイドカーが受け付けた前記リクエストの前記ターゲットコンポーネントへの送信を前記サイドカーに指示するリクエスト監視部を、前記ターゲットクラスタ及び前記新規クラスタのいずれか一方にデプロイするステップと、を含むことを特徴とする更新制御方法。 - 請求項６に記載の更新制御方法であって、
前記リクエスト監視部は、
前記ターゲットクラスタ及び前記新規クラスタの各々の前記グループに含まれる前記複数のターゲットコンポーネント間で送受信されるリクエストを監視する処理と、
前記リクエストの監視結果及び前記サイドカーが受け付けた前記リクエストの実行状態に基づいて、前記サイドカーが受け付けた前記リクエストの送信タイミングを決定する処理と、を実行することを特徴とする更新制御方法。 - 請求項７に記載の更新制御方法であって、
前記複数のターゲットコンポーネントは、ステートフルな第１コンポーネント及び前記第１コンポーネントに前記リクエストを送信する第２コンポーネントの各々を少なくとも一つ含み、
前記更新制御方法は、前記少なくとも一つの計算機が、前記ターゲットクラスタの前記グループに含まれる前記第１コンポーネントと、前記新規クラスタの前記グループに含まれる前記第１コンポーネントとが、互いに状態を同期するように設定するステップを含むことを特徴とする更新制御方法。 - 請求項７に記載の更新制御方法であって、
前記少なくとも一つの計算機が、前記ターゲットクラスタに含まれる前記コンポーネントの依存関係を示す情報を生成するステップと、
前記少なくとも一つの計算機が、前記ターゲットクラスタに含まれる前記複数のコンポーネントのバージョンの更新を指示するユーザに前記情報を提示し、前記グループの設定を受け付けるためのインタフェースを提供するステップと、を含むことを特徴とする更新制御方法。 - 請求項７に記載の更新制御方法であって、
前記少なくとも一つの計算機が、前記サイドカーが受け付けた前記リクエストの受信結果及び前記リクエスト監視部による前記リクエストの監視結果を、リクエスト履歴として取得するステップと、
前記少なくとも一つの計算機が、前記リクエスト履歴を提示するインタフェースを提供するステップと、含むことを特徴とする更新制御方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2021134007A JP7621911B2 (ja) | 2021-08-19 | 2021-08-19 | 計算機システム及び更新制御方法 |
| JP2021-134007 | 2021-08-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2023021731A1 true WO2023021731A1 (ja) | 2023-02-23 |
Family
ID=85240290
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/JP2022/006472 WO2023021731A1 (ja) | 2021-08-19 | 2022-02-17 | 計算機システム及び更新制御方法 |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP7621911B2 (ja) |
| WO (1) | WO2023021731A1 (ja) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180196741A1 (en) * | 2015-03-27 | 2018-07-12 | Amazon Technologies, Inc. | Using containers for update deployment |
| US20190065165A1 (en) * | 2014-11-10 | 2019-02-28 | Amazon Technologies, Inc. | Automated deployment of applications |
| JP2020113924A (ja) * | 2019-01-15 | 2020-07-27 | 富士通株式会社 | モニタリングプログラム，プログラマブルデバイス及びモニタリング方法 |
| US20210103441A1 (en) * | 2019-10-08 | 2021-04-08 | Sap Se | Cloud application update with reduced downtime |
-
2021
- 2021-08-19 JP JP2021134007A patent/JP7621911B2/ja active Active
-
2022
- 2022-02-17 WO PCT/JP2022/006472 patent/WO2023021731A1/ja active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190065165A1 (en) * | 2014-11-10 | 2019-02-28 | Amazon Technologies, Inc. | Automated deployment of applications |
| US20180196741A1 (en) * | 2015-03-27 | 2018-07-12 | Amazon Technologies, Inc. | Using containers for update deployment |
| JP2020113924A (ja) * | 2019-01-15 | 2020-07-27 | 富士通株式会社 | モニタリングプログラム，プログラマブルデバイス及びモニタリング方法 |
| US20210103441A1 (en) * | 2019-10-08 | 2021-04-08 | Sap Se | Cloud application update with reduced downtime |
Also Published As
| Publication number | Publication date |
|---|---|
| JP7621911B2 (ja) | 2025-01-27 |
| JP2023028351A (ja) | 2023-03-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112118565B (zh) | 多租户服务灰度发布方法、装置、计算机设备和存储介质 | |
| EP3338186B1 (en) | Optimal storage and workload placement, and high resiliency, in geo-distributed cluster systems | |
| US7165087B1 (en) | System and method for installing and configuring computing agents | |
| EP2944070B1 (en) | Service migration across cluster boundaries | |
| WO2009098909A1 (ja) | 仮想アプライアンス配備システム | |
| WO2004025466A2 (en) | Distributed computing infrastructure | |
| CN108696581A (zh) | 分布式信息的缓存方法、装置、计算机设备以及存储介质 | |
| US20170063986A1 (en) | Target-driven tenant identity synchronization | |
| CN105450759A (zh) | 一种系统镜像的管理方法和装置 | |
| JPWO2017179537A1 (ja) | ソフトウェア更新制御装置、ソフトウェア更新制御システム、ソフトウェア更新制御方法、及び、ソフトウェア更新制御プログラムが格納された記録媒体 | |
| CN110391940A (zh) | 服务地址的响应方法、装置、系统、设备和存储介质 | |
| WO2015158120A1 (zh) | 一种软件版本升级的方法及装置 | |
| CN110673941A (zh) | 多机房中微服务的迁移方法、电子设备及存储介质 | |
| CN111404628A (zh) | 一种时间同步方法和装置 | |
| WO2023021731A1 (ja) | 計算機システム及び更新制御方法 | |
| US9264306B2 (en) | Deployment of software images with run-time reconnection | |
| JP2009217395A (ja) | 仮想サーバソフトウェア更新システム、仮想サーバソフトウェア更新方法、サーバ、及びサーバ用プログラム | |
| CN107704490A (zh) | 一种基于对等存储的数据处理方法及装置 | |
| JP2009251756A (ja) | クライアント装置、分散ファイルシステム、共有リソース多重化方法およびプログラム | |
| CN109491615A (zh) | 一种基于集群存储系统的仲裁系统 | |
| US20180150336A1 (en) | Management system and control method | |
| CN111078135B (zh) | 数据处理环境中的虚拟节点的增强数据存储 | |
| JP2015153330A (ja) | 仮想マシン配置システム及び方法 | |
| US12124857B2 (en) | Server management apparatus and server management method | |
| CN113542019B (zh) | 转控分离分布式cp的升级方法及系统 |
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: 22858056 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 22858056 Country of ref document: EP Kind code of ref document: A1 |