Questa guida aiuta gli sviluppatori di giochi a implementare una pipeline di analisi codificata, modulare e serverless che acquisisce eventi di telemetria dai client di gioco e dai servizi di backend. La guida affronta sia i casi d'uso dell'analisi quasi in tempo reale che dell'analisi in batch. Con il Kit AWS CloudFormation (AWS CDK), è possibile integrare e implementare continuamente la pipeline su più account e regioni AWS. Inoltre, i servizi serverless descritti in questa guida offrono un approccio economico allo sviluppo di giochi. Dopo aver implementato questo modello di guida, sarai pronto per raccogliere e interrogare i dati dei giocatori, acquisire informazioni dettagliate e migliorare il tuo gioco.

Nota: [Disclaimer]

Diagramma dell'architettura

Scarica il diagramma dell'architettura (PDF) 
  • Architettura

  • Questo diagramma dell'architettura mostra una panoramica per una pipeline DataOps modernizzata. Per la pipeline di integrazione e implementazione continua (CI/CD) di DataOps, aprire l'altra scheda.

  • CI/CD di DataOps

  • Questo diagramma dell'architettura mostra una pipeline di CI/CD di DataOps. Per una panoramica della pipeline DataOps modernizzata, aprire l'altra scheda.

Principi di Well-Architected

Il framework AWS Well-Architected consente di valutare i pro e i contro delle decisioni prese durante il processo di creazione di sistemi nel cloud. I sei principi del framework consentono di apprendere le best practice architetturali per la progettazione e il funzionamento di sistemi affidabili, sicuri, efficienti, convenienti e sostenibili. Grazie allo strumento AWS Well-Architected, disponibile gratuitamente nella Console di gestione AWS, puoi rivedere i tuoi carichi di lavoro rispetto a queste best practice rispondendo a una serie di domande per ciascun principio.

