KR102576226B1 - Caching system that can predict and resolve server overload through artificial intelligence algorithms - Google Patents

Abstract

The present invention generates and learns a model for predicting server overload through an artificial intelligence algorithm based on log data accumulated as specific data is cached in cache memory by monitoring server load, and server overload through the learned model. It relates to a caching system capable of predicting and resolving server overload through an artificial intelligence algorithm that predicts and resolves A caching system capable of predicting and resolving server overload through an artificial intelligence algorithm according to the present invention is a web server that receives a request message and query from a user through a web page, and executes an application program for the request message to receive information about the request message. A WAS server that performs calculations and returns calculation results to the web server, and a database server that receives the query from the WAS server, searches data that can be a response to the query, and returns the search result to the WAS server. , a monitoring unit for caching the request message, the operation result of the application program for the request message, the query and the search result of the database for the query in a cache memory unit, and a server load prediction model for predicting the load in the server at a future point in time. It includes a server load prediction modeling and prediction service unit that generates.

Description

Caching system capable of predicting and resolving server overload through artificial intelligence algorithms

The present invention relates to a caching system capable of predicting and resolving server overload through an artificial intelligence algorithm, and more particularly, an artificial intelligence algorithm based on log data accumulated as specific data is cached in cache memory by monitoring server load. It relates to a caching system capable of predicting and resolving server overload through an artificial intelligence algorithm that generates and learns a model that predicts server overload through a learning model and predicts and resolves server overload through the learned model.

The recent increase in data, expansion of various contents, and increase in concurrent users due to the growth of IT services have caused many system problems ranging from slow service response speed to service interruption. In particular, problems with systems operated by governments or public institutions It is creating a serious social phenomenon that goes beyond the occurrence of user complaints and the loss of trust and leads to legal proceedings.

A conventional system is a WEB server that provides a web page composed of HTML to a user according to a user's request, a WAS (Web Application Server) server that processes an application service for a request message transmitted from the WEB server, and a response to a user's query. It consists of a database that stores data that can be

In such a conventional system, when the number of concurrent users using the system increases, the response time of the user is delayed due to insufficient network bandwidth in the web server. In addition, as the application program processing request volume surges, the application programs running inside the WAS server simultaneously request results from the database. In addition, in the database, the amount of data increases and the data is complicatedly twisted to process the information requested from the WAS server, and the database eventually fails to overcome the load and goes down or reaches an infinite standby state.

In order to solve the above-mentioned problems, existing equipment has been replaced with high-performance equipment, or various and more complex architectures such as expansion and distributed processing have been constructed. However, in these existing solutions, there was a realistic problem in that not only the enormous equipment purchase cost, but also the acquisition of experts to operate it and the continuous maintenance cost/time were doubled. Specifically, in the web server, a web accelerator is introduced to solve the user's response delay, not a fundamental improvement, and uses a method that is not very helpful in relieving the boredom of waiting time in the form of pulling out a number ticket at a bank counter. Or, by creating a redundant structure through replacement or expansion of WEB server, WAS server, and database with high-performance equipment, it adopts a method of configuring a single processing unit to be processed by multiple units, resulting in enormous server costs and a complex system due to multiplexing The reality is that software license costs and complex infrastructure maintenance/management costs are complexly increasing.

Therefore, in order to solve the problems of the conventional system, it is urgently necessary to introduce new technology that considers the cost aspect, maintenance/management aspect, and future expandability aspect beyond the limits of physical equipment expansion. Improving the system response performance of the plug-in method in the call There is a way to improve the throughput and response speed of the existing system per second and maximize stability through caching of operation results of applications with high usage and database query results through an intelligent caching system. has been initiated

The method disclosed in Korean Patent Registration No. 10-2027823 caches a request message requested from a web page with high usage and the operation result for the request message in a cache memory, or a query that is used repeatedly and a search for the query The result is cached in the cache memory, and when the data cached in the cache memory is requested or a query is received, the request message and query stored in the cache memory are returned without performing operations on the request message and query in the WAS server and database, respectively. It improves the processing speed and response speed of the entire system by returning the data to the user.

That is, the method disclosed in Korean Patent Registration No. 10-2027823 is limited to improving the current throughput and response speed per second through past data.

On the other hand, the amount of request messages or queries delivered to the caching system is time-series data that shows a certain pattern over time. Therefore, by analyzing such time-series data, it is important to predict the load in the server at some point in the future. possible.

Therefore, it is possible to predict overload in the server by learning artificial intelligence modeling through artificial intelligence algorithms and analyzing time series data through learned artificial intelligence modeling.

Republic of Korea Patent Publication No. 10-2016-0126655 (published on November 02, 2016) Republic of Korea Patent Registration No. 10-2008-0075304 (published on August 18, 2008)

An object of the present invention for solving the above problems is to generate and learn a model for predicting server overload through an artificial intelligence algorithm based on log data, and artificial intelligence capable of predicting and resolving server overload through the learned model. To provide a caching system capable of predicting and resolving server overload through an intelligent algorithm.

In order to achieve the above object, a caching system capable of predicting and resolving server overload through an artificial intelligence algorithm according to an embodiment of the present invention includes a cache server and a customer server group, and the customer server group includes a user's A web server that provides a web page composed of HTML to a user according to a request and receives a request message and a query from the user through the web page, and receives the request message and the query from the web server, A WAS (Web Application Server) server that executes an application program for the request message, performs an operation on the request message, and returns a calculation result to the web server, and receives the query from the WAS server and responds to the query and a database server that searches data that can be, and returns a search result to the WAS server, wherein the cache server includes the request message, the operation result of the application program for the request message, the query and A monitoring unit for caching the search result of the database for the query in the cache memory unit and the request message cached by the monitoring unit in the cache memory unit, the operation result of the application program for the request message, the query and the query A server load prediction modeling and prediction service unit generating a server load prediction model for predicting a server load at a future time based on a query result of a database, wherein the monitoring unit includes a server generated by the server load prediction modeling and prediction service unit. Through the load prediction model, only the request message requested from the web page predicted to have high usage in the future and the operation result for the request message requested from the predicted web page are cached in the cache memory unit, and the server load prediction model and a query predicted to be repeatedly used by a user at a future point in time through a server load prediction model generated by the prediction service unit and only a search result for the predicted query are cached in the cache memory unit.

The WAS server receives a request message for a web page predicted to have a high usage in the future, and when the future approaches the present time, the request cached in the cache memory unit without performing an operation on the request message. When a query predicted to be used repeatedly in the future is returned to the user, and the future is approaching the present time, the query is not transmitted to the database server, and the query cached in the cache memory unit is not transmitted to the database server. Returns query results to the user, improving the processing speed and response speed of the entire caching system.

The monitoring unit includes a WAS calculation result caching module and a database search result caching module, and the WAS calculation result caching module stores a request message requested from a web page with high usage and an operation result of an application program for the request message into a cache memory. cache in the unit, monitor changes in data associated with the web page in real time to determine the validity of the cached operation result, and the database search result caching module retrieves repeatedly used queries and database search results for the queries. A caching system capable of caching in a cache memory unit, monitoring changes in data related to the query in real time to determine the validity of the cached query result, and predicting and resolving server overload through the artificial intelligence algorithm, the WAS calculation result The caching module further includes a log DB unit in which information monitored by the caching module and the database query result caching module are periodically loaded.

The server load prediction modeling and prediction service unit, based on the information loaded in the log DB unit, through a server load prediction modeling module for generating a model for predicting the load in the server and the model generated by the server load prediction modeling module It includes a server load prediction service module that predicts the load in the server and provides it to the monitoring unit, wherein the server load prediction modeling module includes a pre-processing unit that pre-processes information loaded in the log DB unit, and the information pre-processed by the pre-processing unit. and a model generator for generating a plurality of models through a plurality of algorithms, a model comparison unit for comparing the accuracy of the generated plurality of models, and selecting an optimal model among the plurality of models compared by the model comparison unit to predict the server load. Includes a model distribution unit that distributes as a service module.

The selected optimal model is characterized in that it is a model generated based on a multi-variate (LSTM2) algorithm.

According to the caching system capable of predicting and resolving server overload through an artificial intelligence algorithm of the present invention, a model for predicting server overload is generated and learned through an artificial intelligence algorithm based on log data, and server overload is prevented through the learned model. There are effects that can be predicted and resolved.

1 is a diagram showing the configuration of a caching system capable of predicting and resolving server overload through an artificial intelligence algorithm according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating a detailed configuration of a monitoring unit according to an embodiment of the present invention in FIG. 1 together.
FIG. 3 is a diagram illustrating detailed configurations of a server load prediction modeling and prediction service unit according to an embodiment of the present invention in FIG. 1 .
4 and 5 are diagrams showing each configuration of the server load prediction modeling module.
6A is a diagram showing an example of the collection of data loaded in the log DB unit by the pre-processing unit.
6B is a diagram showing a data frame after data pre-processing.
7 is a diagram illustrating a general description of model generation of a model generator.
8 is a diagram showing a plurality of artificial intelligence algorithms used by the model generator when generating a model.
9A to 9C are diagrams illustrating an example in which a model generator generates a model through an autoregressive model (ARIMA) algorithm.
10A to 10D are diagrams showing examples in which a model generator generates a model through a multi-linear regression algorithm.
11A and 11B are diagrams showing an example in which a model generator generates a model through an XGBoost algorithm.
12A to 12C are diagrams illustrating examples in which a model generator generates a model through a univariate (LSTM) algorithm.
13A to 13C are diagrams illustrating an example in which a model generator generates a model through a univariate (CNN) algorithm.
14A to 14C are diagrams illustrating examples in which a model generator generates a model through a multi-variate (LSTM) algorithm.
15A to 15C are diagrams illustrating examples in which a model generator generates a model through a multi-variate (CNN) algorithm.
16A to 16C are views showing examples in which a model generator generates a model through a multi-variate (LSTM2) algorithm.
17A to 17C are diagrams illustrating an example in which a model generator generates a model through a multi-variate (GRU) algorithm.
18 is a view showing an embodiment in which the model comparison unit compares each model generated by the model generator according to the present invention and selects an optimal model.

Hereinafter, some embodiments of the present invention will be described in detail through exemplary drawings. In adding reference numerals to components of each drawing, it should be noted that the same components have the same numerals as much as possible, even if they are displayed on different drawings.

And, in describing the embodiments of the present invention, if it is determined that a detailed description of a related known configuration or function hinders understanding of the embodiments of the present invention, the detailed description will be omitted.

Also, terms such as first, second, A, B, (a), and (b) may be used to describe components of an embodiment of the present invention. These terms are only used to distinguish the component from other components, and the nature, order, or order of the corresponding component is not limited by the term.

In this specification, the singular form also includes the plural form unless otherwise specified in the phrase. The terms "comprising" and/or "comprising" used in the specification do not exclude the presence or addition of one or more other components other than the recited components.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

1 is a diagram showing the configuration of a caching system 1000 capable of predicting and resolving server overload through an artificial intelligence algorithm according to an embodiment of the present invention.

Referring to FIG. 1, a caching system 1000 capable of predicting and resolving server overload through an artificial intelligence algorithm according to an embodiment of the present invention (hereinafter, mixed with the term 'caching system 1000') is a cache server (100) and customer server group (200).

The cache server 100 includes a monitoring unit 110, a cache memory unit 120, a log DB unit 130, and a server load prediction modeling and prediction service unit 140. The customer server group 200 includes a Web server 210, a WAS server 220 and/or a database server 230.

First, the web server 210 of the customer server group 200 provides a web page composed of HTML to the user according to the user's request, and receives a request message and/or query from the user through the web page. and forwards it to the WAS server 220.

WAS server 220 processes the application service for the request message transmitted from the Web server 210. The WAS server 220 executes an application program, performs an operation on the request message, and returns the operation result to the web server 210. In addition, the WAS server 220 forwards the query transmitted from the web server 210 to the database server 230.

The database server 230 retrieves data that may be a response to a query received from the WAS server 220 and returns the search result to the WAS server 220 .

The cache server 100 caches the request message and the operation result of the application program for the request message in the cache memory unit 120, more specifically, in the cache memory within the cache memory unit 120. Then, the cache server 100 caches the query and the query result of the database server 230 for the query in the cache memory unit 120 .

At this time, the cache server 100 does not cache all request messages and calculation results for all request messages, but the current usage is high, or at a future point in time by the server load prediction modeling and prediction service unit 140 to be described later. Only request messages requested from web pages expected to have high usage and operation results for the request messages are cached.

In addition, the cache server 100 does not cache all queries and search results for all queries, but is currently used repeatedly, or is used by the server load prediction modeling and prediction service unit 140 to be described later to provide information to users at a future point in time. Only queries that are predicted to be used repeatedly and the search results for those queries are cached. A detailed description of the server load prediction modeling and prediction service unit 140 will be described later.

