KR20240053091A - Micro service providng system based on cloud - Google Patents

Abstract

The present invention includes a plurality of functional service modules having a container structure for performing specific functions; A plurality of function databases assigned to each of the plurality of function service modules; a common database storing base data commonly required for the plurality of functional service modules; and a container-structured common service module for management of the common database. Includes, the function service module can access a specific function database using an API (Application Programming Interface) based on HTTP (hypertext transfer protocol), and the base data of the common database is composed of a separate table and It is possible to provide a cloud-based microservice provision system characterized by synchronization and storage in multiple functional databases.

Description

Cloud-based micro service provision system {MICRO SERVICE PROVIDNG SYSTEM BASED ON CLOUD}

The present invention relates to a cloud-based microservice provision system, and more specifically, to a cloud-based microservice provision system with improved scalability and autonomy through a cloud native database structure.

Server-based web hosting has the problem of low usability as it is limited to server-level operation. In other words, with server-based hosting, it is virtually difficult to fully utilize the entire server, and it is very difficult to maximize the efficiency of server hosting for all customers with whom mutual agreement is not possible. Additionally, server-based hosting involves managing multiple servers with limited manpower, which can place a very large workload on management personnel during operation.

Recently, as interest in cloud computing, which provides virtualized IT (information technology) resources as a service using Internet technology, has increased, many cloud-related services and products are being released around the world.

Cloud computing uses distributed processing technology and virtualization technology to allow users to easily rent storage, networks, platforms, and computer resources, so users can do computing work anywhere as long as they have Internet access and a terminal with computing capabilities. The most common cloud service types include IaaS (Infrastructure as Service), PaaS (Platform as Service), and SaaS (Software as Service).

However, due to the limited resources of these cloud services, there is a risk that problems such as performance delay or system delay may occur whenever the number of users increases. Accordingly, research and development on cloud systems with improved scalability and autonomy are needed.

The purpose of the present invention, which was devised to solve the above-mentioned problems, is to provide a cloud-based microservice provision system capable of improving scalability and autonomy.

Additionally, another purpose of the present invention is to provide a cloud-based microservice provision system capable of load distribution processing.

A cloud-based microservice provision system according to an embodiment of the present invention includes a plurality of function service modules having a container structure for performing specific functions, a plurality of function databases assigned to each of the plurality of function service modules, and the plurality of function services. It includes a common database for storing basic data commonly required for modules, and a common service module with a container structure for management of the common database, wherein the functional service module is an API (Application Programming Interface) based on HTTP (hypertext transfer protocol). ) can be used to access a specific function database, and the base data of the common database can be configured as a separate table and synchronized and stored in the multiple function databases.

In addition, it further includes an in-memory cluster that has an allocated area in the cloud and provides a cache for distributed data processing, and a distributed message processing module that performs distributed processing of real-time data based on the in-memory cluster, The distributed message processing module may replicate the base data of the common database and distribute it to the plurality of function databases, or may distribute change details of the base data to the plurality of function databases.

In addition, the HTTP-based API may include any one of HTTP methods including POST, GET, PUT, and DELETE, and a URL (Uniform Resource Locator) of data that the function service module wishes to process. .

In addition, log data generated according to the operation of the plurality of functional service modules is distributed and stored in the plurality of functional databases through a message queue with a publish/subscribe structure by the distributed message processing module. It can be.

In addition, at least one of the plurality of function service modules operates as a security module that performs an authentication function of a network-connected user terminal, and at least another one of the plurality of function service modules periodically updates event data stored in the in-memory cluster. It operates as a data storage module that stores in the function database, and the security module generates an authentication key for each user terminal and stores it in the in-memory cluster, and stores the authentication key in the in-memory cluster while the user terminal uses the cloud service. Authentication of the user terminal is periodically performed using a stored authentication key, and the authentication cycle is set differently depending on the type of event data that the user terminal wishes to access, and the data storage module is configured to: Depending on this, the storage cycle in the database can be set differently.

According to the present invention as described above, it is possible to provide a cloud-based microservice provision system capable of improving scalability and autonomy.

Additionally, according to the present invention, a cloud-based microservice provision system capable of load distribution processing can be provided.

Figure 1 is a diagram showing the connection relationship between a cloud-based microservice provision system and a user terminal according to an embodiment of the present invention.
Figure 2a is a hierarchy diagram of an existing virtual machine, and Figure 2B is a hierarchy diagram of a container according to an embodiment of the present invention.
Figure 3 is a diagram showing the architecture of a cloud-based microservice provision system according to an embodiment of the present invention.
Figure 4 is a diagram showing the distributed processing method of an existing application.
Figure 5 is a diagram showing a service and database configuration method according to an embodiment of the present invention.
Figure 6 is a diagram showing a configuration method of a cloud-based microservice provision system according to an embodiment of the present invention.
Figure 7 is a diagram for explaining database synchronization according to an embodiment of the present invention.
Figure 8 is a diagram for explaining the operation of a distributed message processing module according to an embodiment of the present invention.
Figure 9 is a diagram showing an in-memory cluster according to an embodiment of the present invention.
Figure 10 is a diagram showing an access method to a common database according to an embodiment of the present invention.
Figure 11 is a diagram showing a data access method of a user client and view environment according to an embodiment of the present invention.

Hereinafter, embodiments related to the present invention will be illustrated in the drawings and described in detail through detailed description. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and should be understood to include all changes, equivalents, and substitutes included in the spirit and technical scope of the present invention. .

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, order, or order of the component is not limited by the term. Additionally, in this specification, when a component is described as being “connected,” “coupled,” or “connected” to another component, the component may be directly connected or connected to the other component, but each component It should be understood that another component may be “connected,” “coupled,” or “connected” between elements. In the case of “connection”, “coupling” or “connection”, it is understood as being physically “connected”, “coupled” or “connected” as well as being electrically “connected”, “coupled” or “connected” as required. It can be.

Terms such as “unit (unit),” “unit,” “character,” and “module” used in this specification refer to a unit that processes at least one function or operation, which is hardware, software, or hardware. and software. In addition, terms such as “include,” “comprise,” or “have” used in this specification mean that the corresponding component may be included, unless specifically stated to the contrary, and thus exclude other components. It should be interpreted as being able to include other components.

In addition, it is intended to be clear that the division of components in this specification is merely a division according to the main function each component is responsible for. That is, two or more components, which will be described below, may be combined into one component, or one component may be divided into two or more components for more detailed functions. In addition to the main functions it is responsible for, each of the components described below may additionally perform some or all of the functions handled by other components, and some of the main functions handled by each component may be performed by other components. Of course, it can also be carried out exclusively by .

Hereinafter, a cloud system with a cloud native database structure according to an embodiment of the present invention will be described with reference to drawings related to embodiments of the present invention.

Figure 1 is a diagram showing the connection relationship between a cloud system and a user terminal according to an embodiment of the present invention.

Referring to FIG. 1, a cloud system 100 (hereinafter referred to as a cloud system) having a cloud native database structure according to an embodiment of the present invention can be connected to a network with a plurality of user terminals 10, and through this, various cloud services can be provided to users. can be provided.

Here, the network refers to a connection structure that allows information exchange between nodes such as terminals and servers. Examples of such networks include the Internet, LAN (Local Area Network), and Wireless LAN (Wireless Local Area). Network), WAN (Wide Area Network), PAN (Personal Area Network), 3G, 4G, 5G, LTE, Wi-Fi, etc., but are not limited to these.

Recently, data generated in various fields is being adopted in a cloud computing environment due to the size and type of data. In particular, most of the software is distributed as a service based on the cloud environment.

Additionally, services such as interactive messengers, portals, and knowledge blogs are also provided based on the cloud environment.

The user terminal 10 can access the cloud system 100 through a network, and through this, the user can use various cloud services provided by the cloud system 100.

Additionally, the user terminal 10 is not particularly limited as long as it has a communication function connected to the cloud system 100 and a display function capable of outputting images or text. For example, the user terminal 10 may be a desktop computer, a laptop computer, a tablet PC, a wireless phone, a mobile phone, or a smart phone. ), smart watch, smart glass, wearable device, etc., but is not limited thereto.

Figure 2a is a hierarchy diagram of an existing virtual machine, and Figure 2b is a hierarchy diagram of a container according to an embodiment of the present invention.

Server virtualization technology, the existing traditional method of forming a cloud, has been implemented through the creation of virtual machines through a hypervisor. Referring to Figure 2a, since a virtual machine is a single computer, a guest OS must always be installed on the host OS and hypervisor. Therefore, since the OS is included in the image, not only does the image capacity increase, but there is also the problem of causing a lot of traffic to transmit the virtualized image over the Internet. In particular, since virtual machines focus only on virtualizing the OS, they only have the ability to create and run images and lack deployment and management functions.

On the other hand, as shown in Figure 2b, containers have a relatively lightweight hierarchical structure compared to virtual machines. These containers only have a container engine on the host OS and do not have a separate guest OS. Therefore, only the programs and libraries for server operation can be installed in isolation in the image installed in the container, and the image capacity can be greatly reduced by sharing OS resources with the host OS. Additionally, unlike virtual machines, containers do not have a separate layer to virtualize hardware, so they can have the advantage of relatively faster memory access, file system, and network speeds compared to virtual machines.

Figure 3 is a diagram showing the architecture of a cloud system according to an embodiment of the present invention.

The cloud system 100 is a system designed based on containers to support various server environments and web-based applications, and has an architectural environment of the type shown in FIG. 3.

That is, the cloud system 100 includes a worker node, which is a virtual or physical machine on which containers are deployed, a management node (or master node) that manages all worker nodes, and a container repository where container images are stored. (Container Repository).

Additionally, each worker node includes one or multiple container applications, and containers belonging to the same worker node can communicate locally with each other and share disk resources.

The management node stores the configuration environment of the cloud system and can manage the entire cluster consisting of worker nodes. For this purpose, the management node may include a network proxy, an API server, a control manager, an event manager, and a scheduler.

A network proxy receives and relays requests from clients seeking resources on other servers in a computer network. Through this, it simplifies and encapsulates the structure of the distributed system, reducing the complexity of the service.

The API server is responsible for requests from users and communication between nodes, and the scheduler allocates resources required for deployment and service of containers (or pods) to appropriate nodes.

In addition, the control manager manages storage space for containers (or pods), label assignment for dynamically added or deleted containers (or pods), replication, and load balancing when grouping multiple containers (pods). In addition, the event manager plays the role of notifying the administrator terminal when a specific situation (or event) occurs within the cloud system.

A worker node is a service component that receives commands from a management node and performs actual work, and can have at least one container application.

Figure 4 is a diagram showing a distributed processing method of an existing application, and Figure 5 is a diagram showing a service and database configuration method according to an embodiment of the present invention.

Referring to Figure 4, the existing application consists of a user client and view environment, controller level, service level, DAO (Data Access Object), and database (DB). In the case of these conventional applications, distributed processing of the load was performed through a load balancer such as L4.

However, the existing distributed processing method simply duplicates the database without considering the characteristics of the data, and the data commonly used by each application is inevitably divided.

Referring to Figure 5, in order to solve the above-mentioned problem, the present invention first subdivides microservices into functional units and performs a process of separating data according to related functions.

In other words, after separating each service, common and standard services and individual micro services are configured respectively, and a connection method between separated data is established to configure the entire service.

In addition, access to the database is done using an API (Application Programming Interface) based on HTTP (hypertext transfer protocol) through each service module.

