Ieri 20 ottobre si è tenuta l’edizione londinese di GCP NEXT World Tour, la serie di eventi che porta gli ingegneri Google a giro per il mondo a raccontare le meraviglie della loro Cloud Platform. Durante il keynote dell’evento di ieri sono stati fatti due annunci importanti:

  • Google Stackdriver, la piattaforma di logging e monitoring per sistemi on-premise, GCP e AWS, è passata in General Availability.
  • Google Cloud Storage (GCS), il servizio object storage di GCP, ha subito un profondo restyling, con nuove tipologie di storage e nuove features estremamente interessanti.

In questo articolo descriverò le novità di GCS che mi hanno colpito maggiormente.

Storage per tutti i gusti

Un servizio di block storage su infrastruttura cloud può essere usato per una gran varietà di applicazioni: distribuzione di contenuti, storage applicativo (ad esempio per applicazioni Big Data), backup e disaster recovery, e la lista potrebbe continuare. Ognuno di questi scenari presenta dinamiche specifiche, che determinano requisiti specifici; tali requisiti devono essere gestiti con un servizio appropriato in termini di latenza, velocità di recupero, costi di storage e di retrieval.

Per venire incontro ad ogni tipo di esigenza, l’offerta Google Cloud Storage si arricchisce con 4 nuove storage classes:

new storage classes Google Cloud Storage

  • Multi-Regional: massima disponibilità dei dati, perfetta per content delivery o dati acceduti molto frequentemente
  • Regional: i dati sono conservati all’interno di una sola regione, per offrire le migliori performance con applicazioni di data analytics
  • Nearline e Coldline: due diversi tier per garantire la massima flessibilità di archiviazione, mantenendo performance e modalità di accesso consistenti.

Il prezzo della nuova storage class Coldline è in linea con quanto offerto da Amazon con il suo strumento di archiviazione Glacier. Coldline, tuttavia, garantisce un accesso consistente rispetto agli altri livelli di storage (leggi: le API sono le stesse), ha un tempo di accesso nell’ordine dei millisecondi (che fa un certo effetto, comparato alle ore necessarie per recuperare un vault da Glacier), e come dettaglieremo nel prossimo paragrafo, garantisce un’estrema flessibilità nel passaggio da una classe di storage all’altra (cosa che su Amazon è invece più complessa, essendo Amazon Glacier ed Amazon S3 due sistemi distinti).

Data Management Lifecycle

Come abbiamo visto, i nuovi livelli di storage rendono Cloud Storage uno strumento adatto in ogni situazione. Dove però la cosa – almeno secondo il mio parere – si fa realmente interessante, è sulle possibilità offerte dal nuovo meccanismo di gestione del ciclo di vita dei dati. Tali regole infatti, includono il passaggio automatico dei singoli oggetti da una classe di storage all’altra, superando il vincolo di dover assegnare una singola storage class ad un intero bucket.

Mi spiego con un esempio: abbiamo un bucket che colleziona file di log prodotti giornalmente dai nostri sistemi. Generalmente ci interessa analizzare solo una parte di questi log, diciamo quelli prodotti nell’arco degli ultimi 30 giorni. Più di rado ci troviamo a dover fare analisi che coprono un periodo temporale più lungo, diciamo un anno. Infine, per ragioni legali siamo tenuti a conservare i log relativi agli ultimi 5 anni.

Questo scenario piuttosto comune descrive tre diverse modalità di utilizzo dello stesso dato. Il nostro strumento di storage dovrebbe adattarsi a queste modalità garantendoci performance adeguate per ognuna di esse (e adattando coerentemente il pricing). Se poi la transizione da una modalità di storage ad un’altra avvenisse in maniera automatica e trasparente, sarebbe il massimo.

Detto, fatto! Con le nuove modalità di Lifecycle Management di GCS, possiamo implementare tutto il meccanismo con una singola istruzione da riga di comando.

Eccola qua:

gsutil lifecycle set config-file.json gs://noovle-website-logs

gsutil → è un tool da riga di comando incluso nella suite Google Cloud SDK, liberamente scaricabile da https://cloud.google.com/sdk/.

gs://noovle-website-logs → è il nome del nostro bucket di esempio.

config-file.json → è il nome di un file che contiene la nuova configurazione di Lifecycle Management.

Il contenuto di questo file, nel nostro caso, è il seguente:
{
"rule":[
{
"action":
{
"type": "SetStorageClass",
"storageClass": "NEARLINE"
},
"condition": {"age": 30}
},
{
"action":
{
"type": "SetStorageClass",
"storageClass": "COLDLINE"
},
"condition": {"age": 365}
},
{
"action":
{
"type": "Delete"
},
"condition": {"age": 1825}
}
] }

Voilà! Tre semplici regole che istruiscono Cloud Storage a:

  • Spostare ogni oggetto più vecchio di 30 giorni nella Storage Class Nearline
  • Spostare ogni oggetto più vecchio di 365 giorni nella Storage Class Coldline
  • Cancellare ogni oggetto più vecchio di 5 anni (1825 giorni)

Semplice no? Se siete interessati ad ulteriori dettagli sulle novità di Google Cloud Storage, leggete il post dell’annuncio ufficiale, o date un’occhiata alla documentazione.