Caso di studio: perché utilizzo l'infrastruttura cloud AWS per i miei prodotti

Come piattaforma per l'esecuzione di un prodotto software complesso e impegnativo, AWS offre flessibilità utilizzando le risorse quando necessario, alla scala necessaria. È su richiesta e istantaneo, consentendo il pieno controllo dell'ambiente in esecuzione. Quando si propone una tale soluzione di architettura cloud a un client, l'infrastruttura fornita e il relativo prezzo dipendono fortemente dai requisiti che devono essere configurati in anticipo.

Questo articolo presenterà una di queste architetture di infrastruttura cloud AWS, proposta e implementata per LEVELS, un social network con una funzione di pagamento facciale integrata che trova e applica tutti i vantaggi che gli utenti potrebbero ottenere per i programmi di carte in cui si trovano, le cose che possiedono o i luoghi loro vivono in.

Requisiti

Il cliente aveva due requisiti principali che la soluzione proposta doveva soddisfare:

1. Sicurezza
2. Scalabilità

Il requisito di sicurezza riguardava principalmente la protezione dei dati degli utenti dall'accesso non autorizzato dall'esterno, ma anche dall'interno. Il requisito di scalabilità riguardava la capacità dell'infrastruttura di supportare la crescita del prodotto, adattandosi automaticamente all'aumento del traffico e ai picchi occasionali, nonché il failover e il ripristino automatici in caso di guasti dei server, riducendo al minimo i potenziali tempi di inattività.

Panoramica dei concetti di sicurezza di AWS

Uno dei principali vantaggi della configurazione della tua infrastruttura AWS Cloud è il completo isolamento della rete e il pieno controllo sul cloud. Questo è il motivo principale per cui sceglieresti il ​​percorso Infrastructure as a Service (IaaS), piuttosto che eseguire ambienti Platform as a Service (PaaS) un po' più semplici, che offrono solide impostazioni predefinite di sicurezza ma mancano del controllo completo e granulare che ottieni configurare il proprio cloud con AWS.

Sebbene LEVELS fosse un prodotto giovane quando si sono rivolti a Toptal per i servizi di consulenza AWS, erano disposti a impegnarsi in AWS e sapevano di volere una sicurezza all'avanguardia con la loro infrastruttura, poiché sono molto preoccupati per i dati degli utenti e la privacy. Inoltre, stanno pianificando di supportare l'elaborazione delle carte di credito in futuro, quindi sapevano che avrebbero dovuto garantire la conformità PCI-DSS a un certo punto.

Virtual Private Cloud (VPC)

La sicurezza su AWS inizia con la creazione del tuo Amazon Virtual Private Cloud (VPC), una rete virtuale dedicata che ospita le tue risorse AWS ed è logicamente isolata dalle altre reti virtuali nel cloud AWS. Il VPC ottiene il proprio intervallo di indirizzi IP, sottoreti completamente configurabili, tabelle di routing, elenchi di controllo dell'accesso alla rete e gruppi di sicurezza (in pratica un firewall).

Con LEVELS, abbiamo iniziato isolando il nostro ambiente di produzione dagli ambienti di sviluppo, test e QA. La prima idea era di eseguire ciascuno di essi come il proprio VPC completamente isolato, ciascuno in esecuzione di tutti i servizi richiesti dall'applicazione. Dopo alcune considerazioni, si è scoperto che potevamo consentire una certa condivisione delle risorse tra i tre ambienti non di produzione, il che ha ridotto in una certa misura i costi.

Pertanto, abbiamo optato per l'ambiente di produzione come un VPC, con ambienti di sviluppo, test e QA come un altro VPC.

Accesso all'isolamento a livello di VPC

La configurazione a due VPC isola l'ambiente di produzione dai restanti tre ambienti a livello di rete, assicurando che un'errata configurazione dell'applicazione non sia in grado di oltrepassare tale limite. Anche se la configurazione dell'ambiente non di produzione dovesse puntare erroneamente a risorse dell'ambiente di produzione, come database o code di messaggi, non c'è modo di accedervi.

Con gli ambienti di sviluppo, test e QA che condividono lo stesso VPC, è possibile l'accesso transfrontaliero in caso di configurazione errata, ma, poiché tali ambienti utilizzano dati di test, non esistono reali problemi di sicurezza con la mancanza di isolamento.

Modello di sicurezza del negozio di asset

