이 문서에서는 Google Cloud에서 API 기반 모바일 게임 백엔드를 실행하기 위한 권장사항을 설명합니다. 이 문서에서는 게임 개발자가 모바일 게임의 온라인 아키텍처를 설계하기 위한 시작 지점으로 사용할 수 있는 참조를 제공합니다. 이 문서의 권장사항은 모든 유형의 모바일 게임에 적용될 수 있습니다. 하지만 이 문서에서는 플레이어 진행 상태 및 계정 정보를 데이터베이스에 저장하고 게임 개발자가 작성한 커스텀 인터페이스 API를 통해 데이터에 액세스하는 게임을 중심으로 설명합니다.
이 문서는 Niantic의 Pokemon Go, Nintendo의 Super Mario Run, King의 Candy Crush Saga와 같은 모바일 비디오 게임을 개발하는 팀을 대상으로 합니다. 이 문서의 권장사항은 일반적인 웹 앱 또는 소셜 앱과 같은 규모에 해당하는 확률 게임(카드 게임 및 카지노 게임) 또는 판타지 스포츠 앱(예: 판타지 풋볼)을 대상으로 하지 않습니다.
게임의 조회 중심 특성으로 인해 사용량이 많은 시간대에 수요가 크게 증가할 수 있습니다. 앱 스토어 또는 스트리밍 커뮤니티에 앱에 등록될 가능성이 높으므로 성공적인 재해 시나리오를 설정하고 게임 인기가 높아졌을 때 확실한 확장 경로를 준비하는 것이 중요합니다. 개발 중 정보에 입각한 결정을 통해 위험을 최소화할 수 있습니다.
예상되는 사용자 부하 예측
모바일 게임의 온라인 백엔드를 설계할 때는 사용자 부하를 예측하는 것이 매우 중요합니다. 예상 부하에 맞게 대부분의 리소스가 사용되도록 아키텍처를 설계하면 더 큰 게이머 커뮤니티에서 인기를 얻었을 때 그러한 수요를 충족시킬 수 없어서 실패할 수 있습니다. 확장에 실패하면 수익 가능성과 스튜디오 평판에 영향을 줄 수 있습니다. 예상 부하에 맞게 실행되는 아키텍처를 설계하더라도 예기치 못한 성공을 위해 확실한 확장 경로를 준비하는 것은 어려운 도전과제일 수 있습니다.
사용자 부하 예상은 항상 많은 데이터를 기반으로 이뤄지지만, 두 가지 핵심 범주를 포함합니다.
- 플레이어 수와 플레이 세션 빈도: 이것은 일반적으로 업계 유사 게임의 플레이어 수와 마케팅 지출을 통해 사용자를 확보하기 위한 예산을 기반으로 예상될 수 있습니다.
- 각 플레이어의 API 부하: 이것은 포괄적인 부하 테스트를 통해 측정될 수 있습니다.
초기 예상 수행
초기 예상을 수행할 때는 다음과 같이 사용 가능한 모든 요소들을 고려합니다.
- 업계에서 이전 게임 또는 유사 게임의 성공 정도
- 모든 포함된 지적 재산(IP)의 인기도
- 업계 출시 시기
- 앱 포트폴리오에서 나머지 부분의 사전 등록 또는 상호 프로모션 수
- 마케팅 예산
사용자 수를 예상한 후에는 예상 값의 4배에 해당하는 최적 사례 시나리오를 만드는 것이 일반적입니다. 하지만 입소문을 타거나 기타 예상치 못한 방식으로 성공을 거두는 성공-재해 상황을 고려하는 것이 좋습니다. 일부 스튜디오는 사용자 예상 값을 10배로 증가시키지만, Google Cloud에서 이전에 출시된 게임들은 예상값보다 20배 이상 증가했으며 심한 경우 40배까지 증가한 경우도 있었습니다. 이러한 값이 실현성이 높지는 않아도, 이러한 값을 계산하고 아키텍처가 해당 수준으로 확장될 수 있는지 확인할 만한 가치가 있습니다.
부하 테스트 실행
예상 사용자 수를 아는 것만으로는 모바일 게임의 확장 수요를 이해하는 데 충분하지 않습니다. 가능한 한 실제 상황과 밀접한 조건을 이용해서 부하 테스트를 실행하는 것이 중요합니다. 부하 테스트는 거의 최종 버전에 해당하는 게임과 클로즈 베타 테스터를 사용해서 실행되어야 합니다. 부하 테스트를 수행하면 상태 스토리지 데이터베이스의 프로필 성능과 API 레이어를 통해 사용 가능한 여유 공간이 충분한지 확인할 수 있습니다. 실제 사용자는 개발자가 예측할 수 없는 사용 패턴을 만드는 경우가 많습니다. 따라서 대규모 부하 테스트의 모델로 사용할 수 있도록 일부 라이브 플레이어 사용 프로파일링을 얻는 것이 중요합니다. 이전 섹션에서 계산한 초기 예상에 따라 결정된 규모로 베타 테스트에서 사용자 패턴을 복제하기 위해 부하 테스트 프레임워크를 사용하는 것이 좋습니다.
대규모 부하 테스트를 실행할 때는 Google Cloud 영업팀에 연락하여 스트레스 테스트를 계획한 기간 동안 적절한 클라우드 고객 관리 티켓을 등록합니다. 고객 관리 티켓을 등록하면 필요에 따라 할당량 상향 조정을 사전적으로 요청할 수 있습니다. 또한 Google Cloud 제품이 예상한 방식으로 작동하지 않을 때 고객 관리 엔지니어로부터 질문에 대한 답변을 얻을 수 있습니다.
참조 아키텍처를 사용한 검증
다음 다이어그램은 이 문서의 권장사항을 위한 참조 아키텍처를 제공합니다.
이전 다이어그램에서 게임 클라이언트는 부하 분산기를 통해 모바일 게임 백엔드에 연결합니다. 백엔드는 플레이어 레코드 데이터베이스에 직접 연결되며, 플레이어 진행 상태, 사용 권한, 기타 데이터를 저장 및 검색하는 선택적인 고속 캐시 레이어를 포함합니다. 백엔드는 작업 측정항목 및 로그를 Google Cloud Observability로 전송합니다. 측정항목 및 로그는 백엔드 성능을 모니터링하는 데 핵심적이며, 데이터 웨어하우스에 액세스할 수도 있습니다. 애널리틱스 전문가가 BigQuery를 사용하여 데이터 웨어하우스에 직접 액세스할 수 있고 AutoML을 사용하여 소비 및 앱 제거 예측에 사용되는 모델을 생성할 수 있습니다. 그런 후 이러한 예측을 게임 백엔드에 제공할 수 있습니다. 다음 구성요소에 대해서는 이 문서의 뒷부분에서 자세히 설명합니다.
- 클라이언트 대면 API에 사용되는 컴퓨팅
- 상태 스토리지에 사용되는 데이터베이스
- Google Cloud Observability 관측 가능성 및 모니터링
- 분석
일부 모바일 게임은 전용 게임 서버 또는 TURN/STUN 서버를 사용하여 실시간 멀티플레이어를 제공합니다. 이 문서의 권장사항에는 이러한 서버가 명시적으로 포함되지 않지만, 해당 방식이 게임 서버와 호환됩니다.
컴퓨팅 옵션
Google Cloud는 App Engine과 같은 완전 관리형 확장 옵션부터 Google Kubernetes Engine(GKE)과 같은 완전 맞춤설정 가능한 환경까지 모바일 게임 백엔드에 대해 몇 가지 컴퓨팅 옵션을 제공합니다. 자신의 요구를 자세히 이해하고 그에 맞게 결정하는 것이 중요합니다. 다음 섹션의 모든 옵션은 Cloud Load Balancing과 완전히 통합되므로, HTTP(S) 트래픽에서 원활한 확장을 활용할 수 있습니다. 이 옵션에는 또한 엔터프라이즈급 DDoS 보호와 같은 Google Cloud Armor 기능이 포함되어 있습니다.
입증된 확장 가능한 서버리스에 대해 App Engine 사용
App Engine은 기본 인프라를 관리할 필요 없이 코드 작성에 집중할 수 있게 해주는 Gogole Cloud의 완전 관리형 서버리스 플랫폼입니다. 게임 요구에 맞게 확장하도록 App Engine을 구성할 수 있습니다. 또한 단일 명령어로 소스에서 직접 빌드 및 배포를 수행하여 개발자가 빠르게 반복 작업을 수행하도록 지원합니다. App Engine은 인프라 확장 작업 관련 경험이 적거나 제한된 팀에게 이상적입니다. 이것은 Nintendo, Madfinger Games, Pocket Gems,, Backflip Studios에서 출시된 게임을 포함하여 많은 모바일 게임 출시를 통해 대규모로 입증되었습니다.
App Engine이 내 게임에 적합한지 여부를 평가할 때는 플레이어의 쿼리 비율을 기준으로 인스턴스를 시작하거나 중지할 수 있는지를 이해하는 것이 중요합니다. 따라서 서비스 설계 시 사용자 요청 간에 상태를 메모리 내에 유지하도록 계획하지 않아야 합니다. 요청 간에 상태를 유지해야 할 경우, 해당 상태를 상태 스토리지 데이터베이스(다음 섹션 참조)에 저장하고 검색하거나 Memorystore(Memcached 또는 Redis)와 같은 별개의 캐시를 사용해야 합니다.
App Engine 앱은 다른 런타임 환경에서 효율적으로 실행되기 위해 추가 시간 또는 리소스가 필요할 수 있습니다. 멀티 클라우드 또는 하이브리드 클라우드 환경에 배포될 수 있는 단일 런타임 대상이 필요한 경우에는 대신 Cloud Run 또는 Google Kubernetes Engine이 권장됩니다.
새 서버리스 앱에 Cloud Run 사용
Cloud Run을 사용하면 Kubernetes 클러스터를 관리할 필요 없이 게임 백엔드를 위해 컨테이너로 새 앱을 개발할 수 있습니다. Cloud Run은 플레이어 기반의 요청 수요를 충족하도록 API 컨테이너를 자동으로 확장할 수 있습니다. 인프라를 추상화하고, 선택한 구성에 따라 확장이 자동으로 처리되는 완전 관리형 런타임 환경을 포함하여 App Engine의 많은 이점을 제공합니다. 공개 표준 Knative를 기반으로 하기 때문에 Cloud Run을 사용할 때 이동성 서비스를 더 쉽게 작성할 수 있습니다. Cloud Run 앱은 Kubernetes의 컨테이너에서 실행됩니다. 이것은 이후에 더 많은 제어가 필요할 때 자체 관리형 Kubernetes로 이동하기 위한 명확한 경로를 제공합니다.
워크로드 완전 제어를 위한 GKE 사용
Google Kubernetes Engine은 더 많은 제어가 필요하거나 숙련된 운영 팀과 함께 작업하는 개발자들을 위한 옵션입니다. 팀에서 이미 앱 스택을 위해 Kubernetes가 사용되는 경우 GKE를 사용하면 동일한 Kubernetes 인터페이스 및 명령줄 인터페이스(CLI)를 사용하여 기존 서비스와 함께 게임 백엔드를 실행할 수 있습니다. 여러 클라우드에서 또는 온프레미스로 앱을 실행하려는 경우 GKE는 클라우드(클라우드 기반 앱)용으로 빌드된 앱을 위한 단일 대상 플랫폼을 제공합니다. Pokémon GO를 포함하여 많은 게임들이 GKE를 사용해서 대규모로 성공적으로 출시되었습니다.
상태 스토리지 데이터베이스
모바일 게임을 위한 데이터베이스를 선택할 때는 증가하는 플레이어 기반과 늘어나는 게임 복잡성 문제를 확장 및 관리할 수 있는 방법을 고려해야 합니다. Spanner 및 Firestore는 다양한 기능을 제공하며, 관리형 경험을 제공하고, 입증된 대규모 모바일 게임 성공 사례를 갖고 있습니다. Google Cloud는 또한 관리형 MySQL 데이터베이스인 Cloud SQL을 제공합니다. 하지만 Cloud SQL은 수동 데이터베이스 샤딩 또는 클러스터링이 상태 스토리지 레이어에 상당한 어려움과 복잡성을 일으킬 수 있고, 그 결과 원치 않는 다운타임 및 고객 영향으로 이어질 수 있기 때문에 어려울 수 있습니다.
사용자 간 거래가 지원되는 글로벌 게임에 Spanner 사용
Spanner는 무제한 규모, strong consistency, 최대 99.999% 가용성을 지원하는 완전 관리형 관계형 데이터베이스입니다. 관계형 데이터베이스 작업 경험이 있는 개발자들을 위해 SQL 시맨틱스 및 유사한 인터페이스를 제공합니다. Spanner는 전역적으로 배포될 수 있지만, 리전별로 액세스될 수 있습니다. 따라서 분산 복제본 성능과 함께 단일 데이터베이스 인스턴스의 단순성을 지원합니다.
Spanner는 무한 규모를 제공하므로 플레이어 프로필 및 인벤토리 스토리지에 적합합니다. 또한 게임 고객을 위해 신뢰할 수 있는 플레이어 간 거래 또는 경매장 기능을 제공할 수 있는 트랜잭션 보장을 제공합니다. Spanner는 개발자 온보딩 및 데이터베이스 관리를 위해 여러 가지 마이그레이션, 개발, 관측 가능성, 점검 도구를 제공합니다. Spanner는 수백만 건의 초당 쿼리 수(QPS)까지 점진적으로 확장됩니다. 하루 예상 QPS가 1,000을 넘는 것과 같은 대규모 실행을 위해서는 준비 및 벤치마킹에 대한 권장사항을 따르는 것이 좋습니다.
Spanner는 사용자 수가 10억 명에 달하는 사용 사례로 확장할 수 있으며 필요한 성능을 충족하기 위해 확장을 관리하는 유연성을 제공합니다. Spanner는 모바일 게임 공간에서 상당히 많이 사용되고 있습니다. 게임에서 이를 사용하기 위한 방법은 게이밍 데이터베이스로 Spanner를 사용하기 위한 권장사항을 참조하세요.
개발 속도 및 낮은 운영 오버헤드를 위한 Firestore 사용
Firestore는 확장 가능한 완전 관리형 NoSQL 문서 데이터베이스입니다. 효율적인 개발자 환경을 제공하며, 새 정보를 저장해야 할 때 스키마 업데이트가 필요하지 않습니다. 또한 strong consistency, 트랜잭션 보장, 최대 99.999% 가용성을 제공합니다. 또한 Firestore는 Firebase 클라이언트 라이브러리를 사용하는 모바일 게임에서 직접 액세스될 수 있습니다.
일반적인 접근 방법은 플레이어별로 단일 Firestore 문서를 사용하고 게임 설계에 맞게 작동하는 계층으로 모든 진행 상태를 해당 문서에 저장하는 것입니다. Firestore를 사용하도록 게임을 설계할 때는 Firebase 제한사항 및 Firestore 권장사항을 고려하세요. 이러한 권장사항을 기준으로 할 때 동일 문서를 자주 업데이트해야 하는 워크로드는 여기에 적합하지 않습니다. Pokémon GO와 같이 규모가 매우 큰 게임이 Firestore(이전 명칭: Datastore)를 사용하여 성공적으로 출시되었습니다. 이러한 게임들은 예상 플레이어 트래픽의 50배가 넘는 압도적인 수요를 충족시키도록 확장될 수 있었습니다.
Firestore는 확장을 자동으로 처리할 수 있습니다. 하지만 주요 마케팅 행사 이후와 같이 갑작스러운 사용량 증가에 대해 원활한 확장을 보장하기 위해서는 Google Cloud 계정 관리자와 함께 미리 용량 증가를 계획해야 합니다.
성능 최적화로 캐싱 재평가
성능 최적화를 위해서는 데이터베이스 앞에 인메모리 캐시를 배치하는 것이 일반적인 모바일 게임 전략입니다. 인메모리 캐시는 자주 읽혀지는 데이터를 저장하거나 우선순위가 낮은 업데이트를 일괄 처리합니다. 이 전략은 아키텍처에 디자인 복잡성을 추가할 수 있으며, 읽기 및 쓰기 부하를 처리할 수 있는 Spanner 또는 Firestore와 같은 확장 가능한 관리형 데이터베이스에는 필요하지 않은 경우가 많습니다. 데이터베이스 액세스 패턴에 대해 부하 테스트를 수행하고 캐시가 필요하면 관리 오버헤드를 줄이기 위해 Redis용 Memorystore 또는 Memcached와 같은 관리형 옵션을 고려하세요.
규정 준수 요건을 준수하도록 데이터 지역성 선택
전 세계에서 플레이되는 많은 게임들은 GDPR과 같은 현지의 데이터 관련 법률을 준수해야 합니다. GDPR 요건을 준수하려면 Google Cloud 및 GDPR 백서를 참조하고 올바른 Spanner 또는 Firestore 리전 구성을 선택하세요.
관측 가능성
관측 가능성을 조기에 구현하는 것이 좋습니다. 앱 및 백엔드 인프라의 관측 가능성은 문제를 빠르게 찾아서 해결하고, 개발 주기를 빠르게 하고, 문제가 발생했을 때 고객에 대한 영향을 줄이기 위해 중요합니다. 개발을 시작할 때 Google Cloud Observability에 적합한 형식을 채택하면 시간과 비용을 절약할 수 있습니다.
오픈소스 표준을 사용하여 Cloud Monitoring에 앱 측정항목 적용
모든 Google Cloud 리소스는 이미 Cloud Monitoring에 계측이 통합되어 있으며 Google Cloud 콘솔에서 확인 가능합니다. 따라서 Cloud Monitoring와 통합을 위해 모바일 게임 백엔드를 계측하는 것이 좋습니다. Cloud Monitoring과 통합하면 인프라 및 앱을 위해 통합 인터페이스(단일 창구라고도 부름) 모니터링 대시보드를 사용할 수 있습니다. 통합 인터페이스를 사용하면 인터페이스 및 앱에 대해 주요 측정항목을 나란히 확인하고 문제를 빠르게 찾아서 격리시킬 수 있습니다.
커스텀 측정항목 및 분산 추적을 앱에 구현할 때는 이전에 OpenCensus로 알려진 무료 오픈소스 프로젝트인 OpenTelemetry를 사용하는 것이 좋습니다. OpenTelemetry는 여러 언어 간 측정항목 및 추적 수집을 위해 공급업체에 중립적인 지원을 제공하며, Cloud Monitoring 및 Cloud Trace를 포함하여 많은 관측 가능성 제품으로 이를 내보낼 수 있습니다. 자세한 내용은OpenCensus를 사용한 커스텀 측정항목을 참조하세요.
구조화된 로깅 사용
로깅 형식을 선택할 때는 구조화된 로깅을 사용하고 로그 중 관심 부분을 JSON 필드로 정렬하는 것이 좋습니다. 이 구현을 사용하면 Cloud Logging에서 로그를 빠르게 정렬, 검색, 필터링할 수 있습니다. 많은 프로그래밍 언어에 Cloud Logging으로 내보낼 수 있는 인기 있는 구조화된 로깅 라이브러리 또는 모듈이 포함되어 있습니다. Google Cloud에서도 많은 관용적인 Logging 클라이언트 라이브러리가 제공됩니다.
BigQuery 로그 싱크 만들기
로그를 나중에 분석해야 할 경우 또는 해당 운영 리전의 데이터 보관 법률에 따라 이를 유지해야 하는 경우에는 미리 로그에 대해 BigQuery 싱크를 설정합니다. 싱크를 만든 후에 생성되는 새 로그만 BigQuery에 기록됩니다. BigQuery에 대량의 로그 볼륨을 기록하는 경우에는 파티션을 나눈 테이블을 사용하는 옵션을 선택하는 것이 좋습니다.
애널리틱스
나중을 위해 애널리틱스 형식을 지정하는 것이 좋습니다. 게임이 애널리틱스 백엔드에 기록하는 이벤트 및 측정항목을 결정할 때는 인사이트를 얻기 위해 데이터 마이닝을 수행할 때 가장 쉬울 형식을 고려합니다. 추출, 변환, 로드(ETL)를 사용하여 앱에 기록되는 데이터를 애널리틱스 쿼리에 적합한 형식으로 복사할 수 있지만, 이를 위해서는 시간과 비용이 필요합니다. 애널리틱스 출력 형식의 설계에 투자하면 상당한 비용을 절약하고 실시간 애널리틱스 인사이트를 얻을 수 있습니다. Square Enix, King, LINE GAMES의 사용 사례와 프레젠테이션 자료를 검토하는 것이 좋습니다. 이러한 프레젠테이션은 모바일 게임 향상을 위한 Google Cloud 애널리틱스 제품 사용에 대한 실제 세계의 인사이트를 제공할 수 있습니다.
기존 형식에 대한 일괄 처리 사용
타사 통합 또는 서비스의 데이터와 같이 제어할 수 없는 출력 형식의 측정항목 데이터를 분석하려는 경우 측정항목 데이터를 Cloud Storage에 먼저 저장하는 것이 좋습니다. 데이터 형식이 지원되는 경우 BigQuery 인터페이스에서 BigQuery 통합 쿼리를 사용하여 직접 쿼리할 수 있습니다. 데이터 형식이 지원되지 않는 경우에는 ETL을 사용하여 Dataflow 또는 다른 도구를 사용해서 Cloud Storage로 데이터를 복사한 후 다른 소스의 데이터와 함께 BigQuery에 결과 형식 데이터를 저장할 수 있습니다. 실시간으로 데이터가 긴급하게 필요하지 않는 한 스트리밍 대신 일반적인 일괄 작업을 설정하여 비용을 절약하는 것이 좋습니다. 이 접근 방법에 대한 자세한 내용은 애널리틱스 이벤트 및 로그에 대한 대규모 수집 최적화를 참조하세요.
검증된 모델로 앱 제거 및 지출 예측
원격 구석, 앱 내 메시징, Firestore 클라이언트 라이브러리와 같은 많은 다른 기능들 중 하나를 위해 이미 모바일 게임에 Firebase를 사용 중일 수 있습니다. 또한 Firebase는 기본 제공되는 앱 제거 및 지출 예측 머신 러닝(ML) 모델을 제공합니다. 원격 구성 맞춤설정을 통합하여 애널리틱스 데이터에 ML을 적용하고, 사용자의 예측 동작을 기준으로 동적 사용자 세그먼트를 만들 수 있습니다. 이 데이터는 다른 Firebase 기능을 트리거하는 데 사용하거나 추가 유연성을 위해 BigQuery로 내보낼 수 있습니다.
AutoML Tables 커스텀 모델 학습을 위한 데이터 정규화
효율적인 ML 모델을 생성하기 위해서는 일반적으로 관련 기능을 선택하고 초매개변수를 조정하는 등의 광범위한 머신 러닝 전문 기술이 요구됩니다. 하지만 다음 데이터 준비 가이드라인은 이러한 태스크를 처리하고 사용자 대신 유용한 모델을 생성할 수 있도록 최신 자동화 도구의 기능을 향상시켜 줍니다. 모델이 생성된 다음에는 이를 Google Cloud에 호스팅하여 플레이어의 게임 내 구매 또는 게임 종료 예측과 같은 온라인 또는 일괄 예측을 수행할 수 있습니다.
애널리틱스 이벤트와 플레이어 데이터는 기존의 애널리틱스 쿼리 및 비즈니스 인텔리전스 측정항목에 유용하지만 ML 모델 학습을 위해서는 다른 형식이 필요합니다. 모바일 게임에서 ML을 위한 일반적인 사용 사례는 플레이어가 게임에서 처음으로 비용을 지출할 시간을 예측하는 커스텀 모델을 만드는 것입니다. AutoML Tables는 학습 프로세스를 크게 단순화시킬 수 있습니다. 일반적인 개요는 AutoML Tables 문서 학습 데이터 준비 및 학습 데이터 만들기 권장사항을 참조하세요.
많은 게임 스튜디오 및 출판업체들이 학습 기초로 daily-rollup 형식을 사용함으로써 뛰어난 성과를 얻었습니다. daily rollup은 각각의 중요한 애널리틱스 이벤트에 대해 하나의 필드를 포함하는 정규화된 행 형식입니다. 여기에는 플레이어가 해당 일자까지 이벤트를 트리거한 횟수에 대한 누적 수가 포함됩니다. 이 행은 true 또는 false has made
a purchase 플래그와 함께 플레이어가 지금까지 트리거한 잠재적으로 중요한 모든 이벤트에 대한 일별 스냅샷을 제공합니다.
AutoML Tables 빠른 시작 설명서에 설명된 프로세스를 수행하면 이 방식으로 형식이 지정된 데이터로 학습할 때 높은 품질의 모델을 얻을 수 있습니다. 그런 후 이 모델에 daily-rollup 행을 부여하고 플레이어가 구매를 수행할 가능성에 대한 예측을 제공할 수 있습니다. 또한 다른 플래그와 함께 데이터 형식 지정과 비슷한 접근 방법을 사용하여 앱 제거 또는 기타 플레이어 동작을 포함한 여러 예측을 수행하도록 모델을 학습시킬 수 있습니다. 정규화된 데이터 형식을 빌드하기 위해 초기 비용을 투자하면 상상할 수 있는 모든 플레이어 행동을 예측하기 위한 모델들을 빠르게 시험해볼 수 있습니다. 이 모델링은 게임의 환금성을 높이고 원하는 플레이어 결과를 얻을 수 있는 기능을 우선 적용하는 데 잠재적인 도움을 줄 수 있습니다.
Spanner 게임 데이터베이스에서 분석 수행
또한 관리자 및 분석 전문가는 Spanner를 사용하여 게임의 데이터베이스 트래픽에 영향을 주지 않고 데이터에 액세스할 수 있습니다. BigQuery-Spanner 제휴를 사용하면 데이터를 복사하거나 이동하지 않고 BigQuery가 실시간으로 Spanner에 상주하는 데이터를 쿼리할 수 있습니다. 또한 Spanner는 Looker 또는 Google Cloud 콘솔에서 분석할 수 있는 Dataflow 템플릿을 사용하는 데이터 내보내기를 지원합니다.
배포, 알림 및 기타 주제
모바일 게임 개발은 대규모의 방대한 주제입니다. 하나의 가이드로 각각의 요소를 다뤄볼 수는 없지만 다음 섹션에서는 추가적으로 중요한 고려 사항들에 대해 설명합니다.
Cloud CDN을 사용하여 게임 애셋 배포
Cloud CDN은 게임 애셋을 모바일 클라이언트에 배포할 수 있으며, Cloud Monitoring 및 Cloud Logging 통합이 기본 제공됩니다. 기존 공급업체 관계가 있는 경우 대부분의 주요 CDN은 Cloud Storage를 원천 서버로 사용할 수 있습니다.
reCAPTCHA를 사용하여 악용 행동 감소
reCAPTCHA가 기술적으로 백엔드 인프라의 일부는 아니지만 클라이언트에 대한 귀중한 통합 기술이 될 수 있습니다. 앱에서 악용 활동을 줄이기 위해 적응형 챌린지를 사용하고 모바일 게임의 경우에는 자동화된 사용자 등록(봇) 횟수를 줄이기 위해 자주 사용됩니다. 자세한 내용은 reCAPTCHA 문서를 참조하세요.
Firebase 클라우드 메시징을 사용하여 클라우드에 푸시 알림
모바일 게임에서 푸시 알림을 전송해야 하거나 각 사용자에게 메시지 기능을 제공해야 하는 경우에는 Firebase 클라우드 메시징(FCM)을 고려하세요. FCM은 비용 없이 메시지를 안정적으로 전송할 수 있게 해주는 크로스 플랫폼 메시징 서비스입니다. 또한 데이터 메시지를 전송하기 위해 사용될 수 있으며, 앱 코드 내에서 수행되는 작업을 완전하게 결정할 수 있습니다. 자신의 고유 메시징 백엔드 앱을 작성하거나 서버리스 Cloud Functions를 사용하여 메시지를 만들고 Firebase Admin SDK 또는 FCM 서버 프로토콜을 사용하여 이를 전송할 수 있습니다.
게임 구성 배포 단순화
모바일 게임에서 게임 밸런싱에 대한 일반적인 접근 방법은 대부분의 게임플레이 매개변수를 데이터로 정의하는 것입니다. 그런 후 드랍율 또는 무기 공격 스탯과 같은 매개변수를 수정해야 할 때 클라이언트에 업데이트를 안전하게 배포할 수 있습니다. Firebase 원격 구성은 사용자가 앱 업데이트를 다운로드할 필요 없이 앱의 동작 및 모양을 변경할 수 있도록 설계되었습니다. 앱에서 기본값을 정의하고, Firebase Console을 사용하여 또는 원격 구성 백엔드 API에서 프로그래매틱 방식으로 코드 베이스의 모든 세그먼트 또는 특정 세그먼트에 대해 값을 재정의할 수 있습니다.
게임 밸런스를 위한 ML 평가
게임 밸런스를 위한 ML 사용에 대한 연구가 진행되어 GDC에서 제공된 몇 가지 성공적인 사례 연구 및 기타 이벤트가 생성되었습니다. 이러한 사례 연구는 대부분 데이터 과학자 및 ML 엔지니어가 빌드한 커스텀 솔루션으로부터 비롯되며, 숙련된 팀 없이는 쉽게 복제되지 않습니다. 게임 밸런스를 위한 또는 AI 상대로서 ML을 평가하고 싶으면 광범위한 ML 전문 기술 없이도 AutoML Tables와 같은 도구를 통해 커스텀 모델을 사용한 실험을 진행할 수 있습니다. 아이템 또는 다음 이동 선택과 같은 플레이어 동작을 예측하기 위해서는 이 문서 앞부분의 AutoML Tables 모델 학습을 위한 데이터 정규화에 설명된 것과 비슷한 접근 방법을 따릅니다.
다음 단계
- 게임을 위한 Google Cloud
- 클라우드 게임 인프라 개요
- Cloud 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기