Nel cloud computing, la gestione delle dimensioni è un obiettivo e una sfida. Ciò è particolarmente vero per le aziende che devono distribuire aggiornamenti software o firmware via etere (OTA). La sfida consiste nel gestire i volumi, garantendo che i caricamenti e i download siano sicuri, efficienti e tempestivi. Un'impostazione comune per questo tipo di operazioni consiste nell'utilizzare un file system virtuale montato su un server cloud privato con un CDN per distribuire il software a livello globale. Sebbene si tratti di una configurazione adeguata a cui molte aziende si sono affidate per scalare la distribuzione, come si fa a trovare un equilibrio tra questa soluzione e la riduzione dei costi? Questo non è solo uno scenario ipotetico: molte aziende si trovano ad affrontare sfide simili, tra cui un nostro cliente del settore elettronico che doveva distribuire aggiornamenti del firmware OTA a milioni di smart TV in tutto il mondo.
La distribuzione di software di questo tipo comporta una posta in gioco elevata. Gli aggiornamenti possono riguardare nuove funzionalità, perfezionamento dell'interfaccia utente, patch di sicurezza o miglioramenti delle prestazioni. Un'azienda che gestisce gli aggiornamenti OTA deve assicurarsi che, se decine di migliaia di clienti aggiornano i loro televisori nello stesso momento, la soluzione sia in grado di gestire il carico in modo efficiente senza costi aggiuntivi o spese generali. Non si tratta di una sfida unica. Migliaia di aziende utilizzano l'OTA per i loro prodotti e software.
Nel caso del nostro cliente, il produttore ha inizialmente utilizzato diversi servizi per gestire questo aspetto: Content Delivery Network (CDN) di Akamai per la distribuzione globale, Elastic Compute Cloud (EC2) diAWS per la potenza di calcolo, Elastic Load Balancer per il traffico in entrata ed Elastic File System (EFS) per l'archiviazione e la gestione dei file del firmware. Questa configurazione è stata realizzata per gestire una distribuzione di dati su scala immensa in tutto il mondo. Tuttavia, ha comportato anche un prezzo elevato, in particolare per i costi di uscita.
AWSEFS era parte integrante delle attività del produttore e consentiva di archiviare e gestire gli aggiornamenti del sistema operativo e del firmware a livello centrale, nonché di distribuirli in modo efficiente a livello globale grazie all'integrazione con EC2 e Elastic Load Balancer. Tuttavia, i costi associati a EFS, in particolare quando si tratta di trasferimenti di dati su larga scala al di fuori delle reti di AWS, sono diventati una preoccupazione crescente.
L'aumento dei costi associati a EFS, in particolare per quanto riguarda le tariffe di uscita dal sito AWS, ha portato a rivalutare il sistema di archiviazione e distribuzione degli aggiornamenti delle smart TV. Questo ha segnato un momento cruciale nella strategia del produttore di gestire i costi mantenendo il suo solido sistema di distribuzione globale, passando da EFS a Linode Object Storage.
Soluzione
Object Storage L'economicità non era sufficiente a convincere questo cliente a migrare da EFS. Doveva anche integrarsi perfettamente con il flusso di lavoro esistente. Sono riusciti a farlo con l'aiuto del team di supporto di Akamai e di alcuni strumenti open source.
All'interno della loro architettura, hanno creato un bucket primario Object Storage nella regione Asia-Pacifico e Giappone e un secondo bucket negli Stati Uniti che funge da backup. Questa ridondanza evita la perdita di dati e garantisce che la disponibilità degli aggiornamenti del firmware rimanga costante anche in caso di guasto del bucket di archiviazione primario. I due bucket vengono sincronizzati utilizzando rclone, un'utility open source nota per la sua efficienza nel trasferimento e nella sincronizzazione dei file. Questo strumento è stato fondamentale per garantire che entrambi i bucket potessero fungere da server di origine affidabili per la CDN.
La transizione ha comportato una sfida tecnica significativa: sostituire la soluzione di archiviazione esistente (EFS) con un nuovo protocollo di archiviazione (Object Storage) senza interrompere il flusso di lavoro. EFS e Object Storage sono fondamentalmente diversi per architettura e funzionalità. EFS fornisce un'interfaccia e una semantica da file system, essenziali per molte applicazioni che richiedono un file system tradizionale. Al contrario, Object Storage è accessibile tramite un'API web, che non supporta nativamente le operazioni del file system. Di conseguenza, non è possibile sostituire semplicemente EFS con Object Storage.
Per ovviare a questo problema, abbiamo utilizzato S3FS, uno strumento open source che simula un'interfaccia di file system in cima all'API S3 . S3FS ci ha permesso di "montare" i bucket di Object Storage sulle istanze EC2 esistenti del produttore, in modo da comportarsi come EFS. Questo approccio ha permesso alle applicazioni e ai processi esistenti di interagire con Object Storage come se fosse un file system tradizionale, riducendo al minimo le modifiche necessarie al codice dell'applicazione e il rischio di errori durante la transizione.
Questa architettura (sopra) non solo snellisce il processo di aggiornamento del software su milioni di dispositivi in tutto il mondo, ma consente anche un significativo risparmio sui costi. Passando dall'Elastic File System (EFS) di AWSa Object Storage, l'azienda ha ridotto drasticamente i costi di storage: Object Storage si è rivelato più di 15 volte meno costoso per GB rispetto a EFS. È stata inoltre registrata una riduzione del 90% dei costi di uscita, con un miglioramento sostanziale rispetto al precedente ambiente AWS . Questi risparmi dimostrano l'efficacia della nuova soluzione di storage nel gestire sia l'efficienza operativa che l'economicità.
Non si trattava solo di un aggiornamento tecnico, ma di un riallineamento con gli obiettivi di efficienza, scalabilità e gestione dei costi del produttore. Adottando Object Storage e integrandolo senza problemi (con l'aiuto di strumenti come rclone e S3FS), il produttore ha potuto ridurre significativamente i costi operativi senza compromettere l'affidabilità o la velocità della distribuzione globale del firmware. Questo caso di studio dimostra come le decisioni sull'adozione della tecnologia possano avere un impatto significativo sui profitti di un'organizzazione.
Analisi critica dell'efficacia dei costi
Esaminando la transizione da AWS a Linode tramite Akamai, la decisione appare inizialmente come una chiara vittoria in termini di risparmio sui costi. Tuttavia, un'immersione più profonda nelle strutture dei costi e nel confronto dei prodotti rivela alcune sfumature. Ecco alcuni punti decisionali chiave da tenere a mente:
- AWS S3 vs. Linode Object Storage: L'architettura iniziale incanalava un notevole traffico in uscita attraverso Elastic Load Balancer verso il CDN Akamai. Data questa struttura, l'uso di Object Storage è risultato più conveniente di AWS S3 grazie ai costi di uscita significativamente inferiori. Tuttavia, se abbinato a AWS Cloudfront, i costi di egress per l'archiviazione degli oggetti potrebbero essere pari a zero.
- AWS Cloudfront vs. Akamai CDN: La scelta di Akamai rispetto a AWS Cloudfront è stata influenzata dalla necessità di ridurre al minimo le modifiche all'architettura. L'organizzazione ha apprezzato le prestazioni, l'affidabilità e il supporto comprovati di Akamai e la flessibilità offerta dall'utilizzo di più fornitori di cloud.
Per quantificare l'impatto finanziario, consideriamo uno scenario ipotetico in cui, su base mensile, un cliente gestisce 50 TB di dati archiviati con 100 TB di trasferimenti in uscita. Di seguito è riportata una ripartizione semplificata dei costi per AWS EFS, AWS S3 e Linode Object Storage:
Soluzione di stoccaggio | Calcolo | Costo totale |
AWS EFS | (0,3$/GB * 50.000GB) + (0,03$/GB * 100.000GB) | $18,000 |
AWS S3 | (0,023$/GB * 50.000GB) + (0,09$/GB * 10.000GB) + (0,085$ * 40.000GB) + (0,07$/GB * 50.000GB) | $8,950 |
Linode Object Storage | (0,02$/GB * 50.000GB) + (0,005$/GB * 49.000GB) | $1,245 |
(Nota: i confronti tra i prezzi olistici sono difficili. Questo dato tiene conto solo dei costi di archiviazione e di larghezza di banda per l'archiviazione dei file, ma non tiene conto della CDN. Vale anche la pena ricordare che alcuni provider offrono tariffe più scontate per i clienti con volumi eccezionalmente elevati).
Vediamo ora i costi comparativi associati all'archiviazione e all'uscita per questi servizi cloud (Nota: i prezzi si basano sul costo al momento della stesura di questo articolo).
Tipo di servizio | Descrizione dei costi | Prezzo | Note |
Conservazione EFS | Per GB al mese | $0,30/GB | API intuitiva e facile da usare, ma costo elevato. Considerare alternative per grandi volumi |
S3 Immagazzinamento | Per GB al mese per i primi 50 TB | 0,023 DOLLARI/GB | Economico per l'archiviazione di grandi quantità di dati |
S3 Uscita | Per GB per i primi 10 TB | $0,09/GB | Più costoso per il trasferimento di dati elevati, a meno che non sia abbinato a Cloudfront. |
Per GB per i successivi 40 TB | 0,085 DOLLARI/GB | Scalare i costi con il volume | |
Per GB per i successivi 100 TB | $0,07/GB | Tariffe migliori per trasferimenti di volumi ancora più elevati | |
Stoccaggio Linode | Per GB al mese | $0,02/GB | Il più conveniente per l'archiviazione |
Ingresso Linode | Prima 1 TB gratuito, poi per GB | $0,005/GB | Significativi risparmi sull'uscita dei dati, massimizzazione dell'efficienza del budget |
In questa analisi, l'utilizzo di Object Storage è circa 1/15 del costo della soluzione originale con AWS EFS e circa 1/7 del costo dell'utilizzo di AWS S3 (supponendo che AWS Cloudfront non venga utilizzato per compensare le tariffe di uscita).
Conclusione
Questo confronto dei costi illustra i notevoli risparmi ottenuti passando a Linode Object Storage. Evidenzia inoltre l'importanza di adattare le soluzioni cloud alle specificità dei modelli di traffico e dei requisiti della rete di distribuzione dei contenuti (CDN) di un'azienda. Quando le aziende analizzano le proprie strategie di utilizzo e distribuzione dei dati, possono scoprire significative opportunità di risparmio che altrimenti potrebbero essere trascurate.
La decisione di cambiare soluzione di storage non è stata presa alla leggera, ma è stata supportata da una valutazione dettagliata dei requisiti operativi e degli obiettivi finanziari dell'azienda. Comprendendo il volume dei dati gestiti, la frequenza di accesso ai dati e la distribuzione geografica degli utenti, l'azienda è stata in grado di identificare Linode come la soluzione più conveniente che soddisfaceva anche le sue esigenze. Questo tipo di processo decisionale informato è fondamentale nelle architetture cloud, dove i costi possono variare drasticamente in base al tipo di storage, ai volumi di trasferimento dei dati e alle frequenze di accesso.
Mentre i programmatori e gli architetti dovrebbero concentrarsi sulle prestazioni e sulla scalabilità di una soluzione, potrebbero anche dover considerare l'impatto finanziario sulle aziende per cui lavorano. Le soluzioni non devono solo soddisfare i requisiti tecnici, ma anche allinearsi alle più ampie strategie finanziarie di un'organizzazione. In questo modo si possono evitare gli sforamenti di budget e garantire che gli investimenti IT offrano il massimo rendimento possibile.
Aiutiamo continuamente le aziende a progettare soluzioni di questo tipo. Se volete saperne di più su come implementare voi stessi, iscrivetevi alla nostra newsletter, collegatevi con noi su Twitter o LinkedIn, o iscrivetevi al nostro canale YouTube. Oltre a queste guide tecniche, se voi o la vostra organizzazione state pensando di ottimizzare le vostre soluzioni di cloud storage e CDN, potete provare le soluzioni di Linode iscrivendovi e ricevendo 100 dollari di crediti gratuiti.
Commenti