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 distribuzione del software e dell'infrastruttura di gioco che riduca al minimo i tempi di inattività che impediscono ai giocatori di partecipare al gioco. Sebbene alcuni tipi di aggiornamenti possano richiedere l'installazione di nuovi aggiornamenti sul 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 CloudFormation Terraform 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 progressiva

L'obiettivo principale di una sostituzione progressiva per lo schieramento è eseguire il rilascio senza chiudere il gioco e senza influire sui giocatori. È importante che l'aggiornamento o le modifiche da eseguire siano retrocompatibili e funzionino in modo adiacente alle versioni precedenti del sistema.

In questa distribuzione, le istanze del server vengono sostituite (sostituite o implementate) in modo incrementale 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 Auto Scaling di istanze EC2 contenente la nuova versione di build del server di gioco distribuita su di esse, e quindi indirizzare gradualmente i giocatori alle sessioni di gioco ospitate su questa nuova flotta di server. Se è richiesto un aggiornamento del client di gioco associato 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 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 per i server che consentono ai team operativi di gioco di automatizzare questo processo. In alternativa, per ridurre la quantità di infrastruttura e il tempo necessario per eseguire un'implementazione progressiva, è 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 di produzione. Questo approccio riduce la quantità di infrastruttura necessaria, ma aumenta anche il rischio, poiché il numero di server di gioco live disponibili per i giocatori si riduce 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 applicativi che non ospitano il gameplay. Se questi servizi vengono distribuiti in modo altamente disponibile con più istanze in cluster, la complessità delle implementazioni su questi servizi dovrebbe essere inferiore rispetto alle distribuzioni su server di gioco dedicati.

Blue/green distribuzione

L'obiettivo principale di un' blue/green implementazione in un gioco è ridurre al minimo i tempi di inattività e consentire al contempo il ripristino sicuro della distribuzione precedente se vengono identificati problemi. È adatto per implementazioni in cui due versioni del backend del gioco sono compatibili e possono essere utilizzate dai giocatori contemporaneamente.

Nella strategia blue/green di distribuzione, vengono configurati due ambienti identici (blu e verde). La versione del gioco esistente è contrassegnata in blu, mentre la nuova versione del gioco che è l'obiettivo dello schieramento è etichettata in verde. Quando l'ambiente verde è pronto per la migrazione, puoi configurare il livello di routing in modo da trasferire il traffico verso l'ambiente verde mantenendo il vecchio ambiente (blu) disponibile 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 in modo da iniziare a inviare sessioni di gioco alla nuova flotta o, nel caso dei servizi di backend di gioco, potrebbe essere 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 tuo nuovo gruppo target.

Uno degli svantaggi della strategia di blue/green distribuzione è il costo intrinseco dell'ambiente di standby dovuto all'infrastruttura aggiuntiva richiesta durante l'esecuzione dell'implementazione. Un'opzione per mitigare questo costo aggiuntivo dell'infrastruttura è prendere in considerazione l'adozione di una variante di blue/green distribuzione in cui il nuovo software di gioco viene distribuito sugli stessi server già distribuiti in produzione. In questo scenario, è possibile avviare un nuovo processo basato sul server ecologico con il nuovo software insieme al processo blue server esistente, con il cutover tra i processi del server anziché tra infrastrutture fisiche separate. Questo approccio può anche velocizzare l'implementazione dei giochi su una grande quantità di infrastrutture eliminando la necessità di attendere il lancio di nuovi server nel cloud. Per le migliori pratiche su questo approccio di distribuzione, vedi Blue/Green Deployments on. AWS

Dispiegamento nelle Canarie

L'implementazione di Canary è utile per gli sviluppatori di giochi, poiché la strategia può essere applicata per rilasciare una versione alpha o beta anticipata di un gioco o una funzionalità del gioco, come una nuova modalità di gioco, una nuova mappa o una sfida, per un numero limitato o limitato di giocatori in produzione. Tale distribuzione si chiama canarino. La versione potrebbe includere funzionalità di tracciamento e segnalazione aggiuntive, quindi quando giocatori reali giocano a quel gioco o a quella funzione, i dati di telemetria relativi al 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 riscontrano problemi e la versione dovrebbe 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 ricevono una notifica, può essere chiesto loro di fornire un feedback regolare sulla loro esperienza. Tale attività di test sarebbe idealmente coordinata da un team operativo dal vivo.

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 è necessario un secondo ambiente completo. La capacità del nuovo ambiente ridotto determina il numero di giocatori che saranno coinvolti 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 abbia un costo relativamente inferiore a quello standard blue/green, si stima comunque che comporti costi che potrebbero essere superiori a quelli della tecnica di sostituzione progressiva delle installazioni canarie.

Esegui un solo Canary in un ambiente di produzione e concentralo sui dati e sui feedback. L'implementazione di più canaries 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 canarino si verifica quando uno o più esperimenti (generalmente test dell'interfaccia utente) vengono eseguiti attraverso implementazioni mirate, in cui un set di server di backend del gioco utilizza una versione di una funzionalità e un altro set della stessa dimensione utilizza un'altra versione della stessa funzionalità. A tale scopo non viene creata alcuna infrastruttura aggiuntiva o speciale e solo i server di backend selezionati ricevono questi aggiornamenti. Il risultato degli esperimenti è 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 la sua usabilità o 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 del gioco sui server utilizzati per i test.

Implementazioni tradizionali obsolete

Nello stile di distribuzione tradizionale, durante una finestra di manutenzione programmata il gioco viene chiuso e i giocatori connessi vengono eliminati 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 previsto. Di conseguenza, questo modello provoca il maggior impatto sui giocatori e dovrebbe essere evitato quando possibile.

Una volta implementato l'aggiornamento, il gioco può essere sottoposto a un test di fumo prima di aprirlo ai giocatori, che aspetterebbero la riapertura del gioco. Ciò può causare un picco di traffico quando i giocatori tentano 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 gradualmente ai giocatori di rientrare in gioco in gruppi.

In alternativa, puoi optare per un provisioning eccessivo 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 implementazione durante le ore non di punta, quando il numero di giocatori è minimo. La manutenzione programmata frequentemente, così come la manutenzione prolungata, comporta intrinsecamente il rischio di abbandono dei giocatori e di una potenziale perdita di entrate. I giocatori si aspettano dei cambiamenti anche dopo una nuova release e possono perdere la fiducia nel gioco una volta rientrati dopo un periodo di inattività.

Passaggi dell’implementazione