Cloud function calling method, first platform, storage medium and computer program product

Abstract

The application discloses a cloud function calling method, a first platform, a storage medium and a computer program product. The method comprises the following steps: receiving one or more requests, wherein the one or more requests are used for calling one or more cloud functions associated with an application program; analyzing the one or more cloud functions to obtain a first result, wherein the first result represents whether the one or more cloud functions have predictability; and based on the first result, configuring a first strategy for the one or more cloud functions, wherein the first strategy comprises a first sub-strategy of a space dimension and a second sub-strategy of a time dimension, the first sub-strategy represents the number of containers that need to be preheated, and the second sub-strategy represents the survival time length of the containers, and the containers can provide a running environment for the one or more cloud functions. The technical scheme provided by the application can reduce the cold start delay of the cloud function on the basis of reducing the resource occupation of the platform.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a cloud function call method, a first platform, a storage medium, and a computer program product. Background Technology

[0002] Serverless computing, as a new cloud computing model, effectively reduces the maintenance costs of underlying resources by introducing Function as a Service (FaaS), allowing personnel to focus on the logic of cloud functions. When using a serverless platform, if a cloud function is called for the first time or after a long period of inactivity, a new container (also called a container instance) needs to be started to run the function's code. The time consumed in this process is called cold start latency. Cold start latency leads to longer response times, which in turn affects user experience.

[0003] In related technologies, serverless platforms can reduce cold start latency and improve user experience by pre-starting a large number of containers. However, keeping containers in a constantly running state (also known as a hot state) consumes a lot of resources, increasing the cost of serverless platforms.

[0004] Therefore, there is currently no solution for reducing cold start latency while minimizing the resource consumption of a serverless platform. Summary of the Invention

[0005] To address the related technical issues, embodiments of this application provide a cloud function call method, a first platform, a storage medium, and a computer program product.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a cloud function calling method, applied to a first platform, including:

[0008] Receive one or more requests, which are used to invoke a function or cloud function associated with the application;

[0009] The one or more cloud functions are analyzed to obtain a first result, which characterizes whether the one or more cloud functions are predictable;

[0010] Based on the first result, a first strategy is configured for the one or more cloud functions. The first strategy includes a first sub-strategy in the spatial dimension and a second sub-strategy in the temporal dimension. The first sub-strategy represents the number of containers that need to be preheated, and the second sub-strategy represents the lifespan of the containers. The containers are able to provide a runtime environment for the one or more cloud functions.

[0011] This application also provides a first platform, including: a processor and a memory for storing computer programs capable of running on the processor.

[0012] When the processor runs the computer program, it executes the steps of any of the cloud function call methods described above.

[0013] This application embodiment also provides a storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the cloud function call method described above.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the cloud function call methods described above.

[0015] The cloud function invocation method, first platform, storage medium, and computer program product provided in this application embodiment include: The first platform receives one or more requests, which are used to invoke one or more cloud functions associated with an application; the one or more cloud functions are analyzed to obtain a first result, which characterizes whether the one or more cloud functions are predictable; based on the first result, a first strategy is configured for the one or more cloud functions, the first strategy including a first sub-strategy in a spatial dimension and a second sub-strategy in a temporal dimension, the first sub-strategy characterizing the number of containers requiring preheating, and the second sub-strategy characterizing the lifespan of the containers, wherein the containers can provide a runtime environment for the one or more cloud functions. The technical solution provided in this application embodiment analyzes cloud functions by focusing on their own characteristics, so as to configure scheduling strategies for containers for cloud functions from both temporal and spatial dimensions, thereby flexibly adjusting the number of containers requiring preheating and their lifespan. In this way, the cold start latency of cloud functions can be reduced while reducing platform resource consumption. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a cloud function calling method according to an embodiment of this application;

[0017] Figure 2 This is a schematic diagram of the optimized process for the first cold start in the application examples of this application;

[0018] Figure 3This is a schematic diagram of the optimized process for the second type of cold start in the application examples of this application;

[0019] Figure 4 This is a schematic diagram of the structure of a cloud function calling device according to an embodiment of this application;

[0020] Figure 5 This is a schematic diagram of the structure of the first platform in the embodiment of this application. Detailed Implementation

[0021] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0022] One approach in related technologies is to use a default container stem cell strategy, which involves preheating a fixed number of containers upon receiving a request and setting a fixed container lifespan (e.g., ten minutes). If a container's lifespan exceeds the fixed time and it is not called again, it is destroyed, thus reducing platform overhead. However, this approach cannot be adapted to different applications, and for applications with regular request patterns (e.g., a request frequency of once every eleven minutes), it may lead to a large number of cold starts.

[0023] Another approach is to use a dynamic strategy to predict application call patterns. This involves using historical application call data as input to the model, allowing it to learn these patterns and output the predicted number of containers to be warmed up. Since there are already started containers when a request is received, cold start latency can be reduced. However, this approach suffers from slow model convergence and a tendency for state space explosion. Furthermore, because the model cannot effectively learn from applications with irregular patterns, it leads to numerous cold starts. Additionally, most models only learn about the application itself, resulting in overly large task units involved in scheduling and wasted memory resources.

[0024] Based on this, in various embodiments of this application, the granularity of cloud function scheduling is reduced from the application level to the cloud function level. By analyzing the predictability of cloud functions, different scheduling strategies can be configured from both temporal and spatial dimensions based on the characteristics of the cloud functions themselves, so as to flexibly adjust the number of containers requiring preheating and their lifespan. In this way, the cold start latency of cloud functions can be reduced while minimizing platform costs.

[0025] This application provides a cloud function calling method, applied to a first platform, such as... Figure 1 As shown, the method includes:

[0026] Step 101: Receive one or more requests, the one or more requests being used to invoke a function associated with the application or a cloud function;

[0027] Step 102: Analyze the one or more cloud functions to obtain a first result, wherein the first result characterizes whether the one or more cloud functions are predictable;

[0028] Step 103: Based on the first result, configure a first strategy for the one or more cloud functions. The first strategy includes a first sub-strategy in the spatial dimension and a second sub-strategy in the temporal dimension. The first sub-strategy represents the number of containers that need to be preheated, and the second sub-strategy represents the lifespan of the containers. The containers can provide a runtime environment for the one or more cloud functions.

[0029] In practical applications, the first platform can be called a serverless platform or an OpenWhisk platform (at least in a serverless environment). It should have at least monitoring functions, be able to obtain the request and call status of cloud functions, analyze the regularity of cloud functions, perform container scheduling, and monitor the status of containers in the platform. This application embodiment does not limit the name of the first platform, as long as its functions are implemented.

[0030] In practical applications, in step 102, since different cloud functions may exhibit significant differences in their regularity, the first platform can sequentially and regularly divide each of the one or more cloud functions to obtain the first result; wherein, different cloud functions may correspond to different types.

[0031] Specifically, in some optional embodiments, the analysis of the one or more cloud functions to obtain a first result includes:

[0032] Obtain a first list, which represents the historical call history of the one or more cloud functions;

[0033] Based on the first list, a second result is obtained, which characterizes the fluctuation of the one or more cloud function calls and includes one or more first values ​​corresponding to the one or more cloud functions;

[0034] If the first value corresponding to the first cloud function in the one or more cloud functions is greater than the first threshold, it is determined that the first cloud function is not predictable.

[0035] In practical applications, the first list can be understood as a historical call list of the one or more cloud functions (which can be represented as...). The first list may contain the number of historical requests for each of the one or more cloud functions.

[0036] In practical applications, for the first cloud function f, the first platform can determine the number N of requests associated with the first cloud function f in the one or more requests, and determine the first sub-list corresponding to the first cloud function from the first list; wherein, the one or more requests can be understood as requests received at time tn, and the first sub-list can contain the historical number of requests for the first cloud function.

[0037] Next, the first platform can add the number N of requests associated with the first cloud function f to the first sublist to obtain an updated first sublist. Based on the updated first sublist, the first cloud function is analyzed to obtain a first value corresponding to the first cloud function. This first value can be called the coefficient of variation (CV), which at least reflects the fluctuation of the updated first sublist. In this embodiment, the name of the first value is not limited, as long as its function is implemented. The first value corresponding to the first cloud function can be calculated using the following formula:

[0038] (1)

[0039] in, This is represented as the first value corresponding to the first cloud function. This is represented as the average number of historical requests for the first cloud function. This is represented as the standard deviation of the historical request count for the first cloud function.

[0040] In practical applications, if the first value corresponding to the first cloud function is greater than the first threshold (which can be represented as k), the first platform can determine that the first cloud function is unpredictable, meaning that the first cloud function has poor regularity. In this case, the first cloud function can also be called an unpredictable cloud function; the value of the first threshold may need to be adjusted, and the initial value can be set to 5.

[0041] In practical applications, when the first value corresponding to the first cloud function is less than or equal to the first threshold, the first platform can analyze the first cloud function by combining the fluctuation of the first value corresponding to the first cloud function.

[0042] Based on this, in some optional embodiments, the method may further include:

[0043] If the first value corresponding to the first cloud function is less than or equal to the first threshold, a second list is obtained, and the second list contains the historical values ​​corresponding to the first cloud function.

[0044] Based on the second list and the second result, a third result is obtained, wherein the third result includes one or more differences between the first value corresponding to the first cloud function and the historical value;

[0045] If the first difference among the one or more differences is greater than the second threshold, it is determined that the first cloud function is not predictable;

[0046] If one or more of the differences are less than or equal to the second threshold, the first cloud function is determined to be predictable.

[0047] In practical applications, the second list can be understood as the historical first value list of the first cloud function (also known as the historical CV list, which can be represented as...). The second list may contain historical values ​​of a preset number of the first cloud functions (which can be set as needed, for example, to 5).

[0048] In practical applications, the first platform can sequentially subtract the first value corresponding to the first cloud function from each historical value in the second list (which can also be understood as traversing the second list) to obtain one or more differences (which can be represented as...). , (This is represented as the length of the second list).

[0049] In practical applications, if one of the one or more differences is greater than the second threshold (which can be represented as d), the first platform can consider the first cloud function to be in a fluctuating state. In this case, the first cloud function is determined to be unpredictable. The value of the second threshold may need to be adjusted, and the initial value may be set to 1. This application embodiment does not limit this.

[0050] In practical applications, when one or more of the differences are less than or equal to the second threshold, the first platform can determine that the first cloud function is predictable, such as a timer-type cloud function; that is, the first cloud function has strong regularity, and in this case, the first cloud function can also be called a predictable cloud function.

[0051] It should be noted that after completing the analysis of the first cloud function, the first platform can update the first value of the first cloud function to the second list so as to perform cloud function analysis for the requests received at the next time point (which can also be understood as the next iteration); wherein, if the historical values ​​in the second list reach the upper limit, the earliest historical value in the second list is removed.

[0052] In practical applications, after obtaining the first result, the first platform can configure dynamic strategies for predictable cloud functions to maximize the benefits for the first platform.

[0053] Specifically, in some optional embodiments, configuring a first strategy for the one or more cloud functions based on the first result includes:

[0054] If the first result indicates that the one or more cloud functions are predictable, then state information is obtained, which indicates the survival status of the container.

[0055] Based on the state information and the first model, the first sub-strategy is configured, and the first model is used to predict the number of preheated containers.

[0056] Based on the second model, the second sub-strategy is configured, and the second model is used to predict the survival time of containers.

[0057] In practical applications, the first model can be understood as a model trained on a deep reinforcement learning algorithm (such as the actor-critic algorithm). The second model can be understood as a model trained on a long short-term memory network (LSTM). The second model can contain four hidden layers, each containing 32 neurons and a ReLU activation function. The loss function of the second model can be set as mean squared error (MSE).

[0058] It should be noted that when the prediction accuracy of the first model and the second model decreases, the first platform can retrain the first model and the second model. Furthermore, after training, the first platform can also simulate actual requests, allowing the first model and the second model to continuously learn during this process.

[0059] In addition, the status information may include the number of currently alive containers, the lifespan of each container, the stage each container is in, and a list of cloud functions. The list of cloud functions is used to retain the number of cold starts that occur for each cloud function and the request load (which can be understood as the number of requests) corresponding to each time point. The list of cloud functions will change as time points change.

[0060] In practical applications, during the process of configuring the first sub-policy (also known as the deep reinforcement learning policy) for the first cloud function through the first model, since the state information and action space corresponding to the first cloud function are continuous, the first platform can set corresponding rewards for each iteration of the first model (which can also be understood as each learning), so that the first model can converge better, thereby achieving a balance between user experience and the cost of the first platform.

[0061] It should be noted that when the first model is implemented based on an actor neural network, the first platform will first define the behavior and reward function of the first model. Regarding behavior, as the number of containers increases or decreases, the behavior space of the first model will gradually expand with iteration. Therefore, the first platform can set a parameter M, the value of which increases according to the Fibonacci sequence. Simultaneously, the behavior space is set to... The behavior space is capped to prevent the first model from blindly expanding its exploration space (i.e., to prevent the behavior space from expanding indefinitely), thereby reducing the convergence time required for the first model. If the number of surviving containers reaches M, M will expand to the next value in the Fibonacci sequence, and the behavior space will expand accordingly. The reward function can be set to calculate the reward value for each iteration after each iteration (or after the window at each time point ends), based on the actual number of requests received, to continuously update the first model.

[0062] In practical applications, in each iteration, the first platform can use the current state information as input to the first model, enabling the first model to select an action from the exploration space based on a random policy to output the first sub-policy; wherein, the random policy can be represented as... That is, random strategy Selecting behavior based on state information The probability distribution.

[0063] In practical applications, the first platform can calculate the expected value of the reward corresponding to the first sub-strategy after this iteration.

[0064] For example, assuming the first model is a model implemented based on an actor neural network, for the current time point... The first platform can be in the first sub-strategy Select behavior based on state information s Let Q be the objective function, and calculate the reward value that can be obtained by the objective function Q; the expected value can be calculated using the following formula:

[0065] (2)

[0066] in, Represented as a value network or value function; This is represented as the reward function for this iteration; This represents the number of currently alive containers; This represents the success rate of the request. This is expressed as the failure rate for the request; Represented as a reward coefficient, .

[0067] It should be noted that the first platform can set a lower reward coefficient for the number of surviving containers (which can also be understood as setting a higher penalty coefficient for the number of surviving containers) to constrain the number of surviving containers, causing the first model to tend to maintain a smaller number of containers while ensuring the success rate of requests. If the number of surviving containers is not constrained, the first model will tend to maintain a higher number of containers to increase the success rate of requests. Although the above method can reduce the occurrence of cold starts, it will increase the cost of the first platform and generate a higher loss value.

[0068] Here, by removing the expected value function, we can obtain the following formula:

[0069] (3)

[0070] Next, to reduce errors, the first platform can estimate only the value network, resulting in the following formula:

[0071] (4)

[0072] Here, in order to estimate the value network at each iteration, the first platform can use one-step TD to update formula (4) to obtain the following formula:

[0073] (5)

[0074] in, This is expressed as an estimated value of the current state information. This is represented as a hyperparameter used to update the step size. This indicates the degree of importance attached to the reward in the next iteration. This represents the estimated value of the state information at the next point in time.

[0075] Next, based on formula (5), the first platform can obtain the temporal difference error at the current time point, so as to adjust the learning direction of the first model based on the temporal difference error:

[0076] (6)

[0077] in, This is represented as the timing difference error at the current time point.

[0078] In this embodiment of the application, by flexibly adjusting the reward coefficient of the reward function for the first model, the learning effect of the first model can be improved (which can also be understood as a smaller loss value). In this way, the convergence speed of the first model can be accelerated while avoiding the explosion of the state space.

[0079] In practical applications, after a container call is completed, the first platform typically keeps the container active for a period of time to prepare for new requests at the next point in time. This period is called the container lifespan or container lifespan window. However, the calling patterns of different cloud functions may vary significantly. When the request frequency is sparse, if the container lifespan is too long, it will occupy the memory space of the first platform for a long time, greatly reducing memory utilization. Therefore, the first platform can configure the second sub-strategy based on the second model.

[0080] In practical applications, to configure the second sub-strategy through the second model, the first platform can input the historical call intervals of the first cloud function into the second model, enabling the second model to learn the call patterns of the first cloud function and output the predicted call intervals of the first cloud function. To allow the second model to focus more on recent call patterns, the first platform can update the historical call intervals of the first cloud function based on received requests and remove some historical call intervals after a certain period. Then, by expanding the predicted call intervals of the first cloud function, the first platform can obtain the second sub-strategy; this expansion can be achieved using the following formula:

[0081] (7)

[0082] in, This is represented as the predicted call interval. Represented as the expansion factor, It is a constant greater than 1 to avoid situations where the container's lifespan is less than 1. This represents the lifespan of the container.

[0083] In practical applications, the first platform can further divide the container's survival time, as represented by the second sub-strategy, into two parts: a warm-up window and a liveness maintenance window. This division can be achieved using the following formula:

[0084] (8)

[0085] in, This is represented as the preheating window, i.e., the preheating time of the container; This refers to the active window, which is the duration for which the container remains active. It is represented as a window coefficient, and the value can be set as needed.

[0086] In practical applications, after obtaining the first result, the first platform can configure a fixed strategy (or default strategy) for cloud functions that are not predictable, so as to maximize the benefits of the first platform.

[0087] Specifically, in some optional embodiments, configuring a first strategy for the one or more cloud functions based on the first result includes:

[0088] If the first result characterizes the one or more cloud functions as unpredictable, the first sub-policy and the second sub-policy are configured in a fixed manner.

[0089] In practical applications, because unpredictable cloud functions lack clear patterns and the corresponding request numbers fluctuate, accurate prediction through models is impossible; the only option is to minimize the resulting errors. Therefore, the first platform can configure the first sub-strategy and the second sub-strategy in a fixed manner.

[0090] For example, the first platform can use a default container stem cell strategy as the first sub-strategy; wherein, the container stem cell strategy is used to indicate a fixed number (e.g., 10) of containers that need to be preheated. In this way, for each cloud function, the first platform can preheat a fixed number of containers.

[0091] For example, the first platform can use the default keep-alive strategy as the second sub-strategy; wherein, the keep-alive strategy is used to indicate the survival time of the container for a fixed period of time, such as 10 minutes. In this case, the container's warm-up window can be 0, while the keep-alive window can be 10 minutes.

[0092] In this embodiment, considering both time and space dimensions, the first platform can select a more suitable strategy for cloud functions with different characteristics. Specifically, it applies a dynamic strategy to predictable cloud functions and a fixed strategy to non-predictable cloud functions, maximizing the advantages of both strategies. This minimizes platform costs while reducing the frequency and latency of cold starts.

[0093] In practical applications, in addition to the first threshold and the second threshold, the first platform can also optimize the thresholds during the cloud function call at each time point to determine the optimal threshold combination for different cloud functions, thereby minimizing the cost of the cloud function call at the next time point.

[0094] Based on this, in some optional embodiments, the method may further include:

[0095] Determine a fourth result and a fifth result, wherein the fourth result characterizes the maintenance cost of the container and the fifth result characterizes the response cost of the one or more requests;

[0096] Based on the fourth and fifth results, a sixth result is obtained, which characterizes the calling cost of the one or more cloud functions;

[0097] Based on the sixth result, the first threshold and the second threshold are updated to obtain the updated first threshold and the second threshold. The first threshold and the second threshold are used to determine whether the one or more cloud functions are predictable.

[0098] In practical applications, the fourth result can be understood as the cost at the first platform level, and may include the overhead caused by maintaining containers for calling the one or more cloud functions (or the time cost of the containers). Additionally, the fifth result can be understood as the cost at the user level, and may include the response overhead for the one or more requests.

[0099] In practical applications, the first platform can calculate the fourth result and the fifth result based on the container's lifespan and the request response latency, respectively.

[0100] Specifically, in some optional embodiments, determining the fourth and fifth results includes:

[0101] Obtain a seventh result and an eighth result respectively. The seventh result includes the survival time of the container, and the eighth result includes one or more of the cold start latency, warm start latency, and warm-up latency associated with the one or more requests.

[0102] Based on the seventh result, the fourth result is obtained;

[0103] Based on the eighth result, the fifth result is obtained.

