Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

GAMEOPS03-BP04 Adotta una strategia di distribuzione che riduca al minimo l'impatto sui giocatori

Incorpora una strategia di implementazione per il software e l'infrastruttura di gioco che riduca al minimo i tempi di inattività che impediscono ai giocatori di giocare. Sebbene alcuni tipi di aggiornamenti possano richiedere l'installazione di nuovi aggiornamenti nel client di gioco, progetta il gioco in modo da ridurre al minimo o evitare i tempi di inattività durante le distribuzioni.

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all’implementazione

Uno dei passaggi più importanti da considerare quando si sviluppa una strategia di distribuzione del gioco è determinare come verrà gestita l'infrastruttura di gioco. Gestisci la tua infrastruttura di gioco utilizzando uno strumento Infrastructure as Code (IaC) come AWS CloudFormationTerraform di Hashicorp per ridurre gli errori umani durante la preparazione dell'ambiente. I modelli di infrastruttura possono essere implementati e testati in pipeline automatizzate, il che crea coerenza nella configurazione dei diversi ambienti di gioco.

Esistono diverse strategie di distribuzione che possono essere utilizzate per un gioco:

Sostituzione rotativa

L'obiettivo principale di una sostituzione a rotazione in caso di schieramento è effettuare il rilascio senza interrompere il gioco e senza influire sui giocatori. È importante che l'aggiornamento o le modifiche da eseguire siano compatibili con le versioni precedenti e funzionino in modo adiacente alle versioni precedenti del sistema.

In questa distribuzione, le istanze del server vengono sostituite in modo incrementale (sostituite o implementate) da istanze che eseguono la versione aggiornata. Questa sostituzione progressiva può essere eseguita in diversi modi. Ad esempio, per implementare aggiornamenti continui a una flotta di server di gioco dedicati, un approccio tipico prevede la creazione di un nuovo gruppo di EC2 istanze Auto Scaling contenente la nuova versione di build del server di gioco distribuita su di esse, e quindi il routing graduale dei giocatori verso sessioni di gioco ospitate su questo nuovo parco di server. Se è associato un aggiornamento del client di gioco richiesto come prerequisito per utilizzare la nuova build del server di gioco, devi includere un controllo di convalida per verificare che solo i giocatori su cui è installato questo nuovo aggiornamento del client di gioco vengano indirizzati a queste sessioni di gioco.

Le flotte di server (ad esempio, i gruppi di EC2 Auto Scaling) contenenti la vecchia versione di build del server di gioco vengono rimosse dal servizio solo dopo aver esaurito le sessioni attive dei giocatori in modo corretto, in genere impostando metriche personalizzate del server che consentono ai team addetti alle operazioni di gioco di automatizzare questo processo. In alternativa, per ridurre la quantità di infrastruttura e il tempo necessario per eseguire un'implementazione continua, è possibile adottare un approccio alternativo in cui le istanze di produzione esistenti vengono rimosse dal servizio, aggiornate con la nuova build del server di gioco e quindi reinserite nel parco macchine di produzione. Questo approccio riduce la quantità di infrastruttura richiesta, ma aumenta anche il rischio, poiché il numero di server di gioco live disponibili per i giocatori viene ridotto man mano che i server vengono sostituiti.

Questo modello può essere utilizzato anche per eseguire distribuzioni continue su servizi di backend come database, cache e server di applicazioni che non ospitano il gameplay. Purché questi servizi siano distribuiti in modo altamente disponibile con più istanze cluster, la complessità delle implementazioni su questi servizi dovrebbe essere inferiore a quella delle implementazioni su server di gioco dedicati.

Implementazione blu/verde

L'obiettivo principale di una blue/green distribuzione in un gioco è ridurre al minimo i tempi di inattività, garantendo al contempo un ripristino sicuro della distribuzione precedente in caso di problemi. È adatto per implementazioni in cui due versioni del backend di gioco sono compatibili e possono servire i giocatori contemporaneamente.

Nella strategia blue/green di distribuzione, vengono configurati due ambienti identici (blu e verde). La versione del gioco esistente è etichettata in blu, mentre la nuova versione del gioco, che rappresenta l'obiettivo di distribuzione, è etichettata in verde. Quando l'ambiente verde è pronto per la migrazione, è possibile configurare il livello di routing in modo da trasferire il traffico verso l'ambiente verde, mantenendo al contempo disponibile il vecchio ambiente (blu) nel caso in cui sia necessario un failback. In questo scenario, gli aggiornamenti del routing potrebbero richiedere l'aggiornamento del servizio di matchmaking per configurarlo per iniziare a inviare sessioni di gioco alla nuova flotta o, nel caso dei servizi di backend di gioco, potrebbe riguardare l'aggiornamento dei record DNS in Amazon Route 53 per il tuo servizio o lo spostamento dei pesi del load balancer delle applicazioni per inviare traffico al nuovo gruppo target.

