클라우드 게임 인프라 개요

Last reviewed 2022-01-28 UTC

이 솔루션은 클라우드 플랫폼에서 게임 인프라를 호스팅하는 데 사용되는 일반적인 구성 요소와 디자인 패턴에 관한 개요를 제시합니다.

비디오 게임은 지난 수십 년 사이에 성공적인 엔터테인먼트 사업으로 진화하였습니다. 광대역 인터넷이 확산되면서 게임 성장을 이끈 주요 요인 중 하나가 온라인 플레이가 되었습니다.

온라인 플레이는 세션 기반의 멀티플레이어 매치, 대규모 멀티플레이어 가상 세계, 그리고 싱글플레이어 경험들이 서로 뒤얽힌 형태 등 여러 가지 형태로 제공됩니다.

과거에는 클라이언트-서버 모델을 이용한 게임을 제공하려면 온라인 인프라를 운영할 전용 온프레미스 서버를 구입하거나 여러 개의 서버를 구입하여 한 곳에 유지해야 했으며 이는 대형 스튜디오와 발행업체만 할 수 있었습니다. 그리고 고정된 하드웨어를 가지고 과다 지출을 하지 않고 고객의 요구를 충족하려면 광범위한 예측과 용량 계획이 요구되었습니다. 오늘날의 클라우드 기반 컴퓨팅 리소스 환경에서는 규모에 상관없이 모든 게임 개발자와 게시자가 필요한 모든 리소스를 요청하여 받을 수 있으므로 과다한 초기 경비 지출과 프로비저닝이 초과되거나 부족해지는 문제를 방지하는 데 도움이 됩니다.

고수준 구성 요소

아래의 다이어그램은 게이밍 아키텍처의 온라인 부분을 보여줍니다.

프런트엔드 및 백엔드 구성요소가 있는 Google Cloud의 게임 인프라 다이어그램

게이밍 아키텍처의 프런트엔드 구성 요소는 다음과 같습니다.

게임 외적인 기능을 제공하는 게임 플랫폼 서비스.
게임을 호스팅하는 전용 게임 서버.

게이밍 아키텍처의 백엔드 구성 요소는 다음과 같습니다.

기록된 시스템에서 지속되고 일반적으로 게임 데이터베이스에 저장되는 게임 상태.
분석과 게임 플레이 이벤트를 저장하고 쿼리하는 분석 스택.

이러한 구성 요소는 온프레미스, 사설 또는 공용 클라우드, 심지어 완전 관리형 솔루션 등 다양한 환경에서 호스팅될 수 있습니다. 시스템이 구성 요소와 최종 사용자 간의 통신을 위한 지연 시간 요건을 충족한다면 이 중 어떤 환경에서도 작동할 것입니다.

프런트엔드

프런트엔드는 클라이언트가 직접적으로 또는 부하 분산 레이어를 통해 상호작용할 수 있는 인터페이스를 제공합니다.

예를 들어 세션 기반의 1인칭 슈팅 게임에서 프런트엔드는 일반적으로 Open Match와 같은 랜덤 대결 서비스를 의미합니다. 이 서비스는 전용 게임 서버 인스턴스에 관한 연결 정보를 클라이언트에 배포합니다.

클라이언트가 랜덤 대결 서비스에 요청을 전송합니다.
랜덤 대결 서비스는 일치 기준에 따라 전용 게임 서버 인스턴스에 플레이어를 할당합니다.
랜덤 대결 서비스가 연결 정보를 클라이언트에 전송합니다.
그러면 클라이언트가 사용자 데이터그램 프로토콜(UDP)을 사용하여 전용 게임 서버 인스턴스에 직접 연결할 수 있습니다.

프런트엔드 서비스를 외부 클라이언트만 사용해야 하는 것은 아닙니다. 프런트엔드 서비스는 서로 간에, 그리고 백엔드와 통신을 하는 것이 일반적입니다.

그러나 프런트엔드 서비스는 인터넷을 통해 제공되기 때문에 공격에 노출될 가능성이 있습니다. 이러한 보안 및 안정성 문제를 해결하는 데 도움이 되도록 서비스 거부 공격과 이상 패킷에 대비하여 프런트엔드 서비스를 강화하는 것을 고려해볼 필요가 있습니다. 이와 반대로 백엔드 서비스는 일반적으로 신뢰할 수 있는 코드를 사용해야만 액세스할 수 있으므로 공격에 더 강할 것입니다.