[0104] In practical applications, for the first cloud function, the first platform can determine the lifespan of the container associated with the first cloud function based on the second sub-strategy; based on the first sub-strategy and the second sub-strategy, determine one or more of the cold start latency, warm start latency, and preheating latency (which can also be understood as at least one or more of them) generated by the request associated with the first cloud function; wherein, the cold start latency can be understood as the sum of the latency of starting a container in the cold phase and the latency of running the first cloud function through the started container; the preheating latency can be understood as the latency of running the first cloud function through a container in the pre-warm phase; the warm start latency can be understood as the latency of directly calling a container in the warm phase.

[0105] It should be noted that for the first cloud function, the first call is considered a cold start, meaning the corresponding container is in a cold phase. When the corresponding container is in the warm-up phase, the call to the first cloud function is also considered a cold start. Since the container in the warm-up phase has already started, although there will still be a cold start latency, the latency caused by the container in the warm-up phase will be less than that caused by the container in the cold phase. After the warm-up phase ends, the corresponding container will be in the warm start phase (i.e., it will remain alive for a period of time), and the call to the first cloud function will be considered a warm start. Therefore, by pre-warming up some containers through the call requirements of one or more requests, the occurrence of cold starts can be effectively reduced.

[0106] In practical applications, based on the lifespan of the container associated with the first cloud function, the first platform can obtain the maintenance cost of the container associated with the first cloud function; wherein, the maintenance cost of the container associated with the first cloud function can be obtained through the following formula:

[0107] (9)

[0108] in, This represents the lifespan of the container associated with the first cloud function; This is represented as the first scaling factor, and its value can be set as needed. This represents the maintenance cost of the container associated with the first cloud function.

[0109] In practical applications, based on one or more of the cold start latency, warm start latency, and warm-up latency generated by the request associated with the first cloud function, the first platform can obtain the response cost of the request associated with the first cloud function; wherein, the response cost of the request associated with the first cloud function can be determined by the following formula:

[0110] (10)

[0111] in, This represents the hot start latency caused by the request associated with the first cloud function; This represents the cold start latency caused by the request associated with the first cloud function; This represents the warm-up delay caused by the request associated with the first cloud function; This is represented as the second scaling factor, and its value can be set as needed. This represents the response cost of the request associated with the first cloud function.

[0112] It should be noted that, without considering factors such as network fluctuations, the first platform can consider the response latency of requests associated with the first cloud function as cold start latency. The execution time of the first cloud function was not considered in the above process because, after data processing, the first platform no longer focuses on the specific function of each cloud function and therefore cannot know its specific execution time.

[0113] In practical applications, based on the maintenance cost of the container associated with the first cloud function and the response cost of the request, the first platform can determine the call cost (also known as the total cost) of the first cloud function; the call cost of the first cloud function can be obtained through the following formula:

[0114] (11)

[0115] In practical applications, based on the call cost of the first cloud function, the first platform can perform multi-objective optimization on the first threshold and the second threshold corresponding to the first cloud function to minimize the call cost of the first cloud function, thereby obtaining the optimal threshold combination for the first cloud function, i.e., the updated first threshold and the second threshold; wherein, multi-objective optimization can be performed using the following formula:

[0116] (12)

[0117] in, This is represented as the first threshold. This is represented as the second threshold. and This is represented as a weighting factor, and the value can be set as needed.

[0118] The cloud function invocation method provided in this application embodiment involves a first platform receiving one or more requests, which are used to invoke an application-associated cloud function. The platform analyzes the one or more cloud functions to obtain a first result, which characterizes whether the one or more cloud functions are predictable. Based on the first result, a first strategy is configured for the one or more cloud functions. The first strategy includes a first sub-strategy in a spatial dimension and a second sub-strategy in a temporal dimension. The first sub-strategy characterizes the number of containers requiring preheating, and the second sub-strategy characterizes the lifespan of the containers. The containers can provide a runtime environment for the one or more cloud functions. The technical solution provided in this application embodiment analyzes cloud functions by focusing on their own characteristics, enabling the configuration of container scheduling strategies for cloud functions from both temporal and spatial dimensions. This allows for flexible adjustment of the number of containers requiring preheating and their lifespan. In this way, the cold start latency of cloud functions can be reduced while minimizing platform resource consumption.

[0119] The following section provides a more detailed description of this application with reference to application examples.

[0120] To address the cold start problem in serverless computing, this application proposes a serverless cold start optimization scheme oriented towards cloud functions; specifically, as follows: Figure 2 As shown, for a new request, the Serverless platform (i.e., the first platform mentioned above) divides the cloud functions involved in the request into predictable categories. Then, in the spatial dimension, the actor-critic algorithm and the container stem cell strategy are applied to predictable and unpredictable functions respectively to determine the number of containers that need to be warmed up. In the temporal dimension, the LTSM and keep-alive strategies are applied to predictable and unpredictable functions respectively to determine the lifespan of the containers.

[0121] Here, a cold start process for a cloud function is described, such as... Figure 3 As shown, it includes the following steps:

[0122] Step 301: Iterate through each cloud function in the application;

[0123] This involves obtaining the request call status of cloud functions in each application within 1440 minutes each day, performing predictability analysis on each cloud function, and then executing step 302.

[0124] Step 302: Is it a predictable function (i.e., the first result mentioned above);

[0125] If the cloud function is a predictable function, then proceed to step 303; if the cloud function is an unpredictable function, then proceed to step 307.

[0126] Step 303: Based on the actor algorithm (i.e., the first model mentioned above), determine the number of preheating containers (i.e., the first sub-strategy mentioned above);

[0127] Step 304: Obtain the historical call interval list (i.e., the first list mentioned above);

[0128] Step 305: Use LSTM (i.e., the second model mentioned above) to make predictions and obtain the time window size (i.e., the second sub-policy mentioned above).

[0129] Step 306: Divide the time window into a preheating window and a maintain-activity window;

[0130] Then, proceed to step 309.

[0131] Step 307: Determine the number of preheating containers based on the container stem cell strategy;

[0132] Step 308: Determine the container's lifespan based on the keep-alive strategy;

[0133] Then, proceed to step 309.

[0134] Step 309: Preheat the container;

[0135] Here, container preheating is performed based on the determined predicted number of containers and container survival time.

[0136] Step 310: Obtain the number of requests corresponding to each cloud function at the current time point;

[0137] Step 311: Calculate the reward value and time-series difference error based on the number of requests obtained, and optimize the actor algorithm and LTSM;

[0138] Step 312: Update the container's state based on the number of requests received;

[0139] It should be noted that the execution order of steps 311 and 312 is not important.

[0140] Step 313: Obtain the historical CV list (i.e., the second list mentioned above);

[0141] Step 314: Calculate the CV at the current time point (i.e., the second result mentioned above);

[0142] Step 315: Determine whether CV is greater than the threshold k (i.e., the first threshold mentioned above);

[0143] If the CV is greater than the threshold k, the cloud function is considered to be an unpredictable function and step 317 is executed; if the CV is less than or equal to the threshold k, step 316 is executed.

[0144] Step 316: Traverse the historical CV list and determine whether the difference (i.e., the third result mentioned above) is greater than the threshold d (i.e., the second threshold mentioned above).

[0145] If the difference is greater than the threshold d, the cloud function is considered to be an unpredictable function and step 317 is executed; if the difference is less than or equal to the threshold d, the cloud function is considered to be a predictable function and step 317 is executed.

[0146] Step 317: Update the cloud function predictability and historical CV list;

[0147] Here, based on the characteristics of cloud functions, the predictability of cloud functions and the historical CV list are updated, and the historical call list is also updated.

[0148] Step 318: Has the final time point been exceeded?

[0149] If the final time point (i.e., 1440 minutes) is exceeded, it means that the current iteration round has ended; otherwise, requests will continue to be received at the next time point, and step 301 will be repeated.

[0150] In this application example, the task granularity of the optimization target is reduced from the application level to the cloud function level. The predictability of each cloud function is analyzed to allow for strategy partitioning based on predictability. Then, container scheduling is performed from both spatial and temporal dimensions. Cold start latency is reduced by pre-warming or creating containers, and the occurrence of cold starts is reduced by adjusting the container survival window size, thereby achieving more accurate resource scheduling while saving memory resources on the serverless platform.

[0151] In addition, the costs of cold start and serverless platform are quantified separately, focusing the cold start problem on serverless platform costs and user costs. Multi-objective optimization is performed on the predictability partitioning threshold so as to find the optimal threshold for cloud function predictability partitioning while maximizing the benefits of both.

[0152] To implement the cloud function invocation method of this application embodiment, this application embodiment also provides a cloud function invocation device, which is set on a first platform, such as... Figure 4 As shown, the device includes:

[0153] Receiving unit 401 is configured to receive one or more requests, the one or more requests being used to invoke an application or cloud function;

[0154] Analysis unit 402 is used to analyze the one or more cloud functions to obtain a first result, wherein the first result characterizes whether the one or more cloud functions are predictable;

[0155] Configuration unit 403 is configured to configure a first strategy for the one or more cloud functions based on the first result. The first strategy includes a first sub-strategy in the spatial dimension and a second sub-strategy in the temporal dimension. The first sub-strategy represents the number of containers that need to be preheated, and the second sub-strategy represents the lifespan of the containers. The containers are capable of providing a runtime environment for the one or more cloud functions.

[0156] In some optional embodiments, the receiving unit 401 is configured to obtain a first list, the first list representing the historical call information of the one or more cloud functions;

[0157] The analysis unit 402 is used to obtain a second result based on the first list. The second result characterizes the fluctuation of the one or more cloud function calls. The second result includes one or more first values ​​corresponding to the one or more cloud functions. If the first value corresponding to the first cloud function in the one or more cloud functions is greater than a first threshold, it is determined that the first cloud function is not predictable.

[0158] In some optional embodiments, the receiving unit 401 is further configured to obtain a second list when the first value corresponding to the first cloud function is less than or equal to the first threshold, the second list containing historical values ​​corresponding to the first cloud function;

[0159] The analysis unit 402 is further configured to obtain a third result based on the second list and the second result, the third result including one or more differences between the first value corresponding to the first cloud function and the historical value; if the first difference is greater than a second threshold in the one or more differences, the first cloud function is determined to be unpredictable; if the one or more differences are all less than or equal to the second threshold, the first cloud function is determined to be predictable.