As a result, when a request message for a web page calculated to have high current usage or high usage in the future is received, and the future approaches the present time, the WAS server 220 does not perform an operation on the request message and caches it. An operation result for a corresponding request message stored in the cache memory inside the memory unit 120 may be brought and returned to the user through the web server 210 .

In addition, when a query calculated to be used repeatedly in the present or to be used repeatedly in the future is received, and the future comes to the present time, the WAS server 220 does not pass the query to the database server 230, the cache memory unit ( 120) A search result for a corresponding query stored in the cache memory may be retrieved and returned to the user through the web server 210. Through this, the processing speed and response speed of the entire caching system 1000 can be improved.

FIG. 2 is a view showing the detailed configuration of the monitoring unit 110 according to an embodiment of the present invention in FIG. 1 together.

Referring to FIG. 2 , the monitoring unit 110 includes a WAS calculation result caching module 111 and a database search result caching module 113 .

The WAS calculation result caching module 111 caches a request message requested from a web page with high usage and an operation result of an application program for the corresponding request message in the cache memory unit 120 . And, the WAS calculation result caching module 111 monitors changes in data associated with the corresponding web page in real time to determine the validity of the cached calculation result. That is, the WAS operation result caching module 111 monitors whether there is a change (change) in the information constituting the corresponding web page, the content information of the request message requested in the corresponding web page, and the format information of the corresponding request message. If there is no change, it is determined that the operation result stored in the cache memory unit 120 is valid, and if there is a change, it is determined that the operation result stored in the cache memory unit 120 is no longer valid. If valid, the operation result stored in the cache memory unit 120 is returned to the user via the WAS server 220 and the web server 210. When it is no longer valid, the operation result stored in the cache memory unit 120 is deleted. The WAS calculation result caching module 111, when the monitoring result and the changed information corresponds to frequently changed information such as personalization-related information, session, cookie, parameter value, etc., the WAS server 220 and/or the database server 230 A new value changed from is retrieved and cached in the cache memory unit 120 to automatically update information in real time. The WAS calculation result caching module 111 converts the request message and the calculation result for the request message into a reusable serialized object form according to object storage rules, and caches the result in the cache memory unit 120 . As a result, cached data can be used without modifying the source of the application program or changing the method.

The database search result caching module 113 caches a query that is used repeatedly and a database search result for the query in the cache memory unit 120 . Then, the database query result caching module 113 monitors changes in data related to the query in real time to determine the validity of the cached query result. That is, the database search result caching module 113 monitors whether there is a change in the content information of the query, the form information of the query, etc., and determines that the search result stored in the cache memory unit 120 is valid if there is no change, If there is a change, it is determined that the inquiry result stored in the cache memory unit 120 is no longer valid. If valid, the query result stored in the cache memory unit 120 is returned to the user via the WAS server 220 and the web server 210. When it is no longer valid, the inquiry result stored in the cache memory unit 120 is deleted. The database search result caching module 113 converts the corresponding query and the search result of the query into a reusable serialized object form according to an object storage rule, and caches the result in the cache memory unit 120 . As a result, cached data can be used without modifying the source of the application program or changing the method.

Meanwhile, the information monitored by the above-described WAS calculation result caching module 111 and the database inquiry result caching module 113 are loaded into the log DB unit 130, respectively.

That is, the request message cached by the WAS operation result caching module 111 in the cache memory unit 120, the operation result of the application program for the request message, and the change in data associated with the corresponding web page are monitored in real time and the cached operation is performed. The log DB unit 130 stores information on whether there is a change (change) in the validity of the result, information constituting the monitored web page, content information of the request message requested from the corresponding web page, format information of the corresponding request message, etc. load into In addition, the WAS calculation result caching module 111, when the changed information as a result of monitoring corresponds to frequently changed information such as personalization related information, session, cookie, parameter value, etc., from the WAS server 220 and/or database server 230. The changed new value is brought and cached in the cache memory unit 120, and the information automatically updated in real time is also loaded into the log DB unit 130.

In addition, the query cached by the database query result caching module 113 in the cache memory unit 120, the query result of the database for the corresponding query, and the change in data related to the query are monitored in real time to determine the validity of the cached query result, the corresponding Information on whether or not there is a change in the content information of the query and the format information of the corresponding query is loaded into the log DB unit 130 .

When the monitoring unit 110 loads each piece of information in the log DB unit 130, the date information (date) and time information (time) corresponding to each piece of information, the user access count (user access count), access In addition, information about CPU usage during operation, memory usage during access and operation, and the like are necessarily loaded. However, it is not limited thereto, and additional (derived) data may be used after being created in the source.

Information loaded in the log DB unit 130 is periodically loaded by the monitoring unit 110, analyzed by a server load prediction modeling module 141 to be described later, and used when modeling a server load prediction model.

FIG. 3 is a diagram showing the detailed configuration of the server load prediction modeling and prediction service unit 140 according to an embodiment of the present invention in FIG. 1 .

The server load prediction modeling and prediction service unit 140 includes a server load prediction modeling module 141 and a server load prediction service module 143 .

The server load prediction modeling module 141 generates and learns a model for predicting load in the server at a future point of time based on information loaded in the log DB by the monitoring unit 110 . The server load prediction modeling module 141 may generate and learn a plurality of models through various server load prediction algorithms.

The server load prediction service module 143 predicts the server load at a future point in time through the generated and learned model. The server load prediction service module 143 predicts the server load through a plurality of models generated by the server load prediction modeling module 141, and as an embodiment, the plurality of models generated by the server load prediction modeling module 141. Among them, the optimal model can be used. The server load prediction service module 143 may predict the load in the server at a future point in time (eg, 1 hour later) as a value between 0 and 1 and provide the predicted load to the monitoring unit 110 .

When a request message or query is received through each server in the customer server group 200, the monitoring unit 110 determines whether each request message or query has high usage at a future point in time to the server load prediction service module 143 or It requests a prediction that it will be used repeatedly, and receives a response to the prediction. In the response received by the monitoring unit 110, if it is predicted that the request message or query will be used frequently or repeatedly in the future, the monitoring unit 110 calculates the received request message and the operation result for the request message. , queries and search results for the queries are cached in the cache memory unit 120, as described above.