Le risorse vengono archiviate nello storage di oggetti Amazon Simple Storage Service (S3) . L'infrastruttura di storage S3 è completamente indipendente dai VPC e il suo modello di sicurezza è diverso. Lo storage è organizzato in bucket S3 separati per ogni ambiente e/o classi di asset, proteggendo ciascun bucket con i diritti di accesso appropriati.

Con LEVELS sono state identificate diverse classi di risorse: caricamenti degli utenti, contenuti prodotti da LEVELS (video promozionali e contenuti simili), applicazioni Web e risorse dell'interfaccia utente (codice JS, icone, caratteri), configurazione di applicazioni e infrastrutture e bundle di implementazioni lato server.

Ognuno di questi riceve un bucket S3 separato.

Gestione dei segreti dell'applicazione

Con AWS, c'è un AWS Systems Manager Parameter Store crittografato o AWS Secrets Manager , che sono servizi chiave-valore gestiti progettati per mantenere i segreti al sicuro (puoi saperne di più su Linux Academy e 1Strategy).

AWS gestisce le chiavi di crittografia sottostanti e gestisce la crittografia/decrittografia. I segreti stessi possono avere criteri di autorizzazione di lettura e scrittura applicati in base ai prefissi delle chiavi, sia per l'infrastruttura che per gli utenti (rispettivamente server e sviluppatori).

Accesso SSH al server

L'accesso SSH ai server in un ambiente completamente automatizzato e immutabile non dovrebbe essere affatto necessario. I registri possono essere estratti e inviati a servizi di registrazione dedicati, il monitoraggio viene anche scaricato su un servizio di monitoraggio dedicato. Tuttavia, potrebbe essere necessario un accesso SSH occasionale per l'ispezione della configurazione e il debug.

Per limitare la superficie di attacco dei server, la porta SSH non viene esposta alla rete pubblica. I server vengono raggiunti tramite un bastion host, una macchina dedicata che consente l'accesso SSH esterno, inoltre protetto inserendo nella whitelist solo l'intervallo di indirizzi IP consentito sul firewall. L'accesso è controllato distribuendo le chiavi SSH pubbliche degli utenti nelle caselle appropriate (gli accessi con password sono disabilitati). Tale configurazione offre una porta abbastanza resiliente per il passaggio di malintenzionati.

Accesso al database

Gli stessi principi sopra delineati si applicano ai server di database. Potrebbe anche esserci la necessità occasionale di connettere e manipolare i dati direttamente nel database, sebbene questa non sia assolutamente una pratica consigliata e tale accesso deve essere protetto allo stesso modo in cui è protetto l'accesso SSH dei server.

È possibile utilizzare un approccio simile, utilizzando la stessa infrastruttura host bastion con tunneling SSH. È necessario un doppio tunnel SSH, uno all'host bastion e, attraverso quello, un altro al server che ha accesso al database (l'host bastion non ha accesso al server del database). Attraverso quel secondo tunnel, è ora disponibile una connessione dalla macchina client dell'utente al server di database.

Panoramica sui concetti di scalabilità di AWS

Quando si parla esclusivamente di server, la scalabilità si ottiene piuttosto facilmente con piattaforme più semplici di AWS. Lo svantaggio principale è che alcuni requisiti potrebbero dover essere coperti dai servizi esterni della piattaforma, il che significa che i dati viaggiano attraverso la rete pubblica e infrangono i confini di sicurezza. Rimanendo con AWS, tutti i dati vengono mantenuti privati, mentre la scalabilità deve essere progettata per ottenere un'infrastruttura scalabile, resiliente e tollerante ai guasti.

Con AWS, l'approccio migliore alla scalabilità è sfruttare i servizi AWS gestiti con monitoraggio e automazione testati in battaglia su migliaia di clienti che utilizzano la piattaforma. Aggiungi backup dei dati e meccanismi di ripristino al mix e ottieni molte preoccupazioni dal tavolo semplicemente facendo affidamento sulla piattaforma stessa.

Avere tutto ciò che viene scaricato consente un team operativo più piccolo, compensando in qualche modo il costo più elevato dei servizi gestiti dalla piattaforma. Il team LEVELS è stato felice di scegliere quel percorso ove possibile.

Amazon Elastic Compute Cloud (EC2)

Affidarsi a un ambiente collaudato che esegue istanze EC2 è ancora un approccio piuttosto ragionevole, rispetto al sovraccarico e alla complessità aggiuntivi dell'esecuzione di container o ai concetti architetturali ancora molto giovani e in rapida evoluzione dell'elaborazione serverless.

