Cloud Storage: guida a GCS

Google Cloud Storage nasce per conservare e recuperare dati binari come entità complete. Sul vostro computer, un'entità di questo tipo si chiamerebbe file; in GCS, invece, prende il nome di oggetto. A differenza dei file sul computer, gli oggetti GCS sono immutabili: una volta creati, non possono più essere modificati.

Gli oggetti GCS possono essere eliminati o sostituiti, ma non modificati. È una caratteristica che apre la strada a numerose architetture su scala cloud.

Gli oggetti GCS sono inoltre opachi: GCS non ne conosce la struttura interna, perché si tratta semplicemente di sequenze di dati binari. Per tenere traccia di informazioni come data e ora di creazione, tipo MIME e dimensione, GCS si affida ai metadati associati.

Gli oggetti GCS sono durevoli. Google li archivia con un mix di tecniche che garantiscono almeno 11 "nove" di durabilità annuale in una regione, ovvero il 99,999999999%. (Per tutelarsi da perdite legate a disastri locali, naturali o causati dall'uomo, è possibile scegliere di replicare i dati in più regioni o persino su più cloud.) Undici nove significano che, su un miliardo di oggetti archiviati per 100 anni, si registrerebbe al massimo una perdita.

Gli oggetti GCS sono disponibili: GCS è in grado di restituire un oggetto su richiesta. Per la disponibilità mensile sono previste diverse opzioni di SLA: 99,95%, 99,9% o 99,0%. Tradotto in tempo, equivalgono rispettivamente a 22 minuti, 44 minuti o 7 ore e 18 minuti di indisponibilità al mese.

Gli oggetti GCS risiedono in bucket all'interno di un progetto GCP. I bucket forniscono il contesto di archiviazione: identità, progetto host (a cui sono legati sicurezza e account di fatturazione), posizione geografica, policy e molto altro.

Ogni bucket GCS ha un identificatore univoco a livello globale espresso come URI . Per bucket e oggetti GCS, Google adotta lo schema URI gs:.

La sintassi dell'URI è: gs:///

Per esempio, gs://doit-intl-storage/logo.png è un URI univoco a livello globale.

GCS gioca un ruolo di primo piano nelle architetture di molti sistemi cloud. In linea generale, è l'opzione più economica per archiviare informazioni. Per mantenere il giusto equilibrio fra costi e prestazioni, però, è bene tenere d'occhio latenza, banda e i consueti vincoli architetturali.

Va ricordato che GCS è un servizio. L'accesso avviene tramite API REST, a sua volta esposta da librerie client per numerosi linguaggi di programmazione, da una CLI e da molti strumenti di terze parti. GCS non è un sistema di block storage e non può essere usato direttamente come file system per macchine virtuali o container.

I fattori che incidono sul costo di Google Cloud Storage sono diversi. Tra i principali da monitorare:

• Dimensione dell'oggetto
• Durata dell'archiviazione
• Caratteristiche del bucket: posizione, ridondanza e classe di storage
• Attività, come la scrittura e la lettura di un oggetto e dei suoi metadati
• Byte trasmessi su una o più reti durante il trasferimento dell'oggetto

I costi possono essere letti su due piani. Il primo è il costo puro di archiviazione: quanto si spende per conservare un oggetto se, una volta scritto, non viene mai letto né eliminato. Il secondo riguarda i costi legati all'attività: lettura, trasferimento, eliminazione, query e così via.

Qualche numero per inquadrare meglio la situazione. Per il puro costo di archiviazione, prendiamo come esempio un singolo oggetto da 1 GiB conservato per un anno. (1 GiB = 1073741824 byte (= 10243 B = 230 B).)

Lo storage standard più caro si trova in Brasile, a 0,42 $, mentre in molte altre località scende a 0,24 $. Lo storage standard è la scelta migliore per gli oggetti consultati di frequente. Per gli oggetti inattivi, invece, lo storage di classe archive abbatte sensibilmente i costi: 0,036 $ in Brasile, 0,0144 $ altrove.

I costi legati all'attività possono cogliere di sorpresa chi è alle prime armi. Vengono addebitate le operazioni di scrittura, lettura, listing degli oggetti ed eliminazione anticipata (se l'oggetto è archiviato in un contesto di storage a lungo termine). Voci che possono incidere sulla progettazione e persino sull'architettura di un sistema su scala cloud.

Un esempio: ho seguito come consulente un'azienda che gestiva immagini satellitari. Il loro sistema on-premise archiviava una grande quantità di tile di piccole dimensioni. Migrando su GCS, si sono accorti che la loro impostazione — leggere tanti tile piccoli per ricomporre un'immagine di grandi dimensioni — generava costi elevatissimi a causa delle operazioni di lettura.

Hanno quindi ridisegnato il sistema, archiviando meno immagini ma di dimensioni maggiori e scomponendole in memoria dopo la lettura. Un approccio decisamente controintuitivo, ma è la realtà di GCS.

Affronterò il tema più ampio della sicurezza nel cloud in un articolo dedicato. La sicurezza di GCS è gestita tramite IAM. In passato si sono verificate fughe di dati anche gravi, perché era fin troppo facile concedere accidentalmente accesso pubblico a un bucket. Google è intervenuta su questo fronte e oggi sono presenti numerosi meccanismi di avviso.

Per restare in contatto, seguiteci sul DoiT Engineering Blog , sul canale LinkedIn di DoiT e sul canale Twitter di DoiT . Per scoprire le opportunità di carriera, visitate https://careers.doit-intl.com .