Setting device, API server, and setting method

Abstract

Provided is a setting device 40 for setting data to an API server operating in a container, wherein said setting device comprises: a first setting unit 401 for setting, in an application layer of the API server, a maximum reception resource amount of an API request from a user system received by an API processing unit of the application layer; and a second setting unit 402 for performing, in a resource of a transport layer of the API server, a setting for receiving a health check request from a maintenance operation system, and a setting associated with the API processing unit so as to be linked with activity / inactivity of the API processing unit.

Description

Setting device, API server, and setting method

[0001] The present disclosure relates to a setting device, an API server, and a setting method.

[0002] For an API (Application Programming Interface) server running in a container, stable operation without downtime and without adding external devices is required when a large number of API requests arrive from user systems. To address this, there is a flow control technology that sets a maximum amount of resources that can be accepted for API requests and rejects API requests that exceed a set threshold (Non-Patent Document 1).

[0003] There is also a demand for monitoring the health of API servers at the application level. To address this, there is a health check technology in which a maintenance operation system running on a container periodically sends a health check request to the API server, checks whether there is a response from the API server, and restarts the container of the API server if there is no response from the API server.

[0004] “Flow Control with Tomcat,” Casley Deep Innovations, Inc., [online], [Retrieved December 23, 2023], <URL: https: / / www.casleydi.com / blog / engineer / 197 / >

[0005] When the API server is operated using flow control and health checks, the API processing unit in the application layer receives API requests from user systems and health check requests from the maintenance and operation system.

[0006] This method works normally when the number of API requests is below the maximum resource capacity. However, when a large number of API requests arrive from a user system, the API processing unit uses up to the maximum resource capacity, making it unable to process health check requests from the maintenance operation system. The health check requests are rejected by the flow control. This poses a problem: the maintenance operation system may mistakenly determine that the health check is NG and erroneously restart the API server container.

[0007] The present disclosure has been made in consideration of the above circumstances, and an object of the present disclosure is to provide a technology that enables health checks of an API server to be continued even when a large number of API requests arrive.

[0008] A configuration device according to one aspect of the present disclosure is a configuration device that sets data in an API (Application Programming Interface) server running in a container, and includes: a first configuration unit that sets, in the application layer of the API server, a maximum amount of resources that can be accepted for API requests from a user system that can be accepted by an API processing unit in the application layer; and a second configuration unit that sets, in the transport layer resources of the API server, a setting to accept health check requests from a maintenance and operation system and a setting to be linked to the API processing unit so as to be linked to the life and death of the API processing unit.

[0009] An API server according to one aspect of the present disclosure is an API (Application Programming Interface) server running in a container, and includes an API processing unit in the application layer that accepts and processes API requests from a user system using the maximum amount of resources that can be accepted for API requests set in the application layer, and transport layer resources that are configured to accept health check requests from a maintenance and operation system and that are linked to the API processing unit so as to be linked to the status of the API processing unit.

[0010] One aspect of the configuration method of the present disclosure is a configuration method for setting data in an API (Application Programming Interface) server running in a container, in which a configuration device performs a first setting in the application layer of the API server to set the maximum amount of resources that can be accepted for API requests from a user system that can be accepted by an API processing unit in the application layer, and a second setting in the transport layer resources of the API server to accept health check requests from a maintenance and operation system and to be linked to the API processing unit so as to be linked to the life or death of the API processing unit, in any order or simultaneously.

[0011] According to the present disclosure, it is possible to provide a technology that allows for continued health checks of an API server even when a large number of API requests arrive.

[0012] Fig. 1 is a diagram showing a system configuration according to this embodiment. Fig. 2 is a diagram showing a specific example of the system configuration. Fig. 3 is a diagram showing a data setting method performed by a setting device. Fig. 4 is a diagram showing an example of the hardware configuration of the setting device.

[0013] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the description of the drawings, the same parts are designated by the same reference numerals and the description thereof will be omitted.

[0014] [Summary] The present disclosure provides a method for controlling the flow rate of API requests to an API server running in a container while continuing to check the health of the API server, without adding an external device.