Thereafter, the WAS server 220 receives a request message for a web page calculated to have a high usage in the future, and when the future approaches the current point in time, the cache memory unit 120 does not perform an operation on the corresponding request message. When a query calculated to be used repeatedly in the future is received and the result of the operation of the request message stored in my cache memory is returned to the user through the web server 210, and the future approaches the present time, the query is not transmitted to the database server 230, the query result for the query stored in the cache memory in the cache memory unit 120 is brought and returned to the user through the web server 210.

4 and 5 are diagrams showing each configuration of the server load prediction modeling module 141 .

Referring to FIGS. 4 and 5 , the server load prediction modeling module 141 includes a preprocessor 1411 , a model generator 1413 , a model comparison unit 1415 and a model distribution unit 1417 .

6A is a diagram showing an example of the collection of data loaded in the log DB unit 130 by the preprocessing unit 1411, and FIG. 6B is a diagram showing a data frame after data preprocessing.

Referring to FIG. 6A , the pre-processing unit 1411 collects log information from each server in the customer server group 200 . The data collected by the pre-processing unit 1411 from the log DB unit 130 includes 1 to 4 below.

1. Request Date time (2022-11-14 10:00:00) : varchar(50)

2. User access count (user access count for the last hour): bigint

3. CPU usage in decimal format (ex: send 0.55 when cpu is using 55%) : float

4. Memory usage in decimal format (ex: 0.60 when mem 60% is in use) : float

As shown in FIG. 6B , the pre-processing unit 1411 pre-processes data (original data, original data) loaded in the log DB unit 130 . Then, the pre-processing unit 1411 divides for model learning and verification.

FIG. 7 is a diagram illustrating a general description of model generation by the model generator 1413, and FIG. 8 is a diagram showing a plurality of artificial intelligence algorithms used by the model generator 1413 when generating a model.

Based on the preprocessed data, the model generating unit 1413, referring to FIG. 7, generates a model according to various artificial intelligence algorithms.

At this time, the modeling data of the model generator 1413 is date information (date) based on time information (time) for each time within a certain period, as shown in FIG. 7 as an embodiment, and the number of user accesses (user access) count), cpu usage during access and operation, memory usage during access and operation, etc.

As an example, when the model generation unit 1413 generates a model, it can be seen that the users column shows a certain pattern from January to March 2022, as shown in FIG. It is possible to predict the load in the server at

Traditionally, in the case of time series data, a function is created by reflecting cycle, seasonality, and trend, and the model generator 1413 according to the present invention uses ARIMA, SARIMA, ARIMAX, SARIMAX, etc. as a time series methodology, and additionally multiple regression analysis After creating the model using (regression), it is compared with the time series model. The model generation unit 1413 finally creates a model using LSTM, GRU, and CNN among the artificial neural models using single variables (users) and multiple variables, respectively, and then, the model comparison unit 1415 compares each model And, the optimal model selected by the model distribution unit 1417 is distributed to the server load prediction service module 143, and the server load prediction service module 143 monitors the selected optimal model from the monitoring unit 110. Delivers the response to the load prediction in the requested server.

As an embodiment, the model generator 1413 may generate each model through a total of 9 algorithms as summarized in FIG. 8 . That is, ARIMA (Autoregressive model) can be used as a time series type, Multi-linear Regression and XGBoost can be used as regression analysis types, and LSTM (univariate), CNN (univariate), and LSTM (multi-variate) as artificial neural network types. ), CNN (multi-variate), LSTM2 (multi-variate), and GRU (multi-variate) can be used.

9A to 9C are diagrams illustrating examples in which the model generator 1413 generates a model through an ARIMA (Autoregressive model) algorithm.

First, the model generating unit 1413, referring to FIGS. 9A to 9C , uses an autoregressive model (ARIMA) to generate a load prediction model within the server. At this time, the prediction result chart is shown in FIG. 9C.

ARIMA is a combination of AR (Autoregression) model and MA (moving average) model, and is the most basic model among time series analysis models. SARIMA is a model in which seasonality is added to the ARIMA model, and is used when analyzing a model with seasonality.

On the other hand, ARIMA and SARIMA models use only the dependent variable with date as an index to create the model, whereas SARIMAX is an exogenous method that uses exogenous variables. That is, in addition to the date index, day of month, day of week, hour, cpu usage, memory usage, etc. are used. As a result of the model itself, there are cases where negative numbers come out, so it is necessary to return a value greater than 0 by applying a rule during post-processing or API service.

Major libraries include Pandas, Sklearn (scikit learn), and Skforecast. As a result, ARIMA series is judged to be less accurate than artificial neural networks.

10A to 10D are diagrams showing examples in which the model generator 1413 generates a model through a multi-linear regression algorithm. At this time, the prediction result chart is shown in FIG. 10C.

The model generation unit, referring to FIGS. 10A to 10D , generates a load prediction model within the server using Multi-linear Regression.

Linear Regression is one of the most used predictive model algorithms and has the advantage of expressing a clear function as a result borrowed from statistical techniques.

At this time, Ordinary Least Squares means a method of finding a function by minimizing the sum of squares of errors.

y = a_0 + a_1 * x ## Linear Equation

Regarding the cost function, the function for finding a_0 and a_1 of OLS means a function that finds the lowest value by becoming a quadratic function that minimizes the sum of squares of the difference between all observed values and predicted values.

At this time, multiple regression can be performed by adding independent variables as needed.

y = a_0 + a_1*x1 + a_2*x2 + a_3*x3 …

Major libraries include Pandas and Sklearn (scikit learn).

11A and 11B are diagrams showing an example in which the model generator 1413 generates a model through an XGBoost algorithm. At this time, the prediction result chart is shown in FIG. 11B.

Referring to FIGS. 11A and 11B , the model generator 1413 generates a load prediction model within the server using XGBoost.

XGBoost is an abbreviation of eXtreme Gradient boosting, and Boosting means an ensemble technique that uses a combination of multiple decision trees. Among algorithms using boosting techniques, gradient boosting is representative, and there is a gradient boost module that supports XGBoost in parallel. XGBoost can be used for both regression and classification.

12A to 12C are views showing examples in which the model generator 1413 generates a model through a univariate (LSTM) algorithm. At this time, the prediction result chart is shown in FIG. 12C.

LSTM stands for Long Short-term Memory, and it compensates for the weakness of the RNN algorithm, which shows strength in predicting sequence or time-series data, in which accuracy decreases as the data set becomes longer. LSTM solves the long-term dependence problem and the vanishing gradient problem.