Il provisioning delle istanze EC2 deve essere completamente automatizzato. L'automazione è ottenuta tramite AMI personalizzate per diverse classi di server e Auto Scaling Groups che si occupano dell'esecuzione di flotte di server dinamici mantenendo il numero appropriato di istanze di server in esecuzione nella flotta in base al traffico corrente.

Inoltre, la funzione di ridimensionamento automatico consente di impostare il limite inferiore e superiore del numero di istanze EC2 da eseguire. Il limite inferiore aiuta nella tolleranza ai guasti, eliminando potenzialmente i tempi di fermo in caso di guasti delle istanze. Il limite superiore mantiene i costi sotto controllo, consentendo un certo rischio di fermo macchina in caso di condizioni estreme impreviste. Il ridimensionamento automatico ridimensiona quindi dinamicamente il numero di istanze entro tali limiti.

Servizio database relazionale Amazon (RDS)

Il team ha già eseguito Amazon RDS per MySQL , ma la strategia di backup, tolleranza agli errori e sicurezza appropriata doveva ancora essere sviluppata. Nella prima iterazione, l'istanza del database è stata aggiornata a un cluster a due istanze in ogni VPC, configurato come master e replica di lettura, supportando il failover automatico.

Nell'iterazione successiva, con la disponibilità del motore MySQL versione 5.7, l'infrastruttura ha ottenuto un aggiornamento al servizio Amazon Aurora MySQL . Sebbene sia completamente gestita, Aurora non è una soluzione scalabile automaticamente. Offre il ridimensionamento automatico dello storage, evitando il problema della pianificazione della capacità. Ma un architetto di soluzioni deve ancora scegliere la dimensione dell'istanza di elaborazione.

I tempi di inattività dovuti al ridimensionamento non possono essere evitati, ma possono essere ridotti al minimo con l'aiuto della capacità di riparazione automatica. Grazie a migliori capacità di replica, Aurora offre una funzionalità di failover senza interruzioni. Il ridimensionamento viene eseguito creando una replica di lettura con la potenza di elaborazione desiderata e quindi eseguendo il failover su tale istanza. Tutte le altre repliche di lettura vengono quindi rimosse dal cluster, ridimensionate e riportate nel cluster. Richiede un po' di giocoleria manuale ma è più che fattibile.

La nuova offerta Aurora Serverless consente anche un certo livello di ridimensionamento automatico delle risorse di elaborazione, una funzionalità che vale sicuramente la pena esaminare in futuro.

Servizi AWS gestiti

A parte questi due componenti, il resto del sistema beneficia dei meccanismi di ridimensionamento automatico dei servizi AWS completamente gestiti. Si tratta di Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), Amazon S3 Object Storage, funzioni AWS Lambda e Amazon Simple Notification Service (SNS), dove non è necessario alcuno sforzo di ridimensionamento particolare da parte dell'architetto.

Infrastrutture mutevoli e immutabili

Riconosciamo due approcci alla gestione dell'infrastruttura dei server: un'infrastruttura mutevole in cui i server vengono installati e continuamente aggiornati e modificati sul posto; e un'infrastruttura immutabile in cui i server non vengono mai modificati dopo il provisioning e tutte le modifiche alla configurazione o gli aggiornamenti del server vengono gestiti fornendo nuovi server da un'immagine comune o da uno script di installazione, sostituendo quelli vecchi.

Con LEVELS, la scelta è di eseguire un'infrastruttura immutabile senza aggiornamenti sul posto, modifiche alla configurazione o azioni di gestione. L'unica eccezione sono le distribuzioni delle applicazioni, che avvengono sul posto.

Maggiori informazioni sull'infrastruttura mutabile e immutabile possono essere trovate nel blog di HashiCorp.

Panoramica dell'architettura

Tecnicamente, LEVELS è un'app mobile e un'app Web con il backend dell'API REST e alcuni servizi in background, un'applicazione piuttosto tipica al giorno d'oggi. A tal proposito è stata proposta e configurata la seguente infrastruttura:

Isolamento della rete virtuale - Amazon VPC

Il diagramma visualizza una struttura di un ambiente nel suo VPC. Altri ambienti seguono la stessa struttura (con il cluster Application Load Balancer (ALB) e Amazon Aurora condivisi tra gli ambienti non di produzione nel VPC, ma la configurazione di rete è esattamente la stessa).

Il VPC è configurato in quattro zone di disponibilità all'interno di una regione AWS per la tolleranza agli errori. Sottoreti e gruppi di sicurezza con elenchi di controllo dell'accesso alla rete consentono di soddisfare i requisiti di sicurezza e controllo dell'accesso.

L'estensione dell'infrastruttura in più regioni AWS per un'ulteriore tolleranza agli errori sarebbe stata troppo complessa e non necessaria in una fase iniziale dell'attività e del relativo prodotto, ma è un'opzione in futuro.

Informatica

LEVELS esegue un'API REST tradizionale con alcuni lavoratori in background per la logica dell'applicazione che si verifica in background. Entrambi vengono eseguiti come flotte dinamiche di semplici istanze EC2, completamente automatizzate tramite Auto Scaling Groups. Il servizio gestito di Amazon SQS viene utilizzato per la distribuzione delle attività in background (lavori), evitando la necessità di eseguire, mantenere e ridimensionare il proprio server MQ.

Ci sono anche alcune attività di utilità che non hanno una logica aziendale condivisa con il resto dell'applicazione, come l'elaborazione delle immagini. Tali tipi di attività funzionano molto bene su AWS Lambda , poiché i Lambda sono scalabili orizzontalmente indefinitamente e offrono un'elaborazione parallela senza pari rispetto ai server di lavoro.

Bilanciamento del carico, ridimensionamento automatico e tolleranza ai guasti

Il bilanciamento del carico può essere ottenuto manualmente tramite Nginx o HAProxy, ma la scelta di Amazon Elastic Load Balancing (ELB) aggiunge il vantaggio di avere l'infrastruttura di bilanciamento del carico scalabile intrinsecamente automaticamente, a disponibilità elevata e tollerante ai guasti.

Viene utilizzata la versione Application Load Balancer (ALB) dell'ELB, che utilizza il routing del livello HTTP disponibile nel sistema di bilanciamento del carico. Le nuove istanze aggiunte alla flotta vengono registrate automaticamente con l'ALB attraverso i meccanismi della piattaforma AWS. L'ALB monitora inoltre la disponibilità delle istanze in ogni momento. Ha il potere di annullare la registrazione e terminare le istanze malsane, attivando il ridimensionamento automatico per sostituirle con quelle nuove. Attraverso questa interazione tra i due, si ottiene l'auto-guarigione della flotta EC2.

Archivio dati dell'applicazione

L'archivio dati dell'applicazione è un cluster Amazon Aurora MySQL , costituito da un'istanza master e una serie di istanze di replica di lettura. In caso di errore dell'istanza master, una delle repliche di lettura viene promossa automaticamente a una nuova istanza master. Configurato come tale, soddisfa il requisito di tolleranza ai guasti richiesto.

Le repliche di lettura, come suggerisce il nome, possono essere utilizzate anche per distribuire il carico del cluster di database per le operazioni di lettura dei dati.

Lo storage del database viene ridimensionato automaticamente con incrementi di 10 GB con Aurora e anche i backup sono completamente gestiti da AWS, offrendo un ripristino point-in-time per impostazione predefinita. Tutto ciò riduce praticamente a zero il carico di amministrazione del database, ad eccezione dell'aumento della potenza di elaborazione del database quando se ne presenta la necessità, un servizio che vale la pena pagare per funzionare senza preoccupazioni.

Archiviazione e gestione delle risorse

LEVELS accetta i contenuti caricati dagli utenti che devono essere archiviati. Lo storage di oggetti Amazon S3 è, abbastanza prevedibilmente, il servizio che si occuperà di tale attività. Ci sono anche risorse dell'applicazione (elementi dell'interfaccia utente - immagini, icone, caratteri) che devono essere messe a disposizione dell'app client, in modo che vengano archiviate anche nell'S3. Offrendo backup automatizzati dei dati caricati attraverso la loro replica di archiviazione interna, S3 fornisce la durabilità dei dati per impostazione predefinita.

Le immagini caricate dagli utenti sono di varie dimensioni e peso, spesso inutilmente grandi per essere servite direttamente e in sovrappeso, gravando sulle connessioni mobili. La produzione di diverse varianti di dimensioni diverse consentirà di offrire contenuti più ottimizzati per ogni caso d'uso. AWS Lambda viene sfruttato per tale attività, nonché per creare una copia delle immagini originali caricate in un bucket di backup separato, per ogni evenienza.

Infine, un'applicazione Web in esecuzione su browser è anche un insieme di risorse statiche: l'infrastruttura di build Continuous Integration compila il codice JavaScript e archivia ogni build anche in S3.

Una volta che tutte queste risorse sono state archiviate in modo sicuro in S3, possono essere servite direttamente, poiché S3 fornisce un'interfaccia HTTP pubblica o tramite Amazon CloudFront CDN. CloudFront distribuisce le risorse geograficamente, riducendo la latenza agli utenti finali e abilita anche il supporto HTTPS per servire le risorse statiche.

Fornitura e gestione delle infrastrutture

Il provisioning dell'infrastruttura AWS è una combinazione di rete, risorse e servizi gestiti da AWS e risorse di calcolo EC2 nude. I servizi AWS gestiti sono, beh, gestiti. Non c'è molto a che fare con loro se non il provisioning e l'applicazione della sicurezza appropriata, mentre con le risorse di elaborazione EC2 dobbiamo occuparci della configurazione e dell'automazione da soli.

Utensili

La Console AWS basata sul Web rende la gestione dell'infrastruttura AWS "simile a dei mattoncini lego" tutt'altro che banale e, come qualsiasi lavoro manuale, piuttosto soggetta a errori. Ecco perché l'utilizzo di uno strumento dedicato per automatizzare quel lavoro è altamente desiderato.

Uno di questi strumenti è AWS CloudFormation , sviluppato e mantenuto da AWS. Un altro è Terraform di HashiCorp, una scelta leggermente più flessibile che offre più fornitori di piattaforme, ma interessante qui principalmente a causa della filosofia di approccio all'infrastruttura immutabile di Terraform. In linea con il modo in cui viene eseguita l'infrastruttura LEVELS, Terraform, insieme a Packer per la fornitura delle immagini AMI di base, si è rivelata un'ottima soluzione.

Documentazione infrastrutturale

Un ulteriore vantaggio di uno strumento di automazione è che non richiede documentazione dettagliata dell'infrastruttura, che prima o poi diventa obsoleta. Il paradigma “Infrastructure as Code” (IaC) dello strumento di provisioning funge da documentazione, con il vantaggio di essere sempre aggiornato con l'infrastruttura reale. Avere una panoramica di alto livello, meno soggetta a modifiche e relativamente facile da mantenere con le eventuali modifiche, documentate a lato è quindi sufficiente.

Pensieri finali

L'infrastruttura AWS Cloud proposta è una soluzione scalabile in grado di soddisfare la crescita futura dei prodotti per lo più in modo automatico. Dopo quasi due anni riesce a mantenere bassi i costi operativi, affidandosi all'automazione del cloud senza avere un team operativo dedicato ai sistemi attivo 24 ore su 24, 7 giorni su 7.

Per quanto riguarda la sicurezza, AWS Cloud conserva tutti i dati e tutte le risorse all'interno di una rete privata all'interno dello stesso cloud. Nessun dato riservato è mai richiesto per viaggiare attraverso la rete pubblica. L'accesso esterno è concesso con autorizzazioni granulari fini ai sistemi di supporto affidabili (CI/CD, monitoraggio esterno o avvisi), limitando l'ambito di accesso solo alle risorse necessarie per il loro ruolo nell'intero sistema.

Architetturato e configurato correttamente, un tale sistema è flessibile, resiliente, sicuro e pronto a rispondere a tutti i requisiti futuri relativi alla scalabilità per la crescita del prodotto o all'implementazione di sicurezza avanzata come la conformità PCI-DSS.

Non è necessariamente più economico delle offerte prodotte da artisti del calibro di Heroku o piattaforme simili, che funzionano bene purché si adattino ai modelli di utilizzo comuni coperti dalle loro offerte. Scegliendo AWS ottieni un maggiore controllo sulla tua infrastruttura, un ulteriore livello di flessibilità con la gamma di servizi AWS offerti e una configurazione personalizzata con la capacità di messa a punto dell'intera infrastruttura.

Ulteriori letture sul blog di Toptal Engineering:

• Fai i compiti: 7 consigli per l'esame di architetto di soluzioni certificate AWS
• Terraform vs. CloudFormation: la guida definitiva
• Registrazione SSH e gestione delle sessioni tramite AWS SSM
• Lavorare con TypeScript e Jest Support: un tutorial AWS SAM