게임 플랫폼 서비스

이 구성 요소의 일반적인 명칭은 플랫폼 서비스 또는 온라인 서비스입니다. 플랫폼 서비스는 필수적인 메타-게임 기능을 위한 인터페이스 즉, 플레이어가 동일한 전용 게임 서버 인스턴스에 참가하도록 허용하거나 게임에서 '친구 목록' 소셜 그래프를 담고 있는 인터페이스를 제공합니다. Steam, Xbox Live, 또는 Google Play 게임즈 등 사용자의 게임이 실행되는 플랫폼에서 이러한 서비스를 제공하는 것이 일반적입니다.

리더 보드 및 경기 기록
랜덤 대결
온라인 로비
Chat
인벤토리 관리
승인
파티/그룹
프로필
길드
교차 플랫폼 잠금 해제
피드
소셜 ID 매핑
애널리틱스
상태

게임 플랫폼 서비스는 웹 서비스와 유사한 패턴으로 진화했습니다.

2000년대 초반, 일반적인 플랫폼 서비스 제품군은 대개 싱글톤으로 구현되는 모놀리식 서비스로 실행되곤 했습니다. 제휴를 하더라도 이러한 패턴은 클라우드 배포에 권장되지 않습니다.
2000년대 중반에는 여러 서비스가 독립적으로 확장 가능하도록 업계가 변화됨에 따라 지금은 이미 친숙한 서비스 지향 아키텍처 패턴(SOA)이 대중화되었습니다. 게다가 이제는 게임 클라이언트와 서버뿐 아니라 웹 서비스, 더 나아가서는 스마트폰 앱에서도 서비스에 액세스할 수 있습니다.
지난 5년 동안에는 많은 개발자가 확장성이 뛰어난 웹 기업들이 옹호하는 마이크로 서비스 접근법을 채택하였습니다. 플랫폼 서비스와 웹 애플리케이션의 여러 가지 근본적인 과제는 개발 주기를 짧게 만들고 전 세계에 걸쳐 배포성이 우수한 서비스를 운영하는 것 등등 서로 동일합니다. 마이크로 서비스는 이러한 문제를 해결하는 데 도움이 될 수 있으며 애플리케이션을 클라우드 플랫폼에서 실행되도록 설계할 때 훌륭한 선택이 될 수 있습니다.
또한 이제는 플랫폼 서비스 또는 완전 관리형 플랫폼 서비스를 빌드하는 방법을 제공하는 여러 호스팅 서비스 또는 관리형 서비스가 있습니다.

백엔드 플랫폼 서비스

대부분의 플랫폼 서비스는 외부 클라이언트에 의해 액세스되지만 때로는 플랫폼 서비스가 온라인 인프라의 다른 요소, 예를 들어 공개 인터넷에 노출되지 않는 내부 경쟁 플레이어 순위 서비스에서만 액세스하는 것이 합리적인 경우도 있습니다. 이러한 백엔드 플랫폼 서비스는 보통 외부 네트워크 경로 및 IP 주소가 없지만 프런트엔드 플랫폼 서비스와 동일한 설계 사례에 따릅니다.

Google Cloud 게임 플랫폼 서비스 리소스

다음 리소스는 Google Cloud에서 플랫폼 서비스를 빌드하는 방법에 대한 자세한 정보를 제공합니다.

전용 게임 서버

전용 게임 서버는 게임 로직을 제공합니다. 사용자가 느끼는 지연 시간을 최소화하기 위해, 클라이언트 게임 앱은 일반적으로 전용 게임 서버와 직접 통신합니다. 이러한 점에서 이 앱은 프런트엔드 서비스 아키텍처의 일부입니다.

업계에 표준화된 용어가 없으므로 이 문서에서는 용어를 아래와 같이 정의하겠습니다.

머신이란 게임-서버 프로세스가 실행되는 실제 머신 또는 가상 머신을 의미합니다.
게임 서버는 게임-서버 프로세스를 의미합니다. 여러 개의 게임-서버 프로세스가 하나의 머신에서 동시에 실행될 수 있습니다.
인스턴스란 하나의 게임-서버 프로세스를 의미합니다.

전용 게임 서버의 유형

