WO2018151536A1 - 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 - Google Patents

멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 Download PDF

Info

Publication number
WO2018151536A1
WO2018151536A1 PCT/KR2018/001948 KR2018001948W WO2018151536A1 WO 2018151536 A1 WO2018151536 A1 WO 2018151536A1 KR 2018001948 W KR2018001948 W KR 2018001948W WO 2018151536 A1 WO2018151536 A1 WO 2018151536A1
Authority
WO
WIPO (PCT)
Prior art keywords
game
server
api
tenants
api server
Prior art date
Application number
PCT/KR2018/001948
Other languages
English (en)
French (fr)
Inventor
권오현
Original Assignee
권오현
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 권오현 filed Critical 권오현
Priority to JP2019562534A priority Critical patent/JP6830695B2/ja
Priority to CN201880010780.4A priority patent/CN110267717B/zh
Priority claimed from KR1020180018306A external-priority patent/KR102024164B1/ko
Publication of WO2018151536A1 publication Critical patent/WO2018151536A1/ko

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor

Definitions

  • the present invention relates to a method and apparatus for automatically generating auto scaling call rules for individual tenants in a multi-tenancy environment. More specifically, the present invention relates to a method and apparatus for a backend as a service (BaaS) for creating / managing a game API (application programming interface) server with one click on a cloud basis.
  • a backend as a service BaaS
  • game API application programming interface
  • the current mobile game server development process is being carried out in a copy and paste manner that reuses the previous code because of the “similarity of functions” described in the previous section.
  • a new game When a new game is added, it copies the previously written server code from the repository, modifying and reusing only part of it.
  • the object of the present invention is to solve all the above-mentioned problems.
  • Another object of the present invention is to provide a Baas (Backend as a Service) for game developers more convenient game development.
  • API application programming interface
  • the system automatically sets the auto-scaling call rules for each tenant to generate the auto-scaling call rules for each tenant with only minimal operational data for each tenant, and also automatically performs the autoscaling call rules for each tenant. The purpose.
  • a method for automatically generating an autoscaling calling rule for each tenant in a multi-tenancy environment may be performed by a backend as a service (BaaS) management server operating in a cloud-based multi-tenancy environment from a plurality of tenants.
  • a backend as a service (BaaS) management server operating in a cloud-based multi-tenancy environment from a plurality of tenants.
  • API application programing interface
  • a processor operatively connected, wherein the processor receives a request for a game application programming interface (API) server from the plurality of tenants in a cloud-based multi-tenancy environment, and according to the request, the game API
  • API application programming interface
  • the plurality of tenants may be provided with functions necessary for game development and running based on the game API server.
  • BaaS for more convenient game development of a game developer can be provided.
  • game developers can more conveniently develop the game with less human / material resources.
  • system automatically sets the auto scaling call rule for each tenant to generate an auto scaling call rule for each tenant with minimal operational data for each tenant, and automatically performs the auto scaling call rule for each tenant.
  • FIG. 1 is a conceptual diagram illustrating a development method for an existing back-end server.
  • FIG. 2 is a conceptual diagram illustrating a game BaaS according to an embodiment of the present invention.
  • FIG. 3 is a conceptual diagram illustrating a method of providing a game API server based on a cloud according to an embodiment of the present invention.
  • FIG. 4 is a conceptual diagram illustrating a service providing method through a game API server according to an exemplary embodiment of the present invention.
  • FIG. 5 is a conceptual diagram illustrating a traffic demand prediction method specialized for a mobile game server according to an embodiment of the present invention.
  • FIG. 6 is a conceptual diagram illustrating a game API server operating method according to an embodiment of the present invention.
  • FIG. 7 is a conceptual diagram illustrating a structure of a BaaS management server according to an embodiment of the present invention.
  • FIG. 8 is a conceptual diagram illustrating the operation of BaaS according to an embodiment of the present invention.
  • FIG. 9 is a conceptual diagram illustrating an operation of a BaaS management server according to an embodiment of the present invention.
  • FIG. 10 is a conceptual diagram illustrating an operation of a BaaS management server according to an embodiment of the present invention.
  • FIG. 11 is a conceptual diagram illustrating a method for automatically generating auto scaling call rules for individual tenants in a multi-tenancy environment according to an embodiment of the present invention.
  • FIG. 12 is a conceptual diagram illustrating a method for automatically setting a tenant auto scaling call rule according to an embodiment of the present invention.
  • the mobile game may be driven based on an application (APP, application) installed on the device and a back-end application programming interface (API) server that performs invisible functions.
  • the back-end API server for mobile games has similar features such as membership / login / item / chart / ranking / character / ranking / level regardless of game genre and size. Due to these characteristics, the production process of the mobile game server can be standardized and automated.
  • BaaS Backend as a Service
  • Creating a game using the game server BaaS can dramatically reduce production time and costs. With the introduction of the game server BaaS, we can catch two rabbits: reduced costs and shorter development time. You can also add these savings to your game production to make your games even higher.
  • the game server BaaS may provide 1 game API server automatic production function, 2 server auto scaling, 3 game management function, and the like.
  • Game server BaaS according to an embodiment of the present invention can create and provide a game API server for game developers within a certain time with just one click. Through this, domestic game developers can shorten the production period and cost of the game, and can create high-quality games by investing the reduced production period and the cost in other development.
  • FIG. 1 is a conceptual diagram illustrating a development method for an existing back-end server.
  • FIG. 2 is a conceptual diagram illustrating a game BaaS according to an embodiment of the present invention.
  • the game BaaS may provide a game developer with one-click on a cloud server a back-end server that provides a game API used in a game.
  • the mobile game may operate based on a game API server that is in charge of an app installed on the device and a member registration, login, item purchase function, and the like.
  • Game API server for these functions is composed of standardized functions regardless of game genre and size and can be automated.
  • the game BaaS may automatically generate / provide an integrated DB (database) and a game API server according to a game genre / interlocked SNS / item type / character type / ranking type.
  • it may be a cloud service of a multi-tenancy environment that provides a service to a plurality of game servers, and the service may be provided for each tenant.
  • the game BaaS may directly develop a game app without going through a separate game API server production step.
  • FIG. 3 is a conceptual diagram illustrating a method of providing a game API server based on a cloud according to an embodiment of the present invention.
  • FIG. 3 a network for the game BaaS is disclosed.
  • the BaaS management server may provide a game API server by interworking with each tenant (eg, a game server) in a cloud-based multi-tenancy environment.
  • the game API server implements APIs available to game developers. Game developers can implement the game by selectively utilizing the API required for the game among the available APIs implemented in the game API server.
  • the BaaS management server may provide a game developer with a game API server that implements all APIs that can be provided in advance, or provide a game API server that implements only APIs required by the game developer.
  • the BaaS management server may check the load on the API server provided to perform the game and perform scale up / scale out of the game API server.
  • the BaaS management server may predict the load (eg, central processing unit (CPU) load, memory load, etc.) of the game API server through a separate prediction unit or prediction server.
  • the prediction unit (or separate prediction server) of the BaaS management server may perform load prediction based on a separate game API server rather than a game API server provided to a real game developer in order to predict the load of the game API server.
  • Cloud services in a multi-tenancy environment that provides services to a plurality of clients (game servers) like the present invention require traffic control for each tenant. Traffic control can be handled to some extent by auto scaling, but the call rule of auto scaling has a problem that can be generated only after accumulating operational data.
  • the tenant may be a game server serviced by a BaaS management server according to an embodiment of the present invention.
  • BaaS management server according to an embodiment of the present invention can provide a cloud service of a multi-tenancy environment providing a service to a plurality of tenants.
  • the game BaaS provides a simpler software development kit (SDK) for connecting the application and the game API server, so that instead of the complex code (e.g. 100 lines) for connecting the existing application to the game API server,
  • SDK software development kit
  • the connection between the application and the game API server may be performed through code (for example, two lines).
  • BaaS-based multi-tenancy service is composed of a server infrastructure consisting of infrastructure as code (IaC), REST (Representational State State Transfer) API, the SDK for the client, the REST API is an interface between the back end and the client It is responsible for collecting metrics such as when and how many times the SDK accesses the REST API.
  • IaC infrastructure as code
  • REST Real-Representational State State Transfer
  • FIG. 4 is a conceptual diagram illustrating a service providing method through a game API server according to an exemplary embodiment of the present invention.
  • FIG. 4 a method of implementing necessary functions on a game based on a game API server provided by a BaaS management server in a game developer device is disclosed.
  • the game developer device may set a project name of a game to be developed and select a project type of the game. For example, if a game developer wants to develop a sports game, the sports game may be selected as the project type.
  • the game developer device may select a character API server, a skill API server, an item API server, and the like among game API servers provided by the BaaS management server.
  • Existing game developers have set up a separate backend API server for the development / implementation of characters, skills, and items used in games when developing games, and separately developed functions for characters, skills, and items.
  • the game API server includes a character API server, skill API server, item API server for the development / setting of the character, skill, item, etc. of the sports game, the game developer is required API server Optionally available.
  • the game developer does not need to set up a separate backend API server for functions such as characters, skills, and items to be used in the game, and develop functions for characters, skills, and items, and the character API server and skills included in the game API server.
  • Such a game API server may be provided by grouping into a game API server group.
  • the state of the server, whether the server is automatically expanded, etc. may be additionally set through the game developer device.
  • the game BaaS may provide an event management function, a game information management function, a maintenance function, a push sending function, an error report function, a game log function, a ranking management function, a server setting function, and the like.
  • a game API server for developing characters, skills, items, and the like related to a game may be provided through a game information management function.
  • a game API server for push sending may be provided to game users through a push sending function.
  • a game API server for social login may be provided through a game log function.
  • a game API server for a notification management function, a member management function, and the like may be provided through BaaS.
  • FIG. 5 is a conceptual diagram illustrating a traffic demand prediction method specialized for a mobile game server according to an embodiment of the present invention.
  • the game BaaS may perform a search for a pattern after classifying traffic by day.
  • a mobile game server with an Intelligence Load Balancer (hereinafter referred to as ILB) can apply an automatic server scale out function without any separate measurement and analysis process.
  • ILB Mobile games do not distribute traffic, but tend to focus on specific periods of time. ILB can take advantage of a predefined event calendar to preemptively generate unusual traffic. Mobile game servers using ILB can operate without interruption by automatic server expansion even in the event of traffic explosion. ILB can automatically perform AutoScale Up and AutoScale Out for game API servers.
  • FIG. 6 is a conceptual diagram illustrating a game API server operating method according to an embodiment of the present invention.
  • Game BaaS can support the use of Scale Out without advanced technical personnel by setting the Scale Out rule with the game genre / standardized traffic pattern.
  • FIG. 7 is a conceptual diagram illustrating a structure of a BaaS management server according to an embodiment of the present invention.
  • the BaaS management server may have a plurality of hierarchical structures.
  • the plurality of hierarchical structures may include a business layer 700, a cache layer 710, a persistence layer 720, and an analysis layer 730.
  • the business layer 700 may include a plurality of game API servers.
  • the plurality of game API servers may be servers for providing functions used by game developers.
  • the plurality of game API servers may include a subscription API server, a login API server, an item API server, a character API server, and the like.
  • a game developer device using a BaaS and / or a game server (hereinafter referred to as a game server) may provide a user device with necessary functions in cooperation with at least one API server among a plurality of API servers.
  • SDK software development kit
  • game developers can utilize a plurality of game API servers provided by the BaaS management server.
  • the BaaS management server can be used as a template by creating a docker image of standardized functions such as subscription, login, items, charts, ranking, and payment.
  • the docker image stored when the new game server is generated may be distributed to the called server so that the game API server may be activated at the same time as the game server is created.
  • Information transmitted from each game server through the plurality of game API servers may be stored in a data storage layer such as a cache layer 710 and / or a persistence layer 720.
  • a data storage layer such as a cache layer 710 and / or a persistence layer 720.
  • the game server is provided with the user login function through the login API server included in the BaaS management server, the user login information is stored in the cache layer 710 and / or the persistence layer 720 through the game API server.
  • the game API server may call data stored in the cache layer 710 and / or persistence layer 720 as needed, and the cache layer 710 and / or persistence layer 720 transfer the called data to the game API server.
  • the cache layer 710 may provide a fast API query function based on a memory map.
  • the cache layer 710 may be implemented to store data frequently called through a plurality of API servers.
  • the cache layer 710 may store data that requires fast processing or frequently called among data stored / managed in the persistence layer 720.
  • the persistence layer 720 is a layer responsible for data processing (creation / modification / deletion / selection (search)) of data.
  • Persistence layer 720 may be implemented for data storage / management for the operation of a plurality of API server.
  • Table 1 below shows exemplary storage solutions and types of each of the persistence layer 720 and the cache layer 710.
  • the analysis layer 730 may be implemented to manage the operations of the business layer 700, the cache layer 710, and the persistence layer 720 through state analysis of the BaaS management server.
  • the analysis layer 730 may serve as an intelligence load balancer (ILB) for load balancing a plurality of game API servers.
  • ILB intelligence load balancer
  • the analysis layer 730 dynamically collects traffic for a certain period of time (eg, day / time) to dynamically generate an AutoScale calling rule.
  • Game server operators can use the AutoScale environment without the need for advanced server management personnel, and mobile game servers with ILB can run uninterrupted even under heavy traffic.
  • the analysis layer 730 determines data to be stored / managed in the cache layer 710, data to be stored / managed in the persistence layer 720, and data on the cache layer 710 and / or persistence layer 720. You can save / manage the data.
  • FIG. 8 is a conceptual diagram illustrating the operation of BaaS according to an embodiment of the present invention.
  • FIG. 8 illustrates a management method for a plurality of game API servers to be linked with a game server.
  • a plurality of game API servers may operate in conjunction with game servers 810, 820, and 830.
  • BaaS may operate in conjunction with a plurality of game servers 810, 820, and 830 for each of a plurality of games, and the plurality of game API servers provided by BaaS may be matched with game servers 810, 820, and 830. Can be.
  • the plurality of game API servers may correspond to the game server in various ways.
  • a plurality of game API servers may be grouped into game API server groups 850 and 860, respectively, and game API server groups 850 and 860 may be matched with at least one game server 810, 820, 830. have.
  • One game API server group 850 and 860 may be a collection of all APIs provided by BaaS.
  • one game API server group 850 and 860 may include a membership API, a login API, an item API, a chart API, a ranking API, a payment API, and the like.
  • the throughput required by game server 1 810 exceeds a threshold throughput that can be processed through one game API server group 1 850, then another plurality of game API server group 2 860 may be gamed.
  • the server 1 810 may be additionally matched to satisfy the throughput required by the game server 1 810.
  • game server 1 810 determines whether the throughput required by game server 1 810 is less than the threshold throughput that can be processed through one game API server group 1 850.
  • another game server 820 provided with services based on the BaaS management server.
  • the service may be provided using the same game API server group 1 (850) as game server 1 (810). That is, one game API server group 1 850 may provide a service to a plurality of different game servers 810 and 820.
  • scaling such as server expansion / server reduction may be performed in consideration of throughput of a plurality of game API server groups.
  • the analysis layer establishes a matching relationship between the game API server group and the game server by analyzing the throughput required by the game server to determine whether to scale to the server, such as server expansion, server maintenance, or server shrinkage. Can be done.
  • FIG. 9 is a conceptual diagram illustrating an operation of a BaaS management server according to an embodiment of the present invention.
  • FIG. 9 illustrates a management method for a plurality of game API servers to be linked with a game server.
  • At least one game API server among a plurality of game API servers provided as BaaS may be separated, and BaaS may be provided to the game server based on the separated at least one game API server.
  • separation of the game API server with high throughput among the plurality of game API servers included in the business layer may be performed, and allocation of a separate server resource to the separated game API server and management of server resources May be performed to provide BaaS.
  • the analysis result of the analysis layer, the login API throughput among the membership API, login API, item API, chart API, ranking API, payment API included in the game API server group 900 may be greater than or equal to the threshold throughput.
  • the login API 920 may be separated from the game API server group 900 and managed as a separate game API server group 950.
  • the analysis layer may provide a service to the game server by applying separate server scaling to the separated game API server group 950.
  • game server 1 and game server 2 may be provided with a subscription API, login API, item API, chart API, ranking API, payment API function through game API server group 1, game server 1 and game server.
  • the server allocated to the game API server group 1 can be expanded or reduced according to the throughput required in 2.
  • the game server 1 may be provided with the login API function through the separate API server group 1, and the game server 2 may be provided with the login API function through the separate API server group 2.
  • Scaling of the servers included in the separate API server group 1 may be performed according to the login related throughput required by the game server 1.
  • Expansion / contraction of the servers included in the separate API server group 2 may be performed according to the login related throughput required by the game server 2.
  • separate separation may be performed for at least one game API server among the plurality of game API servers included in the game API server group according to the determination of the separation layer.
  • Separate game scaling may be applied to the game API server group and the game API server group.
  • FIG. 10 is a conceptual diagram illustrating an operation of a BaaS management server according to an embodiment of the present invention.
  • FIG. 10 a management method of a plurality of game API servers to be linked with a game server is disclosed.
  • a plurality of game API server management method over time is disclosed.
  • the BaaS management server may collect throughput of each of the plurality of game API servers over time, and predict the throughput of each of the plurality of game API servers over time to group the plurality of game API servers.
  • the BaaS management server may perform throughput analysis for each time slot for each of a plurality of game API server groups matching the plurality of game servers and a plurality of game API servers included in the plurality of game API server groups.
  • the API server may mean a game API server.
  • the first game API server group 1010 may include a first API server 1 1013, a first API server 2 1016, and a first API server 3 1019.
  • the second game API server group 1020 may include a second API server 1 1023, a second API server 2 1026, and a second API server 3 1029.
  • the third game API server group 1030 may include a third API server 1 1033, a third API server 2 1036, and a third API server 3 1039.
  • API server 1 1013, 1023, 1033 may be a login server
  • API server 2 1016, 1026, 1036 may be a subscription server
  • API server 3 1019, 1029, 1039 may be an item server.
  • first API server 1 1013, first API server 2 1016, first API server 3 1019), second API server 1 1023, second API server 2 (1026), second API server 3 (1029), (third API server 1 (1033), third API server 2 (1036), third API server 3 (1039) may be adaptively grouped. Can be.
  • the total time may be divided into a plurality of time intervals, and the game API server group may be changed according to the plurality of time intervals.
  • first API server 1 (10) 1013, first API server 2 (20) 1016, first API server 3 (30) 1019), (second API server 1 (30) 1023, 2nd API server 2 (10) 1026, 2nd API server 3 (20, 1029)), (3rd API server 1 (50) 1033, 3rd API server 2 (10) 1036, the third API server 3 (10, 1039) may be assumed to be required.
  • the parenthesis next to the server is an arbitrary representation of throughput.
  • the first API server 2 (20) 1016, the first API server 3 (30) 1019, the second API server 3 (20) ( 1029), the third API server 2 (10) 1036 and the third API server 3 (10) 1039 may be set as the second 'game API group 1050 to process a request of the game server.
  • the game API group may be adaptively regrouped in consideration of the required throughput for each game API server over time, and accordingly, server scaling may be efficiently performed while reducing the required amount of server resources.
  • FIG. 11 is a conceptual diagram illustrating a method for automatically generating auto scaling call rules for individual tenants in a multi-tenancy environment according to an embodiment of the present invention.
  • the cloud service 1100 of a multi-tenancy environment that provides a service to a plurality of clients (game servers) as in the present invention may adaptively adjust traffic for each of the plurality of tenants 1110, 1120, and 1150. This is necessary.
  • Tenants 1110, 1120, and 1150 may be game servers serviced by the BaaS management server according to an embodiment of the present invention. Traffic control can be handled to some extent with the existing auto scaling, but the current auto scaling call rule is set and generated by humans after the accumulation of operational data.
  • autoscaling may not operate normally until sufficient operational data is accumulated, and setting of the autoscaling calling rules based on the judgment of a person may result in each tenant 1110.
  • traffic expansion may not be properly handled.
  • the autoscaling call rule for each tenant is generated using only minimal operational data, and the autoscaling call rule is automatically performed. Aim.
  • each tenant 1110, 1120, 1150 operates its own service with an architecture and an interface provided by a multi-tenancy provider (BaaS provider). This may mean that even though the services between tenants 1110, 1120, and 1150 are different, the back end infrastructure and the interface used are the same.
  • BaaS provider multi-tenancy provider
  • the BaaS-based multi-tenancy service may be composed of a server infrastructure configured with infrastructure as code (IaC), a REST API, and a client SDK.
  • IaC infrastructure as code
  • REST API is responsible for the interface between the backend and the client, and can collect metrics such as when and how many times the SDK accesses the REST API.
  • REST APIs can be included in the business layer.
  • the analysis layer may collect operational data for each of the tenants 1110, 1120, and 1150 and generate rules.
  • the analysis layer can include a flexible, scalable data store, a log collector that collects operational data, and a data visualization tool that analyzes the collected operational data and outputs them as rules.
  • operation data for tenants 1110, 1120, and 1150 may be collected in a data store.
  • Operational data is collected by the log collector of the analysis layer, and the log collector can be built in the IaC infrastructure for multi-tenant to proceed with the collection.
  • Data collected by the log collector are the interface call time (YYMMDDHHMM), the calling interface, and the parameters passed to the interface.
  • call time data The most important of these is call time data.
  • the call time can be collected in minutes. Collecting operational data, in seconds or microseconds, is not a good fit for generating autoscaling rules and can be a waste of computing power because the time that autoscale takes is minutes.
  • Operational data can be divided into individual tenant data and multi-tenant data.
  • the data per individual tenant may be operational data associated with individual tenants, and the data per multi-tenant may be operational data associated with multiple tenants.
  • the main tenant data of an individual tenant may include traffic information by day, traffic information by hour, and traffic information by event.
  • Day traffic information may include information on traffic by day. All services have different traffic by day depending on the characteristics of the service. Traffic information for each day of the week may be collected through a search and registration request for traffic information for each day of the service.
  • the time zone traffic information may include information on time zone traffic. According to the characteristics of the service, the traffic trend varies according to time zones, and there are some services in which more than 90% of traffic flows in a specific time zone. Tenants 1110, 1120, and 1150 that provide this type of service are very difficult to manage traffic in a multi-tenancy environment. Therefore, the information on the traffic trends according to time zones may be collected through the time-domain traffic trend information search and registration request.
  • the traffic information per event may include information about traffic for each event.
  • a game service may show a sharp increase in traffic during the vacation season and a webtoon service may show a pattern of increasing traffic on holidays such as Children's Day and Christmas.
  • the characteristics that affect time such as holidays, vacations, etc. in the area where the service is provided are collectively called 'events', and the event information may vary from country to country.
  • the analysis layer analyzes traffic information by day, hourly traffic information, and traffic information by event to define traffic patterns and set auto scaling call rules.
  • the auto scaling call rule set according to the defined traffic pattern information may be stored in a relational database of a persistent layer that can be accessed and used by the auto scaling call rule system.
  • a traffic pattern may be defined as below based on the traffic information of each day and the hourly information, and an auto scaling call rule may be set.
  • game API server call records for each of a plurality of game API servers included in a game API server group may be collected.
  • the game API server call record may include information about time (year / month / day / hour / minute, YYMMDD HH: MM), called uniform resource locator (URL), and passed parameters.
  • the number of calls can be counted in minutes based on the game API call history. For example, a day could be split into minutes for the login API server, resulting in a count of minute calls. That is, the number of minute calls for each of the plurality of game API servers may be counted based on the API call records for each of the plurality of game API servers.
  • the above process may be repeated on a weekly basis, and the minute share of each day of the plurality of game API servers may be calculated based on the number of minute calls to each of the plurality of game API servers aggregated on a daily basis.
  • the minute share by day is grouped by week so that the share of minute by week is calculated for each of the plurality of game API servers.
  • the average value of the daily minute share of each of the plurality of game API servers for each day of the week may be calculated. For example, the average share value of Monday's minutes, the average share of Tuesday's items, and the like of the item API server of the game API server may be determined.
  • the weighted average value may be calculated by setting a higher weight as the adjacent value based on the current time point when calculating the daily minute share average value for each of the plurality of game API servers. Based on the current point in time, the daily share of the weekly share before 1 week is assigned a weight higher than the daily share of the weekly share before 2 weeks, and the weighted average value to which the weight value is applied may be calculated.
  • information (or inflection point information) about an interval (or a time point) requiring server scaling is stored in a storage unit (for example, a relational database management system (RDBMS)).
  • RDBMS relational database management system
  • the RDBMS is a data storage structure contained in the persistent layer.
  • a schedule for auto scaling is registered in the scaling scheduler server based on information on a section (or time point) that requires server scaling registered in the RDBMS, and is assigned to each of a plurality of game API servers based on the schedule for auto scaling. You can scale server resources.
  • a traffic pattern may be defined as below based on event information of each event, and an auto scaling call rule may be set.
  • the lifespan of a mobile game can be short, and therefore setting up an autoscaling calling rule based on a record of a yearly event can be meaningless. For example, if a game-related event is provided for a specific game on Children's Day 2017, it may be meaningless to predict the traffic by using the data on Children's Day 2018. In addition, events provided within one area may have an average effect.
  • an event day is registered in the analysis layer, and when the event registration date ends, the event for each of the plurality of game API servers
  • the increase / decrease of the share may be determined by comparing the minute share of the registration date with the minute share of the corresponding day.
  • the increase and decrease of the occupancy may be determined for each of the plurality of game API servers.
  • the occupancy increase / decrease of each game may be determined at the event of a plurality of events, and the average value of the occupancy increase / decrease of the game may be determined at the event of a plurality of events.
  • the average value of occupancy increase / decrease for each game may be determined for each event type.
  • an average value of share increase / decrease by game by event category may be determined by classifying an event category (for example, a subscription event or an item presentation event), or by game by event category according to a category of an event to be performed.
  • Auto scaling may be performed for each of the plurality of game API servers based on the average value of occupancy increase and decrease.
  • Information on the average value of the share increase / decrease by game at the event may be registered in the storage unit (eg, RDBMS).
  • the schedule for autoscaling at the event is based on the information on the average value of the share increase / decrease by game (or the average value of share increase / decrease by game by event category) stored in the storage and the average value of daily share share by event.
  • the server resources allocated to each of the plurality of game API servers may be scaled based on the schedule for auto scaling.
  • the plurality of game API servers are based on the average value of the share increase / decrease of the share per game and the average share of the Wednesday minute share for each of the plurality of game API servers. Auto scaling on server resources allocated to each may be performed.
  • FIG. 12 is a conceptual diagram illustrating a method for automatically setting a tenant auto scaling call rule according to an embodiment of the present invention.
  • traffic pattern information of a tenant is defined through a method of collecting and analyzing traffic operation data for each tenant, it is possible to set an auto scaling call rule.
  • the areas where autoscaling should be applied are the server instance (or business layer) responsible for the REST API, and the persistent layer where the data is stored. Therefore, both the server instance and the persistent layer may be scalable environments.
  • a server computing resource for generating call rules 2) a server computing resource for changing auto scaling call rules, and 3) a scheduler for changing call rules to generate an auto scaling call rule.
  • Both 1) and 2) can be configured as functional micro servers of cloud services such as Amazon Web Service (AWS) Lambda and Azure Function.
  • Azure Amazon Web Service
  • a server computing resource for calling rule generation is defined as a call rule generator 1200
  • a server computing resource for autoscaling calling rule change is called a call rule changer 1220
  • a call rule change scheduler is defined as a scheduler 1240. Can be.
  • the call rule generator 1200 may register a pattern defined by the scheduler.
  • the scheduler 1240 may register days of the week and time when autoscaling is to be performed, events and server computing resources to be prepared, and times when autoscaling ends.
  • the scheduler 1240 may execute the call rule changer at a predetermined time, and the call rule changer 1220 may apply the day / time / event / server computing resource registered in the scheduler 1240 to the tenant's server infrastructure. .
  • Embodiments according to the present invention described above can be implemented in the form of program instructions that can be executed by various computer components and recorded in a computer-readable recording medium.
  • the computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination.
  • Program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tape, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device may be modified with one or more software modules to perform the processing according to the present invention, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

본 발명에 따른 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법은 클라우드 기반의 멀티 테넌시 환경에서 동작하는 BaaS(backend as a service) 관리 서버가 복수의 테넌트로부터 게임 API(application programing interface) 서버에 대한 요청을 수신하는 단계와 BaaS 관리 서버가 요청에 따라 게임 API 서버를 제공하는 단계를 포함할 수 있되, 복수의 테넌트는 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받을 수 있다.

Description

멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치
본 발명은 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치에 관한 것이다. 보다 상세하게는 클라우드 기반으로 게임 API(application programming interface) 서버를 원 클릭으로 생성/관리하는 BaaS(Backend as a Service)를 위한 방법 및 장치에 관한 것이다.
콘텐츠 진흥원이 발간한 「2015 게임백서」에 따르면 2014년 기준 모바일 게임의 평균 개발기간은 10개월에 제작인원은 7.6명이라고 한다. 평균 임금을 대입해 계산해보면 1개의 게임을 만드는데 대략 2억 4천만 원이 들어간다. 그런데 이렇게 만든 게임의 평균 이용기간은 4개월(14.7주)밖에 되지 않는다. 즉 모바일 게임은 제작 기간의 절반도 안 되는 짧은 수명을 갖고 있는 것이다. 따라서 제작 기간을 줄이면 게임 개발사의 수익률을 높일 수 있다. 그러나 제작 기간을 줄이기 위해선 인원을 더 투입해야 하고, 결과적으로 비용이 늘어나기 때문에 개발사에겐 대안이 없었다. 즉, 게임 개발을 위한 자원은 많이 들어가는데 반해 게임의 유행 주기가 짧아 게임 개발사들이 경영상의 문제점을 가지게 된다.
현 모바일 게임 서버 개발 과정은 이전 항목에서 구술한 ‘기능의 유사성’을 이유로, 이전 코드를 재사용하는 카피 앤드 페이스트(Copy + Paste) 방식으로 진행되고 있다. 새로운 게임이 추가되면 이전에 작성한 서버 코드를 저장소에서 복사해 일부만 수정, 재사용하는 것이다.
이로 인해 유사한 서버 코드를 프로젝트 별로 관리해야 하는 리포지터리(repository) 관리 문제, 동일한 배포 환경을 프로젝트가 추가될 때 마다 설정해야 하는 인프라 관리의 문제, 서버 코드를 각각의 서버에 개별 전송해야 하는 코드 배포의 문제가 지속적으로 발생하고 있다.
본 발명은 상술한 문제점을 모두 해결하는 것을 그 목적으로 한다.
또한, 본 발명은, 게임 개발자의 보다 편리한 게임 개발을 위한 BaaS(Backend as a Service)를 제공하는 것을 다른 목적으로 한다.
또한, 본 발명은, 게임 개발을 위한 미리 생성된 API(application programming interface) 서버를 제공하여 게임 개발자들이 보다 편리하게 적은 인적/물적 자원으로 게임을 개발할 수 있도록 하는 것을 다른 목적으로 한다.
또한, 본 발명은, 테넌트별로 오토 스케일링 호출 규칙을 시스템이 자동으로 설정하여 테넌트별로 최소한의 운영 데이터만으로 테넌트별 오토 스케일링 호출 규칙을 생성하고, 또한 테넌트별 오토 스케일링 호출 규칙을 자동으로 수행하는 것을 다른 목적으로 한다.
상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.
본 발명의 일 태양에 따르면, 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법은 클라우드 기반의 멀티 테넌시 환경에서 동작하는 BaaS(backend as a service) 관리 서버가 복수의 테넌트로부터 게임 API(application programing interface) 서버에 대한 요청을 수신하는 단계와 상기 BaaS 관리 서버가 상기 요청에 따라 상기 게임 API 서버를 제공하는 단계를 포함하되, 상기 복수의 테넌트는 상기 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받을 수 있다.
본 발명의 다른 태양에 따르면, 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙을 자동 생성하는 BaaS(backend as a service) 관리 서버는 복수의 테넌트와의 통신을 위해 구현되는 통신부와 상기 통신부와 동작 가능하게(operatively) 연결된 프로세서를 포함하되, 상기 프로세서는 클라우드 기반의 멀티 테넌시 환경에서 상기 복수의 테넌트로부터 게임 API(application programing interface) 서버에 대한 요청을 수신하고, 상기 요청에 따라 상기 게임 API 서버를 제공하도록 구현될 수 있되, 상기 복수의 테넌트는 상기 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받을 수 있다.
본 발명에 의하면, 게임 개발자의 보다 편리한 게임 개발을 위한 BaaS가 제공될 수 있다.
또한, 게임 개발을 위한 미리 생성된 API를 제공하여 게임 개발자들이 보다 편리하게 적은 인적/물적 자원으로 게임을 개발할 수 있도록 할 수 있다.
또한, 테넌트별로 오토 스케일링 호출 규칙을 시스템이 자동으로 설정하여 테넌트별로 최소한의 운영 데이터만으로 테넌트별 오토 스케일링 호출 규칙을 생성하고, 테넌트별 오토 스케일링 호출 규칙을 자동으로 수행하는 것을 다른 목적으로 한다.
도 1은 기존의 백엔드 서버에 대한 개발 방식을 나타낸 개념도이다.
도 2는 본 발명의 실시예에 따른 게임 BaaS를 나타낸 개념도이다.
도 3은 본 발명의 실시예에 따른 클라우드 기반으로 게임 API 서버를 제공하는 방법을 나타낸 개념도이다.
도 4는 본 발명의 실시예에 따른 게임 API 서버를 통한 서비스 제공 방법을 나타낸 개념도이다.
도 5는 본 발명의 실시예에 따른 모바일 게임 서버에 특화된 트래픽 수요 예측 방법을 나타낸 개념도이다.
도 6은 본 발명의 실시예에 따른 게임 API 서버 운영 방법을 나타낸 개념도이다.
도 7은 본 발명의 실시예에 따른 BaaS 관리 서버의 구조를 나타낸 개념도이다.
도 8은 본 발명의 실시예에 따른 BaaS의 동작을 나타낸 개념도이다.
도 9는 본 발명의 실시예에 따른 BaaS 관리 서버의 동작을 나타낸 개념도이다.
도 10은 본 발명의 실시예에 따른 BaaS 관리 서버의 동작을 나타낸 개념도이다.
도 11은 본 발명의 실시예에 따른 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법을 나타낸 개념도이다.
도 12는 본 발명의 실시예에 따른 테넌트별 오토 스케일링 호출 규칙을 자동으로 설정하는 방법을 나타낸 개념도이다.
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여 지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다.
이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 바람직한 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.
모바일 게임은 디바이스에 설치되는 앱(APP, application)과 눈으로 보이지 않는 기능을 담당하는 백엔드 API(application programming interface) 서버를 기반으로 구동될 수 있다. 모바일 게임을 위한 백엔드 API 서버에는 게임의 장르, 규모와 관계없이 회원가입/로그인/아이템/차트/랭킹/캐릭터/랭킹/레벨 등의 비슷한 기능이 존재한다. 이런 특성 덕분에 모바일 게임 서버의 제작 과정은 표준화/자동화가 가능하다.
BaaS(Backend as a Service)는 자주 사용되는 서버 기능들을 클라우드 API 형태로 제공하여 매번 따로 개발하지 않고 쉽게 이용 가능하도록 도와주는 서비스이다. 게임 서버 BaaS를 이용해서 게임을 제작하면 제작 기간과 비용을 대폭 절감할 수 있다. 게임 서버 BaaS를 도입하면 제작 인원의 축소를 통한 비용 절감과 개발 기간 단축이라는 두 마리 토끼를 잡을 수 있다. 또한 이렇게 절약한 리소스를 게임 제작에 추가 투입하여 더욱 수준 높은 게임을 만들 수 있다.
본 발명의 실시예에 따른 게임 서버 BaaS는 ① 게임 API 서버 자동 제작 기능, ②서버 자동 확장(Auto Scaling), ③게임 관리 기능 등을 제공할 수 있다. 본 발명의 실시예에 따른 게임 서버 BaaS는 원 클릭만으로 일정 시간 이내에 게임 개발자들을 위한 게임 API 서버를 생성 및 제공할 수 있다. 이를 통해 국내의 게임 개발사들은 게임 제작 기간과 비용이 줄어들 수 있고 줄어든 제작 기간과 비용을 다른 개발에 투자하여 양질의 게임을 생성할 수 있다.
도 1은 기존의 백엔드 서버에 대한 개발 방식을 나타낸 개념도이다.
도 1을 참조하면, 기존의 게임 개발자들은 게임에 사용되는 채팅 기능, 데이터베이스 기능, 랭킹 기능 등을 위해 별도의 벡엔드 API 서버를 자체적으로 개발하고 있었다. 이러한 벡엔드 API 서버에 대한 자체 개발은 게임의 개발 기간을 길어지게 하고 있다. 또한 별도의 자체 벡엔드 API 서버에 대한 관리로 인해 관리의 부담이 늘어나고 있다.
도 2는 본 발명의 실시예에 따른 게임 BaaS를 나타낸 개념도이다.
도 2를 참조하면, 본 발명의 실시예에 따른 게임 BaaS는 게임에서 사용되는 게임API를 제공하는 벡엔드 서버를 클라우드 서버 상에서 원클릭으로 게임 개발자들에게 제공할 수 있다.
모바일 게임은 디바이스에 설치되는 앱(App) 및 회원가입, 로그인, 아이템 구매 기능 등을 담당하는 게임 API 서버를 기반으로 동작할 수 있다.
모바일 게임을 구현하기 위해 공통적으로 요구되는 기능으로 회원가입/로그인/아이템/차트/랭킹/캐릭터/아이템 등의 표준화된 기능이 존재할 수 있다. 이러한 기능들을 위한 게임 API 서버는 게임의 장르, 규모와 관계 없이 표준화된 기능으로 구성되어 자동화가 가능하다. 본 발명의 실시예에 따른 게임 BaaS는 게임 장르 / 연동 SNS / 아이템 형태 / 캐릭터 유형 / 랭킹 유형 등에 따라 통합된 DB(database)와 게임 API 서버를 자동 생성/제공할 수 있다.
본 발명의 실시예에 따르면, 복수의 게임 서버로 서비스를 제공하는 멀티 테넌시(multi-tenancy) 환경의 클라우드 서비스일 수 있고, 테넌트별로 서비스를 제공할 수 있다.
기존의 경우, 게임 개발자들이 별도의 게임 API 서버를 제작하는 단계를 거쳤다면, 본 발명의 실시예에 따른 게임 BaaS는 별도의 게임 API 서버 제작 단계를 거치지 않고 바로 게임 앱을 개발할 수 있다.
도 3은 본 발명의 실시예에 따른 클라우드 기반으로 게임 API 서버를 제공하는 방법을 나타낸 개념도이다.
도 3에서는 게임 BaaS를 위한 네트워크가 개시된다.
도 3을 참조하면, BaaS 관리 서버는 클라우드 기반 멀티 테넌시(multi-tenancy) 환경에서 각각의 테넌트(예를 들어, 게임 서버)와 연동되어 게임 API 서버를 제공할 수 있다.
게임 API 서버에는 게임 개발자들이 활용 가능한 API들이 구현되어 있다. 게임 개발자들은 게임 API 서버에 구현된 제공 가능한 API들 중 게임에 필요한 API를 선택적으로 활용하여 게임을 구현할 수 있다.
BaaS 관리 서버는 미리 제공가능한 모든 API가 구현된 게임 API 서버를 게임 개발자에게 제공할 수도 있고, 게임 개발자가 필요로 하는 API만이 구현된 게임 API 서버를 게임 개발자에게 제공할 수도 있다.
또한, BaaS 관리 서버는 게임의 수행을 위해 제공된 API 서버에 걸리는 부하를 체크하여 게임 API 서버에 대한 스케일 업(scale up)/스케일 아웃(scale out)을 수행할 수 있다. 본 발명의 실시예에 따른 BaaS 관리 서버는 별도의 예측부 또는 예측 서버를 통해 게임 API 서버의 부하(예를 들어, CPU(central processing unit) 부하, 메모리 부하 등)를 예측할 수 있다. BaaS 관리 서버의 예측부(또는 별도의 예측 서버)는 게임 API 서버의 부하를 예측하기 위해 실제 게임 개발자에게 제공되는 게임 API 서버가 아닌 별도의 게임 API 서버를 기반으로 부하 예측을 수행할 수 있다.
본 발명과 같이 복수의 클라이언트(게임 서버)로 서비스를 제공하는 멀티 테넌시(multi-tenancy) 환경의 클라우드 서비스는 테넌트별로 트래픽 조절이 필요하다. 트래픽 조절은 오토 스케일링으로 어느정도 대처가 가능하나, 오토 스케일링의 호출 규칙은 운영 데이터를 축적한 이후에만 생성이 가능한 문제가 있다. 테넌트는 본 발명의 실시예에 따른 BaaS 관리 서버에 의해 서비스되는 게임 서버일 수 있다. 본 발명의 실시예에 따른 BaaS 관리 서버는 복수의 테넌트로 서비스를 제공하는 멀티 테넌시 환경의 클라우드 서비스를 제공할 수 있다.
또한, 게임 BaaS 는 보다 간단하게 어플리케이션과 게임 API 서버의 연결을 위한 SDK(software development kit)이 제공되어 기존의 어플리케이션과 게임 API 서버와의 연결을 위한 복잡한 코드(예를 들어, 100줄) 대신 간단한 코드(예를 들어, 2줄)를 통해 어플리케이션과 게임 API 서버 간의 연결이 수행될 수 있다. SDK를 통해
본 발명의 실시예에 따른 BaaS 기반의 멀티 테넌시 서비스는 IaC(Infrastructure as Code)로 구성된 서버 인프라와 REST(Representational　State　Transfer) API, 클라이언트용 SDK로 구성되고, REST API는 백엔드와 클라이언트 간의 인터페이스를 담당하며 SDK에서 REST API로 접근하는 시점과 횟수 등의 지표를 수집할 수 있다.
도 4는 본 발명의 실시예에 따른 게임 API 서버를 통한 서비스 제공 방법을 나타낸 개념도이다.
도 4에서는 게임 개발자 장치에서 BaaS 관리 서버에 의해 제공된 게임 API 서버를 기반으로 게임 상에서 필요한 기능을 구현하는 방법이 개시된다.
도 4를 참조하면, 게임 개발자 장치(또는 게임 서버)는 개발하고자 하는 게임의 프로젝트 이름을 설정하고, 게임의 프로젝트 유형을 선택할 수 있다. 예를 들어, 게임 개발자가 스포츠 게임을 개발하고자 하는 경우, 프로젝트 유형으로 스포츠 게임이 선택될 수 있다.
또한, 게임 개발자 장치는 BaaS 관리 서버에 의해 제공되는 게임 API 서버 중 캐릭터API 서버, 스킬API 서버, 아이템API 서버 등을 선택할 수 있다. 기존의 게임 개발자의 경우, 게임을 개발시 게임에서 사용되는 캐릭터, 스킬, 아이템 등의 개발/구현을 위한 별도의 벡엔드 API 서버를 설정하고, 별도로 캐릭터, 스킬, 아이템을 위한 기능을 개발하였다.
하지만, 본 발명의 실시예에 따른 게임 API 서버는 스포츠 게임의 캐릭터, 스킬, 아이템 등의 개발/설정을 위한 캐릭터 API 서버, 스킬 API 서버, 아이템 API 서버를 포함하고, 게임 개발자는 필요한 API 서버를 선택적으로 활용할 수 있다. 게임 개발자는 게임 상에서 사용될 캐릭터, 스킬, 아이템 등의 기능을 위한 별도의 벡엔드 API 서버의 설정 및 캐릭터, 스킬, 아이템을 위한 기능 개발을 할 필요가 없이 게임 API 서버에 포함되는 캐릭터 API 서버, 스킬 API 서버, 아이템 API 서버를 통해 게임에 사용될 캐릭터, 스킬, 아이템의 특성을 설정해줌으로써 간단하게 게임을 위한 캐릭터, 스킬, 아이템을 개발할 수 있다. 이러한 게임 API 서버는 게임 API 서버 그룹으로 그룹핑하여 제공될 수도 있다.
또한, 게임 개발자 장치를 통해 서버의 상태, 서버의 자동 확장 여부 등이 추가로 설정될 수 있다.
좌측을 참조하면, 게임 BaaS는 이벤트 관리 기능, 게임 정보 관리 기능, 유지관리 기능, 푸시 발송 기능, 오류 보고서 기능, 게임 로그 기능, 랭킹 관리 기능, 서버 설정 기능 등을 제공할 수 있다.
예를 들어, 게임 정보 관리 기능을 통해 게임과 관련된 캐릭터, 스킬, 아이템 등의 개발을 위한 게임 API 서버가 제공될 수 있다. 푸쉬 발송 기능을 통해 게임 유저들에게 푸시 발송을 위한 게임 API 서버가 제공될 수 있다. 또한, 게임 로그 기능을 통해 소셜 로그인을 위한 게임 API 서버가 제공될 수 있다. 이뿐만 아니라, 공지 관리 기능, 회원 관리 기능 등을 위한 게임 API 서버가 BaaS를 통해 제공될 수 있다.
도 5는 본 발명의 실시예에 따른 모바일 게임 서버에 특화된 트래픽 수요 예측 방법을 나타낸 개념도이다.
도 5를 참조하면, 게임 BaaS는 요일 별 트래픽을 분류한 후 패턴에 대한 검색을 수행할 수 있다. Intelligence Load Balancer(이하 ILB)가 적용된 모바일 게임 서버는 별도의 측정, 분석 과정을 진행하지 않아도 자동 서버 확장 기능(Scale Out)을 적용할 수 있다.
모바일 게임은 트래픽이 분산되지 않고, 특정 기간에 집중되는 특징을 보인다. ILB는 미리 정의된 이벤트 달력을 활용해 비정상적인 트래픽 발생에 선제 대응할 수 있다. ILB를 활용하는 모바일 게임 서버는 트래픽 폭증 상황에서도 자동 서버 확장으로 중단 없이 운영이 가능하다. ILB는 게임 API 서버에 대한 자동 스케일 업(AutoScale Up)과 자동 스케일 아웃(AutoScale Out)을 자동으로 수행할 수 있다.
도 6은 본 발명의 실시예에 따른 게임 API 서버 운영 방법을 나타낸 개념도이다.
기존의 경우, 물리적 서버 확장(Scale Out)을 지원하는 모바일 게임 서버를 구축하기 위해서는 단일 서버, 스케일 업(Scale Up), 스케일 아웃(Scale Out) 환경을 모두 경험한 고급 서버 인력이 요구된다. 그러나 스케일 아웃 서버 구축 경험을 보유한 고급 기술 인력은 전체 서버 개발 인력 중 극소수이며, 이로 인해 중규모 이하의 게임 개발사는 스케일 아웃(Scale Out)을 구성하지 못하며, 서버 장애에 적극적으로 대응하지 못하고 있다. 이로 인해 게임의 성공 시점부터(동접 10,000명 이상/단일 서버 대응 불가) 서버 장애가 발생해 서비스가 실패하는 모순적인 상황이 발생하고 있다.
본 발명의 실시예에 따른 게임 BaaS는 게임 장르/정형화된 트래픽 패턴으로 Scale Out룰을 설정해 고급 기술인력 없는 Scale Out사용을 지원할 수 있다.
이하, 본 발명의 실시예에서는 구체적인 BaaS 구조와 BaaS의 동작이 개시된다.
도 7은 본 발명의 실시예에 따른 BaaS 관리 서버의 구조를 나타낸 개념도이다.
도 7을 참조하면, BaaS 관리 서버는 복수의 계층 구조를 가질 수 있다. 복수의 계층 구조는 비즈니스 레이어(businesslayer)(700), 캐시 레이어(cache layer)(710), 퍼시스턴스 레이어(persistence layer)(720), 분석 레이어(analysis layer)(730)를 포함할 수 있다.
비즈니스 레이어(700)는 복수의 게임 API 서버를 포함할 수 있다. 복수의 게임 API 서버는 게임 개발자들이 사용하는 기능을 제공하기 위한 서버일 수 있다. 예를 들어, 복수의 게임 API 서버는 회원가입 API 서버, 로그인 API 서버, 아이템 API 서버, 캐릭터 API 서버 등을 포함할 수 있다. BaaS를 이용하는 게임 개발자 장치 및/또는 게임 서버(이하, 게임 서버)는 복수의 API 서버 중 적어도 하나의 API 서버와 연동하여 게임에서 필요한 기능을 사용자 장치로 제공할 수 있다. BaaS관리 서버에서 게임 서버로 제공되는 SDK(software development kit)를 기반으로 게임 개발자는 BaaS관리 서버에서 제공되는 복수의 게임 API 서버를 활용할 수 있다.
BaaS 관리 서버는 회원 가입, 로그인, 아이템, 차트, 랭킹, 결제 등과 표준화된 기능을 도커 이미지(docker image)로 만들어 템플릿으로 활용할 수 이다. 신규 게임 서버 생성시 저장된 도커 이미지는 호출된 서버에 배포되어, 게임 서버의 생성과 동시에 게임 API 서버가 활성화될 수 있다.
게임 서버에서 복수의 게임 API 서버 각각을 통해 전송되는 정보는 캐시 레이어(710) 및/또는 퍼시스턴스 레이어(720)와 같은 데이터 저장 계층에 저장될 수 있다. 예를 들어, 게임 서버가 BaaS관리 서버에 포함되는 로그인 API 서버를 통해 사용자 로그인 기능을 제공받는 경우, 사용자 로그인 정보가 게임 API 서버를 통해 캐시 레이어(710) 및/또는 퍼시스턴스 레이어(720)에 저장될 수 있다. 게임 API 서버는 필요에 따라 캐시 레이어(710) 및/또는 퍼시스턴스 레이어(720)에 저장된 데이터를 호출할 수 있고, 캐시 레이어(710) 및/또는 퍼시스턴스 레이어(720)는 호출된 데이터를 게임 API 서버로 제공할 수 있다.
캐시 레이어(710)는 메모리 맵(memory map) 기반의 고속 API 조회 기능을 제공할 수 있다. 캐시 레이어(710)는 복수의 API 서버를 통해 빈번하게 호출되는 데이터를 저장하기 위해 구현될 수 있다. 캐시 레이어(710)는 퍼시스턴스 레이어(720)에서 저장/관리되는 데이터 중 빠른 처리가 필요하거나 빈번하게 호출되는 데이터를 저장할 수 있다.
퍼시스턴스 레이어(720)는 데이터 처리(데이터의 생성/수정/삭제/선택(검색))를 담당하는 계층이다. 퍼시스턴스 레이어(720)는 복수의 API 서버의 동작을 위한 데이터 저장/관리를 위해 구현될 수 있다.
아래의 표1은 퍼시스턴스 레이어(720)와 캐시 레이어(710) 각각의 스토리지 솔루션과 타입을 예시적으로 나타낸 표이다.
레이어Layer 스토리지 솔루션Storage Solution 타입Type 사용 용도
Persistent MariaDB RDBMS 결제, 회원 정보 관리정형 데이터 관리ACID Transaction
DynamoDB NoSQL 게임 데이터 관리BASE Transaction수평적 확장
Elastic Search NoSQLSearch Engine 로그 데이터 관리비정형 데이터 분석
Cache Redis in-Memory Store 캐싱 데이터 관리
분석 레이어(730)는 BaaS관리 서버의 상태 분석을 통해 비즈니스 레이어(700), 캐시 레이어(710), 퍼시스턴스 레이어(720)의 동작에 대한 관리를 위해 구현될 수 있다.
분석 레이어(730)는 복수의 게임 API 서버의 부하 밸런싱을 위한 ILB(Intelligence Load Balancer)로서의 역할을 수행할 수 있다. 분석 레이어(730)는 일정 기간(예를 들어, 요일/시간)별 트래픽을 수집해 오토 스케일(AutoScale) 호출 규칙을 동적으로 생성한다. 게임 서버 운영자는 고급 서버 관리 인력 없이도 오토 스케일(AutoScale) 환경을 이용할 수 있으며, ILB가 적용된 모바일 게임 서버는 트래픽 폭증 상황에서도 중단 없이 운영될 수 있다.
또한, 분석 레이어(730)는 캐시 레이어(710)에서 저장/관리될 데이터, 퍼시스턴스 레이어(720)에서 저장/관리될 데이터를 결정하고, 캐시 레이어(710) 및/또는 퍼시스턴스 레이어(720) 상에서 데이터에 대한 저장/관리를 수행할 수 이다.
도 8은 본 발명의 실시예에 따른 BaaS의 동작을 나타낸 개념도이다.
도 8에서는 게임 서버와 연동될 복수의 게임 API 서버에 대한 관리 방법이 개시된다.
도 8을 참조하면, 게임 서버(810, 820, 830)가 BaaS를 요청하는 경우, 복수의 게임 API 서버가 게임 서버(810, 820, 830)와 연동되어 동작할 수 있다. BaaS는 복수의 게임 각각을 위한 복수의 게임 서버(810, 820, 830)와 연동되어 동작할 수 있고, BaaS에 의해 제공되는 복수의 게임 API 서버는 게임 서버(810, 820, 830)와 매칭될 수 있다.
복수의 게임 API 서버는 다양한 방식으로 게임 서버와 대응될 수 있다.
예를 들어, 복수의 게임 API 서버가 게임 API 서버 그룹 각각(850, 860)으로 그룹핑되고, 게임 API 서버 그룹(850, 860)은 적어도 하나의 게임 서버(810, 820, 830)와 매칭될 수 있다. 하나의 게임 API 서버 그룹(850, 860)은 BaaS에서 제공되는 모든 API 들의 집합일 수 있다. 예를 들어 하나의 게임 API 서버 그룹(850, 860)은 회원 가입 API, 로그인 API, 아이템 API, 차트 API, 랭킹 API, 결제 API 등을 포함할 수 있다.
예를 들어, 게임 서버1(810)에 의해 요구되는 처리량이 하나의 게임 API 서버 그룹1(850)을 통해 처리 가능한 임계 처리량을 넘어가는 경우, 다른 복수의 게임 API 서버 그룹2(860)이 게임 서버1(810)과 추가적으로 매칭되어 게임 서버1(810)에 의해 요구되는 처리량을 만족시킬 수 있다.
반대로, 게임 서버1(810)에 의해 요구되는 처리량이 하나의 게임 API 서버 그룹1(850)을 통해 처리 가능한 임계 처리량보다 작은 경우, BaaS 관리 서버를 기반으로 서비스를 제공받는 다른 게임 서버(820)가 게임 서버1(810)과 동일한 게임 API 서버 그룹1(850)을 사용하여 서비스를 제공받을 수 있다. 즉, 하나의 게임 API 서버 그룹1(850)이 복수의 서로 다른 게임 서버(810, 820)로 서비스를 제공할 수 있다.
위와 같은 방식으로 복수의 게임 API 서버 그룹의 처리량을 고려하여 서버 확장/서버 축소와 같은 스케일링이 수행할 수 있다. 분석 레이어는 게임 서버에 의해 요구되는 처리량에 대한 분석을 통해 게임 API 서버 그룹과 게임 서버 간의 매칭 관계를 설정하여 서버 확장, 서버 유지 또는 서버 축소와 같은 서버에 대한 스케일링 여부를 결정하고, 서버 스케일링을 수행할 수 있다.
도 9는 본 발명의 실시예에 따른 BaaS 관리 서버의 동작을 나타낸 개념도이다.
도 9에서는 게임 서버와 연동될 복수의 게임 API 서버에 대한 관리 방법이 개시된다.
도 9를 참조하면, BaaS로서 제공되는 복수의 게임 API 서버 중 적어도 하나의 게임 API 서버가 분리되고, 분리된 적어도 하나의 게임 API서버를 기반으로 BaaS가 게임 서버로 제공될 수 있다.
분석 레이어의 분석 결과, 비즈니스 레이어에 포함되는 복수의 게임 API 서버 중 처리량이 많은 게임 API 서버에 대한 분리가 진행될 수 있고, 분리된 게임 API 서버에 별도의 서버 자원에 대한 할당 및 서버 자원에 대한 관리가 수행되어 BaaS가 제공될 수 있다.
예를 들어, 분석 레이어의 분석 결과, 게임 API 서버 그룹(900)에 포함되는 회원 가입 API, 로그인 API, 아이템 API, 차트 API, 랭킹 API, 결제 API 중 로그인 API 처리량이 임계 처리량 이상일 수 있다. 이러한 경우, 로그인 API(920)는 게임 API 서버 그룹(900)에서 분리되어 분리 게임 API 서버 그룹(950)으로 관리될 수 있다.
분석 레이어는 분리 게임 API 서버 그룹(950)에 대해 별도의 서버 스케일링을 적용하여 게임 서버에 서비스를 제공할 수 있다. 예를 들어, 게임 서버1 및 게임 서버2는 게임 API 서버 그룹1을 통해 회원 가입 API, 로그인 API, 아이템 API, 차트 API, 랭킹 API, 결제 API 기능을 제공받을 수 있고, 게임 서버1 및 게임 서버2에서 요구되는 처리량에 따라 게임 API 서버 그룹1에 할당되는 서버가 확장 또는 감소될 수 있다.
게임 서버1은 분리 API 서버 그룹1을 통해 로그인 API 기능을 제공받을 수 있고, 게임 서버2는 별도의 분리 API 서버 그룹2를 통해 로그인 API 기능을 제공받을 수 있다. 게임 서버1에서 요구되는 로그인 관련 처리량에 따라 분리 API 서버 그룹1에 포함되는 서버의 스케일링이 수행될 수 있다. 게임 서버2에서 요구되는 로그인 관련 처리량에 따라 분리 API 서버 그룹2에 포함되는 서버의 확장/축소가 수행될 수 있다.
즉, 분리 레이어의 결정에 따라 게임 API 서버 그룹에 포함되는 복수의 게임 API 서버 중 적어도 하나의 게임 API 서버에 대한 별도 분리가 진행될 수 있다. 게임API 서버 그룹과 분리 게임 API 서버 그룹은 별도의 서버 스케일링이 적용될 수 있다.
도 10은 본 발명의 실시예에 따른 BaaS 관리 서버의 동작을 나타낸 개념도이다.
도 10에서는 게임 서버와 연동될 복수의 게임 API 서버에 대한 관리 방법이 개시된다. 특히, 시간에 따른 복수의 게임 API 서버 관리 방법이 개시된다.
도 10을 참조하면, BaaS 관리 서버는 시간에 따른 복수의 게임 API 서버 각각의 처리량을 수집하고 시간에 따른 복수의 게임 API 서버 각각의 처리량을 예측하여 복수의 게임 API 서버를 그룹핑할 수 있다.
BaaS 관리 서버는 복수의 게임 서버와 매칭되는 복수의 게임 API 서버 그룹과 복수의 게임 API 서버 그룹에 포함되는 복수의 게임 API 서버 각각에 대한 시간대별 처리량 분석을 수행할 수 있다. 이하에서 API 서버는 게임 API 서버를 의미할 수 있다.
제1 게임 API 서버 그룹(1010)은 제1 API 서버1(1013), 제1 API 서버2(1016), 제1 API 서버3(1019)를 포함할 수 있다.
제2 게임 API 서버 그룹(1020)은 제2 API 서버1(1023), 제2 API 서버2(1026), 제2 API 서버3(1029)을 포함할 수 있다.
제3 게임 API 서버 그룹(1030)은 제3 API 서버1(1033), 제3 API 서버2(1036), 제3 API 서버3(1039)을 포함할 수 있다.
예를 들어, API 서버1(1013, 1023, 1033)은 로그인 서버, API 서버2(1016, 1026, 1036)는 회원가입 서버, API 서버3(1019, 1029, 1039)은 아이템 서버일 수 있다.
시간에 따른 처리량을 고려하여 (제1 API 서버1(1013), 제1 API 서버2(1016), 제1 API 서버3(1019)), (제2 API 서버1(1023), 제2 API 서버2(1026), 제2 API 서버3(1029)), (제3 API 서버1(1033), 제3 API 서버2(1036), 제3 API 서버3(1039)) 각각이 적응적으로 그룹핑될 수 있다.
전체 시간은 복수의 시간 구간으로 분할될 수 있고, 복수의 시간 구간에 따라 게임 API 서버 그룹이 변화될 수 있다.
제1 시간에 (제1 API 서버1(10)(1013), 제1 API 서버2(20)(1016), 제1 API 서버3(30)(1019)), (제2 API 서버1(30)(1023), 제2 API 서버2(10)(1026), 제2 API 서버3(20)(1029)), (제3 API 서버1(50)(1033), 제3 API 서버2(10)(1036), 제3 API 서버3(10)(1039))의 처리량이 필요한 경우가 가정될 수 있다. 서버 옆의 괄호는 처리량을 수치로서 임의적으로 표현한 것이다.
위와 같은 경우, 제1 API 서버1(10)(1013), 제2 API 서버1(30)(1023), 제2 API 서버2(10)(1026), 제3 API 서버1(50)(1033)이 제1' 게임 API 서버 그룹'(1050)로 설정되고, 제1 API 서버2(20)(1016), 제1 API 서버3(30)(1019), 제2 API 서버3(20)(1029), 제3 API 서버2(10)(1036), 제3 API 서버3(10)(1039)이 제2' 게임 API 그룹(1050)으로 설정되어 게임 서버의 요청을 처리할 수 있다.
위와 같이 시간에 따른 게임 API 서버 별 필요 처리량을 고려하여 적응적으로 게임 API 그룹을 재그룹핑할 수 있고, 그에 따라 필요한 서버 자원의 양을 감소시키면서 효율적으로 서버 스케일링이 수행될 수 있다.
도 11은 본 발명의 실시예에 따른 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법을 나타낸 개념도이다.
도 11을 참조하면, 본 발명과 같이 복수의 클라이언트(게임 서버)로 서비스를 제공하는 멀티 테넌시 환경의 클라우드 서비스(1100)는 복수의 테넌트(1110, 1120, 1150) 각각에 대한 적응적인 트래픽 조절이 필요하다. 테넌트(1110, 1120, 1150)는 본 발명의 실시예에 따른 BaaS 관리 서버에 의해 서비스되는 게임 서버일 수 있다. 트래픽 조절은 기존의 오토 스케일링으로 어느정도 대처가 가능하나, 현재의 오토 스케일링의 호출 규칙은 운영 데이터의 축적 이후 사람에 의해 설정되어 생성이 되고 있다. 즉, 멀티 테넌시 환경의 클라우드 서비스(1100)에서는 운영 데이터가 충분히 축적될 때까지 오토 스케일링이 정상적으로 동작하지 않을 수 있고 사람의 판단으로 인한 오토 스케일링 호출 규칙의 설정은 결과적으로 각각의 테넌트(1110, 1120, 1150)의 서비스 초기에 트래픽 확장에 정상적으로 대응할 수 없다.
테넌트(1110, 1120, 1150)의 서비스 성격에 따라 요일, 시간 등 트래픽 운영 데이터는 서로 상이하기 때문에 이미 만들어진 오토 스케일링 호출 규칙을 재활용하는 것도 어렵다. 또한, 오토 스케일링 호출 규칙은 인간의 경험에 기반하기 때문에, 사람이 직접 설정해야 하는 문제가 있다. 이러한 이유들로 인해, 멀티 테넌시 클라우드 서버를 사용하는 테넌트(1110, 1120, 1150)는 서비스 초기에 발생하는 트래픽 장애에 적극적으로 대응할 수 없다.
본 발명의 실시예에 따른 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법에서는 최소한의 운영 데이터 만으로 테넌트별 오토 스케일링 호출 규칙을 생성하고, 또한 오토 스케일링 호출 규칙을 자동으로 수행하는 것을 목표로 한다.
멀티 테넌시 환경에서, 각 테넌트(1110, 1120, 1150)는 멀티 테넌시 사업자(BaaS 제공자)가 제공하는 아키텍처와 인터페이스로 자신의 서비스를 운영한다. 이는 테넌트(1110, 1120, 1150) 간의 서비스가 다르더라도 사용하는 백엔드 인프라와 인터페이스가 동일함을 의미할 수 있다.
따라서, 개별 테넌트(1110, 1120, 1150)가 사용하는 인터페이스 별 호출 시점, 호출 횟수 등을 수집하면 패턴화하는 것이 가능하다. 테넌트(1110, 1120, 1150) 별로 자주 호출하는 인터페이스에서 트래픽이 몰리는 요일과 시간 정보 등의 운영 데이터를 수집하고　규칙을 찾는 것이다. 전술한 바와 같이 BaaS 기반의 멀티 테넌시 서비스는 IaC(Infrastructure as Code)로 구성된 서버 인프라와 REST API, 클라이언트용 SDK로 구성될 수 있다. 이 중 REST API가 백엔드와 클라이언트 간의 인터페이스를 담당하며 SDK에서 REST API로 접근하는 시점과 횟수 등의 지표를 수집할 수 있다. REST API는 비즈니스 레이어에 포함될 수 있다.
분석 레이어는 테넌트(1110, 1120, 1150) 별로 운영 데이터를 수집하고 규칙을 생성할 수 있다. 분석 레이어는 유연하게 확장 가능한 데이터 저장소, 운영 데이터를 수집하는 로그 수집기, 수집한 운영 데이터를 분석하고 규칙으로 출력하는 데이터 시각화 도구를 포함할 수 있다. 분석 레이어 상에서 먼저 테넌트(1110, 1120, 1150) 별 운영 데이터를 데이터 저장소에 수집할 수 있다. 운영 데이터의 수집은 분석 레이어의 로그 수집기가 담당하며, 멀티 테넌트를 위한 IaC 인프라에 로그 수집기를 미리 내장하여 수집을 진행할 수 있다. 로그 수집기에 의해 수집되는 데이터는 인터페이스 호출 시간(YYMMDDHHMM)과 호출한 인터페이스, 인터페이스에 전달되는 파라미터 이다.
이 중 가장 중요한 것은 호출 시간 데이터이다. 호출 시간은 분 단위로 수집될 수 있다. 오토 스케일이 수행되는 시간이 수 분 단위이기 때문에 초 또는 마이크로 초 단위의 운영 데이터를 수집하는 것은, 오토 스케일링 규칙 생성의 목적에 부합하지 않으며 컴퓨팅 파워의 낭비 요인이 될 수 있다.
운영 데이터는 개별 테넌트 별 데이터와 다중 테넌트 별 데이터로 구분할 수 있다. 개별 테넌트 별 데이터는 개별 테넌트와 관련된 운영 데이터이고, 다중 테넌트 별 데이터는 다중 테넌트와 관련된 운영 데이터일 수 있다.
개별 테넌트의 주요 운영 데이터는 요일별 트래픽 정보, 시간별 트래픽 정보, 이벤트별 트래픽 정보를 포함할 수 있다.
요일별 트래픽 정보는 요일별 트래픽에 대한 정보를 포함할 수 있다. 모든 서비스는 서비스의 특성에 따라 요일별 트래픽이 상이하다. 서비스별 요일별 트래픽 정보 검색, 등록 요청을 통해 요일별 트래픽 추이에 대한 정보가 수집될 수 있다.
시간대별 트래픽 정보는 시간대별 트래픽에 대한 정보를 포함할 수 있다. 서비스의 특성에 따라 시간대별 트래픽 추이는 상이하며, 특정 시간대에 90% 이상의 트래픽이 몰리는 서비스도 존재 한다. 이러한 유형의 서비스를 제공하는 테넌트(1110, 1120, 1150)는 멀티 테넌시 환경에서 트래픽 관리를 하는 것이 매우 어렵다. 따라서, 시간대별 트래픽 추이 정보 검색, 등록 요청을 통해 시간대별 트래픽 추이에 대한 정보가 수집될 수 있다.
이벤트별 트래픽 정보는 이벤트별 트래픽에 대한 정보를 포함할 수 있다. 게임 서비스를 예로 들면 방학 시즌에 트래픽이 급증하는 패턴을 보이고 웹툰 서비스는 어린이날, 크리스마스 등 공휴일에 트래픽이 증가하는 패턴을 보일 수 있다. 서비스를 제공하는 지역의 공휴일, 방학 등 시간에 영향을 주는 특징을 '이벤트'로 통칭하여 부르며, 이벤트 정보는 국가별로 다를 수 있다. 이러한 이벤트 정보를 데이터 시각화 도구에 등록하면 이벤트별 트래픽을 분석할 수 있다.
분석 레이어는 요일별 트래픽 정보, 시간별 트래픽 정보, 이벤트별 트래픽 정보를 분석하여 트래픽 패턴을 정의하고 오토 스케일링 호출 규칙을 설정할 수 있다. 정의된 트래픽 패턴 정보에 따라 설정된 오토 스케일링 호출 규칙은 오토 스케일링 호출 규칙 시스템이 접근해 사용할 수 있는 퍼시스턴트 레이어의 관계형 데이터베이스 등에 저장할 수 있다.
본 발명의 실시예에 따르면, 요일별 트래픽 정보 및 시간별 정보를 기반으로 아래와 같이 트래픽 패턴이 정의되고, 오토 스케일링 호출 규칙이 설정될 수 있다.
우선 게임 API 서버 그룹에 포함되는 복수의 게임 API 서버 각각에 대한 게임 API 서버 호출 기록이 수집될 수 있다. 게임 API 서버 호출 기록은 시간(년/월/일/시간/분, YYMMDD HH:MM), 호출한 URL(uniform resource locator), 전달된 파라미터에 대한 정보를 포함할 수 있다.
1일 단위 집계의 종료 후 게임 API 호출 기록을 기반으로 분 단위로 호출 수가 집계될 수 있다. 예를 들어, 로그인 API 서버에 대해 하루가 분 단위로 분할되어 분 단위 호출 수가 집계될 수 있다. 즉, 복수의 게임 API 서버 각각에 대한 API 호출 기록을 기반으로 복수의 게임 API 서버 각각에 대한 분 단위 호출 수가 집계될 수 있다.
주 단위로 위와 같은 과정이 반복되고 하루 단위로 집계된 복수의 게임 API 서버 각각에 대한 분 단위 호출 수를 기반으로 복수의 게임 API 서버 각각에 대한 요일별 분 단위 점유율이 산출될 수 있다. 요일별 분 단위 점유율은 주 단위로 그룹핑되어 복수의 게임 API 서버 각각에 대하여 주 단위 요일별 분 단위 점유율이 산출될 수 있다. 예를 들어, 현재 시점을 기준으로 1주전(월요일 분 단위 점유율1, 화요일 분 단위 점유율1, 수요일 분 단위 점유율1, 목요일 분 단위 점유율1, 금요일 분 단위 점유율1, 토요일 분 단위 점유율1, 일요일 분 단위 점유율1), 2주전(월요일 분 단위 점유율2, 화요일 분 단위 점유율2, 수요일 분 단위 점유율2, 목요일 분 단위 점유율2, 금요일 분 단위 점유율2, 토요일 분 단위 점유율2, 일요일 분 단위 점유율2), 3주전(월요일 분 단위 점유율3, 화요일 분 단위 점유율3, 수요일 분 단위 점유율3, 목요일 분 단위 점유율3, 금요일 분 단위 점유율3, 토요일 분 단위 점유율3, 일요일 분 단위 점유율3) 등과 같이 복수의 게임 API 서버 각각에 대하여 주 단위 요일별 분단위 점유율이 산출될 수 있다.
주 단위 요일별 분단위 점유율을 기반으로 해당 요일 별로 복수의 게임 API 서버 각각에 대한 일별 분 단위 점유율의 평균값이 산출될 수 있다. 예를 들어, 게임 API 서버 중 아이템 API 서버의 월요일 분 단위 점유율 평균값, 화요일 분 단위 점유율 평균값 등이 결정될 수 있다.
본 발명의 실시예에 따르면 복수의 게임 API 서버 각각에 대한 일별 분 단위 점유율 평균값을 산출시 현재 시점을 기준으로 인접한 값일수록 높은 가중치를 설정하여 가중 평균값이 산출될 수도 있다. 현재 시점을 기준으로 1주 전의 일별 분 단위 점유율은 2주 전의 일별 분 단위 점유율 보다 높은 가중치가 할당되고 가중치 값을 적용한 가중 평균값이 일별 분 단위 점유율의 평균값이 산출될 수 있다.
복수의 게임 API 서버 각각에 대한 일별 분 단위 점유율 평균값을 고려하여 서버 스케일링이 필요한 구간(또는 시점)에 대한 정보(또는 변곡점 정보)를 저장부(예를 들어, RDBMS(relational database management system))에 등록할 수 있다. RDBMS는 퍼시스턴트 레이어에 포함된 데이터 저장 구조이다.
RDBMS에 등록된 서버 스케일링이 필요한 구간(또는 시점)에 대한 정보를 기반으로 스케일링 스케쥴러 서버에 오토 스케일링을 위한 스케쥴이 등록되고, 이러한 오토 스케일링을 위한 스케쥴을 기반으로 복수의 게임 API 서버 각각에 할당되는 서버 자원을 스케일링할 수 있다.
또한, 본 발명의 실시예에 따르면, 이벤트별 트래픽 정보를 기반으로 아래와 같이 트래픽 패턴이 정의되고, 오토 스케일링 호출 규칙이 설정될 수 있다.
모바일 게임의 수명이 짧을 수 있고, 따라서, 년 단위 이벤트에 대한 기록을 기반으로 오토 스케일링 호출 규칙을 설정하는 것은 의미가 없을 수 있다. 예를 들어, 특정 게임에 대하여 2017년 어린이날에 게임 관련 이벤트를 제공한 경우 해당 데이터를 2018년 어린이날에 사용하여 트래픽을 예측하는 것은 의미가 없을 수 있다. 또한, 하나의 지역 내에서 제공된 이벤트는 평균적인 효과를 가질 수 있다.
전술한 방법을 기반으로 복수의 게임 API 서버 각각에 대한 일별 분 단위 점유율에 대한 정보를 알고 있는 경우, 분석 레이어에 이벤트 일이 등록되고, 이벤트 등록일이 종료되면, 복수의 게임 API 서버 각각에 대해 이벤트 등록일의 분 단위 점유율과 최근 해당 요일의 분 단위 점유율을 비교하여 점유율의 증감폭이 결정될 수 있다. 점유율의 증감폭은 복수의 게임 API 서버 각각에 대해 결정될 수 있다.
복수의 이벤트에 대해 이벤트시 게임별 점유율 증감폭이 결정되고, 복수의 이벤트에 대한 이벤트시 게임 별 점유율 증감폭의 평균값이 결정될 수 있다.
본 발명의 실시예에 따르면 이벤트 종류별로 이벤트시 게임 별 점유율 증감폭의 평균값이 결정될 수도 있다. 예를 들어, 이벤트 카테고리(예를 들어, 회원 가입 이벤트, 아이템 증정 이벤트 등)을 분류하여 이벤트 카테고리별 게임 별 점유율 증감폭의 평균값이 결정될 수도 있고, 수행되는 이벤트의 카테고리에 따라 이벤트 카테고리별 게임 별 점유율 증감폭의 평균값을 기반으로 한 복수의 게임 API 서버 각각에 대한 오토 스케일링이 수행될 수 있다.
이벤트시 게임 별 점유율 증감폭의 평균값(또는 이벤트 카테고리별 게임 별 점유율 증감폭의 평균값)에 대한 정보가 저장부(예를 들어, RDBMS)에 등록될 수 있다. 저장부에 저장된 이벤트시 게임별 점유율 증감폭의 평균값(또는 이벤트 카테고리별 게임 별 점유율 증감폭의 평균값)에 대한 정보와 일별 분 단위 점유율의 평균값에 대한 정보를 기반으로 이벤트시 오토 스케일링을 위한 스케쥴이 등록될 수 있고, 이러한 오토 스케일링을 위한 스케쥴을 기반으로 복수의 게임 API 서버 각각에 할당되는 서버 자원이 스케일링될 수 있다. 예를 들어, 수요일에 아이템 증정 이벤트가 수행되는 경우, 복수의 게임 API 서버 각각에 대한 1) 아이템 증정 이벤트시 게임별 점유율 증감폭의 평균값과 수요일 분 단위 점유율의 평균값을 기반으로 복수의 게임 API 서버 각각에 할당되는 서버 자원에 대한 오토 스케일링이 수행될 수 있다.
도 12는 본 발명의 실시예에 따른 테넌트별 오토 스케일링 호출 규칙을 자동으로 설정하는 방법을 나타낸 개념도이다.
도 12를 참조하면, 테넌트별 트래픽 운영 데이터를 수집하고 분석하는 방법을 통해 테넌트의 트래픽 패턴 정보가 정의되면, 오토 스케일링 호출 규칙을 설정하는 것이 가능하다.
오토 스케일링이 적용되어야 하는 부분은 REST API를 담당하는 서버 인스턴스(또는 비즈니스 레이어), 데이터가 저장되는 퍼시스턴트 레이어이다. 따라서 서버 인스턴스와 퍼시스턴트 레이어 모두 스케일링이 가능한 환경일 수 있다.
본 발명의 실시예에 따르면, 오토 스케일링 호출 규칙을 생성하기 위해 1) 호출 규칙 생성용 서버 컴퓨팅 자원, 2) 오토 스케일링 호출 규칙 변경용 서버 컴퓨팅 자원, 3) 호출 규칙 변경용 스케쥴러가 필요하다. 1), 2) 모두 AWS(Amazon Web Service) Lambda, Azure Function등 클라우드 서비스의 함수형 마이크로 서버로 구성할 수 있다.
이하에서는　호출 규칙 생성용 서버 컴퓨팅 자원은 호출 규칙 생성기(1200), 오토 스케일링 호출 규칙 변경용 서버 컴퓨팅 자원은 호출 규칙 변경기(1220), 호출 규칙 변경용 스케쥴러는 스케쥴러(1240)라는 용어로 정의될 수 있다.
호출 규칙 생성기(1200)는 스케쥴러에 의해 정의된 패턴을 등록할 수 있다. 스케쥴러(1240)에는 오토 스케일링이 수행되어야 하는 요일, 시간, 이벤트와 준비되어야 하는 서버 컴퓨팅 자원, 오토 스케일링이 종료되는 시간이 등록될 수 있다. 스케쥴러(1240)는 정해진 시간에 호출 규칙 변경기를 실행하고, 호출 규칙 변경기(1220)는 스케쥴러(1240)에 등록된 요일/시간/이벤트/서버 컴퓨팅 자원 등을 테넌트의 서버 인프라에 적용할 수 있다. 오토 스케일링 패턴이 종료되는 시간에는 기본적인 오토 스케일링 규칙을 복원 적용해 서버 컴퓨팅의 낭비를 막을 수 있다.
이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (10)

  1. 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법은,
    클라우드 기반의 멀티 테넌시 환경에서 동작하는 BaaS(backend as a service) 관리 서버가 복수의 테넌트로부터 게임 API(application programing interface) 서버에 대한 요청을 수신하는 단계; 및
    상기 BaaS 관리 서버가 상기 요청에 따라 상기 게임 API 서버를 제공하는 단계를 포함하되,
    상기 복수의 테넌트는 상기 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 BaaS 관리 서버는 상기 복수의 테넌트 각각의 운영 데이터를 고려하여 오토 스케일링 호출 규칙을 생성하고, 상기 오토 스케일링 호출 규칙을 기반으로 상기 게임 API 서버에 대한 오토 스케일링을 수행하고,
    상기 운영 데이터는 상기 복수의 테넌트 각각에 대한 요일별 트래픽 정보, 시간대별 트래픽 정보 및 이벤트별 트래픽 정보를 포함하는 것을 특징으로 하는 방법.
  3. 제2항에 있어서,
    상기 게임 API 서버는 상기 복수의 테넌트에 의해 제공되는 게임의 구동을 위한 기능을 제공하고,
    상기 게임 API 서버는 회원가입 API 서버, 로그인 API 서버, 아이템 API 서버, 캐릭터 API 서버 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  4. 제3항에 있어서,
    상기 BaaS 관리 서버가 상기 복수의 테넌트 각각과 상기 게임 API 서버의 연결을 위한 SDK(software development kit)를 제공하는 단계를 더 포함하고,
    상기 SDK를 기반으로 상기 게임 서버와 상기 게임 API 서버가 연결되고,
    상기 BaaS 관리 서버는 상기 복수의 테넌트 각각에서 SDK를 기반으로 REST(Representational　State　Transfer) API로 접근하는 시점 및 횟수에 대한 지표를 수집하여 상기 운영 데이터를 결정하고,
    상기 REST API는 상기 BaaS 관리 서버와 복수의 테넌트 각각 간의 인터페이스를 담당하는 것을 특징으로 하는 방법.
  5. 제4항에 있어서,
    상기 BaaS 관리 서버는 비즈니스 레이어, 캐시 레이어, 퍼시스턴스 레이어 및 분석 레이어를 포함하고,
    상기 비즈니스 레이어는 상기 게임 API 서버를 포함하는 복수의 게임 API 서버를 포함하고,
    상기 캐시 레이어 및 상기 퍼시스턴스 레이어는 데이터에 대한 저장 및/또는 관리를 위해 구현되고,
    상기 분석 레이어는 상기 복수의 게임 API 서버에 대한 스케일링, 상기 캐시 레이어와 상기 퍼시스턴스 레이어에 저장되는 데이터를 관리하기 위해 구현되는 것을 특징으로 하는 방법.
  6. 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙을 자동 생성하는 BaaS(backend as a service) 관리 서버는,
    복수의 테넌트와의 통신을 위해 구현되는 통신부; 및
    상기 통신부와 동작 가능하게(operatively) 연결된 프로세서를 포함하되,
    상기 프로세서는 클라우드 기반의 멀티 테넌시 환경에서 상기 복수의 테넌트로부터 게임 API(application programing interface) 서버에 대한 요청을 수신하고,
    상기 요청에 따라 상기 게임 API 서버를 제공하도록 구현되되,
    상기 복수의 테넌트는 상기 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받는 것을 특징으로 하는 BaaS 관리 서버.
  7. 제6항에 있어서,
    상기 프로세서는 상기 복수의 테넌트 각각의 운영 데이터를 고려하여 오토 스케일링 호출 규칙을 생성하고, 상기 오토 스케일링 호출 규칙을 기반으로 상기 게임 API 서버에 대한 오토 스케일링을 수행하고,
    상기 운영 데이터는 상기 복수의 테넌트 각각에 대한 요일별 트래픽 정보, 시간대별 트래픽 정보 및 이벤트별 트래픽 정보를 포함하는 것을 특징으로 하는 BaaS 관리 서버.
  8. 제7항에 있어서,
    상기 게임 API 서버는 상기 복수의 테넌트에 의해 제공되는 게임의 구동을 위한 기능을 제공하고,
    상기 게임 API 서버는 회원가입 API 서버, 로그인 API 서버, 아이템 API 서버, 캐릭터 API 서버 중 적어도 하나를 포함하는 것을 특징으로 하는 BaaS 관리 서버.
  9. 제8항에 있어서,
    상기 프로세서는 상기 복수의 테넌트 각각과 상기 게임 API 서버의 연결을 위한 SDK(software development kit)를 제공하도록 구현되고,
    상기 SDK를 기반으로 상기 게임 서버와 상기 게임 API 서버가 연결되고,
    상기 프로세서는 상기 복수의 테넌트 각각에서 SDK를 기반으로 REST(Representational　State　Transfer) API로 접근하는 시점 및 횟수에 대한 지표를 수집하여 상기 운영 데이터를 결정하고,
    상기 REST API는 상기 BaaS 관리 서버와 복수의 테넌트 각각 간의 인터페이스를 담당하는 것을 특징으로 하는 BaaS 관리 서버.
  10. 제9항에 있어서,
    상기 프로세서는 비즈니스 레이어, 캐시 레이어, 퍼시스턴스 레이어 및 분석 레이어를 포함하고,
    상기 비즈니스 레이어는 상기 게임 API 서버를 포함하는 복수의 게임 API 서버를 포함하고,
    상기 캐시 레이어 및 상기 퍼시스턴스 레이어는 데이터에 대한 저장 및/또는 관리를 위해 구현되고,
    상기 분석 레이어는 상기 복수의 게임 API 서버에 대한 스케일링, 상기 캐시 레이어와 상기 퍼시스턴스 레이어에 저장되는 데이터를 관리하기 위해 구현되는 것을 특징으로 하는 BaaS 관리 서버.
