Archivio Autore

WeFitter Cloud Architecture





WeFitter (https://www.wefitter.com) è un app mobile che incentiva l’attività fisica premiando le attività quotidiane degli utenti iscritti alla community con sfide settimanali e obiettivi individuali, il tutto integrato tramite API con le principali “Fitness Apps” di terze parti. L’obiettivo di WeFitter, inclusa da Google nel programma per le 500 migliori startup, era di passare da un’infrastruttura monolitica su Digital Ocean ad una totalmente dinamica e flessibile su Google Cloud.

La progettazione e il deploy online su GCP hanno richiesto circa 3 mesi di attività costante, tutta l’infrastruttura di Cloud Computing è tutta “usa e getta” (adoro questo termine…), questo significa, che nel caso estremo in cui tutte le istanze siano cancellate nello stesso momento, il tempo necessario per ripristinare tutta l’infrastruttura è pari al tempo di inizializzazione delle nuove istanze e i rispettivi tempi di boot. Ad ogni boot ognuna delle istanze verifica il suo stato e il tipo di servizio da fornire, in caso di necessità esegue il deploy e la configurazione degli applicativi necessari al corretto funzionamento dei servizi. Tutti i sorgenti degli applicativi sono gestiti da 2 repository distinti, BitBucket per la parte di development e GitLab per la parte di  Continuous Deployment.

Ad Ansible è affidata tutta la gestione e verifica delle istanze e dei servizi necessari per:

  • App Front-end / Back-end
  • Job scheduler
  • WordPress website e blog
  • Caching System (Redis)

I Front-end sono configurati su webserver Nginx su cui sono stati apportate modifiche per migliorarne le performance e l’efficienza, in particolare sono stati assegnati un numero di processi sempre disponibili pari al numero medio di richieste giornaliere, così facendo il carico della macchina rimane più stabile rispetto ad una gestione variabile dei processi (carico / scarico) nel corso della giornata, il grafico di monitoraggio di CPU e RAM non presenta picchi ed è più semplice notare anomalie.

Cloud SQL


La gestione del database relazionale MySQL è affidata a Cloud SQL, servizio in grado di fornire supporto anche per la replica dei dati su un database server slave in modalità failover, soluzione utilizzata anche come READ Replica per i backend dell’applicazione principale (API last release). L’accesso al database da parte di tutta l’infrastruttura di Computing Engine è garantito da Cloud SQL Proxy. La parte di autenticazione è gestita tramite permessi impostati su Google IAM ma soprattutto l’utilizzo di questo componente risulta fondamentale per la gestione delle connessioni da parte dei gruppi di auto-scaling con IP temporaneo.

Networking


L’accesso da internet è configurato con Google CDN e Google Load Balancer, diverse regole (Forwarding Rules) pre-impostante manualmente consentono di redirigere il traffico in base all’indirizzo di destinazione tra API requests, Webpages public / private, blog, third party web sites (resource reselling) and so on… Come consuetudine tutta la parte di Front-end rimane esposta a internet, comunque protetta dal Firewall di Google, mentre la parte di Back-end rimane privata tramite private subnetwork (no legacy!).

Una delle caratteristiche che impongo sempre alle mie architetture scalabili è quella di essere impostata su un modello master-group, ciò rappresenta che il mio servizio X che deve rispondere ai requisiti di alta affidabilità e alta disponibilità, gestito da un sistema di auto-scaling, è distribuito su un’istanza master, di solito con elevata capacità di lavoro, e ad un gruppo di istanze in modalità auto-scaling, ognuna di queste con capacità di lavoro ridotte rispetto al master ma utilizzabili in cluster per distribuire il carico su più macchine. In questo modo ottengo un’alta affidabilità del servizio X, ho almeno 2 istanze che lavorano in cluster e il bilanciatore si occupa di gestire la distruzione del carico / traffico, e ottengo un’alta disponibilità in quanto, se la capacità del master non dovesse essere sufficiente, il gruppo in auto-scaling associato si occuperà di aumentare o diminuire le risorse quando si renderà necessario.

Security


La sicurezza di tutta l’infrastruttura è garantita dagli interventi effettuati prima del rilascio online e tramite aggiornamenti periodici automatizzati (Ansible). Sul Firewall sono state controllate tutte le porte incrociandole con i servizi presenti sull’infrastruttura in cloud e abilitando solo quelle strettamente necessarie (closed by design), l’accesso ai servizi riservati è assicurato solo da certe reti private, così come l’accesso al DB da remoto è possibile sono tramite IP/subnet autenticata.

Prima del rilascio online sono stati eseguiti diversi stress-test con il fine di individuare la corretta configurazione per i diversi servizi coinvolti nella gestione del traffico, tra questi troviamo Load Balancer e le regole di Balancing mode (RPS), auto-scaling groups (2 per 2 differenti compiti) e il carico massimo assimilabile, in questo ultimo caso è stato molto utile valutare il comportamento dell’applicazione stessa in caso di carico estremo.

Google Next 2017 – Milano

Come ogni anno anche in Italia Google organizza il Google Next, evento dedicato al 100% alle tecnologie in cloud, ovvero tutte le principali tecnologie di Google. 
I vantaggi di un’architettura bilanciata sono molteplici e garantiscono un’elevata affidabilità dei nostri servizi online grazie al numero variabile di nodi disponibili.