FIG. 6 is a diagram showing a configuration method of a cloud system according to an embodiment of the present invention, and FIG. 7 is a diagram illustrating database synchronization according to an embodiment of the present invention.

Referring to FIGS. 6 and 7, the cloud system 100 according to an embodiment of the present invention includes a plurality of service modules 131 and 132, a plurality of databases 151 and 152, and an in-memory cluster 120. can do.

The service modules 131 and 132 are modules with a granular container structure to perform specific functions, respectively, and can provide various cloud services to the network-connected user terminal 10.

For example, the service modules 131 and 132 may include at least one common service module 131 and a plurality of functional service modules 132.

The common service module 131 is a module that manages the common database 151 among the plurality of service modules 131 and 132, and may be installed in response to the common database 151.

In addition, the common service module 131 is responsible for managing the base data stored in the common database 151, and provides HTTP to enable access to the base data when there is a request for access to the base data from the function service module 132. Based API can be provided through the function service module 132.

The functional service module 132 is a module excluding the common service module 131 among the service modules 131 and 132, and can each perform a specific, segmented function.

For example, the functional service module 132 includes a security module that performs authentication for the user terminal 10, a group message module related to the interactive messenger service, a processing module for message delay, an external mobile notification message module, and a PC message. It can be set as a module, etc.

Additionally, when performing a specific function, the function service module 132 may refer to a function database 152 other than the function database 152 associated with itself.

In this case, the function service module 132 can access the specific function database 152 using an HTTP-based API.

For example, if the function 1 service module 132 wants to refer to the function 2 database 152, the function 1 service module 132 requests access to the function 2 database 152 to the function 2 service module 132. can be transmitted, and the function 2 service module 132 can provide an HTTP-based API to the function 1 service module 132.

At this time, the HTTP-based API may include any one of the HTTP methods including POST, GET, PUT, and DELETE, and the URL (Uniform Resource Locator) of the data that the function 1 service module 132 wants to process. there is.

Accordingly, the function 1 service module 132 uses the API transmitted from the function 2 service module 132 to create data (POST), query data (GET), and modify data targeting the function 2 database 152. (PUT) and data deletion (DELETE) can be performed.

Meanwhile, in FIG. 6, the function service module 132 consists of a controller level, service level, DAO, service level, and DAO (Data Access Object), and each function service module 132 includes a function database 152. A case where is installed in conjunction is shown.

However, the form of the functional service module 132 may change. For example, if the function database 152 associated with the function service module 132 does not exist, the function service module 132 may be configured with only a service level. Additionally, the service level of the function service module 132 may be omitted, and in this case, the function service module 132 may be configured as a DAO for accessing the controller level and the related function database 152.

The databases 151 and 152 may be based on resources such as non-volatile memory. Data stored in the in-memory cluster 120 may be periodically stored in the databases 151 and 152.

Additionally, the databases 151 and 152 may be arranged in relation to the service modules 131 and 132, and may serve to store data related to each service module 131 and 132.

For example, the databases 151 and 152 may include at least one common database 151 and multiple functional databases 152.

The common database 151 is a database installed corresponding to the common service module 131 among the plurality of databases 151 and 152, and can store base data commonly required for the plurality of functional service modules 132.

The function database 152 is a database installed correspondingly to each function service module 132 among the plurality of databases 151 and 152, and stores data necessary to perform a specific function assigned to the plurality of function service modules 132. You can.

That is, the function database 152 can be assigned to correspond one-to-one with a plurality of function service modules 132, and can receive and store base data from the common database 151.

For example, the base data may include user (customer) information, member information, agent information, partner information, organization information, statistical information, system information, etc. commonly required by the functional service module 132. The underlying data may be organized into separate tables.

In the function database 152, separate function data for implementing a specific function (or service) of the function service module 132 may be stored along with the base data.

However, if the base data required by the multiple function service modules 132 is stored in only one or a small number of common databases 151, the common database 151 is pending when a large number of requests for the base data occur. ) will occur. This pending phenomenon refers to a form in which further transactions are rejected and additional requests are rejected when simultaneously connected DB transactions exceed the limit.