PCT/KR2018/001948 2017-02-14 2018-02-14 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 WO2018151536A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2019562534A JP6830695B2 (ja) 2017-02-14 2018-02-14 マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法および装置
CN201880010780.4A CN110267717B (zh) 2017-02-14 2018-02-14 在多租户环境中按不同单独租户自动生成自动缩放呼叫规则的方法及装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20170019803 2017-02-14
KR10-2017-0019803 2017-02-14
KR1020180018306A KR102024164B1 (ko) 2017-02-14 2018-02-14 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치
KR10-2018-0018306 2018-02-14

Publications (1)

Publication Number Publication Date
WO2018151536A1 true WO2018151536A1 (ko) 2018-08-23

Family

ID=63169474

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/001948 WO2018151536A1 (ko) 2017-02-14 2018-02-14 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2018151536A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110851512A (zh) * 2019-10-10 2020-02-28 上海易点时空网络有限公司 用于开源框架的数据配置方法及装置
CN113824675A (zh) * 2020-09-17 2021-12-21 京东科技控股股份有限公司 管理登录态的方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282630A1 (en) * 2013-03-14 2014-09-18 Microsoft Corporation Backend custom code extensibility
US20150057078A1 (en) * 2013-08-20 2015-02-26 Microsoft Corporation Integrated game development cloud computing platform
US20160092339A1 (en) * 2014-09-26 2016-03-31 Oracle International Corporation Efficient means to test server generated applications on mobile device
US20160323377A1 (en) * 2015-05-01 2016-11-03 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140282630A1 (en) * 2013-03-14 2014-09-18 Microsoft Corporation Backend custom code extensibility
US20150057078A1 (en) * 2013-08-20 2015-02-26 Microsoft Corporation Integrated game development cloud computing platform
US20160092339A1 (en) * 2014-09-26 2016-03-31 Oracle International Corporation Efficient means to test server generated applications on mobile device
US20160323377A1 (en) * 2015-05-01 2016-11-03 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AMAZON GAMELIFT DEVELOPER GUIDE, 16 January 2017 (2017-01-16), Retrieved from the Internet <URL:https://web.archive.org/web/20170116031349/http://docs.aws.amazon.com:80/gamelift/latest/developerguide/gamelift-dg.pdf> *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110851512A (zh) * 2019-10-10 2020-02-28 上海易点时空网络有限公司 用于开源框架的数据配置方法及装置
CN110851512B (zh) * 2019-10-10 2022-07-12 上海易点时空网络有限公司 用于开源框架的数据配置方法及装置
CN113824675A (zh) * 2020-09-17 2021-12-21 京东科技控股股份有限公司 管理登录态的方法和装置
CN113824675B (zh) * 2020-09-17 2023-08-08 京东科技控股股份有限公司 管理登录态的方法和装置

Similar Documents

Publication Publication Date Title
WO2020017844A1 (ko) 클라우드 플랫폼에서 복수의 클러스터 및 어플리케이션을 모니터링하는 방법
WO2018203635A1 (ko) 클라우드 플랫폼에서 어플리케이션을 컨테이너화하는 방법
WO2020224250A1 (zh) 智能合约的触发方法、装置、设备及存储介质
WO2020017846A1 (ko) 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법
WO2020253135A1 (zh) 自动化分析方法、用户设备、存储介质及装置
WO2018151536A1 (ko) 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치
WO2021027143A1 (zh) 信息推送方法、装置、设备及计算机可读存储介质
WO2014027834A1 (ko) 광고 효과 분석 장치 및 방법
WO2014029111A1 (zh) 一种用户行为处理系统及方法
WO2020233060A1 (zh) 事件通知方法、事件通知服务器、存储介质及装置
WO2022108427A1 (ko) 5g 기반 iot 환경을 위한 지능형 트러스트 인에이블러 시스템
WO2010005252A2 (ko) 온라인 광고에 대한 과금을 위한 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
WO2020122291A1 (ko) 인공지능 기반의 공동주택 관리업무지시 자동화 장치 및 방법
WO2017039121A1 (ko) 노출 순위를 기반으로 하는 바이럴 마케팅 서비스 제공 시스템
WO2011074714A1 (ko) 지능형 맞춤화된 학습서비스 방법
KR102024164B1 (ko) 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치
WO2021133076A1 (ko) 인공지능 학습데이터 생성을 위한 크라우드소싱 기반 프로젝트의 작업단가 관리 방법 및 장치
WO2017196074A1 (ko) 매출 보상금 지급 방법 및 이를 실행하는 서버
CN112000443A (zh) 一种业务数据处理方法、装置及电子设备
WO2020032502A1 (ko) 에너지 빅데이터 수집에 기반한 에너지 분석 및 솔루션 제시 플랫폼을 위한 방법
WO2015093737A1 (ko) 컨텐츠 노출을 이용한 어플리케이션 배포／실행 시스템 및 방법
WO2023033444A1 (ko) 이슈 기반 뉴스 정보 제공을 위한 서비스 제공 장치 및 방법
WO2022075560A1 (ko) 에너지 데이터 중개 시스템 및 방법
WO2022092690A1 (ko) 시공간 특성에 따른 긱 서비스 예측 시스템 및 그 방법
WO2019098428A1 (ko) 사용자 별 확장 가능 관리 테이블을 이용한 erp 펑션 제공 방법 및 이를 수행하는 erp 펑션 제공 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18754043

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019562534

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 29/10/2019)

122 Ep: pct application non-entry in european phase

Ref document number: 18754043

Country of ref document: EP

Kind code of ref document: A1