Uno degli svantaggi della strategia di blue/green implementazione è il costo intrinseco dell'ambiente di standby dovuto all'infrastruttura aggiuntiva richiesta durante l'esecuzione dell'installazione. Un'opzione per mitigare questo costo aggiuntivo dell'infrastruttura consiste nel prendere in considerazione l'adozione di una variante di blue/green implementazione in cui il nuovo software di gioco venga distribuito sugli stessi server già distribuiti in produzione. In questo scenario, è possibile avviare un nuovo processo server verde con il nuovo software accanto al processo server blu esistente, con il passaggio tra i processi del server anziché tra un'infrastruttura fisica separata. Questo approccio può anche velocizzare l'implementazione dei giochi su una grande quantità di infrastruttura, eliminando la necessità di attendere il lancio di nuovi server nel cloud. Per le best practice su questo approccio di implementazione, consulta Blue/Green Deployments on. AWS

Implementazione delle Canarie

L'implementazione di Canary è utile per gli sviluppatori di giochi, in quanto la strategia può essere applicata per rilasciare una versione alpha o beta anticipata di un gioco o una funzionalità di gioco come una nuova modalità di gioco, mappa o sfida a un gruppo ristretto o ristretto di giocatori in produzione. Tale schieramento si chiama canarino. La versione potrebbe includere funzionalità di tracciamento e segnalazione aggiuntive, quindi quando giocatori reali giocano a quel gioco o a quella funzionalità, i dati di telemetria di gioco vengono raccolti e analizzati per individuare eventuali anomalie e problemi.

Per quanto riguarda le nuove funzionalità, i giocatori non vengono costantemente informati in merito e la telemetria del gioco è la fonte principale utilizzata per determinare se i giocatori stanno riscontrando problemi e la versione deve essere annullata. Allo stesso tempo, se non vengono identificati problemi significativi, la funzionalità può essere ulteriormente estesa a più giocatori per ottenere dati aggiuntivi. Se i giocatori vengono avvisati, può essere chiesto loro di fornire un feedback regolare sulla loro esperienza. Tale attività di test sarebbe idealmente coordinata da un team operativo in diretta.

Come strategia, Canary Deployment può essere utilizzato anche per le versioni standard per rendere gradualmente disponibile una nuova funzionalità ai giocatori. Un potenziale vantaggio rispetto all' blue/green ambiente standard è che non è richiesto un secondo ambiente completo. La capacità del nuovo ambiente ridimensionato determina il numero di giocatori che devono essere integrati nella nuova funzionalità. Prima di aggiungere altri giocatori, la capacità deve essere ridimensionata in modo appropriato. Anche se si prevede che questa blue/green tecnica personalizzata avrà un costo comparativamente inferiore rispetto alla tecnica blu/verde standard, si stima comunque che comporti costi che potrebbero essere superiori a quelli della tecnica di sostituzione a rotolamento dei canarini.

Utilizzate un solo canarino in un ambiente di produzione e concentratelo per raccogliere dati e feedback. Se vengono utilizzati più canarini, ciò complica la risoluzione e l'isolamento dei problemi di produzione e compromette la qualità dei set di dati e del feedback raccolti.

Una variante del canary si verifica quando uno o più esperimenti (generalmente test dell'interfaccia utente) vengono eseguiti tramite implementazioni mirate, in cui un set di server di backend di gioco serve una versione di una funzionalità e un altro set delle stesse dimensioni serve un'altra versione della stessa funzionalità. A tale scopo non viene creata alcuna infrastruttura aggiuntiva o speciale e solo le aree prescelte dei server di backend ricevono questi aggiornamenti. Il risultato degli esperimenti consiste nell'osservare come i giocatori reagiscono a ciascuna delle versioni della stessa funzionalità, determinare se esiste un consenso generale di gradimento o antipatia e osservare se ci sono problemi identificati con l'usabilità o la funzionalità. Tali esperimenti strategici sono anche chiamati A/B test e l'intero processo è chiamato test A/B. Al termine di questi esperimenti, vengono raccolti i dati di test necessari prima di tornare alla versione corrente del sistema di backend di gioco sui server utilizzati per i test.

Implementazioni tradizionali precedenti

Nello stile di implementazione tradizionale, durante una finestra di manutenzione programmata il gioco viene chiuso e i giocatori connessi vengono abbandonati o esauriti prima che le istanze del server all'interno del backend di gioco vengano aggiornate con le ultime build di codice. Questa distribuzione ha un impatto sui giocatori ogni volta che viene eseguita e i giocatori devono essere avvisati prima del programma. Di conseguenza, questo modello causa il maggior impatto sui giocatori e dovrebbe essere evitato quando possibile.

Dopo l'installazione dell'aggiornamento, è possibile testare il gioco prima di aprirlo ai giocatori, che aspetterebbero la riapertura del gioco. Ciò può causare un picco di traffico quando i giocatori cercano di accedere e giocare entro un breve periodo di tempo. Pertanto, se il gioco non è progettato per gestire tali picchi di traffico, puoi scegliere di consentire ai giocatori di rientrare gradualmente in gioco in batch.

In alternativa, puoi optare per un sovradimensionamento dell'infrastruttura per sostenere il picco di traffico iniziale e, una volta che il traffico di gioco si sarà stabilizzato, le risorse potranno essere ridotte. Se necessario, esegui questo tipo di schieramento durante le ore non di punta, quando il numero di giocatori è minimo. La manutenzione programmata frequentemente, così come la manutenzione prolungata, comporta intrinsecamente un rischio di abbandono dei giocatori e una potenziale perdita di entrate. I giocatori si aspettano cambiamenti anche dopo una nuova versione e possono perdere la fiducia nel gioco una volta rientrati dopo un periodo di inattività.

Passaggi dell’implementazione