[0160] In some optional embodiments, the analysis unit 402 is further configured to determine a fourth result and a fifth result, the fourth result representing the maintenance cost of the container and the fifth result representing the response cost of the one or more requests; based on the fourth result and the fifth result, obtain a sixth result, the sixth result representing the calling cost of the one or more cloud functions; based on the sixth result, update a first threshold and a second threshold to obtain updated first thresholds and second thresholds, the first threshold and the second threshold being used to determine whether the one or more cloud functions are predictable.

[0161] In some optional embodiments, the receiving unit 401 is configured to acquire a seventh result and an eighth result, respectively, wherein the seventh result includes the survival time of the container, and the eighth result includes one or more of the cold start delay, hot start delay, and preheating delay associated with the one or more requests;

[0162] The analysis unit 402 is used to obtain the fourth result based on the seventh result; and to obtain the fifth result based on the eighth result.

[0163] In some optional embodiments, the receiving unit 401 is configured to acquire state information, which characterizes the survival status of the container, if the first result indicates that the container is predictable in the one or more cloud functions.

[0164] The configuration unit 403 is used to configure the first sub-strategy based on the state information and the first model, wherein the first model is used to predict the number of preheated containers; and to configure the second sub-strategy based on the second model, wherein the second model is used to predict the survival time of the containers.

[0165] In some optional embodiments, the configuration unit 403 is configured to configure the first sub-policy and the second sub-policy in a fixed manner when the first result characterizes the one or more cloud functions as unpredictable.

[0166] In practical applications, the receiving unit 401 can be implemented by the communication interface in the cloud function call device, and the analysis unit 402 and the configuration unit 403 can be implemented by the processor in the cloud function call device.

[0167] It should be noted that the cloud function calling device provided in the above embodiments is only illustrated by the division of the above-described program units when performing cloud function calls. In actual applications, the above processing can be assigned to different program units as needed, that is, the internal structure of the device can be divided into different program units to complete all or part of the processing described above. In addition, the cloud function calling device and the cloud function calling method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0168] Based on the hardware implementation of the above program modules, and in order to implement the cloud function call method of the embodiments of this application, the embodiments of this application also provide a first platform, such as... Figure 5 As shown, the first platform 500 includes:

[0169] The communication interface 501 enables interaction with other devices;

[0170] The processor 502 is connected to the communication interface 501 to enable interaction with other devices and to execute the methods provided by one or more of the above-mentioned technical solutions when running a computer program;

[0171] The computer program is stored in memory 503.

[0172] Specifically, the communication interface 501 is used to receive one or more requests, the one or more requests being used to invoke an or cloud function associated with the application;

[0173] The processor 502 is configured to analyze the one or more cloud functions to obtain a first result, the first result representing whether the one or more cloud functions are predictable; based on the first result, configure a first strategy for the one or more cloud functions, the first strategy including a first sub-strategy in the spatial dimension and a second sub-strategy in the temporal dimension, the first sub-strategy representing the number of containers that need to be preheated, the second sub-strategy representing the survival time of the containers, the containers being able to provide a running environment for the one or more cloud functions.

[0174] In some optional embodiments, the communication interface 501 is used to obtain a first list, the first list representing the historical call information of the one or more cloud functions;

[0175] The processor 502 is configured to obtain a second result based on the first list, the second result representing the fluctuation of the one or more cloud function calls, the second result including one or more first values ​​corresponding to the one or more cloud functions; if the first value corresponding to the first cloud function in the one or more cloud functions is greater than a first threshold, it is determined that the first cloud function is not predictable.

[0176] In some optional embodiments, the communication interface 501 is further configured to obtain a second list when the first value corresponding to the first cloud function is less than or equal to the first threshold, the second list containing historical values ​​corresponding to the first cloud function;

[0177] The processor 502 is further configured to obtain a third result based on the second list and the second result, the third result including one or more differences between the first value corresponding to the first cloud function and the historical value; if the first difference in the one or more differences is greater than a second threshold, the processor determines that the first cloud function is not predictable; if the one or more differences are all less than or equal to the second threshold, the processor determines that the first cloud function is predictable.

[0178] In some optional embodiments, the processor 502 is further configured to determine a fourth result and a fifth result, the fourth result representing the maintenance cost of the container and the fifth result representing the response cost of the one or more requests; based on the fourth result and the fifth result, obtain a sixth result, the sixth result representing the invocation cost of the one or more cloud functions; based on the sixth result, update a first threshold and a second threshold to obtain updated first thresholds and second thresholds, the first threshold and the second threshold being used to determine whether the one or more cloud functions are predictable.

[0179] In some optional embodiments, the communication interface 501 is used to obtain a seventh result and an eighth result, respectively, wherein the seventh result includes the survival time of the container, and the eighth result includes one or more of the cold start latency, warm start latency, and warm-up latency associated with the one or more requests;

[0180] The processor 502 is configured to obtain the fourth result based on the seventh result; and to obtain the fifth result based on the eighth result.

[0181] In some optional embodiments, the communication interface 501 is used to obtain state information, which represents the survival status of the container, when the first result characterizes the predictability of the one or more cloud functions.

