Local blog for Italian speaking developers
Dietro le quinte con il backend GCP di Dragon Ball Legends
23 luglio 2018
Pubblicato da Samir Hammoudi, Gaming Technical Specialist, Google Cloud
Dragon Ball Legends
, il nuovo gioco per dispositivi mobili di Bandai Namco Entertainment (BNE), è basato sul popolare franchise
Dragon Ball Z
ed è stato lanciato da pochissimo per i gamer di tutto il mondo. La pianificazione originale dell'infrastruttura cloud per alimentare il gioco risale al febbraio 2017, quando BNE si è rivolta a Google Cloud per parlarci di alcune problematiche che stava affrontando e in quale modo avremmo potuto aiutare.
In base alla domanda prevista, BNE aveva tre esigenze ambiziose per il proprio gioco:
Massima scalabilità
. Per lanciarlo a livello globale, il gioco necessitava di un backend che potesse essere scalabile per milioni di giocatori e continuare a funzionare correttamente.
Rete globale
. Il gioco consente battaglie giocatore-contro-giocatore in tempo reale, quindi doveva basarsi su una rete affidabile e a bassa latenza in tutte le regioni.
Analisi dei dati in tempo reale
. Il gioco è progettato per evolversi in tempo reale insieme ai giocatori, quindi è stato fondamentale avere una pipeline di analisi dei dati per lo streaming dei dati in un data warehouse. In questo modo il team operativo può misurare e valutare come giocano le persone e adattarsi alle esigenze di ogni momento.
Noi siamo molto esperti in tutte e tre le aree. Google dispone di molteplici servizi globali con oltre un miliardo di utenti e usiamo i dati generati da tali servizi per migliorarli nel tempo. Poiché
Google Cloud Platform
(GCP) viene eseguita sulla stessa infrastruttura di questi servizi Google, i clienti GCP possono usufruire delle stesse tecnologie potenti.
Diamo un'occhiata a come BNE ha collaborato con Google Cloud per creare l'infrastruttura di Dragon Ball Legends.
Problematica n.1: massima scalabilità
MySQL è ampiamente utilizzato dalle aziende di videogiochi in Giappone. Gli ingegneri sono abituati ad adoperare database relazionali con schema, query SQL e coerenza forte. Il lato applicazione è molto semplificato: non è necessario gestire le limitazioni del database, come la coerenza finale o l'imposizione dello schema. MySQL è ampiamente utilizzato anche in altri settori e molti ingegneri di backend lo conoscono bene.
Offre molti vantaggi, ma ha un grande limite: la scalabilità. Infatti per incrementare le prestazioni di MySQL, bisogna aggiungere più CPU, RAM o disco. Se una singola istanza di MySQL non può più gestire il carico, puoi dividere il carico partizionando gli utenti in gruppi e assegnandoli a più istanze indipendenti di MySQL. Tuttavia partizionare presenta alcuni inconvenienti. La maggior parte degli sviluppatori di giochi calcola il numero di shard necessari per il database prima dell'avvio del gioco, poiché la partizione è laboriosa e soggetta a errori. Ciò causa l'overprovisioning del database per gestire infine più giocatori del previsto. Se il gioco è popolare come ci si aspetta, non ci sono problemi. Ma se il gioco è un successo travolgente e supera tutte le aspettative? Come ci comportiamo con la lunga coda che rappresenta la diminuzione graduale dei giocatori attivi? E se fosse un vero e proprio flop? La partizione di MySQL non è scalabile dinamicamente, e regolare le sue dimensioni comporta modifiche e rischi.
Teoricamente i database possono essere scalabili senza tempi di inattività e offrire al tempo stesso i vantaggi del database relazionale. Quando ci è giunta voce che BNE stava valutando la partizione di MySQL per gestire l'enorme traffico previsto per Dragon Ball Legends, abbiamo suggerito invece di prendere in considerazione Cloud Spanner.
Perché Cloud Spanner?
Cloud Spanner è un database relazionale completamente gestito che offre scalabilità orizzontale e alta disponibilità pur mantenendo una forte coerenza con uno schema simile a quello di MySQL. E, meglio ancora, è un servizio gestito da
Google SRE
, che elimina la manutenzione del database riducendo al minimo il rischio dei tempi d'inattività. Secondo noi, Cloud Spanner avrebbe aiutato BNE a rendere il gioco globale.
Dalla valutazione all'implementazione
Prima di adottare una nuova tecnologia, gli ingegneri dovrebbero sempre testarla per confermare le prestazioni attese nello scenario reale. Prima di sostituire MySQL, BNE ha creato una nuova istanza di Cloud Spanner in GCP, incluse alcune tabelle con uno schema simile a quello utilizzato in MySQL. Poiché i loro sviluppatori di backend usavano Scala, hanno scelto la
libreria client Java per Cloud Spanner
e hanno scritto alcuni esempi di codice per testare il carico di Cloud Spanner. In questo modo potevano verificare se riuscivano a tenere il passo con le query al secondo (QPS) per le scritture, con picchi di circa 30.000 QPS. Grazie alla collaborazione tra l'ingegnere del cliente e i team di ingegneri Cloud Spanner hanno raggiunto facilmente questo obiettivo. Hanno persino sviluppato il proprio wrapper
DML (Data Manipulation Language)
per scrivere comandi SQL come INSERT, UPDATE e DELETE.
Rilascio del gioco
Una volta ottenuto il proof-of-concept, si poteva procedere con l'implementazione. In base agli utenti attivi giornalieri attesi (DAU), hanno calcolato il numero di nodi Cloud Spanner necessari, sufficienti per tutti i giocatori preregistrati previsti. Per prepararsi al rilascio hanno organizzato due beta test chiusi che convalidassero il backend e non hanno avuto un solo problema con il database! Oltre tre milioni di partecipanti in tutto il mondo si erano preregistrati per Dragon Ball Legends, e nonostante il numero pazzesco, il rilascio ufficiale del gioco è andato benissimo.
In breve, ora BNE può concentrarsi sul miglioramento del gioco piuttosto che doversi occupare dei propri database.
Problematica n.2: rete globale
Parliamo ora della seconda sfida per BNE: la creazione di un gioco globale giocatore-contro-giocatore (PvP) in tempo reale. L'obiettivo di BNE per Dragon Ball Legends era permettere a tutti di giocare l'uno contro l'altro, ovunque si trovassero. Se sai qualcosa sull'utilizzo di rete, pensi immediatamente ai problemi di latenza. Ad esempio, il Round Trip Time (RTT) tra Tokyo e San Francisco è mediamente di circa 100 ms. Per risolverlo, BNE ha deciso di dividere ogni secondo del gioco in intervalli di 250 ms. Pertanto, anche se agli utenti il gioco sembra essere in tempo reale, in realtà è un gioco a turni velocissimi (ulteriori informazioni sull'architettura
qui
). Alcuni potrebbero sostenere che 250 ms sono più che sufficienti per la latenza, ma è estremamente difficile prevedere la latenza durante la comunicazione su Internet.
Perché Cloud Networking?
Ecco come un game client accede al game server su GCP su Internet. Dato che il numero di hop può variare ogni volta, giocare in modalità PvP può sembrare a volte veloce, a volte meno.
Una delle ragioni principali per cui BNE ha deciso di utilizzare GCP per il backend di Dragon Ball Legends è stata la
rete dedicata di Google
. Come puoi vedere dall'immagine qui sotto, quando usi GCP, una volta che il game server accede a uno dei centinaia di Points Of Presence (POP) di GCP in tutto il mondo, è sulla rete dedicata di Google. Ciò significa niente hop imprevedibili con latenza e prevedibilità più basse possibile.
Come sfruttare Google Cloud Network
Di solito le aziende di videogiochi implementano il PvP connettendo direttamente due giocatori o tramite un game server dedicato. Generalmente i giochi di combattimento che richiedono una latenza bassa tra i giocatori preferiscono la comunicazione P2P. Quando due giocatori sono geograficamente vicini, il P2P funziona molto bene, ma non necessariamente quando sono in regioni diverse (alcuni vettori addirittura bloccano i protocolli P2P). Per consentire a due giocatori in continenti diversi di comunicare attraverso la rete dedicata di Google, devono prima comunicare tramite P2P e, se ciò non riesce, eseguono il failover su un'implementazione open source di STUN/TURN Server chiamata
coturn
che funge da relay tra due giocatori. In questo modo, le battaglie tra continenti sfruttano il più possibile la rete Google, che è affidabile e a bassa latenza.
Problematica n.3: analisi dei dati in tempo reale
L'ultima sfida per BNE era l'analisi dei dati in tempo reale. BNE voleva offrire la migliore esperienza possibile ai propri utenti, e un modo per farlo erano le operazioni di gioco live, o LiveOps, in cui gli operatori apportano continui cambiamenti al gioco per farlo risultare sempre nuovo. Ma per comprendere le esigenze dei giocatori, BNE aveva bisogno di dati: i dati del log delle azioni degli utenti. Ottenendo questi dati quasi in tempo reale, poteva quindi prendere decisioni su quali modifiche apportare al gioco per incrementare la soddisfazione e il coinvolgimento degli utenti.
A questo fine, BNE ha utilizzato una combinazione di Cloud Pub/Sub e Cloud Dataflow per trasformare i dati degli utenti in tempo reale e inserirli in BigQuery.
Cloud Pub/Sub offre un sistema di messaggistica affidabile a livello globale che memorizza i log in modo che possano essere gestiti da Cloud Dataflow.
Cloud Dataflow è un servizio di elaborazione parallela completamente gestito che consente di eseguire ETL in tempo reale e in parallelo.
BigQuery è il data warehouse totalmente gestito in cui sono archiviati tutti i log di gioco. Poiché BigQuery offre archiviazione in termini di petabyte, la scalabilità non era un problema. Grazie alla solida elaborazione parallela nelle query dei log, BNE può ottenere una risposta a una query scansionando terabyte di dati in pochi secondi.
Questo sistema consente a un'azienda di visualizzare il comportamento dei giocatori quasi in tempo reale e decidere quali nuove funzionalità apportare o cosa modificare all'interno del gioco per soddisfare i propri fan.
Risultati
Usando Cloud Spanner, BNE si è potuta concentrare sullo sviluppo di un fantastico gioco invece che sulla scalabilità o sulla capacità del database.
Dal punto di vista delle operazioni, il database scalabile completamente gestito consente di ridurre drasticamente i rischi legati all'errore umano oltre che a un sovraccarico operativo.
Usando il Cloud Networking, BNE ha sfruttato la rete dedicata di Google per offrire la migliore esperienza utente ai propri fan, anche quando "combattono" in regioni diverse.
Infine, utilizzando lo stack di analisi di Google (Cloud PubSub, Cloud Dataflow e BigQuery), BNE ha potuto analizzare i comportamenti dei giocatori quasi in tempo reale e prendere decisioni su come modulare il gioco per soddisfarli ancora di più!
Se desideri ulteriori dettagli su come BNE ha valutato e adottato Cloud Spanner per questo gioco, puoi seguire la sessione di
Google Cloud NEXT’18
a San Francisco.
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly
