Efficienza su larga scala: una storia sull'ottimizzazione dei costi di AWS

Pubblicato: 2022-07-22

Di recente ho lanciato una piattaforma di analisi delle criptovalute, aspettandomi un numero limitato di utenti giornalieri. Tuttavia, quando alcuni YouTuber popolari hanno trovato utile il sito e hanno pubblicato una recensione, il traffico è cresciuto così rapidamente da sovraccaricare il server e la piattaforma (Scalper.AI) è diventata inaccessibile. Il mio ambiente AWS EC2 originale necessitava di ulteriore supporto. Dopo aver considerato più soluzioni, ho deciso di utilizzare AWS Elastic Beanstalk per scalare la mia applicazione. Le cose stavano andando bene e funzionavano senza intoppi, ma sono rimasto sbalordito dai costi nella dashboard di fatturazione.

Questo non è un problema raro. Un sondaggio del 2021 ha rilevato che l'82% dei decisori IT e cloud ha riscontrato costi cloud non necessari e l'86% non ritiene di poter ottenere una visione completa di tutte le proprie spese per il cloud. Sebbene Amazon offra una panoramica dettagliata delle spese aggiuntive nella sua documentazione, il modello di prezzo è complesso per un progetto in crescita. Per rendere le cose più facili da capire, analizzerò alcune ottimizzazioni rilevanti per ridurre i costi del cloud.

Perché ho scelto AWS

L'obiettivo di Scalper.AI è raccogliere informazioni sulle coppie di criptovalute (gli asset scambiati durante il trading su uno scambio), eseguire analisi statistiche e fornire ai trader di criptovalute approfondimenti sullo stato del mercato. La struttura tecnica della piattaforma è composta da tre parti:

Script di importazione dei dati
Un server web
Una banca dati

Gli script di importazione raccolgono dati da diverse origini e li caricano nel database. Avevo esperienza di lavoro con i servizi AWS, quindi ho deciso di distribuire questi script configurando le istanze EC2. EC2 offre molti tipi di istanza e ti consente di scegliere il processore, lo storage, la rete e il sistema operativo di un'istanza.

Ho scelto Elastic Beanstalk per le restanti funzionalità perché prometteva una gestione fluida delle applicazioni. Il servizio di bilanciamento del carico ha distribuito correttamente il carico tra le istanze del mio server, mentre la funzione di scalabilità automatica ha gestito l'aggiunta di nuove istanze per un carico maggiore. La distribuzione degli aggiornamenti è diventata molto semplice, richiedendo solo pochi minuti.

Scalper.AI ha funzionato in modo stabile e i miei utenti non hanno più dovuto affrontare tempi di inattività. Certo, mi aspettavo un aumento della spesa poiché ho aggiunto servizi extra, ma i numeri erano molto più grandi di quanto avessi previsto.

Come avrei potuto ridurre i costi del cloud

Guardando indietro, c'erano molte aree di complessità nell'uso dei servizi AWS da parte del mio progetto. Esamineremo le ottimizzazioni del budget che ho scoperto lavorando con le funzionalità comuni di AWS EC2: istanze con prestazioni espandibili, trasferimenti di dati in uscita, indirizzi IP elastici e stati di terminazione e arresto.

Istanze di prestazioni espandibili

La mia prima sfida è stata supportare il consumo di energia della CPU per il mio progetto in crescita. Gli script di acquisizione dei dati di Scalper.AI forniscono agli utenti un'analisi delle informazioni in tempo reale; gli script vengono eseguiti ogni pochi secondi e alimentano la piattaforma con gli aggiornamenti più recenti dagli scambi di criptovalute. Ogni iterazione di questo processo genera centinaia di lavori asincroni, quindi l'aumento del traffico del sito ha richiesto più potenza della CPU per ridurre il tempo di elaborazione.

L'istanza più economica offerta da AWS con quattro vCPU, a1.xlarge, mi sarebbe costata circa $ 75 al mese in quel momento. Invece, ho deciso di distribuire il carico tra due istanze t3.micro con due vCPU e 1 GB di RAM ciascuna. Le istanze t3.micro offrivano velocità e memoria sufficienti per il lavoro di cui avevo bisogno a un quinto del costo di a1.xlarge. Tuttavia, il mio conto era ancora più alto di quanto mi aspettassi alla fine del mese.

Nel tentativo di capire il motivo, ho cercato nella documentazione di Amazon e ho trovato la risposta: quando l'utilizzo della CPU di un'istanza scende al di sotto di una linea di base definita, raccoglie crediti, ma quando l'istanza supera l'utilizzo della linea di base, consuma i crediti guadagnati in precedenza. Se non ci sono crediti disponibili, l'istanza spende i "crediti in eccedenza" forniti da Amazon. Questa capacità di guadagnare e spendere crediti fa sì che Amazon EC2 utilizzi in media la CPU di un'istanza nell'arco di 24 ore. Se l'utilizzo medio supera la linea di base, l'istanza viene addebitata a una tariffa fissa per ora di vCPU.

Ho monitorato le istanze di importazione dei dati per più giorni e ho scoperto che la configurazione della mia CPU, che aveva lo scopo di ridurre i costi, ha fatto il contrario. Il più delle volte, il mio utilizzo medio della CPU era superiore alla linea di base.

Un grafico ha tre selezioni a discesa scelte nella parte superiore dello schermo. I primi due, a sinistra, sono "10 febbraio 2022 - 19 febbraio 2022" e "Giornaliero", seguiti da una piccola "i" cerchiata. Il terzo è a destra dello schermo e dice "Linea" con un simbolo per un grafico a linee. Sotto le selezioni a discesa, il grafico contiene due grafici a linee con filtri. In alto, la riga del filtro legge "Raggruppa per: Tipo di utilizzo" (il filtro selezionato, che ha uno sfondo blu) e quindi mostra i filtri non selezionati: "Servizio, Account collegato, Regione, Tipo di istanza, Risorsa, Categoria di costo, Tag , Altro", con "Risorsa" in grigio e gli ultimi tre con frecce a discesa accanto a loro. Il grafico della linea superiore ha "Costi ($)" sull'asse y, che vanno da 0,0 a 2,5. Il grafico della linea inferiore ha "Utilizzo (vCPU-Hours)" sull'asse y, che va da 0 a 40. Entrambi i grafici a linee condividono le date etichettate sull'asse x, che vanno dal 10 febbraio al 19 febbraio, e una chiave etichettando le loro linee viola: "USE2-CPUCredits:t3." Il grafico della linea superiore ha circa otto punti collegati linearmente e tende al rialzo nel tempo: un punto intorno (febbraio-10, $ 0,3), un secondo intorno (febbraio-11, $ 0,6), un terzo intorno (febbraio-12, $ 0,5), un quarto intorno (14 febbraio, $ 2,1), un quinto intorno (15 febbraio, $ 2,4), un sesto intorno (16 febbraio, $ 2,3), un settimo intorno (18 febbraio, $ 2,3) e un ottavo intorno (febbraio- 19, $ 2,6). Il grafico della linea inferiore ha anche circa otto punti collegati linearmente e tende al rialzo nel tempo: un punto intorno (Feb-10, 5 vCPU-Hours), un secondo intorno (Feb-11, 15 vCPU-Hours), un terzo intorno (Feb-10, 5 vCPU-Hours), -12, 10 ore vCPU), un quarto circa (14 febbraio, 40 ore vCPU), un quinto circa (15 febbraio, 50 ore vCPU), un sesto circa (16 febbraio, 45 ore vCPU) , un settimo circa (18 febbraio, 45 ore di vCPU) e un ottavo circa (19 febbraio, 55 ore di vCPU). — Il grafico sopra mostra i picchi di costo (grafico in alto) e l'utilizzo del credito della CPU in aumento (grafico in basso) durante un periodo in cui l'utilizzo della CPU era al di sopra della linea di base. Il costo in dollari è proporzionale ai crediti in eccesso spesi, poiché l'istanza viene fatturata per ora vCPU.

Inizialmente avevo analizzato l'utilizzo della CPU per alcune coppie di criptovalute; il carico era piccolo, quindi pensavo di avere molto spazio per la crescita. (Ho usato solo una microistanza per l'importazione dei dati poiché un minor numero di coppie crittografiche non richiedeva la stessa potenza della CPU.) Tuttavia, ho capito i limiti della mia analisi originale una volta che ho deciso di rendere le mie informazioni più complete e supportare l'importazione di dati per centinaia di coppie di criptovalute, l'analisi del servizio cloud non significa nulla se non eseguita sulla scala corretta.

Trasferimenti di dati in uscita

Un altro risultato dell'espansione del mio sito è stato l'aumento dei trasferimenti di dati dalla mia app a causa di un piccolo bug. Con il traffico in costante crescita e senza più tempi di inattività, avevo bisogno di aggiungere funzionalità per catturare e attirare l'attenzione degli utenti il prima possibile. Il mio ultimo aggiornamento è stato un avviso audio attivato quando le condizioni di mercato di una coppia di criptovalute corrispondevano ai parametri predefiniti dell'utente. Sfortunatamente, ho commesso un errore nel codice e i file audio sono stati caricati nel browser dell'utente centinaia di volte ogni pochi secondi.

L'impatto è stato enorme. Il mio bug ha generato download di audio dai miei server Web, causando ulteriori trasferimenti di dati in uscita. Un piccolo errore nel mio codice ha prodotto una fattura quasi cinque volte più grande delle precedenti. (Questa non è stata l'unica conseguenza: il bug potrebbe causare una perdita di memoria nel computer dell'utente, quindi molti utenti hanno smesso di tornare.)

Un grafico simile al precedente ma con il primo elenco a discesa "06 gennaio 2022 - 15 gennaio 2022", "Costi ($)" del grafico della riga superiore che vanno da 0 a 30 e il grafico della riga inferiore con " Utilizzo (GB)" sull'asse y, da 0 a 300. Entrambi i grafici a linee condividono le date etichettate sull'asse x, da gennaio-06 a gennaio-15, e una chiave che etichetta le loro linee viola: "USE2- Byte di trasferimento dati in uscita." Il grafico della linea superiore ha circa otto punti collegati linearmente e tende al rialzo nel tempo: un punto intorno (06 gennaio, $ 2), un secondo intorno (08 gennaio, $ 4), un terzo intorno (09 gennaio, $ 7), un un quarto intorno (10 gennaio, $ 6), un quinto intorno (12 gennaio, $ 15), un sesto intorno (13 gennaio, $ 25), un settimo intorno (14 gennaio, $ 24) e un ottavo intorno (gennaio- 15, $ 29). Il grafico della linea inferiore ha anche circa otto punti collegati linearmente e tende al rialzo nel tempo: un punto intorno (06 gennaio, 10 GB), un secondo intorno (08 gennaio, 50 GB), un terzo intorno (09 gennaio, 80 GB), un quarto circa (10 gennaio, 70 GB), un quinto circa (12 gennaio, 160 GB), un sesto circa (13 gennaio, 270 GB), un settimo circa (14 gennaio, 260 GB) e un ottavo circa (15 gennaio, 320 GB). — Il grafico sopra mostra i picchi di costo (grafico in alto) e l'aumento dei trasferimenti di dati in uscita (grafico in basso). Poiché i trasferimenti di dati in uscita vengono fatturati per GB, il costo in dollari è proporzionale all'utilizzo dei dati in uscita.

I costi di trasferimento dei dati possono rappresentare fino al 30% degli aumenti dei prezzi di AWS. Il trasferimento in entrata EC2 è gratuito, ma le spese di trasferimento in uscita vengono fatturate per GB ($ 0,09 per GB quando ho creato Scalper.AI). Come ho imparato a mie spese, è importante essere cauti con il codice che influisce sui dati in uscita; ridurre i download o il caricamento dei file ove possibile (o monitorare attentamente queste aree) ti proteggerà da commissioni più elevate. Questi centesimi si sommano rapidamente poiché gli addebiti per il trasferimento di dati da EC2 a Internet dipendono dal carico di lavoro e dalle tariffe specifiche della regione AWS. Un ultimo avvertimento sconosciuto a molti nuovi clienti AWS: il trasferimento dei dati diventa più costoso tra posizioni diverse. Tuttavia, l'utilizzo di indirizzi IP privati può evitare costi di trasferimento dati aggiuntivi tra diverse zone di disponibilità della stessa regione.

Indirizzi IP elastici

Anche quando si utilizzano indirizzi pubblici come gli indirizzi IP elastici (EIP), è possibile ridurre i costi EC2. Gli EIP sono indirizzi IPv4 statici utilizzati per il cloud computing dinamico. La parte "elastica" significa che puoi assegnare un EIP a qualsiasi istanza EC2 e utilizzarlo fino a quando non scegli di interromperlo. Questi indirizzi ti consentono di scambiare senza problemi istanze non sane con istanze sane rimappando l'indirizzo a un'istanza diversa nel tuo account. Puoi anche utilizzare gli EIP per specificare un record DNS per un dominio in modo che punti a un'istanza EC2.

AWS fornisce solo cinque EIP per account per regione, rendendoli una risorsa limitata e costosa con un uso inefficiente. AWS addebita una tariffa oraria bassa per ogni EIP aggiuntivo e fattura extra se rimappa un EIP più di 100 volte in un mese; rimanere al di sotto di questi limiti abbasserà i costi.

Termina e ferma gli stati

AWS offre due opzioni per la gestione dello stato delle istanze EC2 in esecuzione: terminare o arrestare. L'interruzione interromperà l'istanza e la macchina virtuale di cui è stato eseguito il provisioning non sarà più disponibile. Tutti i volumi Elastic Block Store (EBS) collegati verranno scollegati ed eliminati e tutti i dati archiviati localmente nell'istanza andranno persi. Non ti verrà più addebitato l'istanza.

L'arresto di un'istanza è simile, con una piccola differenza. I volumi EBS allegati non vengono eliminati, quindi i loro dati vengono conservati e puoi riavviare l'istanza in qualsiasi momento. In entrambi i casi, Amazon non addebita più costi per l'utilizzo dell'istanza, ma se si opta per l'arresto anziché per l'interruzione, i volumi EBS genereranno un costo finché esistono. AWS consiglia di arrestare un'istanza solo se prevedi di riattivarla a breve.

Ma c'è una funzione che può aumentare la tua fattura AWS alla fine del mese anche se hai terminato un'istanza invece di interromperla: gli snapshot EBS. Si tratta di backup incrementali dei tuoi volumi EBS archiviati in Simple Storage Service (S3) di Amazon. Ogni snapshot contiene le informazioni necessarie per creare un nuovo volume EBS con i dati precedenti. Se termini un'istanza, i suoi volumi EBS associati verranno eliminati automaticamente, ma i relativi snapshot rimarranno. Poiché S3 addebita il volume di dati archiviati, ti consiglio di eliminare queste istantanee se non le utilizzerai a breve. AWS offre la possibilità di monitorare l'attività di storage per volume utilizzando il servizio CloudWatch:

Dopo aver effettuato l'accesso alla Console AWS, dal menu Servizi in alto a sinistra, trova e apri il servizio CloudWatch.
Sul lato sinistro della pagina, nel menu comprimibile delle metriche , fai clic su Tutte le metriche .
La pagina mostra un elenco di servizi con metriche disponibili, inclusi EBS, EC2, S3 e altro. Fare clic su EBS e quindi su Metriche per volume . (Nota: l'opzione EBS sarà visibile solo se hai dei volumi EBS configurati sul tuo account.)
Fare clic sulla scheda Interrogazione . Nella vista Editor , copia e incolla il comando SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId e quindi fai clic su Esegui . (Nota: CloudWatch utilizza un dialetto di SQL con una sintassi univoca.)

Una panoramica della configurazione del monitoraggio di CloudWatch descritta sopra (mostrata con dati vuoti e nessun parametro selezionato). Se disponi di istanze EBS, EC2 o S3 esistenti sul tuo account, queste verranno visualizzate come opzioni di parametro e popoleranno il tuo grafico CloudWatch.

CloudWatch offre una varietà di formati di visualizzazione per l'analisi dell'attività di archiviazione, come grafici a torta, linee, barre, grafici ad area in pila e numeri. L'utilizzo di CloudWatch per identificare i volumi e gli snapshot EBS inattivi è un semplice passo verso l'ottimizzazione dei costi del cloud.

Soldi extra in tasca

Sebbene gli strumenti AWS come CloudWatch offrano soluzioni decenti per il monitoraggio dei costi del cloud, varie piattaforme esterne si integrano con AWS per un'analisi più completa. Ad esempio, le piattaforme di gestione del cloud come CloudHealth di VMWare mostrano una ripartizione dettagliata delle aree di spesa più elevate che possono essere utilizzate per l'analisi delle tendenze, il rilevamento delle anomalie e il monitoraggio dei costi e delle prestazioni. Ti consiglio inoltre di impostare un allarme di fatturazione CloudWatch per rilevare eventuali picchi di addebiti prima che diventino eccessivi.

Amazon fornisce molti ottimi servizi cloud che possono aiutarti a delegare il lavoro di manutenzione di server, database e hardware al team AWS. Sebbene i costi della piattaforma cloud possano aumentare facilmente a causa di bug o errori degli utenti, gli strumenti di monitoraggio AWS forniscono agli sviluppatori le conoscenze per difendersi da spese aggiuntive.

Con queste ottimizzazioni dei costi in mente, sei pronto per far decollare il tuo progetto e risparmiare centinaia di dollari nel processo.

In qualità di partner di consulenza avanzata nell'Amazon Partner Network (APN), Toptal offre alle aziende l'accesso a esperti certificati AWS, su richiesta, in qualsiasi parte del mondo.