[0015] Specifically, the maximum number of resources that can be accepted for API requests by the API processing unit in the application layer is set in the application layer of the API server. Also, the transport layer resources of the API server are set to accept health check requests from the maintenance operation system and to be linked to the API processing unit so as to be linked to the API processing unit's status.

[0016] This allows the API server to process health check requests while processing API requests up to the maximum number of API request reception resources available, even when external devices cannot be added to the API server. As a result, erroneous determinations of health check results can be eliminated even when a large number of API requests arrive.

[0017] [System Configuration] FIG. 1 is a diagram showing a system configuration according to this embodiment.

[0018] The system 1 includes an API server 10 that runs in a container, a user system 20 that sends API requests to the API server 10, and a maintenance operation system 30 that runs in a container and sends health check requests to the API server 10 to check the normality of the API server 10. "Running in a container" has the same meaning as "running as a container" or "running on a container platform."

[0019] The application layer of the API server 10 includes an API processing unit 101 that processes API requests and health check requests. The transport layer of the API server 10 includes a resource 102 that is linked to the API processing unit 101. The linking between the API processing unit 101 and the resource 102 is performed by a system call such as bind().

[0020] In this embodiment, the system configuration described above further includes a setting device 40 that sets data in the API server 10. The setting device 40 is present in the maintenance operation system 30, for example, and includes a first setting unit 401 and a second setting unit 402. Note that the setting device 40 may be a computer other than the maintenance operation system 30. For example, the setting device 40 may be a server device or a user terminal that implements the API server 10.

[0021] The first setting unit 401 has a function of setting the maximum amount of resources that can be received for API requests from the user system 20 that are received by the API processing unit 101 in the application layer of the API server 10. The maximum amount of resources that can be received for API requests is, for example, the maximum number of API requests, the maximum CPU usage rate that can process API requests, and the maximum amount of memory usage.

[0022] The second setting unit 402 has a function of setting the health check condition data from the maintenance operation system 30 to "connectability to the transport layer resource 102 linked to the API processing unit 101." In other words, the second setting unit 402 performs the function of setting the transport layer resource 102 of the API server 10 to accept a health check request from the maintenance operation system 30 and linking it to the API processing unit 101 so as to be linked to the life or death of the API processing unit 101.

[0023] The setting of the API server 10 by the setting device 40 may be performed by the setting device 40 itself, independently and autonomously, or may be performed by the setting device 40 based on setting input by the user.

[0024] By setting the API server 10 by the setting device 40, the API processing unit 101 and the resource 102 of the API server 10 are provided with the following functions.

[0025] The API processing unit 101 has a function of controlling the flow rate of API requests using the maximum resource amount for API request reception set in the application layer, and of receiving and processing API requests from the user system 20 .

[0026] The resource 102 is configured to receive a health check request from the maintenance operation system 30 and is also configured to be linked to the API processing unit 101 so as to be linked to the life and death of the API processing unit 101. The resource 102 has a function of receiving a health check request from the maintenance operation system 30, calling the API processing unit 101 based on the health check request, and, if the API processing unit 101 goes down, closing its own port in response to the down.

[0027] [Specific Example] FIG. 2 is a diagram showing a specific example of the system configuration of the system 1. As shown in FIG.

[0028] A Tomcat container running on Kubernetes (k8s) is used as the API server 10. A Tomcat process 101 running as an API processing unit 101 in the application layer of the Tomcat container 10 is started using a TCP transport layer resource 102 with port number 8080.

[0029] By setting a maxThreads value (maximum amount of resources for receiving API requests) in the application layer of the Tomcat container 10, the Tomcat process 101 controls the flow rate of API requests from the portal site 20 (user system) based on the maximum number of simultaneous connections.

[0030] The maintenance operation system 30 utilizes the Liveness Probe function of k8s, and sets the health check target to the TCP socket of the transport layer resource 102 of the Tomcat container 10. In other words, in order to exclude the health check request from the flow control target by the Tomcat process 101, the health check confirmation target by the LivenessProbe 30 is changed to the TCP socket of the Tomcat container 10.

[0031] This prevents the Tomcat container 10 from going down even when a large number of API requests arrive, and allows the health check by the LivenessProbe 30 to continue. If the Tomcat process 101 goes down, the TCP port 8080 is closed as shown on the right side of Figure 2, so that an abnormality in the Tomcat container 10 can be detected by the failure of the health check.

[0032] [Setting Method] FIG. 3 is a diagram showing a data setting method performed by the setting device 40. As shown in FIG.

[0033] The first setting unit 401 sets, in the application layer of the API server 10, the maximum reception resource amount of an API request from the user system 20 that is received by the API processing unit 101 in the application layer (step S1).

[0034] Next, the second setting unit 402 sets the transport layer resources of the API server 10 to accept health check requests from the maintenance and operation system 30 and to be linked to the API processing unit 101 so as to be linked to the life and death of the API processing unit 101 (step S2).

[0035] The order of steps S1 and S2 is arbitrary. Step S1 may be performed before step S2, or steps S1 and S2 may be performed simultaneously.

[0036] [Effect] According to this embodiment, the application layer of the API server 10 is set to a maximum resource amount for accepting 20 API requests from user systems that are accepted by the API processing unit 101 in the application layer, and the transport layer resources of the API server 10 are set to accept health check requests from the maintenance and operation system 30 and are linked to the API processing unit 101 so as to be linked to the life and death of the API processing unit 101. Therefore, it becomes possible to continue health checks of the API server even when a large number of API requests arrive, without adding an external device to the API server 10.

[0037] [Others] The present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present disclosure.

[0038] When the setting device 40 of the present embodiment described above is configured with a computer other than the maintenance operation system 30, it can be realized, for example, by using a general-purpose computer system including a CPU 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906, as shown in Fig. 4. The memory 902 and the storage 903 are storage devices. In this computer system, the CPU 901 executes a predetermined program loaded onto the memory 902, thereby realizing each function of the setting device 40.

[0039] The setting device 40 may be implemented by one computer. The setting device 40 may be implemented by multiple computers. The setting device 40 may be a virtual machine implemented on a computer.

[0040] The program for the setting device 40 can be stored in a computer-readable recording medium such as a HDD, SSD, USB memory, CD, or DVD. The computer-readable recording medium is, for example, a non-transitory recording medium. The program for the setting device 40 can also be distributed via a communication network.

[0041] 1 System 10 API server, Tomcat container 101 API processing unit, Tomcat process 102 Resource 20 User system, portal site 30 Maintenance operation system, Liveness Probe 40 Setting device 401 First setting unit 402 Second setting unit 901 CPU 902 Memory 903 Storage 904 Communication device 905 Input device 906 Output device

Claims

1. A setting device for setting data in an API (Application Programming Interface) server running in a container, comprising: a first setting unit for setting, in the application layer of the API server, the maximum amount of resources that can be received for API requests from user systems that are received by the API processing unit in the application layer; and a second setting unit for setting, in the transport layer resources of the API server, the resources to receive health check requests from a maintenance operation system and to be linked to the API processing unit so as to be linked to the API processing unit in accordance with the status of the API processing unit.

2. An API (Application Programming Interface) server that runs in a container, comprising: an API processing unit in the application layer that receives and processes API requests from a user system using the maximum amount of resources that can be received for API requests set in the application layer; and transport layer resources that are configured to receive health check requests from a maintenance and operation system and are linked to the API processing unit so as to be linked to the status of the API processing unit.

3. A configuration method for setting data in an API (Application Programming Interface) server running in a container, in which a configuration device performs the following in any order or simultaneously: a first setting in which the application layer of the API server is set to the maximum amount of resources that can be received for API requests from user systems that are received by the API processing unit of the application layer; and a second setting in which the transport layer resources of the API server are set to receive health check requests from a maintenance and operation system and are linked to the API processing unit so as to be linked to the life and death of the API processing unit.

Images