오늘날의 백엔드 게임 서버에 있어서 전용이라는 단어는 오해의 소지가 있습니다. 원래 전용이라는 말은 전용 하드웨어에서 1:1의 비율로 실행되었던 게임 서버를 가리켰습니다. 오늘날 대부분의 게임 발행업체는 한 머신에서 동시에 실행되는 여러 개의 게임-서버 프로세스를 관리합니다. 이제 이러한 프로세스만을 위한 전용 머신이 있는 경우는 드물지만, 전용 게임 서버라는 용어는 게임 업계에서 여전히 자주 사용되고 있습니다.

전용 게임 서버는 그 서버에서 실행하는 게임의 유형 만큼이나 다양합니다. 다음 섹션에서는 몇 가지 고수준 게임 서버 범주에 대해 다루도록 하겠습니다.

실시간 시뮬레이션

최근까지는 판매를 위해 공급된 제품을 위한 거의 모든 전용 게임 서버가 실시간 시뮬레이션 게임용 프런트엔드의 일부였습니다. 실시간 시뮬레이션 게임 서버는 이전부터 수직 확장의 한계를 넓혀왔습니다. 가장 어려운 게임은 머신당 여러 개의 서버 프로세스를 실행하거나 세상을 지리적으로 분할하는 등과 같은 수동-수평 확장 전술로 이동하였습니다. 커스텀 흐름 제어, 안정성 및 혼잡 회피를 수반하는 UDP 통신이 지배적인 네트워킹 패러다임입니다.

대부분의 실시간 시뮬레이션 게임 서버는 무한 루프로 구현되며, 여기서 게임의 목표는 주어진 시간 안에 루프를 끝내는 것입니다. 일반적으로 주어지는 시간은 16밀리초 또는 33밀리초로, 이는 각각 초당 60회 또는 30회 상태 업데이트 속도를 제공합니다. 업데이트 속도를 프레임 속도 또는 틱 속도라고도 합니다. 서버는 시뮬레이션을 자주 업데이트하지만 업데이트를 여러 차례 수행한 후에야 서버가 상태 업데이트를 클라이언트에 전달하는 것이 일반적입니다. 이렇게 함으로써 네트워크 대역폭 요구사항이 합리적으로 유지됩니다. 업데이트 빈도가 낮다면 지연 보상, 내삽, 외삽과 같은 전략을 이용하여 완화할 수 있습니다.

이 모든 것이 실시간 시뮬레이션 게임 서버가 게임 서버 설계와 게임이 실행되는 컴퓨팅 플랫폼에 대한 세심한 주의를 필요로 하는, 지연에 민감하고 컴퓨팅 및 대역폭 집약적인 워크로드를 실행한다는 뜻입니다. Google Cloud는 Google Kubernetes Engine(GKE)과 같은 Kubernetes 클러스터에서 전용 게임 서버를 간단하게 실행할 수 있도록 Agones 오픈소스 프로젝트를 개발했습니다.

세션 또는 매치 기반 게임

요즘에는 여러 서버가 세션을 따로따로 실행하도록 설계되어 있는 게임이 아주 흔합니다. 대표적인 예로 Call of Duty™, Fornite™, 또는 Titanfall™과 같은 1인칭 슈팅 게임(FPS)이나 Dota 2™ 또는 League of Legends™와 같은 멀티플레이어 온라인 배틀 아레나(MOBA) 게임이 있습니다. 이러한 게임은 신속한 게임 플레이와 정교한 게임 상태 계산을 필요로 하는 서버를 갖추고 있으며 AI 또는 물리 시뮬레이션 전용 스레드가 있는 경우가 많습니다.

대규모 멀티플레이어 영속적 세계

약 20년 전, Ultima Online™은 대규모 멀티플레이어 온라인(MMO) 게임의 폭발적인 확대를 위한 기반을 닦았습니다. World of WarcraftTM나 final Fantaxy XIVTM와 같이 오늘날 가장 인기 있는 MMO는 여러 기능이 끊임없이 변화하는 복잡한 서버 디자인이 특징입니다.

MMO 게임 서버에서도 서버 인스턴스 간에 게임 항목을 전달하고 게임 세계를 분할하거나 변환하고 인접한 게임 세계 영역을 시뮬레이션하는 여러 인스턴스를 물리적으로 같은 곳에 두는 등 복잡한 문제들은 공통으로 적용됩니다. 수백 명 또는 수천 명의 플레이어가 있는 영속적인 세계의 상태 업데이트를 계산하기 위한 컴퓨팅 및 메모리 요구사항은 Eve Online™의 시간 지연과 같은 솔루션으로 이끌 수 있습니다.

요청/응답 기반 서버

엄밀히 말하면 모든 전용 게임 서버는 일련의 요청과 응답을 기반으로 합니다. 그러나 특히 실시간 통신에 대한 필수적인 요구가 없는 모바일 게임 서버에서는 웹 호스팅에 사용되는 것과 같은 HTTP 요청 및 응답 의미 체계를 채택하였습니다.

요청/응답 게임 서버의 과제는 여타 웹 서비스의 경우와 동일하며 그 예를 들면 다음과 같습니다.

게임 서버의 응답 시간을 가능한 한 빠르게 유지하기.
게임 서버를 전 세계에 배포하여 지연 시간을 줄이고 중복성을 추가하기.
게임 클라이언트의 행동을 서버에서 검증하여 악용 또는 부정행위로부터 보호하기.
서비스 거부 및 기타 공격에 맞서 게임 서버 강화하기.
클라이언트 측에서 통신 재시도를 위한 지수 지연 구현하기.
“붙어 있는” 세션을 만들거나 프로세스 상태를 외부화하기.

간략한 통신 의미 체계와 애플리케이션 또는 네트워크 오류 후 재시도의 용이성과 같은 요청/응답 게임 서버의 강점은 턴제 게임과 모바일 게임에서 원활하게 작용합니다. 이 유형의 서버에는 App Engine 또는 Cloud Run과 같은 플랫폼에서 서버리스 API를 사용하는 것이 좋습니다.

게임 세계 상태의 외부화

게임 플레이어는 게임 다운타임이 제로가 되는 것을 점점 더 기대합니다. 이 말은 개별 서버 인스턴스에 영향을 미치는 문제로부터 게임 플레이어의 경험을 보호해야 한다는 뜻입니다. 이를 위해 게임은 단일 게임-서버 프로세스 외부에서 플레이어 상태를 유지하는 것이 좋습니다 이렇게 되면 서버 프로세스 충돌 시의 장애 복구성과 효과적인 부하 균형 능력 등 많은 이점이 있습니다.

안타깝지만 웹 서비스에서 널리 사용되고 있는 외부화된 상태 패턴을 사용하는 것은 다음과 같은 이유에서 문제가 될 수 있습니다.

초당 수십 회 업데이트되는 고유 항목이 많이 있는 경우에는 업데이트가 외부 상태에 기록될 수 있는 속도가 문제가 될 수 있습니다. 이는 Memcached 또는 Redis와 같은 메모리에 캐시되는 키-값 저장소를 사용하더라도 마찬가지입니다.
외부 상태 캐시에 대한 쿼리의 말단 지연 시간은 커다란 문제를 시사합니다. 쿼리의 1% 또는 심지어 0.1%라도 지연 시간이 업데이트 마감 시간보다 훨씬 더 길다면 상태-업데이트 마감 시간을 맞추기가 어렵습니다.
어느 프로세스가 외부 상태 캐시에 있는 객체에 관해 읽기 전용 권한 또는 읽기-쓰기 권한을 가질지에 대한 결정은 서버 모델에 복잡성을 가져다줍니다.

그러나 이러한 문제를 해결할 경우 여러 가지 좋은 점이 수반됩니다. 적절한 액세스 관리를 통해 여러 프로세스에 외부화된 상태를 성공적으로 제공할 경우 게임 상태 업데이트의 여러 부분을 병렬로 계산하는 기능을 크게 간소화할 수 있습니다. 이것은 항목을 인스턴스 간에 마이그레이션할 때의 이점과 유사합니다.

Google Cloud 전용 게임 서버 리소스

다음 문서는 Google Cloud에서 전용 게임 서버를 실행하는 방법을 설명합니다.

백엔드

백엔드 서비스는 다른 프런트엔드 및 백엔드 서비스에만 인터페이스를 제공합니다. 외부 클라이언트는 백엔드 서비스와 직접 통신할 수 없습니다. 백엔드 서비스는 일반적으로 데이터베이스의 게임 상태 데이터 또는 데이터 웨어하우스의 로깅 및 분석 이벤트와 같은 데이터를 저장하고 액세스하는 방법을 제공합니다.

게임 데이터베이스

플레이어가 귀사의 게임을 중단하고 다시는 돌아오지 않게 될 시나리오의 예로 서버가 작동하지 않는 경우와 플레이어의 게임 진행 과정이 유실되는 경우가 있습니다. 안타깝지만 데이터베이스 레이어를 제대로 설계하지 않으면 두 가지 경우 모두 발생할 수 있습니다.

게임 세계 상태와 플레이어의 게임 진행 데이터를 저장하는 데이터베이스는 게임 인프라에서 가장 중요한 요소로 간주될 수 있을 것입니다.

데이터베이스가 예상 워크로드를 처리하는 능력뿐 아니라 게임이 큰 성공을 거두었을 때 필요한 워크로드까지도 평가해야 합니다. 예상 플레이어를 기반으로 설계되고 테스트되었으나 갑자기 훨씬 더 큰 부하를 받는 백엔드는 누구에게도 안정적으로 서비스를 제공할 수 없을 것입니다. 예상치 못한 성공에 대비하여 계획을 세우지 않으면 데이터베이스 문제 때문에 플레이를 할 수 없게 될 때 플레이어가 귀사의 게임을 포기할 것이므로 게임이 실패할 수도 있습니다.

게임은 특히 이 문제에 취약합니다. 성공적인 제품을 보유한 대부분의 기업은 점진적이고 유기적인 성장을 기대할 수 있습니다. 그러나 게임은 일반적으로 처음에는 관심이 크게 증폭되었다가 순식간에 사용량이 훨씬 더 감소할 것입니다. 게임이 성공을 거두게 되면 데이터베이스에 과부하가 걸려서 사용자 진행 상황을 저장하기도 전에 막대한 지연이 발생하거나 진행 상황을 모두 저장하지 못할 수도 있습니다. 게임의 특정 기능이 더 이상 실시간 업데이트를 지원하지 못하는 상황을 원하는 게임 개발자는 없을 것이므로, 데이터베이스 리소스를 면밀하게 계획하세요.

게임 데이터베이스를 설계할 때 다음과 같이 하세요.

정보에 입각해서 결정을 내리세요. 개발 시 특정 데이터베이스가 테스트하기 쉬워서 모든 옵션을 제대로 평가해보지도 않고 그 데이터베이스를 제품 데이터베이스로 삼으면 안됩니다. 게임에서 이루어지는 데이터베이스 액세스의 유형과 빈도를 예상되는 플레이어를 기반으로, 그리고 그 예상치의 10배를 기반으로 하여 이해하는 것이 중요합니다. 그러면 어떤 백엔드가 이러한 시나리오들을 가장 잘 처리할 수 있는지와 관련하여 정보에 입각한 선택을 할 수 있습니다. 데이터베이스 위기가 닥쳤을 때 그 위기를 타개하는 방법을 찾으려고 애쓰는 상황이 발생하지 않도록 하세요.
한 가지 솔루션이 적절한 솔루션이라고 생각하지 마세요. 한 가지 유형의 데이터베이스만 실행할 수 있다는 규칙은 없습니다. 성공을 거둔 많은 게임은 관계형 데이터베이스를 사용하여 계정 정보를 저장하고 게임 내 구매를 처리하는 한편, 게임 상태 정보를 별도의 NoSQL 데이터베이스에 보관합니다. NoSQL 데이터베이스는 용량이 크고 지연 시간이 적은 워크로드를 처리하는 데 더 좋고, 관계형 데이터베이스는 확실한 트랜잭션을 제공할 수 있습니다.
데이터를 백업하세요. 정기적으로 백업하고 백업을 지리적으로 분산시키는 것이 데이터베이스 결함을 복구하는 데 있어서 중요합니다.

관계형 데이터베이스

많은 게임 개발팀이 하나의 관계형 데이터베이스로 시작합니다. 데이터베이스 성능이 더 이상 처리할 수 없을 정도로 데이터와 트래픽이 증가할 경우, 일반적으로 먼저 취하게 되는 방법은 데이터베이스를 확장하는 것입니다. 확장이 더 이상 불가능하게 되면 많은 개발자가 커스텀 데이터베이스 서비스 레이어를 구현합니다. 이 레이어에서 쿼리와 캐시 결과의 우선 순위를 결정할 수 있는데, 둘 다 데이터베이스 액세스를 제한합니다. 확장과 데이터베이스 서비스 레이어를 추가함으로써 막대한 수의 플레이어를 처리할 수 있는 게임 백엔드를 생성할 수 있지만 이러한 방법은 일반적으로 다음과 같은 문제를 유발할 수 있습니다.

