클라우드 게임 인프라 개요

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

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

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

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

고수준 구성 요소

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

이미지

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

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

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

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

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

프런트엔드

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

예를 들어 세션 기반의 1인칭 슈팅 게임에서 프런트엔드 서비스는 일반적으로 무작위 대결 서비스를 의미합니다. 이 서비스는 전용 게임 서버 인스턴스에 관한 연결 정보를 게임 클라이언트에 배포합니다. 게임 클라이언트는 인터넷을 통해 무작위 대결 서비스에 요청을 전송합니다. 게임 클라이언트는 무작위 대결 서비스로부터 연결 정보가 포함된 응답을 수신하고 나면 사용자 데이터그램 프로토콜(UDP)을 사용하여 전용 게임 서버 인스턴스에 직접 연결할 수 있습니다.

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

게임 플랫폼 서비스

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

플랫폼 서비스의 예:

  • 리더 보드 및 경기 기록
  • 무작위 대결
  • 온라인 로비
  • 채팅
  • 인벤토리 관리
  • 승인
  • 파티/그룹
  • 프로필
  • 길드
  • 교차 플랫폼 잠금 해제
  • 피드
  • 소셜 ID 매핑
  • 분석
  • 상태

게임 플랫폼 서비스를 위한 소프트웨어 설계 전략과 웹 서비스에서 제공하는 기능 및 API는 유사한 패턴으로 진화했다는 점에서 서로 비슷합니다.

  • 2000년대 초반, 일반적인 플랫폼 서비스 제품군은 대개 싱글톤으로 구현되는 모놀리식 서비스로 실행되곤 했습니다. 제휴를 하더라도 이러한 패턴은 클라우드 배포에 권장되지 않습니다.

  • 2000년대 중반에는 여러 서비스가 독립적으로 확장 가능하도록 업계가 변화됨에 따라 지금은 이미 친숙한 서비스 지향 아키텍처 패턴(SOA)이 대중화되었습니다. 게다가 이제는 게임 클라이언트와 서버뿐 아니라 웹 서비스, 더 나아가서는 스마트폰 앱에서도 서비스에 액세스할 수 있습니다.

  • 지난 5년 동안에는 많은 개발자가 확장성이 뛰어난 웹 기업들이 옹호하는 마이크로 서비스 접근법을 채택하였습니다. 플랫폼 서비스와 웹 애플리케이션의 여러 가지 근본적인 과제는 개발 주기를 짧게 만들고 전 세계에 걸쳐 배포성이 우수한 서비스를 운영하는 것 등등 서로 동일합니다. 마이크로 서비스는 이러한 문제를 해결하는 데 도움이 될 수 있으며 애플리케이션을 클라우드 플랫폼에서 실행되도록 설계할 때 훌륭한 선택이 될 수 있습니다.

  • 또한, 이제는 플랫폼 서비스 또는 완전 관리형 플랫폼 서비스를 구축하는 방법을 제공하는 여러 호스팅 서비스 또는 관리형 서비스가 있습니다.

백엔드 플랫폼 서비스

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

Google Cloud Platform 플랫폼 서비스 솔루션

다음 솔루션은 Cloud Platform에서 백엔드 서비스를 구축하는 더 자세한 방법을 제공합니다.

전용 게임 서버

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

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

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

전용 게임 서버의 유형

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

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

실시간 시뮬레이션

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

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

이 모든 것이 실시간 시뮬레이션 게임 서버가 게임 서버 설계와 게임이 실행되는 컴퓨팅 플랫폼에 대한 세심한 주의를 필요로 하는, 지연에 민감하고 컴퓨팅 및 대역폭 집약적인 작업 부하를 실행한다는 뜻입니다.

세션 또는 매치 기반 게임

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

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

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

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

요청/응답 기반 서버

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

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

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

간략한 통신 의미 체계와 애플리케이션 또는 네트워크 오류 후 재시도의 용이성과 같은 요청/응답 게임 서버의 강점은 턴제 게임과 모바일 게임에서 원활하게 작용합니다.

게임 세계 상태의 외부화

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

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

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

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

Cloud Platform 전용 게임 서버 솔루션

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

백엔드

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

게임 데이터베이스

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

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

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

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

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

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

관계형 데이터베이스

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

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

NoSQL 데이터베이스

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

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

  • 확장—수평 확장을 염두에 두고 설계되었으며 이를 사용하도록 기본으로 설정되어 있기도 합니다. 클러스터 크기 조정은 일반적으로 다운타임 없이 수행될 수 있는 작업이지만, 때로는 추가 노드가 완전히 통합될 때까지 어느 정도의 성능 손실이 발생하기도 합니다.

  • 스키마 변경—스키마가 동적이고 애플리케이션 레이어에 의해 시행됩니다. 이것은 커다란 이점으로, 새 게임 기능을 위해 새 필드를 추가하는 작업이 간단할 수 있다는 뜻입니다.

  • 관리—대부분의 클라우드 제공업체가 최소 하나의 호스팅 또는 관리형 NoSQL 데이터 저장소 엔진을 제공하는데, Cloud Platform은 여러 개를 제공합니다

Google Cloud Platform 게임 데이터베이스 솔루션

분석

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

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

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

Google Cloud Platform 게임 분석 솔루션

다음 단계

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

  • 다른 Google Cloud Platform 기능을 직접 사용해 보세요. 가이드를 살펴보세요.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...