13A to 13C are diagrams showing examples in which the model generator 1413 generates a model through a univariate (CNN) algorithm. At this time, the prediction result chart is shown in FIG. 13C.

CNN (univariate) is an abbreviation of Convolutional Neural Networks, and is mainly used for image or video processing in deep learning. CNN (univariate) compensates for the weakness of the RNN algorithm, which shows strength in predicting sequence or time series data, in which accuracy decreases as the data set becomes longer. CNN (univariate) solves the long-term dependence problem and the vanishing gradient problem.

14A to 14C are views showing examples in which the model generator 1413 generates a model through a multi-variate (LSTM) algorithm. At this time, the prediction result chart is shown in FIG. 14C.

LSTM stands for Long Short-term Memory, and the RNN algorithm, which is strong in predicting sequence or time series data, compensates for the weakness that accuracy decreases as the data set becomes longer. LSTM solves the long-term dependence problem and the vanishing gradient problem.

15A to 15C are views showing examples in which the model generator 1413 generates a model through a multi-variate (CNN) algorithm. At this time, the prediction result chart is shown in FIG. 15C.

As mentioned above, CNN is an abbreviation of Convolutional Neural Networks. It is mainly used for image or video processing in deep learning, and as the name suggests, it is a neural network model that requires a preprocessing called convolution. CNN compensates for the weakness of RNN algorithms, which show strength in predicting sequence or time series data, in which accuracy decreases as the data set becomes longer. CNN also solves the long-term dependence problem and the vanishing gradient problem.

16A to 16C are diagrams showing examples in which the model generator 1413 generates a model through a multi-variate (LSTM2) algorithm. At this time, the prediction result chart is shown in FIG. 16C.

LSTM, as described above, stands for Long Short-term Memory, and the RNN algorithm, which is strong in predicting sequence or time-series data, compensates for the weakness that accuracy decreases as the data set becomes longer. LSTM solves the long-term dependence problem and the vanishing gradient problem.

17A to 17C are diagrams showing examples in which the model generator 1413 generates a model through a multi-variate (GRU) algorithm. At this time, the prediction result chart is shown in FIG. 17C.

GRU (multi-variate) is a simpler improvement of the existing LSTM. Compared to LSTM, the performance speed is faster, but the accuracy tends to be slightly lower. While LSTM uses four gates, it uses only two gates, a reset gate and an update gate, and this can be said to be the reason for the speed improvement.

18 is a view showing an embodiment in which the model comparison unit 1415 compares each model generated by the model generator 1413 and the model distribution unit 1417 selects the optimal model according to the present invention. .

As described above, the model comparison unit 1415 compares each model generated by the model generation unit 1413, and the model distribution unit 1417 selects an optimal model based on the comparison.

An example of selecting an optimal model by the model comparison unit 1415 and the model distribution unit 1417 is shown in FIG. 18 .

Referring to FIG. 18, the optimal model selection by the model distribution unit 1417 may finally be LSTM2 (multi-variate), and the accuracy of LSTM2 (multi-variate) may be tested as the highest among all algorithms. . It can be seen that LSTM2 (multi-variate) shows about 97.5% accuracy. The loss value of the model was loss: 0.0006 during learning and val_loss: 0.0007 during verification, respectively.

On the other hand, the above-mentioned future time point is generally prepared based on 1 hour later. However, if the future time point is set to a time point at which the future arrives before the operation on the system is completed, or the caching system 1000 according to the present invention is changed from the turn-off state to the first turn-on state, the initial prediction is seconds, When it is necessary to predict the future time point after the minute unit, and/or temporarily predict the future time point in second or minute units as the future time point is variably changed, the model distribution unit 1417 is better than LSTM2 (multi-variate) A model generated based on GRU (multi-variate) can be selected as an optimal model. GRU (multi-variate), as described above, has fewer parameters than LSTM, so it has low computational cost, and its model is simple, so it has a faster learning rate, but it can produce similar performance.

Meanwhile, the present specification proposes a language and platform capable of describing and managing MLOps (Machine Learning Operations) workflow for detecting anomalies in time series data. In order to perform prediction and anomaly detection of time series data, an MLOps platform that can quickly and flexibly apply the analyzed model to the operating environment is required. Therefore, we propose to develop a Python-based AMML (AI/ML Modeling Language), which is widely used for data analysis, to easily configure and execute MLOps workflows. The proposed AI MLOps platform uses AMML to provide date information (date), time information (time), time series data loaded into the log DB from various data sources (R-DB, NoSql DB, Log File, etc.), It is possible to perform pre-processing of information such as user access count, CPU usage during access and operation, memory usage during access and operation, and load prediction in the server.

Machine learning is a field of artificial intelligence, which develops algorithms and techniques for computers to learn. In other words, it is to obtain results such as valuable patterns or predictions through the learned model. Machine learning is divided into supervised learning and unsupervised learning according to the learning method.

Supervised learning is training a model on input data and data with correct labels. Representative algorithms include support vector machines (SVMs), decision trees, and deep learning algorithms. On the other hand, unsupervised learning is learning when there is only input data. Representatively, clustering-based algorithms exist, such as k-means clustering and DBSCAN (density-based spatial clustering of applications with noise). For the proper operation of the machine learning model, it is important to secure automated data for learning and to continuously apply/manage the learned model to the operating environment. Although it is possible to create a model with the initially collected data, data drift may occur in which the data gradually changes after the operating environment is applied. This lowers the accuracy of the model and makes it impossible to flexibly adapt to data changes. Therefore, there is a need to continuously collect and manage changing data in the operating environment and update the model. In particular, when monitoring the caching system 1000, it is necessary to store and manage data in order to check changes in advance signs of abnormal situations and to learn models later. In general, when an error occurs in the caching system 1000, the person in charge focuses on solving the abnormal situation, so it is difficult to secure and manage data. In order to solve this problem, only abnormal data should be stored and managed separately, and data necessary for analysis should be automatically saved when an abnormality occurs. In addition, it should be possible to quickly apply the learned model to the operating environment by using the data obtained in this way.

According to a survey by Makinen et al. (2021), among experts working in the machine learning (ML) domain, 40% of respondents said they use both ML models and infrastructure for operation. In addition, the data used for analysis were mostly relational data and time series data. This suggests the need for storage management and continuous model learning/application of relational and time series operating environment data.