확장—기존의 관계형 데이터베이스는 수직 확장 접근법에 집중합니다. 그러나 클라우드 기반 게임 백엔드를 계획할 때는 수평 확장 접근법을 사용할 것을 권장합니다. 단일 VM에 존재할 수 있는 코어의 수는 항상 제한되지만 클라우드 프로젝트에 VM을 추가하는 것은 꽤 간단하기 때문입니다. 관계형 데이터베이스는 샤딩, 클러스터링, 단계형 복제본과 같이 수평 확장을 위한 패턴으로 되어 있지만, 실행 중인 데이터베이스에 다운타임 없이 추가하기는 어려울 수 있습니다. 트래픽 또는 데이터가 하나의 데이터베이스보다 더 빨리 증가할 가능성이 있다면 작은 클러스터로 시작하세요. 위기가 닥쳤을 때 데이터베이스를 확장하는 방법을 배워야 하는 상황은 발생하지 않는 것이 좋습니다. 실행되고 있는 클러스터에 노드를 추가하는 것이 쉽지는 않지만 가능합니다.
스키마 변경—성공을 거둔 게임 중 게임의 수명 기간 내내 지속되는 데이터베이스 스키마를 가지고 출시되는 게임은 극소수입니다. 플레이어는 새로운 기능과 콘텐츠를 요구하고, 이를 추가하려면 데이터베이스에 새로운 유형의 데이터를 저장해야 합니다. 개발 단계 초기에, 스키마를 어떻게 업데이트할지를 결정하는 것이 좋습니다. 프로세스를 확립하지 않은 상태에서 게임을 출시한 후에 스키마를 업데이트하려고 한다면 예상치 못한 다운타임이나 플레이어 데이터의 손실까지도 발생할 수 있습니다.
관리—실행 중인 관계형 데이터베이스를 확장하고 그 스키마를 업데이트하는 일은 모두 복잡한 작업입니다. 자동으로 관리되는 관계형 데이터베이스는 클라우드 플랫폼의 흔한 서비스이지만, 현재는 게임 백엔드에 자동으로 관리되는 데이터베이스를 채택하는 비율이 낮습니다. 이는 게임 백엔드가 쓰기가 많은 작업부하이기 때문입니다.

Google은 이러한 문제를 해결하는 데 도움이 되는 관리되는 관계형 데이터베이스인 Spanner를 제공합니다. Spanner는 클라우드용으로 빌드되었고 strong consistency와 글로벌 분산 특성을 가지며, 확장성이 뛰어난 엔터프라이즈급 데이터베이스 서비스입니다. 여기에는 관계형 데이터베이스 구조의 이점과 비관계형 수평적 확장이 결합되어 있습니다. Spanner는 여러 게임 회사의 프로덕션급 시스템에서 게임 상태 데이터베이스와 인증 데이터베이스를 모두 교체하기에 적합한 것으로 인정 받고 있습니다. Google Cloud 콘솔을 사용하여 노드를 추가함으로써 성능 또는 스토리지를 추가적으로 확장할 수 있습니다. Spanner는 strong consistency로 전역 복제를 투명하게 처리할 수 있으므로 리전 복제본을 관리할 필요가 없습니다. 자세한 내용은 게이밍 데이터베이스로 사용되는 Spanner의 권장사항을 참조하세요.

NoSQL 데이터베이스

비관계형 데이터베이스는 특히 쓰기가 많은 작업부하에 확장성 있는 운영을 위한 솔루션을 제공할 수 있습니다. 단, NoSQL 데이터 모델과 액세스 패턴, 그리고 트랜잭션 보장에 대해 이해해야 합니다.

NoSQL 데이터베이스에는 여러 가지 유형이 있는데, 게임 세계 상태를 저장하는 데 적합한 NoSQL 데이터베이스의 특징은 다음과 같습니다.

확장—수평 확장을 염두에 두고 설계되었으며 이를 사용하도록 기본으로 설정되어 있기도 합니다. 클러스터 크기 조정은 일반적으로 다운타임 없이 수행될 수 있는 작업이지만, 때로는 추가 노드가 완전히 통합될 때까지 어느 정도의 성능 손실이 발생하기도 합니다.
스키마 변경—스키마가 동적이고 애플리케이션 레이어에 의해 시행됩니다. 이것은 커다란 이점으로, 새 게임 기능을 위해 새 필드를 추가하는 작업이 간단할 수 있다는 뜻입니다.
관리—대부분의 클라우드 제공업체가 최소 하나의 호스팅 또는 관리형 NoSQL 데이터 스토리지 엔진을 제공하는데, Google Cloud는 여러 옵션을 제공합니다

Google Cloud 게임 데이터베이스 리소스

애널리틱스

분석은 오늘날 게임에서 중요한 구성요소로 발전하였습니다. 온라인 서비스와 게임 클라이언트 모두 분석 및 원격 분석 이벤트를 하나의 공통된 수집점으로 전송할 수 있으며, 여기서 관련 이벤트가 하나의 데이터베이스에 저장됩니다. 그런 다음, 게임 플레이 프로그래머와 디자이너에서부터 비즈니스 인텔리전스 분석가와 고객 서비스 담당자까지 모든 사람이 이러한 이벤트를 쿼리할 수 있습니다. 수집되는 분석 자료의 복잡성이 증가함에 따라, 이러한 이벤트를 쉽고 빠르게 쿼리할 수 있는 하나의 형식을 유지할 필요성도 증가합니다.

지난 10년 동안 Google에서 게시한 작업에 기초한 오픈소스 프레임워크인 Apache™ Hadoop®의 인기가 크게 상승했습니다. Hadoop 에코시스템이 확대되면서 분석 이벤트를 포맷하여 데이터 웨어하우스에 삽입하는 복잡한 일괄 처리 추출, 변환, 로드(ETL) 작업의 사용이 증가하였습니다. 맵리듀스의 사용률이 실천 가능한 결과가 도출될 정도로 빠르게 증가하였으며 이로 인해 새롭고 더 컴퓨팅 집약적인 분석이 가능해졌습니다.

한편, 클라우드에서 제공되는 기술은 계속해서 진화하였습니다. 그 중 다수가 빨리 배울 수 있고 전문 운영 직원을 필요로 하지 않는 관리형 서비스로 제공됩니다. Google의 최신 스트리밍 ETL 패러다임은 일괄 처리와 스트림 처리 모두에 하나의 통합된 접근 방식을 제공하며, 관리형 클라우드 서비스와 오픈소스 프로젝트 Apache Beam 두 가지 모두로 제공됩니다. 클라우드 데이터 저장소 가격의 지속적인 개선에 힘입어 이제는 데이터를 읽고 쓰는 방식을 최적화하는 대규모 관리형 클라우드 데이터베이스에 방대한 양의 로그와 분석 이벤트를 보관하는 것이 가능합니다. 이러한 데이터베이스의 최신 쿼리 엔진은 TB의 데이터를 몇 초 안에 집계할 수 있습니다. 이와 관련한 예를 확인하려면 위키백과 페이지뷰 500억 회를 5초 안에 분석한 사례를 참조하세요.

나중을 위해 애널리틱스 형식을 지정하는 것이 좋습니다. 게임이 애널리틱스 백엔드에 기록하는 이벤트 및 측정항목을 결정할 때는 인사이트를 얻기 위해 데이터 마이닝을 수행할 때 가장 쉬울 형식을 고려합니다. ETL을 사용하여 앱에 기록되는 데이터를 애널리틱스 쿼리에 적합한 형식으로 복사할 수 있지만, 이를 위해서는 시간과 비용이 필요합니다. 애널리틱스 출력 형식의 설계에 투자하면 상당한 비용을 절약하고 실시간 애널리틱스 인사이트를 얻을 수 있습니다.

기존 형식에 대한 일괄 처리 사용

타사 통합 또는 서비스의 데이터와 같이 제어할 수 없는 출력 형식의 측정항목 데이터를 분석하려는 경우 측정항목 데이터를 Cloud Storage에 먼저 저장하는 것이 좋습니다. 데이터 형식이 지원되는 경우 BigQuery 인터페이스에서 BigQuery 통합 쿼리를 사용하여 직접 쿼리할 수 있습니다. 데이터 형식이 지원되지 않는 경우에는 ETL을 사용하여 Dataflow 또는 다른 도구를 사용해서 Cloud Storage로 데이터를 복사한 후 다른 소스의 데이터와 함께 BigQuery에 결과 형식 데이터를 저장할 수 있습니다. 실시간으로 데이터가 긴급하게 필요하지 않는 한 스트리밍 대신 일반적인 일괄 작업을 설정하여 비용을 절약하는 것이 좋습니다. 이 접근 방법에 대한 자세한 내용은 애널리틱스 이벤트 및 로그에 대한 대규모 수집 최적화를 참조하세요.

검증된 모델로 앱 제거 및 지출 예측