Accordingly, the base data composed of separate tables and stored in the common database 151 can be synchronized and stored in each function database 152.

That is, the databases 151 and 152 are reorganized into a common database 151 that stores common and standard base data and a functional database 152 assigned to each functional service module 132, and the common database 151 ) was implemented to enable load distribution on the databases 151 and 152 by synchronizing and storing the base data in each function database 152. Accordingly, it is possible to provide a cloud system 100 in which problems such as performance degradation do not occur even when a large number of users access simultaneously.

The in-memory cluster 120 can store authentication keys and event data on a container basis, and can provide storage space for distributed data processing by the distributed message processing module 160. This in-memory cluster 120 has an allocated area within the cloud and may be based on volatile memory resources such as cache and RAM memory.

In other words, the in-memory cluster 120 provides a cache that can be used to store authentication keys and event data and distribute data, and through this, a more comfortable and faster cloud service can be provided to users. .

The authentication key is used to authenticate the user who wants to use the cloud system 100, and the event data is a set of data required to provide cloud services by the function service module 132 and data generated when providing cloud services. means.

Additionally, event data may have different security levels depending on its properties. For example, personal information and corporate trade secrets with high security importance may have a high security level, while additional information generated when using cloud services may have a low security level.

That is, the functional service module 132 provides a cloud service using event data stored in the in-memory cluster 120, and thus it is possible to provide a service with improved speed and responsiveness.

Event data stored in the in-memory cluster 120 may be regularly distributed and stored in the function database 152. For example, at least one of the plurality of function service modules 132 may be set as a data storage module, and the data storage module regularly stores event data stored in the in-memory cluster 120 in the corresponding function database 152. You can save it.

In particular, the data storage module 132 may set the storage cycle differently depending on the type of event data. For example, the data storage module 132 can set the storage cycle to be short for event data with a high security level, and set the storage cycle to be relatively long for event data with a relatively low security level.

Meanwhile, at least one of the plurality of function service modules 132 may operate as a security module that performs an authentication function of the network-connected user terminal 10.

In this case, the security module has a container structure and can perform user login and authentication procedures. For example, the security module may provide a login interface for network-connected user terminals 10 and may perform periodic authentication for user terminals 10 for which the login procedure has been completed.

For example, the security module can generate and grant a different authentication key to each user terminal 10 for which the login procedure has been completed, and the authentication key for each user terminal 10 can be stored in the in-memory cluster 120. .

In addition, the security module periodically authenticates the user terminal 10 using the authentication key stored in the in-memory cluster 120 while the user terminal 10 uses the cloud service provided by the cloud system 100 (for example, For example, 5 second intervals).

For example, the authentication key granted by the security module may also be stored in the user terminal 10, and the security module periodically receives the authentication key from the user terminal 10 and compares it with the authentication key stored in the in-memory cluster 120. By doing so, you can proceed with the authentication process. That is, if the authentication key transmitted from the user terminal 10 is the same as the authentication key stored in the in-memory cluster 120, the authentication is determined to be successful and the user's use of the cloud service is continuously permitted, and the user terminal 10 If the transmitted authentication key is different from the authentication key stored in the in-memory cluster 120, it is determined that authentication has failed and the user's use of the cloud service can be blocked.

In particular, the security module 131 may set the authentication cycle differently depending on the type of event data that the user terminal 10 wishes to access. For example, if a specific user wants to access event data with a high security level, the authentication cycle can be set short, and if a specific user wants to access event data with a relatively low security level, the authentication cycle can be set relatively long. You can set it.

When the connection of the user terminal 10 is terminated, the security module can delete the authentication key of the user terminal 10 stored in the in-memory cluster 120, and when the user terminal 10 reconnects later, the above-described login procedure and You can perform the authentication process again.