Time-series data can be said to be data taken over a certain period of time when the data includes temporal movement. Forecasting these time series data is challenging due to unprecedented fluctuations and incomplete information. Time series analysis techniques include statistical techniques and techniques using deep learning. As described above, regression analysis, an autoregressive integrated moving average (ARIMA) technique, etc. are used as statistical techniques, and various techniques such as long short-term memory (LSTM) are used as deep learning techniques.

In this specification, we propose an MLOps platform for time-series data analysis. Specifically, it proposes the Python-based workflow technology language AMML (AI/ML modeling language) for automated operation data storage and rapid model deployment, an execution engine, and model management methods. In the following, details of the MLOps (machine learning operations) platform proposed in order, cases using the LSTM model, and conclusions about the MLOps platform are presented.

1. Related works

1.1 MLOps

MLOps is a combination of DevOps and machine learning, a collection of technologies and tools for deploying machine learning models in production environments. DevOps aims to reduce the gap between software development and operation, and CI (continuous integration)/CD (continuous deployment) are two main principles. CI is a method in which development organizations frequently integrate and develop. Through this, it is possible to continuously perform tests and improve errors little by little, and as a result, the software development period can be shortened. CD is a method in which new versions are continuously created for application and testing of the operating environment. This approach provides faster service delivery to customers with new features and continuous integration (CI).

MLOps adds the continuous training (CT) concept of continuous model retraining to these CI/CD functions of DevOps. CT is a concept that involves periodically retraining a model using new data and evaluating the quality of a new model.

The level of automation in MLOps can indicate a level of maturity. There is currently no standard for MLOps maturity levels, but as a major maturity model for reference, there are MLOps maturity levels defined by Google and Microsoft. As shown in <Figure 1>, Google's maturity model has a total of three levels: level 0: manual process, level 1: ML pipeline automation, level 2: CI/CD pipeline automation (CI/CD pipeline automation) step. Microsoft's maturity level consists of a total of five levels as shown in <Figure 2>. Level 0: No MLOps, Level 1: DevOps but no MLOps, Level 2: Automated Training, Level 3: Automated Model Deployment ), Level 4: consists of Full MLOps Automated Operations.

<Figure 1> Google's MLOps Maturity Level

<Figure 2> Microsoft's MLOps Maturity Level

MLOps solutions are being developed by various open sources and companies. MLflow and Kubeflow are actively being developed as open source solutions. MLflow is developed in python. The main components are composed of Trackings, Projects, Models, and Model Registry. Tracking is an API and UI that records the parameters, code, and results of machine learning experiments. Projects are a standard format for packaging reusable code. Models provides rules and tools for packaging machine learning models in different ways.

Model Registry provides a centralized model repository, API, and UI to collectively manage the entire lifecycle of MLflow models. Kubeflow provides a portable and scalable deployment of machine learning workflows on Kubernetes. Key components include Notebooks, TensorFlow model training, Model serving, and Katib. Notebooks can create and manage Jupyter notebooks, and TensorFlow model training can train deep learning models. Model serving uses KFServing and Seldon Core to serve models. Pipelines build scalable, end-to-end machine learning workflows based on containers. Katib enables hyperparameter tuning and provides neural network architecture exploration capabilities. Commercial solutions include Microsoft's Azure Machine Learning, AWS's SageMaker, and Google's Vertex AI. These services enable model development and operation in the cloud. It supports data analysis environment using Jupyter notebook, and provides workflow setting and model management function through UI. However, there are difficulties in sharing and reusing the workflow created with the UI with stakeholders.

1.2 ML-Schema

ML-Schema is proposed by the W3C (world wide web consortium) Machine Learning Schema community group, and its purpose is to provide interoperability between machine learning developers. To do this, we present a shared schema that provides a set of classes, properties, and constraints that can be used to represent and exchange information about machine learning algorithms, data sets, and tests.

Mun et al. (2021) proposed DL2IA (deep learning description language for image analysis), a language that can define and learn deep learning models based on ML-Schema and PROV-ML. DL2IA is a language made of XML, and it was shown that learning and verification can be performed by expressing and using a deep learning model for license plate recognition. However, XML has a disadvantage that it is difficult for humans to easily understand and use, and the expression is long. Also, XML contains both workflow and model information, making it difficult to understand. Accordingly, in this specification, a simplified AMML is proposed. AMML provides a simplified workflow and model representation method, facilitating sharing among stakeholders.

1.3 LSTMs

LSTM is mainly used in time series data analysis in the field of deep learning. LSTM is an improved model of RNN (recurrent neural network). RNNs are characterized by cells storing states, unlike cells of existing neural networks that do not store states. Also, it uses the state of the previous time as input.

The model is performed through the BPTT (backpropagation through time) algorithm. The BPTT algorithm is a learning algorithm modified so that the existing backpropagation algorithm can be used in RNN. However, RNN has a problem of exploding or decreasing its influence over time, which was a problem of existing neural network algorithms. LSTM improves the performance of the model by using forget gate, input gate, and output gate to solve this problem. Forget gate processes the input of the previous time, input gate processes the current input, and output gate processes the output of the model.

1.4 YAML ain't markup language

Although XML has the advantage of being easy to parse and structured through computers, it is in a format that is easier for computers to understand than humans, and it is difficult to use because each start tag and end tag must be written when writing. YAML aims to be a language that is easy for humans to understand. A variety of data in key-value format and list format can be easily expressed in YAML. <Figure 3> shows the data of the purchase list in YAML (left) and XML (right). Compared to XML, YAML is concise and easy to understand.

<Figure 3> Products purchased list using YAML and XML

4. AMML for workflow

AMML is divided into a workflow construction language and a language defining deep learning models to flexibly configure the workflow of MLOps. The workflow configuration language was configured similarly to the Linux command line, and YAML was used as the model definition language.

In the AMML workflow composition language, the connection relationship between components is expressed using a pipe ('|'). That is, the output of the component before the pipe becomes the input of the component after the pipe.

<Figure 4> is an example of a workflow configuration language. This is an example of a workflow composition that receives data from three normal sources and outputs the average and standard deviation. normalsource is a component that generates data having a normal distribution with a set mean and standard deviation. It is designed to support the ‘join’ component that can combine multiple flows and the ‘split’ component that can divide one flow into several flows so that workflows can be configured in various forms.

<Figure 4> Example of AMML and Workflow Diagram

A component consists of a component name and a callback script. The component name is the name of a component to process data. A callback script is a script that is called when a component processes data. For example, if it is defined as 'filter cond = col1 > 1', the filter component receives data one by one during execution and transmits data to the next pipeline only when the value of col1 is greater than 1. At this time, filter is the component name and ‘cond = col1 > 1’ is the callback script. This workflow configuration language is compiled into bytecode for workflow configuration and callback script bytecode. The callback script byte code is set in the workflow component and executed when executed.

<Figure 5> is an example of workflow compilation. ① is the command to create the filter component of the workflow, and ② is the compiled bytecode of the ‘cond = col1 > 1’ script, which is the condition of the filter component of the workflow. The callback script supports basic operations such as four arithmetic operations, comparisons, and boolean operations, and supports method calls provided as built-in.

<Figure 5> Workflow and Callback Script bytecode

<Figure 6> shows the component inheritance structure and each component. Components are classified into AbstractIngress, AbstractProgress, and AbstractEgress with AbstractComponent as the highest abstract class. AbstractIngress is responsible for getting data from the data source and passing it to the next component. In order to create a new type of data source, it can be implemented by inheriting AbstractIngress.

AbstractProgress receives data from the previous component, processes it, and transfers the processed data to the next component. For example, it is a component that performs data filtering and transformation tasks such as filter, minmax scaler, zscore scaler, and LSTM, as well as prediction and learning. AbstractEgresss is a component that processes and terminates data received from the previous component. Components such as print and alert belong to this category. That is, it is used when there is no data to be passed to the next component, and is usually used as the last component in a workflow. Each component runs independently in the form of multiprocess. Sending and receiving of data is done through queues between processes.

<Figure 6> Component Class Diagram

Each component received data in the form of a dictionary from the data source and processed them one by one. Dictionary-type data is a data type in which column names and data are in key-value format, and is a data type that is basically supported by Python. As long as the data source can be expressed in the form of a dictionary, various data sources such as RDB as well as NoSql and log files can be additionally implemented and used.

The workflow configuration language configures the workflow for learning and applying the model, and provides various preprocessing tasks (minmax, z-score scaler, etc.) such as data filtering and column extraction, as well as generating alarms and creating snapshots when abnormalities occur Allow the process to be configured in a variety of ways.

Among them, the snapshot generation component stores input data in an internal buffer. This is a method of saving data when a snapshot save event occurs in another component. Mainly, when an anomaly occurs in the operating environment, the data in the buffer is immediately saved in the database so that it can be used for later analysis or model relearning. <Figure 7> shows how to save data when an alert occurs. ① is an alert generated from a surveillance component. ② is the process of saving alert information. In ③, an alert occurrence event is transmitted to the Snapshot component. ④ is the process of saving the data in the buffer of the Snapshot component.

<Figure 7> Process of snapshot event

5.AMML for models

Deep learning models are defined using YAML. The definition structure of the model is divided into model and learning. The dataset and preprocessing process are not defined separately because they are configured through the workflow. <Figure 8> is a general DNN (deep neural network) expressed in YAML. It is a structure that receives data from a total of six input fields and generates one output.

<Figure 8> Example of AMML for model

The model defines the structure of the model by setting the layers of the deep learning model. Each layer can set and adjust parameters such as the activation function and the number of units. In this specification, a model was constructed using Input, LSTM, and Dense components for analyzing time series data. Learning can be configured by setting parameters such as the loss function and optimizer required for model training. The model learning component constructs and trains a model using the Keras library using the model and training information. Keras used was version 2.9.0.

The YAML of the defined deep learning model is stored in the database along with the model name. In the LSTM learning component, YAML is loaded into the database by referring to the set model name. After creating the model structure using the loaded YAML, learning is performed by receiving input data from the data source.

6.Dataset

ETDataset (electricity transformer dataset) was used to test and verify the time series model.

ETDataset is a data set for predicting the temperature of transformer oil and using it for preventive maintenance of transformers. In this experiment, learning was performed using the ETT-h1 dataset measured in units of time among the ETT (electricity transformer temperature)-Small dataset. The composition of the data set consists of a total of 8 columns including date and oil temperature. <Figure 9> shows the column structure and sample data of ETT-h1.

<Figure 9> Structure and sample of ETT-h1

7. AMML model for ETDataset analysis

The workflow for ETDataset analysis using AMML consists of a learning workflow and a prediction workflow. <Figure 10> expresses the structure of the learning workflow. The learning workflow loads the data of ETT-h1 from the training data source and performs min-max scale work, which is a preprocessing task.

The min-max scaler converts the data into values between 0 and 1 using the min and max values of the column. The preprocessed data is input to the LSTM model learning component to learn and create a model. The model was constructed using LSTM, which is frequently used in analyzing time series data.

<Figure 10> Workflow for model training

<Figure 11> shows the structure of the model and YAML settings related to learning. The activation function of LSTM is set to ‘tanh’.

When training the LSTM model, ‘MAE (mean absolute error)’ was used as the loss function, and ‘adam’ was used as the optimizer. Learning was performed for a total of 20 epochs.

The LSTM model learning component outputs the error (loss) for each epoch and passes it to the next component.

<Figure 11> Model for ETT-h1 analysis

The learned model file is stored in the Hadoop file system (HDFS), and the model meta information (model name, Hadoop storage location of the model) is stored in the database (PostgreSQL) so that it can be used when predicting the temperature of the transformer in the future. <Figure 12> shows the process of saving the learned model. ① When model training is completed in the LSTM training component, a request is made to the Model Manager to register the model and metadata. ② Model Manager stores metadata in the PostgreSQL database. This allows you to retrieve and use the trained model. ③ When the metadata is saved, save the model to HDFS to complete.

<Figure 12> Process of model storing

The prediction workflow is configured as shown in <Figure 13>. Similar to the training workflow, we load the ETT-h1 data from the data source to perform a min-max scale operation. Then, prediction is performed using the LSTM component. The LSTM component loads the model by requesting it from the Model Manager where the model is stored. After changing the predicted value to the original scale through the minmax_inverse component, the predicted value is output.

<Figure 13> Workflow for ETT-h1 predict

<Figure 14> shows the loading process of the model. ① Request a model from the Model Manager. ② Model Manager brings metadata (location information of HDFS). ③ Import the model from HDFS. ④ Send the model to the LSTM component. Finally, the LSTM component uses the loaded model to make predictions on the input data and outputs the results.

<Figure 14> Process of model loading

8. LSTM model training and results

A learning workflow made with AMML was performed. <Figure 15> is a screen for registering and executing the workflow for model learning. The workflow is the same as that of <Figure 10> “source id="ett" | minmax_scaler | train_lstm model="ett:0.1", epoch=20 | print” was used.

<Figure 15> Workflow for training LSTM model

<Figure 16> is a graph showing the change in loss when training is performed with the workflow in <Figure 15>. The final learning loss was 0.0130. <Figure 17> is a graph comparing the value predicted by the model with the actual value, and it can be seen that the predicted value is quite similar. The prediction error was measured as 0.0075.

<Figure 16> loss of model training

<Figure 17> ett-h1 predict and label data

AMML's design principles focused on constructing workflow pipelines as concisely as possible and minimizing setup to increase usability. Google's Vertex AI platform provides a Python SDK to help build pipelines. However, in general languages such as Python, the workflow expression is relatively complex compared to AMML. Additionally, MicroSoft provides a GUI for configuring workflows in Azure ML. The proposed AMML is easy to collaborate with other stakeholders by simply copying and sharing. Preprocessing and analysis components can be changed and applied flexibly. In addition, workflows made in AMML can be easily deployed in production environments.

9. Conclusions

In many cases, machine learning experts put models into production alongside model development. To this end, it collects and processes training data, and continuously learns and improves models. The learned model must be periodically applied to the operating environment. MLOps can automate these processes to improve work efficiency and enhance interoperability between developers and experts. In this specification, AMML is presented as a way to implement MLOps, and LSTM models are learned and predicted to determine applicability. Through this, it was confirmed that the learning and prediction workflow using AMML can be flexibly applied to the operating environment.

The database server 230 and the log DB unit 130 according to the present invention may include a database management system (DBMS). The DBMS is a set of software tools that allow multiple users to access data in the database server 230 and log DB unit 130. DBMS includes IMS, CODASYL DB, DB2, ORACLE, INFORMIX, SYBASE, INGRES, MS-SQL, Objectivity, O2, Versanat, Ontos, Gemstone, Unisql, Object Store, Starburst, Postgres, Tibero, MySQL or MS-access can do. DBMS can access specific data according to the input of a specific command.

In this specification, each component in the cache server and customer server group 200 may be processors that execute sequential processes stored in memory. Or, it can operate as software modules driven and controlled by a processor. Further, a processor may be a hardware device.

In this specification, a "unit" includes a unit realized by hardware, a unit realized by software, and a unit realized using both. Further, one unit may be realized using two or more hardware, and two or more units may be realized by one hardware.

The protection scope of the present invention is not limited to the description and expression of the embodiments explicitly described above. In addition, it is added once again that the scope of protection of the present invention cannot be limited due to obvious changes or substitutions in the technical field to which the present invention belongs.

100: cache server 110: monitoring unit
111: WAS calculation result caching module
113: database query result caching module
120: cache memory unit 130: log DB unit
140: server load prediction modeling and prediction service department
141: server load prediction modeling module
1411: pre-processing unit 1413: model generation unit
1415: model comparison unit 1417: model distribution unit
143: server load prediction service module
200: customer server group 210: web server
220: WAS server 230: DB server
1000: A caching system that can predict and resolve server overload through artificial intelligence algorithms

Claims (5)

In a caching system capable of predicting and resolving server overload through artificial intelligence algorithms including cache servers and customer server groups,
The customer server group,
A web server that provides a web page composed of HTML to a user according to a user's request and receives a request message and a query from the user through the web page;
a web application server (WAS) server that receives the request message and the query from the web server, executes an application program for the request message, performs an operation on the request message, and returns an operation result to the web server; and
A database server that receives the query from the WAS server, searches data that can be a response to the query, and returns a search result to the WAS server;
The cache server,
a monitoring unit for caching the request message, an operation result of the application program for the request message, the query, and a search result of a database for the query in a cache memory unit; and
Server load for estimating the load in the server at a future point in time based on the request message cached by the monitoring unit in the cache memory unit, the operation result of the application program for the request message, the query, and the search result of the database for the query. Includes a server load prediction modeling and prediction service unit for generating a prediction model,
The monitoring unit,
Through the server load prediction modeling and the server load prediction model generated by the prediction service unit, only the request message requested from the web page predicted to have high usage in the future and the operation result for the request message requested from the predicted web page are described above. A query that is cached in the cache memory unit and predicted to be repeatedly used by a user at a future point in time through a server load prediction model generated by the server load prediction modeling and prediction service unit and only the search result for the predicted query is the cache memory. cache in wealth,
The monitoring unit,
It includes a WAS calculation result caching module and a database search result caching module,
The WAS operation result caching module,
A request message requested from a web page and an operation result of an application program for the request message are cached in a cache memory unit, and changes in data related to the web page are monitored in real time to determine the validity of the cached operation result;
The database query result caching module,
Repetitively used queries and database search results for the queries are cached in a cache memory unit, and changes in data related to the queries are monitored in real time to determine the validity of the cached search results;
The caching system capable of predicting and resolving server overload through the artificial intelligence algorithm,
Further comprising a log DB unit in which information monitored by the WAS calculation result caching module and the database inquiry result caching module are periodically loaded,
The server load prediction modeling and prediction service unit,
a server load prediction modeling module for generating a model for estimating load in the server based on the information loaded into the log DB unit; and
A server load prediction service module that predicts the load in the server through a model generated by the server load prediction modeling module and provides it to the monitoring unit;
The server load prediction modeling module,
a pre-processing unit for pre-processing information loaded into the log DB unit;
a model generator for generating a plurality of models through the information preprocessed by the preprocessor and a plurality of algorithms;
a model comparison unit that compares the accuracy of a plurality of generated models; and
A model distribution unit for selecting one of the plurality of models compared by the model comparison unit and distributing it to the server load prediction service module;
The model distribution unit,
If the future time point is after 1 hour, a model generated based on a multi-variate (LSTM2) algorithm is selected and distributed to the server load prediction service module,
The model distribution unit,
The future point in time is set to a point in time that arrives before the operation on the caching system capable of predicting and resolving server overload through the artificial intelligence algorithm is completed, or the caching system capable of predicting and resolving server overload through the artificial intelligence algorithm is turned off. As the state is changed to the first turn-on state, the initial prediction must predict the future in seconds or minutes, or the caching system capable of predicting and resolving server overload through the artificial intelligence algorithm temporarily predicts the future in seconds or minutes Caching capable of predicting and resolving server overload through an artificial intelligence algorithm, characterized by selecting a model generated based on a multi-variate (GRU) algorithm and distributing it to the server load prediction service module when system. delete delete delete delete