Il diagramma dell'architettura sopra riportato è un esempio di una soluzione creata tenendo conto delle best practice Well-Architected. Per essere completamente Well-Architected, dovresti seguire il maggior numero possibile di best practice.

  • Gli strumenti di sviluppo AWS, in particolare CodeBuild, CodeCommit e AWS CodePipeline, abilitano il CI/CD (integrazione e distribuzione continue) dell'intera architettura come applicazione codificata. Ciò significa che tutte le operazioni possono essere eseguite modificando il codice. Inoltre, la pipeline CI/CD esegue test automatici del sistema di queste modifiche – all'interno della fase di QA – per garantire che potenziali errori possano essere verificati preventivamente, prima che vengano implementate in produzione. La registrazione operativa di ogni componente dell'architettura viene inviata a CloudWatch insieme alle notifiche SNS per avvisare gli amministratori di eventuali problemi operativi e di implementazione.

    Questi strumenti sono stati scelti non solo per consentire agli operatori di avere informazioni dettagliate sull'architettura, ma anche per fornire un controllo granulare sull'implementazione iniziale della guida e sulle modifiche successive. Ciò significa che gli operatori possono monitorare le modifiche, confermare che siano pronte per la produzione e annullare eventuali modifiche che influenzino la produzione, senza impattare l'esperienza degli utenti.

    Leggi il whitepaper sull'eccellenza operativa 

  • Ogni provider di telemetria (data producer) riceve una chiave di accesso (archiviata in DynamoDB) per accedere e inviare i dati di telemetria a Gateway API, il che significa che solo i data producer autorizzati ricevono le chiavi di accesso. Fornire un'unica fonte per l'archiviazione delle chiavi di autenticazione consente di affidarsi allo stesso processo di autenticazione per la gestione dell'API e delle risorse AWS implementate dalla guida. Le applicazioni di backend possono interagire in modo sicuro con l'API della guida utilizzando credenziali AWS temporanee.

    Inoltre, tutti gli eventi di telemetria inviati tramite Gateway API vengono crittografati durante il transito e tutti i dati degli eventi di telemetria che vengono archiviati in Amazon S3 vengono crittografati quando sono inattivi.

    Leggi il whitepaper sulla sicurezza 

  • Questa guida prevede due livelli di resilienza: a livello regionale e globale. Tutti i componenti regionali dell'architettura utilizzano funzionalità serverless di AWS. Le funzionalità serverless aiutano a garantire che ogni servizio continui a fornire le funzionalità richieste in più zone di disponibilità (AZ), purché che non si verifichino errori regionali. In caso di errore regionale, è possibile distribuire nuovamente la guida in un'altra regione AWS o anche in un altro account AWS.

    Leggi il whitepaper sull'affidabilità 

  • I componenti serverless, come Gateway API, contribuiscono a rendere questa guida adeguatamente flessibile e scalabile per soddisfare i requisiti di prestazione dei provider di telemetria. Inoltre, Amazon Kinesis offre prestazioni praticamente in tempo reale per l'analisi di flussi di dati. In aggiunta, l'implementazione della guida come applicazione codificata consente agli utenti di sperimentare grazie alla possibilità di aggiungere automaticamente le fasi DEV, TEST e QA.

    Leggi il whitepaper sull'efficienza delle prestazioni 

  • AWS Glue consente il crawling automatico dello schema dei dati, compensando la pratica di strutturare lo schema corretto per l'analisi, particolarmente dispendiosa in termini di tempo. Infine, strutturando la guida come applicazione codificata, è possibile abbinare i moduli appropriati ai diversi casi d'uso, il che contribuisce a razionalizzare i costi.

    Leggi il whitepaper sull'ottimizzazione dei costi 

  • Sia Amazon S3 che AWS Glue supportano un modello di importazione dei dati basato su eventi serverless. AWS Glue Jobs trasferisce la responsabilità della gestione e dell'ottimizzazione dell'infrastruttura ad AWS. Amazon S3 implementa politiche relative al ciclo di vita dei dati e ottimizza la formattazione e compressione dei file, archiviando tutti i dati inseriti in formato Parquet. Poiché i dati vengono trasformati e archiviati in un formato Parquet compresso, le scansioni dei dati per query vengono ridotte, il che significa che saranno necessarie un minor numero di risorse di calcolo per il carico di lavoro della guida.

    Leggi il whitepaper sulla sostenibilità 

Risorse per l'implementazione

Il codice di esempio è un punto di partenza. È convalidato dal settore, prescrittivo ma non definitivo, ed è il punto di partenza per iniziare a lavorare.

Apri codice di esempio su GitHub

Contenuti correlati

[Oggetto]
[Tipo di contenuti]

[Titolo]

[Sottotitolo]
Questo [post sul blog/e-book/guida/codice di esempio] mostra come [inserire una breve descrizione].

Avvertenza

Il codice di esempio, le librerie software, gli strumenti della linea di comando, le proof of concept, i modelli e le altre tecnologie correlate (comprese tutte le tecnologie di cui sopra fornite dal nostro personale) vengono forniti all'utente sotto forma di contenuto AWS ai sensi dell'Accordo cliente AWS o del relativo accordo scritto stipulato tra l'utente e AWS (a seconda dei casi). Non bisogna utilizzare il contenuto AWS in questione negli account di produzione o sui dati di produzione o altri dati fondamentali. L'utente è responsabile dei test, della sicurezza e dell'ottimizzazione del contenuto AWS, come il codice di esempio, in modo appropriato per l'utilizzo in produzione sulla base delle pratiche e degli standard di qualità specifici. L'implementazione del contenuto AWS può comportare costi AWS per la creazione o l'utilizzo di risorse AWS addebitabili, quali le istanze Amazon EC2 in esecuzione o l'archiviazione Amazon S3.

Eventuali riferimenti a servizi o organizzazioni di terze parti contenuti in questa guida non implicano alcuna approvazione, sponsorizzazione o affiliazione tra Amazon o AWS e dette terze parti. La guida di AWS è un punto di partenza tecnico e l'integrazione con servizi di terze parti può essere personalizzata al momento dell'implementazione dell'architettura.