Since the security module performs an authentication procedure based on the authentication key stored in the in-memory cluster 120, authentication operations can be performed with improved speed compared to the existing method.

Additionally, at least one of the plurality of function service modules 132 may operate as a security module or a management module that performs scaling for other function service modules 132.

Scaling is intended to distribute the load generated by multiple user connections, etc., and refers to the function of adjusting the number of modules 132 in response to the generated load. For example, the number of modules 132 may be increased or decreased in response to the number of sessions of the user terminal 10 and/or traffic generated by the user terminal 10.

Meanwhile, since the service modules 131 and 132 each have a container structure, it is easy to replicate and manage the service modules 131 and 132 of this container structure.

That is, the management module 140 may perform scaling of the service modules 131 and 132 to distribute the load of the service modules 131 and 132. Specifically, the management module 140 may adjust the number of service modules 131 and 132 in response to traffic generated by the user terminal 10.

For example, when a large number of user terminals 10 are additionally connected to the cloud system 100, the load on a specific function service module (for example, a security module) increases rapidly, which may delay the authentication process and service use. there is.

In order to solve this problem, the management module 140 detects traffic by the user terminal 10 and, when the detected traffic exceeds a preset standard value, the number of specific function service modules (e.g., security modules) can be increased, and the number of increased specific function service modules (for example, security modules) can be determined in response to the amount of traffic exceeding the reference value.

Figure 8 is a diagram for explaining the operation of a distributed message processing module according to an embodiment of the present invention.

The distributed message processing module 160 is a module that performs distributed processing of real-time data and can operate based on the in-memory cluster 120.

The distributed message processing module 160 is a large-capacity real-time log processing system and can be defined as a message queuing system that processes using the publish/subscribe paradigm.

Additionally, the distributed message processing module 160 can be used for basic data synchronization of the common database 151 and the functional database 152 described above.

That is, the distributed message processing module 160 can replicate the base data of the common database 151 and distribute it to a plurality of function databases 152, and accordingly, each function database 152 can store the provided base data. You can.

In general, the distributed message processing module 160 may distribute the change history of the base data of the common database 151 to a plurality of function databases 152, and accordingly, each function database 152 may store the provided base data. You can update the stored base data by referring to the change history.

For example, change history of basic data stored in the common database 151 can be extracted based on CDC (Change Data Capture) technology.

Referring to FIG. 8, the distributed message processing module 160 includes a connector 161 that manages whether the base data of the common database 151 has been changed, a data high-speed processor 162 that performs serialization for sending and receiving data, and a serialization It may include a real-time messaging queue 163 that performs distributed processing of distributed data in real time.

Through this, the base data of the common database 151 or the change history of the base data is stored in a plurality of function databases (Message Queue) with a publish/subscribe structure by the distributed message processing module 160. 152) can be distributed and stored.

In addition, in the case of log data generated as a plurality of function service modules 132 provide cloud services when executing each application, a message queue with a publish/subscribe structure by the distributed message processing module 160 It can be distributed and stored in multiple function databases 152 through (Message Queue).

For example, Apache Kafka may be used as the distributed message processing module 160. Apache Kafka is a distributed messaging system developed by LinkedIn and was released as open source in 2011, and shows superior TPS than existing messaging systems through an architectural design specialized for large-capacity real-time log processing. Kafka operates based on the publish-subscribe model. It is largely composed of producers, consumers, and brokers. Kafka's broker manages messages based on topics. The producer creates a message on a specific topic and then delivers the message to the broker. And, when the broker classifies the received messages by topic and stacks them, consumers who subscribe to the topic take the messages and process them. Kafka is designed to operate as a cluster of brokers for scale-out and high availability, and operates as a cluster even when there is only one broker.

Figure 9 is a diagram showing an in-memory cluster according to an embodiment of the present invention.

Referring to FIG. 9, the in-memory cluster 120 according to an embodiment of the present invention may include a slave node 121, a master node 122, and a manager node 123, each having the container structure of FIG. 2B. .

The slave node 121 may store the authentication key and event data in the cache. To this end, a cache capable of storing data may be allocated to each slave node 121.

The master node 122 serves to monitor the status of the slave node 121. For example, the master node 122 may provide a notification to a network-connected administrator terminal (not shown) when the utilization of resources secured through the slave node 121 reaches a preset threshold.

In response to this, the manager can transmit a slave addition request through the manager terminal, and the manager node 123 can secure additional necessary resources by adding the slave node 121 in response to the request.

By designing the in-memory cluster 120 based on the container as described above, it is possible to prevent unexpected loads on the in-memory cluster 120 and resulting system failures due to simultaneous access by a large number of users. In other words, by configuring the in-memory cluster 120 based on a container, the desired amount of resources can be secured by responding to actual data requests in real time, and it is a cloud service that does not cause problems such as performance degradation even when a large number of users access simultaneously. can be provided.

Figure 10 is a diagram showing an access method to a common database according to an embodiment of the present invention, and Figure 11 is a diagram showing a data access method of a user client and view environment according to an embodiment of the present invention.

Referring to Figures 10 and 11, user clients and view environments that do not need direct access to the common database 151 transmit actual real-time data asynchronously in both directions through the load balancer and/or in-memory cluster 120. It is accessible.

Those skilled in the art to which the present invention pertains will understand that the present invention can be implemented in other specific forms without changing its technical idea or essential features. Therefore, the embodiments described above should be understood in all respects as illustrative and not restrictive. The scope of the present invention is indicated by the scope of the claims described below rather than the detailed description above, and all changes or modified forms derived from the meaning and scope of the claims and their equivalent concepts are included in the scope of the present invention. must be interpreted.

10: User terminal
100: Cloud system
120: In-memory cluster
131: Common service module
132: Functional service module
151: Common database
152: Function database
160: Distributed message processing module

Claims (5)

A plurality of functional service modules having a container structure for performing specific functions;
a plurality of function databases allocated to each of the plurality of function service modules and storing event data for providing the specific function;
a common database storing base data commonly required for the plurality of functional service modules; and
a common service module with a container structure for managing the common database; Including,
The functional service module is,
You can access specific function databases using HTTP (hypertext transfer protocol)-based API (Application Programming Interface).
The base data of the common database is,
A cloud-based microservice provision system composed of separate tables and synchronized and stored in the plurality of function databases. According to paragraph 1,
An in-memory cluster that has an allocated area within the cloud and provides a cache for distributed data processing; and
a distributed message processing module that performs distributed processing of real-time data based on the in-memory cluster; It further includes,
The distributed message processing module is,
A cloud-based microservice provision system, characterized in that the base data of the common database is copied and distributed to the plurality of function databases, or the change history of the base data is distributed and provided to the plurality of function databases. According to paragraph 2,
The HTTP-based API is,
A cloud-based microservice provision system that includes one of the HTTP methods including POST, GET, PUT, and DELETE and a URL (Uniform Resource Locator) of the data that the functional service module wants to process. According to paragraph 3,
Log data generated according to the operation of the plurality of function service modules is distributed and stored in the plurality of function databases through a message queue with a publish/subscribe structure by the distributed message processing module. Characterized by a cloud-based microservice provision system. According to paragraph 2,
At least one of the plurality of function service modules operates as a security module that performs an authentication function of a network-connected user terminal, and at least another one of the plurality of function service modules periodically performs the function using event data stored in the in-memory cluster. It operates as a data storage module that stores data in the database.
The security module is,
Generate an authentication key for each user terminal and store it in the in-memory cluster, and periodically perform authentication of the user terminal using the authentication key stored in the in-memory cluster while the user terminal uses the cloud service. Setting the authentication cycle differently depending on the type of event data the user terminal wants to access,
The data storage module is,
A cloud system characterized in that the storage cycle in the database is set differently depending on the type of event data.

Images