원격 구석, 앱 내 메시징, Firestore 클라이언트 라이브러리와 같은 많은 다른 기능들 중 하나를 위해 이미 모바일 게임에 Firebase를 사용 중일 수 있습니다. 또한 Firebase는 기본 제공되는 앱 제거 및 지출 예측 머신 러닝(ML) 모델을 제공합니다. 원격 구성 맞춤설정을 통합하여 애널리틱스 데이터에 ML을 적용하고, 사용자의 예측 동작을 기준으로 동적 사용자 세그먼트를 만들 수 있습니다. 이 데이터는 다른 Firebase 기능을 트리거하는 데 사용하거나 추가 유연성을 위해 BigQuery로 내보낼 수 있습니다. Firebase는 Unity 및 C++ 클라이언트도 제공하며 모바일 게임으로 제한되지 않습니다.

AutoML Tables 커스텀 모델 학습을 위한 데이터 정규화

효율적인 ML 모델을 생성하기 위해서는 일반적으로 관련 기능을 선택하고 초매개변수를 조정하는 등의 광범위한 ML 전문 지식이 요구됩니다. 하지만 다음 데이터 준비 가이드라인은 이러한 태스크를 수행하고 사용자 대신 유용한 모델을 생성할 수 있도록 최신 자동화 도구의 기능을 향상시켜 줍니다. 모델이 생성된 다음에는 이를 Google Cloud에 호스팅하여 플레이어의 게임 내 구매 또는 게임 종료 예측과 같은 온라인 또는 일괄 예측을 수행할 수 있습니다.

애널리틱스 이벤트와 플레이어 데이터는 기존의 애널리틱스 쿼리 및 비즈니스 인텔리전스 측정항목에 유용하지만 ML 모델 학습을 위해서는 다른 형식이 필요합니다. 게임에서 ML을 위한 일반적인 사용 사례는 플레이어가 게임에서 처음으로 비용을 지출할 시간을 예측하는 커스텀 모델을 만드는 것입니다. AutoML Tables는 학습 프로세스를 간소화하는 데 도움이 될 수 있습니다. AutoML Tables에 대한 자세한 내용은 학습 데이터 준비 및 학습 데이터 만들기 권장사항을 참조하세요.

많은 게임 스튜디오 및 출판업체들이 학습 기초로 daily-rollup 형식을 사용함으로써 성과를 얻었습니다. 일일 롤업은 각각의 중요한 애널리틱스 이벤트에 대해 하나의 필드를 포함하는 정규화된 행 형식입니다. 행 형식에는 플레이어가 지금까지 이벤트를 트리거한 횟수에 대한 누적 수가 포함됩니다. 이 행은 true 또는 false has made a purchase 플래그와 함께 플레이어가 지금까지 트리거한 잠재적으로 중요한 모든 이벤트에 대한 일별 스냅샷을 제공합니다.

AutoML Tables 빠른 시작 설명서에 설명된 프로세스를 수행하면 이 방식으로 형식이 지정된 데이터로 학습할 때 높은 품질의 모델을 얻을 수 있습니다. 그런 후 모델에 일별 롤업 행을 제공하고 플레이어가 구매를 수행할 가능성에 대한 예측을 제공할 수 있습니다. 또한 앱 제거 또는 기타 플레이어 행동을 포함하여 다른 예측을 수행하도록 모델을 학습하기 위해 다른 여러 플래그와 함께 형식 지정 데이터에 대해서도 비슷한 접근 방식을 사용할 수 있습니다. 정규화된 데이터 형식을 빌드하기 위해 초기 비용을 투자하면 원하는 모든 플레이어 행동을 예측하기 위한 모델들을 빠르게 시험해볼 수 있습니다. 이 모델링은 게임의 환금성을 높이고 원하는 플레이어 결과를 얻을 수 있는 기능을 우선적용하는 데 잠재적인 도움을 줄 수 있습니다.

Google Cloud 게임 분석 솔루션

다음 단계

온라인 게임을 위한 솔루션도 일반적인 패턴을 따릅니다. 즉, 클라이언트가 서비스와 게임 서버라는 프런트엔드에 전달을 하면 프런트엔드가 이를 분석 및 상태 스토리지라는 백엔드로 전달합니다. 이러한 각각의 구성 요소를 온프레미스, 클라우드, 또는 이 두 가지가 혼합된 형태에서 실행할 수 있습니다. 더 구체적인 패턴에 관해서는 게임 솔루션을 참조하세요.

Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기