Service provision system, information processing device and service provision program
The system adjusts API request rates based on microservice load to optimize performance and prevent overload, enhancing operational efficiency and user convenience.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2026-03-12
AI Technical Summary
Conventional techniques do not account for the load of microservices resulting from API requests, leading to inefficiencies and potential throughput penalties.
A service providing system that adjusts API request rate limits based on the overall load of microservices, increasing or decreasing limits according to load thresholds, and updating limits periodically or upon client requests.
Enables the system to operate in accordance with microservice loads, improving convenience and reducing the risk of overload by dynamically managing API request rates.
Smart Images

Figure 2026044168000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates to a service providing system, an information processing device, and a service providing program that provide services that are used by user terminals used by users. [Background technology]
[0002] Conventionally, it is known to allocate the transmission of API event submissions from power users to a SaaS by assigning the power users to an auxiliary API event queue managed by a proxy that recognizes the power users as submitting API events beyond the limit when the API event rate or volume for the user group as a whole exceeds or approaches a SaaS-imposed trigger of a throughput penalty for the user group, and slows the power users' rate of submissions to the SaaS vendor (see, for example, Patent Document 1). [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Special Publication No. 2024-504201 Summary of the Invention [Problem to be solved by the invention]
[0004] However, conventional techniques do not operate in accordance with the load of microservices that operate due to API requests.
[0005] Therefore, an object of the present invention is to provide a service providing system, an information processing device, and a service providing program that can operate in accordance with the load of microservices that operate due to API requests. [Means for solving the problem]
[0006] The service providing system of the present invention is characterized in that when a specific request is received as a specific API request to which specific identification information is assigned as identification information of a specific client, if the number of times the API request to which the specific identification information is assigned does not exceed a specific rate limit as a rate limit associated with the specific identification information, the service providing system executes a connection to a microservice in response to the specific request, and when the specific request is received, updates the specific rate limit in accordance with the overall load of all of the microservices that operate due to the specific request.
[0007] With this configuration, when the service providing system of the present invention receives an API request accompanied by the identification information of a specific client, it updates the rate limit associated with the identification information of the specific client in accordance with the overall load of all microservices that operate as a result of the received API request, thereby enabling the system to operate in accordance with the load of the microservices that operate as a result of the API request.
[0008] The service providing system of the present invention may increase the specific rate limit when the specific request is received and the load is equal to or less than a specific threshold.
[0009] With this configuration, when the service providing system of the present invention receives an API request accompanied by the identification information of a specific client, if the overall load of all microservices operating due to the received API request is below a specific threshold, it increases the rate limit associated with the identification information of the specific client, thereby improving convenience when there is room for load on the microservices.
[0010] The service providing system of the present invention may lower the specific rate limit when the specific request is received and the load is equal to or greater than a specific threshold.
[0011] With this configuration, when the service providing system of the present invention receives an API request accompanied by the identification information of a specific client, if the overall load of all microservices operating due to the received API request is equal to or greater than a specific threshold, the service providing system lowers the rate limit associated with the identification information of the specific client, thereby reducing the possibility of the load on the microservices becoming too large.
[0012] The service providing system of the present invention may update the specific rate limit to a default value if the current date and time is equal to or greater than a specific time since the most recent update date and time of the specific rate limit.
[0013] With this configuration, the service providing system of the present invention updates the rate limit associated with the identification information of a specific client to the default one if the current date and time has passed more than a specific time since the most recent update date and time of the rate limit associated with the identification information of the specific client, thereby reducing the possibility that the rate limit will differ from the default one for a long period of time.
[0014] When the service providing system of the present invention receives the specific request and updates the specific rate limit, it may send an API response indicating that the specific rate limit has been updated to the sender of the specific request.
[0015] With this configuration, when the service providing system of the present invention receives an API request accompanied by the identification information of a specific client, and updates the rate limit associated with the identification information of the specific client, it sends an API response to the sender of the API request indicating that the rate limit associated with the identification information of the specific client has been updated, thereby improving convenience for the client.
[0016] The service providing system of the present invention may include the updated rate limit associated with the specific identification information in the API response.
[0017] With this configuration, the service providing system of the present invention includes, in the API response, the updated rate limit associated with the identification information of a specific client, thereby further improving convenience for the client.
[0018] When the service providing system of the present invention receives the specific request and updates the specific rate limit, it may include information in a web page associated with the specific identification information that the specific rate limit has been updated.
[0019] With this configuration, when the service providing system of the present invention receives an API request accompanied by the identification information of a specific client, and updates the rate limit associated with the identification information of the specific client, the service providing system includes information in the web page associated with the identification information of the specific client that the rate limit associated with the identification information of the specific client has been updated, thereby improving the convenience of users who can view this web page.
[0020] The service providing system of the present invention may include, in the web page, the updated rate limit associated with the specific identification information.
[0021] With this configuration, the service provision system of the present invention includes the updated rate limit associated with the identification information of a specific client in the web page associated with the identification information of the specific client, thereby further improving the convenience for users who can view this web page.
[0022] The service provision program of the present invention is a service provision program executed by a computer, and when the computer receives a specific request as a specific API request assigned with specific identification information as identification information of a specific client, if the number of times the computer has received the API request assigned with the specific identification information does not exceed a specific rate limit as a rate limit associated with the specific identification information, the program causes the computer to connect to a microservice in response to the specific request, and when the computer receives the specific request, causes the computer to update the specific rate limit in accordance with the overall load of all of the microservices that operate due to the specific request.
[0023] With this configuration, when a computer executing the service provision program of the present invention receives an API request accompanied by the identification information of a specific client, the computer updates the rate limit associated with the identification information of the specific client in accordance with the overall load of all microservices operating as a result of the received API request, thereby enabling the computer to operate in accordance with the load of the microservices operating as a result of the API request. [Effects of the Invention]
[0024] The service providing system, information processing device, and service providing program of the present invention can operate in accordance with the load of microservices that operate due to API requests. [Brief explanation of the drawings]
[0025] [Figure 1] 1 is a block diagram of a system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram of an example of the service providing system shown in FIG. 1 when configured by one computer. [Figure 3] FIG. 3 is a diagram showing an example of user management information shown in FIG. [Figure 4]3 is a diagram showing an example of rate limit management information shown in FIG. 2; FIG. [Figure 5] 3 is a diagram illustrating an example of API request history information illustrated in FIG. 2. FIG. [Figure 6] FIG. 2 is a block diagram of an example of a user terminal shown in FIG. [Figure 7] 3 is a flowchart of the operation of the service providing system shown in FIG. 2 when an API request is received from a client. [Figure 8] 10 is a flowchart illustrating an example of the operation of the service providing system shown in FIG. 2 when determining whether the number of times an API request to which client identification information assigned to the target request is received exceeds a rate limit. [Figure 9] 2 is a sequence diagram of the operation of the system shown in FIG. 1 when a user terminal displays a web page for the user. [Figure 10] 3 is a flowchart of the operation of the service providing system shown in FIG. 2 when the rate limit is returned to the default rate limit. DETAILED DESCRIPTION OF THE INVENTION
[0026] Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0027] First, the configuration of a system according to an embodiment of the present invention will be described.
[0028] FIG. 1 is a block diagram of a system 10 according to the present embodiment.
[0029] As shown in Fig. 1, the system 10 includes a service providing system 20 that provides services to be used by a user terminal used by a user. The service providing system 20 may be configured with a single computer such as a PC (Personal Computer), or may be configured with multiple computers. The service providing system 20 may be configured on a cloud.
[0030] The system 10 includes a user terminal 30 used by a user. The system 10 may also include at least one other user terminal having a similar configuration to the user terminal 30. The user terminal may be configured, for example, by a computer such as a PC.
[0031] FIG. 2 is a block diagram of an example of a service providing system 20 configured by one computer.
[0032] As shown in Figure 2, the service providing system 20 includes an operation unit 21, which is an operation device such as a keyboard or mouse through which various operations are input; a display unit 22, which is a display device such as an LCD (Liquid Crystal Display) that displays various information; a communication unit 23, which is a communication device that communicates with external devices via a network such as a LAN (Local Area Network) or the Internet, or directly via a wired or wireless connection without using a network; a memory unit 24, which is a non-volatile memory device such as a semiconductor memory or an HDD (Hard Disk Drive) that stores various information; and a control unit 25 that controls the entire service providing system 20.
[0033] The storage unit 24 can store a service providing program 24a for providing services. The service providing program 24a may be installed in the service providing system 20 during the manufacturing stage of the service providing system 20, or may be additionally installed in the service providing system 20 from an external storage medium such as a USB (Universal Serial Bus) memory, or may be additionally installed in the service providing system 20 from a network.
[0034] The storage unit 24 can store user management information 24b for managing users of the service providing system 20.
[0035] FIG. 3 is a diagram showing an example of the user management information 24b.
[0036] The user management information 24b shown in FIG. 3 includes, for each user, a user ID as the user's identification information, a user password, and identification information of the client manufactured by the user (hereinafter, client identification information will be referred to as "client identification information"). For users who have manufactured multiple clients, the user management information 24b is associated with multiple client identification information. For users who have not manufactured clients, the user management information 24b is not associated with client identification information. The user management information 24b shown in FIG. 3 is drawn with some information omitted.
[0037] As shown in FIG. 2, the storage unit 24 can store rate limit management information 24c for managing rate limits of an API (Application Programming Interface).
[0038] FIG. 4 is a diagram showing an example of the rate limit management information 24c.
[0039] 4, the rate limit management information 24c includes, for each client identification information, client identification information, the current rate limit for the client, the default rate limit for the client, the lower limit of the rate limit for the client, the upper limit of the rate limit for the client, and an update date and time indicating the date and time when the rate limit for the client was updated. The rate limit management information 24c shown in FIG. 4 is drawn with some information omitted.
[0040] The client identification information may be issued, for example, by the operator of the service providing system 20. The same client identification information may be issued for clients manufactured by the same manufacturer regardless of the type of client, or different client identification information may be issued for each type of client even if the clients are manufactured by the same manufacturer.
[0041] As shown in FIG. 2, the storage unit 24 can store API request history information 24d that indicates the history of API requests.
[0042] FIG. 5 is a diagram showing an example of the API request history information 24d.
[0043] As shown in Fig. 5, the API request history information 24d includes, for each API request, the date and time the API request was received and the client identification information assigned to the API request. Some information is omitted from the API request history information 24d shown in Fig. 5.
[0044] 2 includes, for example, a CPU (Central Processing Unit), a ROM (Read Only Memory) that stores programs and various data, and a RAM (Random Access Memory) that serves as a memory used as a work area for the CPU of the control unit 25. The CPU of the control unit 25 executes programs stored in the storage unit 24 or the ROM of the control unit 25.
[0045] By executing the service providing program 24a, the control unit 25 realizes microservices such as microservice 25a, a request receiving unit 25b that receives API requests from clients, a load analysis unit 25c that analyzes the load on the microservices, a rate limit management unit 25d that manages the rate limit of the API, a response generation unit 25e that generates an API response, a monitoring unit 25f that monitors the rate limit management unit 25d and includes a notification of an update to the rate limit in a web page for the user, and a web page generation unit 25g that generates a web page.
[0046] The load analysis unit 25c can quantify the load of a microservice based on, for example, the CPU usage rate of the microservice in the service providing system 20, the RAM usage rate of the microservice in the service providing system 20, and the response time of the microservice, i.e., the processing time of an API request. For example, the load analysis unit 25c can calculate the load of a microservice as a percentage.
[0047] FIG. 6 is a block diagram of an example of the user terminal 30. As shown in FIG.
[0048] As shown in Figure 6, the user terminal 30 includes an operation unit 31, which is an operation device such as a keyboard or mouse through which various operations are input; a display unit 32, which is a display device such as an LCD that displays various information; a communication unit 33, which is a communication device that communicates with external devices via a network such as a LAN or the Internet, or directly via a wired or wireless connection without using a network; a memory unit 34, which is a non-volatile memory device such as a semiconductor memory or HDD that stores various information; and a control unit 35 that controls the entire user terminal 30.
[0049] The storage unit 34 can store a client program 34a for the client and a web browser program 34b for the web browser. The client program 34a and the web browser program 34b may each be installed on the user terminal 30 during the manufacturing stage of the user terminal 30, or may be additionally installed on the user terminal 30 from an external storage medium such as a USB memory, or may be additionally installed on the user terminal 30 from a network.
[0050] The control unit 35 includes, for example, a CPU, a ROM that stores programs and various data, and a RAM as memory used as a work area for the CPU of the control unit 35. The CPU of the control unit 35 executes programs stored in the storage unit 34 or the ROM of the control unit 35.
[0051] The control unit 35 executes the client program 34a to implement a client 35a.
[0052] The control unit 35 executes the web browser program 34b to implement the web browser 35b.
[0053] The user of the user terminal 30 may be the manufacturer of the client 35a, or may be someone other than the manufacturer of the client 35a.
[0054] The operation of the system 10 will now be described.
[0055] In the following, the user terminal 30 will be described as a representative of the user terminals. However, user terminals other than the user terminal 30 can also perform the same operations as the user terminal 30.
[0056] First, the operation of the service providing system 20 when an API request is received from the client 35a will be described.
[0057] FIG. 7 is a flowchart showing the operation of the service providing system 20 when an API request is received from the client 35a.
[0058] When the client 35a uses an API provided by the service providing system 20, the client 35a sends an API request to the service providing system 20, along with the client identification information of the client 35a. For example, the client 35a may add the client identification information of the client 35a to the API request as an API key. Upon receiving the API request, the service providing system 20 executes the operation shown in FIG. 7. Hereinafter, the API request that causes the service providing system 20 to start the operation shown in FIG. 7 will be referred to as the "target request" in the description of the operation shown in FIG. 7.
[0059] As shown in FIG. 7, the request receiving unit 25b of the service providing system 20 determines whether the number of times an API request to which the client identification information assigned to the target request has been assigned exceeds the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c (S101).
[0060] For example, if the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is "100 times / minute or 10,000 times / week," the request receiving unit 25b determines whether the number of times an API request to which the client identification information assigned to the target request is assigned exceeds the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c, as shown in FIG. 8.
[0061] FIG. 8 is a flowchart illustrating an example of the operation of the service providing system 20 when determining whether the number of times an API request to which the client identification information assigned to the target request has been received exceeds the rate limit.
[0062] As shown in FIG. 8, the request receiving unit 25b calculates the number of times that an API request that was assigned the same client identification information as the client identification information assigned to the target request was received within the past one minute, starting from the current date and time, based on the API request history information 24d (S121).
[0063] When the process of S121 is completed, the request receiving unit 25b determines whether the number calculated in S121 exceeds 100 (S122).
[0064] If the request receiving unit 25b determines in S122 that the number calculated in S121 does not exceed 100, it calculates the number of times that an API request that was assigned the same client identification information as the client identification information assigned to the target request was received within the past week, starting from the current date and time, based on the API request history information 24d (S123).
[0065] When the process of S123 ends, the request receiving unit 25b determines whether the number calculated in S123 exceeds 10,000 (S124).
[0066] If the request receiving unit 25b determines in S124 that the number calculated in S123 does not exceed 10,000, it determines that the number of times the API request to which the client identification information assigned to the target request has been received does not exceed the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c (S125), and terminates the operation shown in Figure 8.
[0067] If the request receiving unit 25b determines in S122 that the number of times calculated in S121 exceeds 100, or determines in S124 that the number of times calculated in S123 exceeds 10,000, it determines that the number of times the API request to which the client identification information assigned to the target request has been received exceeds the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c (S126), and terminates the operation shown in Figure 8.
[0068] The above describes a case where the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is "100 times / minute or 10,000 times / week." However, the same applies to rate limits other than "100 times / minute or 10,000 times / week."
[0069] As shown in FIG. 7, when it is determined in S101 that the number of times an API request to which the client identification information assigned to the target request has been received exceeds the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c, the response generation unit 25e generates an API response including an error message indicating that the service cannot be provided because the rate limit has been exceeded (S102).
[0070] If the request receiving unit 25b determines in S101 that the number of times the API request to which the client identification information assigned to the target request has been received does not exceed the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c, the request receiving unit 25b connects to the microservice corresponding to the target request (S103). Therefore, the microservice that operates due to the target request starts operating.
[0071] When the process of S103 ends, the load analysis unit 25c determines whether the overall load of all microservices operating due to the target request is equal to or less than a first threshold (S104). The first threshold in S104 is, for example, 30%.
[0072] When it is determined in S104 that the overall load of all microservices operating due to the target request is equal to or less than the first threshold, the rate limit management unit 25d determines whether the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is less than the upper limit associated with the client identification information assigned to the target request in the rate limit management information 24c (S105).
[0073] When the rate limit management unit 25d determines in S105 that the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is less than the upper limit associated with the client identification information assigned to the target request in the rate limit management information 24c, the rate limit management unit 25d increases the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c in accordance with a specific rule (S106). However, the rate limit management unit 25d can only increase the rate limit in S106 up to the upper limit associated with the client identification information assigned to the target request in the rate limit management information 24c. Furthermore, the rate limit management unit 25d stores the date and time when the process of S106 was executed as an update date and time in the rate limit management information 24c, in association with the client identification information assigned to the target request.
[0074] When the processing of S106 is completed, the monitoring unit 25f includes a notification (hereinafter referred to as the "raising notification") that the rate limit has been raised and the rate limit after being raised in S106 in a web page for the user identified by the user ID associated in the user management information 24b with the client identification information assigned to the target request, i.e., a web page for the manufacturer of the client identified by the client identification information assigned to the target request (S107).
[0075] When the processing of S107 ends, the response generation unit 25e generates an API response indicating that the microservice has been connected, that the rate limit has been increased, and the rate limit after the increase in S106 (S108). For example, the response generation unit 25e may include information about the increase in the rate limit and the rate limit after the increase in S106 in the header of the API response. Note that when the client 35a receives an API response including information about the increase in the rate limit and the rate limit after the increase in S106, the client 35a can reflect the increase in the rate limit and the rate limit after the increase in some kind of operation, for example, by displaying on the display unit 32 that the rate limit has been increased and the rate limit after the increase.
[0076] If the load analysis unit 25c determines in S104 that the overall load of all microservices operating due to the target request is not equal to or less than the first threshold, the load analysis unit 25c determines whether the overall load of all microservices operating due to the target request is equal to or greater than a second threshold (S109). The second threshold in S109 is greater than the first threshold in S104, and is, for example, 80%.
[0077] When the rate limit management unit 25d determines in S109 that the overall load of all microservices operating due to the target request is equal to or greater than the second threshold, it determines whether the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c exceeds the lower limit associated with the client identification information assigned to the target request in the rate limit management information 24c (S110).
[0078] When the rate limit management unit 25d determines in S110 that the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c exceeds the lower limit associated with the client identification information assigned to the target request in the rate limit management information 24c, the rate limit management unit 25d lowers the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c in accordance with a specific rule (S111). However, the rate limit management unit 25d can only lower the rate limit in S111 to the lower limit associated with the client identification information assigned to the target request in the rate limit management information 24c. Furthermore, the rate limit management unit 25d stores the date and time when the process of S111 was executed as an update date and time in the rate limit management information 24c, in association with the client identification information assigned to the target request.
[0079] When the processing of S111 is completed, the monitoring unit 25f includes a notification (hereinafter referred to as the "reduction notification") that the rate limit has been reduced and the rate limit after being reduced in S111 in a web page for the user identified by the user ID associated in the user management information 24b with the client identification information assigned to the target request, i.e., a web page for the manufacturer of the client identified by the client identification information assigned to the target request (S112).
[0080] When the processing of S112 ends, the response generation unit 25e generates an API response indicating that the microservice has been connected, that the rate limit has been reduced, and the rate limit after the reduction in S111 (S113). For example, the response generation unit 25e may include information about the rate limit being reduced and the rate limit after the reduction in S111 in the header of the API response. Note that when the client 35a receives an API response including information about the rate limit being reduced and the rate limit after the reduction in S111, the client 35a can reflect the fact that the rate limit has been reduced and the rate limit after the reduction in some kind of operation, such as by displaying on the display unit 32 that the rate limit has been reduced and the rate limit after the reduction.
[0081] When the response generation unit 25e determines in S105 that the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is not less than the upper limit associated with the client identification information assigned to the target request in the rate limit management information 24c, or determines in S109 that the overall load of all microservices operating due to the target request is not equal to or greater than the second threshold, or determines in S110 that the current rate limit associated with the client identification information assigned to the target request in the rate limit management information 24c is not greater than the lower limit associated with the client identification information assigned to the target request in the rate limit management information 24c, the response generation unit 25e generates an API response indicating that it has connected to the microservice (S114).
[0082] When the processing of S102, S108, S113 or S114 is completed, the request receiving unit 25b transmits the API response generated in S102, S108, S113 or S114 to the client that sent the target request (S115), and ends the operation shown in FIG. 7.
[0083] Next, the operation of the system 10 when the user terminal 30 displays a web page for the user will be described.
[0084] FIG. 9 is a sequence diagram of the operation of the system 10 when the user terminal 30 displays a web page for the user.
[0085] A user can instruct the user terminal 30 to access a web page for logging in to the service providing system 20 (hereinafter referred to as the "login page") via the operation unit 31 of the user terminal 30. When instructed to access the login page, the web browser 35b of the user terminal 30 accesses the login page (S141), as shown in FIG.
[0086] When the web page generation unit 25g of the service providing system 20 receives the access in S141, it transmits the data of the login page to the web browser 35b (S142).
[0087] When the web browser 35b receives the data transmitted in S142, it displays a login page based on the received data on the display unit 32 (S143). Therefore, the user can enter the combination of his or her own user ID and password on the login page displayed on the display unit 32.
[0088] When the user ID and password are entered on the login page, the web browser 35b transmits the combination of the entered user ID and password to the service providing system 20 (S144).
[0089] If the user ID and password combination sent in S144 is not stored in the user management information 24b, i.e., if user authentication fails, the web page generation unit 25g of the service providing system 20 sends data of a web page indicating login failure (hereinafter referred to as the "login failure page") to the web browser 35b (S145).
[0090] When the web browser 35b receives the data transmitted in S145, it displays a login failure page on the display unit 32 based on the received data (S146).
[0091] If the combination of user ID and password sent in S144 is stored in the user management information 24b, i.e., if the user authentication is successful, the web page generation unit 25g of the service providing system 20 sends web page data for the user identified by the user ID sent in S144 to the web browser 35b (S147).
[0092] When the web browser 35b receives the data transmitted in S147, it displays a web page based on the received data on the display unit 32 (S148). If the user is a client manufacturer and the web page for the user contains an increase notice, the user can recognize that the rate limit has been increased and the rate limit after the increase. Also, if the user is a client manufacturer and the web page for the user contains a decrease notice, the user can recognize that the rate limit has been decreased and the rate limit after the decrease.
[0093] Next, the operation of the service providing system 20 when the rate limit is returned to the default rate limit will be described.
[0094] FIG. 10 is a flowchart showing the operation of the service providing system 20 when the rate limit is returned to the default rate limit.
[0095] 10, the rate limit management unit 25d determines whether or not there is client identification information in the rate limit management information 24c for which the current date and time has been updated for a specific period of time or more until it determines that there is client identification information in the rate limit management information 24c for which the current date and time has been updated for a specific period of time or more (S161). The specific period of time in S161 may be, for example, several tens of minutes.
[0096] When the rate limit management unit 25d determines in S161 that there is client identification information in the rate limit management information 24c where the current date and time is more than a specific time after the update date and time, it updates the current rate limit associated in the rate limit management information 24c with the client identification information where the current date and time is more than a specific time after the update date and time to the default rate limit (S162).
[0097] When the process of S162 is completed, the rate limit management unit 25d deletes the update date and time associated with the client identification information for which the current rate limit has been updated in S162 in the rate limit management information 24c (S163), and executes the process of S161.
[0098] As described above, when the service providing system 20 receives an API request accompanied by the identification information of a specific client, the service providing system 20 updates the current rate limit associated with the identification information of the specific client in accordance with the overall load of all microservices operating as a result of the received API request (S104 to S106 and S109 to S111), thereby being able to operate in accordance with the load of the microservices operating as a result of the API request.
[0099] When the service providing system 20 receives an API request with the identification information of a specific client, if the overall load of all microservices operating due to the received API request is equal to or less than the first threshold (YES in S104), it increases the current rate limit associated with the identification information of the specific client (S106), thereby improving convenience when there is room for the load on the microservices.
[0100] When the service providing system 20 receives an API request with the identification information of a specific client, if the overall load of all microservices operating due to the received API request is equal to or greater than the second threshold (YES in S109), the service providing system 20 lowers the current rate limit associated with the identification information of the specific client (S111), thereby reducing the possibility that the load on the microservices will become too large. Therefore, the service providing system 20 can also reduce the possibility that the load on the microservices will become too large and the service providing system 20 itself will become temporarily unavailable.
[0101] When the service providing system 20 receives an API request accompanied by the identification information of a specific client, and updates the current rate limit associated with the identification information of the specific client (S106 or S111), the service providing system 20 transmits an API response indicating that the current rate limit associated with the identification information of the specific client has been updated to the sender of the API request (S108 or S113, and S115), thereby improving convenience for the client. That is, as described above, the client can reflect the increase or decrease in the rate limit in some operation.
[0102] Furthermore, the service providing system 20 includes the updated current rate limit associated with the identification information of a specific client in the API response (S108 or S113), thereby further improving convenience for the client. That is, as described above, the client can reflect the increased or decreased rate limit in some operation.
[0103] When the service providing system 20 receives an API request with the identification information of a specific client, and updates the current rate limit associated with the identification information of the specific client (S106 or S111), the service providing system 20 includes information on the update of the current rate limit associated with the identification information of the specific client in the web page associated with the identification information of the specific client (S107 or S112), thereby improving the convenience of users who can view this web page.
[0104] Furthermore, the service providing system 20 includes the updated current rate limit associated with the identification information of the specific client in the web page associated with the identification information of the specific client (S107 or S112), thereby further improving the convenience for users who can view this web page.
[0105] If a specific time or more has passed since the latest update date and time of the current rate limit associated with the identification information of a specific client (YES in S161), the service providing system 20 updates the current rate limit associated with the identification information of the specific client to the default rate limit (S162), thereby reducing the possibility that the current rate limit will differ from the default rate limit for a long period of time. [Explanation of symbols]
[0106] 20 Service provision system (computer, information processing device) 24a Service Delivery Program 25a Microservices 35a Client
Claims
1. When a specific request is received as a specific API request to which specific identification information is assigned as identification information of a specific client, if the number of times the API request to which the specific identification information is assigned does not exceed a specific rate limit as a rate limit associated with the specific identification information, a connection is made to a microservice in response to the specific request; A service providing system characterized in that, when the specific request is received, the specific rate limit is updated according to the overall load of all of the microservices that operate due to the specific request.
2. 2. The service providing system according to claim 1, wherein when the specific request is received, if the load is equal to or less than a specific threshold, the specific rate limit is increased.
3. 2. The service providing system according to claim 1, wherein when the specific request is received, if the load is equal to or greater than a specific threshold, the specific rate limit is reduced.
4. 2. The service providing system according to claim 1, wherein the specific rate limit is updated to a default value if the current date and time is a specific time or more since the most recent update date and time of the specific rate limit.
5. The service providing system according to claim 1, characterized in that when the specific request is received and the specific rate limit is updated, an API response indicating that the specific rate limit has been updated is sent to the sender of the specific request.
6. The service providing system according to claim 5 , wherein the updated rate limit associated with the specific identification information is included in the API response.
7. The service providing system according to claim 1, characterized in that when the specific request is received and the specific rate limit is updated, the fact that the specific rate limit has been updated is included in a web page associated with the specific identification information.
8. The service providing system according to claim 7 , wherein the updated rate limit associated with the specific identification information is included in the web page.
9. When a specific request is received as a specific API request to which specific identification information is assigned as identification information of a specific client, if the number of times the API request to which the specific identification information is assigned does not exceed a specific rate limit as a rate limit associated with the specific identification information, a connection is made to a microservice in response to the specific request; When the specific request is received, the information processing device updates the specific rate limit according to the overall load of all of the microservices that operate due to the specific request.
10. A service providing program executed by a computer, When the computer receives a specific request as a specific API request to which specific identification information as identification information of a specific client is assigned, if the number of times the computer has received the API request to which the specific identification information is assigned does not exceed a specific rate limit as a rate limit associated with the specific identification information, causing the computer to connect to a microservice in response to the specific request; A service providing program characterized in that, when the computer receives the specific request, the computer updates the specific rate limit in accordance with the overall load of all of the microservices that operate due to the specific request.
Citation Information
Patent Citations
Dynamic power user identification and isolation for managing SLA guarantees
JP2024504201A