[0182] The processor 502 is configured to configure a first sub-strategy based on the state information and a first model, wherein the first model is used to predict the number of preheated containers; and to configure a second sub-strategy based on a second model, wherein the second model is used to predict the survival time of containers.

[0183] In some alternative embodiments, the processor 502 is configured to configure the first sub-policy and the second sub-policy in a fixed manner when the first result characterizes the one or more cloud functions as unpredictable.

[0184] It should be noted that the specific processing procedures of the communication interface 501 and the processor 502 can be understood with reference to the above method.

[0185] Of course, in practical applications, the various components in the first platform 500 are coupled together through the bus system 504. It can be understood that the bus system 504 is used to implement communication between these components. In addition to the data bus, the bus system 504 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 5 The general designated all buses as Bus System 504.

[0186] The memory 503 in this embodiment is used to store various types of data to support the operation of the first platform 500. Examples of such data include any computer program used to operate on the first platform 500.

[0187] The methods disclosed in the embodiments of this application can be applied to the processor 502, or implemented by the processor 502. The processor 502 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 502 or by instructions in the form of software. The processor 502 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 502 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the memory 503. The processor 502 reads the information in the memory 503 and combines its hardware to complete the steps of the aforementioned method.

[0188] In an exemplary embodiment, the first platform 500 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0189] It is understood that the memory (memory 503) in this embodiment of the application can be volatile memory or non-volatile memory, or both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); the magnetic surface memory can be disk storage or magnetic tape storage. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0190] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 503 storing a computer program, which can be executed by the processor 502 of the first platform 500 to complete the steps of the aforementioned cloud function call method. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0191] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by the processor 502 of a first platform 500 to complete the steps of the aforementioned cloud function call method.

[0192] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0193] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0194] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A cloud function calling method, characterized in that, Applied to a first platform, the method includes: Receive one or more requests, which are used to invoke a function or cloud function associated with the application; The one or more cloud functions are analyzed to obtain a first result, which characterizes whether the one or more cloud functions are predictable; wherein, if they are predictable, the one or more cloud functions have strong regularity, and if they are not predictable, the one or more cloud functions have weak regularity. Based on the first result, a first strategy is configured for the one or more cloud functions. The first strategy includes a first sub-strategy in the spatial dimension and a second sub-strategy in the temporal dimension. The first sub-strategy represents the number of containers that need to be warmed up, and the second sub-strategy represents the lifespan of the containers. The lifespan of a container is the duration during which the container is in an active state. The containers are able to provide a runtime environment for the one or more cloud functions.

2. The method according to claim 1, characterized in that, The analysis of the one or more cloud functions to obtain a first result includes: Obtain a first list, which represents the historical call history of the one or more cloud functions; Based on the first list, a second result is obtained, which characterizes the fluctuation of the one or more cloud function calls and includes one or more first values ​​corresponding to the one or more cloud functions; If the first value corresponding to the first cloud function in the one or more cloud functions is greater than the first threshold, it is determined that the first cloud function is not predictable.

3. The method according to claim 2, characterized in that, The method further includes: If the first value corresponding to the first cloud function is less than or equal to the first threshold, a second list is obtained, and the second list contains the historical values ​​corresponding to the first cloud function. Based on the second list and the second result, a third result is obtained, wherein the third result includes one or more differences between the first value corresponding to the first cloud function and the historical value; If the first difference among the one or more differences is greater than the second threshold, it is determined that the first cloud function is not predictable; If one or more of the differences are less than or equal to the second threshold, the first cloud function is determined to be predictable.

4. The method according to claim 1, characterized in that, The method further includes: Determine a fourth result and a fifth result, wherein the fourth result characterizes the maintenance cost of the container and the fifth result characterizes the response cost of the one or more requests; Based on the fourth and fifth results, a sixth result is obtained, which characterizes the calling cost of the one or more cloud functions; Based on the sixth result, the first threshold and the second threshold are updated to obtain the updated first threshold and the second threshold. The first threshold and the second threshold are used to determine whether the one or more cloud functions are predictable.

5. The method according to claim 4, characterized in that, The determination of the fourth and fifth results includes: Obtain a seventh result and an eighth result respectively. The seventh result includes the survival time of the container, and the eighth result includes one or more of the cold start latency, warm start latency, and warm-up latency associated with the one or more requests. Based on the seventh result, the fourth result is obtained; Based on the eighth result, the fifth result is obtained.

6. The method according to any one of claims 1 to 5, characterized in that, The step of configuring a first strategy for the one or more cloud functions based on the first result includes: If the first result indicates that the one or more cloud functions are predictable, then state information is obtained, which indicates the survival status of the container. Based on the state information and the first model, the first sub-strategy is configured, and the first model is used to predict the number of preheated containers. Based on the second model, the second sub-strategy is configured, and the second model is used to predict the survival time of containers.

7. The method according to any one of claims 1 to 5, characterized in that, The step of configuring a first strategy for the one or more cloud functions based on the first result includes: If the first result characterizes the one or more cloud functions as unpredictable, the first sub-policy and the second sub-policy are configured in a fixed manner.

8. A first platform, characterized in that, include: The processor and the memory used to store computer programs that can run on the processor. When the processor is used to run the computer program, it performs the steps of the method according to any one of claims 1 to 7.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images