padroneggiare sempre di pi\u00f9 l\u2019argomento<\/a>. <\/p>\n\n\n\nIn beSharp non ci accontentiamo di comprendere. Noi vogliamo sperimentare. Perfezionare. Sporcarci le mani nei contesti pi\u00f9 estremi, quelli in cui anche i nerd pi\u00f9 accaniti penserebbero che siamo pazzi (true story\u2026 ma non ce la prendiamo :D). <\/p>\n\n\n\n
E cos\u00ec, qualche tempo fa, in un crescendo di smanettamento sempre pi\u00f9 estremo, abbiamo assemblato il primo racing simulator by beSharp: volante direct-drive da 32 Nm di coppia, pedali con smorzatori idraulici progettati per resistere a oltre 140 kg di pressione, sedile racing con cinture a 6 punti e, soprattutto, una piattaforma di movimento a 4DOF per riprodurre la dinamica del veicolo e le asperit\u00e0 del tracciato. <\/p>\n\n\n\n
Non contenti, abbiamo costruito pezzo per pezzo anche un hardware super-carrozzato<\/strong> che abbiamo subito iniziato a maltrattare installandoci sopra \u201cAssetto Corsa Competizione\u201d, uno dei software di simulazione di guida pi\u00f9 fedeli mai costruiti. <\/p>\n\n\n\nLa parte veramente interessante di questo progetto – nonch\u00e9 la pi\u00f9 challenging – \u00e8 stata per\u00f2 riuscire a intercettare da \u201cAssetto Corsa\u201d il maggior numero possibile di metriche<\/strong>, di portarle efficientemente sul Cloud con un sistema di ingestion<\/strong> e, infine, visualizzarle a schermo in real-time<\/strong> durante la corsa. Una figata, vero?<\/p>\n\n\n\nD\u2019altro canto, anche Galileo Galiei lo aveva detto: \u201cMisura ci\u00f2 che \u00e8 misurabile, e rendi misurabile ci\u00f2 che non lo \u00e8\u201d.<\/p>\n\n\n\n
Si sa, noi ci ispiriamo solo ai migliori \ud83d\ude09 <\/p>\n\n\n\n
E\u2019 proprio sull\u2019aspetto Cloud della soluzione che ci concentreremo in questo articolo. Vi racconteremo nel dettaglio come abbiamo combinato i servizi di AWS per progetti data-centrici fino ad arrivare ad un risultato soddisfacente secondo i nostri standard.<\/p>\n\n\n\n
Cominciamo!<\/p>\n\n\n\n
Le sfide tecniche incontrate<\/h2>\n\n\n\n
L’obiettivo principale da tenere a mente durante la progettazione e lo sviluppo \u00e8 sempre stato solo uno: le performance<\/strong>.<\/p>\n\n\n\nQuindi dovevamo trovare un modo rapido per estrarre tutte le metriche di cui avevamo bisogno dal software che ci permetteva di girare nelle piste pi\u00f9 veloci del mondo.<\/p>\n\n\n\n
Bene, come punto di partenza avevamo un noto software di simulatore di guida, che utilizziamo per divertirci virtualmente su pista. Da qui nasce la prima sfida tecnica.<\/p>\n\n\n\n
Il simulatore di guida utilizzato \u00e8 infatti pensato per essere installato ed eseguito per giocarci, non per integrarsi con applicazioni terze.<\/p>\n\n\n\n
Ma girando nei pi\u00f9 remoti spazi di internet, unendo pezzi di documentazione presi qua e l\u00e0, ci siamo riusciti! Abbiamo scoperto che il software espone un server UDP locale nativamente.<\/p>\n\n\n\n
Il protocollo UDP, tra l\u2019altro, faceva al caso nostro, dovendo estrarre dati runtime con performance super ottimali!<\/p>\n\n\n\n
Ok perfetto, nulla di pi\u00f9 facile, allora creiamo un connettore in Python, estraiamo ed \u00e8 fatta no? Sarebbe stato bellissimo ma molte metriche mancavano, quindi dovevamo cercare un altra strada.<\/p>\n\n\n\n
Non ci siamo fatti abbattere e dopo altre ore di ricerche forse avevamo la risposta: prenderle direttamente dalla RAM<\/strong>.<\/p>\n\n\n\nAbbiamo trovato degli indirizzi di memoria che venivano scritti con tutti i dati di cui avevamo bisogno, direttamente dal software del simulatore.<\/p>\n\n\n\n
Quindi siamo partiti a sviluppare un piccolo script in Python che estrae i dati binari e li converte in modo da vedere se c’\u00e8 tutto quello di cui abbiamo bisogno.<\/p>\n\n\n\n
Eureka! Questa volta avevamo tutto.<\/p>\n\n\n\n
Abbiamo concluso questa prima parte aggiungendo al nostro script di estrazione dati una parte che prende tutti i dati, li impacchetta in JSON e li spedisce in cloud.<\/p>\n\n\n\n
S\u00ec, ma dove in Cloud?<\/p>\n\n\n\n
L’archittettura su AWS<\/h2>\n\n\n\nIngestion<\/h3>\n\n\n\n
Se siete dei lettori abituali saprete bene che a noi di beSharp fa impazzire la progettazione di infrastrutture cloud altamente performanti, scalabili e affidabili. In questo progetto abbiamo trovato pane per i nostri denti.<\/p>\n\n\n\n
La prima cosa alla quale pensare \u00e8: quale servizio scegliere come porta di ingresso nel cloud?<\/p>\n\n\n\n
Le possibilit\u00e0 a nostra disposizione erano molteplici: potevamo gestire tutto il flusso dei dati proveniente dal simulatore con uno stream Kinesis o con un cluster Fargate ad esempio.<\/p>\n\n\n\n
Entrambe le soluzione sarebbero state scalabili e performanti ma queste strade avrebbero portato a dover sviluppare e gestire una componente software che smistasse il traffico in base ai dati in input.<\/p>\n\n\n\n
Queste soluzioni non rispettavano pienamente i criteri di qualit\u00e0 infrastrutturale che ci eravamo posti, noi volevamo un infrastruttura interamente Event Driven e Serverless, in grado di garantire un’ elevata scalabilit\u00e0 e l’integrazione gestita out of the box con un’ampia gamma di servizi AWS.<\/p>\n\n\n\n
Abbiamo trovato queste caratteristiche nel servizio IoT Core<\/strong>.<\/p>\n\n\n\nLe caratteristiche che hanno fatto vincere questo servizio rispetto agli altri sono: <\/p>\n\n\n\n