KR102024164B1 - 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 - Google Patents
멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 Download PDFInfo
- Publication number
- KR102024164B1 KR102024164B1 KR1020180018306A KR20180018306A KR102024164B1 KR 102024164 B1 KR102024164 B1 KR 102024164B1 KR 1020180018306 A KR1020180018306 A KR 1020180018306A KR 20180018306 A KR20180018306 A KR 20180018306A KR 102024164 B1 KR102024164 B1 KR 102024164B1
- Authority
- KR
- South Korea
- Prior art keywords
- game
- server
- api
- tenants
- servers
- Prior art date
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
-
- 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
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Telephonic Communication Services (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (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는 본 발명의 실시예에 따른 테넌트별 오토 스케일링 호출 규칙을 자동으로 설정하는 방법을 나타낸 개념도이다.
도 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)과 자동 스케일 아웃(Auto Scale 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 | NoSQL Search 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)
- 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법은,
클라우드 기반의 멀티 테넌시 환경에서 동작하는 BaaS(backend as a service) 관리 서버가 복수의 테넌트로부터 복수의 게임 API(application programing interface) 서버에 대한 요청을 수신하는 단계; 및
상기 BaaS 관리 서버가 상기 요청에 따라 상기 복수의 게임 API 서버를 제공하는 단계를 포함하되,
상기 복수의 테넌트는 상기 복수의 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받고,
상기 복수의 게임 API 서버는 상기 복수의 테넌트 각각에 의해 공통적으로 제공되는 게임의 구동상 필요한 기능을 제공하고,
상기 복수의 게임 API 서버는 회원가입 API 서버, 로그인 API 서버, 아이템 API 서버, 캐릭터 API 서버 중 적어도 하나를 포함하고,
상기 복수의 테넌트는 상기 복수의 게임 API 서버에 대한 별도 구현없이 SDK(software development kit)를 기반으로 상기 복수의 게임 API 서버에 대한 호출을 기반으로 상기 게임의 구동상 필요한 기능을 제공하는 것을 특징으로 하는 방법. - 제1항에 있어서,
상기 BaaS 관리 서버는 비즈니스 레이어, 캐시 레이어, 퍼시스턴스 레이어 및 분석 레이어를 포함하고,
상기 비즈니스 레이어는 상기 복수의 게임 API 서버를 포함하고,
상기 캐시 레이어 및 상기 퍼시스턴스 레이어는 데이터에 대한 저장 및/또는 관리를 위해 구현되고,
상기 분석 레이어는 상기 복수의 게임 API 서버에 대한 스케일링, 상기 캐시 레이어와 상기 퍼시스턴스 레이어에 저장되는 데이터를 관리하기 위해 구현되고,
상기 BaaS 관리 서버는 상기 분석 레이어의 분석 결과를 기반으로 상기 비즈니스 레이어에 포함되는 상기 복수의 게임 API 서버 중 상대적으로 처리량이 많은 적어도 하나의 게임 API 서버를 분리하고, 분리된 상기 적어도 하나의 게임 API 서버에 별도의 서버 자원에 대한 할당 및 서버 자원에 대한 관리를 수행하는 것을 특징으로 하는 방법. - 제2항에 있어서,
상기 BaaS 관리 서버는 상기 복수의 테넌트 각각의 운영 데이터를 고려하여 오토 스케일링 호출 규칙을 생성하고, 상기 오토 스케일링 호출 규칙을 기반으로 상기 복수의 게임 API 서버에 대한 오토 스케일링을 수행하고,
상기 운영 데이터는 상기 복수의 테넌트 각각에 대한 요일별 트래픽 정보, 시간대별 트래픽 정보 및 이벤트별 트래픽 정보를 포함하고,
상기 복수의 게임 API 서버는 복수의 게임 API 서버 그룹으로 1차적으로 그룹핑되고,
상기 오토 스케일링은 상기 복수의 게임 API 서버 그룹에 포함되는 복수의 게임 API 서버 각각에 대한 시간대별 처리량 분석을 수행하여 상기 복수의 게임 API 서버 그룹을 2차적으로 재그룹핑하여 재그룹핑된 복수의 게임 API 서버 그룹을 생성하는 것을 특징으로 하는 방법. - 제2항에 있어서,
상기 BaaS 관리 서버가 상기 복수의 테넌트 각각과 상기 복수의 게임 API 서버의 연결을 위한 상기 SDK를 제공하는 단계를 더 포함하고,
상기 SDK를 기반으로 게임 서버와 상기 복수의 게임 API 서버가 연결되고,
상기 BaaS 관리 서버는 상기 복수의 테넌트 각각에서 SDK를 기반으로 REST(Representational State Transfer) API로 접근하는 시점 및 횟수에 대한 지표를 수집하여 운영 데이터를 결정하고,
상기 REST API는 상기 BaaS 관리 서버와 복수의 테넌트 각각 간의 인터페이스를 담당하는 것을 특징으로 하는 방법. - 삭제
- 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙을 자동 생성하는 BaaS(backend as a service) 관리 서버는,
복수의 테넌트와의 통신을 위해 구현되는 통신부; 및
상기 통신부와 동작 가능하게(operatively) 연결된 프로세서를 포함하되,
상기 프로세서는 클라우드 기반의 멀티 테넌시 환경에서 상기 복수의 테넌트로부터 복수의 게임 API(application programing interface) 서버에 대한 요청을 수신하고,
상기 요청에 따라 상기 복수의 게임 API 서버를 제공하도록 구현되되,
상기 복수의 테넌트는 상기 복수의 게임 API 서버를 기반으로 게임 개발 및 구동에 필요한 기능을 제공받고,
상기 복수의 게임 API 서버는 상기 복수의 테넌트 각각에 의해 공통적으로 제공되는 게임의 구동상 필요한 기능을 제공하고,
상기 복수의 게임 API 서버는 회원가입 API 서버, 로그인 API 서버, 아이템 API 서버, 캐릭터 API 서버 중 적어도 하나를 포함하고,
상기 복수의 테넌트는 상기 복수의 게임 API 서버에 대한 별도 구현없이 SDK(software development kit)를 기반으로 상기 복수의 게임 API 서버에 대한 호출을 기반으로 상기 게임의 구동상 필요한 기능을 제공하는 것을 특징으로 하는 BaaS 관리 서버. - 제6항에 있어서,
상기 프로세서는 비즈니스 레이어, 캐시 레이어, 퍼시스턴스 레이어 및 분석 레이어를 포함하고,
상기 비즈니스 레이어는 상기 복수의 게임 API 서버를 포함하고,
상기 캐시 레이어 및 상기 퍼시스턴스 레이어는 데이터에 대한 저장 및/또는 관리를 위해 구현되고,
상기 분석 레이어는 상기 복수의 게임 API 서버에 대한 스케일링, 상기 캐시 레이어와 상기 퍼시스턴스 레이어에 저장되는 데이터를 관리하기 위해 구현되고,
상기 프로세서는 상기 분석 레이어의 분석 결과를 기반으로 상기 비즈니스 레이어에 포함되는 상기 복수의 게임 API 서버 중 상대적으로 처리량이 많은 적어도 하나의 게임 API 서버를 분리하고, 분리된 상기 적어도 하나의 게임 API 서버에 별도의 서버 자원에 대한 할당 및 서버 자원에 대한 관리를 수행하는 것을 특징으로 하는 BaaS 관리 서버. - 제7항에 있어서,
상기 프로세서는 상기 복수의 테넌트 각각의 운영 데이터를 고려하여 오토 스케일링 호출 규칙을 생성하고, 상기 오토 스케일링 호출 규칙을 기반으로 상기 복수의 게임 API 서버에 대한 오토 스케일링을 수행하고,
상기 운영 데이터는 상기 복수의 테넌트 각각에 대한 요일별 트래픽 정보, 시간대별 트래픽 정보 및 이벤트별 트래픽 정보를 포함하고,
상기 복수의 게임 API 서버는 복수의 게임 API 서버 그룹으로 1차적으로 그룹핑되고,
상기 오토 스케일링은 상기 복수의 게임 API 서버 그룹에 포함되는 복수의 게임 API 서버 각각에 대한 시간대별 처리량 분석을 수행하여 상기 복수의 게임 API 서버 그룹을 2차적으로 재그룹핑하여 재그룹핑된 복수의 게임 API 서버 그룹을 생성하는 것을 특징으로 하는 BaaS 관리 서버. - 제7항에 있어서,
상기 프로세서는 상기 복수의 테넌트 각각과 상기 복수의 게임 API 서버의 연결을 위한 상기 SDK를 제공하도록 구현되고,
상기 SDK를 기반으로 게임 서버와 상기 복수의 게임 API 서버가 연결되고,
상기 프로세서는 상기 복수의 테넌트 각각에서 SDK를 기반으로 REST(Representational State Transfer) API로 접근하는 시점 및 횟수에 대한 지표를 수집하여 운영 데이터를 결정하고,
상기 REST API는 상기 BaaS 관리 서버와 복수의 테넌트 각각 간의 인터페이스를 담당하는 것을 특징으로 하는 BaaS 관리 서버. - 삭제
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/KR2018/001948 WO2018151536A1 (ko) | 2017-02-14 | 2018-02-14 | 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 |
JP2019562534A JP6830695B2 (ja) | 2017-02-14 | 2018-02-14 | マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法および装置 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020170019803 | 2017-02-14 | ||
KR20170019803 | 2017-02-14 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20180093834A KR20180093834A (ko) | 2018-08-22 |
KR102024164B1 true KR102024164B1 (ko) | 2019-09-23 |
Family
ID=63452924
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020180018306A KR102024164B1 (ko) | 2017-02-14 | 2018-02-14 | 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 |
Country Status (3)
Country | Link |
---|---|
JP (1) | JP6830695B2 (ko) |
KR (1) | KR102024164B1 (ko) |
CN (1) | CN110267717B (ko) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102537906B1 (ko) * | 2022-01-07 | 2023-05-30 | 주식회사 저스트큐 | 위탁 판매를 위한 관리 서버의 오토 스케일링 방법 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102366871B1 (ko) * | 2021-09-11 | 2022-02-23 | 정규일 | 클라우드 기반 모바일 BaaS의 지능형 데이터 캐싱 추천 서버 및 방법 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140282630A1 (en) * | 2013-03-14 | 2014-09-18 | Microsoft Corporation | Backend custom code extensibility |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7711847B2 (en) * | 2002-04-26 | 2010-05-04 | Sony Computer Entertainment America Inc. | Managing users in a multi-user network game environment |
US8151199B2 (en) * | 2009-02-09 | 2012-04-03 | AltEgo, LLC | Computational delivery system for avatar and background game content |
-
2018
- 2018-02-14 JP JP2019562534A patent/JP6830695B2/ja active Active
- 2018-02-14 KR KR1020180018306A patent/KR102024164B1/ko active IP Right Grant
- 2018-02-14 CN CN201880010780.4A patent/CN110267717B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140282630A1 (en) * | 2013-03-14 | 2014-09-18 | Microsoft Corporation | Backend custom code extensibility |
Non-Patent Citations (1)
Title |
---|
아마존 게임 리프트(2017.01.16) 1부.* |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102537906B1 (ko) * | 2022-01-07 | 2023-05-30 | 주식회사 저스트큐 | 위탁 판매를 위한 관리 서버의 오토 스케일링 방법 |
Also Published As
Publication number | Publication date |
---|---|
KR20180093834A (ko) | 2018-08-22 |
CN110267717B (zh) | 2023-06-27 |
CN110267717A (zh) | 2019-09-20 |
JP6830695B2 (ja) | 2021-02-17 |
JP2020509513A (ja) | 2020-03-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10909554B2 (en) | Analyzing big data to determine a data plan | |
US11847103B2 (en) | Data migration using customizable database consolidation rules | |
US10552292B2 (en) | System, method and computer product for management of proof-of-concept software pilots, including neural network-based KPI prediction | |
US9367601B2 (en) | Cost-based optimization of configuration parameters and cluster sizing for hadoop | |
Tsuchiya et al. | Big data processing in cloud environments | |
US9189543B2 (en) | Predicting service request breaches | |
CN101535944A (zh) | 基于集的相似性的可扩展用户聚类 | |
CN110647512B (zh) | 一种数据存储和分析方法、装置、设备和可读介质 | |
CN107851105A (zh) | 具有副本位置选择的分布式存储*** | |
Ardagna et al. | Modeling performance of hadoop applications: A journey from queueing networks to stochastic well formed nets | |
CN109428910B (zh) | 一种数据处理方法、装置及*** | |
Tadakamalla et al. | Characterization of IoT workloads | |
KR102024164B1 (ko) | 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 | |
CN110233741A (zh) | 服务计费方法、装置、设备及存储介质 | |
CN108959048A (zh) | 模块化环境的性能分析方法、装置及可存储介质 | |
CN109298929A (zh) | 定时任务执行时间推荐方法、装置、设备和存储介质 | |
US10959041B1 (en) | Traffic analysis of mobile phones partitioned by geohash | |
CN103426050B (zh) | 业务课题分析支持*** | |
Corradi et al. | Automatic extraction of POIs in smart cities: Big data processing in ParticipAct | |
CN107423315B (zh) | 一种户外媒体资源数据的挖掘处理方法及*** | |
KR102068119B1 (ko) | 광고대행사용 통합 관리 시스템 | |
WO2018151536A1 (ko) | 멀티 테넌시 환경에서의 개별 테넌트별 오토 스케일링 호출 규칙 자동 생성 방법 및 장치 | |
US11216830B1 (en) | Mobile communication device location data analysis supporting build-out decisions | |
WO2016206441A1 (zh) | 一种虚拟资源分配方法及装置、计算机存储介质 | |
CN110309223B (zh) | 选择数据节点的方法、***以及相关设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E90F | Notification of reason for final refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant |