Immagine di dennizn da Shutterstock
Un nostro cliente ha recentemente riscontrato un problema sul proprio bucket S3 mentre trasferiva oggetti dalla storage class Standard a Glacier Deep Archive: nonostante lo spostamento, gli oggetti continuavano a comparire nello storage Standard.
Analizzando il bucket S3 del cliente, ho confermato che lo storage Standard non si era effettivamente ridotto rispetto alla dimensione iniziale di 4,9 TB, come si vede nell'immagine seguente, tratta dalla metrica di storage del bucket.
Metrica S3 Total Bucket Size
Dalla metrica S3 Total Bucket Size risulta uno storage Standard di 4,9 TB (rappresentato dalla linea arancione). Il cliente aveva avviato il trasferimento verso Glacier Deep Archive il 6 maggio, ma al 10 maggio la metrica non rifletteva ancora la modifica.
Metrica S3 per lo storage Standard
Aprendo la metrica Total Bucket Size in CloudWatch, ho notato una discrepanza tra le metriche di S3 e quelle di CloudWatch: la metrica S3 indicava 4,9 TB di storage Standard nel bucket, mentre CloudWatch ne mostrava 5,3 TB.
Metriche CloudWatch dei bucket per storage class
Dettaglio delle metriche per ciascuna storage class
Dall'analisi sono emersi due problemi nella transizione degli oggetti tra storage class:
(1) La metrica S3 Standard non si era ridotta dopo lo spostamento degli oggetti su un'altra storage class.
(2) La metrica S3 e quella di CloudWatch mostravano una discrepanza significativa sul totale dello storage Standard.
Risolvere i problemi
Approfondendo la modalità con cui il cliente aveva trasferito gli oggetti da Standard a Glacier Deep Archive, ho scoperto che l'operazione era stata eseguita manualmente dalla console S3: aprendo l'oggetto nella console, era stata selezionata la voce Action, Edit actions, Edit storage class.
Modifica manuale della storage class dell'oggetto
Modificare la storage class di un oggetto dalla console crea in realtà una copia dell'oggetto e mantiene quello esistente come versione precedente (se sul bucket è abilitato il versioning).
In altre parole, quando si modifica la storage class dalla console non si cambia la classe dell'oggetto: viene creato un nuovo file nella storage class selezionata.
Poiché sul bucket è abilitato il versioning, esistono ora due versioni del file: una in Glacier Deep Archive (la versione corrente) e una in Standard (la versione non corrente). È questo il motivo per cui lo storage Standard non si è ridotto.
Lifecycle rule
Indagando sulla discrepanza tra la metrica S3 e quella di CloudWatch per la classe Standard, ho scoperto che le metriche S3 visualizzate nella pagina del bucket considerano solo la dimensione complessiva dei file correnti, mentre CloudWatch include anche i file non correnti e i multipart upload falliti.
Poiché il cliente aveva modificato manualmente la storage class degli oggetti, era stata creata una nuova copia in Glacier Deep Archive come versione corrente, mentre l'oggetto nello storage Standard era diventato la versione non corrente.
Dato che il cliente non aveva bisogno della versione non corrente in Standard, ho consigliato di creare una lifecycle rule per ripulire il bucket e rimuovere le versioni non correnti dallo Standard.
Il cliente ha implementato la seguente lifecycle rule: due giorni dopo che un oggetto diventa non corrente (ovvero viene sostituito da una versione più recente), tutte le sue versioni non correnti vengono eliminate definitivamente.
Lifecycle rule per eliminare le versioni non correnti
**Il risultato**
Una volta applicata la lifecycle rule, il 14 maggio, abbiamo osservato che S3 ha iniziato a rimuovere automaticamente le versioni non correnti.
Lo storage Standard è diminuito dopo l'applicazione della lifecycle rule
La lifecycle rule ha ridotto in modo significativo lo storage del bucket S3, portandolo da 4,9 TB a 1,3 TB. Il cliente ha così ottenuto un risparmio sui costi del bucket S3 e, al contempo, ne ha migliorato le prestazioni.
Un intervento semplice, dunque, che ha permesso al cliente non solo di risparmiare sui costi di storage, ma anche di ottimizzare le prestazioni del bucket. Nel grafico seguente si nota l'aumento dei costi S3 del cliente in corrispondenza della transizione manuale degli oggetti su Glacier Deep Archive del 6 maggio e il successivo calo dopo l'implementazione della lifecycle rule il 14 maggio. Il grafico è generato da DoiT Cloud Navigator — Cloud Analytics.
In sintesi
Questo caso evidenzia quanto siano importanti le lifecycle rule di S3 per una gestione efficace del bucket e per le transizioni tra storage class. La modifica manuale del cliente ha generato una duplicazione inutile tra Glacier Deep Archive e Standard, facilmente evitabile con le lifecycle rule.
Inoltre, sfruttare le metriche di S3 e CloudWatch è fondamentale per capire cosa contiene il bucket S3 e per supportare la gestione dei costi e l'ottimizzazione delle prestazioni.
Contattaci
Per qualsiasi domanda sull'ottimizzazione di S3 o se desidera supporto nella revisione della Sua architettura AWS, non esiti a contattarci su DoiT International. Il nostro team di esperti è sempre a Sua disposizione.