Questa Guida aiuta i clienti a riunire diversi tipi di set di dati e a unirli in un'unica vista consolidata. I clienti di AWS Game Tech possono creare un profilo comportamentale completo dei propri giocatori per ottenere ulteriori informazioni riguardo all'interazione tra giocatori e gioco, la partecipazione alla community di gioco e la socializzazione con altri giocatori. Il Cohort Modeler classifica e aggrega le metriche dei giocatori in raggruppamenti composti da singoli giocatori, in base a diversi tipi di dati metrici, tra cui metriche di gioco, comportamenti di gioco e transazioni finanziarie. Una comprensione più approfondita del comportamento dei giocatori è alla base delle continue decisioni di progettazione e sviluppo.
Diagramma dell'architettura
[Descrizione del diagramma dell’architettura]
Fase 1
I server e i client di gioco utilizzano sensori per valutare le azioni dei giocatori, tra cui comportamenti inappropriati, lo stile del giocatore e gli acquisti all'interno del gioco. Queste azioni vengono registrate in modo dichiarativo con l'API Cohort Modeler al fine di raccogliere dati sulla progressione dei giocatori, sulla creazione della community, sulla fidelizzazione e altro ancora.
Fase 2
I consumatori di dati memorizzano i suggerimenti sui contenuti ed eseguono query dell'API. I consumatori di dati includono soluzioni di intelligenza artificiale e machine learning (IA/ML) nonché servizi di matchmaking che mettono in contatto i giocatori.
Fase 3
Gateway Amazon API ospita un'API Cohort Modeler basata su risorse per interagire con i vertici e gli spigoli del grafo.
Fase 4
AWS Lambda soddisfa le richieste fatte all'endpoint API, converte le richieste HTTP/S in query su grafo Gremlin e le invia al database.
Fase 5
Amazon Neptune è un database a grafo interamente gestito che archivia i dati e le interazioni dei giocatori.
Fase 6
Gli utenti aziendali possono utilizzare un notebook Jupyter ospitato sul cloud AWS per esplorare in modo interattivo le coorti dei giocatori.
Fase 7
Gli sviluppatori possono modificare e implementare l'esempio di codice Cohort Modeler utilizzando il Modello di applicazione serverless AWS (AWS SAM), basato su AWS CloudFormation.
Fase 1
I server e i client di gioco utilizzano sensori per valutare le azioni dei giocatori, tra cui comportamenti inappropriati, lo stile del giocatore e gli acquisti all'interno del gioco. Queste azioni vengono registrate in modo dichiarativo con l'API Cohort Modeler al fine di raccogliere dati sulla progressione dei giocatori, sulla creazione della community, sulla fidelizzazione e altro ancora.
Fase 2
I consumatori di dati memorizzano i suggerimenti sui contenuti ed eseguono query dell'API. I consumatori di dati includono soluzioni di intelligenza artificiale e machine learning (IA/ML) nonché servizi di matchmaking che mettono in contatto i giocatori.
Fase 3
Gateway Amazon API ospita un'API Cohort Modeler basata su risorse per interagire con i vertici e gli spigoli del grafo.
Fase 4
AWS Lambda soddisfa le richieste fatte all'endpoint API, converte le richieste HTTP/S in query su grafo Gremlin e le invia al database.
Fase 5
Amazon Neptune è un database a grafo interamente gestito che archivia i dati e le interazioni dei giocatori.
Fase 6
Gli utenti aziendali possono utilizzare un notebook Jupyter ospitato sul cloud AWS per esplorare in modo interattivo le coorti dei giocatori.
Fase 7
Gli sviluppatori possono modificare e implementare l'esempio di codice Cohort Modeler utilizzando il Modello di applicazione serverless AWS (AWS SAM), basato su AWS CloudFormation.
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.
-
Eccellenza operativaLeggi il whitepaper sull'eccellenza operativa
La telemetria dei componenti di applicazioni, dei carichi di lavoro e dell'infrastruttura è accessibile tramite Amazon CloudWatch Logs. Tutte le metriche operative relative allo stato di integrità sono accessibili tramite CloudWatch. L'applicazione stessa tiene traccia della telemetria degli utenti e delle transazioni tramite API di importazione e query.
-
SicurezzaLeggi il whitepaper sulla sicurezza
Tutti i dati risiedono in Neptune e sono crittografati quando sono a riposo. Tutti i dati di importazione in blocco (dati non API) risiedono su Amazon Simple Storage Service (Amazon S3) e sono crittografati anche quando sono a riposo. I dati in transito sono crittografati tramite un endpoint VPC dedicato a cui solo Neptune ha accesso. Tutti i dati delle query (tramite l'API) vengono crittografati in transito utilizzando Transport Layer Security (TLS)/HTTPS.
-
AffidabilitàLeggi il whitepaper sull'affidabilità
L'architettura è disaccoppiata utilizzando un modello a tre livelli di accesso, da Gateway API a Lambda a Neptune. Ogni livello è scalabile in modo indipendente ed è caratterizzato da elevata disponibilità. Inoltre, i livelli sono stateless e consentono limiti per i tentativi automatici. Ogni livello invia singolarmente i log a CloudWatch per l'analisi. L'architettura viene fornita come infrastructure as code (IaC) tramite CloudFormation. CloudFormation gestisce eventuali aggiornamenti, rollback o errori.
-
Efficienza delle prestazioniLeggi il whitepaper sull'efficienza delle prestazioni
I servizi di questa architettura offrono dimensionamento automatico e previsione lineare dei costi. Neptune possiede alcune funzionalità per esplorare e determinare la modellazione delle relazioni tra giocatori e coorti. L'architettura utilizza anche un notebook Jupyter di riferimento contenente esempi di codice e fornisce istruzioni dettagliate sull'importazione, query e modellazione dei dati
-
Ottimizzazione dei costiLeggi il whitepaper sull'ottimizzazione dei costi
L'architettura riduce al minimo i costi di trasferimento dati dalla regione AWS addebitando le risposte alle query API solo per le informazioni dettagliate sui giocatori. Di conseguenza, i costi di trasferimento dati vengano sostenuti solo per i servizi utilizzati nell'architettura e non per l'importazione dei dati. Inoltre, è possibile prevedere i costi in base ai precedenti utilizzi.
-
SostenibilitàLeggi il whitepaper sulla sostenibilità
I servizi di questa soluzione sono serverless, il che elimina la necessità dell'hardware. In generale, Neptune supporta funzionalità serverless. In questa architettura, utilizziamo una versione di Neptune che non è serverless ma che utilizza comunque una quantità minima di hardware necessaria per garantirne l'affidabilità.
Risorse per l'implementazione
Viene fornita una guida dettagliata da sperimentare e utilizzare all'interno del tuo account AWS. Ogni fase della creazione della guida, inclusa l'implementazione, l'utilizzo e la pulizia, viene esaminata per prepararla all'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.
Contenuti correlati
Informazioni dettagliate sulla base dei giocatori utilizzando AWS for Games Cohort Modeler
AWS for Games Cohort Modeler: modello di dati a grafo
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.